// AI CODING · ONE YEAR LATER
무료 토큰이 많다는 이유로 Gemini CLI를 시작했다. 1년이 지난 지금은 코드를 직접 잘 짜는 방법보다 AI가 같은 원칙 안에서 움직이게 만드는 방법을 더 많이 고민한다.
작년 8월쯤 Gemini CLI를 사용하면서 처음 바이브 코딩에 입문했다.
처음부터 AI로 앱을 만들겠다는 거창한 목표가 있었던 것은 아니다. 단순한 업무를 자동화할 방법을 찾다가 Make와 n8n 같은 도구를 알게 됐다. 이것저것 살펴보다 보니 개발자인 내가 자동화 도구를 새로 배우는 것보다 그냥 직접 개발하는 편이 낫겠다는 생각이 들었다.
그때 눈에 들어온 것이 Gemini CLI였다. 무료로 사용할 수 있는 토큰이 많았고, 일단 시작해 보기에는 부담이 없었다.
1. 생각한 것을 실제로 만들 수 있다는 놀라움
Gemini CLI로 처음 무언가를 만들었을 때는 꽤 놀랐다.
완벽하지는 않았지만, 내가 만들고 싶다고 설명한 것이 실제 코드와 화면으로 만들어졌다. 이전에도 개발은 계속해 왔지만, 머릿속에 있던 아이디어를 이렇게 빠르게 확인해 본 경험은 많지 않았다.
처음에는 AI가 만들어 주는 코드 자체가 신기했다. 원하는 것을 설명하고, 결과를 확인하고, 다시 수정해 달라고 요청했다. 그렇게 대화를 주고받다 보면 어느 순간 실제로 동작하는 결과물이 나왔다.
그러다 문득 궁금해졌다.
Gemini CLI도 이 정도인데, 사람들이 가장 좋다고 말하는 Claude는 얼마나 다를까?
결국 월 20달러짜리 Claude Pro를 구독했다.
2. Claude는 확실히 달랐다
처음 사용했을 때 든 생각은 단순했다.
오, 달랐다.
Gemini CLI보다 대답이 안정적이었고, 설명도 훨씬 친절했다. 어떤 사람들은 Claude가 답변을 너무 장황하게 해서 토큰을 낭비한다고 했지만, 나는 오히려 그 설명이 좋았다. 단순히 코드를 던져 주는 것보다 왜 이렇게 설계했고 무엇을 고려했는지 길게 설명해 주는 방식이 잘 맞았다.
문제는 정말로 토큰을 많이 사용한다는 것이었다.
개인 프로젝트로 앱 하나를 만들어 보려고 한 시간 정도 설계를 이야기하면 사용량이 거의 끝났다. 매일 퇴근해서 집에 돌아온 뒤 자기 전까지 Claude와 한 시간쯤 대화했다. 토큰을 다 쓰면 그날 개발은 끝이었다.
퇴근
→ Claude와 개발
→ 토큰 소진
→ 취침그렇게 2주 정도 생활했다.
이 방식으로는 안 되겠다는 생각이 들어 결국 월 200달러짜리 Max 요금제를 구독했다.
3. 토큰을 아끼는 대신 많이 쓰는 방법을 고민했다
Max 요금제를 구독하고 나서는 생각이 반대로 바뀌었다.
이전에는 토큰을 아껴서 오래 사용하는 방법을 고민했다. 이제는 토큰을 최대한 많이 사용해서 개발 속도를 높이는 방법을 고민하기 시작했다.
개인 프로젝트를 여러 개 만들었고, 회사에서 그동안 시간이 부족해 시도하지 못했던 것들도 해봤다. 아이디어가 생기면 일단 만들어 볼 수 있었다. 완성하지 못해도 괜찮았다. 예전이었다면 시작하기 전에 비용과 시간을 계산했을 일도 AI와 함께라면 먼저 만들어 보고 판단할 수 있었다.
하지만 여전히 문제가 있었다.
AI와 계속 대화를 주고받으며 개발하다 보니 조금 전까지 되던 것이 갑자기 안 되기도 했다. 앞에서 합의했던 내용을 잊고 엉뚱한 방향으로 가기도 했다. 코드가 많아지고 대화가 길어질수록 실수도 늘어났다.
빠르게 만들 수는 있었지만, 결과를 안정적으로 유지하기는 어려웠다.
4. 대화가 아니라 Spec을 기준으로 개발하기 시작했다
그 문제를 해결하려고 찾은 것이 Spec Kit이었다.
대화의 흐름에만 의존하지 않고, 먼저 Spec을 만들고 그 내용을 기준으로 설계와 개발을 진행했다. 무엇을 만들어야 하는지, 어떤 조건을 만족해야 하는지, 하지 말아야 할 것은 무엇인지 문서로 남겼다.
기준이 생기자 AI가 중간에 다른 방향으로 빠지는 일이 줄었다. 문제가 생겼을 때도 대화를 처음부터 다시 설명하는 대신 Spec으로 돌아가 확인할 수 있었다.
그 이후 OpenCode가 나오고 Claude의 팀 기능을 접했다. 올해 들어서는 orchestration이 화두가 되면서 여러 에이전트를 어떻게 나누고 조율할지 고민하기 시작했다.
하나의 AI에게 모든 일을 맡기는 것이 아니라 역할을 나눴다. 한 에이전트가 설계하면 다른 에이전트가 검토하고, 구현한 결과를 또 다른 에이전트가 테스트하게 했다.
프롬프트 엔지니어링과 컨텍스트 엔지니어링도 계속 공부했다. 어떤 말을 해야 더 좋은 답을 얻을 수 있는지보다, AI가 작업에 필요한 정보를 잃지 않도록 어떻게 제공할지를 더 많이 고민하게 됐다.
그 과정에서 그동안 만들지 못했던 앱을 여러 개 만들었다. 게시하지 않은 앱도 많았다. 만들었다가 지우고, 다른 방식으로 다시 만들어 보기를 반복했다.
5. 더 빨라졌는데, 오히려 번아웃이 왔다
AI를 사용하면 일을 덜 하게 될 줄 알았다.
실제로는 반대였다.
개발 속도가 빨라지니 같은 시간에 더 많은 일을 했다. 예전에는 구현에 며칠이 걸려 포기했을 아이디어도 이제는 바로 시작할 수 있었다. 하나를 완성하면 쉬는 대신 다음 아이디어를 만들었다.
손은 덜 힘들었을지 몰라도 머리는 계속 돌아갔다.
결국 어느 순간 번아웃이 왔다. 회사에서는 계속 AI를 사용해 개발했지만, 퇴근 후 개인 개발은 멈췄다. 1~2주 정도는 집에서 아무것도 만들지 않고 쉬었다. 뇌가 이제 그만 생각하고 싶다고 말하는 것 같았다.
조금 쉬고 나니 다시 무언가를 만들 수 있을 정도로 회복됐다.
그 무렵부터 하네스라는 말이 많이 들리기 시작했고, 이어서 Loop Engineering이 등장했다. 새로운 용어가 계속 나오니 처음에는 또 뒤처지는 것 같은 FOMO가 느껴졌다.
하지만 자세히 살펴보니 완전히 낯선 이야기는 아니었다.
명확한 기준을 문서로 만들고, AI가 그 기준을 벗어나지 않게 하고, 결과를 테스트한 뒤 문제가 있으면 다시 실행하는 것. 이름은 달라졌지만 이미 내가 실패하면서 하나씩 추가하고 있던 방법도 많았다.
그걸 깨닫고 나니 새로운 용어가 나올 때마다 조급하게 따라가야 한다는 생각이 조금 줄었다.
6. 이제는 코드를 잘 짜는 방법을 먼저 고민하지 않는다
작년 8월부터 시작했으니 이제 1년 정도 됐다.
그 짧은 시간 동안 개발 방식이 너무 많이 바뀌었다.
예전에는 코드를 어떻게 하면 더 잘 짤 수 있을지를 먼저 고민했다. 함수 이름은 어떻게 지을지, 클래스를 어떻게 나눌지, 이 로직을 더 간결하게 만들 방법은 없는지를 생각했다.
지금은 내가 모든 코드를 직접 잘 짜려고 하지 않는다.
대신 좋은 코드가 어떤 모습인지 정하고, AI가 그 기준에 맞춰 작성하도록 만든다. 프로젝트마다 공통된 컨벤션 문서를 제공한다. 헥사고날 아키텍처나 SOLID 같은 설계 원칙을 정하고, AI가 그 원칙을 벗어나지 않는지 검사하는 하네스를 갖춘다.
코드를 예쁘게 작성하는 방법을 직접 찾아 헤매기보다, 내가 원하는 코드의 형태를 설명하고 그것을 반복해서 만들어 낼 수 있는 구조를 고민한다.
그렇다고 개발자가 할 일이 없어진 것은 아니다. 오히려 내가 집중하는 대상이 달라졌다.
이제는 디테일한 구현보다 전체 구조를 어떻게 설계할지, 프로젝트에 쌓여 있는 도메인 문제를 어떤 순서로 풀어야 할지 AI와 함께 고민한다. 코드 작성보다 문제를 정의하고 기준을 만드는 시간이 늘었다.
앞으로 AI가 더 좋아지면 개발자는 코드 자체에 지금보다 더 적게 신경 쓰게 될지도 모르겠다.
그렇다면 개발자는 무엇을 해야 할까.
아마 어떤 문제를 풀어야 하는지 알아내고, 그 문제를 제대로 설명하고, AI가 만든 결과가 정말 원하는 방향인지 판단하는 일이 더 중요해질 것 같다.
1년 전에는 무료 토큰이 많다는 이유로 Gemini CLI를 시작했다. 지금은 여러 에이전트가 같은 원칙과 문서를 기준으로 움직이게 하는 방법을 고민하고 있다.
돌아보면 도구만 바뀐 것이 아니었다.
내가 개발을 바라보는 방식 자체가 꽤 많이 달라졌다.
답글 남기기