두 회사가 함께 만드는 프로젝트 | 발주자가 먼저 정할 5가지

핵심 요약 — 하드웨어는 A사, 소프트웨어는 B사처럼 나눠 맡기는 프로젝트에서 문제는 각 회사 안이 아니라 둘이 만나는 자리에서 생겨요. 공동수급 방식에 따라 책임 범위도 완전히 달라지고요. 롯데백화점 수원 푸드홀 실시간 혼잡도 시스템을 캐논코리아와 공동 수행하며 겪은 것과, 발주자가 착수 전에 정해둘 5가지를 정리했어요.

“센서는 저쪽에서 넣어주기로 했어요. 개발만 맡아주시면 돼요.”

이런 식으로 시작하는 프로젝트가 꽤 있어요. 얼핏 명확해 보이는데, 막상 진행하면 “센서에서 값이 이상하게 옵니다”와 “받는 쪽에서 잘못 읽는 것 같은데요” 사이에서 시간이 흘러요. 어느 쪽 문제인지 가릴 기준이 없으면 그 판단은 결국 발주자에게 돌아와요.

---

1. 왜 한 프로젝트에 여러 회사가 들어오나요

한 회사가 다 못 하는 일이 실제로 있어서예요.

센서나 장비를 만드는 회사와 화면·서버를 만드는 회사는 하는 일이 달라요. 매장에 설치되는 시스템, 공장 설비와 연결되는 시스템, 공공기관 대형 사업이 대표적이에요. 이런 프로젝트는 한 회사가 전부 맡으면 오히려 품질이 떨어져요.

발주자 입장에서도 이점이 있어요. 계약 창구가 하나로 줄고, 각 분야에서 실제로 해본 곳을 고를 수 있어요. 다만 그 편의는 조건이 붙어요. 어디까지가 누구 몫인지가 문서에 적혀 있을 때만 성립해요.

2. 공동 수행 방식은 어떻게 나뉘나요

세 갈래고, 고르는 순간 책임 범위가 정해져요.

방식	일하는 구조	책임
공동이행	출자비율대로 인원·자금을 내서 전체를 같이 수행	구성원이 연대해 책임
분담이행	일을 나눠 각자 맡은 부분만 수행	원칙적으로 각자 맡은 부분
주계약자 관리	주계약자가 전체를 관리하고 나머지가 참여	주계약자가 관리 책임

위 구분은 국가계약 공동계약 제도의 공개 기준이에요. 민간 프로젝트는 이 틀을 그대로 쓰지 않아도 되지만, 계약서에 방식을 안 적으면 실무에서는 대개 공동이행처럼 굴러가요.

하드웨어와 소프트웨어처럼 산출물이 뚜렷하게 갈리면 분담이행이 깔끔해요. 반대로 한 시스템을 여러 회사가 같이 만드는 형태면 공동이행으로 묶는 게 자연스럽고요.

여기서 발주자가 알아둘 게 하나 있어요. 공동이행방식에서는 구성원 한 곳이 경영이 어려워져 하자보수를 못 하면 나머지가 떠안는 사례가 실제로 있어요. 공공 SW·SI 사업에서 특정 기업의 문제를 컨소시엄 전체가 무한 책임지는 관행이 과하다는 지적이 업계에서 이어지는 배경이에요. 발주자에게 유리해 보이지만, 참여를 꺼리게 만들어서 좋은 팀을 못 모으는 원인이 되기도 해요.

3. 실제로 문제가 생긴 자리는 어디였나요

각 회사 안이 아니라 둘이 만나는 지점이었어요.

[리테일 · 실시간 시스템(SI)] 롯데백화점 수원 푸드홀 실시간 혼잡도 관리 시스템

2024년 5월에 오픈한 프로젝트예요. 저희는 캐논코리아와 컨소시엄을 구성해 공동 수행했고, 센서는 캐논코리아가 제공했어요. 개발 기간은 4개월, 저희 쪽 투입은 기획 1명·디자인 1명·개발 2명이었어요.

문제 → 해결 → 성과로 정리하면 이래요.

문제. 매장이 붐비는 건 눈에 보이는데 그걸 숫자로 가진 사람이 없었어요. 인력을 어디에 더 둘지, 어떤 안내를 언제 띄울지가 감으로 결정됐고요.

해결. 센서가 보내는 값을 모아 혼잡도로 바꾸고, 관리자 화면에서 기준을 조정하면 매장 곳곳의 사이니지에 반영되게 만들었어요.

성과. 혼잡도 데이터를 인력 배치와 실시간 광고 송출에 실제로 썼어요. 사이니지를 보고 방문객이 붐비는 매장을 피해 이동하는 모습도 관찰됐고요.

그런데 개발하면서 가장 애먹은 세 가지는 전부 경계면에 있었어요.

• 보안 요건 때문에 내부·사설 네트워크로 구성해야 했어요. 외부 통신을 전제로 짠 구조를 다시 잡아야 했고요.
• 여러 센서가 동시에 값을 보내면서 데이터 취합이 밀리는 현상이 있었어요. 센서 쪽 문제인지 받는 쪽 문제인지 나누는 것부터 일이었어요.
• 관리자 화면에서 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 처음에 JavaFX로 만든 부분을 나중에 C#으로 다시 구현해서 해결했어요.

세 가지 모두 “누가 잘못했나”로는 안 풀렸어요. 값이 어느 구간에서 어떻게 변하는지 같이 보면서 좁혀야 했어요.

4. 경계면을 어떻게 정의해야 할까요

주고받는 값의 모양과 실패 처리를 숫자로 적어야 해요.

“연동한다”는 말은 계약서에 적혀도 아무것도 정하지 않은 거예요. 최소한 이 정도는 문장이 아니라 값으로 있어야 해요.

• 무엇을 보내나 — 항목 이름, 형식, 단위
• 얼마나 자주 — 초당 몇 건, 몇 초 간격
• 몇 개가 붙나 — 센서·장비 대수와 늘어날 여지
• 늦으면 몇 초까지 정상인가 — 여기를 안 정하면 지연이 문제인지 아닌지 판단이 안 돼요
• 끊기면 어떻게 하나 — 재시도 횟수, 그동안 화면에 뭘 보여줄지
• 값이 이상하면 누가 보나 — 기록을 어느 쪽이 남기고 누가 먼저 확인하는지

마지막 항목이 실무에서 제일 크게 갈려요. 양쪽 다 기록을 안 남기면 문제가 생겼을 때 재현이 안 돼요. 그러면 회의만 늘어나요.

저희는 같은 기능 수보다 출시 후 얼마나 자주 수정될지부터 보는데, 여러 회사가 얽힌 프로젝트에서는 이 질문이 경계면에 집중돼요. 기기 연동에서 무엇을 먼저 정해야 하는지는 기존 시스템·API·디바이스 연동이 있으면 왜 더 어려워질까요에 따로 정리해뒀어요.

5. 하자가 생기면 누가 책임지나요

방식을 안 적으면 전부가 책임지는 쪽으로 흘러요.

오픈하고 나서 화면이 멈췄다고 해볼게요. 센서가 값을 안 보낸 건지, 서버가 못 받은 건지, 화면이 못 그린 건지에 따라 고칠 사람이 달라요. 그런데 계약서에 “공동으로 수행한다”만 적혀 있으면 세 경우 모두 양쪽이 같이 불려요.

착수 전에 이 셋을 정해두면 대부분 정리돼요.

1. 하자 판정 기준 — 무엇이 하자이고 무엇이 개선 요청인지
2. 1차 확인 담당 — 문제가 생겼을 때 먼저 보는 쪽과 연락 순서
3. 경계면 하자의 처리 — 어느 쪽 몫인지 불분명할 때의 절차와 비용 분담

특히 세 번째를 비워두는 경우가 많은데, 실제로 시간을 가장 많이 잡아먹는 게 그 구간이에요.

여러 회사가 얽힌 프로젝트를 준비 중이라면, 경계면 문서부터 같이 잡아드릴게요. 프로젝트 상담받기 →

6. 발주자가 착수 전에 정할 5가지

#	정할 것	안 정하면 생기는 일
1	수행 방식(공동이행·분담이행·주계약자)	실무에서 연대 책임처럼 굴러감
2	산출물별 담당 회사	경계 산출물이 공중에 뜸
3	주고받는 데이터 규격과 지연 허용치	지연이 하자인지 판단 불가
4	장애 시 1차 확인 담당과 연락 순서	초기 대응이 회의로 흘러감
5	경계면 하자의 비용 분담 기준	오픈 후 분쟁의 주된 원인

다섯 항목 모두 견적 단계에서 물어보세요. 착수 뒤에 꺼내면 협의 사항이 되지만, 견적 단계에서는 제안서에 반영돼서 나와요. 비용도 거의 안 달라져요.

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

오픈이 끝이 아니라 경계면이 시험받기 시작하는 시점이에요.

푸드홀 사례에서 사이니지 광고가 끊기던 문제는 개발 중에는 잘 드러나지 않았어요. 실제 매장에서 오래 켜두고 나서야 보였고, 결국 만들던 방식을 바꿔 다시 구현했어요. 실시간 시스템은 오픈이 끝이 아니라 시작이라, 배포 후 조정 단계까지 처음부터 계산에 넣어야 해요.

여러 회사가 함께한 프로젝트라면 그 조정 기간을 누가 붙어 있을지도 정해둬야 해요. 각자 계약이 끝나면 빠지는 구조로 짜두면, 정작 문제가 보이기 시작할 때 아무도 안 남아 있어요.

8. 자주 묻는 질문

컨소시엄으로 발주하면 관리가 더 편한가요?

상대할 창구는 줄어요. 대신 책임 경계가 안쪽으로 숨어서, 문제가 생겼을 때 판단이 발주자에게 돌아와요. 경계면 문서가 있으면 편해지고, 없으면 오히려 어려워져요.

공동수급 방식은 어떻게 고르나요?

산출물이 뚜렷하게 나뉘면 분담이행, 한 시스템을 같이 만들어야 하면 공동이행이 맞아요. 하드웨어와 소프트웨어 조합이면 대개 앞쪽이에요.

우리 같은 중소 규모 프로젝트에도 해당되나요?

규모보다 참여 회사 수가 기준이에요. 두 곳만 들어와도 경계면은 생겨요. 오히려 작은 프로젝트일수록 문서를 안 만들고 시작해서 나중에 더 헤매는 경우가 많아요.

9. 정리하면

여러 회사가 들어오는 프로젝트에서 발주자가 할 일은 각 회사를 잘 고르는 것보다 둘 사이를 정의하는 일에 가까워요. 잘하는 두 회사가 모여도 경계면이 비어 있으면 그 자리에서 시간이 사라져요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논·코닥·KICT 같은 곳과 함께해 왔고, 컨소시엄으로 들어간 프로젝트도 해봤어요. 비슷한 업종의 예쁜 결과물보다 비슷한 운영 문제를 해결해본 경험이 더 도움이 된다고 생각해요.

기기나 설비가 얽힌 시스템을 준비 중이시라면, 경계면 규격부터 함께 정리해볼게요 →

관련 글

• 롯데백화점 푸드홀 실시간 혼잡도 시스템 구축 사례
• 실시간 운영 시스템 외주, 발주 전에 무엇을 정리해야 할까요
• SI 개발 비용, 도급 구조부터 봐야 하는 이유