안녕하세요, 株式会社estie(에스티) 이사 CTO인 Nari(@tiwanari)입니다.

여러분은 새로운 프로덕트를 세상에 내놓기 전에, "놓치는 부분(抜け漏れ)"이 있지는 않을까 불안해했던 경험이 없으신가요?

얼마 전, 어떤 프로덕트의 출시 전 체크 과정에서 "개인정보가 에러 모니터링 도구로 전송되도록 구현되어 있다"라는 지적을 받았습니다. 이를 찾아낸 것은 사람이 아니라, 출시 전 체크리스트를 읽게 한 AI의 스캔이었습니다.

생각해 보면 주의를 기울여야 하는 당연한 일이라도, 출시 전의 분주한 시기에 모든 관점을 떠올리는 것은 매우 힘든 일입니다. 제로 베이스에서 프로덕트를 개발하고 출시해 본 경험이 있는 분이라면, XSS(Cross-Site Scripting)와 같은 기술적인 취약점뿐만 아니라 이용 약관이나 전기통신사업법, 개인정보 취급까지, 세상에 내놓기 전에 확인해야 할 사항이 놀라울 정도로 많다는 것을 알고 계실 것입니다.

estie에서는 여러 팀이 병행하여 신규 프로덕트를 만들고 있습니다. 출시할 때마다 챙겨야 할 관점을 누군가의 기억에 의존하는 것은 한계가 있으며, 프로덕트가 차례차례立ち上がる(시작되는) estie와 같은 환경에서는 리뷰가 병목 현상(Bottleneck)이 됩니다. 그래서 사내 개발자 채널에 "출시 전의 포괄적인 체크리스트를 안전장치로서 정비하고 싶다"라고 제안한 것이 이 메커니즘의 시작이었습니다.

이번에는 이 메커니즘을 자신의 조직에서 만드는 방법을 쓰겠습니다. estie에서 사용하고 있는 약 100개 항목의 체크리스트를 소재로, 절차·판정 설계·잘 되지 않았던 부분까지 소개하겠습니다. 또한, 이 기사에서는 출시 전 체크리스트와 AI 스캔을 결합한 메커니즘을 「프로덕트 릴리스 하네스(Product Release Harness)」라고 부릅니다.

프로덕트 릴리스 하네스란 (하는 것·하지 않는 것)

「프로덕트 릴리스 하네스」는 사람이 판단하기 전에 놓치는 부분을 기계적으로 찾아내는 안전장치로서 만들었습니다. 작업 흐름은 4단계, 책임의 구분은 3층 구조입니다. AI가 정보를 수집하고, 증적을 통해 "미검증"을 줄이며, 마지막에는 책임자가 판단합니다.

「하지 않는 것」도 미리 적어두겠습니다. 우선, 테스트·SAST(정적 분석)·의존성 라이브러리 감사·시크릿 스캔·보안 리뷰·법무 확인을 대체하는 것이 아닙니다. 오히려 그러한 확인을 제대로 통과했는지, 누락은 없는지를 횡단적으로 살펴보는 것이 이 메커니즘의 역할입니다. XSS나 의존성 취약점 그 자체는 전용 스캐너가 더 확실하게 찾아낼 수 있으므로, 하네스가 하는 일은 간이 체크와 "그 확인을 했는가?"라고 묻는 단계까지입니다. 법령이 관련된 항목도 최종적인 판단은 법무나 전문가에게 넘깁니다.

이런 것들을 발견할 수 있습니다

서두의 PII(개인식별정보) 지적 외에도, 개발 중인 프로덕트에 스캔을 돌려보니 다음과 같은 지적이 나왔습니다.

"말해주면 알겠지만, 모르면 놓칠 만한 것"을 포함하여 포괄적으로 지적이 올라옵니다. 품질이 얼마나 향상되었는지를 숫자로 말하기는 어렵지만, 적어도 이러한 우려 사항을 출시 후가 아니라 출시 전에 해결할 수 있게 되었습니다.

만드는 법은 체크리스트 구축·스캔·전처리·집약의 4단계

메커니즘의 최소 구성은 다음 세 가지입니다.

• Git으로 관리하는 체크리스트
• 대상 리포지토리(Repository)를 읽을 수 있는 AI 에이전트
• 결과를 남기는 장소 (PR·Issue·문서 중 어느 것이든 좋음)

estie에서는 Claude Code의 사내 플러그인으로 만들었지만, 처음부터 플러그인화할 필요는 없습니다. 우선 하나의 리포지토리에서 로컬로 실행하고, 결과를 문서로 출력하는 것부터 시작할 수 있습니다.

중요한 것은 「체크리스트」입니다. 바로 그 만드는 방법을 살펴보겠습니다.

1. 포괄적으로 뽑아내고, 깎아내어 「정본(正本)」으로 만들기

첫 번째 체크리스트는 AI에게 "BtoB 대상 신규 프로덕트 출시 시 확인해야 할 관점을 포괄적으로 나열해줘"라고 지시하여 만들었습니다. 이 지시는 여러분의 컨텍스트에 적합한 것으로 선택하시면 됩니다.

(AI를 상당히 몰아붙여서) 포괄성을 중시하게 하여 나온 결과는 A4 11페이지 분량의 "이것도 적혀 있으면 안심"이라고 할 수 있을 정도로 다양한 관점이 채워진 것이었으며, 여기서부터의 작업은 더하는 것이 아니라 깎아내는 것이었습니다.

깎아내는 기준은 "이것을 체크할 수 없다면, 출시를 중단해야 하는가?" 하나로 정했습니다. 체크하지 않아도 되는 항목은 전사 거버넌스에서 별도로 관리하는 것(반사회적 세력 체크나 외환법 등), PMF(Product Market Fit) 이후에 정비할 운영 사항(영업·CS), 애초에 우리가 하지 않는 것들로 분류하여 제외했습니다. "이것도 적혀 있으면 안심"이 아니라, "여기에 적힌 것만 지키면 된다"라고 말할 수 있는 범위로 좁히는 것이 목적입니다.

실제로 소개하자면, AI가 제안한 포괄적인 안에는 예를 들어 다음과 같은 항목들이 나열되어 있었습니다. 모두 적혀 있으면 안심할 만한 것들이었습니다. 이를 위의 기준에 따라 엔지니어링·디자인·영업·법무 등 사내 전문가들에게 확인받으며 정리해 나갔습니다.

그 과정에서 남기기로 결정한 항목에는 나중에 설명할 "판정 규칙"까지 함께 적어 넣었습니다. 그림으로 나타내면, 체크리스트 작성 시 다음과 같은 단계를 거칩니다.

그렇게 좁힌 관점들을 하나의 "정본(正本)"으로 모읍니다. AI와 인간이 반드시 동일한 최신 버전을 참조할 수 있도록, 관점별로 파일을 나누고, 번호를 부여하여 읽는 순서를 정하며, 맨 앞에 목차를 두는 형식을 취했습니다.

checklist/
├── 0_index.md # 목차·범례 (여기가 입구)
├── 1_engineering.md # 개발 품질·SRE·보안
...

각 항목은 "태그(필수 / 조건부 / 권장)", "왜 중요한가", "구체적인 액션", "담당"의 형태로 작성합니다. 태그의 의미는 다음과 같습니다.

관점 ID: security.sentry.pii
태그: 필수
대상: 에러 모니터링
...

일반론뿐만 아니라 자신들의 업계나 프로덕트 고유의 관점을 넣는 것도 중요합니다. estie의 경우, 부동산 거래업법이나 지도 데이터 이용 허가, 여러 고객의 데이터를 섞지 않는 멀티 테넌트(Multi-tenant) 분리, 생성 AI 기능의 사전 리뷰와 같은 항목이 포함됩니다. 이 역시 자신의 컨텍스트에 맞춰 AI에게 포괄적으로 출력하게 한 뒤 깎아내는 방식이 좋습니다.

"그래서 결국 어떤 항목들이 있는 거야?"라고 궁금해하실 분들을 위해, estie의 체크리스트 중에서 특히 놓치기 쉬운 항목을 제목만 뽑아 두겠습니다. 자신의 리스트와 대조해 보며 빠진 것이 있다면 챙겨 보시기 바랍니다.

놓치기 쉬운 항목 (제목만 발췌)

개발·보안

• healthcheck 용 이외의 모든 엔드포인트(Endpoint)·Server Action에 인증과 인가를 필수 적용
• 테넌트 간에 데이터가 섞이지 않는 구조로 설계 (테넌트 식별을 클라이언트가 보내는 값이 아닌 인증 토큰으로 수행)
• 의존성 자동 업데이트에 cooldown(냉각기) 설정 (알림 활성화와는 별개의 개념)
• 알려진 취약점이 남아 있는 의존 라이브러리 사용 금지 (수정 버전이 나오지 않아 버전 고정 상태로 멈춰 있는 것)
• 외부에서 받은 데이터를 이스케이프(Escape) 처리하지 않고 HTML로 화면에 렌더링하지 않기
• 보안 헤더(Security Header) 설정
• 기밀 정보를 코드에 쓰지 않고, secret 스캔을 통해 유출 방지
• 앱 로그·모니터링 기반에 개인정보가 노출되지 않았는지 체크
• 부정 액세스를 탐지·추적할 수 있는 인증·감사 로그를 취득하고 보존
• 모든 타임스탬프의 UTC 저장 철저 및 DB 세션의 타임존을 UTC로 고정

법무·컴플라이언스

• 공통 이용약관(Terms of Service) 본문은 개정하지 않고, 신규 프로덕트 고유의 이용 범위 및 특약은 이용 신청서의 특기 사항으로 흡수한다
• Web 회원가입(Sign-up) 동선이 있는 경우, 플로우 상에서 이용약관에 대한 동의를 취득한다 (신청서의 서면 동의만으로는 계약자 본인 이외의 이용자의 동의를 얻을 수 없음)
• 신규 프로덕트에서 취득하는 개인 데이터 항목을 개인정보 처리방침(Privacy Policy)에 반영한다 (개인정보 보호법)
• 국내 리전(Region) 외의 SaaS를 신규로 이용하는 경우, '외적 환경의 파악'으로서 보관국의 법령을 확인한다 (개인정보 보호법)
• 타인의 통신 매개 기능(채팅 등)을 포함하는 경우, 신고를 수행하고 통신의 비밀을 보호하는 구현을 진행한다 (전기통신사업법)
• 신규 외부 전송 도구를 추가하는 경우, 외부 전송 공표 내용에 추가한다 (전기통신사업법의 외부 전송 규율)
• 영업 메일 송신 기능을 포함하는 경우, 옵트인(Opt-in) 취득과 송신자 표시에 대응한다 (특정전자메일법)
• 업법상 면허·등록이 필요한 행위에 해당하지 않는 구조 설계인지 확인한다 (부동산이라면 택건업법 등, 업종별 관련 업법)
• 공공기관의 데이터·지도 데이터·유료 데이터의 이용 허락 및 표시 요건을 확인한다
• 공개·발표 전에 상표 출원을 완료한다 (상표법. 프레스 릴리스·LP 공개 전이 엄수 타이밍)

AI 기능 거버넌스 (AI Function Governance)

• AI 출력 위치에 면책 표시를 구현한다
• 사용 벤더명과 이용약관으로의 동선을 UI에 표시한다
• 고객 데이터를 AI에 연동하는 경우, UI를 통해 통지 및 동의를 취득한다
• AI가 추정·평가 결과를 제시하는 경우, "참고치이며 공적인 평가가 아니다"라는 취지를 이용약관과 UI에 명기한다 (금액에 국한되지 않고, 스코어(Score)나 랭크(Rank) 등 자격자의 평가로 오인될 수 있는 모든 출력)

세일즈·CS (Sales/CS)

• 신규 프로덕트의 정식 명칭(브랜드명)을 확정한다 (CRM의 상품 등록·신청서·가격표의 전제가 됨)
• 문의 접수처와 1차 대응부터 개발팀으로의 에스컬레이션(Escalation) 경로를 결정한다
• PoC 운용 오너, 상담 리드(Lead)의 초도 대응 및 문의 대응을 누가 담당할지 명기한다

이 외에도 테스트의 충실도를 확인하는 항목 등, estie에서 요구하는 기준에 따라 항목을 설정하고 있습니다. 참고로, 프로덕트 디자인 관점은 자사의 디자인 시스템이나 표기 규약에 의존하는 항목이 많으므로 여기서는 생략합니다.

2. 스캔은 AI에게 맡기고, 판정은 5개 구분으로 한다

정본 체크리스트와 대상 리포지토리 전체(코드·설정·CI·인프라 정의)를 AI에게 읽게 하여, 각 항목을 판정하게 합니다. Skill의 골자는 다음과 같습니다.

당신은 출시 전 체크 보조자입니다. 최종적인 출시 여부는 인간이 판단합니다.
체크리스트의 각 항목에 대해 대상 리포지토리를 확인하고,
Pass / Fail / 要確認(확인 필요) / 未検証(미검증) / 対象外(대상 외) 중 하나로 판정해 주세요.
...

판정은 다음 5개 구분입니다. 핵심은 "모름(미검증)"과 "관계없음(대상 외)"을 구분하는 것입니다. 출시 판단에 있어 이 둘은 완전히 의미가 다릅니다.

• ✅ Pass: 요건을 충족하고 있음을 확인했다
• ❌ Fail: 요건을 위반하고 있음을 확인했다 (필수 사항이라면 출시 차단 요소/Release Blocker)
• ⚠️ 要確認 (확인 필요): 증거는 있으나 법무·임계치·타당성 등 인간의 판단이 필요하다
• ❓ 未検証 (미검증): 확인해야 할 위치에 접근할 수 없거나, 조사되지 않았다
• ➖ 対象外 (대상 외): 해당 기능이나 데이터가 없음을 확인했다

출력은 판정뿐만 아니라 근거까지 한 줄로 추적할 수 있는 형태로 만듭니다. 여기서 중요한 것은, "찾지 못했다는 사실"을 Fail의 근거로 삼지 않는 것입니다. 마스킹 처리가 보이지 않는 것뿐이라면 그것은 Fail이 아니라 미검증입니다. 실제로 개인정보를 전송하는 구현을 확인했을 때 비로소 Fail입니다.

가장 위험한 것은 미검증 항목을 몰래 Pass나 대상 외로 섞어버리는 것입니다. 법무 확인 등은 코드를 읽는 것만으로는 알 수 없습니다. 그것은 "안전"한 것이 아니라 "미검증" 상태이며, 모르는 것을 Pass로 처리하지 않는 것이 판정의 정확도 그 자체보다 중요합니다.

3. 코드 외의 증적을 모아 "미검증"을 줄인다

많은 항목이 「미검증 (Unverified)」 상태로 남으면 인간의 수고가 늘어나기 때문에, 판단을 내리기 전에 확인할 수 있는 것들은 가급적 미리 처리해 둡니다. 코드만으로는 알 수 없는 항목은 Slack이나 문서, Terraform 등의 별도 리포지토리(Repository)에 증적(Evidence)이 있는지 찾아봅니다.

이 공정 역시 체크리스트와 마찬가지로, 어느 정도는 어떤 항목의 증적이 어디에 있는지를 인간이 미리 작성해 두지 않으면 제대로 작동하지 않습니다. 「관련되어 보이는 곳을 찾아줘」라고만 하면, AI는 찾아본 것처럼 행동하며 「찾을 수 없었습니다」라고 답변하기 때문입니다. 그래서 항목별로 찾을 장소와 무엇이 발견되어야 판정을 올릴 수 있는지를 결정해 두었습니다.

증적 수집은 스캔(Scan)과는 별개의 단계로 분리했습니다. 동일한 실행 과정에 섞어버리면, 코드로 확인된 사항과 증적으로 확인된 사항의 구분이 출력 내용 속에서 모호해지기 때문입니다. 프롬프트(Prompt)는 다음과 같은 골자로 구성했습니다.

체크리스트 중 「미검증」으로 판정된 항목에 대해,
아래에 나열된 장소만 탐색하고, 증적이 발견된 것만 보고해 주세요.
찾을 장소:
...

중요한 점은 Pass로 올리는 기준을 증적의 종류에 따라 나누었다는 것입니다. 「법무 채널에서 상담했다」는 것은 「법무가 승인했다」는 뜻이 아닙니다. 상담 스레드가 발견되었다면 그것은 Pass가 아니라, 인간이 확인해야 할 「확인 필요 (To be confirmed)」로 분류하여, AI가 임의로 판단하게 하지 않고 증적 링크를 출력하도록 하고 있습니다.

4. 결과를 PR에 집약한다

사내 시스템으로서, 스캔 결과는 개인의 손에서 끝나지 않고 하네스(Harness) 리포지토리로의 PR(Pull Request)로 만들어 한곳에 모으도록 하고 있습니다. 여기서 만드는 PR은 코드 변경이 아니라, 출시 전 체크의 기록입니다.

다음과 같은 항목들을 기록으로 남기고 있습니다.

• Fail 항목과 확인 필요·미검증 목록
• 각 항목의 근거 파일 및 증적 링크
• 다음에 누가 무엇을 확인할 것인지
• 최종 판단자와 Go / No-Go 이유

PR 본문은 다음과 같은 템플릿으로 시작하면 편리합니다.

# 출시 전 체크 결과
## 대상
- 프로덕트 / 리포지토리 / 대상 커밋
...

이 PR을 머지(Merge)하는 것은 「출시해도 좋다」는 의미가 아니라, 「확인 기록을 남겼다」는 의미입니다. 모든 프로덕트의 결과가 모이면 자주 Fail이 발생하는 항목이나, 애초에 포착하지 못했던 관점들이 보이기 시작합니다. 그것을 보고 체크리스트 자체를 수정하고 있기 때문에, 툴이 똑똑해진다기보다는 체크리스트가 성장해 나간다는 느낌에 가깝습니다.

원래는 출시 전 체크를 위해 만들었지만, 지금은 취약점 체크와 마찬가지로 이미 운영 중인 프로덕트의 정기적인 건강 검진용으로도 사용되기 시작했습니다. 정본(Source of truth)이 하나 있다면 출시 타이밍과 관계없이 동일한 체크를 돌릴 수 있고, 게다가 체크리스트도 성장하는 형태입니다 (이 때문에 체크 결과에는 「체크리스트 커밋」이라는 항목도 포함되어 있습니다).

가치는 「이 시스템」이 아니라 「수집된 관점」에 있다

만들어 보며 느낀 점은, 가치는 시스템 그 자체보다 사내 전문가들의 관점을 하나의 체크리스트로 모았다는 점에 있다는 것입니다. 보안(Security)·SRE·법무·영업(Sales)·AI 거버넌스·브랜딩 등 각 분야 담당자들에게 「절대로 놓쳐서는 안 될 관점」을 물어보았고, 수주 만에 70건이 넘는 코멘트를 받았습니다. 이 사람들의 관점 그 자체가 이 툴의 내용물입니다.

전문가가 매번 모든 프로덕트를 확인하는 것은 어렵지만, 그 관점을 형식지(Formal knowledge)로 만들어 AI가 사용할 수 있는 형태로 두면 더 많은 프로덕트에 전달할 수 있습니다. 사람을 대체하는 것이 아니라, 「깊이」를 가진 전문가의 지견을 널리 전달하기 위한 시스템입니다.

전문가로부터 받은 코멘트는 그때마다 Git 커밋으로 반영해 왔습니다. 커밋 메시지에는 어떤 지적을 받아 어떤 항목을 어떻게 변경했는지 적혀 있습니다. 「이 관점은 판단이 어려우므로 보수적으로 남겨둔다」, 「이것은 자사에서 수행하지 않으므로 삭제한다」와 같은 판단들이 날짜와 함께 나열되어 있는 상태입니다.

현재의 체크리스트만 봐서는 왜 그런 문구인지 알 수 없습니다. 이력이 있다면, 이 항목을 이제 완화해도 되는지, 아니면 아직 이른 것인지를 당시의 판단과 함께 검토할 수 있습니다. 한 번 제외했던 항목을 다시 복구할 때도, 언제 어떤 이유로 삭제했는지를 추적할 수 있습니다. 체크리스트 그 자체만큼이나, 그곳에 도달하기까지의 경위와 컨텍스트 (Context)가 자산이 되고 있다는 것이 지금의 실감입니다.

또한, 모든 프로덕트의 결과가 모일수록 놓치고 있었던 관점도 발견되므로, 현재의 약 100개 항목은 내년에는 더 늘어나 있을 것입니다. 리스트가 개선될 때마다 전사의 프로덕트가 지켜야 할 기준도 한 단계씩 높아집니다.

즉, 가장 시간을 들일 가치가 있는 것은 AI의 메커니즘보다 체크리스트의 내용이라고 생각합니다. 여러분도 각자 회사의 기준을 파악하고, 이를 개선하는 사이클을 꼭 돌려보시길 바랍니다.

너무 많이 깎아내어 구멍이 생겼던 이야기

잘 되고 있는 이야기만 하면 거짓말 같으니, 실패했던 이야기도 적어두겠습니다.

앞서 약 70%를 깎아내어 5개 영역으로 압축했다고 말씀드렸습니다. 사실 그 정리 과정에서 보안 항목을 몇 가지 너무 많이 깎아냈습니다. 망라안 (Comprehensive plan)에는 다음과 같은 항목이 있었습니다.

- XSS 취약성이 없는가
- 검사: 사용자 입력의 출력 지점에서 이스케이프 (Escape) / 새니타이즈 (Sanitize)가 수행되고 있는가.
dangerouslySetInnerHTML 등의 사용 지점을 확인
...

망라안에서 정본 체크리스트로 항목을 옮기는 과정에서, 이 항목은 조용히 누락되었습니다. 이를 깨달은 것은 이행 후에 신구 스캔 결과를 대조했을 때였습니다. 구버전에서는 잡아냈던 XSS가 신버전에서는 보고되지 않고 있었던 것입니다.

복구할 때는 단순히 부활시키는 것이 아니라, 판정 규칙을 포함하여 다시 작성했습니다.

- 외부에서 받은 데이터를 이스케이프 하지 않고 HTML로 묘사하지 않는다 (필수)
- 액션: dangerouslySetInnerHTML / innerHTML / 동적 eval에 외부 유래 데이터를 직접 전달하지 않는다. 묘사가 필요하다면 새니타이저 (Sanitizer)를 통하거나, 값을 분해하여 묘사한다
...

이번에 다시 찾아낼 수 있었던 것은, 결과를 PR (Pull Request)에 모아 모든 프로덕트를 횡단적으로 보고 있었기 때문이었습니다. 메커니즘의 실수를 메커니즘으로 잡아낸 셈입니다. 이행이나 통합을 했다면, 구버전과 신버전으로 동일한 리포지토리를 스캔하여 차이점을 확인하십시오. 이 수고로움은 추천할 만합니다.

또 하나는 한계라기보다 타협입니다. 계약 내용, 법무 판단, 관계자의 합의는 코드를 아무리 읽어도 나오지 않습니다. AI에게는 거기서 무리하게 결론을 내리게 하지 않고 '미검증' 상태로 멈추게 하며, 마지막 Go / No-Go 결정은 인간이 맡습니다. AI는 판단 재료를 갖추어 주지만, 리스크를 책임지는 역할까지 대신할 수는 없습니다.

마치며

처음에는 AI가 내놓은 리스트에 압도당하기도 했지만, 최종적으로 자사에 맞는 체크리스트를 만들 수 있었던 것은 큰 자산이 되었습니다.

우선은 '클리어하지 못했다면 정말로 출시를 중단하고 싶은 10개 항목'을 하나의 리포지토리에서 돌려보는 것부터 시작해 보시면 좋을 것 같습니다. 거기서부터 결과를 PR에 모으고, 놓친 부분들을 추가해 나가면 정본은 자연스럽게 성장합니다.

갑자기 CI (Continuous Integration)의 필수 게이트로 설정하면, 오탐 (False Positive)이 계속될 때 메커니즘 자체를 사용하지 않게 됩니다. 우선은 리뷰 보조로서 운영하며, 팀이 결과를 신뢰할 수 있는 상태부터 시작하는 것을 추천합니다. AI에게 무엇을 읽힐지 고민하기 전에, 우리 산업이나 프로덕트에서 절대 놓쳐서는 안 될 관점을 모으는 것. 그곳이 이 메커니즘의 가장 중요하고 의미 있는 부분이었습니다.

estie에서는 「산업의 진가를 더욱 넓힌다.」라는 Purpose (목적) 아래, 여러 프로덕트를 빠르고 안전하게 세상에 내놓는 메커니즘을 함께 만들 동료를 모집하고 있습니다. 멀티 프로덕트의 출시 품질이나 AI 거버넌스의 표준화에 관심이 있는 분은 꼭 캐주얼하게 이야기 나누어 봅시다.

Discussion