기존 프로그램 복제 개발 방식 조사 및 계산기 적용

1. 정보수집

1.1 ArtCraft 소개

ArtCraft 는 그림과 영상을 만드는 무료 프로그램 묶음이다. 개발자는 Brandon Thomas 1명이며, 개발에는 Claude Opus 5.5 라는 AI 모델을 사용하였다고 밝혔다.

ArtCraft 의 이미지 편집 프로그램 PhotoCraft 는 기존 유료 그림 편집 프로그램과 메뉴, 단축키, 도구 배치가 거의 같다. 공개 후 약 4주 동안 GitHub 별 7만 개 이상을 받았다.

이 프로그램이 주목받은 이유는 개발 기간과 인원이다. 수십 년 동안 수백 명이 만든 프로그램과 비슷한 것을 1명이 AI 에이전트를 이용하여 수 주 만에 공개하였다.

1.2 ArtCraft 의 개발 원리

ArtCraft 저장소의 규칙 문서와 시험 자료를 분석한 결과, 짧은 기간에 개발할 수 있었던 원리는 7가지로 정리되었다. 표 2는 원리마다 쉬운 설명과 ArtCraft 의 근거를 나타낸다.

7가지 가운데 가장 큰 차이를 만든 것은 정답지가 이미 있다는 점으로 판단된다. 새 프로그램을 설계할 때는 무엇이 맞는 동작인지부터 정해야 한다. 기존 프로그램을 따라 만들 때는 기존 프로그램의 결과가 곧 정답이다.

1.3 다른 실제 사례

같은 원리를 먼저 쓴 사례로 Anthropic 의 C 컴파일러 실험(2026년 2월)이 있다. 컴파일러는 사람이 쓴 프로그램 글을 컴퓨터가 실행할 수 있는 형태로 바꾸는 프로그램이다.

이 실험에서는 AI 에이전트 16개가 약 2주 동안 C 컴파일러를 만들었다. 기존 공개 C 컴파일러를 정답지로 두고, 같은 파일을 두 컴파일러로 처리한 결과를 비교하여 오류 위치를 찾았다.

결과물은 Linux 운영체제의 핵심 부분을 빌드하고 실행하였다. 개발자는 시험이 통과했다고 일이 끝났다고 보기 어렵다는 점을 한계로 기록하였다.

2. 전략수립

2.1 맨 처음부터 개발하는 방식과 정답지 비교 방식의 차이

그림 3은 정답지 비교 개발의 작업 순서를 나타낸다. 정답 수집 다음의 2~5단계는 사람이 매번 지시하지 않아도 에이전트가 반복할 수 있다.

기존 Genealogy 시리즈의 개발 방식과 비교하면, 기능 지도와 개발일지는 이미 갖추고 있었다. 정답지, 하한선, 자동 점수표가 없었으며 다음 작업은 매번 사람이 지시하였다.

2.2 시험 대상 선정

첫 시험 대상으로 기존 계산기와 지뢰찾기를 정하였다. 두 프로그램은 Windows 사용자 대부분이 알고 있어 결과를 바로 비교할 수 있다.

순서는 계산기를 먼저 하였다. 계산기는 같은 키를 누르면 언제나 같은 숫자가 나와 정답 자료를 만들기 쉽다. 지뢰찾기는 지뢰 위치가 매번 바뀌어 정답 자료를 만드는 방법이 더 복잡하다.

2.3 프로그래밍 언어 선택

언어는 6가지를 비교한 뒤 사용자가 직접 골랐다. 표 5는 비교 결과를 나타낸다.

선택한 언어는 Rust 이다. ArtCraft 와 같은 언어와 화면 부품(egui)을 써서 같은 구조를 재현할 수 있고, 메모리 오류를 컴파일 단계에서 막는다.

2.4 정답 자료 수집 방법 결정

정답 자료는 사용자 PC 의 기존 계산기를 자동으로 조작하여 모으기로 하였다. 키를 입력하고 화면 숫자를 복사(Ctrl+C)한 뒤, 복사된 글자를 읽어 정답으로 기록한다.

원본 계산기의 소스 코드는 공개되어 있으나 열어 보지 않았다. 클린룸 원칙에 따라 키 입력과 화면 결과만 사용하였다.

3. 예시. 계산기 복제 과정과 결과

3.1 작업 폴더와 권한 준비

먼저 PC 의 문서 폴더에 판 폴더 GCalc_v1.0.0.0 을 만들었다. 이어서 창만 뜨는 빈 실행 파일을 넣고, 기존 계산기와 메모장의 자동 조작 권한을 받았다.

3.2 정답 자료 수집

기존 계산기에 키 입력 62가지를 넣고 결과를 기록하였다. 그림 4는 62건을 분류별로 나눈 건수를 나타낸다.

사칙연산과 같음 키가 14건으로 가장 많았다. 오류 문구와 메모리는 각 4건이었다.

수집 중 두 가지 문제가 발생하였다. 표 6은 문제와 처리 방법을 나타낸다.

정답 자료에서 기존 계산기의 규칙 8가지를 확인하였다. 표 7은 규칙과 근거 사례를 나타낸다.

3.3 수를 다루는 부분 구현

계산기의 숫자는 분수 형태로 보관하였다. 1÷3 을 0.333… 으로 바꾸지 않고 1/3 그대로 저장하면, 다시 3을 곱했을 때 정확히 1이 된다.

화면에 보일 때만 유효숫자 16자리로 반올림하였다. 제곱근은 분수로 정확히 나타낼 수 없으므로 소수점 아래 40자리까지 구하여 보관하였다.

3.4 계산 규칙과 명령 목록 구현

계산기의 상태(입력 중인 숫자, 기다리는 연산자, 메모리 값)를 다루는 부분을 따로 만들었다. 단추와 키 29개는 명령 목록 하나에 모았다.

그림 5는 GCalc 의 구조를 나타낸다. 화면 단추, 키보드, 창 없는 실행, 자동 시험이 모두 같은 명령 실행 함수를 부른다.

3.5 정답 자료 자동 비교

정답 자료 62건을 GCalc 에 넣어 결과를 자동으로 비교하였다. 첫 실행에서 62건 모두 일치하였다.

이에 따라 하한선을 62로 정하였다. 앞으로 코드를 고쳐 일치 건수가 62보다 적어지면 시험이 실패한다.

무작위 시험도 함께 수행하였다. 명령 29개를 무작위 순서로 4만 회 눌러 프로그램이 멈추지 않는 것을 확인하였다.

3.6 화면 구현

화면은 기존 계산기 표준 모드의 배치를 따랐다. 위에 계산식 줄과 큰 숫자, 그 아래 메모리 단추 6개, 맨 아래 단추 24개를 6행 4열로 놓았다.

그림 6은 1234567+89= 를 입력한 GCalc 화면이다. 큰 숫자에는 세 자리마다 쉼표를 넣었고, 같음 단추는 파란색으로 표시하였다.

한글 글꼴 파일은 프로그램에 포함하지 않았다. 실행할 때 Windows 에 설치된 맑은 고딕과 Segoe UI 를 읽어 사용한다.

3.7 Windows 실행 파일 생성

실행 파일은 Linux 환경에서 Windows 용으로 빌드하였다. 결과 파일 GCalc.exe 의 크기는 약 4.4 MB 이다.

실행 파일, 소스 코드, 규칙 문서, 정답 자료, 화면 캡처를 PC 의 GCalc_v1.0.0.0 폴더에 저장하였다. PC 에서 GCalc.exe 를 직접 실행하여 확인하는 작업은 남아 있다.

4. 결과 및 남은 일

본 작업에서는 기존 프로그램을 따라 만드는 개발 방식을 조사하고, 그 방식을 계산기 프로그램 GCalc 에 적용하였다.

ArtCraft 조사에서는 개발 원리 7가지를 확인하였다. 그중 원본 프로그램의 결과를 정답지로 두고 자동 비교하는 방법이 개발 속도에 가장 크게 작용한 것으로 판단된다.

GCalc 에서는 기존 계산기에서 정답 자료 62건을 수집하였고, 첫 구현에서 62건이 모두 일치하였다. 기능 목록 26항목 중 16항목을 구현하였다.

정답 자료가 아직 없는 부분은 열린 항목 6건으로 기록하였다. 표 9는 열린 항목과 다음 작업을 나타낸다.

이 방식은 기존 Genealogy 시리즈에도 적용할 수 있다. 이미지 뷰어 WingView 는 공개된 이미지 형식 설명서와 시험 파일을, iCAD 는 도면 파일 저장 후 다시 열기 결과를 정답지로 쓸 수 있다.

다음 판에서는 열린 항목의 정답 자료를 보강하고, 같은 방식으로 지뢰찾기 복제에 착수한다.