비유: 마이크로서비스 아키텍처는 마치 수천 개의 작은 가게들이 모여 있는 거대한 쇼핑몰과 같습니다. 각 가게 (서비스) 는 독립적으로 운영되고, 서로 HTTP 라는 '메시지'로만 소통합니다.
현실: 쇼핑몰을 운영하는 우리는 가게 내부 (소스 코드) 를 볼 수 없습니다. 오직 가게 문 앞에 붙은 **간판 (API 명세)**만 볼 수 있습니다.
문제: 기존 간판에는 "이 가게는 '신발'을 팝니다"라고 적혀 있을 뿐, "신발을 사려면 발 크기가 250mm 이상이어야 한다"거나 "신발을 사면 반드시 영수증이 발급되어야 한다"는 중요한 규칙이 적혀 있지 않습니다.
결과: 개발자들은 이 불완전한 지도를 보고 수동으로 가게를 방문해보며 "아, 여기는 신발을 안 팔네?"라고 실수할 때까지 확인해야 합니다. 이는 시간도 많이 걸리고, 실수가 발생하기 쉽습니다.
2. 해결책 1: APOSTL (새로운 '계약서' 언어)
이 논문은 기존 간판에 **추가적인 규칙 (계약)**을 적을 수 있는 새로운 언어인 APOSTL을 제안합니다.
비유: 기존 간판에 **"계약서 (Contract)"**를 붙이는 것입니다.
전제 조건 (Precondition): "이 가게에 들어오려면 (POST), 반드시 빈 자리 (404 에러) 가 있어야 합니다." (이미 있는 사람을 다시 등록하면 안 됨)
결과 조건 (Postcondition): "거래가 끝나면 (POST), 반드시 영수증 (200 OK) 과 똑같은 물건을 돌려받아야 합니다."
불변 조건 (Invariant): "쇼핑몰 전체를 보면, 어떤 가게든 정원이 초과되면 안 됩니다."
이 계약서를 통해, 테스트 도구는 "이 가게가 규칙을 지켰는지"를 자동으로 판단할 수 있게 됩니다.
3. 해결책 2: PETIT (완벽한 '검사관' 로봇)
이제 이 계약서를 바탕으로 작동하는 자동화 도구인 PETIT를 소개합니다.
비유: PETIT 는 쇼핑몰을 돌며 자동으로 테스트하는 로봇 검사관입니다.
작동 방식:
데이터 생성: 로봇은 가상의 고객 (테스트 데이터) 을 만들어냅니다. (예: "이름은 '홍길동', 나이 20 세인 고객")
요청: 로봇은 이 고객으로 각 가게에 방문하여 주문을 냅니다.
계약서 확인: 가게가 주문을 처리한 후, 로봇은 계약서 (APOSTL) 를 꺼내 확인합니다.
"규칙대로 200 OK 를 줬나?"
"보낸 물건과 받은 물건이 똑같은가?"
"쇼핑몰 전체 정원이 넘지 않았는가?"
특징: 이 로봇은 가게 내부 (코드) 를 보지 않아도, 오직 간판과 계약서만 보고도 "이 가게는 정상이다" 혹은 "이 가게는 고장났다"를 판단할 수 있습니다.
4. 실험 결과: "순서도 중요해!"
논문의 핵심 발견 중 하나는 테스트를 하는 순서가 매우 중요하다는 것입니다.
비유: 쇼핑몰을 검사할 때 순서가 중요합니다.
순서 A (생성 -> 수정 -> 조회): 먼저 새로운 가게를 열고 (생성), 그 다음에 물건을 고치고 (수정), 마지막으로 확인 (조회) 합니다. 이 순서라면 모든 테스트가 잘 통과합니다.
순서 B (수정 -> 생성 -> 조회): 아직 가게가 없는데 먼저 물건을 고치려고 하면? 당연히 실패합니다.
발견: PETIT 는 이 순서를 바꿔가며 테스트함으로써, "아, 이 가게는 가게를 만들기 전에 고치려고 하면 에러를 잘 처리하네?" 혹은 "아, 이 가게는 가게를 만든 후에도 고치지 못하네?"라는 숨겨진 버그를 찾아냅니다.
5. 결론: 왜 이것이 중요한가?
이 논문은 **"소프트웨어를 믿을 수 있게 만드는 자동화된 검사 시스템"**을 만들었습니다.
기존 방식: 사람이 일일이 가게를 방문해서 "음, 괜찮아 보이네?"라고 눈으로 확인 (수동 테스트).
이 논문의 방식: 로봇이 계약서를 들고 자동으로 모든 가게를 돌며, 규칙 위반 시 즉시 "여기 고장났어요!"라고 알려줍니다.
한 줄 요약:
"이 논문은 복잡한 소프트웨어 시스템을 **계약서 (APOSTL)**로 명확히 정의하고, 이를 바탕으로 **자동 검사관 (PETIT)**이 규칙 위반을 찾아내도록 하여, 소프트웨어의 품질을 자동으로 보증하는 방법을 제시합니다."
이 기술은 앞으로 더 복잡해지는 소프트웨어 세상에서, 인간이 놓칠 수 있는 실수를 로봇이 대신 찾아내어 더 안전하고 신뢰할 수 있는 서비스를 만드는 데 기여할 것입니다.
1. 문제 정의 (Problem)
블랙박스 테스트의 어려움: 마이크로서비스는 독립적으로 배포되며 클라이언트에게 소스 코드가 숨겨져 있어 블랙박스 시스템으로 간주됩니다. 이를 테스트하려면 소스 코드 접근 없이 API 명세만 의존해야 합니다.
기존 명세 언어의 한계: 현재 널리 사용되는 OpenAPI Specification (OAS) 은 데이터 타입, HTTP 메서드, 응답 코드 등 구조적 정보만 제공합니다. 하지만 테스트를 수행하기 위해 필요한 **시스템의 상태 (State), 불변식 (Invariants), 전조건 (Preconditions), 후조건 (Postconditions)**과 같은 논리적 속성을 정의할 수 있는 표현력이 부족합니다.
수동 테스트의 비효율성: 현업에서는 수동으로 요청을 생성하고 응답을 확인하는 방식이 주를 이루며, 이는 신뢰할 수 없고 확장성이 떨어집니다.
2. 제안된 방법론 (Methodology)
이 연구는 API 명세 문서만으로도 마이크로서비스를 완전히 자동화하여 테스트할 수 있는 두 가지 핵심 요소를 개발했습니다.
A. APOSTL (API PrOperty SpecificaTion Language)
목적: 기존 OpenAPI Specification 을 확장하여 테스트에 유용한 논리적 속성을 추가하는 명세 언어입니다.
기반: 1 차 논리 (First-order logic) 를 기반으로 하며, RESTful API 의 순수 연산 (Side-effect 가 없는 GET 연산) 을 사용하여 조건을 기술합니다.
주요 기능:
확장 속성: OAS 의 x- 접두사를 사용하여 x-requires(전조건), x-ensures(후조건), x-invariants(불변식), x-regex(데이터 생성 정규식) 를 정의합니다.
계약 (Contract) 정의: 특정 연산이 수행되기 전과 후의 시스템 상태, 그리고 요청/응답 데이터 간의 관계를 논리식으로 명시합니다.
데이터 생성: 정규식 (x-regex) 을 통해 유효한 테스트 데이터를 자동으로 생성할 수 있도록 지원합니다.
B. PETIT (aPi tEsTIng Tool)
목적: APOSTL 로 주석이 달린 OpenAPI 명세 파일을 입력받아 마이크로서비스를 자동으로 테스트하는 도구입니다.
아키텍처:
Specification Parser: OAS 파일을 파싱하여 자바 객체로 변환합니다.
Input Generator: 스키마와 정규식을 기반으로 유효한 테스트 데이터 (JSON) 를 생성하거나 기존 데이터 풀 (Pool) 에서 재사용합니다.
Formula Parser (ANTLR 기반): APOSTL 수식이 문법 규칙을 따르는지 검증하고 파싱 트리를 생성합니다.
HTTP Manager: 실제 마이크로서비스에 HTTP 요청을 전송하고 응답을 수신합니다.
Tester & Evaluator: 생성된 데이터로 요청을 수행하고, 전조건/불변식/후조건을 검증하여 테스트 결과를 판별합니다.
사용자 정의 가능한 순서 전략 (예: CMO, MCO 등) 을 통해 연산 실행 순서를 제어하여 다양한 시나리오를 테스트합니다.
테스트 종료 후 데이터베이스를 원래 상태로 되돌리는 (Rollback) 기능을 포함합니다.
3. 주요 기여 (Key Contributions)
APOSTL 명세 언어 개발: API 명세에 논리적 계약 (계약 기반 설계, Design by Contract) 을 추가하여 블랙박스 테스트가 가능한 형태로 변환하는 언어를 제안했습니다.
PETIT 테스트 도구 구현: 명세 기반 테스트 (Specification-Based Testing) 알고리즘을 구현하여, 소스 코드 없이도 의미 있고 중복되지 않는 테스트 데이터를 생성하고 테스트를 수행하는 도구를 만들었습니다.
자동화된 테스트 프로세스: 마이크로서비스의 구현 오류를 자동으로 탐지하고, 테스트 순서 전략이 오류 탐지율에 미치는 영향을 분석했습니다.
4. 평가 및 결과 (Evaluation & Results)
연구진은 "Tournaments Application"이라는 사례 연구를 통해 PETIT 를 평가했습니다.
정확한 구현체 테스트:
올바른 구현체에서도 테스트 순서 전략 (Order Strategy) 에 따라 일부 연산이 "실패 (예상됨)" 또는 "불확실 (Inconclusive)"로 판정될 수 있음을 발견했습니다. 이는 특정 리소스가 생성되기 전에 관찰 연산이 수행되거나, 리소스가 삭제된 후 접근 시도 등이 발생하기 때문입니다.
이를 통해 단일 실행만으로는 모든 테스트 커버리지를 보장할 수 없으며, 다양한 순서 전략을 적용하여 실행 트레인을 분석해야 함을 강조했습니다.
결함 있는 구현체 테스트 (Faulty Scenario):
의도적으로 6 가지 오류 (예: 잘못된 삭제, 데이터 미저장, 업데이트 실패 등) 를 주입한 구현체를 테스트했습니다.
결과: 적절한 순서 전략을 선택했을 때 PETIT 는 모든 주입된 오류를 성공적으로 탐지했습니다.
오류 탐지 패턴: 변경자 (Mutators) 연산의 오류는 주로 생성자 (Constructors) 가 먼저 실행되어 유효한 데이터가 존재할 때 탐지되었습니다. 반대로 생성자가 먼저 실행되지 않으면 오류를 탐지하지 못하는 경우가 있었습니다. 이는 테스트 순서 전략의 중요성을 보여줍니다.
5. 의의 및 결론 (Significance & Conclusion)
산업적 필요성 충족: 마이크로서비스 아키텍처로 전환하는 산업계에서 신뢰할 수 있는 자동화된 블랙박스 테스트 솔루션의 부재를 해결합니다.
소스 코드 불필요: 개발팀이 아닌 외부 팀이나 QA 팀이 소스 코드 접근 없이도 API 명세만으로 철저한 테스트를 수행할 수 있게 합니다.
계약 기반 설계의 실용화: 논리적 명세 (APOSTL) 를 통해 API 의 의도된 동작을 명확히 하고, 이를 기반으로 자동화된 검증이 가능하게 하여 소프트웨어의 신뢰성을 높입니다.
향후 과제: 현재 APOSTL 은 중첩된 양화사 (Nested Quantifiers) 등을 지원하지 않아 표현력이 제한적입니다. 향후 문법을 확장하고, RAML 등 다른 API 명세 언어와의 호환성을 높이며, PETIT 가 단일 실행 내에서 연산을 반복 수행할 수 있도록 개선할 필요가 있습니다.
결론적으로, 이 논문은 API 명세에 논리적 속성을 추가하고 이를 자동화 도구로 연결함으로써 마이크로서비스의 블랙박스 테스트를 혁신적으로 개선할 수 있음을 입증했습니다.