dev.to

Two Weeks In: A 15-Year QA Veteran, Back to Being the New Guy

15년 차 QA 베테랑, 다시 신입이 되다

15년 동안 QA 업무를 맡아온 저자가 AI agent 스타트업에 합류한 뒤 겪은 첫 2주를 돌아봅니다. 경험은 결론만이 아니라 그 결론이 맞았던 조건과 맥락까지 담아야 하며, AI가 많은 사례를 처리해도 마지막 검증에는 사람이 필요하다고 말합니다.

AI 요약

15년 동안 manual testing, test automation, test development, test management를 거친 QA 경력자가 해고 뒤 옛 동료의 제안으로 AI agent 스타트업에 합류합니다. CTO와 한 차례 대화하고 HR 면접을 거쳐 입사한 뒤, 정확히 2주 동안 새 조직의 프로세스와 자신의 경험을 다시 살펴봅니다.

익숙한 방식과 다른 개발 프로세스

새 회사의 제품 → 요구사항 → 개발 → 테스트 → 출시 흐름은 기존에 익숙했던 방식과 다릅니다. 첫 주에는 엉망이라고 생각했지만, 시간이 지나며 잘못된 방식이 아니라 다른 방식일 수 있다고 받아들이기 시작합니다. 경력이 길수록 자신이 알던 질서와 맞지 않는 일을 먼저 의심하기 쉽기 때문에, 이번 2주의 원칙을 “먼저 이해하고, 그다음 판단하기”로 정했습니다. 초심자의 마음은 말처럼 쉽지 않고, 자신의 판단과 계속 논쟁하는 과정이라고 설명합니다.

속도는 오히려 만족스럽다고 말합니다. 이전 회사에서는 요구사항이 바뀌면 PM이 즉시 답해야 했지만, 새 조직에서는 테스터가 더 오래 생각하고 스스로 판단할 여지가 있습니다. QA 업무에서는 앞단에서 반나절을 들여 경계 조건, 이상한 입력, 여러 가정을 점검하면 나중에 일주일치 재작업과 장애 대응을 줄일 수 있습니다. “느리게 가는 것이 빠른 길이고, 빠르게 가는 것이 느린 길”이라는 경험칙을 새 회사의 업무 속도에서 다시 확인합니다.

312개 사례를 맞혀도 313번째는 남습니다

저자는 dev.to에 연재 중인 36 Stratagems 시리즈에서 Mark라는 인물을 만들었습니다. Mark는 오랜 경험을 머릿속에 축적한 뒤 회사에서 그 경험을 하나의 Skill로 추출당하고 해고된 인물입니다. 이야기 속 Skill은 과거 장애 시나리오 312개에서 96.8%의 진단 정확도를 기록합니다.

하지만 313번째 사례에서 문제가 발생합니다. 450ms 재시도 대기 시간은 5년 전 RabbitMQ의 GC window에 맞추려고 만든 호환성 설정이었습니다. Kafka로 오래전에 전환한 시스템에 이 값이 그대로 적용됐고, 문서에는 “450ms는 RabbitMQ GC window에 맞춘 값입니다. 이 맥락 밖에서는 재사용하지 마세요”라는 경고가 남아 있었습니다. 당시에는 아무도 그 의미를 이해하지 못했고, 새벽 4시에 CTO가 문서를 다시 찾은 뒤에야 원인을 확인했습니다.

저자가 이야기 마지막에 쓴 문장은 다음과 같습니다. “AI가 틀려서 실패한 것이 아닙니다. 어제에 대해서는 맞았지만, 이제는 어제가 실행되고 있지 않았기 때문에 실패했습니다.” 경험에서 중요한 것은 450ms라는 결론이 아니라, 왜 300ms가 아니라 450ms였는지 설명하는 맥락입니다. 그 맥락은 새벽 3시 postmortem에서 나온 판단일 수 있고, 문서 한 곳에 온전히 남지 않을 수 있습니다.

경험을 Agent로 추출한다는 말

새 회사 벽에는 두 문구가 붙어 있습니다. “당신의 경험은 Agent로 단련되기를 기다리고 있습니다.” “훌륭한 직원은 일을 끝냅니다. 훌륭한 Agent는 일을 계속 끝냅니다.” 저자는 15년 동안 QA 직함을 거의 모두 거쳤지만, 이 문구 앞에서는 아직 포장도 뜯지 않은 원재료처럼 느껴진다고 말합니다. 직원이 일을 하고 Agent가 그 일을 계속하게 된다면, 자신이 경험을 쌓아 Agent로 대체하는 구조처럼 보이기 때문입니다.

그럼에도 Agent와 model을 직접 만져보는 일 자체를 좋아하기 때문에 이 상황을 피하려 하지는 않습니다. 오히려 15년의 경험이 어떤 Agent로 만들어질지 직접 확인하고 싶어서 이 회사에 왔다고 말합니다. 다만 마지막 6개의 연재 글을 먼저 완성할 때까지는 기다려 달라고 농담합니다.

QA의 역할은 마지막 검증에 남습니다

Mark 이야기의 시간 설정을 30번 넘게 검토했지만, 같은 parameter가 한 곳에서는 1년 된 것으로, 다른 곳에서는 5년 된 것으로 묘사된 오류를 발견하지 못했습니다. 한 독자가 이를 지적하자 저자는 “당신이 제가 쓴 것보다 더 꼼꼼하게 읽었습니다”라고 답했습니다. 경험 많은 사람도 오류를 놓치기 때문에 새로운 시선이 필요하다는 사례입니다.

저자는 AI가 312개 사례를 실행해도 313번째 사례에는 사람이 필요하다고 말합니다. AI agent 분야에는 똑똑한 model이 부족한 것이 아니라, 결과가 계속 제대로 작동하는지 지켜보는 사람이 부족하다고 봅니다. 15년 동안 해온 QA 업무가 바로 그 역할이며, Agent를 다루는 회사에서도 업무의 본질은 달라지지 않았다고 설명합니다.

현재 36 Stratagems 중 30편을 끝냈고 마지막 6편은 새 업무에 적응할 때까지 잠시 미뤘습니다. 먼저 사업과 제품을 배우고 맡은 일을 출시한 뒤, 남은 글을 마무리하겠다는 계획입니다.

dev.to 반응

  • @merbayerp — 새 직장을 축하합니다. Mark 이야기를 읽고 나니, 벽에 정말 “당신의 경험은 Agent로 단련되기를 기다리고 있습니다”라고 적힌 회사에 들어간 것은 훌륭한 커리어 계획이거나 Stratagem #37의 시작처럼 보입니다. 문서를 잘 지켜보세요. 혹시 xulingfeng-final-v2.agent라는 파일을 발견하면 열지 마세요. 농담은 여기까지 하겠습니다. 이번 글에서 가장 중요한 부분을 짚었다고 생각합니다. 경험은 450ms라는 값이 아니라, 왜 450ms가 존재했는지, 어떤 가정이 그 값을 맞게 만들었는지, 그 가정이 언제 더는 사실이 아니게 됐는지를 아는 일입니다. 경험 많은 사람에게서 답을 추출하는 일은 점점 능숙해지고 있지만, 그 답을 둘러싼 경계 조건까지 추출하는 일은 훨씬 어렵습니다. 그리고 Agent로 단련되기 전에 마지막 6편을 끝내세요. 기다리는 사람이 있습니다. 다시 축하합니다. QA 경력과 AI 시스템을 망가뜨려 보는 집착이 제대로 작동할 만한 곳처럼 보입니다.
  • @sylwia-lask — 멋진 글입니다. 정말 그렇습니다. 스타트업에서 일하다가 대기업으로 옮기고 나니, 느린 속도를 appreciate하게 됐습니다.
  • @shubhradev — Mark 이야기 옆에 그런 벽 문구가 붙어 있다는 우연이 대단합니다. 새 직장과 마지막 6편 모두 잘 풀리기를 바랍니다.
  • @gramli — “제가 무엇을 하고 있는지 전혀 모르겠습니다”라는 문장이 오늘 저를 웃게 했습니다. 경력이 아무리 길어도 가끔은 모두 그렇게 느낍니다.

원문: dev.to / 번역·요약: Trawling