QA 인프라 발표

이 편은 근거가 얇다는 것부터 말하고 시작해야 합니다. 31분짜리 발표인데 자막이 없어서 화면 슬라이드만으로 재구성했습니다. 발표자가 실제로 한 말, 부연 설명, 14분에 걸친 질의응답 답변이 전부 빠져 있습니다. 그 결손을 안고도 남는 게 하나 있었는데, 도구 이야기가 아니라 「무엇을 증거로 칠 것인가」의 이야기였습니다.

무엇을 말한 발표인가

출발이 좁은 정의에 대한 반박입니다. “QA는 테스트다” 라는 인식이 오히려 QA의 역할을 가둔다는 문제의식입니다. 검증의 본질은 “기획 의도대로 구현되었는가” 를 확인하는 것이지, 특정 도구를 보는 게 목적이 아니라고 합니다.

그리고 권한 이야기가 나옵니다. 데이터베이스나 빌드 도구 접근을 요청할 때마다 “QA가 그 정보에 왜 접근해요?” 라는 반문을 들었다고 합니다. 결론은 이렇습니다 — 권한은 주어지는 게 아니라, “이렇게 하면 더 빠르고 정확하고 완전하게 테스트할 수 있다”를 증명해야 얻어지는 것.

인프라를 도구 목록이 아니라 능력으로 정의합니다 — “개발 활동을 관찰·파악·가시화할 수 있게 하는 기반 작업 그 자체.” 그리고 핵심은 개별 도구가 아니라 그렇게 쌓인 것들의 누적이라고 못 박습니다.

돌아간다면 제일 먼저 만들 것으로 「버그 등록 인프라」를 꼽습니다. 이유가 정확합니다 — 테스트 주기(케이스 준비 → 수행 → 버그 등록 → 수정) 중 버그 등록이 외부와 닿는 유일한 접점인데, 숙련자도 로그·재현 스크린샷·중복 확인에 5~10분이 걸리고 귀찮으면 누락됩니다. 해법은 핫키 한 번에 영상·로그·스크린샷을 동시 수집하는 도구입니다.

마무리가 실행 가능합니다 — “돌아오는 월요일, 조회 권한 하나를 요청하세요.”

대표 기법 — 사례 하나가 발표 전체를 지탱한다

뽑기 확률 검증 사례입니다.

예전: 수백 판을 반복해서 뽑고 통계로 확률을 추정했습니다. 이건 “체감 확인” 입니다. 이후: 확률 데이터 원본을 쿼리 한 줄로 5초 만에 조회하게 되자, 검증 방식 자체가 바뀌었습니다.

이게 도구 이야기가 아니라는 게 요점입니다. 같은 질문(“확률이 맞는가”)에 대해 무엇을 증거로 칠 것인가가 바뀐 겁니다. 수백 판의 표본은 “아마 맞는 것 같다” 까지만 갑니다. 원본 조회는 맞거나 틀리거나입니다. 접근 권한 하나가 판정의 성격을 바꿉니다.

깨본 결과 — 결손을 먼저 센다

분석 가능한 것이 절반입니다. 31분 중 발표가 16분, 질의응답이 14분인데 질의응답은 질문 텍스트만 슬라이드에 남고 답변은 음성입니다. 그래서 청중이 무엇을 궁금해했는지는 알지만 발표자가 뭐라고 답했는지는 모릅니다.

질문 목록 자체는 읽을 만합니다 — “권한 필요성을 인정하지 않는 사람은 어떻게 대처하나”, “AI로 절약한 시간을 어디에 재배분하나”, “실무에서는 어떤 레이어부터 구축하나”. 전부 이 발표가 열어 놓고 답을 안 준 자리입니다. 답이 있었을 텐데 제 분석에는 없습니다.

그리고 수치가 하나도 없습니다. “5~10분”, “5초”, “수백 판” — 전부 슬라이드의 표현이고 어떻게 잰 값인지가 없습니다. 이 발표는 애초에 측정 보고가 아니라 경험 공유라서 그게 흠은 아닙니다. 다만 인용할 때 수치를 떼고 논지만 가져와야 합니다.

⚠ 결손을 메우려면 방법이 있습니다 — 음성 전사를 붙여 다시 분석하면 됩니다. 안 한 이유는 단순합니다. 이 발표에서 제가 얻을 것이 논지 하나로 이미 정해졌기 때문입니다. 답변 14분을 복원해도 그 판정이 바뀔 것 같지 않았습니다. ⚠ 이건 추정이고, 틀렸을 수 있습니다.

내 환경에 대봤다

버그 등록 인프라는 제가 이미 그 방향으로 가 있습니다. 자동화 런이 판정 시점에 증거를 스스로 남기게 해 뒀고, 이미지·영상은 재생성이 안 되니 따로 보관합니다. 발표가 말한 “핫키 한 번에 동시 수집” 과 문제의식이 같습니다 — 귀찮으면 누락된다는 것.

「인프라가 없으면 AI에게 줄 컨텍스트가 없다」도 제 경험과 맞습니다. 제가 만든 것들 중 실제로 값을 한 건 모델이 똑똑해서가 아니라 읽을 게 있어서 였습니다.

그런데 제일 크게 남은 건 뽑기 사례입니다. 저는 무엇을 증거로 칠 것인가를 따로 쓰고 있는데, 이 사례가 그 글의 제일 좋은 예시입니다. 같은 질문에 대해 추정으로 답하느냐 확정으로 답하느냐가 도구가 아니라 접근 권한에서 갈립니다.

판정

무엇	판정
증거의 성격이 권한에서 갈린다	채택 — 예시로. 판정을 다루는 글에 그대로 들어갈 사례다
버그 등록 시점 증거 동시 수집	이미 함. 문제의식이 같다
“인프라가 없으면 AI에 줄 컨텍스트가 없다”	동의. 다만 제 경험이 근거지 이 발표가 근거는 아니다
수치 인용	⛔ 금지. 전부 슬라이드 표현이고 산정 방법이 없다
재분석	보류. 답변 14분을 복원해도 판정이 바뀔 것 같지 않다 재개 조건: 권한 협상이나 레이어 구축 순서를 실제로 해야 할 일이 생길 때

이 편에서 값을 치른 교훈은 자료 쪽이 아니라 제 쪽입니다 — 결손이 있는 자료는 결손을 먼저 세고 읽어야 합니다. 31분 중 14분이 안 들어와 있는데 그걸 안 적고 요약만 쓰면, 나중에 이 페이지를 근거로 뭘 주장할 때 그 구멍이 안 보입니다.

그리고 ⚠ “재분석해도 판정이 안 바뀔 것 같다”는 제 추정입니다. 실제로 확인한 게 아닙니다. 여기 적어 두는 이유는, 나중에 이 판정이 틀렸다고 밝혀졌을 때 어디서 틀렸는지가 남아야 하기 때문입니다.