손대지 말고, 구조부터 보여달라

지난해 8월 회사를 나온 뒤, 같이 퇴사한 네 명이 한동안 하나의 제품을 만들었다.

종이 문제집을 온라인에서 풀 수 있게 하고, 출판사가 자체적인 온라인 서비스를 운영할 수 있도록 만드는 제품이었다. 나는 기획을 맡았고, 함께 나온 프론트엔드와 백엔드 개발자가 구현을 맡았다. 11월과 12월을 지나면서 제품은 거의 완성 단계까지 갔다.

그런데 우리가 영업을 준비할 즈음 상황이 빠르게 달라졌다.

올해 들어 AI가 코드를 만드는 수준이 눈에 띄게 올라갔다. 몇 달 전만 해도 개발자가 직접 해야 한다고 생각했던 작업들이 훨씬 빠르게 만들어지고 있었다.

우리가 만든 제품이 갑자기 필요 없어졌다는 뜻은 아니었다. 하지만 출판사를 찾아가 이 제품을 팔아야 하는 입장에서는 이야기가 달라졌다. 지금 가격과 방식으로 계속 가져가는 것이 맞는지 다시 생각해야 했다.

그래서 다른 방향을 고민하기 시작했다.

새로 생각한 것은 PDF 같은 문서를 사람이 일일이 읽고 다시 입력하는 일을 줄이는 서비스였다.

일반적인 OCR처럼 글자를 그대로 읽어내는 것이 아니라, 사용자가 먼저 필요한 데이터의 구조를 정하면 그 형태에 맞춰 정보를 뽑아주는 방식이다.

견적서에서 업체명, 금액, 날짜만 필요하다면 그 항목만 데이터로 가져오고, 다른 종류의 문서라면 필요한 구조를 다시 정하면 된다.

아이디어는 있었지만 바로 모든 개발자를 투입하는 것은 부담스러웠다.

첫 번째 제품도 시장에 내놓기 직전에 방향을 다시 고민하게 됐다. 이번에는 처음부터 큰 비용을 들이기보다 먼저 작동하는 형태를 만들어 시장 반응을 확인하는 편이 낫다고 생각했다.

그때 프론트엔드 개발자가 내게 제안했다.

핵심 엔진은 자신이 맡을 테니 회원, 이용 기록, 결제, 데이터 구조처럼 서비스가 돌아가기 위해 필요한 서버 영역을 내가 한번 만들어보라는 것이었다.

나는 개발자가 아니다.

하지만 AI를 이용하고 Firebase를 쓰면 일반적인 백엔드 정도는 직접 시도해볼 수 있을 것 같았다.

개발자가 내게 이 일을 맡긴 이유도 단순히 사람이 부족해서는 아니었다. 기획자인 내가 서버와 데이터가 어떤 방식으로 연결되는지 직접 경험해보면 앞으로 개발자와 기능만 이야기하는 것이 아니라 구조까지 이야기할 수 있을 것이라고 했다.

그래서 시작했다.

Firebase를 선택한 것도 같은 이유였다.

지금 필요한 것은 몇 년 동안 사용할 완벽한 시스템이 아니라, 이 아이디어가 실제로 제품이 될 수 있는지를 빠르게 확인할 수 있는 구조였다.

문제는 내가 작업하던 GPT 계정이 중간에 바뀌었다는 것이었다.

이미 다른 계정에서 어느 정도 작업해놓은 코드가 있었는데, 새로운 AI에게는 그 앞의 대화가 없었다. 프로젝트 폴더만 연결되어 있는 상태였다.

1월 20일 오전, 새로 연결한 AI에게 처음 입력한 내용이 그래서 이것이었다.

“먼저 변경은 하지 말고, 이 저장소의 목적, 주요 파일과 폴더 구조를 요약해 주세요.”

그리고 조건을 하나 더 붙였다.

필요한 명령이 있다면 무엇을 왜 실행해야 하는지 먼저 설명하고, 내가 승인한 뒤 실행해달라고 했다.

AI에게 작업을 맡기기 전에 먼저 확인하고 싶었다.

이 AI가 지금 어떤 프로젝트를 보고 있는지 제대로 이해하고 있는가.

내가 코드를 직접 읽을 수 없는데 AI마저 잘못 이해하고 있다면 그다음부터는 무엇을 기준으로 맞고 틀린지를 판단해야 할지 알 수 없게 된다.

AI는 프로젝트를 확인하기 위해 네 가지 정도의 명령을 제안했다.

나는 네 가지를 모두 실행하라고 하지 않았다.

“1번만 먼저 실행해 주세요.”

우선 파일 목록만 보기로 했다.

목록을 확인한 뒤 문서를 하나씩 읽게 했다. 프로젝트가 어떤 구조인지 설명하게 하고, 실제 코드와 문서가 같은 이야기를 하고 있는지도 비교하게 했다.

모르는 것이 많았기 때문에 오히려 순서를 잘라야 했다.

한꺼번에 여러 가지를 바꾸면 무엇 때문에 결과가 달라졌는지 내가 알 방법이 없다.

하나를 보고, 설명을 듣고, 이해한 다음 다음으로 넘어가는 방식으로 작업했다.

그날 하루 동안 생각보다 많은 것을 손봤다.

회원 정보를 어떻게 구분할 것인지, 로그인한 사람을 어떻게 확인할 것인지, 사용 기록을 어떻게 남길 것인지 같은 내용들이 계속 이어졌다.

중간에는 AI가 먼저 코드를 수정한 적도 있었다.

나는 바로 말했다.

앞으로는 임의로 코드를 수정하지 말라고.

내가 직접 코드를 작성하지 못한다고 해서 무엇을 바꿀지 결정하는 것까지 AI에게 넘기고 싶지는 않았다.

그날 마지막 작업을 마친 뒤에도 한 가지를 부탁했다.

“다음 세션에서 지금 작업을 그대로 이어갈 수 있도록 모든 맥락을 정리해 주세요.”

계정이 바뀌면서 앞선 대화가 끊긴 일을 이미 한 번 겪었기 때문이다.

코드보다 먼저 작업의 이유와 결정 과정을 남겨야 했다.

이번 주에 며칠 더 백엔드를 만져보면서 한 가지는 분명해졌다.

개발을 직접 한다는 것이 꼭 코드를 직접 입력한다는 뜻만은 아니었다.

무엇을 확인할지 정하고, AI가 설명하는 내용을 이해할 수 있을 때까지 다시 묻고, 수정 범위를 정하고, 그 결과가 처음 의도와 맞는지를 판단하는 것도 개발 과정의 일부였다.

나는 아직 개발자가 아니다.

지금도 코드 한 줄을 보고 바로 의미를 알아내지는 못한다.

하지만 적어도 이번 프로젝트에서는 모른다는 이유로 전부 맡기지는 않으려고 한다.

AI가 코드를 만들 수 있다면, 나는 그 AI가 어디까지 이해하고 있는지 확인하고 어떤 방향으로 움직여야 하는지를 결정해야 한다.

아마 당분간은 이 방식으로 계속 만들어볼 것 같다.

그날의 성장 노트

내가 저지른 실수 — AI가 프로젝트 폴더를 보고 있다는 사실만으로 기존 맥락까지 이해하고 있을 것이라고 생각할 뻔했다.

AI의 맹점 — 프로젝트 파일을 읽을 수 있는 것과, 왜 그렇게 만들어졌는지 이해하는 것은 다른 문제였다.

비개발자의 원칙 — 내가 이해하지 못한 상태에서는 한꺼번에 진행하지 않는다. 먼저 읽게 하고, 설명을 듣고, 작업 범위를 확인한 뒤 하나씩 실행한다.