Can LLMs Test Terminal User Interfaces?

당신이 비디오 게임 개발자라고 상상해 보세요. 산, 도시, 캐릭터가 있는 아름답고 복잡한 세계를 구축했지만, 문이 실제로 열리는지 또는 플레이어가 벽에 끼이는지 테스트하는 것을 깜빡했습니다. 소프트웨어의 세계에서 이것은 악몽입니다. 이를 방지하기 위해 프로그래머들은 "자동화 테스터(automated testers)"를 사용합니다. 이들은 버튼을 클릭하고, 명령어를 입력하며, 실제 사용자가 발견하기 전에 버그를 찾아내기 위해 소프트웨어를 망가뜨리려고 시도하는 로봇 조수들입니다.

오랫동안 우리는 두 가지 주요 유형의 소프트웨어를 테스트해 왔습니다. 첫째, 스마트폰이나 컴퓨터의 앱과 같은 **그래픽 사용자 인터페이스(GUI)**가 있습니다. 이것은 라벨이 붙은 문, 창문, 버튼이 있는 화려하고 색채감 넘치는 방과 같습니다. 테스터는 컴퓨터에게 " '시작' 버튼이 어디 있지?"라고 묻고 클릭하기 쉽습니다. 둘째, **명령줄 인터페이스(CLI)**가 있습니다. 이것은 옛날 방식의 전보와 같습니다. 비밀 코드를 입력하면 컴퓨터가 텍스트로 응답합니다. 이것은 단순하기 때문에 테스트하기 쉽습니다: 이것을 입력하면 저것이 나옵니다.

하지만 **터미널 사용자 인터페이스(TUI)**라는 세 번째의 은밀한 유형의 소프트웨어가 있습니다. 이것을 "레트로 퓨처리즘(retro-futuristic)" 앱이라고 생각하세요. 이들은 옛날 전보(검은 화면에 텍스트만 있는 형태)처럼 보이지만, 화려한 방처럼 작동합니다. 움직이는 커서, 팝업 메뉴, 그리고 타이핑함에 따라 변하는 복잡한 상태를 가지고 있습니다. 이들은 해커, 시스템 관리자, 심지어 AI 코딩 어시스턴트들에게 인기가 있습니다. 문제는 우리가 이것들을 제대로 테스트하는 방법을 잘 모른다는 것입니다. 이들은 단순한 전보 테스터에게는 너무 복잡하지만, 화려한 방 테스터들이 필요로 하는 "라벨이 붙은 버튼"은 갖추고 있지 않습니다. 이 논문은 큰 질문을 던집니다. 현대의 인공지능(AI) 로봇이 이 까다로운 텍text 기반 앱들을 테스트하는 법을 배울 수 있을까요, 아니면 그들도 우리만큼 혼란스러워할까요?

---

위대한 TUI 탐정 이야기

이 논문의 연구진은 탐정 놀이를 하기로 했습니다. 그들은 197개의 실제 TUI 애플리케이션(파일 관리자부터 시스템 모니터까지 모든 것)을 대량으로 수집하여 엄격한 스트레스 테스트를 거치게 했습니다. 하지만 그전에 먼저 하나의 미스터리를 풀어야 했습니다. 현재 이 앱들이 얼마나 잘 테스트되고 있는가?

그들은 이 197개 앱의 코드 내부를 들여다보았고, 충격적인 비밀을 발견했습니다. 테스트 코드 중 단 **12%**만이 실제로 화면과 상호작용하려고 시도했습니다. 훨씬 더 심각한 것은, 화면에 손을 댄 테스트 중 거의 절반이 단 하나의 키도 입력하지 않았다는 점입니다! 그들은 단지 앱이 처음 열렸을 때 화면이 제대로 보이는지만 확인했을 뿐입니다. 마치 자동차의 엔진을 한 번도 켜보지 않고 자동차의 도색 상태만 체크하는 것과 같습니다. 결국, 대부분의 TUI는 눈을 감은 채 테스트되고 있었습니다.

그래서 팀은 AI와 무작위 확률을 이 앱들에 풀어놓았을 때 어떤 일이 일어날지 보기 위해 자체적인 도구를 만들었습니다. 그들은 "헤드리스(headless)" 실험실(화면 없이 가상 터미널만 있는 컴퓨터)을 구축하고 각 앱을 특수한 컨테이너에 담았습니다. 그런 다음 네 가지 전략 간의 경주를 설정했습니다:

1. 무작위 원숭이(The Random Monkey): 최대한 빠르게 무작위 키를 마구 입력하는 로봇.
2. AI 가이드(The AI Guide): 화면을 보고 다음에 무엇을 타이핑할지 결정하는 똑똑한 대규모 언어 모델(LLM).
3. 지도를 가진 AI 가이드(The AI Guide with a Map): 똑똑한 로봇이지만, 이번에는 앱을 제대로 시작하기 위한 올바른 "실행 코드(arguments)"까지 파악한 상태.
4. AI 시나리오 작가(The AI Scriptwriter): 소스 코드를 읽고 시작하기 전에 테스트 계획을 작성하는 로봇.

그들은 이 전략들을 197개의 앱에 실행했으며, 각 앱에 정확히 600초(10분)의 시간을 주어 버그를 찾게 했습니다.

결과: 누가 승리하는가?

결과는 놀랍고 다소 직관에 반하는 것이었습니다.

1. "똑똑한" 로봇이 가장 빠른 것은 아니다.
연구진이 각 전략이 실행당 발견한 버그 수를 조사했을 때, 무작위 원숭이가 실제로 가장 많은 크래시(crash)를 발견했습니다. 왜일까요? 그것은 믿을 수 없을 정도로 빨랐기 때문입니다. 600초 동안 무작위 로봇은 수백 개의 키를 입력할 수 있었습니다. AI 로봇들은 "생각"하고 답변을 기다리느라 시간을 보내는 "똑똑한" 존재들이었기에, 같은 시간 동안 고작 십여 개의 키만 입력할 수 있었습니다.

2. 하지만 "똑만한" 로봇은 훨씬 더 효율적이다.
여기 반전이 있습니다. 만약 키 입력당 성능을 측정한다면, AI 로봇들은 무작위 원숭이보다 13배 더 뛰어났습니다. 무작위 원숭이는 그저 어둠 속에서 다트를 던져 운 좋게 몇 번 맞히는 수준이었지만, AI 로봇들은 정교하게 조준했습니다. AI 로봇들은 "입력 게이트형(input-gated)" 버그—즉, 숨겨진 메뉴를 열기 위해 특정 키 순서를 입력해야만 발생하는 크래시—를 찾아내는 데 독보적이었습니다. 무작위 원숭이는 코드를 절대 알아내지 못했지만, AI는 해냈습니다.

3. "실행 코드"가 진정한 영웅이었다.
가장 큰 돌파구는 AI의 지능이 아니라, 앱을 시작하는 법을 알아내는 능력이었습니다. 많은 TUI는 인터페이스를 제대로 열기 위해 특정 파일이나 인자(arguments)가 필요합니다. 이것들이 없으면 앱은 즉시 종료됩니다. AI를 사용하여 실행 입력을 자동으로 도출하는 전략이 가장 많은 버그를 발견했고 가장 많은 코드를 커버했습니다. 결국, 자동차의 열쇠를 돌리는 법을 모르면 차를 테스트할 수 없는 법입니다.

4. "크래시(Crash)"의 함정.
연구진은 우리가 보통 버그를 세는 방식에서 발생하는 주요 함정도 발견했습니다. 그들은 "크래시"(프로그램이 예기치 않게 멈춤)의 **82%**가 사실은 프로그램이 "이봐, 파일이 필요해!"라거나 "중단하라는 명령을 받았어!"라고 말하는 것에 불과하다는 것을 발견했습니다. 이것들은 진짜 버그가 아니라 정상적인 동작입니다. 단순히 프로그램이 멈출 때마다 카운트하면 잘못된 경보가 울립니다. 팀은 실제 에러인지 아니면 정중한 종료인지 확인하기 위해 화면의 실제 텍스트를 살피는 특별한 "크래시 탐지기"를 구축해야 했습니다. 노이즈를 걸러낸 후, 그들은 197개 앱에서 179개의 실제 유효한 버그를 찾아냈습니다.

5. 코드 커버리지 $\neq$ 더 많은 버그.
소프트웨어 테스트에서 사람들은 보통 더 많은 코드 라인을 커버하면 더 많은 버그를 찾을 것이라고 믿습니다. 이 논문은 TUI의 경우 이것이 사실이 아님을 시사합니다. 그들은 가장 많은 크래시를 발견한 테스트가 종종 더 낮은 코드 커버리지를 가졌음을 발견했습니다. 왜일까요? 크래시를 발견하면 테스트가 즉시 중단되기 때문입니다! 테스트가 중간에 끊기므로 나머지 코드를 커버할 수 없습니다. 이는 TUI의 경우, 얼마나 많은 코드 라인이 닿았는지를 세는 것이 테스트의 품질을 측정하는 나쁜 방법임을 의미합니다.

결론

이 논문은 텍스트 기반 인터페이스에 대한 자동화된 테스트가 가능하지만, 아직 해결된 것은 아니라고 결론짓습니다. 어떤 단일 AI 모델도 압도적인 승자가 되지 못했습니다. 사실, 단순한 무작위 테스터가 더 빨랐기 때문에 경쟁력이 있었습니다. 성공의 핵심은 하이브리드 전략이었습니다. 즉, AI를 사용하여 앱을 시작하고 올바른 상태로 이동하며, 그 후 고속 무작위 테스팅을 사용하여 인터페이스를 극한까지 몰아붙이는 것입니다.

저자들은 또한 더 나은 도구가 필요하다고 경고합니다. 현재의 테스트 방식(단순히 프로그램이 멈추는지 확인하는 것)은 가짜 알람이 너무 많습니다. 그들은 다른 사람들이 이러한 앱을 제대로 테스트할 수 있도록 자신들의 도구인 tuicov와 tuibot을 공개했습니다. 메시지는 명확합니다. TUI는 소프트웨어 세계의 거대하고 성장하는 부분이지만, 현재 테스트의 "무법지대"와 같습니다. 우리는 이들을 길들이기 시작할 도구를 가지고 있지만, 오래된 규칙에 의존하는 것을 멈추고 이 독특한 텍스트 기반 인터페이스의 특성을 이해하는 테스트를 설계해야 합니다.