Show Cover Slide

Expiry-Ready 개발 방법 주장: 스타트업을 위한 지식관리 최소화 전략

서문: Expiry-Ready란 무엇인가?

더 좋은 코드에게 자리를 양보하도록 준비하자

삭제 준비된 코드는 단순히 삭제될 코드를 의미하는 것이 아닙니다.
이는 보관 후 필요 시 삭제하거나 이관할 준비가 된 코드를 의미합니다.
Expiry-Ready는 코드나 시스템이 필요 없어졌을 때, 즉시 삭제되거나 이전될 준비가 되어 있어야 한다는 철학을 담고 있습니다.
이를 즉시 삭제하거나 이관할 수 있도록 미리 준비하는 설계 철학입니다.

Expiry-Ready의 의미:
삭제 준비된 코드는 더 이상 사용되지 않거나, 더 이상 활성화할 필요가 없는 기능에 대해 명확히 준비된 상태를 의미합니다.

만료보다는 삭제라는 표현을 사용하는 이유는, 단순히 시간이 지나 사라지는 것이 아니라, 의도적 판단과 실행을 수반하는 행위로 바라보기 위함입니다.

이는 삭제 가능성을 염두에 두고 설계된 코드로, 기능을 제거하거나 시스템에서 제외할 때 필요한 정보(Owner, Purpose, Expiry Condition 등)를 미리 기록하고 준비하는 과정입니다.

Expiry-Ready는 단순한 “삭제”가 아니라, 필요하지 않은 코드나 기능을 효율적으로 정리하고, 기술 부채(Technical Debt)와 소프트웨어 로트(Software Rot)의 위험을 줄이기 위한 선제적 관리 방법입니다.

I. 시작하며: 스타트업이 반드시 마주하는 개발 리스크

스타트업은 빠르게 만들고, 빠르게 검증해야 합니다.
하지만 그 과정에서 관리되지 않는 코드, 실험 후 방치된 기능, 기억나지 않는 레포지터리가 쌓입니다.
이것은 시간이 지날수록 다음과 같은 심각한 문제로 발전합니다:

• 기술 부채(Technical Debt)
• 소프트웨어 부패(Software Rot)
• 시스템 복잡성 증가
• 유지보수 비용 폭발

이 글에서는 불필요한 지식과 관리를 최소화하고, 더 나은 코드 설계를 통해 구조적으로 예방하는 방법을 제시합니다.
그리고 그 핵심은 바로 Expiry-Ready 개발론입니다.

“만드는 것보다, 덜어내는 용기가 스타트업을 지킨다.”

II. Expiry-Ready 철학: 우리는 왜 코드를 삭제 준비해야 하는가?

개발 문화는 코드에서 시작되지 않습니다

개발 문화는 도구나 프로세스에서 시작되지 않습니다.
조직의 사고방식, 리더십의 기준, 그리고 팀이 공유하는 기술 철학에서 출발합니다.

그리고 우리의 철학은 명확합니다:

“코드는 언제든 삭제될 수 있어야 한다.”

설계는 기술의 문제가 아니라, 기준의 문제입니다

설계의 출발은 어떤 기술을 쓰느냐가 아니라,
기준을 세우고, 시스템을 어떻게 구성하고, 필요 없을 때 무엇을 제거할지를 고민하는 과정입니다.

• 무엇을 중심으로 시스템을 나눌 것인가
• 기능을 어떻게 구분하고 책임을 정의할 것인가
• 어떤 구조가 우리에게 유연성을 줄 것인가

기준이 명확한 팀은 “만드는 것” 뿐만 아니라
“걷어내는 것” 까지도 함께 설계합니다.

애자일은 실험하고 삭제할 수 있어야 완성됩니다

애자일은 Jira나 스프린트 같은 도구가 아닙니다.
애자일의 본질은 검증과 학습의 속도입니다.

• 고객이 원하는 가치를 얼마나 빨리 검증하는가
• 실패했을 때 얼마나 빠르게 걷어낼 수 있는가

진짜 애자일은
삭제 준비(Expiry-Ready)된 설계 없이는 불가능합니다.

“실패는 축적하는 것이 아니라, 삭제하고 학습하는 것이다.”

III. Expiry-Ready 구조: 살아 있는 시스템을 만들기

삭제 준비(Expiry-Ready)된 구조란 무엇인가?

모든 코드는 언젠가 사라집니다.
중요한 것은 그것을 예상하고 만드는가의 여부입니다.

우리는 이렇게 설계합니다:

• 코드의 수명을 가정하며 만든다
• 유효기간이 짧은 코드는 격리한다
• 오래가는 코드는 구조화한다

삭제 준비(Expiry-Ready)된 구조는 다음과 같은 원칙을 따릅니다:

작은 성공 경험

우리는 간단한 유틸리티로 시작한 코드가,

• 반복 사용을 통해 독립 모듈로 성장하고,
• 필요 없는 부분은 깨끗하게 제거되어,
• 전체 시스템은 더 단순해지는 경험을 여러 번 했습니다.

이 경험은 우리에게 확신을 주었습니다.

“삭제 준비된 구조가 살아 있는 시스템을 만든다.”

IV. Expiry-Ready 실천 방법

생성 시점에 기록을 남깁니다

코드나 레포지터리를 만들 때, 다음을 반드시 기록합니다:

• Owner: 이 코드/레포의 책임자는 누구인가?
• Purpose: 이 코드/레포가 존재하는 이유는 무엇인가?
• Expiry Condition: 이 코드/레포는 언제 폐기될 수 있는가?
• (선택) Dependency: 어디에 연결되어 있는가?
• (선택) Change History: 주요 변경 이력은 무엇인가?

작성의 목적은 단순히 문서화를 위한 것이 아닙니다.
“삭제 가능성”을 기록하기 위해서입니다.

관리되지 않는 조짐을 감지합니다

시간이 지나면서 Owner의 활동이 급격히 줄어들면,
해당 코드/레포는 Unmaintained(방치 상태) 에 가까워집니다.

우리는 다음을 주기적으로 모니터링합니다:

• 최근 1달 커밋 수
• 이전 1달 커밋 수

눈에 띄는 감소가 감지되면, 삭제 준비 기록(Expiry-Ready Record)을 작성합니다.

삭제 준비 기록(Expiry-Ready Record)을 남깁니다

• 삭제 가능성, 만료 조건을 명확히 문서화합니다.
• 중앙 시스템(예: GitHub Issue, Notion, 전용 레포)에 보관합니다.
• 나중에 삭제/이관/보존을 판단할 때 참고합니다.

“삭제는 감이 아니라 기록으로 판단한다.”

V. 삭제를 문화로 만든다

삭제는 리팩터링(Refactoring)이 아니라, 책임 종료입니다

삭제는 단순한 코드 정리가 아닙니다.
기능이나 코드가 더 이상 필요하지 않다고 팀이 명확히 결정하고, 이를 체계적으로 실행하는 과정입니다.

리팩터링은 기능을 유지한 채 내부 구조를 개선하는 작업이라면, 삭제는 그 기능 자체가 더 이상 필요 없음을 선언하는 결정입니다.
이는 책임의 종료이자, 시스템 경계를 재정의하는 행위입니다.

삭제는 팀이 명시적으로 선언하는 것입니다:

“이 기능은 더 이상 우리 시스템의 일부가 아니다.”

삭제는 다음을 의미합니다:

• 기술적 부채를 제거하는 것
• 관리할 지식의 양을 줄이는 것
• 시스템의 복잡성을 덜어내는 것

삭제를 문화로 실천합니다

우리는 삭제를 일상적 개발 프로세스에 다음과 같이 녹입니다:

• 코드 리뷰에서 “이건 나중에 지울 수 있나요?”를 질문합니다.
• temporary-, experimental- 같은 네이밍으로 삭제 의도를 명시합니다.
• 삭제 LOC(Line of Code), 폐기된 모듈 수를 KPI로 관리합니다.
• 매 분기 잘 삭제한 사례 를 회고하고 공유합니다.

실패를 남기지 않습니다

우리는 실험이 실패했을 때, 이렇게 자문합니다:

“이 기능은 실패했을 때 깔끔히 걷어낼 준비가 되어 있는가?”

답할 수 없다면, 실험을 시작하지 않습니다.

VI. 학습과 전파: 지식 관리 최소화 전략

지식 관리 최소화 원칙

우리는 팀이 기억에 의존하지 않도록 시스템을 설계합니다.
이를 위해 다음과 같은 원칙을 따릅니다:

• 설계는 구두가 아니라 기록으로 설명합니다.
• 반복되는 질문은 지식 베이스에 정리합니다.
• 실험은 문서화하고, 삭제는 히스토리로 남깁니다.

실험과 삭제를 모두 기록합니다

• 실험 기능은 Notion, GitHub Discussions 등에 배경과 결과를 기록합니다.
• 삭제된 기능은 “왜 삭제했는가”를 명확히 남깁니다.
• 재요구가 발생할 때, 과거 의사결정의 근거로 활용합니다.

신입에게 가르치는 첫 번째 원칙

신입 팀원에게는 코딩 규칙보다 먼저 이렇게 가르칩니다:

“작성 원칙”보다, “삭제 설계 원칙”을 먼저 배워야 한다.

• 기능은 항상 유효기간을 상상하며 작성합니다.
• 시스템은 지속가능성을 최우선 가치로 둡니다.

반복해서 되새기는 질문

• 이 기능은 언제 없어질 수 있는가?
• 실패할 경우, 어떻게 폐기할 수 있는가?
• 다른 서비스에 주는 영향은 없는가?

이 질문을 통해 우리는 설계 자체의 수명을 함께 고민합니다.

VII. 철학으로 되새긴다

우리는 코드를 삭제할 수 있도록 설계합니다.
우리는 언제나 덜어낼 수 있는 구조를 우선합니다.
이는 단순한 기술 방법론이 아니라, 우리의 기술 철학이자 팀의 정체성입니다.

“살아남는 코드는, 삭제될 준비가 끝난 코드다.”

그리고 이 철학은 우리 팀의 설계를 결정짓고,
개발 문화를 만들어갑니다.

우리는 코드를 더 많이 만드는 것보다,
더 잘 덜어내는 용기를 먼저 배웁니다.

시스템이 성장할수록,
팀이 성장할수록,
우리는 이 질문을 반복합니다:

“지금 이 코드, 이 구조는 삭제될 준비가 되어 있는가?”

만들고, 실험하고, 걷어내는 흐름 속에서
스타트업은 살아 있고, 성장할 수 있습니다.

“삭제는 시스템을 정리하는 것이 아니라, 팀의 책임을 정리하는 일이다.”