▲

인지 부채: 속도가 이해를 초과할 때

 (rockoder.com)
3P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • AI 보조 개발이 코드 생산 속도를 인간의 이해 속도보다 빠르게 만들며, ‘인지 부채(cognitive debt)’ 가 발생함
  • 코드가 정상 작동하고 테스트를 통과하더라도, 개발자 스스로 코드의 구조와 이유를 이해하지 못하는 상태가 누적됨
  • 리뷰어의 검토 한계, 조직의 암묵지 손실, 신입 개발자의 학습 결핍 등이 이 부채를 가속함
  • 조직은 속도 중심의 지표(DORA, 스토리 포인트 등) 만 측정해 이해 결핍을 포착하지 못함
  • 생산성과 이해의 괴리가 커질수록, 장기적으로 유지보수 실패·지식 단절·엔지니어 성장 정체로 이어질 위험이 큼

이해 지연(The Comprehension Lag)

  • 수동 코딩은 생산과 흡수 두 과정을 동시에 수행하며, 타이핑의 마찰이 사고를 촉진함
    • 코드를 작성하며 자연스럽게 정신적 모델과 직관이 형성됨
  • AI 보조 개발은 이 과정을 분리시켜, 출력 속도는 급증하지만 이해 속도는 인간 한계에 묶임
  • 이 출력-이해 간의 격차가 바로 인지 부채이며, 기술 부채와 달리 속도 지표에서는 보이지 않음
  • 문제는 나중에 MTTR 증가, 변경 실패율 상승 등 신뢰성 지표로 드러남

조직이 실제로 측정하는 것(What Organizations Actually Measure)

  • 조직은 가시적 산출물(기능 수, 커밋, 리뷰 속도 등)만 측정함
  • 과거에는 산출과 이해가 연결되어 있었기에, 기능을 배포하면 이해도 있다고 가정했음
  • 그러나 AI 시대에는 표면적 이해만으로도 기능 배포가 가능, 이 가정이 더 이상 유효하지 않음
  • 조직 지표는 이해 결핍을 포착하지 못해, 성과 평가와 보상 체계가 왜곡됨

리뷰어의 딜레마(The Reviewer’s Dilemma)

  • AI로 인해 주니어가 시니어보다 더 빠르게 코드 생성 가능
  • 시니어 리뷰어는 방대한 코드량을 깊이 검토할 시간이 부족해, 검토 깊이를 희생하게 됨
  • 결과적으로 ‘리뷰된 코드 = 이해된 코드’라는 전제가 무너짐
  • 조직 압박은 속도를 우선시하므로, 검토 품질보다 처리량 중심의 문화가 강화됨

번아웃 패턴(The Burnout Pattern)

  • AI 도구를 사용하는 엔지니어는 높은 산출량과 낮은 확신감이 공존하는 피로를 경험함
  • 코드는 작동하지만, 자신이 만든 시스템을 완전히 이해하지 못하는 불안감이 지속됨
  • 속도 중심의 평가 체계가 깊은 이해를 위한 시간 투자를 불이익으로 만들며, 인지 부채를 가속함

조직 기억의 붕괴(When Organizational Memory Fails)

  • 조직 지식은 문서화된 명시적 지식과 개발자 머릿속의 암묵지로 구성됨
  • AI 개발은 암묵지 형성 과정(직접 구현 경험) 을 단축시켜, 지식 축적이 이루어지지 않음
  • 결과적으로 시스템은 작동하지만, 이해 가능한 인력이 점차 사라짐
  • 문제 발생 시, 누구도 시스템의 맥락을 설명할 수 없는 상태가 됨

인지 부채의 누적(How the Debt Compounds)

  • 첫째, 오래된 코드일수록 위험해짐 — 작성 당시에도 불완전하게 이해된 코드가 완전히 불투명해짐
  • 둘째, 사고 대응 시 복구 시간 급증 — “블랙박스가 만든 블랙박스”를 디버깅하는 상황 발생
  • 셋째, 미래 시니어 엔지니어의 부재 — AI 의존으로 학습 곡선이 사라져, 장기적 리더십 공백 초래

디렉터의 시각(The Director’s View)

  • 경영진은 생산성 향상, 일정 단축, 인력 효율화 등 긍정적 신호만 인식함
  • ‘이해 깊이’나 ‘설명 가능성’ 을 측정하는 지표가 존재하지 않아, 인지 부채는 보고되지 않음
  • 따라서 데이터 기반 의사결정은 합리적이지만 불완전, 실제 위험은 감춰짐

모델의 한계(Where This Model Breaks)

  • 모든 작업에 인지 부채 개념이 동일하게 적용되지는 않음
    • 단순 반복 작업이나 빠른 실험에는 적합할 수 있음
  • 과거에도 이해 수준은 개인별로 달랐으며, 새로운 현상이라기보다 분포의 이동일 가능성 있음
  • 향후 도구·문서화 개선으로 이해 격차를 줄일 가능성도 존재함

측정의 문제(The Measurement Problem)

  • 조직은 측정 가능한 것만 최적화함
    • 속도는 측정 가능하지만, 이해는 측정 불가
  • 이해가 평가 체계에 반영되지 않는 한, 속도 중심의 인센티브가 유지됨
  • 이는 개인이나 관리자의 실패가 아니라, 과거 시대의 측정 시스템이 현재 현실과 불일치한 결과임
  • 결국 이 격차는 유지보수 비용 증가, 사고 대응 지연, 시스템 취약성 노출 등으로 드러날 가능성 있음
  • “시스템은 측정하는 대로 최적화된다. 그러나 지금 측정하는 것은 더 이상 중요한 것을 담지 못한다”는 결론으로 마무리됨
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • 최근 몇 달간의 경험이 기사 내용과 매우 공감됨
    내가 일하는 프로젝트는 꾸준히 성장했지만 엔지니어 수는 오히려 줄어듦
    테스트 의존도를 높이고 시뮬레이터 기반 개발로 전환했음. 실제 시스템에서 검증하는 일은 드물고, 그럴 때마다 가장 복잡한 부분을 다룸
    작년쯤부터는 몇 달간 작업했던 기능조차 세부 내용을 금방 잊어버리는 걸 느꼈음. 아직 코딩 에이전트가 본격적으로 도입되기 전이었는데도 그랬음
    에이전트가 들어오자 PR 리뷰가 훨씬 암묵적이 되어, 맥락이 머리에 남지 않아 의식적으로 집중해야 함. 팀원들도 같은 경험을 보고함
    지금은 코드와 함께 에이전트의 계획을 커밋하는 등 여러 시도를 하는 중임. 덕분에 프로세스가 더 체계적이고 명시적으로 변하고 있음
    다만 엔지니어링 매니저는 이런 인지 부하 증가에 대해 거의 인식하지 못하는 듯했음

    • 내 경험상 매니저들은 종종 숲만 보고 나무를 놓침. 좋은 매니저는 팀의 인지적 부담을 덜어주는 것이 역할임
    • 배운 건 결국 기록하는 습관임. 읽기만 해서는 머리에 남지 않음
    • 지금은 진짜 AI 주도 개발을 뒷받침할 추상화가 부족함. 우리는 자신을 대체했지만, 그 위 한 단계의 도구는 아직 없음
    • 앞으로는 에이전트와의 대화 기록(프롬프트, 계획, 결과 보고) 을 남기는 게 점점 중요해질 것 같음

  • 글의 전제인 “개발자는 6개월 전 자신이 쓴 코드를 기억한다”는 가정은 틀림
    예전부터 코드를 쓸 때 이해하는 게 읽을 때보다 쉬웠음. Joel Spolsky도 “코드를 읽는 게 쓰는 것보다 어렵다”고 했음

    • 세부 로직은 잊어도 전체 흐름은 기억해서 다시 파악하기 쉬움
    • 4년 전 코드베이스를 다시 봤는데도 구조와 의도를 잘 떠올릴 수 있었음
    • 여러 코드베이스를 오가며 일하지만, 6개월 후 돌아가도 일주일 후 돌아가도 비슷한 느낌임. 익숙한 코딩 스타일과 구조적 직관이 금방 되살아남
    • 처음 배울 때는 손으로 직접 코딩하며 비판적 사고를 내재화하는 게 중요함. 그래서 Jupyter notebook으로 단계별로 실험하곤 함
    • 읽는 게 어렵다는 건 느리다는 뜻이 아님. AI가 코드를 대신 써도 이해 과정은 여전히 필요함. 다만 사람은 본능적으로 어려운 일을 피하려 함

  • “이해되지 않는 코드” 문제는 AI 이전에도 있었음
    예를 들어 Microsoft의 Pinball 코드 삭제 사례처럼, 오래된 외주 코드가 너무 복잡해 아무도 이해하지 못해 결국 기능을 포기한 적도 있음
    Oracle RDBMS 코드베이스 사례도 비슷함

    • 하지만 OP의 말처럼, AI 코드에서는 이런 상황이 더 자주, 더 빨리 발생할 수 있음
    • 그래서 프롬프트를 버전 관리에 함께 저장해야 한다고 생각함. 그것이 사람과 기계 모두에게 맥락이 됨
    • “내가 코드를 쓸 땐 나와 신만 이해했는데, 이제는 신만 이해한다”는 농담이 떠오름

  • “정상적으로 작동하지만 낯선 시스템”이라는 말이 인상적이었음
    이는 개발자가 매니저로 전환될 때 느끼는 감정과 비슷함. 코드에서 멀어질수록 이해가 추상적이고 단절된 느낌이 됨

    • 나도 매니저이자 개발자인데, 요즘은 “vibe-coding”이 내 일의 대부분임. 큰 그림을 생각하고, 코드가 그 그림과 맞는지 검증하는 게 핵심임
    • 결국 좋은 관리처럼 명확한 도메인 경계와 품질 기준, 반복 개선 프로세스가 필요함

  • “깊이 이해하려는 엔지니어가 속도 지표에서 뒤처진다”는 말이 가장 뼈아픔
    시장은 품질보다 속도를 중시하고, 결국 신중한 엔지니어가 해고당하는 구조임

    • 물론 제약이 창의성을 낳기도 함. 무한한 시간과 돈이 있다면 완벽을 추구하겠지만, 현실은 경쟁과 자원 한계 속에서 제약이 품질을 만든다는 예시도 많음

  • 이제는 “LGTM, LLM” 시대로 가야 할지도 모르겠음
    산업은 항상 과도하게 치닫고 나중에 균형을 찾음. 문제는 20배 생산성을 요구하면서 100% 책임을 지라는 불가능한 기대임
    결국 이해를 포기하거나, 최대 20% 정도의 생산성 향상만 받아들여야 함

    • Sid Meier의 “Double it or cut it in half”라는 게임 디자인 조언처럼, 극단적인 조정이 필요함 (링크)
    • 생산성 향상은 코드베이스 구조에 따라 달라짐. 레거시 프로젝트는 오히려 느려지고, LLM 친화적 구조에서는 큰 향상이 가능함
    • 나도 아직 그 구조를 배우는 중이며, 이건 아직 bleeding edge 단계임
    • 코드 작성 외에도 LLM을 제품 전체 전달 과정에 창의적으로 활용하면 더 큰 생산성 향상이 가능함
    • 하지만 결국 문제가 터지면 “왜 아직 해결 못했냐”는 질문을 받게 됨. 단기 출시 중심 문화는 여전함
    • 결국 망가져야 고칠 수 있음, 임시방편은 고통을 길게 끌 뿐임

  • Richard Gabriel의 Worse Is Better 철학이 떠오름
    AI 코드는 종종 정확성보다 단순함을 택하지만, “작동하기만 하면 이긴다” 는 현실적 접근이 승리할 수도 있음
    일단 작동하는 시스템이 생기면 점진적으로 개선할 수 있음

    • 하지만 “이기는 것”이 목표가 아니라 자부심 있는 제품을 만드는 것이어야 하지 않겠냐는 반론도 있음
    • 어떤 경우엔 AI가 인간 코드를 리팩터링하기도 함. 솔직히 AI가 나보다 더 깔끔하게, 더 빠르게 코드를 씀
    • 단순함이 정확성과 충돌할 수 있다는 점은 흥미로운 질문임

  • 우리 팀도 지난 6개월간 기사에서 말한 현상을 똑같이 겪었음
    AI 보조 개발이 암묵적 지식 축적을 단절시킨다는 핵심 문장이 정확함
    다만 이 현상이 일시적 과도기일 수도 있음
    장기적으로는 LLM이 코드 구조를 잘 정리해, 사람이 필요한 순간에만 깊이 이해하도록 돕는 메타 수준의 가치를 제공할 수도 있음

    • 하지만 현재 LLM은 너무 많은 불필요한 코드와 비정제된 해결책을 만들어서, 오히려 디버깅과 유지보수에 LLM이 필수인 상황임

  • 문서화가 부족하면 제품 지원팀도 큰 타격을 받음
    고객이 제품 동작을 물어볼 때, 엔지니어조차 자신이 쓴 코드를 잘 모르면 답변이 어려움
    업데이트 속도가 빠르면 다른 팀이 따라가기 힘듦

    • 코드 작성 시간을 줄인 만큼 문서화가 워크플로의 일부가 되어야 함. 나도 이제 그렇게 해야겠다고 생각함

  • 고수준 언어의 등장 때도 비슷한 일이 있었지만, 결과적으로 괜찮았음
    그렇다면 LLM이 코드 이해를 추상화해도 괜찮을까?
    차이는 컴파일러는 결정적(deterministic) 이지만 LLM은 확률적(probabilistic) 이라는 점임

    • LLM을 컴파일러에 비유하는 건 무리임. 컴파일러는 연역적, LLM은 귀납적 과정임
    • 미래에는 결정적 에이전트, 초고속 모델, 로컬 실행 환경이 갖춰지면 고수준 언어와 큰 차이가 없을 수도 있음
    • 다만 프로그래밍 교육은 완전히 바뀔 것임. 언어 자체를 아는 건 지금의 어셈블리 수준으로 밀려날 것임
    • 고수준 언어는 인간이 읽기 쉽게 구조를 명시화하는 게 목적이었지만, LLM은 그 반대임
    • 실제로 하드웨어 수준의 직관이 사라지면 비효율적 코드나 보안 취약점이 생길 위험이 커짐
답변달기