AX(AI Transformation) - 기획서부터 백엔드, 프론트엔드, 배포까지, AI가 바꾼 개발 파이프라인 이야기

AX(AI Transformation) - 기획서부터 백엔드, 프론트엔드, 배포까지, AI가 바꾼 개발 파이프라인 이야기

 

얼마 전까지만 해도 "AI 잘 쓰는 개발자"의 기준은 코드 자동완성을 얼마나 잘 활용하느냐였습니다. 커서(Cursor)를 쓰냐, Claude Code를 쓰냐. 그게 전부인 줄 알았어요.

그런데 어느 순간부터 그 질문이 달라지기 시작했습니다. "어떤 AI 에디터를 쓰냐"가 아니라, "어떤 파이프라인으로 개발하느냐"로. 그 변화를 직접 겪으면서, 저는 꽤 많은 것을 다시 생각하게 됐습니다.

 

AI 에디터를 넘어 파이프라인으로: 파도의 방향이 바뀌었다.

2023년에 DX(디지털 전환)가 있었다면, 2025년엔 AX(AI 전환)가 왔습니다. 이름만 바뀐 게 아닙니다. 결이 다릅니다.

DX는 오프라인에 있던 것을 온라인으로 옮기는 작업이었습니다. 예약 시스템을 만들고, 재고 관리를 엑셀에서 SaaS로 이전하고. 비교적 명확한 목적지가 있었죠.

AX는 좀 다릅니다. "AI로 뭘 해야 하지?"라는 질문 자체가 출발점인 경우가 많습니다. 그래서 많은 팀이 가장 손쉬운 것부터 잡습니다. 코드 자동완성. 자동 테스트 생성. PR 요약.

나쁜 선택은 아닙니다. 그런데 거기서 멈추는 팀과, 그다음을 보는 팀 사이에 이미 격차가 생기고 있습니다.

1세대 AI 도입이 "AI로 코드를 빠르게 짜는 것"이었다면, 2세대는 다릅니다. 기획서부터 배포까지, 산출물 전 공정에 AI가 읽고 쓸 수 있는 언어를 심는 것. 그게 지금 제가 생각하는 진짜 AX입니다.

 

직접 겪어본 이야기: 내가 파이프라인을 만들게 된 이유

처음엔 솔직히 불편했습니다. 내가 짜야 할 코드를 AI가 대신 쓴다는 게 왠지 어색했거든요.

그런데 방향을 바꾸니 달라졌습니다. AI에게 코드를 맡기는 게 아니라, AI가 일할 수 있는 환경을 설계하는 것이 제 일이 됐습니다.

그 과정에서 겪은 일들이 있습니다.

첫 번째. 저는 Claude Code 환경에 훅(hook), 스킬(skill), 에이전트 계층을 직접 만들어 쌓았습니다. 처음엔 "이게 AI 생산성이랑 무슨 관계가 있나?" 싶었어요. 그런데 써보니 알겠더라고요. AI가 실수를 덜 하는 환경이 결국 생산성의 본체였습니다. AI 자체보다 AI를 둘러싼 구조가 더 중요했습니다.

두 번째. Figma에서 컴포넌트를 코드로 자동 변환하는 걸 해봤습니다. 처음엔 기대가 컸습니다. 그런데 디자인 토큰이 정리 안 된 상태에서 돌리니 쓸 수 없는 코드가 나왔어요. AI가 나쁜 게 아니었습니다. 제가 AI에게 줄 재료를 준비 안 한 거였습니다.

세 번째. Vercel에 환경변수를 설정하다가 런타임에서만 인증이 실패하는 이슈를 겪었습니다. 원인은 $ 문자가 포함된 값을 대시보드에 넣을 때 \$로 이스케이프된 채 저장된 것이었습니다. AI가 검토한 코드에는 문제가 없었습니다. 우리가 AI에게 준 컨텍스트에 구멍이 있었던 겁니다.

세 가지 사례에서 공통점이 보였습니다. 문제는 항상 AI 이전 단계에 있었습니다. AI에게 무엇을 어떻게 줄 것인가, 그 준비가 개발 생산성의 진짜 열쇠였습니다.

 

왜 PRD부터 시작해야 하는가: 스펙 없이 시작한 코드는 결국 다시 짠다.

AI 에이전트에게 "API 만들어줘"라고 말하면 뭔가 나오긴 합니다. 그런데 그게 우리가 원하는 건지 보장할 수 없습니다. 어떤 인증 방식인지, 실패 시 어떻게 처리하는지, 어떤 응답 구조를 써야 하는지 — 그 맥락이 없으면 AI는 그냥 그럴듯한 코드를 만들 뿐입니다.

문제는 요청 방식이 아닙니다. 입력 자체입니다.

현업에서 쓰는 PRD(Product Requirements Document, 제품 요구사항 문서)의 문제가 여기 있습니다. 대부분의 PRD는 사람이 읽기 위해 씁니다. "사용자가 로그인 버튼을 누르면 인증 프로세스가 시작된다." 이 문장은 사람에게는 자연스럽지만 AI에게는 모호합니다. 어떤 인증 방식인지, 실패 시 어떻게 처리하는지, 어떤 상태를 반환해야 하는지가 없습니다.

그래서 PRD를 다시 써야 합니다. 명시적 제약, 수용 기준(acceptance criteria), 데이터 계약이 담긴 AI가 읽을 수 있는 문서로. 그게 파이프라인의 진짜 출발점입니다.

요즘은 이걸 **컨텍스트 엔지니어링(Context Engineering)**이라고 부릅니다. AI에게 무엇을 어떤 형식으로 줄 것인가를 설계하는 일 자체가 하나의 전문 영역이 된 겁니다.

 

 

 

파이프라인 5단계: 기획에서 배포까지

개발 파이프라인에는 순서가 있습니다. 상류가 제대로 정의되어야 하류가 흔들리지 않습니다. AI를 쓸수록 이 원칙이 더 선명해집니다.

1단계 — PRD 표준화

PRD를 AI가 읽을 수 있는 형식으로 바꾸는 데서 시작합니다. YAML 프론트매터에 기능 ID, 수용 기준, 의존성, 데이터 타입을 명시합니다. "사용자가 가입할 수 있다"가 아니라, "이메일 + 비밀번호를 받아 users 테이블에 INSERT하고, 중복 시 409를 반환한다"로 씁니다. 처음엔 귀찮습니다. 그런데 이게 이후 모든 단계의 재료가 됩니다.

2단계 — 디자인 시스템 토큰화

Figma Variables를 JSON 토큰으로 추출하고, 그것이 Tailwind 설정이나 CSS 변수로 자동 연동되게 합니다. 디자이너가 브랜드 컬러를 바꾸면 코드가 따라 움직이는 구조. 이게 되어 있지 않으면, 컴포넌트를 AI가 아무리 잘 만들어도 스타일 불일치가 수동으로 쌓입니다.

3단계 — API 스펙 먼저

PRD에서 정의한 요구사항이 OpenAPI 스펙 또는 Zod 스키마로 정리됩니다. 코드를 먼저 짜는 게 아닙니다. 어떤 데이터를 주고받을지를 먼저 정합니다. 이 스펙이 명확하면 프론트엔드와 백엔드가 병렬로 개발해도 충돌이 없습니다. AI도 스펙에서 시작하면 훨씬 정확한 코드를 만듭니다.

4단계 — 프론트엔드 조립

디자인 토큰, API 스펙, PRD 요구사항이 모두 AI가 읽을 수 있는 형태로 갖춰져 있으면 프론트엔드 개발은 AI가 상당 부분 조립합니다. 컴포넌트 생성, API 연동, 에러 핸들링. 사람은 설계를 검토하고 엣지 케이스를 판단합니다.

5단계 — 하네스(검증 게이트)

하네스(harness)란 AI가 만든 결과물을 자동으로 검증하는 장치입니다. 타입 체크, 빌드 검증, 런타임 테스트, AI 코드 리뷰어. 이 게이트 없이 파이프라인을 돌리는 건 안전장치 없이 공장을 가동하는 것과 같습니다. 실수가 빠르게 누적됩니다.

 

 

시작하는 팀을 위한 현실적인 조언

"그럼 당장 뭘 해야 하나요?"라는 질문을 많이 받습니다.

다짜고짜 에이전트부터 도입하지 마세요. 저도 그랬다가 돌아온 경험이 있습니다. AI 에이전트는 좋은 재료가 있을 때 진짜 힘을 발휘합니다. 재료가 엉망이면 결과도 엉망입니다.

첫 주에 할 일은 하나입니다. PRD 하나를 골라서 AI가 이해할 수 있는 형식으로 다시 씁니다. 수용 기준을 명시적으로, 데이터 흐름을 타입과 함께. 그것만 해도 충분합니다.

첫 달에 할 일은 두 가지입니다. Figma 디자인 토큰 정리, 그리고 OpenAPI 스펙 기반으로 엔드포인트 하나를 파이프라인화합니다. 한 번 성공하면 팀 전체가 느낍니다. 뭔가 달라지고 있다는 걸.

첫 분기에 할 일은 자동화와 회고입니다. 리뷰 게이트를 CI에 붙이고, 실패했던 것들을 회고합니다. AI 실수의 패턴이 보이기 시작합니다. 그 패턴이 다음 하네스를 설계하는 재료가 됩니다.

핵심은 이겁니다. AI에게 일을 맡기는 게 아니라, AI가 일할 수 있는 환경을 만드는 것이 AX입니다.

사용자는 완성된 화면을 봅니다. 버튼이 잘 눌리는지, 속도가 빠른지. 그게 전부처럼 보이죠.

그런데 그 화면의 품질은 PRD가 얼마나 명확했는지, 디자인 토큰이 얼마나 잘 정의됐는지, API 스펙이 얼마나 구체적이었는지에 달려 있습니다. 사용자 눈에 보이지 않는 곳에서 품질이 결정됩니다.

AI가 바꾼 건 단순히 코드 작성 속도가 아닙니다. 상류 산출물의 품질이 하류 결과를 결정한다는 원리를 더 선명하게 드러낸 것입니다.

그 파이프라인을 설계하는 사람이, 다음 시대의 개발자라고 생각합니다.