하이퍼그래프 붙인 에이전트 도구에서 코덱스로 만든 미술관 지도까지 — 밤사이 개인 작업이 줄줄이 공개됐고, 자체 OCR 모델이 클로바를 앞섰다는 본인 전언(비교 조건 미공개)도 나왔다

23일 밤 9시 25분, 한 참여자가 자기 에이전트 도구에 하이퍼그래프를 붙였다고 알렸다. 하이퍼그래프는 연결선 하나가 둘 넘는 대상을 한꺼번에 묶을 수 있는 관계 구조다. 이 참여자는 이를 붙인 덕에 엣지 근거를 복합적으로 쿼리할 수 있게 됐다고 설명했다. 에이전트가 참고하는 지식을 단순한 목록이 아니라 서로 얽힌 관계로 다루고 찾으려는 시도로 보인다.

자정을 앞둔 23시 52분에는 다른 참여자가 코덱스로 만든 미술관 지도 웹앱을 보여 주며 "실제 전시정보도 볼 수 있습니다"라고 소개했다. 코덱스 하나로 지도와 전시 정보를 묶은 웹앱을 혼자 만들어 보인 셈이다. 그런데 2분 뒤 이 참여자의 입에서 나온 건 자랑보다 비용 이야기였다.

구글 사진 api 비용 너무 비싸요......

이 참여자는 사진 API 비용 때문에 이미지를 위키 이미지로 되돌릴 생각이라고 했다. 웹앱은 이미 만들어 보여 줄 수 있는 단계였지만, 굴리는 과정에서는 외부 API 요금이 설계를 되돌리게 만든 셈이다. 위키 이미지로 돌아간다는 건 사진의 선택 폭을 조금 내주더라도 매달 나가는 요금을 줄이겠다는 계산으로 읽힌다.

비슷한 시각인 23시 58분, 또 다른 참여자는 사진 데이터를 R2 저장소에 넣고 인덱싱해 검색되게 한 구성을 소개하며 "사진데이터는 다 r2 넣고"라고 적었다. 사진을 바깥 API로 불러올지, 직접 쌓아 두고 검색할지를 두 사람이 서로 다른 방식으로 풀고 있었던 것으로 읽힌다. 불과 몇 분 사이에 같은 사진 데이터 문제를 두고 두 갈래의 답이 방에 나란히 놓였다. 앞의 사례가 요금 때문에 한발 물러섰다면, 이쪽은 사진을 직접 들고 있는 쪽을 택한 것으로 보인다.

새벽 2시 무렵에는 성능 소식이 올라왔다. 한 참여자가 자체 OCR 모델이 클로바를 잡았다고 전하면서도 "근데 아직 모든 벤치에서 국내 모든 모델을 이긴건 아니라서"라고 스스로 단서를 달았다. 이 비교는 자체 모델을 둔 쪽의 전언이며, 어떤 벤치에서 몇 점이 나왔는지는 대화에 담기지 않았다. 결과를 과장하기보다 어디까지 왔는지를 스스로 선 긋는 방식이 눈에 띈다.

밤 9시부터 새벽 2시까지 다섯 시간 가까이 이어진 이 화제에는 12명이 113건을 주고받았다. 하이퍼그래프에서 웹앱, OCR까지 분야는 제각각이었지만, 각자 만든 결과물을 밤사이 바로 방에 꺼내 보이는 흐름이 이어졌고, 성능을 스스로 에누리한 OCR 사례까지 더해지며 공개의 온도는 자랑보다 점검에 가까웠다. 동시에 미술관 지도 사례처럼 사진 API 같은 운영 비용이 설계를 되돌리게 한다는 점은, 개인 작업의 다음 관문이 만드는 일보다 굴리는 비용 쪽에 있음을 시사한다.