toss2026년 6월 26일

누군가는 토스를 테스트하는 동안, 우리는 테스트하는 법을 만듭니다. (새 탭에서 열림)

토스 QA Platform 팀은 매주 수백 건의 변경이 포함된 앱을 안정적으로 배포하기 위해, 테스트와 품질 관리의 표준화를 추진하고 있습니다. 단순히 테스트 도구를 제공하는 데 그치지 않고, AI와 자체 플랫폼을 활용해 테스트 실행부터 결함 분석, 출시 후 대응까지 효율화하려 합니다. 궁극적으로는 사람이 중요한 판단에 집중하고, 반복적인 검증은 자동화하는 것이 목표입니다. ## 매주 반복되는 릴리즈 검증 - 토스는 매주 새로운 버전을 배포하며, 한 번의 릴리즈마다 평균 300~400건의 코드가 변경됩니다. - 릴리즈 후보가 올라오면 다음 순서로 검증합니다. - **토스닥터(Toss Doctor)**: 로그인부터 탈퇴까지 핵심 기능을 빠르게 확인하는 스모크 테스트 - **PRCheck**: 변경된 코드와 영향 범위, 버그 위험도, 테스트 우선순위 분석 - **토스체커(Toss Checker)**: 기존 기능이 손상되지 않았는지 확인하는 전사적 리그레션 테스트 - 배포 후에는 크래시 지표를 모니터링하고, 문제가 발생하면 핫픽스를 즉시 배포할지 다음 릴리즈에서 해결할지 판단합니다. - 핫픽스는 사용자에게 추가 업데이트를 요구하므로, 단순히 빠른 대응보다 재발 가능성과 해결의 안전성을 함께 고려합니다. ## 토스 전체의 품질을 지원하는 QA - QA Platform 팀의 역할은 특정 제품의 테스트에 국한되지 않습니다. - QA를 처음 시작하는 팀에 테스트 방향을 제시하고, 사내 도구의 품질을 보증하며, 조직 단위의 QA 프로세스 설계를 지원합니다. - 목표는 누구나 쉽게 테스트 케이스를 만들고, 빠르고 정확하게 테스트할 수 있는 환경을 구축하는 것입니다. - 이를 통해 개별 팀이 아닌 토스 전체의 품질 수준을 끌어올리려 합니다. ## 토스 품질의 세 가지 표준 - **매번 신뢰할 수 있는 배포** - 한 번 성공하는 것이 아니라 매주 일정한 품질과 신뢰성을 유지하는 것이 중요합니다. - **결함을 정확히 발견하는 테스트** - 테스트의 양보다 실제 사고로 이어질 가능성이 높은 결함을 놓치지 않는 것이 핵심입니다. - **효율적인 품질 보증** - 반복 작업을 사람의 수작업만으로 처리하지 않고 자동화해, 지속 가능한 방식으로 품질을 유지해야 합니다. - 올해는 여기에 AI를 활용해 자동으로 수행되는 테스트의 범위를 넓히고 있습니다. 다만 모든 판단을 AI에 맡기기보다, 사람은 사람의 판단이 필요한 영역에 집중하도록 역할을 나눕니다. ## 자체 QA 플랫폼 ‘토션’ - 상용 도구는 토스의 빠른 배포 주기와 업무 방식에 맞게 유연하게 바꾸기 어려웠기 때문에 자체 플랫폼 **토션(Tossion)**을 개발했습니다. - 토션은 처음에 TestRail을 대체하는 플랫폼으로 시작했습니다. - 테스트 케이스 작성 - 테스트 실행 - 결과 기록 - 테스트 관련 봇 통합 - 여러 봇은 **토스버틀러(Toss Butler)**라는 하나의 봇으로 통합해 토스의 업무 흐름에 맞췄습니다. - 이후 다음 기능들이 추가됐습니다. - **PRCheck**: PR 변경 사항을 분석하고 테스트가 필요한 영역을 제시 - **tcgen**: PRD, 디자인 문서 등 여러 맥락을 바탕으로 테스트 케이스 초안 자동 생성 - **자동화 테스트 플랫폼**: 매뉴얼 테스트와 자동화 테스트 결과를 한 화면에서 비교 - **Crash Trend 대시보드**: 크래시의 발생 추세와 토스에 적합한 지표를 분석 - **핫픽스 대시보드**: 장애 원인 분류와 재발 방지 대책 관리 ## 도구 제공만으로는 부족했던 이유 - 팀은 테스트 케이스를 쉽게 만들면 사람들이 테스트를 더 적극적으로 수행할 것이라고 예상했습니다. - 하지만 tcgen을 공개한 뒤 기대만큼 사용되지 않았습니다. - 실제 사용자가 원한 것은 테스트 도구가 아니라 다음과 같은 지원이었습니다. - 누군가 테스트를 빠르고 정확하게 대신 수행할 것 - 테스트 결과의 품질까지 책임질 것 - 도구를 제공하는 것은 사용자 입장에서 업무를 줄이는 것이 아니라 새로운 업무를 넘기는 일이 될 수 있었습니다. - 이에 따라 QA Platform 팀은 도구를 제공하는 데서 나아가, 직접 테스트를 처리하고 품질까지 책임지는 방향으로 전략을 바꿨습니다. ## AI와 빠른 방향 전환 - AI는 빠르게 발전하기 때문에 어제 효과적이었던 방식이 오늘에는 낡을 수 있습니다. - QA 도구가 품질 향상을 돕기보다 변화 속도를 늦추지 않도록, 지속적인 검토와 폐기가 필요합니다. - 실제로 API 테스트를 위한 **API Labs**는 방향이 맞지 않다고 판단해 개발 8시간 만에 폐기했습니다. - 토션, 토스닥터, 토스체커, 자체 스킬들도 완성된 제품이 아니라 필요하면 언제든 교체할 수 있는 시스템으로 설계됐습니다. - AI가 도구를 만드는 속도는 높여도 다음 문제를 대신 결정하지는 못합니다. - 무엇을 품질로 정의할 것인가 - 어떤 기준을 끝까지 지킬 것인가 - 어떤 테스트를 사람에게 맡길 것인가 - 따라서 품질 기준을 세우고 도구의 방향을 조정하는 일은 여전히 QA 팀의 핵심 역할입니다. ## 앞으로 이어질 이야기 - 이후 시리즈에서는 다음 주제를 구체적으로 다룰 예정입니다. - 토션이 어떻게 시작됐는지 - 토스닥터가 배포 전 무엇을 검증하는지 - 토스체커가 증가하는 회귀 테스트를 어떻게 자동화하는지 - 지능형 AI 봇이 여러 도구를 어떻게 연결하는지 - 토스 QA Platform 팀은 매주 반복되는 변화 앞에서 “정말 배포해도 괜찮은가”를 확인하며, 테스트를 수행하는 방법 자체를 만들어가고 있습니다. 실용적으로는 테스트 도구를 도입할 때 기능 수보다 사용자의 실제 부담을 줄이는지 먼저 검증해야 합니다. 또한 AI 기반 QA 시스템은 완성품으로 보기보다, 품질 기준과 업무 방식의 변화에 맞춰 빠르게 교체·개선할 수 있도록 설계하는 것이 중요합니다.

release-managementaitest-automationregression-testing+4

aws2026년 6월 17일

AWS DevOps Agent, 프로덕션 배포 전 코드 변경 사항 평가를 위한 릴리스 관리 기능 추가(프리뷰) | Amazon Web Services (새 탭에서 열림)

AWS DevOps Agent에 코드 변경사항을 운영 배포 전에 검토하고 자동으로 테스트하는 릴리스 관리 기능이 프리뷰로 추가되었습니다. 에이전트는 조직의 자연어 기준, 의존성 안전성, 접근 제어, 운영 환경 요구사항을 검토하고 변경사항에 맞는 테스트를 생성·실행합니다. 이를 통해 AI가 생성한 코드 증가로 발생한 리뷰 병목과 운영 환경과 테스트 환경의 차이를 줄이고, 코드 작성부터 배포까지 자동화 수준을 높일 수 있습니다. ## AI 코드 증가로 인한 리뷰와 테스트 병목 - AI 코딩 도구 확산으로 풀 리퀘스트 수가 리뷰·테스트 역량보다 빠르게 증가하고 있습니다. - 일정 압박 때문에 사람이 코드를 충분히 검토하지 못한 채 승인하는 문제가 발생합니다. - 테스트 환경이 운영 환경과 달라 실제 배포 후에야 문제가 발견될 수 있습니다. - AI 모델은 사람이 시간 압박 속에서 놓치기 쉬운 기능 및 보안 문제를 탐지할 수 있어, 빠르면서도 안전한 배포가 중요해졌습니다. ## 릴리스 준비성 검토 - 모든 코드 변경사항을 다음 기준으로 분석합니다. - 운영 환경 요구사항 - 서비스 및 리포지터리 간 의존성 안전성 - 사용자가 정의한 내부 표준과 모범 사례 - AWS Well-Architected Framework에 따른 접근 제어 변경사항 - 여러 리포지터리의 의존성을 분석해 한 서비스의 변경이 다른 서비스에 미칠 영향을 확인합니다. - 별도의 기준을 지정하지 않으면 일반적인 모범 사례를 적용합니다. - AWS가 관리하는 격리 환경에서 애플리케이션을 실행하고 다음을 확인합니다. - 빌드 성공 여부 - 애플리케이션 실행 가능 여부 - 기본적인 사용자 여정과 기능 동작 - 분석 결과는 AWS DevOps Agent 콘솔과 GitHub·GitLab 풀 리퀘스트 댓글에 표시됩니다. - Kiro power 또는 Claude Code 플러그인을 통해 커밋 전에 IDE에서 직접 검토를 실행할 수도 있습니다. ## 조직별 자연어 기준 설정 - AWS DevOps Agent 콘솔에서 `Knowledge` → `Instructions`로 이동해 검토 기준을 편집합니다. - `Release readiness review`에 특정 작업용 지침을 추가할 수 있습니다. - 일반 영어 문장으로 다음과 같은 내부 기준을 정의할 수 있습니다. - 암호화 및 네트워크 접근 규칙 - 로깅과 관측 가능성 요구사항 - 민감 데이터 분류 및 고위험 리소스 식별 - 차단하지 않고 경고만 해야 하는 기준 - 모든 에이전트에 공통 기준을 적용하려면 `All agents` 지침을 수정합니다. ## 자동 릴리스 테스트 - 웹 애플리케이션과 API 애플리케이션을 대상으로 변경사항에 특화된 테스트 계획을 자동 생성합니다. - 정적인 테스트 스위트를 반복 실행하는 대신, 변경 내용과 영향 범위를 분석해 테스트를 구성합니다. - 다음 유형의 문제를 검증합니다. - 기능적 정확성 - 기존 동작의 회귀 - 서비스 간 통합 문제 - 수동 테스트 계획에서 누락될 수 있는 시나리오 - 고객이 제공한 운영 유사 환경에서 병합 전에 테스트를 실행합니다. - 각 실행 결과에는 다음 구조화된 산출물이 포함됩니다. - 메트릭 - 로그 - 트레이스 - 테스트 실행 요약 ## 검토 실행 방법 - 먼저 GitHub 또는 GitLab 리포지터리를 Agent Space에 연결해야 합니다. - 연결된 코드는 인덱싱되며, 리포지터리와 클라우드 리소스 간 의존성을 나타내는 지식 그래프가 생성됩니다. - 웹 앱에서 Agent Space를 선택한 뒤 `Web app` 탭과 `Operator access`를 선택합니다. - 릴리스 준비성 검토는 다음 방식으로 실행할 수 있습니다. - 연결된 리포지터리에 풀 리퀘스트 제출 - 채팅에서 온디맨드 요청 실행 - 채팅에서는 다음과 같이 요청할 수 있습니다. ```text Perform a production risk analysis on my repository branch ``` - 이후 분석할 리포지터리와 브랜치를 지정합니다. - 브랜치 이름, 풀 리퀘스트 번호, 커밋 SHA를 기준으로 분석할 수 있습니다. - 인프라 영향, 설정 변경, 배포 시 발생 가능한 위험을 종합적으로 검토합니다. - 완료 후 후속 질문을 통해 특정 변경사항의 하위 소비자, 영향받는 파일과 줄 번호, 해결 방법을 추가로 확인할 수 있습니다. ## 검토 결과와 보고서 - `Changes` 메뉴의 `Proposed changes` 표에서 실행된 검토를 확인할 수 있습니다. - 카테고리와 상태로 필터링하거나 이름으로 검색할 수 있습니다. - `Timeline` 탭에서는 에이전트가 호출한 도구, 참고한 의존성, 각 단계의 관찰 내용을 시간순으로 확인할 수 있습니다. - `Report` 탭에는 다음 정보가 제공됩니다. - 최종 권고 조치 - 발견된 심각한 문제 수 - 커밋 리비전 - 변경된 파일 수 - 권고 조치는 다음 세 가지 중 하나입니다. - `BLOCK` - `Proceed with Caution` - `Safe to Release` - 보고서의 주요 구성은 다음과 같습니다. - `Analysis`: 권고 조치의 근거와 발견된 위험 - `Issues`: 심각도별 문제 목록 - `Recommendations`: 문제 해결을 위한 구체적인 조치 - `Changes`: 변경된 파일, 변경 유형, 분류, 변경 내용 AWS DevOps Agent의 릴리스 관리 기능은 사람의 리뷰를 완전히 대체하기보다는, AI 생성 코드가 늘어난 환경에서 반복적인 위험 분석과 변경별 테스트를 자동화하는 보조 수단으로 활용하는 것이 적절합니다. 우선 내부 보안·운영 기준을 자연어 지침으로 명확히 정의하고, 풀 리퀘스트 단계에서 릴리스 준비성 검토를 실행한 뒤 운영 유사 환경의 자동 테스트를 병행하는 방식을 권장합니다.

release-managementobservabilitygitlabgithub+4

spotify2026년 2월 19일

Spotify 앱을 출시하는 방법: 내부 (새 탭에서 열림)

스포티파이는 Jira 중심의 복잡하고 분절된 릴리스 관리 프로세스를 개선하기 위해 자체 개발 포털인 Backstage 기반의 '릴리스 매니저 대시보드(Release Manager Dashboard)'를 구축했습니다. 이 도구는 10개 이상의 시스템에서 데이터를 통합하여 릴리스 매니저의 인지 부하를 줄이고, 안드로이드, iOS, 데스크톱 등 각 플랫폼의 릴리스 상태를 한눈에 파악할 수 있게 합니다. 결과적으로 스포티파이는 데이터 중심의 빠른 의사결정 체계를 갖추게 되었으며, 릴리스 과정에서 발생할 수 있는 휴먼 에러를 최소화했습니다. ### Jira 중심 프로세스의 한계와 새로운 도구의 탄생 * 기존에는 모든 릴리스 정보가 Jira 티켓에 흩어져 있어, 릴리스 매니저가 수많은 탭을 오가며 상태를 확인해야 하는 컨텍스트 스위칭 문제가 심각했습니다. * 새로운 대시보드는 컨텍스트 스위칭 최소화, 인지 부하 감소, 빠르고 정확한 의사결정 지원을 목표로 설계되었습니다. * 이를 통해 모바일 릴리스 프로세스에 대한 기본 지식만 있다면 누구나 직관적으로 상황을 이해할 수 있는 환경을 조성했습니다. ### 통합된 데이터와 트랙 중심의 관리 * 플랫폼(Android, iOS, Desktop)과 버전의 조합을 '트랙(Track)'으로 정의하고, 각 트랙을 독립적이면서도 통합적으로 관리합니다. * **트랙별 필수 데이터:** 릴리스 상태(State), 릴리스 차단 버그(Blocking Bugs), 회귀 테스트 통과 여부(Sign-off), 최신 릴리스 후보(RC) 빌드 및 앱스토어 업로드 상태 등을 포함합니다. * **품질 및 사용량 지표:** Crash 발생률, ANR(응답 없는 앱), 곡당 CPU 예외 사항, DAU(일일 활성 사용자 수) 등 실시간 품질 지표를 함께 모니터링합니다. * **미할당 버그 관리:** 특정 버전에 할당되지 않았거나 우선순위가 없는 버그들을 별도로 표시하여, 릴리스를 방해할 수 있는 잠재적 요소를 사전에 분류하고 담당 팀을 지정합니다. ### Backstage 기반의 에코시스템과 직관적인 UI * 스포티파이의 내부 개발자 포털인 Backstage의 플러그인(React, TypeScript 기반)으로 개발되어 기존 개발 도구들과의 UI/데이터 일관성을 유지합니다. * **신호등 시스템:** 상태를 초록색(준비 완료), 노란색(대기/경고), 빨간색(오류/즉각 조치 필요)으로 시각화하여 즉각적인 상황 판단을 돕습니다. * 상세 정보가 필요한 경우 클릭 한 번으로 앱 빌드나 크래시 상세 리포트 등 관련 플러그인으로 바로 연결되는 드릴다운(Drill-down) 구조를 갖췄습니다. ### 백엔드 아키텍처 및 성능 최적화 * 약 10개의 기존 시스템으로부터 데이터를 수집하고 통합하는 API 게이트웨이 역할을 수행하는 백엔드 서비스를 구축했습니다. * 초기 버전은 매번 대규모 쿼리를 실행하여 속도가 느리고 비용이 높았으나, 5분 단위의 데이터 사전 집계(Pre-aggregation)와 캐싱 기술을 도입해 최적화했습니다. * 이를 통해 대시보드 로딩 시간을 8초로 단축하고, 운영 비용을 획기적으로 낮추면서도 높은 신뢰성을 확보했습니다. ### 단계별 릴리스 모니터링 상세 * **Production(운영):** 이미 배포된 버전의 크래시 지표와 지난 24시간 동안의 DAU 추이를 모니터링하여 배포 후 예기치 못한 문제를 감시합니다. * **Current(현재):** 배포 대기 중인 버전의 상태를 집중 관리합니다. ITGC(IT 일반 통제) 테스트 통과 여부와 데이터 손실 임계치 준수 여부 등을 확인하여 최종 배포 가능 여부를 결정합니다. * **Upcoming(차기):** 다음 릴리스 버전을 미리 준비하며, 해당 단계에서 불필요한 섹션은 비활성화하여 현재 집중해야 할 정보와 구분합니다. 복잡한 마이크로서비스 환경이나 멀티 플랫폼 앱을 운영하는 조직이라면, 흩어진 릴리스 데이터를 하나로 모으는 전용 대시보드 구축이 필수적입니다. 특히 Backstage와 같은 내부 개발 포털을 활용해 도구 간 데이터 일관성을 확보하고 시각적인 상태 지표(초록/노랑/빨강)를 도입하면, 릴리스 관리의 효율성을 극대화하고 배포 안정성을 크게 높일 수 있습니다.

release-managementci-cdreacttypescript+4