시니어 개발자가 전문성을 전달하지 못하는 이유

• 시니어 개발자와 비개발자는 AI 에이전트가 개발자를 대체한다는 같은 문장을, 안정성과 시장 학습이라는 서로 다른 기준으로 받아들임
• 비즈니스 조직은 빠르게 출시해 피드백을 얻고 불확실성을 줄이려 하지만, 시니어 개발자는 시스템을 망가뜨리는 복잡성 증가를 경계함
• 고객이 생긴 뒤에는 시장 탐색과 서비스 지속이라는 두 순환이 동시에 돌며, 시니어 개발자의 핵심 책임은 복잡성 관리로 바뀜
• 설득은 “복잡성이 문제”라고 말하는 데서 끝나지 않고, Google Forms나 기존 UI 버튼처럼 더 빠른 실험으로 상대의 속도 욕구를 충족해야 가능함
• AI는 출시 속도를 높이지만 이해·수정·디버깅 가능성을 해칠 수 있고 책임지지 않으므로, 시니어 개발자는 Speed와 Scale을 분리할 수 있음

서로 다른 기준으로 같은 문장을 듣는 이유

• 시니어 개발자와 비개발자는 “AI 에이전트가 소프트웨어 개발의 미래이며 개발자는 필요 없어질 것”이라는 같은 문장을 서로 다르게 받아들임
• 카피라이팅에서 메시지는 청중에 맞아야 하며, 같은 문장도 청중에 따라 다른 의미가 됨
• 시니어 개발자의 직감이 AI 낙관론과 갈라지는 이유는 업무의 초점이 시장 학습인지, 서비스 안정성인지에 따라 문제 정의가 달라지기 때문임

시니어 개발자가 경계하는 것

• 시니어 개발자 중에는 새 도구, 다른 회사의 방식, Hacker News의 모범 사례를 근거로 무언가를 도입하려는 유형이 있음
• 더 선호되는 시니어 개발자는 “정말 필요한가?”, “안 하면 어떻게 되는가?”, “지금은 버티고 나중에 더 중요해지면 다시 볼 수 있는가?”를 먼저 물음
• 이 유형은 개발을 최대한 피하고, 줄이고, 재사용하려 함
• 전문 소프트웨어 개발에서 시니어 개발자가 가장 경계하는 대상은 복잡성임
• 특수 케이스, 조건문, 새 데이터베이스 테이블, 새 컴포넌트는 모두 시스템에 복잡성을 더함
• 작동 중인 시스템에 책임을 지는 개발자는 결국 복잡성 증가를 두려워하게 됨
• 새롭고 창의적인 설계를 잘하는 시니어 개발자도 작동 중인 시스템을 맡으면 복잡성을 경계하게 됨

비즈니스 조직이 경계하는 것

• 마케터, 영업 담당자, 제품 관리자, CEO는 시장에 무언가를 내놓고 피드백을 받아 가치가 있는지 배우는 순환 속에 있음
• 이 순환의 목표는 학습이며, 가장 큰 위협은 불확실성임
• 어떤 전략도 성공이 보장되지 않기 때문에 불확실성은 가혹하게 작동함
• 마케팅·영업 보상, 창업자의 급여, 제품 관리자의 데이터가 시간과 결합되면, 마감 전에 불확실성을 줄이는 유일한 방법이 최대한 빨리 시장에 내놓는 것처럼 느껴짐
• 시장에 더 많이 내놓을수록 더 많은 피드백을 얻고, 잠재적으로 불확실성을 더 줄일 수 있음
• 모든 회사는 이 순환에서 시작하며, 이 순환은 순수한 속도를 중심으로 움직임

고객이 생긴 뒤의 두 번째 순환

• 고객이 돈을 내기 시작하면 서비스의 지속과 보장을 목표로 하는 두 번째 순환이 생김
• 시스템은 계속 작동해야 하고, 이해 가능하며, 디버깅 가능하고, 수정 가능하고, 가르칠 수 있고, 안정적이어야 함
• 시니어 개발자는 고객에게 계속 서비스를 제공해야 하는 비즈니스 책임을 맡기 때문에 안정성을 중요하게 여김
• 이 모든 것을 위협하는 것은 다시 복잡성임
• 복잡성은 시스템을 덜 이해 가능하게, 덜 디버깅 가능하게, 덜 수정 가능하게, 덜 가르치기 쉽게, 결국 덜 안정적으로 만듦
• 복잡성이 올라가면 안정성이 내려가고, 시니어 개발자는 책임을 다하지 못하며, 결제 중단 같은 문제가 생길 수 있음
• 첫 번째 순환의 목표가 불확실성 감소라면, 두 번째 순환의 목표는 복잡성 관리임

커뮤니케이션이 실패하는 지점

• 고객이 생긴 뒤에는 시장 탐색과 서비스 지속이라는 두 순환이 동시에 돌아감
• 비즈니스는 가능성을 탐색하면서 동시에 고객에게 서비스를 제공해야 함
• 어느 순환에 시간을 쓰느냐에 따라 같은 문제가 다르게 보임
• 비즈니스 조직은 불확실성을 줄이기 위해 더 빨리 만들고 시장에 내놓으려 함
• 시니어 개발자는 요청이 늘어날수록 복잡성, 유지보수 비용, 이해 가능성, 지속적인 개발 속도, 시간에 따른 생산성을 걱정함
• 하지만 복잡성 관리의 언어만으로는 다른 부서의 불확실성 감소 욕구를 해결하기 어려움
• 설득하려면 시니어 개발자의 해법을 상대의 문제에 대한 해법으로도 표현해야 함
• 커뮤니케이션은 복잡성 관리의 관점으로 문제를 말하면서, 불확실성 감소의 관점으로 해법을 말하지 못할 때 실패함

시니어 개발자의 실질적 강점

• 시니어 개발자의 가장 유용한 능력은 불필요한 것을 만들지 않고, 이미 만들어진 것을 재사용할 기회를 찾아내는 데 있음
• 설문 데이터를 수집해야 한다면 Google Forms를 쓰면 됨
• 새 기능 전체를 만들어 테스트하는 대신 기존 UI에 버튼을 넣고 사람들이 클릭하는지 볼 수 있음
• 새 분석 서비스를 도입하기 전에 분석이 필요한 가장 중요한 의사결정을 먼저 묻고, 하나의 결정, 하나의 차트, 하나의 지표로 시작할 수 있음
• 생일 케이크 전체를 굽는 대신 샌드위치에 초 하나를 꽂는 식의 접근이 가능함
• 시니어 개발자는 기존 소프트웨어를 활용해 사람들이 원하는 것을 제공하는 법을 배움
• 이를 짧게 전달하는 문장은 “Can we try something quicker?”임
• “quicker”는 상대가 실제로 원하는 속도를 인정함
• “something”은 다른 달성 방법이 있음을 암시함
• “try”는 불완전하지만 충분히 좋을 수 있다는 가능성을 담음
• 이 문장은 회사가 원하는 불확실성 감소 속도를 인정하면서도, 시니어 개발자가 줄이고, 재사용하고, 가능하면 피하는 전문성을 발휘할 여지를 줌

AI가 바꾸는 압력과 남는 책임

• AI는 짧은 시간에 많은 것을 만들 수 있기 때문에 줄이고, 재사용하고, 피하는 태도가 무의미해 보일 수 있음
• 하지만 AI는 아직 시니어 개발자가 하는 한 가지 일인 책임지기를 하지 못함
• 시니어 개발자가 시스템 이해 가능성을 중요하게 여기는 이유는 문제가 생겼을 때 고칠 수 있어야 하기 때문임
• 이해 가능성은 시스템이 성장해야 할 때 지능적으로 확장하고, 유료 고객에게 계속 안정적으로 서비스를 제공하게 해줌
• AI는 시장에 내놓는 속도를 크게 높이지만, 시니어 개발자가 책임지는 안정성 순환에도 영향을 줌
• AI 에이전트, 주니어 개발자, 비개발자, 투자자와 그 주변 사람들까지 시스템에 코드를 추가하면, 시스템은 속도를 과도하게 보상하는 대신 안정성을 포기하게 됨
• AI는 이해 가능성, 수정 가능성, 디버깅 가능성, 가르칠 수 있음, 보장 가능성을 악화시킬 수 있음
• AI는 시스템을 불안정하게 만들 수 있지만 책임은 지지 않음
• 이 지점이 시니어 개발자의 핵심 걱정임

작성자보다 편집자에 가까운 시니어 개발자

• 시니어 개발자가 쓸 수 있는 한 가지 방법은 분리(decoupling) 임
• 오랫동안 소프트웨어 개발자만 소프트웨어를 만들 수 있었기 때문에, 개발자는 시장 학습과 서비스 안정성이라는 두 순환을 모두 책임졌음
• 하나의 시스템이 두 목표를 동시에 지탱하는 구조였음
• 두 목표에 각각 다른 시스템을 둔다면 속도와 안정성을 분리할 수 있음
• 소설가가 빠르게 초고를 완성한 뒤, 나중에 잘 되는 부분을 뽑고 안 되는 부분을 버리는 편집 과정을 거치는 것과 비슷함
• 편집자의 일은 잘 작동하는 조각을 가져와 응집력 있는 전체로 다듬는 것임
• Speed 버전은 속도를 위한 시스템으로, AI 에이전트, 생성된 미검토 코드, 주니어 개발자, 마케팅 등이 빠르게 아이디어를 실현하는 공간이 될 수 있음
• Speed 버전은 이해 가능성이 아니라 시장 피드백을 얻을 만큼 충분히 좋은 상태를 목표로 함
• Scale 버전은 안정성을 위한 시스템으로, 시니어 개발자가 안정적이고 이해 가능하며 확장 가능하게 설계함
• Speed 버전은 비즈니스가 시장에서 계속 배우게 해주고, 시니어 개발자는 그 뒤를 따라 잘 검토되고 이해 가능한 시스템을 구축함
• Scale 버전의 설계는 Speed 버전에서 무엇이 잘 작동했고 무엇이 작동하지 않았는지에 영향을 받음
• 기능은 Speed에서 만들어지고, 이후 Scale에서 안정화됨
• 실제 구현 형태는 명확하지 않을 수 있지만, 핵심은 속도를 추구하는 일과 안정성을 추구하는 일이 다르다는 점을 명시적으로 분리하는 데 있음
• 야심 찬 요청을 받았을 때 “Speed 버전은 3일 안에 준비하고, Scale 버전은 약 6주 뒤에 준비하겠다”고 말할 수 있음
• 상대는 속도와 추진력을 얻고, 시니어 개발자는 관찰과 설계의 시간을 얻음
• 이런 관점에서 시니어 개발자는 “시니어 소프트웨어 작성자”보다 시니어 소프트웨어 편집자에 가까워질 수 있음