PoC 요구사항을 바꾸려는 과정에서 Codex와 GitHub Copilot으로 프로토타입 만들기

본문

작성자는 여러 AI 코딩 도구를 업무용 PoC(Proof of Concept)에 적용해 보고, 이후 이 도구들을 사용한 감사(audit) 경험을 정리하려고 합니다. 이번 글에서는 PDF 문서를 표시하고 그 안의 데이터를 추출·감사하는 기능을 검증하기 위해 OpenAI Codex와 GitHub Copilot을 사용한 과정을 비교합니다. 작성자가 만들려는 것은 의도적으로 프론트엔드 중심의 프로토타입이며, 최종 구현 단계에서는 모킹한 문서 뷰어를 Apryse WebViewer로 교체하고 데이터 추출 및 감사 동작을 백엔드 API에 연결할 계획입니다.

Codex로 만든 React PoC

Codex를 새로 내려받은 뒤 작성자는 “5.6 Terra Medium” 환경에서 작업을 시작했다고 설명합니다. Codex는 비교적 빠르게 React 기반 PoC를 만들었고, 프로젝트가 상당히 신속하게 로드됐습니다. 다만 실제로 사용할 수 있는 PDF 뷰어를 구성하기 위해 몇 차례 대화를 주고받아야 했고, 문서에서 데이터를 추출하는 기능도 단순히 동작하는 수준을 넘어 데이터가 누락되거나 가려진(redacted) 경우를 제대로 처리하도록 여러 번 조정해야 했습니다.

작성자는 Codex가 다른 AI 도구보다 흥미로운 데이터와 다양한 형식을 가진 유효한 PDF를 더 효과적으로 찾거나 생성했다고 말합니다. 이후 일부 정보를 가린 PDF를 다시 업로드하고, 가려진 필드는 다음 필드의 라벨을 가져오지 말고 빈칸으로 남겨 달라고 지시했습니다. 이 방식은 약간의 추가 지시를 주자 의도대로 동작했습니다. 즉, 이 PoC에서 중요한 검증 대상은 단순한 PDF 렌더링만이 아니라 문서에 값이 없거나 값이 의도적으로 제거됐을 때 추출기가 어떤 결과를 내는지까지 포함합니다.

Codex를 사용한 작업 흐름은 비교적 매끄러웠습니다. Codex는 디렉터리 안의 코드를 직접 수정했고, 현재 설정에서는 수정 전에 승인을 요청했습니다. 작성자는 npm run dev를 중지했다가 다시 실행하면서 변경된 결과를 확인했습니다. 다만 처음에는 실제로 검증하려는 PDF 뷰어 부분을 너무 빨리 스텁(stub)이나 모크(mock)로 대체하려는 경향이 있었습니다. Codex는 초기 프로젝트를 만든 뒤 약 30초 만에 Apryse WebViewer를 추천했지만, 정작 최초 구성에서는 WebViewer 자체를 모킹했습니다. 작성자는 라이선스 키가 필요할 수 있다는 이유로 도구가 실제 구성 대신 모킹을 선택했을 가능성을 언급하지만, 이는 작성자의 추측으로 제시됩니다.

작성자가 Apryse WebViewer로 교체해 실제 추출을 수행하도록 요청하자, Codex는 비교적 빠르게 그 방향으로 진행했습니다. 결과적으로 Codex는 프론트엔드의 흐름과 추출 기능을 검증하는 출발점을 제공했지만, PoC의 핵심 검증 대상이 처음부터 모킹돼 있었다는 점은 작업의 초기에 확인할 필요가 있는 부분으로 남았습니다.

GitHub Copilot에서 발생한 패키지와 컨텍스트 문제

작성자가 사용한 옵션 대부분은 무료 등급(free tier)이었습니다. 이후 GitHub Copilot을 사용하려 했지만 무료 등급 사용자는 데스크톱 앱을 이용할 수 없다는 사실을 실행 시점에 알게 됐습니다. 대신 VS Code에서 Copilot을 실행했고, 다른 AI 채팅 도구와 비슷한 인터페이스를 예상했다가 설치가 제대로 되지 않았다고 생각했습니다. 실제로는 새 프로젝트 안에서 작업해야 했고, 열려 있는 파일이 있으면 Copilot이 그 파일을 컨텍스트로 사용한다는 점을 뒤늦게 파악했습니다.

Copilot은 약 5초 만에 프로젝트 구조와 워크스페이스 생성 버튼을 제시했고, 부모 디렉터리를 선택한 뒤 1분 이내에 프로젝트를 만들었습니다. 화면에는 사용량이 0.2 크레딧으로 표시됐습니다. 그러나 의존성을 설치하는 단계에서부터 문제가 이어졌습니다. Copilot은 처음에 WebViewer 버전을 9.x대에서 10.0.0으로 바꾸자고 제안했고, 이후에는 PoC이므로 최신 버전을 사용하자고 했습니다. 패키지 문제를 해결하지 못하자 PDF.js로 전환하자고도 제안했습니다.

Copilot은 Apryse 패키지가 제대로 설치되지 않았다고 판단했지만, 작성자는 실제로 패키지 자체에는 문제가 없었다고 설명합니다. Copilot이 어떤 버전을 사용해야 하는지 추측하며 여러 선택을 하는 과정을 지켜본 뒤, 작성자는 Apryse 코드를 만들 때 어떤 출처를 사용하는지 직접 물었습니다. Copilot은 처음에는 디렉터리 파일 트리에 Apryse 이메일이 포함된 것을 보고 작성자가 Apryse 내부 저장소에 접근할 수 있을 것이라고 추론했습니다. 작성자가 이 추론을 바로잡자 Copilot은 PDF 뷰어와 Apryse를 별도로 평가하자고 제안했습니다.

웹 검색 비활성화가 만든 차이

작성자가 사용한 GitHub Copilot은 처음 대화에서 실시간 웹 검색을 활성화하지 않은 상태였습니다. Copilot은 Apryse에 대해 특정 출처에 접근할 수 없으며, 학습한 일반적인 패턴을 바탕으로 코드를 생성하고 있다고 밝혔습니다. 또한 현재 npm 버전을 확인할 수 없고, 공식 Apryse 문서와 교차 검증할 수 없으며, 생성한 코드가 오래됐거나 잘못됐을 가능성이 있다고 설명했습니다. 구체적으로 @pdftron/pdfjs-express 같은 패키지 이름, WebViewer() 함수 형태, path: '/lib' 같은 설정을 추측해 사용했다고 밝혔습니다.

작성자는 이 사실이 처음부터 명확하게 고지되지 않았다는 점에 크게 불만을 느꼈다고 말합니다. 다른 AI 채팅 도구에서는 인터넷 접근이 기본적으로 가능하다고 생각했기 때문에, Copilot이 실시간 웹 접근을 하지 않는다는 사실을 별도의 질문을 통해서야 알게 됐습니다. 이후 GitHub 설정에서 Copilot이 인터넷을 검색할 수 있도록 하는 토글을 변경하고, 새 채팅에서 원래 프롬프트를 다시 실행했습니다.

그 결과는 크게 달랐습니다. 새 프로젝트의 구조 자체가 이전과 달라졌고, 패키지 버전과 관련된 문제는 전혀 발생하지 않았습니다. 약 10분 만에 Apryse 기반의 동작하는 PoC가 만들어졌으며, 이번에는 단순한 일반 React 프로젝트가 아니라 Apryse를 포함한 프론트엔드와 백엔드 구조가 함께 생성됐습니다. 작성자의 경험에서는 인터넷 검색 설정의 유무가 서드파티 기술과 API를 사용하는 PoC의 결과를 직접적으로 바꿨습니다.

작성자가 제기한 개발 경험 문제

이 사례의 핵심은 AI가 자신 있게 제시하는 코드가 실제 최신 문서나 패키지 상태에 근거한 것인지 사용자가 즉시 알기 어렵다는 점입니다. GitHub Copilot은 인터넷 검색이 꺼진 상태에서 Apryse의 패키지 이름과 API 구조를 일반적인 패턴으로 추정했고, 그 과정에서 사용자를 PDF.js 같은 다른 라이브러리로 유도했습니다. 반면 검색을 허용하자 공식 문서와 현재 버전에 맞는 것으로 보이는 구조를 사용해 동일한 목표를 훨씬 짧은 시간에 달성했습니다.

작성자는 이런 동작이 일반적인 프로그래밍이나 서드파티 API를 사용하지 않는 작업에서는 안전장치 또는 더 나은 기본 경험이 될 수도 있다고 추측합니다. 그러나 외부 라이브러리와 최신 API를 검증해야 하는 작업에서는 검색 가능 여부와 그 상태를 사용자에게 명확히 알려야 한다고 문제를 제기합니다. 또한 여러 AI 도구를 한 번에 비교하는 감사는 일회성에 가까우며, 일상 업무에서 사용하는 개인화된 컨텍스트가 쌓이면 도구 간 비교 환경이 오염될 수 있다고 말합니다. 앞으로도 DevEx(Developer Experience) 감사를 진행하고 싶지만, 업무에 도구를 계속 사용하면서 동일한 조건을 유지하기 어려울 수 있다는 점도 함께 언급합니다.

원문: dev.to / 번역·요약: Trawling