현장에서 오래 일하다 보면 이런 말을 듣는 순간이 온다. “오퍼레이터를 고객으로 생각해.” 처음 들었을 때 기분이 살짝 묘했다. 나는 엔지니어고, 저 사람은 장비를 쓰는 사람인데 — 왜 내가 고객 응대를 해야 하지? 그런데 시간이 지나면서 알게 됐다. 실력 있는 엔지니어들은 전부 그 태도로 일하고 있었다. QA 마인드란 결국 거기서 시작한다.
이 글에서는 QA가 단순히 오류를 잡는 일이 아닌 이유, 내가 아무리 잘 만들어도 사용자 경험을 이길 수 없는 이유, 그리고 오류 제보부터 불합리 제보·컴플레인까지 모든 피드백을 자산으로 바꾸는 QA 마인드 3가지 원칙을 정리한다.
QA 마인드란 무엇인가
QA는 Quality Assurance의 약자다. 직역하면 품질 보증. 그런데 현장에서 QA를 “테스트해서 버그 잡는 것”으로만 이해하면 절반밖에 못 본다.
QA 마인드란 내가 만든 것을 사용하는 사람의 경험 전체에 책임을 지겠다는 태도다. 코드만이 아니다. 기준서, 사용자 가이드, 워크플로우, 장비 운용 절차 — 엔지니어가 설계하고 배포하는 모든 것이 QA의 대상이다. 누군가 그것을 쓰는 순간, 그 사람은 내 고객이 된다.
선배가 던진 말 — 오퍼레이터도 고객이다
한 선배가 말했다. “장비를 사용하는 오퍼레이터, 프로세스 엔지니어를 고객으로 생각해라.”
언뜻 들으면 기분 나쁜 말이다. 엔지니어로서 자존심도 있고, 내가 설계한 것에 자부심도 있는데 — 왜 내가 서비스 마인드를 가져야 하지? 그런데 그 말의 뜻은 갑을 관계가 아니었다. 내가 만든 것이 실제로 쓰이는 환경에 진지하게 관심을 가지라는 말이었다.
실력 있는 엔지니어들은 그 태도를 갖추고 있었다. 사용자가 불편하다고 말하면 방어하지 않았다. 왜 불편한지를 먼저 들었다. QA 마인드의 출발점은 내 결과물에 대한 자부심이 아니라, 사용자의 경험에 대한 진지한 관심이다.
내가 아무리 잘 만들어도 사용자 경험을 이길 수 없다
이 사실을 인정하는 데 시간이 걸렸다. 기준서를 꼼꼼하게 써도, 가이드를 상세하게 만들어도, 예외 케이스를 촘촘하게 커버해도 — 실제 사용자들은 내가 예상하지 못한 방식으로 그것을 쓴다.
스타크래프트가 좋은 예다. 개발자가 설계한 종족 밸런스와 유닛 스펙이 있었지만, 유저들은 그 이상을 만들어냈다. 저그 뮤탈 스택, 프로토스 리버 드롭, 테란 벌처 마인 드롭 — 개발자가 의도하지 않은 빌드오더와 전략이 게임 전체의 메타를 바꿨다. 유저들이 직접 맵을 제작해 종족별 특성을 반영했고, 그렇게 게임은 개발자의 통제 밖에서 더 풍부해졌다.
엔지니어링도 마찬가지다. 내가 설계한 워크플로우를 사용자가 내 의도대로만 쓸 거라는 전제 자체가 틀렸다. 사용자는 더 빠른 방법을 찾고, 단계를 건너뛰고, 예상치 못한 순서로 작업한다. 코드라면 더 입체적으로 작용한다 — 예외 상황의 조합은 내가 테스트한 경우의 수를 항상 넘어선다.
이것을 실패로 볼 게 아니다. 사용자 경험이 내 설계를 넘어선다는 것은 내 결과물이 실제로 쓰이고 있다는 신호다. 중요한 건 그 다양한 경험을 어떻게 받아들이느냐다.
QA의 현실적 기준 — 치명적 오류만 없으면 된다
모든 예외를 커버하려는 시도는 소모전이다. 사용자 경험의 다양성을 내가 사전에 전부 예측하고 설계할 수는 없다. 그렇다면 QA의 현실적인 기준은 어디에 있어야 할까.
기준은 하나다. 치명적인 오류만 없으면 된다.
치명적인 오류란 복구가 불가능하거나, 데이터가 날아가거나, 시스템 전체가 멈추는 상황이다. DB가 날아간다든지, 잘못된 기준서가 전체 공정에 영향을 미친다든지 — 이런 오류는 사전에 반드시 막아야 한다. 반면 사용자가 불편하다고 느끼는 UX 문제, 예상과 다른 동작 방식, 가이드의 모호한 표현 — 이것들은 배포 후 피드백으로 다듬어 나갈 수 있다.
완벽한 배포를 기다리다 아무것도 내놓지 못하는 것보다, 치명적 오류만 없는 상태로 배포하고 사용자와 함께 개선해 나가는 쪽이 더 강하다.
사용자 피드백은 오류 제보만이 아니다 — VOC를 아는가
제조·서비스 업계에는 VOC라는 개념이 있다. Voice of Customer, 고객의 목소리다. 사용자가 제품이나 프로세스에 대해 표현하는 모든 의견·요구·불만을 체계적으로 수집하고 반영하는 활동을 말한다. QA 마인드를 가진 엔지니어에게 VOC는 선택이 아니다 — 내 결과물이 실제 사용 환경에서 어떻게 작동하는지 알 수 있는 유일한 창구다.
QA 마인드를 가진 엔지니어가 받아들여야 하는 VOC의 범위는 생각보다 넓다.
| VOC 유형 | 예시 | QA 관점에서의 의미 |
|---|---|---|
| 오류 제보 | 버튼을 눌렀는데 작동 안 함 | 기능 결함, 즉각 대응 |
| 불합리 제보 | 이 절차가 왜 이렇게 복잡하냐 | 설계 구조 문제, 개선 인풋 |
| 불편 제보 | 이 가이드 뭔 말인지 모르겠다 | 가이드 품질 문제, 재작성 필요 |
| 컴플레인 | 쓰기 불편하다, 바꿔달라 | 사용자 경험 전반 재검토 신호 |
이 모든 VOC가 QA의 인풋이다. 오류만 QA 대상이 아니다. 불합리하다는 말, 불편하다는 말, 컴플레인 — 전부 내 결과물이 실제 사용 환경에서 마주치는 현실이고, 전부 VOC다.
선배가 말한 고객감동 마인드란 이것이다. VOC가 들어왔을 때 방어하지 않고, 먼저 듣고, 적극적으로 대응하는 것. 컴플레인을 귀찮은 일로 보지 않고, 내가 놓친 사용자 경험을 알려주는 신호로 보는 것.
피드백을 주고받는 경험 자체가 가치다 — 소통이 QA를 완성한다
흥미로운 점이 있다. 사용자도 피드백을 주고받는 경험 자체를 가치 있게 생각한다.
내가 컴플레인을 냈는데 엔지니어가 진지하게 들어주고, 빠르게 대응해줬다면 — 사용자는 그 결과물을 더 신뢰하게 된다. 단순히 오류가 수정됐기 때문이 아니다. 내 말이 반영됐다는 경험, 소통이 됐다는 경험이 신뢰를 만든다.
반대로 피드백을 무시하거나 방어적으로 대응하면, 사용자는 더 이상 피드백을 주지 않는다. 침묵이 된다. 침묵은 만족이 아니다 — 그냥 포기한 것이다.
QA 마인드를 가진 엔지니어는 피드백 루프를 열어두는 사람이다. 오류든, 불합리든, 컴플레인이든 — 사용자가 말할 수 있는 환경을 만들고, 그 말에 적극적으로 반응하는 것. 그 소통의 반복이 결과물을 점점 더 좋게 만든다. 그게 QA가 완성되는 방식이다.
핵심 요약
- QA 마인드란 내 결과물을 사용하는 사람의 경험 전체에 책임을 지는 태도다
- 코드뿐 아니라 기준서, 가이드, 워크플로우 — 엔지니어가 만드는 모든 것이 QA 대상이다
- 사용자 경험은 내 설계를 항상 넘어선다 — 이를 인정하는 것이 QA 마인드의 시작이다
- 치명적 오류만 없으면 배포할 수 있다 — 나머지는 피드백으로 다듬는다
- VOC란 고객의 목소리 전체다 — 오류 제보, 불합리 제보, 컴플레인 모두 VOC이자 QA 인풋이다
- VOC에 적극 대응하는 것이 고객감동 마인드다 — 무시와 판단은 다르다
- VOC를 주고받는 경험 자체가 신뢰를 만든다 — 소통이 QA를 완성한다
QA 마인드의 핵심은 도메인 지식으로 사용자 경험을 해석하는 데 있다. 데이터 분석에서도 같은 원칙이 작동한다.
엔지니어가 기술 역량 외에 갖춰야 할 태도가 궁금하다면 이 글도 이어서 읽어볼 만하다.
QA와 품질 관리에 대한 공식 기준이 궁금하다면 ASQ(미국 품질 협회)에서 더 알아볼 수 있다.
