'AI를 도구로 쓴다'는 말은 이제 너무 좁다. 최근 개발자 커뮤니티에서 눈에 띄는 글들을 읽다 보면, 더 정확한 표현은 'AI와 함께 생각한다'에 가깝다. 인프라 마이그레이션, Go 백엔드 사이드 프로젝트, 임베디드 펌웨어—도메인도 스택도 제각각인 세 가지 실제 사례가 놀랍도록 같은 결론을 가리키고 있다.
맥락: "파트너, 도구가 아니다"
DynamoDB 전문가로 알려진 Rick Houlihan은 You Cannot Outrun a Wave에서 byline을 이렇게 시작한다. "나는 내 AI와 함께 씁니다. AI를 통해서가 아니라." 그는 주말 동안 Claude와 함께 가족이 운영하는 세탁소의 웹 인프라를 재건했다. 프랜차이즈 공식 벤더의 모바일 Lighthouse 점수는 9점, 반면 그가 직접 구축한 페이지는 Google 리치 결과 14개를 확보했다. 핵심은 기술 격차가 아니라 인센티브 격차였다는 그의 진단이 날카롭다. AI가 힘을 줬지만, 그 힘을 제대로 쓰려면 도메인 이해가 먼저라는 것.
Kanchen Lin의 AI-Native Dev Flow for Go Side Projects는 이 파트너십을 훨씬 명시적인 워크플로우로 구조화한다. 그가 설계한 qrspi 플로우는 8단계다: question → research → design → structure → plan → worktree → implement → PR. 각 단계는 슬래시 커맨드로 실행되고, 모든 결과물은 thoughts/qrspi/<date>-<slug>/에 마크다운으로 커밋된다. QR 코드 생성기라는 '의도적으로 평범한' 프로덕트를 선택한 이유가 흥미롭다. 결과물이 아닌 과정을 증명하고 싶었기 때문이다. depguard 룰로 아키텍처 드리프트를 자동 차단하면서, AI 에이전트가 2,000줄을 넘어도 '플롯을 잃지 않도록' design.md와 plan.md가 맥락을 고정한다.
세 번째 사례는 가장 극적이다. Temporal의 개발자 Shy는 Behind The Badge에서 고백한다. "저는 이 프로젝트 전까지 펌웨어 코드를 한 번도 써본 적이 없습니다." 그럼에도 그는 ESP32-S3 기반, C+MicroPython 이중 레이어, 자이로스코프·IR 송수신·진동 모터가 들어간 개발자 컨퍼런스용 배지 2,000개를 4개월 만에 양산했다. Claude와 Claude Code로 시작해 Codex로 전환하면서, 5,000줄의 프로덕션 로직을 유지했다. 테스트 코드는 그 4배. 아키텍처 토론 문서는 21,000줄. 그가 내린 정의는 명쾌하다. "나는 풀타임 아키텍트가 됐고, 구현 능력은 뛰어나지만 판단력은 부족한 주니어 팀을 갖게 됐다."
해석: 세 사례가 공유하는 문법
도메인이 다르고 스택도 다르지만, 세 워크플로우에는 공통된 패턴이 있다.
첫째, 컨텍스트 고정이 품질을 결정한다. qrspi의 design.md든, 펌웨어 프로젝트의 21,000줄 아키텍처 문서든, Houlihan의 직접 측정과 명시적 진단이든—AI에게 '지금 뭘 짓고 있는지'를 끊임없이 환기시키는 구조가 없으면 세션이 길어질수록 코드가 표류한다. 컨텍스트 관리는 AI 협업에서 코드 작성만큼 중요한 작업이다.
둘째, 도메인 판단력은 여전히 인간의 몫이다. Shy가 10년 이상의 개발 경력 없이 이 워크플로우가 작동하지 않았을 것이라고 말한 부분이 핵심이다. AI가 틀렸을 때 알아채는 능력, 어떤 질문이 중요한지 판단하는 능력은 경험에서 나온다. Houlihan이 프랜차이즈 벤더의 실패를 "기술 격차가 아니라 인센티브 격차"로 진단할 수 있었던 것도 같은 이유다.
셋째, 테스트와 검증 루프가 신뢰를 만든다. Shy는 평소 테스트를 잘 쓰지 않던 개발자였지만, AI가 생성하는 코드에 신뢰를 쌓기 위해 처음부터 강력한 테스트 커버리지를 설계했다. Lin의 qrspi도 각 단계에 체크포인트를 명시한다. AI 협업에서 '빠른 프로토타이핑 → 검증 → 고도화' 사이클이 빨리 돌아갈수록, 검증 루프의 품질이 전체 아웃풋의 천장을 결정한다.
시사점: 워크플로우 자체가 포트폴리오다
Lin이 qrspi 아티클에서 한 말이 계속 마음에 걸린다. "누구나 QR 코드 생성기를 만들 수 있다. 아키텍처, 트레이드오프, 스펙 편차가 모두 디스크에 기록된 채로 만드는 건 다른 신호다." AI 도구가 보편화될수록 '무엇을 만들었냐'보다 '어떻게 생각하며 만들었냐'가 차별화 포인트가 된다. 워크플로우 자체가 곧 역량의 증거다.
UI/UX 관점에서도 시사점이 있다. 세 사례 모두 결국 '사용자 경험을 개선하기 위한 인프라'를 다루고 있다. 세탁소 로컬 SEO, 개발자 배지의 MicroPython REPL, QR 코드 리다이렉트 레이턴시—기술적 결정이 최종적으로는 실제 사용자의 경험에 닿는다. AI 협업 워크플로우도 마찬가지로, 설계 단계에서 "이게 사용자에게 진짜 도움이 되는가"라는 질문을 먼저 던지는 구조가 되어야 한다.
전망: 다음 질문은 '얼마나'가 아니라 '어떻게'
이 세 사례가 공통으로 증명하는 것은 하나다. AI 협업의 성숙도는 '얼마나 많이 쓰느냐'가 아니라 '어떤 구조로 쓰느냐'에 달려 있다. 컨텍스트를 어떻게 고정할 것인지, 검증 루프를 어떻게 설계할 것인지, 도메인 판단과 AI 구현 사이의 경계를 어디서 그을 것인지—이 질문들에 자기만의 답을 가진 개발자와 그렇지 않은 개발자 사이의 격차는 앞으로 더 빠르게 벌어질 것이다. 파도를 앞지를 수는 없다. 올라타는 법을 배우는 것만이 답이다.