고정된 경로 대신 경계를 긋는 AI 에이전트 설계
전통적인 소프트웨어 엔지니어링은 가능한 결과의 범위를 좁혀 동일한 입력에 언제나 동일한 출력이 나오도록 보장하는 방향으로 발전해 왔습니다. 하지만 협업 관리 플랫폼 Linear는 AI 에이전트를 구축할 때 이와 정반대의 접근 방식을 취했습니다. Linear 엔지니어링 팀의 마티스 볼팅(Matthijs Wolting)은 2026년 8월 10일 기술 블로그를 통해, 사전에 명시적으로 규정하지 않은 방식으로 예상 밖의 문제를 해결하는 데 AI의 진정한 가치가 있다고 밝혔습니다.
Linear는 에이전트의 경로를 촘촘한 스크립트로 고정하는 대신, 에이전트가 스스로 해결 경로를 탐색할 수 있는 다섯 가지 '경계'를 정의했습니다. 이 경계는 상위 시스템 프롬프트, 제약이 인코딩된 도구 디자인, Linear 전용 제품 도메인 모델, 런타임 실행 범위(Scope), 그리고 하부의 자체 오케스트레이션 하네스로 구성됩니다. 시스템 프롬프트는 슬랙과 같은 외부 환경과 내부 워크플로에 맞춘 자연스러운 어조, 종교·정치 등 민감한 영역에 대한 개입 차단, 사용자 요청 범위를 크게 넘어서는 작업에 대한 사전 확인 요구 등 최소한의 원칙에만 집중합니다.
얕은 도구 생태계와 점진적 스킬 공개
Linear 엔지니어링 팀은 자사 에이전트의 구조가 코드베이스를 수정하는 일반적인 코딩 에이전트와 근본적으로 다르다고 설명합니다. 코딩 에이전트는 파일 읽기·쓰기, 명령 실행 등 소수의 '깊은 원시 도구(deep primitives)'를 조합해 작업하며, 사전학습 데이터에 코드와 셸 환경이 풍부하게 포함되어 있습니다. 반면 Linear Agent는 이슈 생성, 문서 수정, 고객 요청 갱신 등 제품의 특정 기능에 직접 묶인 다수의 '비교적 얕은 도구(shallow tools)'를 다뤄야 합니다. 또한 기반 모델의 사전학습 데이터에는 Linear 자체의 데이터 구조나 비즈니스 맥락이 거의 포함되어 있지 않습니다.
이를 극복하기 위해 Linear는 데이터 접근 도구뿐만 아니라 해당 데이터의 제품 내 의미와 모범 활용 원칙을 결합했습니다. 대표적으로 고객 요청(Customer Requests) 기능의 경우, 피드백을 집계하고 이를 프로젝트 기획 문서와 연결하는 패턴을 함께 학습시켰습니다. 또한 모델이 방대한 도구에 압도당하지 않도록 메타데이터, 프롬프트 조각, 도구 묶음을 캡슐화한 '시스템 스킬(System Skills)' 단위를 도입했습니다. 에이전트는 호출 맥락에 따라 필요한 스킬을 선별 로드하거나, 작업 진행 도중 추가 필요성을 자체 판단해 필요한 스킬을 점진적으로 주입(Progressive Disclosure)받습니다.
안전성을 위한 저수준 API 차단과 기능적 한계
Linear Agent 아키텍처에서 눈에 띄는 기술적 선택 중 하나는 GraphQL API, CLI, SDK 같은 저수준 원시 인터페이스에 에이전트가 직접 접근하지 못하도록 차단한 점입니다. Linear 측은 에이전트에게 너무 넓은 원시 API 접근 권한을 부여하면 모호하거나 복잡한 작업에서 무리하고 투기적인 동작(speculative actions)을 시도해 워크스페이스 데이터를 망가뜨릴 위험이 커진다고 설명합니다. 따라서 정교하게 설계된 고수준 도구만을 제공해 오류 방지와 예측 가능성을 확보했다는 입장입니다.
그러나 이러한 설계는 명확한 실무적 트레이드오프를 동반합니다. 공식 시스템 스킬로 포장되지 않은 Linear의 비정형 작업이나 롱테일 업무 요구사항의 경우, 에이전트가 유연하게 우회하지 못하고 작업을 거부하게 됩니다. 프롬프트 대신 도구 스키마 자체에 유효하지 않은 동작을 방지하는 제약을 심는 방식은 모델의 환각과 비정상 호출을 줄여주지만, 동시에 사용자가 에이전트를 통해 시도할 수 있는 작업의 폭(breadth)을 회사가 사전에 규정한 경계 안으로 한정 짓는 결과를 낳습니다.
범용 프레임워크를 건너뛰고 자체 하네스를 만든 기술적 이유
Linear는 LangChain 등 널리 쓰이는 오픈소스 에이전트 프레임워크를 채택하지 않고 독자적인 오케스트레이션 하네스를 직접 구축했습니다. 이 하네스는 모델 제공자에 구애받지 않는 공급자 독립적 AI 클라이언트, 듀러블(Durable) 워크플로 엔진 기반의 에이전트 실행 루프, 그리고 스트리밍 계층으로 이루어져 있습니다.
자체 하네스를 구축한 첫 번째 핵심 이유는 프롬프트 캐시(Prefix Cache) 보존입니다. 스킬이 런타임에 동적으로 추가될 때 LLM 공급자의 캐시가 깨지면 지연 시간과 추론 비용이 급증하기 때문에, 정교한 도구 주입 메커니즘이 필요했습니다. 두 번째는 '맥락 기반 조건부 승인(Contextual Approval)'입니다. 도구 단위의 정적 규칙 대신, 동일 세션에서 자신이 방금 생성한 항목은 확인 없이 삭제할 수 있지만 기존 데이터나 외부 연동 코멘트는 반드시 사용자 승인을 거치도록 상태 맥락을 평가합니다. 마지막으로 장시간 실행되는 부모-자식 서브 에이전트 환경에서 작업 대기 시간 동안 서버 리소스를 안전하게 해제(suspend)하고 응답 수신 시 재개(resume)하는 수명 주기 제어가 필수적이었기 때문입니다.
아키텍처 관점에서의 종합 평가와 확인이 필요한 과제
Linear의 접근 방식은 LLM 기반 B2B 애플리케이션 개발에서 범용 프레임워크 중심의 프로토타이핑이 프로덕션 단계에서 겪는 한계를 명확히 짚어줍니다. 고유한 도메인 지식을 프롬프트 문맥 길이에 억지로 밀어넣는 대신, 도구 설계와 점진적 스킬 로딩으로 분리하고 인프라 레벨에서 상태를 관리하는 것은 엔터프라이즈 환경에서 매우 유효한 전략입니다.
다만 실무 도입 관점에서는 검증되지 않은 데이터와 관리 부담을 살펴볼 필요가 있습니다. Linear는 접두사 캐시 보존을 통한 비용 방어를 강조하지만, 실제 토큰 절감률이나 지연 시간 단축 효과에 대한 정량적 벤치마크는 공개하지 않았습니다. 또한 자체 하네스를 유지보수하면서 워크플로 엔진과 LLM 제공자 변경에 지속적으로 대응해야 하는 엔지니어링 부하를 감당해야 합니다. 업무 맥락에 따라 AI의 자율적 개입이나 가벼운 농담이 협업 피로를 유발할 수 있다는 점 역시 조직 내 도입 시 고려해야 할 실무적 과제입니다.
출처
Linear의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
How we built Linear Agent (새 창)
