5 Rules for Building AI Agents That Work in Production | Nan Yu & Jacob Shumway

---

title: "5 Rules for Building AI Agents That Work in Production | Nan Yu & Jacob Shumway" date: 2026-08-13 channel: pragmaticengineer video_id: 4mKtJzfGj0U video_url: https://www.youtube.com/watch?v=4mKtJzfGj0U language: ko type: youtube-deep-digest

URL: https://www.youtube.com/watch?v=4mKtJzfGj0U
날짜: 2026-08-13
채널: pragmaticengineer
출연: Nan Yu, Jacob Shumway (Linear)
진행: Peter

편집 메모: 영상에서 “다섯 가지 규칙”을 별도의 번호 목록으로 선언하지는 않는다. 아래 다섯 규칙은 Peter, Nan Yu, Jacob Shumway의 대화 전체에서 반복해서 드러난 프로덕션 에이전트 구축 원칙을 시간순 전개와 함께 재구성한 것이다.

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==프로덕션 에이전트의 핵심은 거대한 프롬프트를 붙이는 것이 아니라, 명확한 목표와 도구 기반 컨텍스트 구축 능력을 가진 모델을 실제 업무 흐름의 적절한 진입점에 연결하고, 사람의 책임·제품의 기본값·평가 루프까지 시스템으로 설계하는 데 있다.==

• 에이전트는 LLM을 한 번 호출하는 챗봇이 아니라 목표를 향해 도구를 호출하며 반복 실행되는 루프다.
• 모델에게 모든 컨텍스트와 세부 지시를 미리 주기보다, 검색·스킬·가이드를 불러올 도구를 주고 스스로 컨텍스트를 만들게 해야 한다.
• 성공 기준은 “무엇이든 할 수 있는가”가 아니라 사용자의 실제 의도를 파악하고, 원치 않는 비싸고 성가신 행동을 하지 않으며, 핵심 사용 사례를 안정적으로 끝내는가다.
• Linear Agent의 차별점은 Linear의 도구를 노출한 MCP 서버에 그치지 않고, Linear가 생각하는 좋은 제품 개발 프로세스와 기본값을 네이티브 에이전트에 심었다는 데 있다.

이 대화는 Linear Agent를 사례로 삼아, 2025년 하반기의 엉성한 프로토타입이 어떻게 Slack·코드베이스·프로젝트·티켓의 컨텍스트를 잇고, 이슈를 만들고 코드를 작성해 PR까지 만드는 시스템으로 발전했는지를 보여준다. 결론은 에이전트를 앱 안의 챗봇 하나로 축소하지 말고, 사용자가 실제로 일하는 대화·회의·프로젝트 업데이트 속에 배치하라는 것이다.

1. 에이전트의 본질: 한 번의 답변이 아니라 목표를 향한 도구 사용 루프

에이전트는 “똑똑한 모델”이라는 속성보다 모델을 어떤 실행 구조에 넣는지가 중요하다.

1.1. 기술적 정의: LLM 호출의 반복

1. 일반적인 LLM 호출과 에이전트의 차이

   1. 일회성 질의응답: 보통 LLM은 질문 하나를 받고 답변 하나를 돌려준다.
   2. 반복 실행: 에이전트는 질문·답변·질문·답변의 루프를 돌며 매 턴마다 도구를 호출한다.
   3. 자율성: 모델은 한 번에 완성된 답을 맞히는 대신, 목표를 달성하는 데 필요한 다음 행동을 선택한다.

2. 에이전트의 최소 구성

   1. 목표와 마일스톤(goal/milestone): 에이전트가 어디까지 가야 성공인지 정의한다.
   2. 컨텍스트 구축 도구: 검색, 데이터 조회, 문서·코드 읽기, 스킬·가이드 로딩 기능을 제공한다.
   3. 완료 판단: 충분한 정보를 모았다고 판단하면 중간 결과들을 종합해 최종 응답을 만든다.

3. 핵심 정신 모델

   1. 에이전트는 “모델 + 도구 + 루프”다.
   2. 모델이 매 단계 컨텍스트를 가져오고, 그 컨텍스트를 바탕으로 다음 도구 호출을 결정하는 과정 자체가 에이전트의 행동이다.
   3. 따라서 품질은 모델의 지식량뿐 아니라 어떤 도구를 언제 쓸 수 있는지, 목표가 얼마나 잘 정의됐는지에 좌우된다.

1.2. 제품으로서의 에이전트: 여러 하위 시스템과 하나의 표면

1. 기술적 정의보다 넓은 제품 개념

   1. 개발자에게 “에이전트가 무엇인가?”라고 물으면 LLM 루프라는 기술적 답이 나온다.
   2. 사용자가 접하는 제품으로서의 에이전트는 AI 루프에 여러 기능을 포장한 것이다.
   3. 실제로는 서로 상호작용하는 여러 하위 시스템(subsystem)의 집합이고, 챗봇 같은 하나의 facade가 그 앞을 감싼다.

2. 부가 기능도 에이전트의 일부다

   1. 데스크톱 에이전트에는 스케줄러나 보조 기능처럼 본체의 추론 루프만으로 설명되지 않는 요소가 들어간다.
   2. 이런 기능을 따로 떼어내기보다, 사용자가 경험하는 하나의 에이전트 제품으로 봐야 한다.
   3. 이 관점은 “모델에 API를 연결했는가?”보다 “업무 시스템 전체에서 어떤 역할을 맡는가?”를 설계의 중심에 놓게 한다.

2. 규칙 1 — 모델에게 정답을 미리 주지 말고, 목표와 컨텍스트 도구를 줘라

대화에서 가장 강하게 반복되는 원칙은 **최소 지시(minimal instruction)**와 도구를 통한 컨텍스트 구축이다.

2.1. 과도한 프롬프트는 과적합을 만든다

1. 지시를 늘리는 것이 품질을 보장하지 않는다

   1. 모델에게 너무 많은 지시를 주면 특정 소프트웨어의 세부 규칙에 과적합(overfit)될 수 있다.
   2. 실제 작업에서 중요하지 않은 디테일을 과도하게 강조해, 모델이 더 중요한 목표를 놓칠 수 있다.
   3. “설명은 반드시 140자 이하” 같은 좁은 제약은 예측 가능해 보이지만, 예상하지 못한 유용한 행동의 공간을 줄인다.

2. 원칙을 쓰고 절차를 과도하게 고정하지 않는다

   1. 프롬프트와 스킬에는 특정 출력 형식의 모든 경우를 나열하기보다, 어떻게 생각하고 어떤 제품 원칙을 지켜야 하는지를 담는다.
   2. 잘 정의된 목표를 주면 모델은 검색하고, 필요한 정보를 찾아내고, 다음 행동을 스스로 선택할 만큼 충분히 똑똑하다.
   3. 에이전트가 할 수 있는 일을 지나치게 잠그면 안전해지는 대신 답답하고 활용 범위가 좁아진다.

2.2. “컨텍스트를 주지 말고 컨텍스트를 불러올 도구를 줘라”

1. 컨텍스트의 전달 방식

   1. 모든 배경정보를 시스템 프롬프트에 넣어 주는 대신, 검색·스킬 로딩·가이드 로딩·코드/문서 조회 도구를 제공한다.
   2. 모델은 목표를 이해한 뒤 필요한 정보를 검색해 자기 컨텍스트를 만든다.
   3. 이렇게 하면 작업별로 필요한 정보만 가져오고, 거대한 고정 프롬프트가 낡거나 충돌하는 문제를 줄일 수 있다.

2. Linear 사례에 적용된 의미

   1. 이슈를 만들 때 우선순위, 제목, 설명을 어떻게 정할지에 대한 Linear의 의견은 해당 스킬에 들어간다.
   2. 모델은 모든 스킬을 처음부터 읽는 대신 요청에 맞는 스킬을 동적으로 로드한다.
   3. 지시문은 적게 유지하면서도, 필요한 순간에는 도메인 규칙과 관련 도구를 확보할 수 있다.

3. 실행 가능한 규칙

   1. 먼저 “사용자가 끝내고 싶은 일”을 한 문장으로 정의한다.
   2. 그 목표를 달성하는 데 필요한 정보원을 도구로 노출한다.
   3. 모델이 컨텍스트를 수집하고 판단하도록 하며, 개발자가 모든 경로를 미리 하드코딩하려는 유혹을 줄인다.

3. 규칙 2 — 실제 사용자가 원하는 워크플로에서 시작하고, 일찍 풀어 실사용으로 발견하라

Linear 팀은 완성된 사양서에서 출발하지 않았다. 직접 요청된 작고 가치 있는 작업을 프로토타입으로 만들고, 내부 사용자가 예상 밖의 활용을 발견하도록 했다.

3.1. 2025년 하반기의 출발점과 첫 프로토타입

1. 초기 메모의 중심 명제

   1. Nan Yu가 2025년 하반기에 쓴 메모에는 “컴퓨터는 우리를 위해 많은 일을 할 수 있다”는 생각이 중심에 있었다.
   2. 사람이 하기 싫은 일을 컴퓨터에 넘기자는 것이 출발점이었다.
   3. 기술적으로는 트리거 이벤트, 발생한 컨텍스트, 지시, 반복되는 액션, 결과라는 흐름을 이미 상정했다.

2. 처음에는 야심이 부족했다

   1. 초기 팀은 에이전트를 로봇 같은 이름의 “프로그램 매니저”로 생각하고, 스프레드시트 관리와 티켓 추적 같은 지루한 업무부터 맡기려 했다.
   2. Peter는 기술 프로그램 매니저가 스프레드시트와 티켓을 관리하는 가장 지루한 직업 중 하나라는 농담을 던졌고, 대화 중 웃음이 나왔다.
   3. 1년이 채 지나지 않아 팀의 관점은 바뀌었다. 에이전트는 지루한 업무 자동화뿐 아니라 상호작용적이고 창의적인 작업, 제품 개발 전 과정의 증강에도 쓸 수 있게 됐다.

3. 첫 버전의 형태

   1. 프런트엔드에서 LLM을 직접 호출하는 내부 플래그 기능으로 시작했다.
   2. Linear의 명령 메뉴에 있는 액션들을 도구로 노출하고, 모델이 무엇을 할 수 있는지 시험했다.
   3. 팀 스스로도 “정말 해킹에 가까운(hacky)” 프로토타입이라고 표현했다.

3.2. 가장 먼저 만든 것은 사용자가 이미 원하던 일이다

1. 세일즈 통화 메모에서 이슈 추출

   1. 초기의 명확한 수요는 사람이 세일즈 콜을 손으로 적은 메모를 에이전트에 던지는 것이었다.
   2. 메모에서 만들어야 할 제품 이슈, 보고된 버그, 후속 작업을 추출해 달라는 요청이었다.
   3. 이는 사용자가 직접 요청했고 팀 자신도 업무에서 느끼던 문제였기 때문에, 단순하지만 가치 있는 출발점이 됐다.

2. 처음부터 채팅이라고 가정하지 않았다

   1. 텍스트를 붙여 넣고 제출하는 입력창이면 충분할 수도 있다고 생각했다.
   2. 어떤 UI가 최종 형태인지, 채팅이 맞는지도 정해져 있지 않았다.
   3. 따라서 정교한 제품 사양서를 먼저 쓰기보다 여러 실험과 방향을 시도하면서 무엇을 만들어야 하는지 발견했다.

3.3. Slack에 조용히 출시하고 예상 밖의 행동을 관찰하다

1. 비밀스러운 첫 프로덕션 출시

   1. 이미 Slack 연동이 있었기 때문에 별도의 대대적인 출시 없이 Linear 봇 멘션 경로에 에이전트를 조용히 연결했다.
   2. 사용자가 Slack에서 Linear를 멘션하면 기존 봇의 폼을 쓰듯 대화를 시작할 수 있었다.
   3. 팀은 사람들이 발견한 뒤 원하는 방식으로 쓰게 두고, 어떤 활용이 자연스럽게 생기는지 관찰했다.

2. 명시적 명령에서 암묵적 의도 추론으로

   1. 예상 가능한 사용은 “Linear, 이슈를 만들어 줘”라고 말하고 자연어로 내용을 설명하는 것이었다.
   2. 그러나 사용자들은 Linear가 Slack 스레드 전체의 컨텍스트를 읽는다는 사실을 알아차렸다.
   3. 그래서 “방금 우리가 한 일을 보고 적절히 처리해 줘(look at what we just did / do the right thing)”라고 하거나, 심지어 @Linear 뒤에 위쪽 손가락 이모지만 남기기도 했다.

3. 에이전트의 창발적 행동

   1. 에이전트는 스레드에서 이슈 이름처럼 보이는 내용이 여러 개 있다는 것을 추론했다.
   2. 관련 이슈들을 만들고, 사용자에게 자신이 처리했다는 결과를 알려 주는 계획을 세웠다.
   3. 팀은 이 정도로 자연스러운 암묵적 사용이 가능하리라고 예상하지 못했다. 이 사례는 제품을 실제 사용자 손에 놓았을 때만 드러나는 행동 공간을 보여준다.

4. 규칙 3 — 단순한 API/MCP 묶음이 아니라, 스킬을 동적으로 로드하는 네이티브 에이전트를 설계하라

Linear Agent는 모든 기능을 한 번에 모델에게 던지는 방식에서 출발해 컨텍스트 문제와 환각을 겪었고, 스킬 아키텍처로 이동했다.

4.1. “Linear에서 할 수 있는 모든 것”을 한 번에 주는 방식의 한계

1. 초기 접근

   1. Linear의 모든 표면에서 가능한 많은 액션을 모델에 제공하려 했다.
   2. 기능 수가 늘면서 컨텍스트가 복잡해지고 환각(hallucination)이 발생했다.
   3. GraphQL 스키마를 통째로 제공하고 모델이 쿼리를 작성하게 하는 실험도 했지만 잘 작동하지 않았다.

2. 문제의 본질

   1. API가 많다고 해서 모델이 어떤 상황에 어떤 API를 써야 하는지, 회사의 제품 원칙에 맞는 결과를 어떻게 구성해야 하는지 자동으로 알게 되지는 않는다.
   2. 모든 도구를 항상 노출하면 모델의 선택 공간이 커지고, 관련 없는 도구와 규칙이 컨텍스트를 차지한다.
   3. 단순한 도구 연결은 실행 능력을 주지만, 도메인에 맞는 좋은 실행 방식을 반드시 보장하지는 않는다.

4.2. 스킬: 관련 도구와 지침을 한 단위로 묶기

1. 동적 스킬 로딩

   1. 에이전트에 “스킬을 로드하는 도구”를 제공한다.
   2. 요청을 읽은 모델이 필요한 스킬을 선택해 불러온다.
   3. 각 스킬은 관련 도구들과 그것을 사용하는 지침을 함께 제공한다.

2. 티켓 생성 스킬의 예

   1. Linear 팀은 이슈를 만들 때 어떤 우선순위를 정할지에 대한 의견을 갖고 있다.
   2. 제목과 설명에 어떤 정보를 넣을지도 제품 운영의 판단이다.
   3. 이런 판단을 create ticket 스킬에 인코딩해, 단순히 이슈 생성 API를 호출하는 것보다 Linear다운 결과를 만들게 했다.

3. 네이티브 에이전트의 장점

   1. CLI나 MCP는 보통 앱을 사용하기 위한 도구와 사용법을 제공하지만, 네이티브 에이전트는 수백 개의 스킬을 둘 수 있다.
   2. 동적 로딩으로 작업별 동작 방식을 제어하면, 앱을 고급 사용자(power user)가 쓰는 것처럼 매끄럽고 일관되게 사용할 수 있다.
   3. 모델이 루프 안에서 어떤 도구를 호출할지 판단하기 때문에, Slack에서 멘션만 해도 사용자의 의도를 읽고 가장 게으른 경로로 적절한 일을 해주는 행동이 창발한다.

4.3. 네이티브 에이전트와 MCP의 역할 차이

1. MCP 서버만 제공하는 세계

   1. 제품은 MCP 서버와 도구만 제공하고 사용자가 어떤 모델이나 클라이언트로 연결할지에 맡길 수 있다.
   2. 이 방식은 접근성을 제공하지만, 사용자마다 프롬프트·도구 선택·출력 방식이 달라질 수 있다.
   3. 제품 팀이 원하는 작업 흐름과 기본값을 직접 반영하기는 어렵다.

2. 네이티브 에이전트가 갖는 제품적 통제

   1. 네이티브 에이전트에는 Linear가 생각하는 좋은 제품 관리와 소프트웨어 개발 방식이 스킬·지침·기본값으로 들어간다.
   2. MCP가 “도구를 쓸 수 있음”을 제공한다면, 네이티브 에이전트는 “도구를 어떤 판단 순서와 품질 기준으로 써야 하는가”까지 제공한다.
   3. 이것이 단순한 API 포장과 도메인 에이전트의 차이다.

5. 규칙 4 — 에이전트를 실제 시스템의 컨텍스트와 책임 구조에 연결하라

Linear Agent의 데모는 자연어를 이슈로 바꾸는 수준을 넘어, 논의·결정·담당·코드 변경·검증을 하나의 추적 가능한 시스템으로 잇는다.

5.1. Slack에서 아이디어가 PR로 가는 실제 루프

1. 모호한 대화에서 시작한다

   1. Nan Yu는 Slack에서 디자이너 Yan과 Jacob을 태그해 “이 부분이 이상한데 이렇게 해볼까?”라는 식으로 아이디어를 주고받는다.
   2. 처음부터 정확한 작업이 정의된 것은 아니다. 디자이너가 의견을 내고, Nan Yu가 명확히 하며, Jacob이 이의를 제기한다.
   3. 팀은 무엇이 실제 문제인지, 그 이의를 어떻게 처리할지 논의하면서 일종의 “진실을 찾아가는” 과정을 거친다.

2. 결정이 내려지면 에이전트가 실행한다

   1. 대화의 결론을 바탕으로 @Linear, create an issue for me라고 요청한다.
   2. 과거에는 “이슈만 만들어 달라”고 했다면, 이제는 “전체 컨텍스트를 보고 올바른 일을 판단한 뒤 이슈를 만들고 작업까지 진행하라”고 할 수 있다.
   3. Linear는 이슈를 만들고 Jacob을 담당자로 지정한 뒤, 스스로에게 작업을 위임했다.

3. 코드와 PR까지 이어진다

   1. 데모에서 작업은 약 18분 전에 완료된 상태였고, 실행에는 약 6분이 걸렸다.
   2. 그 결과 클릭해서 확인할 수 있는 PR이 생성됐다.
   3. 사람은 PR을 직접 실행·검토하면서 이것이 좋은 아이디어였는지 확인하고, 필요하면 다음 결정을 내린다.

5.2. 채팅을 시스템 오브 레코드로 바꾸기

1. Slack만으로는 일이 사라진다

   1. Slack 스레드에만 아이디어를 남기면 대화가 쌓이면서 중요한 작업을 잃어버릴 수 있다.
   2. 검색으로 누군가 기억해 내길 바라거나, 누군가 잊지 않기를 바라는 방식은 신뢰할 수 없다.
   3. Linear의 목표는 이슈를 올바른 프로젝트와 백로그의 올바른 위치에 놓고, 실제 완료까지 추적하는 것이다.

2. 에이전트가 한 일도 사람의 책임과 연결한다

   1. Linear가 코드를 작성했더라도 결과 이슈의 담당자는 Jacob처럼 실제 사람으로 연결된다.
   2. 누가 충분한 정보를 갖고 작업을 시작하기로 결정했는지 기록하면, 에이전트의 자동화가 책임의 공백으로 변하지 않는다.
   3. 대부분의 에이전트 작업은 사람에게 귀속되지만, 모든 경우가 사람의 직접 호출이어야 하는 것은 아니다.

3. 사람 없이 이어지는 예외

   1. Datadog 같은 모니터링 시스템의 경보가 울리면 시스템이 자동으로 버그를 생성하고 Linear가 순차적으로 해결할 수 있다.
   2. 이 경우 사람은 마지막까지 코드를 직접 만지지 않을 수 있으므로, 에이전트가 누가 코드를 검토해야 하는지 결정할 필요가 있다.
   3. 즉, 사람 귀속은 자동화를 막는 규칙이 아니라, 승인·검토·책임의 다음 지점을 명확하게 만드는 장치다.

5.3. 여러 데이터 소스를 이어 붙여 “시스템 전체를 아는” 에이전트 만들기

1. 접근 가능한 컨텍스트

   1. 에이전트는 Linear의 티켓뿐 아니라 Slack 스레드도 읽는다.
   2. 코드베이스, 프로젝트 설명, 다른 티켓, 열린 PR과 같은 정보원도 함께 읽을 수 있다.
   3. 특정 데모의 컨텍스트는 Slack 스레드에서 왔지만, 성능의 핵심은 한 소스가 아니라 여러 소스를 연결하는 데 있다.

2. 중복 작업을 피하는 지능

   1. 새 이슈를 만들기 전에 이미 누군가 같은 작업을 했는지, 시스템에 열린 PR이 있는지 확인할 수 있다.
   2. 컨텍스트를 읽지 않는 에이전트는 새 작업을 무작정 밀어붙이지만, 연결된 에이전트는 현재 시스템 상태를 고려한다.
   3. “무엇을 할까?”뿐 아니라 “이미 무엇이 되어 있는가?”를 확인하는 것이 프로덕션 안정성의 핵심이다.

6. 초기 개선 과정: 좁은 고빈도 경로부터 라우팅하고, 모델·평가를 반복 최적화하라

처음부터 모든 사용 사례를 동일한 수준으로 지원하지 않았다. 실제 사용 분포와 평가 데이터를 이용해 자주 쓰이는 경로를 먼저 다듬었다.

6.1. 80%의 초기 사용량을 전용 경로로 보내기

1. 초기 제품 상태

   1. 기술적으로 여러 기능을 수행할 수는 있었지만, 실제로 잘 수행하지는 못했다.
   2. 스킬 아키텍처가 완성되지 않아 기능의 품질과 범위가 제한적이었다.
   3. 초기 사용량의 대부분은 이슈 생성에 몰렸다.

2. 작은 라우터와 특화된 하위 프롬프트

   1. 팀은 작은 라우터를 만들고 사용 사례의 약 80%를 이슈 생성 전용 서브프롬프트로 보냈다.
   2. 별도의 큰 메인 모델은 모든 도구에 접근해 범용 작업을 수행하고, 작은 라우터는 요청을 범용 경로 또는 특화 경로로 분기했다.
   3. 이 구조는 “모든 기능을 가장 큰 프롬프트 하나에 넣기”보다 고빈도 작업을 빠르고 예측 가능하게 최적화한다.

6.2. 가장 큰 모델로 가능성을 확인한 뒤 작은 모델로 내리기

1. 프로토타입 단계의 원칙

   1. 먼저 사용 가능한 가장 큰 모델을 붙여 그 작업이 원리상 가능한지 확인한다.
   2. 성공 기준을 정하고 평가 세트를 만든다.
   3. 기준을 계속 만족한다는 안전망이 생긴 뒤 모델을 작은 쪽으로 최적화한다.

2. 비용과 품질의 균형

   1. 이상적으로는 작업에 필요한 가장 작은 모델을 사용해야 한다.
   2. 이유는 비용을 줄이기 위해서다.
   3. 그러나 초기에 작은 모델을 고집하면 실제 능력의 상한을 확인하지 못할 수 있으므로, “가장 큰 모델로 가능성 확인 → 평가 구축 → 작은 모델 최적화” 순서가 안전하다.

6.3. 평가 데이터는 예상 밖의 사용에서 나온다

1. 반복 사용이 데이터셋을 만든다

   1. 사용자가 예상과 다르게 에이전트를 사용하면 그 사례를 데이터셋에 추가한다.
   2. 제품을 사용하고 고치고 다시 사용하는 과정이 초기 평가의 큰 부분을 차지한다.
   3. 기능이 무엇을 해야 하는지에 대한 이해는 사전 설계만이 아니라 실제 사용에서 축적된다.

2. 객관적 평가와 주관적 평가를 섞는다

   1. 객관적·결정론적 기준: 사용자가 “진행 중(in progress)”이라고 요청하면 항상 상태 필드에 in progress가 들어가야 한다.
   2. 주관적 기준: 설명이 좋은 구조인지, 필요한 정보가 제목 필드에 올바르게 추출됐는지처럼 정답이 하나가 아닌 품질을 판단한다.
   3. 주관적 기준에는 LLM-as-a-judge를 사용할 수 있지만, 그 심판 모델이 정말 올바르게 평가하는지는 사람이 점검해야 한다.

3. 평가를 과하게 믿지 않는다

   1. 팀은 LLM 평가를 일관성이 중요한 영역에서 특히 유용한 도구로 본다.
   2. 에이전트는 같은 의도에 여러 방식으로 답해도 되는 경우가 많으므로, 불필요한 일관성 규칙은 거짓 신호(false signal)를 만들 수 있다.
   3. 모든 창의적 변형을 감점하면 실제 사용성보다 평가 점수에 맞춰지는 문제가 생긴다.

7. 규칙 5 — 사용자의 의도를 읽고, 핵심 경로는 견고하게, 나머지는 열린 채로 둬라

Applied AI의 큰 병목은 모델이 멍청해서가 아니라, 모델의 능력을 충분히 활용하지 못하는 데 있다. 따라서 평가와 제품 설계는 에이전트가 사용자의 실제 의도를 얼마나 잘 읽는지에 초점을 둬야 한다.

7.1. “능력 과잉(capability overhang)”을 줄이는 제품 설계

1. 문제는 모델의 지능 부족이 아니다

   1. Frontier LLM은 이미 매우 똑똑하고 많은 작업을 수행할 수 있다.
   2. 문제는 우리가 그 능력을 충분히 사용하지 않는 것, 즉 capability/capacity overhang이다.
   3. 제품의 기회는 모델을 더 똑똑하게 만드는 것뿐 아니라 사용자가 진짜 원하는 작업을 알아채고 실행하게 만드는 데 있다.

2. 과도한 열의도 실패다

   1. 사용자가 말을 했을 때 실제로 끝내고 싶은 작업이 무엇인지 파악해야 한다.
   2. 사용자가 원하지 않았는데 에이전트가 비싸고 성가신 작업을 먼저 실행하면, 능력이 아니라 UX 실패가 된다.
   3. Slack에서 후속 질문이 들어왔을 때도 “내가 답할 수 있는가?”, “지금 끼어들어야 하는가?”를 판단하는 내부 과정이 필요하다.

3. 사용자 피드백을 평가로 승격한다

   1. 출시 후 또는 내부 dogfooding 중 사용자는 좋아요·싫어요와 설명으로 피드백을 준다.
   2. “이상하게 행동했다”, “이런 바보 같은 실수를 했다”는 사례와 그 이유가 반복해서 모이면 평가 케이스가 된다.
   3. 이런 피드백 루프는 에이전트가 자기 자신을 무한히 개선한다는 뜻이 아니라, 운영팀이 실제 실패를 제품 개선·평가 데이터로 되돌리는 구조라는 뜻이다.

7.2. 실패 사례를 숨기지 말고 기능 백로그로 연결한다

1. 할 수 없는 기능을 스스로 보고하기

   1. 사용자가 요청한 작업에 필요한 도구가 없으면, 에이전트가 그 기능을 수행하지 못했다고 보고하는 도구를 호출한다.
   2. 시스템은 해당 요청과 같은 이슈가 이미 있는지 자동으로 검색한다.
   3. 기존 이슈가 있으면 거기에 추가하고, 없으면 새 이슈를 만든다.

2. 운영 중인 제품이 스스로 개선 큐를 만든다

   1. 이렇게 하면 “무엇을 더 만들면 사용자가 실제로 만족할까?”라는 질문에 실제 요청의 흐름으로 답할 수 있다.
   2. 개발팀에는 에이전트가 못 한 일에 대한 지속적인 이슈 스트림이 들어온다.
   3. 기능 로드맵이 내부 추측만이 아니라 실사용 실패와 수요에 연결된다.

7.3. 자유를 허용하되 안전 경계를 둔다

1. 업무 도메인 안에서도 의외의 사용이 나온다

   1. Linear Agent는 업무 공간과 개발팀에 붙어 있어 사용자가 아주 엉뚱한 모험을 하는 경우는 많지 않다.
   2. 그러나 고객 피드백 번역처럼 팀이 예상하지 못한 창의적 사용은 자주 나왔다.
   3. 예를 들어 프랑스 고객의 Intercom 티켓이 들어오면, 이슈로 만들기 전에 프랑스어 내용을 번역해 달라는 자동화를 설정할 수 있다.

2. 안전 문제만 없으면 시도하게 한다

   1. 사용자가 에이전트에게 시를 써 달라고 해도 괜찮다.
   2. 안전 문제 같은 명확한 경계가 없다면 사용 목적을 지나치게 제한하지 않는다.
   3. 너무 세밀하게 통제하면 예상치 못한 가치를 없애고 사용자를 답답하게 만들 수 있다.

7.4. 핵심 사용 사례를 “보증 기간” 안에 두고 출시한다

1. 완벽한 출시 시점은 오지 않는다

   1. 백엔드 관점에서 팀은 “조금 이른 것 같지만 너무 이르지는 않다”는 시점에 출시했다.
   2. 주관적 품질을 내부에서 영원히 다듬을 수도 있지만, 완벽한 지점을 객관적으로 찾기는 어렵다.
   3. 제품을 공개하고 더 많은 데이터를 얻어 개선하는 선택을 했다.

2. 영웅 사용 사례(hero use case)를 먼저 견고하게 만든다

   1. UI 중심 제품은 사용자가 할 수 있는 일을 UI가 제한하므로, 의도하지 않은 기능을 제거하는 방식으로 품질을 정의하기 쉽다.
   2. 에이전트는 모든 사용 사례를 동일한 신뢰도로 보장하기 어렵기 때문에, 핵심적으로 시연하고 싶은 경로를 먼저 정한다.
   3. 티켓 생성, 티켓 관리, PR 생성은 Linear가 마케팅에서 강조할 수 있을 정도로 안정적인 “보증(warranty) 범위”에 해당한다.

3. 핵심 경로 밖의 변동성을 받아들인다

   1. 핵심 경로가 단단하고 팀이 그 방향을 믿는다면, 다른 경로의 신뢰성 편차는 이 기술의 본질적 특성으로 감수할 수 있다.
   2. 이는 아무렇게나 출시한다는 뜻이 아니라, 무엇을 약속하고 무엇을 탐색 영역으로 남길지 명확히 한다는 뜻이다.
   3. 품질 기준은 모든 것을 완벽하게 하는 것이 아니라, 사용자가 처음 접하는 핵심 가치를 확실히 전달하는 것이다.

8. 제품 전략: MCP인가 네이티브 에이전트인가보다 실제 워크플로의 진입점이 먼저다

8.1. 사용자는 한 번에 자신의 일을 끝내지 않는다

1. 업무는 다단계 프로세스다

   1. 사람은 책상에 앉아 업무 전체를 한 번에 원샷하지 않는다.
   2. 대화, 조사, 회의, 결정, 실행, 검토, 문서 업데이트처럼 여러 단계가 이어진다.
   3. 따라서 에이전트도 단일 프롬프트의 정답보다 전체 프로세스의 어느 지점에 연결되는지가 중요하다.

2. 워크플로를 분해하는 질문

   1. 사용자가 실제로 끝내려는 일은 무엇인가?
   2. 그 일의 어느 지점에서 외부 지능을 호출하는 것이 자연스러운가?
   3. 결과를 어디에 기록하고, 누가 검토하며, 다음 단계로 어떻게 넘길 것인가?

8.2. 챗봇은 에이전트의 입구가 아니라 후속 대화를 위한 표면이다

1. 앱 안의 챗봇은 눈에 띄지만 충분하지 않다

   1. 사용자는 앱에 챗봇이 있으면 그것을 에이전트라고 부르기 쉽다.
   2. 챗봇은 후속 질문과 여러 턴의 프로세스를 진행할 표면으로는 필요하다.
   3. 하지만 실제 인지와 업무가 시작되는 진입점은 앱 안의 챗봇만이 아니다.

2. 자연스러운 진입점

   1. Slack에서 진행 중인 논의가 있을 때.
   2. 회의 후 브리핑을 정리할 때.
   3. 프로젝트 업데이트를 쓰면서 자료를 조사할 때.
   4. 이런 지점이 실제 업무의 온램프(on-ramp)이며, 대화형 채팅은 그 뒤의 후속 처리와 긴 꼬리(long tail)를 담당한다.

8.3. 도메인 에이전트는 직원처럼 여러 표면에서 일해야 한다

1. 직원 비유

   1. 에이전트는 한 앱에 갇힌 버튼보다 조직의 직원에 가깝다.
   2. 직원에게 특정 앱 화면에서만 말하지 않고 Slack이나 실제로 일하는 곳에서 대화하듯, 에이전트도 사용자의 업무 표면에서 호출돼야 한다.
   3. 네이티브 에이전트의 가치는 특정 웹사이트 방문을 강제하는 것이 아니라 사용자가 이미 있는 곳에서 좋은 워크플로를 이어 주는 데 있다.

2. 멀티플레이어 시스템의 서로 다른 표면

   1. Linear는 여러 사람이 같은 시스템을 쓰는 멀티플레이어 제품이라 사용자별 최적 표면이 다르다.
   2. 고객 지원 담당자는 Zendesk나 Intercom의 플러그인에서 템플릿을 고르고 이슈를 설명해 상위 팀으로 에스컬레이션할 수 있다.
   3. 그 사람에게 Linear의 전체 UI는 필요하지 않지만, 그 입력 스트림은 다른 팀이 실제 작업을 수행하는 데 매우 가치 있다.

3. 제품 의견과 사용자 선택의 균형

   1. 도메인 제품은 좋은 프로세스에 대해 의견이 있어야 한다.
   2. 그러나 사용자가 어떤 워크플로와 서비스를 통해 접근할지까지 과도하게 통제해서는 안 된다.
   3. 좋은 에이전트는 제품의 가치와 원칙은 유지하면서, 호출 표면은 사용자의 실제 일하는 방식에 맞춘다.

9. 장기 방향: 능동성·기억·프로젝트 운영을 당연한 기본값으로

9.1. 다음 두 축: proactivity와 longer-running memory

1. 능동적인 에이전트(proactivity)

   1. 현재 에이전트는 사용자가 멘션하거나 요청할 때 반응한다.
   2. 앞으로는 프로젝트의 상태와 이벤트를 바탕으로 필요한 조율이나 업데이트를 먼저 제안·실행하는 방향으로 간다.
   3. 단순히 답변하는 모델이 아니라 프로젝트를 앞으로 밀어 주는 담당자가 되는 것이다.

2. 장기 기억(longer-running memory)

   1. 프로젝트는 며칠 만에 끝날 수도 있고 한 분기 동안 지속될 수도 있다.
   2. 에이전트는 프로젝트 생애 동안 일어난 일을 계속 이해하고, 이전 결정과 현재 상태를 연결해야 한다.
   3. 사람 조율, 문서 최신화, 진행 상태 관리가 프로젝트 전체 기간에 걸쳐 이어져야 한다.

9.2. 최종 목표: “프로젝트가 잘 운영되고 있다”는 사실을 당연하게 여기기

1. 사용자는 Linear에서 실행하는 프로젝트가 잘 운영되고 있다고 믿고 싶어 한다.
2. Slack에서 엔지니어와 긴 대화를 나눈 뒤 “이제 PRD로 가자”는 말이 나와도, 사람이 PRD 업데이트를 귀찮아하고 시간이 없다는 이유로 문서가 낡아서는 안 된다.
3. 그 대화를 Linear에 지정하면 결정과 문서 업데이트가 자연스럽게 기록되고, 프로젝트가 계속 굴러가게 하는 것이 팀이 말한 목표다.

영상에서 재구성한 5가지 프로덕션 규칙

1. 명확한 목표를 주고, 컨텍스트를 불러올 도구를 제공하라. 과도한 지시 대신 모델이 검색·스킬·가이드를 통해 필요한 맥락을 스스로 만들게 한다.
2. 실제 사용자가 원하는 다단계 워크플로에서 시작하고 일찍 출시하라. 세일즈 메모에서 이슈를 뽑는 작은 수요처럼 직접 요청되고 팀도 겪는 문제를 먼저 해결한 뒤, 실사용에서 새로운 활용을 발견한다.
3. 모든 API를 한꺼번에 던지지 말고 동적 스킬과 네이티브 제품 원칙을 설계하라. MCP의 도구 연결을 넘어, 도메인에 맞는 판단 방식과 기본값을 에이전트에 담는다.
4. 에이전트를 시스템 전체와 책임 구조에 연결하라. Slack의 대화를 백로그·코드·PR·프로젝트 컨텍스트와 이어 붙이고, 자동화된 결과도 적절한 사람의 책임과 검토로 귀속한다.
5. 사용자 의도와 핵심 경로를 평가하라. 가장 큰 모델로 가능성을 확인한 뒤 작은 모델로 최적화하고, 객관적·주관적 평가와 실사용 피드백을 섞되, 핵심 영웅 사용 사례는 견고하게 만들고 나머지 탐색 공간은 열어 둔다.

주요 발언 모음

“At a high level, an agent is really just calling an LLM in a loop.”
“높은 수준에서 보면 에이전트는 그저 LLM을 루프 안에서 호출하는 것이다.” — Jacob Shumway

“Give it as little instruction as possible. Give it the tools to load context. Don’t give it context.”
“지시는 최대한 적게 하고, 컨텍스트를 불러올 도구를 줘라. 컨텍스트 자체를 주입하지 마라.” — Linear 팀

“The models are really smart, but we’re just not using them enough.”
“모델은 정말 똑똑하지만, 우리는 그것을 충분히 활용하지 않고 있다.” — Nan Yu

“It’s not an end-to-end solution. It’s a middle solution.”
“AI는 엔드 투 엔드 솔루션이 아니라 중간 단계의 솔루션이다.” — 대화 중 제시된 관점

“No one sits down at their desk and one-shots their whole job.”
“누구도 책상에 앉아 자신의 일을 한 번에 끝내지 않는다.” — Nan Yu

“I’m just too lazy to update the PRD.”
“나는 PRD를 업데이트하기가 너무 귀찮다.” — Peter의 마무리 농담

핵심 데이터 & 수치

• 2025년 하반기: 초기 에이전트 아이디어를 적은 메모가 작성된 시점이다. 대화 시점인 2026년 하반기 기준 AI 시간으로는 아주 오래전의 일로 묘사된다.
• 약 1년: 초기 아이디어에서 에이전트가 창의적이고 엔드 투 엔드 제품 개발을 수행하는 관점으로 빠르게 확장된 기간이다.
• 6분: Slack에서 논의된 이슈를 Linear Agent가 처리하고 실행 가능한 PR을 만든 데 걸린 데모 시간이다.
• 18분 전: 데모 시점에 해당 작업이 완료된 시점으로 표시됐다.
• 80%: 초기 사용 사례의 약 80%를 이슈 생성 전용 서브프롬프트로 라우팅해 최적화했다.
• 3~5배 저렴: 중간 광고에서 Oceans가 미국 고위급 채용과 같은 결과물을 3~5배 낮은 비용으로 제공한다고 홍보했다. 이는 본론의 Linear Agent 설계 수치가 아니다.
• 99% 거절: 같은 광고에서 Oceans가 지원자의 99%를 거절한다고 설명했다. 이 역시 본론과 분리해서 봐야 한다.
• 10% + 80% + 10%: 인간이 처음 10%와 마지막 10%를 맡고 AI가 중간 80%를 맡는다는 현재의 작업 분담 비유다.
• 0.1% + 마지막 터치: 장기적으로 인간의 역할이 문제 정의의 첫 0.1%와 최종 터치로 축소될 수 있다는 전망이다.
• 수일~한 분기: 미래 Linear Agent가 기억하고 운영해야 할 프로젝트의 지속 시간 예시다.
• 140자: 지나치게 구체적인 프롬프트 제약의 예로 든 문자 수다. 핵심은 이런 하드코딩된 제한을 줄이라는 것이다.

결론 및 시사점

1. 에이전트는 프롬프트 프로젝트가 아니라 업무 시스템 프로젝트다. 모델을 좋은 모델로 바꾸는 것만으로는 부족하며 목표, 도구, 컨텍스트, 상태, 책임자, 검토 경로를 함께 설계해야 한다.
2. 최소 지시와 풍부한 도구가 장기적으로 더 유연하다. 제품 팀의 모든 지식을 시스템 프롬프트에 박아 넣으면 변화에 약해진다. 필요한 순간에 스킬·가이드·문서·코드를 조회하게 해야 한다.
3. 실제 사용이 사양서를 만든다. Linear는 채팅인지 입력창인지도 정하지 않은 채 세일즈 메모→이슈 추출 같은 명확한 수요로 시작했고, Slack의 “손가락 이모지” 같은 창발적 사용을 통해 제품 범위를 발견했다.
4. 네이티브 에이전트의 경쟁력은 도구 개수가 아니라 도메인 판단이다. MCP가 기능 접근을 제공한다면, 네이티브 에이전트는 좋은 제품 관리·이슈 작성·백로그 정리·검토라는 의견을 실행 가능한 기본값으로 만든다.
5. 자동화의 결과를 추적 시스템에 남겨라. Slack에서 그럴듯한 답을 하는 것보다 이슈를 올바른 프로젝트와 백로그에 놓고 PR·담당자·상태까지 연결하는 것이 실제 업무 가치를 만든다.
6. 사람의 책임을 자동화와 함께 설계하라. 에이전트가 코드를 작성해도 누가 시작을 승인했고 누가 검토하는지가 보여야 한다. 완전 자동화가 필요한 모니터링 경로도 마지막 검토자를 시스템이 찾을 수 있어야 한다.
7. 평가는 정답 일치율만으로 만들 수 없다. 결정론적 필드 검증, LLM-as-a-judge, 실제 사용자 피드백을 섞되, 에이전트의 유용한 다양성까지 실수로 벌주지 않도록 한다.
8. 출시 기준은 모든 것을 잘하는 것이 아니다. 핵심 영웅 사용 사례를 보증 범위로 만들고, 핵심 경로 밖의 변동성은 관찰·개선 영역으로 남겨야 한다.
9. 진입점은 챗봇보다 업무의 순간에 있다. Slack 대화, 회의 브리핑, 프로젝트 업데이트 조사처럼 사용자가 이미 결정을 내리는 곳에 에이전트를 연결해야 일반 모델과 차별화된다.
10. 다음 단계는 반응형 도구에서 프로젝트 운영자로의 이동이다. 능동성·장기 기억·문서 최신화·사람 조율이 결합되면 사용자는 “프로젝트가 잘 운영되고 있다”는 사실을 당연하게 여길 수 있다.

핵심 요약 (20줄)

1. 에이전트는 질문 하나에 답하는 모델이 아니라 목표를 향해 도구를 호출하며 반복 실행되는 LLM 루프다.
2. 에이전트는 목표와 마일스톤을 받고, 도구로 스스로 컨텍스트를 만들며, 충분한 정보가 모이면 결과를 종합한다.
3. 제품으로서의 에이전트는 AI 루프 하나가 아니라 여러 하위 시스템과 하나의 사용자 표면이 결합된 집합체다.
4. Linear의 초기 메모는 사람이 하기 싫은 일을 컴퓨터에 맡기자는 생각에서 출발했다.
5. 첫 프로토타입은 프런트엔드에서 LLM을 직접 호출하고 Linear의 명령 메뉴 액션을 도구로 노출한 엉성한 내부 기능이었다.
6. 팀은 세일즈 통화 메모에서 제품 이슈와 버그를 추출하는 사용자가 이미 원하던 문제를 첫 실용 사례로 삼았다.
7. Slack에 에이전트를 조용히 연결하자 사용자는 자연어 명령뿐 아니라 전체 스레드와 손가락 이모지로도 작업을 요청했다.
8. 모든 Linear API와 GraphQL 스키마를 한 번에 주는 방식은 컨텍스트 문제와 환각을 일으켜 실패했다.
9. 팀은 관련 도구와 제품 원칙을 묶은 스킬을 동적으로 로드하는 네이티브 에이전트 구조로 이동했다.
10. Slack의 모호한 아이디어는 논의와 결정 과정을 거쳐 이슈가 되고, 담당자 지정과 코드 작성 및 PR 생성까지 이어질 수 있다.
11. 에이전트가 만든 결과도 사람의 백로그와 담당자에게 연결해야 작업이 채팅 속에서 사라지지 않는다.
12. 초기 사용량의 약 80%가 이슈 생성이어서 작은 라우터와 전용 서브프롬프트로 그 경로를 먼저 최적화했다.
13. 가장 큰 모델로 가능성을 검증한 뒤 평가 세트를 만들고 작업에 필요한 가장 작은 모델로 비용을 낮추는 순서가 권장된다.
14. 평가는 결정론적 필드 검증과 설명·제목 품질 같은 주관적 판단을 함께 다뤄야 한다.
15. LLM 심판은 유용하지만 사람이 심판의 정확성을 점검해야 하며, 모든 응답을 획일화하면 거짓 신호가 생긴다.
16. 가장 큰 응용 AI 문제는 모델이 멍청해서가 아니라 모델의 능력을 충분히 활용하지 않는 능력 과잉이다.
17. 좋은 에이전트는 사용자의 의도를 이해하고 원치 않는 비싸고 성가신 행동을 자제한다.
18. 도메인 에이전트의 진입점은 앱 속 챗봇만이 아니라 Slack 대화, 회의 브리핑, 프로젝트 업데이트 조사 같은 실제 업무 순간이다.
19. Linear Agent의 다음 방향은 며칠에서 한 분기까지 이어지는 프로젝트를 기억하고 능동적으로 조율하는 것이다.
20. 프로덕션 에이전트의 기준은 모든 것을 완벽히 하는 것이 아니라 핵심 워크플로를 견고하게 실행하면서 나머지는 실사용으로 계속 발견하고 개선하는 것이다.