포트폴리오보다 확인 가능한 증거로 개발사를 선정하는 체크리스트

개발사를 고를 때 포트폴리오는 후보를 찾는 자료일 뿐 최종 판단의 증거가 되기 어렵습니다. 지금 제안한 팀이 어떤 방식으로 보안을 설계하고, 어떤 산출물을 납품하며, 장애가 났을 때 누가 복구하는지를 확인해야 합니다. 가장 실용적인 방법은 요구사항마다 증거의 형태, 확인 방법, 미충족 시 판정을 한 줄씩 적는 평가표를 먼저 만드는 것입니다.

이 글의 체크리스트는 특정 업체를 추천하지 않습니다. 후보에게 같은 질문을 보내고, 공개 가능한 샘플이나 가린 문서, 스테이징 재현, 담당자 설명처럼 확인 가능한 자료를 받아 비교하는 절차입니다. 자료가 없다는 사실도 숨겨진 위험으로 기록합니다. 다만 공개 정보만으로는 확인할 수 없는 고객·계약 정보의 공개를 요구하지 말고 민감한 값은 가린 샘플로 대체하도록 합의해야 합니다.

후보 소개를 증거 요청서로 바꾸는 방법

먼저 사업 요구사항을 구현 기능이 아니라 위험과 확인 가능한 결과로 다시 씁니다. 예를 들어 고객 개인정보를 처리하는 주문 시스템이라면 ‘보안에 강한 개발사’라는 문장 대신 ‘권한 없는 사용자가 주문 상세를 볼 수 없고, 비밀값이 저장소와 로그에 남지 않으며, 취약점이 발견됐을 때 담당자와 대응 기한을 확인할 수 있어야 한다’고 적습니다.

각 요구사항에 네 칸을 붙이면 제안서의 수사를 비교 가능한 기록으로 바꿀 수 있습니다. 첫째 후보가 제출할 산출물, 둘째 자료의 최신 시점과 책임자, 셋째 발주자가 직접 재현할 확인 방법, 넷째 미충족 시 보류·조건부·탈락 중 어떤 판정을 내릴지입니다. 이 표를 제안 요청 단계에서 먼저 보내면 업체마다 다른 범위의 포트폴리오를 같은 기준으로 볼 수 있습니다.

• 주장: 어떤 결과를 약속하는가

• 증거: 문서·커밋·로그·스테이징 화면 중 무엇을 제출하는가

• 검증: 누가 어떤 입력으로 언제 다시 확인하는가

• 판정: 계약 전 보류인지, 수락 전 보완인지, 후보 제외인지

보안 증거는 정책명이 아니라 재현 단위로 요청합니다

보안 증거의 출발점은 업체가 사용하는 도구의 이름이 아니라 개발 과정에서 위험을 발견하고 처리하는 흐름입니다. NIST의Secure Software Development Framework(SSDF)는 안전한 개발 관행을 공통 언어로 제시하고 소프트웨어 구매자와 공급자의 대화에도 활용할 수 있다고 설명합니다. 따라서 후보에게 보안 인증서 하나만 요구하기보다 위협 모델, 의존성 목록, 테스트 결과, 취약점 처리 기록을 요구사항별로 매핑하게 하는 편이 실제 작업을 확인하기 쉽습니다.

웹 애플리케이션이라면 인증·인가, 입력 검증, 세션, 오류 처리, 로깅 같은 항목을 추상적인 ‘안전한 코드’로 두지 않습니다. OWASP의Application Security Verification Standard(ASVS)는 애플리케이션 보안 통제를 테스트할 기준이면서 계약에 검증 요구사항을 적을 기반으로도 사용할 수 있습니다. 발주자는 프로젝트 위험에 맞는 항목을 골라 ‘요구사항 ID, 테스트 입력, 통과 결과, 미통과 조치’의 네 칸으로 바꾸면 됩니다.

CISA의 Secure by Demand 안내도 구매자가 조달 과정에서 보안을 명시적으로 요구해야 한다는 방향을 제시합니다. 실무에서는 이 원칙을 ‘후보가 보안에 신경 쓴다’는 답변으로 끝내지 않고, 샘플 위협 모델의 작성일, 최근 취약점의 접수·수정·배포 흐름, 비밀값을 주입하는 환경 설정, 권한 테스트 화면을 확인하는 질문으로 바꿉니다.CISA Secure by Demand Guide

• 위협 모델 또는 보안 요구사항 목록: 대상 자산·신뢰 경계·완화책이 적혀 있는가

• 의존성·SBOM 또는 패키지 목록: 버전과 업데이트 책임이 보이는가

• 보안 테스트 결과: 테스트 일자·범위·미해결 항목·재검증 결과가 있는가

• 취약점 대응 규칙: 심각도별 담당자·기한·고객 통지 조건이 계약에 남는가

납품 증거는 마지막 압축 파일보다 빌드 경로를 봅니다

납품 단계에서는 화면이 보인다는 사실만으로 완료를 선언하지 않습니다. 어떤 커밋이 어떤 빌드 명령과 의존성 잠금 파일을 거쳐 배포 파일이 됐는지, 데이터베이스 변경을 어떤 순서로 적용하고 되돌리는지, 환경별 설정에서 비밀값을 어떻게 분리하는지를 확인해야 합니다. 발주자가 받은 것은 결과물뿐 아니라 결과물을 다시 만들고 문제를 추적할 수 있는 경로여야 합니다.

빌드 재현성은 거창한 시스템부터 시작하지 않아도 됩니다. 릴리스마다 커밋 ID, 빌드 시각, 런타임 버전, 패키지 잠금 파일의 해시, 테스트 명령과 결과, 배포 파일의 해시를 한 장의 릴리스 기록에 남기면 됩니다. 공급자가 서명된 provenance를 제공한다면 출처 확인에 도움을 받을 수 있지만, 서명이 소프트웨어의 안전을 보증하지는 않으므로 실제 정책 기준과 테스트를 함께 확인해야 합니다. 이 점은GitHub Artifact Attestations 문서도 명시합니다.

수락 테스트에는 기능 목록만 넣지 말고 납품 파일과 확인 명령을 함께 적습니다. 예를 들어 ‘주문 생성 통과’만 쓰는 대신 테스트 데이터의 입력, 예상 응답, 저장된 상태, 로그에서 확인할 추적 ID, 실패 시 재처리 또는 롤백 방법을 기록합니다. 그래야 담당자가 바뀌어도 같은 결과를 다시 판정할 수 있습니다.

1. 후보에게 동일한 납품 증거 목록과 제출 기한을 보냅니다.

2. 샘플 릴리스 기록의 커밋·해시·테스트 결과를 대조합니다.

3. 스테이징에서 새 버전을 설치하고 마이그레이션과 롤백을 직접 실행합니다.

4. 수락 조건을 충족한 항목과 보완 기한을 계약 부속 기록에 남깁니다.

운영 증거는 인수인계 전에 복구를 재현합니다

운영 역량은 ‘유지보수를 지원한다’는 문장보다 장애 상황에서 확인됩니다. 후보에게 정상 운영 화면을 보여 달라고 하기 전에 알림이 어디로 오고, 담당자가 무엇을 보고 우선순위를 정하며, 고객 영향이 있는 오류를 어떻게 공지하고, 마지막 정상 상태로 어떻게 되돌리는지 설명하게 합니다. 런북과 연락망은 납품 문서가 아니라 실제 대응자가 사용할 입력과 행동의 목록이어야 합니다.

운영 수치를 계약에 넣으려면 먼저 측정 방법을 합의합니다. Google SRE가 설명하는SLI·SLO·SLA 구분처럼 사용자가 체감하는 가용성·지연·오류율을 무엇으로 측정할지, 목표를 어떤 기간으로 계산할지, 목표를 놓쳤을 때 어떤 대응을 할지 나누어 적습니다. 특정 숫자를 모든 프로젝트에 강제하지 말고 업무 영향과 비용을 기준으로 목표를 정해야 합니다.

복구 증거는 설명회가 아니라 리허설로 수집합니다. 테스트 환경에서 알림을 발생시키고, 담당자가 로그의 추적 ID로 대상을 찾고, 백업 또는 이전 릴리스에서 복구하고, 데이터 정합성을 대조하게 합니다. 리허설이 끝난 뒤 걸린 시간, 누락된 권한, 설명이 막힌 단계, 재시도 후 중복 여부를 기록하면 운영 비용과 남은 위험을 후보 비교에 반영할 수 있습니다.

• 런북: 정상·실패·재처리·롤백 절차가 각각 있는가

• 관측성: 요청 ID, 오류율, 지연, 배포 버전을 연결해서 볼 수 있는가

• 복구: 백업 복원 후 데이터 정합성과 고객 영향까지 확인하는가

• 책임: 업무 시간·비상 상황의 담당자와 응답 경계가 계약에 있는가

가상 사례: B2B 주문관리 MVP의 후보 판정

예시의 입력은 8주 안에 주문관리 MVP를 출시해야 하는 B2B 팀입니다. 고객 연락처와 주문 금액을 저장하고 외부 물류 API를 호출하며, 업무 시간 밖에도 실패 알림을 받아야 합니다. 예산과 일정이 제한되어 있으므로 모든 보안 체계를 새로 심사하는 것이 목표가 아니라, 이 서비스의 핵심 위험을 후보가 실제로 관리할 수 있는지 확인하는 것이 목표입니다.

결정 절차는 세 후보에게 같은 증거 요청서를 보내는 것으로 시작합니다. 후보마다 최근 작업의 이름이나 고객명은 받지 않고, 가린 위협 모델 한 장, 의존성 목록의 일부, 실패한 배포를 복구한 스테이징 기록, 운영 런북의 목차, 릴리스 기록 샘플을 요청합니다. 이어서 60분 검증 세션에서 테스트 계정으로 권한 차단과 외부 API 실패를 재현하고, 후보가 어떤 로그와 재처리 절차를 안내하는지 관찰합니다.

중간 산출물은 evidence-matrix-v0.1이라는 표입니다. 행에는 개인정보 접근, 릴리스 재현, 물류 API 실패, 백업 복구를 두고 열에는 제출 자료, 검증 입력, 결과, 미충족 조치, 책임자를 둡니다. 예를 들어 물류 API 실패 행에 ‘타임아웃 입력 → 실패 이벤트와 추적 ID 확인 → 한 건 재처리 → 중복 주문 없음’을 적고, 이 흐름을 스테이징에서 통과한 후보만 운영 검토로 넘깁니다.

예상 결과는 가장 화려한 포트폴리오를 가진 팀이 자동으로 이기는 것이 아닙니다. 보안과 납품은 통과했지만 복구 리허설의 담당자와 시간 기록이 비어 있다면 조건부 후보로 남기고, 운영 증거를 수락 전에 보완하도록 일정과 책임자를 계약에 적습니다. 반대로 일정이 빠르다는 이유로 검증되지 않은 증거를 통과시키면 출시 후 장애 때 발주자가 다시 확인 비용을 부담하게 됩니다.

실패 경로와 이 체크리스트의 한계

실패의 대표적인 신호는 화면 캡처와 인증서 사본은 빨리 오지만 원본 날짜, 적용 범위, 재현 절차, 미해결 항목을 묻는 순간 답변이 멈추는 경우입니다. 이때 ‘자료가 부족하지만 믿고 진행’으로 넘기지 말고 평가표의 상태를 보류로 바꿉니다. 후보에게 고객명과 개인정보를 가린 샘플, 항목별 범위 설명, 제한된 테스트 계정, 보완 제출 기한을 다시 요청하고, 기한 안에 확인되지 않으면 범위를 줄이거나 다른 후보로 전환합니다.

검증 도중 테스트가 실패하면 결함을 감추기보다 실패 입력, 관찰된 결과, 영향 범위, 복구 시도, 재검증 결과를 기록합니다. 원인이 환경 설정이면 설정을 고친 뒤 같은 입력으로 재시도하고, 데이터 변환이나 권한처럼 되돌리기 어려운 문제면 배포를 멈추고 롤백 또는 수동 승인으로 우회합니다. 이 기록은 후보를 벌주기 위한 점수가 아니라 실패를 발견했을 때 협업이 가능한지 보는 운영 증거입니다.

반대로 단순한 홍보용 랜딩 페이지처럼 민감정보를 저장하지 않고 외부 연동과 상시 운영이 없는 작업이라면 전체 공급망 심사를 그대로 적용할 필요는 없습니다. 이 경우에도 소스 전달, 배포 권한, 수정 범위, 기본 접근성, 장애 시 연락 방법 정도의 축소된 증거표는 남기되, 위험이 낮다는 판단의 근거와 생략한 검증 항목을 기록합니다. 체크리스트는 모든 프로젝트를 같은 무게로 만들기 위한 문서가 아니라 위험에 맞춰 증거의 깊이를 조절하는 도구입니다.

선정 완료 조건을 계약 전에 고정합니다

최종 선정은 점수 합계만으로 끝내지 않습니다. 보안·납품·운영 각 영역에 최소 통과 항목을 두고, 조건부 항목에는 보완 산출물과 마감일, 확인 책임자를 붙입니다. 포트폴리오에서 얻은 신뢰는 후보를 대화로 초대하는 데 사용하고, 계약과 수락은 반드시 제출된 증거와 재현 결과를 기준으로 삼습니다.

• 모든 핵심 요구사항에 증거·검증 방법·판정이 연결되어 있는지 확인

• 보안 샘플과 테스트 결과에 범위·일자·미해결 항목이 기록되어 있는지 확인

• 릴리스 한 건을 커밋부터 스테이징 설치와 롤백까지 재현

• 장애 알림·런북·복구 리허설을 실제 담당자가 수행하고 시간을 기록

• 남은 위험과 조건부 보완 기한을 계약 부속 문서에 서명해 보관

완료 조건은 후보가 ‘가능하다’고 말한 상태가 아니라, 발주자가 같은 입력으로 핵심 증거를 확인하고 결과를 기록한 상태입니다. 위 항목을 모두 확인·기록하고 미충족 위험의 소유자와 다음 조치를 남겼다면 개발사 선정 검증이 완료됩니다.