Agent로 돌아가는 팀을 만들려면

Fermented Post 이 글은 두 가지 버전이 공존합니다 — 원본(Raw)과 AI가 다듬은 버전(Polished)

AI 생산성을 dramatic 하게 우리는 논의하고 있습니다. 데이터 분석도, 개발도, 기획도, 디자인도 인간의 병목을 벗어나 4~5명이 100개가 넘는 에이전트를 소유하고, 굴리고 발전해서 앞으로 나아가는 체계를 떠올립니다. 그러나 개념에 앞서서, 우리는 성공하는 팀을 만들고 100개가 넘는 에이전트를 만들어 나가는 과정이 있을 것입니다. 우리의 비즈니스가 존재할 거고, 돈을 지불하는 고객이 있겠죠. 그 팀이 성공에 도달하기까지, 무엇이 필요하고 어떻게 일해야하는지를 논의해보고자 합니다.

무엇이 Agentic하게 됩니까?

왜 당신은 아직 당신의 일을 에이전트에게 못 맡겼나요? 디자인이 마음에 안들어서? 기획이 제대로 된 건지 몰라서? 아키텍처가 너무 허접해서? 우리가 만들게 될 가치나 새로운 것들은 전혀 자동으로 만들 수 있는 종류의 것들이 아닙니다. 다음을 모두 고려해서 나오는 종합적인 art입니다.

• 제약 조건
• 요구사항
• 비용
• 사용성

고민하고 상황을 파악하는 시간, 다음 기능을 고민하는 시간, 데이터 피드백을 하는 시간들을 어떻게 줄일 수 있는지가 성공하는 팀 앞에 존재하는 1순위입니다.

일을 나누는 두 가지 기준

1. 한 번이라도 해보았나요?
2. 얼마나 어려운 일인가요?

프로그램과 코드를 기준으로는 저는 위의 두 가지가 가장 중요하다고 생각합니다. 한 번이라도 했다면 레슨 런들이 존재하고, 앞에 해뒀던 결과물들을 바탕으로 피드백해서 더 나은 시도를 할 수 있습니다. 그러나 처음 하는 일이라면, 섬세하고 고민하고 다 같이 합의하고 생각할 시간이 필요합니다. 또 하나, 쉬운 일이라면 쉽게 시도할 수 있습니다. 누구나 시도할 수 있고, 깊은 고민 없이 하고 검사를 받으면 됩니다. 그러나 어려운 일이라면, 다 같이 소유하고 결정하고 고민하는 시간이 필요합니다.

하네스는 결과물입니다. 성공을 보장하는 장치가 아닙니다.

하네스가 개발이 똑바로 되는 좋은 수단이라고 생각합니다. 그러나, 하네스가 만들어졌다면 이미 우리는 무엇을 할 지 알고 있는 상태여야 합니다. 고로 하네스는 우리가 길을 따라 걸으면서 남겨둔 헨젤과 그레텔의 빵부스러기처럼, 실수나 고민을 반복하지 않도록 닦아둔 길에 가까운 결과물입니다. 결국에 새롭게 나아갈 때에는 고민과 새로운 스텝을 밟아야 합니다. 이것에는 시간과 노력이 들어야 합니다. 그 시간이 이전보다 짧아졌더라도, 시간 자체는 줄일 수 없습니다.

Agile 개발 방법론에서 배우는 인간-AI alignment

5명의 팀이 하루 4~5개 세션을 굴려서 개발하는 방식은 마치 Scaled agile team에서 총 30~50명 정도의 팀이 협업하는 것과 닮아 있습니다. 우리는 각자 사람(매니저)를 통해서 팀의 작업물들을 공유받고 다른 사람들의 작업물들은 물론 우리 스스로의 작업물을 검토할 시간도 부족합니다. 이러한 상황에서 에이전트와의 alignment 뿐만 아니라 우리들의 alignment를 맞추려면 기존 방법론의 방식들의 차용이 필요합니다.

• Sprint planning
• 포스트잇과 볼펜
• Committed Story and Uncommitted Story
• Retrospective
• CIDP(Continuous Innovation and Delivery Pipeline)

인간과 인간 사이에 alignment 과정에서 마찰을 해결함으로써, 인간-AI alignment 또한 높일 수 있습니다.

공유 세션, 세션 리뷰

내가 잘 하지 못하는 것을 하고 싶을 때, 우리 팀은 모두가 할 수 있도록 보조해야 할 의무가 있습니다. 개발을 잘 하지 못하는 내가 개발을 하고 싶을 때, 개발을 잘 하지만 비즈니스가 부족한 내가 비즈니스 thinking을 하고 싶을 때. 공유 세션을 열고 그 곳에 모여서 일을 진행합니다. 전문가가 같이 코멘트 주고 관심 있는 모두가 쳐다보고 코멘트를 남기거나 진행을 보조합니다. 우리 팀의 내 분야에서의 일에 대한 의무는 내가 가집니다. 나를 대신할 프로세스를 만드는 것도, 페르소나를 만드는 것도 팀원의 의무입니다. 우리는 우리가 일할 수 있는 AI system을 만들어나가는 것이, 우리의 하루 일을 하는 것보다 중요합니다.

Issac’s agile development process

전통적인 Sprint planning 으로 시작해 서로 간의 mindset과 vision의 alignment를 맞춥니다. 회의와 브레인스토밍은 공유 세션에서 bmad-brainstorming으로 진행합니다. 특히, 내가 아닌 다른 사람들이 질문하는 질문의 차이들을 기록하고 이를 채워낼 수 있는 역량을 모두 함께 성장시킵니다. 내 범위에서 일어나는 작업들은, 나의 전문성을 보조하는 장치들을 생성합니다. 그러나 이것은 결코 완벽하지 않습니다. 다른 누군가가 내 분야에서 작업할 수 있도록 무한히 보조합니다. 당신이 귀찮다면, 당신을 대체할 수 있는 것을 만드는 것 또한 당신의 책임입니다.

내가 전문적이지 않은 부분들은 반드시 공유 세션으로 진행합니다. 리뷰의 단위는 세션이지 결과물이 아니며, 우리는 과정을 개선합니다.

회고합니다. 우리 사이에 있었던 마찰, 스스로 겪은 마찰, agent와의 마찰을 모두 friction graph로 기록하고 마찰을 줄일 수 있는 방법론을 고민합니다. 저번 주와 이번 주 속도가 같지만 마찰이 줄었다면, 더 많은 부분을 자동화하는데 성공한 팀입니다.

핵심 지표

1. 재작업률: 빠르게 만든 결과물을 방향이 어긋나 다시 만들고 있지는 않은지?
2. 전문가 개입 횟수: 같은 종류의 문제를 해결하기 위해 같은 전문가가 반복해서 호출되고 있지는 않은지?
3. 마찰 수: 이번 주 작업하면서 존재한 마찰의 개수가 많지 않았는지?

TDD, 에픽과 스토리 기반 진행, 단위 테스트 등 좋은 소프트웨어 개발 방법론은 필수입니다. 이것이 속도를 낮춘다면 더 많은 시간을 할애해서라도 달성할 수 있어야 합니다. 타협의 여지가 아니며, 정말로 극적인 상황이 아니라면 규칙을 준수합니다.

결론

좋은 소프트웨어 팩토리를 구축하면 좋은 소프트웨어 개발이 된다는 본질은 동일하다고 믿고, 모두가 발전하는 팀이 되어 성공을 이룩해야 합니다. 그런 팀이 되지 않는다면 개인 플레이나 대기업에서 조직 간 마찰과 동일한 현상을 해결할 수 없다고 생각합니다. 성공적인 서비스를 내면서도 마찰을 0으로 줄인 팀이 되었다면, 우리는 진정으로 AI native한 팀을 만들었다고 할 수 있습니다. 그러나 단언컨대, 마찰이 0인 상황은 존재하지 않습니다.

AI-native 팀은 마찰이 없는 팀이 아닙니다. 마찰을 발견할 때마다 그것을 다음 실행의 기본값으로 바꾸는 팀입니다.

제 저장소에는 하네스가 있습니다. 훅과 스킬, CLAUDE.md, 몇 개의 검증 스크립트. 누군가 이걸 통째로 복사해 가면 저와 같은 결과가 나올까요.

나오지 않습니다. 저는 그걸 여러 번 확인했습니다.

하네스는 품질을 만들어내는 장치가 아닙니다. 이미 끝난 판단이 굳어서 남은 화석입니다. 저 훅 하나하나는 제가 같은 실수를 세 번쯤 반복한 뒤에야 생겼고, 그 세 번의 실수는 파일에 남지 않았습니다. 남은 건 결론뿐입니다. 결론만 물려받은 사람에게 그것은 지켜야 할 규칙이지 이해한 규칙이 아닙니다.

물론 화석도 일을 합니다. 린트 룰은 그 룰이 왜 생겼는지 모르는 사람의 코드도 걸러내고, 검증 스크립트는 처음 온 사람이 저지를 사고를 막아줍니다. 하네스는 팀의 하한선을 올립니다. 다만 하한선만 올립니다. 그리고 팀이 어느 순간부터 나아가지 못하는 이유는 하한선이 낮아서가 아니라, 상한선이 몇 달째 그 자리에 있어서입니다.

그래서 저는 팀의 자산 목록을 거꾸로 적기 시작했습니다. 우리가 자동화한 것의 목록이 아니라, 아직 자동화하지 않기로 한 판단의 목록을.

난이도는 기준이 될 수 없습니다

목록을 적으려면 기준이 있어야 합니다. 제가 처음 적은 기준은 이랬습니다. 새로운 것과 기존과 비슷한 것, 어려운 것과 쉬운 것.

며칠 써보고 절반을 버렸습니다.

버린 쪽은 난이도입니다. 첫째, 난이도는 해보기 전에는 알 수 없습니다. 어려운 작업인지 아닌지는 세 시간을 넣어본 뒤에야 알게 되는 결과값입니다. 결과값을 입력으로 쓰는 기준은 기준이 아닙니다. 둘째, 사람의 난이도 순서와 모델의 난이도 순서는 애초에 같지 않습니다. 사람에게 지루하기만 한 대규모 기계적 변환은 에이전트에게 가장 쉬운 일이고, 우리가 몇 년에 걸쳐 쌓아온 암묵적 예외 처리는 사람이라면 반사적으로 피해 가는 지뢰인데 에이전트에게는 최난도입니다. 사람 기준으로 그린 난이도 축을 에이전트에게 들이대면, 가장 위험한 칸이 가장 안전한 칸으로 보입니다.

남은 쪽, 그러니까 새로운 일이냐 해본 일이냐는 버리지 않았습니다. 다만 축에서는 내렸습니다. 왜 내렸는지는 사분면을 그린 다음에 말씀드리는 편이 빠를 것 같습니다.

축으로 남길 수 있었던 것은 결국 두 개였습니다. 기계가 정답을 판정할 수 있는가. 그리고 틀렸을 때 되돌리는 비용이 얼마인가.

두 축은 대등하지 않습니다

	기계가 정답을 판정할 수 있다	판정할 수 없다
되돌리기 싸다	Datadog에 뜬 에러 메시지 수정, 잘못 연결된 API 호출 정리, 테스트가 이미 갖춰진 코드 위의 작업	이메일 인프라 변경 — 태그를 붙여 하드바운스와 소프트바운스를 나누고 모니터링을 거는 일
되돌리기 비싸다	대규모 리팩터링, 아키텍처 변경	신규 기능, 에이전틱 기능

왼쪽 위는 고민할 게 없습니다. 던지고, 결과를 기계가 판정하고, 아니면 되돌립니다. 오른쪽 아래도 고민할 게 없습니다. 여기 있는 것들이 목록에 오릅니다.

사고는 나머지 두 칸에서 납니다.

왼쪽 아래, 검증은 되는데 되돌리기가 비싼 칸. 대규모 리팩터링은 테스트가 전부 초록색인데도 위험합니다. 판정을 통과했다는 것과 되돌릴 수 있다는 것은 다른 이야기라서요. 초록불을 확인한 다음 날, 그 변경을 되돌리려면 일주일이 듭니다.

그리고 오른쪽 위. 이 칸이 제일 유혹적입니다. 되돌리기가 싸니까 일단 던져보고 싶어집니다. 저도 그렇게 생각했습니다.

그런데 되돌림은 틀렸다는 걸 알아챈 다음에야 작동하는 기능입니다. 검증이 안 되는 칸에서는 알아채는 시점이 오지 않습니다. 이메일 인프라를 예로 들어보죠. 롤백 자체는 어렵지 않습니다. 그런데 소프트바운스를 하드바운스로 잘못 분류하고 있다는 사실은 한참 뒤에야 드러납니다. 그동안 멀쩡히 살아있는 주소들이 조용히 억제 목록에 쌓입니다. 되돌리기가 싸다는 사실은 아무것도 구해주지 못합니다.

그래서 두 축은 대등하지 않습니다. 되돌림 비용은 검증 가능성에 종속됩니다. 검증이 안 되면 되돌림은 없는 기능이나 마찬가지입니다.

새로움은 축이 아니라 설명입니다

이제 미뤄둔 이야기를 하겠습니다. 새로운 일이냐, 해본 일이냐.

위 표를 다시 보면 그 축이 이미 들어와 있습니다. 왼쪽 위는 전부 해본 일이고, 오른쪽 아래는 전부 처음 하는 일입니다. 새로움은 사분면을 가로지르는 대각선으로 흐릅니다. 별개의 축이 아니라 두 축의 합성 방향입니다.

그런데 대각선에서 벗어나는 것이 둘 있습니다. 대규모 리팩터링은 수없이 해본 일인데 되돌리기가 비싸고, 이메일 인프라 변경은 새롭다고 하기도 애매한데 검증이 안 됩니다. 그리고 앞에서 봤듯이 사고는 정확히 그 두 칸에서 납니다. 새로움만 보고 있으면 사고가 나는 자리를 못 봅니다.

더 큰 차이가 하나 더 있습니다. 새로움은 우리가 바꿀 수 없습니다. 어제 처음 해본 일은 영원히 그때 처음 해본 일입니다. 반면 검증 가능성과 되돌림 비용은 바꿀 수 있습니다. 테스트를 붙이면 오른쪽 칸이 왼쪽 칸이 되고, 배포를 플래그 뒤에 숨기면 아래 칸이 위 칸이 됩니다.

그래서 새로움은 축이 아니라 설명입니다. 어떤 티켓이 왜 저 자리에 있는지는 알려주지만, 그래서 무엇을 하라고는 말해주지 않습니다. 축은 행동을 지시할 수 있어야 합니다.

게이트는 기준이 아니라 경계입니다

두 축은 바꿀 수 있다고 했습니다. 바꾸는 도구가 하네스입니다.

테스트를 붙이는 것, 검증 스크립트를 CI에 거는 것, 배포를 플래그 뒤에 숨기는 것, 훅으로 특정 패턴을 막는 것. 전부 티켓을 사분면 위에서 왼쪽 위로 미는 일입니다. 그러니까 하네스는 에이전트를 잘 굴리게 해주는 장치가 아니라, 던질 수 있는 것과 없는 것 사이의 선을 옮기는 장치입니다.

여기서 앞의 이야기와 부딪히는 것처럼 보입니다. 하네스는 품질을 못 올린다더니, 이제는 칸을 옮긴다고 하니까요.

부딪히지 않습니다. 하네스는 품질을 올리지 않습니다. 경계를 옮길 뿐입니다. 어제는 제가 옆에 붙어 있어야 했던 일이 오늘은 던지고 결과만 보면 되는 일이 됩니다.

여기서 하한선과 상한선이 갈립니다. 그 훅을 받아서 쓰는 사람에게는 하한선이 올라간 것입니다. 규칙이 하나 늘었고, 그만큼 사고가 줄었습니다. 하지만 그 경계를 실제로 민 사람에게는 상한선이 움직인 것입니다. 어제까지 아무도 넘기지 못하던 자리를 넘길 수 있게 만든 사람은 그 사람뿐입니다. 같은 훅이 누구에게는 지켜야 할 규칙이고 누구에게는 이번에 새로 알아낸 것인 이유가 여기 있습니다.

그러면 목록의 성격도 달라집니다. 아직 자동화하지 않기로 한 판단의 목록은 한 번 정하고 벽에 붙이는 명단이 아닙니다. 스프린트마다 줄어들어야 하는 목록입니다. 이번 달에 항목 하나가 목록에서 빠졌다면 우리가 그만큼 경계를 밀었다는 뜻이고, 몇 달째 같은 항목이 그대로 있다면 그건 그 판단이 어려워서가 아니라 아무도 그것을 밀지 않고 있다는 뜻입니다.

게이트는 통과와 불통과를 가르는 기준이 아니라, 우리가 밀어서 옮기는 경계입니다.

물려줄 것은 결론이 아니라 망한 세션입니다

경계를 미는 일은 결국 하네스를 만드는 일이고, 하네스는 실수에서 나옵니다. 그런데 실수는 개인이 겪습니다. 제가 세 번 틀린 뒤에 훅 하나를 만들면 팀에 남는 것은 훅 하나입니다. 세 번의 실수는 제 머릿속에만 남습니다.

글 첫머리에서 하네스를 복사해 가도 같은 결과가 나오지 않는다고 했습니다. 이유가 여기 있습니다. 우리는 결론만 물려줍니다.

그러니 물려줄 것을 바꿔야 합니다. 결론이 아니라 결론에 이른 세션을요. 그것도 잘 풀린 세션이 아니라 망한 세션입니다. 에이전트가 세 번 헛다리를 짚고, 제가 프롬프트를 세 번 고쳐 쓰고, 결국 접근을 통째로 바꿨던 그 기록이 훅 옆에 놓여 있어야 훅이 읽힙니다.

처음에 저는 이걸 공유 계정으로 생각했습니다. 중요한 작업은 팀 계정으로 하자고요. 틀린 해법입니다. 계정을 공유하면 누가 무엇을 했는지가 사라집니다. 원한 것은 자격 증명의 공유가 아니라 기록의 공개였는데, 정확히 반대로 가는 장치를 고른 셈입니다.

다음으로 생각한 것은 같이 앉아서 하는 세션이었습니다. 이건 틀리진 않았는데 오래 못 갑니다. 사람은 보고 있는 사람 앞에서 자기가 못하는 것을 하지 않습니다. 정확히 반대로 합니다. 자신 있는 것을 골라서 보여줍니다. 관찰이 붙는 순간 세션은 시연이 됩니다.

남는 것은 비동기입니다. 망한 트랜스크립트를 PR에 붙이거나 채널에 그대로 던지는 것. 지루하고 멋이 없는데, 이 방식은 유지됩니다. 보고 있는 사람이 없어서요.

하나 더 있습니다. “내가 잘 못하는 것을 공유하자”는 말에는 함정이 있습니다. 자기 약점을 아는 사람은 이미 그 약점의 절반을 해결한 사람입니다. 진짜로 위험한 것은 내가 잘한다고 믿고 있는 영역이고, 그 영역의 세션은 제가 먼저 공유하자고 말하지 않습니다. 그래서 공유는 고르는 것이 아니라 기본값이어야 합니다.

스프린트는 아직 만들 수 있는 양으로 계획됩니다

여기까지는 개인의 습관에 가깝습니다. 남은 것은 팀이 언제 모여서 무엇을 정하느냐입니다.

우리 팀의 스프린트 플래닝은 여전히 이렇게 묻습니다. 이번 스프린트에 몇 개를 만들 수 있는가. 이 질문에는 구현이 병목이라는 전제가 깔려 있습니다. 애자일의 의례 대부분이 그 전제 위에서 설계됐습니다.

에이전트는 정확히 그 전제만 무너뜨립니다. 구현은 늘어납니다. 검증은 늘어나지 않습니다.

이건 제 인상이 아니라, 애자일 프레임워크들이 팀 크기라는 숫자로 무엇을 방어해 왔는지를 보면 드러납니다.

• Scrum Guide — 팀은 10명 이하. 이유로 적힌 것은 작은 팀이 더 잘 소통하고 더 생산적이라는 관찰입니다.
• SAFe — ART의 규모는 50~125명. 그 상한의 근거는 사람이 유지할 수 있는 안정적인 사회적 관계의 수였습니다.
• Team Topologies — 한 팀이 맡을 수 있는 도메인 개수를 인지 부하로 제한합니다. 복잡한 도메인 하나를 맡았다면 단순한 것 하나도 더하지 말라고까지 씁니다.

전부 사람 쪽 비용입니다. 만들어내는 양을 방어하는 규정은 사실상 없습니다.

그리고 사람 쪽 비용은 에이전트를 붙인다고 줄지 않습니다. 오히려 늘어납니다. 에이전트가 만든 것도 결국 사람이 읽고 승인해야 하니까요.

Brooks는 인원을 늘릴 때 생기는 부담을 두 항으로 나눴습니다. 훈련과 상호통신입니다. 그리고 훈련에 대해 이렇게 썼습니다. 훈련은 나눌 수 없으므로, 이 부분의 추가 비용은 인원수에 선형으로 비례한다고.

에이전트판 훈련은 컨텍스트 로딩입니다. 그리고 이건 에이전트마다, 태스크마다 다시 지불됩니다. Anthropic이 자사 멀티에이전트 시스템을 두고 공개한 수치로는 채팅 대비 토큰이 약 15배 들었고, 토큰 사용량 하나만으로 성능 분산의 80%가 설명됐습니다.

Brooks의 법칙은 사라지지 않았습니다. 단위가 사람-달에서 토큰으로 바뀌었을 뿐입니다.

그렇다면 스프린트 플래닝이 묻는 질문도 바뀌어야 합니다. 이번 스프린트에 몇 개를 만들 수 있는가가 아니라, 이번 스프린트에 몇 개를 검증할 수 있는가.

안 지킬 약속에는 만료일이 붙어야 합니다

스프린트가 검증량으로 계획된다면, 계획 회의에 꺼내놓을 문서도 달라집니다. 백로그 옆에 그 목록이 있어야 합니다.

사실 이 목록에는 이미 이름이 있습니다. 팀이 지키기로 한 약속과 지키지 않기로 한 약속 중에서, 지키지 않기로 한 쪽입니다. 이번 스프린트에 우리는 이것들을 넘기지 않는다. 그게 약속입니다.

그런데 목록을 붙여두는 것만으로는 아무 일도 일어나지 않습니다. 지켜지는 팀과 안 지켜지는 팀의 차이는 목록이 얼마나 정교하냐가 아니라, 각 항목에 오너와 만료일이 붙어 있느냐입니다.

만료일이 왜 필요한지는 앞에서 이미 나왔습니다. 몇 달째 같은 항목이 목록에 남아 있다면 그건 그 판단이 어려워서가 아니라 아무도 밀지 않고 있다는 뜻입니다. 만료일은 그 사실을 드러냅니다. 만료일이 지났는데 항목이 그대로라면, 회의에서 물어야 할 질문은 왜 아직 자동화가 안 됐냐가 아니라 이걸 미는 일이 누구 일이었냐입니다.

그러면 회고에서 셀 숫자도 정해집니다. 이번 스프린트에 목록에서 몇 개가 빠졌는가. 그리고 목록에 있는데도 몇 번이나 그냥 넘겼는가. 이 두 숫자가 없으면 목록은 장식입니다.

화석이 두꺼워지는 것은 시간이 흘렀다는 뜻입니다

여기까지가 제가 지금 생각하는 그림입니다. 검증된 방법론은 아닙니다. 이 목록을 몇 분기째 굴려본 팀을 저는 아직 못 봤고, 제 팀도 이제 막 적기 시작했습니다.

다만 이 글이 맞는지 틀리는지는 비교적 싸게 확인할 수 있습니다. 필요한 것은 문서 하나입니다. 이번 스프린트에 에이전트에게 넘기지 않기로 한 것들을 적고, 각 줄에 이름과 날짜를 붙입니다. 다음 스프린트에 그 목록에서 몇 줄이 지워졌는지 셉니다.

줄이 지워지고 있다면 팀의 상한선이 올라가고 있는 겁니다. 몇 달째 그대로라면, 우리가 잘하고 있다고 믿는 동안 하한선만 계속 올리고 있었던 거고요.

하네스는 앞으로도 계속 늘어날 겁니다. 훅도, 스킬도, 검증 스크립트도. 그건 좋은 일입니다. 다만 그것들이 쌓이는 속도는 우리 팀이 얼마나 잘하고 있는지를 알려주지 않습니다. 화석이 두꺼워지는 것은 시간이 흘렀다는 뜻이지, 우리가 앞으로 갔다는 뜻이 아니니까요.