진짜 '딸깍'으로 다 되나요? — 보수적 개발자가 AI 에이전트로 프로덕트를 릴리즈하며 깨달은 것들
발표 했던 내용을 AI로 내용을 정리하여 기록으로 남깁니다. AI로 정리하여 일부 내용은 발표했던 내용과 다를 수 있고, 오류가 있을 수 있습니다.
“AI로 딸깍 한 번이면 프로덕트가 나온다”는 이야기가 넘쳐나는 시대다. 바이브 코딩(Vibe Coding)이라는 말이 유행하고, 링크드인에는 매일 혁명적인 생산성 이야기가 올라온다. 하지만 현업에서 코드를 치는 엔지니어에게 이런 이야기는 여전히 현실과 동떨어져 있다.
이 글은 에이전틱 엔지니어링(Agentic Engineering) 관점에서, AI 에이전트(Claude Code)를 실전 프로덕트 개발에 투입하며 얻은 5가지 교훈을 정리한 것이다. 바이브 코딩의 한계를 넘어, 실제로 프로덕트를 릴리즈하려면 무엇이 필요한지 공유한다.
나는 스스로를 ‘보수적인 개발자’로 정의해왔다. 새로운 기술이 나오면 관망하고, 구독 서비스에 섣불리 돈을 내지 않는 스타일이다. AI 도구에 대해서도 “다들 호들갑이 심하네”라며 상황을 지켜본다.
이번에 K-DEVCON 커뮤니티 사이트를 개편하며 LLM 에이전트를 실전에 투입했고, 결국 월 100달러짜리 Claude Max 플랜까지 결제하게 되었다. 이 글은 그 과정에서 얻은 기술적, 전략적 교훈을 정리한 것이다.
바이브 코딩(Vibe Coding)에서 에이전틱 엔지니어링(Agentic Engineering)으로
2025년 2월 3일, 안드레이 카파시가 ‘바이브 코딩(Vibe Coding)’이라는 개념을 트위터에 올렸다. 분위기에 취해서 코드를 직접 쓰지 않고, 복사-붙여넣기만 했는데 결과물이 나왔고 그게 꽤 잘 동작하더라는 이야기였다. 이 단어는 빠르게 밈이 되어 업계를 휩쓸었다.
하지만 정확히 1년 뒤인 2026년 2월 5일, 카파시는 ‘에이전틱 엔지니어링(Agentic Engineering)’이라는 더 정교한 용어를 제시했다.
- 에이전틱(Agentic): 개발자가 직접 코드를 짜는 대신, 코드를 작성하는 에이전트를 관리하고 감독하는 역할을 수행한다.
- 엔지니어링(Engineering): 그 과정에 전문성이 필수적이며, 배우고 발전시켜야 하는 영역이다.
“LLM 에이전트가 어디로 흘러가는지에 대해서 엄격한 감독과 검증이 필요하다. 우리가 LLM 사용의 이점은 누리면서도 소프트웨어 품질은 떨어뜨리지 않아야 한다.”
실제로 나는 AI와 작업하면서 바이브보다는 싸움에 가까운 경험을 더 많이 했다. “하지 말라는 걸 왜 하고 있어?” 라고 한 순간이 한두 번이 아니었다. 현실은 ‘바이브’가 아니라 ‘엔지니어링’의 영역이다. 에이전트가 내놓는 아웃풋을 통제하고 검증할 수 있을 때, 비로소 기술은 가치를 발휘한다.
AI 코딩 비용: 토큰을 아끼지 마라, 개발자의 ‘흐름(Flow)’이 더 비싸다
처음에는 무료 플랜으로 시작했다. Gemini CLI 무료 플랜으로 스켈레톤을 뽑아냈는데, 첫 시작은 잘 됐다. 문제는 거기서 발전시켜 나가는 것이었다. 복잡한 것들을 추가할수록 원하는 형태가 안 나오거나, 20분이 지나도 끝나지 않거나, 사용량이 막히곤 했다.
Claude Pro로 올렸지만, 여전히 토큰이 빠르게 떨어졌다. 토큰이 남아 있으면 개발하고, 떨어지면 빨래하고 설거지하면서 알람을 맞춰두고 기다렸다. 이른바 ‘토큰 기반의 삶’을 살았다.
이 생활이 나쁘지는 않았지만, 곧 깨달은 것이 있다. 토큰 몇 달러를 아끼기 위해 개발자의 가장 소중한 자산인 ‘인지적 흐름(Flow)’이 끊기는 손실이 훨씬 크다는 것이다. 개발하다가 흐름 끊기는 것만큼 싫은 게 없지 않은가.
결국 월 100달러의 Claude Max 플랜으로 업그레이드했다. 이건 단순한 지출이 아니라 “더 많은 것을 만들 수 있는 가능성”에 대한 투자다. 흐름을 끊지 않고 병렬로 여러 에이전트를 돌리며 아웃풋을 뽑아내는 환경이, 대기 시간 때문에 멈춰 있는 것보다 압도적인 생산성 이득을 가져다준다.
병렬 실행과 워크트리
토큰을 충분히 확보한 뒤에는 병렬 실행을 적극 활용했다. 여러 터미널을 띄워 Claude Code를 동시에 돌리거나, Claude Code 안에서 서브 에이전트를 만들어 병렬로 처리하게 했다. 다만 같은 경로에서 작업하면 여러 작업 내역이 하나의 PR에 섞이는 문제가 있었다.
이 문제는 워크트리(Worktree)로 해결했다. 워크트리를 사용하면 작업을 분리해서 관리할 수 있고, Claude Code에서도 이를 지원한다. Mac 사용자라면 Conductor도 추천한다. 워크트리와 Git을 시각적으로 관리할 수 있어서 유용하다.
AI 디버깅: 직접 디버깅하지 마라, 에이전트에게 로그를 던져라
AI가 작성한 코드에서 에러가 발생했을 때, 나는 습관적으로 직접 코드를 뜯어보며 해결하려 했다. 토큰도 아껴야 했으니까. 에러 로그를 AI에게 던져줘도 해결을 못해서, 무의미하게 토큰만 소모되는 루프에 빠졌다.
그때 지인에게 결정적인 질문을 받았다.
“왜 그거를 네가 직접 해결하고 있어? 에이전트한테 던져서 직접 고치게 해야지.”
이건 중요한 발상의 전환이었다. 핵심은 에이전트를 단순한 ‘코드 생성기’가 아니라, 스스로 문제를 추론하고 해결하는 ‘주체’로 대우하는 것이다. 에러 로그와 테스트 실패 내역을 통째로 에이전트에게 던져서 원인 분석부터 수정까지 맡겨야 한다.
개발자의 역할은 문제를 직접 푸는 사람이 아니라, 에이전트가 문제를 풀 수 있도록 올바른 맥락을 제공하고 최종 판단을 내리는 ‘디렉터’가 되는 것이다. 물론 이를 위해서는 토큰을 아끼지 않을 수 있는 환경이 먼저 갖춰져야 했다.
AI가 작성한 코드를 어떻게 신뢰할까? 테스트 코드가 답이다
AI가 작성한 코드를 어떻게 믿을 수 있을까? 그 해답은 테스트 코드를 통한 강제적인 검증이다.
AI가 작성한 코드가 기존 코드에 영향을 미치지 않았다는 것을 증명하는 방법, 그건 테스트를 통과하는 것이다. 테스트 통과라는 명확한 기준이 있을 때, 비로소 AI의 속도를 온전히 누릴 수 있다.
테스트가 방어해야 할 것은 단순 로직만이 아니다.
- 코드 아키텍처: 아키텍처 테스트로 구조적 규칙을 강제
- 커버리지: 최소 커버리지 기준 설정
- 코드 퀄리티: 정적 검사 도구를 테스트 파이프라인에 포함
AI한테 “우리 팀이 원하는 방향”을 알려주는 가장 좋은 방법 중 하나가 테스트 결과를 전달하는 것이다. 문서화보다 더 명확하고, AI의 방향을 지나치게 좁히지 않으면서도 가드레일 역할을 해준다.
Claude Code 스킬(Skills)로 개발 생산성 높이기
백엔드 개발자도 SEO 점수를 높일 수 있었던 이유
K-DEVCON 사이트 개편 중 가장 흥미로웠던 것은, 백엔드 개발자인 내가 SEO 점수를 극적으로 개선한 사례다.
투 트랙 라우팅으로 SSR 없이 SEO 해결
프론트엔드와 백엔드를 분리해서 배포하는 것은 업계 표준이다. 그런데 웹 크롤러는 HTML을 그 자체로만 가져가지, JavaScript를 렌더링해서 분석하지 않는다. 이걸 처음 알았을 때 꽤 충격이었다.
보통 이 문제의 해결책으로 SSR(서버 사이드 렌더링)을 도입하라고 한다. 하지만 백엔드 개발자 관점에서 프론트엔드 서버를 별도로 구성하는 건 관리 포인트가 늘어나는 일이다. 상용 솔루션도 비용이 든다.
그래서 택한 전략이 투 트랙 라우팅이다.
- Backend: 콘텐츠가 생성/수정/삭제될 때 메타 태그가 포함된 정적 OG(Open Graph) HTML을 생성해서 공유 볼륨에 저장
- Nginx: User-Agent를 기반으로 분기. 일반 사용자는 React SPA로, 크롤러 봇은 미리 생성된 정적 HTML로 라우팅
SSR 도입 없이도 크롤러가 원하는 메타데이터를 제공할 수 있게 되었다.
SEO Skills로 개선 포인트 자동 진단
하지만 내가 직접 한 것만으로는 한계가 있었다. SEO 전문가가 아니니까. 그때 Claude Code의 Skills 중에 SEO 관련 스킬이 있다는 걸 알게 됐다. SEO 스킬을 실행하면 현재 사이트의 SEO 점수를 분석하고, 어떤 부분을 보완할 수 있는지 목록으로 뽑아준다.
이 목록을 다시 Claude Code에 던져서 “이런 것들을 보완해줘”라고 요청하면, 소스 코드를 확인해서 직접 수정해준다. 이 루프를 주 1회 정도 반복하면서 SEO를 지속적으로 개선해 나가고 있다. SEO처럼 본인의 전문 분야가 아닌 영역에서 특히 스킬의 효과가 크다고 느꼈다.
Lighthouse + Claude Code로 웹 퀄리티 개선
Lighthouse 결과를 JSON으로 추출한 뒤 Claude Code에 던져서 분석하게 했다. “우리 사이트에 지금 이런 문제가 있다고 하는데, 소스 코드를 확인해서 개선해줘”라고 요청하면 알아서 수정해준다. 프론트엔드 개발자라면 놓치지 않았을 포인트들도, AI의 도움으로 백엔드 개발자가 직접 해결할 수 있었다.
반복 작업을 스킬(Skills)로 템플릿화
같은 프롬프트를 반복해서 입력하는 게 귀찮아졌다. 예를 들어 “커밋되지 않은 변경 사항을 분석해서 테스트 코드를 작성해줘”라는 요청을 매번 타이핑하는 것은 비효율적이다.
Claude Code의 Skills 기능으로 이런 반복 작업을 템플릿화했다.
이런 스킬은 단순한 프롬프트가 아니라, 엔지니어의 노하우를 코딩 규약으로 이식한 결과물이다. 본인만의 반복 패턴이 있다면 스킬로 만들어두는 것을 추천한다.
에이전틱 엔지니어링 회고: AI가 채우지 못하는 ‘마지막 20%’
AI가 업무의 80%를 해결해 주는 시대가 왔다. 하지만 나머지 20%의 디테일을 채우고, 최종 결과에 대해 책임을 지는 것은 여전히 사람의 몫이다.
요즘 AI 활용과 관련해서 자극적인 이야기가 많다. 누군가는 엄청난 토큰을 태웠다고 하고, 코드를 수만 줄 추가했다고 한다. 실제로 확인해보면, 그런 케이스는 혼자서 한 분야를 담당하거나 실시간 서비스에 직접 영향을 미치지 않는 경우가 많았다. 너무 불안해할 필요는 없다.
AI는 수많은 ‘답변’을 줄 수 있지만, 우리 서비스의 맥락에 맞는 ‘방향’을 선택하는 것은 직접 경험해본 개발자만이 할 수 있다. 지식으로만 아는 것은 수용에 그치지만, 직접 경험하며 채워 넣은 디테일은 무기가 된다.
AI가 해준 답변을 무작정 수용하지 말고, “얘는 왜 이렇게 판단했지?”를 고민해봐야 한다. 그 과정에서 얻어가는 것이 분명히 있다. 알고 있으면 방향을 선택할 수 있지만, 모르면 수용밖에 할 수 없다.
AI는 책임을 지지 않는다. 오직 사람만이 책임을 지고 방향을 결정할 수 있다.
“당신은 AI 에이전트로 무엇을 만들어 보았고, 그 과정에서 어떤 디테일을 채웠나요?” 이제는 ‘딸깍’ 그 이상의 엔지니어링을 고민해야 할 때다.