코드를 안 짜는 개발자의 시대가 온다면

안녕하세요, AI 커피챗입니다.

요즘 개발자 커뮤니티를 보면 재미있는 현상이 있어요. "나 요즘 코드 한 줄도 안 쳐"라는 말이 자랑처럼 들린다는 거죠. 몇 년 전만 해도 "하루에 코드 몇 천 줄 짰어"가 자랑이었는데 말이에요.

실제로 지금 Claude Code, Cursor, GitHub Copilot 같은 AI 코딩 도구들을 써보신 분들은 아실 거예요. 정말로 코드를 직접 타이핑할 일이 거의 없어졌다는 걸요.

그런데 여기서 질문이 하나 생깁니다. "그럼 개발자는 이제 뭘 하는 사람이죠?"

코드 작성에서 코드 설계로

미국 스타트업 미디어 Every에서는 흥미로운 실험을 하고 있어요. 5개의 소프트웨어 제품을 운영하는데, 각 제품마다 딱 한 명의 개발자가 담당한다고 합니다. 그것도 수천 명이 매일 사용하는 프로덕션 레벨의 제품을요.

어떻게 이게 가능할까요? Every의 제품 총괄 Kieran Klaassen은 이렇게 설명합니다. "이제 개발자 한 명이 몇 년 전 다섯 명이 하던 일을 할 수 있어요. 단, 올바른 시스템만 갖춘다면요."

복합 엔지니어링(Compound Engineering)

Every 팀이 부르는 이 새로운 개발 방식의 핵심은 간단합니다. "매번 작업할 때마다 다음 작업이 더 쉬워지도록 만드는 것"이죠.

전통적인 개발에서는 기능을 하나 추가할 때마다 코드베이스가 복잡해지고, 다음 기능 개발이 더 어려워졌어요. 예상 못한 버그도 많아지고, 서로 얽힌 의존성 때문에 머리가 아팠죠.

하지만 복합 엔지니어링은 반대예요. 기능을 하나 만들 때마다 AI와 팀 전체가 학습하면서, 다음 기능은 더 빠르고 정확하게 만들 수 있게 됩니다. 마치 복리 이자가 쌓이듯이, 개발 경험과 지식이 축적되면서 점점 더 빠른 속도로 성장하는 거죠.

어떻게 이런 마법 같은 일이 가능할까요?

4단계 개발 순환: 계획 → 작업 → 검토 → 축적

Every 팀의 개발 프로세스를 들여다보면, 흥미롭게도 실제 코드 작성은 전체 시간의 20% 정도만 차지한다고 해요. 나머지 80%는 계획과 검토에 쓰인다고 하죠.

"코드는 AI가 짜는데 왜 시간이 더 오래 걸려요?"라고 생각하실 수 있어요. 하지만 여기에 핵심이 있습니다. 좋은 계획 없이는 AI도 방향을 잃어버리거든요. 마치 아무리 빠른 자동차라도 목적지를 모르면 소용없는 것처럼요.

계획 단계: 개발의 80%를 차지하는 가장 중요한 단계

AI가 모든 코드를 작성하는 세상에서, 개발자의 시간은 대부분 계획을 짜는 데 쓰입니다. 이게 처음에는 좀 이상하게 느껴질 수 있어요. "코딩 안 하는데 무슨 개발자야?"라는 생각이 들 수도 있죠.

좋은 계획은 리서치에서 시작해요. AI 에이전트에게 현재 코드베이스를 분석하게 하고, 커밋 히스토리를 읽게 하고, 인터넷에서 모범 사례를 찾아오게 합니다. 마치 새로운 팀원이 입사해서 기존 코드를 공부하는 것처럼요.

그다음 AI는 계획 문서를 작성합니다. 이 문서에는 구현할 기능의 목표, 제안된 아키텍처, 구체적인 코드 작성 아이디어, 리서치 출처 목록, 그리고 성공 기준이 포함되어 있죠.

"잠깐, AI한테 다 맡기면 되는 거 아니에요?" 아니에요. 계획 단계는 순수한 위임이 아니라, 개발자와 AI 사이에 정확한 공통 이해를 만드는 과정이에요. 복잡한 프로덕션 프로젝트일수록 좋은 계획이 필수적이죠. 계획 없이 코딩을 시작하면 나중에 전체를 다시 뒤엎어야 하는 상황이 생기거든요.

물론 모델이 발전하면서 작은 프로젝트에서는 계획 단계가 점점 짧아지고 있어요. AI가 개발자의 의도를 더 잘 파악하거나, 예상 밖으로 좋은 결과를 내기도 하니까요. 하지만 좋은 계획을 짜는 능력은 여전히 개발자의 핵심 역량입니다. 창의성과 깊은 사고가 필요한 부분이거든요.

작업 단계: 가장 간단한 단계

계획이 잘 짜여 있다면, 이 단계는 정말 쉬워요. AI 에이전트에게 "시작해"라고 말하기만 하면 됩니다. AI는 계획을 읽고 할 일 목록을 만든 뒤, 하나씩 구현해나가죠.

여기서 중요한 트릭이 하나 있어요. MCP(Model Context Protocol) 같은 도구를 사용하는 건데요, 이걸 쓰면 AI가 웹앱을 실제로 사용해보거나 폰에서 시뮬레이션을 돌릴 수 있어요. 마치 실제 사용자처럼요.

그래서 AI는 코드를 조금 작성하고, 앱을 직접 실행해보고 문제를 발견한 다음, 코드를 수정하고, 다시 테스트하고, 만족할 때까지 반복하는 방식으로 일합니다. 특히 디자인 작업이나 사용자 플로우를 만들 때 이 방식이 굉장히 효과적이에요. 사람이 직접 보면서 "아 이건 좀 이상한데" 싶은 부분을 AI도 스스로 발견할 수 있거든요.

최신 Opus 4.5 같은 모델을 쓰면, 작업 단계에서 나오는 결과물이 대부분 제대로 작동하고 계획했던 대로 나온다고 해요. 물론 계획이 잘 짜여있을 때 말이죠. 여기서도 계획의 중요성이 다시 한번 드러나는 거예요.

검토 단계: AI와 인간이 함께 코드를 살펴보기

작업이 끝났다고 바로 배포하는 건 아니에요. 검토 단계에서는 AI가 자기 작업을 스스로 검토하고, 개발자도 함께 검토합니다.

전통적인 개발 도구들도 여전히 유용해요. 린터로 기본적인 에러를 찾고, 유닛 테스트를 실행하고, 직접 사용해보며 동작을 확인하죠. 이런 기본적인 검증은 어떤 방식으로 개발하든 필요한 과정이에요.

그런데 Every 팀은 한 발 더 나갑니다. 그들이 만든 복합 엔지니어링 플러그인은 12개의 서브 에이전트를 동시에 돌려서 코드를 검토해요. 한 에이전트는 보안 이슈를 찾고, 다른 에이전트는 성능 문제를 체크하고, 또 다른 에이전트는 과도하게 복잡한 부분이 없나 살펴봅니다.

이 모든 관점이 종합되어 개발자에게 전달되면, 개발자는 무엇을 고쳐야 하고 무엇을 무시해도 되는지 판단하죠. 사람의 판단력은 여전히 필요해요. AI가 모든 걸 알려주더라도, 그게 우리 프로젝트에 중요한 문제인지 아닌지는 결국 사람이 결정해야 하니까요.

하지만 진짜 마법은 다음 단계에서 일어납니다.

축적 단계: 복리 효과가 만들어지는 곳

이 단계가 복합 엔지니어링의 핵심이에요. 앞 단계들에서 배운 것들을 그냥 흘려보내지 않고, 버그든 성능 이슈든 문제 해결 방법이든 모두 기록해서 다음번에 AI가 활용할 수 있게 만드는 거죠.

예를 들어볼까요? Every의 이메일 어시스턴트 Cora의 코드베이스에는 이런 규칙들이 쌓여 있어요. 새로운 기능을 추가하기 전에 스스로에게 물어보라는 거죠. 이게 시스템의 어디에 속하는지, 기존 것에 추가해야 할지 새로 만들어야 할지, 비슷한 문제를 전에 해결한 적이 있나 재사용할 수 있을지를요.

그리고 이 질문들에는 과거에 겪었던 실수의 구체적인 사례들이 함께 저장되어 있어요. "지난번에 A 방식으로 했다가 B 문제가 생겼으니 이번엔 C 방식을 고려해봐"라는 식으로요.

멋진 점은 이게 거의 자동으로 일어난다는 거예요. 코드 리뷰가 끝나면, AI에게 "리뷰 코멘트를 요약해서 나중을 위해 저장해줘"라고 하면 됩니다. 최신 모델들은 이걸 아주 잘 해내죠. 사람이 일일이 문서화할 필요가 없어요.

그리고 더 멋진 점은 이 학습 내용이 팀 전체에 자동으로 공유된다는 거예요. 이 규칙들은 코드베이스 안에 프롬프트로 저장되거나 플러그인으로 만들어져서, 팀의 모든 개발자가 사용할 수 있어요. 어제 입사한 신입이나 3년차 시니어나 똑같이 과거의 실수를 피할 수 있는 거죠. 신입 개발자가 "저 이거 처음인데요"라고 걱정할 필요가 없어요. 팀이 쌓아온 모든 지혜가 이미 시스템 안에 들어있으니까요.

복리 효과의 실현

전통적인 개발에서는 코드베이스가 커질수록 개발이 느려졌어요. 복잡도가 기하급수적으로 증가하니까요. 레거시 코드를 건드리는 게 두렵고, 새로운 기능 하나 추가하는데 예상치 못한 버그가 다섯 군데에서 터지고, 결국 "이 프로젝트는 이제 손 못 대겠다"는 상황까지 가기도 했죠.

하지만 복합 엔지니어링에서는 반대예요. 코드베이스가 커지면 AI의 지식도 함께 커지기 때문에, 새로운 기능 개발이 오히려 더 빨라집니다. 열 번째 기능을 만들 때는 첫 번째 기능을 만들 때보다 훨씬 빠르고 정확하게 만들 수 있어요. 이전에 겪었던 모든 시행착오가 학습 자료로 축적되어 있으니까요.

이게 바로 '복리(Compound)' 효과죠. 은행 예금의 복리 이자처럼, 시간이 지날수록 가속도가 붙는 겁니다.

개발자의 새로운 병목: 생각의 속도

이제 소프트웨어 개발의 병목은 코딩 속도가 아니에요. 타자를 아무리 빨리 쳐도 개발 속도가 빨라지지 않는 세상이 된 거죠.

새로운 병목은 무엇을 만들지 결정하는 속도, 계획을 처리하고 개선하는 속도, 그리고 '좋은 것'이 무엇인지 설명하는 능력입니다. 결국 생각의 속도가 개발 속도를 결정하게 된 거예요.

이건 사실 좋은 소식이에요. 개발자가 타이핑 속도나 라이브러리 암기력으로 평가받는 게 아니라, 문제 해결 능력과 설계 사고로 평가받게 된다는 뜻이니까요. 진짜 중요한 스킬이 빛을 발하게 된 거죠.

달라지는 것들

복합 엔지니어링이 자리잡으면 많은 것들이 달라져요. 수동으로 테스트 코드 짜는 일도 사라지고, 읽기 쉽게 주석 달기 위해 고민하는 일도 줄어들죠. 면접에서 화이트보드에 코드 짜는 것도 의미가 없어지고, 신입이 첫 커밋하는데 몇 주 걸리는 일도 없어집니다. 레거시 코드 때문에 기술 스택을 못 바꾸는 상황도 개선될 수 있어요.

대신 가능해지는 것들도 많아요. 개발자 한 명이 전체 제품을 담당할 수 있고, 복잡한 리팩토링을 두려워하지 않게 되고, 새로운 기술 스택으로 빠르게 전환할 수 있고, 신입도 첫날부터 의미있는 기여를 할 수 있게 됩니다.

시작하는 방법

"좋은 건 알겠는데, 우리 팀은 어떻게 시작하죠?" Every 팀은 자신들이 쓰는 방식을 Claude Code 플러그인으로 공개했어요. 지금 당장 다운받아서 똑같은 워크플로우를 써볼 수 있습니다.

물론 도구는 도구일 뿐이에요. 중요한 건 마인드셋의 전환입니다. 계획에 시간을 투자하기 시작해야 해요. 바로 코딩하고 싶은 유혹을 참고 먼저 생각하는 거죠. AI를 명령하는 도구가 아니라 협업하는 팀원처럼 대하고, 한 번 겪은 문제는 두 번 안 겪게 만드는 시스템을 갖추고, 전체 프로젝트를 한 번에 바꾸려 하지 말고 한 기능부터 작게 시작하는 겁니다.

개발자의 미래

코드를 안 짜는 개발자의 시대가 온다고 해서, 개발자가 필요없어지는 건 아니에요. 오히려 반대죠. 개발자는 이제 무엇을 만들지 구상하는 사람, 시스템이 어떻게 작동해야 하는지 설계하는 사람, AI의 작업물을 평가하고 개선하는 사람, 그리고 팀 전체의 학습을 시스템화하는 사람이 되어가고 있어요.

어쩌면 이게 원래 개발자가 해야 했던 일인지도 모르겠어요. 단지 지금까지는 코드 타이핑하느라 시간이 없었을 뿐이죠. AI가 코드를 대신 짜주는 시대, 개발자는 드디어 진짜 엔지니어링을 할 시간을 갖게 된 것 같습니다.

---

출처: [클릭]

이 글이 도움이 되셨나요? 여러분 팀은 AI 코딩 도구를 어떻게 활용하고 계신가요? 댓글로 경험을 공유해주세요!