채팅 문제

Source: Dev.to

개요

AI는 당신의 코드를 잃어버리지 않는다. 당신의 결정을 잃어버린다.

출력은 저장된다; 이것이 쉬운 부분이다. 살아남지 못하는 것은 추론이다. 하나의 접근 방식을 다른 것보다 선택하고, 합의한 제약 조건이나 명시적으로 배제한 범위 등 모든 것이 대화가 끝나면 사라진다.

나는 ChatGPT를 개발 파트너로 삼아 5개월 동안 만든 크로스‑플랫폼 여행 앱 TrekCrumbs를 구축하면서 이 문제를 겪었다. 코드는 견고했고, 속도도 실제적이었다. 하지만 그 이면에 내가 눈치채지 못한 문제들이 쌓이고 있었다.

초기 단계에서 나는 데이터를 구조화하는 방법에 대해 결정을 내렸다: 각 종류의 크럼(여행 활동, 숙박, 항공, 기차 등)마다 별도의 스키마를 만드는 것이었다. 당시에는 합리적이었고, 유연하며, 깔끔하고 확장하기 쉬웠다. 이 결정은 다시 열어보지 않은 채 채팅에 남겨졌다.

몇 주 뒤, 나는 첫 번째 결정에 의존하는 또 다른 결정을 내렸지만 그 사실을 깨닫지 못했다. 또 다른 결정이 이어졌다. 필드가 스키마 사이를 떠돌고, 검증 로직이 중복되었으며, 작은 변경이 전혀 관련 없어 보이는 부분까지 깨뜨리기 시작했다. ChatGPT는 계속해서 수정안을 제시했다: 매핑 레이어, UI 패치, 변환기 등. 모두 기술적으로는 맞았지만, 실제 문제를 더욱 악화시켰다.

핵심 문제는 단순했다: 대화 중에 내린 중요한 결정이 문서화되지 않았고, 이후 모든 것에 은밀히 영향을 미쳤다. 비용이 드러났을 때는 한 번에 폭발했다.

나는 일주일 동안 멈췄다. 기능을 추가하거나 버그를 고치기 위해서가 아니라, 스키마를 처음부터 다시 만들기 위해서였다. 데이터 모델을 정규화하고, 처음부터 끝까지 모든 것이 실제로 어떻게 작동해야 하는지를 파악하는 데 일주일을 보냈다. 그 주는 코딩이 아니라, 몇 달 전부터 기록해 두었어야 할 결정을 내리는 시간이었다.

아키텍처가 명확해지자 AI는 리팩터링을 빠르고 깔끔하게 수행했다. 이것이 병목이었던 것은 아니었다. 병목은 결정이 채팅에 머물고, 채팅은 이전 대화를 효과적으로 이어가는 데 적합하지 않다는 점이었다.

Trail 프레임워크

그래서 나는 Trail Framework(Trail)를 만들었다.

Trail은 대화를 산출물로 대체한다. 의도를 미리 정의한다. 누가 결정하고, 누가 계획하고, 누가 구현하며, 누가 검토하는지를 설계 단계에서 구분한다. 작업은 감사 가능한 파일을 생성하는 구조화된 실행을 통해 수행된다. 모든 결정이 문서화되고 보존되며 검증 가능하다.

핵심 아이디어는 간단하다: 대화는 흐트러질 수 있지만 파일은 그렇지 않다. AI는 작업을 수행할 수 있지만, 결정자는 약하고 역사가 역할은 더 못한다. 신뢰성은 명시적인 산출물, 역할 분리, 원활한 인수인계에서 온다.

Trail은 프로젝트 관리 도구가 아니다. 방법론도 아니다. Git, Agile, 혹은 이미 사용 중인 어떤 툴도 대체하지 않는다. 이 모든 위에 얹혀 하나의 규칙만을 강제한다: 결정은 채팅에 남겨두지 않는다.

Trail은 오픈 소스이다.

• Web:
• GitHub: