증강 코딩 운영 기록

이 문서는 증강 코딩을 개인 실험에서 팀 운영으로 확장한 과정을 정리한 기록이다. 핵심은 AI 전면 위임이 아니라, 사람의 의도와 검증 루프를 기준으로 작업을 운영하는 방식이다.

1) 시작점

처음에는 바이브 코딩과 AI 전면 위임 방식에 회의적이었다. 명령을 바꿔도 결과물이 반복해서 마음에 들지 않았고, 코드 품질도 애매했다. 무엇보다 그 결과가 실제 우리 업무 맥락에 맞는지 확신하기 어려웠다. 돌이켜보면 그 시기에는 기대를 과하게 두고 AI에게 한 번에 너무 많은 것을 요구한 측면도 있었다.

이후 Kent Beck의 증강 코딩 관점을 보고 방향을 바꿨다. 코드 품질을 중요하게 보던 사람이 AI를 적극적으로 쓰되, 자기 방식으로 번역해서 운영하는 점이 크게 와닿았다. 그때부터 "전면 위임"이 아니라 "사람이 설계하고 AI가 작성한다"는 기준으로 접근했다.

그래서 팀 적용 전에 개인 프로젝트에서 약 2주간 먼저 검증했다.

검증 과정에서 확인한 내용은 다음과 같다.

  • 티켓 기반 구조를 쓰면 재현성이 올라간다.
  • 테스트 루프를 강제하면 속도와 안정성을 동시에 확보할 수 있다.
  • 프롬프트 감각보다 작업 순서와 검증 구조가 결과에 더 큰 영향을 준다.

이 결과를 바탕으로 팀 적용을 시작했다.

2) 팀 적용 방식

현재 팀에서 쓰는 기본 흐름은 다음과 같다.

  1. Jira 티켓을 읽고 plan.md를 만든다.
  2. plan.md 기준으로 구현을 진행한다.
  3. 테스트 통과를 기준으로 수정 루프를 반복한다.
  4. PR 생성 후 리뷰 단계로 이동한다.

초기에는 개인 사용 중심이었지만, 효과가 확인되면서 팀원 사용이 늘어났다. 운영 원칙은 바이브 코딩이 아니라 테스트 기반 실행이다.

관측된 변화는 다음과 같다.

  • 작업 안정성 향상
  • 구현/검증 속도 개선
  • 리뷰 이전 단계 품질 편차 감소

3) 운영 방식이 바뀐 지점

처음부터 “하네스”라는 단어를 쓰고 시작한 것은 아니었다. 하지만 운영을 쌓으면서 현재 방식이 하네스 구조로 정리됐다.

현재 사용 중인 스킬은 다음과 같다.

  • jira-to-plan
  • augmented-coding
  • push-pr
  • review

그리고 위 스킬을 work 스킬로 통합해서 사용하고 있다.

현재 구조는 다음처럼 역할이 나뉜다.

  • 사람: 목표/제약/완료 기준을 정의
  • AI: 구현/수정/반복 실행
  • 리뷰: 자동 리뷰 + 사람 판단 결합

팀에서 실제로 바뀐 행동은 분명했다. AI를 "도구"가 아니라 "작업자"로 두고, 작업자로서의 의무(보고/수정/반복)를 수행하도록 의도해서 운영하기 시작했다.

결국 포인트는 개인 요령이 아니라, 팀 기준으로 운영 규칙을 잡아가는 데 있었다.

4) 사람이 판단하는 영역과 자동화 경계

전면 자동화는 목표가 아니다. 사람이 직접 판단해야 하는 영역은 유지한다.

  • 도메인 정책 적합성
  • 업무 요구사항 충족 여부
  • 장기 유지보수 관점의 가독성/구조 판단
  • 코드리뷰 최종 판단

현재 기준에서 자동화 우선순위는 아래와 같다.

  • Jira 티켓 읽기 및 작업 시작
  • Planning 기준의 PRD 초안/Story/Task 분해
  • 반복 구현/테스트 루프 실행

운영 원칙은 간단하다. 자동화는 실행량을 늘리는 데 쓰고, 사람은 직접 봐야 하는 판단에 집중한다.

5) kancli 개발 배경

병렬 작업이 늘어나면서 운영 UI가 병목이 되었다. 여러 터미널을 분산해서 관리하는 방식은 집중 저하와 관리 비용 증가를 만들었다.

이 문제를 줄이기 위해 단일 터미널에서 칸반 방식으로 상태를 관리하는 CLI를 개발 중이다.

목표는 다음 세 가지다.

  • 작업 상태를 한 화면에서 관리
  • 컨텍스트 스위칭 비용 감소
  • 병렬 작업 운영 가시성 개선

6) 현재 팀 이슈

최근 기준으로 팀 병목은 "리뷰 속도"보다 "리뷰 품질"에 더 가깝다.

현재 자동 리뷰(CodeRabbit + /review)를 적용해도 남는 이슈는 다음이다.

  • 도메인 적합성 판단
  • 요구사항 누락/해석 오류 검증

이 문제의 상당수는 Jira 티켓 자체가 부정확하거나 누락된 상태에서 시작될 때 발생한다.

질문 escalation 포맷은 아직 팀 표준이 없다. 이 항목은 운영하면서 별도 규격화가 필요하다.

7) 현재 결론

현재까지 정리된 결론은 아래와 같다.

  • 증강 코딩 성과는 모델 선택보다 운영 설계에서 갈린다.
  • 개인 프롬프트 실력보다 팀 하네스가 결과를 안정화한다.
  • “많이 생성”보다 “의도-검증 루프” 품질이 중요하다.

아직 완성형은 아니다. 다만 여기까지 운영해본 결과, 도구 자체보다 팀 운영 방식이 결과를 더 크게 좌우한다는 점은 확인했다.