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

전문성의 가장 중요한 부분은 내부 세계 모델에서 나오며, 그것과 분리할 수 없음
보통은 무엇이든 말로 표현할 수 있고, 말만 전달되면 듣는 사람이 말한 사람의 뜻을 그대로 이해한다고 믿지만, 이 믿음 때문에 개발자의 전문성을 다른 사람에게 “전달”하라는 요구가 생김
사실 지식은 말로 꽤 잘 전달되지만, 모든 지식이 연결되어 굳어진 세계 모델은 그렇지 않음. AI는 사실을 훨씬 많이 알 수 있어도, 아직 그 지식을 바탕으로 놀라울 만큼 자주 맞는 통찰을 내는 방식으로 활용하지는 못함
전문성 전달은 실제로는 어디로 가고 무엇을 배워야 하는지에 대한 힌트에 가깝고, 받는 사람이 내면화할 노력과 적절한 프로젝트를 통해 같은 전문성을 획득해야 함

재능 있어 보이고 “감”을 잡는 주니어와 그렇지 않은 주니어의 큰 차이 중 하나가 정확한 세계 모델을 빠르게 형성하는 능력임
소프트웨어의 “물리 법칙”을 이해해 적용하는 사람과, 그냥 절차만 적어 내려가며 각 단계의 본질을 이해하려 하지 않는 사람은 구분됨
객체지향에 익숙한 사람에게 함수형 프로그래밍을 가르칠 때 특히 두드러지는데, 어떤 사람은 모델이 깨지고, 어떤 사람은 변수의 세계에서 모나드의 세계로 비교적 쉽게 번역할 수 있음을 빠르게 봄

우연히 어제 Peter Naur가 1985년에 쓴 글 https://pages.cs.wisc.edu/~remzi/Naur.pdf을 봤고, 계속 생각하게 됨
거의 30년 동안 대부분 한 대기업에서 일했고, 매주 상당한 시간을 새로 온 사람들이 겪는 문제에 답하는 데 씀. 질문만 들어도 문제의 뿌리가 그들의 세계 모델, Naur가 말하는 Theory가 불완전하거나 왜곡되어 추론을 어렵게 만든다는 걸 바로 알 때가 많음
과제는 자신의 이론을 텍스트와 다이어그램 같은 상징 표현으로 바꿔, 충분한 경험과 지능을 가진 사람이 비슷한 정신 모델을 떠올리게 만드는 것임. 즉 내 이론을 다른 사람의 머릿속에 설치하고 싶은 것
Naur가 말한 유형의 이론은 직접 이식할 수 없지만, 시니어 개발자의 일은 강의실이든 현장이든 경험을 끌어와 그런 이론을 재생산하는 방법을 찾는 것이라고 봄. 그래서 커뮤니케이션 능력이 중요하고, 다른 사람에게서 작동 이론을 받는 과정을 여러 번 겪어야 효과적인 본능이 생김
이제 이 일이 업무에서 가장 보람 있는 부분이 되었고, 의미 있게 이 기능을 수행한다고 느끼는 한 은퇴를 서두르고 싶지 않음

모두가 같은 내부 세계 모델을 가졌다면 혁신은 거의 없었을 테니, 오히려 이건 좋은 일이라고 봄
주니어를 훈련하고 멘토링할 때 가능한 것과 실패로 이어지는 패턴을 보여주려 하지만, 그 훈련은 대개 조각나 있고 불완전함
가능한 한 왜 그렇게 하는지 설명하지만, 하지 말라고 딱 잘라 말하는 건 많지 않음. 내가 가르친 사람들이 문제를 푸는 방식에 자주 놀라고, 나도 자주 배움
자기 기여에 관심이 없고 일을 급여 수단으로만 보는 사람에게는 훈련이 덜 성공적임. 그렇게 생각하는 게 틀렸다는 뜻은 아니지만, 무관심을 바탕으로 일의 세계관을 만들면 훈련을 내면화하기 어렵다

시니어 개발자로서 일괄적인 단정을 정말 싫어함
“정말 이게 필요한가?”, “안 하면 무슨 일이 생기나?”, “일단 버티고 나중에 더 중요해지면 돌아올 수 있나?” 같은 태도 때문에 실패한 경우도, 실험가들 때문에 실패한 경우만큼 봤음
시스템마다 다르고 제품마다 다름. 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개월 밀림

트레이드오프가 핵심임. 비프로그래머는 트레이드오프가 없다고 상상함
프로그래머라면 결국 설계의 모든 가능한 측면이 트레이드오프라는 걸 깨달아야 함