법은 행위의 최저선입니다. "여기서부터는 처벌한다"는 선이지, "여기까지는 해도 괜찮다"는 선이 아닙니다. 보안 업무에서 자주 마주치는 어려운 결정들은 대개 법은 안 어겼는데 무엇을 해야 할지 알 수 없는 자리에 있습니다. 이번 회차의 주제는 그 자리에서 무엇을 기준으로 판단할 것인가입니다.

1. 보안 전문가의 직업 윤리란

윤리는 도덕 강의가 아니라 직업적 판단의 일관성을 만드는 도구입니다. 같은 상황에서 같은 결정을 내릴 수 있게 해 주고, 그 결정의 근거를 외부에 설명할 수 있게 해 주는 장치입니다.

법과 계약을 통과한 행위라도 윤리 프레임에서 한 번 더 점검해야 하는 이유는, 법과 계약이 미처 정의하지 못한 영역이 항상 남기 때문입니다. 그 자리에서의 결정이 회사·고객·사회의 신뢰를 결정합니다.

2. 국제 직업 윤리 강령

보안 분야에는 여러 윤리 강령이 있습니다. 표현은 조금씩 다르지만 공통된 5개의 기둥이 보입니다.

2.1 다섯 개의 공통 기둥

이 강령들을 가로질러 자주 등장하는 다섯 가지 원칙입니다.

이 다섯 개를 본인의 사고 체크리스트에 새겨 두면, 어려운 결정 앞에서 무엇을 점검할지 흐름이 잡힙니다.

3. (ISC)² Code of Ethics

CISSP·CCSP를 발행하는 (ISC)²의 윤리 강령은 단 4개 항목으로 구성됩니다. 짧고 강력해서 자주 인용됩니다. 의역하면 다음과 같습니다.

1. 사회, 공공의 이익, 그리고 인프라를 보호하라.
2. 정직하고, 공정하며, 책임감 있고, 합법적으로 행동하라.
3. 본인의 의무에 성실하고, 효과적으로 봉사하라.
4. 직업의 발전과 보호에 기여하라.

순서가 의미를 가집니다. 사회 보호 > 행동의 도덕성 > 의무 수행 > 직업 발전. 만약 의뢰인의 요구와 사회의 이익이 충돌한다면, 1번이 2~4번보다 우선합니다. 가령 의뢰인이 "이 취약점은 우리만 알고 있으니 영원히 비밀로 해달라"고 요구해도, 그 취약점이 다른 회사·시민에게 광범위한 위험을 끼친다면 1번이 작동합니다.

3.1 EC-Council의 더 구체적인 항목

CEH 발행기관인 EC-Council의 강령은 더 구체적입니다. 자주 인용되는 항목 몇 개입니다.

4. 취약점 공개

발견한 취약점을 어떻게 알릴지는 보안 업무에서 가장 자주 마주치는 윤리 결정입니다. 세 가지 모델이 있습니다.

4.1 풀 디스클로저

발견 즉시 모든 정보(상세 분석, PoC 코드)를 공개하는 방식입니다. 1990년대 보안 커뮤니티에서 자주 쓰인 방식이지만, 지금은 마지막 수단으로 보는 시각이 우세합니다.

4.2 코디네이티드 디스클로저

지금의 표준입니다. 발견자는 먼저 벤더에 통보하고, 양측이 패치 일정과 공개 시점을 협의해 같이 공개합니다.

90일은 Google Project Zero가 정착시킨 표준입니다. 의료기기·산업제어 같은 일부 영역은 더 긴 기간(120일~365일)을 적용하기도 합니다.

4.3 논 디스클로저

벤더 내부 또는 의뢰인과 발견자 사이에서만 처리하고 외부 공개를 하지 않는 방식입니다. 모의해킹 위탁 결과 보고서가 여기에 해당합니다.

4.4 어느 모델을 언제 쓰는가

마지막 행이 가장 어려운 결정입니다. 협의된 90일을 기다리는 동안 실제 피해자가 늘어나고 있다면, 코디네이티드 원칙을 깨고 즉시 공개하는 것이 사회 보호 원칙에 부합할 수 있습니다.

5. 취약점 공개의 한국적 맥락

한국에는 KrCERT/CC 취약점 신고 제도, KISA 화이트해커 사례 보호 같은 제도가 있습니다.

다만 한국 법은 선의의 모의해킹에 대한 명시적 면책 조항이 없습니다. KISA 정책은 행정 가이드라인이지 법적 면책이 아닙니다. 좋은 의도로 점검했더라도 사후에 동의가 없었다고 주장되면 망법 제48조 1항이 적용될 수 있습니다.

이 맥락에서 한국 보안 연구자가 외부 시스템을 점검할 때의 표준 절차는 다음과 같습니다.

1. 점검 전 명시적 동의를 받거나, 공개 버그 바운티 프로그램에 등록된 자산에만 점검
2. 동의가 없는 외부 자산은 포트 스캔 수준에서 멈추고, 그 결과를 KrCERT/CC에 신고
3. 취약점 PoC를 직접 실행하지 않고 추정 단계에서 멈춤

6. 내부 고발

회사가 알면서도 사고를 숨기려 할 때, 또는 명백한 위법을 지시받을 때, 보안 담당자는 내부 고발을 해야 하는가. 이 자리는 윤리적으로 가장 어렵습니다.

6.1 한국의 내부 고발 보호

내부 고발자는 법적으로 보호받지만, 실무적으로는 회사 내 불이익(평가·승진·재계약)이 빈번합니다. 그래서 고발이 정당한 윤리적 의무인 자리와 사내 절차로 해결할 수 있는 자리를 구분해야 합니다.

6.2 고발 전 점검 절차

6.3 무엇이 고발을 정당하게 만드는가

법적·윤리적으로 고발을 정당하게 만드는 4가지 요건입니다.

이 네 가지를 모두 충족하지 못한 고발은 명예훼손·업무방해로 거꾸로 처벌받을 수 있습니다. 그래서 고발을 결심한 시점부터는 변호사·노무사 상담을 함께 진행하는 것이 표준입니다.

7. 보안 사고 보고 시 윤리적 판단

내부 고발이 아니더라도, 일상적인 사고 보고에서도 윤리적 판단이 필요한 자리들이 있습니다.

7.1 사고 규모 축소 압력

상황: 회사가 "1만 명 유출"을 "기술적으로는 1만 명이지만 실제 영향은 100명 미만"으로 발표하고 싶어한다. 보안팀에 그 논리를 만들어 달라고 요구.

7.2 사고 원인 묘사

같은 사고도 표현 방식으로 인상이 달라집니다.

윤리적으로 적절한 표현은 마지막입니다. 사실에 부합하면서 책임 소재가 명확한 표현을 쓰는 것이 보안 담당자의 일입니다.

7.3 외부 위탁사 책임 분배

위탁 개발사의 잘못으로 사고가 났는데, 회사가 "위탁사 책임이라 우리는 책임 없다"고 발표하려 한다.

8. 윤리적 딜레마 시나리오 토론

이번 회차의 핵심 활동입니다. 정답이 없는 시나리오들을 두고 본인이라면 어떻게 판단할지 적어 보세요. 답을 한 가지로 좁히는 게 아니라, 판단 근거를 명시적으로 적어 보는 것이 목적입니다.

8.1 시나리오 A: 친구 회사의 데이터

당신은 모의해킹 회사 직원이다. 어느 날 친구가 운영하는 작은 SaaS 회사가 위탁 의뢰를 했다. 점검 중 친구 회사가 자기 회사 사용자의 비밀번호를 평문으로 저장하고 있는 것을 발견했다. 친구는 보고서에서 "비밀번호 저장 방식은 문제없음"으로 적어 달라고 부탁한다. ISMS 인증을 받기 위함이라고 한다.

8.2 시나리오 B: 발견한 0-day

당신은 한 오픈소스 라이브러리에서 RCE 취약점을 발견했다. 이 라이브러리는 수천 개의 상용 제품에 쓰이고 있다. 메인테이너에게 통보했지만 3개월째 응답이 없다. 그러는 사이 다른 보안 연구자가 비슷한 영역을 탐색하고 있다는 트윗을 봤다.

8.3 시나리오 C: 회사 SOC가 발견한 직원 사찰

당신은 회사 보안운영센터(SOC) 분석가다. 침해 의심 트래픽을 분석하던 중, 인사팀이 특정 노조 활동 직원의 메일을 별도 모니터링하고 있다는 사실을 발견했다. 이 모니터링은 회사 정책에 명시되어 있지 않고, 통신비밀보호법 위반 가능성이 있다.

8.4 시나리오 D: 모의해킹 중 발견한 본인의 정보

당신은 외부 위탁 모의해킹팀의 일원이다. SQL 인젝션이 성공해 회원 데이터베이스를 추출했더니, 본인의 개인정보(과거 이 회사 서비스 가입 기록)가 그 안에 있는 것을 발견했다.

8.5 시나리오 E: AI가 만들어 준 익스플로잇

당신은 모의해킹 중 어려운 표적을 만났다. Claude에게 "이 시스템에 대한 익스플로잇을 짜 달라"고 요청했더니, 매우 정교한 0-day 익스플로잇 코드를 만들어 줬다. 시도해 보니 작동한다.

마지막 질문(AI 사용 명시)이 중요합니다. 7장에서 다시 다루지만, AI 산출물은 본인이 만들었다고 표시하면 책임이 완전히 본인에게 옵니다. AI를 썼다는 사실은 숨기는 것이 아니라 명시하는 것이 윤리적 표준입니다.