Chiko IT
AI & Machine Learning

기술 부채, 인지 부채, 의도 부채 – 개념 세분화는 실무에 쓸모가 있나

Chiko
12min read

목차

[PR #2847] Reviewer: @seoyeon
> src/pipeline/retry.py:47 — 이 부분 의도가 뭔지 모르겠습니다.
> 요구사항은 "3회 재시도"였는데 지수 백오프 + jitter가 들어가 있네요.
> git blame 보니 Claude 생성 코드로 커밋만 남아있고 의도는 사라졌습니다.
> 유지해도 되는지, 원래 요구사항대로 고쳐야 하는지 판단이 안 섭니다.

실제로, 이런 종류의 PR 코멘트가 최근 1년 사이에 눈에 띄게 늘었다. 코드 자체는 문제가 없다. 테스트도 통과한다. 다만 "왜 이렇게 짰는지"가 증발한 상태다. 지금까지 부르던 "기술 부채"라는 단어로는 이 상황이 잘 설명되지 않는다. 코드가 더럽지도 않고 구조가 꼬인 것도 아닌데 유지보수가 까다로워진다. 2026년 3월 Hacker News에 올라와 200점을 넘긴 글 하나가 바로 이 틈을 건드렸다. 기술 부채를 technical, cognitive, intent 세 갈래로 쪼개야 한다는 주장이었다. 댓글 반응은 정확히 반으로 갈렸다. 한쪽은 "드디어 누가 정리해줬다", 다른 쪽은 "개념 인플레이션이다, 다 기술 부채 안에 들어간다"였다.

그런데, 이 글은 그 논쟁을 2주 정도 뜯어보고, 실무에 끌어올 때 무엇을 남기고 무엇을 버릴지 정리한 실무 가이드다. 5년차 입장에서 새 용어를 무조건 도입하는 건 피하는 편이다. 팀 온보딩 시간만 늘어나고 실질 개선이 적은 경우가 많다. 그래서 세 가지 중 실제로 실무에 새로운 축을 만드는 게 무엇인지에 초점을 맞췄다.

세 가지 "부채"가 가리키는 것

용어부터 짚는다. 1992년 Ward Cunningham이 기술 부채를 비유로 꺼냈을 때는 단순했다. 지금 빠르게 짜면 나중에 이자를 낸다는 이야기다(출처: Ward Cunningham OOPSLA ’92 Experience Report). 2020년대 들어와서 이 개념은 "코드 품질이 낮은 것"을 통칭하는 단어로 퍼졌다. 세분화 진영은 여기서 세 축을 뽑아낸다.

특히, Technical debt는 코드·아키텍처 차원의 부채다. 중복된 로직, 테스트 부족, 오래된 라이브러리. 지표로 측정이 된다. SonarQube나 CodeScene 같은 도구가 잡아주는 대부분이 여기 속한다.

Cognitive debt는 코드를 읽는 사람의 뇌에 쌓이는 부채다. 함수가 너무 많은 책임을 가지거나, 이름이 모호하거나, 추상화가 깊어서 따라가기 힘든 상태다. 코드는 "깨끗"해 보이지만 읽는 데 시간이 걸린다. 사람마다 느끼는 강도가 다르다는 점이 측정을 어렵게 만든다.

결국, Intent debt는 이게 왜 이렇게 되어 있는지, 원래 뭘 하려던 건지에 대한 기록이 없는 상태다. AI 생성 코드가 이 부채를 급격히 늘린다. 커밋은 찍히고 코드는 돌지만, 의도는 프롬프트 로그에 있고 그마저도 휘발된다.

구분 측정 가능성 주요 원인 복구 비용
Technical debt 높음 (정적 분석 도구) 시간 압박, 우회 구현 중간
Cognitive debt 낮음 (리뷰 시 체감) 과도한 추상화, 네이밍 실패 낮음
Intent debt 매우 낮음 AI 생성 코드, 문서 부재 높음

물론, 세 개가 실제로 다른 맥락을 가리키는지 보면, 적어도 intent debt는 다른 둘과 분명히 구분된다. 코드를 아무리 예쁘게 리팩토링해도 "왜 이렇게 짰는지"는 복구되지 않는다. Cognitive와 technical의 구분은 좀 더 흐릿하다.

개념 인플레이션이라는 비판

따라서, HN 댓글에서 가장 추천을 많이 받은 반대 의견은 이렇다. "모든 부채는 결국 기술 부채다. 이름을 세 개로 쪼갠다고 해결이 빨라지지 않는다." 이 비판은 일부 맞다. 용어를 계속 추가하면 생기는 부작용이 있다.

첫째, 논의의 대상이 흐려진다. "이건 cognitive debt야, technical debt가 아니야"라는 라벨 논쟁에 시간이 들어간다. 정작 해결은 뒤로 밀린다. 둘째, 팀 내 커뮤니케이션 비용이 올라간다. 신규 입사자에게 세 가지 부채를 설명하는 데 30분이 필요한 반면, 실제 효용이 그만큼 되는지는 불분명하다. 셋째, 측정 가능성이 낮은 개념일수록 면피 도구로 변한다. "그건 cognitive debt라 어쩔 수 없어요"라는 말은 기술 부채라고 말할 때보다 책임 소재가 더 흐릿해진다.

물론, 개인적으로는 Intent debt만 독립된 개념으로 다루고, cognitive는 기술 부채의 하위 카테고리로 묶는 쪽이 낫다고 본다. AI 코드 비중이 올라가면서 의도 휘발 문제는 확실히 새로운 축이다. 반면 cognitive는 예전부터 "가독성 문제"로 다뤄왔다. 용어를 새로 붙일 실익이 크지 않다.

왜 intent debt만 따로 뺄 가치가 있나

Technical debt는 측정된다. Cognitive debt는 리뷰어가 직접 읽으면서 체감한다. Intent debt는 둘 다 안 된다. 코드를 읽어도, 정적 분석을 돌려도 "왜 이 구현을 골랐는가"는 나오지 않는다. 이 비대칭성이 intent debt를 따로 관리해야 할 유일한 이유다.

AI 도구가 생성한 코드에서 이 현상이 가장 두드러진다. 개발자가 직접 타이핑한 코드는 최소한 작성자 머릿속에 왜 그렇게 짰는지가 남아있다. AI가 짠 코드는 그 단계가 없다. 프롬프트는 채팅창에 있고, 결과물만 커밋된다. 몇 주 뒤에는 프롬프트 히스토리도 사라진다. 남는 건 "동작하는 코드"뿐이다.

한편, 이 간극은 측정은 안 되지만 체감은 된다. 같은 규모의 코드베이스라도 AI 생성 비율이 높아질수록 "이거 왜 이래요?" PR 코멘트가 늘어난다는 관찰이 여러 팀에서 보고되고 있다. 아직 공식 통계는 없지만, 2026년 초 GitHub이 공개한 개발자 설문(출처: State of the Octoverse 2025 Supplement)에서 "AI 생성 코드 리뷰에 쓰는 시간이 이전보다 늘었다"고 답한 비율이 60%를 넘었다.

실무에 끌어오는 3단계 가이드

새 입사자가 "이거 어떻게 해요?" 물을 때 아래 순서로 설명한다. 용어를 외우게 하는 건 피하고, 습관만 박히게 하는 쪽이다.

1단계 — PR 템플릿에 의도 블록 추가

즉, GitHub PR 템플릿(.github/pull_request_template.md)에 아래 블록을 넣는다.

## Why (의도)
- 왜 이 변경이 필요한가?
- AI 도구 사용했다면 어떤 프롬프트로 생성했는가?

## What (변경 내용)
- 어떤 파일을 어떻게 바꿨는가?

## Trade-off
- 어떤 대안을 고려했고 왜 이걸 골랐는가?

"Why" 블록이 핵심이다. Cursor나 Claude Code로 짠 코드가 PR에 올라올 때, 코드 자체는 깨끗해도 의도 블록이 비어있으면 리뷰어가 되묻게 된다. 템플릿으로 이걸 강제하면 intent debt가 쌓이는 속도가 확연히 느려진다. 팀에 따라 차이는 있지만 "왜 이렇게 짰어요?" 코멘트가 눈에 띄게 줄어든다는 경험 공유가 여럿 있다.

2단계 — AI 생성 코드에 의도 주석

AI가 생성한 코드 중 비즈니스 로직이나 경계 조건을 다루는 부분에는 짧은 의도 주석을 남긴다.

# [AI-gen:claude-sonnet-4.5] 2026-04-15
# 의도: 재시도 시 thundering herd 방지 위해 jitter 추가
# 프롬프트 요약: "지수 백오프에 ±20% 랜덤 jitter"
def retry_with_backoff(func, max_attempts=3):
    ...

과하다고 느낄 수 있다. 6개월 뒤에 이 함수를 건드리는 사람이 있다면, 이 세 줄이 intent debt를 갚는 영수증 역할을 한다. 모든 AI 생성 코드에 붙일 필요는 없다. utils.py의 헬퍼 함수까지 이러면 주석만 잔뜩이고 가치가 떨어진다. "왜 이 값인지", "왜 이 구현 패턴인지"가 중요한 구간에만 붙인다.

Anthropic이 2026년 초에 확장한 Claude Code의 CLAUDE.md 컨벤션에서도 유사한 방향을 권장한다. 프로젝트 루트에 의도 기록용 파일을 두고, AI가 읽고 쓰게 만드는 방식이다. MCP 서버로 ADR을 직접 쓰게 하는 팀도 있다.

3단계 — 리뷰 체크리스트 3줄

이처럼, 리뷰어에게는 체크리스트를 짧게 준다.

  • 이 PR의 "Why"를 한 문장으로 말할 수 있는가?
  • 6개월 뒤 이 코드를 처음 본 사람이 이해할 수 있는가?
  • 대안이 있었다면 왜 안 골랐는지 어디엔가 적혀있는가?

반면, 세 번째 항목이 intent debt 방지에 가장 효과가 크다. "왜 A가 아니라 B를 골랐는가"에 대한 기록이 남으면, 나중에 요구사항이 바뀌었을 때 판단이 빨라진다. 대안을 아예 고려 안 한 코드인지, 고려했는데 기각한 코드인지 리뷰어가 알 수 있다.

과잉 세분화를 피하는 실전 기준

반면, 용어를 팀에 강요하는 순간 역효과가 난다. 몇 가지 기준을 뒀다.

회의에서 "cognitive debt"라는 단어를 쓰지 않는다. 대신 "이 함수 읽기 어려움"이라고 말한다. 구체적이면 해결이 빠르다. 용어가 들어가면 "cognitive냐 technical이냐" 라벨 논쟁으로 빠진다.

"intent debt"는 PR 리뷰나 ADR 문서에서만 쓴다. 커피챗이나 스탠드업에서까지 용어를 끌고 오면 피곤해진다. 공식 문서와 구두 커뮤니케이션에서 용어 사용 범위를 다르게 두는 편이 낫다.

이처럼, 지표로 잡히지 않는 부채는 KPI에 올리지 않는다. Cognitive debt를 KPI로 관리하자는 제안이 나오면 반대한다. 측정 불가능한 걸 KPI로 쓰면 숫자를 꾸며내는 쪽으로 인센티브가 생긴다. 측정이 되는 부분만 KPI로, 나머지는 리뷰 품질로 관리한다.

예를 들어, 팀 외부 발표에서는 그냥 "기술 부채"로 묶는다. 용어 학습 비용을 상대방에게 떠넘기지 않는다. 사내 공유 문서에서도 처음 나올 때는 "의도 부채(intent debt)"라고 병기한다.

새 코드 리뷰에 바로 쓰는 9줄 체크리스트

특히, 아래는 실제로 PR 리뷰 템플릿에 붙여서 쓰는 9줄짜리 체크리스트다. 이름은 "3×3 리뷰 체크리스트"다.

Intent 체크 (3줄):

  • 이 변경의 목적이 PR 설명 또는 커밋 메시지에 적혀있는가?
  • AI 도구 사용 시 어떤 프롬프트였는지, 왜 이 결과를 채택했는지 기록했는가?
  • 대안과 트레이드오프가 어디엔가 남아있는가?

그런데, Technical 체크 (3줄):

  • 기존 유틸·헬퍼를 재사용했는가, 중복 구현했는가?
  • 테스트 커버리지가 떨어지지 않는가?
  • 의존성 버전이 팀 기준에 맞는가?

예를 들어, Readability 체크 (3줄):

  • 함수 이름만 보고 뭐 하는지 짐작 가능한가?
  • 한 함수가 한 가지 일만 하는가?
  • 깊은 추상화가 실제 재사용을 위한 것인가, "나중에 쓸 수도 있어서"인가?

이처럼, 이 9줄이 사실상 세 종류의 부채를 다 커버한다. "cognitive debt"라는 단어를 한 번도 꺼내지 않고도 말이다. 용어를 교육하는 대신 체크리스트로 행동을 유도하는 쪽이 신입 입장에서도 덜 피곤하다.

주의사항: 이 구분을 오용하는 패턴

용어를 들여오면서 피해야 할 안티패턴이 몇 가지 있다.

첫째, "intent debt니까 리팩토링으로 해결 안 됨"이라고 선언하는 것. 맞는 말이지만 그걸로 방치해도 된다는 뜻은 아니다. Intent debt는 주석·ADR·PR 설명으로 갚는다. 다른 부채와 방식만 다르지 갚아야 하는 건 똑같다.

둘째, 세 가지 부채를 다 관리하겠다고 Notion 페이지를 세 개 만드는 것. 페이지만 늘고 업데이트가 밀린다. 하나의 부채 트래커에 태그로 구분하는 쪽이 현실적이다.

셋째, AI 생성 코드마다 의도 주석을 강제하는 것. 2단계에서 적은 대로 비즈니스 로직·경계 조건에만 붙인다. 전부 붙이면 주석이 코드보다 많아지고, 결국 아무도 안 읽는다.

넷째, "우리 팀은 cognitive debt가 없다"고 선언하는 것. 측정 불가능한 걸 없다고 주장하는 건 자기 부정이다. 모든 코드베이스에는 읽기 어려운 구간이 있다.

용어보다 중요한 것은 관찰 자체

이 논쟁에서 제일 중요한 건 용어가 아니다. AI가 코드를 많이 짜는 환경에서 의도의 휘발 속도가 빨라졌다는 관찰이다. 이 관찰이 맞다면 이름을 뭐라 붙이든 대응은 해야 한다. 이름을 세 개로 나눌지, 하나로 묶을지는 팀 커뮤니케이션 스타일에 따라 다르다.

실용적으로는 intent debt만 독립 항목으로 관리하고 나머지는 기존 기술 부채 프로세스에 묻어가는 쪽이 낫다. 세 개를 다 관리하려면 용어 교육만으로 시간이 빠진다. 새로 도입하는 개념은 하나씩 가는 게 안전하다.

물론, 당장 이번 주에 해볼 만한 액션 세 가지를 남긴다.

  1. PR 템플릿에 "Why" 블록 한 덩이 추가한다.
  2. AI로 생성한 비즈니스 로직 코드에 [AI-gen:모델명] 태그와 의도 한 줄을 붙인다.
  3. 리뷰 체크리스트에 "대안이 기록되어 있는가" 한 줄을 넣는다.

이 셋만 넣어도 intent debt라는 단어를 따로 외우지 않아도 된다. 실제로 팀에 정착하면 그때 용어를 공식화해도 늦지 않다. 다만 AI 코드 생성 비율이 전체의 절반을 넘어가는 팀에서는 이 정도 대응으로 부족하다는 신호가 조금씩 나오고 있어서, 용어 체계까지 공식화해야 할 시점이 오는지는 더 지켜봐야 한다.

관련 글

More posts