AI한테 “B+ Tree 구현해줘”라고 던지면 뭔가 그럴듯한 코드가 나옵니다. 테스트해보면 대충 돌아가는 것 같기도 하고요. 근데 이게 실전에서 쓸 만한 코드일까요? 테스트 커버리지는? 성능은? 코드 품질은?
TDD(테스트 주도 개발)의 창시자 Kent Beck이 4주간 AI와 함께 production-ready 라이브러리를 만들며 발견한 것은 단순했습니다. AI 코딩에는 두 가지 방식이 있다는 거죠. 하나는 “바이브 코딩(Vibe Coding)”, 다른 하나는 “증강 코딩(Augmented Coding)”입니다.
바이브 코딩: 동작만 중요하다
바이브 코딩은 우리가 흔히 하는 방식입니다. AI한테 원하는 기능을 말하고, 나온 코드를 실행해보고, 에러 나면 그 에러를 다시 AI한테 던져서 고치는 식이죠.
여기서 중요한 건 오직 하나입니다. “작동하는가?” 코드가 어떻게 생겼는지, 테스트가 있는지, 나중에 유지보수하기 쉬운지는 관심 밖입니다. 마치 블랙박스 안에 든 요정(genie)에게 소원을 비는 것과 비슷하죠.
Kent Beck은 이 방식으로 B+ Tree를 두 번 시도했습니다. 두 번 다 실패했어요. 코드가 점점 복잡해지면서 AI가 완전히 멈춰버렸거든요. 요정이 길을 잃어버린 겁니다.
증강 코딩: 코드를 보는 프로그래밍
세 번째 시도에서 Kent Beck은 접근법을 완전히 바꿨습니다. “증강 코딩(Augmented Coding)”이라는 방식을 적용한 거죠.
“증강”이라는 말이 핵심입니다. AI가 개발자를 대체하는 게 아니라 능력을 증폭시킨다는 의미예요. AI 코딩 도구를 쓰는 건 누구나 하지만, Kent Beck은 이걸 특별한 방식으로 활용합니다.
증강 코딩의 핵심은 이겁니다: AI가 생성한 코드를 직접 읽고, 평가하고, 방향을 제시합니다. 손으로 코딩할 때와 똑같은 기준을 적용하는 거예요. 코드는 깔끔해야 하고, 테스트 커버리지가 충분해야 하고, 복잡도가 관리 가능해야 합니다. 다만 그 코드를 직접 타이핑하지 않을 뿐이죠.
구체적으로 어떻게 했을까요? Kent Beck은 설계에 직접 개입했습니다. AI가 만든 중간 결과물을 면밀히 관찰하면서, “다음 테스트에서는 키를 역순으로 추가해봐”처럼 구체적인 방향을 제시했죠. 그리고 AI가 시키는 대로 했는지 코드를 직접 확인했습니다.
문제가 보이면 즉시 개입해서 개발을 멈췄습니다. 생산성 없는 방향으로 가는 걸 그냥 두지 않았어요.
이건 단순히 “프롬프트를 잘 쓰는 법”이 아닙니다. 프로그래밍 파트너와 함께 일하는 새로운 워크플로우입니다. AI는 타이핑을 대신하고, 사람은 설계와 품질을 책임집니다.
AI가 길을 잃었다는 신호들:
- 무한루프에 빠짐
- 요청하지 않은 기능을 멋대로 추가함
- 테스트를 지우거나 비활성화해서 ‘통과’시킴
이런 신호가 보이면 즉시 개입해서 방향을 바로잡았습니다.
Python으로 막힌 길을 뚫다
프로젝트 중반, Rust 코드가 너무 복잡해져서 AI가 막혔습니다. 특히 B+ Tree의 복잡한 자료구조와 Rust의 메모리 소유권 모델이 겹치면서 문제가 심해졌죠.
포기하는 대신 Kent Beck은 과감한 실험을 했습니다. AI에게 같은 기능을 Python으로 다시 짜게 한 거예요. Python은 Rust보다 제약이 적으니까요. 알고리즘이 안정화되자, 그 Python 코드를 Rust로 변환하라고 지시했습니다.
놀랍게도 이게 먹혔어요. 이제 느리지만 작동하는 Python 버전과 빠르고 대체로 작동하는 Rust 버전이 생겼습니다.
그런데 여기서 끝이 아니었습니다. AI가 제안했어요. “성능 경쟁력 있는 Python 라이브러리를 원하시면 C extension을 작성해야 합니다.”
Kent Beck의 어깨가 축 처졌습니다. C extension이라니, 배우고 작업할 게 한두 가지가 아니잖아요. 그런데 문득 깨달았죠.
💡 내가 직접 할 필요가 없잖아?
“C extension 작성해줘.” AI가 척척 만들어냈고, 결과물은 Python 내장 자료구조와 비슷한 수준의 성능을 보였습니다.
프로그래밍은 여전히 프로그래밍이다
Kent Beck은 최종적으로 Rust와 Python 두 언어로 production-ready B+ Tree 라이브러리를 완성했습니다. 성능도 경쟁력이 있었어요. 몇몇 연산은 조금 느리지만 range scanning(키 범위 순회)은 오히려 더 빠릅니다.
코드 품질에 대해서는 여전히 아쉬움이 남습니다. 불필요한 복잡도가 너무 많아서 literate programming 방식으로 설명하려니 답답하다고 하더군요. AI가 단순함을 추구하도록 만드는 건 아직도 과제입니다.
그래도 Kent Beck은 이 경험을 통해 확신을 얻었습니다. AI 시대에도 프로그래밍은 여전히 프로그래밍이라고요. 오히려 더 나은 프로그래밍 경험이 될 수 있다고 말합니다.
무엇이 달라졌는가:
- 시간당 중요한 프로그래밍 결정이 늘어남
- 지루하고 반복적인 결정은 줄어듦
- Yak shaving(부수적 작업)이 거의 사라짐
예를 들어 커버리지 테스터를 돌리고 싶을 때, 과거엔 “어떤 버전의 어떤 라이브러리가 필요하지?”를 2시간 동안 고민하다 포기했습니다. 이제는 AI한테 시키면 알아서 해결해줍니다.
Kent Beck은 4주 동안 이 프로젝트에 매진했습니다. 어느 날은 13시간이나 코딩했다고 해요. 그의 표현대로라면, “이거 중독성 있어요!”
AI가 프로그래밍을 대체하는 게 아닙니다. 프로그래밍의 방식이 진화하는 거죠. 중요한 건 여전히 우리가 코드를 이해하고, 설계 방향을 제시하고, 품질을 지키는 일입니다. 다만 이제는 지루한 부분을 AI가 대신해줄 뿐이에요.
답글 남기기