현장 실시간 시스템, 단계마다 어떤 산출물이 남을까요

먼저 짧게 답부터 드릴게요. 현장에 센서를 깔고 실시간으로 데이터를 보여 주는 시스템은 화면 시안만으로 진행을 알기 어려워요. 겉은 멀쩡해 보여도 데이터가 밀리거나 끊기는 문제는 운영 환경에서야 드러나거든요. 그래서 단계마다 어떤 산출물이 나오는지를 계약 때 정해 두고, 그 산출물로 진행을 확인해야 해요. 착수 전 정의서, 기획·설계 문서, 구축 단계의 규격·구성도, 검증 단계의 시험 기록, 운영 전환 때 넘겨받을 소스와 운영 문서예요. 롯데백화점 수원 푸드홀 실시간 혼잡도 시스템을 만든 경험으로 정리했어요.

“화면은 거의 다 됐다는데, 왜 진짜 되는 건지는 모르겠어요.”

현장 시스템 프로젝트 중반에 발주 담당자에게서 자주 듣는 말이에요. 버튼을 누르면 숫자가 바뀌니 다 된 것 같은데, 센서 수십 개가 한꺼번에 데이터를 보낼 때도 그 숫자가 제때 바뀌는지는 화면만 봐서는 알 수 없거든요. 이 간극을 메우는 게 단계별 산출물이에요.

실시간 시스템의 견적과 기간을 숫자로 정하는 법은 실시간 시스템 외주, 견적 전에 정할 것에서, 롯데 수원 푸드홀 사례의 전체 그림은 롯데백화점 푸드홀 실시간 혼잡도 시스템 사례에서 다뤘어요. 오늘은 4개월 동안 단계마다 무엇이 산출물로 남고, 그걸로 어떻게 진행을 확인하는지만 좁혀서 볼게요.

---

1. 실시간 시스템은 왜 화면보다 산출물로 봐야 할까요

눈에 보이는 건 화면인데, 돈과 시간이 드는 건 화면 뒤이기 때문이에요. 실시간 시스템은 센서가 데이터를 보내고, 그 데이터를 받아 모으고, 밀리지 않게 처리해서 화면에 올려요. 이 가운데 화면은 마지막 한 겹이에요.

롯데백화점 수원 푸드홀 혼잡도 시스템이 그랬어요. 매장별 혼잡도를 보여 주는 화면은 금방 그렸지만, 센서 여러 개가 동시에 데이터를 보내자 취합이 밀리는 현상이 나타났어요. 화면만 보면 “숫자가 나온다”였지만, 실제로는 그 숫자가 몇 초 전 것인지가 문제였어요. 그래서 진행을 화면으로 확인하면 “거의 다 됐다”가 되고, 산출물로 확인하면 “데이터 취합 지연을 아직 못 잡았다”가 돼요.

개발외주비용을 비교할 때도 산출물 목록이 있는 견적과 없는 견적은 같은 기준이 아니에요. 산출물이 적힌 쪽은 단계마다 무엇을 받을지 정해져 있고, 없는 쪽은 “다 되면 보여 드릴게요”로 끝나요. 뒤쪽이 싸 보여도 진행을 확인할 방법이 없어요.

2. 착수 전 — 무엇이 ‘실시간’인지 정의하는 산출물

가장 먼저 나와야 할 산출물은 ‘실시간의 기준’을 적은 정의서예요. 실시간이라는 말은 사람마다 다르게 들어요. 누구는 1초, 누구는 1분을 떠올리죠. 이 기준이 정해지지 않으면 뒤 단계가 전부 흔들려요.

착수 전 단계에서 받아 둘 산출물은 이래요.

• 갱신 주기 정의 — 화면 숫자가 몇 초·몇 분마다 바뀌어야 하는지
• 센서·데이터 목록 — 어떤 장비가 무슨 데이터를 얼마나 자주 보내는지
• 네트워크 조건 — 외부 인터넷을 쓰는지, 내부망만 쓰는지
• 화면·표출 장치 목록 — 관리자 화면과 현장 사이니지가 각각 무엇을 보여 주는지

롯데 사례에서는 보안 요건 때문에 처음부터 내부·사설 네트워크로 간다는 조건이 정해져 있었어요. 이 한 줄이 뒤의 구축 방식과 비용을 거의 다 정했어요. 기업을 위한 AI·gen AI 개발 외주처럼 환경이 결과를 좌우하는 프로젝트도 이 착수 전 정의가 부실하면 중간에 크게 되돌아가요.

용어 정리 — 갱신 주기는 화면 숫자가 얼마 만에 한 번씩 새로 바뀌는지예요. 사이니지는 매장에 걸린 안내용 화면이고요. 내부·사설 네트워크는 외부 인터넷과 끊어 놓고 회사 안에서만 데이터가 오가게 만든 망이에요. 실무에선 “이건 사내망이라 바깥에서 못 붙어요”처럼 말해요.

3. 기획·설계 — 센서·네트워크·화면을 잇는 산출물

이 단계의 산출물은 화면 시안이 아니라 ‘데이터가 어디서 어디로 가는지’ 그린 그림이에요. 화면 시안도 나오지만, 실시간 시스템에서 더 중요한 건 데이터 흐름도와 규격 문서예요.

자사 실무 기준 예시 — 기획·설계 단계에서 받아 둘 산출물

산출물	무엇이 적혀 있나요	왜 필요한가요
데이터 흐름도	센서 → 수집 → 처리 → 화면으로 가는 경로	어디서 밀릴지 미리 보여요
데이터 규격 문서	센서가 보내는 값의 형식과 주기	장비사와 맞춰야 연동이 돼요
네트워크 구성도	서버·장비·화면이 어떤 망에 붙는지	보안 요건을 지키는지 보여요
화면·사이니지 시안	관리자 화면과 현장 표출 화면	무엇을 보여 줄지 합의해요

(자사 실무 기준 예시예요. 프로젝트마다 산출물 이름과 범위가 달라요.)

롯데 수원 푸드홀은 캐논코리아와 컨소시엄으로 함께 수행했고, 센서는 캐논코리아가 제공했어요. 그래서 데이터 규격 문서를 양쪽이 맞추는 일이 설계 단계의 큰 몫이었어요. 장비를 쥔 쪽이 따로 있으면 이 문서가 곧 협업의 기준선이 돼요. GUI 소프트웨어 외주 개발이라도 바깥 장비와 붙는 순간, 화면 시안만으로는 설계가 끝나지 않아요.

4. 구축 — 지연과 끊김을 드러내는 산출물

구축 단계의 산출물은 ‘돌아가는 화면’이 아니라 ‘부하를 줬을 때의 기록’이에요. 센서 하나로 시험하면 다 되는데, 여러 개가 동시에 보내면 밀리는 문제가 여기서 나와요.

롯데 사례에서 실제로 두 가지가 드러났어요. 첫째는 데이터 취합 지연이었어요. 다수의 센서가 한꺼번에 데이터를 보내자 모으는 쪽이 밀렸어요. 둘째는 관리자 페이지에서 등록한 광고가 현장 사이니지에서 끊기는 현상이었어요. 둘 다 화면만 보면 몰라요. 동시에 데이터를 쏟아붓고, 오래 틀어 놓고 지켜봐야 나와요.

그래서 이 단계에서는 이런 산출물을 받아 두세요.

• 부하 시험 기록 — 센서를 실제 개수만큼, 또는 그 이상으로 돌렸을 때의 지연 측정
• 연속 가동 기록 — 사이니지를 오래 틀어 놓고 끊김이 없는지 본 결과
• 오류 처리 정의 — 데이터가 안 들어오거나 밀릴 때 화면이 어떻게 보이는지

앱 개발 외주 과정에서도 비슷하지만, 현장 실시간 시스템은 “한 번 되는 것”과 “오래, 많이 돌려도 되는 것”의 차이가 특히 커요. 이 기록이 없으면 오픈 첫날 사람이 몰렸을 때 처음으로 문제를 만나게 돼요.

5. 검증 — 운영 환경에서 버티는지 보는 산출물

검증의 산출물은 ‘테스트 환경에서 됐다’가 아니라 ‘운영 환경에서도 됐다’는 기록이에요. 둘은 다른 서버, 다른 조건이라 결과가 달라질 수 있어요.

롯데 사례의 사이니지 끊김은 이 단계에서 구조 자체를 바꿔 해결했어요. 처음에는 한 방식(JavaFX)으로 사이니지 표출을 구현했는데, 운영 환경에서 끊김이 반복되자 이후에 다른 방식(C#)으로 다시 구현했어요. 이건 “만들고 끝”이 아니라 “운영 환경에서 버티는지까지 본다”는 게 무슨 뜻인지 보여 주는 대목이에요. 검증 단계의 산출물이 없었다면 이 문제를 오픈 뒤에 만났을 거예요.

자사 실무 기준 예시 — 검증 단계에서 받아 둘 산출물

산출물	확인하는 것
운영 환경 시험 기록	실제 망·실제 장비에서 돌린 결과
장기 가동 기록	며칠 연속 틀어 놓고 끊김·지연이 없는지
결함·조치 목록	나온 문제와 어떻게 고쳤는지
재검증 기록	고친 뒤 같은 조건으로 다시 돌린 결과

(자사 실무 기준 예시예요. 항목은 시스템마다 달라요.)

여기서 나온 결함·조치 목록은 나중에 운영을 넘겨받을 때도 쓰여요. “이 문제는 이렇게 고쳤다”는 기록이 있으면 같은 문제가 다시 나왔을 때 빨리 대응할 수 있어요.

6. 운영 전환 — 넘겨받을 산출물

마지막 산출물은 ‘넘겨받을 것들’이에요. 소스코드, 빌드 방법, 운영 문서, 계정이요. 이게 없으면 다음에 손볼 사람이 처음부터 다시 파악해야 해요.

• 소스코드와 빌드 방법 — 코드만이 아니라 그걸 실제로 돌리는 방법까지
• 운영 문서 — 서버를 어떻게 켜고 끄는지, 문제가 생기면 어디를 보는지
• 계정·접속 정보 — 서버와 장비에 붙는 권한을 누가 갖는지
• 데이터 규격·구성도 최종본 — 설계 때 만든 문서를 실제 구축에 맞춰 갱신한 것

실시간 시스템은 오픈 뒤에도 센서가 늘거나 매장이 바뀌면 손봐야 해요. 그때 이 산출물이 있으면 연동 부분만 고치면 되지만, 없으면 전체를 다시 뜯어봐야 해요. 소스코드의 권리 관계는 계약서에 미리 적어 둬야 분명해져요. 전체 견적에서 각 단계가 어디쯤인지는 소프트웨어 개발 외주 비용 가이드에, 공공·중견 SI의 도급 구조는 SI 개발 비용, 도급 구조부터 봐야 하는 이유에 정리해 뒀어요.

7. 그래서 기간은 어떻게 잡을까요

단계별 산출물이 정해지면 기간도 그 산출물이 나오는 시점으로 잡아요. “언제 다 돼요?”가 아니라 “이 산출물은 언제 나와요?”로 물으면 일정이 구체적으로 보여요.

롯데 수원 푸드홀 혼잡도 시스템은 기획 1·디자인 1·개발 2명이 4개월에 걸쳐 만들었어요. 이 기간 안에 착수 전 정의, 설계 문서, 구축과 부하 시험, 운영 환경 검증, 운영 전환이 단계로 들어가요. 숫자로 보면 4개월이지만, 그 안에 어떤 산출물이 어느 시점에 나오는지 쪼개 두면 중간에 늦어져도 어디서 늦는지 바로 알 수 있어요.

흔한 실수 구축이 길어지면 검증을 줄이는 거예요. 일정이 밀리면 가장 먼저 줄이고 싶은 게 운영 환경 시험이에요. 그런데 롯데 사례의 사이니지 끊김처럼, 운영 환경에서야 드러나는 문제는 검증을 줄인 만큼 오픈 뒤로 넘어와요. 검증 단계의 산출물은 일정이 밀려도 지켜야 할 쪽이에요.

실시간 시스템은 “언제 끝나요”보다 “이 단계 산출물이 언제 나와요”로 관리하는 게 안전해요. 그게 발주자가 진행을 눈으로 확인하는 거의 유일한 방법이거든요.

8. 운영해 본 개발사는 어떻게 보나요

현장 실시간 시스템은 만드는 것보다 운영 환경에서 버티게 만드는 게 진짜 일이라고 봐요. 화면은 금방 그리지만, 센서가 한꺼번에 데이터를 보낼 때도 밀리지 않고, 사이니지가 며칠을 틀어 놔도 끊기지 않게 하는 건 단계마다 산출물로 확인하면서 가야 닿는 지점이에요.

롯데 수원 푸드홀 사례에서 사이니지 표출 방식을 중간에 다시 구현한 경험이 그걸 가르쳐 줬어요. 그 뒤로 이 시스템은 혼잡도 데이터를 바탕으로 인력을 배치하고 실시간으로 광고를 내보내는 데 쓰였고, 방문객이 붐비는 매장을 피해 움직이는 모습도 관찰됐어요. 만약 검증 단계를 건너뛰었다면 이 성과는 오픈 뒤 문제를 고치느라 묻혔을 거예요.

현장에 시스템을 들이려는데 무엇을 산출물로 받아야 할지 감이 안 오신다면, 범위가 아직 안 정해졌어도 괜찮아요. 센서 개수와 갱신 주기, 설치 환경을 놓고 단계마다 어떤 산출물을 받을지부터 같이 정리해 볼 수 있어요. 저희는 10년 넘게 50개 이상의 프로젝트를 진행하면서 자체 SaaS 4종을 직접 운영해 온 개발사이고, 롯데·캐논 같은 곳과도 함께해 왔어요. 현장 실시간 시스템, 단계별 산출물부터 같이 짚어 봐요 →

9. 자주 묻는 질문 (FAQ)

실시간 시스템 외주 과정은 어떻게 흘러가나요?

착수 전 정의, 기획·설계, 구축, 검증, 운영 전환의 다섯 단계로 나눠요. 앱 개발 외주 과정과 큰 틀은 같지만, 실시간 시스템은 센서·네트워크·현장 장비가 끼어서 단계마다 ‘현장에서 버티는지’를 확인하는 산출물이 하나씩 더 붙어요. 화면 시안만으로는 진행을 알 수 없어서, 각 단계에서 무엇을 산출물로 받을지 계약 때 정해 두는 게 중요해요.

GUI 소프트웨어 외주 개발에서 산출물은 화면 말고 또 뭐가 있나요?

화면을 갖춘 설치형 프로그램이라도 산출물은 화면 말고도 여러 가지예요. 데이터가 오가는 규격 문서, 네트워크 구성도, 장비·버전 조합 테스트 결과, 운영 환경에서 돌린 부하 시험 기록, 소스코드와 빌드 방법이요. 롯데 수원 푸드홀 사례에서는 관리자 화면 뒤에서 센서 데이터를 받아 처리하는 부분이 진짜 일이었어요.

기업을 위한 AI·gen AI 개발 외주도 단계별 산출물로 관리할 수 있나요?

네, 오히려 더 그래야 해요. AI가 들어가면 결과가 데이터와 환경에 따라 달라져서, 기획·데이터 준비·평가·검수 단계마다 ‘무엇을 받았는지’를 산출물로 남겨 둬야 나중에 되짚을 수 있어요. 특히 평가 단계의 지표 기록과 운영 전환 때의 재검증 결과는 꼭 산출물로 받아 두세요.