매우 도전적인 질문이다. 이런 도전적인 질문은 여지없이 욕을 먹기 마련이다. 뭐라고 남이 하는 걸 가지고 참견이냐라는. 그럼에도 AI, AX의 시대에 동참하고 있는 각자가 대표 도구인 클로드코드(Claude Code)와 그 너머의 AI를 어떤 방식으로 쓰고 있는지 짚어볼 시점이라는 생각이 든다. 정말 현실적인 이유인 토큰비 때문이다.
정말 클로드코드 전성시대다. 세상은 어찌보면 ChatGPT 이후 개발에서 AI를 인정했지만, 생활의 AI를 만든건 클로드코드가 아닐까 싶다. 올 초 앤트로픽의 클로드코드가 나온 이후 “도구로의 AI”에 대한 접근성이 크게 열렸다. 세상의 지식과 채팅하는 것을 넘어 API와 MCP로 주변과 연결된 진짜 도구가 된 것이다. 더불어 개발자의 도구 대표가 IDE에서 CLI로 넘어오며 코딩이 아닌 텍스팅이 새로운 개발 언어로 자리잡았다.
이전에도 CLI 기반의 도구가 있었다. 클로드코드가 대세가 된 건 CLI로써 훌륭해서가 아니라 CLI가 인터페이스로 더 적합한 형태가 될 만큼 앤드로픽의 LLM(Claude Sonnet)이 코드 작성에 뛰어난 성능을 보였기 때문이다. 그리고 Public LLM Vendor들이 코딩 각축전/경쟁전이 벌어지면서 성능(Performance)의 새로운 판이 벌어졌다. 간단한 Prompt만으로도 기대했던 결과를 만들어내는 코드가 만들어진다. 이전 AI는 코드 분석에 도움을 줬다면 이제 만드는 것도 쓸만한 수준이라는 믿음을 줬다. 사람이 작성한 Business Logic을 대상으로 테스트 코드를 작성하거나 코드 리뷰를 방식이었다면, 이제 요구 사항 분석, 테스트 코드, 로직 작성, 리뷰 체계와 같은 전체 개발 Cycle을 AI를 써서 실행할 수 있게 됐다. 어깨너머로 바라본 개발자들의 일하는 모습은 터미널에 3~4개 클로드코드가 분석, 코딩, 테스트 코드, 리뷰를 동시에 진행하는 것이 일상이다. 쿨~ 하다.
그런데… 정말 이게 맞는걸까??
요즘 클로드코드를 개발하는 모습은 TDD(Test Driven Development)와 정말 닮았다. 되짚어 질문해보면 왜 TDD가 나왔을까? 근원적인 이유는 사용자가 원하는 것을 잘 모르기 때문이다. 사용자 스스로도 자신이 원하는 것을 명확하게 모르기 때문에, 변화를 적극적으로 수용할 수 있는 단단한 개발을 하기 위해서다. 이 질문은 쓰는 사람과 만드는 사람이 분리된 상황에서는 언제나 유효하다. 실제 현장의 요구 사항은 여전히 엑셀 파일 하나로 전달되고, 해석된 결과물을 고객에게 전달하면 “이건 제가 원하는게 아닌데요.” 라는 반응이 일반적이다. 자신이 직접 만들어 쓰는게 아닌 이상 다른 사람이 내 마음에 쏙드는 물건을 만들어주는 경우는 없다. 물론 이런 이유로 직접 만드는 바이브코딩이 더 유행인지도 모르겠다.
이런 상황에서 AI 기반의 TDD는 어떤 효과를 만들까? 대강 아래와 같은 상황이 벌어진다.
- 요구 사항(개략적인)을 입력으로 테스트 코드 생성
- 입력 – 요구사항
- 출력 – 테스트케이스 코드
- 기본 팀 개발 Convention 스킬이 적용된 Business Logic 코드 생성
- 입력 – 요구사항, 테스트케이스 코드
- 출력 – Business Logic 코드
- 테스트를 수행하고, Test Fail된 코드에 대한 수정
- 입력 – Business Logic 코드, 테스트케이스 코드
- 출력 – 수정된 Business Logic 코드
- 코드 리뷰
- 입력 – 요구 사항, 테스트케이스, Business Logic 코드
- 출력 – 코드 수정 사항
1~4 단계의 단일 Iteration 과정을 보더라도 후반부로 갈수록 더 많은 입력이 AI에게 필요하다. 앞단에서 생성한 출력 결과들이 뒷단계의 입력으로 사용되고, 입력의 크기는 상상 이상으로 커진다. 한번의 단일 Iteration으로 완성되지 않기 때문에 많은 Iteration을 반복해야 한다. 만약 세부적인 명세가 없어 Business Logic을 파고들면서 구체화하는 과정이 필요한 상황이라면 정교한 컨텍스트를 위해 더 많은 입력이 필요하다. AI 언덕에서 구르는 Snowball 효과가 여기에서 발생한다. 불명확한 요구사항이나 명세의 부재는 눈덩이가 구르는 언덕의 기울기를 급경사로 만든다. 입력과 출력을 토큰으로 대입해보면 소위 토큰을 태우는 Token Maxing 효과가 나온다. 정교한 개발 전략이 뒷받침되지 않으면 지갑이 남아나지 않는다.
개발 전략: 개인 바이브와 조직 바이브의 차이
개발 전략은 개인이 하는 바이브와 조직의 바이브를 갈리는 지점이다. 개발 전략은 장기적인 조직의 개발 Economy를 결정한다. 전략의 부재는 조직내 개인이 개인 바이브를 통해 성과를 만들고 있다는 것을 의미한다. 각자가 자신의 방식으로 문제를 풀지만, 조직내의 각자가 푸는 문제는 조직의 문제를 해결하는 것이다. 개인 프로젝트를 하는게 아니니까. A와 B가 해결하고 기여해야 하는 도메인이 있고, 각자의 Problem Space가 존재하고 이에 대한 해결책을 A, B 모두 바이브를 통해 정의하고 해결하고 있다. Problem Space의 합집합이 도메인 문제와 해결 방안이지만, 교집합 역시 중요하다. 특히 AI가 빠르게 대량으로 생산하는 코드에서 교집합 부분은 서비스의 연속성에 치명적인 영향을 미칠 수 있다. 성공적인 합집합과 교집합을 유지 관리하는 것이 결국은 개발 조직과 서비스 조직의 연속성을 보장하기 때문에 더욱 더 개발 전략이 중요한 이유다.
개발 전략의 중요성을 우리 업계는 이미 MSA(Microservice Archtiecture)를 조직내에서 도입하면서 경험했다. Architecture 수준의 Governing을 통해 관리되지 않는 마이크로서비스 체계는 빠른 속도를 보장할 수는 있어도, 각자 개발에 따른 파편화를 피할 수 없다. “빠른 배포”라는 이름하에 마이크로서비스를 개발할 수 있지만, 동일한 역할/기능을 하는 마이크로서비스가 남발되기도 하고, 분리된 코드베이스로 인해 “코드 중복”이 걸러지기 어렵게 됐다. 중복과 반복 지점에 대한 변경이 발생하면 고친 문제가 고쳐지지 않는 세상 골치아픈 상황에 처하기도 한다. 어찌보면 AI로 인한 코드 대량 생산 시대가 우리에게 같은 질문을 다시 하고 있는게 아닌가 싶다.
AI 기반의 개발은 사람 중심의 개발과는 다르다. 사람이 개발하던 방식을 AI 방식에 대입하면 결국 같은 문제를 되풀이할 수 밖에 없다. 새술을 새부대에 담아야 하는 것처럼 새로운 관점에서 개발 패러다임을 봐야하고, 이 패러다임은 개발 체계 흐름을 한 요소를 해결하는 방식이면 제한된 결과만을 얻게 된다. 전지적 관점(Holistic View)에서 조망하고, 사람과 AI의 역할 재정립, 그리고 그 사이를 단단하게 잇는 거버닝이 수반되야 한다.