AI Native라는 말에는 사람을 움직이는 힘이 있다.
반복 작업을 줄이고, 더 빠르게 실험하고, 개인의 경험을 조직의 지식으로 바꾼다. 개발자는 코드를 작성하는 데서 그치지 않고 문제를 정의하고 결과를 검증하는 일에 더 많은 시간을 쓸 수 있다. 잘 설계한다면 AI는 새로운 도구 하나가 아니라 일하는 방식 자체를 바꾼다.
나 역시 그 가능성을 믿는다. 여러 AI 도구를 사용하고 작업 방식을 옮기는 과정에서 한 가지를 더 자주 생각하게 됐다.
AI Native 조직을 만드는 일에서 모델 선택은 시작일 수 있지만, 완성은 될 수 없다.
선택과 방치는 비슷해 보인다
AI 모델의 순위는 빠르게 바뀐다. 오늘 뛰어난 모델이 몇 달 뒤에도 가장 좋은 선택이라는 보장은 없다. 이런 변화에 맞춰 직접 만든 확장도 계속 점검해야 한다. 유지보수 부담이 크다면 별도의 확장을 최소화하고 도구의 기본 기능을 활용하는 편이 나을 수 있다.
중요한 것은 하나의 도구를 오래 고집하는 일이 아니다. 직접 쌓을 것과 공급자에게 맡길 것을 의식적으로 결정하고, 그 선택을 다시 평가하는 일이다.
선택과 방치는 겉으로 비슷해 보여도 결과는 전혀 다르다.
나도 처음에는 특정 도구 안에 작업 규칙과 자동화를 쌓았다. 도구를 바꾸려 하자 서로 다른 성격의 내용이 섞여 있다는 것이 보였다. 제품에 종속된 설정도 있었고, 어떤 도구에서도 유지하고 싶은 판단 기준과 작업 절차도 있었다.
그래서 AI 도구를 바꾸는 비용을 낮추는 법에서 다뤘듯 공통 원칙, 작업별 스킬, 비공개 설정을 분리했다. Cursor에서 Codex로 옮기고, 다시 Claude Code와 Codex를 함께 사용해도 업무 절차의 원본은 도구 밖에 남도록 했다.
그렇다고 파일을 많이 만들어 두는 것만으로 운영 능력이 생기지는 않았다. 7일간의 Claude Code 기록에서 사용자 프롬프트 236건과 스킬 호출 10건을 확인했다. 보유한 스킬 53개 중 호출이 기록된 스킬은 3개였다. 개인 스킬 45개 중 38개에는 자연어 요청에 따른 자동 선택을 막는 설정이 붙어 있었다.
이 경험은 스킬 53개를 만들고 3개만 쓰고 있었다에 따로 기록했다. 만들어 놓았다는 사실과 실제 작업에서 쓰인다는 사실은 달랐다. “도구가 있다”와 “도구가 살아 있다” 사이에는 관측과 유지보수가 필요했다.
도구를 계속 돌보기 위한 구조
이 문제를 풀기 위해 만든 것이 Agent Skill Garden이다. 반복되는 작업을 특정 모델에 종속되지 않는 스킬로 정리하고, Cursor·Claude Code·Codex의 스킬 탐색 방식에 맞게 연결했다.
저장소의 목적은 스킬 수를 늘리는 것이 아니다. 실제 작업에서 반복되는 판단을 추출하고, 다시 사용할 수 있는 절차로 만든 뒤, 검증하고 관찰하며 유지할 가치가 있는지 판단하는 것이다.
구조에도 그 기준을 반영했다.
- 공통 업무 원칙과 절차는 특정 제품 밖에 둔다.
- 제품마다 다른 스킬 탐색 방식은 어댑터로 분리한다.
- 설치 여부가 아니라 실제 선택 근거를 로컬에서 확인한다.
- 정적 검사와 합성 평가로 구조와 안전 경계를 검증한다.
- 사용 기록과 검증 결과를 바탕으로 스킬을 개선하거나, 합치거나, 정리한다.
이 과정은 my-cursor는 잘 작동했지만, Agent Skill Garden으로 다시 시작했다에 더 자세히 정리했다. 이것이 AI Native의 정답이라는 뜻은 아니다. 다만 모델보다 오래 남는 운영 능력을 개인 수준에서 실제 형태로 축적해 본 실험이다.
이 과정을 거치며 도구가 잘 유지되고 있는지 판단하는 기준도 달라졌다. 마지막 커밋 날짜와 함께 사용 중 겪은 문제가 전달되는지, 달라진 작업 방식이 반영되는지, 실패를 확인할 방법이 있는지를 살펴보게 됐다. 더 이상 유지할 이유가 없다면 근거를 남기고 내려놓는 것도 운영이다.
도구를 추천할 때 함께 전할 것
이런 개인 실험을 다른 사람과 나누려면 무엇을 확인했고 어디까지 적용할 수 있는지도 함께 전해야 한다. 도구에 대한 설명은 듣는 사람의 다음 선택에 영향을 주기 때문이다.
“이번 모델이 좋더라”는 짧은 감상도 추천하는 사람의 역할과 그에 대한 신뢰에 따라 방향을 정하는 신호가 될 수 있다. 듣는 사람은 지금 익히는 도구에 계속 시간을 써도 되는지, 이미 만든 자동화를 옮겨야 하는지까지 생각할 수 있다.
이 기준은 내가 도구를 추천할 때도 적용된다. 어떤 작업에서 좋았는지, 아직 확인하지 못한 부분은 무엇인지, 개인적인 감상인지 함께 시험해 보자는 제안인지 설명하고 싶다. 앞에서 Skill Garden을 개인 수준의 실험으로 소개한 것도 같은 이유다. 적용 범위가 보이면 듣는 사람도 자신의 업무에 써 볼지 판단하기 쉬워진다.
아이디어, 실험, 결정의 단계를 구분해 공유하는 일도 운영의 일부라고 생각한다. 판단에 필요한 맥락이 함께 전달될수록 무엇을 시험하고 어떤 결과를 보고 결정할지 명확해진다.
사용한 흔적보다 만들어진 변화
AI 도입 초기에는 측정하기 쉬운 숫자에 눈이 간다. 활성 사용자 수, 사용량, AI가 참여한 커밋 수처럼 눈에 보이는 지표가 생긴다. 이런 숫자는 도입 현황을 살피고 도움이 필요한 곳을 찾는 데 유용하다.
하지만 사용한 흔적이 곧 만들어진 변화는 아니다.
SPACE 프레임워크는 개발자 생산성을 개인의 활동량이나 하나의 지표만으로 측정할 수 없다고 설명한다. 2025 DORA 연구도 AI를 조직이 이미 가진 강점과 약점을 확대하는 증폭기로 본다. 도구 자체보다 도구가 들어가는 조직 시스템이 중요하다는 이야기다.
내가 스킬 호출 기록을 확인한 이유는 스킬이 필요한 요청에서 선택됐는지, 특정 작업에만 호출이 몰렸는지, 실제로 사용하는 말과 스킬 설명이 맞는지 진단하기 위해서였다. 사용자 프롬프트 수 대비 스킬 호출 수는 약 4.2%였다. 4.2%라는 숫자보다 그 숫자가 드러낸 설정 오류와 설명의 불일치가 중요했다.
조직에서도 AI를 얼마나 많이 사용했는지와 함께 다음 변화를 물어야 한다.
- 요구사항에서 배포까지 걸리는 시간이 줄었는가
- 운영 결함과 회귀가 줄었는가
- 리뷰와 QA에 전가되는 비용은 늘지 않았는가
- 유지보수 가능한 코드와 문서가 남았는가
- 한 사람의 성공이 다른 사람도 반복할 수 있는 방식으로 남았는가
사용량은 출발점을 알려준다. AI Native의 성과는 더 나은 결과가 반복되는 구조를 만들었는지로 판단해야 한다.
내가 만들고 싶은 AI Native 조직
개인 환경에서 규칙을 분리하고 사용 기록을 살핀 경험은 다음 실험을 설계할 근거가 됐다. 여러 사람이 함께 쓰는 환경에서도 도움이 되는지는 별도로 확인해야 한다. Agent Skill Garden은 그 질문을 구체적인 절차와 코드로 다뤄 볼 출발점이다.
팀으로 넓힌다면 반복되는 업무 하나부터 동료들과 함께 정하고 싶다. 대표 요청과 성공 기준을 정해 시험하고, 결과의 품질과 검증에 든 시간, 허용한 범위 안에서 실행됐는지를 살펴보려 한다. 그 결과를 바탕으로 무엇을 유지하고 누가 돌볼지 결정할 수 있다. 절차가 과해졌다면 줄이고, 도움이 되지 않는다면 내려놓을 수 있어야 한다.
나는 이런 경험을 동료들과 쌓고 싶다. 한 사람의 발견이 다음 사람의 출발점이 되고, 모델이 바뀌어도 함께 쌓은 판단과 검증의 기준이 남는 것. 내가 생각하는 AI Native의 운영 능력은 그런 축적에 있다.