실시간 시스템 외주, 견적 전에 숫자로 정할 5가지 | 발주 기준

먼저 결론부터요. 실시간 시스템의 견적을 가르는 건 기능 개수가 아니라 숫자예요. 몇 초마다 갱신할지, 몇 초까지 늦어도 되는지, 끊겼을 때 화면에 뭘 띄울지를 정해두면 견적 편차가 크게 줄어요. 저희가 롯데백화점 수원 푸드홀 혼잡도 관리 시스템을 4개월간 만들며 배운 걸 기준으로 정리했어요. 직접 만들고 운영까지 해본 개발사 관점이에요.

“실시간으로 보이게만 해주시면 돼요.”

발주 상담에서 정말 자주 나오는 문장이에요. 말하는 쪽에서는 요구가 간단하다고 생각하시는데, 받는 쪽에서는 여기서부터 견적이 갈려요. 같은 문장을 듣고 어떤 개발사는 30초마다 새로고침하는 화면을 떠올리고, 어떤 곳은 센서에서 초 단위로 올라오는 데이터를 상상하거든요. 비용은 두세 배 차이가 나요.

---

1. ‘실시간’이라는 말이 왜 견적을 흔들까요

같은 단어를 서로 다른 시스템으로 이해하기 때문이에요.

소프트웨어 개발 외주에서 견적이 벌어지는 항목은 대개 정해져 있어요. 기능 수, 디자인 방식, 연동 대상 같은 것들이죠. 그런데 실시간이 붙으면 성격이 달라져요. 기능 목록은 그대로인데 뒤에 깔리는 구조가 통째로 바뀌기 때문이에요.

화면에 숫자 하나를 띄우는 일도 그래요. 30초마다 갱신하면 서버가 가끔 물어보면 끝나는 일이에요. 1초마다 갱신하려면 연결을 계속 열어두거나 밀어주는 구조가 필요하고, 접속자가 늘면 서버도 함께 늘어나요. 유지보수 난이도도 다르고요.

그래서 실시간 시스템의 외주개발 견적을 비교하시려면 기능 목록보다 먼저 맞춰야 할 게 있어요. 숫자예요.

2. 견적 전에 숫자로 정할 5가지는 무엇인가요

아래 다섯 개를 정하시면 견적 편차의 대부분이 사라져요.

1. 갱신 주기 — 화면 값이 몇 초마다 바뀌어야 하나요. 1초, 5초, 30초, 1분 중 어디인지만 정해도 구조가 정해져요.
2. 허용 지연 — 실제로 일어난 일이 화면에 뜰 때까지 몇 초까지 늦어도 되나요. 사람이 보는 화면과 자동으로 제어가 걸리는 화면은 기준이 완전히 달라요.
3. 동시 접속과 데이터 발생량 — 몇 명이 동시에 보고, 센서나 장비가 몇 대에서 얼마나 자주 데이터를 보내나요. 여기서 서버 비용이 결정돼요.
4. 데이터 유실 허용 여부 — 잠깐 끊긴 사이의 값을 버려도 되나요, 나중에 채워 넣어야 하나요. 후자면 저장 구조가 한 겹 더 생겨요.
5. 장애 시 표시 규칙 — 연결이 끊기면 화면에 뭘 띄우나요. 마지막 값을 그대로 두는 것과 ‘확인 불가’를 띄우는 건 다른 요구예요.

다섯 개를 한 장으로 정리해 견적 요청서에 붙이시면, 개발사끼리 같은 전제로 계산하게 돼요. 요구사항 문서 전체를 완성하실 필요는 없어요. 요구사항 정의서를 어디까지 써야 하는지는 따로 정리해뒀는데, 실시간 프로젝트라면 이 다섯 줄이 앞쪽에 오는 게 맞아요.

용어 정리 — 갱신 주기와 허용 지연 갱신 주기는 화면이 새 값을 가져오는 간격이고, 허용 지연은 현장에서 일이 벌어진 뒤 화면에 보일 때까지 참을 수 있는 시간이에요. 둘은 다른 숫자예요. 5초마다 갱신해도 데이터가 서버를 거쳐 오는 데 10초가 걸리면 화면은 10초 뒤 세상을 보여줘요. 실무에서는 “몇 초마다 볼지”와 “몇 초 늦어도 되는지”를 따로 물어봐요.

3. 실시간에도 층위가 있다는 걸 아시나요

네 가지로 나눠 보시면 우리 프로젝트가 어디인지 금방 잡혀요.

층위	갱신 감각	흔한 예	구현 방식(예시)
준실시간	분 단위	일일 현황판, 매출 집계	주기적으로 다시 물어보기
화면 실시간	수 초	혼잡도, 재고 현황, 주문 접수	서버에서 밀어주는 단방향 스트리밍
상호작용 실시간	1초 이내	채팅, 협업 편집, 위치 추적	양방향 연결(웹소켓)
장비 실시간	밀리초~초	센서 수집, 설비 제어, 사이니지 송출	경량 메시지 규격(MQTT 등)

여기서 자주 벌어지는 일이 있어요. 필요한 건 두 번째 줄인데 세 번째 줄로 견적이 나오는 경우예요. 실시간이라는 단어만 듣고 양방향 연결부터 깔면 서버 비용과 장애 지점이 함께 늘어나요. 최근에는 국내 개발자 커뮤니티에서도 대부분의 서비스에 웹소켓이 필요하지 않다는 얘기가 자주 나와요(2026년 7월 개발 블로그 논의 기준).

방식을 정하는 건 개발사 몫이지만, 어떤 층위를 전제로 계산했는지 물어보시는 건 발주자 쪽에서 하실 수 있어요. 답이 명확한 곳과 그렇지 않은 곳의 차이가 꽤 커요.

4. 설치 환경이 비용을 얼마나 바꿀까요

화면보다 어디에 설치되느냐가 훨씬 크게 작용해요.

저희가 롯데백화점 수원 푸드홀의 실시간 혼잡도 관리 시스템을 만들 때가 그랬어요. 캐논코리아와 컨소시엄으로 함께 수행했고 센서는 캐논코리아가 제공했는데, 어려웠던 지점은 전부 환경 쪽이었어요.

보안 요건 때문에 내부·사설 네트워크로 구성해야 했어요. 외부에서 접속할 수 없으니 확인 작업마다 현장 일정이 필요했죠. 여기에 여러 센서가 동시에 데이터를 보내면서 취합이 지연되는 현상도 생겼어요. 센서 한 대로 시험할 때는 안 보이던 문제였어요.

가장 오래 붙들었던 건 사이니지였어요. 관리자 페이지에서 등록한 광고가 현장 화면에서 끊기는 문제가 있었는데, 결국 처음 JavaFX로 만든 부분을 C#으로 다시 구현해서 풀었어요. 개발 중 테스트에서는 드러나지 않다가 운영 환경에서 나타난 문제였고요.

이 프로젝트는 개발에만 4개월이 걸렸고 기획 1명, 디자인 1명, 개발 2명이 붙었어요. 오픈 이후에는 혼잡도 데이터로 인력 배치와 실시간 광고 송출을 운영에 적용했고, 사이니지를 본 방문객이 붐비는 매장을 피해 이동하는 모습도 관찰됐어요. 프로젝트 전체 이야기는 따로 정리해뒀어요.

5. 기간과 비용은 어느 정도로 잡아야 할까요

두 가지 기준을 나눠서 보셔야 해요. 저희 실무 관행과 공개된 외부 자료는 성격이 다르거든요.

저희 실무 기준 예시 (프로젝트마다 달라요. 자사 실거래 통계가 아니에요.)

조건	추가로 잡는 기간
폐쇄망·사설망 구성	현장 확인 일정 별도 산정
센서·장비가 여러 대	동시 부하 확인 기간 추가
현장 설치물(사이니지·키오스크) 포함	설치 후 조정 기간 별도
기존 관제 시스템과 연동	대상당 2～4주

공식 외부 기준

• 공개 시장 자료 기준으로 플랫폼·실시간 시스템의 개발 기간은 4～6개월 이상으로 알려져 있어요.
• 한국소프트웨어산업협회(KOSA) 2024년 공표 기준 응용SW개발자 월 평균임금은 약 712만 원, IT PM은 약 953만 원이에요. 여기에 업계 관행상 마진이 붙어 실제 소프트웨어 외주개발 견적이 정해지는데, 이 부분은 추정 영역이에요.

두 표를 섞어 읽지 마세요. 위는 저희가 일정을 잡는 방식이고, 아래는 공개 자료예요.

운영사 Tip — 저희는 실시간 프로젝트에서 오픈일을 마감으로 잡지 않아요. 오픈 후 조정 기간까지 일정에 넣어요. 현장에 설치해야 드러나는 문제가 반드시 나오거든요. 실시간 시스템은 오픈이 끝이 아니라 시작이라, 배포 후 조정 단계까지 처음부터 봐요.

6. 발주 단계에서 흔히 놓치는 건 무엇일까요

실시간 프로젝트에서 반복해서 보는 세 가지예요.

하나, 부하 시험을 검수 직전으로 미뤄요. 장비 한 대로 개발하다가 마지막에 전부 붙이면, 취합이 밀릴 때 되돌릴 시간이 없어요. 초반에 실제 대수의 절반 정도로 한 번 부딪혀보는 편이 안전해요.

둘, 현장 방문과 장비 대여 일정이 견적에 없어요. 금액은 크지 않은데 일정에는 확실히 영향을 줘요. 폐쇄망이면 방문 횟수가 그대로 기간이 돼요.

셋, 데이터 보관 기간을 안 정해요. 초 단위로 쌓이는 데이터는 몇 달만 지나도 양이 커져요. 며칠 치를 원본으로 두고 그 뒤엔 요약만 남길지 미리 정하지 않으면 운영비가 나중에 올라가요.

7. 운영까지 보면 무엇이 달라질까요

실시간 시스템의 비용은 오픈 이후에 다시 계산돼요.

화면 개발은 끝이 있어요. 만들면 끝나니까요. 그런데 실시간으로 뭔가를 계속 받는 시스템은 성격이 달라요. 장비가 늘어나고, 네트워크가 흔들리고, 데이터가 쌓여요. 오픈 시점의 설계가 1년 뒤에도 버티는지는 그때 가서야 알게 되고요.

그래서 저희는 견적 단계에서 세 가지를 함께 물어봐요. 장비가 두 배로 늘면 서버를 어떻게 늘릴지, 데이터가 몇 달 치 쌓이면 어디로 옮길지, 야간에 끊겼을 때 누가 어떻게 알게 되는지예요. 이 답이 준비된 견적과 아닌 견적은 총액이 비슷해도 1년 뒤가 달라져요.

납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. 저희가 자체 SaaS 4종을 직접 굴리면서 얻은 감각이기도 하고요.

8. 마무리

실시간 시스템의 발주는 기능을 정하는 일이 아니라 기준값을 정하는 일에 가까워요. 갱신 주기와 허용 지연, 동시 접속, 유실 허용, 장애 시 표시. 이 다섯 줄만 있어도 받아보시는 소프트웨어 외주 견적의 성격이 달라져요.

숫자를 아직 못 정하셨어도 괜찮아요. 대부분 현장 상황을 이야기하다 보면 자연스럽게 정해져요. 지금 만들려는 시스템이 어느 층위인지 헷갈리신다면 현장 조건부터 같이 정리해봐요 → 방향이 명확하지 않은 단계에서 이야기하는 편이 오히려 나아요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 센서와 현장 장비가 붙는 시스템을 여러 번 겪어봐서, 어디에서 시간이 새는지는 비교적 정확히 짚어드릴 수 있어요.

9. 자주 묻는 질문

실시간 시스템은 개발 기간을 얼마나 잡아야 하나요?

공개 시장 자료 기준으로 플랫폼·실시간 시스템은 4～6개월 이상으로 알려져 있어요. 저희가 롯데백화점 수원 푸드홀 시스템을 만들 때도 개발에 4개월이 걸렸고요. 다만 기간 숫자보다 오픈 이후 조정 일정을 따로 잡아두시는 게 더 중요해요.

개발 외주 맡기는 절차 5단계는 무엇인가요?

요구사항 정리, 업체 선정과 견적 비교, 계약과 착수, 개발과 중간 확인, 검수와 운영 이관 순서예요. 실시간 시스템이라면 첫 단계에서 갱신 주기와 허용 지연을 숫자로 적어두셔야 해요. 이 숫자가 없으면 견적 비교 자체가 성립하지 않아요.

실시간이면 웹소켓으로 만들어야 하나요?

꼭 그렇진 않아요. 몇 초 단위로 화면에서 보기만 한다면 주기적 조회나 단방향 스트리밍으로 충분한 경우가 많아요. 양방향으로 즉시 주고받아야 할 때 웹소켓이 필요하고, 장비가 많이 붙으면 MQTT 같은 경량 규격을 쓰기도 해요.

---

관련 글

• 롯데백화점 푸드홀 실시간 혼잡도 시스템 구축 사례
• 기존 시스템 연동이 있으면 왜 더 어려워질까요
• 요구사항 정의서, 어디까지 써야 견적이 맞아질까요