개발팀 모두가 AI를 쓰면 생기는 일 — 프롱트

한 줄 요약

팀 전원이 AI 에이전트로 개발할 때 실제로 벌어지는 변화(리뷰 병목·구성원별 방식 편차·중복 코드 증가)를 짚고, 표준을 위에서 강제하는 대신 사례 공유 문화·최소 규칙·검증 항목 합의·솔직한 PR·작업 로그로 통일성을 만드는 방법을 제안한다.

영상 메타

픽업

  • 팀 개발 속도가 빨라져 PR이 매우 빨리 올라오는 대신 리뷰가 병목이 된다. PR은 쌓이는데 검증은 해야 하니, 검증에 에이전트를 쓸까 그 에이전트를 또 검증할 에이전트를 쓸까 하는 상황까지 간다.
  • 같은 팀 안에서도 방식이 갈린다 — 누구는 병렬 에이전트, 누구는 설계 단계에서만, 누구는 라인 바이 라인. 팀 단위 양극화가 보이는데, 팀 플레이가 좋은 팀은 에이전트로 호랑이가 날개를 단 격이 되고 반대 상황도 있다. 프론트 개발자가 API를, 백엔드 개발자가 UI를 만들기도 한다.
  • 코드 품질은 모델 발전으로 상향 평준화되지만 중복 코드가 늘어난다는 보고가 있다. 어제 만든 소스가 오늘은 어떤 에이전트를 쓰느냐에 따라 다르게 나와 들쑥날쑥해진다 — 유지보수 관점에서 좋지 않다.
  • 표준을 정하기보다 공유하는 문화를 먼저 만드는 것이 중요하다. 상황마다 해결책이 다르니 사례를 공유하고, 측정하고, 회고하고, “우리 팀이 이걸 도입해 볼까” 하는 사이클을 돌린다. 그럴싸한 TF를 만들어 워크플로를 정해도 한 달 뒤 새 도구·기능이 나오면 물거품이 되는 경우가 있다.
  • 규칙은 최소한으로 두되 엄격히 적는다. 복잡한 규칙은 지키기 어렵고 에이전트·도메인마다 다르다. 제1원칙을 잘 정리하고, 그 원칙을 담은 규칙 파일(CLAUDE.md 같은 것)을 PR과 리뷰로 계속 유지보수한다.
  • 개발 방법보다 검증 항목을 맞추는 것이 핵심이다. 사람이 체크할 것 — 정확성, 기본 규칙 준수, 보안, 테스트 통과 — 만 팀이 합의해 두면 각자 에이전트를 다르게 써도 통일성이 생긴다. AI에게 맡길 범위와 사람이 꼭 확인할 부분, 테스트 커버리지 통과 기준을 미리 정해 둔다.
  • PR은 더 꼼꼼하고 솔직하게 쓴다 — 원래 목적, 그 방법을 고른 이유(개발자가 아는 선에서), AI가 구현한 부분이 무엇인지, 리뷰어가 반드시 확인할 부분. 그리고 결제·보안·코어 모듈처럼 중요한 곳은 에이전트에게 작업 로그를 남기게 해 두면 나중에 문제가 생겼을 때 원인을 찾는 자료가 된다. 화이트보드에 구조를 직접 그려 동료에게 설명하면 문제점도 발견되고 설계 능력도 길러지며, 결국 에이전트와의 소통보다 동료와의 소통이 여전히 가장 중요하다.

용어

  • 에이전트(Agent) [하니스 · 패턴]: 지시를 받아 코드를 직접 작성·수정하는 AI 실행 주체. 영상은 이를 “사람이 많아진 것”으로 보라고 말한다.
  • 병렬 에이전트 [하니스 · 패턴]: 여러 에이전트를 동시에 돌려 작업을 나눠 진행하는 방식. 같은 팀 안에서도 이 방식을 쓰는 사람과 안 쓰는 사람이 갈린다.
  • CLAUDE.md [지식 · 컨텍스트 자산]: 프로젝트의 제1원칙과 최소 규칙을 담아 에이전트가 매번 읽는 규칙 파일. 영상은 이 파일을 PR·리뷰로 계속 유지보수하라고 말한다.
  • 훅(Hook) [하니스 · 패턴]: 에이전트 작업 전후에 자동 실행되는 스크립트. 작업 로그를 자동 수집하는 수단으로 언급된다.
  • 리뷰 병목 [워크플로우 · 문화]: 코드 생성 속도가 검증 속도를 앞질러 PR이 쌓이는 현상. 에이전트 도입 팀의 대표적 첫 증상.
  • 상향 평준화 [워크플로우 · 문화]: 모델 발전으로 코드 품질의 하한이 올라가는 현상. 단 중복 코드 증가라는 부작용이 함께 보고된다.
  • 에이전트 작업 로그 [지식 · 컨텍스트 자산]: 에이전트가 무엇을 어떤 이유로 어떻게 구현했는지, 어떤 어려움이 있었는지 남기는 기록. 사후 원인 추적의 근거 자료.
  • 검증 항목 합의 [워크플로우 · 문화]: 개발 방식을 통일하는 대신 “사람이 무엇을 체크하는가”를 팀이 맞추는 접근. 방식 다양성을 허용하면서 결과의 통일성을 얻는다.