앱 MVP 외주개발 오픈소스 기록: 배포 전 5가지 확인 항목
앱 MVP 외주개발 오픈소스 기록: 배포 전 5가지 확인 항목
앱 MVP 외주개발이 끝날 무렵 “소스코드는 받았다”는 말만으로 인수인계가 끝났다고 보기 어렵습니다. 앱은 직접 작성한 코드뿐 아니라 라이브러리·프레임워크·빌드 도구처럼 다른 소프트웨어에 의존해 동작할 수 있기 때문입니다. 그래서 배포 전에는 어떤 구성요소를 썼는지, 어떤 버전인지, 어디에서 왔는지, 라이선스 정보는 무엇인지, 다음 변경을 누가 확인하는지를 한 기록에 남겨 두는 편이 좋습니다.
먼저 답하면, 외주 개발사에 ‘오픈소스를 쓰지 말라’고 요구하기보다 구성요소 목록과 확인 책임을 인수인계 산출물로 정하는 방식이 현실적입니다. GitHub는 프로젝트가 직접·간접 의존성을 가질 수 있다고 설명하고, SPDX는 소프트웨어 구성·출처·라이선스 등의 정보를 전달하기 위한 개방형 표준입니다. 이 글은 특정 도구를 도입하거나 라이선스 준수를 보장하는 글이 아니라, 창업팀이 배포 전 확인 대상을 잃지 않도록 기록을 만드는 방법입니다.
공식 원문 확인일: 2026년 9월 16일 · 작성: 유인어스(UINUS)
왜 ‘사용한 라이브러리 목록’만으로는 부족할까요?
의존성은 앱 코드에 직접 적은 패키지만 뜻하지 않을 수 있습니다. GitHub의 공급망 보안 문서는 manifest·lockfile에 적힌 직접 의존성뿐 아니라, 의존성이 다시 사용하는 간접 의존성도 프로젝트에 포함될 수 있다고 설명합니다. 즉 외주 견적서나 저장소 첫 화면만 보고 “무엇이 들어갔는지”를 단정하기보다, 실제 빌드 기준 목록을 어떤 시점에 뽑았는지까지 남겨야 다음 담당자가 같은 상태를 다시 확인할 수 있습니다.
목록의 목적도 구분하세요. 이 기록은 취약점·라이선스·배포 적합성의 결론을 자동으로 내려 주지 않습니다. 다만 질문이 생겼을 때 ‘어느 앱 버전의 어떤 구성요소를, 어느 저장소와 근거에서 확인했는가’를 되짚을 출발점을 만듭니다. SPDX도 SBOM 정보를 출처·라이선스·보안 등과 함께 전달하는 표준이라고 설명하면서, 라이선스 준수에 관한 법적 해석은 하지 않는다고 밝힙니다.
배포 전 한 장에 나눌 5가지
기록 칸 | 출시 전 질문 | 남길 근거 |
|---|---|---|
대상 빌드 | 어느 앱 버전·커밋·배포 후보를 기준으로 하나? | 버전 식별자와 목록을 뽑은 시각 |
구성요소 | 직접·간접 의존성을 어디까지 확인했나? | 패키지명·버전·의존 관계 또는 내보낸 목록 |
출처 | 저장소·패키지 출처·사용 위치는 무엇인가? | 원본 URL, manifest·lockfile 또는 빌드 산출물 위치 |
라이선스 정보 | 표기된 라이선스 정보와 확인 원문은 무엇인가? | 표기값, 원문 링크, 확인이 필요한 항목 |
변경 책임 | 추가·업데이트·삭제 때 누가 다시 확인하는가? | 요청자·검토자·승인자와 다음 확인 조건 |
이 표는 모든 팀에 같은 필드를 강제하는 양식이 아닙니다. 모바일 앱, 서버, 웹 관리자, 외부 SDK처럼 실제 배포 범위가 다르면 목록의 경계도 달라집니다. 핵심은 “오픈소스 사용 여부” 한 줄을 남기는 대신 대상 빌드와 근거를 같이 고정하는 것입니다.
1. 목록의 기준을 ‘현재 소스’가 아니라 ‘배포 후보’로 고정하세요
외주개발 중인 저장소는 계속 바뀔 수 있습니다. 그래서 인수인계 문서에는 “최신 코드”처럼 모호한 표현보다, 확인한 앱 버전·커밋·빌드 번호 또는 배포 후보를 적습니다. GitHub는 저장소의 manifest와 lockfile을 바탕으로 의존성 이름·버전을 구성할 수 있고, 변경이 기본 브랜치에 반영될 때 그래프가 갱신될 수 있다고 설명합니다. 사용 도구가 GitHub가 아니어도, 목록을 만든 기준 시점과 대상 산출물을 분리해 남기는 판단은 적용할 수 있습니다.
이미 완료 판단을 어떻게 남길지 정하지 않았다면 앱 외주개발 검수 기준 글을 먼저 보세요. 기능 검수의 완료 기준과 구성요소 기록의 기준은 서로 대체 관계가 아니라, 같은 인수인계에서 다른 질문을 다루는 항목입니다.
2. 직접 의존성과 간접 의존성을 한 단어로 뭉개지 마세요
직접 추가한 라이브러리만 목록에 남기면, 그 라이브러리가 다시 불러오는 구성요소가 빠질 수 있습니다. GitHub 문서는 직접 의존성과 간접 의존성을 구분하고, 의존성 그래프가 두 종류의 정보를 포함할 수 있다고 안내합니다. 따라서 외주 인수인계 때는 “직접 추가한 것”과 “빌드 결과에 함께 들어온 것”을 같은 의미로 쓰지 않는 편이 좋습니다.
모든 팀이 당장 완전한 자동 목록을 만들 필요는 없습니다. 다만 개발사에 목록을 요청할 때는 앱·서버·웹 중 어디를 대상으로 했는지, 패키지 관리 파일과 빌드 결과 중 무엇을 근거로 했는지, 확인하지 못한 범위가 있는지를 함께 받으세요. 빈칸을 추정으로 채우지 않는 것이 다음 검토를 더 빠르게 합니다.
3. 라이선스 이름은 추측하지 말고 표기와 원문을 함께 남기세요
SPDX License List는 자주 쓰이는 라이선스와 예외에 표준화된 짧은 식별자, 전체 이름, 라이선스 본문, 고정 URL을 제공한다고 설명합니다. 따라서 기록에는 “오픈소스라서 괜찮음”처럼 결론을 쓰기보다, 패키지에 표시된 라이선스 정보와 확인한 원문 링크를 나란히 두는 편이 낫습니다. SPDX 식별자는 정보를 명확하고 기계가 읽을 수 있게 전달하는 데 도움이 되지만, 그 자체가 특정 사용 방식의 허용 여부를 판정하는 도구는 아닙니다.
라이선스가 여러 개이거나 표기가 없거나, 앱 배포·소스 공개·고지와 관계된 판단이 필요한 경우에는 ‘확인 필요’로 표시하세요. 이 글은 계약·저작권·라이선스의 법률 자문이 아니며, 실제 의무는 해당 라이선스 원문과 배포 방식, 전문가 검토를 통해 판단해야 합니다.
4. 기록은 한 번 만든 뒤 끝나는 문서가 아니라 변경 기준입니다
새 패키지를 추가하거나 버전을 올리면 이전 목록이 더 이상 현재 배포 후보를 설명하지 못할 수 있습니다. CISA의 SBOM 최소 요소 문서는 소프트웨어의 새 빌드·릴리스나 구성요소·의존성 변경이 있을 때 이를 반영한 SBOM을 만들어야 한다는 원칙을 제시합니다. 이 문서는 미국 기관의 최소 요소 자료이므로 한국의 모든 앱에 의무라는 뜻은 아닙니다. 여기서는 작은 팀이 ‘무엇이 바뀌면 목록을 다시 확인할지’를 정하는 참고 기준으로만 활용하세요.
외주개발에서 추가 기능을 요청하는 과정이라면 추가 기능 요청의 비용·일정·승인 기록도 함께 확인할 수 있습니다. 기능 변경 승인과 구성요소 변경 확인을 같은 회의에서 다루더라도, 둘의 근거와 책임자는 따로 남기는 편이 좋습니다.
5. 인수인계에는 파일뿐 아니라 다음 확인자를 남기세요
목록 파일을 전달받아도 다음 배포에서 아무도 열어 보지 않으면 운영 기록이 되기 어렵습니다. 따라서 각 항목에 요청자·작성자·검토자·최종 확인자를 모두 같은 사람으로 단정하지 말고, 팀 규모에 맞게 누가 어떤 변경을 확인할지 정합니다. GitHub처럼 저장소 읽기 권한이 있으면 SPDX 호환 SBOM을 내보낼 수 있는 서비스도 있지만, 도구 제공 여부는 각 저장소 설정·권한·패키지 생태계에 따라 다릅니다.
소스·도메인·클라우드 같은 자산 자체의 소유와 회수는 앱 외주개발 인수인계 체크리스트에서 별도로 점검하세요. 오픈소스 기록은 자산 이전을 대신하지 않고, 자산 안에서 어떤 구성요소를 확인했는지 보완하는 문서입니다.
출시 전 짧게 점검하세요
배포하려는 앱·서버·웹의 버전 또는 커밋을 먼저 고정합니다.
직접·간접 의존성을 어느 근거에서 확인했는지 기록합니다.
패키지명·버전·출처·라이선스 표기와 원문 링크를 연결합니다.
불명확한 항목은 결론 대신 확인 필요로 표시합니다.
새 빌드·패키지 변경·배포 전 누가 목록을 다시 볼지 정합니다.
유인어스는 민간 사업 지원 서비스입니다. 이 글은 오픈소스 사용, 보안 수준, 라이선스 준수, 계약·저작권 적합성, 앱 심사 또는 사업 성과를 보장하지 않습니다. 실제 배포 판단은 최신 공식 문서, 사용한 구성요소의 원문, 서비스 구조와 계약, 필요시 법무·보안·개발 검토를 바탕으로 진행하세요.
자주 묻는 질문
외주개발사가 준 소스코드만 있으면 오픈소스 기록은 필요 없나요?
소스코드는 중요한 인수인계 대상이지만, 현재 배포 후보가 어떤 구성요소에 의존하는지 바로 보여 주지 않을 수 있습니다. 대상 버전과 목록의 근거를 함께 남기면 다음 변경·검토 때 확인 시작점을 찾기 쉽습니다.
모든 패키지의 라이선스를 팀이 직접 판단해야 하나요?
그렇게 단정할 수 없습니다. 우선 패키지에 표시된 라이선스 정보와 원문을 기록하고, 해석이나 배포 의무 판단이 필요한 항목은 확인 필요로 분리하세요. 실제 판단은 라이선스 원문, 배포 방식, 전문가 검토가 필요할 수 있습니다.
SBOM을 만들면 보안 문제가 해결되나요?
아닙니다. SBOM은 구성요소와 관계를 기록·전달하는 자료입니다. GitHub도 의존성 정보로 취약점 파악과 업데이트를 지원하는 기능을 설명하지만, 목록 자체가 안전성이나 보안 적합성을 보장하지는 않습니다.
외주 종료 때만 목록을 확인하면 되나요?
한 번으로 끝내기보다 새 빌드·릴리스, 구성요소 추가·업데이트처럼 목록의 근거가 바뀌는 시점을 정해 다시 확인하는 편이 좋습니다. 실제 빈도와 책임자는 팀의 배포 방식에 맞춰 정하세요.