분석 프로그램 외주 개발 — '뭘 보고 싶은지'부터 정하셨나요? [2026]

이 글을 쓴 사람: 외주 개발사 대표 (공학박사, 개발 경력 18년)

"분석 프로그램 만들어 주세요"라는 의뢰를 여러 번 받았습니다. 부동산 투자 분석, 방문간호 경영관리 BI, 수면 데이터 대시보드 — 도메인은 다 달랐지만, 매번 같은 곳에서 막혔습니다. 이 글은 그 경험을 정리한 것입니다.

※ 이 글에 등장하는 사례는 실제 프로젝트를 바탕으로 하되, 고객사 정보 보호를 위해 업종·규모·기능 등을 각색했습니다.

솔직히 말씀드리면, "분석 프로그램"이라는 분야는 따로 없습니다

검색창에 "분석 프로그램 외주 개발", "데이터 분석 외주 개발", "대시보드 외주 개발"을 치셨을 겁니다. 그러면 BI 시스템·데이터 시각화 전문 업체가 따로 있고, 그 업체에 맡기면 될 거라고 생각하실 수 있습니다.

솔직히 말씀드리면, 만드는 입장에서는 그런 구분이 크지 않습니다.

저희가 받아본 의뢰 중에 "분석 프로그램"이라고 적혀 있던 것들은 실제로는 이런 일들이었습니다:

• 공공데이터 수십 종을 모아 점수화하고 지도에 표시하는 일
• 수십 개 엑셀로 들어온 운영 데이터를 묶어 경영 대시보드로 만드는 일
• 외부 디바이스에서 오는 실시간 데이터를 받아 임상 운영자 화면에 보여주는 일

이걸 셋 다 "분석 프로그램"이라고 부릅니다. 그리고 셋 다 일이 갈리는 곳은 똑같습니다.

데이터가 어디서 오는지, 누구에게 무엇을 보여줄지, 어떤 판단을 도와줄지 — 이 셋 중 하나라도 모호하면 견적의 절반은 "버퍼"가 됩니다.

아래에서 실제 사례 3건으로 보여드립니다.

사례 1: 부동산 투자 적합성 분석 — "수집"이 분석의 70%였습니다

의뢰

택지개발지구 정보를 자동으로 모아 투자 적합성을 점수화하고, 지도에서 필터로 탐색할 수 있게 해 달라.

입력 — 공공데이터 + 웹 스크래핑

이런 프로젝트의 첫 질문은 항상 똑같습니다. "데이터가 어디서 오나요?"

이 경우엔 LH·국토부 등 공공데이터와 부동산 정보 사이트 스크래핑 조합이었습니다. 이게 핵심입니다 — 공공데이터는 받는 게 끝이 아니라, 받은 다음에 시작입니다.

• 같은 "택지지구"가 기관마다 이름이 다릅니다
• 좌표가 결측값으로 들어옵니다
• 동명이인·동명지역 이슈가 있습니다
• 갱신 주기가 자료마다 다르고, 일부는 비정형(PDF·표 이미지)입니다

스크래핑도 마찬가지입니다. 사이트 구조가 바뀌면 그날 모든 게 멈춥니다.

산출물 — 지도 + 필터

요청은 "지도에서 조건별로 필터링하면서 점수 높은 지구를 빠르게 찾고 싶다"였습니다. NLP·ML로 점수를 산출하고, 그 결과를 지도에 띄우는 구조였습니다.

만들고 보니 화면 자체는 어렵지 않았습니다.

진짜 어려웠던 부분 — "수집·정제가 끝이 없었다"

전체 개발 기간을 돌이켜 보면, 분석 로직 자체보다 수집·정제 작업이 70% 이상이었습니다.

• 한 데이터셋에서 결측값 보정 룰을 만들고 나면, 다른 데이터셋에서 또 새 룰이 필요
• 데이터 소스가 한두 개 추가될 때마다 그동안 짜놓은 통합 룰이 깨짐
• 운영 시작 후에도 "데이터가 안 들어와요" 문의가 끝나지 않음

ML 모델 자체는 결국 깔끔하게 학습됐습니다. 하지만 "이 모델이 잘 돌아간다"는 것과 "분석 프로그램이 잘 돌아간다"는 같은 말이 아닙니다. 후자는 입력 파이프라인이 무너지지 않아야 가능합니다.

여기서 배운 것: 분석 프로그램의 견적에서 "데이터 수집·정제" 비중을 작게 잡으면 거의 무조건 일정이 밀립니다. 분석 로직 1, 수집·정제 2~3 정도가 현실적인 비율입니다.

사례 2: 방문간호센터 경영관리 BI — "뭘 보고 싶은지"가 정해지지 않았던 프로젝트

의뢰

방문간호센터 운영자가 경영 판단을 내릴 수 있게 BI 대시보드를 만들어 달라. 원가·매출 구조 분석 기반 의사결정 지원.

입력 — 공단 데이터 수십 개 엑셀

이번에도 첫 질문은 데이터였습니다. 답은 "공단에서 정기적으로 받는 엑셀 수십 종". 운영 시스템에 통합 입력 폼이 있는 게 아니라, 분석을 위해 별도로 수집되는 데이터였습니다.

데이터끼리 어떤 관계가 있는지, 어디서 어떤 키로 연결되는지부터 저희가 직접 파악해야 했습니다. 그 자체가 별도 프로젝트였습니다.

진짜 어려웠던 부분 — 의뢰자가 뭘 보고 싶은지 정해지지 않았습니다

이건 솔직하게 말씀드려야 하는 부분입니다.

이 프로젝트는 운영 단계가 아니라 연구 목적이었습니다. 클라이언트도 "이 데이터로 뭘 봐야 의미가 있는지" 명확히 알지 못한 상태였습니다. 원가·매출 구조 분석이라는 큰 방향만 있고, 구체적인 KPI·뷰는 비어 있었습니다.

그래서 결국 저희가 가설을 세우고, 화면을 그리고, 클라이언트와 토의하면서 수정하기를 반복했습니다. 의료·돌봄 도메인 지식과 경영 분석 프레임을 학습해 가며, 의미 있는 결과를 "추측해서" 만들었다고 해도 틀리지 않습니다.

이게 분석 프로그램 외주에서 가장 자주 일어나는 일이고, 견적이 흔들리는 가장 큰 이유이기도 합니다. 클라이언트가 정확히 설계해서 와도 수정이 많은데, 그게 아니면 우리가 추측해서 만들고 다시 갈아엎기를 반복합니다.

→ 그래서 분석 프로그램 견적에는 "불확실성 버퍼"가 다른 분야보다 크게 들어갑니다. 이건 업체가 게을러서가 아닙니다.

여기서 배운 것: "BI를 만들어 달라"는 의뢰는 사실 "우리 회사에 어떤 BI가 필요한지 같이 정의해 달라"인 경우가 절반 이상입니다. 그건 별도의 작업이고, 별도의 비용입니다.

사례 3: 웨어러블 임상 모니터링 대시보드 — "분석처럼 보이지만 사실 운영 모니터링"

의뢰

수면 케어 대상자가 단일 모델 웨어러블 디바이스로 수집한 데이터를 임상 운영자 화면에서 보고, 수면 행동 치료 프로그램 진행 상황을 추적하게 해 달라.

입력 — 웨어러블 디바이스 API + 참여자용 앱

다행히 디바이스가 한 모델로 통일돼 있어서, "모델별로 수면 스테이지 정의가 다르다"는 흔한 함정은 피했습니다. 임상 연구 환경이라 디바이스 통제가 가능했던 게 컸습니다.

산출물 — 임상 운영자용 대시보드

임상 운영자가 대상자 일자별 수면 점수·각성 시간·취침/기상 시각·중간 깨어남 등을 빠르게 훑을 수 있는 화면이 핵심이었습니다.

분석 로직 자체는 사실 단순했습니다. 알고리즘이 어려운 게 아니었습니다.

진짜 어려웠던 부분 — "데이터가 잘 들어오고 있나"를 보는 일

진짜 일은 운영 단계에 있었습니다.

• 대상자가 웨어러블 착용을 거른 날이 있는지
• API 연동이 끊긴 대상자가 있는지
• 수집은 됐는데 데이터가 비정상인지 (예: 24시간 내내 깊은 수면)
• 수집이 안 된 대상자에게 어떻게 안내·재요청을 보내는지
• 연동이 풀린 대상자(재로그인 필요)를 어떻게 식별·복구하는지

분석 프로그램은 만들고 끝이 아니라, 데이터가 계속 들어와야 살아 있는 시스템입니다. 외주 견적을 받을 때 이 운영 단계가 얼마나 포함돼 있는지를 꼭 확인하세요. 화면만 만들고 끝나는 견적은 운영 시작 후에 "추가 요청"으로 쌓입니다.

여기서 배운 것: 데이터가 외부에서 들어오는 분석 프로그램은 절반 이상이 "수집 모니터링" 시스템입니다. 그 부분이 견적에 들어가 있는지 확인하세요.

분석 프로그램 견적이 갈리는 변수

세 사례에서 공통으로 보이는 변수가 있습니다:

위 네 가지는 다른 분야 외주에서도 동일하게 작용하는 "기본"입니다.

다섯 번째 — 요구사항 명확도 — 이게 분석 프로그램에서 유독 큽니다.

다른 외주는 보통 "로그인 화면, 회원가입, 게시판"처럼 결과물 형태가 머릿속에 그려집니다. 분석 프로그램은 그게 안 됩니다. "데이터를 보고 뭔가 알고 싶다"가 출발인데, 그 '뭔가'가 정해지지 않은 채 시작되는 경우가 절반 이상입니다.

그래서 분석 프로그램 견적에는 불확실성 버퍼가 크게 들어갑니다.

구체적인 비용 구조는 소프트웨어 외주 개발 비용 가이드를 참고하세요.

AI로 직접 만들 수는 없을까

GPT·Claude·Cursor가 코딩을 도와주는 시대입니다. "분석 프로그램도 의뢰자가 직접 만들 수 있지 않을까" 하는 질문을 자주 받습니다.

저희 입장에서 솔직히 말씀드리면:

AI로 가능한 것

• 일회용 탐색 — "이 엑셀에서 X 트렌드 뽑아 줘" 수준은 GPT·Claude로 충분합니다. 외주를 맡길 일이 아닙니다.
• 프로토타입 — 데이터 한 종을 받아서 화면 한두 개로 보여주는 PoC는 AI 도구로 충분히 만들 수 있습니다. 도메인을 가장 잘 아는 의뢰자가 직접 만드는 게 빠르기도 합니다.

AI로는 잘 안 되는 것

• 데이터 파이프라인 — 여러 소스를 안정적으로 받아오고, 갱신·예외·중복·결측을 처리하고, 운영 환경에서 멈추지 않게 유지하는 일. "눈에 보이지 않는 부분"이 80%인 영역입니다.
• 권한·보안·운영 도구 — 누가 무엇을 볼 수 있는지, 감사 로그, 백업, 장애 대응. PoC에는 없어도 되지만 서비스에는 필수.
• 데이터의 의미 파악 — AI가 코드를 짜 주는 것과, 그 데이터가 도메인에서 무엇을 뜻하는지 판단하는 건 다른 일입니다. 이건 여전히 사람의 영역이고, 의뢰자 본인의 영역이기도 합니다.

요컨대 프로토타입과 서비스화는 다른 프로젝트입니다.

요즘 들어 자주 받는 의뢰가 있습니다. 연구팀이나 사내 분석가가 AI 도구로 만든 PoC를 가져와 **"이걸 그대로 서비스화해 주세요"**라고 하시는 경우입니다. 화면도 작동하고, 결과도 그럴듯하게 나오니까요.

그런데 PoC와 서비스화는 사실상 다른 프로젝트입니다. PoC에서는 "한 명이 / 깨끗한 데이터 한 종으로 / 한 번만 돌려본" 결과이고, 서비스화는 거기에 데이터 파이프라인·예외 대응·권한·보안·재학습·운영 모니터링이 모두 더해진 결과입니다. PoC 만든 분이 알기 어려운 80%의 작업량이 그 사이에 들어 있습니다. 그래서 외주 견적이 PoC 비용 대비 훨씬 크게 나오는 게 정상입니다.

AI가 외주 단가 구조 자체를 어떻게 바꾸고 있는지는 AI 시대 외주 개발 단가에서 따로 정리했습니다. 직접 만들지 외주를 맡길지 판단이 필요하시다면 바이브코딩과 외주 개발을 함께 보세요.

외주 맡기기 전에 의뢰자가 정리하면 좋은 것

분석 프로그램 견적이 흔들리는 가장 큰 변수가 "뭘 보고 싶은지 모름"이라고 말씀드렸습니다. 그렇다고 다 정리해서 와야 한다는 뜻은 아닙니다.

저희는 생각만 가져와도 클라이언트와 같이 정리해서 만듭니다. "같이 만들어 가는" 쪽에 가깝습니다. 다만 다음 세 가지에 대한 답변을 미리 준비해 오시면 견적·일정이 훨씬 단단해집니다:

1. 데이터가 어디서 오는가

• 자체 시스템 DB / 엑셀로 정기 수신 / 외부 API / 디바이스·센서 / 아직 수집 안 됨
• 갱신 주기 (실시간 / 일별 / 월별 / 1회성)
• 형식 일관성 (잘 정제됨 / 일부 비정형 / 사람이 손으로 정리)

2. 누구에게 무엇을 보여주는가

• 사용자 (경영자 / 분석가 / 현장 운영자 / 외부 보고용 / 고객)
• 결과물 형태 (대시보드 화면 / 자동 PDF 리포트 / 알림 / 데이터 export)
• 결정 주체 (사람이 보고 판단 / 시스템이 자동 판단·알림)

3. 운영 기간

• 1회성 분석 (보고서 한 번 만들고 끝)
• 지속 운영 (매일·매주 갱신, 데이터 변화에 대응)
• 후자라면 데이터 수집이 끊겼을 때 어떻게 처리할지가 견적의 별도 항목이 됩니다

세 가지 모두 "잘 모르겠다"여도 괜찮습니다. 그 상태가 출발점이라는 걸 미리 공유해 주시면, 첫 단계로 요구사항 정리 워크숍을 견적에 포함시키는 식으로 풀어 갑니다.

자주 묻는 질문

Q. 데이터가 아직 없어요. 분석 프로그램부터 만들 수 있나요?

데이터 수집부터 같이 합니다. 다만 그건 "분석 프로그램 개발"이 아니라 "데이터 수집 + 분석 프로그램 개발" 두 단계 프로젝트입니다. 견적·일정도 그렇게 분리됩니다. 장비·센서에서 수집해야 한다면 장비 연동·데이터 수집 가이드를 함께 참고하세요.

Q. 셀프서비스 BI(Tableau, Looker, Power BI 등)로 가는 게 낫지 않나요?

쓰는 사람이 한정적이고, 들여다볼 데이터가 정제된 단일 소스라면 셀프서비스 BI가 더 빠르고 저렴할 수 있습니다.

반대로 사용자가 도메인 비기술자이고, 데이터가 여러 소스에서 비정형으로 들어온다면, 셀프서비스 BI를 도입해도 결국 그 앞에서 데이터 준비를 해주는 시스템이 필요합니다. 그 부분은 외주가 맞을 수 있습니다.

Q. ML/AI 모델까지 같이 만들 수 있나요?

가능합니다. 다만 ML 모델 정확도는 데이터 품질·양에서 결정됩니다. 데이터 인프라가 약한 상태에서 모델 정확도부터 요구하시는 경우, 저희는 보통 **"수집·정제부터 단단히 한 다음에 모델로 넘어가시죠"**라고 말씀드립니다. 순서를 거꾸로 하면 결과 모델은 잘 나와도 운영에서 무너집니다.

Q. 견적은 얼마나 나오나요?

분야 평균 단가는 비용 가이드를 참고하세요. 분석 프로그램은 위에서 말씀드린 "불확실성 버퍼"가 다른 분야보다 크게 들어갑니다. 요구사항을 같이 정리하는 과정이 견적 정확도를 가장 크게 올립니다. 첫 미팅에서 견적이 확정되기 어렵다는 점만 미리 양해해 주세요.

Q. 운영 중에 분석 로직을 자주 바꿔야 하는데, 매번 외주를 맡겨야 하나요?

쿼리·필터·집계 기준 정도는 화면에서 직접 바꿀 수 있게 설계할 수 있습니다. 다만 "어디까지를 사용자가 만지고, 어디부터 개발자가 만지게 할지"를 처음에 정해야 합니다. 모든 걸 사용자 손에 맡기면 운영 부담이 사용자에게 옮겨갈 뿐입니다.

마무리

정리하면 이렇습니다:

1. "분석 프로그램"이라는 분야는 사실 따로 없습니다. 데이터·가공·표현 셋이 정해지면 그게 분석입니다.
2. 수집·정제가 분석의 70%를 차지하기도 합니다. 모델보다 파이프라인을 먼저 보세요.
3. "뭘 보고 싶은지"가 견적의 가장 큰 변수입니다. 모호하면 버퍼가 크게 들어갑니다.
4. 프로토타입과 서비스화는 다른 프로젝트입니다. AI로 만든 PoC를 그대로 운영할 수 있다고 가정하지 마세요.
5. 운영 단계의 데이터 무결성까지 견적에 포함됐는지 확인하세요.

저희는 생각만 가져와도 클라이언트와 같이 정리해서 만듭니다. 분석 프로그램은 외주 업체가 답을 가지고 있는 분야가 아니라, 같이 답을 만들어 가는 분야입니다. 그래서 명확한 RFP가 없어도 괜찮습니다.

비용이 궁금하시면 SW 외주 개발 비용 가이드를, 데이터 수집·장비 연동이 핵심이라면 장비 연동·데이터 수집 외주 개발 가이드를, 데스크톱 분석 도구가 필요하다면 윈도우 프로그램 외주 개발 가이드를 참고하세요. 외주 절차 전체가 궁금하시면 SW 외주 개발 절차 총정리도 함께 보세요.

궁금한 점 있으시면 편하게 문의해 주세요. 상담은 무료입니다.

소프트웨어 개발 의뢰가 처음이시라면 소프트웨어 개발 의뢰 가이드에서 전체 흐름을 먼저 확인해 보세요.

About

Things workshop (띵스워크샵)

2020년 설립, 소프트웨어 개발 전문 기업입니다.

"안 된다는 말 대신 방법을 찾습니다."

📧 contact@thingsw.com 📞 032-889-0410 🌐 thingsw.com