19화. 관측성을 테스트로 환원하기 — 로그·메트릭·트레이스(OpenTelemetry)를 테스트 사고로 끌어오기.

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화. 테스터에서 품질 아키텍트로 

 

---

시스템의 속마음을 듣는 기술: 관측성을 테스트로 환원하기

겉으로 보이는 동작만으로 소프트웨어의 건강을 판단하는 시대는 지났습니다.

 

이제는 시스템 내부의 미세한 신호까지 읽어내어 테스트의 깊이를 더하는 관측성(Observability)의 세계로 들어가 봅니다.

 

마치 자동차 정비소의 진단기나 우리 몸의 엑스레이처럼, 보이지 않는 곳의 문제까지 파악하는 테스터의 새로운 시야를 탐험합니다.

 

겉모습만으로는 알 수 없는 시스템의 속마음

지난 연재에서 우리는 플래키 테스트라는 변덕스러운 친구를 어떻게 길들일지 이야기했습니다.

 

테스트 결과가 성공과 실패를 오가는 상황에서, 단순히 '실패했다'는 사실만으로는 문제의 근본 원인을 파악하기 어렵다는 것을 깨달았죠.

 

마치 겉으로는 멀쩡해 보이는 사람이 갑자기 쓰러졌을 때, 단순히 '쓰러졌다'는 사실만으로는 왜 쓰러졌는지 알 수 없는 것과 같습니다.

 

이때 필요한 것이 바로 시스템의 '속마음'을 들여다보는 능력, 즉 관측성입니다.

 

관측성은 시스템이 현재 어떤 상태인지, 왜 그렇게 작동하는지, 그리고 어떤 문제가 발생했는지를 외부에서 수집 가능한 데이터(로그, 메트릭, 트레이스)를 통해 파악할 수 있는 능력을 의미합니다 [1].

 

이는 단순히 시스템이 작동하는지 안 하는지를 보는 '모니터링'과는 다릅니다.

 

모니터링이 '불이 켜져 있는가?'를 묻는 것이라면, 관측성은 '왜 불이 켜져 있는가? 불이 켜지기까지 어떤 과정이 있었는가?'를 묻는 것에 가깝습니다.

 

마치 자동차 정비소에서 단순히 시동이 걸리는지 확인하는 것을 넘어, 진단기를 연결해 엔진의 미세한 떨림, 연료 분사량, 배기가스 농도 등 모든 데이터를 분석하여 문제의 원인을 정확히 찾아내는 것과 같습니다.

 

시스템의 세 가지 목소리: 로그, 메트릭, 트레이스

관측성을 구성하는 핵심 요소는 크게 세 가지입니다. 이 세 가지는 시스템이 우리에게 보내는 각기 다른 목소리라고 할 수 있습니다.

1. 로그 (Logs): 시스템의 일기장

로그는 시스템이 작동하면서 기록하는 일기장과 같습니다.

 

어떤 사용자가 언제 로그인했는지, 어떤 기능이 실행되었는지, 어떤 오류가 발생했는지 등 시스템 내부에서 일어나는 모든 사건을 시간 순서대로 기록합니다.

 

마치 비행기의 블랙박스처럼, 문제가 발생했을 때 로그를 분석하면 어떤 일이 벌어졌는지 상세하게 추적할 수 있습니다.

 

테스트 관점에서는 특정 테스트가 실패했을 때, 해당 테스트가 실행되는 동안 시스템이 어떤 로그를 남겼는지 확인하여 실패 원인을 파악하는 데 결정적인 단서를 얻을 수 있습니다.

 

2. 메트릭 (Metrics): 시스템의 건강 지표

메트릭은 시스템의 건강 상태를 수치로 보여주는 지표입니다.

 

CPU 사용량, 메모리 사용량, 네트워크 트래픽, 초당 처리 요청 수, 응답 시간 등이 여기에 해당합니다.

 

마치 우리 몸의 체온, 혈압, 심박수와 같은 건강 지표와 같습니다.

 

메트릭을 통해 시스템의 성능 변화를 주기적으로 관찰하고, 특정 임계치를 넘어서는 이상 징후가 발생했을 때 빠르게 감지할 수 있습니다.

 

테스트를 실행하는 동안 시스템의 메트릭을 함께 수집하면, 테스트가 시스템에 어떤 부하를 주는지, 성능 저하가 발생하는 지점은 어디인지 등을 객관적인 수치로 확인할 수 있습니다.

 

3. 트레이스 (Traces): 시스템 요청의 여정

트레이스는 하나의 사용자 요청이 시스템 내부의 여러 구성 요소(서버, 데이터베이스, 다른 서비스 등)를 거쳐 처리되는 과정을 추적하는 것입니다.

 

마치 택배가 발송되어 여러 물류 센터를 거쳐 최종 목적지에 도착하기까지의 모든 경로를 기록하는 것과 같습니다.

 

요즘 소프트웨어는 여러 작은 서비스들이 서로 유기적으로 연결되어 작동하는 경우가 많습니다.

 

이때 트레이스는 요청이 어느 서비스에서 얼마나 시간을 보냈는지, 어떤 오류가 발생했는지 등을 한눈에 보여주어, 복잡한 분산 시스템에서 문제의 병목 지점을 찾아내는 데 매우 유용합니다 [2].

 

테스트 관점에서는 특정 기능 테스트가 실패했을 때, 해당 요청의 트레이스를 분석하여 어느 서비스에서 문제가 발생했는지, 그리고 그 원인이 무엇인지 깊이 있게 파고들 수 있습니다.

 

OpenTelemetry: 관측성의 공통 언어

이러한 로그, 메트릭, 트레이스를 효과적으로 수집하고 관리하기 위한 표준화된 기술이 바로 OpenTelemetry입니다.

 

OpenTelemetry는 다양한 프로그래밍 언어와 시스템에서 관측 데이터를 생성, 수집, 내보내는 방법을 정의하는 오픈소스 프로젝트입니다 [3].

 

마치 전 세계 사람들이 각기 다른 언어를 사용하지만, '영어'라는 공통 언어를 통해 소통할 수 있는 것처럼, OpenTelemetry는 다양한 시스템에서 발생하는 관측 데이터를 하나의 통일된 방식으로 다룰 수 있게 해줍니다.

 

이를 통해 테스터는 특정 도구에 얽매이지 않고, 시스템의 속마음을 더 쉽게 이해하고 테스트에 활용할 수 있게 됩니다.

 

테스트 사고에 관측성을 끌어오기: 품질 아키텍트의 새로운 무기

그렇다면 우리는 이 관측성 데이터를 어떻게 테스트 사고로 끌어올 수 있을까요?

 

단순히 테스트가 성공했는지 실패했는지 확인하는 것을 넘어, 테스트 실행 중에 수집된 로그, 메트릭, 트레이스 데이터를 분석하여 테스트의 품질을 한 단계 더 높일 수 있습니다.

 

예를 들어, 웹 페이지의 로그인 기능 테스트를 한다고 가정해 봅시다.

 

기존에는 로그인 버튼을 눌렀을 때 성공적으로 로그인 페이지로 이동하는지만 확인했습니다.

 

하지만 관측성을 활용하면 다음과 같은 질문에 답할 수 있습니다.

• 로그인 요청 시 서버에서 어떤 로그가 남았는가? 혹시 경고나 오류 로그는 없었는가?
• 로그인 처리 과정에서 데이터베이스 쿼리 응답 시간은 얼마나 걸렸는가? (메트릭)
• 로그인 요청이 인증 서버, 사용자 정보 서버 등 여러 마이크로 서비스를 거치면서 어느 단계에서 가장 많은 시간이 소요되었는가? (트레이스)

이러한 질문에 답함으로써 우리는 단순히 기능의 동작 여부를 넘어, 기능이 '어떻게' 동작하는지, '왜' 느려지는지, '어떤' 내부 문제가 발생했는지를 파악할 수 있습니다.

 

이는 테스트의 깊이를 더하고, 잠재적인 성능 문제나 안정성 문제를 사전에 발견하는 데 큰 도움이 됩니다.

 

품질 아키텍트로서 우리는 이러한 관측성 데이터를 테스트 시나리오에 통합하고, 자동화된 테스트 결과와 함께 분석하여 시스템의 전반적인 건강 상태를 진단하는 새로운 무기를 갖게 되는 것입니다.

 

보이지 않는 것을 보는 힘: 더 나은 소프트웨어를 향한 여정

관측성을 테스트 사고로 끌어오는 것은 마치 의사가 환자의 겉모습뿐만 아니라 엑스레이, 혈액 검사 등 다양한 내부 데이터를 종합하여 정확한 진단을 내리는 것과 같습니다.

 

이는 우리가 만드는 소프트웨어가 사용자에게 더 안정적이고 빠르게 작동하도록 보장하는 핵심적인 방법입니다.

 

AI가 테스트를 자동화하는 시대에, 인간 테스터는 이러한 '보이지 않는 것을 보는 힘'을 길러 시스템의 복잡성을 이해하고, 더 높은 차원의 품질을 설계하는 품질 아키텍트로 진화해야 합니다.

 

관측성은 그 여정에서 가장 강력한 동반자가 될 것입니다.

---

참고 자료

[1] Red Hat. "관측성이란?" https://www.redhat.com/ko/topics/devops/what-is-observability
[2] SKBY. "관측가능성 (Observability)." https://blog.skby.net/%EA%B4%80%EC%B8%A1%EA%B0%80%EB%8A%A5%EC%84%B1-observability/
[3] Microsoft. "OpenTelemetry in Application Insights." https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-enable