광고에서 엔지니어링으로: DIALØGUE 구축에서 배운 기술적 교훈
AWS에서 GCP로 마이그레이션하여 92% 비용 절감과 10배 빠른 성능을 달성했습니다—실제로 작동하는 실용적 아키텍처를 위해 "모범 사례"를 버리면서 배운 것들입니다.
*이 글은 DIALØGUE 소개의 기술적 심층 분석 동반 글입니다. DIALØGUE가 무엇이고 왜 만들었는지 읽지 않으셨다면, 먼저 그 글부터 시작하세요!*
여정: 광고 전문가에서 풀스택 엔지니어로
좋아요, 먼저 핵심을 짚겠습니다 – 네, 저는 광고 업계 출신입니다. 네, 미디어 플랜과 크리에이티브 브리프지, 데이터 구조와 알고리즘이 아닙니다. 하지만 재미있는 것은: 시스템이 어떻게 작동하는지 이해하는 것은, 마케팅 퍼널이든 분산 아키텍처든, 같은 분석적 사고방식을 필요로 한다는 것입니다. 차이점은요? 엔지니어링에서는 실수하면 컴퓨터가 즉시 알려줍니다. 캠페인 결과를 기다리지 않아도 되거든요 하하.
DIALØGUE를 구축하는 것은... 강렬했습니다. 코드를 작성하는 것만이 아닙니다(물론 그것도 많았지만). 여러 AI 서비스를 오케스트레이션하고, 비동기 워크플로우를 처리하며, 사용자가 예상치 못한 행동을 해도 무너지지 않는 복잡한 시스템을 설계하는 것입니다. 이 여정이 실제로 저에게 무엇을 가르쳐줬는지 공유하겠습니다 – 좋은 것, 좌절스러운 것, 그리고 "왜 아무도 이걸 말해주지 않았지?" 순간들.
아키텍처 결정: 왜 복잡성이 적인가
시작할 때 아무도 말해주지 않는 것이 있습니다: 복잡성은 여러분의 친구가 아닙니다. 이것을 어렵게 배웠습니다. 정말, 정말 어렵게요. CloudWatch 로그에 파묻혀, 아름답게 설계한 시스템이 왜... 작동하지 않는지 알아내려는 저를 상상해 보세요. T.T
초기 아키텍처 (과도하게 복잡함)
오케스트레이션에 LangGraph로 시작했습니다. 왜? 그래프 기반 접근 방식이 너무 우아해 보였으니까요! 유연성을 줄 거라고! 아름답게 확장될 거라고!
현실 점검: 고통스러울 정도로 느렸습니다. 로컬에서 실행해도요. 클라우드 배포에서도요. 그 아름다운 추상화는 그저... 오버헤드였습니다. 엄청나게 많은 오버헤드.
최종 아키텍처 (실용적으로 단순함)
많은 고민(그리고 디버깅) 끝에, 실제로 작동하는 것은 이것입니다:
```
Frontend (Next.js) → API Gateway → Cloud Run Services → Cloud Workflows → Cloud Storage
↓
Supabase (Auth + Real-time + PostgreSQL + Edge Functions)
```
참고: 2025년 7월에 AWS Lambda/Step Functions에서 GCP Cloud Run/Workflows로 마이그레이션하여 92% 비용 절감과 10배 성능 향상을 달성했습니다.
큰 깨달음: 모든 것을 API로 감싸는 대신 Supabase 직접 쿼리로 전환했을 때, 10배 성능 향상을 얻었습니다 (450ms → 45ms). 그 "적절한" API 레이어링은? 그저 모든 것을 느리게 만들고 있었을 뿐입니다. 이 데이터베이스 우선 아키텍처가 GCP 마이그레이션의 기반이 되었습니다.
AI 모델 선택: 과대광고를 넘어서
모델 현실 상황
좋아요, AI 모델에 대해 이야기해 봅시다. 다 시도해봤습니다. 정말로 시도해봤습니다 – 하루 오후만 가지고 노는 것이 아니라요. 몇 달간의 테스트(그리고 인정하고 싶지 않을 만큼의 API 크레딧 소모) 끝에, 실제로 무언가를 구축할 때 작동하는 것은 이것입니다:
현재 기본 스택:
- Claude (Claude Code를 통해) & Gemini 2.5 Pro (Gemini CLI를 통해): 핵심 개발 듀오입니다. 이 두 모델이 너무 뛰어나져서 제 워크플로우에서 다른 모든 것을 대체했습니다.
- Claude Sonnet 4 API: JSON 신뢰성을 위해 temperature 0으로 DIALØGUE의 스크립트 생성을 구동합니다
이전에 사용했던 것:
DeepSeek: 까다로운 버그 디버깅에 의존했었습니다, 특히 야간 트러블슈팅 세션에서요. 하지만 Claude 4와 Gemini 2.5 Pro가 등장한 후? 그런 엣지 케이스를 동등하게, 아니 더 잘 처리합니다. 모델 역량의 진화로 전문 디버깅 모델이 제 워크플로우에서 불필요해졌습니다.
실제로 작동하는 것:
흥미로운 부분입니다: 각 모델은 그 자체로 이미 믿을 수 없을 정도로 강력합니다. Claude는 아키텍처 사고와 복잡한 추론에 뛰어납니다. Gemini 2.5 Pro는요? 구현과 대규모 코드베이스에서의 컨텍스트 유지에 절대적으로 경이롭습니다. Gemini 2.0에서 2.5로의 도약은 미쳤습니다 – 차이를 문자 그대로 느낄 수 있었습니다. 더 빠른 응답, 1M 토큰 컨텍스트 윈도우(네, 정말로), 그리고 제가 무엇을 만들려는지 실제로 이해합니다.
하지만 진정한 마법이 일어나는 곳은: 서로의 작업을 비평하게 할 때입니다. Claude에게 접근 방식을 설계하게 한 다음, Gemini에게 검토하고 개선을 제안하도록 요청합니다. 또는 Gemini가 솔루션을 생성하면, Claude에게 엣지 케이스나 아키텍처 우려 사항을 분석하게 합니다. 그 주고받기, 협업적 비평 과정 — 그것이 둘 중 어느 것도 혼자서는 도달하지 못했을 획기적인 솔루션을 찾는 곳입니다.
작동하지 않은 것 (과대광고에도 불구하고):
- OpenAI o1/o3: 모두가 이것에 대해 이야기하지만, 실제 개발에는? 너무 느리고, 너무 비싸고, 솔직히 제 사용 사례에는 그다지 나아지지 않았습니다.
- GitHub Copilot Workspace: 좋은 아이디어지만, 그 토큰 제한... 실질적인 것을 하려 할 때마다 한계에 부딪혔습니다
진짜 통찰: 아무도 말해주지 않는 것이 있습니다. 다른 모델은 다르게 실패합니다. 초기 Gemini는 특정 오류에 이상한 루프에 빠졌습니다 – 문제를 볼 수 없었죠. Claude는 즉시 발견했습니다. 하지만 Claude는 Gemini가 몇 초 만에 해결할 단순한 구현을 과도하게 생각했습니다. 비결은 "최고의" 모델을 찾는 것이 아닙니다 – 언제 전환할지 아는 것입니다.
풀스택 개발: 여러 역할 수행하기
터미널 전략
실제로 제 정신을 구한 실용적인 것: 다른 컨텍스트를 위한 별도의 터미널 창. 단순해 보이죠? 게임 체인저입니다.
```bash
# 터미널 1: 프론트엔드 개발자 나
cd podcast_generator_frontend_v2
npm run dev
# React 컴포넌트와 사용자 경험을 생각하는 곳
# 터미널 2: 백엔드 개발자 나
cd gcp_services
./deploy/deploy-service.sh [service-name]
# Cloud Run 서비스가 살아있는 곳 (Lambda보다 훨씬 행복!)
# 터미널 3: 데이터베이스 나
supabase start --workdir supabase
# 테스트용 로컬 Supabase, 실제 작업은 프로덕션
```
우스꽝스럽게 들릴 수 있지만, 터미널 간 물리적 전환이 뇌의 컨텍스트 전환을 도와줍니다. 프론트엔드 나와 백엔드 나는 다른 사람이고, 각자의 공간이 필요합니다.
크로스 스택 커뮤니케이션
풀스택을 혼자 작업하는 것은 이상합니다. 기본적으로 자신과 대화하는 것이니까요. 그래서 메모를 남기기 시작했습니다:
```
// 프론트엔드 나로부터 백엔드 나에게 보내는 메모
/**
* 백엔드 할 일:
* - 엔드포인트 필요 GET /api/podcasts/:id/segments
* - 반환해야 함: { segments: Array<{id, title, status, content}> }
* - 처리해야 함: 404 (찾을 수 없음), 403 (권한 없음)
* - Supabase 구독을 통한 실시간 업데이트가 이상적
* - 미래의 나는 에러 처리에 감사할 것!
*/
```
```
## 프론트엔드 통합을 위한 백엔드 개발자 요약
현재 상태:
- 구현된 엔드포인트: POST /podcasts, GET /podcasts/:id
- 인증: Supabase JWT를 통한 Bearer token
- 실시간: Supabase 채널 "podcast-updates"
다음 프론트엔드 작업:
1. 팟캐스트 생성 폼 구현
2. 실시간 업데이트 구독
3. 에러 상태 처리 (401, 403, 404, 500)
```
이 작은 메모들? 일주일 후 코드로 돌아와서 과거의 내가 무슨 생각을 했는지 전혀 모를 때 절대적인 생명줄입니다.
핵심 기술적 교훈
1. 시스템 사고는 도메인을 초월합니다
광고 배경은 시스템적으로 사고하는 법을 가르쳐 주었습니다 – 사용자 여정, 전환 퍼널, 기여 모델. 이러한 사고 모델은 직접적으로 다음에 적용됩니다:
- 분산 시스템 설계
- 사용자 경험 흐름
- 성능 최적화
- 에러 처리 전략
2. 프로덕션 우선 마인드셋
# 우선순위를 배운 것
if works_in_production and meets_user_needs:
ship_it()
else:
fix_only_blockers()
# 완벽은 완성의 적
3. 풀스택 역량은 진짜입니다
DIALØGUE 구축에 필요했던 것:
- 프론트엔드: React 19, Next.js 15, TypeScript, 실시간 구독, WebSocket 관리 (메모리 누수 수정!)
- 백엔드: Python 3.12, Cloud Run (14개 마이크로서비스), Cloud Workflows, PostgreSQL (Supabase를 통해)
- 인프라: GCP (AWS에서 마이그레이션), API Gateway, Cloud Storage, 프론트엔드용 Vercel
- AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, temperature 최적화 (JSON용 0)
- DevOps: Docker 컨테이너, Cloud Build, 모니터링, JWT 보안 (P-256 마이그레이션)
- 데이터베이스: RLS가 있는 PostgreSQL, Edge Functions, 경합 조건 방지를 위한 원자적 작업
4. 정규 교육의 중요성
정규 소프트웨어 엔지니어링 교육(시스템 설계, 데이터 구조, 알고리즘)이 매우 귀중했습니다. AI에게 코드를 작성하게 하는 것만이 아닙니다 – 무엇을 요청할지, 어떻게 설계할지 아는 것입니다.
마무리 생각
이 모든 것을 거치고 나서 도달한 결론은: DIALØGUE를 구축하는 것이 전문적으로 자신을 보는 방식을 완전히 바꿨다는 것입니다. 기술 팀을 관리하는 사람이었는데 이제? 실제로 그들과 함께 구축할 수 있습니다. 솔직히, 그 느낌은 꽤 놀랍습니다. :D 그 진화는 Swift를 모르면서 네이티브 iOS 앱을 만들기 시작했을 때 계속되었습니다 — 알고 보니 광고 기술(취향, 크리에이티브 방향, "좋은 것"이 어떤 느낌인지 아는 것)이 코딩 기술보다 더 중요했습니다.
광고에서 엔지니어링으로의 여정은 단순히 구문이나 프레임워크를 배우는 것이 아닙니다. 시스템적으로 사고하고, 체계적으로 디버깅하며, 때때로 빠진 세미콜론에 3시간을 보내는 것을 받아들이도록 뇌를 재배선하는 것입니다(좋아요, TypeScript가 그것은 잡아내지만, 요점은 이해하시죠).
재미있는 것 아시나요? 광고에서의 분석적 사고 – 사용자 여정 이해, 전환 퍼널 최적화 등 – 가 엔지니어링에 직접적으로 적용됩니다. 차이점은 코드에서는 무언가가 작동하지 않으면 컴퓨터가 즉시 알려준다는 것입니다. 캠페인 보고서를 기다리지 않아도 됩니다. 즉각적이고 가혹한 피드백입니다.
"제품"은 podcast.chandlernguyen.com에서 라이브입니다. 작동합니다. 완벽하지 않지만, 제 것입니다. 그리고 모든 버그 수정, 모든 기능 추가, 모든 "아하!" 순간 — 이것들은 모두 이 지속적인 여정의 일부입니다.
이처럼 큰 커리어 전환을 해보신 적 있나요 — 한 분야에서 완전히 다른 분야로? 전환에서 가장 놀랐던 것이 무엇인지 듣고 싶습니다. 알려주세요!
감사합니다,
Chandler
추신: 어렵게 배운 것에 대해 말하자면 – 하나의 작은 AI 파라미터 변경이 어떻게 월 $54의 비용을 초래했는지 알고 싶으시나요? 하나의 AI 파라미터 변경으로 월 $54의 비용이 발생했습니다를 확인하세요. 프로덕션 제약 조건에 대해 명시적이지 않고 AI 어시스턴트에게 프로덕션 코드를 맡겼을 때 무슨 일이 일어나는지에 대한 교훈입니다. 스포일러: "작동하게 해줘"와 "프로덕션에 적합하게 해줘"는 매우 다른 요청입니다.
추추신: 저는 아직도 이 엔지니어링이라는 것을 한 번에 하나의 버그씩 파악해 나가고 있습니다. 현재 AI 기반 애플리케이션을 구축하면서 프로덕션을 망가뜨리지 않으려 노력 중입니다. 더 많은 내용은 나중에 이 블로그에서 확인하세요.
