쇼피파이가 증명한 것 : 에이전트보다 중요한 것은 작업장 설계
개인 IDE 속 비공개 AI 세션은 개발자 한 명의 속도를 높일 뿐이다. 작업 기록을 공유하는 구조가 갖춰져야 조직 전체가 학습한다.
에이전트가 어떤 일을 하면 회사 전체가 그 과정에서 뭔가를 배울 수 있어야 한다. 그래야 모든 개발자가 공유된 인사이트와 성공 사례를 자신의 것으로 흡수할 수 있다.
토비 뤼트케는 쇼피파이(Shopify)를 이끌기 전에 독일의 견습 시스템을 통해 프로그래밍을 배웠다. 견습이란 공유된 작업장에서 숙련된 사람들이 일하는 모습을 지켜보며 배우는 오래된 교육 방식이다. 최근 뤼트케는 쇼피파이의 리버(River)에 대해 설명하면서 “공방(Lehrwerkstatt)”이라는 단어를 사용했는데, 이 단어는 “작업장 전체가 곧 교실”인 그 환경을 뜻한다.
쇼피파이의 슬랙 기반 AI 에이전트인 리버와 관련된 수치는 X에서 많은 관심을 모았다. 총 5,938명의 쇼피파이 직원이 지금까지 4,450개의 슬랙 채널에서 리버를 활용해 작업했으며 현재 쇼피파이 전체에서 병합되는 풀 요청의 약 8분의 1을 리버가 공동 작성하고 있다. 중대한 성과지만, 가장 중요한 부분은 이 방식이 잘 작동하는 이유를 이해하는 것이다.
리버는 코드를 읽고 테스트를 실행하고 풀 요청을 열고 데이터 웨어하우스를 조회하고 프로덕션의 트레이스를 검사하며, 좋지 않은 계획이라고 판단하면 반대하기도 한다. 훌륭하다. 머지않아 많은 기업이 이와 같이 영리한 코딩 에이전트를 두게 될 것이다. 일부 기업은 이미 보유하고 있다.
흥미로운 부분은 리버가 단독으로 일하지 않는다는 점이다. 리버는 모두가 볼 수 있는 곳에서 일한다.
공방에 투자하기
필자는 예전에 에이전트가 명시적이고 일관적이고 문서화가 잘된 소프트웨어에서 더 좋은 성과를 낸다고 주장했다. 에이전트는 스키마, 테스트, 규약, 명료한 설정 지침, 그리고 ‘빌드 스크립트를 두 번 실행해야 하는 이유를 기억하는 유일한 엔지니어와 함께 심층적인 회고 과정을 거치지 않아도 되는 코드베이스’와 같은 재미없는 것들을 좋아한다. 정리되지 않은 리포지토리에 에이전트를 넣어보면 자신의 엔지니어링 규율 상태를 효율적으로 감사할 수 있다. 에이전트는 엔지니어링 습관을 비춰주는 거울과 같다.
바로 이 부분에서 쇼피파이는 좋은 사례로 돋보인다. 철저한 엔지니어링 사전 작업이 없었다면 리버는 성공하지 못했을 것이다. 2024년 초만 해도 쇼피파이에는 많은 리포지토리, 맞춤형 개발 환경이 있었고 피드백 루프의 속도도 느렸다. 이 상황에서 쇼피파이가 내린 두 가지 중요한 결단은 “월드(World)”라는 모노리포로 전환하고 개발 환경과 지속적 통합, 프로덕션 이미지를 모두 닉스(Nix) 기반의 재현 가능한 단일 기반 위에 구축한 것이다.
쇼피파이는 “앞으로 코딩에서 AI의 역할이 점점 더 커지고, 인프라는 이를 위한 기반이 돼야 한다”고 인식했다. 그러나 쇼피파이는 읽기 쉬운 코드를 추구하는 수준을 넘어 그 코드에 대한 전사적 공유 기억을 구축하기 시작했다.
집단 코딩
리버에는 모든 기업 설계자가 관심을 가져야 할 한 가지 설계 제약이 있다. 바로 공개 슬랙 채널에서만 동작한다는 점이다. 다이렉트 메시지도 없고 비공개 그룹도 없다. 다른 사람들이 보고 참여하고 검색하고 배울 수 있는 공개된 곳에서만 리버를 호출할 수 있다. 얼핏 별것 아닌 선택처럼 보이지만 그렇지 않다. 공개 채널 한정이라는 설계 제약 자체가 운영 모델이며, 비유하자면 슬랙 안에서 코드 개발을 오픈소스화하는 것과 같다.
이런 설계 제약으로 인해 모든 리버 세션은 그 자체가 공개 기록이 된다. 쇼피파이는 이 기록을 분석해 반복적으로 나타나는 패턴을 찾아 리버의 스킬, 프롬프트, 기본값에 피드백할 수 있다. 한 엔지니어가 어려운 과정을 거쳐 2시에 찾은 해결책이 4시에 다른 엔지니어의 출발점이 된다. 회사는 더 똑똑해지도록 모델을 재학습시킬 필요가 없고, 개발자는 굳이 문서를 작성할 필요가 없다. 작업이 흔적을 남기기만 하면 된다.
뤼트케가 말한 공방이 제품으로 구현된 형태다. 에이전트가 일하는 모습을 모두가 지켜볼 수 있다.
비교를 위해, 대다수 기업에서 AI를 도입하는 방식을 살펴보자. 한 개발자가 다른 사람은 아무도 볼 수 없는 비공개 IDE의 비공개 창에서 비공개 챗봇을 사용해 작업한다. 수천 명이 각자 이런 식으로 작업하면서 제각기 테스트를 조사하고 골치아픈 서비스 경계를 설명하거나 마이그레이션 함정을 피하는 더 현명한 방법을 발견한다. 그러나 세션이 종료되면 발견도 함께 사라진다. 물론 개발자의 작업 속도는 더 빨라질 수 있지만 회사 전체적으로는 어제에 비해 어떠한 개선도 이뤄지지 않는다.
기록이 곧 산출물
지식 관리와 관련해서 과거에 기업이 저지른 실수 중 하나는 문서를 작업이 끝난 이후 사람들이 작성하는 것으로 취급했다는 점이다. 이 방식은 대부분 실패한다. 개발자든 아니든 대다수 직원은 이미 끝낸 일을 문서화하는 지루한 작업을 반기지 않는다.
리버가 제안하는 더 나은 방법은 작업 자체가 문서를 생성하는 것이다.
물론 모든 기록이 유용하지는 않다. 어쩌면 대다수 기록이 유용하지 않을 것이다. 그러나 소수의 유용한 기록은 스킬, 기본값, 예제, 런북, 리포지토리 지침, 또는 다음 사람이 처음부터 다시 시작할 필요가 없게 해주는 링크가 될 수 있다. 쇼피파이에 따르면 리버 세션은 검색과 재현이 가능하다. 또한 쇼피파이는 이런 세션에서 발견된 패턴을 리버의 스킬, 프롬프트, 기본값에 피드백한다. 챗봇이 아닌 학습 루프다.
흔히 말하는 “AI가 개발자의 생산성을 높여줄 것”이라는 프레임은 바로 이 지점에서 너무 작게 느껴진다. 그보다는 AI가 소프트웨어 기업의 교육 효과를 높여준다는 말이 더 흥미롭다. 다만 저절로 되는 일은 아니다. 작업장을 제도화되지 않으면 기업은 각자 원자화된 생산성 사일로 모음에 그대로 머물게 된다.
매직 메모리 파일
agents.md의 유용함은 바로 이 지점에 있다. 단, 그 유용함을 얻으려면 제대로 사용해야 한다. agents.md는 스스로를 에이전트를 위한 README로 설명하며, 현재 6만 개 이상의 오픈소스 프로젝트에서 사용되고 있다. 개발자는 이를 어떻게 사용해야 할까? 깃허브가 2,500개 이상의 리포지토리를 분석한 결과를 근거로 제시하는 지침은 명령은 앞부분에 배치할 것, 구체적일 것, 실제 예시를 제공할 것, 그리고 명시적인 경계를 설정할 것이다.
결국 중요한 것을 기록하라는 말이다.
그러나 이 파일만 있으면 된다고 착각해서는 안 된다. ETH 취리히 연구진이 최근 리포지토리 수준의 컨텍스트 파일이 실제로 코딩 에이전트에 도움이 되는지 여부를 테스트한 결과, 오히려 이런 파일이 많은 경우 작업 성공률을 저하시키고 추론 비용도 20% 이상 높이는 것으로 나타났다. 인포Q(InfoQ)는 연구 결과를 이렇게 요약했다. “LLM이 생성한 컨텍스트 파일은 역효과를 일으키는 경우가 많다. 사람이 작성하는 파일은 맞춤형 툴, 비일상적인 빌드 명령, 매우 구체적인 프로젝트 제약 사항과 같이 추론이 불가능한 부분에 집중해야 한다.”
여기에 기업의 기회가 있다.
공개 깃허브 프로젝트에는 추론할 수 없는 도메인 지식이 드물지만, 기업 소프트웨어는 그러한 지식으로 가득 차 있다. 예를 들어 특정 지역에서 체크아웃 중에 가격 서비스를 호출할 수 없는 이유, 폐기된 것처럼 보이지만 여전히 주요 고객을 지원하는 레거시 API, 또는 데이터 모델과 수익 인식이 말하는 내용이 서로 다른 이유 등이 여기에 해당된다.
에이전트가 발견할 수 있는 디렉터리 맵이나 일반적인 코딩 선호도가 아니라, 바로 이런 컨텍스트가 보존 가치가 있는 컨텍스트다. 이것이 agents.md의 작업장 버전이다. 누군가 자동으로 생성한 뒤 잊어버리는 정적 파일이 아니라 관찰된 작업의 흔적이다. 에이전트가 시행착오를 하고 사람이 교정하고 패턴이 나타나며, 오래 남는 교훈은 지침이 된다.
쇼피파이와 똑같이 할 수는 없다
이 모두가 훌륭한 아이디어로 들리겠지만 한 가지 주의할 점도 있다. 쇼피파이를 복사해 똑같이 할 수는 없다는 것이다. 구글을 그대로 따라 할 수 없고 그렇게 해서도 안 되는 것과 마찬가지다. 여러분의 회사는 쇼피파이가 아니다. 대다수 기업은 리버가 좋아 보인다는 이유만으로 다음날 아침 모노리포 마이그레이션, 닉스 전환, 슬랙 전용 에이전트 사용을 선언해서는 안 된다. 그 접근 방식은 쇼피파이에서 통했을 뿐, 여러분의 회사에서도 작동한다는 보장은 없다.
쇼피파이가 아닌 대다수 기업은 에이전트가 어디에서 작업을 수행하는지, 그 작업에서 누가 배우는지를 물어야 한다. 두 질문에 대한 답이 각각 “비공개 공간”, 그리고 “아무도 없다”라면 문제가 있다. 모든 에이전트 세션이 공개 채널에서 이뤄져야 한다는 말은 아니다. 고객 데이터, 보안 사고, 인사 문제, 또는 제한된 프로덕션 컨텍스트는 절대 공개된 AI 채널에 올려서는 안 된다. 경계는 여전히 중요하다. 에이전트는 사람보다 더 빠르게 움직이고 더 많은 시스템을 다룰 수 있으므로 경우에 따라서는 이 경계의 중요성이 더욱 커진다.
그럼에도 원칙은 여전히 유효하다. 에이전트 작업은 검토, 재사용, 개선이 가능해야 한다. 기업은 첫 요청부터 툴 호출, 실패한 시도, 수정, 풀 요청, 재사용 가능한 지식에 이르기까지 전체 과정을 볼 수 있어야 한다.
공유 학습은 새로운 동시에 오래된 방식
오랫동안 개발자 경험은 더 빠른 설정, 더 나은 문서, 더 편리한 API 등 주로 개인의 마찰을 없애는 데 중점을 뒀다. 이런 부분은 지금도 여전히 중요하다. 그러나 에이전트 개발을 위해서는 공유 학습이라는 새로운 요구사항이 추가된다.
이제 훌륭한 개발자 경험을 위해서는 다른 것도 필요하다. 예컨대, 다음 개발자가 이전 에이전트 세션을 유익하게 활용할 수 있는가? 에이전트는 무엇을 변경했는지에 그치지 않고 무엇을 배웠는지도 설명할 수 있는가? 답답한 감시 환경을 만들지 않고도 개인적인 문제 해결을 팀 자산으로 전환할 수 있는가? 가시성은 감시가 아니며, 개발자의 키 입력을 하나하나 모두 검사하거나 개발자를 기업의 기억 장치를 위한 콘텐츠 생산자로 만드는 것이 목표도 아니다. 목표는 가치 있는 작업이 축적될 수 있을 만큼의 관찰가능성을 확보하는 것이다.
공유 학습 환경 구축은 툴 문제일 뿐 아니라 관리 문제이기도 하다. 개발자가 에이전트를 사용하는 이유는 에이전트가 업무 수행에 도움이 되기 때문이다. 현재 시점에서 사용을 막기는 매우 어렵다. 그러나 개발자들이 자발적으로 유용한 기업 기억을 만들어내지는 않는다. 공유 기억이 자연스럽게 축적되려면 그 과정을 뒷받침하는 워크플로우가 필요하다. 공유 작업장을 가장 편한 길로 만들어야 한다. 필자도 지난 몇 년 동안 다양한 방식으로 이를 적용해왔다.
리버 사례에서도 가르치는 쪽은 여전히 사람이다. 무엇이 유익한 작업인지를 판단하는 책임도 여전히 기업에 있다. 시스템에는 여전히 인간의 판단력과 안목, 보안, 비용 통제, 검토가 필요하다. 기업이 이 교육을 통해 배울 수 있는 공개된 공간에서 이 모든 작업이 이뤄지면 마법 같은 일이 일어난다.
이것이 기업 내부의 에이전틱 코딩이 약속하는 진정한 미래다. 즉, 모든 개발자가 각자 개인적인 뛰어난 역량을 갖는 것이 아니라 모든 개발자가 집단 역량을 활용한다. 뤼트케는 작업을 볼 수 있는 공간에서 배웠고, 견습생들은 그 작업이 이뤄지는 과정을 보며 배웠다. 에이전트 시대에는 그 공간을 소프트웨어용으로 재창조하는 기업이 성공하게 된다.
