Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 시대의 도구는 개인화되고 팀 프로토콜을 통해 통신해야 한다고 주장합니다. 기존 SaaS나 범용 AI 코딩 도구(Claude Code, Codex 등)를 단순히 도입하는 방식으로는 워크플로우 혁신에 한계가 있습니다. 대신, '씨앗(Base)'과 '유연한 부분'으로 구성된 아보카도 같은 구조의 개인화된 툴이 필요합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Claude Code나 Codex를 전사적으로 도입해서 조금은 편해졌지만, 워크플로우 자체는 예전과 크게 다르지 않다. Notion, JIRA, Slack 등에서 여러 AI를 사용하고 있음에도 불구하고, AI의 효과를 제대로 체감하기 어렵다. 세상의 'AI Native'가 무엇인지 점점 알 수 없게 되었다.
저 역시 한 회사의 팀을 AI Native화할 때 완전히 똑같은 것을 느꼈습니다.
하지만 올해 6월경, AI Native가 나아가야 할 방향에 확신을 갖게 되었고, 지금은 '미래는 이것밖에 없다'라고 진심으로 생각하고 있습니다.
이 글은 그때의 경험을 공유하는 것입니다.
먼저 말씀드리자면, 이것은 'SaaS is Dead' 같은 이야기는 아닙니다.
최근 화제가 된 photocraft처럼, 기존 SaaS를 리버스 엔지니어링해서 복사하고 공짜로 쓰자는 이야기도 아닙니다.
말하고자 하는 것은 이겁니다.
AI 시대의 도구는 '일하는 사람' 개개인에게 개인화되고, '팀의 프로토콜(Protocol)'을 통해 통신해야 한다. 이 아키텍처가 새로운 시대의 도구가 되어 워크플로우에 혁명을 일으킬 수 있습니다.
처음에는 저 역시 흔히 듣는 'AI Native 회사를 만드는 방법'을 빠짐없이 시도했습니다.
| 자주 듣는 AI Native | 내용 |
|---|---|
| AI 도구의 적극적인 도입 | Claude Code, Codex 등을 모두가 사용한다 |
| ... | |
| 결과는 아마 여러분과 같았을 겁니다. |
요컨대, 흔히 하는 방식으로는 안 됐던 겁니다.
최근 'AI 시대에는 인간이 병목 현상(bottleneck)이다'라는 이야기를 자주 듣습니다.
하지만, 병목 현상은 '인간'이 아닙니다. 인간이 사용하는 기존의 '범용 도구(汎用ツール)'입니다.
지금 LLM의 한계를 몸으로 느낀 사람이라면 알겠지만, 이상적인 것은 '인간'을 'AI'로 대체하는 것이 아니라, '인간'이 'AI 마법'을 사용할 수 있게 되는 것입니다.
그런데 그 마법을 방해하는 것이 있습니다.
모두 '누구나 사용할 수 있도록' 만들어진 범용 도구입니다. 역설적으로, 어떤 개인에게도, 어떤 프로젝트에도 최적화되어 있지 않다는 것입니다.
예를 들어 '모바일용 클릭커 게임 개발팀'과 '게임 친구 매칭 앱 개발팀'은 필요한 도구의 형태 자체가 다릅니다.
인간 ──▶ [ 범용 도구라는
「すべてのツールを自作する」라고 들으면, '다들 제각기 만들면 감당이 안 되지 않을까?'라고 생각하실 겁니다. 그래서 저희는 자작 툴을 **아보카도 같은 구조**로 설계했습니다.
╭─────────────────────────────╮
│ 유연한 부분(과육) │ ← 직원이 AI와 함께 자유롭게 개선한다
│ │
...
구조는 간단해서, **'씨앗(種)'**과 **'유연한 부분(やわらかい部分)'** 두 가지뿐입니다.
모두가 공유하는 것은 'Protocol'과 'Base'이며, 이 Base와 Protocol만 충족하면 각각 별개의 개인화된 툴로 작동할 수 있습니다.
씨앗은 툴의 '핵심(コア)', 전체를 지탱하는 기반입니다.
엔지니어 관점에서 말하자면, **'Server' + '클라이언트 기본 Base'** 입니다.
- 기본적인 것은 바꾸지 않는다는 전제 하에 만든다. - 정말로 바꾸고 싶을 때는,
**엔지니어와 상담한다**. - Core 업데이트로 충돌이 발생하면,
**개인이 Core에 맞춰 수정한다**.
**핵심**: 이곳을 만져서 자신에게 가장 맞는 툴로 바꿔 나가는 것입니다.
정말로 중요한 것은 이쪽입니다.
직원들은 'Core + 유연한 부분 Base'를 받고, **유연한 부분을 자신에게 가장 적합한 형태로 개선**해 나갑니다. 화면 레이아웃도, 기능도, 워크플로우도 여기서 자유롭게 변경해도 괜찮습니다.
이렇게 툴은 **사용자 본인에게 누구보다 최적화**되어 갑니다.
| 범용 툴 | 아보카도 툴 | |
|---|---|---|
| 누가 사용하도록 만들어졌는가 | '모두' | '사용자 본인' |
| ... |
씨앗이 탄탄하기 때문에, 과육이 아무리 부드러워도 형태가 무너지지 않습니다. 그래서 '아보카도 툴'인 것입니다.
여기까지 읽고, 이렇게 생각한 사람도 있을 겁니다.
'대화로 툴을 조작시키고 싶다면, Computer Use나 MCP로 충분하지 않을까?'
실제로 저희도 처음에는 그렇게 했습니다. 하지만 둘 다 결국 한계에 부딪힙니다.
Computer Use:
화면을 본다 → 마우스를 움직인다 → 버튼을 누른다 → 스크린샷 → 추론 → ...
→ 인간을 위한 UI를 AI가 흉내 내는 것일 뿐입니다(＝효율의 문제)
...
**Computer Use**는 AI 입장에서 거의 '서커스'와 같습니다. 작업 하나에 수십 장의 스크린샷, 클릭할 때마다 추론이 필요합니다. 손으로 집을 수 있는 것을 굳이 젓가락을 건네주면서 '이걸로 집어라'라고 말하는 것과 같습니다. 노력하면 젓가락으로도 잡을 수 있지만, 손이 더 쉽습니다. 모델이 아무리 좋아져도 이 구조적인 비효율은 사라지지 않습니다.
**MCP**는 훨씬 나은 방법이며, 사실 저희의 툴도 내부적으로는 MCP 형태로 AI와 연결되어 있습니다. 문제는 MCP 그 자체가 아니라, **그 너머에 있는 툴이 누구의 것인가**입니다. 팀에게 필요한 필드가 하나 부족해도 만들 수 없습니다. '이 기능, 당장 필요해요'라고 해도 상대방 회사 로드맵을 기다려야 합니다. 게다가 쌓인 데이터는 우리 서버가 아닌 상대방 제품 안에 있습니다.
즉, **중요한 것은 '어떻게 연결하느냐'가 아니라, '연결하는 곳이 누구의 것인가'** 입니다.
물론 좋은 점만 있는 것은 아닙니다. 벽은 크게 두 가지가 있습니다.
**핵심**: 의존할 곳이 없다 = 변명할 곳도 없다.
AI가 똑똑해질수록, **기존의 하네스를 넘어서 무언가를 일으킬 가능성**도 생겨납니다.
게다가 자작 툴이라면, 책임은 **전부 회사 자체**입니다. 'Slack사의 보안 문제 때문에...'라는 변명은 통하지 않습니다. 의존할 곳이 없기 때문입니다.
그래서 엔지니어는 이 리스크를 제대로 인지한 상태에서 다음 두 가지를 할 필요가 있습니다.
**AI를 감시하는 시스템이나 하네스를 만들 것**
**새로운 모델이 나오면, 신중하게 테스트한 후에 도입할 것**
**핵심**: '툴은 받아서 사용하는 것'이라는 인식을 바꿔야 합니다.
2번째는 직원의 마인드를 바꿔야 한다는 것입니다.
| 직종 | 이전에는 | 앞으로는 |
|---|---|---|
| 기획/디자인 | 받아서 사용한다 | 스스로 만든다 |
| 엔지니어 | 기능을 만든다 | 지킨다・감시한다 |
기획자나 디자이너 역시 필요한 것은 스스로 만들고 사용하는 의식으로 변화해야 합니다. 한편 엔지니어는 **기본적인 안전성 확보, 하네스 개선, AI 모니터링** 쪽으로 역할이 이동합니다.
이는 도구에만 국한된 이야기가 아닙니다. 고객을 위한 제품에서도 기획자나 디자이너가 개발에 점점 깊숙이 관여하게 됩니다. 그렇게 되면 **버전이 올라갈 때마다 보안이나 아키텍처를 관리하는 것도 엔지니어의 역할**로 넘어가게 됩니다.
이 이야기를 하면 보통 이런 질문들이 나옵니다.
**Q1. 만들 사람이 없습니다. 개발 리소스가 부족한데요?**
바로 그 전제가 이번에 무너진 것입니다. 도구를 만드는 것이 엔지니어여야 할 필요가 없어졌습니다. — 이것이 변화의 핵심입니다. 업무를 가장 잘 아는 실무자가 직접 만든 것이 오히려 더 정확한 도구가 됩니다. 개발팀의 역할은 '모든 것을 만드는 것'에서 '만들 수 있는 기반을 준비하는 것'으로 바뀌어야 한다고 생각합니다.
**Q2. 직접 만든 도구는 범용 도구보다 품질이 떨어지지 않나요?**
어떤 각도에서 보느냐에 따라 다릅니다. 범용성은 확실히 떨어집니다. 하지만 대단한 문제는 아닙니다. 결국 도구를 사용하는 것은 개인이고, 시간이 지날수록 그 사람에게 완벽에 가까운 도구가 되어가기 때문입니다.
**Q3. 어차피 외부 AI API에 데이터를 보내야 한다면, 똑같지 않나요?**
차이는 **'지나가기만 하는가, 쌓이게 하는가'** 입니다. 추론(Inference) 1회로 데이터가 지나가는 것과, 우리들의 활동 이력이 상대방의 제품 안에 구조화되어 쌓여가는 것은 완전히 다른 이야기입니다. 게다가 직접 만들 경우, 모델을 교체하는 것도 가능하고 민감한 부분만 로컬에 분리할 수도 있습니다. 범용 도구 중에서는 애초에 그 선택지가 없습니다.
**Q4. 만들어 놓고 사용하지 않으면, 낭비가 되지 않나요?**
그것이야말로 '도구 = 구매 자산'이었던 시대의 발상입니다. 반나절을 들여 만든 것을 버리는 것은 낭비가 아닙니다. 맞지 않는 도구를 3년간 구독하는 것이 훨씬 더 큰 낭비입니다. 게다가, 도구를 버려도 그 사이에 쌓인 데이터는 남습니다.