<div id="readability-page-1" class="page"><div>
					<p><a href="https://blog.outsider.ne.kr/1782">작년 연말 회고</a>에서도 얘기했듯이 나는 AI에 보수적인 태도를 가지고 있다. 얼마 전에 <a href="https://podcast.44bits.io/">44bits</a>에서 사람들하고 얘기하다가 이제는 입장 돌변을 자연스럽게 받아들여야 한다는 얘기를 들었는데 그 말이 공감될 정도로 기술 발전이 빠르고 또 경험에 봄에 따라 생각이 확확 달라진다. 회고를 쓴 게 3개월 전인데 얼마 안 되었다고 할 수도 있지만 요즘 같은 시기에는 또 꽤 예전이라고도 할 수 있어서 그사이에 내 생각도 많이 달라졌다.</p>

<p>계속 글을 써야지 하다가 미루면서 쓰게 되는데 이 글은 현재 내 생각을 정리도 하면서 몇 달 뒤에 돌아봤을 때 "이때는 이렇게 생각했구나"하면서 돌아보기 위한 글이라고 할 수 있다.</p>

<div><p>먼저 변명(?)하자면 AI에 보수적인 태도를 일부 가지고 있는 것이지 회의적인 것은 아니다. 굳이 비교하자면 나는 블록체인에 대해서는 회의적인 견해가 있는데 여기서 다 설명할 수는 없지만 블록체인이 실용적인 어떤 결과를 만들어내지 못할 거라고 생각한다. 보수적인 태도라고 한 것은 이러한 회의적인 태도과는 다르다. 당연히 <strong>나도 AI는 더 발전하고 지금보다도 더 실용적으로 우리의 삶이나 업무에 깊숙이 들어오게 될 것이라고 믿는다.</strong></p></div>

<h2>보수적인 태도를 보이는 이유</h2>

<p>그동안 나를 돌아보면 항상 뭔가 새로운 걸 배울 때 보수적인 태도를 가지는 편이다. 이건 내 성격이기도 한데 뭔가 새로운 걸 의심의 눈초리와 함께 쳐다보는 편이다.(영화보면 이런 사람이 더 사기를 잘 당한다던데...)</p>

<p>지금은 내 밥벌이나 다름없는 DevOps를 처음 알게 되었을 때도 "그럼, 개발해 놓고 운영을 안해?" 따위의 생각을 하고 있었고 Docker를 계속 공부하면서도 사실 잘 이해를 못해서 실무에서 이걸 어떻게 사용해야 하는지 전혀 감을 잡지 못하고 있었다. Kubernetes나 Service Mesh를 공부할 때도 내가 Google 같은 빅테크에서 일하는 것도 아닌데 이걸 어디다 쓰지? 같은 생각을 했다.</p>

<p>이건 내가 뭔가를 이해하는 과정이라는 생각도 한다. 첫눈에 반해서 막 좋아하는 기술이 없었던 건 아니지만 대부분은 내가 명확히 이해해야 사용할 수 있기 때문에 그 기술의 의미, 사용처, 예외 케이스, 트레이드 오프 등을 다 이해하려고 하다 보니 좀 떨어진 위치에서 보려고 하는 편이다. 일할 때도 이러한 성향이 나타나는 편인데 그래서 새로운 것에는 항상 내가 다 이해될 때까지는 반대하는 듯한 태도를 펴는 편이다.</p>

<p>그렇다고 관심을 끊지는 않는다. 예전에 DevOps나 Docker, Kubernetes 등도 대세가 될 것을 확실해 보였기 때문에 공부는 계속했다. 내가 완전히 이해를 못해서 그렇지 공부는 그만두지 않았다. AI에 대해서도 마찬가지다. 내 태도와 상관없이 AI는 계속 발전할 거고 점점 깊숙이 들어올 것이므로 AI를 찬양하는 글, 반대하는 글이나 다양한 팁과 기술 흐름의 변화는 계속 따라가려고 하고 있다.</p>

<p>이전에도 계속 보수적인 태도이었지만 DevOps나 Docker나 Kubernetes나 지금은 내 주요 밥벌이가 되었다. 잘 이해 못하는 느낌에 힘들었지만, 어느순간 또 그 기술을 사용하는 회사로 이직해서 사용하기 시작하면 어느 정도는 따라갈 수 있었기에 AI에 대해서도 따라가면 된다는 자신감을 어느 정도 있다.(그래도 올해는 따라가야 한다고 생각한다) 그래서 AI를 잘 쓰고 관심이 큰 사람들 주변에서 정보를 최대한 얻으려고 하고 있다.</p>

<div><p>물론 이전과 다른 점은 그때는 개발이 너무 재밌었고, 집에 와서도 하루 종일 개발관련 뭔가만 하고 있었지만, 지금은 열정이 그 정도는 아니라는 점이다. 내 태도와 상관없이 공부는 계속 해야 하는데 공부의 절대량이 부족하다는 생각이란 AI는 기존 기술과는 상당히 다르므로 그냥 글 읽고 하는 거 말고 직접 써보고 느끼고 잘 사용하는 방법을 체득해야 하는데 이런 쪽에 투입하는 시간이 절대적으로 부족하므로 생기는 조바심이 있다. 조바심은 내 커리어 내내 항상 있던 거지만 이전에는 그 조바심 때문에 학습을 엄청나게 했다면 지금은 그렇지 못하고 있다는게 지금 나의 가장 큰 문제이다. 최근에 깨달은건 내가 내 생각보다 코딩이나 엔지니어링이라는 그 과정 자체를 즐거워한 거 같다는 생각도 들고 내가 AI에는 아직 재미를 못 느끼고 있다는 생각도 든다.(최근에 재미를 조금씩 붙여나가고 있다.)</p></div>

<h2>우려하는 부분</h2>

<p>얼마 전 동료랑 얘기하다가 내가 AI에 대해서 우려하는 부분을 명확하게 깨달았는데 나는 그 "바이브" 느낌이 싫다. Andrej Karpathy가 만든 <a href="https://x.com/karpathy/status/1886192184808149383">vibe coding이라는 용어</a>는 AI로 인해 달라지는 코딩을 잘 표현한 말이기도 하고 마케팅 적으로 크게 성공한 말이기도 하다.</p>

<blockquote>
  <p>제가 "바이브 코딩(vibe coding)"이라고 부르는 새로운 종류의 코딩이 있어요. 분위기에 완전히 몸을 맡기고, 지수적인 발전을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 방식이죠.</p>
</blockquote>

<p>코드를 읽을 필요가 있는가 없는가를 얘기하려는 것이 아니다. 그건 프로젝트의 성격, 상황에 따라 달라지게 마련이다. <strong>내가 불편한 건 바이브 코딩이라는 용어가 책임을 전가하거나 회피하는 분위기를 만들어낸다는 것이다.</strong> 누구나 농담으로라도 한 번씩은 들어보거나 직접 해봤을 말인 "제가 안 그랬어요. AI가 그랬어요."라거나 "AI가 그렇게 대답해 줬어요." 같은 말에서 알 수 있듯이 은근히 AI에게 일을 시키고 자신의 책임을 회피하는 분위기가 생겨나고 있다고 생각한다.</p>

<p><strong>AI에만 맡기지 말고, 생각을 멈추지 말고, 계속 고민하고 연구하고 더 좋은 방법을 찾아야 한다.</strong> 모든 영역이 그런 것은 아니니 단순한 반복 작업등은 더 AI에 맡겨서 시간을 확보하고 그 확보한 시간을 중요한 작업이나 고민을 많이 해야 하는 영역에 더 시간을 써야 한다. 하지만 바이브 코딩이라는 분위기가 이를 저해한다고 본다.</p>

<p>물론 용어 자체의 문제가 아닐 수도 있고 개개인의 성향이나 AI에 대한 기대치에 따라 달라지는 부분인 것도 맞지만, 용어에는 그런 힘이 있다고 생각해서 조심해야 한다고 본다. 그런 면에서 Andrej Karpathy가 바이브 코딩과 전문 영역에서 AI 에이전트를 사용하는 것을 구분하기 위해 <a href="https://x.com/karpathy/status/2019137879310836075">Agentic Engineering을 선택</a>한 것을 지지한다.(<a href="https://addyosmani.com/blog/agentic-engineering/">Addy Osmani의 Agentic Engineering</a>도 참고)</p>

<p>결국 AI를 어떻게 하면 더 잘 사용할 수 있을지에 대한 논의도 아주 중요하지만 동시에 AI로 인해서 생길 문제에 대한 논의도 중요하다고 생각한다. AI뿐만 아니라 모든 혁신적인 변화 분위기에는 항상 그렇긴 하지만 우려에 관한 얘기가 마치 혁신을 저해하는 것처럼 보인다는 것도 불편하다. 물론 그냥 개인 느낌일 수도 있고 어디나 다양한 의견이 있어서 그냥 그렇게 느낄수도 있지만 그런 얘기를 짧은 글로 SNS에 하기는 어려워서 종종 블로그를 이용해야겠다고 생각하고 있다.</p>

<div><p>모든 기술은 트레이드 오프가 있기 마련이다. AI를 잘 활용하는 것만큼 잘못 사용하지 않도록 하는 것도 중요하다고 생각한다. 이건 내가 주로 인프라 업무를 하므로 더 이쪽에 대해서 많이 생각하게 되는거 같은데 어려운 점은 AI의 발전 속도가 너무 빠르다. 지금까지 보던 대부분의 기술은 변화가 생긴다는 것을 감지하고 대세가 되는 것을 보면서 준비해도 늦지 않았지만 지난 1년 사이에 AI가 달라진 걸 생각하면 뭐 준비하고 말고 할 시간이 없다. 냉정히 말해서 변화가 너무 빠르므로 최대한 활용하면서 안전장치를 동시에 만드는 수밖에는 없다고 생각한다.</p></div>

<h2>요즘 고민하고 있는 부분</h2>

<h2>권한 관리</h2>

<p>지금까지의 많은 시스템은 사람과 서비스를 대상으로 만들어졌다. 여기서 사람은 말 그대로 사람이고 서비스는 서버 등에 띄우거나 하는 어플리케이션을 의미한다. 하지만 여기에 에이전트라는 게 하나 더 생겼다. 에이전트라는 말이 요즘은 어디에나 사용되지만 여기서 말하는 에이전트를 사람이 로컬에서 돌리는 에이전트를 얘기한다. 서버에서 에이전트를 실행하는 건 그냥 서비스로 보면 된다고 생각한다.</p>

<div><p>이 에이전트는 사람한테 종속되었다는 특징이 있는데 사람의 권한을 똑같이 가져가기엔 너무 많고 에이전트에게 시킨 일에 딱 맞는 최소한의 권한만 주면 제일 좋을 것 같은데 그럴 방법이 없다. 꼭 코딩 에이전트를 예시로 들지 않더라도 에이전트를 설치해서 내 카드 사용 권한을 준다면 걱정되는 부분도 많은데 최대 10만원 제한 같은 걸 줄 수 있다면 불의의 사고에 대한 영향도를 최소화할 수 있으므로 훨씬 적극적으로 사용할 수 있을 거라고 생각한다. 하지만 현재는 이러한 방법이 없고 과도한 권한을 주고 프롬프트로 최대한 방어해서 쓰거나 제대로 사용하지 못하게 된다.</p></div>

<h2>사용 성숙도 전파</h2>

<p>AI를 코딩할 때 사용하거나 리서치, 업무 자동화 등에 많이 사용할 것이라고 보인다. 시간이 지나지면서 개선되고 있으니, 앞으로도 계속되겠지만 벌써 잘 쓰는 사람과 잘 못 쓰는 사람의 차이가 있다고 느껴지는데 이게 잘 전파가 안 된다고 느껴진다.</p>

<p>기존 코딩 팁이나 지식, 아키텍처 같은 것은 누군가 연구하고 정리해서 공유하면서 팀 전체에 사용 성숙도를 같이 올리는 노력을 하게 마련인데 AI는 그게 좀 쉽지 않은 느낌이다. 기존 기술과 프롬프트를 이용해서 사용하다 보니 잘 쓰는 사람도 "그냥 시키면 알아서 잘해요" 정도로 얘기하거나 별거 아니라고 생각해서 공유를 안 하게 되는 거 같기도 하다. 그리고 취향도 타기 때문에 스킬 같은 것도 남의 것을 가져오기보다 아이디어만 가져와서 직접 만들어 쓰는 게 더 자연스러워지는 거 같다.</p>

<div><p>결국 새로운 변화에 혜택받는 수준을 전체 구성원에게 일정 수준 이상으로 올리는 방법에 대한 고민이라고 할 수 있는데 AI는 기존 기술과는 사용 방법이 다르므로 이러한 고민이 의미 없고 그냥 각자에게 맡기도 다른 고민을 하는게 더 맞나하는 생각도 한다.</p></div>

<h2>에이전트를 위한 인터페이스</h2>

<p>요즘은 AI 에이전트를 10개씩 쓴다는 사람도 있지만 보통 1, 2개를 돌리는 거 같은데 당연히 시간이 지날수록 더 많아질 것이다. 그러면 에이전트에게 제공해야 하는 인터페이스는 무엇인가? 하는 고민을 하고 있다. 인터페이스라는 것을 사용하기 좋게 하면서도 사용 방법에 대한 통제권을 어느 정도 가지는 의미가 있다.</p>

<p>흐름으로 보면 기존에는 UI와 API만 있었고 그 뒤에 MCP가 생겼고, 지금은 CLI가 대세인 분위기이다. 요즘은 AI로 단순 코딩에 큰 노력이 들어가진 않으니 넷 다 제공하고 편한 대로 쓰라고 하는 게 맞는 거 같기도 하고 CLI가 토큰 효율성도 그렇고 사용하기 제일 좋다는 생각도 든다. 하지만 CLI를 제공하면 API도 같이 제공한 것이므로 API도 함께 제공한 것이기도 하다.</p>

<p>"API 사용자가 충분히 많으면 명세에 적힌 내용과 상관없이 시스템의 모든 관찰 가능한 행동에 의존하게 된다."는 하이럼의 법칙이 더욱 강해지고 있다는 요즘이다. CLI를 제공해서 사용 패턴을 제어하는 게 가장 좋다고 생각하지만 사실 API까지 같이 제공했으니, 통제권을 제어하기는 쉽지 않아 보인다. (물론 CLI가 API의 래퍼 역할이라고 볼 수도 있긴 하지만 여기서는 CLI를 제공한다는 게 사용 방식을 더 제어할 수 있을 거 같다는 개인적인 생각이 담겨있다.)</p>

<p>간단히 정리하면 2026년에 새로운 사내 어드민을 만든다면 API와 CLI만 있어도 충분한가? 같은 질문이라고 할 수 있다. 지금은 어떤 면에서는 변화 중에 있기 때문에 UI, API, MCP, CLI를 다주는게 맞나 싶기도 하면서 AI로 코딩이 빨라졌다고 해도 4개를 다 유지보수를 해야 하는 부담을 생각하면 또 걱정도 된다.</p>

          </div></div>

Outsider's Dev Story

Outsider

작년 연말 회고에서도 얘기했듯이 나는 AI에 보수적인 태도를 가지고 있다. 얼마 전에 44bits에서 사람들하고 얘기하다가 이제는 입장 돌변을 자연스럽게 받아들여야 한다는 얘기를 들었는데 그 말이 공감될 정도로 기술 발전이 빠르고 또 경험에 봄에 따라 생각이 확확 달라진다. 회고를 쓴 게 3개월 전인데 얼마 안 되었다고 할 수도 있지만 요즘 같은 시기에는 또 꽤 예전이라고도 할 수 있어서 그사이에 내 생각도 많이 달라졌다.
계속 글을 써야지 하다가 미루면서 쓰게 되는데 이 글은 현재 내 생각을 정리도 하면서 몇 달 뒤에 돌아봤을 때 "이때는 이렇게 생각했구나"하면서 돌아보기 위한 글이라고 할 수 있다.
먼저 변명(?)하자면 AI에 보수적인 태도를 일부 가지고 있는 것이지 회의적인 것은 아니다. 굳이 비교하자면 나는 블록체인에 대해서는 회의적인 견해가 있는데 여기서 다 설명할 수는 없지만 블록체인이 실용적인 어떤 결과를 만들어내지 못할 거라고 생각한다. 보수적인 태도라고 한 것은 이러한 회의적인 태도과는 다르다. 당연히 나도 AI는 더 발전하고 지금보다도 더 실용적으로 우리의 삶이나 업무에 깊숙이 들어오게 될 것이라고 믿는다.
보수적인 태도를 보이는 이유
그동안 나를 돌아보면 항상 뭔가 새로운 걸 배울 때 보수적인 태도를 가지는 편이다. 이건 내 성격이기도 한데 뭔가 새로운 걸 의심의 눈초리와 함께 쳐다보는 편이다.(영화보면 이런 사람이 더 사기를 잘 당한다던데...)
지금은 내 밥벌이나 다름없는 DevOps를 처음 알게 되었을 때도 "그럼, 개발해 놓고 운영을 안해?" 따위의 생각을 하고 있었고 Docker를 계속 공부하면서도 사실 잘 이해를 못해서 실무에서 이걸 어떻게 사용해야 하는지 전혀 감을 잡지 못하고 있었다. Kubernetes나 Service Mesh를 공부할 때도 내가 Google 같은 빅테크에서 일하는 것도 아닌데 이걸 어디다 쓰지? 같은 생각을 했다.
이건 내가 뭔가를 이해하는 과정이라는 생각도 한다. 첫눈에 반해서 막 좋아하는 기술이 없었던 건 아니지만 대부분은 내가 명확히 이해해야 사용할 수 있기 때문에 그 기술의 의미, 사용처, 예외 케이스, 트레이드 오프 등을 다 이해하려고 하다 보니 좀 떨어진 위치에서 보려고 하는 편이다. 일할 때도 이러한 성향이 나타나는 편인데 그래서 새로운 것에는 항상 내가 다 이해될 때까지는 반대하는 듯한 태도를 펴는 편이다.
그렇다고 관심을 끊지는 않는다. 예전에 DevOps나 Docker, Kubernetes 등도 대세가 될 것을 확실해 보였기 때문에 공부는 계속했다. 내가 완전히 이해를 못해서 그렇지 공부는 그만두지 않았다. AI에 대해서도 마찬가지다. 내 태도와 상관없이 AI는 계속 발전할 거고 점점 깊숙이 들어올 것이므로 AI를 찬양하는 글, 반대하는 글이나 다양한 팁과 기술 흐름의 변화는 계속 따라가려고 하고 있다.
이전에도 계속 보수적인 태도이었지만 DevOps나 Docker나 Kubernetes나 지금은 내 주요 밥벌이가 되었다. 잘 이해 못하는 느낌에 힘들었지만, 어느순간 또 그 기술을 사용하는 회사로 이직해서 사용하기 시작하면 어느 정도는 따라갈 수 있었기에 AI에 대해서도 따라가면 된다는 자신감을 어느 정도 있다.(그래도 올해는 따라가야 한다고 생각한다) 그래서 AI를 잘 쓰고 관심이 큰 사람들 주변에서 정보를 최대한 얻으려고 하고 있다.
물론 이전과 다른 점은 그때는 개발이 너무 재밌었고, 집에 와서도 하루 종일 개발관련 뭔가만 하고 있었지만, 지금은 열정이 그 정도는 아니라는 점이다. 내 태도와 상관없이 공부는 계속 해야 하는데 공부의 절대량이 부족하다는 생각이란 AI는 기존 기술과는 상당히 다르므로 그냥 글 읽고 하는 거 말고 직접 써보고 느끼고 잘 사용하는 방법을 체득해야 하는데 이런 쪽에 투입하는 시간이 절대적으로 부족하므로 생기는 조바심이 있다. 조바심은 내 커리어 내내 항상 있던 거지만 이전에는 그 조바심 때문에 학습을 엄청나게 했다면 지금은 그렇지 못하고 있다는게 지금 나의 가장 큰 문제이다. 최근에 깨달은건 내가 내 생각보다 코딩이나 엔지니어링이라는 그 과정 자체를 즐거워한 거 같다는 생각도 들고 내가 AI에는 아직 재미를 못 느끼고 있다는 생각도 든다.(최근에 재미를 조금씩 붙여나가고 있다.)
우려하는 부분
얼마 전 동료랑 얘기하다가 내가 AI에 대해서 우려하는 부분을 명확하게 깨달았는데 나는 그 "바이브" 느낌이 싫다. Andrej Karpathy가 만든 vibe coding이라는 용어는 AI로 인해 달라지는 코딩을 잘 표현한 말이기도 하고 마케팅 적으로 크게 성공한 말이기도 하다.
제가 "바이브 코딩(vibe coding)"이라고 부르는 새로운 종류의 코딩이 있어요. 분위기에 완전히 몸을 맡기고, 지수적인 발전을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 방식이죠.
코드를 읽을 필요가 있는가 없는가를 얘기하려는 것이 아니다. 그건 프로젝트의 성격, 상황에 따라 달라지게 마련이다. 내가 불편한 건 바이브 코딩이라는 용어가 책임을 전가하거나 회피하는 분위기를 만들어낸다는 것이다. 누구나 농담으로라도 한 번씩은 들어보거나 직접 해봤을 말인 "제가 안 그랬어요. AI가 그랬어요."라거나 "AI가 그렇게 대답해 줬어요." 같은 말에서 알 수 있듯이 은근히 AI에게 일을 시키고 자신의 책임을 회피하는 분위기가 생겨나고 있다고 생각한다.
AI에만 맡기지 말고, 생각을 멈추지 말고, 계속 고민하고 연구하고 더 좋은 방법을 찾아야 한다. 모든 영역이 그런 것은 아니니 단순한 반복 작업등은 더 AI에 맡겨서 시간을 확보하고 그 확보한 시간을 중요한 작업이나 고민을 많이 해야 하는 영역에 더 시간을 써야 한다. 하지만 바이브 코딩이라는 분위기가 이를 저해한다고 본다.
물론 용어 자체의 문제가 아닐 수도 있고 개개인의 성향이나 AI에 대한 기대치에 따라 달라지는 부분인 것도 맞지만, 용어에는 그런 힘이 있다고 생각해서 조심해야 한다고 본다. 그런 면에서 Andrej Karpathy가 바이브 코딩과 전문 영역에서 AI 에이전트를 사용하는 것을 구분하기 위해 Agentic Engineering을 선택한 것을 지지한다.(Addy Osmani의 Agentic Engineering도 참고)
결국 AI를 어떻게 하면 더 잘 사용할 수 있을지에 대한 논의도 아주 중요하지만 동시에 AI로 인해서 생길 문제에 대한 논의도 중요하다고 생각한다. AI뿐만 아니라 모든 혁신적인 변화 분위기에는 항상 그렇긴 하지만 우려에 관한 얘기가 마치 혁신을 저해하는 것처럼 보인다는 것도 불편하다. 물론 그냥 개인 느낌일 수도 있고 어디나 다양한 의견이 있어서 그냥 그렇게 느낄수도 있지만 그런 얘기를 짧은 글로 SNS에 하기는 어려워서 종종 블로그를 이용해야겠다고 생각하고 있다.
모든 기술은 트레이드 오프가 있기 마련이다. AI를 잘 활용하는 것만큼 잘못 사용하지 않도록 하는 것도 중요하다고 생각한다. 이건 내가 주로 인프라 업무를 하므로 더 이쪽에 대해서 많이 생각하게 되는거 같은데 어려운 점은 AI의 발전 속도가 너무 빠르다. 지금까지 보던 대부분의 기술은 변화가 생긴다는 것을 감지하고 대세가 되는 것을 보면서 준비해도 늦지 않았지만 지난 1년 사이에 AI가 달라진 걸 생각하면 뭐 준비하고 말고 할 시간이 없다. 냉정히 말해서 변화가 너무 빠르므로 최대한 활용하면서 안전장치를 동시에 만드는 수밖에는 없다고 생각한다.
요즘 고민하고 있는 부분
권한 관리
지금까지의 많은 시스템은 사람과 서비스를 대상으로 만들어졌다. 여기서 사람은 말 그대로 사람이고 서비스는 서버 등에 띄우거나 하는 어플리케이션을 의미한다. 하지만 여기에 에이전트라는 게 하나 더 생겼다. 에이전트라는 말이 요즘은 어디에나 사용되지만 여기서 말하는 에이전트를 사람이 로컬에서 돌리는 에이전트를 얘기한다. 서버에서 에이전트를 실행하는 건 그냥 서비스로 보면 된다고 생각한다.
이 에이전트는 사람한테 종속되었다는 특징이 있는데 사람의 권한을 똑같이 가져가기엔 너무 많고 에이전트에게 시킨 일에 딱 맞는 최소한의 권한만 주면 제일 좋을 것 같은데 그럴 방법이 없다. 꼭 코딩 에이전트를 예시로 들지 않더라도 에이전트를 설치해서 내 카드 사용 권한을 준다면 걱정되는 부분도 많은데 최대 10만원 제한 같은 걸 줄 수 있다면 불의의 사고에 대한 영향도를 최소화할 수 있으므로 훨씬 적극적으로 사용할 수 있을 거라고 생각한다. 하지만 현재는 이러한 방법이 없고 과도한 권한을 주고 프롬프트로 최대한 방어해서 쓰거나 제대로 사용하지 못하게 된다.
사용 성숙도 전파
AI를 코딩할 때 사용하거나 리서치, 업무 자동화 등에 많이 사용할 것이라고 보인다. 시간이 지나지면서 개선되고 있으니, 앞으로도 계속되겠지만 벌써 잘 쓰는 사람과 잘 못 쓰는 사람의 차이가 있다고 느껴지는데 이게 잘 전파가 안 된다고 느껴진다.
기존 코딩 팁이나 지식, 아키텍처 같은 것은 누군가 연구하고 정리해서 공유하면서 팀 전체에 사용 성숙도를 같이 올리는 노력을 하게 마련인데 AI는 그게 좀 쉽지 않은 느낌이다. 기존 기술과 프롬프트를 이용해서 사용하다 보니 잘 쓰는 사람도 "그냥 시키면 알아서 잘해요" 정도로 얘기하거나 별거 아니라고 생각해서 공유를 안 하게 되는 거 같기도 하다. 그리고 취향도 타기 때문에 스킬 같은 것도 남의 것을 가져오기보다 아이디어만 가져와서 직접 만들어 쓰는 게 더 자연스러워지는 거 같다.
결국 새로운 변화에 혜택받는 수준을 전체 구성원에게 일정 수준 이상으로 올리는 방법에 대한 고민이라고 할 수 있는데 AI는 기존 기술과는 사용 방법이 다르므로 이러한 고민이 의미 없고 그냥 각자에게 맡기도 다른 고민을 하는게 더 맞나하는 생각도 한다.
에이전트를 위한 인터페이스
요즘은 AI 에이전트를 10개씩 쓴다는 사람도 있지만 보통 1, 2개를 돌리는 거 같은데 당연히 시간이 지날수록 더 많아질 것이다. 그러면 에이전트에게 제공해야 하는 인터페이스는 무엇인가? 하는 고민을 하고 있다. 인터페이스라는 것을 사용하기 좋게 하면서도 사용 방법에 대한 통제권을 어느 정도 가지는 의미가 있다.
흐름으로 보면 기존에는 UI와 API만 있었고 그 뒤에 MCP가 생겼고, 지금은 CLI가 대세인 분위기이다. 요즘은 AI로 단순 코딩에 큰 노력이 들어가진 않으니 넷 다 제공하고 편한 대로 쓰라고 하는 게 맞는 거 같기도 하고 CLI가 토큰 효율성도 그렇고 사용하기 제일 좋다는 생각도 든다. 하지만 CLI를 제공하면 API도 같이 제공한 것이므로 API도 함께 제공한 것이기도 하다.
"API 사용자가 충분히 많으면 명세에 적힌 내용과 상관없이 시스템의 모든 관찰 가능한 행동에 의존하게 된다."는 하이럼의 법칙이 더욱 강해지고 있다는 요즘이다. CLI를 제공해서 사용 패턴을 제어하는 게 가장 좋다고 생각하지만 사실 API까지 같이 제공했으니, 통제권을 제어하기는 쉽지 않아 보인다. (물론 CLI가 API의 래퍼 역할이라고 볼 수도 있긴 하지만 여기서는 CLI를 제공한다는 게 사용 방식을 더 제어할 수 있을 거 같다는 개인적인 생각이 담겨있다.)
간단히 정리하면 2026년에 새로운 사내 어드민을 만든다면 API와 CLI만 있어도 충분한가? 같은 질문이라고 할 수 있다. 지금은 어떤 면에서는 변화 중에 있기 때문에 UI, API, MCP, CLI를 다주는게 맞나 싶기도 하면서 AI로 코딩이 빨라졌다고 해도 4개를 다 유지보수를 해야 하는 부담을 생각하면 또 걱정도 된다.
댓글 쓰기

요즘 하고 있는 AI에 관한 생각

댓글