No Vibes Allowed: AI 코딩의 환상을 깨고 진짜 문제를 해결하는 법

게시 2026/01/28 업데이트 2026/01/31

By BLUEBUG

51 분읽는 시간

프롤로그: “Vibes”라는 유혹

“Vibe coding”이라는 말이 있다. 직관적으로, 느낌대로 코딩한다는 의미다. 그리고 AI 코딩 도구의 등장 이후, 이 단어는 새로운 의미를 얻었다. AI에게 막연한 요청을 던지고, AI가 뭔가 그럴듯한 코드를 만들어내면, 그것을 받아들이는 방식. 겉보기에는 작동하는 것 같고, 테스트도 통과하는 것 같으니, “느낌상” 괜찮아 보인다. 그래서 머지한다.

HumanLayer의 Dex Horthy가 “No Vibes Allowed”라는 제목으로 강연을 연 이유는 명확하다. 이 “느낌대로” 접근법이 만들어내는 재앙을 너무 많이 봤기 때문이다. 그는 직설적으로 말한다. 복잡한 기존 코드베이스, 즉 브라운필드(Brownfield) 환경에서 AI 코딩 도구를 무분별하게 사용하면, 결과는 “slop”이다. 순수하고 희석되지 않은 난잡함.

우리는 이미 atmoio의 이야기를 통해 이 문제를 목격했다. 2년간 AI와 함께 코딩했지만, 결국 그가 발견한 것은 개별적으로는 그럴듯하지만 전체적으로는 엉망인 코드베이스였다. 그는 결국 다시 손으로 코드를 쓰기로 결정했다. “나는 이 코드로 사용자에게 거짓말하지 않겠다”는 선언과 함께.

그러나 Dex는 포기를 이야기하러 온 것이 아니다. 그는 해결책을 제시하러 왔다. 그 해결책의 이름은 “컨텍스트 엔지니어링(Context Engineering)”이다. 그리고 그 핵심은 놀랍도록 간단하면서도 깊이 있는 통찰로 시작한다. “LLM은 상태가 없다(stateless).”

근본적 한계의 이해: LLM은 기억하지 않는다

Dex의 출발점은 기술적이지만, 그 함의는 철학적이다. 대형 언어 모델은 상태를 갖지 않는다. 즉, LLM은 우리가 이전에 무엇을 이야기했는지, 프로젝트의 맥락이 무엇인지, 코드베이스의 구조가 어떤지 “기억하지” 않는다.

모든 것은 입력 토큰에서 시작된다. 우리가 프롬프트에 포함시킨 것, 그것이 전부다. LLM에게 세상은 매번 새로 시작된다. 이전 대화? 컨텍스트 윈도우에 포함되어 있지 않다면 존재하지 않는다. 프로젝트의 역사? 포함시키지 않았다면 모른다. 코드베이스의 복잡한 의존관계? 보여주지 않았다면 이해할 수 없다.

이것은 LLM의 결함이 아니다. 이것은 LLM의 작동 방식이다. 그리고 이 사실을 받아들이는 것이 효과적인 AI 코딩의 첫걸음이다.

Dex는 여기서 중요한 개념을 제시한다. “입력한 토큰 = 얻는 결과”. 이것은 단순한 등식이 아니다. 이것은 우리가 AI와 일하는 방식을 근본적으로 바꿔야 한다는 의미다.

좋은 프롬프트를 쓰는 것만으로는 충분하지 않다. 컨텍스트 윈도우에 무엇을 넣을지, 어떻게 구조화할지, 얼마나 압축할지. 이 모든 것이 결과의 품질을 결정한다. Dex는 이것을 “컨텍스트 엔지니어링”이라고 부른다. 그리고 그는 세 가지 기준을 제시한다.

정확성(Accurate): 컨텍스트에 포함된 정보가 맞아야 한다. 잘못된 정보, 오래된 정보, 관련 없는 정보가 들어가면 LLM은 잘못된 방향으로 간다.

완전성(Complete): 필요한 정보가 빠지면 안 된다. LLM은 추측할 수 있지만, 그 추측은 종종 틀리다. 특히 복잡한 비즈니스 로직이나 레거시 코드의 특수한 동작에 대해서는.

적절한 크기(Right-sized): 너무 많은 정보도 문제다. 그리고 여기서 Dex는 놀라운 발견을 공유한다.

“Dumb Zone”: 너무 많은 것도 문제다

컨텍스트 윈도우가 크다는 것은 좋은 일 아닌가? Claude Opus는 200k 토큰을 지원한다. GPT-4 Turbo는 128k. 그러니 최대한 많은 정보를 넣으면 되는 것 아닌가?

Dex는 고개를 젓는다. 그는 “Dumb Zone”이라는 개념을 소개한다.

연구 결과에 따르면, 컨텍스트 윈도우의 약 40%를 넘어서면 모델의 성능이 저하되기 시작한다. 왜일까? LLM은 긴 컨텍스트 안에서 중요한 정보를 놓치기 시작한다. 특히 컨텍스트의 중간 부분에 있는 정보는 무시될 가능성이 높다. 이것을 “lost in the middle” 현상이라고 한다.

200k 토큰 윈도우를 가진 모델이라고 해서 200k 토큰을 다 사용하면 안 된다. 오히려 40% 미만, 즉 약 80k 토큰 이하로 유지해야 모델이 최고 성능을 발휘한다.

이것은 역설적이다. 우리는 더 많은 컨텍스트가 더 나은 결과를 가져올 것이라고 생각한다. 그러나 실제로는 적절하게 선별되고 압축된 컨텍스트가 더 나은 결과를 가져온다.

여기서 핵심 질문이 등장한다. 그렇다면 어떻게 컨텍스트를 “적절하게” 관리할 것인가?

코드 리워크의 늪: 우리는 왜 계속 고치는가

Dex는 많은 개발자가 겪는 공통된 패턴을 지적한다. AI에게 작업을 맡긴다. AI가 코드를 생성한다. 코드를 실행해본다. 작동하지 않는다. 에러 메시지를 AI에게 보여준다. AI가 수정한다. 또 실행해본다. 또 다른 문제가 발생한다. 다시 AI에게 보여준다.

이 사이클이 반복된다. 10번, 20번, 때로는 그 이상. 그리고 결국 우리는 지쳐서 직접 코드를 고친다. 또는 “일단 작동하니까”라며 불안한 마음으로 머지한다.

Dex는 이것을 “코드 리워크(rework)”라고 부른다. 그리고 이것이 바로 “vibes coding”의 전형적인 결과라고 지적한다. 우리는 AI가 마법처럼 완벽한 코드를 만들어주기를 바란다. 그러나 AI는 우리가 제공한 컨텍스트 안에서만 작동한다. 그 컨텍스트가 불완전하거나 부정확하면, AI의 출력도 불완전하고 부정확하다.

그렇다면 문제는 AI가 아니다. 문제는 우리가 AI에게 제공하는 정보의 품질이다. 그리고 더 근본적으로는, 우리가 AI와 일하는 방식이다.

RPI: Research, Plan, Implement

Dex의 해결책은 명확한 구조를 갖는다. RPI. Research, Plan, Implement. 조사하고, 계획하고, 구현한다.

이것은 새로운 개념이 아니다. 사실, 이것은 소프트웨어 엔지니어링의 기본이다. 문제를 이해하고, 해결책을 설계하고, 코드로 구현한다. 그러나 AI 시대에 이 원칙은 새로운 의미를 얻는다.

Research: 객관적 진실을 찾아라

첫 번째 단계는 조사다. 그런데 Dex가 강조하는 조사는 우리가 보통 생각하는 것과 다르다.

“시스템이 어떻게 작동하는지 파악하라”는 것은 당연하다. 그러나 Dex는 더 구체적인 것을 요구한다. “관련 파일과 정확한 라인 넘버를 찾아라.”

왜 이렇게 구체적이어야 할까? 왜 “대충 이 모듈에서 인증을 처리한다”가 아니라 “auth/service.py의 145-167번 줄에서 토큰 검증을 수행한다”여야 할까?

이유는 명확하다. LLM은 우리가 제공하는 정보만큼만 정확할 수 있다. “대충 이 모듈”이라고 하면, LLM은 추측해야 한다. 그리고 추측은 틀릴 수 있다. 특히 복잡한 레거시 코드베이스에서는.

Dex는 “객관적 정보(objective information)”를 수집하라고 강조한다. 의견이나 추측이 아니라, 사실. 파일 이름, 라인 넘버, 함수 시그니처, 데이터 구조. 이런 것들은 객관적이다. 해석의 여지가 없다.

이것은 단순히 정확성의 문제가 아니다. 이것은 컨텍스트 압축의 문제이기도 하다. 정확한 라인 넘버를 제공하면, LLM은 전체 파일을 읽을 필요가 없다. 관련된 부분만 집중할 수 있다. 이것은 컨텍스트 윈도우를 효율적으로 사용하는 방법이다.

그리고 여기서 Dex는 흥미로운 기법을 소개한다. 서브 에이전트(Sub-agents).

서브 에이전트: 분할하여 정복하라

전체 코드베이스를 한 번에 분석하려고 하면 컨텍스트 윈도우가 폭발한다. 수십만 줄의 코드를 어떻게 200k 토큰 안에 넣을 것인가?

Dex의 답은 간단하다. 넣지 마라. 대신, 특정 작업을 수행하는 서브 에이전트를 띄워라.

예를 들어, 인증 시스템이 어떻게 작동하는지 알아야 한다면, “인증 관련 코드를 찾아 요약하라”는 임무를 가진 서브 에이전트를 만든다. 이 서브 에이전트는 코드베이스를 탐색하고, 관련 파일들을 찾고, 핵심 로직을 식별한다. 그리고 압축된 요약을 메인 에이전트에게 돌려준다.

메인 에이전트는 전체 코드를 볼 필요가 없다. 서브 에이전트가 정리한 요약만 보면 된다. 이것은 컨텍스트를 극적으로 줄인다.

이것은 마치 대기업의 조직 구조와 같다. CEO는 모든 세부사항을 알 필요가 없다. 각 부서의 임원이 자신의 영역을 관리하고, 요약된 보고서를 올린다. CEO는 그 요약을 바탕으로 의사결정을 내린다.

Dex가 제시하는 것은 AI 에이전트의 위계적 구조다. 각 에이전트는 자신의 전문 영역에서 작동하고, 상위 에이전트에게 압축된 정보를 전달한다. 이것은 우리가 앞서 본 12개 전문 에이전트 팀의 개념과 일맥상통한다.

Plan: 의도를 압축하라

조사가 끝나면, 다음은 계획이다. 그리고 여기서 Dex는 놀라운 통찰을 제시한다.

“계획은 의도의 압축(compression of intent)이다.”

무슨 뜻일까? 우리가 무언가를 만들고 싶을 때, 우리 머릿속에는 복잡한 아이디어가 있다. 여러 가능성, 트레이드오프, 제약사항, 예외 케이스. 이 모든 것을 한 번에 LLM에게 전달하려고 하면, 프롬프트가 길어지고, 컨텍스트가 부풀어 오르며, 결과는 엉망이 된다.

대신, 우리는 이 복잡한 의도를 명확하고 구조화된 계획으로 압축해야 한다.

Dex가 제시하는 계획 문서의 구조는 명확하다:

무엇을 할 것인가 (What)
왜 하는가 (Why)
어떻게 할 것인가 (How)
어떤 순서로 할 것인가 (Steps)
관련된 파일과 라인 넘버 (References)
필요하다면 코드 스니펫 (Snippets)

이것은 단순한 할 일 목록이 아니다. 이것은 구조화된 사양서다. 그리고 중요한 것은, 이 계획 문서는 인간이 작성하고 검토한다는 점이다.

여기서 Dex는 결정적인 원칙을 제시한다. “사고를 외주화하지 마라(Don’t outsource your thinking).”

사고의 외주화 금지: 인간은 여전히 중심이다

AI는 놀라운 도구다. 그러나 AI는 우리의 사고를 대체하는 것이 아니라 증폭시키는 것이어야 한다.

Dex는 명확히 한다. 조사 단계에서 AI는 정보를 수집할 수 있다. 그러나 그 정보가 맞는지, 완전한지, 관련 있는지는 인간이 검증해야 한다.

계획 단계에서 AI는 초안을 제안할 수 있다. 그러나 그 계획이 올바른 방향인지, 비즈니스 요구사항을 만족하는지, 장기적으로 유지보수 가능한지는 인간이 판단해야 한다.

이것은 “Human-in-the-loop”의 진정한 의미다. 인간은 단순히 AI의 출력을 승인하는 고무도장이 아니다. 인간은 각 단계에서 능동적으로 검토하고, 수정하고, 방향을 잡아준다.

Dex는 실제 사례를 공유한다. HumanLayer에서 그들은 RPI 워크플로우를 구현했다. 에이전트가 조사를 마치면, 그 결과를 인간 개발자에게 보여준다. 개발자는 검토하고 승인하거나 수정을 요청한다. 계획 단계도 마찬가지다. 에이전트가 계획을 제안하면, 개발자가 검토한다.

이것은 느린 것처럼 보일 수 있다. 그러나 역설적으로, 이것이 더 빠르다. 왜? 잘못된 방향으로 구현을 시작하는 것을 방지하기 때문이다.

atmoio의 경험을 떠올려보자. 그는 AI에게 큰 작업을 맡기고, 결과를 기다렸다. 그리고 몇 달 후 전체 코드베이스를 보고 “slop”을 발견했다. 만약 그가 조사와 계획 단계에서 개입했다면? 만약 그가 AI의 제안을 검토하고 방향을 잡아줬다면? 결과는 달랐을 것이다.

Implement: 낮은 컨텍스트로 높은 품질을

마지막 단계는 구현이다. 그리고 여기서 RPI의 진가가 드러난다.

잘 짜여진 계획이 있다면, 구현은 놀랍도록 간단해진다. 왜? 컨텍스트가 명확하고 압축되어 있기 때문이다.

예를 들어, 계획에 이렇게 써있다고 하자:

Step 3: Update token validation in auth/service.py
- Location: Lines 145-167
- Change: Replace hardcoded secret with environment variable
- Reference: config/settings.py lines 23-25 for env variable pattern
- Snippet:
  secret = os.getenv('JWT_SECRET')
  if not secret:
      raise ConfigurationError("JWT_SECRET not set")

이제 AI에게 구현을 맡기면, AI는 정확히 무엇을 해야 하는지 안다. 어떤 파일의 어느 부분을 수정해야 하는지. 어떤 패턴을 따라야 하는지. 어떤 에러 핸들링을 해야 하는지.

전체 코드베이스를 컨텍스트에 넣을 필요가 없다. 관련된 몇 개 파일, 그것도 특정 라인만 넣으면 된다. 컨텍스트는 작다. 그러나 정확하고 완전하다.

결과는? AI는 정확한 코드를 생성한다. 리워크가 없다. 또는 최소화된다.

이것이 Dex가 말하는 “No Vibes Allowed”의 진정한 의미다. 느낌대로 하지 말고, 체계적으로 하라. 추측하지 말고, 조사하라. 한 번에 모든 것을 하려 하지 말고, 단계별로 하라. 그리고 각 단계에서 인간이 검증하고 방향을 잡아라.

Mental Alignment: 팀의 정신적 정렬

Dex는 RPI의 또 다른 중요한 이점을 지적한다. “Mental Alignment”, 즉 정신적 정렬이다.

계획 문서는 단순히 AI를 위한 것이 아니다. 그것은 팀을 위한 것이기도 하다.

복잡한 기능을 구현할 때, 팀원들은 서로 다른 이해를 가질 수 있다. 한 사람은 이렇게 생각하고, 다른 사람은 저렇게 생각한다. 회의를 하고, 논의를 하고, 그래도 미묘한 오해가 남는다.

그러나 명확하고 구체적인 계획 문서가 있다면? 모두가 같은 것을 본다. 어떤 파일을 수정할 것인지, 어떤 순서로 할 것인지, 어떤 패턴을 따를 것인지. 오해의 여지가 줄어든다.

이것은 특히 AI와 인간이 협업하는 환경에서 중요하다. AI는 암묵적 지식을 갖지 못한다. “우리 팀은 보통 이렇게 한다”는 것을 모른다. 모든 것을 명시적으로 만들어야 한다.

그리고 그 명시화의 과정이 바로 계획 문서 작성이다. 우리가 계획을 명확히 쓰는 과정에서, 우리 자신의 생각도 명확해진다. 그리고 팀의 이해도 정렬된다.

Dex는 이것을 “의도의 압축(compression of intent)”이라고 불렀지만, 그것은 동시에 “이해의 정렬(alignment of understanding)”이기도 하다.

워크플로우의 재발명: SDLC의 AI 적응

Dex의 강연에서 가장 중요한 메시지는 마지막 부분에 나온다.

“중요한 것은 좋은 프롬프트를 쓰는 것이 아니다. 중요한 것은 팀의 워크플로우와 소프트웨어 개발 생명주기(SDLC)를 AI 중심 환경에 맞게 적응시키는 것이다.”

이것은 패러다임의 전환이다. 우리는 종종 AI를 기존 워크플로우에 “추가”하려고 한다. Copilot을 켜고, 평소처럼 코딩한다. 가끔 AI의 제안을 받아들인다. 이것이 AI 통합이라고 생각한다.

그러나 Dex는 말한다. 그것으로는 충분하지 않다. AI는 단순히 더 빠른 타이핑 도구가 아니다. AI는 우리가 소프트웨어를 만드는 방식 자체를 바꿀 수 있는 도구다.

그러나 그렇게 하려면, 우리가 먼저 바뀌어야 한다. 우리의 프로세스가, 우리의 워크플로우가, 우리의 팀 문화가 바뀌어야 한다.

RPI는 단순한 3단계 프로세스가 아니다. 그것은 AI 시대의 소프트웨어 개발 방법론이다. 그것은 다음을 전제한다:

명시적 지식: 모든 것을 문서화하고 명시화한다. AI는 암묵적 지식을 이해하지 못한다.
구조화된 정보: 정보를 체계적으로 조직한다. 파일 이름, 라인 넘버, 코드 스니펫. 모두 구조화되고 참조 가능해야 한다.
단계적 검증: 각 단계에서 인간이 검토하고 승인한다. 한 번에 모든 것을 하지 않는다.
컨텍스트 관리: 컨텍스트 윈도우를 의식적으로 관리한다. 너무 많지도, 너무 적지도 않게.
팀 정렬: 계획 문서를 통해 팀의 이해를 정렬한다. 모두가 같은 방향을 본다.

이것은 atmoio가 하지 못한 것이다. 그는 AI에게 큰 작업을 맡기고, 결과를 기다렸다. 중간에 검증 지점이 없었다. 명확한 계획이 없었다. 컨텍스트 관리가 없었다.

이것은 12개 에이전트 팀이 한 것이다. 명확한 역할 분리, 체계적인 문서 구조, 단계별 검증. 비록 그들이 “RPI”라는 이름을 쓰지는 않았지만, 그들은 본질적으로 같은 원칙을 따랐다.

99% AI 생성 코드의 세상에서

Dex는 강연을 놀라운 전망으로 마무리한다.

“99%의 코드가 AI에 의해 생성되는 세상이 올 것이다. 그러나 그 세상에서도 인간 개발자는 필수적이다. 왜? 품질을 보증하기 위해서. 방향을 제시하기 위해서. 책임을 지기 위해서.”

이것은 낙관적인 전망인가, 아니면 경고인가?

어쩌면 둘 다일 것이다.

99%의 코드가 AI에 의해 생성된다는 것은 엄청난 생산성 향상을 의미한다. 우리는 상상할 수 없었던 속도로 소프트웨어를 만들 수 있다. 한 사람이 과거의 10명, 100명의 일을 할 수 있다.

그러나 동시에, 이것은 엄청난 책임을 의미한다. 99%의 코드를 직접 쓰지 않았다면, 우리는 그 코드를 어떻게 이해하는가? 어떻게 검증하는가? 어떻게 책임을 지는가?

Dex의 답은 명확하다. RPI와 같은 체계적인 워크플로우. 각 단계에서의 인간 검증. 컨텍스트 엔지니어링을 통한 품질 관리.

우리는 더 이상 코드를 직접 타이핑하는 사람이 아니다. 우리는 AI를 오케스트레이션하는 사람이다. 조사를 지시하고, 계획을 검증하고, 구현을 감독하는 사람.

이것은 더 쉬운 역할인가? 아니다. 이것은 더 어려운 역할이다. 더 높은 수준의 이해를 요구한다. 더 체계적인 사고를 요구한다. 더 명확한 커뮤니케이션을 요구한다.

그러나 동시에, 이것은 더 영향력 있는 역할이다. 우리는 이제 10배, 100배의 코드를 생산할 수 있다. 그리고 그 코드의 품질은 우리의 컨텍스트 엔지니어링 능력에 달려 있다.

atmoio와 Dex 사이에서

atmoio와 Dex Horthy. 두 사람은 같은 문제를 다른 방식으로 접근했다.

atmoio는 AI 코딩을 시도했다가 실패했다. 그는 “slop”을 만들었고, 결국 다시 손으로 코드를 쓰기로 했다. 그의 결론은 “AI는 아직 준비되지 않았다”였다.

Dex는 같은 문제를 봤다. 많은 팀들이 AI로 “slop”을 만드는 것을. 그러나 그의 결론은 달랐다. “AI는 준비되었다. 우리가 준비되지 않았을 뿐이다.”

누가 맞는가?

어쩌면 둘 다 맞다.

AI 도구는 아직 완벽하지 않다. 환각(hallucination)을 만들고, 컨텍스트를 잃고, 예상치 못한 실수를 한다. 이런 의미에서 atmoio가 맞다.

그러나 동시에, 우리의 워크플로우도 준비되지 않았다. 우리는 여전히 AI를 “더 빠른 타이핑 도구”로 취급한다. 체계적인 컨텍스트 관리 없이, 명확한 검증 프로세스 없이 사용한다. 이런 의미에서 Dex가 맞다.

진실은 중간 어딘가에 있다. AI는 강력한 도구이지만, 올바른 방법으로 사용해야 한다. 그리고 그 “올바른 방법”은 우리가 아직 배우고 있는 중이다.

RPI는 하나의 답이다. 완벽한 답은 아닐 수 있다. 모든 상황에 맞는 답도 아닐 수 있다. 그러나 그것은 중요한 원칙들을 담고 있다:

체계적으로 접근하라
단계별로 검증하라
컨텍스트를 관리하라
사고를 외주화하지 마라
인간을 루프 안에 유지하라

이 원칙들은 보편적이다. 우리가 RPI를 따르든, 다른 방법론을 따르든, 이 원칙들은 유효하다.

12개 에이전트 팀의 성공을 다시 보다

이제 우리가 앞서 본 12개 에이전트 팀의 성공을 새로운 시각으로 볼 수 있다.

그들이 성공한 이유는 단순히 최신 AI 모델(Claude Opus 4.5)을 사용했기 때문이 아니다. 그들이 성공한 이유는 Dex가 말하는 원칙들을 따랐기 때문이다.

명확한 역할 분리: 12개 에이전트, 각각 전문 영역. 이것은 컨텍스트 관리다. 각 에이전트는 자신의 영역에만 집중하므로 컨텍스트가 작고 집중적이다.

체계적인 문서 구조: 01_planning/, 02_design/, 03_implementation/… 이것은 RPI의 구현이다. 계획하고, 설계하고, 구현한다.

단계별 검증: 사용자가 구축 범위를 제공하면, AI가 계획서를 작성하고, 사용자가 검토한다. 그다음 설계서, 그다음 구현. 이것은 “Human-in-the-loop”다.

컨텍스트의 명시화: 모든 것이 문서화되어 있다. 암묵적 지식이 아니라 명시적 문서.

그들은 의도적으로 RPI를 따른 것은 아닐 수 있다. 그러나 그들은 본질적으로 같은 원칙을 발견했다. 그리고 그것이 그들의 성공의 이유다.

실무 적용: 어떻게 시작할 것인가

Dex의 RPI를 우리의 일상적인 개발에 어떻게 적용할 수 있을까?

1단계: 작은 것부터 시작하라

전체 프로젝트를 RPI로 전환하려 하지 마라. 먼저 하나의 기능, 하나의 버그 수정부터 시작하라.

예를 들어, “사용자 프로필 편집 기능 추가”라는 작업이 있다면:

Research:

현재 사용자 데이터는 어디에 저장되는가? (models/user.py 라인 23-45)
프로필 화면은 어느 컴포넌트인가? (components/Profile.tsx 라인 67-120)
API 엔드포인트는 어떤 패턴을 따르는가? (routes/users.py 참고)

이것을 문서로 만들어라. research_profile_edit.md

Plan:

  
# Profile Edit Implementation Plan

## Objective
Add ability for users to edit their profile information

## Steps
1. Add PUT endpoint at /api/users/{id}
   - File: routes/users.py
   - After: line 156 (existing GET endpoint)
   - Pattern: Follow update_settings pattern from line 200
   
2. Update User model with validation
   - File: models/user.py
   - Lines to modify: 30-35 (add validators)
   - Reference: Email validation pattern from line 40
   
3. Add ProfileEditForm component
   - File: components/ProfileEditForm.tsx (new)
   - Pattern: Follow SettingsForm.tsx structure
   - API call: Use existing apiClient pattern from utils/api.ts
   
4. Add form to Profile component
   - File: components/Profile.tsx
   - After: line 85 (display section)

이것을 AI에게 검토받고, 수정하고, 승인하라.

Implement: 각 단계를 순서대로 AI에게 맡겨라. 그리고 각 단계의 결과를 검증하라.

2단계: 템플릿을 만들어라

RPI를 반복적으로 하다 보면, 패턴이 보인다. 그 패턴을 템플릿으로 만들어라.

  
# Research Template

## System Understanding
- What currently exists?
- How does it work?
- Where is the relevant code?

## References
- File: [path]
- Lines: [numbers]
- Key functions/classes: [names]

## Dependencies
- What does this depend on?
- What depends on this?

## Constraints
- What can't we change?
- What must we preserve?

  
# Plan Template

## Objective
[What we're trying to achieve]

## Why
[Business/technical justification]

## Steps
1. [First step]
   - Location: [file:lines]
   - Action: [what to do]
   - Pattern: [what to follow]
   - Snippet: [code example if helpful]

2. [Second step]
   ...

## Risks
[What could go wrong]

## Testing
[How to verify]

3단계: 팀과 공유하라

RPI는 개인의 방법론이 아니라 팀의 방법론이어야 한다.

팀 회의에서 RPI를 소개하라. 작은 성공 사례를 공유하라. “이번 주 profile edit 기능을 RPI로 했는데, 리워크가 거의 없었습니다. 계획 문서가 도움이 되었습니다.”

팀원들에게 계획 문서를 코드 리뷰에 포함시키라고 제안하라. Pull Request에 계획 문서를 첨부하면, 리뷰어가 맥락을 빠르게 이해할 수 있다.

4단계: 도구를 만들어라

RPI를 지원하는 도구를 만들어라.

예를 들어, GitHub Issue 템플릿에 Research/Plan/Implement 섹션을 추가하라.

  
## Research
// Link to research document or summary

## Plan  
// Link to plan document or inline plan

## Implementation Status
- [ ] Step 1: ...
- [ ] Step 2: ...
- [ ] Step 3: ...

또는 AI 에이전트 자체에 RPI 워크플로우를 구현하라. “Research mode”에서는 코드 생성을 하지 않고 정보 수집만 한다. “Plan mode”에서는 계획 문서만 작성한다. “Implement mode”에서만 코드를 수정한다.

5단계: 측정하라

RPI가 정말 도움이 되는지 측정하라.

리워크 사이클 수: AI 코드를 몇 번이나 고쳤는가?
First-pass 성공률: AI가 생성한 코드가 첫 번째 시도에서 작동한 비율은?
코드 리뷰 시간: 리뷰어가 코드를 이해하는 데 걸린 시간은?
버그 발견 시점: 개발 중? QA에서? 프로덕션에서?

RPI를 사용하기 전과 후를 비교하라. 데이터가 개선을 보여준다면, RPI는 효과적이다. 그렇지 않다면, 무엇이 잘못되었는지 분석하라.

여전히 남는 질문들

Dex의 RPI는 강력한 프레임워크다. 그러나 모든 질문에 답하지는 않는다.

복잡도의 한계는 어디인가?

RPI는 명확히 정의 가능한 작업에 효과적이다. “사용자 프로필 편집 추가”, “결제 API 통합”, “성능 최적화”. 이런 것들은 조사하고, 계획하고, 구현할 수 있다.

그러나 불명확한 문제는 어떻게 하나? “이 시스템이 왜 느린지 모르겠어요”, “가끔 크래시가 나는데 재현이 안 됩니다”, “전체 아키텍처를 재설계해야 합니다”.

이런 문제들은 조사 자체가 모호하다. 무엇을 조사해야 하는지 모른다. 계획은 더욱 어렵다. 무엇을 계획해야 하는지 모른다.

Dex의 RPI는 이런 “wicked problems”에는 덜 효과적일 수 있다.

학습은 어떻게 일어나는가?

RPI에서 AI는 주어진 계획을 따라 구현한다. 그러나 AI는 그 과정에서 무엇을 배우는가?

LLM은 stateless다. 한 작업에서 배운 것을 다음 작업에 자동으로 적용하지 못한다. 우리가 명시적으로 컨텍스트에 포함시키지 않는 한.

그렇다면 우리는 어떻게 AI를 “학습”시키는가? 매번 같은 것을 설명해야 하는가?

한 가지 방법은 “팀 지식 베이스”를 구축하는 것이다. 우리 팀의 코딩 패턴, 아키텍처 결정, 과거의 계획 문서. 이것들을 체계적으로 관리하고, 필요할 때 컨텍스트에 포함시킨다.

그러나 이것은 추가적인 작업이다. 누가 이 지식 베이스를 관리하는가? 어떻게 최신 상태로 유지하는가?

인간의 역량 저하는?

RPI에서 AI가 점점 더 많은 것을 한다. 조사도, 계획 초안도, 구현도. 인간은 검증하고 승인한다.

그런데 검증하려면 이해해야 한다. 이해하려면 지식이 있어야 한다. 그 지식은 어디서 오는가?

전통적으로 개발자는 직접 코드를 작성하면서 배웠다. 버그와 씨름하면서, 리팩터링하면서, 성능을 최적화하면서. 그 과정에서 깊은 이해가 형성되었다.

그러나 AI가 대부분의 코드를 작성한다면? 주니어 개발자는 어떻게 배우는가? 그들은 검증할 만큼 충분히 알게 될 수 있는가?

이것은 장기적으로 심각한 문제가 될 수 있다. 우리는 AI에게 의존하지만, AI를 제대로 검증할 능력을 잃을 수 있다.

비용은 지속 가능한가?

RPI는 여러 단계를 거친다. 조사를 위한 AI 호출, 계획을 위한 AI 호출, 구현을 위한 AI 호출. 그리고 서브 에이전트까지 사용한다면, 호출 횟수는 더 늘어난다.

Claude Opus 4.5나 GPT-4는 싸지 않다. 대규모로 사용하면 비용이 빠르게 증가한다.

모든 팀이 이 비용을 감당할 수 있는 것은 아니다. 특히 스타트업이나 작은 회사는.

비용과 품질, 속도 사이의 트레이드오프를 어떻게 관리할 것인가?

결론: 체계의 시대

Dex Horthy의 “No Vibes Allowed”는 단순히 AI 코딩의 기법을 설명하는 강연이 아니다. 그것은 패러다임의 선언이다.

“Vibes”의 시대는 끝났다. 느낌대로, 직관대로, 일단 해보고 고치는 방식. 이것은 AI 없이도 문제였지만, AI와 함께라면 재앙이다.

대신, “체계”의 시대가 왔다. 조사하고, 계획하고, 구현하는 체계. 컨텍스트를 관리하는 체계. 각 단계에서 검증하는 체계.

이것은 더 느린 것처럼 보인다. 더 번거로운 것처럼 보인다. 그러나 역설적으로, 이것이 더 빠르다. 왜냐하면 잘못된 방향으로 가는 것을 방지하기 때문이다. 리워크를 줄이기 때문이다. 품질을 유지하기 때문이다.

atmoio는 vibes의 길을 갔다. 그리고 slop을 만났다. 12개 에이전트 팀은 체계의 길을 갔다. 그리고 성공했다. Dex는 그 체계를 RPI라는 명확한 프레임워크로 제시했다.

우리는 어느 길을 갈 것인가?

선택은 명확해 보인다. 그러나 실행은 어렵다. 체계를 만드는 것은 쉽지 않다. 팀을 설득하는 것도 쉽지 않다. 기존 습관을 바꾸는 것도 쉽지 않다.

그러나 대안은 무엇인가? Slop을 만들고, 리워크에 시간을 허비하고, 결국 “AI는 준비되지 않았다”며 포기하는 것?

아니면 Dex가 제시하는 것처럼, 우리의 워크플로우를 진화시키는 것? SDLC를 AI 시대에 맞게 재설계하는 것? 그리고 99%의 코드가 AI에 의해 생성되는 미래에 대비하는 것?

나는 후자를 선택한다. 쉽지 않을 것이다. 실수도 할 것이다. 배워야 할 것도 많다.

그러나 적어도, 나는 vibes가 아니라 체계를 따를 것이다.

Research. Plan. Implement.

그리고 각 단계에서, 인간으로서 책임을 다할 것이다.

왜냐하면 99%의 코드를 AI가 쓰더라도, 100%의 책임은 여전히 인간의 것이기 때문이다.

참고 자료:

원 강연 영상: No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer
HumanLayer: https://humanlayer.dev

작성일: 2026-01-28

AI, Vibe Coding

AI Material Claude agentic-coding vibe-coding SDLC claude-agent orchestration-agents sub-agents Claude.write