반출할 수 없는 로그

한 줄 요약

은행 현장에서 조사가 느려지는 진짜 이유는 기술이 아니라 망분리와 반출 통제이고, 그 제약을 전제로 조사 방법을 짜지 않으면 첫 주를 통째로 날린다.

왜 이게 필요했나

다른 고객사에서 하던 대로 하려다 첫날 막히는 일이 은행에서는 거의 확실하게 일어납니다.

"로그 좀 받아서 제 노트북에서 분석할게요"    → 반출 불가"화면 캡처해서 슬랙에 올릴게요"              → 촬영·캡처 금지"제 노트북 가져가서 붙일게요"                → 개인 기기 반입 불가"인터넷에서 이 도구 받아서 쓰겠습니다"        → 업무망은 인터넷과 분리"운영 DB 에 붙어서 조회해 볼게요"            → 운영계 직접 접근 불가

이건 그 고객사가 유난스러운 것이 아닙니다. 전자금융감독규정과 관련 지침이 요구하는 통제이고, 지키지 않으면 은행이 제재를 받습니다. 담당자에게 "한 번만 봐 달라" 고 부탁할 성질의 것이 아니라는 뜻입니다.

어떻게 동작하나

FDE 가 알아야 할 통제는 크게 넷입니다.

망분리. 업무망과 인터넷망이 물리적으로 또는 논리적으로 분리돼 있습니다. 업무망 PC 로는 외부 인터넷에 나갈 수 없고, 인터넷망 PC 로는 운영 시스템에 붙을 수 없습니다. 그래서 "검색해서 찾아본다" 와 "시스템을 본다" 를 동시에 할 수 없습니다. 두 화면을 번갈아 보며 일하게 되는데, 이걸 모르고 일정을 잡으면 예상의 두 배가 걸립니다.

반출 통제. 업무망 안의 데이터는 밖으로 나갈 수 없습니다. 나가야 한다면 반출 승인 절차를 거치고, 그 절차는 보통 며칠 걸립니다. 로그 파일 하나도 예외가 아닙니다.

접근 통제와 로그 보존. 누가 언제 무엇을 조회했는지가 전부 남습니다. 운영 데이터 접근은 대개 승인 기반이고, 승인 없이 붙는 경로 자체가 없습니다. 접근 기록의 보존 기간도 규정으로 정해져 있습니다.

계정 분리. 조회 계정과 변경 계정이 다르고, 운영계와 개발계 계정이 다릅니다. 조사하다가 고치고 싶어져도 그 계정으로는 못 고칩니다. 이건 불편이 아니라 설계입니다.

현장에서 만나는 모습

첫째, 조사 결과를 밖으로 가져오는 대신 안에서 요약을 만듭니다. 원본 로그는 못 나가지만 "몇 시 몇 분에 어떤 오류가 몇 건" 이라는 집계는 나갈 수 있습니다. 그래서 은행 현장 조사는 처음부터 집계를 만드는 방향으로 설계해야 합니다. 원본을 통째로 들고 나와 나중에 분석하겠다는 계획은 성립하지 않습니다.

둘째, 필요한 것을 미리 목록으로 만들어 한 번에 요청합니다. 반출 승인이든 접근 권한이든 한 건에 며칠이 걸리므로, 조사하다가 하나씩 요청하면 일주일이 그냥 갑니다. 첫날에 "이 조사에 필요한 것" 을 최대한 넓게 잡아 한 번에 올리는 것이 정답입니다. 나중에 안 쓰게 되는 것이 있어도 괜찮습니다.

셋째, 고객사 담당자의 화면을 빌려 보는 시간이 실제 조사 시간입니다. 우리가 직접 붙을 수 없는 경우가 많아서, 담당자 옆에서 "이 쿼리를 쳐 주세요" 하며 진행합니다. 그 사람의 시간은 우리 시간이 아니므로 하루 한두 시간뿐일 수 있습니다. 그 시간 안에 무엇을 볼지 미리 적어 가지 않으면 아무것도 못 봅니다.

넷째, 못 가져온다는 것을 보고서에 적어야 합니다. "로그를 확인할 수 없어 추정한다" 와 "로그를 확인했고 이렇게 나왔다" 는 신뢰도가 다른 결론입니다. 제약 때문에 확인하지 못한 것을 확인한 것처럼 적으면, 그 결론이 틀렸을 때 우리가 거짓말한 것이 됩니다. 제약을 적는 것은 변명이 아니라 결론의 근거를 정확히 밝히는 일입니다.

다음 이론에서 확인할 것

조사 중에 개인정보를 보게 됐을 때 보고서에 무엇을 쓰고 무엇을 쓰면 안 되는지를 다룹니다.