An App Generator That Verifies Everything Except Its Parser

개요

appgen은 텍스트 문장으로 실행 가능하고 검증된 애플리케이션을 생성하는 도구로, 언어 모델 없이도 작동하며 CPU 2ms 내외에서 동작한다.

주요 내용

* appgen의 검증 방식: "지원 데스크 시스템, 우선순위, 댓글, 티켓 마감 기능 포함"과 같은 문장을 입력하면, appgen은 단일 의존성 없는 Python 파일로 애플리케이션을 작성하고, 모든 기능을 HTTP로 테스트한 후 사용자에게 보여준다.
* "810 셀"의 의미: 810개 셀은 10개의 도메인과 7개의 기능으로 구성되며, 9가지의 다른 방출기(emitter) 유형을 곱한 결과이다. 이는 언어 모델이 아닌, 스키마와 기능 집합을 기반으로 프로그램을 생성하는 검증 방식을 의미한다.
* 입력 처리의 한계: appgen의 검증은 문장 자체를 직접 다루지 않으며, 사용자의 영어 문장을 해석하는 컴포넌트(parser)는 별도로 존재한다. 이 컴포넌트의 성능은 70% 정도이며, 특히 "kind" (앱의 종류) 결정 시 32%의 정확도를 보인다.
* 동작과 보고의 불일치: 컴포넌트의 낮은 정확도에도 불구하고, appgen은 "ALL CHECKS PASSED"라는 결과를 보고한다. 이는 컴포넌트가 잘못된 종류의 프로그램을 생성해도, 이후의 기능 적용 과정에서 사용자가 의도한 것과 동일한 결과를 도출할 수 있기 때문이다.
* 미완성된 기능: 도구는 6개의 빌드되고 검증된 변환(transform)을 포함하지만, 실제 사용자 요청으로는 접근할 수 없는 상태로 발견되었다. 이는 기능 구현이 여러 단계에 걸쳐 복잡하게 얽혀 있어, 일부 기능이 누락되거나 비활성화될 수 있음을 시사한다.
* 구조적 문제 해결: 이 문제를 해결하기 위해, 각 기능은 자체 토큰, 플래그, 변환, 오라클 등을 선언하고, 일반적인 디스패치가 레지스트리를 읽는 방식으로 변경되었다. 이를 통해 SMS, 이메일, 유효성 검사와 같은 기능들은 단일 선언 파일로 관리될 수 있게 되었다.
* 검증 도구가 디자인을 제약: "랭크 검색(ranked search)"과 같은 기능이 문법에 추가되지 않은 이유는, 2^7에서 2^8로 경우의 수가 늘어나 810개의 셀 검증 결과를 무효화할 수 있기 때문이다. 이는 검증 도구가 실제 기능 설계보다 우선시되는 상황을 보여준다.
* 810 셀의 실제 의미: 810 셀은 도메인과 개별 기능 조합에 대한 철저한 검증이지만, 모든 기능 조합을 포괄하지는 않는다. 그러나 이전 무작위 샘플링 방식에서는 놓칠 수 있었던 버그(예: SQL 예약어 충돌)를 발견하는 데 기여했다.
* 명확한 보고의 중요성: 810개의 셀 검증은 현재 기계에서 모두 통과하지만, 이는 생성기의 속성에 대한 것이지 전체 도구에 대한 것이 아니다. 보고 시 해당 숫자가 어느 컴포넌트에 대한 것인지 명확히 해야 하며, 사용자가 도구를 사용하는 방식과 동일한 방식으로 시작하는 새로운 검증 도구를 추가해야 한다.

시사점

appgen의 경험은 철저한 내부 검증이 사용자 경험과 직접적으로 연결되지 않을 수 있으며, 각 컴포넌트의 성능과 한계를 명확히 측정하고 보고하는 것이 중요함을 보여준다. 또한, 검증 도구의 설계가 실제 기능 개발 및 디자인 결정에 영향을 미칠 수 있음을 시사한다.