개발 업체 레퍼런스, 무엇으로 확인하나요 | 검증 5단계

핵심 요약

• 포트폴리오 화면은 결과만 보여줘요. 같은 화면도 누가 어떤 조건에서 만들었는지에 따라 값과 위험이 완전히 달라져요.
• 레퍼런스는 보여주는 것 / 공개 자료로 확인되는 것 / 물어봐야 아는 것 세 층으로 갈라 보면 판단이 빨라져요.
• 공공 SW 사업은 수행실적증명서로 실적이 검증되고, 하도급은 50%를 넘길 수 없으며 재하도급은 원칙적으로 안 돼요(소프트웨어 진흥법 기준).
• 레퍼런스 미팅에서 가장 많은 걸 알려주는 질문은 잘된 점이 아니라 “무엇이 가장 애먹었나요” 예요.
• 직접 만들고 자체 SaaS를 운영해온 개발사 기준으로, 업체 레퍼런스를 확인하는 순서를 정리했어요.

“포트폴리오는 다들 좋아 보여요. 그런데 이 중에 누가 진짜인지는 모르겠어요.”

업체를 3～4곳으로 좁힌 뒤에 가장 많이 듣는 말이에요. 이 상태에서 결정을 미루면 대개 견적 금액으로 고르게 되고, 개발외주비용이 가장 낮은 곳을 골랐다가 다시 시작하는 일이 생겨요. 레퍼런스를 보는 순서를 바꾸면 이 자리에서 빠져나올 수 있어요.

---

1. 포트폴리오를 봤는데 왜 판단이 안 될까요

포트폴리오는 결과 화면이고, 발주 판단에 필요한 정보는 대부분 그 화면 밖에 있기 때문이에요.

같은 예약 화면이라도 하나는 3주 만에 템플릿을 고쳐 만든 것이고, 다른 하나는 기존 회원 데이터를 옮기면서 4개월에 걸쳐 만든 것일 수 있어요. 화면만 놓고 보면 둘이 비슷해 보이는데, 우리 프로젝트에 필요한 경험은 후자에만 있어요.

여기에 더해 포트폴리오에는 가장 중요한 정보가 구조적으로 빠져 있어요. 어디가 어려웠는지, 무엇을 다시 만들었는지, 오픈 후에 어떤 일이 있었는지는 아무도 자기 자료에 적지 않거든요. 그래서 포트폴리오는 후보를 좁히는 데까지만 쓰고, 좁힌 뒤에는 다른 자료로 넘어가야 해요.

2. 레퍼런스는 세 층으로 나눠 보세요

무엇을 어디서 얻을 수 있는지부터 갈라 두면, 미팅에서 쓸 질문이 확 줄어요.

층	알 수 있는 것	어디서 확인하나	신뢰도
① 보여주는 것	화면·기능 목록·고객사 로고	업체 홈페이지·제안서	낮음 (선별된 정보)
② 확인되는 것	실적 등록 여부·출시 시점·운영 지속	공개 시스템·앱마켓·라이브 서비스	높음 (제3자 기록)
③ 물어봐야 아는 것	수행 역할·투입 인원·애먹은 지점	레퍼런스 미팅·고객사 확인	높음 (검증 필요)

①에서 시간을 오래 쓰는 경우가 많은데, 실제로 판단을 바꾸는 건 ②와 ③이에요. ②는 우리가 혼자서도 할 수 있고 비용이 들지 않으니, 미팅 전에 끝내 놓는 편이 좋아요.

운영사 Tip — 저희는 반대로 발주사에서 이 질문을 받았을 때 가장 편해요. 답이 정해져 있으니까요. 오히려 질문이 화면 이야기에서 끝나면, 나중에 요구사항이 달라질 확률이 높다고 봐요.

3. 공개 자료로 어디까지 확인할 수 있을까요

생각보다 많이 확인돼요. 미팅을 잡기 전에 이 정도는 혼자 볼 수 있어요.

확인할 것	어디서	무엇을 알 수 있나
SW사업 수행실적	소프트웨어산업정보시스템(SWIT), 한국소프트웨어산업협회	공공 SW 사업 수행 실적이 등록·승인돼 있는지
정보통신공사 실적	정보통신공사업 실적신고 시스템	설비·네트워크가 포함된 구축 사업 경험
앱 업데이트 이력	App Store·Google Play	출시 후 몇 년간 관리됐는지, 최근 업데이트는 언제인지
웹 결과물 생존	포트폴리오에 적힌 실제 주소	지금도 살아 있는지, 모바일에서 깨지지 않는지
사업자 상태	국세청 사업자등록 상태 조회	휴업·폐업 여부

공식 외부 기준 — SW사업 수행실적증명서는 한국소프트웨어산업협회가 실적 신청 접수와 확인을 거쳐 발급하고, 승인된 실적만 증명서가 나와요. 전자신청으로만 처리돼요. 공공 사업 비중이 있는 업체라면 이 기록이 제일 빠른 확인 수단이에요. 다만 민간 프로젝트는 여기에 잡히지 않으니, 민간 위주 업체를 실적 없음으로 오해하면 안 돼요.

앱 업데이트 이력은 특히 많은 걸 말해줘요. 출시일은 있는데 마지막 업데이트가 4년 전이면, 만들고 끝난 프로젝트라는 뜻이에요. 반대로 2～3년에 걸쳐 업데이트가 이어졌다면 그 업체는 운영 단계를 실제로 겪어 봤어요.

4. 그 프로젝트를 누가 어떤 역할로 했나요

포트폴리오에 적힌 프로젝트를 그 업체가 통째로 했다는 보장은 없어요. 여기서 갈리는 게 셋이에요.

• 직접 수행 — 기획·디자인·개발을 그 회사 인력이 했어요.
• 컨소시엄 — 여러 회사가 역할을 나눠 함께 했어요. 우리가 맡길 영역을 그 회사가 했는지 확인해야 해요.
• 하도급 — 수주는 했지만 실제 개발은 다른 회사가 했어요. 이 경우 우리가 만날 팀은 포트폴리오의 팀이 아니에요.

셋 다 정상적인 수행 형태예요. 문제는 구분 없이 하나로 적혀 있을 때 생겨요. 그래서 질문을 이렇게 바꿔 보세요. “이 프로젝트에서 귀사가 맡은 영역이 어디였나요?” 그리고 “이번 프로젝트는 같은 구조로 진행되나요?”

공식 외부 기준 (소프트웨어 진흥법 기준, 공공 SW 사업)	내용
하도급 사전 승인	하도급 계약은 발주기관의 사전 승인을 받아야 해요
하도급 비율 상한	50%를 초과할 수 없어요
재하도급	원칙적으로 허용되지 않아요
승인 기준	하도급 적정성 평가 점수가 85점 이상이면 승인할 수 있어요

공식 외부 기준 — 위 내용은 공공 SW 사업에 적용되는 규정이에요. 민간 계약에는 그대로 적용되지 않아요. 다만 이 기준을 그대로 계약서에 옮겨 적는 건 가능해요. “하도급 시 사전 서면 동의”, “재하도급 금지” 두 줄만 넣어도 팀이 바뀌는 상황을 막을 수 있어요.

용어 정리 — 원도급은 발주사와 직접 계약한 회사예요. 하도급은 원도급사가 일부를 다시 다른 회사에 맡기는 것이고요. 컨소시엄은 여러 회사가 각자 역할을 나눠 함께 수행하는 형태예요. 실무에서는 “이건 컨소시엄이었고 저희가 소프트웨어를 맡았어요”처럼 말해요.

5. 레퍼런스 미팅에서는 무엇을 물어야 할까요

잘된 점을 물으면 준비된 답이 나오고, 애먹은 지점을 물으면 실제 경험이 나와요.

질문 다섯 개면 충분해요.

1. 이 프로젝트에서 가장 애먹은 지점은 무엇이었나요?
2. 그걸 어떻게 해결했나요? (다시 만든 부분이 있었나요?)
3. 처음 잡은 일정과 실제 오픈일이 얼마나 차이 났나요?
4. 오픈 후에 예상 못 했던 일은 무엇이었나요?
5. 지금 다시 한다면 무엇을 다르게 하시겠어요?

2번과 5번이 핵심이에요. 답이 구체적이면 실제로 한 팀이고, “큰 문제 없었습니다”로 끝나면 둘 중 하나예요. 안 했거나, 운영 단계까지 안 가봤거나.

직접 운영해보니 — 저희가 롯데백화점 수원 푸드홀 실시간 혼잡도 관리 시스템을 만들 때, 관리자 페이지에서 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 초기 JavaFX 구현을 C#으로 다시 만들어 해결했고요. 보안 요건 때문에 내부·사설 네트워크로 구성해야 했고, 센서가 동시에 데이터를 보내면서 취합이 지연되는 문제도 겪었어요. 캐논코리아와 컨소시엄으로 함께 수행한 프로젝트였고, 기획 1·디자인 1·개발 2명이 4개월 동안 진행했어요. 이런 이야기를 들으면 그 팀이 어디까지 가봤는지가 보여요. 저희가 레퍼런스 미팅에서 이 얘기를 먼저 꺼내는 이유이기도 해요.

6. 만들어진 뒤에 얼마나 오래 살아남았나요

출시했다는 사실보다, 몇 년을 버텼는지가 더 많은 걸 말해줘요.

서비스는 만든 다음 날부터 흔들려요. OS가 올라가고, 결제 모듈 규격이 바뀌고, 연동한 외부 시스템이 응답 형식을 바꿔요. 이 과정을 겪어 본 팀과 그렇지 않은 팀은 설계 단계에서부터 다른 선택을 해요.

확인 방법은 어렵지 않아요.

• 앱이면 마지막 업데이트 날짜와 최근 리뷰를 보세요.
• 웹이면 포트폴리오에 적힌 실제 주소를 모바일에서 직접 열어 보세요.
• 오래된 프로젝트가 대부분이면, 최근 1년 안에 마무리한 프로젝트를 따로 요청하세요.

측정 프로그램 외주 개발이나 장비 연동처럼 현장 환경이 끼어드는 일이라면 이 확인이 더 중요해요. 장비 펌웨어가 바뀌는 순간 소프트웨어도 같이 손봐야 하는데, 한 번도 안 겪어 본 팀은 이 비용을 견적에 넣지 않거든요.

후보를 3곳으로 좁혔는데 서로 비슷해 보인다면, 판단이 어려운 게 아니라 비교할 축이 아직 안 정해진 것일 수 있어요. 무엇을 기준으로 갈라야 할지부터 같이 정리하고 싶으시면 편하게 물어보세요 →

7. 레퍼런스 확인에서 흔히 하는 실수는 무엇일까요

네 가지가 반복돼요.

흔한 실수	왜 위험한가	대신 할 것
고객사 로고만 보고 판단	로고는 계약 사실만 말해줘요. 규모·역할은 안 보여요	그 프로젝트의 수행 범위를 물어보기
업종이 같으면 안심	같은 업종이라도 기술 유형이 다르면 경험이 안 이어져요	업종보다 기술 유형(Web·App·SI·연동)을 먼저 맞추기
화려한 결과물을 기준 삼기	디자인은 외주로도 채워져요	애먹은 지점과 해결 방식을 묻기
미팅에 온 사람 = 일할 사람이라고 가정	영업 담당과 실무 팀이 다를 수 있어요	실제 투입될 인력과 한 번 만나기

마지막 항목이 가장 자주 놓쳐요. 계약 전에 프로젝트를 맡을 기획자·개발자와 30분만 이야기해 봐도, 이 팀이 우리 요구를 어떻게 이해하는지가 드러나요. 앱 개발 비용처럼 금액이 먼저 궁금한 상황에서도, 이 30분이 결과적으로 가장 큰 비용을 아껴줘요.

가끔 헷갈리는 게 있어요. 자체 서비스를 운영하는 개발사라면 그 서비스 자체가 레퍼런스가 돼요. 오래 돌아가고 있다는 사실이 운영 경험의 증거니까요. 저희도 자체 SaaS 4종을 직접 운영하면서 누적 60만+ 사용자를 겪어 왔고, 그 경험이 외주 프로젝트의 설계 판단에 그대로 들어가요.

방향이 아직 명확하지 않아도 괜찮아요. 후보 업체의 레퍼런스를 어떤 순서로 확인해야 할지 막막하다면, 먼저 확인 순서부터 잡아 드릴게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논·코닥·KICT 같은 곳과도 함께해 왔고요. 그래서 레퍼런스에 대해 물어보시면 잘된 화면보다 애먹었던 자리를 먼저 꺼내는 편이에요.

관련해서 함께 보면 좋은 글

• 개발 외주 업체 선택 체크리스트 7가지
• 개발 외주 업체, 어디서 찾아야 할까요
• 요구사항 한 줄이 견적을 바꿔요 — 롯데·캐논·코닥 사례

8. 자주 묻는 질문

개발 외주 업체 추천해주세요, 라고 물으면 어디서 답을 얻을 수 있나요?

추천을 받는 것보다 추천을 검증할 기준을 먼저 갖는 쪽이 빨라요. 같은 이름을 서너 곳에서 듣더라도 그 업체가 우리와 비슷한 조건의 프로젝트를 해봤는지는 여전히 모르거든요. 이름을 모았으면 이 글의 3단계(공개 자료 확인)와 4단계(수행 역할 확인)를 그대로 적용해 보세요. 세 곳만 돌려도 절반은 걸러져요. 지인 추천은 후보를 좁히는 데는 좋지만, 그 자체가 검증은 아니에요.

기업을 위한 ai·gen ai 개발 외주를 맡기려면 어떻게 해야 하나요?

AI 쪽은 레퍼런스가 쌓일 시간이 짧아서 같은 방식으로는 검증이 안 돼요. 그래서 완성된 결과물 대신 과정을 보는 편이에요. 어떤 모델을 왜 골랐는지, 답이 틀렸을 때 어떻게 잡아냈는지, 운영 비용을 어떻게 추정했는지를 물어보세요. 화면을 보여 달라고 하면 어디든 보여줄 수 있지만, 실패했던 케이스와 그때의 판단을 설명하는 건 실제로 해본 팀만 할 수 있어요.

레퍼런스로 적힌 회사에 직접 연락해도 실례가 아닐까요?

실례가 아니고, 개발사에 먼저 요청하면 대부분 연결해 줘요. 공개된 고객사라면 담당자 연결을 부탁하고, 어려우면 서면 답변이라도 받아 보세요. 다만 연결을 받았다면 질문은 짧게, 세 개 정도로 준비하는 게 좋아요. 일정이 밀린 적이 있었는지, 오픈 후에도 연락이 됐는지, 다시 맡길 의향이 있는지. 이 셋이면 대체로 필요한 답이 나와요.

9. 마무리

레퍼런스 확인은 다섯 단계로 줄어요. 포트폴리오로 후보를 좁히고, 공개 자료로 실적과 생존을 확인하고, 수행 역할을 묻고, 애먹은 지점을 듣고, 실제 투입될 사람을 만나 보는 것.

이 중 두 번째와 세 번째는 미팅 없이도 할 수 있어요. 시간도 반나절이면 끝나요. 그런데 이 반나절을 건너뛰면, 나중에 몇 달을 다시 쓰게 되는 경우가 생겨요. 화면이 아니라 그 화면을 만든 조건을 보는 것, 그게 레퍼런스를 읽는 방법이에요.