Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
JaSST Niigata 발표회 요약은 AI가 작업을 담당하는 시대에 소프트웨어 품질 확보를 위한 인간의 역할을 논합니다. 탐색적 테스트와 API 테스트 사례를 통해, AI가 속도를 높여주더라도 사람이 놓치기 쉬운 가치나 예외적인 리스크를 찾아내는 것이 중요함을 강조했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이 글을 읽기 전에:
LT 대회에서는 질의응답 시간이 없어 발표자에게 확인하지 못한 부분이 있습니다.
각 LT의 '내용'은 영상 시청 메모를 바탕으로 요약되었으며, '고찰', '보충'에는 저의 추측이나 해석이 포함되어 있습니다.
추측 부분임을 명시했지만, 청취 오류 등이 있다면 지적해 주시면 감사하겠습니다.
정확한 내용은 마지막 참고 자료에 있는 각 발표 자료를 봐주시기 바랍니다m(_ _)m
JaSST Niigata에서 개최된 LT 대회 6가지 내용을 'AI가 작업을 하는 시대, 인간은 무엇을 해야 할까'라는 시각으로 세 가지 축으로 정리하여 요약했습니다!
JaSST(Japan Symposium on Software Testing)는 2003년부터 개최되어 온 소프트웨어 테스트 심포지엄입니다. 이번 JaSST Niigata의 주제는 '사고의 순도를 높여 품질의 벽을 돌파하는 것'이었으며, LT 대회 모든 발표가 이 주제와 연결되어 있었습니다.
저는 이번에 온라인으로 참여했습니다!
AI에게 맡겨두기만 하면 큰 역효과가 날 수 있다는 것은 많은 엔지니어가 알고 있다고 생각합니다.
하지만 '그럼 인간은 구체적으로 무엇을 해야 하는가?'라고 질문하면 의외로 말로 표현하기 어려운 것입니다.
그래서 6가지 LT를 저 나름대로 다음 세 가지 축으로 정리했습니다.
| 축 | 한마디로 | LT |
|---|---|---|
| 생각하기 | AI에게만 맡기지 않고, 스스로 생각하기 | Explore It!／API 테스트를 AI 스킬로 하자／니이가타의 어려움. |
| ... | ||
| 개인의 사고에서, 이를 지탱하는 메커니즘, 그리고 조직으로 시점이 확장되는 순서로 소개합니다. |
참고로 이 세 가지 축은 저 나름대로 정리한 것이며 LT 대회에서 이렇게 분류된 것은 아닙니다!
세 발표에 공통적이었던 이야기는 AI가 작업을 담당하는 시대이기에 오히려 무엇을 볼지, 무엇을 중요하게 생각할지를 인간이 고민해야 한다는 내용이었습니다.
발표자: 준페 씨 (자료)
내용(요약)
인간은 집중하고 있을 때 중요한 것을 놓치기 쉬우며, 이는 버그를 간과하는 것과 유사하다 - 작업은 AI의 영역이 되어가고 있으며, 인간에게는 '아직 아무도 발견하지 못한 가치나 리스크를 찾는 탐색'이 그 어느 때보다 요구된다
저의 감상
버그라는 것은 하나의 기능에 너무 집중하면 다른 버그를 놓치고, 집중하지 않아도 놓칠 수 있으며, 적절한 상태로 만드는 것이 꽤 어렵다고 생각합니다.
그런 의미에서 AI가 어느 정도 버그 찾기를 도와주면서, 인간은 자신이 궁금한 부분을 납득할 때까지 탐색적으로 테스트하는 역할 분담이 가능한 것은 새롭게 좋은 시대가 되었다고 다시 한번 느꼈습니다!
발표자: 스즈키 쇼고 씨 (자료)
내용(요약)
저의 감상
AI가 아니라 테스트 경험이 있는 인간이 직접 테스트했다면 발견했을 수도 있는 문제라고 느꼈고, 동시에 AI에 테스트를 맡기는 것은 편리해지는 반면 암묵지를 언어화해야 한다는 것을 느꼈습니다.
실제 실패를 바탕으로 한 대응책에 대한 LT였기 때문에 매우 설득력이 있었습니다!
발표자: Mark Ward 씨 (자료 공개 없음)
내용(요약)
저의 감상
Mark 씨는 자신의 근황을 '논리 무직이면서 외로운 무직'이라고 표현했는데, 정말 재치 있게 말씀하셨다고 생각했습니다🤗
슬라이드 한 장으로 LT에 도전하는 등 개그를 섞은 토크로 매우 듣기 편했습니다!
AI와 협업하면서도 사람의 역량(People Quality)은 의식하고 싶습니다.
AI는 방대한 결과물을 짧은 시간에 만들어주지만, 동시에 사람이 모든 것을 검토하기 어려워집니다.
그래서 AI가 생성한 출력을 시스템이나 수치로 확인하는 LT가 두 편 있었습니다.
발표자: Ejiri Yoshio 씨 (자료)
내용(요약)
결론은 'AI 구동 개발(AI-driven development)을 통해 테스트의 추적성(Traceability) 중요성이 커졌다'입니다.
추적성이란, 요구사항·테스트·테스트 실행 결과 간의 관계를 거슬러 올라갈 수 있는 상태를 의미하며, 이것이 있으면 테스트가 없는 요구사항이나 사양 변경으로 영향을 받는 테스트를 파악할 수 있다고 합니다.
ID가 연결되는 흐름은 다음과 같습니다.
보충: 저의 이해
추적성은 슈퍼마켓 채소의 산지 표시로 비유하니 이해하기 쉬웠습니다!
산지 스티커가 있으면, 어느 밭에서 문제가 발견되었을 때 그 밭의 채소를 즉시 찾아낼 수 있습니다.
이 LT의 시스템은 AI가 테스트를 만들 때부터 처음부터 산지 스티커(ID)를 붙여주는 이미지입니다🍆
| 채소의 산지 표시 | 이 LT의 시스템 |
|---|---|
| 밭 | 사양서 (요구사항) |
| ... | |
| 또한, 부족한 테스트를 찾아내는 것은 HTML이나 CI 그 자체가 아니라 ID를 대조하는 것이라고 이해했습니다. |
HTML은 결과 보여주는 방식(View), CI는 실행 시점을 담당하며, 테스트가 추가되거나 변경될 때마다 리포트가 자동으로 최신화됩니다.
찾아내는 것은 자동화하고, 어떤 테스트를 추가할지 판단하는 것은 사람이라는 분담이라고 추측합니다!
발표자: Komatsuna 씨 (자료)
내용(요약)
하나의 툴을 여러 멤버가 사용하게 되면서 결과물의 품질이나 UI/UX에 대한 피드백이 증가했다고 합니다.
그럴 때마다 프롬프트를 수정하고, 결과물을 만들고 비교하며 다르면 다시 검토하는 루프가 비효율적이었기 때문에, 지표를 정해서 AI로 검증하고 수치로 비교하기로 했습니다.
지표는 실제로 받은 피드백을 그대로 수치화한 것입니다.
| 받은 피드백 | 수치화된 지표 | 측정 방식 |
|---|---|
| 용어가 바뀌어 이해하기 어려움 | 사양과의 용어 일치율 | 생성 결과가 사양서와 같은 용어를 사용했는지 문자열 매칭으로 계산 |
| ... |
같은 사양서·같은 모델로 4가지 프롬프트 후보를 비교한 결과는 다음과 같습니다.
| 프롬프트 | 관점 수 | 용어 일치율 | 추적 가능 섹션 수 | 테스트 케이스 총 개수 |
|---|---|---|---|---|
| 구 프로ンプ트 | 7 | 44% | 0/20 | 76 |
| ... | ||||
| 안 A와 안 B는 '관점 수를 기존 프롬프트와 동일한 7개로 맞춰달라'는 요청에 응하여 추가로 만든 패턴이라고 합니다! |
피드백을 준 사람에게 아무것도 전달하지 않고 4가지 결과물을 주고 골라보게 했을 때, 수치적으로 종합 점수가 가장 좋았던 '세분화 가드(粒度ガード)'가 선택되었고, 이는 수치적 판단과 인간의 판단이 일치했음을 보여주었습니다.
용어 일치율이 가장 높았던 안 B는 추적 가능 섹션 수가 낮았으며, 원인을 확인해보니 다음 관점들이 통째로 사라져 있었습니다:
4건을 일일이 비교하지 않아도 수치만으로 이상 징후를 감지할 수 있었으며, 비교나 퇴행(regression)의 검출 역시 수치로 보는 것이 더 빠르다는 것을 알게 되었습니다.
제 소감
단 하나의 지표만으로는 판단을 오해할 수 있다는 점을 구체적으로 알 수 있었던 LT였습니다!
특히 흥미로웠던 부분은 수치와 인간의 판단이 일치했다는 지점이었는데, 인간의 판단에 수치적 근거가 부여되면서 테스트 설계 개선에 자신감을 가질 수 있는 시스템이 되어 있어 매우 좋았습니다🙆
각 안(세분화 가드, 관점 수 앵커, 섹션 묶기)에 대한 구체적인 내용에 대해서는 설명이 없었기 때문에 (아마도 시간상의 제약 때문이었겠지만) 그 부분에 대해서도 듣고 싶다는 생각이 들었습니다!
여기까지는 개인이나 팀의 이야기였지만, 마지막은 AI를 조직에 어떻게 뿌리내릴 것인가에 대한 이야기였습니다.
발표자: 야마다 료타 씨 (자료 공개 없음)
내용 (요약)
AI 에이전트를 배포한 후 누가 어디서 사용하고 있는지, 또는 어느 곳에서 이용이 멈추고 있는지를 파악하여 다음 지원으로 연결하기 위해 사내 설문조사를 실시했습니다.
설문조사로 알 수 있는 것은 이용 실태와 저해 요인까지이며, 생산성이나 품질 등 성과에 대한 효과는 이 설문조사만으로는 측정할 수 없습니다.
같은 팀 내에서도 사람에 따라 이용의 온도 차이가 크다는 것을 알게 되었고, 사용에 익숙한 사람이 수치를 끌어올려 팀 전체가 잘 활용하고 있는 것처럼 보일 수도 있습니다.
고도화된 사용으로 나아가기 어려운 배경으로는 다음과 같은 의견들이 있었습니다:
다음 단계의 벽은 '사용 불가'가 아니라 '곤란하지 않음'입니다.
가치는 겪고 있는 어려움(pain point)과 연결되어 전달되므로, 타 팀의 실천 사례에서 우리들의 곤란함에 효과적인 유스케이스를 찾아 공유하는 것이 다음 단계의 방법이라고 생각했습니다.
제 소감
다음 벽이 '곤란하지 않음'이라는 점은 정말 신선한 충격이었습니다!
'사용 방법을 모른다'라면 대책을 세울 수 있지만, 'AI가 없어도 문제없거나 현재로서는 곤란하지 않다'는 상황에 대해서는 접근 방식 자체가 어려워집니다.
불편한 것을 불편하다고 인식하지 못하는 경우도 있을 것이라 생각하기 때문에, 겪고 있는 어려움에 효과적인 유스케이스를 공유하는 것은 합리적인 접근법이라고 생각했습니다🐟
이번 LT 6개 중 저에게 가장 와닿았던 것은 테스트의 추적성(traceability) LT였습니다!
솔직히 처음에는 '추적성'이라는 단어의 의미조차 잘 모르고 듣고 있었습니다...
그럼에도 불구하고, AI가 테스트를 만들도록 하면서 사람에게 이해하기 쉬운 표시(ID)를 확실하게 남기고, 인간이 병목 지점이 되기 어려운 시스템을 구축하고 있다는 점이 매우 좋다고 느꼈습니다🙆
저희 팀은 앞으로 테스트 문화를 만들어나가는 단계입니다.
그렇기에 처음부터 이런 표시를 남기는 사고방식을 도입하고 싶다고 생각합니다.
우선은 꾸준히, 테스트 케이스에 대응하는 요구사항의 번호를 붙이는 것부터 시작할 계획입니다(｀・ω・´)ゞ
LT를 통해 AI가 작업을 해주는 시대에 사람이 해야 할 일은 다음 3가지라고 이해했습니다.
모두 'AI에게 작업을 맡긴 후 사람이 무엇을 담당할 것인가'라는 이야기였습니다.
AI 등장으로 QA 업무의 중심축은 '생각하는 것' 쪽으로 크게 이동했다고 느꼈습니다 (QA뿐만이 아니지만).
이 LT 대회뿐만 아니라, JaSST Niigata에서는 '어떤 것을 생각하고 실행해야 하는지'에 대한 힌트를 많이 얻을 수 있었습니다!
| 제목 | 발표자 | 자료 |
|---|---|---|
| Explore It! AI 시대에 효과적인 '탐색' 기술을 5분 동안 소개합니다. | 준페 씨 | Speaker Deck |
| 엔지니어의 AI 활용 실태와 장벽을 조사해 봤습니다. | 야마다 료타 씨 | 자료 공개 없음 |