# 소프트웨어 개발 회사는 어떻게 선택해야 합니까?

부다페스트의 소프트웨어 개발 회사인 Mesterséges Intelligencia Központ Kft.는 좋은 선택이 세 가지 질문에 달려 있다고 봅니다. 개발사가 목표를 이해하는지, 견적을 검증할 수 있는지, 그리고 인도 후 코드와 시스템이 누구의 소유가 되는지입니다.

> **핵심:** 먼저 목표와 필수 요구사항을 적고, 그다음에 견적을 요청하시기 바랍니다. 실제로 작동하는 결과물, 투명한 진행 방식, 코드에 대한 접근 권한을 요구하는 것이 좋으며, 견적은 같은 항목별 명세를 기준으로, 가능하면 측정된 규모로 비교해야 합니다. 계약서에는 소스 코드와 이용 권리, 비밀 유지, 오류 수정, 운영, 그리고 계약 종료 시의 절차도 명시해야 합니다.

## 목표가 먼저입니다: 소프트웨어는 무엇을 할 수 있어야 합니까?

잘못된 선택의 대부분은 개발사가 아니라 모호한 의뢰에서 시작됩니다. 소프트웨어가 무엇을 할 수 있어야 하는지 적혀 있지 않으면 견적마다 의미가 달라지고, 가격도 완성된 결과물도 무엇에 비추어 평가할 기준이 없게 됩니다. 완성된 명세가 필요한 것은 아니지만(좋은 개발사는 명세 작성을 돕습니다), 몇 가지는 미리 생각해 두는 것이 좋습니다.

- **목표:** 소프트웨어가 어떤 문제를 해결하는지, 그리고 무엇을 보고 성공했다고 판단할 것인지.
- **사용자:** 내부 직원, 고객, 파트너 중 누가 사용하는지.
- **필수 요구사항:** 이것 없이는 시작할 수 없는 것. “있으면 좋은” 항목과 구분합니다.
- **기존 시스템:** 무엇과 연결되어야 하는지(ERP, CRM, 온라인 쇼핑몰, 청구서 발행 프로그램, 은행).
- **데이터:** 개인정보를 포함해 어떤 데이터를 다루는지.
- **제약 조건:** 정해진 마감일, 내부 규정, 호스팅이나 보안에 관한 요구가 있는지.

애초에 맞춤형 개발이 필요한지, 아니면 기성 제품이나 기성 제품과 맞춤형 확장의 조합으로도 충분한지도 정해 두는 것이 좋습니다. 이 판단에는 [맞춤 소프트웨어와 기성 솔루션(SaaS) 중 어느 쪽이 맞습니까?](https://www.mestersegesintelligenciakozpont.hu/ko/knowledge-base/custom-software-vs-off-the-shelf) 글이 도움이 됩니다.

## 후보 좁히기: 어떤 회사에 연락해야 합니까?

많은 회사에 연락할 필요는 없습니다. 신중하게 고른 몇몇 후보가 피상적인 견적 여러 개보다 낫습니다. 후보를 좁히는 기준은 다음과 같습니다.

- **비슷한 작업:** 업무용 소프트웨어, 온라인 쇼핑몰, 모바일 앱, AI 통합 등 비슷한 규모와 성격의 시스템을 만들어 본 적이 있는지.
- **기술 적합성:** 기존 시스템과 연결하는 데 필요한 기술을 다루는지.
- **규모의 균형:** 회사의 역량이 프로젝트에 맞는지. 큰 시스템에는 여러 전문 분야가 필요하고, 작은 과제에는 그보다 적게 필요합니다.
- **언어와 연락 가능성:** 귀사의 언어로, 귀사의 시간대에 맞춰 협의할 수 있는지.

## 작업 결과물과 레퍼런스 확인

가장 강력한 증거는 실제로 작동하는 소프트웨어입니다. 후보 회사에 직접 사용해 볼 수 있는 시스템을 보여 주고, 그 안에서 자신들이 맡은 부분이 정확히 무엇이었는지 설명해 달라고 요청하십시오. 많은 고객 프로젝트가 비밀 유지 의무로 보호되므로 항상 이름을 밝힐 수는 없습니다. 그럴 때는 익명화한 설명, 시연, 또는 회사의 자체 제품도 많은 것을 알려 줍니다.

이전 고객이 레퍼런스를 제공한다면 구체적으로 물어보는 것이 좋습니다. 합의한 범위를 지켰는지, 변경과 오류를 어떻게 처리했는지, 소스 코드를 받았는지, 그리고 지금도 함께 일하는지입니다. “만족했습니다” 같은 일반적인 답은 알려 주는 것이 별로 없지만, 고객이 인도 후에도 그 회사와 함께 시스템을 운영하고 있다는 사실은 많은 것을 말해 줍니다.

## 기술 면담

후보마다 기술 면담을 한 번씩 하는 것이 좋으며, 가능하면 귀사 측에서도 기술 전문가가 참석하는 것이 좋습니다. 중요한 것은 답변이 얼마나 자신 있게 들리는가가 아니라, 개발사가 질문을 하는지, 그리고 위험 요소를 짚어 내는지입니다. 좋은 질문은 다음과 같습니다.

- 어떻게 착수할 것이며, 첫 단계는 무엇입니까?
- 저희 기존 시스템은 어떻게 연결할 것이며, 그 시스템에 관해 무엇을 알아야 합니까?
- 테스트는 어떻게 하며, 한 부분이 완료되었는지는 누가 결정합니까?
- 누가 프로젝트를 맡아 일하며, 저희와 연락할 담당자는 누구입니까?
- 시스템은 어디에서 실행되며, 보안 업데이트는 누가 책임집니까?
- 인공지능도 들어간다면, 어떤 데이터가 어디로 가며, AI가 틀리면 어떻게 됩니까?

후보가 질문 하나 없이 첫 대화 직후에 정확한 가격과 마감일을 제시한다면 경고 신호입니다.

## 진행 방식과 소통

소프트웨어 개발에서 예상치 못한 문제는 코드보다 소통에서 생기는 경우가 훨씬 많습니다. 그래서 진행 중에 진척 상황을 어떻게 확인할 수 있는지 물어보는 것이 좋습니다. 좋은 관행의 특징은 다음과 같습니다.

- **단계별 개발:** 작업을 단계로 나누고, 각 단계가 끝날 때 보고서만이 아니라 실제로 작동하는 소프트웨어를 보여 줍니다.
- **코드 접근:** 고객이 인도 시점에야 받는 것이 아니라 첫날부터 코드 저장소(repository)를 볼 수 있습니다.
- **추적 가능한 작업 목록:** 작업, 오류, 변경 사항이 공동으로 관리하는 목록에서 보입니다.
- **고정된 담당자:** 프로젝트를 알고 결정을 내릴 수 있는 사람이 한 명 있습니다.
- **변경 관리:** 새로운 요구나 바뀐 요구는 기술하고, 측정하거나 추정한 뒤, 승인을 받은 후에만 작업에 반영합니다.

## 견적 비교

두 견적은 같은 범위를 대상으로 할 때만 비교할 수 있습니다. 그러므로 모든 후보가 같은 항목별 설명을 받아야 하며, 어떤 기능과 어느 정도의 규모를 기준으로 가격을 제시했는지 요청하시기 바랍니다. 개발사가 소프트웨어의 기능 규모를 표준 방법, 예를 들어 COSMIC 기능점수로 측정한다면 같은 명세로 규모를 검증할 수 있습니다. 이 방법은 [COSMIC 기능점수란 무엇입니까?](https://www.mestersegesintelligenciakozpont.hu/ko/knowledge-base/cosmic-function-points) 글에서 소개합니다.

두 견적 사이에 차이가 크다면 다음을 물어보는 것이 좋습니다.

| 질문 | 알 수 있는 것 |
|---|---|
| 가격은 어느 정도의 규모와 어떤 기능을 기준으로 합니까? | 같은 범위에 가격을 매겼는지 |
| 별도 항목으로 표시된 것은 무엇입니까? | 연동, 데이터 이전, 그래픽, 운영이 포함되어 있는지 |
| 어떤 비기능 요구사항을 고려했습니까? | 성능, 보안, 접근성 |
| 변경은 어떻게 처리합니까? | 진행 중에 새로운 요구가 생기면 어떻게 되는지 |
| 인도 후 오류 수정은 어떤 방식으로 이루어집니까? | 요금에 무엇이 포함되고, 무엇이 별도 작업으로 계산되는지 |
| 소스 코드는 누구의 소유가 되며, 저희는 어떤 권리를 받습니까? | 다른 회사와 함께 시스템을 이어 갈 수 있는지 |
| 정산은 고정 가격입니까, 투입 공수 기준입니까? | 범위에 대한 위험을 누가 부담하는지 |

고정 가격은 범위가 항목별로 확정되어 있을 때 잘 작동합니다. 투입 공수 기준 정산은 더 유연하지만, 범위에 대한 위험은 고객에게 남습니다. 어느 경우든 중요한 것은 범위를 측정하고 추적할 수 있어야 한다는 점입니다. 저희가 가격을 매기는 방식은 [비용 산정](https://www.mestersegesintelligenciakozpont.hu/ko/pricing) 페이지에서 설명합니다.

## 계약서의 핵심 사항

분쟁이나 예기치 않은 상황에서 중요한 것은 계약서입니다. 아래 내용은 정보 제공을 위한 것이며 법률 자문이 아닙니다. 계약서는 변호사에게도 검토를 받는 것이 좋습니다.

### 소스 코드와 이용 권리

헝가리 저작권법([1999년 법률 제LXXVI호](https://njt.hu/jogszabaly/1999-76-00-00), 헝가리어)은 컴퓨터 프로그램 저작물을 소스 코드와 목적 코드 모두에서 저작물로 보호하며(제1조 제2항 (c)호), 소프트웨어에 대한 저작재산권은 양도할 수 있다고 규정합니다(제58조 제3항). 따라서 고객은 저작재산권을 취득하거나, 이용허락(라이선스)을 받습니다. 이 둘은 같지 않습니다.

정확한 표현이 중요한 이유가 되는 몇 가지 규정이 있습니다. 이용허락 계약은 명시적으로 약정한 경우에만 독점적 권리를 부여합니다(제43조 제1항). 계약이 이용 방법과 범위를 정하지 않으면, 이용허락은 계약 목적에 반드시 필요한 범위로 제한됩니다(제43조 제5항). 내용이 명확하지 않으면 저작자에게 더 유리한 해석을 따라야 합니다(제42조 제3항). 그리고 이용권자는 저작자의 명시적 허락이 있어야만 제3자에게 다시 이용을 허락할 수 있습니다(제46조 제1항). 따라서 다음 사항을 명시하는 것이 좋습니다.

- 전체 소스 코드와 문서의 인도(단계별 인도 포함)
- 고객이 저작재산권을 취득하는지, 아니면 어떤 범위의 이용허락을 받는지(독점적인지, 수정할 수 있는지, 제3자에게 넘길 수 있는지)
- 개발사가 직원과 하도급업체가 작성한 코드에 대한 권리를 보유하고 있다는 점
- 사용된 오픈 소스 구성 요소와 제3자 구성 요소의 목록 및 라이선스

### 비밀 유지(NDA)

아이디어나 비즈니스 데이터가 기밀이라면, 세부 사항을 논의하기 전에 비밀유지계약(NDA)을 맺는 것이 좋습니다. 계약에는 무엇이 기밀 정보에 해당하는지, 누가 알 수 있는지, 비밀 유지 의무가 얼마나 지속되는지, 작업이 끝나면 자료를 어떻게 처리하는지를 명시하십시오.

### 오류 수정과 하자 보증

계약서에는 무엇을 오류로 보는지(명시된 요구사항과의 차이), 인수 테스트를 어떻게 진행하는지, 어떤 심각도 등급이 있는지, 각 등급에 개발사가 얼마나 빨리 대응하는지를 정해야 합니다. 인도 시점에 드러나지 않았던 오류를 얼마 동안 무상으로 수정하는지, 그리고 무엇부터 추가 개발로 보는지도 명시하십시오.

### 운영과 SLA

개발사가 인도 후에도 시스템을 운영한다면, 서비스 수준 계약(service level agreement, SLA)이 조건을 정합니다. 약정 가용성, 장애 신고 방법, 심각도별 대응 시간과 해결 시간, 유지보수 시간대, 백업, 보고가 그것입니다. 문서로 남기지 않은 것은 분쟁 시 요구할 수 없습니다.

### 종료 계획(exit plan)

종료 계획은 불만족 때문이든 개발사가 폐업했기 때문이든, 개발사와의 협력을 이어 가지 않을 때 어떻게 되는가라는 질문에 답합니다. 구성 요소는 다음과 같습니다.

- 설치, 아키텍처, 운영에 관한 최신 문서
- 고객 명의로 되어 있거나 최소한 고객이 접근할 수 있는 코드 저장소, 호스팅, 도메인, 클라우드 계정
- 비밀번호와 접근 키의 인계 절차
- 표준 형식으로 데이터를 내보낼 수 있는 기능
- 새 개발사로의 인계 협력

### 데이터 보호: 데이터 처리 계약

개발사가 작업 중에 개인정보에 접근한다면, 예를 들어 시스템을 운영하거나 실제 데이터로 테스트한다면, GDPR상 일반적으로 데이터 처리자에 해당하며 개발사와 서면 데이터 처리 계약을 맺어야 합니다([GDPR 제28조](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)). 이 계약에는 개발사가 고객의 문서화된 지시에 따라서만 데이터를 처리하고, 비밀 유지와 보안을 보장하며, 허가를 받은 경우에만 하위 처리자를 이용하고, 서비스가 끝나면 데이터를 삭제하거나 반환하며, 감사를 허용한다는 내용 등이 담겨야 합니다.

## 보안 관행

보안은 나중에 소프트웨어에 덧붙일 수 없으므로, 개발사가 보안을 어떻게 다루는지 물어보는 것이 좋습니다. 좋은 출발점은 웹 애플리케이션의 가장 심각한 보안 위험을 정리한, 널리 알려진 목록인 [OWASP Top 10](https://owasp.org/www-project-top-ten/)입니다. 현재 유효한 판은 OWASP Top 10:2025입니다(2026년 10월 17일 확인). 1위부터 3위까지는 취약한 접근 통제, 보안 설정 오류, 소프트웨어 공급망 결함입니다. 다음을 물어보십시오.

- 권한은 어떻게 관리하며, 사용자가 자신의 데이터만 볼 수 있는지 어떻게 테스트합니까?
- 사용하는 외부 라이브러리는 어떻게 업데이트하며, 그중 하나에 취약점이 있다는 것을 어떻게 알게 됩니까?
- 비밀번호와 키는 어디에 보관하며, 누가 접근할 수 있습니까?
- 코드 리뷰(code review)와 자동화된 테스트가 있습니까?
- 백업은 어떻게 하며, 복원을 실제로 시도해 본 적이 있습니까?

## 프리랜서와 개발 회사 중 어느 쪽이 맞습니까?

어느 쪽이든 좋은 선택이 될 수 있습니다. 관건은 과제가 얼마나 크고 시스템이 얼마나 오래 쓰일 것인가입니다.

| 기준 | 프리랜서 | 개발 회사 |
|---|---|---|
| 소통 | 한 사람과 직접 | 담당자를 통해, 여러 전문가와 |
| 전문 분야 | 한 사람의 역량 | 여러 전문 분야: 화면, 백엔드, 모바일, 운영, 테스트 |
| 대체 가능성 | 질병이나 이탈 시 작업이 멈춤 | 팀원이 서로의 작업을 넘겨받을 수 있음 |
| 처리 능력 | 작고 범위가 명확한 과제에 적합 | 큰 시스템, 병행 작업에 적합 |
| 계약 | 전문가와 직접 | 팀의 작업에 책임을 지는 회사와 |
| 장기 운영 | 프리랜서의 연락 가능 여부에 달려 있음 | 조직적으로 맡을 수 있음 |

프리랜서는 범위가 명확한 과제에 잘 맞으며, 특히 고객 측에 작업을 지휘하고 넘겨받을 자체 기술 책임자가 있을 때 그렇습니다. 시스템이 회사의 일상 운영의 일부이고, 여러 전문 분야가 필요하며, 수년간 운영될 것이라면 일반적으로 개발 회사 쪽이 위험이 더 작습니다. 종료 계획과 소스 코드 인도는 두 경우 모두 똑같이 중요합니다.

## 경고 신호

- 질문 없이 첫 대화 직후에 제시되는 정확한 가격과 마감일.
- 서면 명세가 없거나, 견적이 무엇을 대상으로 하는지 밝히지 않음.
- 고객이 코드를 볼 수 없고, 인도 시점에야 받게 됨.
- 누가 프로젝트에서 일할지에 대한 모호한 답변.
- 소스 코드가 누구의 소유가 되는지, 고객이 어떤 권리를 받는지 분명하지 않음.
- 데이터 처리 계약이나 비밀유지계약을 거부함.
- 보여 줄 수 있는, 실제로 작동하는 결과물이 없음.

## 체크리스트

| 질문 | 이런 경우 문제없음 |
|---|---|
| 목표와 필수 요구사항이 문서로 정리되어 있습니까? | 모두가 같은 뜻으로 이해하는 짧은 설명이 있음 |
| 실제로 작동하는 결과물을 보았습니까? | 비슷한 시스템을 하나 이상 직접 사용해 봄 |
| 과제를 이해하고 있습니까? | 질문을 했고 위험 요소를 짚었음 |
| 진척 상황을 볼 수 있습니까? | 단계별 시연, 코드 저장소 접근 |
| 견적을 비교할 수 있습니까? | 같은 항목별 범위를 대상으로 하며, 별도 항목이 드러나 있음 |
| 소스 코드와 권리 문제가 정리되어 있습니까? | 계약서에 인도와 권리의 범위가 명시되어 있음 |
| 비밀유지계약과 데이터 처리 계약이 있습니까? | 필요한 곳에서 서명함 |
| 오류 수정과 운영이 정해져 있습니까? | 심각도 등급, 대응 시간, SLA |
| 종료 계획이 있습니까? | 문서, 접근 권한, 데이터 내보내기 |
| 보안에 관해 물어보았습니까? | 권한, 업데이트, 백업에 대한 구체적인 답변 |

## 자주 묻는 질문

### 프리랜서와 개발 회사 중 어느 쪽이 맞습니까?

범위가 명확하고 작은 과제라면 경험 많은 프리랜서도 좋은 선택이 될 수 있으며, 특히 회사에 자체 기술 책임자가 있다면 더욱 그렇습니다. 시스템이 일상 운영의 일부이고, 여러 전문 분야가 필요하며, 오랫동안 운영된다면 개발 회사 쪽이 위험이 더 작습니다. 작업이 한 사람에게만 달려 있지 않기 때문입니다.

### 두 견적은 어떻게 비교해야 합니까?

같은 항목별 명세를 기준으로 제출된 견적만 비교할 수 있습니다. 두 견적 제출 업체 모두에게 어느 정도의 규모와 어떤 기능을 기준으로 가격을 제시했는지, 무엇이 별도 항목으로 들어 있는지, 변경을 어떻게 처리하는지 물어보십시오. 규모를 표준 방법, 예를 들어 COSMIC 기능점수로 측정했다면 같은 명세로 검증할 수 있습니다.

### 계약서에는 무엇이 들어가야 합니까?

범위(항목별 명세), 가격과 일정, 소스 코드 인도와 이용 권리의 범위, 비밀 유지, 인수와 오류 수정 절차, 운영과 SLA, 종료 계획, 그리고 개인정보가 관련된다면 데이터 처리 계약입니다. 이 내용은 정보 제공을 위한 것이며 법률 자문이 아닙니다.

### 개발사가 사라지면 어떻게 됩니까?

소스 코드, 문서, 접근 권한이 고객에게 있다면 다른 개발사가 시스템을 넘겨받을 수 있습니다. 그래서 첫날부터 코드 저장소를 볼 수 있게 하고, 호스팅과 도메인을 자사 명의로 두고, 계약서에 종료 계획을 명시하는 것이 좋습니다. 이런 것들이 없으면 시스템을 이어 가기가 어렵고 오래 걸릴 수 있습니다.

### 소스 코드는 누구의 소유가 됩니까?

계약에 따라 권리를 갖는 쪽의 소유가 됩니다. 헝가리 저작권법에 따르면 소프트웨어에 대한 저작재산권은 양도할 수 있지만, 자동으로 양도되지는 않습니다. 계약서에는 고객이 전체 소스 코드를 받는다는 점과, 그에 대해 정확히 어떤 권리를 취득하는지를 명시하는 것이 좋습니다. 저희의 경우에도 소스 코드와 이용 권리는 계약으로 정합니다.

## 저희는 어떻게 도와드립니까?

저희는 이렇게 일합니다. 첫 상담은 무료이며, 명세를 함께 작성하고, 소프트웨어의 규모를 COSMIC 기능점수로 측정한 뒤, 이를 바탕으로 견적과 일정을 작성합니다. 개발은 단계별로 진행되며 각 단계가 끝날 때마다 시연을 합니다. 요청하시면 비밀유지계약(NDA)을 체결하며, 인도 후에는 운영과 유지보수도 맡습니다. 소스 코드와 이용 권리는 계약으로 정합니다. 진행 단계는 [일하는 방식](https://www.mestersegesintelligenciakozpont.hu/ko/how-we-work) 페이지에서, 가격 산정 방법은 [비용 산정](https://www.mestersegesintelligenciakozpont.hu/ko/pricing) 페이지에서 설명합니다.

현재도 대규모 ERP 및 CRM 시스템을 개발하고 있습니다. 직접 사용해 볼 수 있는 자체 개발 제품은 [작업 사례](https://www.mestersegesintelligenciakozpont.hu/ko/our-work) 페이지에서, 회사에 관해서는 [회사 소개](https://www.mestersegesintelligenciakozpont.hu/ko/about) 페이지에서, 자주 묻는 질문에 대한 답은 [자주 묻는 질문](https://www.mestersegesintelligenciakozpont.hu/ko/faq) 페이지에서 보실 수 있습니다. 개발사를 찾고 계시다면 [연락처](https://www.mestersegesintelligenciakozpont.hu/ko/contact) 페이지에 안내된 연락처로 메시지를 보내 주시기 바랍니다.

## 출처

- [헝가리 국가 법령 데이터베이스(Nemzeti Jogszabálytár): 저작권에 관한 1999년 법률 제LXXVI호(헝가리어)](https://njt.hu/jogszabaly/1999-76-00-00)
- [EUR-Lex: 규칙 (EU) 2016/679(일반 데이터 보호 규칙, GDPR)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
- [OWASP: OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP: OWASP Top 10:2025](https://top10.owasp.org/2025/)