1968 년, 한 획기적인 연구에서 실리콘 밸리를 수십 년 동안 형성할 결과가 발견되었습니다: 최고의 소프트웨어 엔지니어는 동료들보다 훨씬 더 생산적이라는 것이었습니다. 그 이후로 모든 기술 회사는 비범한 결과를 창출할 수 있는 드문 인재를 찾아 나섰습니다.
1 월, 연휴에서 돌아온 우리 엔지니어링 팀은 최첨단 모델의 발전에 AI 에 흠뻑 빠진 상태에서 git worktrees, Claude Code 및 Codex 와 함께 에이전트를 병렬로 실행하기 시작했습니다. 일부 작업에서는 5 배 더 많은 성과를 거두고 있었습니다.
이는 더 큰 질문으로 이어졌습니다: 에이전트가 엔지니어를 한 달 만에 그렇게 훨씬 더 생산적으로 만들 수 있다면, Sierra 의 모든 사람을 그 수준으로 끌어올리려면 무엇이 필요할까? 우리는 6 명으로 구성된 AI 가속화 팀을 구성하여 이를 알아보기로 했습니다. 이 블로그는 우리가 구축한 것과 그 과정에서 배운 점을 설명합니다.
1. 단일 에이전트 (Agent, singular)
우리는 역할별 에이전트 그룹으로 시작했습니다: 지원 에이전트(PINE), 데이터 분석가(Pinewood), 엔지니어(Pinecone), 영업 에이전트(Reggie Jr). 역할당 하나의 에이전트는 직관적으로 보일 수 있지만, 실제로는 실패했습니다.
표면적으로 문제는 직원들이 어떤 에이전트가 무엇을 하는지 기억해야 한다는 부담이었습니다. 소나무 테마 이름에 대한 우리의 애정도 도움이 되지 않았습니다. 그러나 더 깊은 문제는 구조적이었습니다 — 가장 중요한 작업은 팀 내부가 아니라 팀 간에 이루어지기 때문입니다.
핵심적으로, 회사는 완료해야 할 작업들의 집합체입니다. 제품을 출시하는 것을 생각해보세요. 기술 팀뿐만 아니라 영업, 마케팅, 법무, 운영 팀도 포함됩니다. 부서가 존재하는 이유는 한 팀이나 한 사람이 작업의 모든 부분을 수행할 수 없기 때문입니다. AI 는 작업을 점점 더 종단간(end-to-end)으로 완료할 수 있게 되면서 이를 변화시키고 있습니다.
그래서 우리는 이 모든 역할별 에이전트를 Pinecone 으로 통합했습니다: 하나의 Slack 핸들, 하나의 URL, 그리고 질문에서 완성된 결과까지 끊김 없는 단일 스레드를 가진 단일 에이전트입니다. Pinecone 은 어떤 시스템에서 가져와야 하는지, 요청으로 무엇을 해야 하는지 파악하므로 직원이 할 필요가 없습니다. 기술적으로는 어렵지만, 그것이 바로 AI 의 요점입니다: 기술이 복잡성을 흡수하는 것이지, 직원이 흡수하는 것이 아닙니다.
이는 우리가 이미 플랫폼에서 배운 교훈입니다. Sierra 에 구축된 에이전트는 풀 서비스(full-service)입니다: 하나의 에이전트가 제품 발견부터 계정 설정, 문제 해결, 결제 등 모든 것을 처리할 수 있습니다. 오래된 IVR 처럼 "영업은 1 번, 지원은 2 번"이 아닙니다.
모든 것을 하나의 에이전트로 통합하면 회사의 가치가 있는 곳, 즉 완료해야 할 작업에 훨씬 더 가까워집니다. 모든 개선이 전체 비즈니스에 이익이 되므로, 모든 사람이 더 빠르게 발전합니다.
2. 반응형이 아닌 능동형 (Proactive, not reactive)
대부분의 작업은 한 번에 완료되지 않습니다. 팀이 학습하고, 우선순위가 바뀌고, 새로운 정보가 등장함에 따라 며칠, 몇 주, 심지어 몇 달에 걸쳐 진행됩니다. 요청을 받았을 때만 나타났다가 세션이 끝나면 사라지는 에이전트는 그다지 유용하지 않습니다. Pinecone 은 전체 프로세스에 걸쳐 지속됩니다(persists) — 컨텍스트를 전달하고 스레드를 다시 잡아서, 개별 요청뿐만 아니라 작업 자체가 완료될 때까지 계속합니다.
지속성은 또한 Pinecone 을 능동적(proactive)으로 만듭니다. 요청을 기다리는 대신, 다음 단계가 준비되었을 때 — 아티팩트에 웹훅이 실행되거나, Linear 에 작업이 할당되거나, 리뷰가 들어오거나 — 행동할 수 있습니다. 컨텍스트를 수집하고 첫 번째 패스를 수행하여, 판단이 필요할 때 사람들을 참여시킵니다. 회의 전에 준비 노트가 기다리고 있습니다. 점수를 추가하기 위해 앉기 전에 인터뷰 보고서가 초안 작성됩니다. 리뷰는 요약, 주요 위험 및 제안된 코멘트와 함께 도착합니다. 목표는 더 많은 알림이 아닙니다. 완성되지 않은 상태로 도착하는 작업을 줄이는 것입니다.
아직 완전히 정착하지는 못했습니다 — 대부분의 세션은 여전히 사람의 프롬프트로 시작됩니다 — 하지만, 필요할 때 에이전트가 사람에게 프롬프트를 주도록 관계를 역전시키는 것이 지속성이 우리를 이끄는 방향입니다.
3. 비즈니스 컨텍스트가 병목이지, 지능이 아니다 (Business context is the bottleneck, not intelligence)
AI 의 병목 현상은 원시 지능(raw intelligence), 즉 모델이 충분히 똑똑한지 여부였습니다. 오늘날 최첨단 모델은 대부분의 비즈니스 요구에 충분히 능력이 있습니다. 따라서 병목 현상은 컨텍스트로 이동했습니다: 회사 고유의 것, 워크플로, 역사, 어떤 훈련 세트에도 나타나지 않는 판단 호출 등입니다.
1 월, 우리 팀의 두 사람은 Claude Code 와 Opus 4.6 을 사용하여 데이터 분석가 에이전트를 빠르게 만들어, Model Context Protocol (MCP) 및 명령줄 도구를 통해 시스템에 연결했습니다. 많은 추가 지침 없이도 몇 분 만에 Slack, GitHub, ClickHouse, Salesforce 및 PagerDuty 전반의 고객 문제를 조사할 수 있었습니다. 한때 오후 내내 소모되던 작업이 디버깅 및 인시던트 대응의 첫 번째 단계가 되었습니다.
동일한 패턴은 디버깅을 훨씬 넘어 확장됩니다. 완전한 컨텍스트를 가진 에이전트는 고객 회의를 준비하고, 계정을 조사하고, 계약서나 RFP 를 검토하고, 제품 결정을 추적하고, 흩어진 작업을 완성된 아티팩트로 전환할 수 있습니다. 물론, 에이전트에게 이 모든 컨텍스트에 대한 액세스 권한을 부여하는 것은 새로운 문제를 야기합니다. 제한이 없는 에이전트는 막대한 보안 및 개인정보 보호 위험입니다. MCP Gateway 가 이를 해결합니다: Pinecone 은 각 직원의 액세스 권한을 상속하고, 모든 도구 호출에서 정책을 시행하며, 고객 데이터를 격리하고, 감사 추적을 남깁니다.
이미지 설명 읽기
ALT
Sierra MCP Gateway 가 에이전트를 37 개 시스템에 연결합니다
Pinecone 은 Claude Code 와 Codex 위에 구축되었습니다. 이들의 빈번한 개선은 순풍과 같지만, 최첨단 기술은 끊임없이 변화합니다 — 한 모델은 계획에 가장 뛰어날 수 있고, 다른 모델은 코딩에, 또 다른 모델은 글쓰기에 뛰어날 수 있습니다. 모델 위의 레이어를 소유함으로써 각 작업을 적절한 모델로 라우팅하고, 다운타임 동안 장애 조치(fail over)하며, 비용을 관리하면서 특정 업체에 좌우되지 않을 수 있습니다. 그러나 지속 가능한 이점은 기본 모델을 소유하는 것이 아닙니다. 모든 모델을 더 유용하게 만드는 컨텍스트, 워크플로 및 라우팅 레이어를 소유하는 것입니다.
또한 Pinecone 이 꿈꾸게 하는(dream) 실험도 하고 있습니다: 매일의 작업을 되돌아보고 자신의 기술에 대한 개선 사항을 제안하는 것입니다. 시간이 지남에 따라, 이것이 단순히 Sierra 를 위해 일하는 에이전트와 Sierra 로부터 배우는 에이전트의 차이를 만듭니다.
4. 에이전트가 UI 이고, 시스템 오브 레코드가 백엔드다 (The agent is the UI, the system of record the backend)
모든 작업은 구체적인 무언가, 즉 아티팩트(artifact)를 생성합니다. 코딩 에이전트는 가장 먼저 자신의 것을 찾았습니다: 풀 리퀘스트(pull request)입니다. 다른 모든 부서에는 각자의 동등한 것이 있습니다 — 고객 스토리, 계약서, RFP 설문지, 피치 덱, 성과 검토 등입니다.
아티팩트는 입력이자 출력입니다. 에이전트에게 작업 수행에 필요한 컨텍스트를 제공하고 — 완료된 작업이 속하는 곳이기도 합니다. Pinecone 에게 피치 덱을 다듬어 달라고 요청하면, 무엇을 변경하라고 알려주는 채팅 메시지가 아닌, 업데이트된 덱 자체가 반환됩니다.
우리는 시스템 오브 레코드(systems of record)와 함께 작업하는 것이 최선이며, 이를 대체하는 것은 최선이 아님을 발견했습니다. GitHub 는 PR 을 유지하고, Salesforce 는 계정을 유지하며, Linear 는 이슈를 유지합니다 — 에이전트는 이들 전반에 걸친 레이어입니다.
이러한 시스템을 대체하는 것은 수십 년 동안 성숙해온 소프트웨어를 재창조하는 것을 의미합니다. 더 나쁜 것은, 회사를 둘로 나누는 것입니다 — 에이전트를 통해 작업하는 사람들과 원래 도구에서 직접 작업하는 사람들, 각자 자신만의 진실 버전을 가진 상태로 말입니다. 우리의 믿음은 이러한 제품들이 시간이 지남에 따라 더 백엔드처럼 되어가고, 에이전트가 주요 인터페이스가 될 것이라는 점입니다.
5. 단순한 활동이 아닌 결과 (Outcomes, not just activity)
3 월에 Pinecone 이 처음 커밋된 이후로, 600 명 이상의 사람들을 위해 75,000 회 이상의 세션을 실행했습니다. 오늘날, 우리 PR 의 70% 가 이를 통해 열리고 있으며, 수백 개의 자동화가 아무도 명시적으로 프롬프트하지 않은 작업을 조용히 처리하고 있습니다.
그런 숫자는 먼저 제시하고 싶어지는 유혹적이며, 초기에는 추적할 올바른 대상입니다 — 로드맵 슬라이드에서 먼지만 쌓이고 있는 것이 아니라 실제로 사용되고 있다는 증거이기 때문입니다. 그러나 실행된 세션과 도구 호출은 결과(outcome)가 아닌 활동(activity)입니다. 팀은 다운스트림에서 실제로 개선되는 것 없이 — 동일한 수의 실수, 동일한 사이클 타임, 단지 더 많은 AI 가 그 생산에 관여한 것 — 인상적인 채택 차트를 향해 토큰을 최대화(tokenmaxx)할 수 있습니다.
따라서 토큰 사용량은 시작하기에 좋은 지점입니다. 팀은 도구가 실제로 작동하는지 측정하기 전에 도구를 사용하는 습관을 형성해야 합니다. 그러나 그것이 가치가 있는 곳은 아니며, 우리는 이야기가 거기서 끝나기를 원하지 않습니다. 우리가 더 잘 물어보기 위해 노력하는 질문은 에이전트가 얼마나 많은 일을 했는가가 아니라 — 그로 인해 실제로 무엇이 바뀌었는가입니다: 거래가 더 빨리 성사되었는지, 고객의 문제가 첫 번째 시도에 해결되었는지, 누군가가 늦은 밤까지 리뷰를 마치는 대신 저녁 시간을 되찾았는지 등입니다.
아직 그것을 측정할 좋은 방법은 없습니다. 세션과 도구 호출은 단순히 계산하기 더 쉽습니다. 그러나 오늘날 측정할 수 있는 것과 우리가 실제로 관심을 가지는 것 사이의 그 격차가 우리가 다음으로 구축해 나가고 있는 것입니다.
1968 년 그 연구는 최고와 나머지 사이에 10 배의 격차를 발견했고 — 50 년 동안 유일한 해결책은 그 드문 사람들을 찾아 나서는 것이었습니다. 이제 더 나은 해결책이 있습니다: 모든 사람에게 에이전트를 주어 소수가 가졌던 이점을 누리게 하는 것입니다. 목표는 단순히 더 많은 일을 처리하는 것이 아닙니다. 사람들에게 오직 사람만이 할 수 있는 작업, 즉 판단, 취향, 창의성 및 관계 구축을 위한 더 많은 시간을 주는 것입니다.
다음 내용 (Up next)
우리가 구축한 시스템에 대해 더 깊이 있게 다룰 예정입니다:
- Allen Chen 님의 Pinecone, 그 많은 반복, 그리고 그 뒤에 있는 기술 아키텍처
- Mihai Parparita 님의 MCP Gateway 및 완전한 컨텍스트의 안전한 수집
- Rohith Ravi 님의 Agency, 그 모든 것의 기반이 되는 인프라
