예전에는 개발 도구를 한 번 익히면 꽤 오래 썼습니다.

저도 VS Code와 IntelliJ 정도를 중심으로 일했습니다. 업데이트는 계속됐지만 프로젝트를 여는 법, 코드를 찾는 법, 디버깅하는 법과 단축키는 오랫동안 자산으로 남았습니다. 새 버전이 나와도 일을 시작하는 방식 자체가 매달 바뀌지는 않았습니다.

AI 도구를 쓰기 시작한 뒤에는 시간이 다르게 흐릅니다.

여러 코딩 에이전트를 다루기 위해 Orca를 보고 있으면 Paseo가 눈에 들어옵니다. 개인 AI 에이전트는 OpenClaw를 쓰다가 Hermes로 바꾸고 있습니다. 그 안에서 사용하는 모델도 계속 달라집니다. 한 도구의 설정과 사용법을 익혀 이제 손에 붙는가 싶으면, 다음 도구가 더 나은 흐름을 제안합니다.

새 도구가 나오는 것은 반갑습니다. 문제는 개발보다 도구를 옮기는 일에 더 익숙해지는 순간입니다.

VS Code를 배우던 시대와 지금은 무엇이 다를까

VS Code와 IntelliJ는 코드를 읽고 쓰고 실행하는 중심 공간이었습니다. 플러그인과 언어가 달라져도 개발자가 직접 판단하고 조작하는 흐름은 비교적 안정적이었습니다.

최근 AI 개발 환경은 한 제품 안에서 끝나지 않습니다.

  1. 모델이 코드를 해석하고 답을 만듭니다.
  2. 코딩 에이전트가 파일을 수정하고 명령과 테스트를 실행합니다.
  3. 에이전트 작업 환경이 여러 에이전트와 작업 공간을 관리합니다.
  4. 개인 AI 에이전트가 메시징, 기억, 도구와 예약 작업을 연결합니다.

공식 문서를 기준으로 Orca는 여러 코딩 에이전트를 각각 분리된 Git worktree에서 병렬로 실행하고 결과 diff를 비교하는 환경입니다. Paseo는 이미 설치한 Claude Code, Codex, OpenCode 같은 에이전트를 로컬 데몬에서 실행하고 데스크톱·웹·모바일에서 제어하는 방식에 가깝습니다.

OpenClaw는 메시징 채널에서 사용하는 개인 AI 비서이고, Hermes는 여러 채널과 도구에 더해 세션을 넘는 기억과 재사용 가능한 스킬을 중심으로 둡니다. 제 작업 환경에서는 OpenClaw에서 Hermes로 옮기고 있지만, 이것이 모든 사람에게 같은 교체 순서가 정답이라는 뜻은 아닙니다.

서로 완전히 같은 제품들이 한 줄로 세대교체되는 것은 아닙니다. 다만 개발자가 관리해야 할 계층이 늘어났고, 각 계층의 선택지가 매우 빠르게 바뀐다는 점은 같습니다.

예전에는 에디터 하나의 단축키를 익혔다면, 지금은 모델·에이전트·작업 환경·연결 채널의 조합을 함께 관리합니다. 그래서 새 도구의 기능을 배우는 속도만으로는 안정적인 개발 방식이 만들어지지 않습니다.

도구를 빨리 바꾸는 능력과 프로젝트를 끝내는 능력은 다릅니다

새 도구를 설치하고 첫 결과를 얻는 일은 빨라졌습니다. 저장소를 연결하고 프롬프트를 넣으면 코드가 수정되고 브라우저가 열리며 여러 에이전트가 동시에 움직입니다.

하지만 프로젝트가 끝났다는 증거는 화면에 에이전트가 많이 떠 있는 것이 아닙니다.

  • 요구사항을 충족했는가
  • 기존 기능을 깨뜨리지 않았는가
  • 변경 이유와 범위를 설명할 수 있는가
  • 다른 사람이 이어받을 수 있는가
  • 문제가 생겼을 때 이전 상태로 돌아갈 수 있는가
  • 운영에서 실패를 발견할 로그와 알림이 있는가

이 질문에 답하지 못하면 빠른 도구는 빠르게 변경량만 늘릴 수 있습니다.

병렬 에이전트도 마찬가지입니다. 세 에이전트가 동시에 코드를 만들었다면 생산성이 세 배가 된 것이 아니라, 검토할 후보가 세 개 생긴 것일 수 있습니다. 작업을 분리하는 기준, 충돌을 피할 저장소 구조와 결과를 고르는 검증 기준이 먼저 있어야 병렬 실행이 이득이 됩니다.

도구 사용법은 개발 능력의 일부입니다. 그러나 도구를 바꿀 때마다 프로젝트의 맥락과 검증 절차까지 사라진다면, 쌓이는 숙련은 생각보다 적습니다.

모델 이름보다 컨텍스트를 만드는 방식이 오래 남습니다

AI 모델은 계속 바뀝니다. 어제 잘하던 모델보다 오늘 나온 모델이 특정 작업에서 더 나을 수 있고, 같은 모델도 업데이트 뒤 결과가 달라질 수 있습니다. 일시적인 벤치마크 순위를 외우는 것으로는 이 변화를 따라갈 수 없습니다.

그래서 저는 모델에 전달할 작업의 계약을 도구 밖에 남기는 편이 중요하다고 봅니다.

  • 이 프로젝트가 해결하는 문제
  • 건드리면 안 되는 경계
  • 완료 조건과 실패 조건
  • 실행해야 할 테스트와 검증 명령
  • 데이터베이스·브랜치·배포 대상
  • 사람이 승인해야 하는 변경
  • 실패했을 때 되돌리는 방법

이 정보가 저장소의 문서, 이슈, 테스트와 버전 관리 기록에 남아 있으면 모델을 바꾸기 쉽습니다. 반대로 중요한 맥락이 특정 도구의 채팅 기록 안에만 있으면 그 도구를 떠나는 순간 프로젝트의 기억도 함께 잃습니다.

좋은 프롬프트를 쓰는 능력보다 더 오래 남는 것은 좋은 컨텍스트를 유지하는 능력입니다. 프롬프트는 한 번의 요청이고, 컨텍스트는 여러 사람과 도구가 같은 판단 기준으로 일하게 만드는 기반입니다.

계속 바뀌어도 남는 개발자의 자산

1. 문제를 작업 단위로 나누는 능력

에이전트에게 큰 목표를 한 문장으로 넘기면 빈칸을 모델이 추측합니다. 입력, 출력, 예외와 완료 조건을 좁은 단위로 나누면 어떤 모델을 사용해도 결과를 비교하기 쉬워집니다.

2. Git과 변경 기록

에이전트가 만든 결과도 결국 diff로 검토해야 합니다. worktree, branch, commit과 pull request는 특정 AI 제품보다 오래 남습니다. 누가 만들었는지보다 무엇이 왜 바뀌었는지를 확인할 수 있어야 합니다.

3. 테스트와 실행 증거

“완료했습니다”라는 에이전트의 문장은 증거가 아닙니다. 테스트 결과, 실제 화면, API 응답, 데이터베이스 상태와 운영 로그가 증거입니다. 도구가 바뀌어도 완료를 판정하는 방법은 프로젝트에 남아야 합니다.

4. 관찰 가능성과 롤백

코드를 빨리 만드는 능력은 배포 뒤의 문제를 대신 해결하지 않습니다. 오류를 발견할 수 있는 로그와 지표, 영향을 제한할 배포 방식과 되돌리는 절차는 모델 성능과 별개의 운영 능력입니다.

5. 인수인계 가능한 문서

개인의 채팅 세션에만 있는 지식은 팀의 자산이 아닙니다. 프로젝트 규칙, 결정 이유, 반복 절차와 주의점을 파일과 문서로 옮겨야 다음 도구와 다음 담당자가 이어받을 수 있습니다.

결국 남는 것은 도구의 메뉴 위치가 아니라 일을 재현할 수 있게 만드는 구조입니다.

모든 새 도구를 배우지 않고도 놓치지 않는 방법

새 도구를 아예 무시하는 것도 좋은 전략은 아닙니다. AI 개발 방식은 실제로 바뀌고 있고, 이전에는 불가능했던 흐름이 가능해지고 있습니다.

대신 시험하는 도구와 기준으로 쓰는 도구를 구분할 필요가 있습니다.

저는 새 도구를 볼 때 기능 목록보다 다음 질문을 먼저 봅니다.

  • 지금 반복해서 겪는 병목을 실제로 줄이는가
  • 기존 저장소·IDE·CI와 함께 쓸 수 있는가
  • 결과를 diff와 테스트로 검증할 수 있는가
  • 작업 기록과 설정을 다른 도구로 옮길 수 있는가
  • 팀원이 같은 흐름을 재현할 수 있는가
  • 문제가 생기면 기존 방식으로 돌아갈 수 있는가
  • 설치와 전환에 든 시간보다 반복 비용을 더 많이 줄이는가

그리고 새 도구는 새 프로젝트의 화려한 데모보다, 이미 잘 알고 있는 작은 반복 업무에 먼저 적용하는 편이 낫습니다. 기존 결과를 알고 있어야 도구가 실제로 시간을 줄였는지, 단지 새로워서 빨라 보였는지를 구분할 수 있기 때문입니다.

하나를 팀의 기준으로 채택했다면 당분간 기준을 유지하는 것도 능력입니다. 더 새로운 도구가 나왔다는 사실만으로 진행 중인 프로젝트의 작업 환경을 바꾸면, 얻는 기능보다 설정 이전과 검증 비용이 더 커질 수 있습니다.

내일 도구가 사라져도 프로젝트는 남아야 합니다

Orca에서 Paseo로, OpenClaw에서 Hermes로 옮긴 경험은 어느 도구가 최종 승자라는 이야기가 아닙니다. 오히려 최종 승자를 기다리는 전략이 불가능해졌다는 이야기입니다.

새 도구를 빨리 시험하는 능력은 필요합니다. 동시에 프로젝트를 안정적으로 끝내는 능력은 별도로 관리해야 합니다.

도구의 반감기는 짧아질 수 있습니다. 하지만 요구사항, 데이터, 테스트, 변경 기록, 관찰 가능성, 롤백과 운영 책임은 사라지지 않습니다.

그래서 앞으로 익혀야 할 것은 모든 AI 도구의 사용법이 아닙니다.

도구가 바뀌어도 같은 품질로 문제를 정의하고, 일을 나누고, 결과를 검증하고, 다음 사람에게 넘기는 방식입니다.

내일 지금 쓰는 에이전트와 모델을 바꿔도 프로젝트를 계속할 수 있다면, 그때 비로소 AI 도구를 제대로 사용하고 있는 것입니다.

참고한 공식 자료

프로젝트의 AI 도구를 계속 바꾸고 있는데 속도보다 혼란이 커졌다면, MOSH는 특정 제품 하나를 권하기보다 현재 저장소·검증·배포 흐름을 먼저 확인합니다. 도구를 교체해도 남는 개발 방식이 필요한 프로젝트라면 이야기해 주세요.


AI 개발 도구, AI 코딩, 개발 워크플로, Orca, Paseo, OpenClaw, Hermes