사례 01 · 주요 사례
우리 것이 아닌 시스템 위에서 개발하기
- 운영 중
여러 역할이 얽힌 예약·주문 플랫폼을 대기업 고객의 오래된 ERP 위에서 운영에 올렸습니다. 인터페이스 계약은 고객사 엔지니어와 직접 정했고, 범위 변경은 모두 개발에 들어가기 전에 서면으로 승인받았습니다.
- 역할
- Lead Developer
- 역량
- 요구사항 파악 · 시스템 연동 · 이해관계자 조율
- 영역
- 기업용 예약·주문 플랫폼
- 연동 대상
- 고객사의 오래된 ERP, 합의된 인터페이스 계약을 통해
배경
한 소프트웨어 회사의 납품팀에서 대기업 고객을 위한 예약·현장 주문 플랫폼을 만들고 있었습니다. 고객사에는 자체 엔지니어 팀과 오래된 ERP가 있었고, 고객 데이터는 그쪽에 있었습니다. 1차 버전은 이미 있었지만 충분하지 않았고, 이 소프트웨어 회사는 2차 버전을 "재사용할 수 있고 되팔 수 있는 첫 제품"으로 만들고자 했습니다 —— 그래서 이 건이 저에게 왔습니다.
과제와 불분명했던 점
고객사는 두 방향에서 연동하고 있었습니다: 유지보수와 템플릿을 위한 화면, 그리고 실제 업무를 담당하는 API 면 —— 주문, 취소, 일정. 즉 계약이 양방향으로 정확히 맞아야 했습니다. 게다가 고객사는 우리가 그 기준으로 개발하고 있는 바로 그 시점에 자기 쪽 업무 로직을 아직 정하고 있었습니다: "주문 한 건"이 무엇인지 정의하는 데만 몇 주가 걸렸습니다. 소재는 늦게 도착했고, 지연의 책임은 관계자들 사이를 오갔으며, 사양은 불완전한 채로 개발에 들어왔습니다.
내 역할
Lead Developer로서 백엔드와 클라우드 납품을 맡고, 프론트엔드/백엔드/클라우드의 분담을 조율했습니다. 인터페이스 계약은 고객사 엔지니어와 직접 협의했습니다. 고객 대면 클라이언트에서는 복잡하고 계약을 정하는 흐름을 제가 직접 만들고 단순한 화면은 넘겼으며, 화면이 계약과 맞지 않는 부분은 제가 고쳤습니다. 프론트엔드 엔지니어 두 명을 멘토링했습니다. 1차 버전은 아키텍트가 제공한 것이고, 2차 버전에서 그의 관여는 가벼웠으며 클라우드 설정 일부만 담당했습니다 —— 그것은 제 일이 아니었습니다.
요구사항 파악
요구는 PM을 통해 전달되었고, 분류와 분해는 제가 했습니다. 고객사와는 주 몇 회, 내부는 매일 스탠드업이었습니다. 이 프로젝트를 실제로 구한 것은 도구가 아니라 절차였습니다: 현행 업무를 문서로 만들고, 새 흐름을 그리고, 이해관계자와 함께 확인하고, 개발 착수 전에 서면으로 합의하는 것. 대외적으로는 "속도를 위험에 빠뜨리지 않기 위해"라고 설명했지, "개발이 움직이려 하지 않는다"가 아니었습니다.
설계와 트레이드오프
고객 데이터는 고객사 쪽에 두고, 플랫폼은 익명화된 형태로 주문 흐름만 다뤘습니다 —— 보관하는 데이터가 하나 줄면 협의할 일도 하나 줍니다. "주문"의 정의가 아직 움직이고 있었으므로 개발 순서를 그것을 축으로 짰습니다: 승인이 필요 없는 부분을 먼저 다 끝내고, 마지막에 바뀔 부분만 떼어 두는 것 —— 이렇게 하니 고객에게는 시간이 생기고 팀은 놀지 않았습니다. 또 클라이언트가 직접 이어 붙이던 생성/수정/삭제 연속 호출을 하나의 백엔드 엔드포인트로 합쳤습니다: 업무 로직을 서버로 되돌리고, 한 번의 왕복으로 화면이 실제로 필요로 하는 형태를 돌려줍니다.
구현과 연동
예약, 현장 주문, 주방 자원 관리, 좌석과 위치 관리, QR 스캔. 여러 운영 역할에 걸쳐 있습니다. 고객 대면 클라이언트는 Vue 3이며, 그것이 사용하는 백엔드와 함께 개발했습니다. 고객사의 오래된 ERP와는 합의된 인터페이스 계약을 통해 연동합니다.
운영 단계의 장치
플랫폼은 24시간 돌아갑니다 —— 예약 시스템은 언제든 접수할 수 있어야 합니다. 운영 리듬은 의도적으로 이렇게 설계했습니다: 사람이 처리해야 하는 일은 모두 근무 시간 안에 들어오도록. 당일 예약은 첫 손님이 오기 전에 확정하고, 다음 회차는 점심에 배포하며, 마감 후에는 누군가 지켜봐야 할 것이 남지 않게. 시스템 중단은 메일로 알립니다. 다음 날 예약이 문제없이 돌아가도록 백업과 마감 처리는 제가 퇴근 후에 남아 돌렸습니다.
결과
플랫폼은 운영에 올라가 대체 대상이던 옛 시스템을 대신했고, 고객의 일상 운영을 지탱합니다. 세 개의 운영 역할이 각자의 대시보드로 일하고 있습니다.
가져갈 수 있는 배움
고객이 아직 자기 업무 규칙을 정하고 있는 단계에서, 개발 쪽의 일은 기다리는 것도 추측하는 것도 아닙니다 —— 아직 정해지지 않은 부분을 마지막에 건드리도록 순서를 다시 짜고, 그 결정을 충분히 보이게 만들어서 승인하는 일이 "약속"이 아니라 "진척"으로 느껴지게 하는 것입니다.
공개할 수 있는 근거
위에 적은 것이 공개해서 말할 수 있는 범위입니다. 아래는 비공개인 것과 준비 중인 것입니다:
Charlie의 보완 필요 —— 익명화한 구조도 한 장이면 이 사례는 성립합니다. 목업 ERP와 어댑터 계층을 쓴 클린룸 재현은 포트폴리오 항목 P5로 계획되어 있으며 아직 만들지 않았습니다.
답변은 이 사이트에 적힌 내용을 근거로 합니다. 할 가치가 없는 일이라면 그렇게 답합니다.