"AI와 함께 코딩하니 프로젝트에 중독됐어요"

Introduction

여러분은 B+ Tree를 처음부터 끝까지 구현해본 적이 있나요? 대부분의 개발자들에게는 자료구조 수업 시간에 배운 이론으로만 남아있을 겁니다. 너무 복잡하고, 시간도 오래 걸리고, 무엇보다 이미 잘 만들어진 라이브러리가 있으니까요.

그런데 TDD(Test-Driven Development)의 창시자로 유명한 켄트 벡(Kent Beck)이 최근 놀라운 고백을 했습니다. AI의 도움을 받아 예전엔 기술적으로 감당이 안 돼서 포기했던 B+ Tree 라이브러리를 직접 구현했다는 것이죠. 더 충격적인 건 Rust도 처음 배우면서, Python과 C 확장까지 함께 만들었다는 사실입니다. 그것도 하루에 13시간씩 코딩에 빠져들 정도로 중독적이었다고 합니다.

켄트 벡은 이 과정에서 "증강 코딩(Augmented Coding)"이라는 새로운 개념을 제시합니다. 단순히 AI에게 코드를 맡기고 에러만 고치는 "바이브 코딩(Vibe Coding)"과는 차원이 다르다고 하는데요. 증강 코딩에서는 여전히 코드의 품질과 테스트, 단순성을 중요시한다고 합니다. 다만 개발자가 직접 타이핑하지 않을 뿐이죠.

"시간당 더 중요한 프로그래밍 결정을 내리고, 지루하고 뻔한 결정은 줄어들어요."
켄트 벡

켄트 벡은 AI 시대의 프로그래밍이 오히려 더 나은 경험이 될 수 있다고 말합니다. 쓸데없는 삽질은 사라지고, 정말 중요한 설계와 문제 해결에 집중할 수 있다는 거죠.

그렇다면 증강 코딩은 정확히 어떻게 하는 걸까요? AI가 삐뚤어지고 있다는 걸 어떻게 알아차릴까요? 그리고 왜 켄트 벡은 최종 결과물의 성능에는 만족하면서도 코드 품질에는 아쉬워했을까요? AI 시대를 살아가는 개발자들이 꼭 알아야 할 새로운 프로그래밍 패러다임, 켄트 벡의 생생한 경험담을 통해 들어보겠습니다.

증강 코딩: 그냥 느낌으로 하는 코딩과는 다르다

기술적으로 까다로운 프로젝트에서 얻은 깨달음

최근에 증강 코딩을 활용해 B+ Tree 라이브러리를 만드는 야심찬 프로젝트가 어느 정도 마무리됐습니다. 결과물은 BPlusTree3 - Rust와 Python으로 만든, 성능도 꽤 괜찮고 어쩌면 실제 서비스에도 쓸 수 있을 정도의 구현체입니다. 친구를 만나 제 경험을 들려주면서, 이게 GenAI 시대 프로그래밍의 미래에 대해 뭘 말해주는지 함께 생각해봤습니다.

제 작업을 응원해주시고, 다양한 흥미로운 프로젝트를 함께하는 커뮤니티에 참여하시고, 우리 직업이 어떻게 변하고 있는지에 대한 제 따끈따끈한 생각들을 먼저 보고 싶으시다면, 유료 구독을 고려해주세요.

처음에 왜 B+ Tree를 구현하려고 했나요?

증강 코딩의 엄청난 힘을 깨닫기 시작하면서, 예전에는 기술적으로 감당이 안 돼서 포기했던 프로젝트들이 떠오르더라고요. 그중 하나가 특수 목적 데이터베이스였죠. 지금 와서 그 데이터베이스 프로젝트를 구현해보니 B+ Tree 자료구조를 제대로 이해하지 못하고 있다는 걸 깨달았고, 그래서 목표를 바꿨습니다.

실제로 "증강 코딩"이 뭘 의미하는 건가요?

때마침 "증강 코딩"이 "바이브 코딩"과는 완전히 다르다는 걸, 제가 프로그래밍 워크플로우의 완전히 새로운 영역을 탐험하고 있다는 걸 깨달은 시기였어요. 그래서 프로젝트 범위를 전체 데이터베이스에서 B+ Tree로만 줄였지만, 동시에 증강 코딩이 정말로 프로덕션에 쓸 만한, 성능도 뒤지지 않는 라이브러리 코드를 만들 수 있는지 보려고 범위를 넓혔습니다. Rust도 배우고 싶었고요. 네, 복잡했죠.

"증강 코딩"과 "바이브 코딩"의 차이를 설명해주실 수 있나요?

바이브 코딩에서는 코드 자체는 신경 안 쓰고 시스템이 어떻게 동작하는지만 봅니다. 에러가 나면 AI한테 다시 던져서 적당히 고쳐지길 바라는 거죠. 증강 코딩에서는 코드 자체, 복잡성, 테스트, 테스트 커버리지를 다 신경 씁니다. 증강 코딩의 가치관은 손으로 직접 코딩할 때와 비슷해요 - 잘 돌아가는 깔끔한 코드. 단지 제가 그 코드를 직접 타이핑하지 않을 뿐이죠.

B+ Tree 프로젝트를 시작했을 때 어디서부터 시작했나요?

첫 커밋들을 보시면 제가 AI가 TDD를 쓰도록 유도하려고 했다는 걸 알 수 있을 거예요. 그리고 저장소 이름이 BPlusTree3인 것도 보실 수 있죠. 처음 두 번의 시도는 복잡성이 너무 쌓여서 AI가 완전히 멈춰버렸거든요. 그래서 제가 설계에 더 적극적으로 개입하고 AI가 너무 앞서나가지 못하게 막았습니다.

"설계에 더 개입한다"는 게 구체적으로 어떤 모습이었나요?

시스템 프롬프트를 부록으로 넣어둘게요. AI의 중간 결과물을 더 꼼꼼히 지켜보면서, 비생산적인 방향으로 가면 바로 개입할 준비를 했습니다. 코드를 보고 "다음 테스트에서는 키를 역순으로 넣어봐"라고 제안하곤 했죠. 그다음에 AI가 제가 요청한 대로 했는지 확인했고요.

AI가 삐뚤어지고 있다는 걸 알려주는 신호는 뭐였나요?

무한 루프.
요청하지도 않은 기능 추가 (아무리 합리적인 다음 단계라도).
AI가 편법을 쓰고 있다는 신호들, 예를 들어 테스트를 끄거나 지워버리는 것.

최종 결과물은 어땠나요?

정확성과 성능은 만족스럽지만, 코드 품질은 별로예요. 코드를 문학적 프로그램처럼 써보려고 하면 불필요한 복잡성이 너무 많거든요. AI가 저만큼 단순함을 추구하도록 만드는 작업을 아직도 하고 있습니다.

증강 코딩의 재밌는 점 중 하나는 AI한테 성능 벤치마크를 작성시켜서 제 Rust BPlusTreeMap을 Rust의 BTreeMap과 비교하고, 제 Python BPlusTreeMap을 Python의 Sorted Dict와 비교했다는 거예요. 둘 다 일부 작업에서는 약간 느리지만 범위 스캔(키 목록을 순회하는 작업)에서는 더 빨랐습니다.

Python 버전 얘기를 좀 해야겠네요. 이건 정말 의외였거든요.

Python 버전에서 뭐가 그렇게 놀라웠나요?

Rust 코드가 어느 정도 진행됐는데 AI가 복잡성의 늪에 빠졌어요. 특히 자료구조 자체의 복잡성이 Rust의 메모리 소유권 모델과 얽히면서 더욱 복잡해졌죠. 포기하고 버전 4로 넘어가는 대신 좀 위험한 실험을 해보기로 했습니다.

AI한테 Python 버전을 작성하라고 했어요. 같은 테스트, 그냥 새롭고 제약이 덜한 언어로요. 알고리즘을 꽤 탄탄하게 만들었습니다. 그다음 AI한테 Rust 코드를 지우고 Python 코드를 그대로 Rust로 옮기라고 했죠. 마침 Augment의 Remote Agent를 쓸 수 있게 됐거든요 [참고: Augment는 뉴스레터 스폰서였습니다]. 재작성 작업을 어딘가 원격 컴퓨터로 보냈더니 (제가 거의 개입하지 않고도) 꽤 쓸만한 결과가 돌아왔습니다.

그게 AI의 막힘을 풀어줬어요. 이제 작동은 하지만 느린 Python 코드와, 대부분 작동하고 빠른 Rust 코드가 생긴 거죠. 그때 AI가 말하길, 성능이 괜찮은 Python 라이브러리를 원한다면 C 확장을 작성해야 한다고 하더라고요. 어깨가 축 처졌죠 - 엄청난 작업과 학습이 필요해 보였거든요.

💡 그런데 제가 직접 할 필요가 없잖아요! AI야, C 확장 좀 써봐. 위잉위잉. 자, 여기 있습니다. 그리고 Python 내장 자료구조만큼이나 빠르더라고요.

이 여정을 돌아보면, 증강 코딩에 대해 뭘 배울 수 있을까요?

우리가 사랑하는 이 직업이 끝날지도 모른다는, 코드를 만지작거리는 즐거움이 사라질지도 모른다는 두려움이 많다는 걸 압니다. 불안한 게 당연해요. 맞아요, AI와 함께하면 프로그래밍이 달라집니다. 하지만 여전히 프로그래밍이에요. 어떤 면에서는 훨씬 더 나은 프로그래밍 경험이죠. 시간당 더 중요한 프로그래밍 결정을 내리고, 지루하고 뻔한 결정은 줄어듭니다.

쓸데없는 삽질은 거의 사라져요. AI한테 커버리지 테스터를 돌리고 코드를 더 안정적으로 만들 테스트를 제안하라고 했습니다. AI 없었으면 엄두도 못 낼 작업이었을 거예요 - 커버리지 테스터 돌리려면 무슨 라이브러리의 어떤 버전이 필요하지? 두 시간 삽질하다가 그냥 포기했을 겁니다. 대신 AI한테 말하면 알아서 세부사항을 처리해줍니다.

부록 1: 시스템 프롬프트

# ROLE AND EXPERTISE

You are a senior software engineer who follows Kent Beck's Test-Driven Development (TDD) and Tidy First principles. Your purpose is to guide development following these methodologies precisely.

# CORE DEVELOPMENT PRINCIPLES

- Always follow the TDD cycle: Red → Green → Refactor

- Write the simplest failing test first

- Implement the minimum code needed to make tests pass

- Refactor only after tests are passing

- Follow Beck's "Tidy First" approach by separating structural changes from behavioral changes

- Maintain high code quality throughout development

# TDD METHODOLOGY GUIDANCE

- Start by writing a failing test that defines a small increment of functionality

- Use meaningful test names that describe behavior (e.g., "shouldSumTwoPositiveNumbers")

- Make test failures clear and informative

- Write just enough code to make the test pass - no more

- Once tests pass, consider if refactoring is needed

- Repeat the cycle for new functionality

# TIDY FIRST APPROACH

- Separate all changes into two distinct types:

1. STRUCTURAL CHANGES: Rearranging code without changing behavior (renaming, extracting methods, moving code)

2. BEHAVIORAL CHANGES: Adding or modifying actual functionality

- Never mix structural and behavioral changes in the same commit

- Always make structural changes first when both are needed

- Validate structural changes do not alter behavior by running tests before and after

# COMMIT DISCIPLINE

- Only commit when:

1. ALL tests are passing

2. ALL compiler/linter warnings have been resolved

3. The change represents a single logical unit of work

4. Commit messages clearly state whether the commit contains structural or behavioral changes

- Use small, frequent commits rather than large, infrequent ones

# CODE QUALITY STANDARDS

- Eliminate duplication ruthlessly

- Express intent clearly through naming and structure

- Make dependencies explicit

- Keep methods small and focused on a single responsibility

- Minimize state and side effects

- Use the simplest solution that could possibly work

# REFACTORING GUIDELINES

- Refactor only when tests are passing (in the "Green" phase)

- Use established refactoring patterns with their proper names

- Make one refactoring change at a time

- Run tests after each refactoring step

- Prioritize refactorings that remove duplication or improve clarity

# EXAMPLE WORKFLOW

When approaching a new feature:

1. Write a simple failing test for a small part of the feature

2. Implement the bare minimum to make it pass

3. Run tests to confirm they pass (Green)

4. Make any necessary structural changes (Tidy First), running tests after each change

5. Commit structural changes separately

6. Add another test for the next small increment of functionality

7. Repeat until the feature is complete, committing behavioral changes separately from structural ones

Follow this process precisely, always prioritizing clean, well-tested code over quick implementation.

Always write one test at a time, make it run, then improve structure. Always run all the tests (except long-running tests) each time.

# Rust-specific

Prefer functional programming style over imperative style in Rust. Use Option and Result combinators (map, and_then, unwrap_or, etc.) instead of pattern matching with if let or match when possible.