옮기지 못한 이유는 성능이 아니라 쌓인 설정이었다

1년 동안 한 생태계만 쓰던 사람이 다른 상용 코딩 에이전트로 옮겨 본 며칠째 첫인상이 결론을 유보한 채 정리된다. 눈에 띄는 대목은 전환 장벽의 정체인데, 옮기지 않은 이유가 성능이 아니라 스킬과 메모리 같은 설정이 이미 쌓여 있어서였고 설치 과정에서 기존 도구를 감지해 그것을 한 번에 가져오자 전환 비용이 사실상 사라졌다는 것이다. 다만 훅이나 하위 에이전트를 복잡하게 짜 둔 부분은 넘어오지 않는다는 단서가 전언 형태로 붙는다. 그 밖에 한도 소모가 느리고 남은 리셋 권한을 저축해 쓸 수 있다는 점, 모델 라인업이 여러 개라 작업마다 배분할 수 있다는 점, 외부 서비스 연결은 이쪽이 편하지만 공개된 스킬 문서를 이해하고 수행하는 능력은 반대쪽이 낫다는 점이 갈린다. 화면을 직접 열고 클릭하는 조작 능력이 실제로 쓸 만하더라는 관찰도 나오지만, 근거가 전부 며칠치 체감이고 권한과 오조작 위험은 다뤄지지 않는다.

이 글은 제가 여러 자료를 읽고 제 말로 다시 정리한 노트예요. 출처 링크를 달지 않는 대신, 사실 확인이 된 사건은 기록에 따로 있어요.