AI 활용 회고 (2025)

AI를 본격적으로 생산성을 개선하기 위해 사용하기 시작한 것은 작년부터입니다. 그 이전부터 관심을 가지고 뭔가 시도해봤지만 그저 ‘이런 식으로 동작한다’는 수준의 이해를 위한 수준일 뿐이었습니다. 하지만 작년과 올해 사이에 AI 서비스들은 급격하게 발달해 단순히 동작 원리를 파악하거나 동작 수준을 가늠할 필요 없이 그냥 원하는 바를 직접 표현해 적극적으로 사용하며 이 사이에 AI의 존재가 투명해지는 단계에 이르렀습니다. 그래서 지난 오프라인 백업 전략 회고처럼 올해 동안 AI를 활용한 방법, 이로 인한 생산성 개선, 여전히 주의해야 할 점, 이후 발전 방향 등에 대해 설명하고 잘 한 점과 그렇지 않은 점들을 회고해보겠습니다. 참고로 개인적으로 AI를 종종 기계라고도 부르곤 하는데 글에서 AI와 기계는 같은 대상을 가리키고 이들을 혼용하고 있습니다.

작년 하반기에 제가 사용하던 이동통신회사에서 퍼플렉시티라는 서비스를 제공한다고 광고하기 시작했습니다. 이때는 이런 서비스가 있다는 것 자체를 몰랐고 이동통신회사가 몇 십 만원 가치에 해당하는 서비스를 1년 동안 무상 제공한다고 광고해도 이게 무슨 소린지 몰랐습니다. 그렇게 시간을 보내다가 뭔지 모르겠고 또 어디에 쓰는지도 모르겠지만 뭐 등록하지 않고 지나가는 것 보다는 낫겠다 싶어 등록했고 또 그대로 한동안 방치하다가 올해 들어 조금씩 만져보기 시작했고 본격적으로 생활과 일에 AI를 사용하게 된 계기가 되었습니다. 퍼플렉시티는 대략 라마 기반의 자체 모델을 가지고 있기는 하지만 다른 회사의 서비스들을 중계해 주는 점이 핵심입니다. 자체 모델을 통한 답변은 답변 자체만으로는 전혀 인상적이지 않지만 자신이 크롤링한 여러 웹페이지의 정보에 기반해 답변하는 방식 자체는 의미가 없지 않았습니다만, 기능이 안정되는 동안에는 이 역시 그리 인상적인 것은 아니었습니다. 하지만 ChatGPT나 Gemini 같은 여러 서비스들이 제각각 구독 서비스를 출시하는 상황에서 그저 궁금하다고 이 서비스들을 각각 결제해서 사용해보기에는 돈도 없고 또 시행착오에 시간을 쓰기도 어려워보였습니다. 하지만 퍼플렉시티 하나를 결제하면 각자의 최신 모델을 즉시 사용할 수 없는 때도 있지만 ChatGPT, Gemini, Grok, Sonar, Claude Sonnet 등을 드랍다운 박스를 눌러 그때그때 바꿔가며 사용할 수 있습니다. 이 점 때문에 각 회사의 최신 모델을 조금 늦게 사용하게 되더라도 그 서비스를 결제하는 대신 퍼플렉시티를 사용하기로 결정했습니다. 퍼플렉시티 자체는 딥 리서치를 한동안 사용했지만 지금은 거의 스페이스와 다른 서비스를 중간에서 대신 결제해주는 역할에 집중해 사용하고 있습니다.

퍼플렉시티를 사용하며 올해 가장 많이 바뀐 것은 지난 디지털 휴먼 API (2025)에 조금 설명한 여러 가지 자동화 방식입니다. 이전 시대에는 일과 생활에 여러 가지 자동화를 위해 여러 도구를 사용했습니다. n8n은 IFTTT처럼 여러 서비스를 쉽게 이어붙일 수 있고 직접 호스팅할 수 있어 한동안 여러 자동화에 사용했고 지금도 사용하고 있습니다. 가령 어떤 메일을 받으면 지라에 할 일을 생성하거나 매일 같은 시간에 데이터베이스 덤프를 생성하는 일에 사용합니다. 후자는 클래식하게 cron을 사용하곤 하지만 macOS에서는 이 방식을 권장하지도 않고 또 웹 인터페이스를 통해 한 곳에서 관리하는 것이 제 입장에서는 훨씬 편했습니다. 또 코드를 통한 자동화를 제공하지 않는 윈도우 GUI 애플리케이션을 자동화하는데는 아주 오래된 도구인 AutoIt을 사용해 화면을 직접 조작했습니다. 처음에는 인터페이스의 정확한 화면상의 정확한 좌표를 입력했지만 시간이 지나 도구에 익숙해지고 나서는 조작할 인터페이스 핸들을 찾아 인터페이스에 직접 메시지를 보내는 방식으로 자동화하곤 했습니다. AutoIt은 현대에는 많이 낡았지만 여전히 잘 동작했고 또 이런 역할을 하는 현대적인 소프트웨어는 없거나 거의 없었습니다. 그런데 AI 서비스를 사용하면서 자동화 방식이 크게 바뀌었습니다. 이전에는 코드 작성을 최소화하려고 노력했습니다. 일할 때는 누군가 엑셀 스크립트를 사용해 뭔가 만들려 하면 최대한 코드 사용을 피하는 방식을 권장했습니다. 근본적으로 저나 저와 비슷한 직군들 모두 전문적으로 코드를 만드는 사람이 아니기 때문에 우리들이 직접 코드를 만드는 일은 생산성이 떨어지고 또 코드를 한 번 만드는 데까지는 어떻게 해낼 수 있을지 모르지만 이를 장기간에 걸쳐 유지보수하는 일은 또 다른 차원의 일이기에 최대한 코드 작성을 피했습니다. 그런데 AI를 사용하면서 더이상 코드를 피하지 않게 되었습니다.

2025년 말 현재 자동화 상당수는 파이썬 스크립트를 작성해 사용합니다. 물론 모두 제가 직접 작성한 것이 아니라 퍼플렉시티 인터페이스를 거쳐 ChatGPT에게 요구사항을 나열하고 파이썬 스크립트를 작성해달라고 해서 얻은 코드를 아주 조금만 수정해서 실행하고 있습니다. 가령 최근 구글포토 대신 Immich라는 셀프호스팅 가능한 소프트웨어를 사용하기 시작했는데 기존 퍼포스에 보관하던 대량의 사진 파일 뭉치를 어떻게 새로운 환경으로 옮겨야 할지 엄두가 안 났습니다. 하지만 기계에게 현재 경로 하위의 모든 경로를 검사해 모든 이미지 파일을 찾아 SQLite 파일에 기록한 다음 지정한 Immich 서버에 하나씩 올리고 성공적으로 올린 다음에는 SQLite에 올렸다고 표시하는 스크립트를 작성해 달라고 하자 그 자리에서 뚝딱 코드를 작성해 주었습니다. 이 코드는 이미 다른 누군가가 작성해 둔 Immich 서비스에 대량으로 파일을 업로드하는 라이브러리를 사용하고 있었는데 만약 제가 비슷한 역할을 하는 스크립트를 만들려고 시도했다면 저런 라이브러리가 있다는 사실을 한참만에야 알았을 겁니다. 기계가 출력한 코드는 제 취향에 맞는 사소한 수정이 필요했는데 이 수정 역시 제가 하지 않고 기계에게 추가 요구사항을 말해 수정하도록 했습니다. 가령 기계가 처음 만들어준 코드는 인자로 경로를 받게 되어 있었는데 제 취향은 인자 대신 스크립트 내부에 설정하는 것이었습니다. 그래서 인자를 내부 변수로 옮기도록 하고 처음에는 사진 파일을 읽어 직접 Immich 서버에 이 파일이 이미 업로드되었는지 여부를 확인하도록 되어 있었는데 한 번 업로드한 파일은 업로드 여부를 SQLite에 기록해 서버에 다시 요청하지 않도록 수정했습니다. 또 스레드를 통해 여러 파일을 동시에 업로드하도록 했는데 저는 스레드에 대해 아무 지식도 없었지만 기계가 알아서 스레드 안전한 코드를 작성했고 동시에 16개 스레드로 파일을 업로드하도록 수정했습니다. 덕분에 저는 그저 컴퓨터를 켜놓고 자러 갔고 자는 사이에 그동안 쌓인 모든 사진을 Immich 서버에 마이그레이션 했습니다. 만약 이 작업을 제가 직접 하려 했거나 직접 스크립트를 작성하려 했다면 이렇게 빨리 마이그레이션을 마칠 수 없었을 겁니다.

이런 스크립팅 자동화는 업무 영역에서도 생산성을 크게 끌어올렸습니다. 게임디자인 직군의 골때리는 점은 스스로 작성해 제안하는 기능이 의도대로 동작할지 여부를 스스로 잘 모른다는 것입니다. 가령 필드에서 몬스터가 전투륽 시작하면 플레이어 캐릭터를 끝까지 따라와 전투를 계속한다고 해 봅시다. 이렇게 동작하는 대신 누군가 ‘몬스터가 체력이 낮아지면 도망치도록 하면 재미있지 않을까?’ 같은 으견을 제시해 이를 개발하도록 만드는 일이 저희가 할 일입니다. 그런데 아이디어가 나타난 시점에 이 아이디어를 개발해야 하는 게임디자이너는 이 기능이 기존 빌드에 잘 어울려 동작할지 여부를 평가하기 어렵습니다. 여러 사람들이 우려를 표시하지만 그들의 우려 역시 실제 결과를 보기 전에는 모두가 추측일 뿐입니다. 만약 실컷 개발해 테스트해보니 결과가 좋지 않았다면 그나마 다행입니다. 만약 규모가 큰 컨텐츠에 큰 비용과 긴 기간에 걸쳐 개발했는데 막상 테스트해보니 어떻게 튜닝해도 남은 기간 안에 재미있게 만들기 어려울 수 있습니다. 아직 개발 중이라면 컨텐츠 전체를 드랍 할 수도 있겠지만 라이브 중이라면 어쨌든 다음 대규모 업데이트를 해야 합니다. 그러면 뻔히 문제를 알면서도 업데이트 할 수밖에 없습니다. 고객들로부터 욕 먹을 것을 알면서도 서비스를 진행할 수밖에 없습니다. 그런데 기계가 스크립트를 쉽게 작성해주기 시작하면서 어떤 메커닉은 문서를 작성하기 전에 게임디자이너 수준에서 미리 시뮬레이션 해볼 수 있게 되었습니다. 가령 몬스터 AI가 모두 하드코딩 되어 있고 우리들은 코드에 접근할 수 없는 상태에서 몬스터의 행동을 고치고 싶다고 해봅시다. 이전 같으면 우리들이 할 수 있는 일이라곤 새로운 동작을 문서로 만드는 것 뿐입니다. 하지만 이제는 현재 게임의 핵심 동작을 비슷하게 수행하는 CLI 기반 스크립트를 작성한 다음 여기에 새로운 몬스터의 행동을 추가해 실제 게임에 동작이 변경될 때 일어날 일을 예상할 수 있습니다. 바로 문서를 작성하기 시작할 때는 알 수 없었을 사소한 문제, 게임디자인 관점의 코너 케이스 따위를 시뮬레이션을 통해 미리 파악할 수 있습니다. 꽤 잘 동작하는 단위 기능의 시뮬레이션을 작성하는데 넉넉하게 한 시간이면 충분합니다. 그 다음은 조금씩 튜닝해 가며 아이디어를 검증하거나 개발이 진행된 다음 예상되는 튜닝 작업들을 미리 해볼 수도 있습니다. 이제 우리들이 제출하는 문서는 이전처럼 추측에 기반하는 대신 상당 부분 시뮬레이션을 거친 결과입니다. 어느 정도 확신을 가지고 개발할 수 있습니다.

팀에 따라 조금씩 다르긴 하지만 문서를 작성할 때 같은 문서 안에서 상호 충돌하는 요구사항을 작성하거나 용어를 틀리거나 오타를 내는데 민감하게 반응하는 팀이 있습니다. 사실 팀 밖으로 나가는 문서를 작성할 때 이 정도는 신경 써야 합니다. 하지만 문서를 작성하는 도구들은 예나 지금이나 별로 개선되지 않았습니다. 코드 에디터가 선언해 놓고 사용하지 않는 변수를 지적하거나 오타에 실시간으로 줄을 그어주고 또 선언하지 않은 키워드를 사용하려 할 때 경고하는 등의 나름 첨단 기술을 사용해 코드를 작성하는데 비해 문서를 작성할 때는 지금도 이런 기술들의 도움을 받을 수 없습니다. 개발팀 전체에 걸쳐 정의된 용어 대신 다른 용어를 잘못 사용하더라도 문서 작성 도구는 기껏해야 이 단어가 맞춤법 검사 사전에 있는지 검사해 빨간 줄을 그어주는 수준일 뿐입니다. 이런 열악한 환경에서 같은 문서에 앞서 제안한 요구사항과 뒤쪽에 언급된 다른 요구사항이 서로 충돌하더라도 이를 문서를 작성하는 사람이 기계적으로 확인할 방법은 없습니다. 그러니까 이전까지는 그랬습니다. 하지만 이제 이런 검사를 실시간은 아니라도 기계를 통해 확인할 수 있게 되었습니다. 가장 큰 변화는 게임디자인 실무자들이 기획서를 작성할 때 주로 참고하는 컨셉 기획서 또는 하이레벨 문서 또는 마일스톤 목표와 작성한 기획서를 비교해 서로 충돌하거나 빠뜨린 내용이 없는지 기계에게 직접 질문할 수 있습니다. 또 같은 문서 상에 있는 서로 충돌하는 기능 요구사항 뿐 아니라 같은 마일스톤에 제출할 여러 기획서에 걸쳐 충돌하거나 서로 문제를 일으킬 가능성이 있는 요구사항이 있는지 미리 검사할 수 있습니다. 기계가 제시하는 검토 결과를 어디까지 신뢰해야 할까요? 개인적인 경험 범위에서는 상당히 신뢰할만합니다. 만약 기계에게 이런 검증을 시키지 않았다면 개발 도중 알게 됐을 문제들을 개발하기 전에, 문서 작성을 마치기도 전에 미리 알아낼 수 있습니다. 여러 사람이 서로 다른 문서를 작성하며 서로의 문서가 제안하는 기능들이 서로 충돌하지 않도록 관리하는 것은 대단히 어렵고 시간 소모적인 일입니다. 하지만 기계가 모든 문서의 최신 버전을 읽고 서로 충돌하지 않는지, 마일스톤 목표 전체를 커버하는지 등을 한번에, 그리고 아주 빨리 검사해주고 이에 기반해 우리들은 드디어 현대적인 도구의 도움을 받아 훨씬 개선된 문서를 작성할 수 있게 되었습니다.

AI는 생활과 업무 모두에서 검색의 개념을 완전히 바꿨습니다. 이전 시대의 검색은 크게 두 가지 문제가 있었습니다. 하나는 검색할 대상이 검색 가능한 솔루션에 기반하느냐 하는 것입니다. 가령 윈도우의 검색 기능은 오래 전이나 지금이나 전혀 쓸모가 없습니다. 인덱싱 기능은 뭔가 행동하며 시스템 전체를 느리게 만들지만 단 한번도 제대로 작동한 적이 없습니다. 기껏해야 Everything 같은 파일시스템에 기반한 파일 이름 검색 도구를 사용할 뿐입니다. 문서 내부를 검색해 결과를 내는 제대로 된 솔루션은 아주 드뭅니다. 다른 하나는 검색 대상이 서로 다른 솔루션을 통해 기록되고 있고 이 검색이 전혀 통합되지 않는 것입니다. 가령 어떤 문서는 원노트에 있고 또 다른 문서는 컨플루언스에 있으며 또 다른 문서는 로컬에 파일 모양으로 저장되어 있습니다. 검색이 이들 모두를 대상으로 하면 참 좋겠지만 슬프게도 컨플루언스에서 검색하고 원노트에서 따로 검색하고 또 파일시스템을 따로 검색해야 합니다. 기계를 검색에 응용하기 전까지는 FileLocator Pro 같은 딱 봐도 구닥다리같이 생겼지만 어쨌든 잘 동작하는 검색 프로그램을 별도로 구입해 사용하고 있었습니다. 하지만 어떻게든, 어떤 방식으로든 검색이 가능하다 하더라도 이들이 서로 통합되지 않으며 서로 각기 다른 수준의 검색 기능과 서로 다른 검색 기능에 의해 동작하는 점은 생산성을 크게 떨어뜨렸습니다. 이전에 작성한 기획서, 오래된 메모, 회의록 따위가 서로 다른 솔루션에 기록되어 있다면 검색은 보통 문제가 아닙니다. 심지어 시간이 지나면 정확히 어떤 단어를 검색해야 하는지도 확실하지 않습니다. 이 상황에서 기계는 인덱스를 통합해 제공할 수만 있다면 이 모든 문제를 해결할 수 있습니다. 그래서 기계에게 여러 곳에 흩어져 있는 정보를 인덱스화하는 스크립트를 만들어달라고 해서 이 스크립트를 사용해 인덱스 문서를 만든 다음 이 문서를 기계에게 먹여 검색하기 시작했습니다.

퍼플렉시티에는 스페이스라는 기능이 있습니다. 아마 여느 AI 제품들 모두 비슷하거나 거의 똑같은 기능을 제공할 겁니다. 같은 스페이스에 있는 모든 대화는 서로 인스트럭션 프로프트를 공유하고 또 스페이스 단위에 업로드 된 파일을 공유합니다. 그래서 스페이스에 파일을 업로드 한 다음 인덱싱이 끝나면 아무 스레드를 새로 시작하더라도 스페이스 단위의 상태는 유지됩니다. 퍼플렉시티는 프로 서브스크립션 기준 한 스페이스에 파일 50개 까지, 각 파일은 50메가까지 업로드 할 수 있습니다. 그래서 이 제한에 맞춰 인덱스 파일을 작성했습니다. 먼저 컨플루언스에 있는 문서들은 API를 통해 끄집어내 마크다운 한 덩어리로 만들었습니다. 원노트에 있는 노트들도 마크다운 파일 하나로 만들고 또 로컬에 파일 모양으로 저장되어 있는 모든 문서들을 합쳐 마크다운 파일 하나로 만들었습니다. 다음으로 각 파일에 이 파일에 들어있는 텍스트가 무엇인지 설명했습니다. 어떤 파일에는 회의록이 들어있고 어떤 파일에는 개인 메모가 들어있는데 이를 기계에게 설명해야 하기 때문입니다. 이렇게 여러 솔루션들로부터 뽑은 인덱스 파일은 말이 좋아 인덱스이지 사실은 그냥 사람이 읽을 수 있는 마크다운 파일일 뿐입니다. 다만 퍼플렉시티의 스페이스 당 50파일 업로드 제한 안에서 사용하기 위해 여러 파일을 좀 머지했을 뿐입니다. 또 과거에 검색을 위한 인덱싱과 현대에 기계가 파일을 이해하기 위해 임베딩 모델을 통해 벡터 데이터베이스에 기록하는 과정은 완전히 달라 그저 텍스트를 사람이 읽을 수 있는 모양으로 정리하는 것 이외에 딱히 더 할 수 있는 일도 없습니다. 하지만 이 덕분에 여러 솔루션에 여러 검색 방식을 사용해야 했던 데이터들을 일관된 마크다운 모양으로 정리해 기계에게 제시할 수 있는 모양으로 만들었습니다. 그리고 퍼플렉시티 스페이스에 이 모든 마크다운 파일을 업로드 한 다음 몇 분 기다리면 지금까지는 따로따로 검색해야 하거나 검색이 불가능하거나 서로 검색 방식이 달라 검색 작업을 곤란하게 만들었던 텍스트들이 모두 일관된 검색 방식을 사용할 수 있는 통합된 상태로 준비됩니다.

이제 실제 검색할 차례인데 검색은 이전의 키워드 검색과는 완전히 다릅니다. 이제 정말로 내가 원하는 바를 입력하면 됩니다. 정확한 키워드가 뭐였는지 고민할 필요 없습니다. 대충 비슷한 단어를 말하면 알아서 그 비슷한 다른 정확한 용어를 사용한 문서를 찾아주고 또 정확한 용어를 사용하지 않은 문서도 찾아줍니다. 또 문서를 찾아 링크를 보여주기만 하는 것이 아닙니다. 이제 기계는 프롬프트에 따라 문서를 읽고 문서 내용을 제가 제시한 프로프트에 맞춰 재가공해줍니다. 가령 어떤 기능에 대해 지난 수 주에 걸친 회의록을 모두 찾아 의견이 어떻게 발전해 왔는지 시간 순서대로 정리해달라고 하면 이 주제를 언급한 여러 회의록을 읽어 같은 주제의 변경 과정을 차례로 나타내줍니다. 또 회의록 뿐 아니라 같은 주제를 다른 부서에서 다룬 문서가 있다면 그 문서의 내용까지 가져옵니다. 아마 일반적인 검색을 사용했다면 이런 정리 작업은 시간을 제법 잡아먹을 뿐 아니라 다른 부서가 작성한 문서는 그 존재 자체를 모를 수도 있습니다. 하지만 여러 솔루션으로부터 도출된 데이터를 통합한 검색은 이런 경계를 없애버립니다. 이제 검색은 키워드를 나열하고 결과에서 필요한 정보를 찾아 다음 작업을 계속해는 과정의 일부가 아닙니다. 결과를 직접 입력하면 기계가 중간 과정을 모두 직접 수행해 직접 결과를 획득하는 과정입니다. 이제 적어도 제가 접근할 수 있는 여러 가지 솔루션을 모두 통합한 검색 환경을 가지게 되면서 문설ㄹ 작성한 다음 문서를 기계에게 보여주고 지금까지의 논의와 어긋나는 부분이 있을지 질문하고 어긋난다면 어떤 논의와 어긋나는지 확인할 수도 있습니다. 기획서의 어느 문단에 짤막하게 언급된 예외사항 처리 방식은 두 달 전에 협의한 방식과 다를 수 있습니다. 이전 같으면 이 사실을 인지하지 못한 채 그냥 기획서를 제출해 나중에서야 문제를 확인하거나 문제가 있음을 아예 모른 체 개발을 진행해버렸을 수도 있습니다. 하지만 이제 기록이 존재하기만 한다면 이 통합된 검색 환경은 끈질기게 내용을 찾아 문제를 지적해줍니다. 이제 제가 제출하는 기획서는 몇달 전 협의사항마저 빠뜨리지 않고 반영한 상태가 되었습니다.

앞서 어떤 기능을 제안할 때 기계에게 스크립트를 작성하도록 해 동작을 시뮬레이션한다는 이야기를 했습니다. 덕분에 실제로 돌려보기 전에는 존재 조차 알 수 없을 동작을 미리 알아낼 수 있습니다. 그런데 여러 솔루션에 걸쳐 흩어진 정보를 통합한 곳이 있다면 혹시 이 정보를 종합해 동작하는 어떤 구현체를 만들 수 있지 않을까요? 아직 아주 잘 되지는 않지만 정보 범위를 제한하면 기초적인 수준에서는 가능합니다. 가령 대미지 연산 공식의 일부를 수정한다 칩시다. 이전에는 의도를 공식으로 만들어 제안하고 개발되어 실제 동작하기 전까지는 테스트할 방법이 없었다가 이제 스크립트로 시뮬레이션 해볼 수 있는 단계까지는 왔다는 이야기를 했습니다. 단일 스레드에 대미지 연산 공식을 설명한 문서와 전투 과정을 설명한 문서를 제시한 다음 이 문서들에 근거해 동작 시나리오를 작성해 사람이 검증할 수 있게 하거나 몇몇 부분에 핸들을 삽입한 시뮬레이션 스크립트를 작성하도록 하면 꽤 잘 동작합니다. 플레이어 캐릭터와 몬스터가 서로 공격을 주고받고 대미지를 주는 과정을 로그 모양으로 출력하고 플레이어 캐릭터의 현재 상태와 몬스터의 현재 상태를 지켜볼 수 있는 모양으로 만들 수도 있습니다. 만약 앞서 스페이스 단위로 모든 솔루션으로부터 나온 모든 정보를 통합한 상태에서 스크립트 작성 요청이 잘 동작하는 수준에 도달하면 정말 훌륭하겠지만 아직 그 정도는 아닙니다. 하지만 정보 범위를 제한한 다음 프롬프트에 직관적으로 설명 가능한 수준의 구현을 요청하면 기계는 꽤 훌륭하게 동작합니다. 이전에는 시뮬레이션 요구사항을 프롬프트에 정확히 언급하는 방식을 사용했다면 이제 그냥 문서를 주고 그 문서 내용을 적당한 모양으로 만들어내라고 하면 됩니다. 또 여기에 사용하는 문서는 앞서 설명한 대로 기계가 기존 논의사항이나 다른 문서의 내용과 충돌하지 않는지 검토해 이에 맞춰 수정한 문서들입니다. 모르긴 몰라도 제가 원하는 통합된 정보를 기반으로 내가 원하는 부분만 시뮬레이션 하는 코드를 만들어달라는 요구사항이 잘 동작하는 기계가 그리 머지 않은 시점에 만들어질 수 있을 겁니다.

그리고 이제 문서 초안을 기계가 작성하는 단계에 이르렀습니다. 사실 문서 전체를 기계에게 작성해 달라고 하는 단계는 기술적으로는 가능하겠지만 아직 우리들의 일하는 방식이 이를 감당할 수 있지 않다고 생각합니다. 여전히 문서를 브리핑 할 일이 많습니다. 이런 상황에서 문서를 기계가 작성하면 사람이 논리를 전개해 나가는 방식과 일치하지 않기 때문에 브리핑 퀄리티가 떨어집니다. 그래서 브리핑이 필요한 문서는 아직까지는 기계가 직접 초안을 작성하게 하지는 않고 있습니다. 대신 문서를 작성하고 나서 앞서 설명한 대로 기존 협의사항을 반영하는지, 다른 문서나 자기 스스로의 내용과 충돌하지 않는지 검사하는 수준에 머무르고 있습니다. 하지만 기술적으로는 이미 가능하다고 보기에 제 생각의 전개 방식을 기계가 흉내내도록 프롬프트를 작성할 수 있을 거라고 예상합니다. 시행착오가 좀 필요하겠지만 기계가 브리핑을 포함한 문서 초안을 작성하는 단계까지 도달은 얼마 남지 않았다고 생각합니다.

글쓰기에 큰 도움을 받고 있습니다. 리서치하고 싶은 주제가 생기면 기계에게 물어보기 시작해서 질문을 이어가다 보면 이 주제를 관통하는 키워드들을 자연스럽게 알게 됩니다. 키워드 각각에 대해 질문하고 질문에 근거가 되는 자료들을 살펴보면 글을 구성할 목차를 어렵지 않게 생각해낼 수 있습니다. 이전 시대에 키워드로 검색해 검색 결과를 읽는 과정도 사실 지금과 크게 다르지는 않습니다. 다만 지금은 키워드 검색에 비해 의도를 직접적으로 표현할 수 있습니다. 가령 현대 수집형 게임의 이해를 리서치한다면 수집형 게임들의 역사로부터 시작하려 하는데 키워드 검색 기반으로는 누군가가 작성해 놓은 역사 관련 문서나 논문이 없다면 꼼짝 없이 하나하나 검색해 역사를 스스로 구성하는 수밖에 없습니다. 하지만 기계와 함께라면 직접 수집형 게임의 역사를 조사한다고 의도를 정확히 밝혀 기계가 이 의도에 맞춰 검색 결과를 구성하게 할 수 있습니다. 같은 검색 결과라도 역사라는 의도를 반영한 결과와 반영하지 않은 결과는 리서치 속도와 방향을 결정하는데 굉장히 큰 영향을 줍니다. 근래에 작성하는 글들은 가능하면 문장의 출처를 표기하고 있습니다. 블로그 글 정도를 작성하는데 주장의 출처를 밝힐 필요는 딱이 없을 수 있지만 문단이나 문장을 작성하기 위해 참고한 문서를 언급해 놓으면 미래에 저 자신이 다시 그 글을 읽을 때 도움을 받을 수 있다는 장점이 있습니다. 하지만 출처를 관리하는 일은 상당히 피곤합니다. 잠깐만 실수하면 엉뚱한 문장에 엉뚱한 출처 링크를 붙일 수도 있습니다. 이럴 때 기계의 도움을 받습니다. 기계에게 글 내용과 출처 링크의 내용이 올바르게 배치되었는지 검사해 달라고 할 수 있는데 이 때 어지간한 실수를 모두 커버할 수 있습니다. 기계가 문단을 읽고 그 끝에 달린 출처 링크를 방문해 양쪽의 내용을 살펴본 다음 일치하는 부분, 부분적으로 일치하는 부분, 일치하지 않는 부분을 알려줍니다. 저는 그 결과를 보고 적절히 고치기만 하면 됩니다. 비슷한 요령으로 오타 검사에도 활용하는데 전통적인 오타 검사가 기계적으로 작동했다면 기계에게 시키는 오타 검사는 이제 오타 뿐 아니라 어색한 표현과 맥락 상 어울리지 않는 표현들을 찾아내 수정 방향까지 제안해줍니다. 문서를 작성하는 도구와 통합되어 있지 않아 과정이 조금 귀찮긴 하지만 그나마 AI 에이전트가 통합된 브라우저를 사용하면 이 과정이 훨씬 편해집니다. 한 번 사용해 보고 나면 이전 시대의 단순한 오타 검사로 돌아갈 수 없습니다.

AI 에이전트가 탑재된 브라우저는 제 메인 AI 서비스가 퍼플렉시티여서 자연스럽게 코멧 브라우저를 사용하고 있습니다. 크롬 브라우저에 퍼플렉시티 AI 에이전트를 포함한 브라우저입니다. 브라우저에 탑재된 AI 에이전트는 일상적인 비정형 작업을 처리해줍니다. 속도가 상당히 느리기는 하지만 그런 작업들을 반복해야 하거나 여러 작업을 동시에 수행해야 할 때 큰 위력을 발휘합니다. 가령 회식 장소를 골라야 하는 상황에 네이버맵 웹사이트를 열고 직접 검색해볼 수도 있습니다. 하지만 네이버맵 웹사이트를 연 다음 에이전트에게 상황을 설명하고 피해야 할 음식, 이동 거리, 그 시간대에 사람이 너무 많지 않은 곳 등의 조건을 설명하고 가게 이름, 링크, 거리, 가격대 등을 표 모양으로 정리해 달라고 말하면 직접 브라우저를 조작해 검색해 결과를 보고 이를 정리해줍니다. 물론 이 시간에 제가 같은 작업을 직접 수행하는 쪽이 더 빠릅니다. 에이전트는 화면을 읽기 위해 스크린샷을 찍고 이를 서버로 보내 해석한 결과를 받는 등 낭비가 심합니다. 하지만 이 상황은 식기세척기 논란과 비슷합니다. 식기세척기는 제가 설거지하는 것보다 더 느리지만 더 나은 결과를 내고 제가 그 시간 동안 아무것도 안 해도 되도록 만들어줍니다. 에이전트도 마찬가지인데 그냥 시켜놓고 다른 브라우저 탭으로 전환해 다른 일을 하고 있으면 됩니다. 또 슬랙에서 여러 사람들의 식사 주문을 받는 상황을 생각해봅시다. 여러 사람들이 메뉴 이름을 말하고 메뉴 이름은 종종 같은 메뉴를 가리키지만 표현이 다를 수도 있습니다. 또 누군가는 앞서 메뉴 옵션을 말했다가 뒤에 수정해달라고 요청할 수도 있습니다. 이들을 직접 정리하고 주문하는 일은 상당히 피곤한 일입니다. 실수 가능성도 높습니다. 하지만 이 상황에서 에이전트에게 사람, 메뉴, 옵션 등을 표 모양으로 정리하되 메뉴와 옵션이 같은 대상을 가리키면 모두 같은 이름으로 정규화해서 표현해달라고 요청하면 순식간에 정리해줍니다. 더이상 골아프게 모든 대화를 하나하나 읽어 메뉴를 취합할 필요가 없습니다.

최근 블로그에 탱딜힐의 기원, 턴 기반 게임디자인, 호요버스 게임의 성장시스템 같은 글을 작성했는데 제가 이런 주제들을 잘 알고 있어 작성한 글들이 아닙니다. 앞서 설명한 대로 기계의 도움을 받아 리서치한 결과에 기반해 작성한 것입니다. 그런데 이 글들은 모두 에이전트가 탑재된 브라우저의 도움을 크게 받았습니다. 글 길이가 길어지면 프롬프트에 글 전체를 직접 붙여넣기 상당히 어려워집니다. 하지만 에이전트를 탑재한 브라우저는 긴 글이라도 직접 전체를 읽고 뭔가를 요청할 수 있습니다. 그래서 컨플루언스에서 미리 작성한 글을 여러 탭으로 연 다음 각각의 탭에 서로 다른 명령을 내립니다. 한 에이전트에게는 오타, 맞춤법, 어색한 표현 위주로 검사를 스킵니다. 다음 에이전트에게는 앞서 소개한 글 내용과 각주의 내용이 서로 일치하는지 검사하고 일치할 경우에는 더 나은 자료가 있는지, 일치하지 않는 경우에는 일치하는 자료를 제안하도록 합니다. 그 다음 에이전트에게는 글 전체에 걸쳐 서로 충돌하는 내용과 설명이 부족한 내용, 너무 어려운 표현이나 복잡한 표현을 검사하도록 합니다. 물론 검사하는데 그치지 않고 수정 제안을 함께 출력하도록 합니다. 다른 탭에도 같은 글에 필요한 작업들을 시킨 다음 첫 탭으로 돌아가보면 여러 에이전트가 에디터를 직접 조작해 동시 편집하는 모습을 볼 수 있습니다. 그리고 앞쪽부터 작업이 완료되는 대로 결과에 기반해 글을 수정합니다. 오타와 각주를 수정하고 어려운 표현을 정리하고 서로 충돌하는 내용을 조율합니다. 그리고 다시 첫 탭으로 돌아와 같은 질문을 반복해 수정되지 않은 부분이 있는지 다시 검사합니다. 만약 이 과정을 제가 직접 수행한다면 일단 실수가 많을 수밖에 없고 동시에 여러 가지 맥락으로 글을 읽으며 수정하기는 쉽지 않습니다. 특히 글이 길어지면 글 전체에 걸쳐 충돌하는 내용을 찾아내기도 쉽지 않습니다. 하지만 에이전트가 탑재된 브라우저를 사용하면 여러 가지 맥락의 서로 다른 수정 작업을 동시에 수행할 수 있고 그 수준도 상당히 높습니다.

작년에 이동통신회사로부터 받은 퍼플렉시티 1년 무료 버전은 이미 끝났습니다. 이미 올 한해 동안 기계에 적극적으로 의존하는 삶을 살아 왔기에 어떤 AI 서비스든 하나 선택해 다음 1년간 사용할 생각인데 여전히 어느 한 제품을 선택해 완전히 정착할 단계는 아닌 것 같아 인구 당 세계에서 가장 유료 결제 사용자 비율이 높다는 ChatGPT를 사용하는 대신 이번에도 퍼플렉시티를 선택했습니다. 퍼플렉시티가 ‘Best’라며 어떻게든 사용하게 만들려고 노력하는 자체 모델은 여전히 전혀 인상적이지 않은 결과를 보여줍니다. 하지만 퍼플렉시티를 통해 사용할 수 있는 다른 회사들의 모델은 꽤 쓸모있고 이들 각각을 별도로 구입하지 않아도 됩니다. 올해의 핵심은 자동화 방식의 완전한 변화, 완전히 통합된 검색 환경, 그리고 드디어 문서도 현대적인 방식으로 기계의 도움을 받으며 작성할 수 있게 된 것입니다. 아마 내년 한 해가 지나고 나면 시장에 제품들도 크게 바뀌고 제가 기계를 사용하는 방식 역시 꽤 바뀌어 있을는지도 모릅니다. 그럼 다음 1년도 기계에 의존하며 살아보겠습니다.