일관성 있는 Agentic AI Workflow를 팀 프로젝트에 적용하는 법
개요
코딩 에이전트가 개발의 필 수 도구가 된 지금, AI를 쓰지 않는 개발자를 찾기가 오히려 어렵다. 기업들도 이 흐름에 발맞춰 OpenAI, Claude, Gemini를 종류별로 전부 구독하며 적극적인 사용을 장려한다.
하지만 비싼 비용을 들여 AI를 구독한다고 해서 생산성이 저절로 높아지지는 않는다.
METR 리서치에 따르면 AI 코딩 도구를 사용했을 때 개발 완료 시간이 오히려 19% 증가했다는 결과도 있다. 개발자들은 20% 단축을 기대했지만, 실제로는 정반대였다.
반면, SNS에서 자주 회자되는 프로그래밍좀비라는 개발자는 AI를 활용해 350개의 앱을 개발하고 수익화에 성공했다고 한다. 중국인 개발자 EastonDev는 10,000라인 레거시 코드를 14일 만에 리팩토링하며 테스트 커버리지, 버그, 성능 지표까지 개선했다.
같은 도구를 쓰면서 왜 이런 생산성 차이가 생길까? 개인이 각자 알아서 AI를 사용하다 보면, 도구에 대한 이해도, 축적된 경험, 효과적인 활용법에 따라 결과가 천차만별이기 때문이다. AI 구독은 개인 능력의 상한선을 높여주지만, 그것이 곧 팀 전체의 생산성 향상으로 이어지지는 않는다.
이 글에서는 개인의 AI 활용 역량을 팀 전체의 역량으로 전환하는 방법을 다룬다.
LLM과 Harness의 한계
LLM의 한계는 이미 잘 알려진 내용이므로 깊이 다루지는 않겠다. 다만 트랜스포머 기반 AI에게 업무를 맡길 때 반드시 인지해야 할 본질적 한계를 짚고 넘어가보자.
1. 컨텍스트는 유한하다
아무리 컨텍스트 윈도우가 커져도, 긴 맥락이 필요한 작업에는 여전히 한계가 있다. 대규모 코드베이스 전체를 이해하거나, 수십 개 파일에 걸친 리팩토링을 한 번에 처리하기는 어렵다. 이를 해결하려면 맥락을 효과적으로 전달하는 별도의 방법을 고안해야 한다.
2. 결과물은 확률적이다
같은 프롬프트에도 매번 다른 결과가 나온다. 이는 LLM의 근본적인 생성 방식 때문이다. 창의적인 작업에서는 장점이 되지만, 일관성이 필요한 작업에서는 치명적인 단점이 된다.
3. 환각은 피할 수 없다
LLM은 자신 있는 어조로 틀린 정보를 생성한다. 코딩 맥락에서는 존재하지 않는 API를 호출하거나, deprecated된 문법을 최신인 것처럼 제안하거나, 아예 없는 라이브러리를 import하는 코드를 만들어낸다. 문제는 이런 환각이 그럴듯해 보인다는 것이다. 검증 없이 AI의 출력을 그대로 믿으면, 컴파일 에러는 그나마 다행이고 런타임에서나 확인하는 대형사고로 이어질 수 있다.
Harness: 현실적인 해결책
이러한 한계를 보완하는 여러 방법 중, 현재 가장 제품 수준의 완성도를 보여주는 것이 Harness(Tool Use 기반의 에이전트 구조)다. Claude Code, Cursor, Windsurf 같은 코딩 에이전트들이 이 방식을 채택하고 있다.
하지만 Harness에는 **유효기간**이 있다.
Bitter Lesson의 깨달음, Scaling Law는 여전히 유효하다. 어느 날 갑자기 Google이나 OpenAI의 신모델이 등장해, 팀이 공들여 구축한 Harness를 무용지물로 만들 수 있다. 실제로 예전에는 PDF에서 텍스트를 추출하려면 복잡한 파이프라인이 필요했지만, 이제는 멀티모달 모델에 이미지로 던지면 끝이다. 팀이 몇 주간 구축한 PDF 파싱 Harness가 하룻밤 사이에 레거시가 되어버리는 것이다.
그럼에도 Harness를 만들어야 하는 이유
이런 리스크에도 불구하고, 지금 당장 Harness가 제공하는 생산성 향상은 무시할 수 없다.
Harness 없이 Raw LLM만 쓰는 것과, 잘 구성된 에이전트 환경에서 작업하는 것의 생산성 격차는 이미 크게 벌어졌다. 6개월 뒤 무용지물이 될 수 있다 해도, 그 6개월간의 생산성 이득이 구축 비용을 상 회한다면 만들어야 한다.
문제는 이 Harness를 개인이 아닌 팀 전체가 일관되게 사용하도록 만드는 것이다.
개인의 AI 역량 ≠ 팀의 AI 역량
AI를 잘 쓰는 개인은 많다. 하지만 그 개인이 속한 팀이 AI를 잘 쓰는가는 전혀 다른 문제다.
팀원들에게 비싼 AI 구독을 제공한다고 해서 팀 생산성이 저절로 높아지지 않는다. 개인 단위의 AI 활용이 팀 단위의 생산성으로 전환되지 못하는 데는 구조적인 이유가 있다.
1. 인간 지능이 병목이다
AI의 코드 생산 속도는 인간의 리뷰 속도를 아득히 넘어선다. ITWorld의 분석에 따르면, 이는 "조립 라인에서 한 기계만 속도를 높이고 나머지를 그대로 두면, 공장이 빨라지는 것이 아니라 처리되지 못한 작업이 쌓여갈 뿐"인 상황과 같다. 코드는 10배 빨리 생성되는데, 리뷰는 여전히 사람이 일일이 해야 한다면 결국 인간 리뷰어가 병목이 될 수 밖에 없다.
2. 검증 체계가 없다
AI가 생성한 코드를 얼마나 신뢰할 수 있는가? 코드래빗 보고서에 따르면, AI 생성 코드는 사람이 작성한 코드보다 PR당 1.7배 더 많은 이슈를 발생시킨다. 객관적인 검증 지표와 자동화된 품질 게이트 없이는, AI 결과물에 대한 확신을 가질 수 없다.
3. 숙련도 격차가 크다
누군가는 정교한 프롬프트와 최적화된 에이전트 설정으로 높은 품질의 결과물을 뽑아내지만, 누군가는 기본적인 활용에도 어려움을 겪는다. 같은 도구, 같은 구독료를 내면서도 생산성 격차는 몇 배씩 벌어진다. 이 격차를 좁히는 것은 개인의 노력만으로는 한계가 있다.
4. 경험과 노하우가 휘발된다
가장 심각한 문제다. 비슷한 업무를 하는 팀원들이 각자 비슷한 프롬프트를 만들고, 비슷한 에이전트 구성을 시도한다. 누군가 효과적인 방법을 발견해도, 그 지식은 개인에게 머문다. 슬랙에 공유한 팁은 며칠 뒤 묻히고, 노션에 정리한 가이드는 업데이트되지 않는다. AI를 잘 쓰는 경험과 노하우가 팀에 축적되지 않고 휘발된다.
이 네 가지 문제의 공통점은 무엇인가? AI 역량을 축적하고 공유할 워크플로우의 부재다.
개인의 역량에 의존하는 한, 팀 전체의 AI 활용 수준은 들쭉날쭉할 수밖에 없다. 필요한 것은 개인의 경험이 팀의 자산으로 축적되고, 검증된 워크플로우가 모든 팀원에게 일관되게 적용되는 구조다.
AI 시대, 리더가 해야 할 일
앞으로 모든 기술 리더는 개인의 경험이 팀의 자산으로 축적되는 구조를 설계해야 한다. 이것은 비단 AI Era만 해당되는 이야기가 아니다. 다만 AI 시대에는 앞서 언급한 이 문제가 첨예해졌을 뿐이다.
리더의 역할은 적극적으로 Harness를 구축하고, 이를 팀 워크플로우에 녹여내는 것이다. 다음은 이를 위한 다섯 가지 원칙이다.
1. 워크플로우 단계별로 맥락을 분리하라
하나의 거대한 프롬프트로 모든 것을 해결하려 하지 마라. 기획 검토, 설계, 구현, 테스트, 리뷰 - 각 단계는 필요로 하는 맥락이 다르다. 단계마다 적절한 컨텍스트만 전달하면 LLM의 유한한 컨텍스트 윈도우를 효율적으로 활용할 수 있고, 결과물의 품질도 높아진다.
2. 결정적 작업(Deterministic Tasks)과 비결정적 작업(Non-Deterministic Task)을 구분하라
모든 것에 LLM을 쓸 필요는 없다.
결정적 작업은 규칙 기반으로 항상 같은 결과를 내야 하는 작업이다. 린팅, 포매팅, 정적 분석, 타입 체크, 보안 스캔이 여기에 해당한다. 이런 작업에 LLM을 쓰면 불필요한 비용과 불확실성만 늘어난다. 전통적인 도구가 더 빠르고, 더 정확하고, 더 일관적이다.
비결정적 작업은 맥락 이해와 판단이 필요한 작업이다. 여기가 LLM이 진가를 발휘하는 영역이다:
- Tidying: 변수명 개선, 불필요한 중복 제거 같은 작은 정리 작업
- Reviewing: 잠재적 버그 탐지, 성능 이슈 지적, 컨벤션 위반 발견
- 문서화: 코드 주석, README, API 문서, CHANGELOG 작성
- 테스트 생성: 단위 테스트 작성, 엣지 케이스 도출, 테스트 커버리지 확장
결정적 작업은 CI 파이프라인에 맡기고, LLM은 비결정적 작업에 집중시켜라.
3. 변경 범위를 작게 유지하라
AI가 한 번에 수천 줄을 생성할 수 있다고 해서, 매번 수천 줄을 생성해야 하는 것은 아니다. 큰 변경은 리뷰어의 인지 부하를 높이고 병목을 유발한다. 충분히 검증 가능하고, 문제가 생겨도 쉽게 롤백할 수 있는 작은 단위로 변경을 쪼개야 한다.
그렇다고 무조건 작게만 유지하라는 것은 아니다. 핵심은 인지 부하 없이 자동 검증 가능한 범위를 찾는 것이다.
Kent Beck은 Tidy First?에서 리팩토링보다 작고 린팅보다는 의미 있는 'Tidying'이라는 개념을 제안한다. 예를 들어:
- 가드 클로즈로 중첩 조건문 펼치기
- 설명하는 변수명으로 매직 넘버 대체하기
- 죽은 코드 제거하기
- 함수 순서 재배치하기
이 정도 규모의 변경은 테스트만 통과하면 별도 리뷰 없이 머지해도 된다. 워크플로우를 잘 설계하면 이런 Tidying 작업을 AI가 자동으로 수행하고, 자동으로 검증하고, 자동으로 적용하는 것이 가능하다.
4. 인간 개입을 최소화할 수 있는 워크플로우를 만들어라
병목은 결국 인간이다. AI의 생산 속도를 인간의 리뷰 속도가 따라갈 수 없다면, 인간 개입을 최소화하여 AI 결과물을 검증할 수 있는 자동화된 워크플로우가 필요하다.
일반적으로 검증 워크플로우는 계층적으로 구성된다:
1차: 결정적 검증 (CI 파이프라인)
- 린팅, 포매팅, 타입 체크 통과 여부
- 테스트 스위트 전체 통과 여부
- 보안 스캔, 의존성 취약점 검사
2차: 비결정적 검증 (AI 리뷰어)
- PR이 생성되면 리뷰어 에이전트가 변경점을 분석
- 잠재적 버그, 성능 이슈, 아키텍처 위반 탐지
- PR 변경의 핵심 포인트 요약 및 개선 제안
3차: 범위 기반 자동 승인
- Tidying 수준의 작은 변경 + 1차/2차 검증 통과 → 자동 머지
- 버저닝을 유발하는 큰 변경 → 리뷰 생성
여기서 Conventional Commits 규칙이 에이전트에게 힌트를 줄 수 있다. 커밋 메시지에 feat:, fix:, refactor:, chore:, docs: 같은 타입과 !(breaking change) 표시를 강제하면, AI가 변경의 성격과 영향 범위를 명확히 판단할 수 있다.
chore: 미사용 import 제거 → 자동 머지 가능
refactor: 결제 로직 함수 분리 → AI 리뷰 후 자동 머지
feat!: 인증 API 응답 구조 변경 → 별도의 리뷰 프로세스 필요
이렇게 구성하면 버저닝을 유발하는 큰 변경이 아닌 chore, style, docs, refactor 수준의 변경은 1차/2차 검증만 통과하면 리뷰어 에이전트가 직접 머지할 수 있다. feat!, fix! 같은 breaking change나 feat 같은 의미 있는 변경만 별도의 리뷰 프로세스를 도입하면 된다.
이 워크플로우의 수준이 높아져서 다소 큰 변경마저도 리뷰 에이전트가 인간 지능 개입 없이 머지가능한 수준으로 고도화된다면 결국 대부분의 변경이 인간 개입 없이 자동으로 처리되고, 이 팀/프로젝트의 생산성은 큰 변곡점을 맞게 될 것이다.
5. 모든 개선이 팀의 자산으로 축적되게 하라
이것이 가장 중요하다.
AI 도입은 "좋은 도구를 사주면 끝나는" 문제가 아니다. 2025 DORA 리포트는 성공적인 AI 도입을 툴 문제가 아니라 시스템 문제로 정의하며, AI의 가치는 도구 그 자체보다 주변의 기술·문화적 환경에 Lock-in 된다고 말한다.
누군가 효과적인 프롬프트를 발견했다면, 그 프롬프트는 휘발되지 않고 팀 전체가 쓰는 도구에 반영되어야 한다. 누군가 실수를 방지하는 워크플로우를 만들었다면, 그 워크플로우는 개인의 습관이 아니라 팀의 시스템으로 자리 잡아야 한다.
개인이 발견한 베스트 프랙티스가 → 팀의 표준 워크플로우가 되고 → 버전 관리되며 → 지속적으로 개선되는 구조.
이 구조가 작동하려면, 조직은 명확하고 공유된 AI 스탠스(정책/기대치/허용 도구/적용 범위) 를 가져야 한다. DORA 리포트는 AI 도입의 긍정적 효과가 이런 "clear and communicated AI stance"의 존재에 의존하며, 이것이 있을 때 개인 효과와 조직 성과의 긍정적 영향이 증폭된다고 제시한다.
이것을 가능하게 하는 것이 AI 시대 리더십의 핵심 역할이다.
다음 편에서는 이 원칙들을 Claude Code의 Skills, Hooks, Plugins로 구현하는 구체적인 방법을 살펴보겠다.