넥시박스
저널
2026-04-22 · 회고 · 자동화 · 프로덕션

플랫폼 자동화 서비스 종료에서 배운 것들

프리랜서로 맡았던 한 플랫폼 자동화 프로젝트가 종료되면서 얻은 운영의 교훈. 그리고 그 경험이 지금 어디로 흘러갔는가.

1. 프로젝트 맥락

저는 2024년부터 2025년까지, 프리랜서 개발자로서 한 클라이언트의 네이버 플레이스 사업자를 위한 자동화 서비스를 구축·운영했습니다. 식당·카페·소상공인을 대상으로 리뷰 응답·재고 동기화·랭킹 모니터링을 자동화하는 서비스였습니다. 제 역할은 기술 파트너였고, 서비스 자체는 클라이언트 소유였습니다.

여러 계층의 자동화와 장기 운영이 한 시스템 안에서 맞물려 돌아가는 형태라 난이도가 낮은 프로젝트는 아니었습니다. 다만 세부 구현·기술 스택은 클라이언트 자산이라 본 글에서는 다루지 않습니다. 대신 프로젝트를 통해 제 쪽에 남은 세 가지 운영 교훈을 이야기하려 합니다.

2. 같은 요구, 다른 견적

프로젝트 시작 시점에 클라이언트는 두 곳의 다른 업체에서도 견적을 받았다고 들었습니다. 한 곳은 제가 제시한 비용의 약 2배를, 다른 한 곳은 약 3배의 구축 기간을 요구했습니다. 요구사항 자체는 동일했습니다. 차이는 어디에서 나왔을까요.

제가 먼저 한 일은 요구사항을 두 층으로 분리하는 것이었습니다. "반드시 달성해야 하는 비즈니스 결과"와 "그걸 달성하는 기술적 방법". 클라이언트는 전자에 대해서는 명확했지만, 후자에 대해서는 특정 고정관념이 있었습니다. 몇 번의 대화로 그 고정관념을 풀어내니 구현 경로가 훨씬 짧아졌습니다.

하나의 요구사항을 예로 들면, 클라이언트는 특정 작업을 매우 자주 수행해야 한다고 보고 있었습니다. 목적을 되짚어보니 실제로 필요한 건 훨씬 여유 있는 빈도였고, 도메인 패턴에 맞춘 맞춤 스케줄로도 충분했습니다. 결과적으로 인프라 소비가 큰 폭으로 줄었습니다. 같은 관점의 재해석이 프로젝트 전반에 걸쳐 반복됐습니다.

비용·기간 차이의 상당 부분은 이런 식으로 "대화를 통한 요구 재해석"에서 나왔습니다. 구현 능력보다, 요구사항을 함께 다듬는 과정이 가장 큰 레버리지였습니다.

3. 운영하면서 배운 세 가지

첫째, 관찰성은 처음부터 깔아야 한다. 시스템 내부 상태를 충분히 남기는 로깅·모니터링 체계를 처음부터 기본으로 넣었습니다. 초기엔 오버엔지니어링처럼 보였지만, 운영 중간에 무언가가 달라질 때 원인을 재현 가능한 상태로 추적할 수 있었던 유일한 수단이었습니다. 관찰성이 없었다면 맨눈으로 수백 번 시도하며 추측했을 겁니다.

둘째, 플랫폼 위에 짓는 서비스의 진짜 비용은 정책 변동 노출이다. 운영 중반부터 플랫폼의 신호가 조금씩 바뀌기 시작했습니다. 구현 레벨에서는 대응 가능했지만, 더 근본적으로는 서비스의 존립 자체가 플랫폼의 정책 결정에 종속된다는 의미였습니다. 코드는 언제든 고칠 수 있지만, 플랫폼 정책 변화는 고칠 수 없습니다.

셋째, 어려운 기술은 대화로 풀린다. 난이도가 높았던 부분은 대부분 "이 지점에서 무엇이 병목이 되고 있는가"를 클라이언트와 함께 살펴보면 의외로 해법이 열렸습니다. 이 프로젝트에서 가장 까다로웠던 요구사항도 결국 처음 합의한 예산과 기간 안에 완료했습니다. "어렵다"의 상당 부분은 "관점이 고정돼 있다"였습니다.

4. 종료, 그리고 전환

2025년 후반, 클라이언트 측 사정으로 서비스 운영이 중단되면서 저의 계약도 함께 마무리됐습니다. 서비스는 그 자체로 좋은 경험이었지만, 기술적 자산보다 더 크게 남은 건 방금 적은 세 가지 운영 교훈이었습니다.

그 직후 저는 NexyBox를 설립했습니다(2025년 11월). 이번에는 다른 방향이었습니다. 플랫폼 위에 서비스를 짓는 대신, 기업 내부의 반복 업무에 AI를 적용하는 방향으로 피봇했습니다. 오랫동안 프로덕션 환경에서 운영 품질을 다듬어온 경험은 그대로 "AI 고객응대 자동화" 상품으로, 관찰성·장기 운영 노하우는 "AI 사내봇" 구축과 공공 AI 도입 과제에 옮겨졌습니다.

플랫폼 정책 리스크는 기업 내부 자동화에는 없습니다. 대신 새로운 어려움(기업 문서 접근 권한, 한국어 프롬프트 평가, 비용 예측 등)이 있고, 그 어려움을 같은 방식으로 — 대화로 — 풀어가는 중입니다. 구축의 가장 큰 레버리지가 "요구 재해석"이라는 점은 그대로 남았습니다.

5. 닫는 한 줄

어려운 기술은 결국 대화로 풀리고, 플랫폼 위에 짓는 서비스의 가장 큰 비용은 정책 변동에 대한 노출입니다.

비슷한 종류의 AI 도입·자동화를 계획하고 계신다면 언제든 연락 주세요.

이런 회고가 더 필요하면 이메일로 알려드립니다.