Agentic Coding vs Vibe Coding

SI에서 Nextjs 첫 프로젝트 반성 및 후기 글에서 잠깐 언급했던 것처럼, AI 코딩 툴이 정말 많이 발전했다.

1년 전에 정확히 같은 주제로 글을 썼던 것으로 기억하지만, 그때와는 너무나도 많은 것이 바뀌었다. 당시에는 agentic workflow 초창기였다면, 지금은 바야흐로 수많은 ai 코딩 툴이 등장하고 또 사라지는 시기인 것으로 보인다.

Cursor ide, Claude code, Gemini cli, Github Copilot...

GOAL

AI를 사용한 코딩에 대한 관념 및, 실제로 사용할 만 한가? 에 대한 재정리

Vibe coding 이란 무엇인가?

wikipedia 에서는 다음과 같이 정의한다.

Vibe coding이란 AI-assisted software development 을 쓰는 행위를 뜻함. chatbot을 사용해서 개발자가 요구 사항이나 태스크를 large language model (LLM)에 전달하고, 프롬프팅을 통해 소스 코드를 생성하는 행위이다. 개발자는 이 과정에서 코드 리뷰나 수정을 하지 않으며, 결과나 관리 툴을 통해 문제를 확인하고 수정을 프롬프팅하게 된다. 전통적인 AI의 도움을 받는 코딩이나 페어 프로그래밍과는 다르게, 인간인 개발자는 코드 리뷰를 하지 않으므로 생성된 소스 코드를 설명하지 않으며, 코드의 정확성이나 구조의 효율성 대신 프롬프팅을 통한 반복 생성 및 수정(iterative experimentation)을 더 중시한다.

따라서 내가 알고 있던 것과는 다르게 바이브 코딩이란 인간의 개입이 최소화 되는 것이다. 내가 지금까지 알고 있고, 활용하고 있던 바이브 코딩이라는 개념은 사실 AI-assisted coding인 것이고...

AI-assisted coding
pair programming
vibe coding
agentic coding?

1. AI assisted coding

내가 바이브 코딩인 줄 알고 해왔던 것. Cursor나 여러 ai 프롬프팅 인풋창에 실제로 물어보는 것. reddit about ai assisted coding 에서는 자신의 경험을 나와 거의 비슷하게 소개하고 있다.

내 경험에 따르면, 효과가 있었던 경우는 다음과 같습니다.

제가 경험을 해보지 않았던 분야: 잘 알고 있지 않는 경우의 일반적인 유즈케이스를 물어볼 때

어떤 특정한 테크 스택에 대한 정보가 필요할 때

한 번 쓰고 버릴 프로젝트일 때: 데모, MVP 등.

레거시 소프트웨어를 다룰 때: 여기에 공부할 시간을 ai로 단축할 수 있습니다.

[[언제 AI를 사용해야 할까]] 따라서 내가 전에 정리했던 케이스와 비슷하다고 생각한다.

2. Pair programming

전통적인 케이스. 이것은 내가 개발을 배울 때를 제외하고 많이 사용해 보지는 않았다.

3. Vibe coding

medium blog - vibe coding vs agentic coding 에 따르면 이렇게 정의함.

문제를 발견함 -> 자연어로 명령함 -> 모델이 써주는대로 확인함. 하지만 Andrew Ng가 경고한 바에 따르면, 현재 바이브 코딩의 문제는 여전히 코드의 구조, 보안, QA를 확인해야 한다는 것이다.

Vibe하게 MVP 데모나 배우는 목적에 유용함.

4. Agentic coding

자연어로 주어지는 어떠한 목표를 독립적인 에이전트들이 조합해서 해결하는 것. ex) 이 repo를 장고5로 업그레이드하고, 모든 테스트를 통과하게 해줘: 각각의 에이전트는 태스크를 계획하고, 파일을 수정하고, CI를 실행하며 pull-request까지를 실행한다.

실제 개발에서 필요한 여러 반복적인 작업을 줄여 준다. 특히 스케일이 큰 리팩토링과 같은 유지보수 작업에 유리함.

Production level에서 문제없이 사용할 수 있는지?

작년에는 내 짧은 이해도로 생각하면 ai의 발전이 아직 미흡하다고 느꼈다. 그렇다면 이번 기회에는 어떨까?

Brendan O'Neill 블로그 에서는 7명의 개발팀을 이끄는 저자가 agentic 코딩을 사용하며 정한 내부 룰을 소개하고 있다.

AI Slop을 피하기 위한 내부 룰. 과하게 복잡하고, 퀄리티가 낮고, 리뷰하기 힘든 코드가 생성되는 것.

1. Think Before You Generate

작업을 시작하기 전, 10~15분 동안 충분히 생각을 할 것.

프롬프트가 가장 간단한 단위의 작업을 수행하도록 할 것:

이 프롬프트가 어떤 커밋을 생성하게 될 것인가?
여러 단계로 나뉜 작업을 진행할 때 어떤 순서대로 진행할 것인가?
어떤 파일을 생성하게 할 것인가?
프롬프트에 어떤 레퍼런스 파일이나 코드를 첨부할 것인가?

그리고 워크스페이스에 밑준비를 한다:

새 파일을 생성하려 한다면 빈 파일을 직접 생성한다.
레퍼런스 파일이나 스니펫을 따로 정리해 놓는다.

명확한 셋업과 설계가 중요하다.

2. 일찍 그리고 자주 커밋할 것(가장 중요!)

ai가 잘못된 결과를 내놓았을 경우, git reset --hard로 곧바로 롤백해야 함. 만약 하기 망설여진 다면, 하나 이상의 작업을 커밋한 것임.

최대한 자주 커밋을 진행해 ai가 생성한 코드를 곧바로 되돌릴 수 있도록 할 것.,

리뷰 시에도 마찬가지.

작업자가 최소한의 단위를 프롬프팅하였는지?
하나의 커밋이 하나의 명확한 목적을 가지는지?
프롬프트에 의도에 맞게 생성되었는지?
하나 이상의 프롬프팅이 커밋에 반영되었는지?

3. 한 번에 한 파일만 작성할 것

4. 오버프롬프팅을 피할 것.

한 번에 두 가지 작업을 시키지 말 것.

이런 패턴이 발견될 경우:

프롬프트 작성
코드 리뷰
리젝트
표현을 바꿔서 다시 프롬프팅.

이 경우 ai가 실패했다면, 다시 프롬프트하지 말고 수동으로 처리해야 함. 이전 코드가 도움이 되지 않는다면 git reset --hard 한 뒤 원하는 작업을 수동으로 처리할 것.

조금씩 그림이 그려지는 것 같다. 이 규칙들은 '팀 단위에서 어떻게 Shared한 코드 베이스를 최대한 문제 없이 처리하는지?'에 대한 나름의 해결책이 될 거라고 생각한다.

위 규칙들을 적용해 Agentic 코딩을 직접 경험해보기로 했다.

아래의 아주 흥미로운 오픈 소스 ai 코드 툴을 찾을 수 있었다.

automaker

Your Autonomous AI Software Engineer. 코드를 카피-페이스트 하지 마세요. 에이전트가 직접 기획, 코딩, 수정까지를 진행하고 유저는 칸반 보드를 통해 태스크를 관리할 수 있습니다. 에이전트들을 병렬 관리해서 코드를 10배 빠르게 완성하세요.

여러가지 툴 중 해당 프로젝트에 끌렸던 이유는

해당 프로젝트는 4명의 개발자들이 실제 agentic coding으로 일주일(a week)만에 작성했다.
아직 베타 버전이라 개선의 여지가 있다.(코드의 변화하는 추이를 확인할 수 있다)
오픈 소스이다.
'비개발자를 위한'이라는 광고문구가 없다.

위 개념을 증명하기 위해 한번 실제로 해당 툴을 통해 Agentic Coding을 경험해보기로 하자.