왜 큰 피처를 만들지 않았나

전환기가 예정된 시스템에서는 “무엇을 만들 것인가”보다 “무엇을 만들지 않을 것인가”가 더 중요한 판단이 된다. 당시 로컬 플랫폼에는 개선하고 싶은 지점도 많았고, 비즈니스 관점에서 당장 눈에 띄는 기능 요청도 존재했다. 하지만 글로벌 마이그레이션이 현실적인 일정 안에 들어와 있는 상황에서, 모든 요청을 기존 플랫폼 위에 구현하는 선택은 장기적으로 더 큰 비용이 될 수 있었다.

이 글은 그래서 하지 않은 결정에 대해 남긴 기록이다. 큰 피처를 만들지 않기로 한 판단은 소극적인 태도가 아니라, 제한된 시간과 인력을 어디에 써야 하는지에 대한 운영 전략이었다. 이 판단의 논리와 예외 조건, 그리고 이해관계자와 어떤 언어로 합의를 만들어 갔는지를 정리해 두고 싶었다.

당시 한국 로컬 커머스 플랫폼은 여전히 비즈니스를 떠받치고 있었지만, 동시에 글로벌 플랫폼으로 흡수될 미래가 예정되어 있었다. 이 상황에서 큰 기능을 새로 구현하면, 짧은 시간 안에 비용을 회수해야 하고, 그렇지 못하면 마이그레이션 시점에 그대로 폐기 비용으로 남게 된다. 문제는 이 논리가 기술팀 안에서는 비교적 자명하지만, 기능을 원하는 입장에서는 언제나 설득이 필요한 이야기였다는 점이다.

더 까다로웠던 건 모든 요청을 일괄적으로 거절할 수는 없었다는 사실이다. 커머스 운영은 매출, 법적 의무, 보안 대응과 직결되기 때문에, 어떤 변경은 “새 기능”처럼 보여도 실제로는 반드시 해야 하는 작업이었다. 결국 핵심은 기능의 크기가 아니라, 그 변경이 전환기 시스템에서 어떤 가치를 남기는지 판단하는 기준을 세우는 일이었다.

전략의 핵심 논리

가장 기본적인 판단 기준은 단순했다. 전환 시점이 가까운 플랫폼에 대규모 기능을 넣어도, 그 기능이 마이그레이션 이후 재사용되지 않는다면 투자 회수 기간이 너무 짧다. 반대로 같은 시간과 인력을 운영 안정화, 구조 이해, 전환 준비에 투입하면 그 결과는 이후 작업에도 남는다. 그래서 의사결정의 중심은 “지금 만들 수 있느냐”가 아니라 “마이그레이션 이후에도 가치가 남느냐”였다.

이 논리를 분명히 해두니 기능 요청을 볼 때도 기준이 생겼다. 당장 화려해 보이는 기능이라도 전환기에 단기 소비성으로 끝나는 항목은 우선순위를 낮췄다. 반대로 당장 눈에 띄지 않더라도 운영 리스크를 줄이거나, 전환에 필요한 시스템 이해를 높이거나, 장애 가능성을 낮추는 변경이라면 더 높은 우선순위를 받을 수 있었다. 하지 않는 결정은 결국 “가치의 지속성”을 기준으로 한 선택이었다.

이해관계자와의 대화

이 판단을 실제로 유지하려면 비기술 이해관계자와의 대화 방식도 달라야 했다. 단순히 “곧 없어질 플랫폼이라 안 된다”라고 말하면, 듣는 입장에서는 기술 조직이 비즈니스 요구를 회피하는 것처럼 보일 수 있다. 그래서 효과적이었던 설명은 기술적 이유보다 투자 대비 효과, 운영 리스크, 전환 이후 중복 비용 관점에서 이야기하는 방식이었다.

의사결정 루프

예를 들어 같은 개발 기간을 기존 플랫폼의 기능 추가에 쓰는 것과, 전환 준비를 위한 구조 정리와 운영 안정화에 쓰는 것을 비교하면 무엇이 더 오래 남는지 설명해야 했다. 이 대화는 단순히 거절을 통보하는 자리가 아니라, 전환기 시스템에서 어떤 선택이 전체적으로 더 합리적인지 함께 맞추는 과정이었다. 결국 중요한 것은 기능 하나를 안 만드는 것이 아니라, 조직이 같은 우선순위 프레임을 공유하게 만드는 일이었다.

실제로 수행한 것과 하지 않은 것

물론 “큰 피처를 만들지 않는다”는 원칙은 아무것도 하지 않는다는 뜻이 아니었다. 운영 안정성을 지키기 위한 수정, 법적 의무를 충족하기 위한 변경, 보안 취약점 대응, 직접적인 매출 영향이 있는 문제 해결은 계속 진행해야 했다. 중요한 것은 이를 새로운 제품 확장과 구분하는 것이었다. 전자는 전환기 시스템을 안전하게 유지하기 위한 비용이고, 후자는 미래가 짧은 플랫폼에 장기 자산을 새로 얹는 일에 가까웠다.

실무에서는 이 경계가 늘 깔끔하지 않았다. 어떤 요청은 작은 수정처럼 시작하지만 실제로는 새로운 운영 복잡도를 만들었고, 어떤 요청은 기능처럼 보여도 법적 또는 비즈니스상 미룰 수 없는 항목이었다. 그래서 원칙만 세워두고 끝낼 수는 없었고, 요청이 들어올 때마다 이 변경이 전환기 운영 안정화에 속하는지, 아니면 단기성 기능 투자에 가까운지 계속 분류해야 했다.

이 결정의 결과

결과적으로 큰 피처를 자제한 판단은 플랫폼의 확장성을 희생한 대신, 전환기 동안 중요한 것에 더 많은 에너지를 쓸 수 있게 했다. 운영 구조를 더 깊이 이해하고, 장애 대응 체계를 다듬고, 배포 리듬을 안정화하고, 이후 글로벌 전환을 준비하는 데 필요한 지식을 쌓는 데 시간을 쓸 수 있었다. 전환기 플랫폼에서 이 균형은 생각보다 중요했다. 무엇이든 만들 수 있다는 자신감보다, 무엇을 만들지 않아야 하는지 아는 절제가 더 큰 안정성을 줬기 때문이다.

이 판단은 다음 글들과도 직접 연결된다. 왜 시스템 경계를 먼저 파악해야 했는지, 왜 정기 배포 체계가 중요했는지, 왜 보안 패치나 법적 요구 대응이 예외 없이 우선순위를 가졌는지 모두 같은 프레임 위에 놓여 있었다. 다음 글에서는 그 판단의 전제가 되었던 시스템 경계 파악을 더 구체적으로 다룬다.

전략 선택의 장단점

큰 피처를 보류한 전략의 장점은 팀의 실행력을 “전환에 필요한 핵심 작업”에 집중시킬 수 있다는 점이다. 운영 안정화, 배포 품질, 보안 대응, 데이터 경계 정의 같은 기반 작업은 눈에 덜 띄지만 컷오버 성공 확률을 직접 높인다.

단점은 단기 성과를 설명하기 어렵다는 점이다. 기능 출시가 줄어들면 외부에서는 정체처럼 보일 수 있다. 그래서 이 전략은 기술 선택만으로 끝나지 않고, 왜 지금은 기반 작업이 우선인지 이해관계자와 지속적으로 합의하는 커뮤니케이션이 함께 필요했다.

기능 요청 분류표

기술 체크포인트

• 기능 요청은 지속 가치 기준(전환 후 재사용 가능성)으로 분류했다.
• 예외 항목(보안/법적 의무/직접 매출 영향)은 별도 우선순위로 처리했다.
• 우선순위 결정 근거를 운영/비즈니스 언어로 설명해 합의 비용을 낮췄다.