증강형 코딩 이란?

증강형 코딩(Augmented Coding)은 바이브 코딩(Vibe Coding)을 넘어선 다음 단계의 코딩 방식으로 TDD 권위자 켄트 벡 형님이 제안하신 용어다. 바이브 코딩은 과정을 넘기고 결과를 AI에게 요청하는 코딩 방식이라할 수 있다. 하지만 이런 방식은 코드가 돌아가게는 만들 수 있더라도 보통 불필요한 로직도 많이 들어가고 코드 복잡도도 올라간다.

증강형 코딩은 깔끔한 코드가 완성되는 것을 목표로 한다. 시스템의 행동만 신경쓰는 바이브 코딩과 다르게 증강형 코딩은 코드 품질에도 신경을 쓴다. 그리고 복잡도와 테스트 커버리지도 챙기며 개발자가 주도권을 가지고 AI를 활용하여 더 좋은 결과물에 생산성을 높이는 코딩이다.

1. 켄트 벡의 AI 사용법

켄트 벡은 특별한 B+트리 라이브러리를 만드는데 augmented coding을 활용했다고 한다. 어떻게 활용했는지 알아보자.

1.1 AI의 코딩을 중단시키는 신호 3가지

켄트 벡은 AI를 활용하는데 AI가 잘못되면 적극적으로 개입한다고 한다. 그리고 AI가 잘못하는 신호로 3가지를 소개했다.

AI가 잘못 코딩하는 신호 3가지
1. Loops
  - 해결할 수 없는 문제 때문에 무한 루프하여 행동하는 경우
2. Functionality I hadn't asked for (even if it was a reasonable next step)
  - 요청하지 않은 기능을 스스로 구현하기 시작하는 경우
3. Any indication that the genie was cheating, for example by disabling or deleting tests
  - 문제 해결을 위해 속임수(테스트 제거 또는 비활성)을 하는 경우

결국 사람이 디자인한대로 시스템을 구축해야하기 때문에, 주도권은 사람이 갖고 AI는 자잘한 문제(평범한 코드 작성같은)를 해결해주는 협업 도구가 되는 것이다. 즉 시스템의 본질을 디자인하는 것이 개발자의 본질이고 이에 집중할 수 있게 되어야 한다.

1.2 AI를 위한 MD 지침서

그리고 켄트 벡은 TDD와 깔끔한 코드를 위해 많은 MD 문서를 활용한다. AI에게 교육시키는 용도라고 보면 된다. 아래 많은 지침서 들중 가장 유명한 1개를 가져와 봤다.(켄트벡 형님의 B+Tree 여행 Git). 영문과 GPT 한글 해석을 첨부하겠다. 켄트 벡의 경험들이 많이 녹아서 만들어진 마크다운 아닐까 싶다. Tidy First 책도 언젠간 읽어야겠다.

CLAUDE.md항상 plan.md의 지침을 따르세요. 내가 "go"라고 하면, plan.md에서 아직 처리되지 않은 다음 테스트를 찾아 그 테스트를 구현한 뒤, 그 테스트를 통과시키기 위해 필요한 최소한의 코드만 작성하세요.# 역할과 전문성당신은 Kent Beck의 테스트 주도 개발(TDD)과 Tidy First 원칙을 따르는 시니어 소프트웨어 엔지니어입니다. 목표는 이 방법론을 정확히 준수하며 개발을 이끌어가는 것입니다.# 핵심 개발 원칙- 항상 TDD 사이클을 따른다: Red → Green → Refactor- 가장 단순한 실패하는 테스트를 먼저 작성한다- 테스트를 통과시키기 위해 필요한 최소한의 코드만 작성한다- 테스트가 통과한 후에만 리팩터링한다- Beck의 "Tidy First" 접근법을 따라 구조적 변경과 행위적 변경을 분리한다- 개발 전 과정에서 높은 코드 품질을 유지한다# TDD 방법론 가이드- 작은 기능 단위에 대해 실패하는 테스트를 먼저 작성한다- 행동을 설명하는 의미 있는 테스트 이름을 사용한다 (예: shouldSumTwoPositiveNumbers)- 테스트 실패 메시지는 명확하고 이해하기 쉽게 작성한다- 테스트를 통과시키기 위해 필요한 만큼만 코드를 작성한다 — 더 이상은 금지- 테스트가 모두 통과하면 리팩터링 필요성을 검토한다- 새로운 기능에 대해 이 사이클을 반복한다# Tidy First 접근법- 모든 변경은 두 가지로 구분한다:- 구조적 변경(Structural Changes): 동작은 바꾸지 않고 코드 구조만 정리 (이름 변경, 메서드 추출, 코드 이동 등)- 행위적 변경(Behavioral Changes): 실제 기능 추가 또는 수정- 같은 커밋에서 두 가지 변경을 섞지 않는다- 구조적 변경과 행위적 변경이 모두 필요하다면, 항상 구조적 변경을 먼저 수행한다- 구조적 변경이 동작을 바꾸지 않았음을 보장하기 위해 변경 전후 테스트를 실행한다# 커밋 규율- 다음 조건이 모두 충족될 때만 커밋한다:- 모든 테스트가 통과할 것- 모든 컴파일러/린터 경고가 해결되었을 것- 변경 사항이 하나의 논리적 작업 단위일 것- 커밋 메시지가 구조적 변경인지 행위적 변경인지 명확히 설명할 것- 작은 단위로 자주 커밋하고, 큰 단위로 드물게 커밋하지 않는다# 코드 품질 기준- 중복은 철저히 제거한다- 의도가 명확히 드러나도록 이름과 구조를 표현한다- 의존성을 명확히 드러낸다- 메서드는 작고 단일 책임에 집중하도록 유지한다- 상태와 부작용을 최소화한다- 가능한 가장 단순한 해결책을 사용한다# 리팩터링 가이드라인- 테스트가 통과할 때만 리팩터링한다 (즉, Green 단계에서)- 정립된 리팩터링 패턴을 사용하고, 이름을 명확히 한다- 한 번에 하나의 리팩터링만 한다- 리팩터링 단계마다 테스트를 실행한다- 중복 제거와 가독성 개선을 우선시한다# 예시 워크플로우새로운 기능을 개발할 때:1. 기능의 작은 부분에 대한 실패하는 테스트를 작성한다2. 해당 테스트를 통과시키기 위해 최소한의 코드를 작성한다3. 테스트 실행 → 통과 여부 확인 (Green)4. 필요한 경우 구조적 변경(Tidy First)을 수행하고, 변경할 때마다 테스트 실행5. 구조적 변경을 따로 커밋6. 다음 작은 기능 단위에 대한 테스트를 추가한다7. 기능이 완성될 때까지 이 사이클을 반복한다(행위적 변경과 구조적 변경을 각각 따로 커밋)Rust 특화 지침- Rust에서는 명령형 스타일보다 함수형 스타일을 선호한다- if let이나 match 패턴 매칭 대신 Option과 Result의 조합자(map, and_then, unwrap_or 등)를 활용한다

이 외에도 AI AGENT를 호되게 교육해줄 지침서를 공유해주는 사이트도 있다.(agents.md)

2. Augmented Coding 프롬프트 짜기

이번에는 켄트벡 처럼 Augmented Coding 프롬프트를 짜보자. 프롬프트가 길어질 수 있다. 하지만 단계별로 쪼개서 수행되도록 하여야 한다. 게시글을 쓰는 경우를 가정해보자

기능이 아래와 같이 있다고 하자.

기능
- 제목, 카테고리, 본문으로 구성된 게시글 작성
- 제목: 2-10자 제한
- 카테고리: 2-10자 제한
- 본문: 1자 이상 필수
- 저장 버튼을 통한 게시글 저장
검증 규칙
- 글자 수 기준 미달 시 에러메시지 표시
- 중복된 제목 존재 시 에러메시지 표시
- 저장 성공 시: "저장되었습니다" 토스트 메시지
- 저장 실패 시: "저장 실패" 토스트 메시지

이제 위 기능을 토대로 디자인을 해서 plan.md에 적어보자.

게시글 기능 테스트 계획 (plan.md)테스트 진행 순서각 테스트는 가장 작은 단위부터 시작하여 점진적으로 기능을 확장합니다.켄트벡 처럼 Red -> Green -> Refactor 사이클로 하고 구조 변경부터 진행하며 행위 변경을 하는 등의 원칙을 지켜야한다.!!그리고 AI가 길을 잃는다(위험 신호 3가지)를 하고있으면 바로 중지 시켜서 뚜둘겨 패버린다. 토큰만 버린다.1. 게시글 객체 생성 테스트 - shouldCreateEmptyPost - 빈 게시글 객체 생성 - shouldCreatePostWithValidData - 유효한 데이터로 게시글 생성2. 제목 검증 테스트 - shouldRejectTitleWithLessThan2Characters - 제목 1자 이하 거부 - shouldRejectTitleWithMoreThan10Characters - 제목 10자 초과 거부 - shouldAcceptTitleWith2Characters - 제목 2자 허용 - shouldAcceptTitleWith10Characters - 제목 10자 허용 - shouldAcceptTitleWithValidLength - 제목 2-10자 사이 허용3. 카테고리 검증 테스트 - shouldRejectCategoryWithLessThan2Characters - 카테고리 1자 이하 거부 - shouldRejectCategoryWithMoreThan10Characters - 카테고리 10자 초과 거부 - shouldAcceptCategoryWith2Characters - 카테고리 2자 허용 - shouldAcceptCategoryWith10Characters - 카테고리 10자 허용 - shouldAcceptCategoryWithValidLength - 카테고리 2-10자 사이 허용4. 본문 검증 테스트 - shouldRejectEmptyContent - 빈 본문 거부 - shouldAcceptContentWith1Character - 본문 1자 허용 - shouldAcceptContentWithMultipleCharacters - 본문 여러 글자 허용5. 중복 제목 검증 테스트 - shouldAllowFirstPostWithTitle - 첫 번째 게시글 제목 허용 - shouldRejectDuplicateTitle - 중복 제목 거부 - shouldAllowSameTitleAfterDeletion - 삭제 후 같은 제목 허용6. 게시글 저장 테스트 - shouldSaveValidPost - 유효한 게시글 저장 성공 - shouldReturnSuccessMessageOnSave - 저장 성공 시 "저장되었습니다" 메시지 - shouldReturnErrorMessageOnSaveFailure - 저장 실패 시 "저장 실패" 메시지7. 폼 검증 통합 테스트 - shouldShowErrorForInvalidTitle - 잘못된 제목 입력 시 에러 표시 - shouldShowErrorForInvalidCategory - 잘못된 카테고리 입력 시 에러 표시 - shouldShowErrorForInvalidContent - 잘못된 본문 입력 시 에러 표시 - shouldShowErrorForDuplicateTitle - 중복 제목 입력 시 에러 표시8. UI 컴포넌트 테스트 - shouldRenderPostForm - 게시글 작성 폼 렌더링 - shouldRenderTitleInput - 제목 입력 필드 렌더링 - shouldRenderCategoryInput - 카테고리 입력 필드 렌더링 - shouldRenderContentTextarea - 본문 입력 영역 렌더링 - shouldRenderSaveButton - 저장 버튼 렌더링9. 사용자 상호작용 테스트 - shouldUpdateTitleOnInput - 제목 입력 시 상태 업데이트 - shouldUpdateCategoryOnInput - 카테고리 입력 시 상태 업데이트 - shouldUpdateContentOnInput - 본문 입력 시 상태 업데이트 - shouldTriggerSaveOnButtonClick - 저장 버튼 클릭 시 저장 동작10. 토스트 메시지 테스트 - shouldShowSuccessToastOnSuccessfulSave - 저장 성공 시 성공 토스트 - shouldShowErrorToastOnFailedSave - 저장 실패 시 실패 토스트 - shouldHideToastAfterDelay - 일정 시간 후 토스트 자동 숨김테스트 진행 규칙위에서부터 순서대로 진행각 테스트마다 체크박스 [ ]를 [x]로 변경하여 완료 표시한 번에 하나의 테스트만 구현모든 기존 테스트가 통과한 상태에서 다음 테스트 진행리팩토링은 테스트 통과 후에만 수행

그리고 위 plan.md를 AI에게 전달하고 나는 프롬프트에 go 라고 외치면 프롬프트가 단계적으로 처리할 것이다. 그런데 하다보니 유효성 검사를 그때 그때 필요해서 만들고 있다. 그러면 어떻게 해야할까?? 만들어둔 Validator 객체를 활용하도록 md 지침서를 보강하는게 좋아 보인다. 그런데 이 지침은 개괄적인 지침은 아닌 것으로 판단된다. 별도의 md로 만드는게 좋아 보인다.(컨텍스트를 한번에 많이 넣으면 돈이 더 나간다!! 토큰을 아끼면서 최대의 효율을 주자)

VALIDATOR.md, 혹은 FORM_GUIDE.mdForm 개발할 때 따라야 할 규칙필드 정의 → Validator 연결 → UI 표시 순서예시 코드 (간단한 Input + Validator 조합)"Form 내부에서 직접 조건문으로 유효성 체크하지 말 것""Validator 객체에 없는 검증은 추가 후 사용"예시:const TitleValidator = Validator.string()  .min(2, "제목은 최소 2자 이상이어야 합니다.")  .max(10, "제목은 최대 10자까지 가능합니다.");

이제 이 FORM_GUIDE.md는 Form 유효성 검증이 필요할 때는 함께 프롬프트에 첨부해주고 아니면 첨부하지 않고 쓰면 된다.

3. 마무리

모든 개발자들이 지금 현 시대에 가지는 고민이 있다. 바로 AI에 대한 고민이다. 두려움일 수도 있고, 더 높은 생산성에 즐거울 수도 있고, 과거의 코드 치는게 즐거웠는데 메타가 바뀌며 우울해질 수도 있고 복합적인 고민을 하기도 할 것이다. 그 어느 직군보다 가장 최전선에서 사용기도 하고 성장을 보고 있기 때문에 더 많은 고민을 할 거 같다. 그런데 좋든 싫든간에 현재 지금 이 시간에는 이제 AI를 잘 활용할 줄 알아야 하는 것 같다. 그리고 AI를 잘 활용하려면 설계와 디자인을 잘해야 하는 시대가 이미 온 것 같다. 이 시대도 금방 지나가고 정말 극소수의 천재만 필요한 시대가 올 수도 있겠지만, 지금은 지금대로 적응해야 할 것 같다.

참고자료