대부분의 기술 문제는 사람 문제다

• 대규모 기술 부채를 가진 회사에서 코드 복제와 구식 프레임워크로 인한 비효율이 발생함
• 프로젝트 진행 중 관리 신뢰 상실과 조직 내 변화 저항이 주요 장애로 작용함
• 기술 부채의 근본 원인은 요구 불명확, 비현실적 일정, 구식 기술 선호, 경영진의 단기 대응, 개인의 자존심 등 사람 요인임
• 기술적 성과뿐 아니라 인식 관리와 커뮤니케이션이 프로젝트 성공에 필수적임
• 엔지니어는 기술 능력 외에도 조직 내 협업과 인간관계 조율 능력을 갖춰야 함

---

기술 부채와 복제 코드 문제

• 예전에 근무했던 회사에서 수백만 줄의 코드와 단위 테스트 부재, 10년 이상 된 프레임워크 사용으로 심각한 기술 부채 존재
  • Windows 전용 모듈을 Linux에서 실행하기 위해 코드 수십만 줄을 복사·붙여넣기로 처리
  • 이로 인해 두 개의 코드베이스가 생겨, 기능 추가와 버그 수정이 각각 따로 필요해짐
• 이러한 상황은 유지보수 불가능한 구조를 초래하며, 장기적으로 코드 간 괴리가 커짐

사람 문제로 인한 기술 부채

• 기술 부채 프로젝트는 경영진 설득이 어렵고, 결과적으로 기능 변화가 거의 없기 때문에 가시적 성과 부족
  • 프로젝트가 지연되며 경영진의 신뢰 상실
• 문제의 본질은 기술이 아니라 사람의 태도와 조직 문화
  • 많은 개발자가 변화에 저항하며, 과거 방식에 안주
  • 코드 구조는 작성자의 성격과 변화 수용도를 반영
• 기술 부채는 명확하지 않은 요구, 비현실적 약속, 구식 기술 선택, 경영진의 중단 결정, 개인적 자존심 등에서 발생
  • 변화 회피 성향이 강한 팀일수록 코드에도 변화 거부적 특성이 반영됨
• 여러 개발자는 수년째 하던 방식 그대로 작업하고 있었고, 심지어 “새로운 것 배우고 싶지 않다”는 말까지 나왔음
• 이런 환경에서는 정리 속도보다 부채 축적 속도가 빠르기 때문에, 부채를 줄이기 전에 부채가 더 쌓이지 않도록 막는 것이 우선임
  • 응급실의 triage(우선 분류) 비유처럼, 먼저 “출혈을 멈추는” 단계가 필요함

이상적인 세계와 현실의 간극

• 엔지니어링 문제를 정치나 조직 맥락과 분리해 해결할 수 있는 이상적 환경은 거의 없음
  • 대부분의 프로젝트에는 비기술적 이해관계자가 존재
  • “우리가 하고 있으니 믿어달라”는 태도는 통하지 않음
• 성과 인식 관리가 실제 성과만큼 중요
  • 비기술자는 기술 부채 정리의 필요성을 직관적으로 이해하지 못하므로, 정량적·사업적 가치로 설명해야 함
  • 리더십이 엔지니어링 배경이 없는 경우, 가시적 수치와 효과 제시가 필요
• 결국 팀이 생산적으로 보이는 것 자체도 실제 생산성만큼 중요함

시니어 엔지니어에게 필요한 역량

• 시니어 이상 직급에서는 부서 간 협업과 인간관계 조율 능력이 필수
  • 컴퓨터공학 교육에서는 성격·자존심·관계 관리같은 ‘사람 다루기’를 가르치지 않음
• 뛰어난 기술력을 가진 엔지니어라도 대규모·조직적 변화가 필요한 문제할 수 있음
  • 개인 생산성은 높지만, 조직적 영향력은 제한적
• ‘Heads up coder’ 역할이 중요함
  • 깊은 기술 역량을 유지하면서도 프로젝트 리스크를 조기에 인지하고 팀을 조정할 수 있는 인물
  • 단일 코어처럼 혼자 빠르게 일하는 대신, 팀 전체를 효율적으로 이끄는 역할
  • 순수 기술형 엔지니어와 달리, 조직의 맥락과 리스크를 함께 읽어내며 움직일 수 있음

정리

• 기술 문제의 근원에는 항상 사람이 있음
  • 대부분의 기술 문제는 사람, 문화, 커뮤니케이션의 문제로 귀결
• 기술 부채는 코드의 문제가 아니라 조직의 행동 패턴과 문화가 만든 결과
  • 기술 부채 해결에는 조직적 변화 수용과 리더십의 이해가 선행되어야 함
• 그리고 기술적 탁월함만으로 해결되지 않는 문제들이 경력 후반의 더 큰 무대에서 기다리고 있음
  • 진정한 시니어 엔지니어는 기술과 인간 이해를 함께 다루는 균형형 리더임

[chebread]

이와 관련해서 더 자세히 알고 싶으신 분은 피플웨어(Peopleware) 읽어보시는 것을 추천드립니다!

[GN⁺]

Hacker News 의견

• 대부분의 문제는 커뮤니케이션 문제임을 느꼈음
  엔지니어는 제품 비전이나 고객과 단절되어 있고, 제품팀은 엔지니어를 단순한 사내 외주팀처럼 다룸
  영업과 CS는 자신들의 약속이 제품 로드맵에 어떤 영향을 주는지 이해하지 못함
  결국 목표와 성공 지표가 엇갈려 모두가 제각각 노를 젓는 상황이 됨
  해결책은 “더 나은 사람”이 아니라, 모두가 같은 목표에 몰입하고 각자의 역할이 전체와 어떻게 맞물리는지 이해하게 하는 것임
  오래된 기술 부채도 마찬가지로, 무시한다고 사라지지 않음. 그 부채가 회사에 주는 비용과 리스크를 수치화해 다른 목표와 균형을 잡고 갚아나갈 계획을 세워야 함

  • 그래서 나는 BigCo 내부 툴링 팀을 위해 Shadow Sessions 프로그램을 만들었음
    사용자가 바로 옆에 있으니 직접 만나 친구가 되고, 그들의 일상과 맥락을 배우는 세션임
    3주마다 자동으로 스케줄링되고, 별도의 액션 아이템 없이 진행됨. 매번 사람들이 놀라워하며 작은 버그들이 해결되고 연결이 생김
    Slack API와 연동되는 자동 스케줄러를 만들어 운영 중이며, 가장 어려운 부분은 일정 조율과 참여 유도임
  • 회사들이 서로 경청하도록 인센티브를 주지 않기 때문이라 생각함
    경영진은 하급자의 말을 듣지 않고, 하급자는 주목받기 위해 경쟁함
    최근 우리 부서에서도 컨설턴트가 새 플랫폼으로 전환하자고 했는데, 아무도 동의하지 않았지만 멈출 수 없었음. 결국 아무도 듣지 않음
  • “그 기술 부채가 회사에 주는 비용을 산출하라”는 말이 인상적이었는데, 구체적으로 어떻게 하는지 궁금함
  • 물론 “더 나은 사람”이 많은 문제를 해결하긴 함. 전부는 아니지만, 꽤 많은 부분을 해결함
  • 제품팀이 엔지니어를 외주처럼 다루는 이유는 “이건 내 아이디어고 너희가 실행한 거야”라는 우월감 때문임
    “왜 이걸 하죠?”라는 질문엔 “믿어봐, 형을” 식의 답만 돌아옴
    이런 PM 행동은 바뀌지 않을 것 같음. 그래서 엔지니어들이 직접 제품 역할을 맡으며 커뮤니케이션 격차를 없애고 있음

• 많은 사람들이 실제로는 일에 자부심을 느끼지 않음을 깨달았음
  어떤 사람에게는 그저 월급일 뿐임
  특히 나이 많은 동료들은 시스템이 무너지는 걸 본 경험이 있어, 다시 그런 상황이 오지 않게 하려 함
  새로운 직장에 갈 때마다 90일 계획 안에 명확한 가이드라인을 세우려 하지만, 결국 핵심은 팀임
  어떤 팀은 변화에 목말라 있고, 어떤 팀은 변화를 방해함
  리더가 무지하거나 가장 빠르고 싼 선택만 고르면 더 어려워짐
  영국의 Post Office 스캔들처럼, 내부에서 문제를 알았지만 막힌 사례도 떠오름

  • 사람들이 일에 자부심을 잃은 이유는 소유권 상실 때문임
    과거에는 절반 이상이 자영업자였지만 지금은 10% 남짓임
    이제 우리가 만드는 건 “우리 것”이 아니라 “고용주의 것”임
    더 열심히 일해도 보상받지 못하고, 오히려 더 많은 일을 떠안게 됨
    결국 사람들은 자원으로 취급되고, 필요 없으면 버려짐
  • 대부분의 회사는 직원에게 관심이 없음, 직원들도 그걸 앎
    위기 시 가장 먼저 해고되는 건 직원이고, CEO는 수백만 달러를 받음
    이런 구조에서 직원이 회사를 위해 헌신하길 기대하는 건 불가능함
  • 자부심이 사라진 이유는 명확함
    덜 일하는 사람이 더 많은 급여를 받고, 당신은 절반 급여의 대체 인력 때문에 해고될 수 있음
    인터뷰는 점점 까다로워지고, 공로는 도둑맞고, 인플레이션은 급여를 잠식함
    결국 “왜 자부심이 사라졌는가”는 미스터리처럼 보이지만 사실 답은 명확함
  • “자부심”으로는 식료품을 살 수 없고, 열심히 일해도 급여는 그대로임
  • 사람들이 일에 흥미를 느껴야만 신경을 씀
    하지만 기업은 대부분의 사람이 원하는 일을 하지 못한다는 걸 알고, 대신 프로세스와 워크플로우에 집중함
    개인에게는 자신이 좋아하는 일을 하면서 좋은 보수를 받는 게 최선임

• “새로운 걸 배우고 싶지 않다”는 개발자의 말이 꼭 나쁜 건 아님
  JavaScript 생태계처럼 매일 바뀌는 프레임워크 피로감과, Go나 LTS 기반의 기술적 안정성은 다름
  안정성은 제품 민첩성에도 도움이 됨
  오래된 C++ 코드베이스를 다루는 시니어 엔지니어와 협상해야 할 수도 있지만, 그걸 단순히 기술 부채라 부르는 건 편견임
  기술 부채 여부는 코드베이스를 책임지는 리드 IC와 그를 관리하는 매니저만이 판단할 수 있음

• 인터뷰에서 인간적인 문제를 언급하면 불합격하기 좋은 방법임
  많은 면접관이 기술적 답변만 정답으로 여기고, 인간적 통찰을 무시함
  나는 오히려 그런 관점을 높이 평가하지만, 동료들과 설득 싸움을 해야 함

  • 다행히 블로그 글은 면접처럼 평가받을 필요가 없어서 좋음 :)
  • 최근 면접에서 모든 면접관이 합격을 줬지만 한 명만 반대했음
    메시지 처리량에 따라 배치 프로세싱이 충분할 수도 있다고 하자, 그가 “큐를 모른다”고 단정함
    10년 넘게 페타바이트급 데이터 제품을 다뤘다고 말했지만, 그의 시스템 설계에 맞지 않는다는 이유로 거절당함
    결국 지금 그 팀은 모든 마이크로서비스를 단일 API 뒤로 묶는 작업을 하고 있음
  • 나는 인터뷰에서 양쪽 트레이드오프를 함께 제시하는 방식을 씀
    팀이 그 균형을 이해하지 못한다면, 그 팀에 합류하지 않아도 됨
  • 여담이지만, Graph DB는 멋져 보여서 과하게 쓰이는 경우가 많음

• Big Tech의 데이터 엔지니어로서 가장 어려운 문제는 두 가지임
  첫째, Conway’s Law로 인해 부서마다 다른 툴체인과 데이터 철학을 가짐
  둘째, 각 사일로가 자기 방식만 옳다고 주장하면서도 서로의 데이터를 원함
  표준화가 불가능한 이유는 각 부서의 리더들이 자신들의 방식만이 유일한 해법이라 믿기 때문임
  실제로 보면 대부분의 접근은 옳기도 하고 틀리기도 함
  겉보기엔 기술 문제 같지만, 결국 사람 문제임

  • 여기에 더해, 요구사항이 처음부터 명확하지 않고, 자동화가 부족해 사소한 요청에 파묻힘
    상류 시스템의 변경 통보가 없어, 하류에서 알람이 울릴 때야 알게 됨
    스프린트가 무의미할 정도로 즉흥 요청이 많고, 문서화되지 않은 지식이 넘침
    이런 경험 덕분에 더 낮은 수준의 컴퓨터 과학을 공부할 동기가 생김
  • 이런 문제는 IT에서 가장 근본적인 사람 중심 문제임
    변화를 이끌려면 네트워크를 만들고, 사람들을 묶고, 투명하게 변화를 전파해야 함
    하지만 진짜 변화를 위해선 디렉터나 VP 같은 상위 리더의 지원이 필요함
    AWS가 이런 조직 변화를 위한 가이드를 냈는데, AWS Prescriptive Guidance는 훌륭한 청사진임
  • 대규모 기관 시스템을 구현할 때 가장 큰 장애물은 부서 간 불신임
    “모두를 하나의 솔루션으로 묶자”로 시작하지만, 곧 각 부서별 프로젝트로 분리됨
    이를 막으려면 강력한 권한을 가진 리더가 필요함
    특히 공공 부문은 서로를 싫어하는 경우가 많아 더 어렵고, 민간은 최소한 일자리 유지라는 공통 목표라도 있음

• Jerry Weinberg의 『Secrets of Consulting』에서 말했듯,
  “겉보기엔 기술 문제 같아도, 항상 사람 문제임”
  기술적 문제의 뿌리는 결국 사람의 선택, 커뮤니케이션, 관리, 역량에 있음

  • 나도 이 말을 하려고 왔음. 그의 통찰은 세월이 지나도 변치 않음

• 시스템 교체 프로젝트에서 분석가로 일했음
  기존 시스템은 단순한 라운드 로빈 방식으로 업무를 배분했지만, 새 시스템은 각자의 업무량을 고려해 공정하게 배분했음
  그런데 일부 직원이 시스템을 조작해 바쁘게 보이도록 만들었고, 결과적으로 성실한 직원이 더 많은 일을 떠맡게 됨
  우리는 문제의 본질이 기술이 아니라 감독 부재임을 명확히 설명했지만, 결국 기술적 해결책을 강요받았음

  • 이건 두 기술적 선택지 간의 문제였다고 생각함
    인간의 본성상 일은 주어진 시간만큼 늘어나기 마련이고, 이런 역인센티브를 기술적으로 제어해야 함
    이상적인 인간을 전제로 시스템을 설계하면 실패함

• Jerry Weinberg는 『The Psychology of Computer Programming』(1971)부터
  “겉보기엔 기술 문제라도, 항상 사람 문제다”라는 원칙을 강조했음
  그의 저서들은 지금 읽어도 가치가 큼

  • 제목을 보자마자 Jerry가 떠올랐음

• 나는 “직무에 자부심이 없다”고 비난하는 태도를 싫어함
  대부분의 직원은 일의 주인이 아니고, 회사가 주인임
  회사가 특정 방향을 강요하고, 반대하면 불이익을 준다면 왜 싸워야 하나
  우리는 그저 기계의 톱니바퀴일 뿐이고, 그렇게 대우받는다면 그에 맞게 행동할 뿐임
  글쓴이의 자기중심적 태도가 불쾌하게 느껴짐

  • 선진국이 아닌 곳에서 일해보면 이게 더 명확함. 모두 그냥 생계를 위해 일할 뿐임

• 나는 지금 꽤 시니어로, 자금 스폰서와 요구사항 담당자와 직접 일함
  그들은 “이걸 해줘, 얼마야?”라고 묻지만, 나는 30분 회의 중 18분 만에 대략적인 견적을 내야 함
  그들은 기술은 모르지만, 돈과 정치의 언어를 완벽히 앎
  어떤 문제는 문자 한 통으로 해결했는데, 예산은 600만 달러였음
  또 어떤 프로젝트는 다른 팀이 가져가 3,500만 달러를 태우고 실패함
  예산을 쥔 스폰서들은 대부분 정치가 우선이고, 목표는 “다음 자리”임
  그들의 커리어를 보면 “어떻게 저 자리에 갔을까” 싶을 때가 많음