개발자에서 'AI 빌더'로: AI의 'if' 지옥에서 탈출하기

AI가 코드를 짜주니 편하신가요? 축하합니다. 당신의 서비스는 지금 'if 지옥'으로 급행 중입니다.

"AI가 짜준 코드로 기능은 돌아가는데, 왜 내 서비스는 점점 스파게티가 될까?" 20년 차 CTO가 직접 겪은 AI 코딩의 임계점과 그 해결책. AI의 게으른 'if 도배'를 멈추고, 지속 가능한 수익형 제품을 위한 Container/Presenter 패턴과 라우트 분리 전략을 공개합니다.

---

1~3편에서 빌더의 마인드셋과 데이터 지표를 다뤘다면, 4편은 제가 직접 서비스를 개발하며 겪은 'AI와의 치열한 주도권 싸움'에 대한 기록입니다.
AI에게 코딩을 맡겼을 때, 어느 지점에서 '개발자의 직관'이 개입해야 하는지 그 생생한 복기 내용을 공유합니다.

---

1. 문제 발생: 비즈니스 지표를 위한 '샘플 모드'의 명분

서비스를 운영하다 보면 개발자의 시야는 '기능'에서 '유저'와 '데이터'로 옮겨가야 합니다.

• 비즈니스 니즈: 유저들이 '로그인' 단계에서 대거 이탈하는 것을 확인했습니다. "일단 구경이라도 시켜야 가입을 한다"는 마케팅적 판단이 섰습니다.
• 기술적 방어선: 원래 인증(Auth)은 무분별한 LLM API 호출과 비용 낭비를 막기 위한 핵심 방어선이었습니다.
• 충돌: 보안을 위해 쳐놓은 '인증'과 유저 확보를 위한 '샘플'이 서로를 괴롭히는 상황이 발생했습니다.

단순히 화면 하나 더 만드는 문제가 아니라, 비즈니스 가치와 시스템 보안이 충돌하는 설계의 숙제가 던져진 것입니다.

---

2. 해결기: '바이브 코딩'의 취기에서 깨어나기

처음엔 저도 AI(Opus/Gemini)가 알아서 잘 비벼줄 것이라 생각했습니다. 일종의 '바이브 코딩(Vibe Coding)'에 취해 있었던 거죠.

---

[1단계: 땜질의 징후와 의심]

기존 page.tsx와 layout을 재사용하며 샘플 데이터를 얹으려 하자, 코드가 꼬이기 시작했습니다.
실전 모드는 인증을 거쳐야 하고 샘플은 패스해야 하는데, 같은 소스를 쓰다 보니 곳곳에서 인증 에러가 터졌습니다.
AI에게 수정을 맡길수록 화면은 깨지고 잘 되던 기능까지 먹통이 되었습니다.

---

[2단계: 토큰 낭비를 멈추는 구조적 결단]

하나 고치면 하나 깨지는 '땜질'은 토큰 비용과 시간의 엄청난 낭비입니다.
저는 여기서 깨달았습니다. 제가 너무 편하게 일을 시키고 있었다는 것을요.

• 명령: "수정하지 말고, 현재 구조의 문제점을 먼저 분석해서 보고해."
• 전략: Next.js 프레임워크의 본질에 맞게 라우트(Route)를 완전히 분리하고, UI와 로직을 찢는 최종 계획을 세우게 했습니다.

---

3. 노하우: "속도에 속지 마라, 당신은 여전히 개발자다"

AI가 코드를 워낙 잘 짜주니 속도가 붙습니다. 여기서 빌더들이 가장 많이 실수합니다.

• 속도의 함정: 코딩이 빠르니 검토를 생략하고 다음 기능으로 넘어갑니다.
  하지만 AI가 짠 코드일수록 본인이 직접 코딩할 때처럼 하나씩 살펴보고 테스트해야 합니다.
• 최소한의 안전장치: 무작정 배포하지 마세요. 최소한 유닛 테스트(Unit Test) 정도는 거쳐야 합니다.
  AI는 '동작하는 코드'를 주지만 '결함 없는 코드'를 보장하진 않습니다.

---

4. 방법론: 상황 설명이 설계의 시작이다

무작정 유명한 패턴을 적용하는 게 능사가 아닙니다. 지금 내 서비스의 상태를 보고 설계해야 합니다.

• 힌트 얻기: 아키텍처가 고민될 땐 AI에게 "이거 어떻게 분리해?"라고 묻지 마세요.
  대신 현재의 구현 상황과 코드 구조를 상세히 설명하고 "여기서 발생할 수 있는 잠재적 구조 결함이 뭐야?"라고 물으세요.
• 판단은 빌더의 몫: AI가 Container/Presenter 패턴을 제안했을 때, 저는 제 서비스의 규모와 Next.js의 특성에 비추어 그것이 최선임을 판단했습니다.
  계획을 보고 받고 검토한 뒤 실행하는 주도권, 그것이 빌더의 핵심 역량입니다.

---

✅ AI 빌더를 위한 체크리스트 (심화 편)

[ ] 잘 되던 기능이 꼬일 때, AI의 땜질을 의심하고 직접 소스(Architecture)를 확인했는가?
[ ] '바이브 코딩'에 취해 계획 없는 수정을 반복하며 토큰을 낭비하고 있진 않은가?
[ ] AI가 짠 코드에 대해 최소한의 유닛 테스트와 로직 검토를 직접 수행했는가?
[ ] 아키텍처가 막힐 때 상황을 상세히 설명하여 AI로부터 설계의 힌트를 끌어냈는가?
[ ] 코딩 속도보다 '설계와 계획의 밀도'에 더 많은 에너지를 쏟고 있는가?

---

마치며: 잊지 마라, 당신은 '개발자'라는 것을

AI가 코드를 짜주니 편하신가요? 하지만 그 편안함이 당신의 설계 본능을 잠재우게 두지 마세요.
인증과 샘플 모드가 충돌할 때, 화면이 깨질 때, 그 문제를 직시하고 아키텍처를 뒤집을 수 있는 힘.
그것이 비전공자 빌더는 절대 가질 수 없는 당신만의 '진짜 해자(Moat)'입니다.
 
코딩이 먼저가 아니라, '계획'이 먼저입니다.
비즈니스 문제를 해결하려다 시스템 전체를 망가뜨리는 우를 범하지 마세요. 잊지 마세요.
당신은 단순한 도구 사용자가 아니라, 무질서한 코드에 질서를 부여하는 '아키텍트'입니다.

---

이글에서 설명하는 개념을 실제로 보고 싶다면?

2026.04.21 - [AI 빌더] - 작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오

작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오

 

---

Next Action:
기획의 완결성에 목매는 이들과 구조의 유연함으로 승부하는 이들의 결정적 차이. 5편 "비전공자는 넘을 수 없는 보이지 않는 벽"에서 뵙겠습니다.
 
[AI 빌더 시리즈]
1. 개발자에서 'AI 빌더'로: 코딩 너머의 성패를 가르는 한 끝 차이
2026.01.12 - [AI, 실무에 담은 기록] - 개발자에서 'AI 빌더'로: 코딩 너머의 성패를 가르는 한 끝 차이

개발자에서 'AI 빌더'로: 코딩 너머의 성패를 가르는 한 끝 차이

 
2. 개발자에서 'AI 빌더'로: 나만의 'AI 사수'로 제품의 한 끝을 채우는 실전 가이드
2026.02.03 - [AI, 실무에 담은 기록] - 개발자에서 'AI 빌더'로: 나만의 'AI 사수'로 제품의 한 끝을 채우는 실전 가이드

개발자에서 'AI 빌더'로: 나만의 'AI 사수'로 제품의 한 끝을 채우는 실전 가이드

 
3. 개발자에서 'AI 빌더'로: AI로 만든 내 서비스, 첫 유저 100명 모으는 법
2026.02.27 - [AI, 실무에 담은 기록] - 개발자에서 'AI 빌더'로: AI로 만든 내 서비스, 첫 유저 100명 모으는 법

개발자에서 'AI 빌더'로: AI로 만든 내 서비스, 첫 유저 100명 모으는 법

 
4. 개발자에서 'AI 빌더'로: AI의 'if' 지옥에서 탈출하기 <- 현재 글

 

5. 개발자에서 'AI 빌더'로: AI 깎는 개발자, 무두질에서 하네스까지

2026.04.02 - [분류 전체보기] - 개발자에서 'AI 빌더'로: AI 깎는 개발자, 무두질에서 하네스까지

개발자에서 'AI 빌더'로: AI 깎는 개발자, 무두질에서 하네스까지