개발자가 ISO/IEC 27001·27701 인증 준비에서 PM과 개발 보안을 맡으며 배운 것

회사에서 ISO/IEC 27001과 ISO/IEC 27701 인증을 준비하면서 PM과 개발 보안 대응을 맡게 됐다. 처음에는 인증을 위한 문서와 체크리스트를 정리하는 일이라고 생각했다. 실제로 해보니 핵심은 문서를 많이 만드는 데 있지 않았다.

조직이 어떤 정보를 다루고 있는지 설명하고, 그 정보가 어떤 위험에 노출되어 있는지 판단하고, 그 위험을 줄이기 위해 실제로 무엇을 했는지 증명하는 일이었다. 특히 개발자 입장에서는 보안 통제를 코드와 배포 과정 안에 넣고, 그것이 계속 지켜지고 있다는 증적까지 남겨야 했다.

회사명과 서비스명, 내부 시스템명, 심사 자료의 세부 내용은 공개하지 않는다. 이 글은 특정 조직의 인증 결과를 설명하는 글이 아니라, 인증을 준비하며 PM과 개발 보안 담당자로서 어떤 일을 했고 무엇을 배웠는지 기록하는 글이다.

ISO 27001과 ISO 27701을 함께 준비한다는 것

ISO/IEC 27001은 정보보호 관리체계(ISMS)를 요구한다. 조직의 상황과 범위를 정하고, 위험을 식별하고, 위험을 처리할 방법을 결정하고, 통제가 실제로 운영되는지 지속적으로 개선하는 구조다. ISO 공식 설명도 27001을 정보보호 관리체계를 수립·구현·유지·지속적으로 개선하기 위한 요구사항으로 설명한다.

ISO/IEC 27701은 개인정보를 처리하는 조직을 위한 개인정보 관리체계(PIMS)를 다룬다. 개인정보를 어떤 목적으로 수집하고, 누가 처리하며, 얼마나 보관하고, 어떤 권리와 책임이 있는지까지 관리 범위가 넓어진다. 따라서 두 표준을 같이 준비할 때는 보안을 별도 프로젝트로, 개인정보를 별도 프로젝트로 나누기보다 하나의 관리체계 안에서 연결해야 한다.

간단히 정리하면 다음과 같다.

실무에서는 두 표준의 요구사항을 따로 복사해서 관리하면 같은 내용을 두 번 관리하게 된다. 접근권한, 자산관리, 사고대응, 교육, 내부심사처럼 공통으로 사용하는 통제는 하나의 프로세스로 만들고, 개인정보와 관련된 추가 책임만 별도로 연결하는 방식이 훨씬 유지하기 쉬웠다.

PM으로 가장 먼저 한 일은 범위를 정하는 것이었다

인증 준비 초기에 가장 위험한 말은 “회사 전체를 준비한다”였다. 회사 전체라는 말만으로는 심사 대상 시스템과 책임자를 정할 수 없고, 필요한 증적의 범위도 계산할 수 없다.

그래서 먼저 인증 범위를 문장으로 고정했다.

1어떤 조직이
2어떤 서비스를 통해
3어떤 정보를 처리하고
4어떤 인프라와 외부 서비스를 사용하며
5어떤 업무를 수행하는가

범위를 정할 때 확인한 항목은 다음과 같았다.

• 대상 조직과 담당자
• 대상 서비스와 운영 환경
• 개발·검수·배포 환경
• 클라우드와 외부 솔루션
• 개인정보가 들어오는 지점과 나가는 지점
• 인증 범위에서 제외되는 시스템과 그 근거
• 외부 제공자와 위탁 처리자의 책임

범위가 명확해지자 PM 업무가 달라졌다. 막연히 “ISO 준비를 하자”고 독려하는 대신, 각 통제에 담당자와 완료 조건을 붙일 수 있었다. 예를 들어 접근권한 통제는 개발팀의 작업이면서 인사·운영·인프라 담당자의 협업이 필요한 일이다. 담당자가 하나가 아니라면 최종 책임자와 협조자를 나눠서 기록해야 했다.

인증 준비를 프로젝트로 운영하기

문서 폴더를 만드는 것만으로는 프로젝트가 운영되지 않는다. 나는 인증 준비 항목을 일반 개발 프로젝트처럼 쪼갰다.

1. 요구사항을 실행 항목으로 바꿨다

표준의 문장을 그대로 할 일 목록에 복사하면 아무도 완료 기준을 이해하지 못한다. 각 항목을 다음 네 가지로 바꿔 기록했다.

예를 들어 “접근권한을 관리한다”는 문장은 실행 항목이 아니다. “입사·이동·퇴사 이벤트가 발생하면 권한 요청과 승인 기록을 남기고, 정기적으로 권한을 검토하며, 검토 결과와 조치 내역을 보관한다”까지 구체화해야 프로젝트 작업으로 바뀐다.

2. 증적을 나중에 모으지 않도록 했다

인증 준비에서 가장 많은 시간이 드는 부분은 마지막에 증적을 한꺼번에 모으는 일이다. 그래서 통제 항목을 만들 때 증적 위치를 함께 정했다.

1통제 항목 → 담당자 → 수행 주기 → 저장 위치 → 검토자 → 보관 기간

증적은 스크린샷만을 의미하지 않는다. 승인된 변경 이력, 배포 기록, 권한 검토 결과, 취약점 조치 티켓, 교육 참석 기록, 장애 대응 타임라인처럼 실제 운영 과정에서 자연스럽게 만들어지는 기록이 더 강한 증적이 된다.

3. 진행률보다 리스크를 관리했다

인증 프로젝트에서 문서 개수나 완료 티켓 수만 보면 중요한 위험을 놓치기 쉽다. 나는 다음 항목을 별도로 추적했다.

• 담당자가 정해지지 않은 통제
• 운영은 하고 있지만 기록이 남지 않는 통제
• 기록은 있지만 승인·검토 주체가 없는 통제
• 개발팀과 운영팀의 책임 경계가 불명확한 통제
• 개인정보 처리 흐름은 존재하지만 문서화되지 않은 시스템
• 심사 직전에 처음 수행하면 신뢰하기 어려운 통제

특히 “지금 한 번 실행한 기록”과 “정해진 주기로 반복 운영한 기록”은 다르다. 인증 준비 막바지에 새로 만든 체크리스트보다 몇 달 동안 쌓인 일관된 운영 기록이 훨씬 설득력이 있다.

개발 보안 대응은 개발 프로세스 안에 들어가야 했다

개발 보안은 별도의 보안 문서에서 끝나지 않는다. 요구사항을 정의할 때부터 설계·개발·검토·테스트·배포·운영 과정에 들어가야 한다.

소스코드와 브랜치 보호

확인해야 할 것은 단순히 private repository인지 여부가 아니었다.

• 저장소 접근 권한이 역할에 맞게 제한되어 있는가
• 퇴사자와 이동자의 권한이 회수되는가
• 보호 브랜치에 직접 push할 수 없는가
• Pull Request와 리뷰 기록이 남는가
• 긴급 변경의 승인과 사후 검토가 가능한가
• 저장소에 비밀키와 개인정보가 들어가지 않는가

여기서 중요한 건 설정 화면을 캡처하는 것이 아니라, 실제 변경 하나가 어떤 흐름으로 운영되는지 설명할 수 있어야 한다는 점이었다.

1작업 브랜치 생성
2  → Pull Request 생성
3  → 자동 검사
4  → 리뷰와 승인
5  → 병합
6  → 배포
7  → 배포 결과와 변경 이력 보관

CI/CD와 비밀정보 관리

배포 파이프라인도 개발 보안의 일부다. 배포 서버에 비밀값을 평문으로 저장하거나 개인 계정의 토큰 하나에 의존하면 장애와 보안사고 양쪽에 취약해진다.

확인한 핵심 항목은 다음과 같다.

• 환경별 비밀값 분리
• 저장소와 로그에 비밀값이 노출되지 않는지 확인
• 토큰 권한 최소화
• 토큰 만료와 교체 절차
• 배포 권한과 승인 권한 분리
• 배포 실패 시 롤백 방법
• 파이프라인 실행 이력 보관

취약점과 오픈소스 관리

“취약점이 없다”는 증적보다 “취약점을 발견하면 어떻게 처리하는가”가 더 현실적인 통제였다.

1취약점 발견
2  → 영향도와 실제 사용 여부 확인
3  → 조치 담당자와 기한 지정
4  → 패치 또는 예외 승인
5  → 재검증
6  → 결과 기록

모든 경고를 즉시 없애는 것이 항상 정답은 아니다. 사용하지 않는 의존성인지, 실제 운영 경로에 노출되는 취약점인지, 패치로 인한 호환성 위험은 무엇인지 판단하고 그 판단 근거를 남기는 것이 중요했다.

ISO 27701에서 개발자가 놓치기 쉬운 부분

개발자는 개인정보를 데이터베이스 테이블이나 API 필드로만 보는 경향이 있다. 하지만 27701에서는 개인정보가 업무 과정에서 어떻게 흘러가는지와 그 처리 목적·책임을 함께 설명해야 한다.

다음 질문에 답하지 못하면 개인정보 흐름이 정리되지 않은 상태다.

• 어떤 화면과 API에서 개인정보가 들어오는가
• 필수 수집과 선택 수집은 구분되어 있는가
• 어떤 서비스와 데이터베이스에 저장되는가
• 로그와 분석 도구로 복사되는가
• 외부 솔루션이나 위탁업체로 전달되는가
• 보관 기간이 끝나면 어디에서 어떻게 삭제되는가
• 운영·개발·고객지원 담당자가 어떤 범위까지 접근하는가
• 이용자 요청이 들어왔을 때 조회·수정·삭제할 수 있는가

개발 보안 관점에서 개인정보 처리는 데이터베이스만의 문제가 아니었다. API 요청 로그, 오류 추적 도구, 메시지 큐, 백업, 테스트 데이터, 관리자 화면, 알림 메시지까지 확인해야 했다. 운영 편의를 위해 넣은 로그 한 줄이 개인정보의 새로운 복제본이 될 수 있기 때문이다.

가장 어려웠던 것은 사람과 시스템 사이의 연결이었다

문서를 작성하는 일 자체보다 어려운 건 문서와 실제 운영을 일치시키는 일이었다.

정책에는 권한을 정기적으로 검토한다고 적혀 있는데 실제 담당자는 누구인지 모르는 경우가 있었다. 절차서에는 배포 전 검토가 필요하다고 적혀 있지만 긴급 배포 때는 다른 방식으로 처리하고 있을 수도 있다. 개인정보 처리방침에는 특정 보관 기간이 적혀 있는데 실제 배치 작업이나 삭제 정책은 존재하지 않을 수도 있다.

이 차이를 줄이기 위해 문서를 먼저 완벽하게 만들기보다 현재 운영을 관찰하고, 실제 운영과 문서의 차이를 나누어 기록했다.

1현재 운영 확인
2  → 문서와의 차이 기록
3  → 위험도 판단
4  → 즉시 개선 또는 예외 승인
5  → 책임자와 완료 기한 지정
6  → 재검토

이 방식은 부족한 부분을 숨기지 않으면서도, 무엇을 언제 개선할지 설명할 수 있게 해줬다.

PM과 개발 보안을 동시에 맡으며 배운 것

첫째, ISO 준비는 문서 작성 프로젝트가 아니라 운영 방식을 바꾸는 프로젝트였다. 문서는 운영을 설명해야 하고, 운영은 문서와 모순되지 않아야 한다.

둘째, 보안 통제는 개발 속도를 늦추는 별도 절차가 아니라 반복 가능한 개발 흐름에 포함되어야 한다. 리뷰, 자동 검사, 권한 관리, 배포 기록이 개발 과정에 자연스럽게 들어가면 보안 담당자가 모든 변경을 수동으로 확인하지 않아도 된다.

셋째, 증적은 심사 직전에 만드는 결과물이 아니라 업무를 수행하는 순간 남아야 한다. 승인·검토·조치·재검증의 흐름이 기록으로 남으면 심사 대응뿐 아니라 실제 장애와 사고 대응에도 도움이 된다.

넷째, 혼자 PM을 맡는다고 해서 모든 일을 혼자 해야 하는 것은 아니다. PM의 역할은 모든 통제를 직접 실행하는 사람이 되는 것이 아니라, 담당자·완료 조건·증적·리스크를 연결하고 끝까지 추적하는 것이다.

마무리

ISO/IEC 27001과 ISO/IEC 27701을 준비하면서 가장 크게 달라진 점은 보안을 바라보는 단위였다. 이전에는 보안을 설정과 코드의 문제로 봤다면, 이제는 사람·프로세스·기술·기록이 함께 맞물려야 실제 통제가 된다는 것을 알게 됐다.

개발자가 PM과 개발 보안 대응을 함께 맡으면 표준의 문장을 코드와 운영 언어로 번역해야 한다. 반대로 개발 과정에서 발생하는 변경·검토·배포·장애 기록을 관리체계의 증적으로 연결할 수도 있다. 이 두 방향을 연결하는 일이 가장 어렵지만, 동시에 개발자가 인증 준비에서 가장 큰 가치를 만들 수 있는 지점이었다.

아직 인증 준비 과정에 있다면 처음부터 모든 문서를 완벽하게 만들려고 하기보다, 먼저 범위를 정하고, 위험을 식별하고, 현재 운영과 문서의 차이를 드러내고, 반복 가능한 증적 흐름을 만드는 것부터 시작하는 편이 좋다.

참고: ISO/IEC 27001과 ISO/IEC 27701의 적용 판본과 심사 기준은 계약 범위와 인증기관의 안내를 우선해야 한다. 이 글은 특정 조직의 심사 결과나 내부 통제 목록을 공개하지 않고, 인증 준비 과정에서의 역할과 실무 관점을 기록한 글이다.

참고 자료

• ISO/IEC 27001 공식 소개
• ISO/IEC 27701 공식 소개