정보보안 취업을 준비하는 분의 포트폴리오를 살펴보면서 웹 서버에서 발생한 로그인 기록을 분석한 프로젝트를 확인한 적이 있습니다. 자료에는 하루 동안 발생한 로그인 실패 횟수와 접속 IP가 표로 정리되어 있었고, 특정 IP에서 실패가 반복되었으므로 무차별 대입 공격이 의심된다는 결론도 적혀 있었습니다. 처음에는 보안 직무와 관련된 경험처럼 보였지만, 분석 기준을 묻자 설명이 짧아졌습니다. 몇 회 이상 실패하면 이상 징후로 판단했는지, 같은 사용자가 비밀번호를 잘못 입력한 상황과 자동화된 공격을 어떻게 구분했는지, 성공한 접속 기록까지 함께 확인했는지가 정리되어 있지 않았기 때문입니다.
원본 기록을 다시 살펴보니 짧은 시간에 여러 계정을 바꾸어 시도한 IP가 있었고, 새벽 시간대에 실패가 집중된 구간도 확인되었습니다. 반면 다른 IP의 반복 실패는 한 계정에서만 발생했고 몇 분 뒤 정상 접속으로 이어졌기 때문에 단순 입력 실수일 가능성이 높았습니다. 준비생은 시간대, IP, 계정, 성공 여부를 기준으로 데이터를 다시 분류하고 판단 근거를 수정했습니다. 이후 의심스러운 시도의 위험도를 구분하고 계정 잠금 정책, 로그인 시도 제한, 추가 인증 적용과 같은 개선 방향까지 제안했습니다.
보안 입문 프로젝트를 취업에 활용하려면 공격 도구를 사용했다거나 취약점을 발견했다는 결과만 강조해서는 부족합니다. 정상과 이상을 구분한 기준, 잘못 판단할 가능성을 검토한 과정, 발견 내용을 상대방이 조치할 수 있도록 정리한 결과가 함께 보여야 합니다. 로그인 기록 몇 줄이나 간단한 웹 취약점 실습이라도 로그분석, 취약점점검, 보고서작성이 하나의 흐름으로 연결되면 신입 지원자의 관찰력과 책임감을 보여주는 취업 자료가 될 수 있습니다.
로그인 기록의 흐름을 읽는 로그분석 경험이 필요합니다
- 횟수만 집계하면 중요한 맥락을 놓칠 수 있습니다
로그를 처음 다루는 준비생은 오류 코드나 실패 횟수부터 집계하는 경우가 많습니다. 그러나 로그인 실패가 많다는 사실만으로 공격이라고 단정할 수는 없습니다. 사용자가 비밀번호를 잊었을 수도 있고, 저장된 인증 정보가 변경되어 애플리케이션에서 반복 오류가 발생했을 수도 있습니다. 반대로 전체 실패 횟수는 많지 않더라도 짧은 시간에 여러 계정을 바꾸어 접근했다면 계정 정보를 대입하는 시도일 가능성을 살펴봐야 합니다.
따라서 시간, IP 주소, 계정, 요청 경로, 성공 여부를 함께 비교해야 합니다. 동일 IP에서 10분 동안 여러 계정을 시도했는지, 하나의 계정에 여러 지역의 IP가 접근했는지, 실패 뒤 정상 접속이 이어졌는지도 확인할 필요가 있습니다. 이 기준을 정리하면 단순 집계가 행동 패턴을 파악하는 과정으로 발전합니다.
- 정상 사용 가능성을 먼저 제외해야 합니다. 사내 테스트 계정, 모니터링 프로그램, 개발자의 반복 접속처럼 업무상 발생할 수 있는 기록을 확인하지 않으면 정상 활동을 위협으로 잘못 판단할 수 있습니다. 분석 전에 시스템의 사용 환경과 계정 종류를 파악하는 이유가 여기에 있습니다.
- 시간의 흐름을 함께 봐야 합니다. 하루 전체의 실패 횟수만 보면 짧은 시간에 집중된 접근과 일정한 간격으로 이어진 시도를 구분하기 어렵습니다. 분 단위와 시간대별로 다시 묶어보면 자동화된 행동의 특징을 더 구체적으로 확인할 수 있습니다.
- 처음 세운 판단이 틀렸던 과정도 경험이 됩니다
한 준비생은 웹 서버 기록에서 특정 해외 IP의 요청량이 많다는 이유로 공격이라고 판단했습니다. 해당 주소를 차단하는 방향까지 제안했지만 요청 경로를 확인하니 이미지와 자바스크립트 파일을 수집하는 검색 엔진 크롤러의 접근이 대부분이었습니다. 사용자 에이전트와 요청 간격, 오류 응답 비율을 추가로 살펴본 뒤 악성 접근이라는 결론을 수정했습니다.
그 과정에서 모든 해외 접근이나 많은 요청을 위험으로 판단해서는 안 된다는 점을 배울 수 있었습니다. 이후에는 요청량뿐 아니라 접근 대상, 반복 간격, 응답 코드, 인증 시도 여부를 함께 확인하는 기준을 만들었습니다. 처음의 오판을 숨기기보다 어떤 정보가 부족했고 무엇을 추가로 확인해 결론을 바꾸었는지 설명하면 분석 태도를 보여주는 사례가 됩니다.
- 결과만 제시한 설명: 웹 서버 기록을 확인해 공격이 의심되는 IP를 발견했습니다.
- 확인 과정이 보이는 설명: 동일 IP에서 짧은 시간 동안 여러 계정의 로그인이 실패한 구간을 찾아 시간대와 계정별로 분류했습니다.
- 판단 근거가 담긴 설명: 로그인 실패 횟수만으로 공격을 단정하지 않고 성공 기록과 요청 간격을 함께 비교했습니다. 한 계정에서 실패 후 정상 접속한 기록은 입력 실수 가능성이 높다고 보았고, 여러 계정을 일정한 간격으로 시도한 IP는 자동화된 접근 가능성이 있다고 판단했습니다. 이후 계정 잠금과 시도 횟수 제한 방안을 제안하고 분류 기준을 문서에 남겼습니다.
- 분석 결과는 조치 방향으로 이어져야 합니다
이상 징후를 발견했다고 작성하는 데서 프로젝트를 끝내면 취업 자료의 깊이가 부족해질 수 있습니다. 발견한 행동이 어떤 위험으로 이어질 수 있는지와 현재 설정에서 이를 줄일 방법이 무엇인지 연결해야 합니다. 로그인 실패가 반복되었다면 단순히 IP를 차단하는 방법만 제시하기보다 시도 횟수 제한, 추가 인증, 알림 설정, 비정상 접근 기준 개선을 함께 검토할 수 있습니다.
조치 후 확인 과정도 필요합니다. 계정 잠금 기준을 너무 엄격하게 설정하면 정상 사용자의 접근까지 방해할 수 있기 때문에 보안성과 사용성을 함께 고려해야 합니다. 개인 실습에서는 실제 운영 환경에 적용하지 못하더라도 테스트 계정으로 정상 로그인과 반복 실패 상황을 재현하고 정책 적용 전후의 변화를 비교할 수 있습니다. 이러한 기록은 탐지에서 끝나지 않고 대응까지 고민했다는 근거가 됩니다.
도구 결과를 그대로 믿지 않는 취약점점검 태도가 중요합니다
- 점검 전에 대상과 허용 범위를 정해야 합니다
보안 실습에서는 취약점 스캐너나 프락시 도구를 사용하는 장면이 자주 등장합니다. 하지만 허가되지 않은 시스템을 점검하거나 범위를 벗어난 공격을 시도해서는 안 됩니다. 개인이 구축한 테스트 서버, 교육용 실습 환경, 명시적으로 사용이 허용된 플랫폼처럼 안전한 대상을 선택해야 합니다. 포트폴리오에도 점검 대상과 범위, 허용된 테스트 조건을 적어 책임 있는 태도를 보여주는 것이 좋습니다.
예를 들어 직접 만든 게시판을 대상으로 인증, 입력값 처리, 권한 확인 항목을 살펴본다면 어떤 기능을 점검했는지 먼저 정의할 수 있습니다. 로그인하지 않은 사용자의 관리자 페이지 접근, 다른 사용자의 게시글 수정, 검색창 입력값 처리처럼 구체적인 시나리오를 만들면 도구 실행보다 목적이 분명해집니다.
- 점검 대상은 기능 단위로 좁혀야 합니다. 웹 서비스 전체를 점검했다는 표현보다 로그인, 게시글 수정, 파일 업로드처럼 확인한 범위를 정확히 적어야 결과의 신뢰도가 높아집니다. 확인하지 않은 영역까지 안전하다고 표현하지 않는 것도 중요합니다.
- 실습 환경을 분리해야 합니다. 실제 개인정보가 없는 테스트 계정을 사용하고, 운영 중인 서비스가 아닌 별도 환경에서 진행해야 합니다. 캡처 화면과 문서에 계정, IP, 토큰 같은 민감한 정보가 노출되지 않았는지도 확인해야 합니다.
- 자동화 도구의 결과는 직접 재현해야 합니다
한 준비생은 취약점 스캐너를 실행한 뒤 높은 위험도로 표시된 항목을 모두 포트폴리오에 넣었습니다. 그중에는 보안 헤더가 없다는 항목과 오래된 라이브러리를 사용한다는 경고가 포함되어 있었습니다. 하지만 실제 서비스의 기능과 버전을 확인하니 일부는 적용되지 않는 조건이었고, 동일한 경고가 중복으로 탐지된 경우도 있었습니다.
준비생은 결과를 다시 분류해 실제로 재현할 수 있는 항목, 설정 확인이 필요한 항목, 현재 환경에는 적용되지 않는 항목으로 구분했습니다. 이후 관리자 권한 확인이 빠진 게시글 수정 기능을 테스트 계정 두 개로 재현했습니다. 일반 사용자 계정으로 다른 사용자의 게시글 ID를 요청했을 때 수정이 가능한 현상을 확인하고, 서버에서 작성자와 요청자의 정보를 비교하도록 수정한 뒤 같은 요청이 거부되는지 재검증했습니다.
- 도구 사용에 머문 설명: 보안 스캐너를 이용해 여러 취약점을 발견했습니다.
- 재현 과정이 포함된 설명: 자동 탐지 결과 중 실제 서비스에 적용되는 항목을 분류하고 테스트 계정으로 권한 확인 누락을 재현했습니다.
- 개선까지 연결한 설명: 사용자 A가 작성한 게시글을 사용자 B의 계정으로 수정할 수 있는지 요청을 바꾸어 확인했습니다. 서버에서 작성자 검증이 빠져 다른 사용자의 수정 요청도 처리된다는 사실을 발견했고, 인증 정보와 게시글 소유자를 비교하도록 수정했습니다. 이후 정상 사용자와 권한이 없는 사용자의 요청을 각각 다시 실행해 허용과 거부가 의도대로 동작하는지 검증했습니다.
- 위험도는 이름보다 실제 영향을 기준으로 판단합니다
취약점 이름이 유명하거나 도구에서 높은 등급을 표시했다고 해서 모든 환경에서 같은 위험을 갖는 것은 아닙니다. 공격에 필요한 조건, 외부 노출 여부, 접근 가능한 정보, 서비스에 미치는 영향, 악용 가능성을 함께 확인해야 합니다. 개인 실습에서는 정교한 위험 평가 체계를 모두 적용하지 못하더라도 판단 기준을 명확히 적는 것이 중요합니다.
예를 들어 오류 화면에 서버 경로가 노출되는 문제와 다른 사용자의 정보를 조회할 수 있는 권한 문제를 발견했다면 조치 우선순위는 달라질 수 있습니다. 내부 경로 노출도 개선해야 하지만 개인정보 접근 가능성이 있는 문제는 영향 범위가 더 클 수 있습니다. 발견 순서대로 나열하지 말고 서비스 영향과 악용 가능성을 기준으로 우선순위를 정해야 보고서의 실용성이 높아집니다.
실제 포트폴리오에서는 스캐너 화면을 많이 첨부했지만 왜 위험한지 설명하지 못하는 경우가 있습니다. 반대로 발견한 항목이 한두 개뿐이어도 발생 조건과 영향 범위, 수정 방법, 재검증 결과가 분명하면 지원자의 이해도를 확인하기 쉽습니다. 신입 프로젝트에서는 많이 찾았다는 표현보다 확인할 수 있는 범위 안에서 정확하게 검증했다는 태도가 더 중요합니다.
발견과 개선을 연결하는 보고서작성이 취업 자료를 완성합니다
- 보고서는 활동 일지가 아니라 판단 자료입니다
보안 프로젝트 보고서를 작성할 때 도구 실행 화면과 명령어를 시간순으로 나열하는 경우가 많습니다. 하지만 실무에서 문서를 읽는 사람은 무엇을 발견했으며, 어느 항목부터 조치해야 하고, 수정 후 상태가 어떻게 달라졌는지를 알고 싶어 합니다. 따라서 보고서에는 점검 목적, 대상과 범위, 발견 내용, 증거, 위험도, 개선 방법, 재검증 결과가 연결되어야 합니다.
발견 내용에는 관찰한 사실과 해석을 구분해서 적는 것이 좋습니다. 동일 IP에서 여러 로그인 실패가 발생했다는 것은 확인된 사실이지만, 계정 탈취 공격이라는 판단은 추가 근거가 필요한 해석입니다. 문서에서 두 내용을 섞지 않으면 과장된 결론을 줄이고 다른 사람이 결과를 다시 검토하기 쉬워집니다.
- 증거 자료에는 필요한 정보만 남겨야 합니다. 전체 로그나 화면을 그대로 첨부하면 계정, 세션값, 내부 주소가 노출될 수 있습니다. 판단에 필요한 부분을 선별하고 민감한 값은 가린 뒤 수집 시간과 확인 조건을 함께 적는 것이 좋습니다.
- 개선 방법은 적용 가능한 수준으로 작성해야 합니다. 보안을 강화해야 한다는 표현보다 서버에서 요청자의 권한을 다시 확인하고 권한이 없으면 거부 응답을 반환하도록 수정한다는 식으로 구체화해야 합니다. 담당자가 무엇을 바꿔야 하는지 알 수 있어야 의미 있는 제안이 됩니다.
- 독자가 달라지면 설명의 깊이도 달라져야 합니다
같은 결과라도 개발자에게 전달하는 문서와 비기술 담당자에게 설명하는 자료는 표현이 달라야 합니다. 개발자에게는 재현 요청, 관련 기능, 수정이 필요한 로직을 구체적으로 전달해야 합니다. 관리 담당자에게는 서비스 영향과 우선순위, 조치하지 않았을 때의 위험을 이해하기 쉽게 설명해야 합니다.
한 준비생은 파일 업로드 기능에서 확장자만 확인하고 파일 내용을 검증하지 않는 문제를 발견했습니다. 처음 작성한 자료에는 요청값과 응답 화면만 길게 첨부되어 있어 어떤 문제가 있는지 이해하기 어려웠습니다. 그는 보고서 첫 부분에 허용되지 않은 형식의 파일이 저장될 가능성이 있다는 영향을 설명하고, 뒤쪽에 테스트 환경과 재현 단계, 수정 전후 결과를 배치했습니다. 개발자를 위한 부분에는 파일 유형과 저장 위치를 서버에서 다시 확인해야 한다는 개선 방향을 적었습니다.
- 발견 사실만 적은 문장: 파일 업로드 기능에서 취약점을 발견했습니다.
- 상황을 설명한 문장: 확장자만 검사하는 조건에서는 파일 이름을 변경한 요청이 업로드되는 현상을 테스트 환경에서 확인했습니다.
- 조치 판단까지 담은 문장: 허용된 이미지 형식만 받을 의도였지만 파일 이름의 확장자만 확인하고 실제 형식을 검증하지 않았습니다. 테스트 파일로 현상을 재현한 뒤 서버에서 파일 유형과 크기를 함께 확인하도록 수정했고, 정상 이미지와 허용되지 않은 파일을 다시 업로드해 결과를 비교했습니다. 보고서에는 재현 조건과 영향 범위, 수정 방법을 분리해 기록했습니다.
- 수정 후 재검증이 문서의 신뢰도를 높입니다
취약점을 발견하고 개선 방법을 제안했더라도 수정 결과를 확인하지 않으면 문제가 실제로 해결되었는지 알 수 없습니다. 조치 전과 같은 계정, 요청값, 테스트 환경에서 다시 확인해야 비교가 가능합니다. 수정 후 공격 요청이 차단되는지뿐 아니라 정상 기능이 그대로 동작하는지도 함께 검증해야 합니다.
게시글 권한 확인을 추가했다면 다른 사용자의 수정 요청은 거부되고 작성자 본인의 요청은 정상 처리되는지 모두 확인해야 합니다. 로그인 시도 제한을 적용했다면 반복 실패가 차단되는지와 정상 사용자가 지나치게 오래 접근하지 못하는 문제는 없는지도 살펴볼 필요가 있습니다. 이러한 결과를 표나 짧은 문장으로 정리하면 문제 발견과 해결이 한눈에 연결됩니다.
면접에서는 보고서 전체를 외우기보다 가장 판단이 필요했던 항목 한두 개를 골라 설명하는 것이 효과적입니다. 무엇을 발견했는지, 처음 예상과 실제 원인이 어떻게 달랐는지, 위험도를 어떤 기준으로 정했는지, 수정 후 무엇을 다시 확인했는지를 순서대로 말하면 됩니다. 이렇게 정리된 문서는 포트폴리오의 첨부 자료를 넘어 문제해결 답변을 준비하는 기반이 됩니다.
- conclusion
보안 입문 프로젝트를 취업 준비에 활용하는 핵심은 많은 공격 기법이나 도구를 보여주는 데 있지 않습니다. 기록에서 이상 징후를 구분한 기준, 발견된 문제를 직접 재현한 과정, 서비스 영향에 따라 조치 순서를 정한 판단이 보여야 합니다. 여기에 개선 전후를 비교한 결과까지 연결하면 작은 실습도 보안 직무에 필요한 관찰력과 책임감을 보여주는 자료가 됩니다.
지금 자신의 결과물을 다시 확인할 때는 스캐너 화면이나 명령어 목록보다 판단의 근거가 남아 있는지 살펴보는 것이 좋습니다. 의심스러운 기록을 왜 위험하다고 보았는지, 정상 행동일 가능성은 어떻게 검토했는지, 같은 현상을 다른 사람이 재현할 수 있는지 확인해야 합니다. 처음 판단이 틀렸거나 도구의 결과가 실제 환경과 달랐더라도 추가 확인을 통해 결론을 수정했다면 충분한 경험이 됩니다.
- 로그를 다룬 프로젝트라면 시간, IP, 계정, 요청 경로, 성공 여부를 함께 비교했는지 점검해야 합니다. 실패 횟수만 집계하지 않고 정상 사용과 자동화된 접근을 구분한 기준이 있어야 분석 경험으로 설명할 수 있습니다.
- 취약한 기능을 확인한 실습이라면 허용된 환경에서 진행했는지와 발생 조건을 재현했는지 살펴봐야 합니다. 자동화 도구의 결과를 그대로 옮기지 않고 실제 영향과 악용 가능성을 검토했다면 위험도 판단 역량을 보여줄 수 있습니다.
- 문서를 정리할 때는 발견 내용, 근거, 영향 범위, 개선 방법, 재검증 결과가 이어지는지 확인해야 합니다. 민감한 정보는 제거하고 조치 우선순위를 표시하면 단순한 활동 기록이 실제로 활용할 수 있는 자료로 바뀝니다.
실제 포트폴리오를 검토하면 공격 도구를 실행한 화면은 많지만 왜 해당 항목을 위험하다고 판단했는지 설명이 빠진 경우가 많습니다. 이 상태에서는 도구 사용 여부는 확인할 수 있어도 지원자가 결과를 해석할 수 있는지는 알기 어렵습니다. 반대로 하나의 로그인 이상 징후라도 정상 가능성을 검토하고, 근거를 비교하며, 개선책을 제안한 과정이 있다면 면접에서 더 깊은 답변을 만들 수 있습니다.
프로젝트를 마친 뒤에는 가장 많은 결과를 찾은 장면보다 판단이 바뀐 장면을 먼저 기록해 보세요. 처음 세운 가설, 추가로 확인한 정보, 최종 결론, 개선 조치, 다시 검증한 결과를 연결하면 이력서에서는 문제해결 경험으로 압축할 수 있고 면접에서는 꼬리 질문에 답하는 근거로 사용할 수 있습니다. 결국 보안 실습이 취업 자료로 바뀌는 순간은 취약점을 발견했을 때가 아니라, 확인한 사실을 과장하지 않고 상대방이 조치할 수 있는 형태로 전달할 수 있게 되었을 때입니다.
