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화. 테스터에서 품질 아키텍트로
공통 언어로서의 BDD: 기획·개발·QA를 한 문장에 모으는 마법
소프트웨어 개발 과정에서 기획자, 개발자, 테스터는 각자의 전문 분야와 시각을 가지고 있습니다.
기획자는 사용자의 요구사항과 비즈니스 가치를, 개발자는 기술적인 구현 방법을, 테스터는 잠재적인 문제점과 품질을 중점적으로 생각하죠.
이처럼 서로 다른 관점과 언어를 사용하다 보면 종종 오해가 생기거나, 중요한 부분이 누락되어 결국 제품의 품질 저하로 이어지곤 합니다.
마치 오케스트라의 지휘자, 연주자, 악기 조율사가 각자 다른 악보를 보고 연주하는 것과 같습니다.
오늘은 이러한 소통의 장벽을 허물고, 모두가 이해할 수 있는 공통 언어를 통해 협업의 효율을 극대화하는 방법, 바로 BDD(행동 주도 개발, Behavior-Driven Development)와 그 핵심 도구인 Gherkin에 대해 이야기해 보겠습니다.
BDD: 오해를 줄이고 협업을 이끄는 통번역기
BDD(Behavior-Driven Development)는 소프트웨어의 행동(Behavior)에 초점을 맞춰 개발하는 방법론입니다.
이는 단순히 기능이 "어떻게 작동하는가"를 넘어, "사용자가 어떤 행동을 했을 때 시스템이 어떻게 반응해야 하는가"를 명확하게 정의하는 데 중점을 둡니다 .
BDD는 마치 기획자, 개발자, 테스터 사이의 통번역기와 같습니다.
각자의 언어를 BDD라는 공통 언어로 번역하여, 모두가 동일한 목표와 기대를 가지고 소프트웨어를 만들어나가도록 돕습니다.
기존의 개발 방식에서는 기획서가 개발팀에 전달되면, 개발자는 이를 코드로 구현하고, 테스터는 다시 이 코드를 기반으로 테스트 케이스를 작성하는 과정에서 정보의 왜곡이나 누락이 발생하기 쉬웠습니다.
하지만 BDD는 기획, 개발, 테스트 팀이 함께 모여 사용자의 행동 시나리오를 정의하고, 이를 기반으로 코드를 개발하며, 동시에 테스트 케이스로 활용합니다.
이 과정에서 자연스럽게 모든 팀원이 소프트웨어의 목표와 동작 방식에 대한 동일한 이해를 갖게 됩니다.
Gherkin: 모두가 함께 연주하는 악보, 혹은 요리 레시피
BDD의 핵심은 사용자의 행동 시나리오를 누구나 이해할 수 있는 자연어 형태로 작성하는 것입니다.
이때 사용되는 특정 문법이 바로 Gherkin(거킨)입니다 . Gherkin은 Given-When-Then이라는 간단한 구조를 사용하여 시나리오를 서술합니다.
이는 마치 오케스트라의 모든 연주자가 동일한 악보를 보고 연주하거나, 요리사가 레시피를 보고 요리하는 것과 같습니다.
악보나 레시피처럼 명확하고 구체적인 지침을 제공하여, 각자의 역할을 수행하면서도 전체적인 조화를 이룰 수 있도록 돕습니다.
Gherkin 문법은 다음과 같은 키워드를 사용합니다:
•Feature (기능): 개발하려는 기능의 큰 그림을 설명합니다. (예: Feature: 사용자 로그인)
•Scenario (시나리오): 특정 상황에서 사용자의 행동과 시스템의 반응을 설명합니다. (예: Scenario: 유효한 자격 증명으로 로그인 성공)
•Given (조건): 시나리오가 시작되기 전의 초기 상태나 전제 조건을 설명합니다. (예: Given 사용자가 로그인 페이지에 접속해 있다)
•When (행동): 사용자가 시스템에 대해 수행하는 특정 행동을 설명합니다. (예: When 사용자가 올바른 아이디와 비밀번호를 입력하고 로그인 버튼을 클릭한다)
•Then (결과): 사용자의 행동에 대한 시스템의 예상되는 결과를 설명합니다. (예: Then 사용자는 메인 페이지로 이동하고 환영 메시지를 본다)
•And, But: Given, When, Then 문장을 이어서 사용할 때 사용합니다.
이러한 Gherkin 문법으로 작성된 시나리오는 다음과 같은 장점을 가집니다:
•명확한 의사소통: 기획자, 개발자, 테스터 모두가 동일한 시나리오를 보고 이해할 수 있어 오해를 줄입니다.
•실행 가능한 명세: Gherkin으로 작성된 시나리오는 자동화된 테스트 코드로 변환될 수 있어, 곧바로 테스트에 활용될 수 있습니다.
•문서화: 시나리오 자체가 소프트웨어의 동작에 대한 훌륭한 문서 역할을 합니다.
Gherkin으로 기획·개발·QA를 한 문장에 모으기
BDD와 Gherkin은 기획, 개발, QA 팀이 마치 한 몸처럼 움직이도록 돕습니다. 예를 들어, 새로운 로그인 기능을 개발한다고 가정해 봅시다.
1.기획자, 개발자, 테스터가 함께 모여 논의합니다.
•기획자는 사용자가 로그인에 성공했을 때 어떤 화면을 보게 될지, 실패했을 때는 어떤 메시지를 받아야 하는지 설명합니다.
•개발자는 기술적으로 어떻게 구현할지, 어떤 제약 사항이 있는지 이야기합니다.
•테스터는 어떤 예외 상황이 발생할 수 있는지, 어떤 방식으로 테스트할지 의견을 제시합니다.
2.이 논의를 바탕으로 Gherkin 시나리오를 작성합니다.
Feature: 사용자 로그인 사용자는 유효한 자격 증명으로 로그인하여 서비스에 접근할 수 있어야 한다. Scenario: 유효한 자격 증명으로 로그인 성공 Given 사용자가 로그인 페이지에 접속해 있다 When 사용자가
올바른 아이디와 비밀번호를 입력하고 로그인 버튼을 클릭한다Then 사용자는 메인 페이지로 이동하고 환영 메시지를 본다And 사용자의 로그인 상태가 유지된다
Scenario: 유효하지 않은 비밀번호로 로그인 실패 Given 사용자가 로그인 페이지에 접속해 있다 When 사용자가 올바른 아이디와 유효하지 않은 비밀번호를 입력하고 로그인 버튼을 클릭한다 Then 시스템은 '비밀번호가 일치하지 않습니다.'라는 오류 메시지를 표시한다 And 사용자는 로그인 페이지에 머무른다 ```
3. 개발자는 이 Gherkin 시나리오를 기반으로 코드를 구현합니다. 시나리오가 명확하기 때문에 개발자는 어떤 기능을 만들어야 할지 정확히 알 수 있습니다.
1.테스터는 이 Gherkin 시나리오를 자동화된 테스트 코드로 변환합니다. Cucumber, SpecFlow, Behave와 같은 BDD 프레임워크를 사용하면 Gherkin 시나리오를 실제 코드로 연결하여 자동으로 테스트를 실행할 수 있습니다. 이렇게 되면 기획서가 곧 테스트 케이스가 되고, 테스트 케이스가 곧 문서가 되는 일석삼조의 효과를 얻을 수 있습니다.
이러한 과정을 통해 기획자, 개발자, 테스터는 서로 다른 문서를 만들고 해석하는 데 시간을 낭비하는 대신, 하나의 공통된 이해를 바탕으로 소프트웨어의 행동을 정의하고 검증하는 데 집중할 수 있습니다. 이는 마치 오케스트라의 모든 구성원이 동일한 악보를 보며 각자의 악기를 연주하여 아름다운 하모니를 만들어내는 것과 같습니다.
품질 아키텍트의 전략적 역할: 소통의 다리를 놓다
AI가 코드를 짜고 테스트를 자동화하는 시대에, 품질 아키텍트의 역할은 단순히 테스트 기술을 아는 것을 넘어, 팀 간의 소통을 원활하게 하고 협업의 효율을 높이는 다리 역할을 하는 데까지 확장됩니다.
BDD와 Gherkin은 이러한 역할을 수행하는 데 매우 강력한 도구입니다.
우리는 팀원들이 BDD 사고방식을 이해하고 Gherkin 문법을 효과적으로 활용할 수 있도록 돕고, 시나리오 작성 과정에서 모든 이해관계자의 의견이 반영될 수 있도록 조율해야 합니다.
BDD는 단순히 테스트 자동화 도구가 아닙니다.
이는 팀 전체의 사고방식과 협업 문화를 변화시키는 촉매제입니다.
기획, 개발, QA가 함께 모여 사용자의 행동을 중심으로 논의하고, 이를 Gherkin이라는 공통 언어로 명확하게 정의함으로써, 우리는 오해를 줄이고, 불필요한 재작업을 방지하며, 궁극적으로는 사용자에게 더 높은 품질의 소프트웨어를 더 빠르게 제공할 수 있습니다.
품질 아키텍트로서 우리는 이러한 협업의 가치를 전파하고, 팀이 BDD를 통해 더욱 강력한 시너지를 낼 수 있도록 이끌어야 할 것입니다.
참고 자료