AI Engineer로서 Vibe Coding을 접근하는 방법

최근 아래 링크에 있는 글을 읽어 보고 생각이 드는 내용을 정리한 아티클입니다.

링크 : https://www.reddit.com/r/vibecoding/comments/1myakhd/how_we_vibe_code_at_a_faang/

 

먼저, 회고를 하기 전에 먼저 해당 내용을 간단히 번역을 하겠습니다.

FAANG에서 AI와 함께 코딩하는 방식

최근 AI 보조 코딩은 프로덕션 코드에 쓸 수 없다고 생각하는 분들의 비판을 자주 보았습니다. 하지만 이는 사실이 아닙니다. 해당 저자는 10년 이상 경력을 가진 AI 소프트웨어 엔지니어이며, 그중 절반가량을 FAANG 또는 유사한 대기업에서 근무했습니다.

이제 현재 저자들이 프로덕션 코드에 AI를 활용하는 방식을 공유해보겠습니다.

1. 항상 기술 설계 문서(Technical Design Document)부터 시작합니다

모든 개발은 기술 설계 문서로 시작합니다.
실질적인 업무의 대부분이 이 단계에서 이루어집니다.

• 설계 문서는 제안서(Proposal) 형태로 시작
• 여러 이해관계자들이 제안의 타당성에 동의하면
• 본격적인 시스템 설계 단계로 넘어갑니다
• 이 단계에서는 전체 아키텍처, 타 팀과의 연동 구조 등 모든 것이 포함됩니다

2. 개발 전에 설계 리뷰를 진행합니다

개발에 들어가기 전, 시니어 엔지니어들이 설계 문서를 철저하게 리뷰합니다.
이 과정에서 설계 문서는 가차 없이 비판받습니다.

이 과정은 고통스럽지만, 저는 이를 “초기에 고통을 집중적으로 치르는 것”이라고 생각합니다.
나중에 발생할 더 큰 문제를 미리 제거하는 단계입니다.

3. 리뷰 통과 후 개발 준비 단계

설계 리뷰를 통과하면 개발을 시작할 수 있습니다.

• 초기 몇 주 동안은 실제 코드보다
• 각 서브시스템에 대한 추가 문서화를 진행
• 개별 개발 팀이 맡을 컴포넌트 단위로 정리

4. 백로그 정리 및 스프린트 계획

이 단계에서 개발자들은 PM, TPM과 함께

• 작업을 작은 단위의 티켓으로 쪼개고
• 각 작업의 우선순위와 순서를 확정합니다.

5. 소프트웨어 개발 (여기서 AI가 본격적으로 힘을 발휘합니다)

이제 실제로 코드를 작성합니다.

• 우리는 TDD(Test Driven Development)를 사용합니다 -> 해당 내용이 핵심
• 먼저 AI 코딩 에이전트에게 테스트 코드를 작성하도록 시킵니다.
• 테스트가 준비된 이후에
• 해당 테스트를 통과하는 기능 구현을 AI와 함께 진행합니다.

이 단계에서 AI는 개발 속도를 극적으로 높이는 가속기(Force Multiplier) 역할을 합니다.

6. 코드 리뷰 및 머지

• 프로덕션 브랜치로 머지되기 위해서는
• 최소 두 명의 개발자 승인이 필요합니다.
• 이 과정에서도 AI는 코드 리뷰 보조 역할로 활용되며 가능성을 보여주고 있습니다.

7. 스테이징 테스트 후 프로덕션 배포

• 스테이징 환경에서 문제가 없으면
• 프로덕션으로 배포합니다.

 

해당 내용을 기반으로 생각한 AI Engineer로서의 고찰

과거에는 제가 재직했던 기업을 포함하여 다양한 회사에서 모델을 직접 개발하고, 이를 서빙 환경까지 구축하여 운영하는 업무를 주로 수행해 왔습니다. 모델 아키텍처 설계부터 학습, 추론 환경 구성, 그리고 실제 서비스에 적용하는 전 과정을 경험하는 것이 자연스러운 흐름이었습니다.

 

그러나 2025년이 끝나가는 현재 시점에서 산업 전반의 흐름은 상당 부분 달라졌다고 느끼고 있습니다. 현재 많은 개발자들이 이른바 vibe coding이라는 이름으로 활용하고 있는 Claude Code, Codex, Cursor와 같은 도구들은, 이미 해외의 대형 기술 기업들이 우수한 개발 인력과 막대한 컴퓨팅 자원을 투입하여 모델 개발뿐만 아니라 멀티 에이전트 아키텍처, MCP(Model Context Protocol) 기반 개발 및 서빙 환경까지 포함한 프로덕션 레벨의 생태계를 만들어가고 있습니다.

 

이러한 상황에서 모델 학습이나 대규모 추론(inference) 영역에서 실질적인 경쟁력을 유지할 수 있는 기업은, 국내외를 막론하고 대규모 GPU 인프라를 보유한 일부 대기업 또는 특정 전문 기업으로 점점 한정되고 있는 현실이라고 판단됩니다.

그 결과, 현재 대부분의 기업들은 Claude Code, Codex, Cursor와 같은 외부 AI 개발 도구를 적극적으로 활용하여 개발을 진행하고 있으며, 그 다음 단계로는 이러한 도구들을 기존의 개발 프로세스에 어떻게 효과적으로 녹여낼 수 있을지에 대한 고민이 이어지고 있습니다. 이는 개발자들만의 고민에 그치지 않고, 비개발 직군까지 포함한 전사적인 관심사로 확장되고 있는 상황입니다. 실제로 LinkedIn이나 Threads와 같은 SNS를 살펴보면, 이와 관련된 다양한 사례와 논의가 지속적으로 공유되고 있음을 확인할 수 있습니다.

 

한편으로 개인적인 바람을 말씀드리자면, 저 역시 모델을 직접 개발하거나, 과거부터 꾸준히 주목받아온 Vertical AI 기반의 모델을 학습·서빙하여 하나의 완성도 높은 서비스를 구축하고자 하는 욕심을 여전히 가지고 있습니다. 이는 AI 엔지니어로서 자연스러운 지향점이기도 합니다.

 

다만, 2026년에 접어들면서 기업의 관점은 더욱 명확해질 것이라고 생각합니다. 많은 기업들이 AI를 통해 명확한 수익성과 실질적인 비즈니스 가치를 창출하기를 기대할 것이며, 사용자가 매우 많은 서비스라면 어느 정도 비용을 감내할 수 있겠지만, 현실적으로는 온프레미스 환경은 물론 AWS, GCP, Azure와 같은 클라우드 플랫폼에서도 모델 학습 및 서빙에 소요되는 비용 부담이 상당히 큰 상황입니다. 이로 인해 관련 투자나 인프라 확장에 대해 이해관계자를 설득하는 과정은 2026년에 더욱 어려워질 가능성이 높다고 보고 있습니다.

 

이러한 배경 속에서, AI Engineer로서 두 가지 방향성을 동시에 추구할 수 있다면 가장 이상적이겠지만, 현실적인 제약을 고려할 때 보다 전략적인 선택이 필요하다고 느끼고 있습니다. 이에 따라, 앞서 언급한 Reddit의 사례와 현재 업계 흐름을 바탕으로 제가 고민하게 된 방향성과 생각을 다음 내용에서 정리해보고자 합니다.

 

FastAPI 기반 AI 백엔드 개발에서 “공수 높은 지점”만 AI로 확실히 줄이는 방법

AI 보조 코딩이 “프로덕션에는 못 쓴다”는 의견은 이제 현실과 다소 거리가 있습니다. 다만 중요한 전제가 있습니다. AI가 생산성을 올리는 구간과, 올리면 오히려 리스크가 커지는 구간을 분리해야 합니다. 즉, “포괄적인 문제 해결”이 아니라 AI 백엔드/서버 개발에서 사람이 시간을 가장 많이 쓰는 반복·정리·검증 작업을 AI로 구조화하는 것이 핵심입니다.

 

상단의 아티클의 FAANG식 개발 프로세스(설계 문서 → 설계 리뷰 → 세분화된 서브시스템 문서화 → 스프린트 계획 → TDD 기반 구현 → 코드리뷰 → 스테이징 → 프로덕션)에는 결국 한 가지를 말합니다.

 

• 문서/설계로 불확실성을 먼저 제거하고
• 테스트로 변경 비용을 낮춘 뒤
• 리뷰로 품질을 올린다

이 흐름에서 AI는 “키보드 타이핑”만 빨라지는 도구가 아니라, 문서·테스트·리뷰·운영 준비에서 큰 힘을 냅니다. 반대로, 설계가 빈약한 상태에서 AI로 코드를 “먼저” 밀어붙이면 속도는 잠깐 빨라져도 운영 단계에서 폭발합니다.

1) FastAPI + AI 백엔드에서 공수가 큰 곳은 어디인가

AI 백엔드(LLM/멀티모달 포함)에서 반복적으로 공수가 크게 드는 영역은 대체로 아래입니다.

1. 요구사항 → API 계약(API contract) → 스키마(Pydantic)로 “정의”하는 작업
2. 예외/에러 정책(에러코드, 메시지, retry 가능 여부) 표준화
3. 비동기/장기 작업 처리(BackgroundTasks vs 작업 큐), 상태 추적
4. 관측성(로그/메트릭/트레이스), 비용(토큰/시간) 계측
5. 회귀 방지용 테스트(TDD/통합테스트) 설계와 유지
6. PR 리뷰에서 놓치기 쉬운 보안·성능·경계조건 체크리스트화
7. 문서화(OpenAPI, 운영 런북, 배포 체크리스트)

FastAPI 자체는 타입힌트 기반으로 빠르게 API를 만들기 좋고, 자동 문서(OpenAPI)를 제공하는 것이 장점입니다.

하지만 “AI 백엔드”는 여기서 끝이 아니라, 모델 호출/비용/장기작업/데이터 거버넌스가 추가되면서 공수 곡선이 급격히 올라갑니다.

2) “AI에게 맡기면 이득이 큰 작업”과 “사람이 잡아야 하는 작업”

AI에게 맡기면 ROI가 큰 작업(추천)

• 설계 문서 초안 생성 및 누락 항목 탐지
• API 스키마(Pydantic v2) 초안, 예제 요청/응답 생성
• 테스트 케이스 생성(정상/경계/오류), 목킹 전략 초안
• OpenAPI 기반 SDK/클라이언트 사용 예시, 운영 문서 초안
• PR 체크리스트 기반 자동 리뷰(성능/보안/경계조건)
• 로그 필드 스펙/메트릭 이름 규칙/대시보드 지표 제안

사람이 반드시 잡아야 하는 작업(강제)

• 시스템 경계 정의: 어떤 데이터를 어디까지 신뢰하는지, PII/비밀키/권한 모델
• 장애 시나리오: 타임아웃, 서킷 브레이커, 재시도 정책, 아이들포턴시
• 비용 정책: 토큰 제한, rate limit, 캐시 정책, 모델 fallback
• 데이터/프롬프트 안전: 프롬프트 인젝션, 로그 마스킹, 정책 위반 처리
• 최종 설계 승인과 운영 책임

AI는 “그럴듯한 구현”을 잘 내지만, 조직의 제약(보안/데이터/운영) 맥락을 자동으로 보장해주지 않습니다. 그래서 사람이 ‘틀’을 잡고 AI는 ‘채우기/검증 보조’를 하는 구조가 가장 안전합니다.

3) FastAPI 개발 흐름을 “AI 친화적으로” 재설계하기

여기서부터가 실전입니다. 목표는 “더 많은 기능”이 아니라 같은 기능을 더 적은 공수로, 더 안정적으로 만드는 것입니다.

 

(A) 설계 문서(Design Doc)를 AI로 “빨리, 제대로” 만들기

설계 문서는 시간을 많이 먹습니다. 하지만 이 단계가 빈약하면 이후 단계가 더 크게 터집니다. AI를 다음 두 역할로 쓰는 것이 효율적입니다.

1. 초안 작성자
2. 리스크 리뷰어

권장 목차(최소):

• 문제 정의 / 범위(Out of scope 포함)
• API 계약(엔드포인트, 스키마, 상태코드)
• 모델 호출 전략(타임아웃, 재시도, fallback, 비용 상한)
• 장기 작업 설계(큐/워커/상태 저장)
• 데이터/보안(PII, 로그 마스킹, 권한)
• 관측성(메트릭/로그/트레이스, 비용 지표)
• 테스트 전략(단위/통합/부하/회귀)
• 롤아웃/롤백/마이그레이션

이 목차를 기반으로 AI에게 “초안 생성”을 시키고, 다시 같은 문서를 넣어 “누락/모순/운영 리스크”를 지적하게 하면, 설계 품질이 빠르게 올라갑니다.

(B) Pydantic v2 스키마 정의를 “AI로 가속”하되, 성능/호환성 체크는 사람의 영역

2025년 기준 FastAPI는 Pydantic 기반 모델링이 사실상 표준이고, Pydantic v2는 성능/스키마 생성 등에서 변화가 큽니다. (다만 케이스에 따라 v1 대비 성능 이슈가 논의되기도 합니다.) 

AI를 활용하는 고효율 패턴:

• 스키마 초안 생성: Request/Response 모델, 에러 모델, pagination 모델
• 예제 페이로드 생성: OpenAPI 문서 품질을 올리는 예제
• 제약조건/validator 초안: 입력 검증 로직

사람이 체크해야 하는 포인트:

• validator가 과하게 무거워져서 핫패스에서 지연이 발생하지 않는지
• 내부 도메인 객체와 외부 API 스키마가 뒤섞이지 않았는지(레이어 분리)

(C) “BackgroundTasks로 버텨도 되는 일”과 “큐로 빼야 하는 일”을 명확히 나누기

FastAPI에는 응답 반환 이후 실행되는 BackgroundTasks가 있습니다.
하지만 AI 백엔드에서는 이미지/영상/대규모 후처리, 외부 API 체인 호출처럼 “진짜 장기 작업”이 흔합니다. 이걸 웹 프로세스 내부에서 버티면 운영이 불안정해집니다.

권장 기준:

• 수백 ms~1~2초 내 끝나는 후처리: BackgroundTasks 가능(예: 로그 집계, 간단한 비동기 알림)
• 수 초~수 분, 실패 가능성 높음, 재시도/상태추적 필요: 작업 큐(Celery/RQ/Arq 등)로 분리

장기 실행 작업은 “웹 서버에서 분리하는 것이 필수”라는 취지의 정리도 많습니다.

또한 FastAPI 의존성(Depends) 및 request lifecycle 관련 동작은 버전 변화/엣지케이스가 존재하므로, “라이프사이클/정리 작업”을 어떤 방식으로 엮는지 주의가 필요합니다. (예: 의존성 yield 동작 변화 이슈)

AI가 도와줄 수 있는 지점은 여기서 큽니다.

• “이 작업은 BackgroundTasks로 충분한가?”를 기준표로 만들어 자동 분류
• 큐로 뺄 경우: 작업 ID, 상태 테이블, 재시도 정책, 아이들포턴시 키 설계 초안 생성
• 운영 대시보드에 필요한 메트릭/로그 필드 제안

4) TDD를 “AI 코딩 에이전트 최적화”로 바꾸는 방법

일반적인 TDD는 테스트가 귀찮아서 무너집니다. 그런데 AI 코딩 에이전트가 등장하면서, “테스트 작성”이 가장 큰 생산성 레버리지가 됐습니다.

권장 루틴(실제로 공수가 줄어드는 형태):

1. 설계 문서에서 API 계약/상태코드를 확정
2. AI에게 테스트를 먼저 쓰게 함
   • 정상 케이스
   • 경계값
   • 모델 호출 실패/타임아웃/부분 실패
   • 권한/PII 마스킹
3. 사람이 테스트를 리뷰(이게 핵심)
4. 구현은 AI + 사람이 같이
5. 스테이징에서 시나리오 테스트

이 접근은 “AI가 생산 코드를 만들어도 안전장치가 있다”는 의미입니다. 테스트는 곧 계약이고, 계약이 있으면 구현은 바꿔도 됩니다.

5) PR 리뷰 공수를 AI로 줄이되, “체크리스트 기반”으로만 쓴다

코드리뷰는 공수가 크지만, 조직 품질의 핵심입니다. AI를 리뷰어로 쓰려면 자유형 코멘트가 아니라 체크리스트 기반이 안전합니다.

AI 리뷰 체크리스트 예시(서버/AI 백엔드 특화):

• 타임아웃/재시도/서킷 브레이커가 일관적인가
• 외부 호출에 아이들포턴시 고려가 있는가
• 입력 검증이 과하거나 부족하지 않은가(Pydantic validator 비용)
• 로그에 PII/비밀키가 남지 않는가
• 예외가 “사용자 메시지 vs 내부 메시지”로 분리되는가
• BackgroundTasks 남용 여부(장기 작업이면 큐로 분리)
• 관측성: request_id, model, token_usage, latency 기록 여부
• rate limit / concurrency limit 고려 여부

이 체크리스트를 템플릿으로 두고, PR마다 AI에게 “위반 항목만 지적”하게 하면 리뷰 속도가 빨라지면서도 품질이 유지됩니다.

6) 2025년 말 기준, 개발 도구 체인도 공수 절감의 일부다(uv, Python 3.13)

AI로 코드 생성이 빨라져도, 로컬/CI가 느리면 전체 생산성이 죽습니다. 2025년에는 uv 같은 Rust 기반 툴 체인이 빠른 설치/실행 경험을 제공하는 흐름이 강해졌고, 공식 문서도 잘 정리돼 있습니다.

런타임 측면에서는 Python 3.13이 2024-10-07에 릴리스되었고, 최신 파이썬의 변경점/성능 특성은 공식 “What’s New”를 기준으로 보는 게 안전합니다.

즉, “AI가 만든 코드”를 빠르게 검증하려면

• 의존성 설치/테스트/린트가 빠른 도구 체인
• 테스트 실행 시간이 짧은 설계(단위 vs 통합 분리)
• 스테이징에서 자동 시나리오 테스트

가 함께 가야 실제 체감 속도가 올라갑니다.

7) 결론: “AI로 가장 비싼 공수”만 정확히 깎아라

FastAPI 기반 AI 백엔드에서 AI를 잘 쓰는 팀은 대체로 공통점이 있습니다.

• 설계 문서를 AI로 빨리 만들지만, 최종 책임은 사람이 진다.
• 구현보다 테스트/리뷰/운영문서에서 AI의 레버리지가 더 크다.
• BackgroundTasks 남용 대신, 장기 작업은 큐로 분리하고 상태/관측성을 잡는다.
• 버전/라이프사이클/의존성 동작 같은 프레임워크 엣지케이스는 이슈/공식 문서로 확인한다.

정리하면:

• “AI가 코드를 짜서 빨라졌다”가 아니라
• “설계-테스트-리뷰-운영 준비의 반복 작업을 AI가 떠받쳐서, 사람이 중요한 결정을 더 많이 하게 됐다”
  가 현재의 AI Engineer로서의 저의 결론입니다.