개별 도구에서 팀 실무의 기초로: 개발 프로세스 내 AI 구조화하기

우리 개발자 대부분은 이미 매일 AI와 함께 코드를 작성하고 있습니다. 제가 생각하기에 더 이례적인 상황은, 팀 전체가 두 가지 극단에 빠지지 않고 표준화된 방식으로 AI를 사용하는 것입니다. 즉, 너무 관료적으로 변해 아무도 따르지 않거나, 혹은 각자 알아서 하여 누구도 올바른 방향으로 가고 있는지 알 수 없는 상태 말입니다.

이 글은 그 중간 지점에 관한 이야기입니다. 설정 튜토리얼은 아닙니다 (공식 문서가 그 어떤 포스트보다 더 잘하고 최신 정보를 제공합니다). 또한 성공 사례나 결과에 대한 글도 아닙니다. 왜냐하면 아직 그런 사례는 아무도 없다고 생각하기 때문입니다. 이 글은 Anthropic과 Cognition이 이 주제에 대해 발표한 자료들을 공부한 후, 웹 개발 및 분산 시스템(distributed systems) 분야에서 일하는 사람의 관점으로 문제를 해석한 결과입니다.

문제는 좀처럼 프롬프트(prompt) 때문이 아니다

가장 중요한 관점의 변화는 AI 에이전트를 단순히 "모델(model)"로만 생각하는 것을 멈추고, 모델에 주변 장치들을 더한 것으로 생각하는 것입니다. 문헌에서는 이 주변 장치들을 하네스(harness)라고 부릅니다. 이는 도구, 검증 절차, 제공되는 컨텍스트(context), 부과하는 제한 사항, 그리고 모델이 실수했을 때 이를 수정하는 피드백 루프(feedback loop)를 의미합니다.

AI 세션이 좋지 않을 때, 많은 사람들은 즉시 모델이나 프롬프트를 탓합니다. 하지만 제 생각에 문제는 종종 하네스(harness)에 있습니다. 코드가 어떻게 작동하는지에 대한 컨텍스트가 부족했거나, 무언가 깨졌는지 확인할 테스트가 없었거나, 모델이 스스로의 작업을 검증할 방법이 없었을 수 있습니다. 이는 프로덕션 환경에서 서비스가 제대로 작동하지 않을 때, 원인이 요청(request) 코드 자체에 있는 것이 아니라 타임아웃(timeout), 재시도(retry), 또는 문제를 사전에 보여줄 메트릭(metrics)의 부재에 있는 것과 같은 논리입니다.

이 단어를 기억하세요. 하네스(harness)는 AI를 둘러싼 인프라(infrastructure)이며, 여기서 다룰 거의 모든 내용은 이를 구축하는 방법입니다. 하네스가 허용하는 가장 실질적인 결정부터 시작하겠습니다.

자율성은 난이도가 아닌 검증 가능성을 따라야 한다

본능적으로는 쉬운 작업에는 AI에게 더 많은 자율성을 부여하고, 어려운 작업에는 적게 부여하고 싶어 합니다. 하지만 저는 핵심 축이 달라야 한다고 생각합니다. 즉, 작업이 검증 가능한 (verifiable) 곳에는 더 많은 자율성을 부여하고, 그렇지 않은 곳에는 적게 부여하는 데 초점을 맞춰야 합니다.

테스트 커버리지가 좋은 서비스는 에이전트 (agent)에게 객관적인 피드백 루프 (feedback loop)를 제공합니다. 에이전트는 코드를 수정하고, 테스트를 실행하고, 무엇이 깨졌는지 확인한 뒤, 이를 수정합니다. 당신은 많은 부분을 위임하고 결과물을 검토할 수 있습니다. 반면, 테스트가 없는 서비스는 이러한 루프를 제공하지 못하며, 이 경우 AI는 아무도 알아차리지 못하는 사이에 잘못된 방향으로 속도를 내고 있을 수 있습니다. 동작이 변했다는 것을 알려줄 장치가 없기 때문입니다. 이 상황에서 AI의 가장 가치 있는 용도는 기능을 생성하는 것이 아니라, 현재의 동작을 포착하는 테스트를 생성하여 모호한 서비스를 검증 가능한 상태로 변환하는 것입니다. 도구를 신뢰하기 전에, 그 도구 자체를 사용하여 기술 부채를 갚는 것입니다.

하지만 검증 가능성 (verifiability)은 하늘에서 떨어지는 것이 아닙니다. 그것은 당신이 구축하는 하네스 (harness)의 일부입니다. 가장 간단한 방법은 리포지토리 (repo) 루트에 파일을 두는 것입니다. 예를 들어 (Anthropic의 제품을 사용 중이라면) 유명한 CLAUDE.md 파일처럼, 에이전트에게 프로젝트를 설명하고, 빌드 방법, 테스트 실행 방법, 컨벤션 (conventions), 건드리지 말아야 할 것 등을 기술하는 것입니다. 다음과 같은 식입니다:

# 서비스-이름
무엇을 하는지 한 문장으로 설명. 주요 스택 (Stack).

...

매우 단순해 보이지만 그렇지 않습니다. 이 파일은 향후 모든 AI 세션의 입력값 (insumo)이며, 동시에 새로운 팀원을 위한 기본적인 온보딩 (onboarding) 문서이기도 합니다. 하지만 이 파일은 항상 최신 상태로 유지되어야 합니다. 그렇지 않으면 단순히 쓸모없어지는 데 그치지 않고, 컨텍스트 (context)를 오염시켜 AI가 잘못된 코드를 확신을 가지고 생성하게 만들기 때문입니다. 문서화 (Documentation)는 이제 예의 차원의 문제가 아니라 실행 설정 (configuration)의 일부가 되었습니다.

이로부터 파생되는 흐름은 평소와 같지만, 다음과 같이 명확히 정리할 수 있습니다:
코드를 작성하기 전에 탐색하고, 계획을 제안하며, 첫 번째 줄을 생성하기 전에 인간이 그 계획을 검토하게 하고, 매 단계마다 검증하며 단계별로 구현하고, 전체 diff (차이점)를 검토하는 것입니다. 가장 레버리지(leverage)가 큰 지점은 바로 계획입니다. 계획에서 실수하는 것은 한 줄의 코드에서 실수하는 것보다 10배 더 많은 비용이 들며, 사람이 개입하기에 가장 저렴한 시점입니다.

마지막으로, 모델의 판단에 의존하지 않는 가드레일 (guardrails)입니다. 매 편집마다 포맷팅 (formatting)과 컴파일 (compilation)을 실행하는 훅 (hook)은 "AI가 빌드를 깨뜨리지 않았기를 바랍니다"라는 문장을 "빌드가 통과하지 않으므로 진행할 수 없습니다"로 바꿔 놓습니다:

# 매 편집 시 실행; exit != 0 이면 에이전트가 수정하도록 에러를 반환
formatar "$arquivo" && compilar || exit 2

또한 승인 없이 AI가 마이그레이션 (migrations), 공개 계약 (public contracts), 또는 결제 코드 (payment code)를 편집하는 것을 방지하는 부정 목록 (negation list)이 있습니다. 여기서 주목할 점은 모델이 규칙을 준수하기로 "결정"하는 것이 아니라, 모델이 차단되는 것이라는 점입니다. 결정론 (determinism)이 중요한 곳에 결정론을 적용하는 것입니다.

기준은 읽기나 쓰기가 아니라, 독립성입니다

멀티 에이전트 (multiple agents)를 이야기할 때, 아키텍트 에이전트, QA 에이전트, 리뷰어 에이전트가 모두 협의하는 "팀"을 구성하고 싶은 강한 유혹이 있습니다. 이는 멋지고 유망해 보이지만, 문제는 에이전트 간의 결정이 협업이 아닌 다수결로 흐르는 경향이 있다는 것입니다. 그들은 서로의 오류를 잡아내는 대신 합의 (consensus)를 향해 수렴해 버립니다. 유용한 기준은 읽기 대 쓰기나 난이도 수준이 아니라, 사실상 독립성입니다. 작업이 서로 소통할 필요가 없는 부분들로 분해되는가, 아니면 각 단계가 이전 단계에 의존하는 추론 체인 (chain of reasoning)인가를 따져봐야 합니다.

이에 대한 직접적인 증거는 제가 최근에 읽은 Google Research의 연구(Kim et al., "Towards a Science of Scaling Agent Systems")에서 확인할 수 있으며, 이는 매우 충격적인 데이터를 보여줍니다.

분리 가능한 (separable) 작업에서는 에이전트 간의 협업(coordination)이 성능을 최대 81%까지 향상시켰지만, 엄격하게 순차적인 (strictly sequential) 작업에서는 성능이 39%에서 70%까지 저하되었습니다. 두 그룹 간의 복잡도는 거의 동일했습니다. 또한 동일한 연구는 이러한 경우 더 나은 모델이 차이를 만들지 못한다는 점을 보여줍니다. 단일 에이전트가 더 유능할수록 협업이 보완할 여지가 줄어들기 때문에, 멀티 에이전트 (multi-agent) 방식이 가치를 발휘하기 위한 기준점은 시간이 갈수록 높아지며, 그 반대가 아닙니다. 서브 에이전트 (subagent)의 역할은 프로세스를 격리하는 것처럼 컨텍스트 (context)를 격리하는 것이지, 역할에 인격을 부여하는 것이 아닙니다.

가치가 있는지 확인하는 방법 (그리고 거짓말을 하는 지표)

이제 팀 내 AI 활용에 관한 현재 담론에서 제가 가장 불편함을 느끼는 부분이자, 가장 직설적으로 말하고 싶은 부분에 도달했습니다.

가장 자주 등장하는 지표는 "AI가 생성한 코드의 비율"입니다. 이 지표는 추출하기 쉽고 빠르게 증가하기 때문에 매력적으로 보입니다. 하지만 이는 잘못된 것을 측정하고 있습니다. 생성된 코드의 양은 전달된 가치가 아니며, 오히려 그 반대일 수도 있습니다. 즉, 검토하고 유지 관리하며 디버깅해야 할 코드만 늘어날 수 있다는 것입니다. 이 지표를 최적화하는 것은 생산적인 것처럼 보이도록 최적화하는 것에 불과합니다.

정작 측정해야 할 것은 품질을 저하시키지 않으면서 작업이 더 빠르게 진행되는지 여부입니다. 여기서 흥미로운 방법론적 이점이 있습니다. 팀 내 AI 도입은 점진적이고 자발적으로 이루어지기 때문에, 동일한 기간 내에 자연스럽게 AI를 사용하여 수행한 요구사항과 AI 없이 수행한 요구사항이 공존하게 됩니다. 이는 검증하기 쉬운 비교 그룹이 됩니다. 동일한 시간 간격 내에서 "AI 사용"과 "AI 미사용"을 비교하는 것은 "이전"과 "이후"를 비교하는 것보다 훨씬 더 신뢰할 수 있습니다. 왜냐하면 팀 구성, 제품 단계, 마감 압박과 같이 시간이 흐름에 따라 변하는 변수들을 제거할 수 있기 때문입니다.

이것이 작동하기 위해서는 AI를 거친 요구사항과 그렇지 않은 요구사항을 구분하는 표시(marking)만 있으면 됩니다. 이러한 분리를 통해 여러분이 이미 수집하고 있을 가능성이 높은 지표들이 하나의 이야기를 들려주기 시작할 것입니다: 요구사항의 시작부터 종료까지 걸린 시간, 기간별 인도량, 리뷰에 소요된 시간, 버그를 발생시킨 카드(cards) 등 말입니다.

제가 주의해야 한다고 생각하는 점은 속도(velocity)만을 단독으로 측정해서는 안 된다는 것입니다. 품질이 없는 속도는 문제를 더 빨리 전달하는 것일 뿐입니다. 제가 이 점을 계속 강조하는 데에는 이유가 있습니다. 품질은 매우 필수적입니다. 모든 시간 관련 지표는 품질 지표와 짝을 이루어야 합니다: 해당 요구사항이 얼마나 많은 재작업(rework)을 발생시켰는지, 프로덕션(production)에 배포된 후 얼마나 많은 버그가 나타났는지와 같은 지표 말입니다.

이것은 무엇이며, 무엇이 아닌가

이 모든 것이 보장된 변화를 의미하는 것은 아닙니다. 이것은 하나의 경로이며, 단계별로 나아가는 경로입니다.
저는 여러분에게 팔 수 있는 숫자를 가지고 있지 않습니다. 대신 저는 에이전트(agent)를 모델보다는 하네스(harness)로 취급하고, 프롬프트(prompt)가 아닌 인프라(infra)에 투자하며, 검증이 있는 곳에는 자율성을 부여하고 검증이 없는 곳에는 검증 체계를 구축하며, 읽기는 병렬화(parallelize)하고 결정은 직렬화(serialize)하고, 무엇보다 중요한 것을 현실적인 방식으로 측정하는 방식으로 문제에 대해 사고하는 방법을 가지고 있습니다. 열정은 넘치고 회의론은 부족한 이 주제에서, 아마도 이 마지막 부분이 가장 유용할 것입니다.