💻 computer science

Jas: AI-Paired Engineering as a Revival of N-Version Programming

본 논문은 정밀한 실행 가능한 명세에 기반하고 병렬적인 N-버전 구현을 통해 검증되는 AI 결합 엔지니어링이, 단 한 명의 개발자가 약 120시간 만에 5개의 서로 다른 소프트웨어 포트를 제작할 수 있게 함으로써 1980년대의 비용 효율성이 낮았던 N-버전 프로그래밍 방법론을 효과적으로 부활시킨다는 사례 연구를 제시한다.

원저자: Jason Hickey

게시일 2026-06-09

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Jason Hickey

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 복잡하고 고급스러운 드로잉 앱(미니 어도비 일러스트레이터 같은 것)의 다섯 가지 서로 다른 버전을 만들고 싶다고 상상해 보십시오. 옛날 방식이라면, 각기 다른 언어를 사용하는 다섯 명의 마스터 건축가를 고용하여 동일한 집을 설계하는 것과 같았을 것입니다. 이는 수년이 걸리고 엄청난 비용이 드는 일이었습니다.

제이슨 히키(Jason-Hickey)라는 한 명의 개발자는 다른 방식을 취했습니다. 그는 단 7주 만에(저녁 시간에만 작업하여) 이 앱의 다섯 가지 작동 버전(Rust, Swift, OCaml, Python, 그리고 웹 브라우저용)을 만들어냈습니다. 그는 팀을 고용하지 않았습니다. 대신 AI를 그의 파트너로 사용했습니다.

그가 어떻게 해냈는지 쉽게 설명하면 다음과 같습니다.

1. "마스터 청사진" (실행 가능한 명세서)

보통 다양한 플랫폼을 위한 소프트웨어를 구축할 때, 각 플랫폼마다 앱의 규칙을 처음부터 다시 작성해야 합니다. 예를 들어 컬러 피커(color picker)의 작동 방식을 바꾸고 싶다면, 다섯 개의 서로 다른 코드베이스를 모두 업데이트해야 합니다.

히키는 그 반대로 했습니다. 그는 단 하나의 "마스터 청사진"(YAML이라는 언어로 작성된 23,000줄짜리 문서)을 작성했습니다.

비유: 이 청사진을 정적인 PDF가 아니라 살아있는 레시피라고 생각하십시오. 이 레시피는 단순히 "빨간 버튼을 만드세요"라고 말하는 것이 아니라, "이 버튼은 어떻게 생겼고, 클릭했을 때 어떻게 반응하며, 그 다음에 어떤 일이 일어나는지"를 정확하게 설명합니다.
마법: 이 청사진은 "실행 가능"합니다. 컴퓨터는 이 하나의 레시피를 읽고 다섯 가지 서로 다른 앱을 위한 사용자 인터페이스를 자동으로 구축합니다. 만약 히키가 규칙을 바꾸고 싶다면, 그는 한 곳에서 수정하기만 하면 되며, 이는 즉시 다섯 가지 앱 모두에 반영됩니다.

2. "다섯 머리 달린 용" (N-버전 프로그래밍)

1980년대에 엔지니어들은 "N-버전 프로그래밍"이라는 방법을 시도했습니다. 그 아이디어는 이렇습니다: "만약 우리가 독립적으로 다섯 가지 다른 버전의 시스템을 구축하고, 그들이 모두 일치한다면, 그것은 옳다는 뜻이다. 만약 그들이 서로 다르다면, 우리는 무언가 잘못되었다는 것을 알 수 있다."

문제점: 비용이 너무 많이 들었습니다. 다섯 명의 팀을 구성하여 다섯 가지 버전의 코드를 각각 작성하는 것은 돈 낭비였습니다.
AI의 반전: 히키는 AI를 사용하여 이 아이디어를 부활시켰습니다. AI가 서로 다른 언어로 코드를 작성하는 힘든 작업을 수행할 수 있기 때문에, 그는 혼자서도 다섯 가지 버전을 구축할 여력이 생겼습니다.
안전망: 이 다섯 가지 버전은 다섯 명의 배심원 역할을 합니다. 만약 "Rust" 버전의 앱은 색상을 빨간색으로 바꾸는데, "Python" 버전은 파란색으로 바꾼다면, 시스템은 즉시 문제를 감지합니다. 그들은 서로를 "차등 테스트(differential test)"합니다. 만약 의견이 일치하지 않는다면, 그것은 마스터 청사진이 불분명했거나, 특정 버전이 실수를 저질렀음을 의미합니다.

3. "탈출구" (The Escape Hatch)

마스터 청사진은 작업의 약 90%를 다룹니다. 하지만 때로는 특정 컴퓨터 플랫폼(예: 아이폰이나 웹 브라우저)에 일반적인 청사진으로는 설명할 수 없는 특별한 기술이 필요할 때가 있습니다.

비유: 청사진이 표준 주택 설계도라고 가정해 봅시다. 하지만 "Rust" 집은 지반이 암석이기 때문에 특수 보강된 지하실이 필요합니다. 청사진은 모두에게 벽과 지붕을 제공하지만, "Rust" 팀은 자신들만의 특별한 지하실을 직접 만들어야 합니다.
히키는 이것을 **탈출구(Escape Hatch)**라고 부릅니다. 이는 각 특정 플랫폼을 위해 필요한 소량의 커스텀 코드이며, 나머지 부분은 공유됩니다.

4. 프로세스가 작동하는 방식 (루프)

히키는 단순히 코드를 타이핑하고 결과가 나오길 기다리지 않았습니다. 그는 특정 루프를 사용했습니다:

설계: 평범한 영어로 계획을 작성합니다.
AI 검토: AI에게 계획의 허점을 찾아달라고 요청합니다 ("무엇이 빠졌나요? 무엇이 혼란스러운가요?").
청사진 업데이트: AI의 조언을 바탕으로 마스터 청사진을 업데이트합니다.
빌드 및 테스트: AI가 다섯 가지 앱을 위한 코드를 생성합니다.
"사람의 눈" 확인: 이것이 가장 느린 부분이었습니다. 히키는 다섯 가지 앱을 나란히 놓고 수동으로 확인했습니다. 만약 하나가 이상하게 보인다면, 그는 청사진을 수정해야 한다는 것을 알았습니다.

결과

시간: 약 120시간의 저녁 작업 (약 7주 소요).
결과물: 하나의 핵심 로직을 공유하는 다섯 가지 완전한 기능의 앱.
비용: "여러 명의 개발자-연수(developer-years)" 대신, 단 한 명의 사람이 몇 달 만에 해냈습니다.

주의 사항 (한계점)

이 논문은 이 방식이 하지 못하는 것들에 대해서도 솔직하게 밝히고 있습니다:

완성된 제품이 아닙니다: 이 앱들은 전문적인 도구에서 볼 수 있는 고급 기능(복잡한 3D 메쉬나 전문 인쇄 기능 등)이 누락되어 있습니다. 이는 완벽한 복제본이 아니라 "상당한 부분의 하위 집합"입니다.
AI에 의존합니다: 만약 AI가 혼란을 겪거나 "환각(hallucination)" 현상(가짜 코드를 만들어내는 것)을 일으키면, 다섯 가지 버전이 서로 일치하지 않음으로써 시스템이 이를 잡아냅니다. 하지만 AI가 특정 작업에 서툴다면 전체 과정이 느려집니다.
사람이 필요합니다: AI가 타이핑을 했지만, 결과를 확인하고, 로직을 수정하며, AI가 어제의 결정을 잊어버리지 않도록 프로젝트의 "기억"을 관리하는 것은 인간의 몫이었습니다.

핵심 요점

이 논문은 AI가 소프트웨어 엔지니어링의 경제학을 바꾸어 놓았다고 주장합니다.
이전에는 품질을 보장하기 위해 소프트웨어의 여러 버전을 만드는 것이 너무 비쌌습니다. 이제는 AI가 반복적인 코딩 작업을 처리해주기 때문에, 한 명의 개발자가 다섯 가지 앱으로 구성된 "배심원단"을 구축하여 서로의 작업을 검증할 수 있게 되었습니다. 이는 비용 문제로 인해 1980년대에 버려졌던 방법을 오늘날 한 명의 개인에게 실용적인 도구로 탈바꿈시켰습니다.

기술 요약: N-버전 프로그래밍의 부활로서의 AI 결합 엔지니어링

문제 정의
성숙한 벡터 일러스트레이션 애플리케이션(예: Adobe Illustrator, Inkscape)은 대규모의 지속적인 팀이 수십 년간 개발해 온 결과물이다. 역사적으로 이러한 애플리케이션을 확장하거나 새로운 플랫폼으로 이식하는 것은 방대한 코드량, UI 프레임워크의 복잡성, 그리고 엄격한 정확성의 필요성 때문에 개인 개발자에게는 도달 불가능한 영역으로 간주되어 왔다. 본 논문은 AI 결합 엔지니어링(AI-paired engineering)이 이러한 경제적 현실을 변화시켜, 단 한 명의 개발자가 전통적인 방식에 비해 훨씬 적은 시간 내에 복잡한 데스크톱 애플리케이션의 고충실도 구현체들을 다수 제작할 수 있게 할 수 있는지 조사한다.

방법론
저자 Jason Hickey는 "AI 결합 엔지니어링"을 규모 있게 수행하기 위해 두 가지 구체적인 안전장치에 중심을 둔 방법론을 채택했다:

정밀하고 실행 가능한 명세 (단일 진실 공급원):
- 프로젝트의 핵심은 애플리케이션의 패널, 다이얼로그, 도구, 메뉴, 상태 모델 및 반응형 동작을 선언적으로 정의하는 23,000라인의 YAML 명세서이다.
- 이 명세서는 **실행 가능(executable)**하다: 약 12,500라인의 공유 인터프리터가 시작 시 YAML을 읽어 UI를 직접 구축하며, 이는 YAML을 각 언어에서 다시 인코딩하기 위한 문서로 취급하지 않는다.
- 이 방법론은 "탈출구(escape hatch)" 패턴을 활용한다: 플랫폼 특유의 뉘앙스(예: 하드웨어 가속 렌더링, 특정 제스처 처리)를 표현할 수 없는 경우 네이티브 코드를 작성한다. 그러나 개념적 로직은 YAML에 유지되므로, 설계 결정은 한 번만 이루어지고 모든 포트(port)로 전파된다.
차분 테스트 레이어로서의 병렬 구현:
- 단일 구현 대신, 저자는 서로 다른 언어와 프레임워크를 사용하는 다섯 가지 작동하는 포트를 구축했다: Rust (Dioxus), Swift (SwiftUI), OCaml, Python (PySide6), 그리고 브라우저 기반의 Flask/HTML 스케치.
- 이 병렬 구현체들은 지속적인 정답성 확인(correctness check) 역할을 한다. 이들은 동일한 명세를 공유하지만 서로 다른 네이티브 렌더러와 상태 관리 관습을 사용하므로, 동작이나 시각적 출력의 차이는 구현상의 버그나 YAML의 미비한 명세를 즉각적으로 알려준다.
- 이 접근 방식은 N-버전 프로그래밍(Avizienis, 1985)을 부활시킨다. 1980년대의 원래 방법론은 $N$ 개의 독립적인 구현체를 만드는 데 드는 막대한 비용 때문에 폐기되었으나, 저자는 AI가 이러한 경제적 문제를 근본적으로 바꾼다고 주장한다. AI가 포트별 기계적 작업을 처리함으로써 단일 개발자가 $N$ 개의 구현체를 만드는 것을 가능하게 하며, 플랫폼의 다양성은 자동화된 테스트가 놓칠 수 있는 오류를 잡아내는 데 필요한 독립성을 제공한다.

주요 기여

사례 연구: 단 한 명의 개발자가 약 120 저녁 시간(7 캘린더 주) 동안 벡터 일러스트레이션 애플리케이션(27개 도구, 14개 패널, 22개 다이얼로그)의 다섯 가지 크로스 플랫폼 구현체를 제작했다.
방법론적 프레임워크: 실행 가능한 명세와 병렬 구현을 차분 테스트 레이어로 결합하는 구체적인 워크플로우를 제시한다.
실무 보고서: AI 결합 엔지니어링의 실제 과정에 대한 상세한 기록을 포함한다:
- 프롬프트 엔지니어링: 산문 형태의 설계를 YAML로 변환하는 반복 루프와 주기적인 코드베이스 리뷰.
- 상태 관리: 세션 간 문맥 유지를 위한 지속적인 파일 기반 메모리(57개 항목)의 결정적 역할.
- 실패 모드: 심볼에 대한 "확신에 찬 환각(confident hallucinations)", 긴 문맥 드리프트(long-context drift), 모호함을 알리지 않고 하나의 해석을 선택하는 경향성 등 AI의 한계에 대한 솔직한 보고.
오픈 소스 산출물: 프로젝트 전체(23,000라인의 명세, 5개의 포트, 4,600개의 자동화 테스트, 수동 테스트 프로토콜 포함)는 github.com/jyh/jas에서 확인할 수 있다.

결과

규모와 범위: 프로젝트 결과물은 총 약 336,000라인의 코드(공유 인터프리터 및 5개 포트 포함)를 생성했다. 공유 YAML 명세가 로직을 주도했으며, 포트별 네이티브 코드는 0라인(OCaml, 완전한 YAML 주도형)에서 약 95,000라인(Rust, 상당한 커스텀 렌더링 필요)까지 다양했다.
차이를 통한 정답성 확보: 병렬 구현 전략은 단일 포트에서는 "조용히 틀렸을(silently wrong)" 법한 명세의 공백을 성공적으로 식별했다. 사례로는 다음과 같은 것들이 있다:
- 퇴화된 색상 채널 처리 (예: HSB 채도가 0으로 떨어지는 경우).
- Web Safe RGB 모드에서의 "스냅(snap)" 동작 타이밍.
- 다이얼로그 컨텍스트에서의 상태 지속성 (예: 헥스 필드 복구).
- 슬라이더 드래그 중 "최근 색상" 처리 로직.
노력: 총 노력은 약 120~~160 개발자 시간으로 추산된다. 저자는 유사한 규모의 포트를 전통적인 도구로 포팅할 경우 통상 1~~2 개발자 년(year)이 소요되며, 5개의 포트를 만드는 데는 여러 개발자 년이 필요할 것이라고 언급했다.

의의 및 주장
본 논문은 결과물이 성숙한 상용 도구의 기능적 완전성(고급 텍스트 셰이핑, 래스터 효과, 완전한 SVG 충실도 부족 등)을 갖추었다고 주장하지 않는다. 대신, 그 의의는 **실행 가능성의 경계(feasibility boundary)**가 이동했음을 보여주는 데 있다.

저자는 정밀한 실행 가능 명세와 AI 생성 병렬 구현을 결합함으로써, 단 한 명의 개발자가 전통적으로 여러 개발자 년이 필요한 범위의 작업을 달성할 수 있다고 주장한다. 이는 N-버전 프로그래밍의 부활로 프레임화되며, AI가 여러 독립적인 구현체를 만드는 경제적 장벽을 낮추었다는 것이다. 이 방법론은 도메인이 선언적으로 기술될 수 있는 영역(UI 및 애플리케이션 로직과 같은)에서, 개발자가 엄격한 수동 테스트와 메모리 관리 프로토콜을 유지한다면, 여러 포트를 통해 얻는 "차분 테스트"의 가치를 전통적인 비용 페널티 없이 실현할 수 있음을 시사한다.

본 논문은 현재의 AI 능력(2026년 기준 Claude Opus 4.6/4.7)에 기반한 스냅샷임을 인정하며, 방법론이 개발자의 도메인 전문 지식과 AI 실패 모드를 관리하는 능력에 크게 의존한다는 점을 명시하며 겸허한 태도를 유지한다. 저자의 주장은 AI가 인간의 감독을 대체한다는 것이 아니라, N-버전 프로그래밍의 경제적 방정식을 변화시켜 개별 개발자에게도 정답성과 이식성을 보장하기 위한 유효한 전략이 되게 한다는 것이다.