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 취약점을 살펴보며 보안의 중요성을 깨달았습니다.
오늘은 이러한 보안 취약점을 자동으로 찾아주는 세 가지 강력한 도구, SAST, DAST, SCA를 만나보고, SonarQube, OWASP ZAP, Snyk과 같은 실전 도구들이 어떻게 품질 아키텍트의 강력한 무기가 되는지 이야기해 보겠습니다.
눈에 보이지 않는 위험을 찾아내는 세 가지 검진 방법
소프트웨어의 보안 취약점은 마치 우리 몸의 숨은 질병과 같습니다.
겉으로는 멀쩡해 보여도 언제 터질지 모르는 시한폭탄처럼 존재할 수 있죠.
이러한 숨은 위험을 찾아내기 위해 우리는 세 가지 다른 방식으로 코드를 스캔합니다.
각각의 방식은 마치 건강검진의 X-ray, MRI, 그리고 혈액 검사처럼 다른 관점에서 문제를 발견합니다.
1. SAST (Static Application Security Testing): 코드를 읽는 의사, 정적 분석
SAST는 정적 애플리케이션 보안 테스트(Static Application Security Testing)의 약자로, 소프트웨어를 실행하지 않은 상태에서 소스 코드나 컴파일된 바이너리 코드를 분석하여 보안 취약점을 찾아내는 방법입니다 .
마치 의사가 환자의 진료 기록이나 X-ray 사진만 보고도 질병을 진단하는 것과 같습니다.
코드를 한 줄 한 줄 읽어가며 잠재적인 보안 약점, 코딩 표준 위반, 버그 등을 미리 발견합니다.
SonarQube는 SAST 도구의 대표적인 예시입니다.
이 도구는 코드의 품질과 보안을 지속적으로 분석하여 버그, 취약점, 코드 스멜(Code Smell, 잠재적인 문제점) 등을 찾아내고, 개발자에게 개선할 부분을 알려줍니다.
마치 코드의 건강검진 리포트를 제공하여 개발자가 코드를 더 건강하게 만들 수 있도록 돕는 역할을 합니다.
개발 초기 단계부터 문제를 발견할 수 있어, 나중에 문제를 고치는 데 드는 시간과 비용을 크게 줄일 수 있다는 장점이 있습니다.
2. DAST (Dynamic Application Security Testing): 실제 작동을 지켜보는 탐정, 동적 분석
DAST는 동적 애플리케이션 보안 테스트(Dynamic Application Security Testing)의 약자로, 소프트웨어를 실제로 실행한 상태에서 외부에서 공격을 시도하는 방식으로 보안 취약점을 찾아내는 방법입니다 .
마치 탐정이 건물에 직접 침투하여 문이 제대로 잠겨있는지, 창문이 허술한지 등을 직접 확인하는 것과 같습니다.
SAST가 설계도를 보고 문제를 찾는다면, DAST는 실제로 건물을 사용해보면서 문제를 찾는 방식입니다.
OWASP ZAP (Zed Attack Proxy)은 DAST 도구의 대표적인 예시입니다.
이 도구는 웹 애플리케이션에 다양한 공격 시나리오를 적용하여 SQL Injection, XSS(크로스 사이트 스크립팅) 등 실제 공격에 사용될 수 있는 취약점을 찾아냅니다.
마치 모의 해킹을 통해 시스템의 방어력을 시험하는 것과 같습니다.
DAST는 실제 운영 환경과 유사한 조건에서 테스트를 수행하므로, SAST로는 발견하기 어려운 런타임(실행 중) 취약점을 찾아내는 데 효과적입니다.
3. SCA (Software Composition Analysis): 식재료의 유통기한을 확인하는 전문가, 오픈소스 분석
SCA는 소프트웨어 구성 분석(Software Composition Analysis)의 약자로, 소프트웨어에 사용된 오픈소스 라이브러리나 외부 구성 요소에 알려진 보안 취약점이 있는지 확인하는 방법입니다 .
요즘 소프트웨어는 수많은 오픈소스 라이브러리를 가져다 쓰는 경우가 많습니다.
SCA는 마치 요리사가 식재료의 원산지, 유통기한, 알레르기 유발 성분 등을 꼼꼼히 확인하는 것과 같습니다.
아무리 내가 만든 코드가 완벽해도, 가져다 쓴 라이브러리에 문제가 있다면 전체 시스템이 위험해질 수 있기 때문입니다.
Snyk은 SCA 도구의 대표적인 예시입니다.
이 도구는 프로젝트에 사용된 오픈소스 라이브러리 목록을 분석하여, 알려진 보안 취약점 데이터베이스와 비교하여 문제가 있는 라이브러리를 찾아내고, 해결책까지 제시해 줍니다.
마치 식재료 전문가가 유통기한이 지났거나 위험한 성분이 포함된 식재료를 찾아내어 알려주는 것과 같습니다.
SCA는 개발자가 미처 인지하지 못하는 외부 의존성으로 인한 보안 위험을 관리하는 데 필수적인 도구입니다.
품질 아키텍트의 새로운 역할: 보안 검진의 지휘자
AI가 코드를 짜고 테스트를 자동화하는 시대에, 품질 아키텍트의 역할은 이러한 다양한 보안 스캔 도구들을 적재적소에 활용하여 소프트웨어 개발 생명주기(SDLC) 전반에 걸쳐 보안을 강화하는 보안 검진의 지휘자가 되는 것입니다.
우리는 단순히 도구를 사용하는 것을 넘어, 각 도구의 특성과 장단점을 이해하고, 어떤 단계에서 어떤 도구를 적용해야 가장 효과적인지 전략을 수립해야 합니다.
•개발 초기 단계 (SAST): 코드를 작성하는 단계에서부터 SonarQube와 같은 SAST 도구를 활용하여 기본적인 코딩 표준과 잠재적인 취약점을 미리 걸러냅니다. 이는 마치 질병이 발생하기 전에 예방 접종을 하거나 건강한 생활 습관을 들이는 것과 같습니다.
•테스트 및 배포 단계 (DAST): 소프트웨어가 실행 가능한 형태로 만들어진 후에는 OWASP ZAP과 같은 DAST 도구를 활용하여 실제 공격 시나리오를 통해 시스템의 방어력을 시험합니다. 이는 마치 실제 질병이 발생했을 때 정밀 검사를 통해 정확한 진단을 내리는 것과 같습니다.
•지속적인 관리 (SCA): Snyk과 같은 SCA 도구를 통해 사용 중인 오픈소스 라이브러리의 보안 취약점을 지속적으로 모니터링하고 업데이트합니다. 이는 마치 복용한 약의 부작용을 꾸준히 확인하고, 유통기한이 지난 약은 교체하는 것과 같습니다.
이러한 도구들을 CI/CD 파이프라인에 통합하여 자동화하면, 개발팀은 매번 수동으로 보안 검사를 할 필요 없이, 코드가 변경될 때마다 자동으로 보안 검진을 받을 수 있게 됩니다.
품질 아키텍트로서 우리는 이러한 자동화된 보안 검진 시스템을 구축하고 관리하며, 도구들이 찾아낸 취약점들을 분석하고 우선순위를 정하여 개발팀이 효과적으로 개선할 수 있도록 돕는 역할을 수행해야 합니다.
더 안전한 소프트웨어를 향한 여정
SAST, DAST, SCA와 같은 코드 스캔 도구들은 더 이상 선택 사항이 아닌 필수적인 요소가 되었습니다.
이 도구들을 효과적으로 활용함으로써 우리는 소프트웨어의 숨겨진 병을 조기에 발견하고 치료하여, 사용자들에게 더 안전하고 신뢰할 수 있는 서비스를 제공할 수 있습니다.
보안은 단 한 번의 검사로 끝나는 것이 아니라, 소프트웨어의 생명주기 내내 지속적으로 관리해야 하는 과정입니다.
품질 아키텍트로서 우리는 이러한 지속적인 보안 관리의 중요성을 인식하고, 최신 도구와 기술을 활용하여 소프트웨어 보안의 최전선에서 사용자들을 지켜내는 파수꾼이 되어야 할 것입니다.
참고 자료