23화. 공격자처럼 생각하기 — OWASP Top 10으로 본 보안 기본기.

AI 시대의 품질 아키텍트 : 테스터에서 시스템 품질 설계자로

Part 0. 오리엔테이션
0화. 30분 데모와 프로덕션 사이의 거리 — 현실 인식과 방향 제시

Part 1. 기초 체력
AI가 짠 코드를 읽고 검증할 수 있는 눈과 웹·API 원리 다지기
1화. AI가 짠 코드를 읽는 눈 — Python 또는 JS/TS 중 하나를 코드 리뷰 가능한 수준까지. 실습: AI가 생성한 테스트 코드의 버그 3개 찾기.
2화. 변경은 diff에서 시작된다 — Git과 PR 기반 협업, 변경 기반 테스트의 첫 단추. 실습: PR diff만 보고 영향 범위 추정해 보기.
3화. 웹은 어떻게 움직이는가 — HTTP, 쿠키·세션의 원리. 실습: 개발자도구로 요청·응답 해부.
4화. 인증의 지도 — OAuth·JWT·RBAC를 테스터 시선으로. 실습: 토큰 만료·권한 우회 시나리오 설계.
5화. API의 두 얼굴 — REST와 GraphQL의 차이와 테스트 관점. 실습: 같은 기능을 두 방식으로 호출·검증.

Part 2. 테스트 자동화
Playwright를 주력으로 깊이 익히기
6화. 왜 Playwright인가 — 도구 선택의 근거와 첫 테스트 작성.
7화. 플래키의 근원, 셀렉터와 대기 — 안정적 셀렉터와 비동기 대기 전략.
8화. 실패를 영상으로 읽는다 — Trace Viewer로 원인 추적.
9화. 계약을 테스트하라 — API·계약 테스트(OpenAPI/GraphQL schema 기반).
10화. 눈에 보이는 회귀, 모두에게 열린 화면 — 시각적 회귀와 접근성 자동 검사. (Selenium·Appium은 레거시·모바일 대응용으로 짧게 짚기)

Part 3. AI 활용·MCP (연재 핵심)
AI를 단순 도구가 아닌 차별화 무기로 만드는 구간
11화. 프롬프트로 테스트를 설계하기 — 명세·PR을 입력해 케이스를 생성·우선순위화하는 패턴 정립.
12화. 에이전트는 무엇을 대신하는가 — 에이전트형 테스트의 개념과 한계(수동 노력 최대 45% 절감 추정).
13화. 스스로 고치는 테스트, 그리고 그 한계 — 자가 치유와 AI Healer. 셀렉터·DOM 변경에서 75%+ 복구, 그러나 복잡한 로직 버그는 사람 몫.
14화. npx playwright init-agents — 첫 MCP 실습 — 접근성 트리 기반 Playwright MCP 시작하기.
15화. MCP로 통합을 검증하다 — MCP 기반 통합 검증 실습.
16화. 환각을 거르는 사람 — AI 결과의 환각·오탐을 걸러내는 인간 검증 체계 설계. 직무 특성상 가장 큰 강점이 되는 지점.

Part 4. 파이프라인·운영
개인기를 조직의 신뢰 시스템으로 연결
17화. 문 앞의 품질 게이트 — CI/CD 품질 게이트 구성.
18화. 플래키를 격리하라 — 불안정 테스트 격리와 실패 원인 자동 분류.
19화. 관측성을 테스트로 환원하기 — 로그·메트릭·트레이스(OpenTelemetry)를 테스트 사고로 끌어오기.
20화. 진짜 같은 가짜 데이터 — 테스트 데이터 합성과 마스킹.

Part 5. 비기능 영역
눈에 보이지 않는 품질 지키기
21화. 무게를 견디는가 — k6/JMeter로 부하·스트레스 테스트.
22화. 손안의 성능 — 모바일 성능 지표(FPS·시작속도·메모리·배터리).
23화. 공격자처럼 생각하기 — OWASP Top 10으로 본 보안 기본기.
24화. 코드를 스캔하는 도구들 — SAST·DAST·SCA(SonarQube·OWASP ZAP·Snyk) 실전.

Part 6. 전략·리더십·표준
아키텍트로서의 설계·운영·리더십
25화. 테스트 가능성을 설계에 심다 — Testability를 기획·개발 단계로 끌어올리기.
26화. 공통 언어로서의 BDD — Gherkin으로 기획·개발·QA를 한 문장에 모으기.
27화. AI를 지휘하는 운영 모델 — 20명 규모 팀을 위한 AI 오케스트레이션 가이드라인과 코칭.
28화. 표준과 AI를 잇다 — KOLAS 인정 요건·품질 표준을 AI 검증 체계로 연결하는 도메인 전문성.
29화. 데모를 프로덕션으로 옮기는 비용 — 30분 데모와 실전의 거리, 사람의 감독이 끝까지 필요한 이유를 균형 있게 정리.
30화. 테스터에서 품질 아키텍트로 

 

---

 

공격자처럼 생각하기: 우리 집 보안 점검하듯 소프트웨어의 빈틈을 찾다

우리는 모두 안전한 집에서 살고 싶어 합니다.

 

문단속을 철저히 하고, 귀중품은 금고에 보관하죠.

 

소프트웨어도 마찬가지입니다.

 

아무리 기능이 좋고 빨라도 보안에 취약하다면 한순간에 모든 것을 잃을 수 있습니다.

 

오늘은 마치 우리 집의 보안을 점검하듯, 혹은 은행 강도의 시선으로 금고의 빈틈을 찾듯, 공격자의 입장에서 소프트웨어의 약점을 찾아내는 보안 기본기를 배워봅니다.

 

특히 전 세계적으로 가장 많이 알려진 웹 보안 취약점 목록인 OWASP Top 10을 중심으로 이야기할 것입니다.

 

왜 공격자처럼 생각해야 할까?

지난 연재에서 우리는 모바일 앱의 성능 지표들을 통해 사용자 경험을 최적화하는 방법을 알아보았습니다.

 

이제는 눈에 보이지 않는 또 다른 중요한 품질, 바로 보안에 집중할 차례입니다.

 

소프트웨어 보안은 마치 집의 방범 시스템과 같습니다.

 

아무리 집이 넓고 가구가 좋아도 문이 잠겨있지 않거나 창문이 허술하다면 언제든 도둑이 침입할 수 있습니다.

 

소프트웨어도 기능이 아무리 뛰어나도 보안에 구멍이 있다면 해커들의 공격에 무방비로 노출될 수 있습니다.

 

테스터로서 우리는 단순히 소프트웨어가 "잘 작동하는지"를 넘어, "잘못 작동하도록 만들 수는 없는지"를 고민해야 합니다.

 

즉, 공격자의 시선으로 소프트웨어를 바라보고, 어떤 방법으로 시스템을 속이거나 파괴할 수 있을지 상상해보는 것입니다.

 

이는 마치 은행의 보안 책임자가 은행 강도의 입장에서 침입 경로를 예측하고 방어 전략을 세우는 것과 같습니다.

 

이러한 사고방식을 통해 우리는 개발자들이 미처 생각하지 못했던 보안 취약점을 발견하고, 사용자들의 소중한 정보와 서비스를 지켜낼 수 있습니다.

 

 

OWASP Top 10: 해커들이 가장 좋아하는 10가지 약점

OWASP(Open Worldwide Application Security Project)는 소프트웨어 보안을 연구하는 비영리 국제 단체입니다.

 

이 단체는 전 세계의 보안 전문가들이 모여 웹 애플리케이션에서 가장 흔하고 치명적인 보안 취약점 10가지를 선정하여 주기적으로 발표하는데, 이것이 바로 OWASP Top 10입니다 [1].

 

이 목록은 마치 "도둑들이 가장 선호하는 침입 경로 10가지"와 같아서, 이 목록만 잘 알아도 대부분의 기본적인 보안 위협에 대비할 수 있습니다.

 

1. A01:2025 – 깨진 접근 제어 (Broken Access Control)

우리 집의 각 방마다 문이 있는데, 어떤 방은 잠겨있지 않거나, 심지어 옆집 사람이 우리 집 안방 문을 열고 들어올 수 있는 상황입니다.

사용자가 접근할 수 있는 기능이나 데이터에 대한 권한이 제대로 설정되지 않아, 권한이 없는 사용자가 다른 사용자의 정보에 접근하거나 관리자 기능까지 사용할 수 있는 취약점입니다.

 

예를 들어, 일반 사용자가 URL만 바꿔서 다른 사용자의 개인 정보를 보거나, 관리자 페이지에 접근하는 경우입니다.

 

2025년 버전에서는 서버 측 요청 위조(SSRF)와 같은 취약점도 이 범주에 포함되어 더욱 광범위한 접근 제어 문제를 다룹니다.

 

2. A02:2025 – 보안 설정 오류 (Security Misconfiguration)

우리 집 문은 튼튼한데, 잠금장치를 제대로 잠그지 않거나, 창문을 열어두고 외출하는 상황입니다.

서버, 웹 애플리케이션, 데이터베이스 등의 보안 설정이 기본값으로 되어 있거나, 불필요한 기능이 활성화되어 있어 공격에 노출되는 취약점입니다.

 

예를 들어, 기본 관리자 계정의 비밀번호를 변경하지 않거나, 에러 메시지에 시스템 내부 정보가 노출되는 경우입니다.

 

이 항목은 2021년 대비 순위가 상승하여, 소프트웨어의 동작이 설정에 점점 더 의존하게 되면서 중요성이 더욱 커졌습니다.

 

3. A03:2025 – 소프트웨어 공급망 실패 (Software Supply Chain Failures)

우리가 요리할 때 사용하는 식재료나 조리 도구에 문제가 있어서, 아무리 좋은 레시피로 요리해도 결국 음식에 문제가 생기는 상황입니다.

소프트웨어 개발에 사용되는 외부 라이브러리, 프레임워크, 빌드 시스템, 배포 인프라 등 전체 소프트웨어 공급망 내에서 발생하는 취약점입니다.

 

2021년의 '취약하고 오래된 구성 요소'에서 확장된 개념으로, 오픈소스 라이브러리의 취약점뿐만 아니라, 개발 과정 전반에 걸쳐 외부 요소로 인해 발생할 수 있는 모든 보안 문제를 포함합니다.

 

이는 커뮤니티 설문조사에서 가장 큰 우려 사항 중 하나로 꼽혔습니다.

 

4. A04:2025 – 암호화 실패 (Cryptographic Failures)

중요한 편지를 보낼 때 암호화하지 않고 그냥 보내거나, 암호화는 했지만 너무 쉬운 암호를 사용해서 누구나 쉽게 열어볼 수 있는 상황입니다.

민감한 데이터(비밀번호, 신용카드 정보 등)를 저장하거나 전송할 때 제대로 암호화하지 않거나, 약한 암호화 방식을 사용하여 데이터가 유출될 경우 쉽게 해독될 수 있는 취약점입니다.

 

웹사이트 주소에 https 대신 http를 사용하는 경우도 여기에 해당합니다.

 

이 항목은 2021년 대비 순위가 하락했지만 여전히 중요한 보안 위험으로 남아있습니다.

 

5. A05:2025 – 주입 (Injection )

식당에서 주문을 할 때, 메뉴판에 없는 이상한 재료를 몰래 추가해서 요리사를 혼란스럽게 만들거나, 주방을 엉망으로 만드는 상황입니다.

사용자의 입력값을 제대로 검증하지 않아, 공격자가 악성 코드를 주입하여 데이터베이스를 조작하거나 시스템 명령을 실행할 수 있는 취약점입니다.

 

가장 대표적인 것이 SQL Injection으로, 웹사이트 로그인 창에 아이디와 비밀번호 대신 특정 코드를 입력하여 관리자 권한으로 로그인하는 경우가 있습니다.

 

이 항목 역시 2021년 대비 순위가 하락했지만, 여전히 가장 빈번하게 테스트되고 많은 CVE(Common Vulnerabilities and Exposures)가 발생하는 취약점 중 하나입니다.

 

6. A06:2025 – 안전하지 않은 설계 (Insecure Design)

 

집을 지을 때부터 방범창이나 잠금장치에 대한 고려 없이, 그저 예쁘게만 짓는 상황입니다.

보안을 고려하지 않고 설계 단계에서부터 취약점이 내재된 경우입니다.

 

예를 들어, 비밀번호 찾기 기능을 너무 쉽게 만들어서 공격자가 다른 사람의 비밀번호를 쉽게 재설정할 수 있게 하거나, 중요한 기능을 구현할 때 보안 검증 절차를 누락하는 등 근본적인 설계 오류를 말합니다.

 

이 항목은 2021년에 도입되었으며, 위협 모델링과 보안 설계에 대한 산업계의 개선 노력으로 순위가 약간 하락했습니다.

 

7. A07:2025 – 인증 실패 (Authentication Failures)

우리 집 현관 비밀번호가 너무 쉬워서(예: 1234) 누구나 쉽게 추측할 수 있거나, 비밀번호를 여러 번 틀려도 계속 시도할 수 있는 상황입니다.

사용자 식별 및 인증 기능에 문제가 있어, 공격자가 다른 사용자로 위장하거나 계정을 탈취할 수 있는 취약점입니다.

 

약한 비밀번호 정책, 다단계 인증 미적용, 로그인 시도 횟수 제한 없음 등이 여기에 해당합니다.

 

2021년의 '식별 및 인증 실패'에서 이름이 변경되었으며, 인증을 위한 표준화된 프레임워크 사용이 증가하면서 발생 빈도가 줄어드는 긍정적인 효과를 보이고 있습니다.

 

8. A08:2025 – 소프트웨어 또는 데이터 무결성 실패 (Software or Data Integrity Failures)

중요한 계약서의 내용이 중간에 누군가에 의해 몰래 변경되었는데, 아무도 그 사실을 모르는 상황입니다.

소프트웨어 업데이트, 중요한 데이터, CI/CD 파이프라인 등에서 무결성 검증이 제대로 이루어지지 않아, 악의적인 조작이나 변조가 발생해도 감지하기 어려운 취약점입니다.

 

예를 들어, 소프트웨어 업데이트 파일이 변조되었는데도 시스템이 이를 정상적인 파일로 인식하고 설치하는 경우입니다.

 

이 항목은 2021년과 동일하게 8위를 유지하며, 소프트웨어 및 데이터 아티팩트의 무결성을 유지하는 것이 중요함을 강조합니다.

 

 

9. A09:2025 – 보안 로깅 및 경고 실패 (Security Logging & Alerting Failures)

우리 집에 도둑이 들어왔는데, CCTV가 작동하지 않거나 녹화가 안 되어 누가 들어왔는지, 무엇을 훔쳐갔는지 전혀 알 수 없는 상황입니다.

보안 관련 이벤트(로그인 실패, 관리자 접근 등)가 제대로 기록되지 않거나, 기록되더라도 모니터링 시스템이 없어 이상 징후를 감지하지 못하는 취약점입니다.

 

해커가 침입해도 아무도 모르게 오랜 시간 동안 시스템에 머무를 수 있게 됩니다.

 

2021년의 '보안 로깅 및 모니터링 실패'에서 이름이 변경되었으며, 관련 로그 이벤트에 대한 적절한 조치를 유도하는 '경고(Alerting)' 기능의 중요성을 강조합니다.

 

10. A10:2025 – 예외 조건 처리 미흡 (Mishandling of Exceptional Conditions)

운전 중 갑자기 타이어가 펑크 났을 때, 차가 완전히 멈춰 서는 것이 아니라 비상등을 켜고 안전하게 갓길로 이동하는 것과 같은 비상 대처 계획이 없는 상황입니다.

시스템이 예상치 못한 오류나 예외 상황에 직면했을 때, 이를 적절하게 처리하지 못하여 보안 취약점으로 이어지는 경우입니다.

 

예를 들어, 오류 메시지에 민감한 시스템 정보가 노출되거나, 특정 조건에서 시스템이 무한 루프에 빠져 서비스 거부(DoS) 공격에 취약해지는 상황 등이 있습니다.

 

이 항목은 2025년에 새롭게 추가된 카테고리로, 부적절한 오류 처리, 논리적 오류, Fail-open(실패 시 개방) 등 비정상적인 조건에서 발생할 수 있는 문제에 초점을 맞춥니다.

 

품질 아키텍트의 새로운 역할: 보안의 파수꾼

AI가 코드를 짜고 테스트를 자동화하는 시대에, 품질 아키텍트의 역할은 소프트웨어의 기능적 완성도를 넘어 보안의 파수꾼으로 확장됩니다.

 

우리는 단순히 OWASP Top 10 목록을 아는 것을 넘어, 각 취약점이 어떻게 발생하고 어떤 방식으로 공격에 이용될 수 있는지 공격자의 관점에서 이해해야 합니다.

 

그리고 이를 바탕으로 개발 초기 단계부터 보안을 고려한 설계를 유도하고, 테스트 과정에서 잠재적인 보안 취약점을 찾아내며, 자동화된 보안 검사 도구를 CI/CD 파이프라인에 통합하는 역할을 수행해야 합니다.

 

마치 집을 짓기 전부터 건축가와 함께 방범 시스템을 설계하고, 건축 과정 내내 보안 규정을 준수하는지 꼼꼼히 확인하는 것과 같습니다.

 

이러한 보안 테스트는 단순히 체크리스트를 확인하는 것을 넘어, 창의적인 사고와 깊이 있는 이해를 요구합니다.

 

공격자처럼 생각하는 훈련을 통해 우리는 소프트웨어의 숨겨진 약점을 발견하고, 사용자들에게 더 안전하고 신뢰할 수 있는 서비스를 제공하는 데 결정적인 기여를 할 수 있을 것입니다.

 

보안은 더 이상 개발자나 보안 전문가만의 영역이 아닙니다. 품질 아키텍트로서 우리 모두가 함께 지켜나가야 할 중요한 가치입니다.

 

참고 자료

[1] "OWASP Top 10:2025 " https://owasp.org/Top10/2025/0x00_2025-Introduction/