Katalon — 로우코드로 시작하는 통합 테스트 자동화

개념

코드로만 자동화해야 하는 건 아니다

모듈 20(레슨 1)의 Selenium도, 모듈 13의 Playwright도 출발점이 같다. 빈 파일을 열고 코드를 직접 쓰는 것이다. 그런데 현실의 QA 조직에는 "자동화는 해야 하는데 코드를 쓸 줄 아는 사람이 없다"는 상태가 흔하다.

Katalon 은 그 간극을 겨냥한 로우코드(low-code) 테스트 자동화 플랫폼이다. 내부적으로는 Selenium과 Appium을 감싸고 있지만, 사용자에게는 코드를 요구하지 않는 화면을 먼저 내민다.

핵심은 레코드&플레이 + 스크립트 모드의 하이브리드

Katalon을 다른 도구와 구분 짓는 특징은 두 가지 모드를 같은 테스트에 대해 동시에 제공한다는 점이다.

로그인 화면을 녹화하면 "이메일 입력 → 비밀번호 입력 → 버튼 클릭"이라는 단계 목록이 만들어지고, 같은 테스트를 스크립트 탭으로 전환하면 이런 Groovy 코드가 보인다.

WebUI.openBrowser('https://example.com/login')
WebUI.setText(findTestObject('Page_Login/input_email'), 'user@example.com')
WebUI.setText(findTestObject('Page_Login/input_password'), 'password123')
WebUI.click(findTestObject('Page_Login/button_submit'))
WebUI.verifyElementPresent(findTestObject('Page_Dashboard/text_welcome'), 10)

findTestObject(...)가 가리키는 것은 Object Repository 에 저장된 로케이터다. 화면 요소를 한 곳에서 이름으로 관리하는 이 구조는, 모듈 13(레슨 4)의 페이지 오브젝트 모델을 도구가 대신 강제해주는 것에 가깝다. 버튼의 id가 바뀌면 저장소의 항목 하나만 고치면 그 요소를 쓰는 모든 테스트가 함께 고쳐진다.

이 하이브리드가 주는 실질적 이점은 성장 경로가 끊기지 않는다는 것 이다. 녹화로 시작한 사람이 어느 날 "이 테스트는 데이터 10건을 돌려야 하는데"라는 벽을 만났을 때, 도구를 갈아엎지 않고 스크립트 탭을 열면 된다.

웹·API·모바일을 한 프로젝트에서

또 하나의 축은 범위다. 보통은 웹은 Playwright, API는 Postman, 모바일은 Appium처럼 도구를 따로 배우고 결과를 따로 모아야 한다. Katalon은 세 가지 테스트 타입을 하나의 프로젝트, 하나의 실행 리포트로 묶는다.

API 테스트 쪽은 모듈 12에서 배운 개념이 그대로 옮겨온다 — 요청 메서드와 헤더, 바디를 지정하고 상태 코드와 응답 본문을 검증한다. 달라지는 건 웹 테스트와 API 테스트를 한 시나리오 안에서 섞을 수 있다 는 점이다. 예를 들어 UI로 주문을 넣고, 곧바로 API를 호출해 주문 데이터가 서버에 제대로 저장됐는지 확인하는 흐름을 한 테스트로 쓸 수 있다.

자동화 피라미드는 그대로다

여기서 반드시 짚어야 할 것이 있다. 모듈 11(레슨 1)에서 배운 자동화 피라미드 — 단위 테스트가 가장 많고 E2E가 가장 적어야 한다는 원칙 — 는 도구가 쉬워졌다고 해서 달라지지 않는다.

오히려 로우코드 도구는 아이스크림 콘 안티패턴을 만들기 더 쉽다. 녹화가 쉬우니 E2E 테스트가 빠르게 불어나고, 몇 달 뒤에는 30분씩 걸리면서 간헐적으로 깨지는 스위트가 남는다. 테스트를 만드는 비용이 싸진 것이지, 유지하는 비용이 싸진 것은 아니다. 녹화한 E2E 테스트도 여전히 느리고, 화면이 바뀌면 여전히 깨진다.

어떤 팀에 맞는가

균형 있게 보면 이렇다. 로우코드는 시작 비용 을 극적으로 낮추고, 코드 기반은 규모가 커졌을 때의 통제력 에서 앞선다. 팀이 지금 어느 문제를 겪고 있는지가 선택을 결정한다.

실무에서 왜 필요한가

채용 공고의 "테스트 자동화 도구 경험"이 항상 코드 기반 도구를 뜻하지는 않는다. 특히 SI·금융·제조 같은 도메인에서는 Katalon처럼 GUI를 갖춘 상용 도구를 쓰는 조직이 많고, 그런 팀에 들어가면 첫날부터 이 화면을 쓰게 된다.

더 중요한 건 판단력이다. "우리도 자동화 하자"는 말이 나왔을 때, 팀의 코딩 역량과 도입 시급성을 근거로 도구를 제안할 수 있어야 한다. 개발 배경이 없는 QA 두 명뿐인 팀에 Playwright를 권했다가 6개월간 아무것도 못 만드는 상황은 실제로 자주 벌어진다. 반대로 이미 개발자가 테스트를 쓰고 있는 팀에 로우코드 도구를 얹으면 버전 관리와 코드 리뷰만 복잡해진다.

실습 과제

과제 1 — 두 모드로 같은 테스트 읽기 (10분)

모듈 20(레슨 1)의 Selenium 로그인 예시와 이 레슨의 Katalon Groovy 코드를 한 줄씩 짝지어 표로 정리한다. 그리고 Katalon 쪽에서 findTestObject가 Selenium의 find_element(By.ID, "email")과 무엇이 다른지 한 문장으로 적는다.

과제 2 — 도구 선택 제안하기 (10분)

다음 팀에 어떤 도구를 권할지, 근거를 두 가지 이상 들어 적는다.

직원 40명 규모의 이커머스 스타트업. QA 담당자 2명 모두 수동 테스트 경력만 있고 코딩 경험은 없다. 배포는 주 2회이며, 매번 결제 흐름을 손으로 확인하느라 반나절이 걸린다. 3개월 안에 회귀 테스트를 자동화하라는 요구를 받았다.

과제 3 — 유지보수 비용 예측하기 (5분)

녹화로 만든 E2E 테스트 50개를 6개월 운영한다고 가정하고, 그 사이에 발생할 유지보수 작업을 세 가지 이상 적는다. Object Repository가 그중 어느 작업을 얼마나 줄여주는지도 함께 적는다.

자가 체크리스트

• 레코드&플레이 모드와 스크립트 모드가 각각 무엇이고, 왜 둘을 함께 제공하는 것이 중요한지 설명할 수 있다
• Object Repository가 페이지 오브젝트 모델과 어떤 점에서 닮았는지 말할 수 있다
• 웹·API·모바일을 한 프로젝트에서 다루는 것의 구체적 이점을 예로 들 수 있다
• 로우코드 도구를 쓸 때도 자동화 피라미드 원칙이 그대로 적용되는 이유를 설명할 수 있다
• 팀 상황(코딩 역량, 시급성, 규모)에 따라 로우코드와 코드 기반 중 어느 쪽을 권할지 판단할 수 있다

흔한 실수

• 녹화한 스크립트를 손보지 않고 그대로 쌓는다. 녹화는 초안이다. 불필요한 클릭 단계, 좌표 기반 로케이터, 하드코딩된 값이 섞여 있으므로 한 번은 열어서 정리해야 한다.
• "코드를 안 써도 되니까 아무나 할 수 있다"고 생각한다. 로케이터가 왜 깨지는지, 대기가 왜 필요한지 같은 원리를 모르면 도구가 GUI든 아니든 똑같이 플래키한 테스트가 나온다.
• 만들기 쉬워서 E2E 테스트를 무한정 늘린다. 모듈 11(레슨 1)의 아이스크림 콘으로 직행하는 길이다. 만드는 비용과 유지하는 비용은 다르다.
• 라이선스·비용 구조를 확인하지 않고 도입한다. 무료 버전에서는 병렬 실행이나 CI 연동 같은 기능이 제한되는 경우가 있어, 스위트가 커진 뒤에야 비용 문제를 만나게 된다.
• 버전 관리 계획 없이 시작한다. 프로젝트 파일이 XML·바이너리에 가까워 일반 코드처럼 diff와 리뷰가 편하지 않다. 누가 무엇을 바꿨는지 추적할 방법을 처음에 정해두어야 한다.

참고 자료

• Katalon 공식 문서 — 설치, 첫 테스트 케이스 생성, 웹·API·모바일별 안내
• Katalon Studio — Record and Playback — 녹화 기능과 생성된 단계를 편집하는 방법
• Katalon — Object Repository — 테스트 오브젝트를 한 곳에서 관리하는 구조