2편을 정리하면서 마지막에 이런 생각이 들었고, 이번에는 Makefile이나 CMake가 아니라 Prompt와 Markdown을 만들고 있었다. 그래서 예전에 새로운 칩셋이나 플랫폼을 받아 개발을 시작하던 방식과 지금 MyStock에서 AI를 사용하는 방식을 한번 나란히 놓아봤다.
과거 지금
신규 칩셋 / 플랫폼 AI
Vendor SDK ChatGPT / Codex
│ │
▼ ▼
구조 / 특성 / 제약 파악 특성 / 한계 / 역할 파악
│ │
▼ ▼
개발하면서 문제될 부분 확인 Context / 정보 비대칭 확인
│ │
▼ ▼
Makefile / CMake Prompt / _devlog /
빌드 시스템 재구성 GitHub / 역할 분리
│ │
▼ ▼
본격적인 제품 개발 MyStock 개발
│ │
▼ ▼
내가 직접 코딩 Codex가 코딩흠... 원래 내가 하던 짓이네
도식으로 놓고 보니 갑자기 너무 익숙했다. 새로운 칩셋이나 플랫폼을 받을 때마다 나는 바로 제품 코드부터 작성하지 않았다. 먼저 Vendor SDK를 살펴보고 구조와 특성, 제약을 파악했다. 개발하면서 계속 걸릴 것 같은 부분이 보이면 Makefile이나 CMake로 빌드 시스템을 다시 구성했고, 내가 개발하기 편한 상태를 만든 다음 본격적인 구현을 시작했다. 이번에도 과정 자체는 크게 다르지 않았다.
다만 대상이 칩셋이나 Vendor SDK가 아니라 ChatGPT와 Codex로 바뀌었다. AI의 특성과 한계를 먼저 이론으로 공부하고 이런 구조를 설계한 것은 아니었다. 그냥 MyStock을 개발하면서 불편한 것이 생길 때마다 하나씩 없앴다.
처음부터 AI 개발환경을 만들 생각은 없었다
대화가 길어지고 대화방이 바뀌면서 프로젝트 맥락이 약해지는 것이 불편해서 작업 과정을 남기는 기록이 필요해졌다. Codex는 실제 Repository를 알고 있지만 ChatGPT는 현재 소스 상태를 모르는 것이 불편했다. 그래서 GitHub를 읽을 수 있게 했다. 그렇다고 ChatGPT까지 Repository 전체를 매번 분석하게 하면 Codex와 역할이 겹쳤다. 그래서 소스를 전부 읽히는 대신 Repository 구조와 _devlog를 이용해 다음 판단에 필요한 정도의 정보만 복원하는 방향으로 바꿨다. Prompt를 전달하는 과정에서 의도가 달라지거나 작업 방식이 흔들리면 규칙을 다시 정리했다.
처음부터 하나의 방법론을 설계한 것이 아니었다. 불편해서 하나를 고쳤고, 또 다른 불편이 생겨 하나를 더 붙였다. 그렇게 반복하다 보니 Prompt, _devlog, GitHub, 역할 분리 같은 요소들이 하나의 작업환경처럼 연결되어 있었다. 그리고 그 모습을 예전 개발 방식과 나란히 놓고 나서야 왜 익숙했는지 알게 됐다.
예전에도 필요성을 느끼기는 했다
사실 AI와 협업하려면 별도의 환경이 필요할 것 같다는 생각 자체는 초반에도 있었다. TPUB를 만들면서 규칙 파일 하나만 잘 작성한다고 끝나는 것이 아니라, 최신 규칙을 확인하고 필요한 자료를 찾고 결과물을 일정한 형식으로 만들고 검증하는 실행 흐름까지 필요하다고 느꼈다.
하지만 그때는 아직 막연했다.
AI와 협업하려면 뭔가 규칙과 환경이 필요하다는 정도였지, 그것이 내가 오랫동안 새로운 플랫폼을 받아들일 때 해오던 개발 선행 작업과 같은 성격이라는 생각까지 이어지지는 않았다. MyStock을 실제로 계속 개발하고, 문제가 생길 때마다 작업 방식을 바꾸고 나서야 그 정체가 조금 더 분명해졌다.
그런데 하나는 예전과 달랐다
과정이 비슷하다고 해서 완전히 같은 것은 아니고, 예전에는 개발환경을 정리한 다음 내가 직접 코드를 작성했다. 환경을 이해하고, 구조를 판단하고, 구현하고, 결과를 검증하는 과정이 한 사람 안에서 이어졌다.
MyStock에서는 마지막 구현까지 Codex에게 넘겼다. 그리고 나는 프로젝트의 목적과 요구사항을 정하고, 구조적인 방향과 범위를 판단한다. ChatGPT와 문제를 구조화하고 선택지를 검토한 뒤 Codex에게 구현을 전달한다. 실제 Python 코드는 Codex가 Repository를 보고 수정한다. 돌이켜보면 AI 연대기 1편에서 시작된 문제도 바로 이 차이에서 생겼다.
내가 구현을 직접 하지 않으니 프로젝트 목적과 판단은 내가 가장 많이 알고, 긴 논의와 결정 과정은 ChatGPT가 많이 알고, 실제 현재 소스는 Codex가 가장 정확하게 아는 상태가 됐다. 예전에는 한 사람 안에 연결되어 있던 정보가 역할에 따라 나뉘었다. _devlog와 GitHub 연결, Prompt 규칙과 역할 분리는 결국 그 분리에서 생기는 불편을 줄이기 위해 하나씩 추가한 것이었다.
AI가 코딩을 대신해도 개발환경까지 없어지는 것은 아니었다
여기까지 오고 나니 이번 실험에서 얻은 판단도 조금 달라졌다. 처음에는 Python을 직접 배우지 않고도 AI에게 구현을 맡겨 MyStock을 계속 개발할 수 있는지가 관심사였다. 실제로 나는 Python 구현에 거의 참여하지 않고도 프로젝트를 진행하고 있다. 하지만 코딩을 AI에게 넘긴다고 해서 개발환경까지 사라지는 것은 아니었다.
새로운 칩셋이나 플랫폼을 사용할 때 Vendor SDK를 그대로 받아 바로 제품 개발부터 시작하지 않았듯이, AI가 코드를 작성해준다고 해서 아무 준비 없이 바로 개발을 계속하면 되는 것도 아니었다. 예전에는 Makefile이나 CMake로 빌드 시스템을 구성했다. 지금은 Prompt, _devlog, GitHub와 역할 분리를 통해 AI와 개발하기 위한 환경을 구성하고 있었다.
형태는 달라졌지만 목적은 비슷했다. 도구의 특성과 제약 때문에 반복해서 발생하는 불편을 줄이고, 내가 판단하고 개발을 이어가기 편한 상태를 만드는 것이다. 그렇기 때문에 나는 처음부터 Context 관리 방법이나 AI 협업 구조에 대한 이론을 세우고 MyStock에 적용한 것이 아니다.
대화가 끊기면 불편해서 기록을 만들었고, 현재 구조를 몰라 판단이 흔들리면 Repository를 볼 방법을 찾았고, 역할이 겹치면 다시 나눴다. 같은 문제가 반복될 것 같으면 그 반복 비용을 줄이는 쪽으로 작업 방식을 바꿨다. 그렇게 하나씩 불편한 것을 없애다 보니 결과적으로 개발환경이라고 부를 만한 구조가 생겼다.
생각해보면 새로운 칩셋과 Vendor SDK를 받을 때도 비슷했다. 처음부터 완벽한 빌드 시스템을 설계하려고 시작한 것이 아니라, 실제 개발에서 계속 발목을 잡을 부분을 줄이다 보니 Makefile이나 CMake를 다시 구성하게 됐다. 이번에는 그 대상이 AI로 바뀌었을 뿐이었다.
기록해야 하는 삽질의 위치도 바뀌었다
이걸 깨닫고 나니 MyStock 개발기를 앞으로 어떻게 기록해야 할지도 더 분명해졌다. 예전에는 SDK나 빌드, 코드에서 겪은 삽질을 기록했다. 같은 문제를 다시 만났을 때 반복하지 않기 위해서였다.
지금 MyStock에서는 내가 실제 Python 구현 내용을 확인하거나 살펴보지 않는다. 대신 어떤 문제가 이상하다고 느꼈는지, 왜 기존 방향을 유지하면 안 된다고 판단했는지, ChatGPT와 어떤 선택지를 검토했는지, Codex에게 어떤 범위와 제약을 전달했는지, 결과를 실행해보고 무엇을 다시 바꿨는지가 내가 실제로 참여한 개발 과정이다.
그래서 기록해야 하는 삽질도 코드에서 구조와 판단, 그리고 AI와 함께 개발하는 작업 방식 쪽으로 조금 올라갔다. 코드를 이해하는 척하기보다 내가 실제로 한 판단을 기록하는 편이 이 실험에는 더 맞다.
AI 때문에 완전히 새로운 개발 방법을 만들고 있다고 생각했던 것은 아니다. 그렇다고 예전 방식을 의식적으로 AI에 적용한 것도 아니었다. 그냥 불편한 것을 하나씩 없애며 개발을 계속했다. 그러다 어느 순간 만들어진 구조를 바라보니, 새로운 칩셋이나 플랫폼을 처음 다룰 때마다 내가 해오던 과정과 닮아 있었다. 코드를 작성하는 주체는 나에서 Codex로 바뀌었다.
하지만 새로운 도구의 특성과 제약을 파악하고, 반복되는 불편을 줄이고, 본격적인 개발을 계속할 수 있도록 환경을 구성해야 한다는 점은 달라지지 않았다. AI가 구현을 대신해도 개발환경까지 대신 만들어지는 것은 아니었다.
그리고 그 환경을 만들기 위해 나는 결국 원래 하던 짓을 하고 있었다.