본문으로 건너뛰기

8부: 팀 표준으로 만들기

앞선 일곱 부분의 내용은 개발자 한 명에게 효과적입니다. 팀이 개입되는 순간, 추가적인 실패 양상이 나타납니다: 하네스가 표류합니다. 한 사람의 규칙 파일은 한 가지를 말하고, 다른 사람의 것은 다른 무언가를 말하며, 에이전트 동작은 팀 전체에서 재현 불가능해지고, 규율은 조용히 무너집니다. 이 부분은 워크플로를 공유되고 지속적인 표준으로 만드는 것에 관한 내용입니다.

염두에 두어야 할 근본 원칙: AI는 자신이 놓인 엔지니어링 문화를 증폭시킵니다. 탄탄한 테스트, 명확한 표준, 건전한 리뷰를 갖춘 팀은 이 도구들로부터 극적으로 더 많은 것을 얻습니다. 그것이 없는 팀은 문제를 더 빠르게 만들어냅니다. 표준화의 목적은 좋은 문화를 최소 저항 경로로 만드는 것입니다.

하네스를 코드처럼 다루십시오​

규칙 파일, 시스템 프롬프트, 평가 스위트, 스킬 라이브러리는 개인 설정이 아닙니다 — 공유 인프라입니다. 코드와 동일하게 다루십시오:

  • 프로젝트와 함께 버전 관리하십시오.
  • 다른 변경 사항과 마찬가지로 풀 리퀘스트에서 리뷰하십시오.
  • 지정된 담당자를 배정하여 방치되지 않고 의도적으로 유지 관리되도록 하십시오.

이 없이는 각 개발자의 에이전트가 미묘하게 다르게 동작하고 누구도 다른 사람의 결과를 재현할 수 없습니다.

데모가 아닌 평가로 게이팅하십시오​

동작하는 데모는 에이전트가 한 번 성공할 수 있음을 증명합니다. 통과하는 평가 스위트는 안정적으로 성공함을 증명합니다. 이 둘은 같지 않으며, 데모의 성공에 기반하여 배포하는 것은 불안정한 에이전트가 프로덕션에 도달하는 경로입니다.

서비스를 테스트 커버리지로 게이팅하는 것과 마찬가지로, 평가 커버리지를 배포의 전제 조건으로 만드십시오. 그러나 명확한 채점 기준이 없는 평가는 아무것도 측정하지 못합니다 — 따라서 무엇을 채점할지 정의하십시오:

  • 태스크 성공률
  • 도구 사용 품질
  • 실행 경로 준수
  • 환각 발생률
  • 응답 품질

CI 게이트가 이를 실질적으로 만듭니다:

# ci: block merge if the agent's eval suite regresses
agent-evals:
  run: eval-suite --rubric rubric.yaml --min-score 0.9
  on: [pull_request]
  required: true

생성된 코드에 맞게 코드 리뷰를 재정비하십시오​

생성된 코드는 사람이 작성한 코드와 동일한 수준 이상의 면밀한 검토가 필요하며 — 리뷰어들은 그 특유의 실패 양상을 알아야 합니다. 환각된 의존성, 얕은 에러 처리, 얼핏 보기에는 문제없어 보이는 정확성 결함을 찾도록 훈련시키십시오 (5부). 기존의 사람 코드 체크리스트를 그대로 재사용하는 대신 해당 패턴에 맞게 리뷰 체크리스트를 조정하십시오.

프로토타입/프로덕션 경계를 명시적으로 그으십시오​

빠르고 자유로운 탐색과 엄격한 프로덕션 작업은 모두 유효합니다 — 단, 모두가 어느 쪽인지 알 때만. 경계를 명시적으로 만드십시오:

  • 어떤 레포지토리가 프로덕션이고 어떤 것이 샌드박스인지.
  • 어떤 브랜치에 전체 규율이 필요한지.
  • 에이전트의 출력이 어떤 환경에 도달할 수 있는지.

이 경계를 모호하게 두는 팀은 실수로 배포되는 프로토타입을 만들어냅니다. 명문화된 경계는 탐색을 빠르게 유지하면서 동시에 프로덕션을 안전하게 유지합니다.

하네스는 한 번 구축하고 여러 번 개선하십시오​

재사용 가능한 프롬프트, 스킬 라이브러리, 도구 연결, 평가 하네스는 프로젝트 전반에 걸쳐 복리로 축적됩니다. AI 개발에서 가장 많은 것을 얻는 팀은 이 공유 하네스를 한 번 구축하고 계속 개선하는 팀입니다 — 각자가 처음부터 자신의 것을 재구축하는 것이 아닙니다. 인프라로 취급하십시오: 문서화되고, 유지 관리되며, 의도적으로 개선됩니다.

판단력을 갖춘 인재를 채용하고 승진시키십시오​

구현이 저렴해질수록 병목은 명세, 평가, 아키텍처적 판단으로 이동합니다. 향후 몇 년간 가장 가치 있는 엔지니어는 에이전트를 잘 지휘할 수 있는 사람입니다 — 코드를 가장 많이 타이핑할 수 있는 사람이 아닙니다. 채용, 레벨링, 인재 개발 방식에 이를 반영하십시오: 명세 역량, 평가 엄밀성, 시스템 설계를 단순한 구현 속도보다 중시하십시오.

가장 강력한 설정은 설계상 하이브리드입니다: 인간이 방향을 설정하고, 에이전트가 구현하며, 명확한 인계 프로토콜이 경계를 관장합니다. 코드 리뷰, 온콜, 팀 구조 모두 에이전트를 단순한 도구가 아닌 참여자로 대하도록 진화합니다.

나만의 워크플로를 설정하십시오​

  • 규칙 파일, 프롬프트, 평가, 스킬을 레포지토리로 이동시키고 변경 사항에 PR 리뷰를 요구하십시오.
  • 공유 하네스의 담당자를 지정하십시오.
  • 평가 스위트가 임계값 이하로 회귀할 때 병합을 차단하는 CI 게이트를 추가하십시오.
  • 생성된 코드의 실패 양상에 대한 한 페이지 리뷰 가이드를 작성하십시오.
  • 프로토타입 대 프로덕션 경계를 문서화하십시오: 레포지토리, 브랜치, 환경.
  • 다음 채용 과정에서 코딩 테스트만이 아니라 명세 및 평가 실습을 추가하십시오.

출처: The New SDLC With Vibe Coding (Google) — https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding