# 코드베이스를 완전히 이해하지 못해도 괜찮은 이유 > Clean Markdown view of GeekNews topic #31377. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31377](https://news.hada.io/topic?id=31377) - GeekNews Markdown: [https://news.hada.io/topic/31377.md](https://news.hada.io/topic/31377.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-13T10:02:23+09:00 - Updated: 2026-07-13T10:02:23+09:00 - Original source: [seangoedecke.com](https://www.seangoedecke.com/in-defense-of-not-understanding-your-codebase/) - Points: 11 - Comments: 2 ## Topic Body - 수천만 줄에 이르는 대규모 시스템은 누구도 전체를 머릿속에 담을 수 없으므로, 엔지니어는 **부분적으로 정확한 이해**만으로도 효과적으로 작업할 수 있어야 함 - Peter Naur의 **Programming as Theory Building**은 기존 팀의 이해가 사라지면 프로그램을 폐기하고 새로 만드는 편이 낫다고 보지만, 사용자와 수많은 예외가 얽힌 대규모 시스템은 처음부터 재구축하기 어려움 - 담당자가 모두 떠난 코드베이스도 하나의 흐름을 끝까지 파악한 뒤 조심스럽게 변경 범위를 넓히면 되살릴 수 있으며, 대규모 조직에서는 이런 **이해의 재구축**이 반복적으로 일어남 - LLM은 상세한 정신 모델 형성을 방해하는 동시에 부분적인 이해를 빠르게 만들고 활용하도록 도우며, 협업·법적 요구사항·보안 업데이트·의존성 도입도 **코드 이해와 다른 가치의 절충**을 요구함 - 정확한 정신 모델은 즐겁고 안정적인 개발에 도움이 되지만 절대적인 기준은 아니며, 실무에서는 속도·법적 준수·조직적 요구를 위해 **완전한 이해를 포기할 필요**도 있음 --- ### 완전한 이해와 부분적인 이해 - 작고 구성원 교체가 적은 코드베이스에서는 전체를 이해해야 좋은 작업이 가능하다고 보기 쉬움 - [Redis](https://redis.io/)나 [The Witness]()) 같은 프로젝트가 이에 해당함 - Google 웹 검색 백엔드나 GitHub처럼 크고 구성원 교체가 잦은 코드베이스에서는 전체를 이해할 수 없으므로, 각자가 맡은 **국소 영역**을 최대한 파악하는 방식으로 작업함 - 두 환경은 개발 방법과 관행, 문화가 크게 다르지만 온라인 소프트웨어 엔지니어링 논의에서는 완전한 이해를 중시하는 첫 번째 문화가 과도하게 대표됨 - 오픈소스 엔지니어는 작업을 글로 공유하려는 동기가 크고, 대규모 독점 시스템보다 순수 엔지니어링 작업이 돋보이기 쉬움 - 독점 시스템은 법적 이유로 공개하기 어렵고, 공개할 수 있더라도 대규모 코드베이스를 설명하려면 지나치게 많은 구체적 맥락이 필요함 - 많은 소프트웨어 환경에서 **부분적 이해**는 잘못된 상태가 아니며, 대규모 시스템에서는 현실적으로 도달할 수 있는 최선임 - 이러한 차이는 [Pure and impure software engineering](https://www.seangoedecke.com/pure-and-impure-engineering/)에서 구분한 완전한 이해의 문화와 부분적인 이해의 문화가 충돌하는 문제로 이어짐 ### Programming as Theory Building의 주장 - Peter Naur의 논문 [Programming as Theory Building](https://pages.cs.wisc.edu/~remzi/Naur.pdf)은 프로그래머가 만드는 주된 산출물을 코드가 아니라 **프로그램에 관한 이론**으로 봄 - 이 이론은 무엇이 왜 일어나는지에 대한 직관적인 이해로 구성됨 - 코드와 문서는 그 이해를 부분적으로만 담을 수 있음 - 코드를 잃더라도 이론을 가진 팀은 프로그램을 다시 작성할 수 있지만, 팀이 전면 교체돼 이해를 잃으면 기존 코드를 파악하기 어려워짐 - Naur에 따르면 문서나 코드만으로 기존 이론을 재구축할 수 없으므로, 원래 프로그램을 폐기하고 새 팀이 문제를 처음부터 다시 풀어야 함 - Naur가 인용한 Gilbert Ryle의 [The Concept of Mind](https://www.andrew.cmu.edu/user/kk3n/80-300/ryle1949.pdf)는 이론 구축의 범위를 더 넓게 봄 - 실제로 무언가를 수행하는 동안 이론이나 노하우가 자연스럽게 만들어질 수 있음 - 따라서 코드 자체를 탐구하며 기존 코드베이스를 이해하는 과정도 이 접근과 양립함 ### 대규모 시스템을 처음부터 재작성할 수 없는 이유 - 사용자가 있는 충분히 큰 시스템에는 다시 구현하기 어려운 수천 개의 [예외 사례와 특이 동작](https://www.seangoedecke.com/wicked-features/)이 축적됨 - 시스템을 잘 아는 팀조차 모든 세부 사항을 동시에 고려할 수 없어 전체를 한 번에 재작성하기 어려움 - 성공적인 재작성은 기존 코드베이스를 작고 격리된 부분으로 나눈 뒤 **한 부분씩 교체**하는 방식으로 진행됨 - 결국 재작성도 기존 시스템에 일련의 변경을 가하는 작업임 - 기존 시스템을 변경할 수 없다면 새 시스템으로 완전히 대체하기는 더욱 어려움 ### 버려진 코드베이스를 복구하는 방법 - 수억 줄의 코드와 수천 명의 엔지니어를 보유한 기술 기업에서는 특정 코드베이스를 아는 사람이 아무도 남지 않는 일이 드물지 않음 - 담당자 몇 명이 좋지 않은 시점에 퇴사하거나 코드베이스가 1년 동안 유지보수되지 않는 것만으로도 이런 상태에 이를 수 있음 - Naur는 기존 이론을 조금이라도 아는 사람 없이 완전히 죽은 프로그램의 복구를 새 프로그래머에게 맡기는 일은 거의 없을 것으로 봤지만, 대규모 조직에서는 실제로 발생함 - 버려진 코드베이스도 시간을 들이면 새로운 이해를 구축하고 효과적으로 작업할 수 있는 상태로 되돌릴 수 있음 - 먼저 하나의 처리 흐름을 **처음부터 끝까지** 이해함 - 조심스럽게 변경하면서 해당 흐름에서 주변 영역으로 이해 범위를 넓혀감 ### 누구나 불완전한 이론으로 작업함 - 현대의 대규모 소프트웨어는 개인은 물론 팀 전체도 모든 동작을 머릿속에 유지할 수 없을 만큼 큼 - 충분히 큰 코드베이스에서는 누구나 프로그램에 대해 어느 정도 **부정확한 이론**을 가진 채 작업하게 됨 - 효과적인 엔지니어는 완벽한 이해를 가진 사람이 답을 줄 때까지 기다리지 않고, 현재 정보로 가장 근거 있는 판단을 내린 뒤 결과에 대응함 - 이러한 작업에는 불확실한 상황에서도 [입장을 정하는 능력](https://www.seangoedecke.com/taking-a-position/)과 [자신감](https://www.seangoedecke.com/what-makes-strong-engineers-strong/)이 필요함 - 대규모 제품의 전체 동작을 아무도 완전히 알지 못하는 현실은 [Nobody knows how software products work](https://www.seangoedecke.com/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 외에도 다양함 - 다른 사람이 같은 코드베이스에 코드를 작성하도록 허용하는 일 - 접근성이나 데이터 보호처럼 **법적으로 요구되는 기능**을 구현하는 일 - 동료가 퇴사하거나 팀을 옮길 수 있도록 허용하는 일 - 보안 패치를 위해 소프트웨어 버전을 업그레이드하는 일 - 라이브러리나 다른 의존성을 도입하는 일 - 이론 구축을 방해한다는 이유만으로 도구나 관행이 나쁘다고 판단할 수 없음 - 코드베이스 이해는 가독성·유지보수성·정확성과 마찬가지로 여러 엔지니어링 가치 가운데 하나임 - 상황에 따라 다른 가치를 희생하면서 정확한 이해를 우선할 수 있음 - 반대로 속도, 법적 준수, 조직 내 정치적 이유를 위해 코드 이해를 양보하기도 함 - 코드 이해가 다른 모든 가치를 실현하기 위한 핵심이라는 반론은 가독성·유지보수성·정확성에도 똑같이 적용할 수 있으며, 실무에서는 이러한 핵심 가치도 지속적으로 절충함 ### 개인적 선호와 업무상의 책임 - 특히 [순수한 엔지니어](https://www.seangoedecke.com/pure-and-impure-engineering/)는 정확한 정신 모델을 유지하며 작업하기를 선호함 - 개발이 더 재미있고 스트레스가 적음 - 스스로 생각하는 진정한 엔지니어링에 더 가깝게 느껴짐 - 많은 엔지니어가 여가 시간에 혼자 작은 오픈소스 프로젝트를 만드는 이유도 코드베이스에 관한 정확한 **Naur식 이론**을 유지하며 작업할 수 있기 때문임 - 업무에서는 개인의 엔지니어링 가치보다 조직이 비용을 지불하며 요구하는 가치 집합을 따라야 함 - 성능을 중요하게 여기더라도 일정에 맞추거나 까다로운 요구사항을 수용하기 위해 느린 코드를 작성할 수 있음 - 코드베이스의 완전한 이해도 항상 지켜야 하는 절대 기준이 아니라, 업무 목적에 따라 다른 가치와 교환할 수 있는 선택지임 ## Comments ### Comment 61732 - Author: ndrgrd - Created: 2026-07-13T19:25:25+09:00 - Points: 1 그래서 추상화에 목매는거죠 ### Comment 61697 - Author: neo - Created: 2026-07-13T10:02:24+09:00 - Points: 2 ###### [Lobste.rs 의견들](https://lobste.rs/s/elhi7o/defense_not_understanding_your_codebase) - 원문의 제목은 아쉽게도 낚시성에 가깝고, 실제 내용은 **대규모 코드베이스를 부분적으로 이해한 상태에서도 진척을 낼 수 있어야 한다**는 쪽에 가까움 이론 구축 관점도 이론에 폭과 깊이가 모두 있다고 보면 글의 요점과 충돌하지 않음. 폭은 시스템의 어느 범위까지 충분히 이해해 질문에 답하고 능숙하게 변경할 수 있는지를 뜻하고, 깊이는 특정 부분에 관해 얼마나 복잡한 질문에 답하며 무결성을 유지한 채 복잡한 변경을 할 수 있는지를 뜻함 코드를 모듈별로 재작성하면서 전환 기간을 둔다면, 해당 모듈에 관해 좁지만 깊은 이론을 구축하고 그에 따라 작업하는 셈이다. 작은 함수에는 매개변수나 반환값을 하나 추가해도 괜찮지만, 규모가 커지면 특정 모듈만이라도 **깨끗한 상태에서 다시 시작**하고 다른 부분이 새 구현을 호출하도록 연결하는 편이 합리적이다. 근본적으로 버그가 많은 구현의 정확성을 점진적으로 개선하려는 방식은 잘 작동하지 않으며, 이는 성능 같은 속성에도 흔히 적용됨 다만 Naur가 “프로그램을 되살리기보다 기존 프로그램 텍스트를 폐기하고 새 프로그래머 팀이 주어진 문제를 처음부터 풀게 해야 한다”고 했을 때, 재작성을 시작하기 전에 기존 코드를 먼저 삭제하라는 뜻인지, 새 프로그램이 적절한 대체재임을 확인한 뒤 폐기해도 된다는 뜻인지는 논의할 여지가 있음 더구나 현실에서는 그 **주어진 문제 자체가 주어져 있지 않다**. Naur는 원래 문제 정의가 남아 있다고 가정하지만, 대규모 코드베이스에는 없는 경우가 많다. 가장 가까운 것은 보통 테스트 스위트이므로, 테스트를 계속 통과시키면서 구성 요소를 교체할 수 있음 당시에는 지속적 배포도 없었다. 오늘날에는 서비스가 계속 실행되는 가운데 호출 대기를 맡고, 질문에 답하며, 긴급 버그를 해결해야 하므로 재작성에 관한 손익 계산도 달라짐 - 이 반론에는 잘 표현된 부분도 있지만, 대부분은 자명하게 느껴짐. 충분히 큰 시스템에서는 **부분적 이해가 유일한 상태**지만, 조직은 언제나 더 깊은 이해를 추구해야 함 “일을 하라고 돈을 받는다”는 논리와 별개로, 대규모 소프트웨어는 사용자를 만족시키거나 사업 목표를 달성하지 못하는 일이 잦다. Windows와 OS X도 누적된 복잡성 때문에 썩어가고 있다고 볼 수 있음 경영진도 마법처럼 복잡성을 없앨 수 있다면 그렇게 할 것이다. 다만 이는 아직 해결되지 않은 소프트웨어 공학 문제이며, 경영진이 나쁜 코드를 출시하고 싶어 한다기보다는 현재 여건에서 그런 절충을 받아들인 것에 가까움 “독점이면 충분하니 형편없고 버그 많은 소프트웨어를 내놓아도 된다”고 볼 수도 있지만 지나치게 허무주의적이다. 독점이 아니거나 사용자를 붙잡아 둘 수 없는 소프트웨어 회사도 많으므로, 그런 곳에서는 품질이 실제로 중요함 - 내 경험상 경영진은 **좋은 소프트웨어 개발 관행을 불신**하고, 더 빨리 움직이겠다며 이를 선제적으로 포기하라고 요구하곤 함. 대부분은 검증 없이 가정만으로 그렇게 결정함 - “항상 더 많이 이해해야 한다”는 목표는 **아무것도 못 하는 상태**에 이를 정도로 오용될 수 있음. 충분한 이해가 아니라 완벽한 이해를 요구받으면 아무것도 하지 못하고 결국 포기하거나 절망하게 됨 이런 해석 아래에서는 이해라는 개념도 일종의 문지기 역할과 비슷해 보임 - 글에서 설명한 접근법은 코드 일부를 **국소적으로 추론하는 능력**과 밀접하게 관련됨 주변을 모두 이해하지 않고도 대규모 코드베이스의 한 부분을 이해하는 국소적 추론은 컴퓨터 과학이 처음부터 추구해 온 핵심 개념이다 **구조적 프로그래밍**의 주요 장점은 국소적 추론이 가능하다는 것이었고, 전역 변수를 피하라는 권고도 대체로 같은 목적에서 나왔다. 함수형 프로그래밍은 부수 효과를 제거해 국소적 추론을 가능하게 하며, 객체 지향 프로그래밍의 원칙 중 하나인 데이터 구조와 이를 다루는 코드를 결합하는 방식도 국소적으로 추론할 또 다른 수단을 제공함 이런 기본 개념의 진정한 힘은 바람직한 상황은 아니더라도 코드베이스 전체를 이해하지 않은 채 작은 부분을 추론하고 작업할 수 있게 해준다는 데 있음 - “코드베이스의 모든 줄을 이해해야 한다”는 조언에 대한 흥미로운 반론으로 읽었고, 글의 중심 논지가 개발 **실무 관행**과 맞닿아 있어 `#practices` 태그를 붙였음 이 커뮤니티가 LLM을 좋아하지 않는다는 것은 알지만, 이 글이 정말 `#vibecoding`에 해당하는지는 의문임 - 알고 있을 수도 있지만 lobste.rs에서는 LLM 사용과 관련된 모든 콘텐츠를 폭넓게 `vibecoding`으로 분류하며, 나도 동의하지 않지만 그것이 관행임. 이 글의 핵심 질문도 **LLM 보조 코딩**과 밀접하게 연관돼 있음 다만 `vibecoding`만 유일한 태그여서는 안 된다는 데 동의함. 글은 마지막에 가서야 LLM을 명시적으로 다루며, 핵심 논점은 LLM 이전 시대에도 흥미롭고 논의할 가치가 있다. 따라서 `practices` 태그를 복원할 근거가 충분하다고 보고 직접 복원했으며, 다른 사람에게도 같은 조치를 권함 - 글의 요점은 모든 프로그래머, 특히 **거대한 코드베이스를 다루는 법**과 그것이 소규모 프로젝트와 어떻게 다른지 이해하려는 사람에게 의미가 있음 LLM 사용이 코드베이스에 대한 완전한 이해를 방해할 수 있는 세상에서도 관련성이 있다 태그가 “바이브 코딩에 관심 있는 사람에게 관련될 수 있다”는 뜻이라면 분명 적절하다. 반대로 “바이브 코딩에 관심 있는 사람을 제외하면 무관하다”는 뜻이라면 적절하지 않다. 다른 태그는 모두 전자의 의미로 쓰이지만, Lobsters 사용자 중 상당수는 이 태그만 후자의 의미로 사용하니 결국 그들은 이 글을 놓칠 수밖에 없음 - 1985년과 다른 현대 개발의 또 다른 특징은 **30만 줄짜리 코드베이스**의 전문가가 되더라도 다음 주에는 전혀 다른 30만 줄짜리 코드베이스에서 일할 수 있다는 것임 경력 있는 현업 프로그래머는 언제든 미지의 영역에 투입될 수 있다는 데 익숙하며, 공통 관용구([Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html)), API를 잘못 사용하면 오류를 내는 컴파일러 같은 자동화 도구, 대규모 프로그램이 “어떻게 구성돼야 하는가”에 대한 직감의 조합에 의존함 LLM으로 재작성한 Bun처럼 “이제 코드베이스 전체의 동작을 이해하는 사람이 없는데 어떻게 계속 개발할 수 있겠는가?”라는 논의도 봤지만, 이는 작가가 아니면 어떻게 소설을 이해할 수 있느냐고 묻는 것과 비슷하다. 결국 코드이므로 읽으면 된다. 어떤 함수가 이해되지 않으면 여러 조각으로 나누고, 테스트를 작성해 보고, 제어 흐름을 종이에 적는 등 무엇이든 해볼 수 있음 프로젝트를 정기적으로 옮겨 다니게 되므로 예전 코드베이스에 대한 이해를 계속 유지할 이유도 없다. 어느 순간 모두 비슷하게 뒤섞인다. 회사가 인수한 스타트업의 Scala 코드가 맞춤형 Thrift 기반 RPC 프로토콜을 통해 Go로 재작성 중인 JSON 기반 Ruby 서비스와 통신하도록 도와야 한다고 해도, 한 시간 정도 `Scala syntax reference`와 `Thrift wire encoding`을 검색하면 시작할 수 있음 전문가가 될 필요도 없다. 한 달 뒤에는 Linux 커널의 Go 구현에서 JavaScript용 OCaml 기반 타입 검사기가 왜 충돌하는지 디버깅하고 있을 수도 있기 때문이다. **결국 전부 코드일 뿐**이다