엔지니어링 기술 부채 정리보다 먼저 고쳐야 할 것: 신뢰와 커뮤니케이션

• 대부분의 기술 문제는 사실 ‘사람 문제’다
• 기술 부채를 키운 건 코드가 아니라 문화였다
• 레거시 코드는 증상일 뿐, 병은 조직 문화다
• 코드가 아니라 사람이 빚을 진다: 기술 부채의 진짜 원인
• 엔지니어링 실패의 그림자, 기술이 아닌 사람과 문화의 문제
• 리팩토링만으론 부족하다: 기술 부채 뒤에 숨은 사람 이야기

기술 부채 이야기 같지만, 실제로는 “사람과 문화” 이야기 핵심 메시지는 이겁니다.

기술 부채, 망가진 코드베이스, 실패한 프로젝트 뒤에는
거의 항상 요구·일정·의사결정·성격·문화 같은 사람 문제가 있다.

기술 부채 사례: “이미 거대한 부채 위에, 코드 복사까지”

• 수백만 줄짜리 레거시 코드
  • 단위 테스트 없음
  • 10년 넘은 오래된 프레임워크 위에 돌아감
• 특정 프로젝트에서, Windows 전용 모듈을 Linux에서 돌려야 하는 요구가 생김.
  • 합리적인 방법: 공유 코드 + 플랫폼별 분리 + 크로스 컴파일
  • 실제로 한 일
    • 다른 팀이 코드를 통째로 복사해서, Windows API 부분만 Linux용으로 갈아 끼움
    • 즉, 수십만 줄 복붙으로 “Windows 버전 / Linux 버전” 두 코드베이스를 만들어버림

이건 비기술자에게도 큰 문제입니다.

• 앞으로 모든 신규 기능, 버그 픽스를 두 군데에 각각 적용해야 하고,
• 두 코드베이스는 시간과 함께 점점 더 서로 달라지고, 정리 불가능한 부채가 됩니다.

“이걸 제대로 정리해보자!”

라며 기술적으로 옳은 방향(refactoring & 구조 정리)으로 프로젝트를 밀어붙입니다.

300x250

그러나 문제는…

기술적으로는 “옳은 일”이었지만,
사람·조직 측면에서 완전히 실패했다는 것.

People Problems: 기술 부채의 근본 원인은 사람

1. 기술 부채가 생기는 전형적인 사람 요인

이런 질문을 던집니다.

“왜 기술 부채가 생기는가?”

그리고 이렇게 답합니다.

• 요구사항이 제대로 정리·합의되지 않은 상태에서 개발이 시작되기 때문
• 영업이나 사업 쪽에서 비현실적인 일정·기능을 고객에게 먼저 약속했기 때문
• 개발자가 익숙한, 이미 낡은 기술을 편해서 선택했기 때문
• 경영진이 너무 반응적이라, 진행 중인 프로젝트를 중간에 취소하거나 우선순위를 뒤엎기 때문
• 누군가의 자존심·에고 때문에 더 나은 방식을 못 받아들였기 때문

즉, 기술 부채는

• 언어, 프레임워크, 아키텍처 자체의 문제가 아니라
• 요구관리, 의사결정, 일정, 커뮤니케이션, 개인 성향과 에고의 결과라는 겁니다.

2. 변화 저항과 심리적 방어

이 refactoring 프로젝트의 핵심 난제는 기술이 아니라 심리와 문화였습니다.

• 레거시 정리는 곧,
  • “지금까지 우리가 해온 방식이 잘못되었다”
  • “내 스킬셋이 구식이다”
    를 공식적으로 인정하는 행위가 됩니다.
• 다른 팀 개발자들은 그대로 예전 스타일로 코드를 계속 작성하고 있었고,
  • 누군가는 “나는 새로 배우고 싶지 않다(I don’t want to learn anything new)”라고 대놓고 말할 정도였습니다.

여기서 깨달았습니다.

“우리가 기술 부채를 정리하는 속도보다,
새로운 기술 부채가 만들어지는 속도가 더 빠르다.”

그래서 비유를 씁니다.

• ER(응급실) 트리아지와 같다.
  • 일단 피부터 멎게(stop the bleeding) 해야 한다.
  • 피가 계속 쏟아지는 상태에서, 뼈를 정교하게 맞추고 수술하는 건 의미가 없다.

이 말은 곧,

• 기술 부채를 정리하고 싶다면
  • 먼저 “부채를 계속 찍어내는 사람·조직 구조”를 멈추게 해야 한다는 뜻입니다.

이상적인 세계 vs 현실: “일만 잘하면 된다”는 환상

엔지니어들이 자주 꿈꾸는 이상적인 세계가 있습니다.

• 정치(Politics)는 신경 쓰지 않고
• “코드만 잘 짜면 된다”
• “좋은 설계와 깔끔한 구현은 언젠가 인정받는다”
• “우리가 열심히 하고 있으니 믿어달라(Just trust us; we’re working on it)”

하지만 그런 세계는 거의 존재하지 않는다는 걸 깨닫습니다.

대부분의 현실 프로젝트는

• 비기술적 이해관계자(non-technical stakeholders)가 존재하며
• 그들에게는
  • 기술 부채, refactoring, 테스트 커버리지… 이런 개념이 직관적으로 와닿지 않습니다.
• “그냥 돌아가던 거 아닌가? 왜 또 시간을 쓰냐?”라는 반응이 나오기 쉽습니다.

그래서 말합니다.

“실제로 많이 해내는 것 못지않게,
‘많이 해내고 있다는 인식(perception)’을 주는 것도 중요하다.”

즉,

• 기술적 성과 = 실제 결과 + 인식 관리(communication)라는 겁니다.

1. 기술 부채를 설명하는 언어의 문제

비기술 조직에 기술 부채의 가치를 설득하려면,

• 엔지니어가 사업 언어와 숫자로 풀어야 합니다.

예를 들어 이런 식입니다.

• “이 모듈 refactoring에 3개월을 쓰면,
  • 장애 빈도가 월 X회 → Y회로 줄어들고,
  • 배포 실패율과 롤백 비용이 Z% 감소하며,
  • 릴리스 주기가 A주에서 B주로 단축됩니다.”

즉,

• “이 refactoring은 코드가 예뻐져서 좋은 것”이 아니라
• “비즈니스 리스크 감소, 비용 절감, 고객 경험 개선에 직결되는 투자”임을 보여줘야 한다는 겁니다.

Heads Up: 시니어 이상에게 요구되는 “사람” 능력

시니어 엔지니어 이후의 역할을 이야기합니다.

1. 학교는 사람·조직 문제를 가르치지 않는다

• 학교는 컴퓨터 과학, 알고리즘, 이론은 가르치지만
• 실제 일을 할 때 필요한
  • 사람 성격 다루기,
    팀 내 갈등 조율,
    에고와 블라인드 스팟 관리
    는 거의 가르치지 않습니다.

그러나 시니어 이상이라면, 기술 트랙이든 매니저 트랙이든 상관없이

• Cross-functional 협업, 이해관계자 관리를 할 줄 알아야 한다고 말합니다.

2. 두 유형의 엔지니어: Heads-down vs Heads-up

1. Heads-down “engineer’s engineer”
   • 거의 모든 기술 스택을 깊이 있게 아는 슈퍼 IC
   • 기술적으로 엄청 뛰어나며, 누구보다 빠르게 코드를 생산
   • 하지만
     • 사람/조직/정치/커뮤니케이션에는 관심이 적고
     • 결과적으로 큰 이니셔티브에서는 한계를 겪는 경우가 많음
   • 이유
     • 결국 혼자서 처리할 수 있는 양에는 한계가 있고,
     • “단일 코어”는 아무리 빨라도 멀티코어의 협업 효율을 이기기 어렵기 때문.
2. Heads-up coder
   • 충분히 깊은 기술 역량을 가지면서, 동시에
   • 머리를 들고(Heads-up)
     • 프로젝트 리스크(기술적/비기술적)를 미리 보고,
     • 사람들의 상태, 조직 분위기, 일정, 이해관계자 반응을 함께 고려하며,
     • 팀이 장애물을 피해갈 수 있도록 방향을 틀어주는 사람
   • 이 유형이 동등하게, 혹은 더 중요할 수 있다고 봅니다.

결국 시니어/리더에게 요구되는 건, 단순히

• “코드 더 잘 짜는 사람”이 아니라
• 기술 + 사람 + 조직을 동시에 보는 능력이라는 메시지입니다.

핵심 포인트 정리

1. 기술 부채는 본질적으로 사람 문제다
   • 불명확한 요구,
   • 무리한 영업 약속,
   • 익숙한 구식 기술만 고집,
   • 반응적인 경영,
   • 에고 때문에 생기는 의사결정 오류 등.
2. 신뢰 상실과 변화 저항이 가장 큰 장애물이다
   • refactoring 프로젝트가 길어지고,
   • 그 과정이 “보여지지” 않으면
   • 경영진은 “믿음”을 잃고, 팀은 “또 갈아엎는 거냐”며 피로감을 느낍니다.
   • “나는 새로 배우기 싫다”라는 직접적인 반발도 존재.
3. 인식 관리와 커뮤니케이션은 기술 성과만큼 중요하다
   • “우리가 무엇을, 왜, 얼마나 하고 있는지”를
     • 비기술 이해관계자가 이해할 수 있는 언어로 설명해야 합니다.
   • 기술적 완성도만으로는 프로젝트를 지킬 수 없습니다.
4. 엔지니어에게 필요한 역량은 기술 + 협업 + 인간관계 조율
   • 시니어 이상은
     • cross-functional 협업,
     • 이해관계자 설득,
     • 갈등 조정,
     • 리스크 관리 능력이 필수입니다.
   • 단순히 “깊은 기술 전문가”만으로는 대규모 기술 부채와 조직 문제를 해결하기 어렵습니다.

조직·보안·개발 환경에서의 적용 가이드 & 점검 포인트

마지막으로, 실제 조직/보안/개발 문화 관점에서 적용해볼 수 있는 체크리스트를 정리해보겠습니다.

1. 요구 관리와 일정·약속 관리

• 요구사항 명세 프로세스가 있는가?
  • “누가 무엇을 왜 원하는지”가 문서로 남고,
  • 개발 착수 전에 이해관계자 간 합의가 되는지.
• 영업/사업 부서가 고객에게 약속하기 전에 기술 검토가 있는가?
  • “기술팀 승인 없는 대외 약속 금지” 같은 룰.
• 비현실적 일정에 대해 ‘레드 카드’를 들 수 있는 구조가 있는가?
  • “이 일정/범위면 품질·보안·운영 안정성이 깨진다”라고 말하면
    • 이를 진지하게 재조정할 수 있는 메커니즘이 있는지.

2. 기술 부채·보안 부채의 가시화

• 기술 부채/보안 부채 목록(debt register)을 운영하는가?
  • 모듈별, 시스템별로
    • 레거시 포인트,
    • 위험도,
    • 부채가 초래하는 실제 비용/리스크를 기록.
• 정기적으로 “부채 상환 스프린트” 또는 refactoring 라인을 확보하는가?
  • 예: 매 분기/반기에 최소 N%의 리소스를 부채 상환에 투자.
• “부채 상환이 사업에 주는 효과”를 숫자로 설명하고 있는가?
  • 장애 감소율, 복구 시간(MTTR) 감소, 배포 성공률, 보안사고 리스크 감소 등으로 환산.

3. 조직 문화: 변화 저항과 학습 문화

• “새로 배우기 싫다”는 정서가 그냥 방치되고 있지 않은가?
  • 교육·러닝 타임, 사내 스터디, 기술 세미나 등을 통한 완만한 변화 제공.
  • 새로운 기술 도입 시 “설명/납득” 과정 포함.
• 기존 방식이 틀렸음을 인정할 수 있는 심리적 안전감이 있는가?
  • “우리가 틀렸다”에서 끝나는 게 아니라
  • “그래서 다음에는 이렇게 바꾸자”로 연결되는 문화.
• 레거시를 유지하던 사람이 방어적으로 되지 않도록 배려하는 구조가 있는가?
  • 기여를 존중하고,
  • 리팩토링을 “비난”이 아닌 “진화”로 프레이밍.

4. 커뮤니케이션 & 인식 관리

• refactoring/보안 강화 작업의 상태를 비기술 언어로 보고하는가?
  • 예: “이번 분기에는 레거시 A 모듈 개선으로,
    • 장애 가능성을 X% 줄이고,
    • 신규 기능 개발 시 반복 소요를 Y일 절감했습니다.”
• 진행 중인 일의 ‘가시성(visibility)’을 확보했는가?
  • 대시보드, 정기 리포트, 경영진 브리핑 등.
• 기술팀 내부에서도 “이게 왜 중요한 일인지” 서로 공감대가 있는가?
  • 팀 내부 합의 없는 상태에서 밖으로만 설득하려고 들면 쉽게 깨집니다.

5. 역할과 평가: Heads-up Coder 키우기

• 시니어/리더 평가 항목에 ‘사람/조직/커뮤니케이션’이 포함되어 있는가?
  • 코드량, 기술 깊이만 보는 게 아니라
  • 리스크 미리 감지·조정, 이해관계자 설득, 팀 내 지식 전파를 평가.
• “Heads-up coder” 역할을 의식적으로 키우고 있는가?
  • 아키텍트, 테크리드, 보안 리드 등이
    • 단순한 기술 고문이 아니라
    • “조정자·번역자·리스크 네비게이터” 역할을 수행하도록 지원.

6. 보안 관점에서의 연결

보안 부채도 기술 부채와 똑같이 사람 문제로 나타납니다.

• 요구 단계에서 보안 요구가 누락됨
• 일정과 마감 때문에 보안 검토 스킵
• “예전에 안 터졌으니 괜찮다”는 인식
• 정책은 있으나, 실제 현장에서는 “업무 우선”으로 무시되는 문화

그래서 보안 관점에서는 아래와 같은 점검이 가능합니다.

• 보안 요구사항이 제품/프로젝트 초기 요구사항 정의에 포함되는가?
• 보안팀이 ‘NO를 말하는 조직’이 아니라 ‘위험을 설명하고 옵션을 제시하는 파트너’로 인식되는가?
• 보안 부채(미적용 취약점, 레거시 프로토콜, 미완 정책 등)가 목록화되어 있고, 기술 부채와 함께 관리되는가?
• 경영진에게 보안 개선을 ‘위험 감소 + 비용 절감 + 컴플라이언스 리스크 감소’로 숫자화해 보여주는가?

기술 부채·실패한 프로젝트·엉망인 시스템을 바로잡고 싶다면,
기술보다 먼저 ‘사람·문화·조직 구조’를 설계하고 다뤄야 한다.