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화. 테스터에서 품질 아키텍트로
테스트 가능성을 설계에 심다: 점검구가 있는 건물처럼, 레고처럼
우리는 지난 연재들을 통해 소프트웨어의 기능이 잘 작동하는지, 성능은 어떤지, 보안에는 문제가 없는지 등 다양한 관점에서 품질을 측정하고 개선하는 방법을 알아보았습니다.
그런데 아무리 훌륭한 테스트 기술과 도구를 가지고 있어도, 정작 테스트하기 어려운 구조로 만들어진 소프트웨어라면 어떨까요?
마치 점검구가 없는 건물에서 배관 문제를 찾아내거나, 접착제로 붙여버린 레고 블록을 분해하려는 것과 같을 것입니다.
오늘은 테스트 가능성(Testability)이라는 개념을 통해, 기획과 설계 단계에서부터 테스트를 염두에 둔 구조를 만드는 것이 왜 중요한지, 그리고 품질 아키텍트로서 우리가 어떤 역할을 해야 하는지 이야기해 보겠습니다.
테스트 가능성: 소프트웨어를 얼마나 쉽게 테스트할 수 있는가
테스트 가능성은 말 그대로 소프트웨어나 그 구성 요소를 얼마나 쉽고 효과적으로 테스트할 수 있는지를 나타내는 척도입니다 .
테스트 가능성이 높다는 것은, 소프트웨어의 내부 동작을 쉽게 관찰하고, 원하는 상태로 제어하며, 테스트 결과를 명확하게 확인할 수 있다는 의미입니다.
이는 마치 잘 설계된 건물에 전기 배선이나 수도관을 점검할 수 있는 점검구가 곳곳에 마련되어 있어, 문제가 생겼을 때 쉽게 원인을 파악하고 수리할 수 있는 것과 같습니다.
반대로 테스트 가능성이 낮으면, 작은 기능을 테스트하는 데도 많은 시간과 노력이 들고, 버그를 찾아내기도 어려워집니다.
이는 마치 복잡한 기계의 부품 하나를 교체하기 위해 전체를 다 분해해야 하는 상황과 비슷합니다.
결국 테스트 비용이 증가하고, 출시 일정이 지연되며, 소프트웨어의 전반적인 품질 저하로 이어질 수 있습니다.
기획·개발 단계에서 테스트 가능성을 끌어올리는 이유
테스트는 소프트웨어 개발 생명주기(SDLC)의 후반부에 이루어지는 활동이라고 생각하기 쉽습니다. 하지만 테스트 가능성은 개발 초기 단계, 즉 기획과 설계 단계에서부터 고려되어야 합니다. 왜냐하면 소프트웨어의 구조와 아키텍처가 결정되는 시점이기 때문입니다. 마치 건물의 설계 단계에서부터 점검구의 위치나 배관의 경로를 정해야 나중에 유지보수가 쉬워지듯이, 소프트웨어도 초기 설계가 테스트 용이성에 큰 영향을 미칩니다.
1. 문제의 조기 발견과 비용 절감
테스트 가능성을 고려한 설계는 잠재적인 문제를 개발 초기 단계에서 발견할 수 있도록 돕습니다.
예를 들어, 특정 모듈이 너무 복잡하게 얽혀 있어 테스트하기 어렵다는 것을 설계 단계에서 파악하면, 이를 더 작고 독립적인 단위로 분리하여 설계할 수 있습니다.
이렇게 하면 나중에 코드를 다 작성한 후에 문제를 발견하여 수정하는 것보다 훨씬 적은 비용과 노력으로 해결할 수 있습니다.
마치 레고 블록을 조립하기 전에 어떤 블록이 서로 잘 맞고 분리하기 쉬운지 미리 확인하는 것과 같습니다.
2. 테스트 자동화의 용이성
테스트 가능성이 높은 소프트웨어는 테스트 자동화에도 유리합니다.
각 기능이 독립적으로 작동하고, 외부와의 의존성이 명확하게 분리되어 있다면, 자동화된 테스트 코드를 작성하기가 훨씬 수월해집니다.
이는 마치 각 부품이 명확하게 분리되는 레고 블록으로 만든 장난감이, 원하는 부분만 떼어내어 다른 부품으로 교체하거나 테스트하기 쉬운 것과 같습니다.
자동화된 테스트는 빠른 피드백을 제공하고, 회귀 테스트(Regression Test) 비용을 절감하여 개발 속도를 높이는 데 기여합니다.
3. 유지보수 및 확장성의 향상
테스트하기 쉬운 코드는 일반적으로 유지보수 및 확장성도 뛰어납니다.
테스트 가능성을 높이기 위해 코드를 모듈화하고, 각 모듈의 역할을 명확히 하며, 의존성을 줄이는 과정은 자연스럽게 코드의 가독성과 재사용성을 높이기 때문입니다.
이는 마치 잘 정리된 도구 상자에서 필요한 도구를 쉽게 찾아 사용할 수 있고, 새로운 도구를 추가하기도 쉬운 것과 같습니다.
테스트 가능성을 설계에 심는 구체적인 방법
그렇다면 기획과 설계 단계에서 테스트 가능성을 높이기 위해 구체적으로 어떤 노력을 해야 할까요?
1. 모듈화 및 낮은 결합도 유지
소프트웨어를 작고 독립적인 모듈로 나누고, 각 모듈 간의 의존성을 최소화해야 합니다.
마치 레고 블록처럼, 각 블록이 독립적인 기능을 수행하고 다른 블록에 미치는 영향이 적을수록 테스트하기 쉽습니다.
특정 모듈을 테스트할 때 다른 모듈의 영향을 받지 않도록 설계하는 것이 중요합니다.
2. 명확한 인터페이스 제공
각 모듈이나 컴포넌트가 외부와 상호작용하는 방식을 명확하게 정의하는 인터페이스를 제공해야 합니다.
이는 마치 건물의 각 방에 어떤 기능이 있고, 어떻게 사용해야 하는지 명확한 안내판이 붙어있는 것과 같습니다.
명확한 인터페이스는 테스트 코드가 해당 모듈을 쉽게 호출하고, 입력값을 전달하며, 출력값을 확인할 수 있도록 돕습니다.
3. 관찰 가능성(Observability) 확보
소프트웨어의 내부 상태를 쉽게 관찰할 수 있도록 로그, 메트릭, 트레이스 등의 정보를 충분히 제공해야 합니다.
지난 연재에서 다루었던 관측성(Observability)과 일맥상통하는 부분입니다.
마치 건물 곳곳에 설치된 센서와 모니터링 시스템이 건물의 상태를 실시간으로 보여주듯이, 소프트웨어도 내부 동작을 투명하게 보여줄 수 있어야 테스트 중 발생하는 문제를 정확하게 파악할 수 있습니다.
4. 제어 가능성(Controllability) 확보
테스트를 위해 소프트웨어의 특정 상태를 쉽게 설정하고 제어할 수 있어야 합니다.
예를 들어, 특정 시나리오를 테스트하기 위해 데이터베이스의 초기 상태를 쉽게 만들거나, 외부 시스템과의 연동을 모의(Mock)할 수 있는 기능을 제공하는 것입니다.
이는 마치 레고 블록을 조립하기 전에 원하는 색상과 모양의 블록을 미리 준비해두는 것과 같습니다.
5. 테스트 데이터 관리 용이성
테스트에 필요한 데이터를 쉽게 생성하고 관리할 수 있는 방법을 설계 단계에서부터 고려해야 합니다.
지난 연재에서 다루었던 테스트 데이터 합성 및 마스킹 기술도 여기에 해당합니다.
마치 요리사가 요리하기 전에 필요한 재료를 미리 손질해두는 것과 같아서, 테스트 데이터 준비에 드는 시간을 줄이고 테스트의 효율성을 높일 수 있습니다.
품질 아키텍트의 전략적 역할: 테스트 가능성을 설계하다
AI가 코드를 짜고 테스트를 자동화하는 시대에, 품질 아키텍트의 역할은 단순히 테스트를 실행하는 것을 넘어, 테스트하기 쉬운 소프트웨어를 설계하는 데 적극적으로 참여하는 것입니다.
우리는 기획자, 개발자와 함께 초기 단계부터 테스트 가능성을 논의하고, 설계에 반영될 수 있도록 가이드해야 합니다.
이는 마치 건물을 짓기 전부터 건축가와 함께 점검구의 위치와 배관 경로를 논의하고, 유지보수가 용이한 설계를 이끌어내는 것과 같습니다.
테스트 가능성을 설계에 심는 것은 단기적으로는 추가적인 노력처럼 보일 수 있습니다.
하지만 장기적으로는 소프트웨어의 품질을 향상시키고, 개발 비용을 절감하며, 시장 출시 시간을 단축하는 데 결정적인 역할을 합니다.
품질 아키텍트로서 우리는 이러한 전략적 사고를 바탕으로, 소프트웨어의 모든 단계에서 품질이 내재화될 수 있도록 이끌어야 합니다.
테스트 가능성을 높이는 것은 단순히 테스트 팀만의 책임이 아니라, 소프트웨어 개발에 참여하는 모든 이해관계자가 함께 고민하고 실천해야 할 중요한 가치입니다.
참고 자료