1편에서 느슨하게 시작하면 예상 못한 연결이 일어난다는 이야기를 했다. 이번에는 대화 안에서 벌어지는 일을 이야기한다. AI와 대화하면서 방향이 바뀌는 순간들. 그 순간에 필요한 것이 무엇이었는가.
바둑 영상에서 기보를 추출하는 프로젝트를 AI와 함께 진행했다. 12시간짜리 세션이었다. 그 안에서 방향이 열 번 바뀌었다.
처음에는 영상에서 돌을 감지하는 것이 목표였다. 프레임 간 차이를 추적해서 새로 놓인 돌을 찾는 방식. 그런데 감지율은 100%인데 좌표가 부정확했다. 여기서 첫 번째 전환이 일어났다. 프레임 이미지를 직접 들여다보니, 착수 위치에 세모 마커가 붙어 있었다. 돌이 아니라 마커를 추적하면 된다. 접근 자체가 바뀌었다.
마커 추적으로 수순 추출이 성공했다. 그런데 결과를 보니 시간 정보가 딸려왔다. 각 수에 몇 초를 썼는지. 여기서 두 번째 전환. 기보 추출이 목표였는데, 시간 데이터가 덤으로 나온 것이다. 기보 데이터베이스에는 시간 정보가 없다. 아무도 갖고 있지 않은 데이터가 생긴 것이다.
시간 데이터가 생기니 질문이 바뀌었다. "즉타(빠르게 둔 수)에서 실수가 더 많은가?" AI 승률 분석과 교차하니 패턴이 보였다. 여기서 세 번째 전환. 기보 추출 프로젝트가 감각 훈련 문제 생성 프로젝트로 변했다.
이런 식으로 열 번. 기보 추출 → 마커 추적 → 시간 분석 → 승률 교차 → 감각 훈련 → 접바둑 분석 → 프로 대국 자동 녹화 → 귀 패턴 클러스터링 → 정석 재분류 → 프로기사별 편향 지도.
처음 목표였던 "영상에서 기보 추출"은 열 번째 전환 뒤에 보면 전체의 5%도 안 되는 부분이었다.
열 번의 전환에서 공통점을 찾았다. 매번 전환을 만든 것은 AI의 제안이 아니었다. 도메인 지식 한 마디였다.
"접바둑이면 첫 프레임에 이미 돌이 있다." — AI가 접바둑 초기 배치를 놓치고 있었을 때.
"접바둑에서는 백이 먼저 둔다." — 흑/백 순서가 뒤바뀌어 시간 분석 전체가 틀어졌을 때.
"그건 정석이잖아. 외워서 두는 건데 당연히 정확하지." — AI가 "즉타가 정확하다"고 분석했을 때.
"0.1집 흘리는 건 당연해. 그러니까 두 점을 깔고 두는 거지." — AI가 0.1집 손해를 교정 대상으로 분류했을 때.
"AI 상대로 손해를 복구하는 건 불가능해. 유지하는 쪽으로 가야지." — AI가 승부수 훈련 문제를 만들려 했을 때.
"두 점으로 이기는 프로는 최정상급이야." — AI가 "프로는 이미 최적화되어 있다"고 비판했을 때.
"대국 종료는 무조건 초읽기 멈춤으로 알 수 있어." — AI가 "돌이 사라지면 대국 종료"로 설계했을 때.
전부 한 문장이다. 그런데 그 한 문장이 없으면 AI의 분석은 틀린 방향으로 간다. 정확하게 틀린다. 숫자는 맞는데 해석이 틀리고, 코드는 돌아가는데 전제가 틀린다.
이 경험에서 배운 것이 있다. AI는 멍청하게 틀리지 않는다. 뛰어나게 틀린다.
"즉타의 평균 손해가 0.19집으로 가장 낮다. 즉타가 오히려 정확하다." 이 분석은 숫자적으로 완벽하다. 계산이 맞고, 통계가 맞고, 그래프까지 깔끔하다. 그런데 결론이 틀렸다. 즉타가 정확한 게 아니라, 초반 정석 수순이 즉타에 몰려 있어서 정확해 보이는 것이다. 외워서 두는 수니까 당연히 정확하다.
"수당 평균 손해 0.1집. 이상치를 줄이는 것이 교정 목표다." 이것도 분석으로서는 맞다. 그런데 접바둑 두 점이 약 13집이고, 141수 × 0.1집 = 14집이니까, 0.1집 손해는 접바둑이 이미 커버하는 범위다. 교정 대상이 아니다.
AI가 뛰어나게 틀리기 때문에 위험하다. 멍청하게 틀리면 눈에 보인다. 뛰어나게 틀리면 그럴듯해서 그냥 넘어간다. 논리가 정교하고 숫자가 정확하고 표현이 매끄러우니까, "맞는 것 같은데?"에서 멈추게 된다.
그러면 그 한 마디는 어디서 오는가.
바둑 50년이다. "접바둑이면 백이 먼저 둔다"를 아는 건 접바둑을 수천 번 둬본 사람이다. "즉타가 정확한 건 정석이니까 당연하다"를 아는 건 정석을 수십 년간 공부한 사람이다. "0.1집은 접바둑이 해결하는 문제"를 아는 건 접바둑의 핸디캡이 어떻게 작동하는지를 몸으로 아는 사람이다.
한 마디의 조건은 도메인 깊이다. 깊이가 없으면 한 마디가 나오지 않고, 한 마디가 없으면 AI의 분석이 틀린 채로 결론이 된다.
그리고 이 한 마디는 계획에서 나오지 않는다. 프로젝트 계획서에 "접바둑 초기 배치를 확인할 것"이라고 적혀 있지 않았다. "AI의 즉타 분석을 의심할 것"이라고 적혀 있지도 않았다. 결과를 보고, "어, 이거 아닌데?"라고 느끼는 순간에 나온다.
느슨하게 시작해야 이 순간이 가능하다. 계획을 촘촘하게 짜면 "계획대로 가고 있는가?"를 확인하느라 "이거 아닌데?"를 놓친다. 느슨하면 결과 자체를 본다. 결과를 보면 어긋남이 보인다. 어긋남을 보면 한 마디가 나온다.
12시간 동안의 대화에는 리듬이 있었다.
AI가 코드를 쓴다. 돌아간다. 결과가 나온다. 내가 본다. "이거 맞아?" 또는 "이거 아닌데." 한 마디. AI가 방향을 수정한다. 다시 코드를 쓴다. 결과가 나온다. 내가 본다.
이 리듬에서 AI의 역할은 실행이다. 코드를 쓰고, 돌리고, 결과를 내놓는 것. 빠르고 정확하다.
나의 역할은 방향이다. 결과를 보고 맞는지 아닌지를 판단하고, 다음 질문을 던지는 것. 느리지만 결정적이다.
실행은 AI가 압도적으로 빠르다. 1,000줄짜리 파이프라인을 몇 분 만에 만든다. 방향은 사람이 쥐고 있어야 한다. "접바둑이면 백이 먼저 둔다"는 한 마디를 AI가 스스로 하지는 못하니까.
이 역할 분담이 자연스럽게 잡혔다. 누가 정한 것이 아니라 대화하면서 잡혔다. 느슨하게 시작했기 때문에 가능했다. 역할을 미리 정했으면 오히려 어색했을 것이다.
예전 소프트웨어 개발에서는 요구사항 문서를 썼다. 도메인 전문가가 원하는 것을 정리하고, 기획자가 번역하고, 개발자가 코드로 만들었다. 몇 주에서 몇 달이 걸렸다.
이 세션에서는 "세모가 50초 안에 둔 거고 숫자가 나오면 초읽기야"라는 한 문장이 몇 분 만에 코드가 되었다. 요구사항 문서가 필요 없었다. 대화가 곧 요구사항이었다.
그런데 이게 가능했던 이유가 있다. 느슨하게 시작했기 때문이다. 요구사항을 먼저 정하고 시작했으면, 그 요구사항에 맞는지 아닌지를 확인하느라 시간이 갔을 것이다. 요구사항 없이 시작했기 때문에, 결과를 보고 즉석에서 방향을 잡는 것이 자연스러웠다.
계획이 없으니 실패도 없다. 예상과 다른 결과가 나와도 그게 실패가 아니라 새로운 방향의 시작이다. 시간 데이터가 덤으로 나온 것처럼. 접바둑 초기 배치 누락이 접바둑 분석의 시작이 된 것처럼.
느슨함이 실패를 발견으로 바꾼다.
다음 글에서는 이 대화들이 나를 어디로 데려갔는지를 이야기한다. 대화 전의 나와 대화 후의 내가 어떻게 달라졌는가.