기술부채는

기술의 문제가 아니다

기술부채는 코드가 아니라
조직이 기술을 다루는 방식의 문제입니다.

기술부채는 기술팀의 문제가 아니다

기술부채는
기술을 무시한 결정의 결과입니다.

• 책임은 기술팀이 아닌 조직 전체에 있음
• 실제 원인은 일정 압박, 전략 부재, 기술 이해 부족
• 조직 문화와 의사결정이 근본 원인

기술부채는 줄일 수 있다

기술부채는
'관리'가 아닌 '최소화'의 대상입니다

• 피할 수는 없지만, 조직의 선택으로 줄일 수 있음
• 기술을 존중하는 문화가 부채 누적을 막음

기술부채의 8가지 유형

1. 설계 부족
2. 과설계 (오버엔지니어링)
3. 문서 부채
4. 테스트 부채
5. 의존성 부채
6. 인프라 부채
7. 지식 부채
8. 의사결정 부채

설계 부족

• 경계 없음, 추상화 없음
• 일정 중심 조직이 원인

구조는 코드보다 먼저 정의되어야 합니다
그리고 언제든 삭제 준비(Expiry-Ready)된 형태여야 합니다

나의 제안

• 목업 코드로 인터페이스를 먼저 구현
• 흐름 중심 구조 설계
• 작업 순서만 바꿔도 구조는 가능

오버엔지니어링

• 너무 정교해서 아무도 못 씀
• 유지할 사람이 없는 구조

유지 불가능한 설계는 기술부채입니다

나의 제안

• 조직이 함께 유지할 수 없는 구조는 도입하지 않음
• 복잡한 설계는 공유와 공감이 가능해야 함
• 설계는 전파 가능한 경계를 만들어야 함

문서 부채

• 설명 없는 시스템
• 온보딩 불가, 협업 저하

문서 없는 구조는 삭제가 두려운 구조입니다
삭제 준비(Expiry-Ready)된 구조는 설명 가능한 구조에서 시작됩니다

나의 제안

• 명확한 코드 = 문서
• 문서 작성은 기여
• 조직의 기억을 남기는 사람을 인정

테스트 부채

• 테스트가 구조를 고착
• 리팩토링 방해

테스트는 감옥이 아닌 보호벽입니다

나의 제안

• 인터페이스 기준 테스트 설계
• 변경이 잦지 않은 인터페이스 구조
• 테스트 설계도 리뷰 대상

의존성 부채

• 특정 기술에 고착
• 대체 불가능 구조

교체할 수 없다면, 그것은 감옥입니다
기술은 언제든 삭제 준비(Expiry-Ready)된 구조 위에서 도입해야 합니다

나의 제안

• 외부 기술은 제거 가능한 구조로 감싸기
• 기술 도입 시 생애주기와 전환 전략 고려
• 기술 선택은 조직의 책임

인프라 부채

• CI/CD 미비, 로그 부재
• 운영 효율 저하

하지 않았다면, 지금부터 하면 됩니다

나의 제안

• 인프라 부채는 실행하지 않아 생긴 문제
• 점검과 청산을 운영 프로세스에 포함
• 운영 신뢰성은 기능보다 더 큰 가치

지식 부채

• 특정인에게만 집중된 지식
• 퇴사 = 리스크

문서를 쓰는 사람은 회사를 지탱하는 사람입니다

나의 제안

• 지식 정리는 조직 유지 핵심 자산
• 온보딩 문서와 구조 설명은 공식 산출물
• 문서화를 정량적 지표로 평가

의사결정 부채

• 기술 이해 없는 결정
• 구조 왜곡, 반복 리팩토링

기술을 모르는 사람이 기술을 결정하면, 그것은 경영 리스크입니다

나의 제안

• 기술은 기술을 이해한 사람이 결정
• 결정 책임은 의사결정권자에게
• 기술 리터러시는 리더십 평가 항목

삭제 준비(Expiry-Ready)된 구조

• 진짜 설계는 버릴 수 있어야 합니다
• 버릴 수 없는 구조는 기술 자산이 아닌 부채입니다
• 삭제 준비(Expiry-Ready)를 통해 설계의 자유를 만듭니다
• 설명 가능하고 문서화된 구조여야 삭제도 가능합니다

기술부채는

문화로 예방합니다

• 코드만 고쳐서는 부채가 줄지 않습니다
• 기술을 다루는 태도와 구조적 감각이 핵심입니다
• 기술부채는 문화의 부재로 발생하며
  결국 문화로만 예방할 수 있습니다

기술부채 예방을 위한 핵심 문화

1. 인터페이스 우선: 목업 코드 중심, 흐름 먼저
2. 가독성 중심: 읽기 쉬운 코드가 좋은 코드
3. 문서화의 인정: 기록은 생산이고 기여
4. 리뷰는 철학: 구조와 책임을 공유하는 시간
5. 기술 선택의 전략화: 최신보다 생존 가능한 구조
6. 지식의 공유: 기억은 개인이 아니라 조직에 남겨야 함

문화적 예방은

행동으로 이어져야 합니다

• 예방 문화는 선언이 아니라 루틴과 제도로 녹아야 합니다
• 회고, 리뷰, 설계 토론, 문서 리뷰 등이 정례화되어야 합니다
• 개발자 개인의 자율성에 맡기지 않고, 조직이 보장해야 합니다

기술부채 예방은 개발자의 품질의지가 아니라
조직의 의사결정 철학에서 출발해야 합니다

기술부채 청산의 날

• 기술부채는 방치하면 쌓입니다
• 중요한 건 정기적인 점검과 삭제 준비(Expiry-Ready)입니다
• “청산의 날”은 특별한 날이 아닌, 루틴이 되어야 할 시간입니다

청산의 날, 이렇게 운영합니다

1. 인터페이스 문서 정리
2. 스파게티 코드 해석
3. 기술부채 항목 태깅 및 명시
4. 삭제 시나리오 작성
5. 리팩토링 우선순위 목록화

반드시 다 해결하지 않아도 됩니다
문서화와 계획만으로도 큰 의미가 있습니다

왜 청산의 날인가?

• 평소엔 눈앞의 기능이 우선되기 때문입니다
• 부채는 안 보이면 계속 밀립니다
• 따로 시간을 정해야만, 그 일에 집중할 수 있습니다

기술부채 청산의 날은
코드를 고치는 날이 아니라,
책임을 되돌아보는 날입니다

진짜 효과는 반복에서 나옵니다

• 반복되면 감각이 생깁니다
• 반복되면 문화가 됩니다
• 반복되면 부채가 쌓이기 전에 인식됩니다

기술부채 청산은 구조 훈련이다

• 구조를 바라보는 감각
• 인터페이스를 설계하는 힘
• 나중에 설명할 수 있는 코드
• 이 모든 것은 훈련을 통해 길러집니다

청산의 날은 결국 개발자가
조직과 함께 성장하는 루틴입니다

기술부채는

기술의 실패가 아닙니다

기술부채는 조직의 태도에 대한 피드백입니다
기술팀만이 아닌, 조직 전체의 책임입니다