4편이 앨리스에게 참고서를 검색하고 근거를 모으는 방법을 가르치는 과정이었다면,
이번 5편은 그다음 단계에 대한 이야기다.
4편에서는 이런 내용을 다뤘다.
매뉴얼에서 무엇을 찾아야 하는지,
찾아온 근거가 충분한지 어떻게 판단할지,
근거가 부족하면 다음에는 무엇을 다시 물어볼지,
그리고 이 과정을 어떤 순서와 조건으로 반복할지.
일단 결과는 나왔다.
하지만 코드 변환율은 약 60% 정도였다.
첫 시도였다는 점을 생각하면 아주 나쁜 결과는 아니었다.
그래도 실제 회사 업무에 사용하려면 적어도 90% 가까이는 나와야 한다는 생각이 들었다.
그렇다면 나머지 40%는 왜 변환되지 않았을까?
매뉴얼 임베딩은 정상적으로 끝났다.
검색 결과도 나왔고, 관련 문서도 어느 정도 찾아오고 있었다.
매뉴얼의 내용이 AI가 이해하기 어려울 만큼 복잡했던 걸까?
아니면 내가 만들어 놓은 검색 가이드라인 자체에 빠진 부분이 있었던 걸까?
이 문제를 생각하다가 문득 새로운 취미를 배울 때가 떠올랐다.
내가 무슨 취미든 특별히 잘하는 사람은 아니지만, 새로운 것을 배우려면 최소한의 선수 지식은 필요하다.
카메라를 처음 배우면서 조리개와 셔터스피드가 무엇인지도 모른 채 사용설명서부터 펼치면,
책 안에 모든 내용이 있어도 원하는 답을 찾기가 쉽지 않다.
앨리스도 비슷한 상태였던 것 같다.
4편에서 만든 과정은 질문을 기준으로 매뉴얼을 검색하고, 근거를 모아 코드를 변환하는 하나의 사이클이었다.
그런데 그 사이클보다 앞에 필요한 과정이 빠져 있었다.
이것이 어떤 제품인지,
화면과 프레임이 어떤 구조로 움직이는지,
어떤 객체와 문법을 사용하는지,
대표적인 함수와 사용 방식은 무엇인지.
이런 기본 개념을 모르는 상태에서 곧바로 매뉴얼 검색을 시작하면, 검색어부터 정확하게 만들기 어렵다.
무엇을 모르는지도 모르는데, 무엇을 찾아야 할지 알 수 있을 리 없다.
그래서 메인 변환 작업을 시작하기 전에 전처리 단계를 하나 추가하기로 했다.
먼저 전체 소스 코드를 앨리스에게 보여준다.
그다음 코드 안에서 사용된 객체와 함수, API와 특수 문법을 추출한다.
추출한 항목을 다시 앨리스가 이미 알고 있는 개념과 알지 못하는 개념으로 나눈다.
그리고 알지 못하는 항목을 기준으로 임베딩된 매뉴얼을 다시 검색한다.
기존 흐름이 사용자의 요청과 전체 소스를 한꺼번에 기준으로 매뉴얼을 검색하는 방식이었다면,
앞으로는 다음과 같은 흐름이 된다.
전체 소스 확인
→ 사용된 객체와 API 추출
→ 알고 있는 개념과 모르는 개념 분리
→ 모르는 항목을 기준으로 매뉴얼 검색
→ 검색 근거 정리
→ 전체 소스 재분석
→ 코드 변환
핵심은 앨리스가 자신이 무엇을 알고 있고, 무엇을 모르는지 확인한 뒤 다시 전체 코드를 바라보게 하는 것이다.
산수의 기본 개념도 모르는 존재에게 『수학의 정석』 한 권을 건네주고 미적분 문제를 풀라고 하면 어떻게 될까?
책이 없어서 못 푸는 것이 아니다.
책에서 무엇을 찾아야 하는지 모르기 때문에 못 푸는 것이다. ㅎㅎㅎ
방향은 잡혔다.
하지만 새로운 전처리 단계를 기존 로직에 연결하면서 구조가 생각보다 많이 커졌다.
한 군데만 고치면 되는 일이 아니었다.
새로 만든 함수의 출력값을 기존 함수가 받아야 했고,
그 결과를 다시 다음 단계에 전달해야 했다.
그런데 기존 코드와 새로 추가한 코드 사이에서 입력값과 반환값의 형태가 서로 맞지 않았다.
어떤 함수는 문자열을 반환했고,
어떤 함수는 리스트를 기대했으며,
어떤 곳에서는 딕셔너리 형태의 결과를 당연하다는 듯 받아들이고 있었다.
결국 여러 군데에서 에러가 연속으로 발생했다.
처음에는 에러가 나올 때마다 하나씩 고치기 시작했다.
쏘피에게 에러 메시지를 보여주고,
수정 코드를 받아 붙이고,
다시 실행하고,
다음 에러가 나오면 또 다른 코드를 붙였다.
처음 몇 번은 실제로 문제가 해결되는 것처럼 보였다.
그런데 어느 순간 이상한 느낌이 들었다.
나는 프로젝트의 진도를 빨리 내고 싶은 마음 때문에 전체 구조를 보지 않은 채, 에러 메시지만 따라가고 있었다.
쏘피가 준 코드를 복사하고,
에러가 난 위치에 붙이고,
실행하고,
또 다른 에러가 나오면 다시 붙였다.
계속 무언가를 하고 있기는 했지만,
정작 나는 지금 어느 방향으로 코드를 수정하고 있는지 설명할 수 없었다.
쏘피가 코드를 작성해 주는 것 자체가 문제는 아니었다.
내가 모든 세부 문법을 직접 작성하거나 완전히 이해해야 한다고 생각하지도 않는다.
AI의 도움을 받아 더 빠르게 구현하는 것이 이 프로젝트의 방식이기도 하다.
문제는 쏘피가 제시한 수정의 의도를 이해하지 못한 채,
에러가 발생한 위치에 코드만 가져다 붙이고 있었다는 점이었다.
적어도 지금 수정이 어느 방향으로 가고 있는지,
어떤 함수 사이에서 입력값과 반환값이 엇갈리는지,
원천 구조를 바꾸는 것인지 중간에서 형태만 변환하는 것인지는 알고 있어야 했다.
세부 구현을 모두 설명하지 못하더라도,
이 함수는 무엇을 받아서 무엇을 돌려주는가?
다음 함수는 어떤 형태를 기대하는가?
두 함수 사이에서 무엇이 맞지 않는가?
지금 붙이는 코드는 그 불일치를 어디에서 해결하는가?
이 정도는 판단한 뒤 코드를 적용해야 했다.
그렇지 않으면 AI를 활용하는 것이 아니라, 에러와 수정 코드에 끌려다니게 된다.
그래서 오늘은 작업을 중단했다.
에러를 해결하지 못해서 멈춘 것은 아니다.
내가 전체 구조를 이해하지 못한 상태에서 코드를 수정하고 있다는 사실을 알아차렸기 때문에 멈췄다.
나는 회사에서 하루 종일 앨리스만 개발하는 사람이 아니다.
기존 업무도 함께 처리해야 하고, 중간에 전화도 받고, 요청사항도 확인해야 한다.
집중력이 떨어진 상태에서 억지로 진도를 내면,
오늘 붙인 코드를 내일 다시 해석하는 데 더 많은 시간을 쓰게 될 수도 있다.
빠르게 한 걸음 더 나가는 것보다, 잘못된 방향으로 세 걸음 나가지 않는 편이 낫다.
이번 작업을 통해 알게 된 것은 단순하다.
앨리스에게 참고서를 읽는 방법을 가르치는 일은, 매뉴얼을 검색하는 기능 하나를 만드는 것으로 끝나지 않는다.
검색한 내용을 어떤 형태로 정리할지,
어떤 함수에 전달할지,
다음 단계에서는 그 결과를 어떤 구조로 받아들일지,
그리고 그 근거를 다시 전체 코드 분석에 어떻게 사용할지까지 함께 설계해야 한다.
앨리스는 매뉴얼을 읽지 못한 것이 아니었다.
읽어 온 내용을 내보내는 톱니와, 그 내용을 받아들이는 톱니의 모양이 서로 달랐던 것이다.
오늘은 두 톱니가 제대로 맞물리지 않는다는 사실을 발견한 것으로 충분하다.
다음 작업에서는 억지로 코드를 이어 붙이는 것이 아니라, 서로 맞물리는 톱니의 모양부터 다시 살펴보려 한다.