코드베이스를 완전히 이해하지 못해도 괜찮은 이유

• 수천만 줄에 이르는 대규모 시스템은 누구도 전체를 머릿속에 담을 수 없으므로, 엔지니어는 부분적으로 정확한 이해만으로도 효과적으로 작업할 수 있어야 함
• Peter Naur의 Programming as Theory Building은 기존 팀의 이해가 사라지면 프로그램을 폐기하고 새로 만드는 편이 낫다고 보지만, 사용자와 수많은 예외가 얽힌 대규모 시스템은 처음부터 재구축하기 어려움
• 담당자가 모두 떠난 코드베이스도 하나의 흐름을 끝까지 파악한 뒤 조심스럽게 변경 범위를 넓히면 되살릴 수 있으며, 대규모 조직에서는 이런 이해의 재구축이 반복적으로 일어남
• LLM은 상세한 정신 모델 형성을 방해하는 동시에 부분적인 이해를 빠르게 만들고 활용하도록 도우며, 협업·법적 요구사항·보안 업데이트·의존성 도입도 코드 이해와 다른 가치의 절충을 요구함
• 정확한 정신 모델은 즐겁고 안정적인 개발에 도움이 되지만 절대적인 기준은 아니며, 실무에서는 속도·법적 준수·조직적 요구를 위해 완전한 이해를 포기할 필요도 있음

완전한 이해와 부분적인 이해

• 작고 구성원 교체가 적은 코드베이스에서는 전체를 이해해야 좋은 작업이 가능하다고 보기 쉬움
  • Redis나 The Witness) 같은 프로젝트가 이에 해당함
• Google 웹 검색 백엔드나 GitHub처럼 크고 구성원 교체가 잦은 코드베이스에서는 전체를 이해할 수 없으므로, 각자가 맡은 국소 영역을 최대한 파악하는 방식으로 작업함
• 두 환경은 개발 방법과 관행, 문화가 크게 다르지만 온라인 소프트웨어 엔지니어링 논의에서는 완전한 이해를 중시하는 첫 번째 문화가 과도하게 대표됨
  • 오픈소스 엔지니어는 작업을 글로 공유하려는 동기가 크고, 대규모 독점 시스템보다 순수 엔지니어링 작업이 돋보이기 쉬움
  • 독점 시스템은 법적 이유로 공개하기 어렵고, 공개할 수 있더라도 대규모 코드베이스를 설명하려면 지나치게 많은 구체적 맥락이 필요함
• 많은 소프트웨어 환경에서 부분적 이해는 잘못된 상태가 아니며, 대규모 시스템에서는 현실적으로 도달할 수 있는 최선임
• 이러한 차이는 Pure and impure software engineering에서 구분한 완전한 이해의 문화와 부분적인 이해의 문화가 충돌하는 문제로 이어짐

Programming as Theory Building의 주장

• Peter Naur의 논문 Programming as Theory Building은 프로그래머가 만드는 주된 산출물을 코드가 아니라 프로그램에 관한 이론으로 봄
  • 이 이론은 무엇이 왜 일어나는지에 대한 직관적인 이해로 구성됨
  • 코드와 문서는 그 이해를 부분적으로만 담을 수 있음
  • 코드를 잃더라도 이론을 가진 팀은 프로그램을 다시 작성할 수 있지만, 팀이 전면 교체돼 이해를 잃으면 기존 코드를 파악하기 어려워짐
• Naur에 따르면 문서나 코드만으로 기존 이론을 재구축할 수 없으므로, 원래 프로그램을 폐기하고 새 팀이 문제를 처음부터 다시 풀어야 함
• Naur가 인용한 Gilbert Ryle의 The Concept of Mind는 이론 구축의 범위를 더 넓게 봄
  • 실제로 무언가를 수행하는 동안 이론이나 노하우가 자연스럽게 만들어질 수 있음
  • 따라서 코드 자체를 탐구하며 기존 코드베이스를 이해하는 과정도 이 접근과 양립함

대규모 시스템을 처음부터 재작성할 수 없는 이유

• 사용자가 있는 충분히 큰 시스템에는 다시 구현하기 어려운 수천 개의 예외 사례와 특이 동작이 축적됨
• 시스템을 잘 아는 팀조차 모든 세부 사항을 동시에 고려할 수 없어 전체를 한 번에 재작성하기 어려움
• 성공적인 재작성은 기존 코드베이스를 작고 격리된 부분으로 나눈 뒤 한 부분씩 교체하는 방식으로 진행됨
  • 결국 재작성도 기존 시스템에 일련의 변경을 가하는 작업임
  • 기존 시스템을 변경할 수 없다면 새 시스템으로 완전히 대체하기는 더욱 어려움

버려진 코드베이스를 복구하는 방법

• 수억 줄의 코드와 수천 명의 엔지니어를 보유한 기술 기업에서는 특정 코드베이스를 아는 사람이 아무도 남지 않는 일이 드물지 않음
  • 담당자 몇 명이 좋지 않은 시점에 퇴사하거나 코드베이스가 1년 동안 유지보수되지 않는 것만으로도 이런 상태에 이를 수 있음
• Naur는 기존 이론을 조금이라도 아는 사람 없이 완전히 죽은 프로그램의 복구를 새 프로그래머에게 맡기는 일은 거의 없을 것으로 봤지만, 대규모 조직에서는 실제로 발생함
• 버려진 코드베이스도 시간을 들이면 새로운 이해를 구축하고 효과적으로 작업할 수 있는 상태로 되돌릴 수 있음
  • 먼저 하나의 처리 흐름을 처음부터 끝까지 이해함
  • 조심스럽게 변경하면서 해당 흐름에서 주변 영역으로 이해 범위를 넓혀감

누구나 불완전한 이론으로 작업함

• 현대의 대규모 소프트웨어는 개인은 물론 팀 전체도 모든 동작을 머릿속에 유지할 수 없을 만큼 큼
• 충분히 큰 코드베이스에서는 누구나 프로그램에 대해 어느 정도 부정확한 이론을 가진 채 작업하게 됨
• 효과적인 엔지니어는 완벽한 이해를 가진 사람이 답을 줄 때까지 기다리지 않고, 현재 정보로 가장 근거 있는 판단을 내린 뒤 결과에 대응함
• 이러한 작업에는 불확실한 상황에서도 입장을 정하는 능력과 자신감이 필요함
• 대규모 제품의 전체 동작을 아무도 완전히 알지 못하는 현실은 Nobody knows how software products work에서 다룬 상황과 같음

Naur 시대와 현대의 코드 규모

• Naur가 논문을 쓴 1985년에는 평균적인 프로그램 규모가 오늘날보다 몇 자릿수 작았을 가능성이 있음
• Naur가 든 첫 번째 대규모 프로그램 사례는 20만 줄 규모의 산업용 모니터링 프로그램이고, 두 번째 사례는 컴파일러였음
• GCC 첫 버전은 1987년에 약 10만 줄이었지만 2015년에는 1,400만 줄 이상으로 늘어남
• 기존 테스트를 재사용할 수 있다면 10만~20만 줄 규모의 프로그램은 비교적 쉽게 재작성할 수 있지만, 100만~200만 줄 이상의 시스템에는 같은 판단을 적용하기 어려움

LLM과 이론 구축의 양면성

• LLM은 일반적인 이론 구축 과정을 방해한다는 이유로 좋지 않은 도구라는 평가를 받곤 함
• 그러나 다른 소프트웨어 도구와 마찬가지로 LLM에도 양면성이 있음
  • 소프트웨어에 관한 상세한 정신 모델을 만들기는 더 어려워질 수 있음
  • 부분적인 이론은 빠르게 구축할 수 있음
  • 불완전한 이해를 바탕으로도 더 효과적으로 작업하도록 지원할 수 있음
• LLM과 코드 이해의 관계는 단순한 장단점 구분으로 정리할 수 없으며, 여전히 판단이 필요한 복잡한 트레이드오프임

코드 이해를 어렵게 해도 필요한 선택들

• 코드베이스의 정확한 이론을 유지하기 어렵게 만드는 요소는 LLM 외에도 다양함
  • 다른 사람이 같은 코드베이스에 코드를 작성하도록 허용하는 일
  • 접근성이나 데이터 보호처럼 법적으로 요구되는 기능을 구현하는 일
  • 동료가 퇴사하거나 팀을 옮길 수 있도록 허용하는 일
  • 보안 패치를 위해 소프트웨어 버전을 업그레이드하는 일
  • 라이브러리나 다른 의존성을 도입하는 일
• 이론 구축을 방해한다는 이유만으로 도구나 관행이 나쁘다고 판단할 수 없음
• 코드베이스 이해는 가독성·유지보수성·정확성과 마찬가지로 여러 엔지니어링 가치 가운데 하나임
  • 상황에 따라 다른 가치를 희생하면서 정확한 이해를 우선할 수 있음
  • 반대로 속도, 법적 준수, 조직 내 정치적 이유를 위해 코드 이해를 양보하기도 함
• 코드 이해가 다른 모든 가치를 실현하기 위한 핵심이라는 반론은 가독성·유지보수성·정확성에도 똑같이 적용할 수 있으며, 실무에서는 이러한 핵심 가치도 지속적으로 절충함

개인적 선호와 업무상의 책임

• 특히 순수한 엔지니어는 정확한 정신 모델을 유지하며 작업하기를 선호함
  • 개발이 더 재미있고 스트레스가 적음
  • 스스로 생각하는 진정한 엔지니어링에 더 가깝게 느껴짐
• 많은 엔지니어가 여가 시간에 혼자 작은 오픈소스 프로젝트를 만드는 이유도 코드베이스에 관한 정확한 Naur식 이론을 유지하며 작업할 수 있기 때문임
• 업무에서는 개인의 엔지니어링 가치보다 조직이 비용을 지불하며 요구하는 가치 집합을 따라야 함
  • 성능을 중요하게 여기더라도 일정에 맞추거나 까다로운 요구사항을 수용하기 위해 느린 코드를 작성할 수 있음
  • 코드베이스의 완전한 이해도 항상 지켜야 하는 절대 기준이 아니라, 업무 목적에 따라 다른 가치와 교환할 수 있는 선택지임