1인 개발자가 기술 부채의 우선순위를 정하는 방법

혼자 여러 프로젝트를 개발하면 기술 부채 목록은 쉽게 길어진다.

테스트 없는 결제 함수
중복된 API 응답 타입
수동 배포 절차
오래된 프레임워크
느린 검색 쿼리
정리되지 않은 폴더
임시로 넣은 retry
문서 없는 cron

전부 중요해 보이지만 한 달을 ‘부채 청산’에만 쓰면 제품이 멈춘다. 반대로 기능만 계속 추가하면 사소한 변경에도 예기치 않은 장애가 생기고, 어느 순간 코드를 여는 것 자체가 부담스러워진다.

팀에서는 다른 개발자가 기억과 리뷰를 나눠 갖지만 1인 개발자는 설계 배경, 운영 대응, 고객 문의, 새 기능을 한 사람이 모두 떠안는다. 그래서 코드 복잡도보다 내 머릿속에만 존재하는 복구 지식과 반복되는 전환 비용이 더 큰 부채가 되기도 한다.

이 글은 기술 부채를 감정적으로 “언젠가 정리할 것”이라고 적어 두는 대신 실제 작업 순서로 바꾸는 방법을 정리한다.

목차

• #모든 낡은 코드가 기술 부채는 아니다
• #1인 개발에서 부채가 더 비싸지는 이유
• #먼저 점수 밖의 위험을 분리한다
• #부채 항목을 결과 중심으로 기록한다
• #우선순위 평가 축을 정한다
• #점수는 결정을 돕는 도구로만 쓴다
• #다음 로드맵과 맞닿은 부채를 찾는다
• #해결 단위를 작게 만든다
• #기능 작업 안에서 갚을지 별도 작업으로 할지
• #부채 예산을 반복 일정에 넣는다
• #완료 조건은 코드 정리가 아니라 위험 감소다
• #Obsidian에서 기술 부채 장부 운영하기
• #미뤄도 되는 부채를 명시한다
• #정기 검토에서 볼 지표
• #흔히 실패하는 우선순위 방식
• #실전 의사결정 예시
• #정리
• #관련 노트

모든 낡은 코드가 기술 부채는 아니다

오래된 코드, 마음에 들지 않는 코드, 기술 부채는 같은 말이 아니다.

5년 된 함수라도 요구사항이 안정적이고 장애가 없으며 다시 바꿀 가능성이 없다면 당장 비용을 만들지 않는다. 반대로 지난주에 급히 추가한 API가 모든 기능 변경을 방해한다면 이미 큰 부채다.

기술 부채를 다음처럼 정의해 볼 수 있다.

현재 선택 때문에
미래의 변경·운영·학습 비용이
반복적으로 증가하는 상태

부채인지 판단하려면 “코드가 예쁜가?”보다 다음 질문이 유용하다.

• 이 영역을 바꿀 때 실제로 시간이 더 드는가?
• 같은 원인으로 장애나 문의가 반복되는가?
• 복구 방법이 내 기억에만 있는가?
• 다음 기능이 이 구조 때문에 우회 구현되는가?
• 의존성 업데이트와 보안 대응을 막고 있는가?
• 실패했을 때 데이터를 되돌릴 방법이 없는가?

1인 개발에서 부채가 더 비싸지는 이유

기술 부채의 전통적인 이자는 변경 시간과 결함 증가다. 1인 개발에는 몇 가지가 더 붙는다.

기억의 만료

당시 왜 예외 처리를 넣었는지 문서가 없으면 석 달 뒤의 나는 사실상 새로운 개발자다. 코드보다 맥락 복원에 시간이 더 든다.

수정 20분
+ 저장소 탐색 40분
+ 배포 절차 다시 찾기 30분
+ 혹시 깨질까 수동 확인 60분
= 부채 이자 130분

역할 전환 비용

개발하다가 운영 장애를 보고, 고객 문의에 답하고, 다시 코드를 열면 작업 맥락이 끊긴다. runbook과 자동화가 없을수록 같은 문제를 매번 처음부터 푼다.

bus factor 1

내가 아프거나 장기간 프로젝트를 쉬면 아무도 복구할 수 없다. 개인 프로젝트라도 미래의 나와 협력자에게 넘길 최소 문서, 백업, 배포 경로가 필요하다.

포트폴리오 효과

여러 프로젝트가 같은 인증, 배포, 로깅 패턴을 복사해 쓰면 한 프로젝트의 임시 선택이 여러 곳으로 번진다. 개별 수정 비용보다 동기화 비용이 커진다.

회피 비용

어려운 모듈을 건드리기 싫어 주변에 새 코드를 덧붙이면 부채가 복리처럼 늘어난다. 실제 시간뿐 아니라 “이 기능은 건드리기 무섭다”는 선택 편향도 비용이다.

먼저 점수 밖의 위험을 분리한다

모든 항목을 하나의 점수표로 줄 세우면 안 된다. 발생 확률은 낮아 보여도 한번 일어나면 사업을 끝낼 수 있는 위험은 별도 게이트로 처리한다.

다음 항목은 우선순위 계산 전에 확인한다.

• 복구 검증이 없는 유일 데이터
• 노출된 secret과 과도한 관리자 권한
• 지원 종료된 인증·암호화 라이브러리의 알려진 취약점
• 결제·포인트·재고의 중복 차감 가능성
• 개인정보의 무제한 로그 또는 잘못된 접근 통제
• 만료가 임박한 인증서·도메인·필수 외부 계약
• 롤백 불가능한 파괴적 migration
• 법적·계약상 기한이 있는 문제

flowchart TD
    A[부채 항목 발견] --> B{데이터 손실·보안·법적
복구 불가능 위험인가?}
    B -->|예| C[즉시 완화 또는 작업 중단 기준]
    B -->|아니오| D[일반 우선순위 평가]
    C --> E[근본 해결 계획]
    D --> F[로드맵과 비용 비교]

긴 근본 해결을 당장 할 수 없다면 피해를 제한하는 완화를 먼저 한다.

위험: 파괴적 배치가 잘못된 범위를 삭제할 수 있음

오늘의 완화
  dry-run 기본값
  최대 처리 건수 제한
  관리자 승인
  백업 snapshot

다음 작업
  삭제 대신 상태 전이
  복구 명령과 테스트

완화가 들어갔다고 부채를 닫지는 않는다. 잔여 위험과 만료 날짜를 남긴다. 백업이 아니라 복구를 테스트해야 하는 이유처럼 백업 존재보다 실제 복구 가능 여부를 확인해야 한다.

부채 항목을 결과 중심으로 기록한다

나쁜 부채 목록은 해결책만 적혀 있다.

- service 폴더 리팩터링
- TypeScript로 바꾸기
- Redis 도입
- 테스트 추가

무엇이 불편한지, 해결하면 무엇이 달라지는지 알 수 없다. 다음 형식으로 기록한다.

type: technical-debt
id: debt-search-fallback
status: observed
area: search
symptom: 검색 인덱스 장애 때 상품 화면 전체가 실패한다.
evidence:
  incidents_90d: 2
  manual_recovery_minutes: 75
impact:
  users: high
  data: low
  operations: high
next_roadmap_contact: 검색 필터 개편
smallest_mitigation: DB 기반 제한 검색 fallback 추가
done_when:
  - 인덱스를 차단한 통합 테스트에서 제한 결과를 반환한다.
  - degraded 응답과 지표가 표시된다.
owner: me
review_on: 2026-09-15

핵심 필드는 다음과 같다.

“코드가 더러움”을 증상으로 쓰지 않는다. “상품 타입을 하나 추가할 때 세 군데 enum을 수동 변경하고 한 번 누락했다”처럼 관찰 가능한 비용을 적는다.

우선순위 평가 축을 정한다

일반 부채는 다섯 축으로 평가할 수 있다.

1. 영향도

실패했을 때 사용자, 데이터, 매출, 운영에 미치는 크기다.

2. 발생 가능성과 빈도

이미 반복된 사건은 추측보다 강한 근거다.

3. 변경 마찰

앞으로 기능을 추가하는 속도를 얼마나 늦추는지 본다.

변경 마찰
= 추가 탐색 시간
+ 수동 검증 시간
+ 회귀 불안 때문에 피한 설계
+ 여러 저장소 동기화 비용

다음 기능이 해당 영역을 곧 건드린다면 점수를 높인다.

4. 복구 난이도

문제가 생겼을 때 자동으로 되돌릴 수 있는지, 원본 데이터와 runbook이 있는지 본다.

낮음: feature flag로 즉시 끌 수 있고 데이터 변경 없음
중간: 수동 SQL과 검증 필요
높음: 원본 재수집 또는 고객 확인 필요
매우 높음: 복구 불가 또는 사실 확인 불가

5. 해결 비용과 불확실성

같은 위험 감소라면 작은 작업을 먼저 할 수 있다. 하지만 “쉬운 것만 처리”하는 함정을 피하려면 영향과 함께 본다.

effort = 구현 + 테스트 + migration + 배포 + 관측 + 롤백

코드 수정 2시간이어도 데이터 backfill과 고객 공지가 필요하면 2시간짜리 부채가 아니다.

점수는 결정을 돕는 도구로만 쓴다

간단한 점수는 비교 대화를 돕는다.

risk = impact × likelihood × recovery_difficulty
interest = repeat_frequency × time_lost_each_time
leverage = roadmap_proximity + change_friction

priority_hint
= (risk + interest + leverage) / effort

정확한 수학 모델처럼 받아들이지 않는다. 1~5 척도를 곱하면 주관적인 차이가 과장되고, effort가 큰 필수 작업은 항상 뒤로 밀릴 수 있다.

실제로는 다음 2단계가 낫다.

1. 안전 게이트와 마감 조건으로 반드시 할 일을 분리한다.
2. 나머지 항목을 점수와 맥락으로 대략 정렬한다.

가상 평가 표를 보자.

점수보다 판단 열이 중요하다. “즉시”, “다음 기능 전”, “맞닿을 때”, “보류” 같은 실행 시점을 붙인다.

다음 로드맵과 맞닿은 부채를 찾는다

기술 부채는 관련 코드를 다시 만날 때 갚는 비용이 가장 낮다. 이미 맥락을 불러왔고 테스트 환경을 열었기 때문이다.

flowchart LR
    R[다음 기능 목록] --> T[건드릴 모듈과 데이터]
    D[기술 부채 장부] --> T
    T --> C[기능에 선행하는 부채]
    T --> B[기능과 함께 갚을 부채]
    T --> L[여전히 닿지 않는 부채]

세 유형으로 나눈다.

선행 부채

해결하지 않으면 기능을 안전하게 만들 수 없다.

기능: 환불 자동화
선행 부채: 결제 이벤트의 멱등성 키 없음

기능 일정에 포함해야 한다. 숨겨진 별도 작업이 아니다.

동반 부채

기능을 만들며 자연스럽게 같은 코드를 건드린다.

기능: 상품 상태 하나 추가
동반 부채: 세 모듈에 복제된 상태 mapping

먼저 characterization test를 만들고 mapping을 한곳으로 모은 뒤 기능을 추가하면 총비용이 줄 수 있다.

무관한 부채

다음 기능과 닿지 않고 위험도 낮다. 별도 정리 욕구만으로 끼워 넣지 않는다.

로드맵 근접성은 긴급성과 다르다. 사고 위험이 큰 항목은 로드맵을 기다리지 않고, 일반 부채는 접촉 시점을 활용한다.

해결 단위를 작게 만든다

“레거시 모듈 리팩터링”은 완료 조건이 없어 계속 커진다. 위험을 줄이는 가장 작은 세로 조각으로 나눈다.

거대한 정산 모듈 개선

1. 대표 12개 사례 Characterization Test
2. 시간과 환율 조회를 주입 가능한 seam으로 분리
3. 결제 승인에 idempotency key 저장
4. 원장과 상태 변경을 한 transaction으로 묶기
5. outbox event 추가
6. 이전 경로와 새 경로 shadow 비교
7. feature flag로 10% 전환
8. 구 경로 제거

각 단계는 독립적으로 위험을 줄이거나 다음 단계를 안전하게 해야 한다. 단지 파일을 옮기고 이름을 바꾸는 작업만으로 완료했다고 보지 않는다.

작은 단위가 좋은 이유는 다음과 같다.

• 기능 작업 사이에 넣을 수 있다.
• 문제가 생기면 원인을 찾기 쉽다.
• 중간에 우선순위가 바뀌어도 이미 얻은 안전망이 남는다.
• rollback이 작다.
• 노력 추정의 오차가 줄어든다.

레거시 코드에 Characterization Test 추가하기의 방식처럼 테스트를 첫 산출물로 잡으면 큰 재작성 없이도 다음 변경 위험이 즉시 낮아진다.

기능 작업 안에서 갚을지 별도 작업으로 할지

모든 리팩터링을 기능 PR에 넣으면 리뷰 범위가 커지고 일정이 흐려진다. 반대로 무조건 별도 프로젝트로 떼면 영원히 우선순위를 얻지 못한다.

기능과 함께 처리할 때도 커밋 순서를 분리한다.

1. 현재 동작 테스트
2. 행동 보존 리팩터링
3. 새 기능
4. 관측과 rollout 설정

이 순서면 회귀와 요구사항 변경을 구분하기 쉽다.

큰 rewrite는 매력적이지만 기존 시스템의 암묵적 규칙을 한꺼번에 잃을 수 있다. strangler 방식으로 경계를 하나씩 바꾸고 실제 트래픽을 비교하는 편이 안전하다.

부채 예산을 반복 일정에 넣는다

남는 시간에 기술 부채를 처리한다는 계획은 거의 작동하지 않는다. 기능과 운영이 항상 남는 시간을 사용하기 때문이다.

1인 개발에서는 고정 비율보다 작은 반복 규칙이 실용적이다.

매주
  30분: 부채 inbox 정리
  1개: 2시간 이하의 반복 마찰 제거

매 기능
  touched module의 테스트·문서 최소 개선

매월
  복구 훈련 또는 의존성 업데이트 한 묶음

매 분기
  지원 종료, secret, 백업, 비용, 미사용 시스템 검토

제품 단계에 따라 비율을 조정한다.

“20%는 기술 부채” 같은 숫자를 맹목적으로 적용하지 않는다. 지불한 이자와 위험에 따라 예산을 늘리거나 줄인다.

완료 조건은 코드 정리가 아니라 위험 감소다

부채 티켓의 완료 조건이 “코드 정리 완료”면 해결 효과를 확인할 수 없다.

다음처럼 바꾼다.

해결 전후 지표를 저장한다.

before:
  change_lead_time_minutes: 140
  manual_steps: 11
  incidents_90d: 3
after:
  change_lead_time_minutes: 55
  manual_steps: 3
  incidents_90d: 0
verify_until: 2026-11-30

사고 건수처럼 표본이 적은 지표는 단기간 0이라고 성공을 확정하기 어렵다. 대신 자동 테스트, 실패 주입, 수동 단계 감소 같은 선행 지표를 함께 본다.

해결 결과가 기대보다 작으면 설계가 틀렸거나 원인이 다른 곳에 있을 수 있다. “리팩터링했으니 끝”이 아니라 장부에 배운 점을 남긴다.

Obsidian에서 기술 부채 장부 운영하기

기술 부채는 코드 TODO, 이슈 트래커, 머릿속에 흩어지기 쉽다. Obsidian에는 판단 맥락을 담고 실제 작업은 저장소 이슈와 연결하는 식으로 역할을 나눌 수 있다.

노트 템플릿 예시는 다음과 같다.

---
type: technical-debt
status: observed
project:
area:
discovered:
review_on:
risk_gate: false
impact: 1
likelihood: 1
change_friction: 1
recovery_difficulty: 1
effort: 1
roadmap_contact:
issue_url:
---

본문에는 다음 질문을 둔다.

# {{title}}

## 증상

## 근거

## 최악의 실패

## 현재 완화

## 가장 작은 다음 단계

## 완료 조건

## 미루는 이유와 재검토 날짜

## 관련 프로젝트와 변경

Dataview 플러그인을 사용한다면 재검토가 지난 항목을 모을 수 있다.

Dataview가 없어도 frontmatter를 일관되게 두면 기본 검색과 Properties로 관리할 수 있다.

프로젝트 MOC에는 모든 부채를 복사하지 않고 연결만 둔다.

## 기술 부채

- 즉시 위험: `복구되지 않는 주문 백업`
- 다음 기능 선행: `검색 fallback 부재`
- 재검토 대기: `관리자 UI 상태 모델 정리`

미뤄도 되는 부채를 명시한다

우선순위는 할 일을 정하는 것만큼 하지 않을 일을 정하는 과정이다.

낮은 우선순위 후보는 다음과 같다.

• 곧 폐기할 실험 기능의 내부 구조
• 변경 가능성이 낮고 격리된 모듈
• 사용자·운영 영향이 없는 미적 중복
• 자동 테스트가 충분하고 안정적인 구식 코드
• 교체 비용이 현재 이자보다 훨씬 큰 의존성
• 관측 근거 없이 미래 확장만 예상한 추상화

다만 won't fix에는 이유와 전제를 기록한다.

status: accepted
decision: 지금은 해결하지 않는다.
reason:
  - 이 모듈은 신규 입력을 받지 않는다.
  - 변경 계획이 없고 외부 네트워크 권한도 없다.
assumptions:
  - 2027년까지 archive-only 상태를 유지한다.
reopen_if:
  - 새 데이터 입력을 다시 활성화한다.
  - 런타임 지원 종료가 발표된다.
review_on: 2027-01-15

전제가 깨지면 다시 열 수 있다. 영구히 눈에서 지우는 것과 의식적으로 수용하는 것은 다르다.

accepted debt도 보안 지원 종료와 데이터 보존 정책은 정기 점검한다. “안 건드리는 코드”가 외부 노출되어 있다면 변경 빈도와 무관하게 위험할 수 있다.

정기 검토에서 볼 지표

부채 장부의 항목 수가 늘거나 줄었다는 사실은 중요한 지표가 아니다. 잘게 쪼개면 늘고, 크게 뭉치면 줄어든다.

실제로 보고 싶은 것은 이자와 위험이다.

변경 효율

• 기능 lead time
• 같은 영역 수정 때 읽은 파일 수
• 수동 검증 단계 수
• 변경 실패율
• rollback 빈도

운영

• 반복 incident 수
• 탐지까지 걸린 시간
• 복구까지 걸린 시간
• 수동 intervention 횟수
• 가장 오래된 미처리 경고

안전

• 복구 훈련 성공과 실제 RPO/RTO
• 고위험 의존성 업데이트 지연
• 만료 예정 secret·인증서
• 권한이 과도한 service account
• 멱등성·원장 불변식 테스트 결과

인지 비용

• 작업을 시작하기 전 맥락 복원 시간
• 같은 운영 절차를 다시 검색한 횟수
• 미래의 나에게 설명할 수 없는 critical path 수
• runbook 없이 수동으로만 가능한 작업 수

매주 전부 측정할 필요는 없다. 실제로 자주 지불하는 비용 두세 개를 골라 추세를 본다.

기술 부채 해결이 기능 속도를 높였는지도 시간이 지나 확인한다. 사전·사후 비교가 없으면 좋아진 느낌만 남는다.

흔히 실패하는 우선순위 방식

가장 보기 싫은 코드부터 고친다

개발자 만족도는 올라가지만 사용자 위험과 로드맵을 놓칠 수 있다. 불편함을 증상과 실제 반복 비용으로 번역해 본다.

가장 쉬운 TODO부터 닫는다

목록은 줄지만 큰 위험은 계속 남는다. 작은 quick win과 high-risk mitigation을 함께 배치한다.

프레임워크 전체를 다시 쓴다

기존 동작의 암묵적 규칙과 운영 도구를 잃고 새 부채를 만든다. 교체 목표, 전환 단위, rollback, 이중 운영 종료 조건이 없으면 rewrite 자체가 부채다.

장애가 난 부분만 patch한다

직접 원인 한 줄만 고치고 탐지, 테스트, rollback, runbook을 남기지 않으면 비슷한 사고가 반복된다. 장애 대응 Runbook에 들어가야 할 내용처럼 복구 능력도 산출물로 본다.

완벽한 아키텍처를 먼저 만든다

아직 검증되지 않은 확장 가능성을 위해 추상화를 늘리면 오늘의 변경 비용만 커질 수 있다. 두세 개의 실제 변형이 생긴 뒤 공통점을 추출한다.

부채를 개인 실패로 본다

빠른 시장 검증을 위해 의도적으로 지름길을 선택하는 것은 합리적일 수 있다. 문제는 상환 조건과 관측이 없는 것이다. 비난보다 결정의 맥락과 만료 조건을 기록한다.

목록만 만들고 재검토하지 않는다

오래된 항목은 전제가 바뀌고 중복된다. review_on과 archive 규칙이 없으면 장부 자체가 부채가 된다.

실전 의사결정 예시

한 주에 다음 세 작업 후보가 있다고 하자.

A. 검색 코드의 중복 mapper 제거 — 4시간
B. 주문 백업 복구 리허설 — 3시간
C. 관리자 페이지 디자인 시스템 정리 — 8시간

겉보기에는 A가 가장 개발다운 개선이고 C가 가장 눈에 잘 보인다. 하지만 맥락을 붙이면 판단이 달라진다.

A: 검색 중복 mapper

impact: 2
likelihood: 4
change_friction: 5
recovery_difficulty: 2
effort: 2
roadmap_contact: 다음 주 검색 필터 추가

반복 이자가 크고 곧 해당 코드를 만난다. 다음 검색 기능의 선행 단계로 처리할 가치가 높다.

B: 백업 복구 리허설

risk_gate: true
impact: 5
likelihood: 2
recovery_difficulty: 5
effort: 2

발생 빈도는 낮아도 복구 불가능 위험이다. 점수 경쟁 없이 먼저 예약한다.

C: 관리자 디자인 시스템

impact: 1
likelihood: 2
change_friction: 2
recovery_difficulty: 1
effort: 4
roadmap_contact: 없음

현재 사용자 영향과 로드맵 접점이 작다. UI 기능을 다시 만들 때 일부 토큰부터 추출하고 지금은 보류한다.

따라서 일정은 다음처럼 잡을 수 있다.

월요일 오전: B 복구 리허설과 결과 기록
화요일: A characterization test와 mapper 통합
수요일 이후: 검색 필터 기능
C: accepted debt로 기록, 관리자 개편 시 재검토

여기에 긴급 기능이 들어오면 B 전체를 못 하더라도 읽기 전용 복구 절차 검증, 권한 확인, 예상 RTO 측정 같은 최소 완화를 먼저 할 수 있다.

이 예시의 핵심은 완벽한 점수를 계산한 것이 아니다. 치명적 위험, 반복 이자, 가까운 변경 접점, 해결 비용을 서로 다른 질문으로 본 것이다.

정리

1인 개발에서 기술 부채를 전부 갚는 것은 불가능하고 그럴 필요도 없다. 필요한 것은 어떤 부채가 실제로 이자를 만들고, 어느 시점에 가장 싸게 줄일 수 있는지 판단하는 체계다.

원칙을 정리하면 다음과 같다.

1. 오래됐거나 보기 싫다는 이유만으로 기술 부채라고 부르지 않는다.
2. 미래 변경과 운영에 반복 비용을 만드는지 증상과 근거로 기록한다.
3. 데이터 손실·보안·법적·복구 불가능 위험은 일반 점수표 밖에서 먼저 처리한다.
4. 영향도, 발생 가능성, 변경 마찰, 복구 난이도, 해결 비용을 따로 본다.
5. 점수는 비교 힌트로만 사용하고 의사결정을 자동화하지 않는다.
6. 다음 로드맵과 맞닿는 부채를 선행·동반 작업으로 연결한다.
7. 큰 리팩터링을 테스트, seam, migration, rollout 같은 작은 위험 감소 단위로 나눈다.
8. 남는 시간이 아니라 반복 일정에 부채 예산을 넣는다.
9. 완료 조건을 코드 모양이 아니라 장애·변경 시간·복구 가능성의 개선으로 쓴다.
10. 미루는 부채도 이유, 전제, 다시 열 조건, 재검토 날짜를 기록한다.
11. 장부 항목 수보다 실제로 지불한 이자와 운영 위험의 추세를 본다.

기술 부채 관리의 목표는 저장소를 완벽하게 깨끗하게 만드는 것이 아니다. 다음으로 중요한 변화를 더 빠르고 안전하게 만들 수 있는 상태를 유지하는 것이다.

관련 노트

• Circuit Breaker로 연쇄 장애 줄이기
• Feature Flag로 배포와 출시 분리하기
• 장애 대응 Runbook에 들어가야 할 내용
• 백업이 아니라 복구를 테스트해야 하는 이유
• RPO와 RTO로 복구 목표 정하기
• CasaTrade 배치와 API가 도메인 로직을 공유하게 만들기
• 레거시 코드에 Characterization Test 추가하기
• Tech Blog Revival