들어가며: 200년 된 운하 마개의 교훈

1978년, 영국 수로공사 작업팀이 체스터필드 운하 바닥에서 발견한 무거운 철사슬. 작업을 방해하는 장애물이라 생각하고 제거했던 그것은 실제로는 200년 된 운하의 마개였습니다. 2차 대전 중 기록이 소실되어 아무도 그 존재를 몰랐고, 결국 운하 전체가 배수되는 사고가 발생했죠.

이 이야기는 팀 하포드(Tim Harford)가 최근 글에서 소개한 사례로, 제도적 기억(Institutional Memory)의 중요성을 극명하게 보여줍니다. 그런데 이 문제, 우리 개발팀에서도 매일 마주하고 있지 않나요?

제도적 기억이란?

제도적 기억은 조직이 오랜 시간에 걸쳐 축적한 지식, 경험, 노하우가 조직 내에 보존되고 전수되는 것을 의미합니다. 이는 다음 네 가지 요소로 구성됩니다:

1. 인적 지식

  • 베테랑 직원들의 경험과 노하우
  • 비공식적인 업무 처리 방법
  • 과거 실패와 성공 사례에 대한 기억

2. 문서화된 기록

  • 공식 문서, 매뉴얼, 보고서
  • 회의록, 의사결정 과정
  • 기술 사양서, 설계도면

3. 조직 문화와 관행

  • 암묵적인 업무 규칙
  • 조직의 가치관과 원칙
  • 반복되는 업무 패턴과 절차

4. 시스템과 구조

  • 업무 프로세스
  • 조직 구조와 역할 분담
  • IT 시스템과 데이터베이스

제도적 기억 상실의 위험성

하포드가 제시한 사례들을 보면 제도적 기억 상실이 얼마나 치명적인지 알 수 있습니다.

폭스바겐의 반복된 배출가스 조작

많은 사람들이 2015년 폭스바겐의 디젤게이트 스캔들을 기억할 겁니다. 미국 환경보호청이 폭스바겐이 배출가스 테스트를 속이기 위해 소프트웨어를 조작했다는 사실을 발견했고, 이로 인해 폭스바겐은 CEO가 사임하고 300억 유로가 넘는 벌금과 소송비용을 지불해야 했죠. 회사의 명성은 땅에 떨어졌습니다.

그런데 놀랍게도 이것이 처음이 아니었습니다. 1973년, 무려 42년 전에도 폭스바겐은 미국 환경보호청으로부터 똑같은 혐의로 고발당했습니다. 당시에도 배출가스 테스트를 속이기 위한 장치를 사용했다는 것이었죠. 폭스바겐은 법정 밖에서 합의했고, 사건은 조용히 마무리되었습니다.

문제는 이 뼈아픈 경험이 조직 내에서 제대로 기억되지 않았다는 점입니다. 만약 2015년의 경영진이 1973년의 교훈을 기억하고 있었다면, 같은 실수를 반복하지 않았을 수도 있었을 텐데요. 결과적으로 폭스바겐은 40년이 넘는 시간차를 두고 본질적으로 동일한 실수를 반복했고, 두 번째는 훨씬 더 큰 대가를 치러야 했습니다.

NASA의 두 번의 우주왕복선 참사

1986년 1월 28일, 챌린저호가 발사 73초 만에 폭발하면서 7명의 승무원이 모두 사망했습니다. 사고 원인은 추운 날씨로 인한 O-링 실패였지만, 더 근본적인 문제는 조직 문화에 있었습니다. 엔지니어들은 발사 전날 밤 위험성을 경고했지만, 관리층은 일정 압박과 정치적 고려로 인해 이를 무시했습니다.

이 참사 이후 NASA는 대대적인 개혁을 단행했습니다. 안전 문화를 강화하고, 엔지니어들의 목소리에 더 귀 기울이겠다고 약속했죠. 그런데 17년 후인 2003년 2월 1일, 컬럼비아호가 대기권 재진입 중 공중분해되면서 또다시 7명의 승무원이 목숨을 잃었습니다.

컬럼비아 사고조사위원회는 충격적인 결론을 내렸습니다. 사고의 직접적 원인은 달랐지만(발사 시 떨어진 단열재 조각이 날개를 손상), 근본적인 조직 문제는 챌린저 때와 놀라울 정도로 유사했다는 것입니다. 엔지니어들이 위험을 경고했지만 관리층이 이를 제대로 받아들이지 않았고, 일정과 예산 압박이 안전보다 우선시되었습니다. NASA는 챌린저의 교훈을 겉으로는 받아들였지만, 깊숙한 조직 문화 차원에서는 충분히 내재화하지 못했던 것입니다.

록히드 트라이스타의 역설적 학습 곡선

항공기 제조업에서는 일반적으로 같은 모델을 많이 만들수록 제조 비용이 줄어듭니다. 이를 ‘학습 곡선’ 효과라고 하는데, 작업자들이 경험을 쌓으면서 더 효율적으로 일하게 되기 때문입니다. 보잉 747이나 에어버스 A320 같은 성공작들이 바로 이런 혜택을 누렸죠.

그런데 록히드 트라이스타는 정반대 현상을 보였습니다. 조직심리학자 린다 아르고트(Linda Argote)가 1990년 발표한 연구에 따르면, 트라이스타는 생산량이 늘어날수록 오히려 제조 비용이 증가했습니다. 특히 1977-1978년에는 2년간 총 14대밖에 생산하지 않았는데, 이때 생산 노하우가 급속히 사라졌습니다.

경제학자 레이니어 벤카드(Lanier Benkard)의 후속 연구는 더욱 놀라운 사실을 밝혀냈습니다. 록히드의 제조 노하우는 1년 정도만 사용하지 않아도 절반이 사라졌다는 것입니다. 즉, 한 해 동안 생산을 중단하면 그동안 쌓아온 효율성의 절반을 잃어버린다는 뜻이었죠. 결국 트라이스타는 상업적으로 실패했고, 250대만 생산한 후 단종되었습니다.

이 사례는 제도적 기억이 단순히 ‘기록’의 문제가 아니라는 것을 보여줍니다. 실제로 해보지 않으면 아무리 매뉴얼이 완벽해도 노하우는 사라진다는 것이죠. 마치 자전거 타는 법을 아무리 책으로 공부해도 실제로 타보지 않으면 균형감각을 잃는 것과 비슷합니다.

개발팀에서 겪는 제도적 기억 상실

소프트웨어 개발 분야에서도 이런 일들이 일상적으로 발생합니다. 코드 레벨에서부터 시스템 아키텍처까지, 지식의 공백은 곳곳에서 우리를 괴롭힙니다.

담당자가 바뀌면서 생기는 가장 흔한 문제는 코드의 의도를 파악하기 어렵다는 것입니다. 예를 들어 이런 코드를 마주했을 때의 당황스러움을 생각해보세요:

# 이런 코드를 보면서 당황한 경험, 다들 있으시죠?
def calc_x(data, flag):
    return data * 0.85 if flag else data * 1.2

# 담당자가 바뀌면 아무도 모르는 매직 넘버...

변수명 calc_x가 무엇을 계산하는 건지, flag가 무엇을 의미하는지, 0.85와 1.2는 어떤 비즈니스 규칙에서 나온 건지 전혀 알 수 없습니다. 더 심각한 것은 왜 이런 로직을 구현했는지 이유를 모른다는 점입니다. 그래서 “이상하게 짜여있는데 건드리기 무섭다”는 증후군이 생깁니다. 특정 버그를 고치기 위해 추가된 코드일 수도 있는데, 그 배경을 모르면 같은 버그가 다시 발생할 수 있거든요.

시스템이나 아키텍처 레벨에서도 마찬가지입니다. 왜 이런 복잡한 구조로 설계했는지, 특정 라이브러리나 프레임워크를 선택한 이유가 무엇인지, 과거에 어떤 성능 이슈나 보안 문제가 있었고 어떻게 해결했는지에 대한 맥락이 사라지면, 새로운 팀원은 같은 실수를 반복하거나 이미 해결된 문제를 다시 고민하게 됩니다. 데이터베이스 스키마 변경 히스토리를 모르는 상태에서 함부로 컬럼을 수정했다가 예상치 못한 곳에서 오류가 발생하는 것도 흔한 일이죠.

개인 차원에서도 마찬가지

조직뿐만 아니라 개인 차원에서도 “개인적 제도적 기억” 상실을 경험합니다. 몇 달 전 내가 짠 코드를 보고 “이게 뭐지?”라고 생각한 경험이 있다면, 바로 이런 현상입니다. 복잡한 정규식이나 알고리즘을 구현할 때는 분명 논리적으로 완벽하게 설계했다고 생각했는데, 시간이 지나면 그 로직을 전혀 기억하지 못하게 됩니다.

개발환경 세팅도 마찬가지입니다. 새로운 프로젝트를 시작할 때 온갖 삽질을 통해 환경을 구축해놨는데, 몇 달 후 다시 세팅하려면 그 과정을 기억하지 못해 또다시 몇 시간을 소모하게 됩니다. 유용한 툴이나 단축키도 마찬가지입니다. 분명 효율적인 방법을 찾아서 사용했는데, 까먹고 다시 비효율적인 방식으로 작업하다가 나중에야 “아, 맞다 이런 방법이 있었지”하고 떠올리는 경우가 많죠.

결국 “6개월 후의 나는 지금의 나가 아니다”라는 현실을 받아들여야 합니다. 현재의 내가 아무리 완벽하게 이해하고 있어도, 미래의 나는 그 맥락을 잃어버릴 가능성이 높습니다.

해결책: 미래를 위한 투자

팀 차원의 대응책

가장 기본적이면서도 효과적인 방법은 코드 자체를 문서화하는 것입니다. 단순히 주석을 다는 것이 아니라, 코드가 스스로 말할 수 있게 만드는 것이죠:

# Bad
def calc_x(data, flag):
    return data * 0.85 if flag else data * 1.2

# Good  
def calculate_discount_price(original_price, is_member):
    """
    회원은 15% 할인, 비회원은 20% 부가세 적용
    2023년 마케팅팀 요청으로 회원 우대 정책 반영
    """
    MEMBER_DISCOUNT_RATE = 0.85
    NON_MEMBER_TAX_RATE = 1.2
    return original_price * MEMBER_DISCOUNT_RATE if is_member else original_price * NON_MEMBER_TAX_RATE

ADR(Architecture Decision Records)을 작성하는 것도 중요합니다. 왜 이런 기술을 선택했는지, 어떤 대안들을 검토했는지, 각각의 트레이드오프는 무엇이었는지를 기록해두면, 나중에 기술 스택을 변경하거나 문제가 생겼을 때 큰 도움이 됩니다.

코드 리뷰를 할 때도 단순히 버그를 찾는 것을 넘어서 “왜?”를 묻는 문화를 만들어야 합니다. 새로운 담당자가 와도 코드의 의도와 맥락을 파악할 수 있도록 하는 것이죠. 그리고 정기적인 지식 공유 세션을 통해 코드 워크스루를 하고, 특히 퇴사자의 핸드오버 시간을 충분히 확보하는 것이 중요합니다.

개인 차원의 대응책

개인적으로는 노션(Notion)이나 옵시디언(Obsidian) 같은 도구로 개인 지식베이스를 구축하는 것을 추천합니다. 작업할 때마다 간단한 메모라도 남기는 습관을 들이면, 나중에 큰 도움이 됩니다.

코드에는 풍부한 주석을 달아야 합니다:

# 2024.03.15 - 김개발자
# 주문 취소 시 재고 복구 로직
# 주의: 부분취소의 경우 재고 계산이 복잡함 (이슈 #1234 참고)
# TODO: 성능 최적화 필요 (현재 O(n²) 복잡도)

일일 업무 로그를 작성하는 것도 좋습니다. 오늘 무엇을 했는지, 어떤 문제가 있었는지를 간단히 기록해두면 “미래의 나”에게 보내는 편지가 됩니다. 개인 프로젝트라도 README 파일에 설치나 실행 방법, 주요 의사결정과 그 이유를 기록해두면 나중에 프로젝트를 다시 시작할 때 시간을 크게 절약할 수 있습니다.

마치며: 기억은 선택이 아닌 필수

체스터필드 운하의 마개처럼, 우리가 당연하다고 생각하는 많은 것들이 사실은 누군가의 중요한 결정이었을 수 있습니다. 그 맥락과 이유를 기록하고 전수하는 것은 선택이 아닌 필수입니다.

개발자로서 우리가 할 수 있는 일은 현재의 나가 미래의 나와 동료들을 도와주는 것입니다. 오늘 작성하는 한 줄의 주석이, 오늘 기록하는 간단한 메모가, 언젠가 누군가에게는 200년 된 운하 마개를 찾는 단서가 될 수도 있으니까요.

“조직의 집단 지성이자 생존 본능”인 제도적 기억을 지키는 것은 우리 모두의 책임입니다. 작은 노력부터 시작해보면 어떨까요?