정말 그 기능이 필요할까요? : 요구사항 너머의 진짜 고민

B2B 서비스를 만들다 보면, 고객사의 요구사항(VoC)은 단순한 '의견'을 넘어 프로젝트 전체를 뒤흔드는 거대한 파도로 다가올 때가 많습니다. 특히 대규모 고객사의 한 마디는 비즈니스 임팩트가 크기에, 우리 개발자들은 본능적으로 "어떻게 구현할까?"부터 고민하며 설계도를 펼치곤 하죠.

하지만 가끔은 잠시 멈춰서 물어야 합니다. "정말 그 기능이 최선일까?" 하고요.

---

1. "수개월이 걸릴 대형 프로젝트의 예감"

최근 현장 운영팀으로부터 긴급한 요구사항이 전달되었습니다. "고객사에서 워크스페이스 1개로 로봇을 여러 층(다층)에서 운영하고 싶어 합니다. 지금 구조로는 안 되니 신규 개발이 필요할 것 같아요."

층을 넘나들려면, 엘리베이터 제어 연동 작업에 작업 관리 및 명령에 관한 부분도 모두 추가 설계를 발생시키는 큰 작업으로 예상될 만큼 수개월이 걸릴 대형 프로젝트 느낌이였습니다.

---

2. 기술 이전에 '맥락'을 묻다

저는 무작정 개발을 시작하기 전에, 고객이 로봇을 사용하는 실제 시나리오를 집요하게 파헤쳐 보기로 했습니다. 과연 이 문제가 로봇들이 실시간으로 층을 넘나들며 작업해야 하는 복잡한 문제인가? 아니면 각 층이라는 독립된 공간에서 제 할 일을 잘하면 되는 문제인가?

직접 확인해 본 결과는 생각보다 단순했습니다. 로봇들이 여러 층을 동시에 쓰긴 하지만, 마치 '싱글 스레드'처럼 한 층에서 작업을 완전히 끝내고 다음 층으로 이동해 다시 시작하는 방식이었죠.

즉, 층간 데이터를 고려한 작업 관리 및 명령에 대한 거창한 시스템은 필요 없었습니다. 단순히 층별로 공간을 분리해 설정하는 가이드만 잘 제공한다면 신규 개발 없이도 요구사항을 완벽히 충족할 수 있었습니다. 수개월의 개발 리소스가 단 한 장의 '운영 가이드'로 대체된 순간이었습니다.

---

3. 요구사항은 '구현'이 아닌 '조율'의 대상입니다

고객의 요청에 밤을 새워 '검수 과정' 기능을 만들었지만, 정작 현장에서는 "작업 속도가 너무 느려진다"며 기능을 꺼두는 사례를 본 적이 있습니다. 의욕적으로 개발에 뛰어들었지만, 결과적으로는 누구에게도 도움이 되지 않는 기능을 만드느라 소중한 리소스를 낭비한 셈이죠.

개발은 단순히 코드를 짜는 행위가 아니라, 한정된 리소스를 투입해 어떤 가치를 만들어낼지 결정하는 트레이드 오프(Trade-off)의 과정입니다. 새로운 기능을 하나 더할 때마다 시스템의 복잡도는 올라가고, 우리는 그만큼의 유지보수 비용과 잠재적인 안정성 리스크를 감수해야 합니다.

그렇기에 엔지니어의 진짜 역할은 고객이 "A를 해달라"고 할 때 그 이면의 "왜?"를 묻고, 그 선택이 가져올 파급효과를 미리 짚어주는 것입니다. 고객사가 정말 원하는 가치가 무엇인지 함께 고민하며, 현재의 안정적인 서비스를 해치지 않는 선에서 최선의 해결책을 이끌어내고 조율하는 것. 그것이 진정으로 비즈니스 문제를 해결해 나가는 성숙한 엔지니어링 마인드가 아닐까 싶습니다.

때로는 화려한 신규 기능을 배포하는 것보다, 기존의 구조를 영리하게 활용해 시스템의 무게를 늘리지 않으면서도 고객의 가려운 곳을 긁어주었을 때 더 큰 성취감을 느낍니다. 기술적인 욕심보다는 서비스의 본질적인 안정성을 지키며 최적의 지점을 찾아가는 것, 그것이 제가 지향하는 가장 강력한 개발 전략입니다.