시니어 개발자가 자기 전문성을 제대로 설명하지 못하는 이유

시니어 개발자가 보는 괴물은 ‘복잡성’임

• 글의 출발점은 요즘 많이 들리는 말, ‘AI 에이전트가 개발자를 대체할 것’에 대한 묘한 불편함임

  • 저자는 비개발자가 이 말을 믿는 건 이해하지만, 시니어 개발자가 그대로 믿는다면 전문성을 의심하게 된다고 말함
  • 이유는 개발이라는 일을 단순히 코드를 생산하는 행위로 보면 AI의 속도가 압도적으로 보이지만, 시니어 개발자의 실제 책임은 그보다 넓기 때문임
  • 특히 운영 중인 시스템을 책임지는 개발자라면 ‘얼마나 빨리 만들었나’보다 ‘이걸 계속 이해하고 고칠 수 있나’를 더 무겁게 봄

• 저자가 좋아하는 시니어 개발자는 새 도구를 들이대는 사람이 아니라, 일을 줄이는 사람임

  • “이거 정말 필요해?”, “안 하면 무슨 일이 생기지?”, “지금은 있는 걸로 버틸 수 없나?” 같은 질문을 던지는 타입
  • 이 태도는 게으름이 아니라 복잡성을 피하려는 전문성에 가깝다는 주장임
  • 새 조건문, 새 테이블, 새 컴포넌트, 새 특수 케이스는 모두 시스템을 더 이해하기 어렵게 만들 수 있음

• 시니어 개발자가 복잡성을 무서워하는 이유는 안정성과 직결되기 때문임

  • 복잡성이 올라가면 시스템은 덜 이해 가능하고, 덜 디버깅 가능하고, 덜 고치기 쉽고, 덜 가르치기 쉬워짐
  • 결국 운영 안정성이 떨어지고, 고객에게 계속 서비스를 제공해야 하는 책임이 흔들림
  • 돈을 내는 고객이 있는 시스템에서는 이 책임이 꽤 현실적인 압박으로 다가옴

비즈니스가 보는 괴물은 ‘불확실성’임

• 반대로 마케팅, 영업, 제품관리자, 최고경영자는 다른 루프에 살고 있음

  • 이들의 목표는 아이디어를 시장에 빨리 내보내고 피드백을 받아 가치가 있는지 배우는 것임
  • 이 루프에서 무서운 건 복잡성이 아니라 불확실성임
  • 어떤 전략도 성공을 보장하지 않으니, 제한된 시간 안에 더 많이 시도해보는 게 불확실성을 줄이는 방법처럼 보임

• 회사가 고객을 얻는 순간 두 개의 루프가 동시에 돌아가기 시작함

  • 하나는 시장에 빠르게 시도해서 배우려는 루프
  • 다른 하나는 돈을 내는 고객에게 서비스를 안정적으로 제공하려는 루프
  • 전자는 속도를 원하고, 후자는 안정성과 이해 가능성을 원함
  • 같은 기능 요청을 두고도 한쪽은 “빨리 배워야 한다”고 보고, 다른 한쪽은 “시스템 복잡도가 또 늘어난다”고 보는 이유임

• 그래서 시니어 개발자의 커뮤니케이션이 자주 실패함

  • 시니어 개발자는 “유지보수 비용”, “이해 가능성”, “장기 생산성”, “복잡성”을 말함
  • 그런데 사업팀의 문제는 불확실성을 줄이는 것이기 때문에, 이 말은 상대의 문제를 직접 해결하는 언어가 아님
  • 저자의 진단은 꽤 날카로움: 다른 사람의 문제를 내 문제의 언어로 설명해서는 설득이 안 됨

• 시니어 개발자의 진짜 강점은 안 만들어도 되는 걸 알아보는 능력임
  • 설문 데이터가 필요하면 새 기능 대신 구글 폼으로 시작할 수 있음
  • 새 기능 검증이 필요하면 기존 화면에 버튼 하나를 넣고 클릭 여부를 볼 수 있음
  • 분석 서비스가 필요하면 먼저 가장 중요한 의사결정 하나, 차트 하나, 지표 하나로 시작할 수 있음
  • 이건 비즈니스가 원하는 빠른 학습을 주면서도 시스템 복잡성을 늘리지 않는 방식임

AI는 속도를 주지만 책임을 지지는 않음

• AI가 들어오면 이 논의가 더 복잡해짐

  • AI 에이전트는 시장에 무언가를 가져가는 속도를 엄청나게 높일 수 있음
  • 하지만 동시에 안정성을 맡은 루프에는 부담을 줄 수 있음
  • 이해 가능성, 수정 가능성, 디버깅 가능성, 교육 가능성이 떨어질 수 있기 때문임

• 저자는 AI가 아직 못 하는 일을 ‘책임지기’라고 봄

  • AI, 주니어 개발자, 비개발자, 투자자까지 모두 시스템에 코드를 추가하면 속도는 빨라질 수 있음
  • 대신 시스템은 점점 이해하기 어려워지고 안정성은 흔들릴 수 있음
  • 문제가 터졌을 때 끝까지 원인을 파악하고 고치고 운영 책임을 지는 건 여전히 사람, 특히 시니어 개발자의 몫임

• 그래서 시니어 개발자의 역할은 작성자보다 편집자에 가까워질 수 있음

  • 소설가가 빠르게 초고를 쓴 뒤 편집자가 되는 부분과 버릴 부분을 골라 하나의 일관된 결과물로 다듬는 비유가 나옴
  • AI와 빠른 실험은 초고를 만드는 역할에 가까움
  • 시니어 개발자는 그중 실제로 살아남은 것을 안정적이고 이해 가능한 시스템으로 옮기는 편집자 역할을 맡게 됨

• 저자가 제안하는 구조는 ‘스피드’ 버전과 ‘스케일’ 버전을 분리하는 것임

  • 스피드 버전은 시장 피드백을 빨리 얻기 위한 시스템으로, AI 에이전트나 검토 덜 된 코드, 주니어 개발자, 마케팅팀까지 활용할 수 있음
  • 스케일 버전은 시니어 개발자가 안정성, 이해 가능성, 확장성을 고려해 다듬는 운영용 시스템임
  • 기능은 스피드에서 먼저 만들어지고, 효과가 확인된 뒤 스케일에서 안정화되는 흐름임

• 이 방식의 핵심은 속도와 안정성을 같은 시스템 하나에 억지로 다 넣지 않는 데 있음

  • 예를 들어 “스피드 버전은 3일 안에 보여줄 수 있고, 스케일 버전은 6주 정도 걸린다”고 말할 수 있음
  • 사업팀은 빠른 학습과 모멘텀을 얻고, 개발팀은 관찰과 설계를 할 시간을 얻음
  • 완벽한 답이라기보다, AI 시대에 시니어 개발자가 자신의 책임을 비즈니스 언어로 다시 설명하는 프레임에 가까움

• 결론은 꽤 간단하지만 묵직함

  • 시니어 개발자는 복잡성을 말하고, 나머지 회사는 불확실성을 걱정함
  • 커뮤니케이션이 되려면 복잡성 관리를 불확실성 감소에 도움이 되는 방식으로 번역해야 함
  • AI가 코드를 더 빨리 쓰게 만들수록, 시니어 개발자는 시스템을 더 잘 편집하고 책임지는 사람으로 남게 됨

---

기술 맥락

• 이 글의 기술적 선택은 속도와 안정성을 한 시스템에서 동시에 해결하려 하지 말고 역할을 분리하자는 거예요. 빠른 실험은 시장의 불확실성을 줄이는 데 좋지만, 그 코드가 그대로 운영 시스템에 들어가면 복잡성과 유지보수 비용이 쌓이기 쉽거든요.

• 왜 시니어 개발자가 복잡성을 싫어하냐면, 복잡성은 장애가 났을 때 원인을 찾고 고치는 시간을 늘리기 때문이에요. 고객이 이미 돈을 내는 서비스에서는 이해 가능성과 디버깅 가능성이 곧 안정성이라서, 새 기능 하나도 그냥 추가하기 어렵게 느껴져요.

• 저자가 말한 스피드 버전과 스케일 버전은 프로토타입과 운영 시스템을 명확히 나누자는 관점에 가까워요. 스피드 버전에서는 AI와 빠른 구현을 활용해 시장 반응을 보고, 스케일 버전에서는 살아남은 아이디어만 다시 설계해 안정적으로 옮기는 방식이에요.

• AI 에이전트가 중요한 이유는 코드 생산 비용을 낮추기 때문이에요. 하지만 생산 비용이 낮아질수록 검토되지 않은 코드가 늘 수 있고, 그 결과 시스템을 이해하는 비용은 오히려 올라갈 수 있어요.

• 그래서 시니어 개발자의 역할은 코드를 덜 쓰는 사람이 아니라 책임질 수 있는 형태로 시스템을 정리하는 사람에 가까워져요. 비즈니스에는 빠른 실험을 주고, 운영 시스템에는 이해 가능한 구조를 남기는 게 핵심이에요.