toss·2026년 1월 20일원문

토스인컴 QA Platform: ‘누구나 테스트할 수 있는’ 도구의 시작 (새 탭에서 열림)

토스 QA 팀은 반복되는 테스트 데이터 생성과 복잡한 API 호출 문제를 해결하기 위해 기존 Swagger API를 GUI 기반으로 추상화한 'QA Platform'을 구축했습니다. 이 도구는 테스트의 진입 장벽을 낮춰 QA뿐만 아니라 모든 팀원이 품질 검증에 참여하게 함으로써 제품 개발 속도를 획기적으로 높이는 결과를 가져왔습니다. 단순히 테스트를 자동화하는 것을 넘어, 품질을 제품 설계 과정의 일환으로 내재화하여 팀 전체가 확신을 가지고 움직일 수 있는 환경을 조성한 것이 핵심입니다. **Swagger 기반의 접근성 개선 (Phase 1)** * Swagger에 흩어져 있는 테스트 API들을 한곳에 모으고, 복잡한 JSON 작성 없이 버튼 클릭만으로 실행할 수 있는 GUI를 도입했습니다. * 사용자의 숙련도에 따라 입력 방식을 이원화했습니다. 'Normal 모드'는 복잡한 필드를 숨겨 누구나 쉽게 쓰게 했고, 'Swagger 모드'는 QA 매니저나 엔지니어가 세부적인 파라미터를 제어할 수 있도록 설계했습니다. * 환경 스위칭, 최근 실행 값 저장, API 응답 값의 자동 복사 기능 등 사소하지만 빈번한 번거로움을 줄여주는 UX 요소를 배치해 심리적 장벽을 낮췄습니다. **자동화의 대중화와 통합 관리 (Phase 2 & 3)** * QA 팀 내부에서만 활용되던 기존의 자동화 스크립트를 플랫폼 내 컨트롤러로 이식하여, 개발자나 기획자도 버튼 하나로 자동화 테스트를 수행할 수 있게 했습니다. * 복잡한 환경 설정이나 스크립트 실행 지식 없이도 자동화 자산을 활용할 수 있게 되어, 검증의 주체가 QA 팀에서 제품 팀 전체로 확장되었습니다. * 외부 도구에 의존하는 대신 조직의 고유한 테스트 방식에 최적화된 통합 관리 시스템을 구축하여, 테스트 설계부터 실행 및 관리까지의 전 과정을 하나로 연결하고 있습니다. **품질 검증에서 품질 설계로의 관점 전환** * 테스트가 '시간을 내서 해야 하는 특별한 작업'이 아니라 '생각나면 바로 하는 일상'이 되면서, 제품의 병목 현상이 제거되고 의사결정 속도가 빨라졌습니다. * 개발자가 기능을 완성하자마자 직접 검증할 수 있는 환경이 마련됨에 따라, 품질은 마지막 단계의 체크리스트가 아닌 개발 흐름 속에 자연스럽게 녹아드는 요소가 되었습니다. * QA 팀은 단순 반복적인 테스트 데이터 세팅 작업에서 벗어나, 더 고도화된 비즈니스 로직 분석과 리스크 관리에 집중할 수 있는 환경을 확보했습니다. 테스트가 쉬워지면 제품의 속도는 자연스럽게 빨라집니다. 기술적인 고도화만큼이나 중요한 것은 "누가 하느냐"에 갇혀 있던 테스트 권한을 "누구나 할 수 있는 구조"로 만드는 것이며, 이를 통해 팀 전체가 품질에 대한 공동의 책임과 확신을 갖는 것이 실질적인 제품 경쟁력으로 이어집니다.

quality-assurancetest-automationapi-testingtest-management+3

toss·2025년 11월 3일원문

토스플레이스 사일로 QA로 일한다는 것 (새 탭에서 열림)

토스플레이스의 QA 팀은 기능 조직으로서의 전문성을 유지함과 동시에 제품 개발 단위인 '사일로(Silo)'에 겸직 형태로 참여하여 제품의 초기 기획 단계부터 배포까지 전 과정을 함께합니다. 이러한 구조적 변화를 통해 QA는 단순한 검수자가 아닌 제품의 히스토리를 깊이 이해하고 리스크를 선제적으로 관리하는 전략적 파트너로 자리 잡았습니다. 결과적으로 품질 관리가 배포를 지연시킨다는 편견을 깨고, 빠른 배포와 높은 품질을 동시에 달성하며 팀 전체의 신뢰를 얻는 성과를 거두었습니다. **사일로 겸직 구조를 통한 품질 관리의 내재화** * QA 매니저는 제품 초기 셋업 단계부터 참여하여 OKR 설계 및 요구사항 정의 과정에서 발생할 수 있는 잠재적 리스크를 사전에 식별합니다. * 제품의 제작 의도와 히스토리를 명확히 파악함으로써 보다 정교한 테스트 범위 산정과 테스트 케이스 설계가 가능해집니다. * 사일로 내부에서 작은 단위의 프로세스 실험을 자유롭게 수행하고, 성과가 검증된 방식은 팀 전체로 확산하는 유연한 운영 방식을 채택하고 있습니다. **협업 효율을 높이는 디자인 및 스펙 리뷰 체계** * '스펙 리뷰 → QnA 세션 → 변경 사항 정리'로 이어지는 흐름을 도입하여 개발 및 QA 과정에서 발생하는 이해관계자 간의 정보 간극을 최소화했습니다. * 디자인 툴(데우스)과 사내 메신저 스레드를 활용해 산재된 변경 내용을 한곳에 모아 관리함으로써 투명성을 높였습니다. * 개발 착수 전 모든 직군이 동일한 이해도를 가질 수 있도록 디자인 픽스 시점에 별도의 리뷰 미팅을 진행합니다. **라이브 모니터링과 품질 책임의 공유** * 릴리즈 이후 QA 혼자 검증하는 한계를 극복하기 위해 모든 팀원이 함께 확인해야 할 '주요 체크리스트'를 도입했습니다. * 개발 외 직군도 직접 제품 상태를 점검하게 함으로써 품질은 QA만의 책임이 아닌 팀 전체의 책임이라는 문화를 형성했습니다. * 이를 통해 최종 스펙을 재검증하고 실환경에서 발생할 수 있는 문제를 조기에 발견하는 환경을 구축했습니다. **개발 효율을 극대화하는 Sanity 테스트 및 백로그 관리** * QA 시작 기준을 명확히 하기 위해 개발 시작 전 'Sanity 테스트' 기준을 수립하고, 정상 시나리오(Happy Case)에 대한 검증을 기본 원칙으로 세웠습니다. * 사내 메신저의 'Send to Notion' 기능을 활용해 대화 중 나오는 아이디어나 작은 이슈들이 누락되지 않도록 즉시 백로그 데이터베이스에 기록합니다. * 이슈의 우선순위를 사용자 경험과 배포 긴급도에 따라 분류하여, 효율적인 리소스 배분과 체계적인 이슈 추적을 실천하고 있습니다. **커뮤니케이션 중심의 도구 최적화 (Jira에서 리스트/캔버스로)** * 소통 채널의 파편화를 막기 위해 기존의 Jira 중심 업무 방식에서 사내 메신저 기반의 '리스트/캔버스' 기능으로 전환을 시도했습니다. * 담당자 지정 및 템플릿 커스터마이징을 통해 이슈 관리와 소통을 한곳에 통합하여 맥락 공유에 드는 리소스를 대폭 줄였습니다. * 도구 자체의 기능보다는 팀의 실제 소통 방식에 가장 적합한 도구를 선택하는 유연함을 발휘하여 업무 속도를 높였습니다. 토스플레이스의 사례는 QA가 제품의 끝단이 아닌 시작점부터 결합될 때 조직의 생산성이 어떻게 극대화될 수 있는지를 잘 보여줍니다. 품질 관리 프로세스를 고정된 틀에 가두지 않고 각 팀의 특성에 맞게 유연하게 설계하고 개선해 나가는 '자율성'과 '실험 정신'은 제품의 신뢰도를 높이고자 하는 모든 IT 조직에 실질적인 영감을 제공합니다.

quality-assurance데이터베이스 설계jiranotion+4

figma·2022년 1월 25일·3분 읽기큐레이션 요약

작지만 큰 업데이트: 퀄리티

Figma의 Quality Week는 단순한 코드 오류뿐 아니라, 사용자가 “버그처럼 느끼는” 문제까지 찾아 개선하는 기간이다. 글은 버그를 고치는 일이 명세대로 복원하는 것 이상이며, 복잡한 운영체제·브라우저·사용자 경험을 고려해 무엇을 고칠 가치가 있는지 판단하는 과정이라고 설명한다. 작은 수정도 실제 사용자에게는 큰 품질 차이를 만들 수 있지만, 수정 자체가 다른 문제를 낳지 않도록 세심한 검토가 필요하다. ### Quality Week의 목적 - Figma 제품 팀은 몇 달에 한 번씩 Quality Week를 진행한다. - 평소 우선순위에서 밀리기 쉬운 문제를 집중적으로 조사하고 수정한다. - 대상에는 다음과 같은 문제가 포함된다. - 전형적인 코딩 오류 - 재현하기 어려운 이상 현상 - 기술적으로는 버그가 아니지만 사용자에게는 버그처럼 보이는 문제 - 전통적인 버그의 정의를 넘어서는 품질 문제 - 2022년 1월 Quality Week에서는 Figma와 FigJam의 여러 작은 개선 사항이 공개됐다. ### macOS 악센트 메뉴와 브라우저별 차이 - macOS에서 악센트 메뉴를 사용해 문자를 입력하면 글자가 반복되거나 입력되지 않는 문제가 있었다. - 원인은 단순한 비즈니스 로직이 아니라 키 입력 과정의 이벤트 순서와 관련된 브라우저 동작의 차이였다. - 키가 눌림 - 키가 일정 시간 유지됨 - 키가 해제됨 - 입력할 문자가 결정됨 - 문자가 화면에 표시됨 - 운영체제와 브라우저가 Figma보다 먼저 처리하는 이벤트 과정에서 예상과 다른 동작이 발생했다. - 이를 보완하는 수정 코드는 10줄 미만이었고 키보드와 마우스 입력 모두 지원했다. - 그러나 수정 사항은 Firefox와 Safari에서는 정상 작동했지만, 사용자 비중이 가장 큰 Chrome에서는 문제가 계속됐다. - 따라서 개발자 관점에서는 버그를 해결했더라도, 대부분의 사용자에게는 여전히 해결되지 않은 문제였다. ### 명확한 버그 정의와 현실적인 버그 정의 - 이론적으로 버그는 두 가지 정보로 정의된다. - 원래 어떻게 동작해야 하는가 - 현재 어떻게 잘못 동작하고 있는가 - Y2K 문제나 Pentium FDIV 버그처럼 기대 동작과 실제 동작의 차이가 명확한 사례도 있다. - 하지만 사람과 기계가 상호작용하는 복잡한 시스템에서는 “정상 동작”의 기준 자체가 불분명할 수 있다. - 기능이 의도대로 작동하지만 사용하기 불편한 경우와, 기능이 완전히 고장 난 경우가 실제 사용자 경험에서는 비슷하게 느껴질 수 있다. - 화성 기후 궤도선 사고처럼 코드 오류가 아니더라도 서로 다른 단위 체계를 사용한 시스템 간 불일치가 치명적인 결과를 낳을 수 있다. - 모든 문제를 수정할 수 있는 것도 아니며, 모든 문제가 수정할 가치가 있는 것도 아니다. - 때로는 원래 상태로 되돌리는 대신, 더 안정적인 새로운 동작 방향을 선택해야 한다. ### “버그처럼 느껴지면 버그”라는 관점 - HEIC 이미지 지원은 전통적인 정의로는 버그가 아니었다. - Figma가 처음부터 해당 포맷을 지원하지 않았으므로 기존 기능이 망가진 것은 아니기 때문이다. - 그러나 iPhone이나 iPad에서 가져온 이미지 중 일부만 작동하면 사용자는 Figma가 불안정하다고 느낀다. - 따라서 사용자 경험 관점에서는 명세에 없던 기능의 부재도 버그로 취급할 수 있다. - Quality Week는 이런 문제를 제품 품질 개선 대상으로 다룰 수 있게 해준다. ### HEIC 지원과 로딩 상태의 중요성 - HEIC 지원을 위해 약 98줄의 코드가 추가됐다. - 하지만 고해상도 HEIC 파일은 용량이 크고 처리 시간이 오래 걸리는 문제가 있었다. - 파일을 캔버스에 끌어놓은 뒤 서버와 내부 처리 과정에서 수 초가 걸리는 동안 아무런 시각적 피드백이 없었다. - 사용자는 기능이 처리 중인지, 아니면 입력을 무시한 것인지 알 수 없었다. - 기능이 실제로 작동하고 있어도 사용자에게 작동하지 않는 것처럼 보이면 품질 문제로 이어진다. - 이를 해결하기 위해 이미지 처리 중임을 알리는 로딩 상태를 추가하는 방안이 제시됐다. - 글은 이처럼 단순해 보이는 로딩 개선에도 사용자의 심리와 관련된 또 다른 이상 현상이 숨어 있었다고 설명하며 이어진다. 작은 버그라도 실제 사용 환경과 사용자 인식을 기준으로 우선순위를 판단해야 한다. 특히 브라우저 호환성, 처리 지연, 로딩 피드백처럼 명세만으로 드러나지 않는 문제를 함께 점검하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

quality-assuranceFigmafigjammacos+3

figma·2018년 1월 24일·3분 읽기큐레이션 요약

퀄리티 위크 동안 Figma에서

Figma는 신규 기능 개발만큼 기존 제품의 품질 개선도 중요하다고 보고, 전 직원이 일주일 동안 버그 수정에 집중하는 ‘Quality Week’를 운영했다. 이 기간에는 사소하지만 반복적으로 사용자 경험을 해치는 버그와 완성도가 낮은 기능을 집중적으로 개선했으며, 제품을 더 빠르고 안정적이며 직관적으로 만드는 데 목적이 있었다. Quality Week는 사용자 만족뿐 아니라 구성원들이 평소 다루지 않던 코드 영역을 경험하고 팀 전체의 품질 의식을 높이는 기회가 되었다. ## 전사적인 품질 개선 주간 - 2017년 초 Figma는 첫 공식 Quality Week를 시작했다. - 엔지니어와 디자이너를 포함한 전 직원이 기존 프로젝트를 잠시 멈추고 제품의 “봄맞이 청소”에 참여했다. - 대상은 치명적인 장애뿐 아니라 다음과 같은 문제였다. - 기능은 동작하지만 사용하기 불편한 버그 - 전문적인 디자인 도구의 기준에 미치지 못하는 세부 동작 - 오랜 시간 반복 사용될 때 불편함이 누적되는 작은 결함 - 디자이너는 Figma를 장시간 사용하므로 작은 오류도 반복되면서 큰 불만으로 이어질 수 있다고 판단했다. - 기능 출시를 계속하는 대신 버그 수정에 집중함으로써 제품의 속도, 안정성, 직관성을 높이려 했다. ## Quality Week 2018의 주요 개선 사항 - 2018년부터 Quality Week를 정기적인 Figma의 전통으로 만들었다. - 두 엔지니어링 팀이 협력해 다양한 버그를 폭넓게 처리하고, 특히 전문 디자인 도구로서 문제가 되는 기능을 우선순위에 두었다. - 대표적인 개선 내용은 다음과 같다. - **Figma Mirror**: 모바일에서 디자인을 확인하는 미러링 앱의 안정성을 높이고 충돌을 줄였다. - **Sketch 가져오기**: Sketch 파일을 편집기 창으로 직접 드래그 앤 드롭할 수 있게 했으며, 텍스트 객체의 변환 정확도를 개선했다. - **Chromebook 지원**: 검색 키와 드래그를 조합해 객체를 복제할 수 있도록 해 학생 등 Chromebook 사용자의 편의성을 높였다. - **레이어 패널**: 레이어를 이동할 때 그룹과 프레임 안에 더 자연스럽게 중첩되도록 동작을 개선했다. - 모든 버그를 해결한 것은 아니며, Quality Week는 연중 진행되는 일반적인 버그 수정과 별도로 집중적인 개선 시간을 확보하는 방식이다. ## 오래된 버그를 해결하는 조직적 가치 - Quality Week의 효과는 사용자에게 제공되는 수정 사항에만 국한되지 않았다. - 개발자와 디자이너가 평소 담당하지 않던 코드베이스와 기능 영역을 살펴볼 수 있었다. - 이를 통해 구성원들이 제품 전체 구조를 더 폭넓게 이해하고 협업할 기회를 얻었다. - 2015년부터 Windows 사용자에게 영향을 주던 오래된 버그가 해결되었고, 이를 기념해 ‘가장 오래된 버그’ 상을 수여했다. - 버그 수정 과정을 행사와 시상식으로 즐겁게 만들어, 반복적이고 비 glamour한 작업에도 성취감을 부여했다. ## 사용자 피드백을 품질 개선에 활용 - 수정된 버그 중 상당수는 Figma 커뮤니티가 제보한 문제에서 비롯되었다. - 사용자는 제품 내부의 도움말 메뉴에서 **Contact Us**를 선택하거나 Twitter, 커뮤니티 포럼, 이메일을 통해 피드백을 보낼 수 있었다. - Figma는 지원팀만이 아니라 엔지니어, 경우에 따라 CEO까지 직접 사용자 지원에 참여하는 ‘전사적 지원’ 문화를 강조했다. - 이는 실제 사용 환경에서 발견되는 문제를 개발팀이 빠르게 이해하고 제품 개선에 반영하는 기반이 되었다. ## 실용적인 결론 신규 기능 출시와 기술 부채·버그 정리는 균형 있게 운영해야 한다. 정기적으로 전사 또는 팀 단위의 집중 품질 개선 기간을 마련하고, 오래된 버그와 반복적인 사용성 문제를 사용자 피드백에 따라 우선 처리하면 제품 완성도와 팀의 코드베이스 이해도를 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)

quality-assuranceFigmadesign-toolswindows+4