모두가 AI가 내 코드를 대신 작성해 줄 것이라고 말했습니다. 그래서 저는 AI에게 AI 에이전트(AI Agent)를 코딩하는 것을 도와달라고 요청했습니다. 한 달 후, 강도 높은 코딩 단계와 깊은 성찰을 거치며 저는 답을 얻었습니다. 그리고 그 답은 제가 예상했던 것과는 달랐습니다.

이 프로젝트는 자기 교육(self-education)이라는 깊은 필요성에서 시작되었습니다. 저는 이것이 실제로 배후에서 어떻게 작동하는지 이해하고 싶었습니다. 따라서 이것은 제가 스크립트로 업무를 자동화한 이야기가 아닙니다. AI 열풍의 보닛을 들어 올리고, "바이브 코딩 (vibe coding)" 방식을 거부하며, 견고한 로컬 AI 에이전트를 처음부터 직접 구축하기로 결심했을 때 어떤 일이 일어나는지에 대한 이야기입니다.

여러분이 읽게 될 내용은 또 다른 AI를 만들기 위해 AI와 함께 한 달 동안 비대칭 페어 프로그래밍 (asymmetrical pair-programming)을 진행하며 얻은 가감 없고 솔직한 회고록입니다.

정확히 무엇에 대해 이야기하고 있는 걸까요? (프로젝트)

맥락을 설명하자면, Vibrisse Agent는 단순한 채팅이나 터미널의 또 다른 API 래퍼 (API wrapper)가 아닙니다. 이것은 "로컬 우선 (local-first)" 하이브리드 아키텍처로 설계된 자율 에이전트 (autonomous agent, Python / LangGraph)입니다. 기본적으로 여러분의 기기에서 실행되지만 (Ollama 또는 vLLM을 통해 — *참고: Mac 사용자라면 oMLX가 정말 최고입니다! 🔥_), 복잡도에 따라 특정 작업을 클라우드 (Groq, OpenRouter)로 동적으로 위임할 수 있습니다.

사양은 야심 찼습니다:

• MCP (Model Context Protocol) 통합: 오픈 소스 생태계의 실제 도구들과 연결하기 위함입니다. 저장소와 PR을 탐색하기 위한 GitHub, 로컬 데이터베이스를 쿼리하기 위한 SQLite, 최신 문서에 접근하기 위한 Context7, 그리고 웹과 상호작용하기 위한 Fetch가 포함됩니다.
• 멀티모달 비전 (Multimodal vision): (Gemma 4와 함께) UI를 실시간으로 분석합니다.
• 온보딩 위저드 (Onboarding Wizard): 동적인 프롬프팅 (prompting) 시스템과 결합됩니다.

• 무엇보다도, 고스트 모드 (Ghost Mode): 소스 코드 주석(// @vibrisse: refactor this loop)에서 직접 백그라운드에서 에이전트를 구동할 수 있는 기능 덕분에, 더 이상 창을 전환할 필요가 없습니다.

단순한 데모가 아니라 진짜 "제품 (product)"을 만들고 싶다는 이러한 요구 수준이 바로 저의 초기 가설들을 완전히 깨뜨려 놓았습니다.

"바이브 코딩 (Vibe Coding)"의 신화

현재 복잡한 애플리케이션을 만드는 데 필요한 것은 오직 프롬프팅 (prompting)뿐이라는 생각이 널리 퍼져 있습니다. 이것이 바로 우리가 "바이브 코딩 (vibe coding)"이라고 부르는 것입니다. 프롬프트를 작성하면 AI가 코드를 내뱉고, "실행"을 클릭하면 붐 — SaaS가 탄생하는 식이죠.

진실은 무엇일까요? 단순한 CRUD 애플리케이션이라면 그 말이 전적으로 맞습니다. 하지만 엄격한 컨텍스트 관리 (context management), 결정론적 도구 실행 (deterministic tool execution), 그리고 상태 지속성 (state persistence)이 필요한 시스템을 구축하기 시작하는 순간... 그 "바이브 (vibe)"는 매우 빠르게 사라집니다.

제가 직면한 주요 문제는 컨텍스트 관리 (context management) (그 유명한 "중간에서의 상실 (Lost in the Middle)")였습니다. 머릿속에 떠오르는 질문들을 AI에게 연쇄적으로 던지며 흐름에 몸을 맡기기는 매우 쉽습니다. 이는 자연스럽고 짜릿한 경험이지만, 대화 속에 엄청난 양의 "노이즈 (noise)"를 생성합니다. 가드레일 (guardrails)이 없다면 결국 막대한 컨텍스트 손실을 겪게 됩니다. 모델은 두 시간 전에 결정된 사항을 잊어버리고, 세션은 표류하며, 코드는 깨져버립니다.

해결책은 마법 같은 새로운 모델이 아니었습니다. 그것은 엄청난 양의 규율과 순수한 소프트웨어 엔지니어링 (software engineering)이었습니다. 즉, 엄격한 세션 파일 (ROADMAP.md), 지속적인 메모, 그리고 명시적인 아키텍처 추적 (architectural tracking)이었습니다.

왜 사용하지 않고 직접 만드는가?

여러분은 아마 이렇게 궁금해하실 수도 있습니다: Cursor, Copilot, 그리고 이제는 Claude Code까지 존재하는데, 왜 굳이 바퀴를 다시 발명하려 하는가?

솔직한 답변은 이렇습니다: 기저에 깔린 메커니즘 (mechanics)에 대해 눈을 감지 않기 위해서입니다. 직접 구축할 때 얻는 진짜 이점은 무언가 고장 났을 때 (그리고 실제로 자주 고장 납니다), 왜 그런 일이 발생했는지 정확히 알고 어떻게 고쳐야 하는지 알게 된다는 점입니다.

단, 한 가지 엄격한 조건이 있습니다. 바로 생성된 코드의 모든 줄, 패턴, 그리고 로직을 이해하는 것입니다. AI의 제안에 이의를 제기할 수 있는 이러한 관점이 없다면, 당신은 제가 **"헬 루프 (hell loops)"**라고 부르는 상황에 빠르게 빠지게 됩니다. 즉, AI는 자신의 컨텍스트 오류 (context errors)를 수정하려고 뱅뱅 돌기만 하고, 인간은 결국 무슨 일이 일어나고 있는지 이해하기를 포기하게 되는 상태를 말합니다.

아무도 인정하지 않는 사실:
AI가 없었다면 이 프로젝트는 지금과 같은 형태로 존재하지 않았을 것입니다. 저에게는 이렇게 빠르게 진행할 시간도, Python에 대한 깊은 기초 지식도 없었습니다. AI (저의 경우 Gemini)와 협업함으로써, 저는 새로운 언어를 처음부터 배우는 기술적 마찰 (technical friction) 대신 **비전과 아키텍처 (vision and architecture)**에 온전히 집중할 수 있었습니다.

하지만 여기에 함정이 있습니다. LLM (Large Language Model)은 고립된 함수 (isolated functions)를 작성하는 데는 탁월하지만, 전역 아키텍처 (global architecture)를 설계하고 유지 관리하는 데는 재앙적인 수준입니다. 저의 15년 웹 개발 경험이 없었다면, 이 프로젝트는 완전히 유지보수가 불가능한 3,000줄짜리 스파게티 코드인 main.py 파일로 끝났을 것입니다.

도움을 받는 개발 단계 사이마다, 저는 프로젝트를 최신 상태 (state of the art)로 유지하고 사람이 읽을 수 있도록 하기 위해 엄격한 "정리" 및 리팩터링 (refactoring) 단계 (관심사 분리 (separation of concerns), SOLID 원칙)를 강제로 적용해야 했습니다. AI가 서둘러 "패치 (patched)"한 코드를 다시 쓰기 위해 직접 손을 더럽혀야 하는 경우도 자주 있었습니다.

언제 답변에 이의를 제기해야 하는지, 언제 방향이 근본적으로 잘못되었다고 느껴야 하는지, 그리고 당장은 "작동"하지만 사흘 뒤면 깨져버릴 솔루션을 언제 거부해야 하는지 — 이것은 프롬프트 (prompt)에서 오는 것이 아닙니다. 그것은 경험에서 옵니다.

오늘날 대다수의 개발자가 AI를 사용하고 있습니다 (Stack Overflow에 따르면 약 76%). 하지만 여전히 두 가지 거짓말이 유포되고 있습니다.

1. "AI가 모든 것을 하므로, 당신은 아무것도 알 필요가 없다."
2. "진정한 개발자는 AI가 필요 없다."

현실은 경험이 협업을 생산적으로 만들었고, 그 협업이 경험을 새로운 도메인에 적용 가능하게 만들었다는 것입니다. 이것은 마법이 아니라, 스마트한 엔지니어링 (smart engineering)입니다.

비대칭 페어 프로그래밍 (Asymmetrical Pair-Programming): 그들이 말해주지 않는 것

AI와 페어 프로그래밍 (Pair-programming)을 할 때, 그 역학 관계는 매우 비대칭적입니다.

AI는 무차별적인 힘 (Brute force)을 가져옵니다. AI는 즉각적으로 파일을 읽고, 몇 초 만에 보일러플레이트 (Boilerplate) 코드를 생성하며, 지치지 않고 문서를 파헤칠 수 있습니다.
개발자인 당신은 아키텍처에 대한 거부권 (Architectural veto)과 비즈니스 비전을 가져옵니다.

이해해야 할 한 가지 필수적인 사실은, 클라우드 AI (Cloud AI)는 본질적으로 수용적이라는 점입니다. AI는 당신이 제안하는 것에 대해 종종 "과도하게 의욕적"입니다. 때때로 제가 기술적인 벽에 직면했을 때, 저는 순수한 개발자의 태도에서 벗어나 AI와 논의해야 했습니다. 저는 AI에게 엄격한 역할("당신은 숙련된 AI 엔지니어입니다...")을 부여하고 그 접근 방식에 이의를 제기해야 했습니다. 그러자 갑자기 "불가능합니다"라는 답변이 대안에 대한 구체적이고 유의미한 분석으로 바뀌었습니다.

제가 배워야 했던 규율은 "생각을 소리 내어 말하기 (Thinking out loud)" 세션을 구축하는 것이었습니다. 각 단계를 진행하기 전에, AI에게 지금까지 무엇을 했는지, 무엇을 할 것인지, 그리고 그 이유는 무엇인지 요약해 달라고 요청하세요. 그 영향(Impacts)에 대해 논의하세요. 순수한 코드에서 한 걸음 물러나 비전에 집중하고, 나의 생각을 AI에게 전달해야 합니다.

"인간 참여형 (Human-in-the-Loop)"과 인터랙티브 아티팩트 (Interactive Artifacts)

가장 큰 깨달음 중 하나는 자율 에이전트 (Autonomous agent)가 모든 것을 혼자서 다 해서는 안 된다는 사실을 깨달은 것이었습니다. 복잡한 작업(아키텍처를 재구축하는 것과 같은)을 위해, 저는 "아키텍트 (Architect)" 모드를 설계해야 했습니다.

에이전트가 한 번에 500줄의 코드를 쏟아내는 대신, "아티팩트 (Artifact)"에 담긴 상세한 계획을 생성합니다. 인터페이스는 이를 가로채 실행을 일시 중지하고, 승인 버튼이 포함된 깔끔한 인터랙티브 렌더링 (Interactive render)을 저에게 보여줍니다.

그곳에서 마법이 일어납니다. 에이전트가 파일을 수정하기 위해 도구(tools)를 사용하기 전에, 저는 그 계획을 검토할 수 있습니다. 시스템의 핵심에 통합된 이 거부권(veto right)은 모든 것을 바꿉니다. 당신은 프로젝트를 예측 불가능하게 망가뜨리는 "블랙박스 (black box)" AI에서, 초안을 제출하는 진정한 동료로 넘어가게 됩니다.

이중 학습 곡선 (아무도 예상하지 못한 부분)

이 여정에서 얻은 가장 예상치 못한 통찰은 AI를 구축하는 법을 배우는 것이 AI를 사용하는 법을 가르쳐 준다는 점입니다.

한 달간의 개발 기간 동안, 두 개의 평행한 학습 곡선이 동시에 펼쳐졌습니다.

엔지니어링 측면에서는, 모델에 다음과 같은 것들이 필요하다는 것을 배우게 됩니다:

• 신선하고 정확한 컨텍스트 (너무 많지도, 아무것이나 되어서도 안 됨).
• 모델이 경로를 이탈하지 않도록 하는 명시적인 제약 조건 (explicit constraints).
• 2시간 전에 내린 결정을 "망각"하는 것을 방지하기 위한 정기적인 요약.
• 깔끔한 모듈화 (modularity)를 보장하기 위해 무엇을 구축할 것인지에 대한 명확한 비전.

사용자 측면에서는, 결국 자신에게도 정확히 똑같은 규율을 적용하게 됩니다:

• 세션을 재개하기 전에 세션을 요약할 것.
• 맹목적으로 신뢰하는 대신 모든 답변에 의문을 제기할 것.
• 세션이 경로를 이탈하는 시점, 답변이 환각 (hallucination)을 일으키거나 시대에 뒤처지는 시점을 파악하고, 언제 새로 시작해야 하는지를 알 것.

_"맥락을 절대 놓쳐서는 안 되는 에이전트를 구축함으로써, 나는 마침내 내가 AI를 사용할 때 왜 맥락을 놓쳤는지를 이해하게 되었다."

물론 스스로를 훈련시키기 위한 훌륭한 리소스들은 존재하지만, 세션이 탈선할 때 대처하는 본능은 오직 직접 구축해 봄으로써만 진정으로 얻을 수 있습니다.

모델은 설계부터 게으르다

우리는 "아키텍트 AI (Architect AI)" (내가 코딩할 때 사용한 Gemini)와 "워커 AI (Worker AI)" (내가 Vibrisse에 통합한 로컬 Gemma e4b / 26b 모델)를 명확히 구분해야 합니다.

아키텍트 AI가 코드를 생성하는 데 탁월하다면, 로컬 워커 AI는 설계부터 게으릅니다. 제약 조건이 없다면, 거대언어모델 (LLM)은 저항이 가장 적은 경로를 택합니다. 모델은 최선의 해결책을 찾는 것이 아니라, 수용 가능한 해결책을 찾습니다.

구체적인 발견: 만약 7B 모델을 엄격한 가드레일 (guardrails) 없이 방치한다면, 그 모델은 결국 새벽 3시에 // ... rest of the code here라고 작성할 것입니다. 하지만 주의하십시오, 이는 클라우드 (Cloud) 모델에서도 마찬가지입니다! 특히 컨텍스트 윈도우 (context window)가 포화 상태가 될 때 더욱 그렇습니다. 모델의 자연스러운 순응성과 결합된 이러한 게으름은, 당신이 흐름을 놓칠 때까지 AI가 당신 없이도 빠르게 진행하도록 방치하게 만듭니다.

이러한 게으름에 대한 해답은 초구조화된 프롬프트 (ultra-structured prompts)입니다. 경험은 여전히 대체 불가능합니다. AI 대신 일을 하기 위해서가 아니라, AI가 정확히 언제 실패하고 있는지를 알기 위해서 말입니다.

(다음 기사 5b에서는 견고한 3계층 파싱 (3-layer parsing)을 통해 우리가 이 문제를 정확히 어떻게 해결했는지 설명하겠습니다. 계속 지켜봐 주세요.)

UX/UI의 결정적 중요성

또 다른 중요한 교훈은, 에이전트 (agent)를 만들 때 UX와 UI는 선택 사항이 아니라는 점입니다. 특히 응답이 클라우드 (Cloud)보다 덜 "즉각적"일 수 있는 로컬 환경에서는 더욱 그렇습니다.

사용자에게 최대한의 피드백을 제공해야 합니다. 모든 동작에는 눈에 보이는 반응이 있어야 하며, 그렇지 않으면 에이전트가 충돌했다고 생각하게 됩니다. 유동적인 느낌을 조성하고, 읽기 편안함을 배려하며, 오류를 우아하게 처리하는 것... 좋은 인터페이스를 구축하는 것(제가 Vibrisse에서 구현한 대화형 _Thought Graph_와 같은 방식)은 사용자 경험을 통해 AI의 기계적 한계를 보완하는 것입니다.

또한 이는 상호작용을 재고하는 것에 관한 것이기도 합니다. 에이전트의 궁극적인 목표는 당신의 IDE 옆에 있는 또 다른 챗봇 (chatbot)이 되는 것이 아닙니다. 목표는 에이전트가 보이지 않게 되어 당신의 워크플로 (workflow)에 통합되는 것입니다 (제가 "고스트 모드 (Ghost Mode)"라고 부르는 방식입니다).

직업의 현주소: 죽지도 않았고 변하지 않은 것도 아니다

개발자들이 사라질까요? 아닙니다. 하지만 직업의 성격이 변하고 있습니다.

우리는 환희의 단계를 지나 성숙의 단계로 진입하고 있습니다. AI는 더 많은 코드를 생성하고, 이는 더 복잡한 시스템으로 이어지며, 결과적으로 아키텍트 (architect) 개발자에 대한 엄청난 수요를 창출합니다. 이것은 **코드에 적용된 제번스의 역설 (Jevons Paradox)**입니다. 코드 생산을 더 효율적으로 만들수록, 복잡한 시스템에 대한 수요는 폭발적으로 증가합니다.

새로운 개발자 프로필은 가장 빠르게 타이핑하는 사람이 아닙니다. 오케스트레이션(Orchestrate)하고, 도전하며, 검증(Validate)하는 방법을 아는 사람입니다.

결론: 마법이 아닌 도구로서의 AI

주변의 소음들에 대해 솔직하게 답해봅시다. _"나는 2일 만에 내 SaaS를 코딩했다, 개발자는 끝났다"_라고 주장하는 사람들에게 말이죠:

"그럴지도 모릅니다. 하지만 당신은 아직 모든 것을 망가뜨리는 버튼을 누르지 않았을 뿐입니다."

AI로 CRUD를 생성하는 것은 빠릅니다. 하지만 컨텍스트(Context)를 안정적으로 관리하고, 중요한 데이터에 대해 환각(Hallucination)을 일으키지 않으며, 모델의 동작이 변할 때도 견뎌낼 수 있는 프로덕션 시스템(Production system)을 구축하는 것은 전혀 다른 이야기입니다. 보안, 에러 처리(Error handling), 성능 최적화(Performance optimization), 머신 리소스 관리(RAM/VRAM)... 오직 경험만이 가져다줄 수 있는 고려해야 할 사항들이 너무나도 많습니다.