흩어진 세션, 기기별 종속된 세션을 연결할 방법이 없을까

퍼플렉시티 프로가 있던 시절 AI를 쓰던 방식은 거의 바이브코딩이었다. 여전히 실제 라이브 서버에 CLI용 AI를 설치해서 서버를 마구 휘젓게 다니도록 놔두기는 아직도 불안하다. 확실하게 검증됐거나, 리뷰가 끝난 사항만 정리해서 배포해야 문제가 안 생긴다는 압박감은 상당하다.

바이브코딩 패턴에선, 나는 서버와 AI 사이에 있는 중간자 역할을 맡는다. 화면에 에러가 뜨면 다시 전달하고, 수정사항을 받으면 다시 입력하기를 반복했다. 중간에 있다보니, 아무리 무지성 CCCV를 하더라도 내용을 일부 보게 되고, 옮기기 전에 이상하거나 질문이 생기면 곧잘 다시 바로 되물었다. 그 상황에서 얻는 배움도 상당했다.

반면, 에이전트는 그 틈이 없었다. 100% 없진 않다. 틈을 비집고 들어가거나, 일부 참견할 수 있는 부분이 있긴하다. 그런데 바이브코딩 대비 현격히 줄었다. 에이전트가 계획하고 추론하면, 그대로 실행까지 넘어간다. 권한 허용을 해달라며 스톱되는 구간이 있긴한데, 거기서 일시정지해서 다른 걸 넣기가 괜히 부담스럽다. 누군가는 오픈클로를 처음부터 에이전트로 썼겠지만, 나는 오픈클로로 ‘약란 유니버스‘를 만들고, 다중 캐릭터 놀이에 빠졌었다. 그래서 서버 안에 스스로 작업하고 기록할 내용은 약란 유니버스 자체의 정체성 수정이나 오픈클로 업데이트 정도였다. 그닥 부담이 생기지 않는 작업이었다. 뭔가 잘못 실행되면 되돌리거나 재설치하는게 전혀 어렵지 않았으니까.

AI 에이전트, 에이전틱 AI

어느 수준부터 ‘에이전트’라는 말을 쓸 수 있을까? 힌트 대부분 오픈클로에서 이미 겪었던 것들이었다.

  • Tool Function
  • Action
  • Planning, Reasoning

그런데, 결국 이 3요소는 모두 LLM 모델이 지원해야 한다. 스크립트를 짜든, 워크플로우를 만들든, 스킬을 만들든, 결국 LLM 모델이 Tool Function을 제대로 지원하고, 제대로 쓸 수 있어야 한다. 계획과 추론도 마찬가지다.

그런데, 주로 접하는 챗지피티, 제미나이, 클로드 모두 이 3요소를 지원한다. 결국 에이전트는 필연적으로 쓰게 된단 의미다. 어차피 쓸 수밖에 없으니, 차라리 제어권을 내가 확보해야 한다.

작업 단위별로 세션을 쪼갠다

제어권을 내가 제대로 확보하기 위한 첫 걸음은 세션 정리였다. 애초에 질의를 입력하기 전에 대략적으로 머릿속에 떠오르는 작업 범위나 단위가 있다. 주기적으로 반복하는 모니터링일 수도 있고, 일시적이고 단순한 질의도 있다. 원래는 어떻게 썼던가 떠올려 본다.

일반 검색

일상 질문이 생길 땐 주로 퍼플렉시티 검색을 했었다. 이건 지금은 구글 AI모드로 옮겨탔으니, 여전히 큰 탈 없이 잘 쓰는 중이다. 여긴 애시당초 검색 목적으로 사용하는 것이 99%다. 그래서 세션을 쪼개는 자체도 큰 고민이 없다. 시작하는 질문 자체가 완전히 달라지고, 답을 얻으면 세션은 그대로 끝난다. 정말 가끔 다시 그 세션을 찾아볼 일이 있긴하지만, 일반 검색을 목표로 하기에 다시 찾아볼 땐 업데이트된 최신 결과가 필요하다. 그냥 새로 묻는 게 더 낫다.

서버 설정

서버 설정부턴 점점 세션이 뒤죽박죽이 된다. 제미나이, 챗지피티를 오가는 건 둘째다. 제미나이 안에서 세션을 엄청 오간다. 그나마 제미나이에 브랜치 대화를 만드는 기능이 생기면서, 뒤죽박죽이 좀 덜 해졌다.

새 채팅에서 브랜치 생성

브랜치를 만들면서부터, 세션 제목에 신경 쓰게 됐다. Nginx 로그 설정, Nginx 로그 분석, IP 차단 검토, AWS 콘솔 설정, 슬로우 쿼리 분석 등등 세션 제목을 확실하게 인지할 수 있게 정해서 넣어야 했다. 한번에 인지하지 못하면 괜히 했던 말을 계속 더 반복해서 넣게 되니, 시간과 토큰만 더 소모한다. 특히 브랜치를 만들기 전 세션과도 잘 구분해야 한다. 비슷한 키워드가 반복되기에, 기껏 관리한 세션이 서로 겹쳐버리는 것도 막아야 한다.

약간의 코딩과 프로그래밍

여기서부턴 IDE의 세상이다. 세션보다 원래 소스가 더 중요하다. 세션 히스토리를 찾아가면서 쓰긴하지만, 최대한 한번 열었을 때 목표했던 작업을 완료하고 세션 자체를 다시 열어보지 않아야 한다. 즉, 작업 시간을 확실하게 확보하던가, 작업 단위를 잘게 쪼개야 했다.

VSCode나 안티그래비티 IDE는 새 디렉터리를 열면, 옆에 에이전트창이 자동으로 새 세션을 입력하도록 유도한다. 위에 있는 세션 히스토리 버튼을 눌러야, 이전 세션을 찾아서 다시 쓸 수 있다. 그나마 UI가 점점 업데이트돼서, 이제는 세션을 실행한 프로젝트나 디렉터리가 어디였었는지도 같이 나온다. 예전엔, 이게 없어서 세션 제목으로 구분했었는데 나름 편해지긴 했다.

IDE의 세션 히스토리

필연적인 세션 흩어짐이 발생한다

웹 제미나이에서 한참 대화를 주고 받다가, 프로그래밍이 필요해보였다. IDE를 켜고 실행했더니, 다시 처음부터 요구사항을 입력해야 했다. 그래서 웹 제미나이 세션 마지막에, 이제 IDE로 옮겨서 작업할 예정이니, 우리의 대화를 IDE에 입력할 수 있게 요약해달라고도 해봤다. 적당히 잘 동작하긴 한다. 그래도 질의 응답 사이에 낀 뭔가 디테일한 1%는 빠지고 실행한다. 이걸 막으려면, 처음부터 IDE에서 대화를 시작해야 했다.

처음부터 IDE에서 대화를 시작하니, 토큰 소모가 한쪽으로 쏠리기 시작했다. 요금제를 더 올리거나, 종량제로 쓰면 되긴하지만 그러고 싶진 않았다. 제미나이는 안티그래비티와 그러했고, 챗지피티는 코덱스와 그러했다. 한쪽만 쏠리지 않게 잘 분산해서 쓰는 것이 효율적인 토큰 활용이다. 내가 귀찮고 불편해지는 만큼 리밋을 마주할 일이 줄어든다.

즉, 할당량과 리밋을 위해서라도 세션은 흩어져야 한다. 단순히 세션 하나하나가 흩어지는 것이 아니라, 어디서 발현한 세션인지도 구분해서 흩어야 한다. 하다못해 에이전트는 나를 거치지 않고 토큰을 줄기차게 소모한다. 세션을 흩어서 관리를 해야만, 에이전트가 최대한 더 많은 작업량을 확보 받는다는 의미도 된다.

기기 종속성이 있는 세션이 있다

나는 데스크탑과 노트북을 오가면서 작업한다. 데스크탑에서 VSCode나 안티그래비티 IDE에서 AI를 쓰려면 로그인 과정을 거친다. 그래서 웹 제미나이나 웹 챗지피티처럼, 세션 자체는 계정에 동기화될 줄 알았다. 아니었다. 로그인은 그저 AI를 쓰기 위한 라이선스 확인 용도일 뿐, 세션은 기기 종속이었다. 로컬에 소스 디렉터리가 있고, 그 소스를 뜯어가며 작업했으니 기기 종속되는 구조 자체는 이해가 됐다. 소스가 로컬이 아니라 원격에 있다면? 소스가 원격에 있어도, 그 소스에 주고 받은 세션은 차라리 그 원격에 있어야 하지 않을까 했다. 하지만, 그러자면 애초에 IDE가 아니라, 원격 서버에 CLI로 AI를 설치하고 썼어야 했다. 결국 돌고돌아, IDE 편의를 누릴려면, 기기 종속성이 생기는 세션은 인정해야 했다.

ChatGPT Work

그런데 똑같은 일이 챗지피티 워크에서도 생겼다. ChatGPT Work. 처음 안내가 나오고 간단히 체험할 땐 티가 안 났다. 옆에 클라우드 모양 아이콘도 뜨고, 노트북에서도 같은 계정으로만 로그인하면 세션 조회가 됐다. 그런데 두번 세번 작업량을 늘리다보니, 노트북에서 조회가 안 되는 세션이 등장하기 시작했다. 코덱스로 로컬 작업을 했던 것도 아닌데, 왜 세션이 안 뜨는 건지 한참 뒤졌다.

같은 Work에서 작업했는데 다른 Work가 됐다.

폰에서 챗지피티 워크를 쓰는 건, 그 워크가 돌아가는 로컬 기기를 켜놔야 한다. 말 그대로 세션에 원격 접속은 하지만, 세션이 동작하는 곳은 로컬이다. 모바일 앱에서 시작하는 Work 세션은 어떻게 동작할 지 아직 안 써봐서 모르겠지만, PC에서 쓰는 ChatGPT Work는 Work Cloud와 Work Local이 쪼개져 있었다. 이 설명 자체는 챗지피티 답변을 그대로 옮긴다.

Work Local인지 아닌지 아이콘 표시라도 좀 생겼으면 좋겠다.
이런거라면, ChatGPT Work를 시작부터 나눠서 쓰게 해주면 좋겠다.

누군가 이 현상을 두고 내게 말했다. 로컬에 있는 물리적인 세션 파일을 복사해서 옮겨쓰면 되는거 아니냐고. 말 그대로 그걸 ChatGPT Work로 해봤다. 안 된다. 아니, 작업해야 하는 양 대비 가치가 너무 적었다. 나도 그랬고, ChatGPT도 그러고 동시에 같은 말을 했다.

“파일을 들고 양쪽 PC를 오가며 Local Work를 이어 쓴다”는 건 실용성이 거의 없다.

5시간 할당량 중 80%를 깔끔하게 써서 얻은 결론이다.

N-Screen처럼 쓰고 싶은 욕심은 계속 생긴다

이제는 거의 쓰지 않는 사장된 용어다. N-Screen. 내가 동영상 서비스를 기획하고 서비스했던 아득했던 과거에는 특징적인 기술이었는데, 이젠 그냥 당연한 환경이다. 그런데 지금 내가 겪는 세션 공유는 아예 원격 데스크탑처럼 쓸 고사양 서버를 따로 구해두고, 거기에 원격 접속해서 계속 쓰는 것 말곤 딱히 다른 방법은 떠오르지 않는다.

바이브코딩 방식으로 웹 제미나이와 웹 챗지피티만 쓸 땐 겪지 않았던 문제다. 퍼플렉시티 프로의 컴퓨트 기능을 쓸 때도 겪지 않았던 문제다. 그땐 그 상황에서만 할 수 있는 작업의 한계나 활용할 소스 한계가 분명히 있었다. 퍼플렉시티 컴퓨트한텐 서버 세팅을 맡길 수 없고, 제미나이 노트북한텐 코딩을 맡길 수 없다.

오픈클로로 작업하면 대략 어디서든 똑같은 세션을 공유해서 쓸 수 있다. 대신 IDE 편의성을 포기해야 한다. 여전히 딜레마다. 작업용 장비를 여러 개 쪼개어 작업할 것이 아니라, 확실한 고성능 1대가 있어야 할까? 그런데 고사양 노트북은 휴대하기가 너무 불편하다. 세션, 그게 뭐라고 나를 이리 매달리게 하는가!