40대 개발자가 기술 부채를 정리하는 순서 — 배울 것·버릴 것·남길 것

경력이 쌓일수록 배워야 할 기술이 줄어들 것 같지만 실제로는 반대였습니다. 플랫폼은 계속 바뀌고, 예전에 선택한 라이브러리는 지원 종료를 맞습니다. 새로운 것을 배우는 일과 오래된 것을 정리하는 일이 동시에 들어옵니다.

저는 이 문제를 ‘무엇을 더 공부할까’가 아니라 ‘무엇을 계속 들고 갈까’라는 질문으로 바꿔 보았습니다. 이번 글은 특정 기술을 버리라는 조언이 아니라, 개인 서비스와 커리어에서 우선순위를 정하는 방법입니다.

기술 부채는 오래된 코드와 같은 말이 아닙니다

오래되었다는 이유만으로 부채가 되는 것은 아닙니다. 오래된 코드라도 장애가 없고 수정 경로를 모두 알고 있다면 위험이 낮을 수 있습니다. 반대로 최신 라이브러리라도 팀이 이해하지 못하고 배포 때마다 불안하다면 부채가 됩니다.

제가 쓰는 기준은 세 가지입니다. 고장 났을 때 복구할 수 있는가, 수정할 사람이 남아 있는가, 다음 변경을 막고 있는가입니다. 이 질문에 연속으로 ‘아니오’가 나오면 버전보다 먼저 부채 목록에 올립니다.

• 복구 가능성: 문제 발생 시 로그·백업·롤백 경로가 있는지 봅니다.
• 지식의 분산: 특정 사람의 기억에만 의존하는 부분인지 확인합니다.
• 변경 비용: 작은 요구사항에도 여러 계층을 건드려야 하는지 살핍니다.

배울 것과 고칠 것을 같은 목록에 넣지 않습니다

새 기술을 배우는 일은 미래 선택지를 넓히지만, 기술 부채를 고치는 일은 현재의 위험을 낮춥니다. 두 작업을 한 목록에 넣으면 흥미로운 학습이 항상 앞서고, 지루한 정리가 뒤로 밀립니다. 그래서 저는 ‘이번 분기 서비스 위험’과 ‘개인 학습’ 목록을 분리합니다.

예를 들어 .NET 11이 프리뷰라면 새 기능을 바로 운영에 넣기보다 별도의 실험 프로젝트에서 빌드와 테스트를 확인합니다. 서비스에 필요한 안정화 작업과 학습을 같은 배포에 섞지 않는 것이 중요합니다.

질문배울 후보먼저 고칠 부채

지금 서비스에 필요한가	새 기능·성능 개선	장애·보안·백업
실험 격리가 가능한가	프리뷰·새 도구	공용 런타임·데이터
실패했을 때 되돌릴 수 있는가	독립 모듈	배포 파이프라인

버릴 기술은 사용 중단 계획까지 써야 합니다

‘이제 이 기술을 쓰지 않겠다’는 선언만으로는 아무것도 바뀌지 않습니다. 어떤 화면과 데이터가 의존하는지, 대체 기술은 무엇인지, 언제 삭제할지를 적어야 합니다. 삭제보다 더 어려운 것은 기존 사용자를 안전하게 옮기는 일이기 때문입니다.

저는 부채 항목마다 유지·격리·교체·폐기 중 하나를 고릅니다. 유지라면 문서와 테스트를 보강하고, 격리라면 경계를 만들며, 교체라면 작은 경로부터 옮깁니다. 폐기는 백업과 복구 확인 뒤에만 진행합니다.

• 유지: 위험이 낮고 대체 비용이 더 큰 기술입니다.
• 격리: 당장은 필요하지만 새 코드로 번지지 않게 경계를 둘 기술입니다.
• 교체: 장애나 지원 종료 위험이 커서 단계적으로 옮길 기술입니다.
• 폐기: 사용 경로를 확인한 뒤 삭제와 복구 테스트까지 끝낼 기술입니다.

경력 후반에는 기술 이름보다 판단 기록이 자산입니다

40대 이후에는 새 도구의 개수로 경쟁하기 어렵습니다. 대신 왜 그 기술을 선택했고, 어떤 조건에서 바꿀지 설명할 수 있는 능력이 남습니다. 프로젝트마다 선택 이유와 포기한 대안을 간단히 기록하면 다음 팀이나 다음 서비스에서 재사용할 수 있습니다.

저는 매달 한 번 기술 부채 목록을 열어 위험도가 변했는지 확인합니다. 모두 해결하려고 하지 않고, 다음 한 달 동안 실제로 장애 가능성을 낮추는 한 항목만 고릅니다.

작게 시험하고 다음 주에 다시 봅니다

생활과 일의 문제는 한 번에 해결되지 않습니다. 저는 새 원칙을 정할 때 먼저 일주일 동안 확인할 수 있는 행동으로 줄입니다. 예를 들어 일거리의 범위를 정리한다면 모든 계약을 다시 쓰기보다, 이번 주에 들어온 요청 세 건을 같은 표에 기록해 봅니다. 창작 경계를 세우는 경우에도 하루 전체를 바꾸지 않고 알림을 끄는 시각 하나만 정합니다. 작은 실험은 실패했을 때 비용이 작고, 성공했을 때 무엇이 영향을 주었는지 설명하기 쉽습니다.

실험이 끝난 뒤에는 결과를 성과와 실패로만 나누지 않습니다. 예상보다 쉬웠던 점, 예상보다 오래 걸린 점, 다른 사람에게 설명하기 어려웠던 점을 적습니다. 이 기록이 있어야 다음 주에 같은 실수를 반복하지 않고 조건을 조정할 수 있습니다. 다른 사람의 조언을 참고하더라도 내 생활과 서비스의 제약을 먼저 적어야 합니다.

• 현재 상태: 지금 어떤 일이 반복되고 무엇이 가장 자주 막히는지 사실로 적습니다.
• 작은 실험: 일주일 안에 확인할 행동 하나와 하지 않을 행동 하나를 정합니다.
• 관찰 신호: 시간·체력·집중·요청 수처럼 실제로 기록할 수 있는 신호를 고릅니다.
• 다음 결정: 계속·축소·중단 중 하나를 다음 회고에서 선택합니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

기술 부채 정리는 최신 기술을 포기하는 일이 아니라, 내 시간과 서비스의 수명을 어디에 쓸지 결정하는 일입니다. 오늘 사용하는 기술을 유지·격리·교체·폐기 네 칸으로 나누고, 첫 번째 교체 후보의 롤백 조건부터 적어 보시기 바랍니다.

참고한 문서: .NET 11 공식 문서 · EF Core 11 변경 사항