이해 부채: LLM이 만든 코드가 남기는 시한폭탄

• 최근 LLM(대규모 언어 모델)이 생성한 코드를 수정·보완하는 데 개발자가 더 많은 시간이 걸리고 있음
• 기존 레거시 코드처럼, 코드를 안전하게 바꾸려면 먼저 무엇을, 왜 그렇게 구현했는지 이해해야 하는데, LLM 코드는 이 과정을 더 어렵게 만듦
• 일부 팀은 코드를 충분히 리뷰·재작업하기 때문에 속도가 느려지지만, 많은 팀은 읽히지도 않고 대충 테스트된 코드를 그대로 저장소에 반영
• 이는 “이해 부채(Comprehension Debt)”를 낳으며, 결국 코드 수정이 필요할 때 더 큰 시간 비용으로 되돌아옴
• LLM은 대체로 70% 수준에서 문제 해결에 쓸 수 있지만, 반복 실패하는 “Doom Loop” 를 피할 수 없고, 결국 사람이 직접 코드를 이해·수정해야 하는 상황이 필연적으로 발생함

---

LLM이 생성한 코드와 이해 부채 문제

• 최근 개발 현장에서는 ChatGPT, Copilot 등 LLM 기반의 코드 자동생성 도구 사용이 늘어나는 추세임
• 이러한 도구들은 개발자의 지식이나 직접 이해 없이도 복잡한 코드를 신속하게 생성함
• 하지만 이 과정에서 코드의 의도, 제한사항, 동작 원리가 명확히 파악되지 않아 '이해 부채'가 쌓이는 현상이 발생함

이해 부채(Comprehension Debt)란 무엇인가

• 이해 부채는 코드의 품질, 구조, 의도를 팀원이 충분히 이해하지 못하는 상태를 의미함
• 단기적으로는 개발 속도를 높일 수 있지만, 장기적으로는 유지 보수 비용 증가, 버그 발생, 기능 확장 제한 등 다양한 부작용으로 이어질 위험 존재함

LLM 생성 코드의 추가적 위험

• LLM이 생성하는 코드는 명확한 주석이나 맥락 제공 없이 결과만 빠르게 도출함
• 팀원 간 지식 공유 미흡 및 기존 시스템과의 호환성 부족 문제 노출 가능성 높음
• 반복적으로 LLM 코드에 의존할 경우, 전체 프로젝트의 코드 신뢰성 저하 초래 가능

기술 부채와 비교

• 기존의 기술 부채는 개발자가 의식적으로 타협하는 결과이지만, LLM 기반의 이해 부채는 무의식적으로 누적될 수 있어 위험성 큼
• 문제 인식이 어렵고, 발생 원인 추적 및 해결이 더 복잡해짐
• 문제 해결 시 “Doom Loop” (LLM을 반복적으로 돌려도 실패하는 악순환) 경험이 흔함

결론 및 시사점

• 결국 사람이 직접 코드를 읽고 고쳐야 함
• LLM 활용 시 코드의 맥락과 의도를 팀원 전체가 이해하도록 문서화·공유하는 노력이 중요함
• 코드 리뷰 강화, 주석과 문서 보강, 지식 공유 세션 등 조직 차원의 장치가 필요
• 이해 부채 관리 없이는 자동화 도구의 장점이 오히려 장기적 리스크로 전환될 수 있음
• 업계 전반이 빠르게 불어나는 이해 부채의 산 위에 앉아 있는 상황임

[shakespeares]

저도 항상 AI는 완전히 결정할 순 없기에 모든 코드에 제가 결정하고 잘되었는지도 스스로 점검합니다.

[cgl00]

제 기준으로는 그냥 딱 10줄 미만 스니펫 짜는 용도네요(ex. json파싱, 소팅 구현). 이렇게만 사용해도 시간이 비약적으로 절약되는거 같습니다.

[pcj9024]

AI 도움으로 뼈대만드는건 괜찮은데 마지막까지 디테일을 살리는건 정말어려운듯

[ahwjdekf]

댓글중 다른 개발자가 작성한것을 가져다쓰는경우에도 리뷰가 필요하니 llm의 경우와 다르지않다는 글이 있는데 전 아니라고 봅니다. 인간의 경우에는 평판, 명성, 보상, 처벌 이런게 작동하니까요. 아마 지금 llm처럼 일했다간 바로 해고될걸요.

[bus710]

저는 항상 "AI는 대신 책임져주지 않는다." 라고 생각하고 있습니다.

[dongho42]

저도 개인적으로 0에서 90을 LLM으로 짰을때의 부작용을 느낀적이 종종 있어서 요즘에는 0에서 90까진 가급적 제가 직접하고 90에서 100까지 가는 과정에서 주로 활용하고 있는데 만족스러워요

[GN⁺]

Hacker News 의견

• LLM에 대한 의존도가 심해지며 기존에도 존재하던 문제들이 더 악화되는 경험을 했음
  Na​​ur의 "이론 구축" 개념을 소개하며, 프로그램 개발팀이 해체되면 해당 프로그램이 사실상 죽은 상태가 됨을 지적함
  Lamport의 '프로그래밍 ≠ 코딩' 논리를 언급하며, 프로그래밍은 '무엇을, 어떻게' 달성할지에 대한 이론 구성이 본질임을 강조함
  필요한 모델이나 이론을 세우지 않는 프로그래머일수록 LLM이 자신을 빠르게 도와준다고 느끼는 경향이 강하다고 생각함

  • 실제로 컴퓨터 및 기술에서 완전히 벗어나 있을 때 소프트웨어 프로젝트에서 더 큰 가치 창출이 가능하다는 경험을 했음
    정확히 무엇을 원하는지 알 때 개발 속도가 비약적으로 빨라지며, 이때 LLM이 매우 유용해짐
    명확한 목표가 있다면 LLM의 환각 역시 즉각적으로 구분해낼 수 있음
    무작정 빈 캔버스를 바라보며 시작하는 접근이 효과적이라고 생각하지 않음
    LLM이 출발을 도울 수 있지만, 잘못하면 오히려 엉뚱한 곳으로 빠지는 경우가 많았음
    가장 어려운 문제는 오히려 부엌에서 요리하며 고민하다가 해결한 경험이 있음

  • AI 코딩에서 동료들보다 좀 더 성공적으로 활용한 이유 중 하나가, LLM 도입 전에도 무엇인가를 빨리 프로토타입으로 만들어보고, 다시 구조를 완전히 수정하거나 폐기하는 과정을 반복했기 때문임
    이런 접근(빠른 프로토타이핑, 지속적 리팩토링 등)은 꽤 유명하지만, 많은 엔지니어들은 처음부터 완벽하게 설계하려고 하거나, 프로토타입에서 개선 없이 지속적으로 패치만 하려는 경향이 있음
    AI와 함께라면 여러 가지 병렬 구현도 저렴하게 가능해서, 다양한 버전을 실험하고 비교해보며 결과적으로 더 강한 프로그램 이론이나 설계를 빠르고 효과적으로 형성할 수 있음
    AI가 이런 루프를 단축시켜주고, 산출물의 리뷰에만 더 집중할 수 있어 개발 과정이 훨씬 효율적으로 이루어짐

  • '이론 구축' 개념이 LLM 코드의 '이해 채무'와 연결된 점이 인상적임
    이것은 단순히 프로그래밍뿐만 아니라 인간의 사고와 이해 과정에도 깊은 관련이 있다고 생각함
    LLM이 만들어내는 코드나 텍스트, 이미지 등은 표면적인 결과에 불과하고, 이 이면의 이론을 직접 구축·경험하지 않으면 단순한 표면적 이해로 끝날 수밖에 없음
    LLM이 언젠가 이론 구축 자체까지 해낼 수 있게 되더라도, 인간이 과정에 직접 개입하지 않은 인공 이해만으로는 의미가 부족하다고 느껴짐
    기계가 대신 사고해주는 게 편리해질수록, 인간의 <이해> 능력이 서서히 퇴화하게 될 것이라는 우려가 있음

  • Lamport의 주장에 동의함과 동시에, AI가 '이론 구축' 과정—즉 코드베이스와 알고리즘, 전체 시스템적 이해—에서도, 기존 팀에게나 인수인계 팀에게 일정 부분 도움이 될 수 있다고 생각함
    모든 지식을 완전히 대체하긴 어렵더라도, AI가 일정 부분의 간극을 메워줄 수 있을 것이라 기대함

  • 기존 개발자들이 모두 사라진 후 새 팀이 프로젝트를 넘겨받은 적이 있는데, 이전 팀의 모든 지식이 증발해 매우 힘든 시간을 보냈음
    원래 설계를 이해하려 애쓰다 버그를 양산했고, 결과적으로 코드 대부분을 재작성·확장하는 등 고생이 많았음
    하지만 이런 어려움 속에서도 오히려 많은 설계 이슈를 직접 답습하는 과정이 있었음

• LLM은 종종 돌아가는 솔루션을 만들어내지만, 필요한 것보다 훨씬 복잡한 코드가 산출되는 경우가 많음
  최초 작성 당시엔 문제가 무엇인지 가장 잘 이해하고 있기 때문에 복잡성을 쉽게 제거할 수 있으나, 나중에는 그 복잡한 코드가 꼭 필요한 것처럼 오해되어 대폭 단순화하기 더욱 어려워짐
  코드의 유지보수자는 맥락이나 배경 지식이 부족해, 더 간단한 대안이 가능하다는 사실을 인지하지 못할 때가 많음

  • LLM에서 불필요한 복잡성을 피하는 방법은 간단함
    첫째, 프롬프트를 명확히 제시해 LLM이 불필요하게 복잡한 결과물을 만들어내지 않도록 유도함
    둘째, 항상 문제를 가능한 한 단순하게 해결하도록 하는 규칙이나 학습, 맥락을 전달해야 함
    마지막으로, 산출된 복잡한 솔루션에 대해 추가 프롬프트로 복잡도를 줄이도록 요청하면 됨

• LLM이 엄청난 양의 디버깅이 어려운 코드를 만들어내는 문제가 실제로 존재함
  '품질을 중요시하는 팀은 충분히 리뷰하며 이해해야 한다'는 원칙이 있지만, 코드 생성 속도가 너무 빨라 리뷰가 따라잡지 못해 병목이 생기거나 형식적 승인으로 넘어가는 경우가 많음
  주변에서는 리뷰 프로세스를 계속 추가하지만, 이런 접근은 주니어 개발자에게나 효과적이고, AI는 학습하지 않기 때문에 같은 이슈가 반복됨
  LLM은 맥락을 매우 많이 필요로 하지만, 대부분의 사람들은 거의 아무 정보도 주지 않은 채 "이 문제를 해결하는 함수 만들어줘" 식으로만 사용함
  결국 모두가 이해하지 못하는 코드 산(tech debt)을 쌓고 있음
  근본적으로 필요한 것은 LLM이 왜 이것을, 어떤 배경과 의도, 선행 사례를 반영해서 만들어야 하는지 더 효과적으로 맥락을 전달할 수 있는 '프리미티브'임

  • 코드 리뷰가 병목이 된다면, 그래도 코딩과 리뷰를 모두 담당하는 것보다는 코드 리뷰만 병목이 되는 게 낫다고 생각함
    이런 과정을 보완할 수 있는 도구(린트, 퍼징, 테스트 등)는 이미 존재함
    전체 프로젝트를 아키텍처링하거나 빠르게 코드 읽고 분석하는 능력이 부족한 사람들에겐 LLM 시대가 어려울 수 있지만, 이런 역량은 충분히 키울 수 있으며, 시간 지나면 모두 적응할 것임
    이 분야를 좋아해서 새로운 도전에 긍정적으로 임함

  • 다양한 지침 instruction .md 파일을 만들어 에이전트들이 지켜야 하는 코딩 규칙, 꼭 피해야 할 함정, 코딩 기준 문서 링크 등을 넣어 최신화하는 경험이 있음
    Gemini와 Claude 같은 모델이 이런 문서 기반 지침을 어느 정도 잘 반영하지만, 가끔 반복적인 실수도 있음(e.g., C++에서 auto 사용 금지 지시를 했는데도 지키지 않는 경우)
    앞으로 모델이 좋아지면 이런 피드백 처리도 더욱 발전할 것이라는 기대
    결국 '느낌대로 코딩(vibe coding)'에서 벗어나 코드 구조와 유닛 간 상호작용은 사람이 직접 신경 쓰고, AI는 문법과 타이핑에 집중시키는 것이 생산성도 높이고 개발자가 전반적 방향성을 계속 잡아가는 이상적인 타협점이라 느꼈음

  • 프롬프트와 맥락을 구성하는 사고방식을 바꾼 후 LLM 활용에 대한 직관이 한층 발전했음
    프롬프트와 맥락을 통해 산출물의 결과 확률 공간을 줄이는 관점에서 접근하게 됨
    이 과정이 코드의 이론을 재사용성 있게 주입하는 데도 매우 효과적임
    다만, 이런 맥락 준비에 많은 노력과 고민이 요구되며, 직접 구현이 더 나을 구간과 LLM 위임이 더 나은 지점의 경계선을 찾는 것이 아직도 쉽지 않음

  • "프리미티브가 다르다"는 지적에 공감하며, 진짜 중요한 단위는 '테스트'라고 생각함
    모델이 코드를 작성할 때 테스트도 함께 만들게 하고, 테스트가 읽기 쉬운지 항상 점검함
    테스트 전체가 모두 통과할 때만 코드를 머지해야 함
    테스트 인프라를 지속적으로 개선해 전체 테스트가 너무 느려지지 않도록 유지해야 함
    구시대 레거시 코드는 테스트가 없다는 특징이 있었는데, LLM 시대에도 동일성이 적용됨

  • "병목이 된다"는 지적에 대해, StackOverflow 코드를 붙여넣을 때도 항상 읽고 검토한 후 사용하므로, 어차피 사람이 병목임
    결국 이런 과정을 거치지 않고는 코드 사용 자체가 불가능한 것과 마찬가지임

• 최근 Dwarkesh Patel 팟캐스트에서 손님이 <A Deepness In The Sky>라는 소설을 추천했고, 실제로 읽다 보니 수천 년이 지난 컴퓨터 시스템과, 과거의 레거시 지식이 주요한 역할을 한다는 점이 인상적이었음
  이는 레거시 코드와 조직적 지식의 가치를 재미있게 다룬 훌륭한 소설이라 추천할 만함

• 팟캐스트: https://www.youtube.com/watch?v=3BBNG0TlVwM

• 책 정보: https://amzn.to/42Fki8n

  • Vernor Vinge 작가가 사망하게 돼 아쉬우며, 그의 아이디어들이 시간이 갈수록 더욱 현실적 영감을 주는 느낌임

  • 먼 미래에 프로그래머가 되는 과정을 묘사한 부분이 정말 흥미로웠음
    엄청나게 많은 라이브러리·패키지로 인해 새로운 코드를 짜는 것이 아니라, 기존 모듈을 찾아서 조합하는 것이 주요 능력이었음
    기존 코드의 세부적인 뉘앙스와 해석을 꿰뚫는 것이 진짜 실력으로 묘사됨

  • "A Deepness In The Sky"가 시리즈의 두 번째 책으로 보이는데, 1편을 먼저 읽지 않아도 괜찮은지 궁금함
    혹시 바로 읽어도 되는지 질문함

• 대부분 개발자가 어셈블리나 기계어 수준까지 이해하지 못함
  고수준 언어가 인간간의 소통 및 협업의 핵심 계층이 되었음
  LLM의 등장으로 그 계층이 자연어 및 스펙 기반 개발로 밀려가고 있음
  결국 고수준 언어가 수십 년간 진화한 끝에 프로그램 동작 명세를 거의 최적의 형태로 전달하고 있다고 생각함
  자연어로 더 많은 추 abstractions를 시도하면 정보 손실이 발생하고, 저수준 언어로 가면 너무 장황해짐

  • 자연어로의 비약이 단순히 추상화 계층의 변화가 아니라, 근본적으로 완전히 새로운 방식임
    기존 도구(어셈블러, 컴파일러, 프레임워크 등)는 모두 하드코딩된 논리를 기반으로 수학적 검증이 가능했지만, LLM 이후부터는 불확실성과 추측, 심지어 환각이 혼재된 세상으로 뛰어드는 셈임

  • 자바스크립트 개발자 다수가 고수준 개념(적절한 데이터구조, DOM, Node API 등)조차 깊이 이해하지 못하는 경우가 많음
    추상화 계층에 대한 과도한 의존이 생기고, 내부 동작 원리를 잘 모르는 상태에 도달함
    외부인은 "여기서 실제로 무슨 일을 하고 있나요?"라는 의문이 들 수밖에 없음
    이런 현상은 이미 일상적으로 받아들여지고 있음
    결국 아무도 코드 내부를 정확히 모르니 LLM이 코드를 작성해도 본질적 차이가 없음을 비유적으로 설명함

  • 자연어 명세가 역할을 하는 것이 맞지만, 반드시 엄격한 의미론을 가진 중간 계층의 기술이 필요하다고 생각함
    예시로 Rust와 LLM 조합에서, 강력한 타입 시스템이 무효 상태를 페쇄해주고 컴파일까지 오래 걸려도, 최종적으로 원하는 결과가 주로 맞게 나옴
    "컴파일만 되면 대체로 동작한다"는 Rust 커뮤니티 문화가 있으며, 여전히 논리적 버그는 나올 수 있으나 실질적인 오류 공간이 좁아짐
    이상적으로는 논리적 의미를 엄밀히 정의하는 엄격한 프로그래밍 언어와 사전 조건, 후기 조건 등으로 명세가 쌓이고, LLM이 자연어를 포멀 명세로 바꿔주는 역할을 하면 좋겠음

  • 자연어는 애초에 명확하지 않은, 모호함을 내포한 언어임
    프로그래밍 언어에서 파싱에 애매함이 생기면 심각한 버그로 보지만, 자연어에서 모호함은 시, 뉘앙스, 암시 등 다양한 소통의 기능으로 자리잡음

  • 고수준 언어의 결정론적(import) 성질이 유일한 차이는 아님
    프로그래밍에서 결정론이 전부가 아니고, 인간 관점에서 의미가 명확하지 않은 코드 역시 충분히 결정론적일 수 있음
    즉, '고/저수준 추상화'와 '결정론/확률론'의 축은 서로 완전히 다른 문제임

• 나와 우리 팀에게 앞으로 다가올 거대한 일감의 물결로 보임
  8년 가까이 레거시 코드를 구출하면서 사업을 이어왔으나 최근에는 회사들이 LLM에 코딩을 의존하고 있어 수요가 줄어든 상태임
  하지만 앞으로 18개월 정도만 견디면, 단기간에 쌓인 LLM 기반 기술 부채를 해결해달라는 요청이 대거 쏟아질 것이기에 거대한 기회가 생길 것으로 예측함
  Claude가 "이제 코드는 프로덕션 레벨입니다"라며 쌓아놓은 부채의 피해가 곧 드러날 것임

• 지인이 LLM이 만든 PR을 리뷰하면서 겪었던 일화를 들었음
  겉보기에 기능이 완벽히 동작하는 PR이었지만, 내부를 들여다보니 실제로는 백엔드를 업데이트하지 않고 캐시만 조작한 꼼수임을 발견함
  이 코드를 머지하면 안 된다는 점을 매니저에게 납득시키기 위해 많은 노력이 필요했음
  결국 이런 식으로 표면만 동작해 보이는 'vibe coded' 소프트웨어가 세상에 꽤 많을 것이라 의심하게 됨

  • 이런 경우에 그냥 머지해서 후폭풍을 직접 겪게 두는 편이 더 낫다고 생각함
    잘못된 의사결정의 결과를 스스로 체험해봐야 깨달음을 얻기 마련임
    피드백이 없으면 학습도 일어나지 않고, 오히려 그런 매니저가 현실감각 없이 개발팀에 무리한 기대와 압박만 높이다가 직원들이 지치고 교체되는 악순환을 초래함

  • 비전문가인 엔지니어링 매니저가 어떻게 오랫동안 업계에 남았는지 궁금함
    지난 15년간 진짜 비기술 매니저는 거의 못 봤음

  • 이런 매니저가 문제를 일으켰다면 CTO, CEO, 오너, 투자자 등에게 보고해야 한다고 생각함

• LLM 코드뿐 아니라, 남이 쓴 코드라면 누구나 '이해 채무'를 치르게 되며
  구글 같은 대기업에서도 신규 엔지니어가 알골리즘에 큰 변화를 빠르게 주기엔 수개월의 이해 과정이 필수임
  하지만, 인간이 잘 디자인한 코드는 LLM 산출물에 비해 확실히 더 이해하기 쉬움

  • 잘 설계된 인간 코드의 장점은, 컨텍스트와 조직적 지식이 쉽게 활용된다는 점임
    사람에게 직접 설명을 들을 수 있고, LLM 또한 그럴싸한 답변을 주지만 실제 맥락의 차이가 존재함

• 나도 'vibe coding'을 많이 해봤는데, 결국 코드의 정신적 모델이 쌓이지 않아 시간은 저축해도 실제로 디버깅할 때 더 큰 시간 손실이 생김
  처음부터 완벽하게 모든 설계를 세우는 것도 현실에서는 불가능함
  그리고 '인정받은 코드 라인'을 생산성 혹은 시간절약 근거로 삼는 기준은 신뢰하기 어렵다고 생각함

  • 'vibe coding'을 실제로 지속해서 시도하는 사람은 찾기 힘들고, 모두 금세 포기하게 되는 것이 당연함
    LLM에 의존한 코드도 신중하게 검토하며 맞는 모양으로 다듬어가면서 사용하는 것이 확실히 효과적임
    이런 과정은 오히려 '페어 프로그래밍'에 가깝다고 생각함
    LLM 산출물을 아무런 검토 없이 바로 사용하는 방식("vibe coding")이 진짜 효율적일 수 없음을 강조함

• 커니핸의 법칙(Kernighan's Law)을 예로 들어 "디버깅은 코드 작성보다 두 배 어렵다"고 말함
  그렇기에 LLM이 코드를 생성한다면, 그 두 배 더 똑똑한 LLM이 디버깅해야 할 수도 있을 것이라 생각함

  • 내 경험은 반드시 그런 건 아니었고, 항상 내가 직접 운전석에 있어야 함
    Claude Code를 주로 사용하며 실수할 때마다 명확히 지적해서 고치거나, 문제 구역을 따로 짚어줘야 함
    LLM은 스스로 무슨 실수를 했는지 모르기 때문에, 마치 주니어 개발자와 일하는 느낌이 남
    즉, 디버깅 자체는 같은 지능 단계에서도 가능하지만, LLM은 스스로 문제 인지를 못함

  • "디버깅엔 두 배 더 똑똑한 사람이 필요하다"는 말에 대해, LLM의 다양한 '생각 깊이' 모드 차이와 관련 있을 수도 있다고 생각함
    복잡한 함수라면 LLM 보고서에 의도와 접근법을 명확히 설명하도록 먼저 코드 주석을 작성첨부하는 방식을 사용함

[ahwjdekf]

코드작성시 ai 사용 금지되는 날이 멀지 않았다고 봅니다. 말도 안될 거 같지만 전 현실이 될거라고 봐요.