☰
jena.run
⌕
♡
💻 개발

처음 보안 직무에 뛰어드는 사람들을 위한 가이드

뭘 공부해야 할지 모르겠다면, 일단 여기서부터 시작해보자

처음 보안 직무에 뛰어드는 사람들을 위한 가이드

이 글을 보고 있다는 것은 보안 직무에 관심이 있거나, 포폴을 작성하고 있다던가, 정보보안학과에 막 입학을 앞둔 새내기거나, 아니면 이미 전공생일 거라고 생각한다.

특히 나의 경우에도 처음 정보보안을 시작할 때 비전공자였기에, 사실상 혼자서 대부분을 배워나갈 수밖에 없는 위치였다.

뭐 누구한테 물어볼 선배가 있는 것도 아니고,

“그래서 뭘 공부해야 하는데?”

하고 검색하면 누구는 네트워크부터 하라고 하고, 누구는 리눅스부터 하라고 하고, 누구는 C언어부터 하라고 하고, 또 누구는 냅다 Kali Linux부터 설치하라고 한다.

결국 이것저것 몸으로 부딪혀가면서 배웠다.

그래서 나름 보안계 자수성가(?)한 입장에서, 처음 시작할 때 내가 알았으면 좋았을 것들을 경험과 함께 한번 적어보려고 한다.

1. 정보보안, 어떤 분야가 있나요?

일단 생각나는 것부터 적어보자면,

Web Hacking
Network Security
Linux Security
Windows Security
Cloud Security
Malware Analysis
Reverse Engineering
DFIR
SOC
SIEM
EDR
IAM
DevSecOps
Cryptography
CTF
Bug Bounty
AWS
Kubernetes

이 정도가 있다. 물론 이거 말고도 훨씬 많다.

기억 안 나는 관계로 패스. 처음 보면 아마 이런 생각이 든다.

그래서 뭘 먼저 공부해야 하는데? 어디서부터 시작해야 하는데?

내가 가장 많이 듣는 질문이기도 하다. 내 답은 생각보다 단순하다.

보안을 먼저 공부하지 말고, 시스템부터 공부하라.

왜냐하면 보안이라는 게 결국 시스템이 어떻게 돌아가는지 이해하고,

“여기서 뭘 믿고 있지?”

“이걸 이상하게 사용하면 어떻게 되지?”

를 찾아내는 일이기 때문이다.

정상적인 동작을 모르는데 비정상적인 동작부터 찾으려고 하면 꽤 고생한다. 나도 해봤다. 경험담이다. 제발 시스템부터 공부해라. 나도 알고 싶지 않았다.

2. 보안은 하나의 직무가 아니다

먼저 이것부터 알아야 한다.

채용공고에 똑같이 Security Engineer, 보안 엔지니어라고 적혀 있어도 실제 하는 일은 회사마다 완전히 다를 수 있다.

대략 나눠보면 이런 식이다.

  • Offensive Security
  • Defensive Security
  • Cloud Security
  • Application Security
  • Incident Response
  • Threat Intelligence
  • Governance / Risk / Compliance

물론 실제 회사에 들어가면 경계가 저렇게 예쁘게 나뉘지는 않는다.

AppSec 하다가 Cloud도 보고, Pentest 하다가 Incident 대응도 하고, 보안 엔지니어인데 갑자기 개발팀 GitHub Actions까지 뜯고 있을 수도 있다.

보안팀 인원이 적으면?

축하한다.

다 한다.

그래도 처음 시작할 때는 하나 정도 방향성을 잡는 것이 좋다.

처음부터 전부 잘할 필요는 없다. 사실 전부 잘하는 사람도 거의 없다.

Offensive Security

보통 사람들이 화이트해킹이라고 하면 가장 먼저 떠올리는 영역이다.

필자 역시 이쪽 분야에서 일을 하고 있다.

주로 하는 일은 이런 것들이다.

  • Web Pentesting
  • Mobile Pentesting
  • API Security Testing
  • Internal Network Testing
  • Red Teaming
  • Cloud Pentesting
  • Vulnerability Research

Burp Suite라는 걸 들고 웹을 테스트하거나,

APK를 뜯거나,

Active Directory 환경을 돌아다니거나,

AWS IAM 설정을 보면서

“아니 이 Role은 대체 왜 AdministratorAccess가 붙어있지?”

같은 고민을 하는 직무다.

이쪽이 재미있으려면 이런 질문이 즐거워야 한다.

“요 기능을 원래 의도와 다르게 사용할 수 있을까?”

사실 Offensive Security에서 중요한 건 도구를 얼마나 많이 외웠느냐보다 이런 발상의 전환에 가깝다.

예를 들어 어떤 기기가 특정 조건에서 별도의 충분한 검증 없이 다른 시스템과 통신할 수 있다는 걸 알아냈다고 치자.

그럼 단순히

“연결이 되네?”

에서 끝나는 게 아니라,

Device
   |
   v
Trusted Connection
   |
   v
Unexpected Input
   |
   v
Code Execution?

까지 생각해보는 것이다.

“이거랑 저거를 연결하면 어떻게 되지?”

“개발자는 이 사용법까지 생각했을까?”

“인증은 있는데 authorization은?”

이런 약간 이상한(?) 생각을 많이 하는 사람이 꽤 잘 맞는다.

정상적인 기능을 비정상적으로 사용하는 창의성이 중요하다.

Defensive Security

SOC, Blue Team, Detection Engineering 같은 분야다.

누군가 공격했을 때 그 공격 시도를 어떻게 발견할지 고민하는 쪽이라고 보면 된다.

주로 이런 것들을 다룬다.

  • SIEM
  • EDR
  • Log Analysis
  • Threat Hunting
  • Detection Engineering
  • Incident Response

쉽게 말하면 흔적을 보고 범인을 찾는 쪽이다.

어렸을 때 코난 같은 추리물을 좋아했다면 은근 잘 맞을 수도 있다.

예를 들어 EDR에서 갑자기 이런 Process Tree가 찍혔다고 하자.

powershell.exe
    |
    v
rundll32.exe
    |
    v
External Connection

이걸 보고

“왜 PowerShell이 저 프로세스를 실행했지?”

“누가 실행했지?”

“저 IP는 어디지?”

“이 전에 어떤 파일이 생성됐지?”

라는 생각이 들면 이쪽 방향성이 괜찮을지도 모른다.

Offensive 쪽이

“내가 어떻게 들어가지?”

를 고민한다면,

Defensive 쪽은

“얘가 어떻게 들어왔지?”

를 고민한다.

둘 다 재밌다.

Application Security

개발자와 가장 가까이 붙어서 일하는 보안 직무 중 하나다.

보통 줄여서 AppSec이라고 많이 부른다.

하는 일은 회사마다 다르지만 대충 이런 느낌이다.

  • Secure Code Review
  • SAST / DAST
  • Threat Modeling
  • Dependency Security
  • API Security
  • CI/CD Security
  • Security Architecture

개발팀에서 새로운 서비스를 만들었다고 하자.

그러면 AppSec에서는

인증 구조 괜찮나?

권한 체크 어디서 하지?

사용자 입력은 어디로 들어가지?

Secret이 코드에 박혀 있지는 않나?

이 API 외부에서 바로 호출 가능한데?

이런 걸 본다.

코드를 좋아하고 개발 경험도 있다면 꽤 추천하는 분야다.

특히 개발자로 일하다가 보안으로 넘어오고 싶다는 사람에게는 개인적으로 AppSec이 꽤 좋은 선택지라고 생각한다.

왜냐하면 개발을 이해하는 보안 엔지니어가 생각보다 상당히 귀하다.

보안팀이 개발자에게

“그냥 보안상 위험하니까 막아주세요.”

라고 말하는 것과,

“현재 object authorization이 resolver마다 구현되어 있어서 누락 가능성이 있으니 authorization layer를 중앙화하는 게 좋을 것 같습니다.”

라고 이야기하는 건 완전히 다르다.

개발자가 후자를 훨씬 좋아한다.

당연하다.

Cloud Security

AWS, Azure, GCP 같은 Cloud Infrastructure의 보안을 담당하는 분야다.

요즘 개인적으로 정말 중요하다고 생각하는 영역이다.

주로 이런 걸 본다.

  • IAM
  • VPC / Network
  • Secrets
  • Kubernetes
  • Container Security
  • CloudTrail
  • Workload Identity
  • CI/CD
  • Cloud Security Posture

Cloud Security에서 정말 많이 보는 게 권한이다.

예를 들어 이런 구조가 있다고 하자.

GitHub Actions
      |
      v
OIDC
      |
      v
AWS STS
      |
      v
IAM Role
      |
      v
Production

그러면 질문은 이거다.

왜 이 Repository가 이 Role을 가져갈 수 있지?

아무 Branch에서나 가능한가?

PR에서도 가능한가?

Role Permission은 어디까지인가?

Cloud는 워낙 자동화가 많아서 설정 하나가 잘못되면 Blast Radius가 상당히 커질 수 있다.

반대로 인프라 좋아하고 AWS 만지는 거 좋아하면 진짜 재밌다.

나는 개인적으로 IAM Policy 읽다가 이상한 Trust Relationship 찾는 순간이 꽤 재밌는 편인데,

보통 사람들은 재미없어하더라.

취향 차이다.

Incident Response / DFIR

사고가 이미 터진 뒤 등장하는 사람들이다.

서버에서 이상한 통신이 발견됐다거나,

직원 PC가 malware에 감염됐다거나,

AWS 계정에서 이상한 API 호출이 찍혔다거나,

그럴 때

그래서 어디까지 털렸는데?

를 알아내야 한다.

Initial Access
     |
     v
Execution
     |
     v
Persistence
     |
     v
Privilege Escalation
     |
     v
Lateral Movement

공격자가 어디서 들어왔고,

뭘 실행했고,

뭘 가져갔고,

다른 시스템으로 이동했는지 추적한다.

이 분야의 특징은 로그가 당신을 배신할 수 있다는 것이다.

필요한 로그만 꼭 없거나,

로그 보존기간이 끝났거나,

시스템 시간이 이상하거나,

담당자가

“그 서버 어제 재설치했는데요?”

라고 할 수도 있다.

그러면 잠깐 멍해진다.

그래도 재밌다.

Threat Intelligence

공격자와 공격 캠페인을 분석하는 분야다.

APT37, Kimsuky, Lazarus 같은 이름을 어디선가 많이 들어봤다면 이런 분야에서 많이 다룬다.

주로

Threat Actor
     |
     +-- Infrastructure
     |
     +-- Malware
     |
     +-- TTP
     |
     +-- Victimology
     |
     +-- Campaign

를 연결해서 분석한다.

단순히

“이 IP 악성이에요.”

에서 끝나는 게 아니라,

이 인프라는 이전 어떤 공격에서도 사용됐고,

이 malware의 동작 패턴은 기존 캠페인과 유사하며,

공격 대상 산업군은 이렇다.

같은 맥락을 만든다.

뉴스, 국제정세, 공격자 TTP 찾아보는 거 좋아하면 잘 맞을 가능성이 크다.

3. 그래서 진짜 뭘 먼저 공부해야 하나요?

여기까지 읽었는데 다시 원점으로 돌아왔다.

아니 그래서 뭘 공부해야 하는데?

개인적으로 처음 시작하는 사람이라면 네 가지를 먼저 추천한다.

Operating System
Networking
Web
Programming

진짜다.

Kali Linux부터 설치하지 않아도 된다.

후드티도 아직 안 사도 된다.

Linux

보안을 할 거라면 Linux와 친해지는 게 좋다.

적어도 이런 명령어들은 인터넷 검색 없이 대충 쓸 수 있으면 편하다.

ls
cd
pwd
cat
grep
find
ps
ss
curl
chmod
chown
ssh
journalctl

근데 명령어 외우기가 중요한 건 아니다.

이런 개념을 이해해야 한다.

Process
User
Group
Permission
Service
Socket
Environment Variable
Filesystem

예를 들어 사고 대응을 하는데 어떤 process가 이상하다.

그럼 자연스럽게

이거 누가 실행했지?

어느 User 권한이지?

어떤 Port 열고 있지?

Parent Process는 뭐지?

를 볼 수 있어야 한다.

리눅스를 공부하는 건 해킹 명령어 외우는 게 아니다.

컴퓨터가 어떻게 돌아가는지 배우는 것에 가깝다.

Network

네트워크도 피하지 말자.

나중에 반드시 다시 만나게 된다.

최소한 이것들은 알아두자.

IP
Subnet
TCP
UDP
DNS
HTTP
TLS
NAT
Proxy
Firewall
Routing

막 CCNA 수준으로 라우팅 프로토콜 다 외우라는 이야기는 아니다.

최소한

Client
   |
   v
DNS
   |
   v
TCP
   |
   v
TLS
   |
   v
HTTP
   |
   v
Server

이 정도 흐름은 머릿속에 있어야 한다.

Wireshark 켜서 내가 웹사이트 하나 접속할 때 실제로 어떤 Packet이 왔다 갔다 하는지도 한번 보면 좋다.

처음에는 외계어 같다.

정상이다.

보다 보면 익숙해진다.

Web

화이트해킹을 하고 싶다면 특히 중요하다.

현대 서비스 대부분이 어쨌든 웹이랑 연결되어 있다.

기본적인 구조부터 이해하자.

Browser
   |
   v
Frontend
   |
   v
API
   |
   v
Backend
   |
   v
Database

그리고 이것들은 웬만하면 알고 있어야 한다.

HTTP
Cookie
Session
JWT
CORS
Same-Origin Policy
Authentication
Authorization
REST
GraphQL

특히 Authentication과 Authorization 차이는 정말 중요하다.

Authentication은

너 누구야?

고,

Authorization은

네가 이거 해도 돼?

다.

로그인을 했다고 모든 데이터를 볼 수 있는 게 아니다.

이 차이에서 수많은 취약점이 나온다.

Programming

보안하려면 코딩 잘해야 하냐는 질문도 엄청 많이 듣는다.

답은

분야마다 다르다.

Reverse Engineering이나 Vulnerability Research를 하려면 꽤 깊게 해야 한다.

반대로 SOC Analyst라면 개발자 수준까지 할 필요는 없을 수도 있다.

그래도 최소한 코드 읽고 간단한 자동화 정도는 할 줄 알면 무조건 도움이 된다.

처음에는 Python 추천한다.

import requests

response = requests.get("https://example.com")

print(response.status_code)
print(response.headers)

이런 것부터 하면 된다.

이후 필요한 순간에

JavaScript
Bash
PowerShell
C
Go

같은 걸 추가하면 된다.

처음부터 언어 6개 배우지 마라.

진짜 하지 마라.

하나도 제대로 못하게 된다.

4. 화이트해킹을 하고 싶다면?

웹부터 시작하는 걸 추천한다.

결과가 눈에 바로 보이고, 기본적인 보안 사고방식을 배우기 좋다.

처음에는 이런 취약점들을 보면 된다.

  • IDOR / BOLA
  • XSS
  • SQL Injection
  • CSRF
  • SSRF
  • File Upload
  • Path Traversal
  • Authentication Flaws
  • Authorization Flaws
  • Business Logic Vulnerabilities

근데 여기서도 이름 외우는 게 목적이 아니다.

예를 들어 IDOR를 공부한다면

User A
   |
   v
Object A

이게 정상 구조다.

그런데

User A
   |
   v
Object B

도 접근된다면?

그때 이런 질문을 한다.

서버는 Object B가 누구 것인지 검사했나?

이런 식으로 Trust Boundary를 보는 습관을 들이는 게 좋다.

Burp Suite는 어떻게 배우나요?

처음 열면 버튼이 많아서 약간 당황한다.

다 필요 없다.

초반에는 이 정도만 써도 된다.

Proxy
HTTP History
Repeater
Decoder

웹사이트 돌아다니면서 HTTP request를 본다.

GET /api/profile HTTP/1.1
Host: example.com
Cookie: session=...

그리고 Repeater로 보내서 이것저것 바꿔본다.

Parameter
Cookie
Header
Object ID
HTTP Method

사실 Burp Suite 배우는 과정은 HTTP 배우는 과정이라고 생각해도 된다.

도구를 배우는 게 아니라 요청과 응답을 보는 법을 배우는 것이다.

5. CTF 많이 하면 취업 가능한가요?

CTF 좋다.

나도 추천한다.

머리 쓰는 재미도 있고 기술 배우기도 좋다.

근데 하나는 알아야 한다.

CTF
 !=
Real-world Pentest

CTF에는 정답이 있다.

어딘가 Flag가 존재한다.

flag{something_here}

실제 모의해킹에는 그런 거 없다.

하루 종일 테스트했는데 아무것도 안 나올 수도 있다.

그리고 실제 업무에서는 기술 말고도 이런 게 중요하다.

Scope
Evidence
Impact
Reproducibility
Communication
Safety
Report

취약점 하나 발견했다고 Production 데이터를 다 뽑으면 안 된다.

“되는 것 같은데?”를 확인하겠다고 고객 DB 날리면 더 안 된다.

취약점을 안전하게 증명하는 방법 역시 기술이다.

6. 보고서를 잘 쓰는 것도 실력이다

화이트해킹한다고 하면 다들 뚫는 것만 생각한다.

근데 실무 들어오면 문서를 엄청 쓴다.

진짜 엄청 쓴다.

개발팀에게

IDOR exists.

Critical.

이라고 던지면 욕먹기 딱 좋다.

좋은 보고서는 최소한 이런 질문에 답해야 한다.

Where is it?

Who can exploit it?

What is affected?

What is the actual impact?

How can it be reproduced?

How should it be fixed?

결국 보안팀의 목적은

“내가 이거 뚫었다.”

하고 자랑하는 게 아니다.

취약점을 고치게 만드는 것이다.

그래서 의외로 글 잘 쓰는 사람이 상당히 유리하다.

7. 포트폴리오는 뭘 해야 하나요?

개인적으로 이런 포트폴리오는 별로다.

Studied Linux
Studied OWASP Top 10
Studied AWS
Studied Python

그래서 뭘 했는데?

라는 질문이 바로 나온다.

포폴에서는 공부했다보다 만들었다가 좋다.

예를 들면 이런 식이다.

  • Web Pentest Report
  • Cloud Security Lab
  • Threat Hunting Report
  • Detection Rule
  • Vulnerability Write-up
  • Secure CI/CD Project
  • Android Pentest Write-up

AWS를 공부했다면 간단하게 환경 하나 만들어도 된다.

AWS
 |
 +-- IAM
 |
 +-- EC2
 |
 +-- S3
 |
 +-- CloudTrail

일부러 취약하게 구성한다.

Public S3
Overprivileged IAM Role
Open Security Group

그리고

  1. 어떤 문제가 있는지
  2. 어떻게 발견했는지
  3. 공격받으면 어떤 영향이 있는지
  4. 어떻게 수정했는지

까지 써본다.

그러면

AWS 공부했습니다.

한 줄보다 훨씬 강하다.

블로그도 포트폴리오다

개인적으로 보안 공부하는 사람에게 블로그를 꽤 추천한다.

다만

XSS란 무엇인가?

SQL Injection이란?

같은 글만 쓰면 수많은 글 사이에 묻히기 쉽다.

차라리 이런 식이 재밌다.

“GraphQL API 하나 때문에 다른 회사 데이터가 보였던 이유”

“AWS Key는 없는데 AssumeRole이 찍혔다”

“APK를 뜯어봤더니 OAuth Callback을 아무 앱이나 받을 수 있었다”

기술 설명에 내가 어떤 생각으로 접근했는지가 들어가는 게 좋다.

면접관 입장에서도 이 사람이 뭘 외웠는지가 아니라

어떻게 생각하는 사람인지

볼 수 있기 때문이다.

8. 자격증은 있어야 하나요?

있으면 좋다.

없다고 보안 못 하는 건 아니다.

자격증은 자격증이다.

Knowledge
Experience
Portfolio
Certification

이 네 개는 서로 완전히 같은 게 아니다.

그래도 신입 입장에서는 이력서 필터링이나 기본 지식 증명에 도움이 되는 경우가 있으니 본인이 원하는 직무에 맞춰 준비하면 된다.

다만

자격증 따면 보안 전문가 되는 거죠?

는 아니다.

운전면허 있다고 F1 선수 되는 건 아닌 것과 비슷하다.

9. GitHub는 어떻게 꾸미나요?

Exploit 코드만 잔뜩 올릴 필요 없다.

오히려 구조적으로 정리된 프로젝트가 보기 좋다.

security-labs/
├── web/
├── cloud/
├── mobile/
├── detections/
├── incident-response/
└── writeups/

README에는 이런 걸 적는다.

Goal
Environment
Threat Model
Testing Process
Findings
Mitigation
Lessons Learned

개인적으로 마지막 Lessons Learned가 꽤 중요하다고 생각한다.

“성공했다”보다

뭐가 예상과 달랐고, 뭘 새로 배웠는가

가 더 흥미롭다.

10. 실제 사이트에서 연습하면 안 돼요?

안 된다.

정말 안 된다.

화이트해킹 배운 지 얼마 안 된 사람들이 가끔 본인 학교 홈페이지나 이상한 사이트 열어놓고

SQLi 되나 한번 해볼까?

하는 경우가 있다.

허가 없는 보안 테스트는 실제 법적인 문제로 이어질 수 있다.

실습은 허용된 환경에서 한다.

PortSwigger Web Security Academy
Hack The Box
TryHackMe
CTF
Local Lab
Bug Bounty Program

Bug Bounty도 아무거나 테스트해도 된다는 뜻이 아니다.

Scope부터 읽어라.

보안에서 Scope 안 읽는 습관은 정말 안 좋다.

실무 가서도 사고 친다.

11. 막상 취업하면 어떤 일을 하나요?

보안 직무에 환상이 약간 있을 수 있다.

0-day
APT
Exploit Development
Reverse Engineering

이런 것만 매일 할 것 같지만 현실은...

Why did this alert fire?

Who owns this server?

Is this IP expected?

Can we close this ticket?

Why does this IAM role have admin?

Can the dev team reproduce this?

When can this patch be deployed?

이런 질문을 훨씬 자주 한다.

보안은 생각보다 굉장히 운영적인 직무다.

그리고 사람하고 대화도 많이 해야 한다.

개발팀.

인프라팀.

법무팀.

경영진.

고객.

생각보다

“나는 컴퓨터랑만 이야기하고 싶어요.”

가 잘 안 된다.

미안하다.

12. 경력이 쌓일수록 달라지는 것

처음에는 보통 이렇게 생각한다.

이거 뚫을 수 있나?

조금 지나면

이거 뚫으면 어디까지 갈 수 있지?

를 본다.

더 지나면

아니 근데 왜 이런 구조가 만들어졌지?

를 생각한다.

Find Vulnerability
       |
       v
Understand Impact
       |
       v
Understand Root Cause
       |
       v
Fix Architecture

개인적으로 이 변화가 꽤 중요하다고 생각한다.

Senior가 될수록 취약점 하나를 찾는 것보다 왜 이런 문제가 계속 생기는지를 보는 시간이 많아진다.

그리고 취약점 고친다고 if문 한 줄 추가한 개발자를 보며

아... 이거 아닌데...

라고 혼자 중얼거리게 된다.

13. 그러면 첫 6개월은 어떻게 공부할까?

사람마다 다르겠지만 아예 아무것도 모르는 상태라면 나는 이렇게 추천한다.

1~2개월

Linux
Networking
HTTP
Python
Git

이 시기에는 hacking을 잘하려고 하지 않아도 된다.

컴퓨터가 어떻게 돌아가는지 이해한다.

3~4개월

화이트해킹에 관심 있다면

Burp Suite
Web Security
Authentication
Authorization
API Security
OWASP

이런 걸 공부한다.

PortSwigger Web Security Academy도 정말 좋다.

무료다.

공짜인데 상당히 잘 되어 있다.

쓰자.

5개월

슬슬 내가 어떤 분야를 좋아하는지 골라본다.

Pentesting
AppSec
Cloud Security
Blue Team
DFIR

아직 못 골라도 괜찮다.

해봐야 안다.

6개월

작은 프로젝트 하나를 끝까지 해본다.

이게 중요하다.

Build Lab
    |
    v
Test
    |
    v
Analyze
    |
    v
Write Report
    |
    v
Publish

프로젝트 10개 시작해서 전부 README에

Coming Soon

이라고 써있는 것보다,

작은 거 하나라도 끝까지 완성해놓는 게 훨씬 낫다.

마지막으로

처음 보안 공부를 시작하면 주변 사람들이 전부 괴물처럼 보인다.

누군가는 CTF 문제를 몇 분 만에 풀고,

누군가는 CVE가 있고,

누군가는 Malware를 Reverse Engineering하고,

누군가는 AWS를 잘하고,

누군가는 AD를 다 털고 다닌다.

그러면 갑자기 조급해진다.

나도 다 해야 하나?

아니다.

진짜 아니다.

보안은 분야가 너무 넓다.

한 사람이 전부 다 잘하기는 어렵다.

나도 모르는 거 엄청 많다.

결국 하나씩 하면 된다.

그리고 내가 개인적으로 신입이나 처음 보안을 공부하는 사람에게 가장 중요하다고 생각하는 능력은 의외로 모르는 걸 모른다고 인정하고 끝까지 파보는 능력이다.

새로운 기술이 나오면

I don't know this.
      |
      v
How does it work?
      |
      v
What does it trust?
      |
      v
What happens if that trust fails?

이 순서로 따라가면 된다.

보안은 결국 이것의 반복에 가깝다.

도구를 많이 외우는 사람이 무조건 잘하는 것도 아니고,

Kali Linux 터미널이 화려하다고 잘하는 것도 아니다.

시스템이 어떻게 돌아가는지 궁금해하고,

남들이

“원래 이렇게 쓰는 건데요?”

라고 할 때

“근데 꼭 이렇게만 써야 하나?”

라고 한 번 더 생각하는 사람.

개인적으로는 그런 사람이 이 분야에서 꽤 오래 살아남는다고 생각한다.

뭐, 적어도 나는 그랬다.

끝까지 읽었네… 메밀 승인 🐾
＋