나는 블로그 글을 올린 뒤로 “코드 생성(codegen)을 어디서부터 시작해 어떻게 잘할 수 있으며, 왜 재미있는가”를 두고 정말 많은 사람과 이야기를 나눴다.
이 주제에 대한 열기는 그야말로 폭발적이었다. “도대체 어떻게 해야 하냐”는 메일이 정말 쏟아졌다. 그러다 보니 ‘다들 첫걸음을 떼는 방법, 그리고 퍼즐을 어떻게 맞춰야 하는지를 헤매고 있구나’가 확 보였다. 문득 생각해 보니 나는 2023년부터 이 프로세스를 직접 해킹하면서 X나 많은 일을 겪어 왔더라. ㅋㅋ

친구들(Fisaconites, 리스펙트!)과 잡담을 하다 AI 보조 에디터·‘에이전트형’ 코더 이야기가 나오자 내가 이렇게 말했다:

내가 초보자라면 곧장 ‘에이전트’ 코더로 점프하는 게 도움이 될지는 모르겠어. 거슬리고 이상하거든. 몇몇 사람을 (성공도 실패도 포함해서) 도와 보니, Copilot으로 시작 → Claude 웹에 복붙 → Cursor 또는 Continue 확장 → 완전 자동화된 ‘에이전트’로 가는 영웅 서사가 가장 무난하더라고.

이 대화 덕분에 ‘에이전트형 코딩(agentic coding)의 여정’을 본격적으로 떠올리게 됐다:

단, 이 여정은 주로 경험자용이야. 개발 경험이 많지 않다면 걍 맨 끝으로 점프해. 우리 뇌는 과거의 규칙 때문에 종종 망가져 있으니까.

시청각의 여정

이건 내 여정이다. 마음만 먹으면 ‘스피드런’도 가능하다. 모든 단계를 꼭 밟을 필요는 없지만, 하나하나가 누적 효과를 준다.

다음이 단계별 개요다.

1단계: 경이로움과 낙관으로 침대에서 일어나기

ㅋㅋ 농담이다. 세상은 난장판이고, 우리에게는 코드 생성밖에 없으니까.

그래도 이런 워크플로가 정말 돌아가고 시너지를 낼 거라고 믿는 편이 낫다. LLM을 혐오한다면 여기서 성공하기 어렵다. ¯\_(ツ)_/¯

2단계: AI 보조 자동완성부터 맛보기

진짜 첫걸음! IDE 안에서 IntelliSense, Zed Autocomplete, Copilot 같은 자동완성을 충분히 써 보라. LLM이 어떻게 사고하고 얼마나 황당한 제안을 하는지 몸으로 익힐 수 있다.

사람들은 이 단계를 스킵하고 곧장 마지막으로 달려간다. 그러곤 “이 LLM X나 못하네!”라고 한다. 100% 틀린 말은 아니지만 전부도 아니다. 마법은 디테일 속에 있다. 인생은 원래 헷갈린다.

3단계: Copilot을 자동완성 그 이상으로 활용하기

자동완성에 적응해 더 이상 항상 빡치지 않는다면, 이제 Copilot과 대화를 시작하라.

VS Code에는 Copilot과 Q&A를 주고받는 창이 있다. 꽤나 사려 깊게 문제를 해결해 준다.

하지만 Copilot은 마치 타임머신 타고 2024년 ChatGPT를 쓰는 느낌이다. 그렇게까지 대단하진 않다. 더 원하게 될 거다.

4단계: Claude나 ChatGPT에 코드 복붙하기

코드를 통째로 브라우저에서 돌리는 대형 기반 모델(foundational model) 창에 붙여넣고 “WHY CODE BROKE??”라고 물어봐라. LLM은 일목요연하고 친절한 답을 돌려준다.

완전히 놀랄 거다! 디버깅 과정을 통째로 날려 버리니 코딩이 다시 재미있어진다. 파이썬 스크립트를 붙여넣고 “Go로 바꿔 줘”라고 하면 진짜 Go 코드를 내놓는다. “원샷으로도 되겠는데?”라는 생각이 든다.

이쯤 되면 Copilot은 2004년식 자동완성처럼 느껴진다. 있으면 좋지만 필수는 아니다.

그리고 두 갈래 하위 경로가 열린다.

분위기 때문에 한 모델이 끌리기 시작함

안타깝지만 이것이 ‘바이브 코딩’의 첫걸음이다. “Claude랑 대화하면 기분이 좋다” 같은 정서적 끌림.

많은 개발자가 Claude를 좋아한다. 나도 코딩에는 주로 Claude를 쓴다. 바이브가 더 좋으니까.

제대로 쓰려면 결국 돈을 내야 한다. 무료 모델만 쓰고 “별로야”라며 툴 탓하는 친구를 종종 본다. 특히 무료 버전이 ChatGPT 3.5였던 시절엔 더 그랬다. 쓸 만한 모델인지 먼저 확인하고 욕하자.

더 빠른 방법을 찾기 시작함

며칠간 Claude에 복붙하다 보면 귀찮아진다. 컨텍스트 패킹에 집착하며 코드베이스 전체를 창에 우겨넣으려 한다.

repomix, repo2txt 같은 툴을 써 보거나 쉘 스크립트를 Claude에게 시켜 짜게 된다.

이게 전환점이다.

5단계: AI 지원 IDE로 이동(Cursor 또는 Continue)

어느 날 친구가 “그냥 Cursor 써봐”라고 한다.

복붙하며 느꼈던 마법이 통째로 IDE 안으로 들어온다. 더 빠르고, 더 재미있고, 거의 마법 같다.

이미 LLM 구독만 몇 개나 결제했으니 월 20달러쯤 더 쓰는 건 아무 일도 아니다. 생산성은 폭발한다.

이제 에디터에 내장된 에이전트형 기능을 만지작거린다. 대체로 잘 돌아간다. 하지만 저 멀리 더 나은 목적지가 보인다.

6단계: 코딩 전에 먼저 계획 세우기

어느새 스펙, PRD, 할 일 문서를 정교하게 작성해서 IDE의 에이전트나 Claude 웹으로 바로 넘긴다.

이렇게 문서를 많이 ‘작성’해 본 적이 없다. 다른 LLM을 불러 문서를 더 다듬고 “이걸 프롬프트로 바꿔 줘”라고 시키고, 코드 생성 프롬프트 설계도 LLM에 맡긴다.

“워터폴”이라는 말을 예전만큼 싫어하지 않는다. 나이가 좀 있다면 90~00년대를 떠올리며 “2001년 이전의 마틴 파울러는 이런 기분이었을까?” 생각할지도.

코드 생성의 세계에서 스펙은 신 그 자체다.

7단계: 루프를 줄이려고 aider 실험

이제 진짜 재미를 볼 준비가 됐다. 그동안은 사람이 반드시 끼어 있어야 했지만, 2025년이다! 손가락으로 코딩이라니.

또 다른 경로로, 음성으로 코딩하는 친구들도 많다. whisper 클라이언트로 aider에 명령을 내리는 식이다. 기가 막히게 웃기고 재미있다. 로컬에선 MacWhisper가 좋고, Aqua나 superwhisper도 괜찮지만 돈이 더 든다. 클라우드 추론을 쓰는 경우도 있다. 난 로컬 선호.

aider를 실행하면 프로젝트에 바로 자리 잡는다. 터미널에 쿼리를 넣으면 행동 전에 “이 변경 실행해도 될까요?”라고 허가를 구하고, 절차를 보여 준 뒤 작업을 실행한다. 몇 단계를 거쳐 알아서 처리하고 커밋까지 한다. 이제는 원샷보다 여러 단계로 나눠 시키는 편이 편하다.

LLM용 규칙 세트를 만들기 시작한다. “Big Daddy” 규칙, “no deceptions” 같은 프롬프트 보강도 배운다. 프롬프트 장인이 되어 간다.

잘 된다.

결국 IDE도 안 켜고, ‘터미널 매니아’가 된다. 로봇이 일하는 걸 바라보며 시간을 보낸다.

8단계: 에이전트형 코딩에 올인

이젠 에이전트가 대부분의 코드를 쓴다. 가끔 상황이 이해되지 않으면 그냥 물어본다.

Claude Code, Cline 등을 시험해 본다. 추론형 모델(deepseek)과 코딩 특화 모델(Claude Sonnet 3.7)을 조합해 계획 단계도 줄인다.

3~5개 세션을 동시 실행하며 탭만 전환하는 기묘한 광경이 펼쳐진다.

방어적 코딩 습관도 자리 잡는다:

• 극단적인 테스트 커버리지
• 형식 검증 고민
• 메모리 안전 언어 채택
• 컴파일러 메시지가 짧아 컨텍스트를 덜 차지하는 언어 선택

아무도 손대지 않고 안전하게 완성되도록 애쓴다.

토큰 비용으로 정말 돈을 많이 쓴다. GitHub Actions 시간도 테스트 돌리느라 다 써 버린다. 그래도 기분은 좋다. 손으로 코딩하지 않아도 안 빡친다.

9단계: 에이전트가 코딩하고, 나는 게임한다

드디어 도착했다. 아니, 완전히는 아니지만 갈 길이 보인다. 친구들이 해고되고 새 직장을 못 구하는 걸 보며 불안이 엄습한다. 이번엔 뭔가 다르다.

“에이전트형 코딩 꼭 써봐!”라고 전도하면 동료들은 종교 광신도 보듯 한다. “나도 ‘agentic’이라는 단어는 싫어해”라며 변명해도 이미 200리터쯤 쿨에이드를 들이켠 사람처럼 보인다. 하지만 세상은 더 밝아 보인다. 코드가 미친 속도로 나오니까.

패러다임이 완전히 뒤집혔다. 토머스 쿤이 혼란을 주제로 새 책을 쓸 만하다.

여정을 거치지 않은 사람은 이 변화를 못 본다. 반면 경험자끼리는 팁을 공유하며 종착지를 논쟁한다.

로봇이 일하는 동안, 미뤄 둔 게임보이 타이틀을 꺼낸다. 로봇이 “계속할까요?” 물으면 yes를 치고 다시 테트리스.

이상하고, 살짝 섬뜩하다.

가속

미래가 어떻게 될지는 모르겠다. 이 여정을 거치지 않은 사람은 고용주에게 덜 매력적으로 보일까 봐 걱정된다. 그건 좀 근시안적이다. 결국 우리는 도구와 자동화 이야기니까.

과거 대규모 채용 때 우리는 네트워크나 기술 스택의 경계를 넓혀 사람을 뽑았다. 파이썬 회사인데도 파이썬을 전혀 모르는 개발자를 인터뷰했다. 뛰어난 엔지니어라면 함께 일하면서 파이썬을 익히면 된다고 믿었고, 실제로 대성공이었다. 종종 그들의 독특한 시각이 팀 전체 수준을 끌어올렸다.

AI 지원 개발도 마찬가지다. 팀 문화에 잘 맞고 열정적인 개발자라면 AI 도구 경험이 부족해도 괜찮다. 더 숙련된 팀원과 함께 일하면서 자기 속도로 배우게 하면 된다. 결국 그들도 운전대를 잡고 이 도구로 가치를 더하게 될 것이다.

또 하나 계속 드는 생각: 글쓰기 능력이 핵심이 됐다. 문서화와 협업에 원래도 중요했지만, 이제는 AI에게 명확하고 정밀한 지시를 내려야 한다. 효과적인 프롬프트를 짜는 능력이 좋은 코드를 쓰는 것만큼 중요해졌다.

리더십

믿든 말든, 모든 리더·엔지니어링 매니저는 AI 지원 개발에 깊이 잠수해야 한다. 이유는 간단하다. 앞으로 입사할 신세대 개발자들은 AI 도구와 에이전트를 통해 코딩을 배웠을 것이다. 그게 소프트웨어 엔지니어링의 미래다. 우리는 이 현실을 이해하고 적응해야 한다.

우리 같은 ‘코드 부머’는 오래 못 갈지도 모른다.

흥미로운 사실: 글을 쓸 때 나는 LLM을 거의 안 쓴다. 잘해 줄 것 같긴 하지만, 내 목소리가 ‘정규화’되는 게 싫다. 반면 내 코드는 정규화되는 게 좋다. 재밌지?

---

Jesse, Sophie, Vibez 크루(Erik, Kanno, Braydon 등), team 2389 그리고 피드백을 준 모든 분께 감사!