토스플레이스 사일로 QA로 일한다는 것

안녕하세요. 토스플레이스 QA Manager 채소연입니다.

토스플레이스의 QA Manager는 기능조직인 QA 팀으로 함께 일하고 있어요. 동시에 팀이나 *사일로로 ‘겸직’의 형태로 배치 되어 제품의 초기 셋업 단계부터 배포까지, 프로젝트와 프로덕트 전반의 품질을 관리합니다.

현재 각 팀원은 겸직으로 1개 이상의 사일로에 소속되며, 기본이 되는 프로세스에 더해서 사일로별 특성과 목표에 맞게 프로세스를 유연하게 운영하고 있습니다. 관심 있고 기여할 수 있는 팀/사일로의 배치를 오픈해서 논의해 결정할 수 있기 때문에, 나의 제품이라는 인식과 동시에 더 큰 동기와 책임감을 가지고 참여할 수 있습니다.

QA는 단순히 기획 리뷰 단계에서만 제품을 리뷰하는 것이 아니라, 제품과 프로젝트의 시작 단계부터 함께합니다.이를 통해 요구사항과 히스토리를 명확히 이해하고, 리스크 확인·테스트 범위 산정·테스트 케이스 설계·테스트 실행까지 더 깊이 있게 지원할 수 있습니다. 또한 팀 빌딩 단계인 OKR 설계 과정부터 참여하기 때문에 QA도 힘께 세운 목표의 달성에 기여하고 있어요. *사일로(Silo): 토스플레이스는 하나의 제품이나 서비스 단위를 책임지는 작은 팀을 사일로(Silo)라고 부릅니다. 각 사일로는 기획, 디자인, 개발, QA, 데이터 등 필요한 직군이 모여 독립적으로 하나의 목표를 가지고 빠르게 제품을 만들어가는 가장 작은 단위의 제품조직 입니다.

제품팀 소속 QA가 만든 인식의 변화

QA Manager로서 종종 이런 질문을 듣습니다.

“QA가 다른 팀과 협업할 때, 가치를 주는 팀으로 보이려면 어떻게 해야 하나요?”

사실 QA가 제품 개발의 마지막 단계에만 깊이 개입한다면, 제품의 히스토리를 알지 못한 채 얕은 테스트만 진행하게 될 수 있습니다. 그렇게 되면 기능 상의 리스크를 뒤늦게 발견해 전체 일정이 늦어지거나, 심지어 스펙을 크게 바꿔야 하는 상황도 생길 수 있어요.

그래서 우리는 QA팀으로서 중앙에서 품질 문화를 이끌어가는 동시에, 각 사일로 안에 들어가 겸직으로 함께하기로 했습니다. QA가 끝단에서 문제를 발견하고 막는 팀이 아니라, 팀의 논의와 의사결정 과정에 직접 참여하면서 리스크를 줄이고 실행 속도를 높이는 동료가 되기 위함이죠. 이를 통해 제품의 제작 의도, 히스토리를 명확하게 알수 있게 되어 리스크 확인, 테스트 범위 산정, 테스트케이스 설계, 테스트 등에서도 많은 도움이 되고 있습니다.

이런 겸직 구조를 통해 가장 크게 달라진 것은 QA에 대한 인식이었어요. 예전에는 QA가 배포를 지연시키기만 한다는 인식이 강했지만, 실제로 함께 일하면서 팀원들은 QA가 있으면 더 빠르고 안정적으로 나아갈 수 있다는 경험을 쌓아가고 있습니다.

즉 QA는 프로세스를 늦추는 팀이 아니라, 빠른 배포와 높은 품질을 동시에 가능하게 하는 존재로 자리잡으며 지금은 함께 일하고 싶은 팀으로 나아가고 있습니다.

겸직으로 제품팀 소속으로 업무를 진행하면서 좋은 점은, 다양한 시도를 작은 단위에서 먼저 실험해볼 수 있다는 것입니다. 사일로 안에서 시도해 보고 좋은 결과가 나오면 전체 팀 프로세스에 도입하고, 효과가 없으면 과감히 버릴 수 있어요.

이 글에서는 저희가 실제로 시도했던 것들 중 일부를 공유해 보려고 합니다.

우리가 시도했던 변화들

✅ 디자인 리뷰 강화

스펙 리뷰를 진행함에도 불구하고 개발·QA 과정에서 자주 발생하는 문제 중 하나는 스펙을 다르게 이해하거나 변경 사항 공유가 누락되는 것이었습니다.

이를 해결하기 위해 사일로 내에서 스펙 리뷰 → QnA 세션 → 변경사항 정리라는 흐름을 제안했어요.

• 리뷰 단계에서는 모든 팀원이 제품의 기본 흐름을 공유할 수 있도록 했습니다.
• QnA 세션은 사전에 질문을 모아 진행하여, 반복 논의를 줄이고 효율성을 높였습니다.
• 변경 내용은 하나의 사내 메신저 스레드나 사내 디자인 툴인 데우스에 모아 관리하고, QA 산출물 내에서 정리하며 운영을 보완했습니다.

이 과정을 통해 스펙 이해의 간극을 줄이고, 변경 사항을 더 빠르고 투명하게 공유할 수 있었습니다.

✅ 라이브 모니터링

릴리즈 이후에도 QA의 역할은 끝나지 않습니다.

사일로에는 보통 QA가 1명만 배치되기 때문에, 혼자서 모든 환경을 커버하거나 여러 관점에서 교차 검증하기에는 한계가 있었습니다. 특히 개발과 직접적인 관련이 없는 직군의 경우, 자신이 만드는 서비스를 실제로 실행해본 경험이 없는 경우도 있었어요.

이런 한계를 극복하기 위해 팀원 모두가 제품의 상태를 함께 확인할 수 있도록, 릴리즈 후 반드시 확인해야 하는 주요 체크리스트를 만들어 공유했습니다. 이를 통해 최종 스펙을 다시 검증하고, 릴리즈 이후 발생할 수 있는 문제를 조기에 발견할 수 있었습니다.

무엇보다 QA 뿐 아니라 모든 팀원이 직접 상태를 점검하면서, 품질은 QA만의 책임이 아니라 팀 전체의 책임이라는 문화를 자연스럽게 강화할 수 있었습니다.

✅ Sanity 테스트 도입

개발을 시작하는 단계에서 QA 시작 기준이 명확하지 않으면, 불필요한 리소스가 소모되거나 QA와 개발자의 이해가 어긋날 수 있었습니다. 이를 해결하기 위해 사일로 시작 시점에 개발자와 QA가 모여 기준을 정리하는 회의를 진행했어요.

그 과정에서 다룬 주요 포인트는 다음과 같았습니다.

• 세부적인 스펙(예: 최소/최대 제한 등)을 개발자가 먼저 정리하고, 이후 PO가 다시 체크해 합의한다.
• 디자인에서 제안된 정상 시나리오(Happy Case)에 대한 검증을 기본으로 삼는다.
• 디자인은 초안 단계에서 위클리 공유로 확인하고, 디자인 픽스가 되는 시점에는 별도의 리뷰 미팅을 잡아 개발 착수 전 모든 직군이 동일한 이해도를 갖고 시작한다.

이 과정을 통해 개발과 QA가 같은 출발선에서 프로젝트를 시작할 수 있었고, 불필요하게 소요되던 리소스를 줄이며 더 효율적으로 QA를 진행할 수 있었습니다.

✅ 사일로 별 백로그 관리

작은 요청이나 발견된 이슈들이 공식적인 백로그에 등록되지 않고 흩어지는 경우가 많았습니다. 수정 요청이 누락되거나 반영되지 않는 일이 반복되면서, 누가 무엇을 확인해야 하는지 추적하기가 쉽지 않았어요.

이를 개선하기 위해 각 사일로 별로 백로그 관리 방식을 정리했습니다.

• 사내 메신저에서 바로 Send to Notion 기능을 활용해, 요청이나 발견된 이슈를 곧바로 해당 사일로의 백로그 데이터베이스에 추가할 수 있도록하며 대화 속에서 나온 아이디어나 수정 요청도 놓치지 않고 바로 기록으로 남길 수 있었습니다. (처음에 문서 작성툴로 관리했지만 이것도 사내 메신저 리스트로 이관되었습니다.)

  

우선순위 관리도 병행했어요.

• 사용자 경험에 큰 영향을 주지 않는 항목은 우선순위를 낮춰두고, 실제 배포나 CS와 관련된 기능은 반드시 챙길 수 있도록 별도로 관리했습니다.

  

이런 방식으로 각 사일로의 백로그를 정리했고 여유가 있을 때 차근차근 처리하거나, 관련 기능을 배포할 시점에 맞춰 함께 해결할 수 있었습니다. 결과적으로 사일로 안에서 발견된 작은 요청들이 흩어지지 않고 모여 관리되면서, QA뿐 아니라 팀 전체가 같은 맥락을 공유할 수 있게 되었습니다.

✅ JIRA FADE OUT + 리스트 / 캔버스 도입

입사 직후 가장 먼저 들었던 의문은 “왜 JIRA가 있는데 사내 메신저로 소통할까?”였습니다.

당시 이슈는 JIRA에 등록하지만, 실제 소통은 제각각이었어요. 어떤 개발자는 JIRA 댓글로, 또 다른 개발자는 사내 메신저 스레드로 대화하다 보니 채널이 분산되었고, 같은 맥락을 두 번 설명해야 하거나 중요한 대화가 흩어지는 일이 잦았습니다.

또한, JIRA에 익숙하지 않거나 자주 확인하지 않는 분들도 있어 빠른 소통이 어렵다는 한계가 있었습니다. 결국 대부분의 논의가 캔버스에서 이뤄졌지만, 이 경우에도 해결된 이슈·수정 중인 이슈·논의 중인 이슈를 구분하기가 쉽지 않았어요.

이 문제를 해결하기 위해 사내 메신저에서 새롭게 제공한 사내 메신저 리스트 기능을 검토했고, 장단점을 팀원들과 공유했습니다. 그중 일부 내용은 다음과 같았어요.

• 스레드 방식이 그대로 적용된다.
• 각 이슈를 하나의 스레드로 관리할 수 있다.
• 담당자 지정이나 템플릿 커스터마이징이 가능하다.

물론 JIRA에 비해 백로그 관리나 장기적 프로젝트 관리 측면에서는 단점이 있을 수 있습니다. 하지만 우리 팀은 이미 사내 메신저를 주요 소통 채널로 활용하고 있었기 때문에, 소통과 관리가 한 곳에 모인다는 점에서 리스트/캔버스가 더 적합한 대안이 될 수 있다고 판단했습니다.

사내 메신저 리스트/캔버스를 도입한 뒤, 우리가 기대했던 장점들이 실제로 팀 안에서 드러났어요. QA 이슈 관리에는 훨씬 적합했고, 특히 소통의 분산 문제를 줄이며 작은 단위의 이슈를 빠르게 처리할 수 있었습니다. 반면, 장기적이고 복잡한 프로젝트 단위의 이슈 관리에는 여전히 한계가 있고 스레드가 길어질 경우 중간 공유와 요약이 어렵다는 단점도 있었습니다.

BTS 툴보다 사내 메신저 LIST가 더 좋다!는 말을 하려는 것은 아닙니다. 저희도 언제든 상황이 변한다면 다른 툴로 이동할 가능성을 열어두고 있어요. 다만 이 도입을 통해 얻은 가장 큰 교훈은, 도구 그 자체보다 현재 팀의 상황에 맞는 도구를 선택하는 것이 중요하다는 점이었습니다.

요청받는 테스트만을 진행할 때보다 사일로 안에서 함께할 때, 의사결정과 앞으로의 계획을 훨씬 잘 이해할 수 있습니다. 또한 사일로 안에 포함된 QA는 단순히 테스트만 하는 역할이 아니라, 제품을 함께 만드는 동료라는 소속감을 가질 수 있어요.

QA는 각 사일로에서 무엇을, 어떻게 하면 좋을지를 스스로 정하며, 그 자율성이 긍정적인 효과로 이어지고 있습니다. 올해 새로 합류한 혜정님은 DA와 협업하며 “데이터 관점에서 제품을 바라보는 게 신기하다”고 했고, 더 나아가 “QA도 데이터화된 지표로 제품의 자신감을 줄 수 있지 않을까?”라는 의견을 주시기도 하셨어요.

매주 진행하는 QA 팀 weekly에서는 각 사일로에서 진행되는 제품이 사일로 현상에 빠지지 않도록 전사와 제품의 소식을 공유하고, 각자 자신이 겸직 사일로의 디테일한 정보를 공유하며 다른 제품 정보까지 함께 나눕니다. 이를 통해 전사의 흐름을 긴밀하게 팔로업하고 있습니다.

이 글은 정답을 제시하려는 것은 아닙니다.

토스플레이스에서 어떤 실험을 해왔는지, 그리고 각 사일로에서 QA 프로세스를 어떻게 설계하고 운영해 가고 있는지를 공유하는 경험담으로 봐주시면 좋을 것 같아요.

토스플레이스의 QA 팀은 기본이 되는 최소한의 프로세스를 지키면서도 사일로별 상황에 맞게 프로세스를 유연하게 설계하고 회고를 통해 지속적으로 업데이트하고 있습니다. 이 유연성이야말로 겸직 구조에서 QA가 더 큰 가치를 발휘할 수 있게 해주는 힘이라고 생각합니다.

중요한 것은 QA가 뒷단에서 버그만 잡는 역할이 아니라, 제품의 시작부터 함께 고민하며 팀과 나아가는 동료라는 점이며 토스플레이스의 QA 팀은 그렇게 조금씩, 그러나 꾸준히 팀과 함께 성장하고 있습니다.

제품의 첫 시작부터 함께하며, 가장 작은 단위의 제품팀과 가까운 위치에서 제품의 Quality Confidence를 책임지는 저희 QA 팀의 성장을 앞으로도 계속 지켜 봐주세요.