결론부터 말씀드리겠습니다. 시니어 개발자와 주니어 개발자의 차이는 코딩 속도에 있지 않습니다. 같은 기능을 구현할 때, 시니어가 키보드를 잡는 시간은 오히려 더 짧은 경우가 많습니다. 차이는 키보드를 잡기 전에 벌어집니다. 문제를 어떻게 분해하는가, 어떤 구조를 선택하는가, 무엇을 만들지 않을 것인가를 결정하는 시간. 이 시간이 이후 모든 코드의 품질과 생산성을 결정합니다. AI가 코드를 대신 써주는 시대에, 이 사실은 더 선명해지고 있습니다.
코딩은 개발의 일부일 뿐이다
개발자가 실제로 코드를 작성하는 데 쓰는 시간은 전체 업무 시간의 극히 일부입니다. 나머지는 회의, 코드 리뷰, 설계 논의, 문서 작성, 디버깅에 분배됩니다. 시니어 엔지니어의 경우 여기에 멘토링, 아키텍처 의사결정, 이전에 출시한 제품의 운영 지원까지 더해집니다. 그리고 이 컨텍스트 전환에는 매번 15~30분의 워밍업 비용이 따릅니다.
그런데 많은 조직에서 개발자의 생산성을 측정하는 기준은 여전히 “얼마나 많은 코드를 짰는가”에 가깝습니다. PR 수, 커밋 수, 코드 라인 수. 이 지표들은 코딩이라는 행위의 양을 측정할 뿐, 그 코드가 올바른 문제를 올바른 방식으로 해결했는지는 말해주지 않습니다.
프레드 브룩스(Fred Brooks)는 1986년 논문 「No Silver Bullet」에서 소프트웨어의 복잡성을 본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)으로 구분했습니다. 우발적 복잡성은 도구와 언어의 발전으로 줄일 수 있지만, 본질적 복잡성은 문제 자체에 내재한 것이어서 어떤 도구로도 제거할 수 없습니다. AI 코딩 도구가 아무리 발전해도 줄일 수 있는 것은 우발적 복잡성뿐입니다. 본질적 복잡성을 다루는 일, 즉 문제를 정의하고 구조를 설계하는 일은 여전히 사람의 영역입니다.
설계라는 보이지 않는 작업
소프트웨어 프로젝트에서 재작업(rework)이 전체 활동의 30~50%를 차지한다는 연구 결과가 있습니다. 그리고 그 재작업의 절반은 요구사항 단계의 문제에서 비롯됩니다. 재작업된 코드의 비용은 처음부터 올바르게 작성된 코드의 2.5배에 달합니다. 이 숫자들이 가리키는 방향은 명확합니다. 코드를 짜기 전에 충분히 생각하는 시간이, 코드를 짠 뒤 고치는 시간보다 훨씬 효율적이라는 것입니다.
허버트 사이먼(Herbert Simon)은 제한된 합리성(bounded rationality) 이론에서, 인간의 인지적 한계를 인정하고 복잡한 문제를 관리 가능한 단위로 분해하는 것이 합리적 의사결정의 핵심이라고 주장했습니다. 그는 『인공의 과학』(The Sciences of the Artificial)에서 설계 행위 자체가 제한된 합리성 안에서의 문제 해결 과정이라고 설명합니다. 시니어 개발자가 코드를 짜기 전에 하는 일이 바로 이것입니다. 복잡한 요구사항을 작은 단위로 분해하고, 각 단위의 경계와 인터페이스를 정의하고, 트레이드오프를 따져 구조를 결정합니다.
(솔직히 말하면, 저도 경력 초반에는 이 과정을 건너뛰고 바로 코드부터 짜는 편이었습니다. 그 대가는 어김없이 리팩터링이라는 이름으로 돌아왔습니다.)
AI 시대에 더 중요해지는 설계 역량
Cloudflare의 엔지니어링 리드 Boris Tane은 AI 코딩 도구를 활용하는 자신의 워크플로우를 공개한 바 있습니다. 그의 접근은 세 단계로 구성됩니다. Research → Plan → Implement. 흥미로운 점은, 전체 워크플로우에서 코드 구현은 마지막 단계에 불과하며, 그 전까지의 모든 시간은 조사와 계획에 투입된다는 것입니다.
그는 AI에게 코드베이스를 “깊이 있게”(deeply, in great detail) 분석하도록 지시한 뒤, 그 결과를 research.md라는 문서로 정리합니다. 이어서 plan.md를 작성하고, 여기에 직접 인라인 주석을 달아 도메인 지식과 제약사항을 반영합니다. “PATCH를 쓸 것, PUT이 아니라”, “캐싱 제거, 불필요함”과 같은 구체적 지시를 통해 설계 의사결정을 확정합니다. 이 주석 달기 사이클을 1~6회 반복한 뒤에야 비로소 “implement it all”이라는 명령을 내립니다.
이 워크플로우의 본질은 무엇일까요. AI가 코드를 생성하는 속도가 빨라질수록, 무엇을 만들 것인가를 결정하는 인간의 판단이 병목이 된다는 것입니다. 코드 작성이라는 우발적 복잡성을 AI가 처리해주는 만큼, 개발자는 본질적 복잡성에 집중할 여유가 생깁니다. 하지만 그 여유를 활용하려면, 설계와 판단의 역량이 갖춰져 있어야 합니다.
실제로 2025년 Stack Overflow 개발자 설문에서도 이 변화가 감지됩니다. 시스템 설계 사고, 디버깅 역량, 아키텍처 판단력은 2024년까지 우수한 개발자를 구분하는 기준이었지만, 2026년에는 모든 개발자에게 필수 역량이 되어가고 있습니다. 프레임워크를 잘 다루는 것으로 충분했던 시대는 지나가고, 시스템이 왜 그렇게 작동하는지를 이해하는 개발자가 살아남는 시대가 오고 있습니다.
코드를 짜기 전에 하는 일들
그렇다면 시니어 개발자가 코드를 짜기 전에 구체적으로 무엇을 하는지 정리해보겠습니다. 이것은 거창한 방법론이 아닙니다. 내일부터 적용할 수 있는 실무 습관입니다.
문제를 문장으로 정의한다. “이 작업이 해결하려는 핵심 문제는 무엇인가”를 한 문장으로 쓰는 것에서 시작합니다. 이 문장이 명확하지 않으면, 코드도 명확해질 수 없습니다. 요구사항 문서를 받았더라도, 자기 언어로 다시 정의하는 과정이 필요합니다.
구조를 먼저 그린다. 코드 에디터를 열기 전에, 모듈 간의 관계와 데이터의 흐름을 스케치합니다. 종이 위의 상자와 화살표만으로 충분합니다. 이 단계에서 발견하는 설계 결함은 수정 비용이 거의 제로에 가깝습니다. 코드 작성 후에 발견하면 2.5배의 비용이 듭니다.
하지 않을 것을 결정한다. 좋은 설계는 무엇을 포함할지만큼, 무엇을 제외할지에서 결정됩니다. “이 기능은 이번 스코프에 포함하지 않는다”, “이 최적화는 지금 필요하지 않다”와 같은 결정을 명시적으로 기록합니다. (이것을 안 하면 스코프 크리프라는 괴물이 찾아옵니다.)
트레이드오프를 문서로 남긴다. “A 방식은 성능이 좋지만 복잡성이 증가한다. B 방식은 단순하지만 확장에 제약이 있다. 현재 트래픽 규모를 고려하면 B가 적합하다.” 이런 의사결정 기록이 있으면, 3개월 뒤 코드를 읽는 동료가 (혹은 미래의 자신이) “왜 이렇게 짰지?”라는 질문에 답할 수 있습니다.
결론
AI가 코드를 대신 써주는 시대에, 개발자의 가치는 코드를 짜는 속도가 아니라 무엇을 짤 것인가를 결정하는 판단력에 있습니다. 브룩스가 40년 전에 지적한 본질적 복잡성은 어떤 도구로도 해결되지 않습니다. 그것은 문제를 이해하고, 분해하고, 구조를 설계하는 인간의 사고로만 다룰 수 있습니다.
결국 좋은 엔지니어링이란, 좋은 코드를 빠르게 짜는 것이 아니라 올바른 코드를 짜기 위한 올바른 질문을 던지는 것입니다. 키보드를 잡기 전 15분의 생각이, 키보드 위에서 보내는 3시간의 코딩보다 더 생산적인 순간은 분명히 존재합니다.
참고 자료
- Brooks, Fred. “No Silver Bullet—Essence and Accident in Software Engineering”, IEEE Computer, 1986
- Simon, Herbert A. 『The Sciences of the Artificial』, MIT Press, 1969
- Tane, Boris. “How I Use Claude Code”, boristane.com, 2025
- Stack Overflow. “2025 Developer Survey Results”, 2025
- ScopeMaster. “Software Rework: How to Reduce It” (재작업 비용 2.5배 데이터)
- Info-Tech Research Group. 요구사항 품질과 재작업 비율 연구
무료로 시작하기
