얼마 전, 친구와 안부를 나누다 보니 이야기가 금세 깊은 수다로 번졌다. AI 지원 코딩이 우리의 워크플로우, 팀 문화, 그리고 ‘장인 정신’에 어떤 영향을 미치는지—레거시 코드베이스를 갈아엎는 일부터 자동화 테스트 커버리지가 프로그래밍의 본질을 어떻게 바꾸는지까지—끝없이 파고들었다.

Granola에서 받아 놓은 녹취록을 o1-pro에 던져 넣고 “블로그 글로 써 줘”라고 해 봤다. 결과? 나쁘지 않았다. 내 생각을 꽤 잘 담아냈다.

몇몇 친구에게 보내자 다들 다른 친구에게 더 돌리고 싶다고 했다. 그럼 공개해야지. 자, 갑니다!

이건 좋은 리마인더야. 만약 누군가에게서 온 이메일이 지나치게 완벽하고 문체에 아무 개성도 없다면… 아마 AI가 쓴 걸 거야. lol.

15분 워터폴, 아니면 전액 환불!

뉴 노멀: “코드 품질이 대체 왜 중요한데?”

우리는 오랫동안 코드를 공예품으로 여겨 왔다. 귀중한 플로 상태에 들어가 논리를 조각하고, 손수 버그를 잡아내며 승리를 만끽하는 식이다. 그런데 대형 언어 모델(LLM) 같은 코드 생성 도구가 몇 분 만에 기능을 뚝딱 만들어 내는 새 패러다임이 슬금슬금 다가오고 있다.

이 속도에 불안을 느끼는 사람도 있다. ‘클린 코드’라는 오래된 기준이 한순간에 뒤집히는 듯하니까. 탄탄한 테스트 스위트나 TDD조차 한 줄씩 써 내려가기보다는, 봇이 스스로를 검증하게 두는 쪽으로 기우는 중이다.

코드 품질이 곤두박질칠까? 그럴 수도 있다. 동시에 정적 분석, 형식 검증, 전면적 테스트 커버리지 같은 ‘초방어적 코딩’을 더 강하게 요구하게 됐다. AI 기반 에이전트가 무언가를 망가뜨려도 바로 잡으려면, 지금처럼 고급 CI/CD 파이프라인과 촘촘한 체크가 필요했던 적이 없었다.

15분 워터폴

한때 ‘워터폴 vs 애자일’을 선악 대결처럼 다뤘고, 애자일이 유일한 해답이라 여겼다. 그런데 코드 생성 덕분에 우리는 초단기 워터폴 사이클, 다시 말해 “15분 워터폴” 쪽으로 기울고 있다. LLM이 명확한 스펙을 요구하니 먼저 스펙을 세세히 정의하고 ‘시작’ 버튼을 누른 뒤 코드를 생성시키고 결과를 리뷰한다. 얼핏 보면 반복적(iterative) 같지만, 실제로는 계획 → 실행 → 검토라는 사이클이 15분마다 돌아간다.

진짜 묘미는 여러 ‘에이전트’를 동시에 띄울 수 있다는 점이다. 하나는 기능을 만들고, 다른 하나는 문서를 작성하고, 세 번째는 테스트 커버리지를 집요하게 분석한다. 이건 옛날식 단선형 워터폴이 아니라, 동시성이 폭발적으로 늘어난 셈이다.

앞으로 달라질 팀 문화

엔지니어링 팀을 이끈다면 윗선에서 “AI를 도입해 생산성을 높여 보자”는 주문을 듣는 동시에, 팀원들의 열정이 제각각이라는 것도 느낄 것이다. 어떤 이는 프롬프트만 던져 새 기능을 통째로 만들 정도로 올인하고, 또 어떤 이는 ‘코드 장인’ 정체성을 지키려 한다.

내가 보기에 효과적인 방법은 이렇다:

1. 작은 파일럿부터 돌려 보기
   위험이 적은 내부 툴이나 사이드 프로젝트를 골라 호기심 많은 엔지니어 몇 명에게 맡겨 보자. 모델을 너무 믿었다가 망가뜨려 보고, 다시 모범 사례로 수습하는 과정에서 많은 걸 배우게 된다.

2. 사람을 번갈아 투입해 서로 배우게 하기
   ‘AI 코딩 전용’ 사이드 프로젝트를 마련해 두면 팀원을 1~2주 단위로 순환 배치할 수 있다. 각자 새로운 환경을 체험하며 배우고, 얻은 교훈을 메인 코드베이스로 가져온다.

3. 문서에 진심을 담기
   AI 에이전트는 극도로 명확한 스펙을 요구한다. 코드 생성은 싸지만 LLM을 올바른 방향으로 이끄는 데는 세심한 기획이 필요하다. 최고의 스펙과 아키텍처 문서를 공유 저장소에 쌓아 두면, 사람이나 에이전트가 교체될 때마다 “문서 잘 써 놔서 살았다”는 말을 듣게 될 것이다.

플로 상태, 과대평가였을지도?

우리 중 상당수는 몰입 상태, 즉 ‘존(zone)’에 들어가는 짜릿함 때문에 코딩을 좋아한다. 하지만 AI 코딩은 그 몰입을 덜 제공한다. 한 시간쯤 프롬프트를 세팅해 두고 AI가 백그라운드에서 코드를 짜게 한 뒤, 가끔 결과를 확인하며 방향만 잡아 주면 된다. 그러다 보면 ‘조용히 몰입해야만 생산적인 건 아니라는 새로운 길도 있구나’ 하고 깨닫게 된다.

어떤 사람에게는 낯설지만, 아이를 돌보거나 여러 일을 동시에 해야 하는 사람에게는 해방감이다. 잠깐 컨텍스트를 전환해 다른 일을 하고 돌아오면 이미 돌아가는 스니펫이 완성돼 있으니까.

이것이 “Peak Programmer”일까?

AI가 코드를 자동으로 뽑아내면 곧 ‘Peak Programmer’—개발자 수요의 정점—에 도달할 거란 얘기도 들린다. 단순 기능 구현이나 API 연결 정도라면 인력이 덜 필요해질 수도 있다. 하지만 보안, 컴플라이언스, 테스트 커버리지, 아키텍처 같은 복잡도는 오히려 늘어난다.

차이는 여기서 갈린다. 여러 AI 도구를 오케스트레이션하고, 코드 품질을 지켜 보며, 확장 가능한 시스템을 설계할 ‘전략형 엔지니어’가 각광받게 된다. 이들은 PM·아키텍트·QA·개발자 역할을 겸하며 프롬프트를 다듬고, 테스트를 정의하고, 품질을 유지하며, LLM이 예측 못 한 엣지 케이스를 처리한다.

현장에서 얻은 꿀팁

1. 처음엔 손으로 시작하고, 그다음 AI 켜기
   iOS 앱이라면 먼저 Xcode에서 프로젝트를 초기화하자. 자동 생성 파일이 LLM을 헷갈리지 않게 하고, 나머지는 AI에게 맡기면 된다.

2. 짧고 명확한 프롬프트가 의외로 잘 먹힌다
   “make code better”(코드를 더 깔끔하게 만들어 줘)처럼 간단한 지시가 장문의 프롬프트만큼 잘 통할 때가 있다. 모델마다 제약이 적을 때 더 잘 동작하니 계속 실험해 보자.

3. 체크포인트 기반 워크플로우 사용
   자주 커밋하자. git commit -m "It passed the tests, I guess!" 같은 커밋이라도 좋다. AI는 고칠 만큼 빠르게 망가뜨리기도 한다. 잦은 커밋은 롤백을 쉽게 해 준다.

4. 기본 기능에 대한 과도한 테스트는 잘라내기
   AI는 for 루프가 도는지까지 테스트하려 든다. 쓸데없는 테스트를 솎아 내 파이프라인을 가볍게 유지하자.

5. 모든 것을 문서화하기
   AI에게 방대한 “Implementation Guide”를 뽑아 달라고 하자. 이 문서는 당신뿐 아니라 이후 AI 패스에도 큰 도움이 된다.

맺는 말

우리 업계는 지금 그 어느 때보다 빠르게 변하고 있다. 플로 상태가 중심이거나 손수 코딩한 기능을 크게 축하하던 전통적 전제는 곧 촌스러워질지도 모른다. 하지만 창의성이 사라지는 것은 아니다. 이제 핵심은 전략적 오케스트레이션—무엇을 만들지, 어떻게 묘사할지, 그리고 어떻게 난장판으로 변하는 것을 막을지—에 있다.

결국 제품을 승자로 만드는 건 무작정 코드를 쏟아붓는 일이 아니다. 사용자 경험을 디자인하는 일이다. 주말 동안 인스타그램 클론 10개를 뚝딱 만들 수 있는 세상이라면, 승부는 코드의 우아함이 아니라 어느 쪽이 사람들의 마음을 사로잡느냐다—그건 디자인과 제품의 영역이다.

그러니 15분 워터폴에 오신 걸 환영한다. AI는 당신의 무한한 주니어 개발자이고, 코드 파이프라인은 터보 부스트가 걸린다. 기묘하고 멋지며 때로는 무섭다. 어쨌든 우리 모두 이 춤을 배워야 할 테니까.

세상 참 웃기다니까. 앞으로 더 웃겨질 거다. 같이 파고들어 보자.