# 시니어 개발자가 전문성을 전달하지 못하는 이유 > Clean Markdown view of GeekNews topic #29459. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29459](https://news.hada.io/topic?id=29459) - GeekNews Markdown: [https://news.hada.io/topic/29459.md](https://news.hada.io/topic/29459.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-13T13:38:51+09:00 - Updated: 2026-05-13T13:38:51+09:00 - Original source: [nair.sh](https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise) - Points: 3 - Comments: 1 ## Topic Body - **시니어 개발자**와 비개발자는 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주 뒤에 준비하겠다”고 말할 수 있음 - 상대는 속도와 추진력을 얻고, 시니어 개발자는 관찰과 설계의 시간을 얻음 - 이런 관점에서 시니어 개발자는 “시니어 소프트웨어 작성자”보다 **시니어 소프트웨어 편집자**에 가까워질 수 있음 ## Comments ### Comment 57382 - Author: neo - Created: 2026-05-13T13:38:51+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48109460) - 전문성의 가장 중요한 부분은 내부 **세계 모델**에서 나오며, 그것과 분리할 수 없음 보통은 무엇이든 말로 표현할 수 있고, 말만 전달되면 듣는 사람이 말한 사람의 뜻을 그대로 이해한다고 믿지만, 이 믿음 때문에 개발자의 전문성을 다른 사람에게 “전달”하라는 요구가 생김 사실 지식은 말로 꽤 잘 전달되지만, 모든 지식이 연결되어 굳어진 세계 모델은 그렇지 않음. AI는 사실을 훨씬 많이 알 수 있어도, 아직 그 지식을 바탕으로 놀라울 만큼 자주 맞는 통찰을 내는 방식으로 활용하지는 못함 전문성 전달은 실제로는 **어디로 가고 무엇을 배워야 하는지에 대한 힌트**에 가깝고, 받는 사람이 내면화할 노력과 적절한 프로젝트를 통해 같은 전문성을 획득해야 함 - 재능 있어 보이고 “감”을 잡는 주니어와 그렇지 않은 주니어의 큰 차이 중 하나가 **정확한 세계 모델을 빠르게 형성하는 능력**임 소프트웨어의 “물리 법칙”을 이해해 적용하는 사람과, 그냥 절차만 적어 내려가며 각 단계의 본질을 이해하려 하지 않는 사람은 구분됨 객체지향에 익숙한 사람에게 함수형 프로그래밍을 가르칠 때 특히 두드러지는데, 어떤 사람은 모델이 깨지고, 어떤 사람은 변수의 세계에서 모나드의 세계로 비교적 쉽게 번역할 수 있음을 빠르게 봄 - 우연히 어제 Peter Naur가 1985년에 쓴 글 [https://pages.cs.wisc.edu/~remzi/Naur.pdf]()을 봤고, 계속 생각하게 됨 거의 30년 동안 대부분 한 대기업에서 일했고, 매주 상당한 시간을 새로 온 사람들이 겪는 문제에 답하는 데 씀. 질문만 들어도 문제의 뿌리가 그들의 세계 모델, Naur가 말하는 **Theory**가 불완전하거나 왜곡되어 추론을 어렵게 만든다는 걸 바로 알 때가 많음 과제는 자신의 이론을 텍스트와 다이어그램 같은 상징 표현으로 바꿔, 충분한 경험과 지능을 가진 사람이 비슷한 정신 모델을 떠올리게 만드는 것임. 즉 내 이론을 다른 사람의 머릿속에 설치하고 싶은 것 Naur가 말한 유형의 이론은 직접 이식할 수 없지만, 시니어 개발자의 일은 강의실이든 현장이든 경험을 끌어와 그런 이론을 재생산하는 방법을 찾는 것이라고 봄. 그래서 커뮤니케이션 능력이 중요하고, 다른 사람에게서 작동 이론을 받는 과정을 여러 번 겪어야 효과적인 본능이 생김 이제 이 일이 업무에서 가장 보람 있는 부분이 되었고, 의미 있게 이 기능을 수행한다고 느끼는 한 은퇴를 서두르고 싶지 않음 - 모두가 같은 내부 세계 모델을 가졌다면 **혁신**은 거의 없었을 테니, 오히려 이건 좋은 일이라고 봄 주니어를 훈련하고 멘토링할 때 가능한 것과 실패로 이어지는 패턴을 보여주려 하지만, 그 훈련은 대개 조각나 있고 불완전함 가능한 한 왜 그렇게 하는지 설명하지만, 하지 말라고 딱 잘라 말하는 건 많지 않음. 내가 가르친 사람들이 문제를 푸는 방식에 자주 놀라고, 나도 자주 배움 자기 기여에 관심이 없고 일을 급여 수단으로만 보는 사람에게는 훈련이 덜 성공적임. 그렇게 생각하는 게 틀렸다는 뜻은 아니지만, 무관심을 바탕으로 일의 세계관을 만들면 훈련을 내면화하기 어렵다 - 말로 지식을 보냈으니 그대로 전달된다고 보는 관점을 **Transmissionism**이라고 부르는 걸 봤음 [https://andymatuschak.org/books/]() - [https://en.wikipedia.org/wiki/Tacit_knowledge]() - 시니어 개발자로서 **일괄적인 단정**을 정말 싫어함 “정말 이게 필요한가?”, “안 하면 무슨 일이 생기나?”, “일단 버티고 나중에 더 중요해지면 돌아올 수 있나?” 같은 태도 때문에 실패한 경우도, 실험가들 때문에 실패한 경우만큼 봤음 시스템마다 다르고 제품마다 다름. CT 스캐너 펌웨어를 만든다면 새 시도를 대하는 방식이, 100명의 고객을 가진 CRUD SaaS와는 달라야 함 열정적이고 지나치게 개방적인 시니어가 시스템을 빠져나오기 어려운 구석으로 몰아넣는 경우도 분명 있지만, PHP5면 충분하다고 말하는 사람들도 있음 - 비슷한 말을 하려고 왔음. 개발을 최대한 피하려는 시니어가 좋은 때도 있고, 적극적으로 개선을 도입하는 게 최선인 때도 있음 **좋은 시니어**는 그 시점을 알아볼 수 있어야 함 - 일종의 **생존자 편향**임. 한 부사장이 이전 회사에서 잘 됐다는 이유로 Elasticsearch를 쓰라고 지시했고, 우리에게도 잘 맞았음 그러니 기술 결정을 할 때 부사장의 말을 듣고 Elasticsearch를 쓰라는 식이 되어버림 - 이건 반대를 위한 반대처럼 보이고, 원 글의 요지는 문맥상 분명했음 당연히 어떤 때는 행동이 필요하지만, 오늘날 균형은 필요 이상으로 모든 것을 복잡하게 만드는 쪽으로 기울어 있음 새 제품과 서비스를 만들지 말라는 뜻이 아니라, 만들 때 전체 엔트로피가 가장 낮은 경로를 찾자는 뜻임. 운영과 기술 부채 감소에도 적용됨 **성급한 최적화**는 모든 악의 근원임 - 동의함. **맥락**이 중요함. 시니어 개발자는 복잡도, 위험, 장단점, 사업 측면을 이해해야 함 스타트업인지 이미 현금 흐름이 탄탄한 대기업인지에 따라 제품 핵심 기능을 바꿀 때 판단이 달라짐 - 원 글쓴이가 전달하려던 메시지를 놓친 것 같음. 강조된 특성들은 모두 더 나은 **안정성**으로 이어질 수 있기 때문에 나온 것임 - 글은 재미있게 읽었고, 핵심 메시지인 **대상에 맞춰 더 잘 소통하기**에는 동의함 다만 프레이밍은 올바른 길로 시작했다가 약간 다른 방향으로 틀어진 느낌임 제시된 두 루프 모두 더 촘촘하고 빠를수록 이득이 있음. 하나는 시스템을 빠르게 “안정적”이고 유지보수 가능한 설정점으로 데려가고, 다른 하나는 불확실성을 다룸 AI에 더 잘 적응하기 위해 시스템을 나누자는 추가 통찰도, AI가 주류가 되기 훨씬 전부터 스파이크로 설명해오던 것임 - 내 전문성을 소통하고 공유하려는 의지가 보통은 주니어 개발자들에게 수요가 없다는 걸 알게 됨 대체로 개발자들은 **멘토**를 찾는 데 관심이 없음. LinkedIn 프로필도 보지 않고, 나를 지식과 전문성의 가능한 원천으로 보지도 않음 업계 30년 경험 뒤에 나눌 게 없는 게 아니라, 나눌 사람이 없음 - 지금 직장에서의 좌절이 이거임. 어리석은 일이 너무 많은데 아무도 피하려 하지 않음 경험이 적은 개발자가 URL 검증기를 **AI 마법**으로 대체하자고 했고, 나는 AI로 미리 채운 캐시 기반 퍼지 매칭 해법을 제안하며 반대했지만 아무도 신경 쓰지 않았음. 이제 AI 모델이 갑자기 내려갔고 시스템이 망가짐. 전체 시스템을 다시 검증해야 함 나보다 먼저 승진한 젊은 개발자가 이를 고치는 방안을 문서로 쓰다가 “Dan, 이거 도와줄 수 있어?”라고 했음. 앞으로 나아가는 방식이 합리적으로 일하는 게 아니라 문서 쓰고 회의하는 것이어서 그가 승진했는데, 이제 내 작업을 이용해 리더십을 증명하려 함 더 나은 해법을 제안할수록 경험이 적은 개발자들에게 위협이 되고, 대체로 돌아가긴 하니 매니저도 신경 쓰지 않음. 내가 더 잘 다룰 방법도 있었겠지만, 헛소리와 싸우는 게 너무 지치고 그냥 좋은 코드를 쓰고 싶음 - 함께 일한 시니어 개발자들은 사무실에 나오고, 주니어와 밀접하게 일하고, 사람들과 대화하는 것에 거의 알레르기가 있었음 반면 주니어들은 대화하고 점심 먹고 자신이 하는 일을 공유하고 싶어 함. 시니어들은 경계적이고 혼자 있음 아마 우리 직장만 그럴 수도 있지만, **사무실**은 중요함 - IBM에서 첫 엔지니어링 일을 할 때 당신 같은 사람이 있었으면 좋았겠음 거기 몇몇 시니어 개발자들은 주니어가 질문하면 화를 냈음. 20년 일한 사람에게 뭔가를 묻는 것 자체도 용기가 필요했는데, 50% 확률로 못되게 굴었음 좋은 학습 경험이 되었고, 지금은 일부러 **멘토링**을 하려고 노력함 - 그런 경험을 했다니 안타깝지만, 시니어에게서 배우려는 사람들은 분명 있음 지난 수십 년 동안 간헐적으로 멘토를 해왔고, 훌륭한 멘티들을 만난 운이 있었음. 몇몇은 거의 10년 가까이 지켜봤고 지금 아주 잘하고 있음 어떻게 찾는지에 대해 더 도움이 되는 말은 없지만, 그런 사람들은 존재함 - 첫 직장에서 스타트업에서 어쩌다 시스템 관리자로 커리어가 굳어졌고, 배울 사람이 별로 없어서, 배우고 싶던 아주 뛰어난 **시스템 관리자**가 면접관으로 있던 다른 주의 회사로 이직했음 그런데 내가 도착한 직후 그가 후임자를 찾았다며 퇴사 통보를 했고, 결과적으로 나에게는 잘 풀리지 않았음 - 내가 본 대부분의 개념 증명은 견인력을 얻으면 **프로덕션**이 되었음 “올라가면 처음부터 다시 작성하자”고 모두가 약속한 적이 몇 번 있었지만, 그런 일은 일어나지 않았음 글은 책임과 책무를 건드리지만, 위험을 감수하는 사람에게는 그런 게 없음. 미친 아이디어를 급히 내보내고 고객이 물기를 바라며 이익을 얻음. 그걸 어떻게 작동시키고 확장하고, 판매가보다 운영비가 더 들지 않게 할지는 그 사람 문제가 아님 오른쪽 루프를 극단으로 가져간 회사들이 있고, 요즘 그중 둘은 매우 유명함. 뭔가를 빨리 출시하고 선형으로만 확장되니 돈을 모으러 감. 성공한 회사이고 사용자도 셀 수 없이 많으며 일부는 돈도 냄. “이게 지속 가능한가, 빠져나갈 길은 뭔가”라고 묻는 시니어 개발자나 합리적인 사람은 해고되고, 남는 사람은 신봉자뿐임 - 그래서 충분히 시니어인 **엔지니어링 리더십**이 필요함. 개별 기여자 리더십과 관리자 리더십 둘 다 포함됨 엔지니어들이 비기술 이해관계자가 시키는 대로 얌전히 하면 책임 공백이 생기고, 언젠가 대재앙처럼 터진 뒤 자기 방어를 가장 못한 사람이 비난받음 반대로 충분히 시야를 넓히고 “왜”를 충분히 물으면, 거의 어떤 사업 문제도 시스템을 끔찍한 일방통행 문으로 밀어 넣지 않는 합리적 방식으로 풀 수 있음 모든 곳이 엔지니어링에 그 권한을 주는 건 아니지만, 주지 않는 곳은 판단을 존중받는 곳으로 떠나는 시니어를 붙잡지 못함. 때로는 기술 부채가 사업상 올바른 선택이지만, 충분히 시니어인 엔지니어는 항상 빠져나갈 길을 만들어둘 수 있음 다만 시스템의 순수성을 사업 문제보다 위에 둘 수는 없음. 시스템 비용은 사업이 지불하므로, 그걸 잊으면 영향력의 기반도 잃음 - 오래된 말처럼, **임시 해킹만큼 영구적인 것은 없다** - 이 문제는 AI 코딩 에이전트보다 훨씬 전부터 있었고, AI가 악화시킬 수는 있음 글의 결론은 사실상 오래된 조언인 “하나는 버릴 계획으로 만들라”임. 나도 Mythical Man-Month는 읽었지만, 의사결정권자를 어떻게 설득하느냐가 문제임 - 회사 문화의 문제일 수도 있음. 예전에 빠르고 지저분한 해법으로 시작해 엉망이 된 적이 있었고, 모든 **quick and dirty** 기능에는 다음 1~2 스프린트에 들어갈 후속 스토리를 반드시 붙인다는 강한 정책을 세웠음 기대에 못 미치면 기능을 비활성화하거나 삭제했고, 그렇지 않으면 검토 후 제대로 리팩터링했음 팀 자율성이 높았고 일정 불만도 거의 없었는데, 대부분 다른 부서들이 뒤처져 있었기 때문임. 마케팅만은 늘 “아이디어”가 있었음 - 작동하는 “프로토타입”이 수요를 처리하고 필요한 기능도 있으며, 개발자의 취향을 달래는 것 말고는 다시 만들 필요가 없다면 왜 시간과 노력을 쓰나? 그것이 프로토타입이나 개념 증명이라는 사실은, 실제 문제가 무엇인지 열거할 수 없다면 본질적으로 중요하지 않음 여러 팀이 기술 부채에 빠져 있고 큰 위험이며 속도를 늦춘다고 불평하지만, 사고 기록에는 사건이 많지 않고 위험한 코드를 프로덕션에서 돌린 탓으로 볼 것도 없음. 위험 등록부에도 “이 코드는 오래되고 형편없고 지원 종료 의존성이 있다”는 항목이 없고, 어느 팀도 기술 부채가 어떻게 얼마나 느리게 하는지 설명하지 못함 반대로 출시 전에 자신들이 쓴 앱을 더 “좋게” 만들 수 있다며 몇 달 동안 리팩터링한 팀도 봤음. 모든 가치 전달이 지연됐고, 리더십은 당연히 화가 났으며 신뢰가 거의 남지 않았음 팀과 이해관계자 사이에 납품에 대한 좋은 대화가 있어야 모두가 만족할 수 있지만, 그게 없으면 이해관계자가 항상 이김 - 기본 문제인 **인센티브**를 놓치고 있음. “회사”가 원하는 것은 중요하지 않고, 특정 결정을 내리는 사람들이 원하는 것이 중요함 새 기능이나 앱을 출시해 회사 지표 어딘가에 나타나게 하는 것만으로 직무가 유지되는 사람들이 있음. 시니어 개발자가 나쁜 아이디어라고 해도 그런 사람들은 듣지 않거나 신경 쓰지 않음. 자기 직장이 걸려 있기 때문임 - 전형적인 예는 논문과 새로 내놓는 것들로 평가받는 **연구자**임 하지만 제품 쪽이라면 고객 요구에 기능을 맞춰야 하므로, 연구자에게 밀어붙이기를 멈추라고 해야 함 - 정말 유능한 시니어는 현재 회사의 지배적 문화가 무엇이고 5년 뒤 무엇이 필요할지 파악한 뒤 거기에 맞춰 적응함 5명짜리 스타트업에는 활주로를 줄이는 추가 복잡성이 필요 없을 수 있음. 500명짜리 회사에는 모든 사업 결정의 **2차 효과**를 완화해야 해서 그 복잡성이 필요할 수 있음 “항상 복잡성을 피하라”는 흑백 논리가 아니라 “말이 될 때 복잡성을 추가하라”이며, 그 질문조차 사업이 몇 달 더 살아남아야 하는 상황에서는 매우 미묘해짐 - 맞음. **우선순위와 투명성**이 있으면 사람들이 문제를 풀 때 써야 할 변수를 바꿀 수 있음 폭풍이 오기 두 시간 전이라면 아키텍처를 생각하기보다 “물이 너무 많이 차서 퍼낼 수 없게 될까?”를 묻게 됨 내가 보는 문제는 경영진이 실제로 돈이 얼마나 남았는지, 진짜 일정이 어떤지 말하지 않으며 게임을 하는 것임. 중요한 순간 전에 기여자들이 떠날까 봐 두려워하기 때문인데, 그러면 사람들은 그 맥락에서 계속 어리석은 결정을 내리고 결국 모두 새 직장을 찾게 됨 - 며칠 전부터 팀에 거의 똑같은 감정을 전달하려고 했고, 특히 “새 기능 전체를 만들어 테스트해야 하나? 기존 UI에 버튼 하나 넣고 사람들이 누르는지 봤나?”는 문장까지 거의 그대로였음 제품 쪽이 이제 자신들의 정신 기능을 쓰지 않아도 된다고 결정한 뒤, 엔지니어들이 집단적으로 고통을 느끼는 것 같음. 일단 만들고 사용자 페르소나와 유용성은 나중에, 혹은 영원히, 알아내라는 식임 예전에는 도메인과 사용자, 제품이 어떤 과정에 들어맞는지 이해하는 데 시간을 썼지만, 이제는 상상 속 사용자가 원한다고 생각하는 것을 그냥 출시하고 성공할 때까지 실험함 원 글이 말한 정확한 문제가 생김. **바이브 코딩**으로 만들어진 임의 기능마다 불안정성과 위험의 원천이 되고, 그 대상에 대한 작동하는 정신 모델이 아무에게도 없으니 더 많은 바이브 코딩으로만 유지보수할 수 있게 됨 - 복잡도를 단일한 측정 차원으로 줄일 수 있다고 해도, 해법 공간의 여러 요소 중 하나일 뿐임 유지보수성, 확장성, 신뢰성, 회복력, 안티프래질리티, 확장 가능성, 범용성, 내구성, 조합 가능성 같은 다른 속성들이 있고, 모두가 항상 적용되는 것은 아님 단일 차원이 아니라 **해법 공간의 트레이드오프**로 이야기할 수 있는 능력이 시니어와 Staff+ 개발자를 가르는 차이라고 봄 - “복잡도”를 주니어가 임의의 한 단면을 보고 받는 첫인상으로 이해하면 언제나 나쁘고 과한 것임 반면 앞으로 10인년 동안 이 시스템 개발을 쉽고 빠르게 만들 요소로 이해하면, 순진한 접근이 정면 돌파하려는 곳에서 옆으로 돌아가는 선택을 뜻함 토끼와 거북이 이야기처럼, 처음 2주를 서둘러 불태우며 낮게 열린 열매와 눈에 보이는 성과, MVP를 얻고, 미성숙한 설계와 개발 중 유지보수 때문에 속도가 계속 줄어드는 흐름은 이해하기 어려움. 몇 주 동안 “빠른” 것처럼 보였지만 결국 일정이 6개월 밀림 - **트레이드오프**가 핵심임. 비프로그래머는 트레이드오프가 없다고 상상함 프로그래머라면 결국 설계의 모든 가능한 측면이 트레이드오프라는 걸 깨달아야 함 - 이런 요소들 중 상당수는 복잡도에 직접 영향을 받음 - 가장 중요한 것 하나를 빠뜨렸음. **사용성**임