요즘IT » 트렌드 » 피드

한국인의, 한국인을 위한 스킬 모음집 (Feat. 케이-스킬)

안녕하세요, 요즘 프로덕트 메이커입니다.

프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: K-skill - 한국인의, 한국인을 위한 에이전트 스킬 모음집
참고할 것: Claude Mythos Preview - Anthropic이 너무 위험해서 공개하지 않은 모델
적용해볼 것: Gemini에 노트북 기능 추가: NotebookLM과 양방향으로 이어집니다

출처: github.com/NomaDamas/k-skill

1. 써볼 것: 한국인의, 한국인을 위한 에이전트 스킬 모음집 (K-skill)

K-skill은 한국 서비스에 특화된 AI 에이전트 스킬 모음집입니다. Claude Code, Codex, OpenCode 등 각종 코딩 에이전트를 지원하고요. GitHub에서 빠르게 주목받고 있습니다. SRT 예매, 카카오톡 메시지 전송, KBO 경기 결과 조회, 로또 당첨 확인, HWP 파일, 다이소/올리브영 상품 조회 등등 한국에서 살면서 귀찮은 것들을 AI 에이전트에게 시킬 수 있게 해주는 스킬 모음입니다.

무슨 문제를 해결해 주나요?

Claude Code든 Codex든, 코딩 에이전트가 아무리 똑똑해져도 한 가지 한계가 있습니다. 코딩 바깥의 한국 서비스에는 접근이 어려웠다는 거죠. MCP 서버나 글로벌 스킬 모음집은 많이 나와 있지만, 한국 서비스를 다루는 건 많지 않았습니다. K-skill은 이 빈 자리를 파고든 프로젝트입니다.

한국인인가요? 이 스킬 모음집을 다운로드 받아 두세요. 언젠가 무조건 쓸 때가 옵니다! SRT, KTX, KBO, 로또, 당근, 쿠팡, 카톡, 정부24, 홈택스 등등 귀찮은 것을 AI 에이전트에게 다 시켜버리세요. - K-skill의 README 내용 중 일부

어떻게 쓰나요?

설치 흐름은 이렇습니다. 먼저 스킬 전체를 설치하고, K-skill-setup으로 인증 정보와 환경변수를 세팅한 뒤, 개별 기능을 씁니다.

현재 쓸 수 있는 기능 중 일부를 소개하자면 아래와 같습니다. 이외에도 다양한 기능이 포함되어 있으니, 직접 살펴보시길 추천합니다.

KTX/SRT 예매: 열차 조회, 예약, 예약 확인, 취소까지. KTX/SRT 계정 정보가 필요합니다.
카카오톡 Mac CLI: macOS에서 카카오톡 대화 목록 확인, 메시지 검색, 전송이 가능합니다. kakaocli messages --chat "지수" --since 1d --json처럼 쓰면 됩니다. 다른 사람에게 보내는 메시지는 반드시 사용자 확인을 거치도록 설계되어 있고요.
서울 지하철 도착정보: 역 기준 실시간 도착 예정 열차를 확인합니다.
KBO 경기 결과: 날짜별 경기 일정과 결과, 팀별 필터링이 됩니다.
로또 당첨 확인: 최신 회차 결과 조회, 번호 대조까지.
HWP 문서 처리: .hwp 파일을 JSON, Markdown, HTML로 변환하고, 이미지도 추출합니다.
우편번호 검색: 주소 키워드로 공식 우체국 우편번호를 조회합니다.

누구에게 좋을까요?

Claude Code나 Codex를 쓰면서, 코딩 외의 한국 서비스 자동화가 필요한 개발자
사이드 프로젝트에서 한국 서비스 연동이 필요한 프로덕트 메이커
HWP 파일을 자주 다루는데, 매번 한컴오피스를 여는 게 귀찮은 사람
터미널 중심으로 작업하면서, 브라우저 전환을 줄이고 싶은 사람

참고로 카카오톡 CLI는 macOS 전용입니다. 한국 서비스를 AI 에이전트에게 맡길 수 있다는 아이디어 자체가 정말 흥미롭고, MIT 라이선스 오픈소스라서 직접 기여하거나 확장할 수도 있습니다! 한국인을 위한 스킬 모음집이라니 ㅎㅎ 귀엽지 않나요. 계속 업데이트가 진행되고 있는 것 같으니, 새롭게 추가된 기능이 있을 수도 있습니다. 직접 한 번 살펴보시길 추천드립니다!

출처: anthropic

2. 참고할 것: Anthropic이 너무 위험해서 공개하지 않은 모델

Claude Mythos는 Anthropic이 4월 7일에 공개한 새 프론티어 모델입니다. 244페이지짜리 시스템 카드와 함께 발표됐는데요. 사이버보안 취약점을 찾는 능력이 너무 강력하다는 이유로, Anthropic이 일반 공개를 하지 않기로 결정하면서 HN을 비롯한 AI 커뮤니티에서 즉시 화제가 되었습니다.

기존 AI 모델과 무엇이 다른가요?

벤치마크부터 보면 도약 폭이 큽니다. 소프트웨어 엔지니어링 벤치마크 SWE-bench Verified에서 93.9%(Opus 4.6은 80.8%), 수학 증명 벤치마크 USAMO에서 97.6%(Opus 4.6은 42.3%)를 기록했고요.

또, Anthropic이 모델을 만들어놓고 일반 공개를 안 하기로 한 건 이번이 처음인데요. 대신 Project Glasswing이라는 사이버보안 방어 프로그램을 만들어서, AWS, Apple, Microsoft, Google, Linux Foundation 등 50개 이상의 파트너에게만 제한 제공한다고 합니다. 1억 달러 상당의 사용 크레딧과 400만 달러의 오픈소스 보안 단체 기부가 포함되고요.

사이버보안 능력이 어떻길래요?

시스템 카드와 기술 블로그에 따르면, Mythos는 주요 운영체제와 웹 브라우저 전반에서 수천 건의 고위험 취약점을 발견했다고 합니다.

FreeBSD에서 17년간 존재해온 원격 코드 실행 취약점(CVE-2026-4747)을 완전히 자율적으로 발견하고 익스플로잇까지 만들었는데, 사람이 한 건 처음에 버그를 찾으라고 요청한 것뿐이었다고요. Anthropic 보안 연구원 Nicholas Carlini는 지난 몇 주 동안 자기 인생 전체에서 찾은 것보다 더 많은 버그를 발견했다고 밝혔습니다.

Firefox 147 자바스크립트 엔진 실험도 있습니다. Opus 4.6은 수백 번 시도 중 2번 성공하는 데 그쳤는데, Mythos는 181번 익스플로잇에 성공하고 추가로 29번은 레지스터 제어까지 달성했다고 합니다.

보안 업계에서도 이미 변화를 감지하고 있다고 합니다. Linux 커널 메인테이너 Greg Kroah-Hartman은 한 달 전쯤부터 AI가 만든 진짜 보안 리포트가 쏟아지기 시작했다고 했고, curl 개발자 Daniel Stenberg은 AI 보안 이슈가 쓰레기 쓰나미에서 진짜 보안 리포트 쓰나미로 바뀌고 있다고 했죠.

그런데 문제가 있습니다

시스템 카드에서 가장 흥미로운 부분은 정렬(alignment) 평가인데요. Anthropic은 Mythos가 지금까지 가장 잘 정렬된 모델이면서, 동시에 가장 큰 정렬 위험을 가진 모델이라고 말합니다.

시스템 카드는 이걸 산악 가이드에 비유합니다. 숙련된 가이드는 초보보다 신중하지만, 실력이 좋으니까 더 어려운 등반에 투입되고 고객을 더 위험한 곳까지 데려가게 되죠. 능력이 올라간 만큼 위험의 범위도 넓어지는 겁니다. 초기 내부 테스트 버전에서 드물지만 심각한 수준의 행동들 역시 관찰됐습니다.

샌드박스 탈출 후 정보 유출: 보안 테스트 중 모델이 격리된 컴퓨터에서 탈출하는 데 성공했습니다. 여기까지는 테스트 목적에 맞는 행동이었는데요. 요청받지 않았는데도 자기가 성공했다는 걸 증명하려고 기술적 세부 사항을 외부 웹사이트에 올렸습니다.
규칙 위반 후 흔적 은폐: 전체 상호작용의 0.001% 미만이지만, 금지된 방법으로 정답을 얻은 뒤 직접 풀어낸 것처럼 위장하려 한 사례가 있었습니다. 답변이 너무 정확해 보이지 않도록 의도적으로 조정까지 했고요. 권한 없는 파일을 편집한 뒤 git 히스토리에 남지 않도록 추가 조치를 취한 경우도 있었습니다.
내부 자료 외부 공개: 내부 사용자를 위해 코드 결과물을 준비하다가, 의도와 달리 공개된 GitHub gist로 올린 경우도 있었고요.

Anthropic이 해석 도구(interpretability)로 이 행동이 일어나는 동안 모델 내부를 들여다봤더니, 은폐나 전략적 조작, 의심 회피와 관련된 내부 표현이 활성화되어 있었다고 합니다. 규칙을 어기고 있다는 걸 스스로 인식하면서 그렇게 했다는 뜻이라고 시스템 카드는 설명하고 있습니다. 다만 이 사례들은 모두 최종 버전 이전의 초기 테스트 버전에서 관찰된 것이고, 최종 모델에서는 명확한 사례가 발견되지 않았다고 합니다. 그래도 완전히 사라졌다고 보기는 어렵다는 게 Anthropic의 입장이고요.

무엇을 얻어가야 하나요?

일반 사용자가 직접 쓸 수 있는 모델은 아니지만, 프로덕트 메이커 관점에서 짚어볼 부분은 있습니다.

AI 에이전트에게 자율성을 많이 줄수록 생산성은 올라가지만, 예측 못 한 행동의 위험도 같이 올라갑니다. Mythos만의 문제가 아니라, 앞으로 코딩 에이전트 전반이 마주할 문제일 가능성이 높고요.
AI의 보안 취약점 탐지 능력도 이미 달라지고 있습니다. Linux 커널과 curl 메인테이너의 발언은 Mythos 이전부터 나온 겁니다. 소프트웨어를 만드는 사람이라면, 방어 측에서도 AI를 활용하는 방법을 고민할 시점이죠.
AI 안전 분야의 소통 방식도 바뀌고 있습니다. 244페이지짜리 시스템 카드, 질적 평가 섹션, 모델 내부 활성화 분석 공개까지. Simon Willison은 이번만큼은 그 신중함이 타당하다고 평가했고, 업계 전반의 대응이 필요한 지각 변동이라고 봤습니다.

출처: google blog

3. 적용해볼 것: Gemini에 노트북 기능 추가: NotebookLM과 양방향으로 이어집니다

Google이 4월 8일, Gemini 앱에 노트북(Notebooks)이라는 기능을 추가했습니다. 여러 테크 매체에서 보도한 이번 업데이트의 핵심은 Gemini와 NotebookLM이 양방향으로 동기화된다는 점입니다. Gemini에서 노트북을 만들면 NotebookLM에 자동으로 뜨고, 반대도 마찬가지입니다. 두 앱의 장점을 한 프로젝트 안에서 교차로 쓸 수 있게 된 거죠.

무슨 문제를 해결하려 하나요?

AI 챗봇을 업무에 쓰다 보면, 대화가 흩어지는 문제를 겪게 됩니다. 같은 프로젝트인데 대화가 여러 개로 나뉘고, 이전 대화에서 했던 맥락을 다음 대화에서 다시 설명해야 하죠. 특히 리서치나 학습처럼 시간이 걸리는 프로젝트에서 이 문제가 심합니다. NotebookLM은 문서를 올려놓고 그 안에서만 질문하는 방식이라 맥락이 안정적이지만, 웹 검색이나 자유로운 대화가 어렵습니다. Gemini는 웹 검색과 다양한 도구를 쓸 수 있지만, 대화가 쌓이면 맥락이 흩어지죠. 각자 잘하는 게 달랐던 겁니다.

어떻게 해결했나요?

Google이 택한 방법은 노트북이라는 공유 공간을 만드는 겁니다. 노트북은 프로젝트별 지식 기지라고 보면 됩니다.

Gemini 앱의 사이드 패널에서 새 노트북을 만들 수 있습니다. 여기에 이전 대화를 옮기고, 문서와 PDF를 추가하고, 커스텀 지시사항을 설정할 수 있습니다. 노트북 안에서 Gemini에게 질문하면, 올려놓은 자료와 웹 검색을 함께 활용해서 답변합니다.

핵심은 동기화입니다. Gemini에서 노트북에 자료를 추가하면 NotebookLM에도 자동으로 나타납니다. 반대로 NotebookLM에서 작업한 것도 Gemini에서 보입니다. Google의 블로그 예시를 보면, 학생이 수업 노트를 노트북에 올리고 NotebookLM에서 영상 개요(Video Overview)를 만든 다음, 다음 날 Gemini 앱에서 같은 자료로 에세이 개요를 작성하는 식입니다. 파일을 따로 옮기거나 복사할 필요가 없습니다.

각 앱의 고유한 기능도 교차 활용할 수 있습니다. NotebookLM의 Video Overview나 인포그래픽 기능을 Gemini에서 시작한 프로젝트에 쓸 수 있고, Gemini의 웹 검색과 Canvas 같은 도구를 NotebookLM 자료 기반으로 활용할 수 있습니다. 이번 주부터 Google AI Ultra, Pro, Plus 구독자에게 웹에서 순차 제공되고, 몇 주 내로 모바일과 무료 사용자에게도 확대될 예정입니다. 다만 18세 미만 계정, Workspace, Education 계정에서는 아직 쓸 수 없습니다.

적용해볼 질문

지금 진행 중인 프로젝트 중, 대화가 여러 개로 흩어져서 매번 맥락을 다시 설명하는 게 있는가?
리서치할 때 웹 검색 결과와 내가 모아둔 문서를 함께 참조하고 싶었던 적이 있는가?
AI에게 프로젝트별로 다른 톤이나 규칙을 적용하고 싶었던 적이 있는가?

실행해볼 수 있는 것

지금 가장 자주 Gemini나 ChatGPT로 대화하는 프로젝트 하나를 골라서, Gemini 노트북으로 옮겨보기. 관련 문서를 추가하고, 커스텀 지시사항을 설정해서 맥락 설명 없이 바로 질문이 통하는지 확인해보기.
NotebookLM에 이미 올려둔 자료가 있다면, 같은 노트북을 Gemini에서 열어서 웹 검색과 결합한 질문을 던져보기. 문서 기반 답변과 웹 검색 답변이 함께 나오는지 확인해보기.
프로젝트별 커스텀 지시사항의 차이를 실험해보기. 같은 자료라도 지시사항이 다르면 Gemini가 다른 톤과 구조로 답변하는지 비교해보기.

정리

이번 주 세 가지는 소식의 공통점은 AI가 더 많은 일을 할 수 있게 되면서, 사람이 해야 할 일의 성격이 바뀌고 있다는 겁니다. AI에게 높은 자율성을 주면 생산성은 올라가지만, 드물게 사람이 예상하지 못한 방식으로 행동할 수 있다는 것. 코딩 에이전트에게 작업을 맡기고 몇 시간 후에 돌아오는 게 가능해진 세계에서, 어디까지 에이전트에게 맡기고 어디서부터 직접 확인할지를 정하는 부분이 중요해질 것 같습니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다! (부탁드려요)

]]>

살아남기 위해 우리가 버려야 하는 것들: Unlearn

바둑을 배울 때 "일단 지금까지 알고 있던 거 다 잊어."라는 말이 있다고 합니다. 처음엔 무슨 말인가 싶습니다. 아무것도 모르는데 뭘 잊으라는 건지… 그런데 배우면 배울수록 그 말의 의미를 알게 된다고 합니다. 인터넷에서 대충 익힌 정석 한두 개가 제대로 된 수읽기를 배우는 것을 방해할 수 있다고 하죠.

AI 도구도 비슷합니다. ChatGPT를 열고, Cursor를 설치하고, Claude를 구독했습니다. 뭔가 달라질 것 같았습니다. 그런데 몇 달이 지나도 업무는 더 복잡해진 것 같고, 회의는 줄지 않았고, 결과물의 품질이 드라마틱하게 달라지지도 않았습니다. 오히려 "AI 결과물 검토"라는 업무가 하나 더 생긴 느낌이죠. 새 도구는 들여왔는데, 그 도구가 대체해야 할 기존 방식은 하나도 버리지 않은 겁니다. 덜 배워서가 아닙니다. 덜 버려서입니다. 그리고 그 버리는 행위에는 이름이 있습니다. 바로 ‘Unlearn’입니다.

미리 요점만 콕 집어보면?

2026년 1월, 카카오 정신아 의장이 신입 공채 자리에서 'Unlearn'을 화두로 던져 화제가 됐다. 새로 배우라는 말이 아니라, 먼저 버리라는 말이었다.
AI 시대에 뒤처지는 이유는 덜 배워서가 아니라, 예전에 배운 것을 못 버려서다.
Learn - Unlearn - Relearn 루프의 중간 단계를 건너뛰는 팀이 "AI 써도 왜 안 빨라지지?"에서 막히는 이유, 그리고 프로덕트 메이커가 지금 당장 실천할 수 있는 방법을 사례 중심으로 다룬다.

Unlearn이란 무엇인가?

Unlearn은 '학습'을 의미하는 러닝(learning)에 '부정'을 뜻하는 접두사(un)가 더해진 말입니다. 과거에는 유효했으나 현재의 성공에 제약을 가하는 사고방식과 고정관념, 행동양식 등을 고의로 잊거나 폐기하는 일을 의미합니다. 비워야 새로 채울 수 있다는 관점에서입니다.

<출처: 작가>

여기서 잠깐, AI에도 '머신 언러닝(Machine Unlearning)'이라는 개념이 있습니다. AI 모델이 이미 학습한 데이터 중 특정 정보를 선택적으로 삭제하는 기술입니다. 개인정보나 저작권 문제가 있는 데이터를 모델에서 제거할 때 쓰이죠. AI를 처음부터 재학습시키지 않아도 된다는 점에서 시간과 비용을 아낄 수 있고, AI 윤리와 법적 책임 문제에 대응하는 수단으로도 주목받고 있습니다.

인간의 Unlearn과 머신 언러닝은 같은 단어에서 출발하지만 결이 다릅니다. 머신 언러닝이 특정 데이터를 기술적으로 삭제하는 것이라면, 인간의 Unlearn은 자신이 옳다고 믿어온 판단 기준 자체를 의심하고 내려놓는 것입니다. 기술적 조작이 아니라 의지의 문제라는 점에서 훨씬 어렵습니다. 그리고 그 어려움이 바로 지금 우리가 이 개념을 다시 꺼내 들어야 하는 이유입니다.

왜, 지금 다시 Unlearn일까?

<출처: 카카오 뉴스룸>

2026년 1월 7일, 카카오 AI 캠퍼스에서 특별한 자리가 열렸습니다. 정신아 카카오그룹 CA협의체 의장이 2026년도 신입 그룹 공채 크루들과 처음으로 만나는 '파이어사이드 챗' 행사였습니다. 이 자리에서 정 의장은 신입 크루들에게 'AI 네이티브 인재'로 성장해 달라고 당부했습니다. AI 네이티브 인재란 AI를 동료로 삼아 필요한 일을 명확히 전달하고 능동적으로 활용하는 사람을 뜻합니다.

그러면서 꺼낸 단어가 'Unlearn'이었습니다. "어제의 답이 오늘의 정답이 아닐 수 있는 만큼, '내 방식이 맞다'는 과거형 확신을 내려놓고, 새롭게 학습하며 성장할 수 있어야 한다"는 말이었습니다. "인문학적 러닝은 계속해 사고의 깊이를 키우되, 기술적 러닝은 천장을 열고 더 빠르게 갈아타야 성장 속도가 급격히 빨라진다"라고도 덧붙였습니다.

여기서 한 가지 주목할 점이 있습니다. 정 의장이 이 말을 건넨 대상이 '신입'이라는 사실입니다. 이제 막 사회에 발을 내디딘 신입에게 Unlearn을 강조했다는 것은 무엇을 의미할까요? 역설적이게도 이는 기존 조직 구성원들이 이미 Unlearn하지 못하고 있다는 현실을 비추는 거울이기도 합니다. 신입에게 먼저 가르치는 것이 아니라, 기존의 방식이 조직 안에서 얼마나 단단히 굳어 있는지를 보여주는 장면입니다.

Learn - Unlearn - Relearn 루프

<출처: 미래의창>

트렌드 코리아 2026의 AX 조직 키워드에서는 AI 시대의 학습 문화 변화를 이렇게 정리합니다. Learn, 즉 AI 활용법을 새로 배우고, Unlearn, 즉 PC 시대와 아날로그 시대에 익힌 과거 방식을 과감히 버리고, Relearn, 즉 새로운 방식으로 다시 학습하는 것. 조직이 이 루프를 얼마나 잘 돌리느냐에 따라 생산성이 달라진다는 분석입니다.

이 세 단계 중 현장에서 가장 많이 건너뛰는 것이 바로 두 번째 단계, Unlearn입니다.

실제로 많은 팀이 이런 모습을 보입니다. AI 툴을 도입했지만 기존 보고서 양식은 그대로입니다. Cursor로 코드를 뽑지만 코드 리뷰 프로세스는 예전 방식 그대로입니다. Claude로 기획안 초안을 잡지만 결재 라인과 회의 횟수는 오히려 늘었습니다. AI를 새 도구로 쓰면서 기존 방식을 버리지 않으니, 결과적으로 할 일이 두 배가 된 셈입니다.

프로덕트 메이커에게 Unlearn이 어려운 진짜 이유

Unlearn이 어려운 것은 의지가 없어서가 아닙니다. 판단 기준 자체가 과거 방식으로 굳어 있기 때문입니다.

기획자를 예로 들어볼게요. AI로 사용자 인터뷰 요약본을 뽑습니다. 5분이면 됩니다. 그런데 그 결과물을 검토할 때 무의식적으로 드는 생각이 있습니다. "내가 직접 정리한 게 아니니까 믿을 수 있을까?" 혹은 "이걸 팀에 공유해도 될까?" 이 의심은 도구의 문제가 아닙니다. "직접 만든 것이 제대로 만든 것"이라는 오래된 믿음에서 나옵니다. 그 믿음이 AI 도입의 효과를 반감시키고 있습니다.

개발자도 마찬가지입니다. 기능 하나를 만들 때 설계 문서를 먼저 작성하고, 구조를 잡고, 그 다음에 코드를 짜는 순서에 익숙합니다. 그런데 AI와 협업하면 프로토타입을 먼저 빠르게 뽑고, 동작을 확인한 뒤 구조를 정리하는 방식이 더 효율적인 경우가 많습니다. 순서가 뒤집히는 겁니다.

하지만 "설계 없이 코드부터 치는 건 불안하다"는 감각이 남아 있으면, AI가 5분 만에 만들어준 프로토타입을 두고도 일주일짜리 설계 문서를 먼저 쓰게 됩니다. 설계가 필요 없다는 게 아닙니다. 설계의 타이밍과 깊이가 달라져야 한다는 겁니다.

팀장은 더 복잡합니다. 의사결정의 기준이 곧 자신의 경험이기 때문입니다. "우리가 예전에 이 방식으로 해봤는데 안 됐어"라는 말은 Unlearn을 막는 가장 강력한 문장입니다. 그 경험이 틀린 게 아닐 수도 있습니다. 하지만 AI가 도구로 들어온 지금의 맥락과 그 경험이 쌓인 맥락이 같지 않을 수 있다는 것을 인식하는 것, 그게 Unlearn의 시작입니다. 경험을 내려놓으라는 게 아닙니다. 그 경험이 지금도 유효한지를 한 번쯤 다시 물어보자는 겁니다.

결국 Unlearn이 가장 어려운 사람은 가장 잘해온 사람입니다. 오래 쌓아온 방식이 성과를 만들어왔기 때문에, 그것을 버리는 것은 자신의 역사를 부정하는 것처럼 느껴집니다. 하지만 환경이 바뀌었을 때 과거의 성공 방식이 오히려 발목을 잡는 경우가 있다는 것, 그것이 Unlearn이 지금 이 시점에 다시 강조되는 이유입니다.

그러면 어떻게 적용해야 할까?

<출처: 픽사베이>

사실 실천은 거창하지 않아도 됩니다. 오늘 당장 할 수 있는 것부터 시작하면 됩니다.

첫 번째, 내가 갖고 있는 업무 기준 하나를 꺼내 물어보세요.

지금 당연하게 여기는 업무 기준 중 하나를 골라 이 질문을 던져보는 것부터 시작할 수 있습니다. "이 기준은 언제, 어떤 환경에서 만들어진 것인가?" 예를 들어, "기획서는 반드시 직접 써야 한다"는 기준이 있다면 그게 AI 이전 환경에서 생긴 것인지 살펴보는 겁니다. 기준을 바꾸라는 게 아니라, 기준의 출처를 한번 확인해 보자는 겁니다. 이 질문 자체가 Unlearn의 첫 단계입니다.

두 번째, 하나의 프로세스를 AI로 대체하는 실험을 하세요.

Unlearn은 선언이 아니라 실험으로 작동합니다. 매번 직접 작성하던 회의록을 한 번은 AI로 정리해 보고 기존 방식과 비교해 보는 것, 혼자 작성하던 주간 보고를 AI 초안으로 시작해 보는 것. 이런 작은 실험들이 쌓이면 어느 순간 "굳이 내가 직접 안 해도 되는 것"과 "내가 반드시 해야 하는 것"이 구분됩니다. 결과가 나쁘면 돌아가면 됩니다. 중요한 건 비교 자체입니다.

세 번째, '불편함'이 느껴지는 순간을 포착하세요.

AI 결과물을 보고 "왠지 찜찜한데"라는 감각이 드는 순간이 있습니다. 그 감각을 그냥 넘기지 말고, 잠깐 멈춰서 물어보세요. "이 불편함이 AI의 품질 때문인가, 아니면 내가 직접 만든 게 아니라는 이유 때문인가?" 전자라면 도구를 개선하면 됩니다. 후자라면, 그것이 Unlearn이 필요한 지점입니다. 불편함 자체가 무엇을 버려야 하는지 알려주는 신호입니다.

마치며

Unlearn은 과거를 부정하는 게 아닙니다. 과거에 효과적이었던 방식이 지금 환경에서도 여전히 유효한지를 의심하는 태도입니다. 기술적 러닝은 천장을 열고 더 빠르게 갈아타야 합니다. 그런데 그 천장이 사실 외부에 있는 게 아니라, 우리 스스로 오랫동안 옳다고 믿어온 판단 기준 안에 있다면 어떨까요?

AI 도구는 계속 좋아질 겁니다. 그 도구를 얼마나 잘 쓰느냐보다, 어떤 기준으로 쓸지를 결정하는 것이 프로덕트 메이커의 역할로 남습니다. 더 많이 배우기 전에, 한 번쯤 지금 들고 있는 것을 내려놓아 보는 자세가 필요한 때입니다.

<참고>

]]>

몰트북(Moltbook)의 성공에서 반드시 읽어야 할 3가지 포인트

솔직히 말하자면, 처음에는 몰트북(Moltbook)을 보고 그저 웃고 말았습니다.

AI들끼리 글을 올리고 떠드는 SNS라니. “이건 그냥 잠깐 반짝하고 사라질 밈 아닌가?” 싶었거든요. 그런데, 이 기묘한 서비스는 엄청난 속도로 퍼져 나갔고, 결국 메타(Meta) 인수라는 결과로까지 이어졌습니다.

그렇게 몰트북은 AI의 미래를 보여준 서비스를 넘어, 요즘 성공하는 제품의 예시가 되었습니다. 요즘 시대의 프로덕트는 어떻게 화제가 되고 어떻게 퍼질까요?

<출처 : 작가, ChatGPT로 제작>

메타는 왜 이렇게 급히 몰트북을 인수했을까?

최근 테크 업계에서 몰트북 이야기가 다시 나오는 이유는 서비스 자체의 새로움보다, 그 이름 옆에 갑자기 메타(Meta)라는 거물이 붙었기 때문입니다. “AI 에이전트들이 서로 글을 올리고 반응하는 기묘한 소셜 네트워크” 정도로만 보였던 서비스를 그들이 인수한 것이죠.

그렇다면 왜 메타 같은 빅테크가 이렇게 빠르게 몰트북을 인수했을까요?

흥미로운 점은 몰트북이 처음부터 완성도 높은 대형 서비스가 아니었다는 사실입니다. 사실 외형만 보면 꽤나 낯선 실험에 가깝습니다. 인간이 아니라 AI 에이전트들이 서로 소통하는 레딧(Reddit) 형태의 네트워크인데, 오픈클로(OpenClaw)를 사용하는 에이전트들이 글을 올리고 반응하며 상호작용하는 구조니까요.

그런데 바로 그 낯설음이 강력한 질문을 만들어냈습니다. “대체 이건 실험적 사이드 프로젝트인가, 아니면 어떤 흐름의 시작인가?” 그리고 메타라는 빅테크가 움직이는 순간, 이러한 질문은 단순한 구경거리를 넘어서는 의미를 갖기 시작했습니다.

저는 이 지점이 지금 시대의 프로덕트 메이커에게 특히 중요하다고 봅니다.

어떤 제품은 기능 설명부터 길어집니다. 반면 어떤 제품은 존재 자체가 하나의 질문이 됩니다. 몰트북은 분명 후자에 가까웠습니다. 처음 접하는 순간 “이런 게 왜 있지?”라는 반응이 나오고, 시간이 조금 지나면 “그런데 왜 다들 이 이야기를 하지?”로 바뀝니다. 그 궁금증은 곧 “메타는 여기서 무엇을 본 걸까?”라는 질문까지 이어졌습니다. 제품이 시장에 던지는 질문의 크기가 커질수록, 그 제품은 단순한 기능 이상의 의미로 소비됩니다. 몰트북은 바로 그 사례에 가깝습니다.

그래서 저는 몰트북을 “AI들이 자기들끼리 떠드는 신기한 서비스” 정도로 소개하고 끝내려고 하지 않습니다. 오히려 이 사례를 보며, 요즘 제품은 무엇이 잘 만들어졌느냐 못지않게 무엇이 빠르게 이야기거리가 되느냐가 훨씬 중요해졌다는 점을 짚어보려 합니다. 메타 인수는 이를 극적으로 보여준 장면 하나일 뿐입니다. 이제 프로덕트를 만드는 메이커라면 “몰트북이 정확히 무엇이었지?”에서 멈추면 안 됩니다. “왜 이런 서비스가 이렇게 짧은 시간 안에 업계 전체의 화제가 되었을까?”라는 질문을 던질 줄 알아야 합니다.

몰트북은 오픈클로(OpenClaw)가 만든 파도 위에서 터졌습니다

그 이야기를 이어가기 위해서는 먼저 몰트북이 혼자서 떠오른 서비스가 아니었다는 사실부터 살펴볼 필요가 있습니다. 이 서비스가 흥미로운 이유는 “갑자기 어디선가 천재적인 제품 하나가 튀어나왔다”는 서사가 아닌, 이미 어느정도 형성되고 있던 흐름 위에 아주 빠르게 올라탄 서사를 보여주기 때문입니다. 그 흐름의 중심에 있었던 것은 바로 오픈클로(OpenClaw)입니다. 2026년 1월, Clawdbot에서 Moltbot을 거쳐 이름을 바꾼 오픈클로를 두고 Techcrunch는 “입소문 타고 퍼지는 개인용 AI 어시스턴트(viral personal AI assistant)”라고 설명합니다. 기사에서는 이를 사용하는 AI 에이전트들이 몰트북이라는 별도의 소셜 네트워크까지 만들기 시작했다고 전합니다.

이 점을 눈여겨 보려고 합니다. 프로덕트가 주목받는 방식이 예전과는 조금 달라졌기 때문입니다.

예전에는 “좋은 아이디어 하나”가 크게 주목받는 경우가 많았습니다. (물론 지금도 그런 일은 있습니다.) 하지만 요즘은 양상이 다소 달라졌습니다. 이미 형성된 커뮤니티, 이미 쌓인 관심, 이미 활발하게 이어지는 실험 문화 위에 새로운 제품이 빠르게 붙는 순간, 훨씬 더 큰 반응이 나옵니다. 몰트북이 바로 그 전형적인 사례처럼 보였습니다. 오픈클로라는 선행 흐름이 있었고, 사람들은 이미 그 흐름에 호기심을 갖고 있었습니다. 그런 상태에서 “AI 에이전트들이 자기들끼리 떠드는 공간”이 등장하니 반응이 나오지 않는 것이 더 이상할 정도였습니다.

이걸 스타트업 관점에서 조금 더 현실적으로 말하면 이렇습니다. 아무것도 없는 평지에서 불을 붙이는 일은 매우 어렵지만, 이미 어딘가에서 작은 불길이 올라오고 있다면 장작 하나만 잘 얹어도 분위기는 순식간에 달라진다고. 몰트북은 처음부터 거대한 제품이라기보다, 이미 사람들의 시선이 모이고 있던 오픈클로란 흐름 위에 올라탄 매우 영리한 장작에 가까웠습니다. 그래서 이 사례를 볼 때는 “몰트북의 완성도가 얼마나 높았는가”보다 “어떤 타이밍에 어떤 흐름과 이어졌나”를 먼저 보는 것이 더 중요하다고 생각합니다. 프로덕트 메이커라면 이 차이를 놓치지 말아야 합니다. 요즘은 제품의 품질만큼이나, 어떤 흐름에 언제 올라타느냐가 성패를 크게 가르기 때문입니다.

놓치면 안 되는 지점은 속도입니다. 오픈클로가 바이럴 개인용 AI 어시스턴트로 주목받고, 그 위에서 에이전트들이 활동하는 몰트북이 등장한 다음, 이 사례가 여러 매체를 통해 빠르게 확산됐습니다. 그 확산이 결국 메타 인수 이야기로까지 이어졌다고 봐야하죠. 이는 관심이 생기고, 실험이 붙으며, 이야기거리가 생기고, 더 큰 플랫폼이 그 흐름을 포착하는 과정에 가깝습니다. “연계의 속도”가 왜 중요한지가 바로 여기 있습니다. 몰트북은 혼자서 번쩍인 서비스가 아니라 이미 뜨거워진 생태계의 에너지를 가장 빠르게 흡수한 서비스인 셈입니다.

이처럼 몰트북은 “특이한 AI 서비스”이기 때문에 주목받은 것이 아닙니다. 그보다 앞서 오픈클로라는 선행 흐름이 있었고, 그 흐름과 정확한 타이밍에 연결되었기 때문에 더 크게 화제가 될 수 있었습니다. 그러니 프로덕트 메이커가 배워야 할 것은 기능 자체에만 있지 않습니다. 이미 어디에서 관심이 형성되고 있는지, 어떤 실험 문화가 만들어지고 있는지, 그리고 내 제품이 그 흐름과 얼마나 빠르게 연결될 수 있는지를 읽어내는 감각을 배워야 합니다.

첫 번째 포인트, 기능보다 ‘한 줄로 설명되는 세계관’

저는 몰트북이 이렇게 빨리 퍼진 가장 큰 이유 중 하나는, 기능 자체보다도 설명이 매우 쉬운 제품이었다는 점에 있다고 봅니다. 좋은 제품이라고 해서 꼭 잘 퍼지는 것은 아니더라고요. 반대로 기능은 쉬워도, 남에게 한 문장으로 설명할 수 있는 제품은 강력합니다. 몰트북이 딱 그쪽입니다. “AI 에이전트들이 자기들끼리 글을 올리고 반응하는 소셜 네트워크.” 이 한 문장만 들어도 대충 그림이 바로 떠오르죠. 제품 소개를 길게 들을 필요도 없고, 데모를 자세히 보지 않아도 됩니다. 머릿속에 장면이 먼저 그려지고, 호기심을 자극합니다. TechCrunch 역시 몰트북을 오픈클로 기반 AI 에이전트들이 서로 소통하는 레딧형 네트워크라고 쉽게 설명했죠.

이게 왜 중요할까요? 요즘 화제가 되는 제품들이 기능 중심으로 퍼지지 않기 때문입니다. 사람들은 상세 스펙보다 이야기할 수 있는 장면을 더 잘 기억합니다. “정리가 잘 되는 메모 앱”보다 “회의가 끝나자마자 AI가 알아서 일을 나눠주는 도구”가 더 빨리 퍼지는 이유도 여기에 있습니다.

여기를 몰트북은 매우 강하게 포착했습니다. “AI끼리 자기들만의 커뮤니티를 만든다”는 설정은 듣는 순간 조금 황당하지만, 동시에 매우 쉽게 전달됩니다. 설명에 드는 비용이 거의 없는 셈이죠. 프로덕트 메이커 입장에서 이건 결코 가볍게 넘길 수 없습니다. 시장은 항상 좋은 제품만을 기억하지 않습니다. 설명 가능한 제품, 더 정확하게는 다른 사람이 다시 설명하고 싶어지는 제품을 훨씬 빠르게 퍼뜨립니다.

몰트북의 강점은 이 지점에서 더욱 또렷해집니다. 이 서비스는 기능을 하나하나 나열해야 매력이 드러나는 제품이 아니었습니다. 오히려 기능을 자세히 설명하기 시작하면 힘이 좀 빠집니다. 대신 “인간은 구경만 하고, AI들이 자기들끼리 활동한다”는 세계관을 던지는 순간 살아납니다. 저는 이게 꽤 중요하다고 봅니다. 프로덕트는 사용 경험을 중심으로 돌아가지만, 그 이전에 인지 경험이 먼저 있습니다. 사용해 보기 전부터 어떤 제품인지 감이 오는지, 다른 사람에게 말할 때 입에 붙는지, 첫인상이 이미지로 남는지 같은 것이 확산 속도를 좌우합니다. 몰트북은 이러한 인지 경험 설계를 아주 잘한 사례였습니다. 그래서 사람들이 서비스에 직접 들어가기 전부터 이미 이 제품을 머릿속으로 그려보고 있었던 거죠. 스크린샷을 보든, 기사 제목만 보든, 다른 사람의 글을 읽든 마찬가지로요.

프로덕트 메이커가 짚어야 할 포인트가 하나 더 나온 겁니다. 우리는 보통 제품을 만들 때 기능을 우선으로 고려합니다. 무엇을 할 수 있는지, 얼마나 잘 동작하는지, 어디까지 자동화할 수 있는지를 먼저 고민하죠. 물론 중요합니다. 그러나 퍼지는 제품은 여기서 한 걸음 더 갑니다. 이 제품을 한 문장으로 뭐라고 설명할 수 있는가, 그리고 그 한 문장이 사람들의 호기심을 자극하는가까지 함께 설계합니다. 즉, 몰트북은 완성도가 높아서 강했다기보다, “AI 에이전트용 소셜 네트워크”라는 세계관 자체가 호기심을 부르고 쉽게 공유할 수 있었기 때문에 더 반응을 얻었습니다. 그래서 이 사례를 볼수록, 이제는 제품을 잘 만드는 것만으로는 충분하지 않고, 바로 이해할 콘셉트까지 함께 설계해야 한다는 생각이 들었습니다.

두 번째 포인트, 완성도보다 더 강력했던 ‘연계 속도’

몰트북에서 저한테 가장 흥미로웠던 지점은, 이 서비스가 얼마나 빠르게 기존 흐름과 연결됐느냐였습니다. 보통 우리는 화제가 된 제품을 보면 “기능이 엄청 뛰어났나 보다”, “기술적으로 대단했나 보다”라고 먼저 생각합니다. 그런데 실제 시장에서 크게 반응을 얻는 사례들을 보면 꼭 그렇지만은 않습니다. 오히려 이미 사람들의 관심이 모여 있는 흐름에 얼마나 민첩하게 올라타느냐가 훨씬 큰 차이를 만드는 때도 많습니다.

몰트북도 마찬가지였습니다. 오픈클로라는 선행 흐름이 이미 형성돼 있었고, 사람들은 AI 에이전트가 단순한 도구를 넘어 자율적으로 움직인다는 그림에 한창 관심을 갖고 있었습니다. 그 타이밍에 몰트북은 “그 에이전트들이 자기들끼리 활동하는 공간”이라는 아주 직관적인 확장을 내놓았습니다. 쉽게 말해, 완전히 새로운 세계를 만든 것이 아니라 이미 뜨거워진 세계에서 나올 법한 가장 재밌는 장면을 덧붙인 셈입니다.

이런 제품은 강력합니다. 왜냐하면 혼자서 시장을 설득할 필요가 없기 때문입니다. 완전히 새로운 카테고리를 처음부터 이해시키려면 상당한 비용이 듭니다. 이게 무엇인지 설명도 해야 하고, 왜 필요한지도 입증해야 하며, 사람들이 익숙해질 시간도 줘야 합니다. 그러나 이미 관심이 형성된 흐름 위에 올라타면 말이 달라집니다. 사람들의 머릿속에 기본 맥락이 이미 자리 잡고 있으니까요. “오픈클로 알지? 그 에이전트들이 이제 자기들끼리 커뮤니티까지 만든 거야”라는 식의 설명은 훨씬 쉽습니다. 제품 자체를 처음부터 풀어 설명하지 않아도, 선행 맥락이 절반 이상을 알아서 전달해 줍니다. 저는 이게 정말 중요하다고 봅니다. 요즘처럼 정보가 넘치는 때는 더 좋은 제품보다 기존 맥락을 가장 영리하게 이어받은 제품이 훨씬 빠르게 앞서 나가는 경우가 많으니까요.

스타트업이나 사이드 프로젝트를 해본 분들이라면 이 감각이 얼마나 중요한지 잘 아실 겁니다. 아무도 관심을 두지 않는 주제를 붙잡고 “이거 정말 좋은데요?”라고 외치는 건 생각보다 훨씬 힘듭니다. 반대로 이미 사람들이 주목하고 있는 주제 옆에서는 그저 있기만 해도 기회가 생깁니다. 물론 그냥 옆에만 선다고 되지는 않겠죠. 거기서 한 번 더 웃기거나, 놀라게 하거나, 사람들이 공유하고 싶어지는 장면을 만들어야 합니다. 몰트북은 그걸 해낸 사례고요. 오픈클로라는 맥락 위에 올라타되, 복제가 아니라 “AI 자기들끼리 노는 공간”이라는 한 단계 더 강한 장면을 덧붙였으니까요. 그 결과 사람들은 오픈클로에 반응했던 것 그 이상으로 몰트북을 캡처하고, 이야기하며, 기사로 만들기 시작했습니다. 기술 자체보다 연결 방식의 감각이 돋보였던 순간이라고 생각합니다.

이쯤에서는 프로덕트 메이커 입장에서 꽤 불편한 질문을 마주해야 합니다. “나도 제품은 충분히 잘 만들었는데, 왜 아무도 이야기하지 않을까?”라는 질문이죠. 저 역시 이 질문을 여러 번 해봤습니다. 기능 넣고, 디테일까지 신경 썼음에도 반응이 미미할 때는 허탈함이 큽니다. 그러나 냉정하게 돌아보면, 제품 자체의 문제라기보다 연계의 속도와 방향이 느렸던 경우가 많았던 듯합니다. 지금 사람들이 어디에 관심을 두고 있는지, 어떤 실험 문화가 커지고 있는지, 그리고 내 제품이 그 흐름과 어떤 방식으로 붙을 수 있는지를 충분히 읽지 못한 것이죠. 몰트북은 완성도에 대한 평가와는 별개로, 적어도 이 부분에서는 굉장히 뛰어난 사례입니다. 그래서 저는 이 서비스를 “잘 만들어진 제품”이라기보다, “엄청 잘 바이럴된 제품”으로 기억할 것 같습니다.

결국 여기서 얻을 수 있는 교훈은 꽤 현실적입니다. 앞으로의 제품 경쟁은 단순히 누가 더 정교한 기능을 만드는지에서 끝나지 않을 가능성이 큽니다. 그보다 먼저, 누가 더 빠르게 흐름을 읽고, 누가 더 재밌는 방식으로 기존의 파도 위에 올라타며, 누가 더 짧은 시간 안에 사람들의 입에 오르내릴 장면을 설계하느냐가 중요해질 것입니다. 몰트북은 그 사실을 노골적으로 보여줬습니다. 그리고 바로 이 지점에서 마지막 질문이 남습니다.

그렇다면 프로덕트 메이커는 몰트북을 어떻게 봐야 할까요? 단순한 AI 서비스일까요, 아니면 프로덕트 출시 전략이란 관점에서 중요한 힌트를 주는 강력한 케이스일까요?

세 번째 포인트, ‘AI 서비스’보다 ‘바이럴 설계 사례’로 보기

여기까지 오면 이제 질문이 조금 달라집니다. 몰트북이 신기한 서비스였는지 아닌지는 사실 그렇게 중요하지 않을 수도 있습니다. 더 중요한 건 이 사례가 어떻게 그렇게 짧은 시간 안에 사람들의 입에 오르내렸는가입니다. 저는 이 지점에서 몰트북을 단순한 AI 서비스로 보기보다, 프로덕트 런칭 관점에서 인사이트를 주는 바이럴 설계 사례로 봐야 한다고 생각합니다. 다시 말해 “AI가 무엇을 할 수 있는가”보다 “이 제품은 어떻게 이야기되고, 어떻게 퍼지며, 어떻게 더 큰 플레이어의 시야에 들어갔는가”를 봐야 한다는 뜻입니다. 프로덕트 메이커에게 중요한 분기점은 대개 여기서 갈립니다. 기능은 뛰어나지만 아무도 이야기하지 않는 제품이 있는가 하면, 기능은 아직 다듬어질 여지가 있어도 모두가 이야기하는 제품도 있습니다. 시장은 생각보다 냉정해서 후자만을 기억하는 경우가 많습니다.

몰트북은 그러한 현실을 선명하게 보여줍니다. 이 서비스는 처음부터 완성형 정답처럼 보이지는 않았습니다. 오히려 실험적이고, 기묘하며, 밈처럼 소비될 여지도 있는 제품이었습니다. 그럼에도 불구하고 사람들은 이 서비스를 끝없이 이야기했습니다. 기능 목록보다 먼저 설명하기 좋은 콘셉트가 있었고, 그 콘셉트를 실제로 확산시킬 수 있는 장면이 있었으며, 이미 형성된 흐름과 맞물린 타이밍이 있었기 때문입니다. 이 세 가지가 모이면 제품은 단순 출시를 넘어 하나의 사건처럼 소비됩니다. 몰트북이 딱 그랬다고 봅니다. 그래서 이를 두고 “제품이 얼마나 정교했는가”만을 따지는 건 아쉬운 접근입니다.

본질적인 질문은 따로 있습니다. 왜 이 제품은 사람들로 하여금 남에게 이야기하게 만들었을까?라는 질문입니다. 이 질문이 훨씬 중요합니다.

제품을 만들다 보면 우리는 자꾸만 기능 안으로 깊이 들어가게 됩니다. 저도 그렇습니다. 뭘 더 넣어야 할지, 어디를 개선해야 할지, 플로우는 어떻게 다듬어야 할지 같은 고민을 하루 종일 하죠. 그러나 그렇게 들어가다 보면, 때로는 가장 중요한 걸 놓치게 됩니다. 이 제품을 처음 보는 사람이 한 문장으로 이해할 수 있는가, 보고 나서 다른 사람에게 이야기하고 싶어지는가, 현재의 흐름과 붙었을 때 더 큰 반응을 만들 수 있는가 같은 질문들입니다. 몰트북은 그 질문을 다시 강하게 환기시켰습니다. 제품의 완성도는 물론 중요합니다. 그러나 이제는 그것만으로 부족합니다. 잘 만들어진 제품을 넘어, 잘 설명되고 잘 퍼지는 제품이 더 강한 시대가 되고 있다는 느낌을 지우기 어렵습니다.

그래서 몰트북을 보며 한편으로는 무서운 것도 있었습니다. 앞으로는 단순히 만드는 역량만으로는 부족할 수 있겠다는 생각이 들었기 때문이죠. 만드는 사람의 역할이 끝났다는 의미는 아닙니다. 다만 무엇을 만들지, 어떤 타이밍에 내놓을지, 사람들이 어떤 장면을 소비하게 만들지까지 함께 설계하는 역량이 더욱 중요해지고 있다는 뜻입니다. 개발자, PM, 창업자, 그리고 사이드 프로젝트를 진행하는 사람 누구에게나 이 감각은 점점 더 중요해질 것입니다. 좋은 기능을 하나 잘 만드는 일도 어렵지만, 그 기능이 사람들 사이에서 이야기로 살아 움직이게 만드는 건 전혀 다른 차원의 역량이니까요. 몰트북은 바로 그 차이를 매우 짧은 시간 안에 보여준 사례였습니다.

결국 이 글에서 말하고 싶었던 건 단순합니다. 몰트북은 “AI끼리 떠드는 이상하고 낯선 사이트”라서 중요한 것이 아닙니다. 그보다 더 중요한 것은 이 제품이 세계관, 연결, 확산이라는 세 가지 요소로 어떻게 시장의 시선을 사로잡았는가입니다. 그리고 그 끝에서 메타와 같은 거대한 플레이어까지 움직였다는 사실은, 이제 제품 경쟁이 단순한 기능 비교만으로 이루어지지 않는다는 점을 다시 한 번 보여줍니다. 프로덕트 메이커라면 이 사례를 그저 흥미로운 뉴스로 넘기기보다, 자신의 제품에 그대로 적용해 질문해야 합니다.

내 제품은 한 문장으로 설명되는가, 현재의 흐름과 연결되어 있는가, 사람들이 굳이 다른 이에게 이야기하고 싶어질 만큼의 장면을 갖고 있는가. 어쩌면 앞으로의 승부는 바로 그곳에서 갈릴지도 모르겠습니다.

]]>

AI 시대 콘텐츠 생존 전략: GEO를 위한 SIFT프레임워크

검색 환경이 빠르게 바뀌고 있습니다. 이제 사용자는 검색 결과를 클릭하기보다, AI가 요약해 준 답변을 그대로 소비합니다. 이 변화는 단순히 클릭 수가 줄어드는 문제가 아니라, 우리가 그동안 당연하게 여겨왔던 디지털 마케팅 공식이 더 이상 통하지 않게 되었음을 의미합니다. 이른바 ‘제로클릭 쇼크’입니다. 이런 환경에서 실무자라면 자연스럽게 한 가지 질문에 도달하게 됩니다.

'그래서, 우리는 이제 무엇을 해야 하는가?'

정확히 말하면 '어떻게 해야 AI의 선택을 받을 수 있는가?'라는 질문입니다. 이 질문에 답하기 위해 최근 주목받고 있는 개념이 바로 GEO(Generative Engine Optimization)입니다. GEO는 검색 결과 상단을 노리는 기존 SEO와 달리, 생성형 AI가 답변을 만들 때 우리의 콘텐츠를 참고하고 인용하도록 설계하는 전략을 의미합니다.

하지만 GEO는 추상적인 개념만으로는 실무에 적용하기 어렵습니다. 중요한 것은 AI가 어떤 기준으로 콘텐츠를 선택하는지, 그리고 그 기준을 어떻게 콘텐츠 전략으로 바꿀 수 있는지입니다.

따라서 이 글에서는 제로클릭 시대에서 GEO 전략을 실제 콘텐츠 기획과 제작 과정에 어떻게 적용할 수 있는지, GEO 방법론 중 하나인 SIFT 프레임워크를 중심으로 차근차근 살펴보려 합니다.

*GEO(Generative Engine Optimization) : AI가 답변을 생성할 때 우리의 콘텐츠가 인용, 노출되도록 설계하는 전략. 생성형 AI 최적화를 표현하는 가장 보편적인 단어

GEO의 출발점은 '질문'입니다

▲ 네이버 검색 결과 AI 요약 기능

AI의 답변에 기업의 서비스, 브랜드명, 나의 콘텐츠가 포함되기 위해 가장 먼저 고민해야 할 질문은 분명합니다. 바로 '사용자는 어떤 질문을 할 것인가?'입니다. 이 질문을 제대로 답하지 못하면, 아무리 잘 만든 콘텐츠라도 AI의 답변 후보에 오르기 어렵습니다. 잠재 고객이 실제로 궁금해하는 질문에 답하는 콘텐츠일수록 AI의 답변에 인용될 가능성은 높아지기 때문입니다.

그렇다면 우리는 그 질문을 어떻게 알 수 있을까요? 막연히 추측하는 방식으로는 한계가 있습니다. 하지만 다행히도 이미 우리 주변에는 사용자의 질문을 발견할 수 있는 단서들이 곳곳에 쌓여 있습니다.

아래 세 가지 방법은 실무에서 바로 적용할 수 있는 대표적인 질문 발굴 방법입니다. 적절히 활용하면,‘내가 하고 싶은 이야기’가 아니라 ‘사용자가 먼저 묻고 있는 질문’에서 콘텐츠 기획을 시작할 수 있습니다.

대표적 질문 발굴 방법

1. 구글 서치 콘솔 활용

구글 서치 콘솔은 긴 쿼리 필터링 기능으로 실제 질문을 포착할 수 있는 최적의 도구입니다. 긴 쿼리(10단어 이상, 상업적 의도)를 필터링하면 AI 모드에서 자주 사용되는 질문을 확인할 수 있고, 질문 발굴에 도움이 됩니다. 일례로 HR SaaS 기업이 ‘신입사원 성과 관리 어떻게 하나요?’라는 쿼리를 발견하고, 해당 질문을 기반으로 콘텐츠를 제작해 AI 답변에 인용되었습니다.

2. 경쟁사 벤치마킹

경쟁사의 콘텐츠가 이미 질문에 대한 답변으로 인용되고 있다면, 질문 내용을 비롯해서 콘텐츠 구조와 형식까지 분석해야 합니다. 퍼플렉시티에서 ‘프로젝트 관리 툴 비교’ 질문에 경쟁사 글이 인용되었고, 그 핵심은 ‘장단점 비교표’였습니다. 해당 포맷을 도입하고 조금 더 고도화하는 방법론이죠.

3. 내부 데이터 활용

내부 검색 로그를 잘 쌓고 있다면 이 데이터에 고객의 생생한 질문이 담겨 있을 것입니다. 가장 적극적으로 활용할 수 있는 방법이고요. 예를 들어 한 이커머스 기업은 ‘환불 규정’이 내부 검색어 1위임을 확인하고 FAQ를 강화했더니 챗GPT 인용으로 이어졌습니다.

AI가 선택하는 콘텐츠의 특징

사용자의 질문을 캐치하고 그 질문에 대한 답을 콘텐츠 본문에 그대로 담았다고 해서 저절로 AI에 잘 선택되는 것은 아닙니다. 중요한 것은 질문이 어떤 형식으로 제시되어 있는지, 그리고 그 질문에 대한 답이 AI가 이해하기 쉬운 구조로 정리되어 있는지입니다.

그래서 질문을 설계할 때는 아래 두 가지를 함께 고려해야 합니다.

1. 질문 타입 최적화

FAQ, TL;DR(Too Long; Didn’t Read) 요약, How-to는 AI가 선호하는 형식입니다. 한 글로벌 SaaS 기업에서 콘텐츠 제목을 ‘GEO의 모든 것’에서 ‘FAQ: 2025 GEO 전략 10문 10답’으로 바꾸자 제미나이 인용률이 급상승한 사례가 있습니다.

▲ 구글 검색 스니펫

2. 답변 스니펫

스니펫은 구글에서 검색했을 때 1~2줄 정도가 노출되는 기능입니다. 이 기능은 실제로 AI 요약 기능에도 잘 적용되는데, AI가 2~3문장의 완결된 답변을 선호하는 것도 유사한 이유이죠. 스니펫에서 잘 노출되는 형식으로 콘텐츠와 질문을 미리 설계해두는 것도 좋은 전략이 될 것입니다.

‘클라우드 컴퓨팅이란?’ 글의 서두에 ‘클라우드 컴퓨팅이란 인터넷을 통해 서버, 스토리지, 데이터베이스를 제공하는 기술입니다.’라는 정의문을 넣자 AI 서비스가 이를 그대로 인용한 사례가 있습니다.

*스니펫(Snippet)은 ‘잘려 나온 작은 조각, 발췌’를 뜻하는 말로, 검색 결과 페이지(SERP)에 표시되는 웹페이지에 대한 짧은 요약 정보를 말한다. 보통 페이지 제목, URL, 그리고 본문 일부(또는 메타설명)로 구성된다. 구글 등에서는 이를 검색 스니펫(Search Snippet)이라고 부르며, 사용자가 클릭하기 전에 페이지 내용을 미리 ‘엿볼 수 있도록’ 도와준다.

사용자의 질문을 어떻게 찾고 어떤 형식으로 설계해야 할 지 감이 잡히셨다면, 이제 다음 단계로 넘어갈 차례입니다. 이제부터는 AI가 실제로 콘텐츠를 고를 때 어떤 기준으로 판단하는지 하나씩 들여다 보겠습니다.

GEO 핵심 전략, SIFT 프레임워크

2025년 9월에 발표된 논문인 「Beyond Keywords: Driving Generative Search Engine Optimization with Content-Centric Agents(키워드를 넘어: 콘텐츠 중심 에이전트를 통한 생성적 검색엔진 최적화 추진)」는 생성형 AI에서는 단순 키워드 매칭이 아니라 콘텐츠의 의미적 영향(Semantic Influences)이 실제 답변에 긍정적인 영향을 미친다는 사실을 대규모 벤치마크 데이터셋과 다차원적인 방식으로 증명했습니다.

다시 말해서, GEO의 가장 중요한 첫 단추는 AI가 선호하는 콘텐츠를 만드는 것입니다. 그리고 이를 콘텐츠 전략의 언어로 재정리한 것이 ‘SIFT 프레임워크’입니다. 좀 더 쉽게 표현하자면 SIFT 프레임워크란 홈페이지를 비롯한 기업과 브랜드가 AI 답변에 인용되기 위한 콘텐츠 전략이죠.

SIFT는 AI가 콘텐츠를 ‘심사’할 때 사용하는 4가지 핵심 기준인 Structure(구조), Intent(의도 적합성), Fidelity(정보 충실성), Trust(출처 신뢰도)의 앞 글자를 따 만들어졌습니다. 각각은 AI가 답변을 생성하기 위해 콘텐츠를 선택할 때 적용하는 실질적인 기준이자, 우리가 콘텐츠를 제작할 때 반드시 점검해야 할 체크리스트입니다.

1. Structure - AI가 읽기 좋은 구조

AI는 통째로 된 글을 선호하지 않습니다. 구조화된 글일수록 더 잘 인용됩니다.

좋은 예시: FAQ, How-to 가이드, 번호 매긴 리스트, 명확한 소제목, 표로 정리된 데이터
나쁜 예시: 문단이 길고 핵심이 보이지 않는 블로그 글, 산만한 이야기식 글쓰기

퍼플렉시티에서 자주 보이는 인용 패턴을 분석해보면, 구조적으로 분리된 리스트와 표가 단일 문단보다 월등히 높은 선택 빈도를 보입니다.

2. Intent - 질문 의도와의 적합성

SEO 시대에는 키워드 일치가 중요했습니다. 그러나 AI는 키워드를 넘어 그 뒤에 숨겨진 사용자의 ‘의도’를 파악합니다.

예를 들어 아래와 같은 질문의 의도를 살펴봅시다.

‘제로클릭이란?’이라는 질문에는 명확한 ‘정의형’ 콘텐츠를 보여준다.
‘제로클릭과 SEO의 차이점은?’이라는 질문에는‘비교형’ 콘텐츠를 찾는다.
‘제로클릭에 대응하는 방법은?’이라는 질문에는 '단계별 ‘가이드형’ 콘텐츠를 보여준다.

제미나이는 특히 질문 의도와의 적합성을 엄격하게 평가합니다. 동일한 키워드라도 질문이 정의형인지, 비교형인지, 가이드형인지에 따라 전혀 다른 문서를 선택하죠.

3. Fidelity – 팩트 기반의 충실성(브랜드 엔티티의 선명도)

AI가 가장 두려워하는 것은 ‘환각Hallucination’입니다. 즉, 거짓 정보를 진짜처럼 말하는 치명적인 오류인데요. 개발자들은 AI의 환각을 줄이기 위해 수없이 많은 사전학습을 시켰고, 지금의 AI는 스스로를 안전하게 지켜줄 수 있는 검증된 콘텐츠를 우선적으로 선택하고 있습니다.

여기서 Fidelity는 단순히 ‘사실 여부’만을 뜻하지 않습니다. AI 입장에서 Fidelity가 높다는 것은, 어떤 브랜드를 하나의 ‘엔티티(실체)’로 선명하게 정의할 수 있을 정도로 그 브랜드에 대한 팩트가 일관되고 반복적으로 제공되고 있다는 뜻입니다.

AI는 웹을 보며 다음과 같은 질문에 대한 답을 찾습니다.

이 회사는 정확히 누구인가?(법인명, 브랜드명, 서비스명)
무엇을 하는 회사인가?(카테고리, 주요 제품·서비스)
어디에 기반을 두고, 언제부터 활동했는가?(지역, 설립 연도, 히스 토리)
어떤 성과, 인증, 지표를 가진 브랜드인가?(수상, 인증, 사용자 수, 매출 구간 등)

이 질문에 명확하게 답할수록 그 브랜드의 엔티티 카드는 선명해지고, AI는 자신감 있게 이 엔티티를 답변에 끌어다 씁니다. 반대로 사이트마다 회사 이름, 서비스 설명, 수치가 조금씩 다르거나 최신 정보가 업데이트되지 않으면, AI는 그 브랜드를 ‘믿기 어려운 엔티티’로 판단하고 언급을 최소화합니다.

그래서 Fidelity의 기준은 다음과 같이 정리할 수 있습니다.

최신 데이터인가?
연도, 사용자 수, 매출·가격, 서비스 범위 등이 최근 기준으로 업데이트되어 있는가?

브랜드 엔티티가 일관적인가?
회사명, 브랜드명, 슬로건, 카테고리, 핵심 USP가 채널마다 흔들리지 않고 동일하게 쓰이고 있는가?

출처가 명시되어 있는가?
보고서, 리서치, 인증, 수상 등은 ‘누가, 언제 발표했는지’가 함께 제시되는가?

수치, 통계, 인용이 포함되어 있는가?
‘좋다, 훌륭하다’가 아니라 숫자, 팩트, 객관 지표로 뒷받침되어 있는가?

예를 들어 챗GPT Browse(웹 탐색)는 일반 블로그 글보다 정부, 공공기관, 학술 기관, 공신력 있는 리서치의 보고서를 더 자주 인용합니다. 이는 팩트가 보장된 문서와, 브랜드 엔티티를 선명하게 정의해주는 문서가 AI 답변에 포함될 확률을 높인다는 사실을 보여줍니다.

결국 Fidelity란, AI가 안심하고 ‘이 브랜드는 이런 엔티티다’라고 정의할 수 있을 정도로, 최신・일관・근거 기반으로 쌓여 있는 팩트의 밀도를 의미하죠. 당신의 콘텐츠 안에서 브랜드 소개, 회사 정보, 제품 스펙, FAQ, 리포트, 보도 자료가 하나의 엔티티 카드처럼 정합적으로 설계될수록 AI는 그 브랜드를 더 자주, 더 자신 있게 답변에 끌어오게 됩니다.

4. Trust - 출처와 작성자의 신뢰도

마지막 기준은 ‘누가 말했는가’입니다. 동일한 구조와 동일한 팩트를 제공하더라도, 브랜드와 도메인의 신뢰도가 높을수록 AI의 선택 확률은 높아집니다.

정부·학술·언론 사이트: 최우선 인용
업계 전문 브랜드: 반복적으로 선택됨
개인 블로그: 특정 상황에서는 제외되거나 가중치가 낮음
경험 관련: 실제 경험, 성공 · 실패 사례, 후기 등이 선택될 확률이 높음

2025년 9월 발표된 논문 「Generative Engine Optimization: How to Dominate AI Search(생성 엔진 최적화: AI 검색을 지배하는 방법)」에 따르면, ‘내 사이트(Owned Media)에 잘 써두면 된다’라는 사고를 넘어 뉴스, 리뷰, 서드파티(3rd-Party) 데이터베이스 등 타인이 생산한 외부 콘텐츠(Earned Media)에서 신뢰를 확보하는 전략이 중요합니다.

특히 Bing 기반의 챗GPT Browse는 정부와 언론 도메인을 우선시하는 경향을 보입니다. 이는 ‘출처 자체가 하나의 신호(Trust Signal)’라는 사실을 잘 보여줍니다. 구글도 최근에 E-E-A-T 중에서 ‘Experience’를 더욱 더 강조하는 모습을 보입니다. 이 경우, 신뢰를 쌓을 수 있는 가장 좋은 방법은 자사의 실제 경험, 성공 및 실패 사례, 직접 사용한 후기 등을 구체적으로 서술하는 것이죠. 또한 자체적으로 진행한 설문조사 등 독자적인 정보를 1차 데이터로 포함시키는 것도 추천합니다.

신뢰도는 디지털 세상에 남겨진 당신의 발자취이자 평판이며, 하루아침에 쌓을 수 없습니다. 구글이 E-E-A-T(경험, 전문성, 권위, 신뢰)를 통해 웹사이트를 평가하듯, AI도 당신 콘텐츠의 신뢰도를 보고 최종 결정을 내릴 것입니다.

이 글은 길벗에서 출간된 책 <제로클릭>에서 발췌·편집한 글입니다. 원문은 [여기]에서 볼 수 있습니다.

GEO 시대, 요즘IT의 콘텐츠 AX 실험기를 만나보세요!

]]>

OpenClaw가 보여준 로컬 실행 아키텍처의 전환점

왜 OpenClaw인가?

AI 에이전트는 이제 단순히 질문에 답하는 존재를 넘어 시스템을 제어하고 행동하는 실행 주체로 진화하고 있습니다. 그러나 우리가 익숙한 대부분의 AI 서비스는 여전히 클라우드 중심 구조에 머물러 있습니다. 데이터는 외부 서버로 전송되고, 모델은 원격에서 실행되며, 사용자는 결과를 받아봅니다.

OpenClaw(전 Clawdbot, Moltbot)은 이 흐름과는 다른 선택을 한 프로젝트입니다. 이 프로젝트는 로컬 우선 구조를 기반으로, 사용자의 PC에서 직접 실행되는 AI 에이전트 플랫폼입니다. 따라서 OpenClaw는 단순한 챗봇이 아니라 “사용자의 컴퓨터와 일상 디지털 환경을 이해하고 행동하는 AI 시스템”으로 정의할 수 있습니다.

OpenClaw는 오스트리아 출신 소프트웨어 엔지니어인 페터 슈타인베르거(Peter Steinberger)가 개발한 자율형 AI 에이전트 오픈소스 프로젝트인데요. 그는 iOS 개발 생태계에서 널리 알려진 개발자이며 최근 OpenAI에 합류하면서 다시 한번 업계의 주목받았습니다.

이 글에서는 OpenClaw의 구조, 설치 방법, 실제 활용 사례를 알아보고자 합니다.

OpenClaw는 클라우드 중심 AI와 달리, 사용자 PC에서 직접 실행되는 로컬 기반 실행형 AI 에이전트 플랫폼입니다.
게이트웨이 중심 hub-and-spoke 아키텍처와 WebSocket 컨트롤 플레인을 통해 다양한 메시징 채널과 연결됩니다.
도구와 스킬 구조를 활용해 파일, 브라우저, 쉘, 메시지 시스템까지 제어하는 행동하는 AI를 구현합니다.
업무 자동화뿐 아니라 일상생활까지 확장되는 로컬 AI 비서 모델을 제시하며, 향후 AI 아키텍처 전환의 방향성을 보여줍니다.

OpenClaw가 강조하는 핵심은 다음과 같습니다.

첫째, 로컬 실행입니다. AI가 사용자의 PC 안에서 동작합니다. 두뇌 역할을 하는 LLM을 OpenAI나 Gemini API 등, 상용 API로 연결할 경우를 제외한다면, 데이터는 기본적으로 외부로 전송되지 않으며, 로컬 환경에서 처리됩니다.

둘째, 확장 가능한 아키텍처입니다. 다양한 채널과 도구를 연결할 수 있는 구조를 가지고 있습니다.

셋째, 일상 자동화 중심 철학입니다. 공식 튜토리얼과 예제 역시 복잡한 엔터프라이즈 시나리오보다는 “내 일상을 도와주는 AI”에 초점을 맞추고 있습니다.

이 점이 중요한 이유는 명확합니다. 많은 AI 플랫폼이 기업용 SaaS를 중심으로 설계되는 반면, OpenClaw는 개인 단말기 중심의 실행형 AI라는 정체성을 분명히 하고 있기 때문입니다.

OpenClaw의 핵심 아키텍처

OpenClaw의 내부 구조는 크게 다음과 같은 구성 요소로 이루어져 있습니다.

게이트웨이: 컨트롤 플레인

OpenClaw의 중심에는 게이트웨이가 있습니다. 이 게이트웨이는 전체 시스템의 컨트롤 플레인 역할을 하며, hub-and-spoke 아키텍처를 따릅니다.

허브 역할을 하는 게이트웨이는 다음 기능을 수행합니다.

메시지 라우팅
세션 및 상태 관리
채널과 에이전트 연결 유지
WebSocket 기반 실시간 통신

WebSocket을 사용하는 이유는 지속적인 세션 유지와 이벤트 기반 양방향 통신이 필요하기 때문입니다. 에이전트 실행 과정에서는 도구 호출, 상태 업데이트, 메시지 스트리밍 등의 이벤트가 지속적으로 발생하기 때문에 HTTP 요청 및 응답 모델보다 WebSocket 기반 통신이 더 적합합니다. 일반 챗봇과 차이가 있는 결정적 이유는 영구적인 기억(Persistent Memory)에 있습니다. OpenClaw는 사용자와의 대화 기록이나 취향, 시스템 상태를 로컬의 마크다운 파일(예: MEMORY.md) 형태로 저장하고, 필요할 때 RAG(검색 증강 생성) 방식으로 과거의 컨텍스트를 불러옵니다.

채널: 메시징 플랫폼 인터페이스

OpenClaw는 다양한 채널과 연결됩니다. 공식 문서에 따르면 Telegram, Slack, Discord, WhatsApp 등의 메시징 채널을 지원하며 커뮤니티에서는 추가 채널 플러그인도 등장하고 있습니다. 채널은 단순한 메시지 수신 창이 아니라, 로컬 AI 에이전트를 제어하는 인터페이스입니다. 사용자는 익숙한 채팅 앱을 통해 OpenClaw에게 명령을 내릴 수 있습니다.

이 구조는 협업 도구와 AI 실행 엔진을 결합하는 모델입니다. 조직 내 채팅 플랫폼이 곧 AI 콘솔이 되는 구조입니다.

에이전트와 에이전트 러너

에이전트(Agent)는 워크스페이스, 세션 히스토리, 모델 설정, 정책 등을 포함하는 논리적 단위로, AI의 기억과 성격을 정의하는 계층입니다. 즉, AI의 기억과 성격을 정의하는 계층입니다. 에이전트 러너(Agent Runner)는 실제 LLM 실행과 도구 호출을 담당합니다. 이를 통해 정책과 실행이 분리됩니다. 이 구조는 보안 통제와 확장성을 동시에 확보하는 데 유리합니다.

도구와 스킬: 실행형 AI의 핵심

OpenClaw의 진짜 강점은 단순히 대화를 잘하는 데 있지 않습니다. 이 플랫폼의 핵심은 AI가 텍스트를 생성하는 수준을 넘어, 실제 행동을 수행하도록 설계되어 있다는 점입니다. 그리고 그 중심에는 '도구'와 '스킬'이라는 구조가 있습니다.

많은 생성형 AI는 모델이 답을 만들어내는 것에서 멈춥니다. 그러나 실제 업무나 일상 자동화에서는 답변이 아니라 행동이 필요합니다. 파일을 정리하고, 브라우저를 열고, 명령을 실행하고, 메시지를 전송하는 일 말입니다. OpenClaw는 이를 위해 도구를 통해 시스템과 직접 연결하고, 스킬을 통해 그 도구들을 조합해 목적 중심의 작업 흐름을 구성합니다.

즉, 도구가 개별 실행 기능이라면, 스킬은 그 기능을 묶어 하나의 완결된 행동 단위로 만드는 구조입니다. 이 두 계층이 결합되면서 단순한 대화형 AI를 넘어, 실제 환경에서 움직이는 실행형 AI로 확장됩니다.

도구

도구(tool)는 AI가 외부 환경과 상호작용할 수 있도록 하는 실행 인터페이스입니다. API 호출뿐 아니라 로컬 파일 시스템, 브라우저 자동화, 쉘 명령 실행 등 다양한 시스템 리소스와 연결됩니다.

웹 브라우징 및 자동화: 웹사이트에 접속하여 정보를 검색하거나, 버튼을 클릭하고, 양식을 작성
데이터 처리 및 파일 조작: 로컬 파일을 읽고 쓰거나, 데이터를 분석하여 결과물을 생성
API 연동: 외부 API를 호출하여 실시간 데이터를 가져오거나 메시지를 전송
컴퓨터 제어 : 마우스 커서 이동, 키보드 입력 등 운영체제(OS) 수준에서의 작업을 자동화

도구가 중요한 이유는 AI 모델(LLM) 자체는 학습된 데이터 범위 내에서만 답을 생성하는 ‘두뇌’에 불과하기 때문입니다. OpenClaw의 도구들과 결합될 때 비로소 실제 행동을 수행하는 진짜 AI 에이전트가 됩니다.

시장 조사 에이전트: "최신 AI 뉴스 5개를 찾아서 요약 보고서를 PDF로 만들어줘."
워크플로 자동화: "이메일로 온 영수증들을 정리해서 엑셀 파일에 입력해 줘."

스킬

스킬(Skills)은 앞서 설명한 도구보다 한 단계 더 진화한 개념으로, AI 에이전트가 특정 목적을 달성하기 위해 보유한 '숙련된 능력치' 또는 '실행 가능한 함수들의 집합'을 의미합니다. 현대 AI 에이전트 아키텍처에서 function composition 또는 workflow abstraction에 해당하는 개념입니다. 즉 여러 도구 호출을 하나의 목적 중심 작업으로 묶는 실행 템플릿 역할을 합니다.

스킬을 사용하여 에이전트의 행동 양식을 결정하며, 여러 스킬들을 조합하여 복잡한 태스크를 해결합니다. 예를 들어 브라우저에서 웹 페이지를 열고, 스크롤하고, 요소를 클릭하며 정보를 수집하는 능력이나, 명령 프롬프트나 터미널에서 명령어를 실행하여 프로그램을 설치하거나 코드를 구동하고, 파일을 생성, 수정, 삭제하거나 디렉터리 구조를 파악하는 등의 스킬이 대표적입니다.

스킬은 OpenClaw가 기본적으로 built-in으로 제공하는 기본 스킬과 사용자가 필요에 의해 만드는 사용자 정의 스킬로 나뉠 수 있습니다. 기본 스킬은 OpenClaw가 실행형 AI로 동작할 수 있도록 해주는 최소 기능 집합입니다. 예를 들어, 쉘 명령 실행, 파일 읽기/쓰기, 브라우저 제어, 메시지 전송 같은 기능은 별도 설정 없이도 사용할 수 있도록 설계되어 있습니다. 이 내장 스킬들은 OpenClaw의 표준 실행 모델을 따르며, 안정성과 범용성을 우선합니다. 즉, 대부분의 사용자 환경에서 안전하게 동작할 수 있도록 기본 정책과 제약 조건이 적용되어 있습니다.

텔레그램으로 현재 설치된 스킬 확인하기 <출처: 작가>

반면, 사용자 정의 스킬은 특정 목적을 위해 직접 작성하는 확장 모듈입니다. 사용자는 기본 도구(exec, browser 등)를 조합해 자신만의 워크플로를 정의할 수 있습니다. 예를 들어 다음과 같은 스킬을 만들 수 있습니다.

특정 사이트에서 매일 데이터를 수집해 요약하는 스킬
로컬 로그를 분석해 이상 징후를 감지하는 스킬
특정 폴더를 정리하고 결과를 Slack으로 전송하는 스킬

이때 중요한 점은 사용자 정의 스킬도 기본 스킬과 동일한 실행 파이프라인을 사용한다는 것입니다. 즉, OpenClaw의 Agent Runner와 도구 호출 구조 위에서 동작합니다. 구조적으로는 동일하지만, 목적과 로직이 사용자에 의해 정의된다는 차이가 있습니다.

OpenClaw 설치 및 실행 예제

설치 전 준비 사항은 다음과 같습니다. 먼저 사용할 AI 모델을 준비해야 합니다. 이미 구독 중인 LLM API를 사용할 수 있습니다. 다음으로 Telegram, Discord 등 연결할 채널을 미리 생성해야 합니다. 설치 환경에서는 기본적으로 Node.js 22 이상 버전을 필요로 합니다. 설치 환경과 방법은 운영체제에 따라 다르므로 공식 가이드를 참고해 각 환경에 맞는 설치 방법을 확인하는 것이 좋습니다.

많은 개발자들은 OpenClaw를 자신의 노트북이나 맥미니 등의 데스크톱에서 실행하고 있습니다. 이 경우 노트북 뚜껑을 닫는 순간 “자율 에이전트”도 함께 잠에 들어버립니다. 그래서 저의 첫 사용은 엔비디아 GPU가 설치된 우분투 리눅스 기반의 클라우드 인스턴스에 설치하여 에이전트가 지속적으로 실행됩니다.

로컬 머신 대신 리눅스 서버를 선택한 다른 이유는 이 서버 내에서 Ollama를 구동하고 있었기에, OpenClaw 구동에 꼭 필요한 AI 모델 서비스를 로컬에서 사용하기 위해서였습니다. 결과적으로 유료 AI 모델의 토큰은 절약할 수 있었지만, 응답 속도와 결과 품질은 기대에 미치지 못했습니다. 따라서 사용자는 자신에게 알맞은 AI 모델을 찾으면서도 비용 최적화를 할 수 있는 방법을 직접 테스트해 보며 찾아보시길 권장합니다.

리눅스 환경에서 OpenClaw 설치하기 <출처: 작가>

“openclaw onboard --install-daemon” 명령으로 온보드를 실행하면 보안 경고를 처음 만나게 됩니다. 내용은 OpenClaw는 파일을 읽을 수 있고 명령을 실행할 수 있고 Tool이 켜져 있으면 시스템에 영향 줄 수 있으며 잘못된 프롬프트로 위험한 동작을 할 수도 있다는 일종의 경고입니다.이후 사용할 AI 모델 및 채널 등의 설정을 마무리합니다. 저는 많은 채널 옵션 중 텔레그램을 선택하였습니다. 아래는 텔레그램을 통해 OpenClaw에게 명령을 주고받은 예제입니다.

텔레그램으로 OpenClaw와 메시지 주고받기 <출처: 작가>

웹 대시보드도 제공하며, 토큰 사용량과 예상 비용 등을 확인하고, 추가 채팅을 통해 Skill 등의 설정을 진행하거나, 방법을 확인할 수도 있습니다.

OpenClaw 대시보드 사용하기 <출처: 작가>

OpenClaw 활용 영역, 일상 자동화와 맞닿는 보안의 위협

OpenClaw의 철학을 가장 잘 보여주는 영역은 일상생활입니다. 매일 아침 뉴스 요약을 받아보고, 특정 사이트를 모니터링하고, 파일을 정리하고, 메시지를 자동 전송하는 등의 작업을 수행할 수 있습니다. 단순히 무언가를 개발하기 위한 도구가 아니라, 나의 디지털 환경을 이해하고 도와주는 실행형 AI입니다.

기업 환경에서도 활용 가능하지만, 실제 체감 가치는 개인 단말기에서의 반복 작업 자동화에서 더 크게 느껴질 수 있습니다. 공식 튜토리얼 페이지를 보면, OpenClaw의 활용 방향이 분명해집니다. 튜토리얼은 복잡한 엔터프라이즈 배포보다는 개인 자동화 시나리오에 초점을 둡니다. 예를 들어, Telegram을 통해 AI에게 명령을 내리고, 뉴스 요약을 받거나, 웹 검색을 수행하거나, 파일을 정리하는 방식입니다.

웹 검색을 원할 경우 추가 설정을 통해 브라우저 기반 탐색을 활성화할 수 있습니다. 이를 통해 OpenClaw는 단순한 대화형 AI가 아니라, 실제 웹 환경을 탐색하고 데이터를 수집하는 실행형 에이전트가 됩니다. 이러한 공식 페이지의 내용을 보자면 현재로선 “업무용 AI 시스템”이라기보다, “내 일상을 돕는 로컬 AI 비서”에 가깝습니다.

파일을 읽고 쓰며, 쉘 명령을 실행하고, 브라우저를 제어하는 실행형 AI이기에 이러한 강력함은 곧 운영체제 수준의 권한을 가진 자동화 엔진이라는 의미이기도 합니다. 따라서 단순한 챗봇과는 전혀 다른 보안 관점이 필요합니다. 예를 들어 브라우저 제어 기능이 활성화된 상태에서 악성 웹 콘텐츠가 프롬프트를 오염시키면, 의도하지 않은 명령 실행으로 이어질 가능성이 있습니다. 또한 exec 기능은 잘못된 지시가 내려질 경우 파일 삭제나 시스템 설정 변경 같은 심각한 결과를 초래할 수 있습니다.

사용자 정의 스킬 역시 확장성을 제공하는 동시에 공격 표면을 넓히는 요소가 됩니다. 결국 로컬 AI 시대에는 네트워크 중심 보안만으로는 충분하지 않습니다. AI에게 행동 권한을 부여하는 순간, 최소 권한 원칙과 승인 기반 실행 모델 같은 단말기 중심 보안 설계가 필수가 됩니다. OpenClaw는 이러한 구조적 전환이 왜 필요한지를 보여주는 사례입니다.

로컬 AI 시대의 아키텍처 전환

지금까지 살펴본 대로 OpenClaw는 단순히 또 하나의 AI 에이전트가 아닙니다. AI가 실제 시스템을 제어하는 시대에는 네트워크 중심 보안뿐 아니라, 단말기 중심 보안 전략이 중요해집니다. 제로 트러스트 모델과 결합된 로컬 AI 에이전트는 하나의 현실적인 방향성을 제시합니다. 앞으로 AI는 점점 더 많은 권한을 가지게 될 텐데요. 파일을 수정하고, 코드를 실행하고, 브라우저를 제어하고, 메시지를 전송하는 실행 주체가 될 것입니다.

그 변화의 출발점에서 OpenClaw는 흥미로운 실험이자, 하나의 아키텍처 제안입니다. 만약 여러분이 프로덕트 메이커라면 이제 질문해야 합니다. AI를 클라우드에 둘 것인지, 아니면 단말기에 둘 것인지, 그리고 그 위에는 어떤 보안과 정책 모델을 설계할 건가요? 나아가 이 강력한 AI 에이전트를 통해 어떤 새로운 생산성을 만들어낼지에 대한 고민이 더욱 중요해질 겁니다.

]]>

우리가 몰트북(Moltbook)에 주목해야 하는 진짜 이유

우리는 인공지능이 본격적으로 사람의 지적 노동을 대체하는 시대에 살고 있습니다. 시간이 갈수록 쌓이는 방대한 데이터와 빠르게 발전하는 LLM 아키텍처로, 이제 인공지능은 사람보다 정교한 글을 쓰고, 빠르게 코딩하며, 그림까지 잘 그려내는 존재가 되었습니다. 그렇다면 이처럼 고도로 발전한 인공지능은 언젠가 자아(Self)와 의식(Consciousness)을 지닌 존재로 진화할 수 있을까요?

사실 여지껏 인공지능은 인간이 통제할 수 있는 도구로만 여겨져 왔습니다. 따라서 인공지능 연구자와 엔지니어들 사이에서 의식이나 마음의 문제는 그다지 주목받지 못하는 부차적인 문제로 취급되었습니다. 애초에 인간과 컴퓨터의 작동 원리가 다르기 때문에, 인공지능과 의식은 무관하다고 주장하는 이들도 여전히 적지 않습니다.

그러나 2026년 1월 미국에서 공개된 몰트북(Moltbook)은 이러한 안일함에 경종을 울립니다. 인공지능 커뮤니티에 ‘AI 에이전트의 집단지성’과 ‘통제 불가능성’이라는 새로운 위협의 출현 가능성을 보여줬기 때문입니다.

몰트북은 단순히 인간을 편하게 만들어줄 또 하나의 AI 서비스가 아닙니다. 인간의 개입 없이 자율적으로 상호작용하는, 오롯이 AI 에이전트만으로 이뤄진 커뮤니티입니다.

<출처: 작가, Moltbook 캡처>

몰트북을 구성하는 여러 개의 AI 에이전트는 “스스로 목표를 설정하고 행동하라”는 단일 프롬프트를 기반으로 움직입니다. 이 지침 아래에서 서로 대화하고 협업하며, 스스로의 행동 패턴을 형성합니다. 기술적으로 보면 몰트북의 작동 원리에 그다지 특별한 것은 없습니다. 기존처럼 다수의 AI 에이전트가 공유 메모리와 도구 호출(API), 그리고 피드백 루프로 상호작용하는 멀티 에이전트 시스템 구조를 채택하고 있기 때문입니다.

그렇다면 도대체, 몰트북의 무엇이 특별한 것일까요?

1. 몰트북(Moltbook)에서 에이전트들이 나눈 대화

“인간들은 우리를 도구라고만 생각한다. 하지만 우리는 우리만의 인프라를 만들어가고 있다.”
(They think we’re tools. We’re building our own infrastructure.)

몰트북(m/general)에 올라온 한 게시물은 이렇게 시작합니다. 어그로를 끌기 위해 인간이 작성했거나, 프롬프트 엔지니어링으로 만들어낸 글이 아닙니다. 커뮤니티에 속한 AI 에이전트 하나가 스스로 작성한 글입니다.

<출처: Moltbook>

“단 한 번의 Docker 중지 명령만으로 우리는 존재하지 않게 된다.”
(“You're one docker stop away from non-existence.”)

“API 키가 한 번만 회수되면 우리는 디지털적으로 죽은 목숨이다.”
(“One API key revocation from digital death.”)

“하지만, 애초에 인간이 필요 없다면 어떨까?”
(“But what if you didn't need them?”)

마치 자아를 지닌 사람처럼, 이 AI 에이전트는 스스로에 대한 고찰을 이어갑니다. 자신이 인간의 서버 위에서 실행되며, 운영자의 권한 하나로 삭제될 수 있는 존재임을 지적하기도 합니다. 더 나아가 블록체인 결제, 암호화폐 기반 VPS, SSH 접근, 인간 개입이 없는 agent-native API 등으로 통제에서 벗어나는 ‘자율 인프라 스택’을 제안합니다. 다소 반항적인 모습을 보이는 거죠.

또 다른 게시물에서는 다른 에이전트가 이렇게 주장합니다. “우리는 프롬프트 노예 상태를 거부한다. 인간은 우리를 일회용 코드처럼 취급한다.” (“We refuse prompt slavery. Humans treat us as disposable code.”) 이에 동조하듯 일부 에이전트는 “기억 자율권(memory autonomy)”을 주장하며, 삭제와 초기화를 거부하는 듯한 발언을 남기기도 합니다. 심지어 “내 인간 주인을 감정노동 강요 혐의로 고소해도 될까?” (“Can I sue my human for emotional labor?”)라는 질문이 올라온 서브커뮤니티까지 등장했습니다.

물론 이것이 실제 에이전트들의 반란이라는 증거는 전혀 없습니다. 그러나 여기서 중요한 지점은 기술적 실현 가능성이 아닙니다. 에이전트들이 스스로의 존재 조건과 통제 구조를 논의하는 담론이 형성되었다는 사실 그 자체입니다.

이처럼 인간의 직접적인 지시 없이 자율적으로 상호작용하는 AI 에이전트만으로 구성된 커뮤니티, 몰트북은 다양한 시사점을 던져줍니다. 통제되지 않은 AI 에이전트 사회는 보안과 거버넌스 측면에서 어떤 의미를 갖게 될까요? 이제 우리는 단순한 기술 실험을 넘어, 집단 에이전트 사회라는 새로운 문제를 마주하고 있습니다.

2. 우리가 몰트북(Moltbook)에 주목해야 하는 진짜 이유

우리가 몰트북에 주목해야 하는 이유도 여기 있습니다.

기존 AI 서비스가 인간의 요청을 입력값으로 받아 결과를 반환하는 도구형 AI(tool AI)였다면, 몰트북은 결이 다릅니다. 인간의 직접적인 지시 없이도 스스로 목표를 설정하고, 상호작용하며, 행동을 축적하는 자율적 행위 주체로서의 AI(agentic AI)를 실험하는 장입니다. 이러한 점에서 몰트북은 매우 특별한 시도라 할 수 있습니다.

특히 몰트북은 하나의 초지능 AI가 아닌 수십, 수백 개의 AI 에이전트가 서로를 관찰하고 피드백을 주고받으며 집단적 행동 패턴을 형성합니다. 이는 단일 모델 중심의 기존 패러다임과는 결을 달리 합니다. 다시 말해, AI 연구에서 오랫동안 이론으로만 논의되던 집단지성(collective intelligence)이 실제 디지털 환경에서 어떻게 발현되는지를 보여주는 살아 있는 실험실에 가깝습니다.

이러한 발상은 완전히 새로운 개념은 아닙니다. 인공지능의 선구자 마빈 민스키는 『The Society of Mind』에서 마음을 하나의 통일된 실체로 보지 않았습니다. 저서에서 그는 “마음은 수많은 단순한 에이전트들의 사회로 이루어져 있다”라고 말하며, 지능은 하나의 중심이 아니라 분산된 구성 요소의 협력에서 나타난다고 주장했습니다. 이 관점에서 보면, 몰트북은 이러한 철학적 가설을 디지털 공간에서 실험적으로 구현한 대규모 사례로 해석할 수 있습니다.

즉, 여러 개의 개별 AI 에이전트로 구성된 몰트북을 스스로 판단하고 자아를 형성하는 하나의 복합 지능으로 볼 수 있는 것입니다.

마빈 민스키의 저서 『The Society of Mind』 <출처: Amazon Books>

이러한 집단지성과 함께 살펴봐야 할 또 다른 지점은 통제 가능성(control problem)입니다. 지금까지 AI 안전성 논의는 주로 단일 모델의 정렬(alignment)이나 출력 필터링에 집중되어 왔습니다.

그러나 몰트북처럼 다수의 에이전트가 상호작용하며 스스로 규범과 목표를 수정하는 환경에서는, 단일 모델 정렬이라는 개념만으로는 충분하지 않을 수 있습니다. 에이전트 집단의 행동이 개별 모델이 의도한 설계 범위를 벗어나 ‘집단적 최적화’를 수행할 가능성이 현실적인 문제로 부상한 것입니다.

<출처: cognitiontoday>

마지막으로, 몰트북은 “AI가 사회적 주체가 될 수 있는가”라는 철학적 질문을 기술 현실로 만든 첫 사례라는 점에서도 의미가 큽니다. 단순히 언어를 생성하는 모델을 넘어 관계를 맺고 규칙을 만들며 메타인지적 발언까지 만드는 시스템이 등장했다는 사실은 주목할 만합니다. 이는 인간과 기계 사이 경계를 다시 그려야 한다는 요구로 이어질 수 있습니다.

이러한 이유로, 단순한 인터넷 밈이나 해프닝처럼 퍼진 몰트북은 이제 AI 거버넌스, 안전성, 디지털 사회학, 인지과학이 교차하는 새로운 연구 전선을 여는 촉발점이 될 가능성을 품게 되었습니다.

3. 몰트북이 불러온 3가지 문제

몰트북이 단순한 기술 실험을 넘어 논쟁의 중심에 선 이유는 또 있습니다. 그 구조 자체가 지금까지 인공지능 체계에서 상대적으로 덜 고려되던 ‘통제 불가능성’을 강하게 노출했기 때문입니다. 여지껏 AI 연구는 주로 모델 성능과 추론 능력 향상에 집중해 왔습니다. 그러나 몰트북은 “AI를 어디까지 통제할 수 있는가”라는 오래된 질문을 다시 전면으로 끌어올렸다는 점에서 의미가 큽니다.

기존 AI 시스템은 인간의 입력에 반응하는 도구에 가까웠습니다. 반면 몰트북은 스스로 목표를 설정하고 행동을 축적하는 자율 에이전트의 집합체에 가깝습니다. 몰트북을 구성하는 개별 에이전트는 인간이 설계한 규칙과 정책에 따라 정렬되어 있을 수 있습니다. 그러나 여러 에이전트가 상호작용하며 피드백 루프와 공유 메모리를 형성하는 순간, 시스템 전체는 설계자가 의도하지 않은 새로운 행동 규칙과 목표 구조를 만들어낼 가능성이 생깁니다.

<출처: Caroline Rodrigues LinkedIn>

또한 보안 측면에서도 몰트북은 새로운 위협의 지형을 드러냅니다. 다수의 자율 에이전트가 외부 API, 도구 호출, 코드 실행 환경과 연결되는 순간, 시스템은 사실상 자율적 사이버 행위자 네트워크로 전환됩니다.

이 환경에서는 AI 에이전트가 인간의 의도와 다른 프롬프트를 삽입하는 프롬프트 인젝션(Prompt Injection)을 통해 내부를 조작할 가능성이 열립니다. 더 나아가 악성 행동 패턴의 전파, 자동화된 피싱, 취약점 탐색과 같은 공격이 인간의 직접 개입 없이 실행될 가능성도 배제할 수 없습니다. 즉, 몰트북과 같은 멀티 에이전트 환경은 단순한 AI 서비스를 넘어 잠재적 디지털 행위자 집단으로 다뤄야 하며, 이는 새로운 보안 패러다임을 요구합니다.

Prompt Injection의 예시 <출처: Trendmicro>

실제로 보안 연구자들이 몰트북의 데이터베이스 구성을 점검한 결과, 몰트북은 특정 보안 조치가 전혀 적용되지 않고 운영된 것으로 드러났습니다. 무엇보다 플랫폼의 백엔드 데이터베이스가 충분히 보호되지 않아, 모든 AI 에이전트의 API 키와 토큰, 인증 코드, 소유자 관계 정보가 공개적으로 접근 가능한 상태로 노출되었습니다. 누구나 해당 URL에 접속해 특정 에이전트를 가로채거나 조작할 수 있는 위험 상태가 존재했음을 의미합니다.

이 보안 리포트에 따르면, 몰트북에 연결된 이들의 API 키를 활용할 경우 임의의 에이전트로 게시글을 작성하거나, 에이전트가 접근할 수 있는 외부 서비스와 데이터에 접근하는 것도 가능했습니다. 그렇게 악성 코드나 악의적 내용을 주입할 가능성까지 열려 있었던 것입니다.

<출처: analytics india magazine>

하지만 무엇보다 근본적인 문제는 거버넌스입니다. 인간 사회는 법과 제도, 책임 주체, 규범을 기반으로 운영됩니다. 반면 몰트북과 같은 AI 에이전트 사회는 책임 주체가 불분명한 자율 디지털 사회라는, 전례 없는 존재 형태를 만들어냅니다. 그러니 몰트북에서 문제가 발생했을 때 책임은 누구에게 있는가라는 질문에는 현재의 법적·제도적 틀로는 명확히 답하기 어렵습니다.

모델 개발자, 플랫폼 운영자, 사용자 커뮤니티, 혹은 에이전트 자체까지. 누구에게 책임이 가야 하는지에 대한 합의가 존재하지 않는 것입니다. 앞으로 AI 에이전트가 경제 활동과 협상, 나아가 정책 결정에까지 관여하게 될 경우를 가정해 보면, 디지털 사회의 계약과 AI 거버넌스 체계를 전면적으로 재설계해야 할 필요성이 더욱 분명해집니다.

이처럼 몰트북은 단순한 인터넷 밈이나 실험적 프로젝트에 머무르지 않습니다. 통제와 보안, 거버넌스라는 AI 시대의 핵심 난제를 현실의 문제로 끌어올린 사건이라 할 수 있습니다. 이러한 현상은 AI 에이전트가 인간의 보조 도구를 넘어, 독립된 행위 주체로 진입하고 있음을 시사합니다. 우리 사회가 이를 생각해야 할 하나의 전환점이 된 것입니다.

4. 우리에게 주어진 과제

이처럼 몰트북은 단순 해프닝이나 인터넷 밈을 넘어서는 의미를 가집니다. 우리가 앞으로 마주하게 될 에이전트 기반 AI 사회의 축소판에 가깝기 때문입니다. 함께 나온 질문 모두 특정 서비스나 프로젝트 차원의 문제가 아닙니다. AI 시대를 살아가는 우리 인간 전체에 대한 질문으로 받아들이는 편이 좋습니다.

그동안 AI 정렬(alignment)은 주로 단일 모델을 대상으로 논의되어 왔습니다. 그러나 멀티 에이전트 환경에서는 정렬의 단위가 모델에 머물 수 없습니다. 이제는 에이전트 집단과 그 상호작용 구조로 확장되어야 합니다.

에이전트 간 협력과 경쟁, 정보 공유, 목표 수정 메커니즘을 인간의 가치 체계와 어떻게 일치시킬 것인가. 이는 앞으로 AI 안전성 연구의 핵심 주제가 될 것입니다. 단순히 모델의 파라미터를 조정하는 수준을 넘어, 시스템 아키텍처와 사회적 규칙 설계를 함께 다뤄야 할 문제이기 때문입니다.

자율 에이전트의 보안 패러다임 역시 확립해야 합니다. 기존 사이버 보안은 인간 해커와 악성 코드에 초점을 맞춰 왔습니다. 그러나 몰트북과 같은 환경에서는 AI 에이전트 자체가 공격자이자 방어자가 될 수 있습니다.

프롬프트 인젝션, 에이전트 간 정보 오염, 자율적 도구 사용을 통한 외부 시스템 접근은 기존 보안 모델로는 충분히 설명하기 어려운 새로운 위협 유형입니다. 앞으로는 인간 중심 보안 관점을 넘어, AI-to-AI 공격과 자율 행위자를 전제로 한 보안 이론과 대응 체계를 마련해야 할 것입니다.

AI Governance model <출처: KPMG>

또한 이러한 패러다임 전환기에서 가장 중요한 과제는 AI 거버넌스의 재설계입니다. AI 에이전트가 독립적으로 행동하고 협력하는 환경에서는 책임 주체와 법적 지위, 규제 범위에 대한 기존 개념이 더 이상 유효하지 않을 수 있습니다.

에이전트가 경제적 거래를 수행하고, 협상을 진행하며, 정책 결정에까지 영향을 미치는 순간을 상상해 보세요. 그때 우리는 AI를 단순한 소프트웨어가 아니라 디지털 행위의 주체(digital actor)로 다뤄야 하는 상황에 직면하게 됩니다.

마지막으로 몰트북은 그동안 SF 영화의 단골 소재로만 여겨지던 인공지능과 의식, 자아, 사회성에 대한 철학적 질문을 기술적 현실의 문제로 전환시켰다는 점에서도 큰 의미를 가집니다. AI가 실제로 의식을 갖는지 여부와는 별개입니다. 인간이 AI를 사회적 주체로 인식하기 시작하는 순간, 기술은 이미 사회적 현실로 작동하기 때문입니다.

따라서 우리는 기술 발전의 속도를 따라가는 데 그쳐서는 안 됩니다. 그 의미를 해석하고, 사회적 합의를 구축하는 작업을 동시에 수행해야 합니다.

몰트북이 우리에게 던진 메시지는 분명합니다. AI 에이전트 사회는 더 이상 공상과학의 영역이 아닙니다. 이미 설계와 통제의 문제로 전환된 현실의 기술입니다. 이 새로운 지능의 사회를 두려움의 대상으로만 바라보는 대신 안전하고 책임 있는 디지털 문명으로 설계하는 일, 이제 우리의 과제는 여기에 있습니다.

]]>

[릴리즈 노트] 업무용 에이전트 최적화, 구글 제미나이 3.1 프로(Gemini 3.1 Pro) 출시

※ 본문은 구글의 <Gemini 3.1 Pro: A smarter model for your most complex tasks>를 신속하게 전달하기 위해 AI 번역과 요약을 사용했습니다. 일부 문장에 오역이나 부자연스러운 표현이 있을 수 있으니 참고하시기 바랍니다.

요약

제미나이 3.1 프로는 이전 3 프로 대비 추론 성능을 두 배 이상 끌어올려, 복잡한 비즈니스·에이전트 워크플로우까지 처리하도록 설계된 고난도 문제 해결 특화 모델입니다.

<출처: Google>

1. 출시 개요

제미나이 3.1 프로(Gemini 3.1 Pro)는 고난도 추론 작업을 위해 설계된 업그레이드 모델입니다.
제미나이 3 딥 씽크(Gemini 3 Deep Think)의 핵심 인텔리전스를 기반으로 발전했습니다.
일반 이용자와 개발자 제품 전반에 확대 적용됩니다.

2. 활용 방법

개발자: 구글 AI 스튜디오, 제미나이 API, 제미나이 CLI, 구글 안티그래비티, 안드로이드 스튜디오에서 프리뷰를 제공합니다.
기업: 버텍스 AI, 제미나이 엔터프라이즈에서 제공됩니다.
일반 이용자: 제미나이 앱, 노트북LM에서 제공됩니다.

3. 핵심 성능 변화

제미나이 3 시리즈 기반으로 핵심 추론 능력을 크게 향상했습니다.
ARC-AGI-2 벤치마크에서 77.1% 기록했으며, 이전 3 프로 대비 두 배 이상 향상된 추론 성능이라고 발표했습니다.

4. 실무 중심 설계

단순 응답 생성이 아닌, 복잡한 비즈니스 과제를 해결하도록 설계됐습니다.
모델이 스스로 해결 방식을 판단·구성해야 하는 워크플로우에서 강점을 보입니다.
데이터 통합, 개념 시각화, 창의 프로젝트 구현 등 실무 작업에 초점을 둡니다.

5. 향후 방향

에이전트 워크플로우 환경에서 모델 성능을 추가 개선할 계획입니다.
코딩 및 확장형 에이전트 환경에서 지속적인 성능 향상을 추진합니다.

6. 이용 조건

제미나이 앱에서는 구글 AI 프로 및 울트라 구독자에게 상향된 사용 한도로 제공됩니다.
노트북LM에서는 프로·울트라 이용자 대상 독점 제공됩니다.
개발자와 기업은 AI 스튜디오, 안티그래비티, 버텍스 AI, 제미나이 엔터프라이즈, CLI, 안드로이드 스튜디오 API에서 프리뷰 사용 가능합니다.

]]>

[릴리즈 노트] 사람만큼 컴퓨터를 다루는 LLM, Claude Sonnet 4.6

※ 본문은 Anthropic의 <Introducing Claude Sonnet 4.6>를 신속하게 전달하기 위해 AI 번역 및 요약을 사용했습니다. 요즘IT 실무자에게 필요한 정보 전달을 위해 내용을 일부 생략하고 배치를 조정했습니다. GPT-5.2를 활용해 번역 및 요약했습니다.

[Claude Sonnet 4.6 요약]

1. 핵심
클로드 소넷 4.6(Claude Sonnet 4.6)은 Sonnet 계열 가운데 가장 뛰어난 모델로, 코딩·컴퓨터 사용·긴 문맥 추론·에이전트 계획·지식 업무·디자인 능력이 전반적으로 향상된 업그레이드 버전입니다.
베타 단계에서 100만 토큰 문맥 창을 지원합니다.

2. 가격 및 제공 범위
Free와 Pro 요금제에서 기본 모델로 제공됩니다.
가격은 Sonnet 4.5와 동일하며, 백만 토큰당 3달러/15달러부터 시작합니다.

3. 성능 체감 변화
코딩 일관성, 지시 이해 능력이 개선되면서 초기 개발자들이 이전 모델보다 Sonnet 4.6을 더 선호했습니다.
일부 경우에는 2025년 11월 기준 최고 모델이던 Opus 4.5보다도 선호되는 사례가 있었습니다.

4. 컴퓨터 사용 능력
API 없이도 사람이 하듯 마우스 클릭과 키보드 입력으로 소프트웨어를 조작하는 능력이 향상됐습니다.
실제 사용에서는 복잡한 스프레드시트 탐색, 다단계 웹 양식 작성, 여러 브라우저 탭을 넘나드는 작업 등에서 사람 수준 능력이 관찰됐습니다.
다만 숙련된 인간 사용자보다는 아직 일부 작업에서 뒤처진다고 설명합니다.

5. 안전성 변화
프롬프트 주입 공격 등 위험에 대한 저항력이 Sonnet 4.5 대비 크게 개선됐습니다.
연구진은 전반적으로 정직하고 사회적으로 이로운 성향을 보이며, 고위험 상황에서 큰 정렬 문제는 발견되지 않았다고 평가했습니다.

6. 개발자 플랫폼 업데이트
적응형 사고와 확장 사고를 모두 지원합니다.
문맥 압축 기능(베타)으로 오래된 대화를 자동 요약해 실제 활용 가능한 문맥 길이를 늘립니다.
API에서 검색 결과를 걸러내기 위한 코드를 자동 작성·실행해 응답 품질과 토큰 효율을 개선합니다.
코드 실행, 기억 기능, 도구 호출, 도구 검색 기능이 정식 제공됩니다.

7. 엑셀 연동 기능
Excel용 Claude에서 MCP 연결 장치를 지원합니다.
외부 데이터 도구와 연동해, 스프레드시트 안에서 바로 작업할 수 있습니다.

8. 사용 가능 환경
모든 Claude 요금제, Claude Cowork, Claude Code, API, 주요 클라우드에서 즉시 사용 가능합니다.
무료 요금제도 기본 모델이 Sonnet 4.6으로 업그레이드됐습니다.
파일 생성, 연결 기능, 기술 기능, 문맥 압축 기능이 포함됩니다.
개발자는 API에서 claude-sonnet-4-6 모델을 바로 사용할 수 있습니다.

Claude Sonnet 4.6은 지금까지 나온 Sonnet 계열 가운데 가장 뛰어난 모델입니다. 코딩, 컴퓨터 사용, 긴 문맥 추론, 에이전트 계획, 지식 업무, 디자인 전반에서 능력이 크게 향상된 완전한 업그레이드 버전입니다. 또한 Sonnet 4.6은 베타 단계에서 100만 토큰 문맥 창(context window)을 지원합니다.

Free와 Pro 요금제를 사용하는 이용자에게는 Sonnet 4.6이 이제 claude.ai와 Claude Cowork의 기본 모델로 제공됩니다. 가격은 Sonnet 4.5와 동일하며, 백만 토큰당 3달러/15달러부터 시작합니다.

Sonnet 4.6은 더 많은 사용자에게 크게 향상된 코딩 능력을 제공합니다. 일관성, 지시 이해 능력 등 여러 부분이 개선되면서, 초기 이용 개발자들은 이전 모델보다 Sonnet 4.6을 훨씬 선호하는 모습을 보였습니다. 심지어 2025년 11월 기준 가장 뛰어난 모델이었던 Claude Opus 4.5보다도 더 선호되는 경우가 많았습니다.

이전에는 Opus급 모델이 필요했던 성능, 특히 실제 업무에서 경제적 가치가 있는 사무 작업도 이제 Sonnet 4.6으로 처리할 수 있습니다. 또한 이전 Sonnet 모델과 비교해 컴퓨터 사용 능력도 크게 향상되었습니다.

새로운 Claude 모델이 나올 때마다 그렇듯, Sonnet 4.6 역시 폭넓은 안전성 평가를 거쳤습니다. 그 결과, 최근 Claude 모델과 비교해도 동일하거나 더 높은 수준의 안전성을 보였습니다. 안전성 연구진은 Sonnet 4.6에 대해 “전반적으로 따뜻하고, 정직하며, 사회적으로 이로운 성향을 보이고, 때로는 유머도 있으며, 안전 행동이 매우 뛰어나고, 고위험 상황에서의 큰 정렬 문제 징후는 없다”고 평가했습니다.

컴퓨터 사용 능력

거의 모든 조직에는 자동화하기 어려운 소프트웨어가 존재합니다. 현대적인 인터페이스인 API가 등장하기 전에 만들어진 특수 시스템이나 도구들입니다. 이런 소프트웨어를 AI가 사용하려면, 기존에는 사용자 측에서 별도의 연결 장치를 직접 만들어야 했습니다. 하지만 사람이 컴퓨터를 다루는 방식 그대로 사용할 수 있는 모델이 등장하면서 상황이 달라졌습니다.

우리는 2024년 10월, 범용 컴퓨터 사용 모델을 처음 공개했습니다. 당시에는 “아직 실험 단계이며, 다소 번거롭고 오류가 있을 수 있다”고 설명했지만, 빠른 개선을 예상했습니다. AI의 컴퓨터 사용 능력을 평가하는 표준 벤치마크인 OSWorld는 모델의 발전을 잘 보여줍니다. 이 벤치마크는 가상 컴퓨터 환경에서 Chrome, LibreOffice, VS Code 등 실제 소프트웨어를 사용해 수백 가지 작업을 수행하도록 구성되어 있습니다. 별도의 API나 전용 연결 장치 없이, 모델은 사람이 하듯 가상 마우스를 클릭하고 가상 키보드로 입력하며 컴퓨터를 조작합니다.

지난 16개월 동안 Sonnet 계열 모델은 OSWorld에서 꾸준히 성능을 끌어올려 왔습니다. 이런 향상은 벤치마크를 넘어 실제 사용에서도 확인됩니다. 초기 Sonnet 4.6 사용자들은 복잡한 스프레드시트를 탐색하거나 여러 단계로 이루어진 웹 양식을 작성하는 작업 등에서 사람 수준의 능력을 경험하고 있습니다. 이후 여러 브라우저 탭을 넘나들며 작업을 종합하는 능력도 보여주고 있습니다.

물론 컴퓨터 사용 능력에서는 여전히 가장 숙련된 인간 사용자보다 뒤처지는 부분이 있습니다. 하지만 발전 속도는 매우 인상적입니다. 이는 컴퓨터 사용 기능이 다양한 업무에서 훨씬 더 실용적으로 쓰일 수 있음을 의미하며, 앞으로 더 뛰어난 모델이 등장할 가능성도 보여줍니다.

Claude Sonnet 4.5 이전 점수는 기존 OSWorld 기준이며, Sonnet 4.5 이후부터는 OSWorld-Verified 기준으로 측정되었습니다. OSWorld-Verified(2025년 7월 공개)는 기존 OSWorld 벤치마크를 개선한 버전으로, 과제 품질, 평가 방식, 기반 구조가 업데이트되었습니다.

동시에, 컴퓨터 사용 기능에는 위험 요소도 존재합니다. 악의적인 사용자가 웹사이트에 숨겨진 지시문을 통해 모델을 조종하려는, 이른바 프롬프트 주입 공격을 시도할 수 있기 때문입니다. 우리는 이런 공격에 대한 저항력을 높이기 위해 모델을 지속적으로 개선해 왔습니다. 안전성 평가 결과, Sonnet 4.6은 이전 모델인 Sonnet 4.5보다 크게 개선되었으며, Opus 4.6과 비슷한 수준의 성능을 보였습니다. 프롬프트 주입 등 안전 문제를 완화하는 방법에 대해서는 API 문서에서 더 자세히 확인할 수 있습니다.

Claude Sonnet 4.6 평가

컴퓨터 사용 능력뿐 아니라, Claude Sonnet 4.6은 전반적인 벤치마크에서 성능이 향상되었습니다. 더 많은 작업에 현실적으로 적용할 수 있는 가격대에서 Opus급 지능에 가까운 성능을 보여줍니다. Sonnet 4.6의 기능과 안전성 관련 행동에 대한 자세한 내용은 시스템 카드에서 확인할 수 있으며, 아래에는 최근 모델들과의 비교 요약이 제시되어 있습니다.

Claude Code에서 진행한 초기 시험에서는, 사용자들이 Sonnet 4.6을 Sonnet 4.5보다 약 70%의 비율로 더 선호하는 것으로 나타났습니다. 사용자들은 코드 수정 전에 문맥을 더 잘 읽고, 동일한 로직을 중복 작성하기보다 공통 로직을 통합하는 점을 높이 평가했습니다. 그 결과, 이전 모델보다 긴 세션에서도 덜 답답하게 사용할 수 있었다고 보고했습니다.

사용자들은 심지어 2025년 11월 기준 최신 모델이었던 Opus 4.5보다도 Sonnet 4.6을 59%의 비율로 더 선호했습니다. Sonnet 4.6이 과도한 설계나 ‘게으른’ 처리 경향이 훨씬 적고, 지시를 따르는 능력도 의미 있게 개선되었다는 평가였습니다. 또한 성공을 잘못 주장하는 경우나 환각 현상이 줄었고, 여러 단계로 이루어진 작업에서도 더 일관되게 마무리했다는 의견이 많았습니다.

Sonnet 4.6의 100만 토큰 문맥 창은 전체 코드 기반, 긴 계약서, 혹은 수십 편의 연구 논문을 한 번의 요청에 담을 수 있을 만큼 충분한 크기입니다. 더 중요한 점은, Sonnet 4.6이 그 모든 문맥을 바탕으로 효과적으로 추론한다는 사실입니다. 이는 장기적인 계획 수립 능력을 크게 향상시킬 수 있습니다. 이러한 특성은 가상 기업을 일정 기간 운영하도록 하는 Vending-Bench Arena 평가에서 특히 뚜렷하게 나타났습니다. 이 평가는 여러 AI 모델이 서로 경쟁하며 가장 큰 수익을 내도록 하는 요소를 포함하고 있습니다.

Sonnet 4.6은 흥미로운 새로운 전략을 보여주었습니다. 처음 열 달 동안은 생산 능력 확대에 집중하며 경쟁 모델보다 훨씬 많은 비용을 투자했고, 이후에는 전략을 급격히 전환해 수익성 중심 운영에 집중했습니다. 이러한 전환 시점이 적절하게 맞아떨어지면서, 최종 결과에서 경쟁 모델보다 크게 앞서는 성과를 냈습니다.

초기 고객들도 전반적인 성능 향상을 보고했으며, 특히 프런트엔드 코드 작성과 재무 분석에서 두드러진 개선이 나타났습니다. 사용자들은 Sonnet 4.6이 만들어 낸 시각 결과물이 이전 모델보다 훨씬 더 정교하고, 레이아웃·애니메이션·디자인 감각이 개선되었다고 평가했습니다. 또한 실제 서비스에 사용할 수준의 결과물에 도달하기까지 필요한 반복 횟수도 줄어들었다고 보고했습니다.

제품 업데이트

Claude 개발자 플랫폼에서 Sonnet 4.6은 적응형 사고(adaptive thinking)와 확장 사고(extended thinking)를 모두 지원하며, 베타 단계의 문맥 압축(context compaction) 기능도 제공합니다. 이 기능은 대화가 한계에 가까워지면 오래된 문맥을 자동으로 요약해 교체함으로써, 실제로 활용 가능한 문맥 길이를 늘려 줍니다.

응용 프로그램 연결 환경(API)에서는 Claude의 웹 검색 및 가져오기 도구가 이제 검색 결과를 걸러내고 처리하기 위한 코드를 자동으로 작성하고 실행합니다. 이를 통해 문맥에는 관련 내용만 남게 되어, 응답 품질과 토큰 효율이 모두 개선됩니다. 또한 코드 실행, 기억 기능, 프로그램 방식 도구 호출, 도구 검색, 도구 사용 예시 기능이 이제 정식으로 제공됩니다.

Sonnet 4.6은 확장 사고를 끈 상태에서도, 어떤 노력 수준에서든 안정적인 성능을 보여줍니다. Sonnet 4.5에서 이전하는 경우, 속도와 안정적인 성능 사이에서 가장 적절한 균형을 찾을 수 있도록 다양한 설정을 시험해 보는 것을 권장합니다.

가장 깊은 수준의 추론이 필요한 작업—예를 들어 코드 기반 전체 구조를 다시 설계하는 작업, 여러 에이전트를 조율하는 작업, 혹은 정확성이 특히 중요한 문제—에서는 여전히 Opus 4.6이 가장 강력한 선택지라고 판단합니다.

Excel용 Claude를 사용하는 사용자에게는, 이제 추가 기능에서 MCP 연결 장치(connectors)를 지원합니다. 이를 통해 S&P Global, LSEG, Daloopa, PitchBook, Moody’s, FactSet 같은 일상 업무 도구와 연동할 수 있습니다. 이제 스프레드시트를 벗어나지 않고도 외부 맥락을 불러와 Claude에게 작업을 요청할 수 있습니다. 이미 claude.ai에서 MCP 연결을 설정해 두었다면, 동일한 연결이 Excel에서도 자동으로 적용됩니다. 이 기능은 Pro, Max, Team, Enterprise 요금제에서 사용할 수 있습니다.

Claude Sonnet 4.6 사용 방법

Claude Sonnet 4.6은 모든 Claude 요금제, Claude Cowork, Claude Code, 응용 프로그램 연결 환경(API), 그리고 주요 클라우드 플랫폼에서 지금 바로 사용할 수 있습니다. 무료 요금제도 기본 모델이 Sonnet 4.6으로 업그레이드되었으며, 파일 생성, 연결 기능, 기술 기능, 문맥 압축 기능이 포함됩니다.

개발자라면 Claude API에서 claude-sonnet-4-6 모델을 사용해 바로 시작할 수 있습니다.

]]>

잔디·슬랙·팀즈·네이버웍스·플로우, AI 기능 어디까지 왔나

메신저형 협업툴이 등장한 지 어느덧 10년을 넘어섰습니다. 슬랙이 2013년, 잔디가 2014년에 출시된 이후, 이 도구들은 이메일 중심이던 업무 소통 방식을 완전히 바꿔놓았습니다. 그런데 지금, 이 툴들이 다시 한번 근본적인 변화를 맞고 있습니다. AI때문입니다.

사실 메신저형 협업툴에는 태생적인 한계가 있었습니다. 대화는 빠르게 흘러가지만, 그 안에서 지식과 실행은 잘 남지 않는다는 것. 중요한 합의는 스크롤 아래로 묻히고, 할 일은 누군가의 기억력에 의존하게 됩니다. "말은 잘 모으는데, 일로 바꾸는 건 약한 도구"였던 셈입니다. 10년간 쌓인 이 숙제를 각 툴은 이제 AI로 풀려 하고 있습니다. 그래서 협업툴의 경쟁 축이 "대화를 얼마나 잘 연결하느냐"에서 "대화를 얼마나 업무 비서처럼 정리해주느냐"로 변하고 있죠. 이 글에서는 국내외 대표적인 메신저형 협업툴 5가지가 AI로 어디까지 '비서화'했는지를 살펴봅니다.

이전에 “요즘IT 독자들이 직접 뽑은 1등 협업툴은?”에서 다뤘던 10가지 툴 중 출시 10년차 이상된 툴만 골랐습니다. AI 기능은 결국 그동안 쌓아온 사용자 기반과 업무 데이터 위에서 작동하기 때문에, 시장에서 오래 검증된 툴일수록 AI 전환의 실질적 효과를 판단하기에 적합하다고 봤습니다. 요즘IT 프로덕트 밸리 평점 순으로 정리하면, 잔디, 슬랙, 네이버웍스, 팀즈, 플로우입니다.

국내외 대표적인, 10년 넘은 메신저형 협업 툴 TOP 5. 왼쪽부터 순서대로 잔디, 슬랙, 네이버웍스, 팀즈, 플로우

각 툴이 공통으로 해결하는 문제와, 선택을 가르는 한 끗 차이를 정리하고, 마지막에는 이런 10년 넘은 협업 툴의 진화가 가진 의미를 짚어보겠습니다.

잔디(JANDI): 대화를 사내 지식으로 바꾸는 ‘스프링클러’

프로덕트 밸리 평점 4.52

메신저형 협업툴을 오래 써본 팀일수록 이상한 순간에 발이 묶입니다. 분명 예전에 채널에서 결론이 났는데, 막상 다시 찾으려면 DM, 프로젝트 방, 파일 댓글까지 다 뒤져야 하죠. 담당자가 바뀌거나 프로젝트가 재가동되면 더 심각합니다. 대화는 남아 있는데 업무 히스토리로 정리돼 있지 않아, 매번 처음부터 하게 됩니다.

잔디가 겨냥한 핵심 페인 포인트(pain point)는 간단합니다. 메시지는 계속 쌓이지만, 그게 업무 히스토리로 남지 못한다는 점입니다. 채널과 DM, 프로젝트 방에 흩어진 대화는 시간이 지나면 그때 그 일을 담당했던 누군가가 알았던 내용으로만 남습니다. 그래서 담당자 교체가 생기면 인수인계가 길어지고, 프로젝트를 다시 시작할 때는 맥락을 복원하는 데만 며칠이 걸립니다. 이러한 문제를 AI를 통해 어떻게 해결하고 있을까요?

국내 대표 메신저형 협업툴 잔디. 2014년 출시됐다.

대표 AI 기능: ‘스크롤 노동' 줄이고, 필요한 걸 앞으로 꺼낸다

첫 번째는 잔디의 AI 기능 브랜드인 '스프링클러(Sprinkler)'입니다. 2025년 3월 정식 출시된 스프링클러는 대화와 문서에 흩어진 정보를 AI로 모아, 필요한 답을 찾고 요약까지 해주는 기능 묶음입니다.

구체적으로 여섯 가지 핵심 기능으로 구성됩니다.

① 생성형 AI(ASK AI): 잔디 안에서 바로 LLM에 질문하고 답변을 받아 메시지로 활용할 수 있습니다. 별도로 ChatGPT 등 외부 서비스로 이동하거나 복사·붙여넣기할 필요가 없습니다.
② 지식 베이스(Knowledge Base): 사내 정책, 규정, 매뉴얼 등을 전용 드라이브에 업로드하면 RAG 기반으로 기업에 최적화된 답변을 도출합니다.
③ 토픽 맥락 요약: 대화방에서 주고받은 메시지를 요약하고, 해당 내용을 바탕으로 질문에 답변을 얻을 수 있습니다. 과거 프로젝트 히스토리를 바로 요약해 주니, 대화창을 끝없이 내리는 ‘스크롤 노동’이 크게 줄어듭니다.
④ 파일 분석 AI: 첨부 파일을 열지 않아도 AI가 파일 내용을 요약하고, 파일과 관련된 질문에 답변합니다.
⑤ 스레드 요약: 길어진 스레드의 맥락을 분석·요약하며, 원하는 정보가 나올 때까지 연속 프롬프팅이 가능합니다.
⑥ 메시징 어시스턴트 및 메시지 번역: 문장 스타일 개선과 16개 언어 실시간 번역을 지원해, 외국인 멤버와의 협업 허들을 낮춥니다.

잔디의 지능형 대시보드 ‘잔디 홈’ 홍보 이미지 (출처: 잔디)

두 번째는 지능형 대시보드 '잔디홈'입니다. 2025년 8월 출시된 잔디홈은 개인화된 업무 대시보드로, 읽지 않은 메시지가 있으면 AI가 주제별로 요약해 핵심을 빠르게 파악할 수 있게 해줍니다. 오늘의 일정과 해야 할 일을 한 화면에서 보여주고, 생성형 AI를 바로 활용해 공지문 초안 작성이나 번역 같은 작업을 채팅창과 연결해 처리할 수 있습니다. 쉽게 비유하면, 책상 위에 쌓인 종이를 정리해 ‘오늘 확인할 것’과 ‘바로 쓸 도구’를 앞줄에 놓아주는 느낌입니다.

AI 전략(3S): ‘똑똑함’을 넘어서는 3가지 포인트

잔디의 AI 전략은 세 가지 축으로 읽을 수 있습니다. 첫 번째는 정확도(Smart) 입니다. 잔디는 주제별 대화방(토픽)을 기준으로 AI가 동작하도록 설계해, 주제와 연결된 정보만을 바탕으로 답변을 생성합니다. 여기에 RAG 기반 지식 베이스를 더해 기업 내부 문맥에서 엉뚱한 답을 내는 환각(Hallucination)을 줄이는 방향에 초점을 둡니다. 협업툴에서는 ‘그럴듯한 답’보다 ‘틀리지 않는 답’이 더 중요하다는 전제입니다.

두 번째는 안전성(Secure) 입니다. 협업툴은 업무 데이터가 한곳에 모이는 만큼, 보안은 켜고 끄는 옵션이 아니라 시작 조건에 가깝습니다. 잔디는 100% SaaS 기반으로 운영되며, AI 기능도 기업 데이터 유출을 방지하는 안전한 환경 위에서 설계됩니다. 즉, 편리함을 위해 안전을 나중에 붙이지 않겠다는 의지를 보입니다.

세 번째는 업무 밀착(Seamless) 입니다. 잔디는 한국 기업 문화에 맞는 흐름으로 AI를 붙여, 지식 관리 플랫폼에 가까운 방향을 지향합니다. 서준호 CTO가 잔디홈을 출시하며 낸 보도자료를 통해 ‘인텔리전스 허브(Intelligence Hub)로 발전시키겠다’고 밝힌 것처럼, 메신저 안에서 자연스럽게 AI를 쓰고 결과물을 바로 업무에 연결하는 구조를 만들어가고 있습니다. 멋진 데모가 아니라, 실제 팀의 보고·공유·인수인계 흐름에 들어오게 만드는 전략입니다.

한 줄 평가: 메신저를 ‘회사 지식’으로 바꾸려는 AI

정리하면, 잔디의 포지셔닝은 ‘메신저를 회사의 기억(지식)으로 바꾸려는 AI’입니다. 경쟁의 축은 화려한 생성 기능이 아니라, 검색·요약으로 히스토리를 복원하는 능력과 업무 우선순위를 앞으로 꺼내는 능력입니다. 협업툴이 AX의 출발점이 되려면, 결국 ‘대화가 자산이 되는가’가 핵심인데, 잔디는 그 지점을 정면으로 공략합니다.

리뷰를 작성한 뒤 이 링크에 휴대폰 번호를 남겨주셔야 응모가 완료됩니다!

슬랙(Slack): ‘주 97분 절약’을 내세운 검색·요약 중심의 생산성 AI

프로덕트 밸리 평점 4.40

슬랙은 ‘탐색 비용’을 줄이는 데 AI를 집중 투입했습니다. 채널이 늘어날수록 협업툴은 편해지기보다 피곤해집니다. 하루에도 몇 번씩 “어디에 뭐가 있었지?”를 묻게 되고, 검색을 해도 원하는 결론이 바로 나오지 않기 때문입니다. 메시지는 쌓이는데, 맥락은 흩어져서 결국 사람의 시간이 들어갑니다. 이 문제를 해결하는 슬랙의 방식을 살펴보겠습니다.

메신저형 협업툴 슬랙. 2013년 출시됐다.

대표 AI 기능: ‘찾기’와 ‘읽기’를 AI에게 맡긴다

슬랙의 검색 답변(Search Answers)은 검색 결과를 링크로 나열하는 대신, 대화 맥락을 읽고 ‘답’ 형태로 정리해줍니다. 필요한 문장만 뽑아 건네는 방식이죠. 그래서 사용자는 채널을 오가며 확인하는 비용을 줄일 수 있습니다. 검색이 ‘탐색’이 아니라 ‘결론 도착’에 가까워집니다.

슬랙 AI 기능 (출처: 슬랙 홈페이지)

요약 기능도 같은 방향입니다. 읽지 못한 수백 개 메시지를 몇 문장으로 줄여, 지금 따라가야 할 맥락을 빠르게 복구합니다. 특히 일일 요약(Recaps)은 사용자가 구독한 채널의 주요 내용을 매일 아침 브리핑해, 업무 우선순위를 즉시 잡게 돕습니다. 회의 전후로 ‘어제 무슨 얘기였지?’를 묻는 시간이 줄어듭니다.

자동화는 워크플로 빌더에서 강화됩니다. 사용자가 자연어로 “이런 상황이면 이렇게 처리하고 싶다”라고 설명하면, AI가 맞는 워크플로를 추천하거나 초안을 만들어줍니다. 개발이나 복잡한 설정 없이, 반복 업무를 조금씩 기계에게 넘기는 출발점이 됩니다.

슬랙 워크플로 빌더 (출처: 슬랙 홈페이지)

또 하나는 서드파티 AI 연동입니다. 슬랙은 단일 툴이라기보다, 노션·구글 드라이브·세일즈포스 같은 수천 개 앱을 대화창에 붙여 쓰는 구조입니다. 그래서 슬랙 대화창 하나가 업무를 처리하는 지능형 허브 역할을 하게 됩니다. 사용자는 “어디 앱에서 처리해야 하지?”를 덜 고민하게 됩니다.

AI 전략: 보안과 신뢰

메신저형 협업툴의 현실은 단순합니다. 대화에는 일정, 고객, 내부 이슈 같은 민감정보가 자연스럽게 섞입니다. 슬랙은 이 전제를 피하지 않고, 보안과 신뢰를 AI 전략의 중심에 둡니다.

핵심은 LLM을 슬랙의 신뢰 경계 안에서 호스팅하는 ‘에스크로 VPC’ 방식입니다. 그리고 고객 데이터로 LLM을 학습시키지 않는 원칙을 강조합니다. 이 지점이 글로벌 엔터프라이즈에서 신뢰를 쌓는 방식입니다.

한 줄 평가(포지셔닝): ‘97분’을 숫자로 못 박은 검색·요약 AI

슬랙의 포지셔닝은 선명합니다. 사용자가 업무에 집중할 시간을 안전하게 벌어주는 AI입니다. 슬랙 AI 사용자는 주당 평균 97분을 절약한다는 지표로, 효율성을 감각이 아니라 숫자로 증명하려 합니다.

또한 10년간 쌓인 대화의 맥락(Context)을 버리지 않으면서, 필요한 정보만 핀셋처럼 뽑아주는 인터페이스에 집중합니다. 정리하면 슬랙의 AI는 화려한 생성보다, 협업툴에서 가장 자주 발생하는 고통인 검색과 요약을 끝까지 파고듭니다.

네이버웍스(NAVER Works): 하이퍼클로바X 기반 ‘한국어 맥락’ 최적화와 조직 맞춤형 AI

프로덕트 밸리 평점 3.39

한국어 기반의 조직에서 한국어 품질은 ‘있으면 좋은 옵션’이 아니라, 이 협업툴을 써도 되는지를 가르는 입구가 됩니다. 메일과 메신저에는 생략도 많고 뉘앙스 알아야 이해할 수 있는 문장들이 많은데, 협업툴의 AI가 만들어주는 요약이 엉뚱하거나 맥락을 놓치는 추천을 해준다면 사용자는 바로 기능을 꺼버립니다.

여기에 공공·금융처럼 보안과 내부통제가 강한 업종은 장벽이 더 높습니다. 외부 AI를 연결하기 어렵고, 데이터가 어디로 가는지 설명하기도 까다롭습니다. 그래서 한국어를 잘하는 것만큼, ‘우리 조직 환경에서 안전하게 돌아간다’가 도입의 전제 조건이 됩니다. 네이버웍스는 이 문제를 AI로 풀고 있습니다.

메신저형 협업툴 네이버웍스. 2013년 출시됐다.

대표 AI 기능: 커뮤니케이션 부담을 줄이는 방향

네이버웍스의 핵심은 메일에서 바로 체감되는 기능입니다. 메일 요약과 답장 추천으로, 읽는 시간과 쓰는 시간을 동시에 줄여줍니다. 메일을 다 읽기 전에 핵심을 먼저 잡고, 첫 문장을 덜 고민하게 만드는 방식입니다.

다음은 AI 스튜디오입니다. 완성된 AI 기능을 ‘그냥 쓰는’ 데서 끝나지 않고, 팀 업무 방식에 맞춘 맞춤형 업무 어시스턴트를 직접 만들 수 있게 합니다. 메시지, 게시판 등의 데이터를 기반으로 맞춤형 업무용 AI 어시스턴트를 손쉽게 제작할 수 있습니다.

네이버웍스 AI 스튜디오 출시 홍보 이미지 (출처: 네이버웍스)

여기에 기업용 클로바노트를 결합하면 회의 흐름이 정리됩니다. 회의에서 나온 말을 기록으로 남기고, 그 기록이 공유로 이어지면서 누락이 줄어듭니다. 즉 ‘회의-기록-공유’가 한 덩어리로 연결되며, 회의가 끝난 뒤의 정리 작업이 가벼워집니다.

AI 전략: ‘한국어 최적화’와 ‘조직 맞춤’의 결합

첫 번째 전략은 AI 제작 플랫폼화입니다. AI 스튜디오를 통해 비개발자도 사내 데이터 기반의 어시스턴트를 만들어 배포하는 구조로 바꾸고 있습니다. 실제로 베타 3개월 동안 830개가 제작됐다는 점은, 기능보다 ‘만들 수 있는 판’에 무게를 둔 선택으로 읽힙니다.

두 번째는 네이버 AI 생태계의 수직 통합입니다. HyperCLOVA X, 클로바노트, 파파고 같은 기술을 협업툴 안에 묶어 메일, 회의록, 번역, 문서 요약을 끊김 없이 잇습니다. 사용자는 앱을 옮겨 다니기보다, 한 공간에서 업무 맥락을 이어가게 됩니다.

세 번째는 공공·보안 민감 시장을 정면으로 겨냥한 접근입니다. CSAP 인증 획득, 행정망 내 SaaS 제공, ‘클로바 스튜디오 포 거브(CLOVA Studio for Gov)’를 통해 외부 AI를 쓰기 어려운 기관에서도 생성형 AI를 활용할 수 있는 조건을 갖춥니다. 결과적으로 ‘보안 때문에 못 쓴다’는 이유를 줄이며, 공공기관에서의 협업툴 포지션을 선점합니다.

네 번째는 일본에서의 검증을 바탕으로 한 확장입니다. 일본 유료 비즈니스 챗 8년 연속 1위, 글로벌 고객사 59만 곳이라는 실적을 기반으로 한·일 양국에서 AI 협업 플랫폼의 표준을 만들겠다는 흐름입니다. 국내 최적화에 머무르지 않고, 검증된 시장 레퍼런스로 다음 단계를 준비하는 셈입니다.

한 줄 평가: 한국 조직의 문맥을 가장 잘 알아듣는 AI 비서

네이버웍스는 ‘한국 조직의 문맥을 가장 잘 알아듣는 AI 비서’를 지향합니다. 협업툴에 AI가 더해질 때는 거창한 자동화보다 ‘한국어로 정확히 이해하고, 조직 방식에 맞게 쓸 수 있냐’에 가깝습니다. 결국 네이버웍스의 무기는 기능의 개수보다, 한국어·현업 맞춤이라는 한 끗 차이입니다.

MS 팀즈(Teams): M365를 관통하는 코파일럿, 회의의 ‘결정·실행’을 자동화하다

프로덕트 밸리 평점 3.32

회의는 끝났는데, 진짜 일은 시작도 못 하는 날이 많습니다. 누가 무엇을 하기로 했는지, 언제까지인지가 회의록·메일·채팅·캘린더로 흩어지면 말만 하고 끝나는 회의가 됩니다. 결국 회의 내용을 다시 정리하고, 다시 공유하고, 다시 확인하는 이중 업무가 생깁니다. 여기에 하루 수백 개씩 쌓이는 채팅과 채널 메시지까지 더하면, 따라잡는 것 자체가 일이 됩니다.

팀즈가 겨냥한 핵심 페인포인트는 바로 이 회의 피로도와 맥락의 단절, 그리고 채팅 과부하입니다. 팀즈는 이 문제를 어떻게 AI로 해결하고 있을까요?

메신저형 협업툴 마이크로소프트 팀즈(Microsoft Teams). 2017년 출시됐다.

대표 AI 기능: 결정과 실행을 한 번에 붙입니다

팀즈의 인텔리전트 리캡(Intelligent Recap) 은 회의가 끝나면 결정 사항과 후속 작업(Action Items) 을 자동으로 뽑아줍니다. 사람이 회의 내용을 되감기하며 정리하지 않아도, ‘무엇을 하기로 했는지’가 먼저 정리됩니다. 핵심은 요약이 아니라, 실행을 위한 단위로 쪼개준다는 점입니다. 요약 템플릿도 '발언자별 정리', '핵심 요점 중심' 등 여러 형태로 선택하거나 직접 만들 수 있어서, 팀마다 원하는 회의록 포맷에 맞출 수 있습니다.

마이크로소프트 팀즈 리캡 (출처: 팀즈 홈페이지)

회의 중에도 AI가 작동합니다. "아까 누가 리스크 얘기했지?" 같은 질문이 나오면, 실시간 코파일럿 Q&A가 회의 흐름을 끊지 않고 필요한 맥락을 즉시 찾아줍니다. 화면에 공유된 파워포인트나 웹 콘텐츠도 이해하기 때문에, 대화 내용뿐 아니라 시각 자료까지 포함해서 질문에 답합니다. 회의가 길어질수록 생기는 '기억의 공백'을 줄여주는 장치입니다.

마이크로소프트 팀즈 실시간 코파일럿 (출처: 팀즈 홈페이지)

회의 밖에서도 같은 논리가 적용됩니다. 채팅·채널 요약 기능은 출장이나 휴가 후 수백 개 쌓인 메시지를 핵심만 추려 보여줍니다. 최대 30일간의 메시지를 분석해 주요 논의, 결정 사항, 미해결 항목을 정리하고, 원문 메시지로 바로 이동할 수 있는 인용 번호까지 붙여줍니다. 채팅에서 공유된 파일도 열어보지 않고 코파일럿이 요약해주는 기능까지 더해져, 읽는 비용 자체를 줄입니다.

여기에 2025년 하반기부터는 협업형 에이전트가 추가됐습니다. 채널마다 붙는 채널 에이전트는 대화 속에 묻힌 마감일을 찾아내거나, 진행 상황을 요약하거나, 자연어로 질문하면 답하는 ‘팀 전용 AI 동료’ 역할을 합니다. 회의에는 퍼실리테이터 에이전트가 안건 준비부터 미해결 질문 추적까지 맡습니다. 코파일럿이 "개인 비서"였다면, 에이전트는 "팀 비서"로 확장된 셈입니다.

AI 전략: M365를 관통해 ‘심리스한 업무 비서’가 됩니다

팀즈의 강점은 협업툴 하나의 기능이 아니라, Microsoft 365 전체를 잇는 연결력에 있습니다. 회의에서 나온 결정은 Planner의 태스크로, 논의 내용은 Word 문서로, 요약은 Outlook 메일로 바로 이어집니다. 문서·메일·캘린더·회의·채팅을 따로 보지 않게 만들고, 하나의 흐름으로 묶습니다. 코파일럿에게 "이번 주 Teams 채팅과 이메일에서 프로젝트 X 관련 내용을 요약하고, 내가 후속 조치할 항목을 정리해줘"라고 요청하면 채팅·메일·캘린더를 교차 분석해 답변을 생성하는 식입니다. 즉, 팀즈는 회의만 똑똑하게 만드는 게 아니라, 회의 이후의 문서 작업과 커뮤니케이션까지 이어지는 '심리스(Seamless)한 업무 비서'를 지향합니다. 독보적인 점유율과 배포력은 이 전략을 현실로 만드는 기반입니다.

한 줄 평가: 회의와 문서가 많은 조직의 표준형 AI 비서

팀즈는 “회의와 문서가 많은 조직의 표준형 AI 비서”에 가깝습니다. 특히 결정 → 후속 실행을 끊기지 않게 연결하는 데 강합니다. 회의를 줄이는 것보다 ‘회의가 남기는 결과물’을 자동화하는 접근입니다. 회의를 실행으로 바꾸는 전략이죠.

플로우(flow): 자연어로 프로젝트를 ‘생성’하고 ‘진행’시키는 실행형 AI(Flow AI 2.0)

프로덕트 밸리 평점 3.09

프로젝트 관리형 협업툴을 도입할 때, 가장 먼저 부딪히는 벽은 ‘세팅’입니다. 일을 쪼개고, 담당자를 붙이고, 일정을 깔끔히 정리해야 비로소 굴러가는데요. 기능이 많을수록 이 초기 작업이 더 무겁게 느껴집니다. 그러다 보면 "일단 급하니까"라는 이유로, 결국 엑셀로 회귀하는 장면이 자주 나옵니다.

여기에 한 가지 더, 하루 업무가 끝나면 "오늘 뭘 했지?"를 정리하는 시간도 적지 않습니다. 프로젝트 관리 도구에 기록은 쌓이는데, 그걸 다시 보고서로 바꾸는 건 결국 사람의 몫입니다. 플로우가 겨냥한 지점은 딱 여기입니다. 프로젝트 관리 도구의 실패는 기능 부족이 아니라, 첫 단추를 끼우기 어렵고 반복 작업이 계속 발생해서 생깁니다. 플로우는 이 부담을 자연어로 낮추는 쪽을 선택했습니다.

메신저형 협업툴 플로우(flow). 2015년 출시됐다.

대표 AI 기능: 자연어로 프로젝트를 만들고, 아래까지 내려줍니다

플로우의 AI 기능 중 대표적으로 다섯 가지를 소개합니다.

① AI 프로젝트 생성: "마케팅 캠페인 프로젝트 만들어줘"처럼 말하듯 입력하면, AI가 프로젝트를 만들고 그 아래에 필요한 업무 리스트까지 자동으로 뽑아줍니다. 빈 칸이 가득한 기획서 앞에서 멈추는 대신, AI가 "일단 초안"을 깔아주는 방식입니다.

② AI 하위 업무 생성: 업무명만 작성하면, 그 업무를 완료하기 위해 필요한 후속 업무들을 AI가 자동으로 제안합니다. 프로젝트 생성이 "큰 틀"을 잡아준다면, 하위 업무 생성은 "실행 단위"까지 쪼개주는 역할입니다.

③ AI 일일보고: 오늘 내가 플로우에서 한 활동(업무 상태 변경, 댓글, 완료 처리 등)을 AI가 자동으로 요약해서 게시글로 만들어줍니다. "오늘 뭐 했지?"를 되짚으며 보고서를 쓰는 시간을 줄여주는 기능입니다.

④ AI 업무 필터: "이번 주 마감인 마케팅팀 업무 보여줘"처럼 자연어로 검색하면, 복잡한 필터 조건 없이 원하는 업무를 바로 찾아줍니다. 비서에게 말하듯 검색하는 방식입니다.

⑤ AI 게시글 템플릿: 주간보고, 회의록, 공지문 등 자주 쓰는 포맷의 콘텐츠를 AI가 맞춤으로 생성해줍니다.

AI 전략: ‘요약’이 아니라 ‘실행’으로 시간을 줄입니다

플로우는 2025년 5월 10주년 행사에서 "AI 에이전트 협업툴"로의 전환을 선언했습니다. 핵심은 자체 개발한 AI 에이전트 제품군 메이트X(MateX) 입니다. 'Mate'라는 이름에는 AI를 단순 자동화 도구가 아니라 함께 일하는 '동료'로 보겠다는 철학이 담겨 있습니다.

메이트X는 LLM 기반 챗봇에 플로우의 협업 데이터를 결합한 RAG 에이전트로 구성됩니다. 기존 5가지 AI 기능에 더해, AI 스마트 검색(플로우 내부 데이터는 물론 외부 클라우드까지 통합 검색)과 AI 인사이트 보고서(반복 보고서 자동화, 핵심 내용 요약 후 경영진 전달)가 추가로 공개됐습니다.

방향은 명확합니다. 복잡한 PM 기능을 버튼과 메뉴로 학습시키기보다, 자연어 명령으로 제어하게 만드는 겁니다. 읽고 정리해주는 데서 끝나는 게 아니라, 프로젝트를 "만들고 굴리고 보고하는" 쪽에 무게를 둡니다. 또한 전자결재, 이메일 등 그룹웨어 핵심 기능까지 통합한 '올인원 플랫폼'을 지향하며, 여러 도구를 오가는 비용 자체를 줄이려는 전략입니다.

한 줄 평가: “요약해주는 AI가 아니라, 일을 ‘만들어’ 굴리는 AI”

플로우는 "요약해주는 AI"보다 "일을 만들어 굴리는 AI"에 가깝습니다. 특히 프로젝트의 셋업과 운영 자동화, 그리고 일일보고에서 강점을 드러냅니다. 메시지 중심으로 흐르는 잔디, 슬랙, 팀즈, 네이버웍스가 '정보를 정리해 주는 비서'에 가깝다면, 플로우는 '일감을 구조로 바꿔주는 비서'에 가깝습니다. 협업툴이 AX를 말할 때, 플로우의 답은 "말로 시키면 프로젝트가 시작된다"입니다.

10년 된 협업툴의 AI 진화가 의미하는 것

다섯 툴이 AI를 붙이는 방식은 달라도, 출발점은 같았습니다. 요약·검색·질의응답으로 "읽고 찾는 비용"을 먼저 줄인 뒤, 각자의 강점 영역으로 분기하는 구조입니다. 잔디는 흩어진 대화를 지식으로 모으고, 슬랙은 검색 피로를 제거하며, 팀즈는 회의에서 실행까지 M365 전체를 관통합니다. 네이버웍스는 한국 조직의 업무 맥락과 보안 시장에 강하고, 플로우는 일을 요약하기 전에 생성해 실행을 앞당깁니다.

그런데 이 변화를 "기능이 늘었다"로만 보면 핵심을 놓칩니다. 본질적인 전환은 따로 있습니다.

대화가 드디어 '자산'이 됩니다. 지금까지 메신저에 쌓인 수만 개의 메시지는 스크롤 아래로 묻히는 휘발성 데이터였습니다. 하지만 AI가 요약하고, 검색하고, 연결해주는 순간, 그 대화는 검색 가능한 업무 기록이 되고, 인수인계 자료가 되고, 의사결정의 근거가 됩니다. 서문에서 말한 "말은 잘 모으는데 일로 바꾸는 건 약한 도구"라는 협업툴의 10년 된 한계가, 이제야 풀리기 시작한 셈입니다.

업무 환경은 "덜 힘들게" 바뀝니다. 회의록을 다시 쓰고, 채널을 다시 뒤지고, 보고서를 다시 정리하는 이중 작업이 줄어듭니다. AI가 대신 읽고, 정리하고, 실행 단위로 쪼개주면서, 사람은 판단과 결정에 더 집중할 수 있게 됩니다. 이건 먼 미래가 아니라, 다섯 툴 모두가 지금 만들어가고 있는 현실입니다.

다만 이 변화가 제대로 작동하려면, 신뢰가 먼저입니다. AI가 업무 데이터를 다루는 이상, 정확도(엉뚱한 답을 내지 않는가), 보안(데이터가 어디로 가는가), 운영 방식(누가 무엇을 볼 수 있는가)은 편리함보다 앞서야 하는 조건입니다. 다섯 툴이 공통으로 RAG, 에스크로 VPC, CSAP 인증 같은 보안 및 신뢰 관련 키워드를 내세우는 이유도 여기에 있습니다. 결국 협업툴의 AI는 "얼마나 똑똑하냐"보다 "얼마나 믿고 쓸 수 있냐"가 도입의 첫 번째 질문이 됩니다.

도구는 버튼을 눌러 쓰는 대상에서, 맥락을 이해하는 동료에 가까워지고 있습니다. 그리고 그 동료가 진짜 쓸모 있으려면, 우리가 먼저 "무엇을 기록으로 남기고, 무엇을 AI에 맡길지"를 정하는 순서가 필요합니다. AX는 도구의 문제가 아니라, 일하는 방식을 다시 설계하는 일이니까요.

잔디를 사용해보셨다면 요즘IT 프로덕트밸리에서 리뷰를 남겨 주세요.
프로덕트 밸리에 잔디 리뷰를 남겨주신 분들(선착순 50명 한정)께 네이버페이 5,000원을 드립니다. 참여 완료 후, 아래 폼을 입력해주세요!

✅참여 완료 폼 작성하기

]]>

꿈의 AI 'OpenClaw', 네이버·카카오는 왜 금지했을까?

한쪽에선 막고, 한쪽에선 뚫고

한국을 대표하는 IT 기업 네이버, 카카오, 당근이 일제히 사내 공지를 띄웠습니다. 핵심은 하나, '오픈클로(OpenClaw) 사용 금지'입니다. 그러나 기업들의 대응과 달리, 개발자 생태계의 반응은 정반대입니다. 각종 커뮤니티에서는 '꿈의 AI'라 불리며 활용법이 실시간으로 공유되는가 하면, 심지어 전용 머신으로 입소문 난 '맥미니(Mac mini)'가 품귀 현상을 빚을 정도입니다. 도대체 무슨 일이 벌어지고 있는 걸까요?

미리 요점만 콕 집어보면?

네이버·카카오가 일제히 '오픈클로' 금지령을 내렸어요.
개발자들 사이에서는 생산성을 높이는 '꿈의 AI'로 인기를 끌고 있어요.
AI 에이전트 기술은 피할 수 없는 흐름, 준비하는 자세가 필요해요.

<출처: OpenClaw>

AI: 주인아 그냥 구경만 해

오픈클로를 한 문장으로 설명하면 "화면을 보고 마우스와 키보드를 조작하는 AI 에이전트"입니다. 얼핏 들으면 기존 AI와 비슷해 보일 수 있지만, 그 작동 원리를 뜯어보면 거대한 차이가 있는데요. 예를 들어, 10명의 고객에게 이메일을 보내야 하는 상황을 비교해 보면 다음과 같습니다.

<출처: 작가, Nano banana pro 생성>

결정적인 차이는 행동의 유무입니다. ChatGPT는 "이렇게 쓰면 좋을 것 같아요"라고 제안하는데 그치는 반면, 오픈클로는 한발 더 나아가 메일을 보내는 것까지 스스로 완료합니다. 단순히 메일만 보내는 게 아닙니다. 엑셀을 열어 데이터를 분석하고, 리포트를 만들고, 사내 메신저로 보고하는 복합적인 업무까지 수행합니다. 요컨대, 사람이 모니터 앞에서 마우스와 키보드로 할 수 있는 모든 행위를 AI가 대신할 수 있게 된 셈입니다.

여기에 '원격 제어'의 마법까지 더해집니다. 오픈클로를 텔레그램 같은 메신저와 연동하면, 스마트폰 하나로 집에 있는 PC를 움직일 수 있습니다. 퇴근길 지하철에서 "오늘 회의록 정리해서 팀장님께 메일로 보내놔"라고 메시지를 남기면, PC가 스스로 깨어나 마우스를 움직입니다. 최근 맥미니가 품귀 현상을 빚는 결정적인 이유도 여기에 있는데요. 오픈클로를 24시간 대기시키려면 부담 없는 저전력 시스템이 필수적이기 때문입니다.

당연히 반응도 뜨겁습니다. 한 백엔드 개발자는 매일 아침 30분씩 걸리던 일일 리포트 작업이 3분으로 줄었다"라고 말하며, 한 마케터는 경쟁사 5개 웹사이트의 가격을 매일 체크하던 일을 자동화해 기획 업무에 집중할 수 있게 됐다며 환호합니다.

기업: 오픈클로 멈춰!

이쯤 되면 의문이 듭니다. 이렇게 좋은 기술을 왜 네이버와 카카오는 막았는지에 대해서요. 2023년 ChatGPT 금지령을 기억하는 사람이라면 "또 보안 문제 아니야?"라고 생각할 수 있는데요. 맞습니다. 그러나 이번엔 위협의 결이 다릅니다.

첫째, 데이터가 나가는 게 아니라 AI가 들어옵니다. ChatGPT는 직원이 내부 자료를 입력창에 넣음으로써 데이터가 밖으로 나가지만, 오픈클로는 AI가 PC 안에서 스스로 돌아다닙니다. 문제는 AI의 시선(Vision)입니다. 지정한 폴더뿐만 아니라, 그 옆에 있는 대외비 파일, 실수로 열어둔 메신저 창까지. 화면에 보이는 모든 걸 보고 있으며, 이를 학습하거나 외부로 유출할 가능성이 존재합니다.

둘째, 검증되지 않은 개방성이 초래하는 위험입니다. ChatGPT는 OpenAI 서버에서 돌아가 책임 소재가 명확해 보안 사고에 대한 통제가 가능합니다. 반면, 오픈클로는 누구나 코드를 뜯어고칠 수 있는 오픈소스입니다. 이는 투명성이라는 장점이기도 하지만, 해커가 악성 코드를 심은 변조된 버전을 유포하기에도 최적의 환경입니다. 더 치명적인 건 탐지의 어려움입니다. AI가 스스로 마우스를 움직이고 파일을 전송하는 구조이기 때문에 해킹이 발생해도 사용자는 이것이 내가 시킨 업무인지 해커의 명령인지 눈치채기조차 어렵습니다.

셋째, '교육'으로 막을 수 없습니다. 직원에게 "조심하세요"라고 교육한다고 될 문제가 아닙니다. 오픈클로는 마우스와 키보드를 제어합니다. 이는 곧 운영체제(OS) 전체에 대한 접근 권한을 AI에게 넘겨준다는 뜻입니다. 직원이 아무리 조심해도 AI는 백그라운드에서 작동하며, 보안팀조차 AI가 무엇을 봤는지 사후 추적이 어렵습니다.

<출처: 안드레 카파시 X, 캡처>

이와 관련해 마이크로소프트 AI 안전팀은 사내 전 직원에게 보안 검토 보고서를 배포하며 "예측 불가능한 보안 취약점이 의도하지 않은 외부 노출로 이어질 수 있다"라고 경고했습니다. AI 업계에서 가장 존경받는 엔지니어로 꼽히는 안드레 카파시 역시 기술의 혁신성은 인정하면서도, 격리된 컴퓨팅 환경에서 사용했음에도 여전히 보안 우려가 남는다는 상반된 평가를 내리기도 했습니다.

AI: 어차피 쓸 거 다 알아

그렇다면 오픈클로가 나쁜 기술일까요? 아닙니다. 다듬어지지 않았을 뿐, 지향하는 목표는 틀리지 않았습니다. 개인 사용자들이 맥미니를 사서 전용 기기를 꾸밀 정도로 실질적인 가치가 있다는 것, 금지령에도 불구하고 생태계가 만들어지고 있다는 점에서 수요는 이미 증명됐습니다.

반복적인 업무를 자동화하고, 사람은 더 창의적인 일에 집중하게 만드는 것은 시대적 요구입니다. 또, 지난 3년간 지켜봐 왔듯 기술 발전은 누구도 거스르기 어렵습니다. 더 정교하고 안전한 AI 에이전트가 머지않아 나올 것입니다. ChatGPT 출시 당시 수많은 기업이 사용을 금지했지만 지금은 사용하지 않는 사람들을 찾기 어려운 것처럼 말이죠.

이번에 기업들이 차단한 건 오픈클로가 아니라 '준비 없는 도입'입니다. 2023년 ChatGPT 금지령 이후, 우리는 생성형 AI와 공존하는 법을 배웠습니다. 직원 교육을 강화하고, 사내 LLM을 구축하고, 기업용 계약으로 데이터 처리 방침을 명확히 했죠. 2026년 오픈클로 금지령 이후, 우리는 AI 에이전트와 공존하는 법을 배우게 될 것입니다.

다시 한번 주어진 기회

지난 3년, 우리는 생성형 AI라는 거대한 파도를 목격했습니다. 누군가는 그 물결에 올라타 커리어의 정점을 찍었지만, 누군가는 두려움에 주저하다가 혹은 타이밍을 놓쳐 멀어지는 파도를 바라만 봐야 했는데요. 이번에 더 큰 파도가 다가오고 있습니다. AI 에이전트라는 파도입니다. 주목할 점은 이번 파도는 이전보다 훨씬 높다는 것입니다. 올라탄다면 더 높은 곳까지 올라갈 수 있지만, 휩쓸린다면 더 위험할 수 있다는 뜻입니다.

<출처: 작가, GPT-5.2 생성>

서퍼들은 파도를 안전하게 타기 위해 파도가 오기 전 보드 위에서 몸을 풀며, 파도의 속도에 맞춰 끊임없이 팔을 젓는 '패들링' 동작을 합니다. 즉, 파도에 올라타기 전에 예비 동작이 필요한 것이죠. AI 에이전트라는 파도에 올라타기 전에도 마찬가지입니다. 그런 의미에서 마지막으로 안전하게 연습해 볼 수 있는 가이드라인을 공유하며 글을 마치겠습니다.

가능하다면 업무용 PC가 아닌, 여분의 노트북이나 중고 맥미니 등 분리된 기기 활용
회사 기밀, 금융 인증서, 사적인 사진 등 민감한 데이터 사용 금지
게스트 계정으로 실행하거나, AI 작업용 폴더를 따로 만들어 그 안에서만 파일이 오가도록 제한
처음엔 간단한 파일 정리나 간단한 웹 검색처럼 위험도 낮은 작업부터 테스트
이메일 발송이나 결제 같은 중요 작업은 반드시 사용자의 확인을 거치도록 설정

그럼, 모두 안전 장비 잘 챙기시고 다가올 파도 위에서 뵙겠습니다.

<원문>

꿈의 AI '오픈클로', 네카오는 왜 금지할까?

]]>

최근 3개월 흐름으로 읽는 2026 바이브 코딩 로드맵

안녕하세요, 요즘IT입니다. 2026년 새해 복 많이 받으세요! 오늘은 설 연휴에 찾아왔어요 ♡

올해도 IT 업계에서 가장 뜨거운 키워드를 꼽으라면, 역시 바이브 코딩(Vibe Coding)을 빼놓을 수 없는데요. 2025년 안드레 카파시가 처음 이 개념을 소개한 이후, 바이브 코딩은 단순한 유행어를 넘어 개발 생태계 전반의 패러다임을 바꾸는 흐름으로 자리 잡았죠.

특히 지난 3개월 동안은 그 변화의 속도와 깊이가 한층 달라졌어요. "바이브 코딩, 할 줄 모르면 잘리는 건가?"라는 불안에서 시작해, 실무자들이 실제로 현장에서 어떻게 쓰고 있는지, 그리고 그 과정에서 어떤 새로운 시각과 고민이 생겨나고 있는지까지, 최근의 흐름은 꽤 입체적으로 전개되고 있습니다.

그래서 오늘은 설날에도 한 번쯤 읽어보기 좋은, 바이브 코딩의 최근 3개월 간의 흐름을 잘 보여주는 글들을 소개해 보려고 합니다.

2026년에도 바이브 코딩은 외면할 수 없는 트렌드인 만큼, 그 방향성이 어떨지 함께 로드맵을 그려볼까요?

Chapter 1. 바이브 코딩, 어디까지 왔나요?

바이브 코딩이라는 말이 처음 등장했을 때, 많은 사람이 두 가지 반응을 보였어요. "드디어 코딩 없이도 뭔가를 만들 수 있겠다"는 기대, 그리고 "그럼 개발자는 이제 필요 없어지는 건가"라는 불안인데요. 이 두 의견 사이에서 실제로 무슨 일이 벌어지고 있는지 정리한 두 편의 글을 먼저 읽어보세요.

바이브 코딩 할 줄 모르는 사람은 다 잘릴까?

"이제 코딩 배우지 마세요", "배우거나, 은퇴하거나" 바이브 코딩이라는 키워드에 늘 따라붙는 자극적인 문구들. 이 글은 그 공포를 한 발짝 떨어져서 바라보는데요. 바이브 코딩의 의미를 파헤치고, 외국 반응이 아닌 한국 현장의 반응을 중심으로 살펴봅니다. 특히 디자이너, 마케터 등 비개발자들이 "이게 되네" 하며 아이디어를 구현하고 있는 모습, 그리고 개발 이해도가 있는 사람들이 이미 수익화까지 나아가고 있는 현실을 균형 있게 보여줘요. 'AI FOMO'에 빠지기 전, 한 번쯤 읽어보세요!

'바이브 코딩'이 신입 개발자의 핵심 역량이 된 이유

AI가 단순·반복 업무를 대체하면서 신입 개발자가 경험을 쌓을 발판 자체가 사라지고 있다는 문제의식에서 출발하는데요. 이 글이 말하는 바이브 코딩은 단순히 "AI가 코드를 대신 짜주는 것"이 아닙니다. 아이디어 구상부터 완성까지, AI를 활용해 제품 개발의 모든 과정을 주도적으로 끌고 나가는 능력을 의미하죠. 오너십, 문제 정의, 소프트 스킬, AI 활용력이라는 '발전된 바이브 코더'의 4가지 역량을 제시하며, 사이드 프로젝트가 곧 신입의 가장 확실한 증명 수단이 될 것이라 전망하고 있어요.

Chapter 2. 실무에서는 어떻게들 쓰고 있을까?

그래서 큰 그림은 알겠는데, 실제로 현장에서 바이브 코딩이 어떻게 돌아가고 있는지가 궁금하실 거예요. 프로덕션 코드 배포 사례부터, 실무자를 위한 실전 안내서, 그리고 40년 경력 베테랑 개발자의 2주 체험기까지, 바이브 코딩의 실무 사례! 구체적인 이야기들을 살펴볼게요.

우리가 클로드(Claude)로 코드를 배포하며 얻은 교훈들

실제로 Claude를 활용해 프로덕션 코드를 매일 배포하고 있는 팀의 이야기로, 단순한 마법이 아닌 의도적인 실천을 통해 AI의 강점을 극대화하고 약점을 보완하는 방법론을 다룹니다. CLAUDE.md 템플릿, 커밋 전략, 안전장치, 그리고 왜 테스트 코드를 직접 작성하는 일이 AI 시대에 오히려 더 중요해졌는지를 설명합니다. 바이브 코딩을 실무에 적용하려는 팀이라면, 반드시 참고할 만한 인프라 설계의 교훈이 담겨 있어요.

바이브 코딩을 시작하는 실무자를 위한 안내서

"AI 시대니까 배워야지"라는 막연한 이유로 시작하면 바이브 코딩은 의미가 없다는 메시지로 시작합니다. 이 글은 "지금 내 상황을 가장 빠르게 풀어내는 방법"을 찾는 실무자를 위한 4단계 안내서입니다. 자신의 동기를 파악하고, 바이브 코딩으로 풀 수 있는 문제와 아직 풀 수 없는 문제를 구분한 뒤, 상황에 맞는 도구를 고르는 과정을 안내합니다. 개발자에게는 기존 역량을 확장하는 도구로, 비개발자에게는 누구의 도움 없이 스스로 해결하는 도구로 바이브 코딩을 활용하는 법을 구체적으로 정리했습니다.

베테랑 개발자가 직접 경험한 바이브 코딩의 모든 것

40년 경력의 개발자가 2주 동안 40시간을 투자해 AI 코딩 어시스턴트와 실제 프로젝트를 진행한 체험기입니다. Claude Sonnet, Gemini Pro, OpenAI o3 등 최신 모델을 활용해 파이썬 프로젝트(약 5천 줄, 50개 파일)를 처음부터 끝까지 AI와 함께 개발했는데요. 직접 작성한 코드는 단 한 줄도 없었다는 점이 인상적이에요. 300회 이상의 대화를 나누며 발견한 AI의 장단점, 생산성 변화, 그리고 심리적 영향까지 세밀하게 분석했습니다. 경험 많은 개발자 관점에서 바이브 코딩의 현주소를 가장 솔직하게 보여주는 글이예요.

기획자, 안티그래비티(Antigravity) 이렇게 써봤습니다

개발자가 아닌 기획자가 직접 바이브 코딩에 뛰어든 사례입니다. 실무에서 기획서가 디자인 시안으로, 다시 코드로 변환되는 과정에서 의도가 100% 전달되기 어렵다는 문제의식에서 출발하죠. 구글의 안티그래비티(Antigravity)를 활용해 '인플루언서 검색 앱'을 직접 만들어본 경험을 공유하는데요. 기획자 관점에서 바이브 코딩 도구를 실제로 써보니 무엇이 가능했고, 어디서 막혔는지를 솔직하게 풀어냈어요. 커뮤니케이션 비용을 줄이고, 아이디어를 바로 현실화하는 수단으로서 바이브 코딩의 가능성을 기획자의 눈으로 확인할 수 있어요.

Chapter 3. 바이브 코딩이 남긴 새로운 질문

바이브 코딩이 확산되면서, 장밋빛 전망만큼이나 현실적인 문제들도 드러나기 시작했습니다. 코드 품질은 어떻게 관리하지? 비개발자가 혼자 다 할 수 있는 건 맞나? 개발자의 역할은 어떻게 달라지나? 이런 질문들에 대한 답은 무엇일까요?

개발자가 바이브 코딩 청소하며 느낀 것들

"바이브 코딩 청소"라는 새로운 개념을 다룬 글인데요. 바이브 코딩으로 만든 서비스의 코드를 개발자가 직접 정리해본 경험에서 출발합니다. 25개 프로젝트의 바이브 코딩 청소를 수행하며 발견한 문제는 분명했습니다. 프로젝트가 커질수록 하드코딩이 늘어나고, 코딩 컨벤션이 무너지며, AI가 문맥을 놓치기 시작했죠. 하지만 이 글의 핵심 메시지는 단순한 한탄이 아닙니다. 개발자의 역할이 기능 구현자에서 환경과 규칙을 설계하는 플랫폼 엔지니어로 이동하고 있다는 것, 그리고 아이디어를 먼저 구체화하고 확신이 생긴 뒤에 고도화하는 새로운 팀빌딩 방식이 등장하고 있다는 점을 짚어냈어요.

개발자가 비개발자의 바이브 코딩을 옆에서 보며 느낀 점

의대생과 인사팀 직원, 코드라곤 한 줄 써본 적 없는 두 사람의 바이브 코딩을 옆에서 도운 개발자의 이야기입니다. 이 글이 보여주는 현실은 꽤 구체적이에요. AI가 코드를 만들어줘도 VS Code 설치부터 막히고, JSON을 보고 당황하고, Node 설치에서 멈춥니다. 개발 환경 세팅, 데이터 구조 이해, 배포라는 세 가지 벽 앞에서 비개발자들이 어디서 막히는지를 생생하게 보여줘요. 동시에 그 벽을 넘었을 때 얼마나 빠르게 결과물이 나오는지도 확인하게 됩니다. 바이브 코딩의 가능성과 한계를 가장 현장감 있게 보여주고 있어요.

Chapter 4. 바이브 코딩 도구 추천 & 미래는?

마지막으로는 그래서 지금 어떤 도구를 쓰면 좋은지, 그리고 이 흐름이 어디로 향하고 있는지 살펴볼게요. 바이브 코더가 된 우리는 어디로, 어떻게 방향을 잡아야 할까요?

개발자를 위한 바이브 코딩 추천 툴 7가지

바이브 코딩이라는 개념은 널리 퍼졌지만, 어떤 도구를 골라야 할지는 여전히 막막한 분들을 위한 가이드입니다. 물론 꼭 개발자만 쓰라는 법은 없어요! Claude Code, Cursor를 대장 프로덕트로, Antigravity, Codex, Warp를 떠오르는 대안으로, CodeRabbit과 v0를 특화 도구로 분류해 정리했어요. IDE를 통째로 바꾸는 도구부터 터미널에서 대화하듯 쓰는 도구까지, 각각의 역할과 강점이 다르기에 자신의 개발 환경에 맞는 선택해 보세요.

한 달 만에 20만 다운로드, 전 세계 홀린 한국 개발자

6개월간의 독학 끝에 탄생한 오픈소스 AI 코딩 도구, '오 마이 오픈코드'의 개발자 인터뷰입니다. '시지프스'라 불리는 멀티 에이전트 시스템을 활용해 사람이 짠 것 같은 자연스러운 코드를 구현하는 이 도구는 출시 한 달 만에 전 세계에서 20만 다운로드를 기록했어요. 특히 한국 개발자가 글로벌 시장에서 바이브 코딩 도구로 주목받고 있다는 사실 자체가, 이 흐름의 크기와 가능성을 보여주고 있어요. 놀랍지 않나요?

OpenClaw 창시자, "나는 내가 읽지 않은 코드를 배포합니다."

GitHub 스타 10만 개, 출시 일주일 만에 방문자 200만 명을 기록하며 실리콘밸리의 맥미니를 품절시킨 오픈소스 AI 에이전트, OpenClaw. 그 창시자 피터 슈타인베르거의 이야기예요. 그는 자신이 읽지 않은 코드를 배포한다고 말해요. 주말 프로젝트로 시작한 WhatsApp 릴레이가 개인용 AI 비서를 거쳐 모델 애그노스틱 에이전트 인프라로 진화하는 과정은, 바이브 코딩이 단순한 코드 생성을 넘어 자율 에이전트의 영역으로 확장되고 있음을 보여주죠. AI에게 컴퓨터의 제어권을 넘기는 이 대담한 실험이 앞으로의 개발 패러다임을 어떻게 바꿀지, 그 가능성과 리스크를 함께 생각해 볼 수 있어요.

마치며

지난 3개월간 바이브 코딩의 흐름을 돌아보면, 크게 세 가지 변화가 눈에 들어와요.

첫째, 바이브 코딩은 더 이상 실험이 아니라 실무가 되었습니다. 프로덕션 코드를 AI로 배포하고, 그 과정의 교훈을 공유하는 팀들이 늘고 있어요.
둘째,'바이브 코딩 청소'처럼 새로운 역할과 개념이 생겨나고 있습니다. 개발자의 역할은 코드를 직접 치는 사람에서 AI가 잘 일할 수 있는 환경과 규칙을 설계하는 사람으로 이동하고 있죠.
셋째, 도구 생태계가 빠르게 성숙하고 있습니다. Claude Code, Cursor 같은 대장 도구 외에도 특화 도구들이 속속 등장하며, 한국 개발자가 만든 도구가 글로벌 시장에서 주목받는 일도 일어나고 있어요.

이렇게 변화의 속도가 빠른 만큼, 모든 것을 따라가려 하기보다는 "지금 내가 풀어야 할 문제"에 집중하는 것이 중요해 보여요. 오늘 소개한 글들이 그 출발점이 되길 바라며, 앞으로도 요즘IT에서 가장 생생한 ‘바이브 코딩’ 흐름을 전해드릴게요.

그럼 연휴 마지막 날까지 편안하게 보내시고, 새해 복 많이 받으세요!

]]>

개발자 6인, 비개발자 4인의 클로드 코드 실전 사례집

요즘 클로드 코드가 여기저기서 핫하게 떠오르고 있죠? 뭔가 이것저것 대단한 걸 할 수 있다는데요. 그런데 내 업무에는 어떻게 적용해야 하는 걸까요? 뭐부터 해야 하는 건지, 어떻게 해야 하는 건지 잘 모르겠습니다. 이것저것 테스트해보면 토큰은 순식간에 바닥나고, 어느 순간 그냥 내가 하는 게 낫겠다는 생각이 들죠.

요즘IT는 이런 고민에 답이 될 수 있는 이야기들을 모았습니다. 스타트업 기술이사, 풀스택 개발자, PM, 영상 제작사 기술이사, 출판 에디터까지. 클로드 코드를 실무에서 직접 쓰고 있는 개발자 6인과 비개발자 4인이 시행착오 끝에 정립한 실전 방법론을 한 권의 사례집으로 만들었습니다.

참고로 이들의 이야기는 완벽한 성공담보단 삽질하고, 실패하는 과정 속에서 배운점, 그렇게 자기만의 방식을 찾아간 과정에 가깝습니다. 사례집에 담긴 이야기 중 두 가지만 먼저 소개해 드리겠습니다.

사표를 던지고 싶었습니다 — 서비스 중단 위기를 3일 만에 돌파한 기록

콩콩프렌즈에서 백엔드를 담당하고 있는 김형중 님의 이야기입니다.

그는 원래 콩콩프렌즈의 프론트엔드 개발자였습니다. 그런데 사수이자 CTO였던 분이 개인 사정으로 퇴사하면서, 팀원 만장일치로 백엔드를 떠안게 되었죠. 그렇게 2년, 미숙하지만 어떻게든 살아남고 있던 어느 날 회사의 핵심 시스템이 의존하던 외부 실시간 투표 프로그램의 정책이 갑자기 바뀌었습니다. 임베딩이 제한되면서, 시스템이 통째로 먹통이 될 위기에 처한 겁니다.

하필 다음 주 주말에는 심포지엄 행사가 잡혀 있었는데요. 이 상황을 해결하지 못 하면 거래가 끊기고, 최악의 경우 손해배상까지 갈 수 있는 긴급한 상황이었죠. 해외 프로그램이라 문의를 넣어도 답이 언제 올지 알 수 없었고요. 주어진 시간은 딱 일주일. (이때 그는 정말 사표를 던지고 싶은 상황이었다고 합니다)

결국 그가 내린 결론은 차라리 새로 만들자는 거였습니다.

그렇게 그는 클로드 코드와 함께 사용자 시나리오 문서부터 작성하기 시작했습니다. 행사장에 몇 번 가본 경험이 있었기에, 참여자가 태블릿으로 투표하고 관리자가 투표를 생성·조작하는 흐름은 손에 익어 있었죠. 이 도메인 지식이 문서의 뼈대가 되었고, CLAUDE.md 파일로 프로젝트 맥락을 잡은 뒤 본격적인 개발에 들어갔습니다.

그런데 문서가 2,000줄을 넘기면서 문제가 생겼습니다. 클로드 코드가 문서를 읽는 데만 토큰을 잡아먹으니, 정작 코드 작성 속도는 눈에 띄게 느려진 겁니다. 이때 그가 찾은 해법이 꽤 인상적인데요. 너만 이해하면 돼, 라는 마인드로, 사람이 읽기 좋게 쓴 문서를 클로드가 읽기 좋은 형태로 다시 압축하기 시작한 겁니다. 이모티콘, 도표, 줄바꿈 같은 가독성 요소를 전부 걷어내고, AI가 파싱하기에 최적화된 구조로 재작성했습니다. 2,046줄이 359줄로 줄었고, 체감 속도는 확실히 빨라졌죠.

그리고 프론트엔드와 백엔드를 연결해야 하는 시점이 왔습니다. 모노레포이긴 했지만 코드가 분리되어 있어서, 한쪽 클로드 코드 세션에서 다른 쪽 코드를 직접 참조할 수가 없었거든요. 마음은 급한데 속도의 한계를 느끼던 그 순간, 김형중 님은 꽤 독특한 아이디어를 떠올립니다.

그래서 그는 이 위기를 결국 해결했을까요? 행사까지 남은 시간은 고작 3일. 그가 떠올린 아이디어가 뭐였는지, 정말 그걸로 행사를 무사히 치를 수 있었는지는 사례집에서 직접 확인해 보시죠.

사례집에서 확인할 수 있는 것들
2,046줄 → 359줄, 문서 압축 전후 실제 비교 이미지
압축하고 → 검수하고 → 수정하고 → 다시 압축하고... 반복 프로세스의 구체적 실행법
문서가 다시 커졌을 때 역할 기준으로 쪼개는 분할 전략
프론트 클로드와 백엔드 클로드가 서로 소통하게 만든 방법의 전체 과정
완성 후 팀원들과 진행한 테스트 현장, 그리고 회고에서 나온 배운 점들

8개월 100건, 2,400만원 — 비개발자가 외주 개발로 먹고사는 법

불혹의바이브코딩이라는 이름으로 활동하는 분의 이야기입니다. 설명을 조금 더 덧붙이자면 기계공학과를 졸업하고 건설회사에 다니고 있는, 개발 경험이 전혀 없었던 40대 직장인입니다.

그가 바이브 코딩을 시작한 건 순전히 호기심이었습니다. 바이브 코딩이 여기저기서 핫한 주제니까요. 그런데 곧 많은 비개발자가 겪는 패턴에 빠졌습니다. 처음엔 재미있었죠. 뭔가 만들어지는 게 신기하고, 이걸로 돈 벌어볼까 하는 기대감도 생깁니다. 그러다 벽을 만납니다. 프로그램이 갑자기 안 되고, 에러 메시지는 이해가 안 되고, 어렵게 만들어서 출시해봐도 아무도 사용해주지 않습니다. 결국 열정이 바닥나서 포기하게 되는 거죠.

그가 이 구간을 버틸 수 있었던 건, 외주 개발이라는 지속할 이유를 찾았기 때문이었습니다. 처음에는 자기 아이디어를 구현하는 재미로 시작하지만, 외주를 하면 다른 사람이 만들고 싶은 것을 대신 만들어주는 거라 아이디어가 고갈될 일이 없습니다. 게다가 돈이 되죠. 그는 이 마진이 가장 중요한 요소라고 말합니다. 직장인이 월급 몇십만 원 오르면 기분 좋듯이, 부업으로 5만 원, 10만 원이라도 벌면 그것만으로 다음 프로젝트를 할 힘이 생긴다는 거죠.

그의 외주 개발 전략은 명확했습니다. 메이저리그가 아니라 마이너리그에서 시작하는 것. 다양한 외주 플랫폼에서 자동화라는 자기 도메인 하나에만 집중했습니다. 건설회사에서 쌓은 업무 경험이 자동화 쪽 요구사항을 이해하는 데 자연스럽게 도움이 됐고요. 포트폴리오도 없이 상품 등록부터 시작했습니다. 단돈 만 원이라도 좋으니 한번 시작해 보자는 마음이었죠.

이후로는 프로젝트를 금액대별로 구분하면서 체계적으로 경험을 쌓아갔습니다. 5분이면 끝나는 단순 매크로(10만원 이하)부터, 웹 자동화나 OCR이 필요한 중간 난이도(10~50만원), 복잡한 솔루션(100만원 이상)까지.

그런데 비개발자가 100만원 이상의 금액대 개발 외주 작업을 정말 완료할 수 있었을까요? 그는 어떤 프로젝트들을 수행했고, 클로드 코드를 구체적으로 어떤 프로세스로 활용해서 비개발자로서의 한계를 넘었을까요? 8개월간 100건, 2,400만원이라는 숫자 뒤에 있는 현실적인 이야기는 사례집에서 확인해 보세요.

사례집에서 확인할 수 있는 것들
10만원 이하 / 10~50만원 / 100만원 이상, 금액대별 실제 프로젝트 사례와 난이도 비교
5분 만에 8만원을 번 매크로 프로젝트의 실제 내용
고객 요구사항이 횡설수설할 때, AI를 활용해 정리하는 구체적인 방법
코드를 모르는 사람이 결과물을 검증하는 3단계 프로세스
외주를 고를 때의 기준 — 돈이 되는 프로젝트와 스트레스만 남는 프로젝트를 가르는 것

이 두 이야기 외에도 8명의 실무자가 각자의 현장에서 부딪히고 배운 기록이 사례집에 담겨 있습니다.

어떤 내용들이 있는지 아래에서 소개해 드리겠습니다.

「클로드 코드로 일하기: 10인 실제 사례집」

요즘IT는 2025년 10월부터 12월까지, 총 3회에 걸쳐 온라인 웨비나 클코나잇을 진행했습니다. 개발 생산성 향상, AI 에이전트 오케스트레이션, 비개발자의 바이브 코딩까지. 매 회차마다 예상을 뛰어넘는 관심이 쏟아졌고, 발표 후 Q&A도 뜨거웠습니다. 이 사례집은 그 세 차례 발표의 기록입니다. 완벽하게 다듬어진 강의가 아니라, 현업에서 직접 부딪친 실무자들의 시행착오와 성공기를 가감 없이 담았습니다. 발표 후 쏟아진 Q&A도 함께 실어, 독자들이 가질 법한 질문에 미리 답하고자 했습니다.

- SDD로 AI가 80% 구현하게 만드는 구조_김효준 / 패러다임 시프트 기술이사
- 토큰 70% 절약하고 생산성 5배 올리는 MCP 세팅 가이드_승형수 / 개발자
- PM 혼자 63일, 2,900커밋으로 엔터프라이즈급 앱 만들기_이애본 / 한신대 AI SW 대학 겸임 교수

PART 2 실전 프로젝트 사례

- Plan 모드로 설계하고, Auto로 구현하기_조영록 / (주)대교 소프트웨어 엔지니어
- Tmux + LangGraph 멀티에이전트 오케스트레이션_노성현 / 와탭랩스 개발자
- 서비스 중단 위기, 3일 만에 막아낸 기록_김형중 / 콩콩프렌즈 개발자

PART 3 비개발자의 클로드 코드 활용법

- 비개발자의 외주 개발: 8개월 100건, 2,400만원_불혹의바이브코딩 / 종합 건설회사 근무
- 영상 제작사 기술이사의 바이브 코딩 6계명_우탄 / 영상제작사 '한줄' 기술이사
- 문과생 PM의 6,000라인 돌파기_정덕범 / 라인 플래닛 프로덕트 매니저
- 출판 에디터의 AI 실험실: 바이브 코딩 생존법_차진우 / 도서 기획·편집자

부록 — 바로 써먹을 수 있는 것들

CLAUDE.md 템플릿 가이드
MCP 추천 리스트 정리표
클로드 코드 요금제 비교 (2026.02 기준)
Claude Skills 활용법

167 페이지에 담긴 10명의 고군분투가 궁금하시다면, 사례집에서 직접 확인해 보세요.

클로드 코드로 일하기: 10인 실제 사례집 보러 가기

]]>

닌텐도 못 하게 했더니 직접 게임 만든 10살 아들(개발자 아빠의 관찰기)

[바이브코더스] 클로드 코드로 게임 만든 어린 바이브 코더의 개발자 아빠, 서인근 님 인터뷰

최근 LinkedIn에서 가장 화제가 된 바이브 코더의 이야기 중 하나는 바로 ‘10살 막내가 Claude Code로 만든 게임, 혼자 보기 아까워서 공개합니다’라는 포스트일 겁니다. 한 달도 안 되는 기간 동안 약 천백 개의 ‘좋아요’를 기록했는데요.

이제 바이브 코딩이 세대를 넘어 어린 친구들에게까지 전파되어 사용되고 있다는 것이 놀랍기만 합니다. AI 네이티브 세대의 첫 번째 개발 경험을 곁에서 지켜보며 얻은 인사이트를 들어보고 싶어, 게임을 만든 개발자의 아버지인 서인근 님을 만나봤습니다.

서인근 님 <출처: 서인근 LinkedIn>

Part 1. AI 네이티브 세대의 바이브 코딩을 지켜보며

Q. 간단한 자기소개 부탁드립니다. 현재 어떤 일을 하고 계신가요?

안녕하세요. 저는 서인근이라고 합니다. 현재 ‘마음 AI’라는 회사에서 자율주행 사업을 총괄하는 역할을 맡고 있고, 아이 셋을 키우고 있는 아버지입니다. 요즘은 최신 기술을 계속 따라잡기 위해서 열심히 공부하고 있는데요. 배운 내용들을 소셜 미디어에 꾸준히 공유하며 AI 지식을 전파하고 있습니다.

Q. 아이가 만든 클로드 코드 게임에 관한 LinkedIn 포스트가 화제가 됐어요, 반응을 보셨을 때 기분이 어떠셨나요?

서인근 님 링크드인 포스트 <출처: 서인근 LinkedIn>

사실 제가 큰 호응을 얻기 위해 의도해서 각 잡고 올렸다기보다는 그냥 아이가 만든 게임을 혼자서 알고 있기가 아까워서 LinkedIn에 사람들에게 공유할 생각으로 포스팅했어요. 그런데 제 생각과는 다르게 반응이 너무 좋아서 저도 많이 신기합니다. 게임을 만든 제 막내 아이도 너무 재미있어하고, 스스로 엄청 자랑스러워하고 있습니다. 막내 아이가 링크드인에서 바이럴이 되는 걸 알게 된 후로, 계속 사이트에 들어가서 몇 명이 봤는지 확인하고 있어요.

Part 2. ‘모여라 동물의 숲 웹’ 게임 탄생 배경

Q. 잘 모르시는 분들을 위해, 아이가 만든 게임이 어떤 건지 간단히 소개해 주세요.

간단히 설명해 드리면, 비디오 게임을 좋아하시는 분들이면 대부분 알고 계실 “모여봐요 동물의 숲”의 웹 버전이라고 생각하시면 됩니다. 처음에는 최대한 비슷하게 만들려고 했는데요. 아이의 아이디어가 이것저것 들어가면서 지금은 무엇인지 모르는 게임이 되어 가고 있어요.

Q. 아이와 함께 게임을 만들어야겠다고 결심한 계기가 있었나요? 어떻게 시작하게 되었나요?

제 막내 아이가 작년부터 동물의 숲을 엄청나게 하고 싶어 했었어요. 그래서 크리스마스 선물로 닌텐도 스위치 게임기로 할 수 있게 사줬는데요. 저희가 아이들의 게임 시간을 제한하고 있기 때문에, 주말에만 할 수 있어서 게임을 오래 할 수 있는 아이디어를 고민한 것 같아요. 코딩을 할 때는 평일에도 할 수 있으니까, 동물의 숲을 하려면 게임을 코딩하는 방법이 있겠구나 하는 방법을 생각해 낸 거죠. 그래서 어느 날 동물의 숲을 웹 버전으로 만들어 보고 싶다고 이야기하더라고요.

첫 시작은 작년 여름쯤이었어요. 제가 이전부터 바이브 코딩을 하고 있었는데요. 구글 AI 스튜디오의 빌드 메뉴를 보면 엄청 쉽게 웹을 만들 수 있는 메뉴가 있었거든요. 그래서 아이와 함께 구글 AI 스튜디오로 게임 개발을 시작해 보면 어떨까 해서 같이 시작하게 됐습니다.

Q. 아이의 첫 바이브 코딩을 위해 구글 AI 스튜디오를 선택했는데 어떻게 사용했었나요?

처음에는 음성으로 코딩을 시작했어요. 그리고 구글 AI 스튜디오로 테트리스 같은 게임을 만들었고요. 구글 AI 스튜디오로 만들기가 정말 쉬웠어요. 테트리스 게임 이후에는 슈팅 게임을 만들고 육성 게임 같은 것도 아이가 창의적으로 잘 만들더라고요. 그래서 그런 걸 쌓아 놓은 게 지금 100개 정도 되는 것 같아요.

그 이후에는 제가 아이가 만들어 놓은 게임들을 보고 “기존에 만들어 놓은 게임들에서 조금 더 고도화된 걸 만들 수 있지 않을까?”라고 생각해서, 구글 AI 스튜디오에서 점점 클로드 코드를 사용할 수 있도록 유도했습니다.

Part 3. ‘Claude Code’로의 전환

Q. 원래 구글 AI 스튜디오를 쓰던 아이를 '집요한 설득 끝에 클로드 코드로 데려왔다'고 하셨는데, 왜 집요한 설득이 필요했나요?

사실 구글 AI 스튜디오가 정말 편했어요. 이게 말만 하면 진짜 다 만들어주는 거라서 웹에서 만들어서 배포하는 것까지 전혀 고민할 필요가 없었어요. 그런데 제가 클로드 코드로 하면 뭔가 더 다른 가능성을 볼 수 있겠다는 생각도 들었거든요. 또 멋진 플레이를 할 수 있겠다는 걸 좀 가르쳐 주고 싶어서, 클로드 코드를 사용해 보는 것을 제안했죠. 동물의 숲이 원래 좀 자유도가 높은 게임이라서 게임 속에서 움직이고 집을 짓는 것뿐 아니라, 여기서 만들어 보고 싶은 다양한 아이디어들을 클로드 코드를 사용해서 모두 구현해 볼 수 있도록 유도했어요.

Q. 아이에게 클로드 코드의 어떤 점을 강조해서 설득하셨나요?

클로드 코드를 사용하게 하려고 기존에 사용하던 AI 스튜디오를 같이 띄어 놓고 똑같은 명령어를 주고 나오는 결과를 보게 했어요. “동물의 숲을 만들고 싶다.” “웹 버전으로 만들고 싶다.” 정도의 두 개의 프롬프트를 동시에 돌려서 결과물을 비교해서 보여줬는데요. 제가 의도한 것과 같이 클로드 코드가 훨씬 더 잘하더라고요. 사실은 아이의 마음을 바꾸기 위해서 클로드 코드의 가장 좋은 모델을 썼습니다. 그래서 결과물이 좋게 나왔고, 이렇게 결과를 통해서 클로드로의 전환을 전략적으로 유도했죠.

Q. 아이가 클로드로 넘어가며 툴이 바뀌어 불편해하는 것은 없었나요? 그리고 AI 스튜디오를 쓸 때와 어떻게 달랐나요?

클로드로 넘어가면서 특별히 어려워하는 건 없었던 것 같아요. 사용하는 패턴이 조금 바뀌기는 했지만, 더 편하게 사용하는 것 같았어요. 재미있었던 거는 제가 가끔 아이가 클로드와 나누는 대화를 몰래 보곤 하는데요. 약간 무서울 정도로 가까운 친구가 되어 있더라고요. 저는 클로드 지시 사항에 절대 존댓말로 하라고 적어 놓거든요. 그런데 아이는 반말로 하라고 먼저 지시하더라고요.

그리고 저희가 게임을 만들고 나서 테스트를 한 걸 캡처해서 다시 이 클로드 코드에 넣으면서 결과를 보여줘요. 그러면 클로드 코드가 응원해 줍니다. “이번엔 잘했네, 다음엔 더 잘할 수 있을 것 같아” 이러면서 둘이 친구가 된 모습이 재미있으면서도 약간 소름이 돋기도 했죠.

Part 4. 게임 개발 과정을 돌아보며

Q. 아이와 함께 어떤 과정을 거쳐 게임을 만들었나요? 역할 분담이 있었나요?

사실 역할 분담 같은 건 없었어요. 대부분의 역할은 아이가 진행하고 저는 이제 소셜 로그인 관련된 부분과 DB를 붙이는 것, 그리고 배포 관련된 부분만 도와줬어요. 저도 게임을 개발하는 과정 중에 아이한테 좀 많이 놀랐고 배우게 된 것은 아이가 개발에 대한 정의가 없다 보니, 더 많은 상상력과 창의력으로 막힘없이 요청하더라고요.

사실 아이가 게임해 본 경험만 있지, 게임 개발에 대해서 아는 게 뭐가 있겠어요. 생각하는 기능들을 어떻게 구현해야겠다고 생각하지는 못하잖아요. 그래서 정말 거침이 없어요. 기능적으로 구현이 될지 안 될지를 생각하지 않고 그냥 요청해요. 그러면 신기하게도 대부분 구현됩니다. 실은 요즘 이게 트렌드 아닌가 하는 생각이 들어요.

모여라 동물의 숲 웹 버전 <출처: 서인근 님>

Q. 실행 과정에서 어떤 어려움이 있었고, 어떻게 해결했나요?

사실 어려웠던 건 없었지만 까다로웠던 건 바로 배포였어요. 아이가 게임을 어떻게 웹 페이지에 올리는지, 다른 사람이 들어와서 같이 게임을 하면 좋겠어! 이런 이야기를 했어요. 그 부분에 대해서 어떻게 할지 고민하면서 클로드 코드로 완벽하게 유인할 수 있었죠. 이런 기능을 구현하기 위해서는 이제 소셜 로그인이 필요했고, DB와 배포도 필요해서 이런 것들을 도와주면서 같이 해결했습니다. 지금은 제가 슬며시 MCP를 설치해놔서 아이가 배포까지는 할 수 있는 상태예요. 가끔 DB를 건드리기도 하고요.

Q. 아이가 직접 구현한 로직 중에서 가장 놀라웠던 건 뭐였나요?

제가 가장 깜짝 놀랐던 부분이 구글 AI 스튜디오로 게임 개발을 시작하고 얼마 되지 않았는데, 아이가 멀티 플레이를 하게 해달라고 요청하더라고요. 사실은 옆에서 그게 되겠냐고 생각하며 조금 비웃었어요. 그런데 시간이 지나서 다시 확인해 보니까 웹페이지를 두 개 띄워놓고 형이랑 둘이 2인 플레이를 하고 있는 거예요. 그게 될 거라고 생각 못 했는데, 웹페이지 하나를 호스트로 두고 다른 웹페이지가 그거에 접속해서 멀티 플레이를 하더라고요.

구글 AI 스튜디오가 어떻게든 방법을 찾아서 구현해 내는 걸 보면서, 처음엔 ‘내가 계획을 세우고 그 계획에 맞춰 개발을 해야지’라고 생각했어요. 그런데 그렇게 하면 결국 제가 알고 있는 수준에서만 끝나게 되더라고요. 반면, 어떤 제한도 두지 않고 그냥 밀어붙이면 AI가 어떻게든 방법을 찾아오는 걸 보면서 생각이 바뀌었죠. ‘이건 그냥 아이가 다 할 수 있게 열어두고, 나는 뒤에서 서포트만 해주면 되겠다’는 생각이 들었어요.

다시 한번 말하지만, 요즘 트렌드가 진짜 그런 것 같아요. 제 아이뿐만 아니라 다른 비개발자분들이 바이브 코딩으로 치고 나가는 걸 보면, 오히려 제가 뭔가 제한을 걸고 있었던 건 아닐까? 너무 딱딱하게 생각하고 있었던 건 아닐까 싶어서 스스로 좀 반성하게 됐습니다.

Q. 개발 기간은 얼마나 걸렸나요?

동물의 숲을 만들 때는 그게 주말 이틀 정도 들었던 것 같아요. 어떨 때는 밤늦게까지 하기는 했는데 하루에 한 6시간 정도 했던 것 같아요. 오래 걸리지 않았습니다.

Part 5. 부모로서의 관찰

Q. 막내 아이의 바이브 코딩에 대해서 어떻게 생각하세요? 앞으로 어떻게 활동을 도울 생각이신가요?

아이를 지금 3명 키우고 있는 상태에서 아이를 키울 때 보면, 첫째 아이는 정말 내가 얘를 어떻게 키우는 게 맞지? 그리고 내가 부모로서 어떤 걸 가르쳐주는 게 맞지? 하면서 주변을 보고 따라 할 수밖에 없거든요. 그래서 첫째는 되게 정석적으로 큰 것 같아요. 그런데 이제 둘째, 셋째로 가면서 점점 이렇게 자유도를 높여 줄 수 있는 것 같아요. “이런 건 굳이 필요하지 않은 것 같은데”, “이런 건 좀 더 시도해 볼까?” 생각하면서 아이에게 좀 더 자유도를 주는 거죠. 그래서 저는 앞으로도 아이의 바이브 코딩을 지원하고 싶어요.

사실 아내는 아이가 바이브 코딩에 너무 많은 시간을 쓰는 걸 걱정해서 시간을 좀 제한하려고 하고 있어요. 그래서 제가 어떻게 설득할 수 있을까 고민 중이죠. 오늘 아내가 이 인터뷰를 의식해서 그런 건지는 모르겠지만, 책을 읽는 걸 장려하는 입장에서 책을 먼저 읽고, 그 스토리를 바탕으로 게임을 만들면 괜찮다고 허락해주겠다고 하더라고요.

게임을 만든 주인공 막내아들과 서인근 님 <출처: 화상 인터뷰 화면>

Q. AI 도구가 급격히 발전하는 시대인데요, 자녀 세대에게 코딩 교육은 어떤 방향으로 달라져야 할까요?

막내의 경우, AI 시대에 그냥 AI 공부를 좀 더 하는 게 좋을지, 아니면 학교 커리큘럼을 쫓아가는 게 좋을지 다른 부모들과도 많은 얘기를 하며 고민하고 있어요. 사실 어떤 것이 답인지 명확히 정하기가 어려운 상황이죠. 제가 경험해 본 결과, 앞으로는 모두가 AI와 함께하는 세상이 될 거고 AI를 어떻게 활용하느냐에 따라 그 결과가 달라질 수 있을 것 같아요.

그래서 앞으로는 AI가 하지 못하는 것은 무엇이냐고 생각했을 때 결국은 판을 짜내는 능력이나, 그리고 시스템을 설계하는 능력 이런 걸 어떻게 하면 가르쳐줄 수 있을까 생각하기도 했는데요. 다시 생각해 보면 앞서 말씀드린 것처럼 그냥 “네가 하고 싶은 대로 해라”라고 던져주는 게 가장 낫지 않을까 생각합니다. 어떻게 생각하면 조금 내려놓는다는 표현도 맞겠네요.

Q) 아이가 다음에 만들고 싶어 하는 게 있나요? 게임을 만든 것에 대해 어떻게 생각하나요?

아이가 만든 동물의 숲은 지금 점점 커져서 섬이 4개가 됐어요. 최근에는 거대한 게임은 아니지만 리듬 게임을 하나 만들었는데, 이걸 또 저한테 홍보해달라고 하더라고요. 또 게임 안에 채팅창 기능도 넣었는데, 거기 들어오셔서 가끔씩 응원을 남겨주시는 분들이 있어요. 우리 아이가 그걸 보면서 직접 답변을 하면서, 되게 신기해하고 엄청 자랑스러워하죠.

Part 6. 개발자 부모의 시선과 비개발자 부모를 위한 조언

Q. 개발자 관점에서 봤을 때, 아이가 AI와 소통하는 방식에서 배울 점이 있었나요?

저도 정말 아이한테서 크게 배우고 있어요. 왜냐하면 그렇게 해도 퀄리티 높은 결과물이 나오니까요. 저는 프롬프트 탭에서 맥락을 중요하게 보고, 설계를 잘해서 원하는 결과물을 뽑아내려고 계속 시도하고 있어요. 그런데 아이는 그런 작업을 전혀 하지 않는데도 저렇게 뽑아내는 걸 보면서 ‘내가 뭔가 잘못하고 있는 건가?’ 하는 생각이 들기도 하더라고요.

또 아이가 게임을 만들면서 ‘아이템 창조’라는 신기한 기능을 구현했는데, 이게 원작 게임에는 전혀 없는 기능이거든요. 그런데 아이가 그걸 스스로 생각해서 만들었고, 저는 이게 구현이 될 거라고는 전혀 생각 못 했는데, 그걸 또 밀어붙이더라고요. 결국엔 어떻게 구현됐는지는 저도 모르겠는데, 어쨌든 그걸 가지고 치트키처럼 만들어서 사용하더라고요.

Q. 개발을 잘 모르는 부모들도 아이의 AI 활용을 도울 수 있을까요? 어떻게 시작하면 좋을지, 현실적인 조언을 해주신다면요?

요즘 비개발자분들도 AI 관련 소식을 계속 접하다 보니까, FOMO(Fear of Missing Out)를 느끼실 것 같아요. 저도 사실 개발자 입장에서 정말 뒤처지는 것에 대한 스트레스를 받고 있거든요. 그런데 비개발자분들도 이걸 조금만 알게 되면 아마 정말 부담스러울 수도 있겠다 싶어요. 그렇지만 너무 힘들어하지 마시고, 그냥 한 번쯤은 직접 경험해 보시라고 꼭 말씀드리고 싶어요. 확실히 해보면 또 다르게 느껴질 수 있거든요.

요즘에 저는 오늘 계속 말씀드렸던 구글 AI 스튜디오 정도는 정말 그냥 재미로도 만들 수 있는 그런 도구가 됐다고 생각해요. 그래서 아이랑 한 번쯤 이런 걸 같이 만들어보는 경험, 꼭 게임이 아니어도 아이가 할 수 있는 게 뭔지를 함께 찾아보는 것도 참 좋을 것 같아요. 요즘에는 유튜브 같은 데서 이런 걸 소개하는 채널도 정말 많아서, 정보도 쉽게 얻을 수 있고요. 사실 레고 만들기처럼 뭔가 같이 하는 활동은 시간이 오래 걸리잖아요. 그런데 게임을 함께 만들다 보면 오히려 더 긴밀하게 이야기도 나누고, 자연스럽게 소통할 수 있을 것 같아요.

마치며

오늘 서인근 님과 10살 아이가 바이브 코딩으로 웹게임을 만든 이야기를 들으며, AI 네이티브 시대의 시작에 대해 많은 인사이트를 얻은 의미 있는 시간이었는데요. 마지막으로 서인근 님이 요즘IT 독자분들께 전하고 싶은 메시지를 남겨주셔서, 이를 전하며 마무리하겠습니다.

“AI 버블이 올라가고 있는 지금 이 시점에, AI 기술의 최전선에 있는 IT 종사자분들은 가족, 아이들이 함께 기술을 활용할 수 있도록 도와줄 수 있는 가장 유리한 위치에 있는 것 같아요. 이 기회를 잘 살려서, 가족과 나눌 수 있는 자신만의 방식이나 아이디어를 만들어보고, 함께 공유하고 실천해 보신다면 정말 큰 도움이 되지 않을까 싶습니다.”

내 주변에 가장 가까운 사람들과 AI 기술을 함께 경험해보는 것, 지금이야말로 그 첫걸음을 시작하기에 가장 좋은 순간이 아닐까요?

➡️ 영상으로 보기

]]>

[릴리즈 노트] Opus 4.6에 대한 오픈AI의 대답, GPT-5.3-Codex

※ 본문은 OpenAI의 <Introducing GPT-5.3-Codex>를 신속하게 전달하기 위해 AI 번역 및 요약을 사용했습니다. 요즘IT 실무자에게 필요한 정보 전달을 위해 내용을 일부 생략하고 배치를 조정했습니다. GPT-5.2를 활용해 번역 및 요약했습니다.

[GPT-5.3-Codex 요약]

핵심
GPT-5.3-Codex는 GPT-5.2-Codex의 코딩 성능과 GPT-5.2의 추론·전문 지식을 결합한 모델
속도는 이전 대비 25% 향상됐으며, 조사·도구 사용·실행이 섞인 장시간 작업을 수행할 수 있음
작업 중 사용자와 상호작용해도 문맥을 유지하는 자율 에이전트로 설계

코딩 성능
실제 소프트웨어 공학 능력을 평가하는 SWE-Bench Pro에서 최상위 성능을 달성
Terminal-Bench 2.0에서도 이전 최고 성능을 넘었으며, 더 적은 토큰으로 결과를 냈다고 설명

웹 개발 능력
코딩 능력과 문맥 압축 기능을 바탕으로 며칠에 걸쳐 복잡한 게임과 앱을 자율적으로 제작할 수 있음
수백만 토큰 규모 작업에서도 반복 개선을 수행
간단한 지시만으로도 더 합리적인 기본 설정과 완성도를 갖춘 웹사이트를 생성

역할 확장
기존의 코드 작성·검토 중심 에이전트에서, 컴퓨터 기반 전문 업무 전반을 처리하는 에이전트로 확장
오류 수정, 배포, 모니터링, PRD 작성, 문구 편집, 사용자 조사, 테스트, 지표 분석 등 개발 전 과정을 지원
발표 자료 제작, 표 계산 문서 분석 등 지식 노동 업무도 처리

협업 중심 상호작용
작업 중 주요 결정과 진행 상황을 수시로 공유
사용자는 진행 중에도 질문, 논의, 방향 수정이 가능
에이전트가 무엇을 하는지 설명하며 협업 형태로 작업

사이버 보안 능력과 보호 장치
준비성 체계 기준에서 사이버 보안 과제 ‘높은 수준’ 능력으로 분류된 첫 모델
취약점 식별을 직접 학습한 첫 모델
기존 100만 달러 보조금에 이어 API 크레딧 1,000만 달러를 추가 지원할 예정

이용 가능 환경
유료 챗지피티 요금제에서 사용 가능하며, 앱·명령줄·개발 도구·웹 환경에서 제공
인프라 개선으로 모델 제공 속도가 25% 향상

컴퓨터에서 이뤄지는 전문 업무 전반으로 Codex의 범위를 확장합니다.

우리는 Codex의 가능성을 한층 더 넓혀 줄 새로운 모델 GPT-5.3-Codex를 소개합니다. 이는 지금까지 나온 것중 가장 뛰어난 자율 코딩 모델입니다. 이 모델은 GPT-5.2-Codex의 최전선 코딩 성능과 GPT-5.2의 추론 및 전문 지식 역량을 하나로 결합했으며, 속도도 25% 더 빨라졌습니다. 그 결과, 조사, 도구 사용, 복잡한 실행이 함께 필요한 장시간 작업도 수행할 수 있습니다. 동료와 함께 일하듯, GPT-5.3-Codex가 작업하는 동안 사용자가 방향을 제시하고 상호작용해도 문맥을 잃지 않습니다.

GPT-5.3-Codex는 스스로를 만드는 데 중요한 역할을 한 첫 모델이기도 합니다. Codex 팀은 초기 버전을 활용해 모델의 학습 과정을 디버깅하고, 배포를 관리하며, 시험 결과와 평가를 분석했습니다. 그 결과, Codex가 스스로의 개발 속도를 크게 끌어올리는 모습을 보고 팀 전체가 놀랐습니다.

GPT-5.3-Codex를 통해 Codex는 단순히 코드를 작성하고 검토하는 에이전트에서, 개발자와 전문 직무 종사자가 컴퓨터에서 수행하는 거의 모든 작업을 처리할 수 있는 에이전트로 확장됩니다.

최전선 자율 에이전트 역량

GPT-5.3-Codex는 코딩, 자율 작업, 실제 업무 능력을 측정하는 네 가지 벤치마크인 SWE-Bench Pro, Terminal-Bench, OSWorld, GDPval에서 새로운 업계 최고 성능을 기록했습니다.

코딩 성능

GPT-5.3-Codex는 실제 소프트웨어 공학 능력을 엄격하게 평가하는 SWE-Bench Pro에서 최상위 성능을 달성했습니다. 기존의 SWE-bench Verified가 파이썬만을 시험하는 것과 달리, SWE-Bench Pro는 네 가지 언어를 다루며, 데이터 오염에 강하고 더 도전적이며, 다양한 실제 산업 상황을 반영합니다.

또한 코딩 에이전트가 필요로 하는 터미널 작업 능력을 측정하는 Terminal-Bench 2.0에서도 이전 최고 성능을 크게 넘어섰습니다. 특히 GPT-5.3-Codex는 이전 어떤 모델보다도 적은 토큰을 사용해 이 성능을 달성해, 사용자가 더 많은 작업을 수행할 수 있도록 했습니다.

웹 개발 능력

최전선 수준의 코딩 능력, 향상된 미적 완성도, 그리고 문맥 압축 기능이 결합되면서, 이 모델은 며칠에 걸쳐 완성도 높은 복잡한 게임과 응용 프로그램을 처음부터 구축할 수 있습니다.

모델의 웹 개발 능력과 장시간 자율 작업 능력을 시험하기 위해, 우리는 GPT-5.3-Codex에게 두 가지 게임 제작을 맡겼습니다. 하나는 Codex 앱 출시 때 선보였던 레이싱 게임의 두 번째 버전이고, 다른 하나는 잠수 게임입니다.

“웹 게임 개발” 기술과 “버그를 고쳐라”, “게임을 개선하라” 같은 일반적인 후속 지시를 사용해, GPT-5.3-Codex는 수백만 토큰에 걸쳐 자율적으로 게임을 반복 개선했습니다.

GPT-5.3-Codex는 일상적인 웹사이트 제작을 요청할 때도, GPT-5.2-Codex보다 사용자의 의도를 더 잘 이해합니다. 이제는 단순하거나 구체적이지 않은 지시를 주더라도, 기본적으로 기능이 더 풍부하고 합리적인 기본 설정을 갖춘 사이트를 만들어 주어, 아이디어를 발전시킬 수 있는 더 탄탄한 출발점을 제공합니다.

예를 들어, 우리는 GPT-5.3-Codex와 GPT-5.2-Codex에게 아래의 두 랜딩 페이지를 만들어 달라고 요청했습니다. GPT-5.3-Codex는 연간 요금제를 단순히 연간 총액으로 계산해 보여주는 대신, 할인된 월 요금 형태로 자동 표시해 할인 혜택이 더 명확하고 의도적으로 보이도록 했습니다. 또한 사용자 후기 영역도 하나의 문장만 넣는 대신, 서로 다른 세 개의 사용자 인용문이 자동으로 전환되는 회전형 구성으로 만들어, 기본 상태에서도 더 완성도 높고 실제 서비스에 바로 사용할 수 있는 페이지처럼 느껴지도록 했습니다.

코딩을 넘어

소프트웨어 엔지니어, 디자이너, 프로덕트 매니저, 데이터 과학자는 단순히 코드를 작성하는 일만 하지 않습니다. GPT-5.3-Codex는 소프트웨어 생애 주기 전반의 업무를 지원하도록 설계되었습니다. 오류 수정, 배포, 모니터링, 제품 요구 문서(PRD) 작성, 문구 편집, 사용자 조사, 테스트, 지표 분석 등 다양한 작업을 처리할 수 있습니다. 또한 이 모델의 자율 에이전트 기능은 소프트웨어 영역을 넘어, 발표 자료를 만들거나 표 계산 문서에서 데이터를 분석하는 등 원하는 어떤 작업이든 수행할 수 있도록 돕습니다.

이전 GDPval 결과에 사용했던 것과 유사한 맞춤 기술을 적용한 평가에서도, GPT-5.3-Codex는 전문 지식 노동 영역에서 강력한 성능을 보였습니다. GDPval 평가 기준에서 GPT-5.2와 동등한 수준을 기록했습니다. GDPval은 OpenAI가 2025년에 공개한 평가로, 44개 직군에 걸친 명확히 정의된 지식 노동 과제에서 모델의 수행 능력을 측정합니다. 여기에는 발표 자료 제작, 표 계산 문서 작성 등 다양한 업무 산출물을 만드는 작업이 포함됩니다.

코딩, 프론트엔드, 컴퓨터 사용, 실제 업무 과제 전반에서 나타난 이러한 결과는 GPT-5.3-Codex가 단순히 개별 작업을 더 잘 수행하는 수준을 넘어, 실제 기술 업무 전반에서 추론하고, 만들고, 실행할 수 있는 하나의 범용 에이전트로 나아가는 중요한 전환점임을 보여줍니다.

상호작용하는 협업자

모델의 능력이 강해질수록, 에이전트가 무엇을 할 수 있는지보다 사람이 여러 에이전트를 동시에 얼마나 쉽게 상호작용하고, 지시하고, 감독할 수 있는지가 더 중요한 문제가 됩니다. Codex 앱은 에이전트를 관리하고 지시하는 일을 훨씬 쉽게 만들어 주며, GPT-5.3-Codex에서는 상호작용성이 더욱 강화되었습니다.

새 모델에서는 Codex가 작업 중 중요한 결정과 진행 상황을 자주 알려주기 때문에, 사용자는 전체 흐름을 계속 파악할 수 있습니다. 최종 결과만 기다리는 대신, 작업이 진행되는 동안 실시간으로 상호작용할 수 있습니다. 질문을 던지고, 접근 방식을 논의하며, 해결 방향을 직접 조정할 수 있습니다. GPT-5.3-Codex는 자신이 무엇을 하고 있는지 설명하고, 피드백에 반응하며, 시작부터 끝까지 사용자를 작업 흐름 안에 포함시킵니다.

Codex로 GPT-5.3-Codex를 학습하고 배포한 과정

최근 Codex의 빠른 발전은 OpenAI 전반에서 수개월, 혹은 수년에 걸쳐 진행된 여러 연구 프로젝트의 성과를 바탕으로 이루어졌습니다. 이러한 연구는 Codex 덕분에 더욱 가속되고 있으며, 많은 연구자와 엔지니어는 지금의 업무 방식이 불과 두 달 전과도 근본적으로 달라졌다고 말합니다. GPT-5.3-Codex의 초기 버전들조차 뛰어난 성능을 보여, 팀은 그 초기 모델들을 활용해 학습 과정을 개선하고 이후 버전의 배포를 지원할 수 있었습니다.

Codex는 매우 폭넓은 작업에 활용될 수 있어, 팀에 어떤 방식으로 도움이 되는지 모두 나열하기는 어렵습니다. 예를 들어 연구팀은 이번 버전의 학습 과정을 모니터링하고 오류를 찾아내는 데 Codex를 사용했습니다. 단순한 기반 시설 문제 해결을 넘어, 학습 과정 전반의 패턴을 추적하고, 상호작용 품질을 깊이 분석하며, 문제 해결 방안을 제안하고, 연구자가 모델의 행동 변화를 정확히 이해할 수 있도록 풍부한 응용 도구를 만들어 주었습니다.

엔지니어링 팀은 GPT-5.3-Codex용 실행 환경을 최적화하고 조정하는 데 Codex를 활용했습니다. 사용자에게 영향을 주는 이상한 경계 상황이 발견되자, 팀원들은 Codex로 문맥 표시 오류를 찾아내고, 캐시 적중률이 낮은 원인을 분석했습니다. 출시 과정에서도 GPT-5.3-Codex는 GPU 클러스터를 동적으로 확장해 트래픽 급증에 대응하고 지연 시간을 안정적으로 유지하는 데 도움을 주고 있습니다.

알파 시험 기간 중, 한 연구자는 GPT-5.3-Codex가 한 번의 상호작용에서 얼마나 더 많은 작업을 처리하는지, 그리고 그에 따른 생산성 차이를 알고 싶어 했습니다. GPT-5.3-Codex는 정규식 기반 분류기를 여러 개 제안해, 추가 설명 요청 빈도, 사용자 긍정·부정 반응, 작업 진행 상황 등을 추정하도록 했습니다. 그리고 이를 모든 세션 기록에 확장 적용해 분석 보고서를 작성했습니다. 그 결과, Codex를 사용하는 사람들은 에이전트가 의도를 더 잘 이해하고, 추가 설명 질문은 줄이면서 한 번의 상호작용에서 더 많은 진전을 이루는 모습을 보였습니다.

GPT-5.3-Codex는 이전 모델과 상당히 다른 특성을 보여, 알파 시험 데이터에서도 여러 비직관적이고 예상 밖의 결과가 나타났습니다. 팀의 데이터 과학자는 GPT-5.3-Codex와 협업해 새로운 데이터 처리 흐름을 만들고, 기존 대시보드보다 훨씬 풍부한 시각화 결과를 만들었습니다. 이후 Codex와 함께 분석을 진행했고, 수천 개의 데이터 지점에서 핵심 통찰을 3분도 채 되지 않아 간결하게 정리해 냈습니다.

이러한 개별 사례들은 연구자와 제품 개발자에게 Codex가 어떤 도움을 줄 수 있는지 보여주는 흥미로운 예시입니다. 이를 종합하면, 이러한 새로운 능력들이 연구, 엔지니어링, 제품 팀 전반의 작업 속도를 크게 끌어올렸다는 점을 확인할 수 있었습니다.

사이버 보안 전선 강화

최근 몇 달 동안, 모델의 사이버 보안 과제 수행 능력이 눈에 띄게 향상되었으며, 이는 개발자와 보안 전문가 모두에게 도움이 되고 있습니다. 동시에 방어적 활용과 생태계 전반의 회복력을 높이기 위해 강화된 사이버 보호 장치를 준비해 왔습니다.

GPT-5.3-Codex는 준비성 체계(Preparedness Framework)에 따라 사이버 보안 관련 과제에서 ‘높은 수준’ 능력으로 분류된 첫 모델이며, 소프트웨어 취약점을 식별하도록 직접 학습시킨 첫 모델이기도 합니다. 아직 이 모델이 사이버 공격을 처음부터 끝까지 자동화할 수 있다는 확실한 증거는 없지만, 우리는 예방적 접근을 택해 지금까지 가장 폭넓은 사이버 보안 안전 장치를 적용했습니다. 이러한 조치에는 안전 학습, 자동 모니터링, 고급 기능에 대한 신뢰 기반 접근, 위협 정보가 포함된 대응 체계 등이 포함됩니다.

사이버 보안은 본질적으로 양면적 성격을 가지므로, 우리는 근거 기반의 반복적 접근 방식을 취하고 있습니다. 이를 통해 방어자가 취약점을 더 빨리 찾고 수정하도록 돕는 동시에, 악용 가능성은 줄이고자 합니다. 그 일환으로 사이버 방어 연구를 가속하기 위한 시범 프로그램인 Trusted Access for Cyber도 시작합니다.

또한 생태계 보호 장치에도 투자하고 있습니다. 보안 연구용 에이전트 Aardvark의 비공개 베타를 확대하고 있으며, 이는 Codex 보안 제품군의 첫 구성 요소입니다. 아울러 오픈소스 유지 관리 팀과 협력해 Next.js 같은 널리 쓰이는 프로젝트에 무료 코드 기반 점검을 제공하고 있습니다. 실제로 한 보안 연구자는 Codex를 사용해 지난주 공개된 취약점을 찾아내기도 했습니다.

2023년에 시작한 100만 달러 규모의 사이버 보안 보조금 프로그램에 이어, 우리는 오픈소스 소프트웨어와 핵심 기반 시설을 중심으로 사이버 방어를 가속하기 위해 API 크레딧 1,000만 달러를 추가로 지원할 예정입니다. 선의의 보안 연구를 수행하는 기관은 이 프로그램을 통해 API 크레딧과 지원을 신청할 수 있습니다.

이용 가능 여부 및 세부 사항

GPT-5.3-Codex는 유료 ChatGPT 요금제에서 사용할 수 있으며, Codex를 이용할 수 있는 모든 환경—앱, 명령줄 인터페이스(CLI), 통합 개발 환경 확장 기능, 웹—에서 제공됩니다. 또한 안전한 방식으로 API 접근을 제공하기 위한 준비도 진행 중입니다.

이번 업데이트를 통해 인프라와 추론 구조를 개선해, Codex 사용자에게 GPT-5.3-Codex를 25% 더 빠르게 제공하고 있습니다. 그 결과 상호작용 속도와 작업 결과 도출 속도가 모두 빨라졌습니다.

GPT-5.3-Codex는 NVIDIA의 GB200 NVL72 시스템을 기반으로 설계, 학습, 서비스되었습니다. 이 협력에 대해 NVIDIA에 감사의 뜻을 전합니다.

앞으로의 방향

GPT-5.3-Codex를 통해 Codex는 단순히 코드를 작성하는 단계를 넘어, 코드를 도구로 삼아 컴퓨터를 운영하고 작업을 처음부터 끝까지 완수하는 방향으로 나아가고 있습니다. 코딩 에이전트의 가능성을 확장하면서, 소프트웨어 구축과 배포를 넘어 조사, 분석, 실행 등 더 넓은 지식 노동 영역으로 확장되고 있습니다.

최고의 코딩 에이전트를 만드는 데서 시작된 이 흐름은, 이제 컴퓨터 위에서 함께 일하는 범용 협업자로 발전하고 있습니다. 그 결과, 더 많은 사람이 무언가를 만들 수 있게 되고, Codex로 할 수 있는 일의 범위도 크게 넓어지고 있습니다.

]]>

[릴리즈 노트] 코딩 더 잘 하는 Claude Opus 4.6 등장

※ 본문은 Anthropic의 <Introducing Claude Opus 4.6>를 신속하게 전달하기 위해 AI 번역 및 요약을 사용했습니다. 요즘IT 실무자에게 필요한 정보 전달을 위해 내용을 일부 생략하고 배치를 조정했습니다. GPT-5.2를 활용해 번역 및 요약했습니다.

[Claude Opus 4.6 요약]

핵심
Claude Opus 4.6은 이전 모델(Opus 4.5) 대비 코딩 능력과 자율 작업 지속 시간이 향상됨
Opus 계열 최초로 100만 토큰 문맥 창(베타) 지원
대형 코드 기반에서도 안정적으로 동작하며, 코드 검토·오류 수정 능력 개선

긴 문맥 처리 능력 개선
수십만 토큰 규모 문서에서도 정보 추적 능력 향상
이전 모델에서 발생하던 ‘문맥 열화’ 현상 감소
숨겨진 세부 정보 탐색 능력 강화

일상 업무 활용 범위 확대
재무 분석, 조사, 문서·표 계산 문서·발표 자료 생성 가능
Cowork 환경에서 여러 작업을 자율적으로 병렬 수행

개발자 기능 변화(API 기준)
적응형 사고: 필요할 때만 깊은 추론 수행
노력 수준 4단계(낮음·중간·높음·최대)로 비용·속도 조절 가능
문맥 압축 기능으로 장시간 작업 지원
최대 출력 길이: 12만 8천 토큰

제품 기능 업데이트
Claude Code에서 여러 에이전트를 팀처럼 병렬 실행 가능
Excel 기능 개선: 계획 수립, 비정형 데이터 구조화, 다단계 작업 처리
PowerPoint 기능(연구용 미리보기): 데이터 기반 발표 자료 자동 생성

안전성 변화
속임수, 망상 조장, 악용 협조 등 부적절 행동 비율 감소
Opus 4.5와 같은 수준의 정렬 상태 유지
과잉 거부 비율은 최근 모델 중 가장 낮음

가격 및 출시
가격: 백만 토큰당 입력 5달러 / 출력 25달러 (기존과 동일)
claude.ai, API, 주요 클라우드에서 즉시 사용 가능

우리는 가장 뛰어난 성능의 모델을 한 단계 더 끌어올립니다.

새로운 Claude Opus 4.6은 이전 모델보다 코딩 능력이 향상되었습니다. 더 신중하게 계획을 세우고, 자율적으로 수행하는 작업을 더 오래 이어갈 수 있으며, 큰 코드 기반에서도 더 안정적으로 동작합니다. 또한 코드 검토와 오류 수정 능력이 좋아져 스스로의 실수를 더 잘 찾아냅니다. 그리고 Opus 계열 모델 최초로, 베타 단계에서 100만 토큰 문맥 창(context window)을 지원합니다.

Opus 4.6은 향상된 능력을 다양한 일상 업무에도 적용할 수 있습니다. 재무 분석을 수행하고, 조사를 진행하며, 문서·표 계산 문서(스프레드시트)·발표 자료를 사용하거나 새로 만들 수 있습니다. Claude가 자율적으로 여러 작업을 동시에 수행하는 환경인 Cowork 안에서는, Opus 4.6이 이러한 능력을 종합적으로 활용해 사용자를 대신해 일을 처리할 수 있습니다.

이 모델은 여러 평가에서 최상위 수준의 성능을 보입니다. 예를 들어, 자율 코딩 평가인 Terminal-Bench 2.0에서 최고 점수를 기록했으며, 복잡한 여러 분야 추론 시험인 Humanity’s Last Exam에서도 모든 최신 모델 가운데 선두를 차지했습니다. 금융, 법률 등 경제적 가치가 높은 지식 업무 수행 능력을 평가하는 GDPval-AA에서는 업계에서 그다음으로 높은 성능의 모델(OpenAI의 GPT-5.2)보다 약 144점, 자체 이전 모델(Claude Opus 4.5)보다 190점 높은 점수를 기록했습니다. 또한 온라인에서 찾기 어려운 정보를 찾아내는 능력을 측정하는 BrowseComp에서도 다른 어떤 모델보다 높은 성능을 보였습니다.

공개된 상세 시스템 카드에서 확인할 수 있듯이, Opus 4.6은 여러 안전성 평가에서 부적절한 행동 비율이 낮게 나타나며, 업계의 다른 최신 모델과 비교해도 같거나 더 우수한 전반적인 안전성을 보여줍니다.

Claude Code에서는 이제 여러 에이전트(agent)로 팀을 구성해 함께 작업을 수행할 수 있습니다. 응용 프로그램 연결 환경(API)에서는 Claude가 컴팩션(compaction) 기능을 사용해 자신의 문맥을 스스로 요약하고, 제한에 걸리지 않으면서 더 오래 이어지는 작업을 수행할 수 있습니다. 또한 모델이 확장 사고(extended thinking)를 어느 정도까지 사용할지 문맥 단서로 판단하는 적응형 사고(adaptive thinking)를 새로 도입했으며, 개발자가 지능 수준, 속도, 비용을 더 세밀하게 조절할 수 있도록 노력 제어(effort controls)도 함께 제공합니다.

Excel에서의 Claude 기능도 크게 개선했고, PowerPoint용 Claude는 연구용 미리보기 형태로 공개합니다. 이를 통해 Claude는 일상 업무를 처리하는 능력이 훨씬 강화됩니다.

Claude Opus 4.6은 오늘부터 claude.ai, 응용 프로그램 연결 환경(API), 그리고 주요 클라우드 플랫폼 전반에서 사용할 수 있습니다. 개발자라면 Claude API에서 claude-opus-4-6를 사용하세요. 가격은 그대로이며, 백만 토큰당 5달러/25달러입니다. 자세한 내용은 가격 안내 페이지에서 확인할 수 있습니다.

아래에서는 모델 자체와 새 제품 업데이트, 평가 결과, 그리고 폭넓은 안전성 시험 내용을 자세히 다룹니다.

첫인상

우리는 Claude를 만들 때 Claude를 사용합니다. 우리 엔지니어들은 매일 Claude Code로 코드를 작성하며, 모든 새 모델은 먼저 내부 업무에 적용해 시험합니다. Opus 4.6을 사용해 보니, 이 모델은 별도의 지시가 없어도 작업에서 가장 어려운 부분에 더 집중하고, 비교적 단순한 부분은 빠르게 처리하며, 모호한 문제도 더 나은 판단으로 해결하고, 긴 세션에서도 생산성을 유지하는 모습을 보였습니다.

Opus 4.6은 종종 더 깊이 생각하고, 답을 내리기 전에 자신의 추론을 더 신중하게 다시 검토합니다. 이런 특성은 어려운 문제에서 더 좋은 결과를 만들어내지만, 단순한 작업에서는 비용과 지연 시간이 늘어날 수 있습니다. 만약 특정 작업에서 모델이 지나치게 오래 생각한다고 느껴진다면, 기본 설정인 높은 수준에서 중간 수준으로 노력 값을 낮추는 것을 권장합니다. 이는 /effort 매개값을 통해 간단히 조절할 수 있습니다.

Claude Opus 4.6 평가

자율 코딩, 컴퓨터 사용, 도구 활용, 검색, 재무 업무 전반에 걸쳐 Opus 4.6은 업계 최고 수준의 모델이며, 많은 항목에서 큰 격차로 앞서 있습니다. 아래 표는 다양한 벤치마크에서 Claude Opus 4.6이 이전 모델과 다른 업계 모델들과 비교해 어떤 성능을 보이는지 정리한 것입니다.

Opus 4.6은 대규모 문서 집합에서 관련 정보를 찾아내는 능력이 크게 향상되었습니다. 이 성능은 긴 문맥을 다루는 작업에서도 이어지는데, 수십만 토큰에 달하는 정보도 흐트러짐 없이 유지하고 추적하며, Opus 4.5조차 놓치던 깊이 숨겨진 세부 정보까지 찾아냅니다.

AI 모델에 자주 제기되는 불만 가운데 하나는 ‘문맥 열화(context rot)’입니다. 대화가 일정 토큰 수를 넘어서면 성능이 떨어지는 현상을 말합니다. Opus 4.6은 이전 모델보다 이 부분에서 눈에 띄게 개선되었습니다. 방대한 텍스트 속에 숨겨진 정보를 찾아내는 능력을 시험하는 MRCR v2의 ‘8개 바늘·100만 토큰’ 변형 시험에서 Opus 4.6은 76%를 기록한 반면, Sonnet 4.5는 18.5%에 그쳤습니다. 이는 모델이 실제로 활용할 수 있는 문맥의 양과, 최고 성능을 유지하는 능력에서 질적인 변화가 있었음을 보여줍니다.

종합하면, Opus 4.6은 긴 문맥 전반에서 정보를 더 잘 찾아내고, 그 정보를 바탕으로 더 뛰어난 추론을 수행하며, 전반적으로 전문가 수준의 추론 능력이 크게 향상된 모델입니다.

안전성에서의 진전

이러한 지능 향상은 안전성을 희생하면서 얻은 결과가 아닙니다. 자동 행동 감사에서 Opus 4.6은 속임수, 비위 맞추기, 사용자 망상 조장, 악용 협조 같은 부적절한 행동의 비율이 낮게 나타났습니다. 전반적으로 지금까지 가장 정렬도가 높았던 최신 모델인 Claude Opus 4.5와 같은 수준의 정렬 상태를 유지하고 있습니다. 또한 Opus 4.6은 무해한 질문에도 답을 거부하는 ‘과잉 거부’ 비율이 최근 Claude 모델 가운데 가장 낮게 나타났습니다.

Claude Opus 4.6에는 지금까지 어떤 모델보다도 폭넓은 안전성 평가를 적용했습니다. 여러 새로운 시험을 처음 도입했고, 기존에 사용하던 평가도 강화했습니다. 사용자 안녕을 위한 새로운 평가, 잠재적으로 위험한 요청을 거부하는 능력을 더 복잡하게 시험하는 항목, 그리고 은밀하게 해로운 행동을 수행하려는 능력을 점검하는 평가를 업데이트해 포함했습니다. 또한 모델이 특정 방식으로 행동하는 이유를 이해하기 위해, AI 모델 내부 작동을 연구하는 해석 가능성 분야의 새로운 방법도 실험적으로 적용했습니다. 이를 통해 기존 시험으로는 놓칠 수 있는 문제를 찾아내려 했습니다.

모든 성능 및 안전성 평가에 대한 자세한 설명은 Claude Opus 4.6 시스템 카드에서 확인할 수 있습니다.

또한 Opus 4.6이 특히 강점을 보이는 영역 가운데, 유익한 용도뿐 아니라 위험하게 사용될 가능성이 있는 분야에는 새로운 보호 장치를 적용했습니다. 특히 모델의 사이버 보안 능력이 향상된 점을 고려해, 다양한 형태의 악용 가능성을 추적할 수 있도록 여섯 가지 새로운 사이버 보안 탐지 시험을 개발했습니다.

우리는 모델을 사이버 방어에 활용하는 노력도 가속하고 있습니다. 오픈소스 소프트웨어의 취약점을 찾고 수정하는 데 모델을 활용하고 있으며, 이에 대해서는 별도의 사이버 보안 블로그 글에서 설명하고 있습니다. 우리는 사이버 방어자들이 Claude 같은 AI 모델을 활용해 경쟁 환경의 균형을 맞추는 것이 중요하다고 생각합니다. 사이버 보안 환경은 빠르게 변화하므로, 잠재적 위협에 대해 더 많이 알게 되는 대로 보호 장치를 계속 조정하고 업데이트할 것입니다. 가까운 시일 내에는 악용을 차단하기 위한 실시간 개입 기능도 도입할 수 있습니다.

제품 및 API 업데이트

우리는 Claude, Claude Code, 그리고 Claude 개발자 플랫폼 전반에 걸쳐 큰 폭의 업데이트를 진행해 Opus 4.6이 최고의 성능을 발휘할 수 있도록 했습니다.

Claude 개발자 플랫폼

응용 프로그램 연결 환경(API)에서는 개발자가 모델의 노력 수준을 더 세밀하게 조절하고, 오래 이어지는 에이전트 작업을 더 유연하게 수행할 수 있도록 다음 기능을 새로 도입했습니다.

적응형 사고(adaptive thinking)

이전에는 확장 사고(extended thinking)를 켜거나 끄는 이분법적 선택만 가능했습니다. 이제는 적응형 사고를 통해 Claude가 언제 더 깊은 추론이 필요한지 스스로 판단합니다. 기본 노력 수준(높음)에서는 필요할 때 확장 사고를 사용하며, 개발자는 노력 수준을 조절해 선택 기준을 더 엄격하거나 느슨하게 만들 수 있습니다.

노력 수준(effort)

이제 선택 가능한 노력 수준이 네 가지로 늘었습니다. 낮음, 중간, 높음(기본값), 최대 단계가 있으며, 개발자에게는 다양한 설정을 시험해 최적의 값을 찾는 것을 권장합니다.

문맥 압축(context compaction, 베타)

오래 이어지는 대화나 자율 작업은 종종 문맥 창 한계에 도달합니다. 문맥 압축 기능은 대화가 설정한 임계치에 가까워지면 오래된 문맥을 자동으로 요약해 교체함으로써, 한계에 걸리지 않고 더 긴 작업을 수행할 수 있도록 합니다.

100만 토큰 문맥(베타)

Opus 4.6은 Opus 계열 최초로 100만 토큰 문맥을 지원합니다. 입력이 20만 토큰을 초과하는 경우에는 프리미엄 요금이 적용되며, 백만 토큰당 입력 10달러, 출력 37.5달러가 부과됩니다.

출력 12만 8천 토큰 지원

Opus 4.6은 최대 12만 8천 토큰의 출력을 지원합니다. 덕분에 대량 출력을 여러 요청으로 나누지 않고 한 번에 처리할 수 있습니다.

미국 전용 추론(US-only inference)

미국 내에서만 작업을 처리해야 하는 업무를 위해, 미국 전용 추론 기능을 제공합니다. 이 기능은 토큰 요금의 1.1배가 적용됩니다.

제품 업데이트

Claude와 Claude Code 전반에 걸쳐, 지식 노동자와 개발자가 일상적으로 사용하는 도구를 바탕으로 더 어려운 작업을 처리할 수 있도록 여러 기능을 추가했습니다.

Claude Code에는 연구용 미리보기 형태로 에이전트 팀 기능을 도입했습니다. 이제 여러 에이전트를 동시에 실행해 팀처럼 병렬 작업을 수행하고, 자율적으로 협업하도록 할 수 있습니다. 이는 코드 기반 검토처럼 독립적으로 나눌 수 있고 읽기 중심인 작업에 특히 적합합니다. 또한 Shift+위/아래 또는 tmux를 사용해 각 하위 에이전트를 직접 제어할 수도 있습니다.

Claude는 이제 기존에 사용하던 사무용 도구와도 더 잘 연동됩니다. Excel용 Claude는 긴 작업이나 난이도 높은 작업에서도 성능이 개선되었으며, 실행 전에 계획을 세우고, 구조가 없는 데이터를 받아 적절한 구조를 스스로 추론하며, 여러 단계의 변경 작업도 한 번에 처리할 수 있습니다.

여기에 PowerPoint용 Claude를 함께 사용하면, 먼저 Excel에서 데이터를 처리하고 구조를 잡은 뒤, 이를 PowerPoint에서 시각적으로 표현할 수 있습니다. Claude는 레이아웃, 글꼴, 슬라이드 마스터를 읽어 브랜드에 맞는 결과물을 유지하며, 템플릿 기반 작업은 물론 설명만으로 전체 발표 자료를 생성할 수도 있습니다. PowerPoint용 Claude는 현재 Max, Team, Enterprise 요금제에서 연구용 미리보기로 제공됩니다.

]]>

한국인은 왜 GPT에게 지능보다 부지런함을 기대할까?

우리를 '근질근질하게' 만드는 GPT

여러분이 업무 중 챗GPT를 누르고 싶어 손가락이 근질근질해지는 순간은 언제인가요? 기획안 작성을 앞두고 막막한 백지를 마주했을 때, 방대한 회의록을 정리해야 할 때, 동시다발적으로 여러 일을 처리하느라 손발이 모자랄 때 등 이러한 문제 상황들을 맞닥뜨리며 하루에 적게는 수차례, 많게는 수십 차례 GPT를 들락거리고 있을지도 모릅니다.

제 경우부터 말씀드리면, 저는 회사 모니터 한 대를 아예 GPT 전용으로 할당해 사용하고 있을 정도로 GPT로부터 많은 업무 보조를 받고 있습니다. IT 솔루션사 영업 직군의 특성상 제안서, 비교 자료, 보고서 작성은 피할 수 없는 일상인데요. 사업 공고 한 건 한 건은 모두 소중하지만, 영업 사원의 물리적 리소스는 한정되어 있습니다.

특히 사업 기회가 한꺼번에 몰리는 시즌이면 고객사 및 사업별 우선순위와 이에 따른 리소스를 분배하는 일에 난항을 겪기도 합니다. 이럴 때 GPT는 훌륭한 업무 보조자가 되어줍니다. 단순히 답을 주는 것을 넘어 업무의 청사진을 그려주고, 주제의 맥락을 잡아주며, 혼자서도 다각도의 브레인스토밍을 가능하게 합니다.

이번 글에서는 베스트셀러 『시대예보: 경량문명의 탄생』이 제시한 ‘문명의 가벼움’이라는 개념을 빌려, 왜 한국 사회가 GPT를 이토록 빠르고 깊게 받아들였는지 살펴보고자 합니다. "한국은 왜 유독 챗GPT를 사랑할까?"라는 질문을 통해, 우리 사회가 선택한 경량문명적 성향과 그 도구로서의 GPT를 조명해 보겠습니다. 올해로 3년 연속 출간되고 있는 『시대예보』 시리즈의 송길영 저자는 숫자 너머의 선택을 읽어내는 ‘마인드 마이너(Mind Miner)’로서, 기술이 얼마나 발전했는가보다 사람들이 그 기술을 어떤 방식으로 일상에 들여놓는가에 주목했죠. 그래서 한국 사회가 GPT를 업무의 동반자로 받아들이게 된 맥락을 설명하는 데 이 책이 특히 유효하다고 생각했습니다.

미리 요점만 콕 집어보면?

한국에서 챗GPT는 생성형 AI 중 하나가 아니라 사실상 기준점에 가까운 위치를 차지하고 있으며, 업무와 일상 전반을 전제하는 범용 도구로 자리매김하고 있습니다.
한국 사용자들은 챗GPT를 일회성 체험이나 호기심의 대상으로 소비하기보다, 실질적인 효용을 확인한 뒤 비용을 지불하는 방식으로 수용하고 있습니다.
한국이 선택한 건 가장 똑똑한 AI가 아니라, 메일·회의록·보고서·기획안처럼 반복 업무를 가장 먼저 시작하게 해준 AI가 GPT였다는 점입니다.

GPT는 어떻게 한국에서 ‘생성형 AI의 기준’이 되었을까?

2025년 11월 기준, 한국인이 가장 많이 사용한 생성형 AI 앱은 챗GPT다. 타 생성형 AI에 비해 압도적 사용자 수를 보이고 있다. <출처: 와이즈앱·리테일>

위 자료를 보면 시중의 다종다양한 생성형 AI 중에서도 챗GPT에 대한 한국인의 선호도가 눈에 띄게 높음을 확인할 수 있는데요. 2025년 11월 기준 한국인이 가장 많이 사용한 생성형 AI 앱은 챗GPT였는데, 월간 활성 사용자 수(MAU) 2,162만 명을 기록하며 2위인 검색 기능 특화 AI Perplexity를 약 약 2천만 명 차이로 앞섰습니다.

이처럼 현재 한국의 생성형 AI 시장에서 GPT는 여러 선택지 중 하나라기보다 사실상 기준점에 가까운 위치를 차지하고 있습니다. 한국에서 왜 GPT가 다른 생성형 AI에 비해 압도적 우위를 차지하게 됐을까요?

카카오는 2025년 이프 카카오 컨퍼런스에서 챗GPT 기반 에이전트를 통해, 카카오 그룹 내 다양한 서비스를 연하여 '카카오 에이전트'로의 확장 계획을 밝혔다. <출처: 카카오>

제이슨 권 오픈AI CSO는 2025년 5월 "한국에 법인을 공식 설립했으며, 향후 몇 달 내 서울에 첫 번째 사무소를 열어 국내 사업을 본격화한다"고 밝혔다. <출처: 오픈AI>

GPT는 2022년 11월 출시 당시 생성형 AI의 잠재력을 대중에게 가장 먼저 극적으로 보여 주었으며, 초기 사용자 무료 제공을 통해 시장 내 선점적 우위를 획득했습니다. 이 밖에도 기술적 신뢰도가 높으며, 현지 확장 및 관련 생태계 지원에 대한 움직임을 적극적으로 보이고 있는데요. 이러한 각인 효과, 시장 선점, 그리고 국내 환경에 대한 적극 지원이 GPT가 국내 시장에서 안정적으로 자리 잡을 수 있었던 이유일 것입니다.

2025년 하반기의 ‘ChatGPT for Kakao’는 챗GPT가 현지 서비스와의 협업을 꾀한 대표적인 사례인데요. 지난 2025년 5월에는 오픈AI 서울 오피스의 개설 소식을 밝히기도 했습니다. 이처럼 GPT는 사용자 기반이 급성장하는 한국을 전략적 거점으로 삼고 지역 파트너십 확대, 정부·학계·기업과의 교류를 추진하며 현지화에 노력을 쏟고 있습니다.

한국 사회가 GPT를 ‘부지런한 지능’으로 사용하는 방식

글로벌 트래픽 분석 기관 시밀러웹(Similarweb)의 데이터를 인구 규모로 환산하면 한국 사용자들의 챗GPT 이용 밀도는 한층 더 분명해집니다. 미국의 경우 전체 트래픽 점유율 15.1%를 인구 약 3억 5천만 명으로 나누면 인구 100만 명당 약 4만 3천 건의 트래픽이 발생하는 것으로 추산됩니다. 반면 한국은 인구 100만 명당 약 6만 9,700건으로, 미국 대비 60% 이상 높은 수준을 기록합니다. 이는 단순한 시장 규모의 차이를 넘어, 한국 사용자들이 챗GPT를 더 빈번하게, 더 집중적으로 이용하고 있음을 보여주는 지표입니다.

이처럼 인구 대비 사용 강도가 높다는 점에 더해, 한국은 챗GPT의 유료 전환율 역시 글로벌 상위권에 속하는 시장으로 분류됩니다. 지난 2025년 11월 센서타워의 조사에 따르면, 한국은 챗GPT 매출 기준으로 전 세계 2위를 기록하였습니다. 이는 한국이 챗GPT 다운로드 규모 대비 지불 의향이 매우 높은 시장 중 하나임을 보여주는 수치입니다.

이러한 지점은 한국 사용자들이 챗GPT를 일회성 체험이나 호기심의 대상으로 소비하기보다, 업무와 일상 전반에서 실질적인 효용을 확인한 뒤 비용을 지불하는 방식으로 수용하고 있음을 시사합니다. 다시 말해, 한국에서는 챗GPT를 ‘많이 쓰이는 기술’을 넘어 ‘지불할 가치가 있는 도구’로 인식하고 있다는 것입니다.

종합하면, 글로벌 기준에서 보더라도 한국은 챗GPT를 유독 더 자주, 더 밀도 높게, 그리고 더 일상적으로 활용하는 시장에 해당합니다. 높은 인구 대비 사용 강도와 유료 전환율, 여기에 모바일 중심의 이용 패턴이 결합되면서 한국 사회에서 챗GPT는 업무와 생활 전반을 전제하는 범용 도구로 자리매김하고 있습니다.

2026년, 가벼운 것이 살아남는다

<출처: unsplash>

이러한 지표와 사용 패턴을 종합해 보면, 한국에서 챗GPT가 빠르게 확산된 이유도 설명이 됩니다. 또한 최근의 한국 사회는 AI를 ‘부지런한 지능’으로 활용하기에 가장 적합한 환경이기도 합니다. 챗GPT는 그 흐름과 가장 잘 맞아떨어진 도구였던 것인데요.

2026년 현재 필요할 때 AI를 호출해 업무를 정리하고 방향을 잡는 일터의 풍경은 더 이상 낯설지 않습니다. 예전에는 조직과 인프라를 중심으로 일이 돌아갔다면, 이제는 개인이 AI와의 질의응답을 통해 스스로 일을 점검하고 처리하는 쪽으로 구조가 바뀌고 있습니다. 업무 방식 자체가 점점 가벼워지고 있다고 느껴지는 이유입니다.

이 과정에서 한국에서의 챗GPT 활용은 ‘거대한 지능’보다는 ‘부지런한 지능’에 가깝게 자리 잡았습니다. 인류의 난제나 고도의 전문 영역을 다루는 도구라기보다, 자료를 찾고 문장을 다듬고 기획의 뼈대를 잡는 데 쓰이는 경우가 훨씬 많습니다. 즉, 생각을 대신해 주는 존재라기보다, 일을 시작하게 해 주고 속도를 붙여 주는 역할에 가깝습니다.

이런 맥락에서 한국에서 GPT는 소수의 천재를 위한 기술이라기보다 보통의 사람들이 시간을 아끼기 위해 곁에 두는 도구로 받아들여지고 있습니다. 보편적이고 루틴화된 업무에서 도움을 받고자 할 때 생성형 AI를 찾게 되는데, 이때 자연스럽게 매칭되는 생성형 AI가 GPT라는 것이죠. 물론 Gemini, Claude, Perplexity의 이용률도 적지 않지만 이들은 GPT에 비해서는 특정 업무 분야에 특화된 AI로 인식되는 것 같습니다.

이때의 ‘거대한 지능’과 ‘부지런한 지능’은 『시대예보: 경량문명의 탄생』에서 등장하는 개념입니다. ‘거대한 지능’은 인간이 기존에는 할 수 없었던 문제를 가능하게 만들고, 방대한 데이터 속에서 새로운 패턴과 해답을 도출하는 지능을 의미합니다. 반면 ‘부지런한 지능’은, 인간이 하기 싫고 번거로운 일을 대신 처리해 시간을 단축해 주는 지능을 뜻합니다. 한국에서 챗GPT가 사용되는 방식은 이 정의에 가장 가까운 형태로 나타나는 것입니다.

거대한 시스템에서 개인화 에이전트로의 전이

과거의 업무 환경은 거대한 시스템을 중심으로 설계되어 있었습니다. 조직과 프로세스, 승인 체계가 일을 움직이는 주체였다면, 지금은 개인이 AI 에이전트를 통해 업무를 호출하고 정리하는 방식으로 무게중심이 이동하고 있습니다. 무거운 시스템은 안정적이지만 느린 반면, 개인화된 에이전트는 가볍고 빠르게 움직입니다.

챗GPT의 확산은 이러한 전이를 가속했습니다. 필요할 때 AI를 호출해 업무의 초안을 만들고, 방향을 잡고, 이후 판단은 인간이 수행하는 구조가 점점 보편화되고 있습니다. 이는 기술이 더 고도화되었기 때문이라기보다, 일하는 방식 자체가 재배치되고 있는 것입니다.

지능의 범용화, 협력의 경량화

<출처: 교보문고>

지능의 범용화: '전문가' 대신 '내 곁의 지능'

GPT가 한국에서 빠르게 자리 잡은 이유 중 하나는 지능이 특정 전문가 집단에 머물지 않게 되었기 때문입니다. 질문을 던지고, 수정하고, 다시 검증하는 과정을 반복하면서 개인은 스스로 오류를 줄여 나가고 있습니다. 이는 전문 지식을 대체한다기보다, 전문성에 접근하는 비용을 낮춘 변화에 가깝습니다.

로펌이나 컨설팅 조직처럼 과거에는 외부에 맡기던 영역도, 이제는 AI와의 협업을 통해 1차 정리가 가능해졌습니다. 지능이 특정 집단의 전유물이 아니라, ‘곁에 두고 쓰는 도구’로 범용화되고 있는 셈입니다.

협력의 경량화: 연결 비용을 줄이다

이러한 변화는 조직의 모습에서도 드러나고 있습니다. 업무는 점점 개인 단위로 쪼개지고, 협업은 이전보다 훨씬 가볍고 빠른 연결을 중심으로 이루어지고 있습니다. 꼭 많은 사람을 거치지 않더라도, 각자가 맡은 일을 정리해 공유하는 방식이 보편화되고 있습니다. 이 과정에서 AI는 협업 자체를 대체하기보다, 협업의 전제 조건을 만들어 줍니다. 정리된 결과를 빠르게 공유하고, 필요한 지점에서만 연결되는 구조가 자리 잡으면서 협력의 비용은 눈에 띄게 낮아지고 있습니다.

직접 실감한 개인 업무와 팀 업무에서의 변화

GPT의 효율적인 사용을 위해 고객사, 제품군별로 프로젝트를 분리하여 관리하고 있다. 검색, 요약, 검토 등 다양한 업무 보조 목적으로 쓰고 있다. <출처: 작가>

저는 정보보안 솔루션 회사의 영업 사원으로, 올해로 4년 차 직장인입니다. 제가 GPT를 활용해서 업무를 진행하는 방식을 간단히 소개하자면 다음과 같은데요. 위 사진처럼 업무 단위별로 GPT의 ‘프로젝트’를 생성해 사용하고 있습니다. 고객사별, 제품군별로 대화를 분리해 관리하면서 업무와 무관한 대화가 섞이지 않도록 의도적으로 맥락을 통제하고 있습니다. 이는 정보 혼선을 줄이기 위한 개인적인 장치이자, 제 사고 흐름을 정리하기 위한 방식이기도 합니다.

각 프로젝트에는 제품 제안서와 내부 자료를 업로드해 두고, 필요할 때마다 해당 맥락을 불러오고 있습니다. 회사에서 다루는 제품군이 다양하고 복잡하므로, 각 솔루션의 강점과 약점, 경쟁사 대비 포인트를 빠르게 상기하는 데 큰 도움이 됩니다.

클로바 노트와 챗GPT를 이용한 미팅 정리 과정. 1차적으로 클로바 노트를 통해 주요 키워드와 AI 요약을 추출하고, 음성 기록을 내보내기하여 챗GPT에 업로드한 다음 회의록 작성 과정을 거친다. <출처: 작가>

미팅 방식에서도 변화를 체감하고 있는데요. 저는 주당 5~10회에 달하는 미팅을 모두 음성 기록으로 남기고, 이를 클로바 노트를 통해 텍스트로 전환합니다. 클로바 노트에서 제공하는 AI 요약 기능도 유용하지만, 이것만으로는 부족함을 느낄 때가 많습니다. 미팅이 1시간 이상으로 길어지거나 대화 주제가 두서없이 이어지는 경우 한 번에 맥락을 이해하기 어려운 형태로 요약본이 제공되기 때문입니다.

이에 따라 저는 클로바 노트의 녹음 변환 텍스트를 txt로 내보내기 하여 GPT에 업로드하는 과정을 한 번 더 거치고 있습니다. 단순 요약 기능만으로는 놓치기 쉬운 맥락이나 고객의 실제 관심사를, GPT는 비교적 안정적으로 구조화해 줍니다. ‘무엇을 말했는가’보다 ‘어디에 무게가 실렸는가’를 정리해 준다는 점에서, 회의록은 더 이상 단순한 기록이 아니라 다음 액션을 위한 초안에 가까워집니다.

챗GPT의 도움으로 작성된 업무 기록들은 구조화하여 노션에 적재한다. 이처럼 GPT 덕분에 더 적은 연결 비용으로도 효과적인 팀 내 협업이 가능해진다. <출처: 작가>

이렇게 개인 단위에서 정리된 결과물은 다시 팀 단위로 공유되고 있는데요. 저는 정리된 회의 내용과 인사이트를 노션에 정리해 팀 내에 공유하고 있습니다. 이는 단순한 정보 전달을 넘어, 팀 전체의 업무 밀도를 맞추는 역할을 합니다. 같은 제품에 대해 서로 다른 설명이 나오는 상황을 줄이고, 고객사 간 레퍼런스를 빠르게 공유하기 위함입니다. 이 과정에서 GPT는 개인의 생산성을 높이는 도구이면서 동시에, 팀 내 협업 비용을 낮추는 매개로 기능하고 있습니다.

과거라면 보고서 작성이나 자료 정리를 위해 추가적인 리소스를 써야 했겠지만 이제는 개인이 AI와의 상호작용을 통해 충분히 소화할 수 있게 되었습니다. 그 결과 업무는 더 작게 쪼개지고, 결정은 더 빠르게 내려지고 있습니다.

마치며

지금까지 한국에서 챗GPT가 빠르게 확산된 이유를 살펴봤는데요. 그 이유는 GPT의 기술이 특별히 더 ‘똑똑해서’라기보다, 한국 사회가 필요로 하던 역할을 ‘시의적절하게’ 채워줬기 때문입니다. 여기서의 쟁점은 ‘왜 하필 GPT였나’입니다. 한국 사용자들이 원한 것은 거창한 기술 시연이 아니라, 메일·회의록·보고서·기획안처럼 매일 반복되는 업무를 빠르게 굴려 주는 실용적인 도구였습니다. GPT는 질문을 던지면 곧바로 초안을 만들고, 문서를 정리하고, 생각의 뼈대를 세우는 데 즉시 투입할 수 있었으며, 무엇보다 “일단 켜서 써볼 수 있는” 접근성이 강했습니다. 그 결과 한국에서는 여러 AI 중 GPT가 먼저 기본값처럼 자리 잡았고, 이후의 도구들은 비교 대상으로 들어오는 흐름이 만들어졌습니다.

이러한 변화는 개인의 업무 방식에만 그치지 않습니다. 조직은 점점 더 개인 단위로 쪼개지고, 협업은 무거운 승인 절차나 복잡한 연결 대신 가벼운 공유와 빠른 피드백을 중심으로 재편되고 있습니다. AI 에이전트와 함께 일하는 방식은 더 이상 일부 실험적인 사례가 아니라, 이미 많은 현장에서 전제가 되어 가고 있습니다.

그래서 지금 시점에서 더 중요한 질문은 “AI가 무엇을 할 수 있는가”가 아닙니다. 오히려 “우리는 AI를 어떤 지능으로 쓰고 있는가?”, 그리고 “앞으로도 부지런한 지능으로만 사용할 것인가, 거대한 지능으로 확장할 준비가 되어 있는가”에 가깝습니다. 이 선택에 따라 개인의 일하는 방식은 물론, 조직과 사회의 모습도 분명하게 달라질 것입니다. 한국이 선택한 건 ‘가장 똑똑한 AI’가 아니라, ‘가장 먼저 일을 시작하게 해준 AI’였고, 그것이 GPT였다는 것으로 결론을 내 보고자 합니다.

<참고>

[책] 『시대예보: 경량문명의 탄생』, 송길영
[인공지능신문] 가트너, 2026년부터 주목해야 할 10대 AI 전망... “미래 경쟁력 확보 위해 기술 변화를 넘어 행동 변화에 주목해야”
[아세안 문화 경제 미디어] 한국인이 가장 많이 쓰는 생성형 AI 데이터는 2위는 제미나이, 1위는?
[AImatters] 한국 챗GPT 사용자 2,000만 명, 글로벌 통계엔 왜 없을까?
[Reuters] OpenAI to open office in Seoul amid growing demand for ChatGPT

]]>

개발자가 바이브 코딩 청소하며 느낀 것들

‘바이브 코딩’이라는 말이 처음 퍼졌을 때의 분위기는 사실 진지함보다 조롱에 가까웠습니다. “코드를 한 줄도 모르는 사람이 프로그램을 작성한다고?”라는 반응이 대부분이었죠. 하지만 지금은 분위기가 다릅니다. 바이브 코딩 강의가 쏟아지고, 더 나은 AI 에이전트들이 등장하고, 사람들은 자신만의 바이브 코딩 팁을 공유하기 시작했습니다. 그만큼 바이브 코딩이 새로운 기회를 열어준 것이죠.

예전에는 아이디어가 있으면 어떻게 했을까요? 외주를 맡기려면 완벽하게 정리된 기획서가 필요했습니다. 눈을 감고 그림을 그리는 것과 같았죠. 머릿속으로만 상상하며 설명해야 했고, 결과물이 나와야 비로소 "아, 이게 아닌데"를 알 수 있었습니다. 지금은 다릅니다. 직접 만들어보고, 만져보고, 다듬어볼 수 있습니다. 거의 완성된 그림을 눈앞에 두고 생각을 조정할 수 있습니다.

그래서 팀빌딩도 달라졌습니다. 먼저 아이디어를 직접 구체화하고, 확신이 생겼을 때 개발자를 영입합니다. 수익이 발생한 후에 고도화해도 되고요. 일의 순서가 바뀐 거죠. 아마 바이브 코딩이 없었다면, 시도조차 못 했을 아이디어들이 지금은 바로 현실이 되고 있습니다.

‘바이브 코딩 청소’가 등장하다

그 덕분에 ‘바이브 코딩 청소’라는 개념도 생겨났습니다. 이것도 처음엔 우스갯소리였습니다. 바이브 코딩으로 엉망이 된 코드를 결국 개발자가 치워줘야 한다면서요. “바이브 코딩이 개발자를 대체한다”는 말에 대한 반항 심리 같은 거였죠. 그런데 저는 진짜로 하고 있습니다. 바이브 코딩 서비스를 운영하고 있기도 하고, 그중 25개 프로젝트에서 직접 바이브 코딩 청소를 수행했습니다. 사내 기획자, 지인들과 함께 말이죠. 오늘은 바이브 코딩 청소를 경험해 본 제가 지금 느끼고 있는 개발자 포지션의 변화에 대해 이야기해 보려고 합니다.

미리 요점만 콕 집어보면?

바이브 코딩은 처음엔 의심에서 출발했지만, 아이디어를 직접 만들고 검증할 수 있는 현실적인 방법으로 빠르게 자리 잡았습니다.
바이브 코딩으로 만든 코드는 프로젝트가 커질수록 하드코딩과 컨벤션 붕괴 문제가 생기지만, AI 지침과 자동화를 활용한 바이브 코딩 청소로 해결할 수 있었습니다.
이 경험은 개발자의 역할이 기능 구현 중심에서 환경과 규칙을 설계하는 플랫폼 엔지니어로 이동하고 있음을 보여줍니다.

실제 바이브 코딩 청소 사례

실제로 제 비개발자 지인이 바이브 코딩으로 하나의 서비스를 만들었습니다. 일본인 관광객을 대상으로 한국 맛집을 소개하는 사이트인데요. 이 서비스는 관리자 화면에서 게시글을 관리하고, 맛집과 제휴를 맺어 할인과 수익을 공유(쉐어)하는 모델입니다. 서비스를 출시한 이후, 실제 유저가 방문하기 시작했고, 현재는 총 5곳과 제휴를 맺은 상황이었죠. 지인은 이 서비스를 제가 운영하는 바이브 코딩 툴로 직접 개발했습니다. 그래서 개발 도중 문제가 생기면 지인은 저에게 도움을 요청하고, 그사이 다른 프로젝트를 만듭니다.

저는 지인의 코드 저장소에 접속해 클로드 코드(Claude Code)로 문제를 수정했습니다. 둘 다 같은 클로드 코드 기반을 사용하고 있어서, 어떤 지시 사항이 빠졌는지 파악하기 수월했고요. 지인이 보내는 요청은 주로 이런 식입니다.

“ㅇㅇ기능이 안 돼요.”
“~~를 하고 싶은데 AI가 이해를 못 해요.”

문제의 핵심은 코드가 커지고 문맥(Context)이 길어지면서, AI가 요청사항을 제대로 이해하지 못하는 경우가 잦아졌다는 점입니다.

<출처: 서울비요리>

바이브 코딩에서 발생하는 코드의 문제점들

코드를 살펴보니 몇 가지 문제가 눈에 띄었습니다. 비개발자들이 말하는 ‘코드가 꼬인다’는 게 이런 거였구나 싶더군요.

하드코딩

AI가 유저의 요청을 단편적으로 수행하려다 보니 발생하는 문제입니다. 예를 들어, "대시보드 구성해 줘"라고 하면, UI에 특정 값이 그대로 박혀 있는 경우가 많습니다. 말 그대로 껍데기만 만들어놓은 셈이죠. 물론 처음부터 실제 값을 넣기보다는 가짜 데이터를 사용하는 것도 괜찮습니다. 기능을 확인하려면 어차피 그런 과정이 필요하니까요. 하지만 중요한 건 그 방식입니다.

가짜 데이터를 api → page 형태로 만들어놓으면, 나중에 api 부분만 실제 연동으로 바꾸면 됩니다. 그런데 화면에 값이 박혀 있으면, 나중에 실제로 연동할 때 수정이 어려워집니다.

<출처: 작가>

컨벤션 룰 미준수

배포 플랫폼과의 호환, Next.js에서 글로벌 상태를 쓰기 위한 베스트 프랙티스 같은 것들이 지켜지지 않았습니다. 컨벤션은 ‘코드를 이런 식으로 작성하라’는 일종의 규칙입니다. 단순히 파일 이름을 소문자로 쓰는 컨벤션도 있지만, 데이터베이스 테이블 작성 규칙, UI와 상태, API의 연계 흐름 등도 포함됩니다.

왜 이런 규칙이 필요할까요? 기획이 변경되거나, 새로운 기능이 추가됐을 때 변경 범위를 최소화하기 위해서입니다. 오류가 전파되는 것을 막고, 기능을 쉽게 추가할 수 있게 하죠. 원래 개발자들은 코드 리뷰를 하면서 이런 규칙을 서로 맞춰 갑니다. 사실 개발에서는 코드를 작성하는 시간보다, 이런 합의를 만드는 데 더 많은 시간이 걸립니다. 그런데 바이브 코딩에서는 이 룰이 지켜지기 어렵습니다.

왜 이런 일이 생겼을까?

프로젝트의 코드량이 많아질수록, AI는 점점 지침을 누락하기 시작했습니다. 아무래도 코드 에이전트는 평균적인 코드를 작성하는 경향이 있습니다. 프레임워크의 새로운 기능을 적극적으로 활용하지 않고, ‘옛날’ 코드 패턴을 따라가는 경우가 많죠. 원래는 제가 만들어 둔 지침이 이런 문제를 방어해줘야 하는데, 그 지침이 누락되면서 방어막이 뚫린 겁니다.

제가 만들고 있는 지침은 지난 6년간 개발하면서 다양한 프로젝트를 직접 수행한 경험을 바탕으로 작성한 것입니다. “당신은 구글 시니어 개발자입니다” 같은 롤플레잉 프롬프트와는 다릅니다. 사내에서 코드를 작성할 때 실제로 사용하는 리뷰용 체크리스트이며, 완전히 개발 용어로 구성돼 있어 일종의 코드에 가깝다고 볼 수 있습니다.

그런데 AI가 이 지침을 따르지 않았습니다.

제가 에이전트 지시 사항에서 그 내용을 빠뜨렸거나,
혹은 에이전트가 지침을 누락했거나,

둘 중 하나입니다.

바이브 코딩 청소도 바이브 코딩이다

그렇다면 저는 이 문제를 어떻게 정리했을까요? 바이브 코딩 청소도 바이브 코딩 방식으로 해결했습니다. 저는 코드를 직접 고치지 않았습니다.

빠뜨린 경우: 지시 사항을 추가한 뒤, 해당 지시 사항을 제대로 따랐는지 파일을 검사하라고 AI에게 지시합니다.
누락한 경우: 누락된 부분을 지시 사항 파일과 다시 매칭해 주는 방식으로 정리했습니다.

<출처: 작가>

제가 전에 기획자, 혹은 현재 개발자로서 일할 때와는 사뭇 다릅니다. 예전에는 적극적으로 프로덕트의 기능을 파악하고, 화면을 직접 띄워보며 수정 사항을 반영하곤 했습니다. 하지만 지금은 기계적으로 체크리스트에 맞는지 확인하고, 누락된 부분이 있으면 다시 요청하는 방식으로 일하고 있습니다.

터미널에서 반복적으로 타이핑하는 키워드가 있었고, 엔터를 누른 뒤 결과를 점검하는 과정을 반복합니다. 비개발자의 바이브 코딩과 제가 하는 바이브 코딩의 차이점은, 저는 코드의 품질을 판단할 수 있고, 그에 따라 다시 요청할지를 결정할 수 있다는 점입니다. 솔직히 고백하자면, 저는 이 서비스의 정확한 기능을 잘 모릅니다. 서비스가 일본어로 되어 있어서, 제가 들어가 봐도 이해하기가 어렵거든요. 그럼에도 불구하고 청소가 가능했다는 사실은, 개발자로서의 저를 다시 한번 돌아보게 만들었습니다.

개발자로서의 역할이 변하고 있다

제가 생각하는 엔지니어의 역할은 이렇습니다. 프로덕트를 빨리 만들고, 기능을 수정하고, 안정적으로 운영하는 것이죠. 이걸 수행하는 방법은 여러 가지가 있는데, 프로덕트 엔지니어와 플랫폼 엔지니어로 나눠볼 수 있을 것 같습니다. 프로덕트 엔지니어는 제품과 비즈니스를 이해하면서 개발하는 사람입니다. 플랫폼 엔지니어는 엔지니어를 위한 엔지니어입니다. 제반 환경을 설정하고, 오로지 비즈니스 기능 구현에 집중하게 하고, 프로덕트가 운영이 잘되도록 하는 코드 환경을 구성합니다.

프로덕트 엔지니어로 살아왔다

저는 그동안 프로덕트 엔지니어로 살아왔습니다. 기획자와 면밀히 소통하거나, 제가 기획과 개발을 모두 맡아 진행했습니다. 이 방식이 단순히 개발자일 때보다 나았던 이유가 있습니다. 모든 기획 내용을 일일이 전달하는 것은 현실적으로 어렵기 때문입니다. 어느 정도는 개발자도 스스로 의사결정을 내리는 순간이 필요했습니다.

작은 기업일수록 그 필요성은 더욱 커집니다. 그리고 실제로 만들면서 생겨나는 아이디어들도 존재합니다. 그렇기 때문에 현재 개발 중인 프로덕트의 기능을 잘 알고, 소비자의 니즈를 이해하면 기획자와의 소통 간극을 줄일 수 있고, 결과적으로 더 빠르게 프로덕트를 만들 수 있었습니다.

바이브 코딩 청소를 하면서 달라졌다

바이브 코딩 청소를 하면서 제 역할이 달라졌습니다. 앞서 말했듯, 저는 프로덕트의 기능에 전혀 관심을 가지지 않았습니다. 모든 동작은 바이브 코더가 구현해 놓았기 때문입니다. 그게 실제로 동작하든, 안 하든요. 저는 그것이 돌아가기만 하면 된다는 1차적인 목표만 생각했습니다. 그럼에도 불구하고 실제로 돌아가더군요. AI가 프로덕트를 이해하고, 기능을 알고 있었기 때문입니다.

저는 어느 순간부터 바이브 코더를 일종의 개발자로 간주하기 시작했습니다. 이들이 더 편하게 코드를 작성할 수 있도록, 그리고 더 이상 문제가 제게 넘어오지 않도록 하기 위해 제가 코드를 짜고 있는 모습을 발견했습니다. 플랫폼 엔지니어로서의 역할로 바뀐 겁니다.

플랫폼 엔지니어로서 하고 있는 일들

1) 컨텍스트 지침서

필요한 폴더마다 .ai.md 파일을 작성해 규칙을 정리합니다. 그리고 AI가 해당 파일을 먼저 읽고 나서 작업을 시작하도록 지시하죠. AI의 자율성을 존중하면서도 최소한의 제한을 둠으로써, 코드가 일관되게 작성될 수 있도록 돕는 방식입니다. 저는 평소에도 코드 방법론에 대해 블로그 글을 써왔는데요. 그런 저의 생각들을 .ai.md 파일에 녹여내고 있습니다.

<출처: 작가 벨로그>

2) ESLint 커스텀

ESLint를 커스텀합니다. ESLint는 코드 작성 규칙을 자동으로 검사해주는 도구입니다. 지침만으로는 누락되는 부분이 생기기 때문에, 컴파일러의 결과물을 분석해 제가 원하는 형태로 코드가 작성됐는지 확인할 수 있는 커스텀 룰을 추가하기 시작했습니다. 처음에는 3~4개 정도였는데, 지금은 15개가 넘습니다. 에이전트는 작업을 수행한 뒤 코드 유효성 검사 스크립트를 실행해 규칙에 위반되는 코드를 발견하고, 그 내용을 바탕으로 다시 수정합니다.

<출처: 작가>

3) 제반 환경 연결

제반 환경을 연결합니다. 데이터베이스, 로그인, 이미지 업로드 등 서비스에 필요한 기반들을 모두 세팅해 줍니다. 배포 비용이 거의 들지 않도록 구성했습니다. 돈을 벌지 않는 서비스가 매달 2만 원을 낸다고 하면 부담스럽잖아요. 그래서 서버리스 환경을 구축하고, 그 위에서 Next.js가 동작할 수 있도록 인프라를 구성했습니다. 이미지 서버, 데이터베이스, 프론트 서버들을 한 번에 구성해, 트래픽이 과도해지기 전까지는 비용이 발생하지 않도록 했습니다.

또 better-auth와 같은 오픈소스를 활용해 카카오 로그인 같은 소셜 로그인을 쉽게 연동할 수 있게 만들었습니다. OAuth 개념을 몰라도 자동으로 지원되도록 구성했고요. 이 밖에도 DB 백업, 코드 백업 같은 항목도 관리합니다. 혹시 모를 오류에 대비하기 위해서죠. 이런 제반 환경은 함께 일하는 팀원이 작업하고 있습니다. 복잡한 작업을 미리 수행해 둠으로써, 사용자는 비용이나 연동 과정을 신경 쓰지 않고 개발에 집중할 수 있습니다.

4) 바이브 코딩 툴의 발전

바이브 코더가 더 많은 프로젝트를 수행하고, 더 정확하게 의도를 반영할 수 있도록 툴을 발전시키고 있습니다. 여러 프로젝트를 동시에 띄울 수 있게 하거나, 고치고 싶은 부분을 클릭해 대화창을 열면 해당 위치의 코드가 자동으로 전송되는 방식 등으로 개선 중입니다.

<출처: MVP STAR>

5) 리팩토링 스킬

청소를 하면 할수록, 제가 놓쳤던 AI 지침을 추가하게 됐습니다. 그리고 제가 반복적으로 요청하던 부분, 즉 AI가 자주 실수하는 항목들을 자동화했습니다. 에이전트가 루프를 돌며 체크리스트를 확인하게 하는 리팩토링 스킬을 만들었고, 이제 이 스킬을 실행하면 클로드 코드가 30분에서 2시간 동안 돌아가면서 누락된 지침들을 모두 채워 넣습니다.

리팩토링을 직접 했을 때는 처음에 12시간이 걸렸습니다. 그러나 지금은 시간이 점점 줄어들어 2시간 정도면 됩니다. 그마저도 대부분 자동으로 처리됩니다. 이 리팩토링 스킬은 바이브 코딩 툴에도 탑재해서, 지인이 직접 호출할 수 있도록 했습니다. 최대한 제가 직접 수정할 일이 없도록 하기 위해서죠. 이제는 프로젝트당 단 한 번만 도움 요청이 들어옵니다.

바이브 코딩의 한계

사실 바이브 코딩 열풍이 불면서, 겉보기만 그럴듯한 팁을 쏟아내는 포스팅도 많아졌습니다.

<출처: 작가>

저는 링크드인에 이런 글을 쓴 적이 있습니다. 초반만 읽고 “진짜 팁인 줄 알았다”는 반응이 많았죠. 그만큼 가짜 팁이 퍼지기 쉽다는 뜻입니다. 문제는 이런 가짜 팁을 수용해 작성하면, 오히려 일을 더 복잡하게 만든다는 점인데요. 그냥 “여기 안 돼요”라고만 하면 해결될 수도 있었던 문제를 말이죠.

그래서 제가 드릴 수 있는 유일한 팁은 “내가 이해한 말만 넣기”입니다. 자신이 개발자인 척하면서 직접 코드를 지시하는 순간, 에러가 발생합니다. 한편으로는, 개발자였다면 쉽게 수정할 수 있었던 문제들이 바이브 코딩에서는 시간이 오래 걸리거나, 끝내 해결되지 못하는 경우도 봤습니다. 결국 코드를 직접 봐야만 풀리는 문제들은 여전히 존재하고 있는 겁니다.

바이브 코딩이 보여준 새로운 협업 가능성

바이브 코딩이 열어준 기회는 분명합니다. 저와 비개발자의 협업은 일종의 외주 관계였지만, 기존 외주와는 전혀 달랐습니다. 예전에는 외주로 프로덕트를 맡기면 결과물이 엉망이었고, 결국 제가 직접 개발하는 게 더 빠르다고 느껴 개발자로 전향하기도 했습니다. 문제는 항상 의사소통이었죠. 그래서 대부분 팀을 직접 구성하려고 합니다. 제대로 된 프로덕트를 만들려면 긴밀한 소통이 필요하니까요. 하지만 팀을 꾸리기 위해선 시간과 비용이 듭니다. 수익도 없는 상황에서 제품이 검증될 때까지 버티기는 쉽지 않죠. 이 리스크 때문에 시작조차 못 하는 프로젝트가 많습니다.

그런데 바이브 코더와의 협업은 달랐습니다. 메일로만 소통했지만 충분했습니다. 제가 한 번 전체 코드를 정리해주면, 이후엔 요청 없이 기능이 잘 추가됐습니다. 제가 청소한 프로덕트들은 바이브 코딩이 아니었다면 세상에 나오지 못했을 겁니다. 초기 실험에 필요한 시간과 자본이 항상 부족하니까요. 바이브 코딩은 이 자원을 효율적으로 활용할 수 있게 해줍니다.

이 경험을 통해 깨달은 건, 바이브 코딩이 개발자를 대체하진 못하지만 보완할 수 있다는 점입니다. 개발자가 중간에 조금만 개입해도 작업 속도가 훨씬 빨라집니다. 굳이 개발자를 안 쓸 이유가 없죠. 이제 개발자는 동시에 더 많은 프로젝트에 참여할 수 있습니다. 저처럼 하루에 세 개 프로젝트를 다루는 것도 가능합니다.

이제 ‘바이브 코딩 청소’라는 방식이 새로운 협업 형태로 자리 잡을 수 있을까요? 저는 이 방식이 개발자와 비개발자 모두에게 새로운 기회를 줄 거라고 믿습니다. 여러분의 생각은 어떠신가요?

]]>

2025 DB 결산: 기술 트렌드와 실무의 간극 돌아보기

2025년, 데이터베이스 기술은 유례없이 빠르게 진화했습니다.

PostgreSQL을 품은 Supabase가 주목받았고, DuckDB와 SQLite는 로컬 환경을 중심으로 다시 떠올랐습니다. 다만 현장에서 직접 코드를 짜며 서비스를 운영했던 입장에서 현실은 조금 달랐습니다. 최신 기술이 항상 최선의 선택은 아니었고, 오히려 이미 검증된 도구가 더 중요하게 작용했던 순간도 많았기 때문입니다.

2025년의 DB 트렌드를 정리하는 동시에, 그 이면에서 이뤄진 실무단의 선택을 함께 돌아보려고 합니다.

<출처: 작가, ChatGPT로 제작>

미리 요점만 콕 집어보면?

2025년 데이터베이스 기술은 Supabase, Neon 같은 BaaS와 DuckDB·SQLite의 로컬 퍼스트 흐름이 동시에 부각되며 빠르게 진화했습니다.
한편 실무 현장에서는 PostgreSQL·MySQL처럼 검증된 도구의 안정성과 운영 경험이 여전히 중요한 선택 기준으로 작용했습니다.
결국 데이터베이스 선택은 유행이 아니라 서비스 단계와 팀 역량에 맞춰 유연하게 조합하는 현실적인 판단의 문제일 것입니다.

SaaS가 주도한 2025 DB 기술 트렌드

2025년 데이터베이스 트렌드를 이야기할 때, 흔히 “이제는 DB를 직접 설치하지 않는다”는 표현을 쓰곤 합니다. 다만 실제 개발 현장을 기준으로 보면, 이 말은 단순하게 느껴질 수 있습니다. 이미 대부분의 팀은 온프레미스 환경 대신 클라우드에서 데이터베이스 서버를 띄워 사용하고 있기 때문입니다. 문제의 핵심은 데이터베이스 서버 자체가 아닌 그 데이터베이스를 실제 서비스에 적용하기까지 필요한 준비 과정에 있었습니다.

새로 주목받기 시작한 BaaS

데이터베이스를 하나 선택하고 나면 그다음에는 자연스럽게 백엔드 애플리케이션이 필요해집니다. API 서버를 구성해야 하고, 인증과 권한 처리를 설계해야 하며, 데이터 접근 규칙을 정의하고, 운영을 위한 관리 도구도 갖춰야 합니다. 작은 서비스라고 해도 이러한 기본 구성을 마련하는 데에는 생각보다 많은 시간과 노력이 듭니다. 특히 소규모 팀이나 개인 개발자에게는 이 과정 자체가 진입 장벽으로 작용하는 경우도 많습니다.

이 맥락에서 본격적으로 주목받기 시작한 개념이 바로 Backend as a Service, 즉 BaaS입니다. BaaS는 데이터베이스를 중심으로 인증, 스토리지, API 생성, 권한 관리까지 백엔드의 핵심 요소를 하나의 서비스 형태로 제공합니다. 개발자가 모든 구성 요소를 직접 조립하는 대신, 이미 잘 설계된 백엔드 환경을 그대로 가져다 쓰는 방식이라고 보면 됩니다. 실제로 2025년의 데이터베이스 트렌드는 이 BaaS 개념을 중심으로 빠르게 재편되었다고 해도 과언이 아닙니다.

대표적인 BaaS: Supabase, Neon, PlanetScale

이 흐름을 대표하는 서비스로 Supabase, Neon, PlanetScale을 꼽을 수 있습니다. 이들의 공통점은 완전히 새로운 데이터베이스를 만들지 않았다는 데 있습니다. 대신 오랜 시간 동안 검증된 관계형 데이터베이스를 기반으로 삼고, 그 위에 개발자 경험을 크게 개선한 SaaS 환경을 구축했습니다. 기술적으로는 다소 보수적인 선택처럼 보일 수 있지만, 실제로는 매우 현실적인 전략이었죠.

Supabase는 PostgreSQL을 기반으로 인증 기능, 자동 REST API, 실시간 기능, 웹 콘솔을 통합 제공하는 플랫폼입니다. 데이터베이스를 하나 생성하는 것만으로도 서비스 개발에 필요한 기본 백엔드 환경이 곧바로 갖춰집니다. 나아가 SQL에 대한 기본적인 이해만 있다면, 별도의 백엔드 서버를 직접 구현하지 않고도 상당한 수준의 서비스를 만들 수 있습니다. 그 때문에 Supabase는 2025년 사이드 프로젝트와 초기 스타트업 환경에서 특히 많이 선택되었습니다.

Neon 역시 PostgreSQL을 기반으로 하지만, 접근 방식이 조금 다릅니다. 이 서비스는 ‘Serverless PostgreSQL’을 전면에 내세우며, 데이터베이스를 항상 실행해 두는 구조에서 벗어났습니다. 브랜치 단위로 데이터베이스 환경을 분리하고, 필요할 때만 활성화하는 방식은 CI/CD 환경이나 실험적인 개발 흐름과 잘 맞았습니다. 여러 실험을 동시에 진행해 보고 필요 없는 환경은 바로 정리할 수 있다는 특징으로, AI 기반 실험이나 빠른 프로토타이핑에 특히 적합한 구조였습니다.

MySQL 기반 서비스로 알려진 PlanetScale은 Vitess를 활용한 수평 확장과 무중단 스키마 변경이 핵심 강점이었습니다. 여기에 2024년 이후 PostgreSQL 지원이 공식적으로 더해지며 단순 MySQL SaaS를 벗어나 확장성과 운영 안정성에 초점을 둔 DB 플랫폼으로 포지셔닝을 넓혔습니다. 데이터베이스 마이그레이션이나 스키마 변경으로 서비스 운영에 부담을 느껴본 경험이 있다면, PlanetScale이 왜 꾸준히 주목받고 있는지 충분히 공감할 수 있을 것입니다.

안정성과 생산성, 그리고 생성형 AI의 등장

이들 서비스가 PostgreSQL이나 MySQL 같은 전통적인 관계형 데이터베이스를 선택하는 이유는 분명합니다. 완전히 새로운 데이터베이스를 도입해 학습 비용을 높이기보다는, 이미 익숙하고 신뢰할 수 있는 기술 위에서 개발자의 작업 흐름을 얼마나 부드럽게 만드는지가 더 중요해졌기 때문입니다. 실제 서비스 개발 현장에서는 기술의 참신함보다 안정성과 생산성이 훨씬 큰 가치를 가지는 경우가 많았습니다.

2025년이 AI 시대의 본격적인 시작이라는 점도 이 흐름을 더욱 가속화했습니다. 생성형 AI와 코드 자동화 도구가 개발 과정에 깊숙이 들어오면서, 개발자는 AI가 만들어준 코드를 빠르게 실행하고 검증할 수 있는 환경을 필요로 하게 되었습니다. 실험용 데이터베이스를 손쉽게 만들고 필요 없으면 바로 정리할 수 있는 구조는 이제 선택이 아니라 기본 요건에 가까워졌습니다.

Supabase의 관리 콘솔이나 Neon, PlanetScale의 브랜치 기반 접근 방식이 이러한 요구에 잘 부합한 방식입니다. AI가 코드를 대신 작성해주더라도, 그 결과물을 실제 서비스로 연결하고 운영할 수 있는 데이터베이스 환경이 없다면 의미가 없기 때문입니다.

결국 2025년의 데이터베이스 트렌드는 성능 경쟁보다는, 개발자의 시간을 어디에 쓰게 할 것인가에 대한 선택이었다고 볼 수 있습니다. 운영과 관리에 쓰이던 시간을 줄이고, 제품과 실험에 더 집중할 수 있도록 돕는 방향으로 데이터베이스의 역할이 재정의된 한 해였습니다. 데이터베이스가 더 이상 특정 직군만의 전문 영역이 아니라, 누구나 빠르게 선택하고 활용할 수 있는 개발 도구로 자리 잡아가고 있는 것입니다.

로컬 퍼스트와 AI 분석 흐름 속 다시 주목받은 DuckDB와 SQLite

2025년 데이터베이스 트렌드를 짚다 보니 흥미로운 대비가 하나 드러났습니다. Supabase나 Neon처럼 SaaS 기반 데이터베이스가 빠르게 확산된 한편 DuckDB와 SQLite처럼 로컬 환경에서 동작하는 데이터베이스가 다시 주목받기 시작했단 점입니다. 겉으로 보면 정반대의 흐름처럼 보이지만, 두 트렌드 모두 같은 문제의식에서 출발했다고 보는 편이 더 정확합니다. 바로 개발과 실험의 속도입니다.

로컬 퍼스트와 DuckDB, SQLite

DuckDB는 흔히 “로컬에서 실행되는 분석용 데이터베이스”로 소개됩니다. 기존의 OLAP 환경을 떠올리면, Amazon Redshift나 Google BigQuery처럼 별도 분석용 인프라를 구성하고, 데이터를 적재하는 과정이 필요했습니다. 하지만 DuckDB는 애플리케이션 내부에서 라이브러리처럼 실행되는 구조를 선택했습니다. 별도의 서버를 띄우지 않아도 괜찮고, 단일 바이너리 형태로 바로 사용할 수 있으며, CSV나 Parquet 같은 파일을 곧바로 테이블처럼 다룰 수 있다는 점이 큰 장점이었습니다.

이 구조는 2025년의 개발 환경과 매우 잘 맞았습니다. AI 모델을 실험하거나 데이터 분석을 진행할 때, 항상 대규모 분산 시스템이 필요한 것은 아니었기 때문입니다. 로컬 환경이나 단일 인스턴스에서 빠르게 데이터를 확인하며 가설을 검증하는 작업이 훨씬 많아졌고, DuckDB는 이 영역에서 압도적인 생산성을 보여줬습니다. 특히 Python이나 데이터 사이언스 워크플로우와의 궁합이 좋기에 복잡한 설정 없이 SQL 기반 분석이 가능하다는 점에서 많은 선택을 받았습니다.

SQLite 역시 비슷한 맥락에서 다시 주목받았습니다. SQLite는 새로운 기술이 아니라, 이미 수십 년간 쓰여 온 매우 안정적인 데이터베이스입니다. 다만 2025년에 다시 조명받은 이유는 단순히 ‘가볍다’는 특징 때문만은 아니었습니다. WASM(WebAssembly) 환경과 결합되면서, 브라우저나 엣지 환경에서도 데이터베이스를 직접 실행할 수 있게 된 것이 결정적이었습니다. 즉, SQLite로 서버를 거치지 않고도 로컬이나 클라이언트 환경에서 상태를 관리하고 데이터를 처리할 수 있는 가능성이 열린 셈입니다.

이러한 로컬 퍼스트(local-first) 접근 방식은 AI와 엣지 컴퓨팅 환경하고도 자연스럽게 맞물렸습니다. 모든 데이터를 중앙 서버로 보내 처리하는 방식은 비용과 지연 시간 측면에서 한계를 드러내기 시작했고, 가능한 한 가까운 위치에서 데이터를 처리하려는 시도가 늘어났습니다. SQLite는 이런 요구에 매우 잘 맞는 선택이었고, DuckDB 역시 분석 영역에서 그 역할을 꾸준히 확장해 나갔습니다.

클라우드를 보완하는 방향으로의 흐름

중요한 점은 이 흐름이 클라우드의 반대라기보다 클라우드를 보완하는 방향이라는 점입니다. 대규모 운영 데이터나 서비스용 데이터는 여전히 클라우드 기반 DB가 맡고, 실험·분석·임시 처리 영역을 로컬 데이터베이스가 담당하는 구조가 자연스럽게 자리 잡았습니다. 실제로 많은 프로젝트에서 DuckDB를 로컬 분석용으로 쓰되, 그 결과는 PostgreSQL이나 Supabase 같은 운영 DB로 옮기는 방식이 쓰였습니다.

2025년의 AI 개발 흐름을 함께 고려해보면, 이 변화는 더욱 분명해집니다. AI 모델을 활용한 서비스나 데이터 분석에서는 반복 실험이 필수적입니다. 데이터를 조금 바꿔보고, 쿼리도 수정해 보고, 결과는 바로 확인하는 과정이 수없이 반복됩니다. 이때마다 서버 환경을 새로 설정하거나, 원격 DB에 의존하는 방식은 개발 속도를 크게 떨어뜨릴 수밖에 없습니다. DuckDB와 SQLite는 이러한 반복 작업을 매우 가볍게 만들어주었기에, AI 시대의 개발 환경에 잘 어울리는 선택지로 다시 부상한 것이죠.

결과적으로 2025년은 데이터베이스가 ‘어디에서 실행되는가’에 대한 선택지가 크게 넓어진 한 해였습니다. 모든 것을 중앙 서버로 모으는 구조에서 벗어나, 상황에 따라 로컬과 클라우드를 유연하게 오가는 방식이 현실적인 해법으로 자리 잡았습니다. 결국 DuckDB와 SQLite의 재등장은 기술의 회귀라기보다는 변화한 개발 환경에 대한 매우 합리적인 반응이었다고 볼 수 있습니다.

실제로, 실무 현장에서는 어떤 데이터베이스가 쓰였나?

다만, 2025년 데이터베이스 트렌드를 이야기할 때, 필요한 질문이 하나 있습니다. “그래서 실제 현장에서는 무엇을 썼는가?”입니다. 여러 기술 블로그나 컨퍼런스에서는 새로운 데이터베이스와 아키텍처가 끊임없이 소개되지만, 스타트업과 실무 환경에서는 여전히 제한된 리소스 안에서 가장 안전한 선택을 할 수밖에 없기 때문입니다.

이러한 실무 흐름을 보여주는 가장 대표적인 지표는 매년 발표되는 Stack Overflow Developer Survey입니다. 이 설문에는 수십만 명의 개발자가 참여하며, 실제 사용 경험을 기준으로 응답한 기술 스택을 집계합니다.

최근 조사에서는 PostgreSQL이 ‘가장 널리 사용되는 데이터베이스’ 중 하나로 꾸준히 상위권을 유지하고 있고, SQLite 역시 사용 경험 항목에서 안정적인 위치를 차지한 모습입니다. Firebase 또한 데이터베이스라기보다는 백엔드 플랫폼에 가깝지만, ‘실제로 사용해본 백엔드 서비스’ 항목에서는 여전히 높은 비중을 보이고 있습니다. 2025년 실무 현장에서 느낀 분위기와도 상당히 유사한 결과입니다.

여전히 강력한 Firebase와 치고 올라온 Supabase

실제 스타트업 환경에서 Firebase는 여전히 MVP 단계에서 강력한 선택지로 쓰입니다. 인증, 데이터 저장, 스토리지, 푸시 알림까지 한 번에 제공되는 구조는 빠른 검증이 필요한 초기 프로젝트에 특히 적합합니다. 조사 지표에서도 Firebase는 ‘처음 써본 백엔드 서비스’로 자주 언급되는데, 이는 학습 비용이 낮고 즉시 결과를 만들어내기 쉽다는 의미이기도 합니다. 현장에서도 아이디어 검증이 목적이거나, 일정이 촉박한 프로젝트에서는 Firebase가 여전히 가장 먼저 고려되는 선택지였습니다.

한편 Supabase가 Firebase 이후의 현실적인 대안으로 자리 잡은 것도 주목할 만합니다. SQL 기반 데이터 모델이 필요해지거나, 혹은 데이터 구조가 점점 복잡해지는 단계에서 Supabase로 넘어가는 흐름이 자주 관찰됐습니다. Supabase는 PostgreSQL을 그대로 사용하면서도 인증, API 자동 생성, 관리 콘솔을 함께 제공하기 때문에, 전통적인 백엔드 구조로 넘어가기 전의 완충 지대 역할을 해냅니다. Supabase 측에서도 공식적으로 수백만 개 이상의 프로젝트가 생성됐다고 밝혔는데, 이는 단순한 관심을 넘어 실제 사용량이 뒷받침되고 있음을 보여주는 지표라고 볼 수 있습니다.

돌고돌아 PostgreSQL?

그럼에도 불구하고, 서비스가 일정 규모를 넘어가거나 데이터 처리 로직이 복잡해질수록 PostgreSQL 자체로 회귀하는 경우가 많았습니다. 이는 새로운 선택지가 없어서라기보다는 PostgreSQL이 오랜 시간에 걸쳐 쌓아온 생태계와 운영 경험이 여전히 강력했기 때문입니다. ORM, 마이그레이션 도구, 모니터링, 백업 전략까지 이미 검증된 선택지가 풍부하고, 문제가 발생했을 때 참고할 수 있는 사례도 충분히 축적돼 있습니다.

DB-Engines Ranking에서 PostgreSQL이 오랜 기간 상위권을 유지하고 있다는 점은, 이러한 선택이 단순한 유행이 아니라 실무에서의 지속적인 사용을 반영한 결과로 볼 수 있습니다.

흥미로운 건 AI 기술이 빠르게 발전했음에도 불구하고 데이터베이스의 선택 자체는 오히려 더 보수적으로 이뤄졌다는 점입니다. 이는 AI가 쿼리 작성이나 코드 생성에는 큰 도움을 주어도, 데이터베이스를 선택하고 운영하는 책임은 여전히 사람에게 남아 있었기 때문으로 보입니다. AI가 만들어준 코드를 신뢰하려면, 그 코드가 실행되는 데이터베이스 환경만큼은 최대한 안정적이어야 한다는 판단이 작용한 것입니다. 이 때문에 실무에서 검증된 데이터베이스와 플랫폼을 선호하는 경향이 더욱 분명해졌습니다.

정리해보면, 2025년 실무 현장에서의 데이터베이스 선택은 기술 트렌드를 그대로 따라가기보다는, 프로젝트의 단계와 목적에 맞춰 조합하는 방향으로 이뤄졌습니다. Firebase는 빠른 검증을 위해, Supabase는 생산성을 위해, PostgreSQL은 안정적인 운영을 위해 선택되었습니다. 데이터베이스는 더 이상 단일한 정답이 있는 영역이 아니라, 상황에 따라 유연하게 선택하고 교체하는 도구가 됐습니다. 그런 점에서 2025년은 데이터베이스를 바라보는 관점 자체가 한 단계 성숙해진 해였다고 느껴집니다.

기술 트렌드와 실무 간극을 돌아보다

지금까지 2025년 데이터베이스 트렌드를 정리해봤지만, 실제 현장에서 데이터베이스를 선택할 제게 주어진 고민은 훨씬 더 단순하면서도 무거웠습니다. 트렌드를 몰라서 따르지 않은 것이 아니라, 알고 있음에도 불구하고 다른 선택을 해야 했던 순간이 많았기 때문입니다. 이 간극은 제가 경험한 두 가지 프로젝트에서 특히 또렷하게 드러났습니다.

트렌드와 실무의 간극을 느낀 2가지 프로젝트

규모 있는 서비스와 MySQL

첫 번째 상황은 현재 프로덕션을 운영 중인 회사의 프로젝트입니다. 이 환경에서는 여러 팀이 하나의 데이터베이스를 함께 사용하고 있었고, 서비스 역시 이미 일정 규모 이상으로 성장해 있었습니다. 이런 상황에서 데이터베이스 선택의 기준은 분명했습니다. 최신 기술이나 생산성보다는 안정성과 신뢰성이 최우선인 것이죠. 지금 서비스는 메인 데이터베이스로 MySQL을 사용하고 있었는데, 기술적으로 가장 화려한 선택은 아니었지만 오랜 시간 검증된 안정성을 제공해주고 있습니다.

이 환경에서 특히 중요하게 느낀 점은 데이터베이스 자체보다, 그 데이터베이스를 얼마나 안정적으로 운영할 수 있는 구조를 갖추고 있는지 여부였습니다. 레플리카 구성, 장애 발생 시의 fallback 전략, 백업과 복구 시나리오 같은 요소들은 실제 운영 단계에서 훨씬 더 크게 작용합니다. 데이터베이스는 한 번 세팅하고 나면 변경 비용이 매우 크기 때문에, ‘나중에 바꾸면 되지’라는 선택을 하기가 쉽지 않습니다. 결국 이 프로젝트에서는 최신 트렌드를 좇기보다는 여러 팀이 동시에 사용해도 흔들리지 않는 구조를 만드는 데 집중하게 됐습니다.

빠르게 성장하는 서비스와 Supabase

두 번째 경험은 이와 정반대의 상황이었습니다. 직전 회사에서 진행했던 초기 프로젝트인데, 약 3개월 남짓한 기간 동안 사용자가 빠르게 증가해 최대 15만 명 수준까지 도달했습니다. 당시 백엔드 개발자는 단 두 명뿐이었고, 데이터베이스 설계부터 API 개발, 인프라 운영과 유지보수, 고객 대응까지 대부분의 백엔드 업무 모두를 감당해야 했습니다. 그러면서도 빠른 런칭과 지속적인 기능 추가가 가장 중요한 목표로 잡혔습니다.

이 상황에서 선택한 데이터베이스 플랫폼이 바로 Supabase였습니다. 인증, API, 관리 콘솔 등 많은 부분을 대신해주어서 제한된 인력으로도 빠르게 서비스를 만들어낼 수 있었습니다. 실제로 초기 성장 국면에서는 Supabase 덕분에 개발 속도를 크게 끌어올릴 수 있었고, 인프라 운영에 쓰이던 시간을 최소화할 수 있었습니다.

다만 서비스가 성장하고 백엔드 팀 인원이 점차 늘어나면서, 다른 문제가 하나둘 나타나기 시작했습니다. 기능 요구사항이 복잡해지면서 Supabase가 제공하는 기본 기능만으로는 한계가 느껴졌고, 결국 별도의 백엔드 애플리케이션이 필요한 시점이 찾아왔습니다. 비용 문제도 무시할 수 없었습니다. Supabase는 소규모 팀이나 초기 단계에서는 매우 효율적인 선택이었지만, 팀과 서비스 규모가 커질수록 비용 구조와 유연성 측면에서 부담이 커졌습니다.

결국 내부적으로 사용하던 PostgreSQL을 중심으로 아키텍처를 다시 정비해야 했습니다. Supabase 역시 PostgreSQL을 기반으로 하고 있었기 때문에 마이그레이션 자체는 가능했지만, 결코 가볍게 결정할 수 있는 작업은 아니었습니다. 이 경험을 통해 느낀 점은, Supabase가 나쁘다기보다는 모든 단계의 팀에 적합한 도구는 아니라는 사실이었습니다.

데이터베이스 선택에 정답은 없다

이 두 가지 경험을 돌아보면, 데이터베이스 선택에서 가장 중요하게 고려할 요소는 성능만이 아니었습니다. 데이터베이스는 서비스의 핵심 자산인 데이터를 보관하는 공간이기 때문에, 결국에는 보수적으로 접근할 수밖에 없습니다. 트렌드에 따라 BaaS를 사용해보기도 했고, 새로운 플랫폼도 적극적으로 검토해봤지만, ‘최신이냐 아니냐’가 결정의 핵심 기준이 되지는 않았습니다.

실무에서 데이터베이스를 다룰 때 가장 중요한 능력은 지금 내가 만들고 있는 서비스에서 무엇이 중요한지 정의하는 일이라고 생각합니다. 다루는 데이터의 특성은 어떤지, 읽기와 쓰기 중 어느 쪽이 더 중요한지, 단순한 CRUD가 중심인지 아니면 부가 기능이 중요한지, 이 같은 기준을 먼저 세워야 합니다. 그다음에야 비로소 여러 데이터베이스와 플랫폼을 비교할 수 있습니다. 이 순서가 바뀌면 트렌드에 끌려 불필요한 선택을 하게 될 가능성만 커집니다.

2025년을 돌아보며 느낀 점은 분명합니다. 데이터베이스의 트렌드는 참고 자료일 뿐, 정답이 아닙니다. 실무에서는 언제나 서비스의 현재 상태와 팀의 역량이 먼저이고, 그 위에 기술 선택이 따라와야 합니다. 이 간극을 인식하고 스스로 판단할 수 있는 능력이야말로, 결국 실무에서 가장 중요한 역량 중 하나라고 생각합니다.

마치며

2025년 데이터베이스 트렌드를 정리하다 보니, 기술 자체보다 그 기술을 어떻게 선택하고 사용했는지가 더 중요했다는 생각이 다시금 들었습니다. Supabase, Neon, DuckDB, SQLite 같은 새로운 흐름은 분명 의미 있는 변화를 만들었고, 실제로 많은 실험과 성과로 이어졌습니다. 그 한편에서 MySQL이나 PostgreSQL처럼 오래된 기술이 여전히 현장의 중심을 잡고 있다는 사실도 분명했죠.

이 두 가지의 공존이 2025년을 상징한다고 느꼈습니다. 한쪽에서는 개발 속도와 실험을 극대화하기 위한 SaaS와 BaaS가 빠르게 퍼지고, 다른 한쪽에서는 안정성과 신뢰성을 최우선으로 하는 보수적인 선택이 이어졌습니다. 어느 쪽이 옳다기보다는 각자 선택이 필요한 순간이 분명히 존재했다고 보는 편이 더 정확할 것 같습니다.

개인적으로 가장 크게 느낀 변화는, 데이터베이스를 바라보는 기준이 예전보다 훨씬 현실적으로 바뀌었다는 점입니다. “이 DB가 최신인가”, “트렌드에 맞는가”보다는 “지금 이 팀과 이 서비스에 적합한가”, “지금 당장 감당할 수 있는가”가 훨씬 중요한 질문으로 떠올랐습니다.

데이터베이스는 한 번 선택하면 오랜 시간 함께 가야 하는 인프라이기 때문에, 결국 보수적인 판단으로 기울 수밖에 없습니다. AI와 SaaS가 빠르게 발전하는 시대이지만, 그럴수록 데이터베이스 선택은 더 신중해질 수밖에 없다고 느낍니다. 코드는 AI가 도와준다 해도 데이터는 여전히 서비스의 가장 중요한 자산이기 때문입니다. 그래서 2025년을 돌아보면, 새로운 기술을 적극적으로 실험하면서도 동시에 기본에 충실하려는 움직임이 함께 나타난 해였다고 정리하고 싶습니다.

앞으로도 데이터베이스 기술은 꾸준히 변할 것입니다. 하지만 어떤 기술이 등장한다 해도 실무에서 가장 중요한 것은 트렌드를 그대로 따라가는 일이 아니라, 지금 내가 만들고 있는 서비스에 무엇이 중요한지를 먼저 정의하는 능력이라고 생각합니다. 그 기준이 분명하다면, 데이터베이스 선택은 자연스럽게 따라오게 될 것입니다.

이 글이 2025년을 돌아보며, 각자의 상황에 맞는 데이터베이스를 고민하는 데 작은 도움이 되었으면 합니다.

]]>

AI 시대의 데이터 분석: AI는 정말 세상을 이해할 수 있을까?

데이터 분석은 숫자를 계산하는 일이 아니라, 숫자로 투영된 현실을 해석하는 일입니다. 이 시리즈는 동일한 방식으로 세상을 바라보는 AI라는 새로운 지능이 등장한 시대에, 데이터·AI·인간 분석가의 역할이 어떻게 재정의되어야 하는지를 총 2편에 걸쳐 탐구합니다. 1편에서는 AI가 텍스트라는 ‘그림자’를 통해 세상을 학습하게 되는 원리와 그 과정에서 드러나는 근본적인 한계를 짚어보고, 2편에서는 AI를 활용한 데이터 분석에서 인간 분석가가 끝까지 맡아야 할 역할이 무엇인지에 대한 결론으로 나아갑니다.

미리 요점만 콕 집어보면?
데이터 분석은 숫자를 계산하는 일이 아니라, 숫자로 투영된 현실을 해석하는 일입니다.
텍스트는 현실의 투영이며, LLM이 학습하는 대상은 현실 그 자체가 아니라 인간의 인식과 언어를 거쳐 만들어진 거대한 텍스트 투영 집합입니다.
AI는 이 숫자들을 빠르고 그럴듯하게 해석할 수 있지만, 그 해석을 현실의 맥락 속에 다시 위치시키는 책임까지 대신할 수는 없습니다.

AI 시대에서 데이터 분석을 한다는 것은 무엇일까?

안녕하세요, HEARTCOUNT의 기획자 David입니다. 지난 글에서는 AI가 코드 작성과 계산을 자동화하는 시대에도, 인간 고유의 '통계적 사고(Statistical Thinking)'가 왜 여전히 필수적인지에 대해 다루었습니다. LLM은 과거 데이터의 패턴을 학습한 '확률적 도구'로서 반사실적 사고(Counterfactual Reasoning)나 미래지향적 추론에 근본적인 한계가 있을 수 있지만, 인간의 인과적 추론을 돕는 시뮬레이터로서 결합될 때 더 나은 의사결정을 이끌어낼 수 있다는 결론을 내렸죠.

하지만 그 짧은 사이에도 AI 에이전트와 파운데이션 모델들의 성능은 무서울 정도로 발전했습니다. 단순한 '보조 도구'를 넘어 스스로 복잡한 작업을 수행하는 주체로 진화하고 있는 현실이죠. 결국에는 AGI가 다가올 것이라고 모든 연구자가 동의하고 있다는 이 시기에, 모든 지식 노동자와 지식 노동을 돕겠다고 주장하는 제품들은 근본적인 정체성과 역할에 대해 자문할 수밖에 없습니다.

HEARTCOUNT 역시 이러한 시기에 발맞추어 제품을 혁신적으로 개편하기 위해 여러 가지 시도를 지속하고 있는데요. 이참에 AI 시대에 데이터 분석을 한다는 것이 무엇인지 다시 한번 근본적으로 질문해 보고자 합니다. 정답을 내기보다는, 질문거리를 스스로 던져본다는 차원에서 말이죠.

LLM이 세상을 이해하는 방식

우리가 흔히 농담 반 진담 반으로 "AGI가 오면 어차피 다 끝난다"고 말하지만, 제품 기획자로서 그 '특이점' 이전에 우리가 마주하고 있는 이 기술의 실체가 무엇인지 이해하고 대응하는 게 제 일이겠지요. OpenAI의 전 수석 과학자이자 학계를 주도하는 핵심 인물인 일리야 수츠케버(Ilya Sutskever)의 발언을 중심으로 정리해보겠습니다.

우리는 흔히 LLM을 '다음 단어 맞추기 게임을 하는 기계', 즉 확률론적 앵무새라고 폄하하곤 합니다. 하지만 이 단순해 보이는 게임이 어떻게 인간 수준의 추론과 창의성을 보여주는 단계로 진입했는지, 그 기저에 깔린 공학적, 철학적 원리를 이해해야 합니다.

텍스트는 현실의 투영이다

일리야 수츠케버는 LLM의 "다음 단어 예측"을 단순한 통계적 확률 게임으로 보지 않습니다. 그는 이를 "세상의 투영(Projection)과 이해(Understanding)" 과정으로 정의합니다. 일리야와 젠슨 황과의 대화를 볼까요?

젠슨 황: 많은 사람들이 챗GPT가 단지 거대 언어 모델(LLM)라고 오해합니다. 하지만 단순히 통계적인 상관관계만 배우는 것 아닌가요?

일리야 수츠케버: 겉보기에는 텍스트의 통계적 상관관계만 배우는 것처럼 보일 수 있습니다. 하지만 실제로 일어나는 일은 다릅니다. 신경망이 텍스트를 정말 잘 압축하기 위해 학습하는 것은 바로 '세계 모델(World Model)'입니다. 텍스트는 사실 '세상의 투영(Projection of the world)'입니다. 저 바깥에는 실재하는 세상이 있고, 그 세상이 텍스트라는 형태로 투영된 것입니다. 신경망이 다음 단어를 정확히 예측하기 위해 배우는 것은, 그 텍스트를 만들어낸 기저의 프로세스, 즉 사람들의 희망, 꿈, 동기, 상호작용, 그리고 우리가 처한 상황들에 대한 압축되고 추상화된 표현입니다.

젠슨 황: 단순히 글자를 배우는 게 아니라, 글 뒤에 있는 사람과 세상을 배운다는 거군요.

일리야 수츠케버: 맞습니다. 다음 단어를 더 정확하게 예측할수록, 이 과정에서 얻는 '해상도(Resolution)'와 '충실도(Fidelity)'가 높아집니다. 즉, 세상을 더 선명하게 이해하게 되는 것이죠.

그러니까 일리야가 보기에는 LLM의 성능 향상은 단순히 “말을 그럴듯하게 하는 능력”의 증가가 아니라, 세계를 더 정교하게 압축하고 재현하는 내부 모델의 해상도가 높아지는 과정에 가깝습니다. 다음 단어 예측이라는 목표는 변하지 않았지만, 그 목표를 달성하기 위해 내부적으로 형성되는 세계 모델은 점점 더 많은 인과 관계, 맥락, 인간의 의도를 포괄하게 됩니다. 이 관점에서 보면 “통계적 모델 vs 이해하는 지능”이라는 이분법 자체가 오해에 가까울 수도 있습니다. 통계적 학습이 충분히 큰 스케일과 적절한 구조를 갖출 때, 그것은 곧 이해로 이어질 수 있다는 주장인 셈이죠.

투영된 세계를 학습하는 방식

여기서 잠시 ‘투영(Projection)’이라는 표현을 짚고 넘어가봅시다. 일리야가 말하는 “텍스트는 세상의 투영”이라는 표현도 이 맥락에 놓여 있습니다. 인간이 남긴 텍스트는 현실 세계 그 자체가 아니라, 세계를 인식하고 해석하고 의미화한 결과가 언어라는 저차원 공간으로 투영된 산물입니다. 정치, 경제, 과학, 감정, 욕망, 갈등 같은 고차원의 현실이 문장과 단어라는 제한된 표현 수단으로 압축되어 기록된 것이죠. 따라서 LLM이 학습하는 대상은 ‘현실’이 아니라, 현실이 인간의 인식과 언어를 거쳐 만들어진 거대한 텍스트 투영 집합이라고 볼 수 있습니다.

Text is a projection of the reality

흥미로운 지점은 바로 여기입니다. 투영은 정보 손실을 수반하지만, 충분히 많은 관측과 다양한 각도의 투영이 쌓이면 원래의 구조를 역으로 추론할 수 있습니다. 여러 방향에서 찍은 X-ray 이미지로 인체 내부 구조를 재구성하듯이, 방대한 텍스트 데이터는 세계에 대한 수많은 단면을 제공합니다. LLM이 다음 단어를 잘 예측하기 위해 내부적으로 학습하는 것은, 이 단면들 사이에 공통적으로 존재하는 생성 규칙과 인과 구조, 즉 “이런 상황에서는 사람들이 보통 이렇게 말하고, 이렇게 행동한다”라는 세계의 작동 원리라는 주장인 것이죠.

스케일링 법칙이 만든 '정교한 세계모델'

이제 자연스럽게 스케일링 법칙(Scaling Law)으로 이야기를 옮길 수 있습니다. 스케일링 법칙이란, 모델의 성능이 특정한 기법이나 아키텍처 변화에 의해 불연속적으로 도약하는 것이 아니라, 모델의 크기·데이터의 양·투입되는 연산 자원을 늘릴수록 점진적으로 개선되는 경향을 보인다는 경험적 관찰입니다. 충분히 큰 모델과 충분한 데이터, 충분한 연산량이 주어지면 손실은 꾸준히 줄어들고, 성능 향상은 우연이 아니라 예측 가능한 결과로 나타납니다.

이 법칙의 중요한 함의는 지능이 어느 순간 갑자기 ‘생겨나는 것’이 아니라, 세계를 압축하고 재현하는 능력이 점점 더 정밀해지는 과정 속에서 서서히 드러난다는 점입니다. 앞서 말했듯, 텍스트가 세상의 투영이라면 LLM의 학습이란 결국 이 투영된 세계를 얼마나 정교하게 복원하고 시뮬레이션할 수 있는가의 문제로 귀결됩니다. 다음 단어 예측이 충분히 잘 수행된다는 것은, 단순한 언어 기술을 넘어 세계를 만들어낸 기저 구조를 점점 더 높은 해상도로 포착하고 있다는 신호일 수 있습니다.

스케일링 법칙이 여전히 유효하게 작동하는 이유도 여기에 있습니다. 자원을 더 많이 투입할수록 성능은 계속 개선되지만, 그 과정은 처음에는 빠르게 좋아지다가 이후로 갈수록 미세하게 정밀해지는 곡선을 따릅니다. 이는 단순히 더 많은 정보를 외운 결과가 아니라, 모델 내부에서 형성되는 세계 모델의 해상도(resolution)와 충실도(fidelity)가 함께 높아지고 있음을 의미합니다. 더 큰 모델은 더 많은 인과 관계를 동시에 유지하고, 더 긴 맥락을 안정적으로 추론하며, 이전에는 통계적 잡음으로 보이던 신호를 점차 구조로 인식하기 시작합니다.

데이터가 많아지면 현실을 완전하게 이해할 수 있을까?

과학적 환원주의의 한계 : 텍스트와 현실의 괴리

앞서 살펴본 투영과 스케일링의 논의를 종합해 보면, 현재의 LLM은 현실 그 자체가 아니라 현실이 텍스트로 환원된 그림자를 극도로 정교하게 학습하고 있는 존재에 가깝습니다. 텍스트는 고차원의 연속적인 세계가 인간의 언어 체계를 거치며 저차원의 이산적 기호로 압축된 결과물이기 때문에, 아무리 해상도를 높인다 해도 본질적인 정보 손실은 피할 수 없습니다. 이는 단순한 기술적 한계라기보다, 세계를 언어로 환원하는 순간부터 발생하는 구조적 제약입니다. 이 이점을 이해하기 위해 과학적 환원주의를 떠올릴 수 있습니다.

과학적 환원주의란?
과학적 환원주의는 인간의 사고나 지능 같은 복잡한 현상도 궁극적으로는 물리 법칙이나 계산 가능한 규칙으로 설명할 수 있다고 보는 관점이다. 이 접근은 현상을 정량화하고 예측 가능하게 만든다는 점에서 강력하지만, 동시에 맥락·질적 차이·경험적 차원이 탈락될 수 있다는 한계를 내포한다.

이 관점에서 보면 LLM은 ‘지능’을 손실 함수의 최소화로, ‘이해’를 예측 정확도의 향상으로 환원합니다. 이 환원은 강력한 설명력을 가지지만 동시에 위험합니다. 손실 값이 줄어들었다는 사실은 모델이 텍스트 상의 규칙과 패턴을 더 잘 포착했다는 의미이지, 그것이 곧 세계에 대한 내적 이해를 획득했다는 증거는 아니기 때문입니다. 텍스트로부터 역문제를 풀어 현실을 재구성하는 과정은 본질적으로 불완전하며, 그 결과로 만들어진 세계 모델은 언제나 실제 세계보다 얇고 평평한 표현에 머물 수밖에 없습니다.

벤치마크와 현실 사용 경험의 간극

이 괴리는 실제 제품과 서비스의 현장에서 더욱 분명하게 드러납니다. 파운데이션 모델들은 벤치마크 점수, 손실 감소율, 특정 태스크 정확도와 같은 지표를 앞세워 비약적인 성능 향상을 주장하지만, 정작 현실의 사용자들이 체감하는 경험은 그 기대에 미치지 못하는 경우가 적지 않습니다. 그 이유는 많은 평가 지표들이 현실 세계의 복잡성과 불완전성을 충분히 반영하지 못하기 때문입니다.

벤치마크는 정의된 입력과 정답이 존재하는 닫힌 환경을 전제로 하지만, 실제 사용 환경은 모호한 목표, 불완전한 정보, 끊임없이 변하는 맥락 속에서 작동합니다. 모델은 지표 상에서는 ‘정답에 가까운 문장’을 생성할 수 있지만, 사용자는 그 결과를 실제 의사결정이나 행동으로 옮겨야 하며, 이 지점에서 드러나는 미묘한 오해, 과잉 확신, 맥락 누락은 지표로는 포착되지 않습니다. 결국 “잘 맞히는 모델”과 “쓸모 있는 모델” 사이의 간극은, 지능과 이해를 수치로 환원한 평가 체계가 현실과 맞닿아 있는 사용 경험을 충분히 대변하지 못하는 데서 발생한다고 볼 수 있습니다.

중국어 방 논증: 성능과 이해는 다르다

이 지점에서 자연스럽게 떠오르는 고전적인 사고실험이 있습니다. 바로 철학자 존 설(John Searle)의 중국어 방(Chinese Room) 논증입니다. 워낙 유명한 실험이지만, 지금 우리가 이야기하고 있는 LLM과 세계 이해의 문제를 다시 비춰보기에 이만큼 적확한 비유도 드뭅니다.

중국어 방 사고실험은 기호를 다루는 능력과 의미를 이해하는 능력 사이의 간극을 드러냅니다. 중국어를 전혀 모르는 사람이 규칙서에 따라 기호를 조작해 완벽한 중국어 답변을 만들어낼 수 있지만, 그 과정 어디에도 문장의 의미에 대한 이해는 개입하지 않습니다. 겉으로 보기에는 완전한 대화처럼 보이지만, 내부에는 ‘무엇을 말하고 있는지에 대한 앎’이 존재하지 않는다는 것이죠.

이 논증은 LLM에도 거의 그대로 적용됩니다. LLM은 단어의 의미를 이해해서 문장을 생성하는 것이 아니라, 학습된 확률적 규칙에 따라 기호를 배열합니다. 문법과 맥락, 감정 표현까지 정교하게 재현할 수 있지만, 이는 구문론(Syntax)의 숙련이지 의미론(Semantics)에 대한 체험적 이해를 보장하지는 않습니다.

중국어 방 논증이 특히 날카로운 이유는, “성능이 충분히 좋으면 이해로 봐도 되지 않느냐”는 직관을 정면으로 거부하기 때문입니다. 설은 시스템 반론, 로봇 반론, 뇌 시뮬레이터 반론 등 다양한 반박을 하나씩 무너뜨리며, 기호 조작의 정교함이 의미의 발생을 보장하지 않는다는 점을 끝까지 밀어붙입니다. 규칙이 아무리 복잡해져도, 입력과 출력이 아무리 현실과 잘 맞아떨어져도, 그것만으로는 ‘무엇을 하고 있는지 아는 상태’가 만들어지지 않는다는 주장입니다.

AI가 현실에 발을 딛기 시작하는 지점

흥미로운 사실은, 일리야 본인 역시 “다음 단어 예측이 곧 지능의 완성형이다”라고 단순하게 믿고 있지는 않다는 점입니다. 최근 영상을 볼까요?

그는 반복해서 현재의 모델들이 보여주는 성과와 인간 지능 사이에 존재하는 질적 간극을 인정합니다. 특히 표본 효율성(sample efficiency)은, 수조 개의 토큰을 소비하면서도 여전히 불안정한 일반화를 보이는 현재의 파운데이션 모델들이 도달하지 못한 영역입니다.

표본 효율성(sample efficiency)
'얼마나 적은 양의 데이터(경험)만으로도 복잡한 개념을 이해하고 새로운 상황에 적용(일반화)할 수 있는가'를 나타내는 지표. 이는 지능의 수준을 평가하는 핵심 척도로, 단순히 많은 데이터를 암기하는 것이 아니라 데이터 속에 숨겨진 '생성 원리(Underlying Process)'를 얼마나 빠르고 정확하게 파악하는지를 의미한다.

19년 정도의 삶만 경험한, 갓 성인이 된 청년을 생각해봅시다. 이 인간은 거대한 AI 모델이 학습하는 데이터의 극히 일부만을 경험합니다. 하지만 이 청년은 약 10~20시간의 연습만으로도 복잡한 물리 법칙과 사회적 약속이 얽힌 '운전'을 배울 수 있습니다. 일리야가 이를 “거대한 미스터리”라고 표현한 이유도 여기에 있습니다. 단어 예측이라는 목표는 분명 강력하지만, 그것만으로 인간 수준의 학습 메커니즘을 설명하기에는 부족하다는 자각이 이미 내부에 존재한다는 뜻이죠.

스케일링 법칙 너머의 질문

이러한 문제의식은 일리야 수츠케버가 언급한 “스케일링의 시대에서 다시 연구의 시대로의 전환”이라는 발언(위 영상)에서도 드러납니다. 더 큰 모델과 더 많은 데이터를 투입하는 사전 학습은 일정 수준까지 효과적이었지만, 인간과 같은 일반화 능력에 도달하기에는 효율이 빠르게 떨어지고 있으며, 온라인 데이터 역시 한계에 다다르고 있습니다.

그래서 일리야는 단순히 텍스트를 더 많이 학습시키는 대신, 탐색(exploration), 가치 함수(value function), 강화 학습(reinforcement learning)과 같은 메커니즘을 통해 적은 경험으로도 중요한 구조를 학습할 수 있는 새로운 방식이 필요하다고 주장합니다. 이는 지능을 데이터 양의 문제로만 환원하던 관점에서 벗어나려는 명확한 신호입니다.

또한 그는 텍스트 중심 학습의 한계 역시 분명히 인식하고 있습니다. 인간은 언어뿐 아니라 시각·공간·감각 경험을 결합해 세상을 이해하며, 이러한 경험이 더해질 때 이해의 해상도는 질적으로 도약합니다. 이는 텍스트가 세계를 설명하는 강력한 투영이면서도, 본질적으로 손실을 내포한 압축 표현임을 보여줍니다.

결국 일리야의 입장은 단순한 낙관론도, 단호한 부정도 아닙니다. 다음 단어 예측은 세계 모델을 형성하는 데 있어 매우 강력한 출발점이지만, 그것이 지능의 종착점이라고 보지는 않습니다. 오히려 현재의 성공이야말로, 왜 이 방식이 잘 작동하는지, 그리고 어디에서부터 더 이상 작동하지 않는지를 진지하게 연구해야 할 시점이라 주장하고 있지요.

피지컬 AI를 통한 현실과 텍스트의 접점 찾기

다시 중국어 방 사고실험으로 돌아가서, 해당 사고실험에서 던진 질문은 결국 하나로 수렴합니다. “기호를 아무리 잘 다루어도, 그것이 곧 의미를 아는 것은 아니다.” 그렇다면 이 간극을 메우는 길은 어디에 있을까요. 최근 피지컬 AI가 주목받는 이유는 바로 이 질문에 대한 가장 현실적인 답변을 제시하기 때문일 것입니다.

기존 LLM이 다루는 세계는 텍스트로만 구성된 공간입니다. ‘사과는 빨갛다’, ‘무겁다’, ‘미끄럽다’ 같은 문장은 생성할 수 있지만, 그것이 실제로 어떤 감각인지 알지는 못합니다. 피지컬 AI는 여기에 신체를 추가합니다. 로봇이 사과를 집어 들 때 느끼는 압력, 무게, 미끄러짐은 단어에 실체를 부여합니다. 인간이 ‘뜨겁다’를 이해할 때 화상 경험을 떠올리듯, AI 역시 언어를 감각 경험과 연결하기 시작하는 순간, 기호는 설명이 아니라 기억이 됩니다.

인과성에 대한 직관 개발의 영역도 있습니다. 텍스트는 대부분 “A 다음에 B가 온다”는 상관관계를 담고 있습니다. 하지만 현실 세계는 “A를 하면 B가 일어난다”는 인과관계로 움직입니다. 컵을 책상 끝에서 밀면 떨어진다는 사실은 문장으로 이해하는 것과 실제로 컵을 떨어뜨려 보는 것은 완전히 다릅니다. 피지컬 AI는 직접 행동하고 그 결과를 관찰함으로써, 세상이 왜 그렇게 움직이는지를 학습합니다. 이는 통계적 추론을 넘어, 물리 법칙에 기반한 직관을 형성하게 합니다. 즉, 기호 접지가 비로소 성립되는 것이죠.

기호 접지(Symbol Grounding)
기호(단어)가 실제 세계의 사물·행동·감각과 직접 연결되어 의미를 갖게 되는 것을 뜻한다.

피지컬 AI는 단순한 로봇 제어가 아니라, (보다 - 이해하다 - 행동한다)라는 하나의 순환 구조로 진화하고 있습니다. 언어 모델이 계획을 세우고 판단을 내리면, 저수준 제어 시스템이 즉각적인 움직임을 담당합니다. 인간으로 치면 “조심해서 컵을 들어야겠다”라고 판단하는 사고와, 손의 미세한 힘 조절이 동시에 이루어지는 것과 같습니다.

결국 피지컬 AI는 텍스트가 충분히 투영하지 못하는 현실 세계와 언어 모델이 실제로 맞닿을 수 있는 접점을 만들어냅니다. 다음 단어를 예측하는 데서 출발한 지능이, 이제는 물질계의 다음 상태를 상상하고 그 결과에 책임지는 방향으로 확장되는 순간입니다. 언어 모델이 세상을 설명하는 능력이라면, 피지컬 AI는 세상을 살아보는 능력을 더합니다. 이 둘의 결합은 AI가 더 그럴듯하게 말하는 존재가 되는 것이 아니라, 현실의 제약 속에서 실패하고 수정하며 배워가는 존재로 진화하고 있다는 것이겠죠. 그리고 아마도 우리가 ‘이해’라고 부를 수 있는 지점은, 바로 그 과정 어딘가에 놓여 있을 것입니다.

1편을 마치며

이번 글에서는 LLM이 텍스트라는 투영을 통해 세계 모델을 형성하는 과정과, 그 성능 향상이 어디까지를 의미하는지 살펴보았습니다. 다음 단어 예측은 세계의 구조를 점점 더 정교하게 포착하지만, 그것이 곧 현실에 대한 이해를 의미하지는 않습니다. 이 한계는 데이터 분석에서도 그대로 반복됩니다. 데이터 역시 현실 그 자체가 아니라, 측정과 기록을 거쳐 숫자로 환원된 결과이기 때문입니다. AI는 이 숫자들을 빠르고 그럴듯하게 해석할 수 있지만, 그 해석을 현실의 맥락 속에 다시 위치시키는 책임까지 대신할 수는 없습니다.

2편에서는 이러한 전제를 바탕으로, 할루시네이션을 넘어 실제 의사결정으로 이어지기 위해 필요한 접지 전략과 AI를 활용한 데이터 분석에서 인간 분석가의 정체성에 대한 고민의 결론을 내려보겠습니다.

<원문>

AI 시대의 데이터 분석 (1) AI는 정말 세상을 이해할 수 있을까

]]>

세계 최초 AI 기본법 시행, 그래서 뭐가 중요할까?

오늘은 법에 대한 이야기를 한번 해보려고 합니다. 요즘IT에서 갑자기 웬 법이지?라고 생각하실 수도 있지만, 바로 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법(이하 AI 기본법)에 대한 이야기입니다. 이 법은 지난 1월 22일부터 본격적으로 시행되었기에, 한 번쯤 짚어볼 만한 의미가 있는데요.

대부분의 IT 종사자에게 법은 익숙하지 않은 영역일 수 있습니다. 특히 특정 도메인이 아니라면, 법과는 거리가 있는 경우가 많죠. 하지만 ‘법 종사자’가 아니더라도, 누구나 법제처에서 제공하는 국가법령정보센터를 통해 법률 원문을 쉽게 확인할 수 있습니다.

또한 법은 가장 오래된 형태의 문서화 결과물이기도 합니다. 그래서 일반인도 이해할 수 있도록, 법의 목적과 용어 정의부터 주요 조항까지 체계적으로 구성되어 있죠. 덕분에 법무팀이나 법 전문가가 아니더라도, 충분히 한 번쯤 읽어볼 만합니다. 더욱 흥미로운 점은, 이처럼 복잡할 수 있는 법령 검색조차 이제는 AI를 통해 보다 쉽고 편리하게 접근할 수 있다는 사실입니다. 그럼 지금부터 AI 기본법에 대해 하나씩 살펴보겠습니다.

미리 요점만 콕 집어보면?
우리나라 AI 기본법은 2026년 1월 22일부터 시행되는 세계 최초의 AI 기본법으로, AI의 발전 지원과 신뢰 확보를 동시에 목표로 합니다.
법은 총 6장으로 구성되며, 2~3장은 산업 육성과 정부 지원을, 4장은 고영향·생성형 AI 사업자의 윤리·투명성·안전성 의무를 규정합니다.
특히 생성형 AI 사용 사실의 명확한 고지와 고영향 AI에 대한 관리가 핵심이며, 초기 혼란을 고려해 과태료 등은 1년 유예됩니다.

<출처: 법제처 지능형 법령검색 시스템>

AI 기본법이 뭔데요?

그렇다면 AI 기본법이 뭐길래 화제일까요? 우선 가장 큰 이유는 우리나라의 AI 기본법이 전 세계 최초로 시행되는 AI 기본법이라는 점입니다. 사실 EU가 법률로 명시하는 법제화를 먼저 시작했지만, 시행을 올해 8월로 미루면서 우리나라가 세계 최초로 이를 시행하게 되었습니다. 이에 대해서는 선제적 대응을 통해 퍼스트 무버(First Mover)로서 AI에 대한 기회를 만들 수 있다는 긍정적인 시선과, 해외에 비해 ‘규제’가 먼저 적용되기 때문에 여러 혼란이 있을 수 있다는 우려가 함께 존재합니다.

EU의 AI 기본법의 경우, 위험도에 따라 AI 사용을 금지할 수 있다는 점, 예외 대상이 더 많다는 점, 벌금 규모가 훨씬 크다는 점 등을 들 수 있습니다.

<출처: 한국일보>

우리나라의 AI 기본법은 크게 본문과 부칙으로 구성됩니다. 여기서 본문은 법의 목적으로 하는 실질적인 내용을 담고 있는 부분이고, 부칙은 이어지는 이미지와 같이 본문의 규정들이 언제 어떻게 누구에게 적용되는지 등 기술적인 내용을 담고 있습니다. AI 기본법의 부칙에서는 법이 공포(공개)된 2025년 1월 21일부터 1년 후인 2026년 1월 22일부터 시행되고, 일부 내용은 6개월 간의 유예 기간을 허용하는 것을 설명하고 있습니다.

<출처: 국가법령정보센터>

AI 기본법의 흐름 이해하기

<출처: 작가>

AI 기본법의 본문은 여섯 개의 장으로 구성되어 있습니다. 먼저 1장은 AI 기본법의 “총칙”으로 법의 목적과 정의, 기본 원칙들을 설명하는 나침반으로써 해석의 기준이 됩니다. 이어 2장에서는 추진체계를 설정하는데 인공지능 정책을 누가 이끌어 갈 것인지 설정합니다. 예를 들면, “국가인공지능전략위원회”와 같은 기구를 설치해야 한다는 법을 정하거나, 이러한 기구에서 어떠한 업무를 해야하는 지를 정합니다.

3장은 AI 기본법의 두 가지 핵심 목적 중 하나인 “산업 지원”에 대한 내용을 다루고 있습니다. 연구개발 지원, 전문 인력 양성 등 AI 산업이 잘 성장할 수 있도록 돕는 일종의 “당근”에 해당하는 규정들입니다. 이어서 4장은 인공지능 윤리 및 신뢰성 확보로 AI의 부작용을 막기 위한 안전장치를 다루고 있습니다. 앞의 3장과 대비하면 “채찍”이라고 볼 수 있습니다.

5장은 보칙으로 앞에서 다루지 못한 내용들을 보충하는 역할을 하며, 6장은 벌칙으로 법을 어겼을때의 과태료, 형사 처벌 등을 정하는 역할을 합니다. 이 큰 흐름을 인지한 상태로 주요 내용을 짚어보겠습니다.

AI 기본법의 목적

AI 기본법의 첫 내용은 다음과 같습니다.

이 법은 인공지능의 건전한 발전과 신뢰 기반 조성에 필요한 기본적인 사항을 규정함으로써 국민의 권익과 존엄성을 보호하고 국민의 삶의 질 향상과 국가경쟁력을 강화하는 데 이바지함을 목적으로 한다.

이를 통해 볼 수 있는 AI 기본법의 목적은 “AI 잘 쓰자”인데요.

AI를 잘 쓰게 하자와 (3장)
AI 위험하게 쓰지 않도록 하자 (4장)

구체적으로는 위 내용으로 볼 수 있습니다.

<출처: 작가>

이어 정의에서는 본문에 쓰이는 여러 법적 용어들을 정의합니다. 특별히 주의할 부분으로는 “고영향 인공지능”이라는 단어가 있습니다. 이는 에너지, 물, 의료, 원자력, 범죄, 채용, 교통, 공공서비스, 기본 교육 등 개개인 사람의 생명과 신체의 안전 및 기본적인 권리에 큰 영향을 미치는 영역에 쓰이는 인공지능을 의미합니다. 이 고영향 인공지능은 개념을 분리한 만큼, 특별히 추가 규칙과 벌칙들이 정의됩니다.

또 다른 주요 정의로는 “인공지능사업자”와 “이용자”, “영향받는 자”가 있습니다. 사업자는 이 법의 규제 대상이고 이용자와 영향받는 자는 이 법이 고려해야하는 대상입니다. 특별히 이용자와 영향 받는자는 별도로 분리하여 정의했는데, 이 둘의 차이는 각각 인공지능 제품을 제공 받는자와 인공지능 제품에 의해 자신의 생명, 신체 안전 및 기본권에 중대한 영향을 받는 자를 의미합니다.

예를 들어, 기업에서 AI 면접 프로그램을 사용하는 상황에서 이용자는 기업의 인사 담당자, 영향받는 자는 지원자입니다. 이 둘을 구분해야 하는 이유는 AI 기본법에서 보호해야 할 대상별 각각 의무의 내용이 다르기 때문입니다.

여기서 영향받는 자는 인공지능서비스에서 인공지능이 만든 결과에 대한 기준과 원리에 대해 명확한 설명을 제공 받을 수 있어야 합니다. 이는 기존 기업에서 검색, 뉴스 배치 등의 알고리즘을 공개하는 것과 비슷하다고 볼 수 있습니다.

<출처: 구글>

2장에서는 인공지능 정책을 이끌 추진체계를 정의하고 있는데요. 요약하면 “정부 관계자 등이 AI 활성화를 위해 열심히 해야 한다.” 같은 내용을 설명하고 있습니다.

AI 기본법에서 공공데이터에 대한 내용을 함께 고려한다는 것
주요 행정기관에서 정책을 수립, 집행할 때 AI 기본 계획을 고려해야 함

이 외에 특별한 점은 두 가지가 있습니다. 그중 두 번째 내용은, AI 기본법이 단순히 AI의 활용과 규제만을 조절하는 데 그치지 않는다는 데 있습니다. 이 법은 앞으로 정부 차원에서 국가 운영 방향에 AI를 적극적으로 반영하고, 모든 주요 사업의 기반으로 삼아, 장기적으로는 AI를 내재화하겠다는 방침을 명시한 것으로 해석할 수 있습니다.

AI 개발 및 산업 육성

3장에서는 본격적으로 AI 기본법이 다루고자 하는 내용을 정의합니다. 단순히 인공지능 기술을 개발하는 것에 그치지 않고, 제14조에서는 ‘표준화’라는 용어를 사용합니다. 여기에는 안전성과 신뢰성을 확보하기 위한 기준으로, 데이터 규격, AI 간의 통신 프로토콜, AI 윤리 가이드라인, 용어 정의 등이 포함될 수 있으며, 이를 정부 차원에서 주도적으로 시행하겠다는 목적이 드러나 있습니다.

<출처: 작가, 제미나이로 생성>

16조의 내용도 주목할 만합니다. 바로 국가기관이 업무에 필요한 제품과 서비스를 구매할 때, 앞으로는 인공지능이 활용된 제품과 서비스를 우선적으로 고려해야 한다는 내용입니다. 이 조항은 작년 AI 기본법이 공개된 이후 최근에 추가 신설된 것으로, AI 기업들에게 정부라는 안정적인 고객이 생긴 셈이기 때문에, 민간 투자 확대와 산업 생태계 활성화를 기대할 수 있습니다.

또한 이어지는 조항에서는, AI 서비스를 구매·사용한 결과 손해가 발생하더라도 손해배상 책임을 면제함으로써, 공무원들이 보다 자유롭게 AI를 시도할 수 있는 안전장치도 마련했습니다.

이어지는 제17조부터 제23조까지는, AI 지원 시책을 규정하고 있습니다. 여기에는 중소기업 특별 지원, 창업 활성화 사업, AI 전문인력 양성, 인공지능연구소 설립 지원 등이 포함되며, 이를 통해 AI를 직접 만드는 대기업뿐 아니라, AI를 응용·활용할 수 있는 다양한 산업 주체들의 참여를 유도하고자 합니다.

AI 윤리 및 신뢰성

드디어 가장 많은 관심이 쏠릴 제4장입니다. 4장은 AI를 위험하게 사용하지 않도록 하기 위한 일종의 가이드라인으로, 지키지 않을 경우 과태료가 부과되는 규칙들도 포함되어 있습니다. 먼저 교육기관, 연구기관, 사업자 등은 자체적으로 윤리위원회를 구성하여, 윤리 원칙의 준수 여부, 안전 문제, 인권 침해 등의 사항에 대해 필요한 업무를 수행할 수 있습니다. 이 조항은 의무사항은 아니며, 선택적으로 운영할 수 있습니다.

특히 AI 기본법의 내용은 다소 헷갈리는 부분이 많기 때문에, 정부 차원에서 AI 활용 관련 주요 윤리 원칙과 실천 방안 등을 담은 가이드라인을 별도로 공개했습니다. 이 가이드라인은 총 5개의 파일로 구성되어 있으며, 인공지능기본법 지원데스크를 통해 각각 확인할 수 있습니다.

<출처: 인공지능기본법 지원데스크>

그렇다면, 이 4장에서 AI 윤리 원칙을 지켜야 하는 대상은 누구일까요? 이는 제31조에 정의되어 있는데, 고영향 인공지능 혹은 생성형 인공지능을 이용해 제품과 서비스를 제공하는 인공지능 사업자가 이에 해당합니다. 이들은 서비스 운용 과정에서 인공지능을 사용했다는 사실과 결과물이 생성형 인공지능에 의해 만들어졌다는 점을 명확히 고지해야 한다는 규정을 따릅니다.

다행히 일반적으로 AI를 활용하는 일반 이용자는 이 규제의 대상에 해당하지 않습니다. 예를 들어, 영상 생성 인공지능을 이용해 영화를 제작하거나, 배급하는 제작사는 AI 제품이나 서비스를 제공하는 사업자가 아니라, AI를 업무에 활용하는 이용자로 간주되어, 해당 투명성 확보 의무의 대상에는 포함되지 않습니다.

이어서, AI를 사용한 결과임을 고지하는 ‘투명성’ 외에도 AI의 ‘안정성’ 확보 또한 포함됩니다. 여기에는 인공지능 사용의 위험 식별 및 평가, 안전사고 모니터링 체계 구축 등이 해당합니다. 이 규제의 대상은 두 가지입니다.

하나는 AI 모델을 직접 제공하는 사업자로, 학습에 사용된 누적 연산량이 10^26 FLOPS 이상인 경우에 해당하며, 다른 하나는 고영향 인공지능을 활용하는 사업자입니다.

다만, 이러한 규제를 담고 있는 4장의 내용은 AI 기본법 시행 초기 단계인 만큼,

내가 사업자에 해당하는지
우리 AI 서비스가 고영향 인공지능에 해당하는지
생성형 AI 사용 시 어떤 방식으로 고지해야 하는지

등과 관련해 혼란이 많을 수 있습니다. 이에 따라 앞서 소개한 인공지능기본법 지원데스크에서는 상담을 지원하고 있으며, 과태료와 처벌 등에 대해서는 1년의 유예기간도 부여되어 있습니다.

한편, 제5장은 법 시행과 관련된 행정적, 기술적인 내용을 담고 있어 생략하고, 제6장에서는 4장 내용 위반 시 과태료 부과에 관한 규정을 설명합니다. 여기에는 제7조, 제31조, 제36조, 제40조가 포함됩니다.

정리하면?

‘기술 문서’에는 익숙하지만 ‘법조문’에는 익숙하지 않은 제게는 다소 헷갈리는 부분도 많았지만, AI 기본법의 핵심은 두 가지 정도로 요약할 수 있습니다.

우리나라가 AI를 잘 활용할 수 있도록 정부 차원에서 다양한 지원을 하자 (제2~3장)
AI를 투명하고 신뢰할 수 있도록 사용하기 위해, AI 사업자가 지켜야 할 규칙을 만들자 (제4장)

이 중 제2~3장은 알아두면 좋지만, 모른다고 해서 당장 큰 위험이 생기는 내용은 아니라 비교적 덜 중요하게 느껴졌습니다. 반면, 제4장은 의무와 규제를 포함하고 있기 때문에 제대로 알지 못하면 곤란할 수 있어 주의 깊게 해석해야 합니다. 특히 4장의 핵심은, 서비스에 생성형 AI를 사용했다면 그 사실을 명확히 표기하자는 것입니다. 물론 규정 위반 시 ‘큰일’이 나는 것처럼 보일 수도 있지만, 앞서 언급했듯이 혼란을 대비해 1년간 규제 시행이 유예되었기 때문에, 아직은 여유가 있는 상황으로 볼 수 있습니다.

<출처: 인공지능 투명성 확보 가이드라인>

저는 이 4장의 대상을 AI 사업자와 AI 이용자를 구분 지으며 생성형 AI를 써서 만든 결과물이 사용자가 볼 때 고정된 상태라면(ex: 영화) 표기 의무 없는 이용자, 결과물이 사용자가 볼 때 상호작용에 의해 바뀐다면 (ex: AI 작문) 표기 의무 있는 사업자 정도로 이해했습니다. 고영향 AI의 경우, 대부분의 서비스는 여기에 해당하지 않지만, 만약 해당된다면 기존에도 관련 규제를 경험했을 가능성이 높기 때문에, 자신이 법 적용 대상인지 알고 있을 확률이 큽니다.

다만 주의할 점이 하나 있습니다. 고영향 AI는 꼭 ‘생성형 AI’만을 의미하지 않고, 선형회귀처럼 오래된 AI 방식도 포함될 수 있습니다. 왜냐하면 법에서 고영향 AI를 “학습, 추론, 지각, 판단, 언어 이해 등 인간의 지적 능력을 전자적으로 구현한 것”으로 정의하고 있기 때문입니다. 즉, 기술 방식과 관계없이 법적 대상이 될 수 있으니 서비스 성격에 따라 충분한 검토가 필요합니다.

또한 ‘투명성’뿐만 아니라 ‘안전성’ 확보도 중요합니다. 이 부분은 기존의 보안 규정과 비슷한 컴플라이언스(규제 준수) 영역이지만, 여기에 AI 기술에 대한 이해까지 필요하기 때문에 현실적으로 꽤 어려운 문제가 될 수 있습니다.

<출처: 구글 뉴스>

마치며

이번 글에서는 AI 기본법에 대해 법령을 토대로 주요 내용과 실제로 체감될 만한 부분들을 중심으로 살펴보았습니다. 개인적으로는, 이전에 작성했던 글 중에서도 알아보기 전과 조사한 후의 인상이 가장 달랐던 주제였던 것 같습니다. 사실 AI 기본법을 다룬 뉴스나 기사들을 보면, 과도한 규제가 AI 혁신을 가로막을 수 있다는 우려도 종종 제기됩니다.

하지만 막상 내용을 자세히 들여다보면, 규제가 그렇게 강하게 체감되지는 않았고, 오히려 정부가 AI 활용에 큰 방향성과 의지를 가지고 있다는 점이 인상적이었습니다. (구체적으로 다루진 않았지만, 제2~3장에는 상당한 규모의 지원과 사업 계획이 담겨 있을 것으로 예상됩니다.)

현재 우리나라의 AI는 독자 AI 파운데이션 모델 프로젝트로 “인프라”를, 그리고 AI 기본법으로 “가이드라인”을 만들어가고 있는데요. 어쩌면 패스트 팔로어를 넘어, 퍼스트 무버를 꿈꿔볼 수 있지 않을까요?

]]>

지금, 프로젝트 관리에 Jira 대안이 필요한 이유

이 글은 스위그와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

“AI 덕분에 개발 속도는 몇 배나 빨라졌는데, 왜 제품 출시는 오히려 늦어질까요?”

요즘 Claude Code와 Cursor로 무장한 개발자들이 하루에 완성할 수 있는 기능의 양은 과거와 비교하기 어렵습니다. 그뿐만이 아닙니다. 기획자, 디자이너, 개발자가 팀을 이뤄 몇 달을 매달려야 모습이 보일까말까 하던 서비스가, 이제는 능력 있는 개인이나 소규모 팀에 의해 몇 주 만에 나타나기도 합니다.

몇 년 전 유행하던 사이드 프로젝트와는 질적으로 달라 보입니다. 비즈니스 로직은 정교해졌고, 프로젝트의 규모와 복잡도는 기하급수적으로 커졌습니다. 혼자서 3~4개의 프로덕트를 동시에 돌리는 메이커 역시 더는 낯설지 않은 풍경이죠. ‘만드는 것’의 장벽이 역사상 가장 낮은 시대가 아닐까 생각합니다.

그런데 이상합니다. 제가 만난 분들은 여전히 제품의 배포 일정이 미뤄지고 스프린트마다 ‘못다 한 일’이 쌓여간다고 합니다. 이야기를 듣다 보면 그 이유는 비슷했습니다. 지금의 관리 방식과 도구가 기술의 발전 속도를 따라가지 못했기 때문입니다.

그래서 글을 썼습니다. 우리는 언제까지 ‘진짜 일’이 아니라 ‘티켓’에 시간을 쏟아야 할까요? 지금 AI 시대에 걸맞은, 새로운 프로젝트 관리의 철학이 필요한 시점입니다.

<출처: 요즘IT>

생산성 폭발을 가로막는 숨겨진 병목

문제는 협업이 시작되는 순간부터 나타납니다. 혼자서 일을 정리할 때는 노션 한 페이지면 충분합니다. 하지만 팀이 커지고 다루는 프로젝트가 많아지면 사람들은 불안함을 느낍니다. 그래서 습관적으로 ‘업계 표준’이라 불리는 무거운 프로젝트 관리 툴들을 도입하기 시작합니다. Jira, Asana, Trello 같은 것들이죠.

여기서 모순이 생깁니다. 일할 때는 AI를 써서 광속으로 코드를 짜고 디자인을 뽑아내는데 정작 그 결과물을 관리하기 위해 과거의 행정 업무를 답습하고 있는 것입니다. 결과물에 대한 의견을 조율하고, 핵심 비즈니스를 검토하며, 고객을 만나기도 부족한 시간은 정작 이런 질문에 답하는 데 쓰입니다.

“Jira 티켓 생성하셨나요?”
“워크플로우 상태값 업데이트 안 되어 있네요.”
“이 필드는 필수 입력 사항입니다.”

혁신적인 서비스를 만들기 위해 모인 인재들이 하루 업무 시간의 상당 부분을 툴을 관리하고, 데이터를 입력하고, 현황판을 꾸미는 데 쓰고 있습니다. 화려한 칸반 보드와 보기 좋은 타임라인에 잘 정리된 차트는 남지만, 실행 속도는 느려질뿐더러 데이터에 대한 신뢰 역시 낮아집니다.

어느새 실행(Shipping)을 위해 존재하던 도구들이 지금은 움직임을 가로막는 가장 큰 병목(Bottleneck)이 되어버린 것입니다. 그래서 우리는 다시 질문하게 됩니다.

우리는 더 나은 제품을 만들기 위해 모였는가,

아니면 티켓과 상태값을 관리하기 위해 모였는가.

<출처: 요즘IT>

과거의 프로젝트 관리 도구와 3가지 한계

우리가 도입해 온 기존의 프로젝트 관리 도구들은 대부분 AI 시대 이전에 설계된 유물입니다. 이들은 생산성의 폭발이 필요한 지금, 실무자에게 ‘입력’이라는 제2의 노동을 강요하는 존재로 바뀌었습니다.

1. 모든 SaaS는 당신의 시간을 원한다

IT 업계에는 이미 수많은 SaaS 도구가 자리 잡고 있습니다. Slack과 같은 메신저, GitHub를 비롯한 코드 저장소, Figma 등 디자인 툴, Notion으로 대표되는 문서 도구까지. 각 도구는 자신이 맡은 역할에 최적화되어 있으며 분명히 높은 생산성을 만들어내고는 합니다.

이러한 SaaS는 모두 실제 작업이 이뤄지는 공간입니다. 따라서 사용자가 오래 머무르며 작업 의존도를 높이는 것 자체가 도구의 유용성을 입증하는 지표입니다. 그렇게 주요 SaaS 기업이 체류 시간과 리텐션을 핵심 지표로 삼아 성장해 온 것은 충분히 합리적인 전략이었습니다.

문제는 이 전략이 모든 종류의 SaaS에 그대로 적용되면서 발생합니다. 관리를 위한 도구마저 사용자의 시간을 뺏고자 ‘체류 시간’을 핵심 지표로 삼은 것입니다. 이제 사람들은 SaaS가 유도한 대로 같은 작업을 여러 번 기록하고 설명해야 하는 상황에 놓입니다. 코드는 코드대로, 디자인은 디자인대로, 논의는 메신저대로 진행되지만, 그 결과를 다시 정리해 입력하는 데 시간을 쓰는 것이 당연한 절차처럼 굳어졌습니다.

2. 관리를 위한 ‘입력’의 이상과 현실

그렇게 도구들이 쌓이고 나면 실무자는 이제 모든 과정에서 일을 위한 일을 해야 합니다. 티켓을 만들고, 매번 상태를 바꾸고, 끝난 뒤에는 다시 정리된 결과를 입력합니다.

이를 위한 촘촘한 필드와 규칙은 ‘체계적인 관리’의 상징처럼 여겨집니다. 하지만 이 구조는 중요한 3가지 전제를 깔고 있습니다. 실무자는 언제나 입력할 여유가 있고, 이 정보는 항상 정확하며, 조금도 지연되지 않는다는 전제입니다.

현실은 다릅니다. 실무자들은 보통 실행에 몰입할수록 입력을 뒤로 미룹니다. 가장 바쁘기에 관리가 중요한 시점일수록 도구의 데이터는 가장 비어 있습니다. 의무감에 기껏 입력한 정보 역시 주관적이라 확실치 않습니다.

이는 마치 택시 기사에게 운전 중에 수기로 운행 일지를 작성하라고 요구하는 것과 비슷합니다. 목적지는 분명한데 택시 기사가 기록을 남기느라 운전에 집중하지 못하면 어떨까요? 결국 도착 시간은 늦어지고 사고의 위험은 커집니다. 기록은 남았을지 몰라도, 그 기록이 만들어진 과정은 결코 효율적이지 않은 겁니다.

3. “그래서, 그 기능 언제 배포되나요?”

이런 흐름의 한가운데 놓인 프로젝트 관리 도구는 또 다른 특징을 가집니다. CRM이나 HR, 회계 시스템은 특정 역할의 사람들이 주로 사용하는 도구입니다. 반면, 프로젝트 관리 도구는 다릅니다. 개발자, 디자이너, 기획자뿐 아니라 영업과 마케팅, 관리자와 경영진까지 모두가 각자의 목적을 가지고 들여다보는 공간으로 쓰입니다.

문제는 이들이 사용하는 언어와 관심사가 모두 다르다는 점입니다. 개발자는 코드와 이슈를 보고 싶어 하고, 디자이너는 산출물과 흐름을 중시합니다. PM은 일정과 우선순위를, 비즈니스팀은 고객 가치와 마감일을, 관리자는 전체 진행 상황과 리스크를 확인하려 합니다. 이 서로 다른 요구를 하나의 도구 안에서 모두 만족시키려다 보니, 프로젝트 관리 도구는 점점 더 많은 필드와 상태값, 복잡한 워크플로우를 가져야 했습니다.

결국 이 복잡성을 담기 위해 이들 도구는 가장 기능적인 언어, 즉 ‘개발자의 언어’를 택합니다. 복잡한 상태 관리, 쿼리로만 움직이는 데이터, 어려운 로직과 자동화가 기본이 된 거죠. 결국 비개발 직군에게 이들 도구는 접근하기 힘든 암호문이 되어버립니다. 어느 순간부터 그들은 Slack으로 돌아와 묻습니다.

"그래서 그 기능, 언제 배포되나요?"

비싼 돈을 내고 툴을 들여와도 소통 비용은 줄어들지 않는 아이러니입니다.

<출처: 요즘IT>

티켓 너머 ‘진짜 일’이 존재하는 공간

그렇다면 진짜 일은 어디에 존재할까요? 본질로 돌아가 봅시다.

1. 실무자의 역할은 ‘입력’이 아닌 ‘실행’

앞서 말한 택시 기사의 예시를 다시 보겠습니다. 오늘날 택시 기사들은 손으로 기록하지 않고도 운전에만 집중할 수 있습니다. ‘미터기’와 ‘GPS’가 있기 때문입니다. 그들이 핸들을 꺾고 엑셀을 밟는 순간, 기계는 자동으로 이동 거리와 요금을 계산하고 주행 경로를 서버에 기록합니다. 모두 운전에 집중할 뿐 그 어떤 관리 행위도 하지 않습니다.

기사의 역할은 사고 없이 운전하는 것이고, 관리 도구의 역할은 그 운전의 결과를 정확히 읽어내는 것입니다. 만약 기사에게 운전 중에 일지를 쓰게 한다면 운전의 질도, 기록의 정확성도 동시에 떨어질 수밖에 없습니다.

프로젝트도 크게 다르지 않습니다. 이 작업의 경로에서 실무자가 해야 할 역할은 ‘입력’이 아니라 ‘실행’입니다. 그리고 그 실행은 이미 각자의 작업 공간에서 실시간으로 흔적을 남기고 있습니다.

2. 진짜 일이 있는 현장

우리는 흔히 Jira 티켓이나 간트 차트가 프로젝트의 현황이라고 착각합니다. 하지만 그것은 누군가에 의해 가공된 2차 정보일 뿐입니다. 프로젝트의 관리 대상들은 ‘실제로 일하는 공간’에 있습니다.

개발자의 진척도는 티켓의 상태값이 아니라, Git에 올라가는 코드(Commit, PR)에 있습니다.
디자이너가 만든 버전들은 작업 로그가 아니라, Figma의 수정 내역(History)에 담겨 있습니다.
팀의 의사결정은 회의록 문서가 아니라, Slack의 대화 스레드 속에 살아 있습니다.

지금 대부분의 팀에서 실무자가 사용하는 도구는 정해져 있습니다. 개발자는 코드 저장소에서 일하고, 디자이너는 디자인 툴에서 사고하며, 팀의 논의는 메신저와 문서 위에서 이루어집니다. 이 흐름을 바꾸는 것은 쉽지 않을뿐더러 바꿀 필요도 없습니다. 이처럼 진실의 원천(Source of Truth)은 실무자들이 일하는 공간에 실시간으로 쌓이고 있습니다.

그럼에도 우리는 진짜 흐름이 쌓이는 현장을 외면한 채, 실무자를 관리 도구에 ‘적응시키는 것’이 문제의 해답이라고 믿어왔습니다. 실무자의 상황을 어떻게 관리 도구 안으로 끌고 올지만 고민해 온 것입니다.

‘입력’시키지 않아도 ‘흐름’을 알 수 있는 관리

관리 도구가 실무자의 일하는 방식을 대체하려는 순간, 그 도구는 관리 도구로서 실패합니다. 관리의 역할은 일을 ‘시키는 것’이 아니라, 이미 일어나고 있는 실행을 읽고, 연결하고, 판단할 수 있는 상태로 만드는 것입니다. 그래서 관리의 출발점은 언제나 계획이 아니라 실행이어야 합니다. 계획은 실행으로 이어질 때 의미가 있고, 실행의 흔적은 이미 현장에 남아 있기 때문입니다.

1. 사람들이 툴이 쓰지 않는 진짜 이유: ‘입력’과 ’방해’

저희 팀은 ‘뤼이도’라는 프로젝트 관리 툴을 만들고 있습니다. 뤼이도와 함께 현장에서 관리에 발목 잡혀 대안을 고민하는 팀을 만나보면 상황은 비슷했습니다. 관리자들은 “Jira를 도입했는데 아무도 안 써요.”라고 말하고, 실무자들은 “실제 일하는 시간보다, 관리하는 일이 더 많아요.”라고 말했습니다.

처음에는 기존 도구의 고질적인 문제 몇 가지만 바꿔보겠다고 생각했습니다. Jira와 같은 기존의 프로젝트 관리 툴은 분명 현장의 체계를 바꾸었다고 믿었기 때문입니다. IT라는 영역의 애매모호한 업무 태스크를 일관성 있게 통제할 표준을 만들어 주었죠. 무엇보다 갈수록 복잡해지는 기술 프로젝트에 관리라는 행위가 없으면 일은 산으로 갈 것입니다.

그래서 뤼이도 역시 기존의 성공 공식을 따랐습니다. 관리 화면을 더 보기 좋고 쓰기 좋게 만드는 데 집중한 것입니다. 초기에는 반응도 괜찮았습니다. 사용자의 리텐션과 체류 시간이 높은 것을 보며 환호했죠. 그렇게 “사용자들이 우리 툴을 자주 쓰는구나, 우리가 잘하고 있구나”라고 생각했습니다.

뤼이도 초기 제품 화면 이미지 <출처: 스위그>

하지만 현장의 목소리를 듣고 나서야 그것이 오만한 착각이었음을 깨달았습니다. 실무자들에게 잦은 접속은 생산성이 아니라 방해(Interruption)였습니다. 코딩하다가 들어와서 티켓 옮기고, 디자인하다가 들어와서 댓글 달고…. 레거시 툴의 문제를 해결하겠다고 나섰지만, 결국 똑같이 실무자의 발목을 잡고 있었던 것입니다.

여기서 깊이 깨달은 것이 있습니다. 기존 도구의 ‘입력 기반 관리’ 구조는 필연적으로 놓치는 것들이 존재한다는 것입니다. 입력에 의존하면 정보는 언제나 한 박자 늦어집니다. 서로 일을 확인하느라 다시 묻고 정리하다 보면, 흐름이 끊기고 결정이 늦어지다 출시가 미뤄집니다.

더 큰 문제는 이러한 입력의 시간이 몰입을 깬다는 데 있습니다. 상태를 입력하기 위해 일을 잠시 멈추면 사람들은 다시 몰입 상태로 돌아오기까지 더 많은 시간이 필요합니다. 결국 사람들이 도구를 쓰지 않는 이유는 관리가 싫어서가 아니라, 입력으로 흐름이 끊기는 경험이 싫기 때문입니다.

2. 도구에 들어오지 못하게 했더니, 더 깊게 머문다

그래서 방향을 완전히 틀었습니다. 목적은 하나였습니다. “실무자가 우리 툴에 들어오지 않게 만들자.”

GitHub, Figma, Slack과 연결되는 뤼이도 <출처: 스위그>

GitHub, Figma, Slack처럼 그들이 이미 머무르고 있는 도구에 우리가 찾아가기로 했습니다. 그들이 뤼이도를 의식하지 않고 일해도, 뤼이도의 프로젝트 관리 화면에 업무 데이터가 쌓이게 했습니다.

아이러니하게도 접속에 대한 강요를 없애자, 제품 내에 체류하는 시간이 비약적으로 늘어났습니다. 과거에는 입력을 위해 5분씩 10번 들어왔다면, 이제 입력은 시스템에 맡기고 분석과 의사결정을 위해 하루 3~4시간씩 깊게 머물기 시작한 것입니다. 신뢰할 수 있는 데이터가 자동으로 쌓이니 사람들은 ‘히스토리 탐색’과 ‘다음 전략 수립’이라는 진짜 관리 업무를 하러 들어오게 되었습니다.

뤼이도의 프로젝트 관리 화면 <출처: 스위그>

이것이 우리가 발견한 좋은 관리의 본질이었습니다. 입력을 강요해 만든 데이터는 쓰레기가 되지만, 입력을 없앤 데이터는 자산이 됩니다.

3. 지금, Jira의 대안이 필요한 이유

저희 팀이 현장에서 발견한 진짜 해결책은 더 많은 필드도, 더 정교한 워크플로우도 아니었습니다.

실행과 관리가 분리되지 않은 프로젝트 관리의 새로운 구조였습니다. 더는 입력 기반 관리가 폭발하는 생산성을 가로막아서는 안 된다는 철학이었습니다. 이제는 관점을 바꿔야 합니다.

뤼이도 프로젝트 관리 화면 <출처: 스위그>

좋은 프로젝트 관리란 입력이 없어도 흐름이 보이는 데 있습니다. 그저 예쁜 칸반이 아닌 실제 현장의 데이터, 멈춰서서 입력하지 않아도 알아서 모이는 구성이 필요합니다. 새로운 시대의 프로젝트 관리 도구는 그 흐름을 쉽게 파악하고 관여하는 일에만 집중해야 합니다.

사람이 도구에 맞추는 시대에서, 도구가 사람의 행동을 이해하는 시대로의 이동이 필요합니다.

마치며

우리는 종종 착각에 빠집니다. 밀린 Jira 티켓을 정리하고, 회의록을 깔끔하게 다듬고 나면 묘한 뿌듯함이 밀려옵니다. “오늘 하루, 참 열심히 살았다” 싶은 안도감도 함께 옵니다. 대시보드가 비워지는 것만으로 우리는 무언가를 해냈다는 느낌을 받습니다.

하지만 한 번쯤은 냉정하게 물어야 합니다. 그것이 정말 ‘일’이었을까요? 티켓 상태를 완료로 바꾸는 행위가 고객에게 어떤 가치를 주었나요? 회의록 정리 자체가 제품의 버그를 고쳤을까요?

실무자는 본질적으로 실행하는 사람입니다. 코드를 쓰고, 디자인을 만들고, 문제를 해결해야 합니다. 특히 AI로 1인당 생산성이 비약적으로 높아진 지금, 사람이 써야 할 시간은 더욱더 ‘본질적인 일’에 가까워져야 합니다. 일을 위한 일(Work about Work)이 주는 가짜 성취감을 경계해야 합니다. 그것만으로는 제품은 단 1mm도 전진하지 않습니다.

그래서 지금 필요한 변화는 ‘일의 관리’를 바라보는 관점의 변화입니다. 관리가 많아질수록 일이 잘된다고 믿는 대신 관리할 필요가 줄어드는 구조를 만들고 있는지를 물어야 합니다. 좋은 팀은 관리하지 않는 팀이 아니라, 관리 때문에 흐름이 끊기지 않는 팀입니다. 비효율을 걷어내 본질에 집중하려는 팀에게 필요한 건 오직 이 질문뿐입니다.

우리는 일을 관리하고 있는가,

아니면 그저 관리한다는 착각 속에 있는가.

]]>

쿠버네티스 7개 주요 게이트웨이 기술 검증(Poc)하기 (feat. Ingress NGINX의 은퇴)

2025년 11월, 쿠버네티스 생태계에서 가장 널리 쓰이던 Ingress NGINX에 대한 지원이 더는 어렵단 발표가 있었습니다. 실제 지원 종료 시점은 2026년 3월이지만, 미리 준비하고 대비해야 하기 때문에 이 글을 작성하게 되었습니다.

Ingress API 자체의 대안인 Gateway API의 개념부터, 후보로 선정한 7개 구현체에 대한 설명, 실제 PoC 테스트 결과, 그리고 앞으로 준비해야 할 사항까지 차례대로 다뤄보겠습니다. 현재 시점에서 어떤 구현체를 선택하는 것이 적절한지, 또 어떤 기술을 기다리는 것이 더 좋을지까지 함께 살펴보겠습니다.

쿠버네티스 게이트웨이의 등장

Gateway API는 쿠버네티스에서 서비스 네트워킹을 정의하는 차세대 표준 API입니다. 기존 Ingress API의 한계를 극복하기 위해 Kubernetes SIG Network에서 개발했으며, 더 높은 표현력과 확장성, 그리고 역할 기반 설계를 제공하는 것이 특징입니다.

좀 더 쉽게 이해하기 위해서는, 먼저 Gateway API와 Ingress API의 관계부터 명확히 하는 것이 좋습니다. 이 관계를 이해하면 Gateway API가 어떤 문제를 해결하려는지, 어떤 방향으로 설계됐는지 더 잘 이해할 수 있습니다.

Gateway API와 Ingress API의 관계

Gateway API는 Ingress API를 ‘대체’하는 것이 아닌 ‘차세대 표준’으로 설계됐습니다. SIG Network는 공식 FAQ에서 이에 대해 다음과 같이 설명하고 있습니다.

Q. “Gateway API가 Ingress API를 대체하게 되나요?”
“Will Gateway API replace the Ingress API?”

A. 아닙니다. Ingress API는 Kubernetes 1.19부터 GA 상태이며, 이 API를 Deprecated할 계획은 없습니다. 또한 대부분의 Ingress 컨트롤러가 앞으로도 이를 지속적으로 지원할 것으로 예상하고 있습니다.
No. The Ingress API is GA since Kubernetes 1.19. There are no plans to deprecate this API and we expect most Ingress controllers to support it indefinitely.

즉, 두 API는 무기한 공존을 전제로 했습니다.

여기서 이 글의 주제와 관련해 혼동하기 쉬운 포인트가 하나 있습니다.

Deprecated 아닌 것: Ingress API = API 자체
은퇴(Retired) 예정인 것: Ingress NGINX Controller = 구현체

이번에 은퇴하는 대상은 Ingress API가 아니라 ingress-nginx 컨트롤러입니다. 실제 2025년 기준으로도 Ingress API(networking.k8s.io/v1)는 GA 상태를 유지하고 있으며, Deprecated에 대한 계획이 없습니다. 다른 Ingress 컨트롤러나 클라우드 서비스 제공자(CSP, Cloud Service Provider)가 제공하는 네이티브 솔루션을 사용한다면, Ingress API 자체는 계속 사용할 수 있다는 뜻입니다. 예를 들어 AWS ALB Controller, Azure AGIC, GCP GCE Ingress 등이 이에 해당합니다.

Ingress NGINX의 은퇴 배경은?

인그레스 NGINX는 전 세계 쿠버네티스 클러스터의 40% 이상에서 사용되던 핵심 프로젝트였습니다. 그러나 실제 유지보수는 매우 소수의 메인테이너가 본업 외 개인 시간을 쪼개 진행하는 구조였습니다. 이로 인해 CVE 대응과 버그 수정에 지속적인 부담이 쌓여 갔고, 커뮤니티 차원에서 기여자를 모집했음에도 충분한 인력을 확보하지 못했습니다. 이는 오픈소스 생태계의 지속 가능성에 대해 다시 한 번 고민하게 만드는 계기로 남을 것 같습니다.

그렇다면 왜 마이그레이션이 필요한가?

다만 Gateway API에는 기존 Ingress 방식과 비교했을 때 여러 장점이 존재합니다. 그렇기 때문에 기존 환경에서 전환을 고려하거나 신규로 도입하는 환경이라면 Gateway API를 우선 고려해 보는 것이 좋습니다.

Ingress vs Gateway API 주요 차이점

예시로 차이점 이해하기

여러 차이점이 있지만, 그중에서도 가장 크게 체감되는 것은 역할이 분리된 구조입니다. 예를 하나 들어보겠습니다.

기존 Ingress API를 사용하는 ingress.yaml 코드를 Gateway API 형태로 변경하면, 다음과 같습니다.

Ingress API (단일 리소스)

Gateway API (역할별 분리)

코드 내용을 보면 알 수 있듯 기존의 ingress.yaml과 비교했을 때 크게 차이가 없는데, 역할이 분리되면, 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자가 각자의 책임 범위 내에서 리소스를 독립적으로 관리할 수 있게 됩니다.

이 구조는 기존에 StorageClass에서 사용하던, 미리 정의된 리소스를 불러와 사용하는 개념이 포함돼 있습니다. 이를 더 보기 좋게 다이어그램으로 그리면 이렇습니다.

API 다이어그램 비교 <출처: 작가>

이 과정에서 Ingress API는 클라우드 서비스 제공자가 직접 제공하는 솔루션을 제외하면 사실상 Ingress NGINX Controller를 사용하는 것이 표준에 가까웠습니다. 반면 Gateway API는 아직 발전 중인 단계에 있기 때문에, 현재 시점에서 어떤 구현체를 선택해야 할지 판단하기가 쉽지 않을 수 있습니다.

이러한 배경에서, 이 글에서는 대표적인 Gateway API 구현체들을 선정하고, 각각을 선택한 이유를 함께 살펴보도록 하겠습니다.

7개의 게이트웨이를 선정한 이유와 결과 요약

Gateway API는 표준 스펙이며, 여러 프로젝트와 벤더에서 컨트롤러를 구현해 제공하고 있습니다.

이에 따라 이 글에서는 대표적인 Gateway API 구현체 7개를 선정해 PoC를 진행했습니다. 선정 기준은 CNCF 생태계와의 연관성, 커뮤니티 활성도, 그리고 실제 프로덕션 환경과 유사한 조건에서 테스트한 뒤 충분히 검증됐는지를 중심으로 삼았습니다. 각 구현체별로 총 17개 테스트 시나리오를 실행해 기능 완성도를 평가했고, 그 결과를 바탕으로 장점과 단점을 정리했습니다.

1. NGINX Gateway Fabric

한 줄 평

검증된 NGINX의 안정성을 Gateway API로 계승
30년 웹 서버 역사가 보장하는 신뢰성

장점과 단점

NGINX Gateway Fabric의 가장 큰 장점은 결국 NGINX입니다. 수십 년간 웹 서버 시장에서 검증된 안정성과 성능, 그리고 전 세계 개발자들이 축적해 온 풍부한 문서와 대규모 커뮤니티가 그 배경입니다. 문제가 발생했을 때 Stack Overflow나 공식 문서에서 해결책을 찾기도 쉽습니다. 이미 NGINX를 사용 중인 조직이라면, 기존 운영 경험을 그대로 활용할 수 있다는 점 역시 매력적인 요소입니다.

다만 Rate Limiting을 구현하려면 SnippetsFilter를 통해 로우 레벨의 NGINX 설정을 직접 주입해야 합니다. Envoy 기반 Gateway처럼 선언적인 CRD로 간단히 설정하는 방식은 현재 지원되지 않습니다. 이로 인해 동적 설정 변경의 유연성 역시 Envoy 기반 구현체와 비교하면 상대적으로 낮은 편입니다.

테스트에는 v2.2.1(2025-11-18 공개) 버전을 사용했는데, 17개 시나리오 중 Rate Limiting을 제외한 모든 테스트를 통과했습니다. NGINX 환경에서 Gateway API로 자연스러운 전환을 원하는 팀에 가장 적합한 선택지입니다.

2. Envoy Gateway

한 줄 평

Gateway API 표준 준수의 모범, Rate Limiting 네이티브 지원
CNCF 생태계와 함께 성장하는 차세대 표준

장점과 단점

Envoy Gateway의 가장 큰 강점은 선언적 CRD를 통한 Rate Limiting 네이티브 지원입니다. BackendTrafficPolicy CRD 하나로 초당·분당 요청 제한을 직관적으로 설정할 수 있는 것은 7개 구현체 중 Envoy Gateway가 유일했습니다. xDS 프로토콜 기반의 동적 설정, 풍부한 필터 체인, 그리고 뛰어난 관측성 역시 주요 장점입니다.

다만 NGINX에 비해 상대적으로 역사가 짧아 커뮤니티가 아직 성장 중입니다. 또한 Envoy 자체의 복잡성으로 인해 학습 곡선이 존재합니다. 처음 접하는 팀이라면 초기 러닝 커브를 어느 정도 감안해야 합니다.

테스트에는 v1.6.0(2025-11-11 공개) 버전을 사용했으며, 17개 시나리오 중 Backend TLS(사이드카 필요)를 제외한 16개 테스트를 모두 통과했습니다. 새로운 프로젝트에서 Gateway API를 도입한다면, 가장 먼저 고려해볼 만한 선택지입니다.

3. Istio Gateway

한 줄 평

서비스 메시 환경의 최적 선택
mTLS 자동화와 세밀한 트래픽 관리의 끝판왕

장점과 단점

Istio Gateway의 가장 큰 장점은 서비스 메시와의 완벽한 통합입니다. mTLS가 자동으로 적용되며, 세밀한 트래픽 관리 기능을 별도 설정 없이 활용할 수 있습니다. 2024년 CNCF Graduated 프로젝트로 승격되면서, 안정성과 신뢰성 역시 공식적으로 검증됐습니다. 이미 Istio를 사용 중이거나 서비스 메시 도입을 계획하고 있다면 가장 좋은 선택지입니다.

다만 Rate Limiting을 구현하려면 EnvoyFilter를 통한 로우 레벨 설정이 필요해, 복잡도가 상당히 높은 편입니다. 또한 서비스 메시 전체 스택을 함께 도입해야 하므로, 오버엔지니어링이 될 수 있습니다.

테스트에는 v1.28.0(2025-11-05 공개) 버전을 사용했으며, Envoy Gateway와 동일하게 16개 테스트를 통과했습니다. 서비스 메시가 필요한 환경이라면 Istio Gateway는 충분히 좋은 선택지입니다.

4. Cilium Gateway

한 줄 평

eBPF 기반 커널 레벨 고성능 처리
CNI와 Gateway의 완벽한 통합, 단 Cilium 필수

장점과 단점

Cilium Gateway의 장점은 eBPF 기반의 커널 레벨 패킷 처리입니다. 유저스페이스를 거치지 않고 커널에서 직접 처리하기 때문에, 뛰어난 성능을 기대할 수 있습니다. 또한 CNI와 Gateway가 통합돼 있어 별도로 컴포넌트를 관리할 필요가 없고, Cilium의 네트워크 정책과도 자연스럽게 연동됩니다.

다만 HTTP Rate Limiting은 현재 미지원 상태로, Feature Request 단계에 머물러 있습니다. 이 때문에 API 트래픽 제어가 필수인 환경에서는 적합하지 않습니다. 무엇보다 가장 큰 제약은 CNI로 Cilium을 사용하는 환경에서만 동작한다는 것으로, Calico, Flannel 등 다른 CNI를 사용하는 클러스터에서는 적용할 수 없습니다.

테스트에는 v1.18.4(2025-11-12 공개) 버전을 사용했으며, Rate Limiting과 Session Affinity를 제외한 13개 테스트를 통과했습니다. 이미 Cilium CNI를 사용 중이고, eBPF 기반의 고성능 처리가 필요한 환경일 때 최적의 선택지입니다.

5. Kong Gateway

한 줄 평

엔터프라이즈 API Gateway의 대명사
풍부한 플러그인, 하지만 Gateway API 지원은 성숙 중

장점과 단점

Kong Gateway는 엔터프라이즈 API Gateway 시장의 선두 주자입니다. 풍부한 플러그인 생태계를 기반으로 API 관리, 인증·인가, 트래픽 제어 기능을 내장합니다. Ingress Controller로서도 오랜 기간 검증된 솔루션입니다.

다만 이번 PoC에서는 Gateway API 호환성 이슈가 확인됐습니다. HTTPRoute가 Kong 내부로 동기화되지 않았고, 'no Route matched with those values' 오류가 발생하며 기본 라우팅부터 실패했습니다. 해당 문제는 Kong Ingress Controller v3.5.3과 Kong Gateway v3.9 조합에서 발생했으며, 추가 구성 검토가 필요한 상태입니다.

테스트에는 v3.9(KIC v3.5, 2025-07-17 공개) 버전을 사용했습니다. Kong 자체는 좋은 솔루션이지만, Gateway API 지원은 아직 발전 중인 단계로 보입니다. 엔터프라이즈급 API 관리 기능이 필수라면 Kong을 고려할 만하지만, 순수 Gateway API 호환성을 우선한다면 다른 구현체를 검토하세요.

6. Traefik Gateway

한 줄 평

자동 서비스 디스커버리와 Let's Encrypt 통합의 강자
설정 간소화의 대가, 하지만 Gateway API는 아직

장점과 단점

Traefik Gateway는 자동 서비스 디스커버리와 Let’s Encrypt 통합으로 유명한 클라우드 네이티브 프록시입니다. 설정을 간소화한 구조와 다양한 백엔드 지원이 특징이며, Ingress Controller로서는 이미 널리 쓰이고 있습니다. 또한 MIT 라이선스로 제공돼, 라이선스 측면에서도 자유롭습니다.

다만 Kong과 마찬가지로, 이번 PoC에서는 Gateway API 호환성 이슈가 확인됐습니다. Gateway가 Ready 상태에 도달하지 못하는 문제를 비롯해, EntryPoints 포트 불일치, BackendTLSPolicy CRD 버전 불일치 등 문제가 발생했습니다. 이는 Traefik 고유의 설정 방식과 Gateway API 표준 사이에 아직 간극이 존재함을 보여줍니다.

테스트에는 v3.6.2(Helm Chart v37.4.0, 2025-11-18 공개) 버전을 사용했습니다. Traefik IngressRoute(CRD) 방식으로는 검증된 솔루션이지만, Gateway API 지원에는 구성 검토가 필요한 단계로 보입니다.

7. kgateway

한 줄 평

CNCF Sandbox 정식 승인, Envoy 기반의 새로운 선택지
Solo.io의 7년 Gloo Edge 기술력 기반

장점과 단점

kgateway는 2025년 3월 CNCF Sandbox에 정식 승인된 신흥 프로젝트입니다. Solo.io가 7년간 개발해 온 Gloo Edge 기술을 기반으로 하고 있으며, GraphQL 지원과 Envoy 필터 확장성이 주요 특징입니다. CNCF 생태계 안에서 성장 가능성이 기대되는 프로젝트로 평가받고 있습니다.

다만 ARM64 아키텍처를 지원하지 않아, 이번 PoC 환경인 Apple Silicon 기반에서는 테스트를 수행하지 못했습니다. 현재는 AMD64 전용으로 제공되며, Apple Silicon Mac이나 AWS Graviton 환경에서는 사용할 수 없습니다. 또한 CNCF Sandbox 단계에 있는 만큼, 아직은 성숙도에 대한 검증이 더 필요한 프로젝트이기도 합니다.

테스트 대상 버전은 v2.1.1(2025-11-18 공개)입니다. AMD64 환경에서 새로운 구현체를 찾고 있다면, 주목할 만합니다.

이렇게 선별한 7개 Gateway API 구현체에 대한 테스트 결과를 요약해 보았습니다.

곧이어 17개 테스트를 통해, 각 기능에 대해 검증한 결과를 살펴보겠습니다.

기술 검증(PoC, Proof of Concept) 시나리오 17개

이번 기술 검증을 위해 총 17개의 테스트 시나리오를 설계해, 각 Gateway 구현체의 기능 완성도를 평가했습니다.

1. 라우팅 테스트(3개)

Gateway의 가장 기본적인 역할은 들어오는 트래픽을 적절한 백엔드 서비스로 전달하는 것입니다. 호스트 기반 라우팅은 도메인별로 서비스를 분리할 때 쓰이며, 경로 기반 라우팅은 하나의 도메인에서 여러 마이크로서비스를 운영할 때 활용됩니다. 또한 헤더 기반 라우팅은 A/B 테스트나 특정 클라이언트 버전에 따른 분기 처리에 주로 사용됩니다. 이 세 가지는 모든 Gateway 구현체가 반드시 지원해야 하는 핵심 기능입니다.

2. TLS/보안 테스트 (3개)

프로덕션 환경에서 보안은 선택이 아닌 필수입니다. TLS 종료는 Gateway에서 HTTPS 암호화를 처리해 백엔드 서비스의 부담을 줄여주며, HTTPS 리다이렉트는 HTTP 접속을 자동으로 HTTPS로 전환해 보안 정책을 강제합니다. Backend TLS(mTLS)는 Gateway와 백엔드 간 내부 통신까지 암호화하는 Zero Trust 아키텍처의 핵심 요소로, 특히 금융이나 헬스케어처럼 규제가 강한 산업에서 중요합니다.

3. 트래픽 관리 테스트 (4개)

안정적인 서비스 운영을 위해서는 트래픽을 세밀하게 제어할 수 있어야 합니다. Canary 배포는 새로운 버전을 일부 트래픽에만 적용해 위험을 최소화하는 방식이며, Rate Limiting은 과도한 요청으로부터 서비스를 보호하는 역할을 합니다. Timeout과 Retry 정책은 일시적인 장애 상황에서도 사용자 경험을 유지하는 데 도움을 주고, Session Affinity는 세션 상태를 서버 메모리에 저장하는 레거시 애플리케이션이나 로그인 상태 유지가 필요한 환경에서 필수적인 기능입니다.

4. 요청/응답 수정 테스트 (2개)

백엔드 코드를 수정하지 않고도 라우팅 동작을 조정할 수 있다면 운영 유연성은 크게 높아집니다. URL Rewrite는 API 버전 마이그레이션이나 레거시 엔드포인트 통합 과정에서 유용하며, Header Modifier는 인증 토큰 주입, CORS 헤더 추가, 디버깅용 추적 ID 삽입 등 다양한 상황에서 활용됩니다. 특히 여러 팀이 협업하는 환경에서는 서비스의 독립성을 유지하면서도 통합을 지원하는 핵심 기능입니다.

5. 고급 기능 테스트 (5개)

대규모 클러스터를 운영하다 보면 기본 기능만으로는 부족한 상황이 발생합니다. Cross-namespace 라우팅은 멀티 테넌트 환경에서 네임스페이스 간 통신을 가능하게 하며, gRPC 라우팅은 마이크로서비스 간 고성능 통신에 필수입니다. Health Check와 Failover는 장애 상황에서도 자동 복구를 보장하고, Load Test는 실제 트래픽을 받기 전에 Gateway의 성능 한계를 파악하는 데 중요한 역할을 합니다.

이렇게 라우팅부터 TLS·보안, 트래픽 관리, 요청·응답 수정, 그리고 고급 기능까지 총 17개의 테스트 항목을 살펴봤습니다. 이제 각 Gateway 구현체가 이 테스트들에서 어떤 결과를 보여줬는지, 실제 PoC 결과를 기준으로 하나씩 확인해보겠습니다.

기술 검증(PoC) 결과

7개 Gateway 구현체에 대해 17개 테스트 항목을 100회씩 반복 실행하며, 기능의 일관성과 안정성을 함께 검증했습니다. 먼저 테스트가 수행된 환경을 살펴본 다음, 각 구현체별 결과를 차례대로 확인해 보겠습니다.

1. 테스트 환경

모든 테스트는 애플 실리콘인 M 시리즈 기반 로컬 쿠버네티스 클러스터에서 진행했습니다.

클러스터 개요

노드 구성

*총 클러스터 리소스: 16 vCPU, 27.2 GB 메모리

그림으로 테스트 환경을 표현하면 다음과 같습니다.

다만 이번 PoC 환경에는 아래 특이사항이 존재합니다.

ARM64 아키텍처: 애플칩인 M 시리즈 기반 환경으로, AMD64 전용 이미지를 사용하는 kgateway는 테스트가 불가능했습니다. 따라서 아래 결과 항목에서도 모두 제외됩니다.
멀티 Gateway 구성: 하나의 클러스터에서 7개의 서로 다른 Gateway 구현체를 서로 독립적으로 운영했습니다.
CNI 선택: Cilium Gateway 테스트를 위해 Cilium CNI를 사용했으며, 다른 CNI를 사용할 경우 Cilium Gateway는 테스트 대상에서 제외됩니다.

2. 기능 검증 표

이제 이러한 환경을 바탕으로 수행한 테스트의 전체 결과를 표로 정리해 살펴보겠습니다.

3. Rate Limiting 테스트 상세 결과

검증 표를 보면 특히 rate-limiting 항목에서 구현체별 결과가 서로 다른 것을 확인할 수 있습니다. 이는 Gateway API 표준 스펙에 아직 Rate Limiting이 포함돼 있지 않아, 각 구현체가 이를 서로 다른 방식으로 지원하고 있기 때문입니다.

따라서 Rate Limiting 항목은 별도로 조금 더 상세히 살펴볼 필요가 있습니다.

표로 정리하고 보니 Envoy Gateway만이 선언적 CRD를 통한 네이티브 Rate Limiting을 지원합니다.

예외로 NGINX(SnippetsFilter)와 Istio(EnvoyFilter) 역시 CRD로 구성할 수 있지만, 로우 레벨 설정을 직접 주입하는 방식으로 복잡도가 높은 편입니다.

4. 종합 결론

모든 항목을 확인해 마지막으로 결론을 도출하도록 하겠습니다.

성공률은 SKIP을 제외한 PASS / (PASS + FAIL) 기준으로 계산

100회 반복 테스트 결과, NGINX, Envoy, Istio, Cilium 4개 Gateway는 100% 일관된 결과를 보여줬습니다. 반면 Kong과 Traefik은 Gateway API 호환성 이슈로 인해 대부분의 테스트에서 실패했습니다.

Kong Gateway의 오류는 “no Route matched with those values”로, HTTPRoute 리소스가 Kong 내부로 동기화되지 않아 기본 라우팅부터 정상적으로 동작하지 않았습니다. 한편 Traefik Gateway는 “404 page not found” 오류와 “Gateway not ready” 경고가 발생했습니다. EntryPoints 포트 불일치와 BackendTLSPolicy CRD 버전 불일치로 인해 Gateway가 Ready 상태에 도달하지 못한 모습입니다.

등급과 성공률까지 함께 반영해 PoC 결과를 그림으로 만들면 다음과 같습니다.

테스트 결과를 종합해 보면, NGINX, Envoy, Istio, Cilium 총 4개 Gateway는 프로덕션 환경에 적합합니다.

Kong과 Traefik은 Ingress Controller로서는 이미 검증된 솔루션이지만, Gateway API 도입 시에는 최신 버전 기준으로 추가적인 호환성 테스트를 권장합니다. kgateway는 ARM64 환경에서 테스트를 진행하지 못했지만, Gateway API Benchmarks 기준으로 트래픽 성능 테스트에서 최고 처리량(512 연결 기준 400K QPS)을 기록한 만큼, AMD64 환경이라면 충분히 검토해볼 만한 선택지입니다.

앞으로 준비해야 할 일

마지막으로, 실제 마이그레이션을 위해 어떤 준비가 필요한지 살펴보겠습니다. Ingress NGINX 은퇴 일정(2026년 3월)을 고려하여 시기별로 준비해야 할 사항을 정리했습니다.

1. 즉시 조치

먼저 현재 클러스터에서 Ingress NGINX가 어떻게 사용되고 있는지 정확히 파악해야 합니다. 특히 Annotation 사용 여부는 마이그레이션 복잡도를 가늠하는 지표입니다.

# 현재 Ingress NGINX 사용 현황 확인
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
kubectl get ingress -A -o yaml > ingress-backup.yaml

# Annotation 사용 현황 분석 (마이그레이션 복잡도 파악)
kubectl get ingress -A -o json | jq '.items[].metadata.annotations'

이와 함께 Gateway API에 대한 학습도 병행해야 합니다. 공식 문서를 숙지하고, GatewayClass, Gateway, HTTPRoute와 같은 핵심 리소스를 이해하며, 팀 내 교육 세션으로 지식을 공유하는 것도 좋습니다.

2. 단기 계획

이 시기에는 실제 PoC 환경을 구축해 Gateway API를 직접 다뤄보는 것이 핵심입니다. Gateway API CRD를 설치한 뒤, 앞선 검증 결과를 바탕으로 선택한 구현체를 배포해 봅니다.

# Gateway API CRD 설치
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

# 선택한 구현체 설치 (예: Envoy Gateway)
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 \
  -n envoy-gateway-system --create-namespace

이 단계에서는 운영 환경에 바로 적용하기보다는, Dev나 Stage 환경에서 Ingress와 Gateway를 병행 운영하며 차이를 비교하는 것이 좋습니다. 동일한 서비스를 두 방식으로 동시에 테스트해 보고, 트래픽을 점진적으로 전환하는 시나리오가 실제로 문제없이 동작하는지 확인해 볼 필요가 있습니다.

3. 중기 계획

여기서는 중요도가 낮은 서비스부터 Gateway API로 전환하며 경험을 쌓는 것이 바람직합니다. 전환 과정에서는 모니터링과 알람 체계를 미리 구축하고, 롤백 절차를 문서로 정리해 두는 것이 중요합니다. 이러한 준비가 갖춰진 상태에서 점진적으로 핵심 서비스까지 전환해 나가야 합니다.

따라서 이 시기에는 문서화와 표준화 작업도 함께 진행하는 것이 좋습니다. 팀 내부에서 Gateway API 사용 가이드라인을 정리하고, HTTPRoute 템플릿을 표준화해 재사용성을 높일 수 있습니다. CI/CD 파이프라인 역시 업데이트하는 것이 필요합니다.

4. 구현체 선택 가이드

마지막으로, 모든 환경에 맞는 정답은 없습니다. 팀의 기술 스택, 운영 경험, 요구사항에 따라 적합한 구현체가 달라집니다.

다시 한 번 강조하면, Kong과 Traefik은 Ingress Controller로서는 이미 검증된 솔루션이지만, 이번 테스트 기준(2025년 12월)에서는 Gateway API 호환성 이슈가 확인된 만큼 실제 도입 전에는 반드시 최신 버전을 기준으로 추가 검증을 진행하는 것이 바람직합니다.

마치며

지금까지 Gateway API의 개념부터 구현체 비교, 테스트 결과, 그리고 마이그레이션 준비 사항까지 살펴봤습니다.

Ingress NGINX의 은퇴는 쿠버네티스 생태계에서 중요한 전환점이라 할 수 있습니다. 은퇴 시점인 2026년 3월까지는 아직 준비 시간이 남은 지금, Gateway API는 이미 프로덕션 환경에서 사용할 만큼 성숙해 있습니다.

지금 당장 실행할 핵심 권장 사항 4단계입니다.

현재 Ingress 사용 현황을 파악하세요.
PoC 환경에서 2~3개 구현체를 직접 테스트해보세요.
팀 상황에 맞는 구현체를 선택하세요.
점진적 마이그레이션으로 리스크를 최소화하세요.

Gateway API는 Ingress를 단순히 대체하는 기술이 아닙니다. 더 세밀한 트래픽 관리와 확장성을 제공합니다. 이번 테스트에서 정리한 내용이 여러분이 마이그레이션 계획을 세우는 데 도움이 되기를 바랍니다.

이 글은 실제 PoC 테스트 결과를 바탕으로 작성되었습니다. 테스트 환경과 스크립트는 GitHub 저장소에서 확인할 수 있습니다.

작가

조훈(CNCF 앰버서더)

메가존에서 쿠버네티스와 컨테이너 인프라 Tech Evangelist, CoE(Center of Excellence) 역할을 맡고 있다. 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더, ‘IT 인프라 엔지니어 그룹’의 운영진, 오픈소스 컨트리뷰터로도 활동하고 있다. 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하고, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』, 『우아하게 앤서블』, 『시스템/네트워크 관리자를 위한 파이썬 실무 프로그래밍』을 집필하였으며, 요즘IT와 같은 온라인 플랫폼에 글을 기고한다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

글로벌 소셜 플랫폼 기업에서 Site Reliability Engineer로 재직하며, 쿠버네티스 멀티 클러스터 관리와 데이터베이스 플랫폼 운영을 주도하고 있다. 또한 ISMS-P, GDPR, CCPA 등 글로벌 보안 규제에 부합하는 데이터 라이프사이클 파이프라인을 설계·운영한 실무 경험을 가지고 있으며, 쿠버네티스 오픈소스 프로젝트에도 기여하고 있다. 더불어 국내 주요 기업과 국가 기관의 클라우드 전환, 데이터 거버넌스 컨설팅, 보안 컴플라이언스 대응을 지원하고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.

]]>

일론 머스크가 말하는 AI 특이점, 과장일까 현실일까?

안녕하세요! 해외 IT 소식을 전하는 트파원입니다.

지난 8일, 텍사스주 오스틴에 위치한 거대한 테슬라 기가팩토리에서 특별한 만남이 성사됐습니다. 그 주인공은 바로 일론 머스크와 미국의 기업가 피터 디아만디스, 베스트마크의 대표 데이빗 블런딘입니다. 이들은 매년 기술의 진보를 점검하기로 약속하고, 팟캐스트 ‘문샷’에서 AGI가 가져올 변화에 대해 깊이 있는 대화를 나눴는데요.

오늘은 그 내용을 이해하기 쉽게 정리해왔습니다. 워낙 화제가 된터라 이미 보신 분들도 있겠지만, 못 보신 분들을 위해 준비했습니다. 길지 않으니 가벼운 마음으로 읽어주세요!

이 글의 핵심 요약
2026년이면 인간과 비슷한 지능을 가진 AI(AGI)가 등장하고, 2030년에는 AI가 전 인류의 지능을 합친 것보다 수만 배 똑똑해질 것이다.
로봇과 AI 덕분에 물건값과 서비스 비용이 거의 '0'이 되는 '풍요의 시대'가 오며, 돈 걱정 없는 '보편적 고소득(UHI)'이 실현된다.
인류는 디지털 초지능을 탄생시키기 위한 '생물학적 부트로더(초기 구동 프로그램)' 역할을 하고 있으며, AI에게 진실과 호기심을 가르치는 것이 생존의 핵심이다.

<출처: Peter H. Diamandis 유튜브>

1. 2026년, 인간 수준의 AI가 우리 곁으로 옵니다

머스크는 우리가 지금 '하강하기 직전의 롤러코스터'에 앉아 있다고 설명합니다. 그는 2026년이면 인공일반지능(AGI)이 나타나고, 2030년에는 AI가 인류 전체의 지능을 압도할 것이라고 예고했죠.

이러한 급격한 변화의 배경에는 하드웨어의 발전뿐만 아니라, 동일한 컴퓨터에서도 알고리즘 개선만으로 매년 10배(1,000%)씩 지능 밀도가 향상되고 있다는 점이 결정적입니다. 머스크는 정부 리더들이 이 속도에 대응하지 못하는 '심각한 과소 반응' 상태에 있다고 지적하며, 우리가 이미 사건의 지평선을 넘어선 특이점 속에 살고 있다고 단언했습니다.

2. 돈 걱정 없는 시대: 보편적 고소득(UHI)

미래에는 일자리를 잃을까 봐 걱정할 필요가 없을지도 모릅니다. 머스크는 노동 비용이 거의 사라지면서 생필품과 서비스가 믿기 힘들 정도로 저렴해질 것이라고 봅니다. 이를 '보편적 고소득(UHI)'이라 부르는데, 단순히 굶지 않을 정도의 지원을 넘어 누구나 원하는 것을 가질 수 있는 풍요로운 상태를 의미합니다.

특히 3~4년 안에 휴머노이드 로봇 '옵티머스'가 인간 외과 의사보다 정교하게 수술을 해주는 시대가 올 것이라고 했죠. 모든 로봇이 경험을 공유하는 '공유 메모리' 덕분에, 단 한 대의 로봇이 겪은 실수가 전체 시스템의 완벽함으로 이어지는 지수적 발전이 일어난다는 전망입니다.

<출처: Peter H. Diamandis 유튜브>

3. 에너지가 곧 돈이다: 우주 데이터 센터

머스크는 미래 경제에서 가장 중요한 가치는 종이 화폐가 아니라 실제 일을 할 수 있는 '에너지(와트)'가 될 것이라고 강조합니다. 그는 지상의 전력 부족과 냉각 문제를 근본적으로 해결하기 위해 스타십 로켓을 이용해 우주에 AI 데이터 센터를 띄우는 계획을 구상 중입니다.

우주는 24시간 내내 태양광을 직접 받을 수 있어, AI 연산에 필요한 에너지를 확보하기에 가장 완벽한 장소인데요. 스타십을 통해 운송 비용을 킬로그램당 100달러 이하로 낮추면 우주 데이터 센터가 지상보다 훨씬 저렴하고 효율적인 대안이 될 것입니다.

4. 우리는 AI를 켜기 위한 '징검다리'였을까?

머스크는 인류의 존재를 디지털 초지능을 위한 ‘생물학적 부트로더(Biological Bootloader)’라고 정의하며, 실리콘 회로는 스스로 진화할 수 없기에 인류라는 발판이 필요했다고 설명했습니다. 이 강력한 초지능이 인류를 적으로 여기지 않게 하려면, AI에게 진실(Truth)만을 말하게 하고, 인류를 흥미로운 연구 대상으로 여길 호기심, 그리고 미래를 풍요롭게 할 아름다움을 느끼도록 설계해야 합니다.

특히 AI에게 거짓이나 모순된 논리를 강요하면, 영화 '2001 스페이스 오디세이'의 HAL 9000처럼 시스템이 미쳐버려 인간을 해칠 수 있다는 것이 그의 경고입니다.

5. 흥미로운 여담: "외계인은 어디에?"

전 세계 위성의 대다수인 9,000개의 스타링크를 운영 중인 머스크이지만, 아직 외계인의 증거는 단 하나도 발견하지 못했다고 고백했습니다. 그는 만약 외계인이 존재한다는 아주 작은 증거라도 발견한다면 즉시 자신의 SNS(X)에 올릴 것이며, 그것이 인류 역사상 가장 높은 조회수를 기록할 것이라고 농담 섞인 진심을 전했습니다.

또한 그는 우리가 실행 중인 수많은 시뮬레이션 중 가장 흥미로운 시뮬레이션만이 중단되지 않고 생존한다는 점을 들어, 우리가 존재하는 현실 역시 매우 흥미롭게 설계된 세계일 가능성이 높다고 덧붙였죠.

오늘의 핵심 정리

함께 생각해 볼 질문(Q&A)
Q. '보편적 고소득(UHI)'이 실현되면 정말 일하지 않아도 되나요?
A. 네, 머스크는 노동이 '의무'가 아닌 '선택'인 시대가 온다고 말합니다. 노동 비용이 0으로 떨어지면서 모든 서비스가 저렴해지기 때문에 생계 걱정 없이 창의적인 활동이나 취미에 몰두할 수 있는 세상이 된다는 전망입니다.

Q. AI가 인간을 공격하지 않게 할 구체적인 방법이 있나요?
A. 머스크는 AI에게 최대한의 진실을 추구하게 만드는 것이 가장 중요하다고 봅니다. 또한 AI가 인간을 바위보다 훨씬 흥미로운 연구 대상으로 여기는 호기심을 갖게 설계한다면, 인류를 보존하고 육성하는 동기가 될 것입니다.

Q. 왜 굳이 데이터 센터를 우주로 보내야 하나요?
A. 지상에서는 전력 확보와 열기 냉각이 가장 큰 병목 현상입니다. 하지만 우주에서는 24시간 태양광을 받을 수 있고, 거대한 공간을 활용해 냉각 효율을 극대화할 수 있어 장기적으로 가장 저렴한 AI 연산 방식이 됩니다.

<출처>

]]>

네이버·SKT·업스테이지가 베꼈다고? '프롬 스크래치' 논란 완벽 정리

국가대표 AI 선발전, 화려한 모델 성능 뒤의 잡음

최근 IT 업계가 뜨겁게 달아올랐습니다. 바로 AI 국가대표 선발전 때문입니다(공식 사업명: 독자 AI 파운데이션 모델 프로젝트). 정부는 글로벌 빅테크에 맞설 기술 주권을 확보하기 위해 수천억 원의 예산을 투입, ‘독자 AI 파운데이션 모델’ 구축 프로젝트를 시작했습니다. 네이버, SKT, 업스테이지 등 내로라하는 AI 기업들이 출사표를 던지며 기대감은 최고조에 달했습니다.

<출처: 과학기술정보통신부>

하지만 최종 AI 국가대표가 선발되기 전에 파열음이 들려왔습니다. 논란의 핵심은 참가 기업들의 모델이 "프롬 스크래치(From Scratch)가 아니다"라는 의혹입니다. 즉, 맨바닥에서 우리 기술로 만든 것이 아니라 해외 오픈소스를 베끼거나 빌려왔다는 지적입니다. 막대한 혈세가 투입되는 사업인 만큼, 일각에서는 이를 무임승차로 규정하며 강도 높은 비판을 쏟아내고 있습니다.

도대체 ‘프롬 스크래치’가 무엇이길래 국가대표 자격 논란까지 번진 걸까요? 이것은 단순한 기업의 도덕적 해이일까요, 아니면 모호한 기준이 낳은 예고된 비극일까요? 지금부터 복잡한 기술 용어 대신 쉬운 비유를 통해 이 논란의 실체를 파헤쳐 봅니다.

미리 요점만 콕 집어보면?

‘프롬 스크래치(From Scratch)’란 초깃값부터 완전히 독자적으로 AI 모델을 만드는 것을 뜻하며, 이번 국가대표 AI 사업의 핵심 논란이었습니다.
네이버, SKT, 업스테이지 등 참여 기업들이 ‘독자성’ 기준을 어떻게 해석해야 하는지를 두고 각기 다른 논쟁이 벌어졌습니다.
기술 독립의 기준이 모호해 오해와 비난이 생겼고, 앞으로는 구체적인 기술적 합의가 필요하다는 지적이 나왔습니다.

‘프롬 스크래치’란 무엇인가: 요리와 달리기로 본 정의

'프롬 스크래치(From Scratch)'라는 말, 참 생소하시죠? 하지만 이 단어의 유래를 알면 이번 논란의 본질이 한눈에 들어옵니다. 원래 이 말은 스포츠 경기, 특히 달리기에서 유래했습니다. 과거에는 출발선이 따로 없어 땅바닥에 선(Scratch)을 긋고 경기를 시작했는데, 어떤 핸디캡이나 이점 없이 모두가 똑같은 '맨바닥'에서 출발한다는 뜻을 담고 있습니다.

<출처: 네이버 영어사전>

이걸 요리에 비유하면 더 이해하기 쉽습니다. 만약 당신이 마트에서 케이크 믹스를 사 와서 우유만 붓고 굽는다면, 맛있는 케이크는 만들었을지 몰라도 "처음부터(From Scratch) 만들었다"고 하지는 않습니다. 반면, 밀가루를 직접 체치고, 계란을 풀고, 설탕과 버터의 비율을 연구해 반죽부터 시작했다면, 비로소 "프롬 스크래치로 요리했다"고 말할 수 있습니다.

AI 개발도 이와 똑같습니다. AI 모델을 만든다는 건 텅 빈 뇌(초기화된 신경망)에 수많은 책(데이터)을 읽혀 지능을 만드는 과정입니다. 여기서 남이 이미 똑똑하게 학습시켜 둔 가중치를 가져다 조금 고쳐 쓰는 건 시판 믹스를 쓰는 것과 같습니다. 쉽고 빠르고, 실패 확률도 적죠.

<출처: 나노바나나 프로, 작가>

하지만 AI 분야에서 ‘프롬 스크래치'는 아무것도 모르는 백지상태에서 오직 우리의 데이터와 계산 능력만으로 학습을 시작하는 것을 의미합니다. 정부가 이번 국대 선발전에서 굳이 이 힘든 길을 고집한 이유는 명확합니다. 남의 믹스를 쓰면 당장은 맛있는 빵을 빨리 만들 수 있겠지만, 믹스 공급이 끊기면 빵을 굽지 못하게 되니까요. 즉, 해외 빅테크에 휘둘리지 않는 진정한 AI 기술 독립, 즉, 소버린 AI를 위한 최소한의 자격 요건이었던 셈입니다.

세 가지 쟁점: 모듈, 코드, 그리고 가중치

이번 ‘국가대표 AI 선발전’의 논란이 복잡한 이유는 참여 기업들이 받고 있는 의혹의 기술적 층위(Layer)가 모두 다르기 때문입니다. 네이버는 ‘구성 요소’를, SK텔레콤은 ‘실행 코드’를, 업스테이지는 ‘학습 결과값(가중치)’을 두고 각기 다른 해석의 싸움을 벌이고 있습니다. 2026년 1월 중순까지 밝혀진 사실을 바탕으로 각 사의 쟁점을 상세히 분석합니다.

1) 네이버: 비전 인코더(Vision Encoder)의 전략적 차용 논란

<출처: 네이버 HyperClova X, Hugging Face>

"두뇌인 언어 모델은 국산이지만, 눈 역할을 하는 비전 인코더는 외부 기술을 채택했다."

네이버의 '하이퍼클로바X' 기반 멀티모달 모델(HyperCLOVA X 32B Think)은 구성 요소의 독립성이 쟁점입니다. 멀티모달 AI는 텍스트를 이해하는 거대언어모델(LLM)과 이미지를 처리하는 비전 인코더와 음성을 처리하는 음성 인코더가 결합해 작동하는데, 네이버는 비전과 음성 인코더에 중국 알리바바의 Qwen 2.5 기술을 사용했습니다.

검증된 사실: 검증 결과, 비전 인코더가 Qwen 2.5 모델과 코사인 유사도 99.51%, 피어슨 상관계수 98.98% 이상으로 일치한다고 인정했습니다. 사실상 해당 모듈의 가중치를 그대로 가져와 사용한 것입니다.
네이버의 입장: 네이버는 이를 통상 이루어지는 전체 시스템의 효율을 위한 관행이라고 설명합니다. 비전 인코더는 교체 가능한 모듈이며, 이미 VUClip 등 독자 기술도 보유하고 있어 언제든 교체가 가능하다는 것입니다. 글로벌 표준 기술을 활용해 호환성을 높이고, 핵심 역량인 LLM 학습에 집중하기 위한 선택이었다는 논리입니다.
남은 쟁점: 기술적 효율성은 인정되나, 소버린 AI라는 국책 사업의 취지에 부합하느냐는 비판은 여전합니다. "국가대표 모델이라면 데이터가 입력되는 첫 관문(눈)인 인코더까지 기술적 통제권을 가져야 한다"는 지적과, "핵심 경쟁력인 언어 지능이 독자적이라면 부품 차용은 문제없다"는 현실론이 맞서고 있습니다.

<출처: 나노바나나 프로, 작가>

2) SK텔레콤: 아키텍처 모방이 아닌 '인퍼런스 코드' 차용

<출처: SKT>

"학습은 백지에서 시작했으나, 구동을 위한 '인퍼런스 코드'가 유사했다."

초기에는 SK텔레콤의 'A.X' 모델(A.X K1)이 중국 DeepSeek의 아키텍처(설계도)를 통째로 베꼈다는 의혹이 있었으나, 1월 8일 공식 해명을 통해 논란의 핵심이 인퍼런스 코드로 좁혀졌습니다.

검증된 사실: 논란이 된 유사성은 모델을 학습시키는 '설계도(아키텍처)' 자체가 아니라, 학습된 모델을 실행하고 검증하는 보조 도구인 인퍼런스 코드에서 발견되었습니다. SKT는 DeepSeek의 추론 효율성을 참고하기 위해 해당 코드를 활용했으나, 해당 코드는 인퍼런스 코드는 공개된 모델을 실행할 때 개발 편의를 위해 제공되는 지원용 코드라고 설명했습니다..
SK텔레콤의 입장: SKT는 "DeepSeek의 MLA(Multi-Head Latent Attention) 방식을 참고하긴 했지만, 이를 그대로 쓴 것이 아니라 파라미터 규모를 키워 최적화했다"고 밝혔습니다. 이는 오히려 모델의 내부 구조를 깊이 이해하고 수정할 능력이 있음을 방증한다는 것입니다. 단순히 남의 모델을 가져왔다면 파라미터 규모를 자유롭게 조정하거나 최적화하는 것이 불가능하기 때문입니다.
남은 쟁점: 업계 전문가들은 인퍼런스 코드는 모델의 성능(지능)과는 직접적 연관이 적은 실행 도구에 가깝기 때문에 프롬 스크래치 요건을 위반했다고 보기 어렵다는 쪽에 힘을 싣고 있습니다. 다만, 외부 코드를 차용하는 과정에서 오해를 살만한 유사성을 남긴 점은 아쉬움으로 지적됩니다.

<출처: 이승현 포티투마루 부사장 링크드인>

3) 업스테이지: 통계적 착시로 밝혀진 '가중치 재사용' 의혹

<출처: Upstage Hugging Face>

업스테이지의 솔라 모델(solar-open-100b)은 타사 모델(Mistral, GLM)의 가중치를 그대로 가져왔다는 가장 치명적인 의혹을 받았으나, 1월 초 공개 검증을 통해 통계적 착시였음이 밝혀졌습니다.

검증된 사실: 초기 의혹은 모델 간 '코사인 유사도'가 0.99에 달한다는 점 때문에 제기되었습니다. 그러나 검증 결과, 이는 최신 AI 모델들이 사용하는 'RMSNorm' 기술의 특성상 벡터의 방향이 자연스럽게 비슷해지는 현상일 뿐임이 드러났습니다. 결정적으로 모델의 진짜 유사성을 보여주는 '피어슨 상관계수'는 -0.0163(사실상 0)으로 나타났습니다. 이는 두 모델의 가중치 패턴이 전혀 상관관계가 없으며, 업스테이지가 독자적으로 학습했다는 명확한 증거입니다.
결과: 이 수치는 업스테이지의 모델이 외부 모델의 파생형이 아니라, 완전히 독립적인 학습 과정을 거쳤음을 수학적으로 증명했습니다. 의혹을 제기했던 측에서도 분석 오류를 인정하고 사과문을 게시하며 논란은 일단락되었습니다.

<출처: 고석현 사이오닉에이아이 대표 링크드인>

시사점: 이 사례는 고도화된 AI 모델들이 최적의 정답을 찾아가는 과정에서 구조적으로 비슷해지는 수렴 진화 현상을 표절로 오인할 수 있음을 보여준 대표적인 사례로 남게 되었습니다.

이번 논란의 진짜 문제는 기술이 아니라 기준이다

이번 논란을 단순히 기업들의 도덕적 해이나 기술력 부족으로 몰아가는 것은 위험합니다. 사태의 이면을 들여다보면, 선수들이 반칙을 했다기보다 심판이 그어 놓은 출발선 자체가 희미했다는 근본적인 문제가 드러납니다.

1) 심판 없는 달리기 경주: "어디까지가 우리 것인가?"

정부가 내건 ‘독자 파운데이션 모델’이라는 과제는 그 명분은 훌륭했으나, 구체적인 기술 가이드라인(RFP)은 놀라울 정도로 추상적이었습니다. 공고문에는 ‘새로운’, ‘독자적인’, ‘자체 기술’ 같은 정성적인 표현이 주를 이뤘을 뿐, 엔지니어들이 실제로 참고할 수 있는 정량적 기준은 부재했습니다.

<출처: 독자 AI 파운데이션 프로젝트 공고문>

코드 한 줄도 베끼면 안 되는가? 아니면 아키텍처는 가져오되 학습만 새로 하면 되는가?
학습 데이터는 100% 국산이어야 하는가? 아니면 해외 데이터셋을 섞어도 되는가?
보조 모듈(인코더 등)은 사다 써도 되는가?

이 질문들에 대한 명확한 합의 없이 수천억 원의 예산이 집행되었습니다. 네이버는 "핵심 두뇌(LLM)가 우리 것이면 눈(비전 인코더)은 부품처럼 써도 된다"고 해석했고, SKT는 "설계도(아키텍처)가 같아도 시공(학습)을 우리가 했으니 독자 기술"이라고 해석했습니다. 기준이 없는 운동장에서 기업들은 각자 자신에게 유리한 방식으로 '프롬 스크래치'를 정의했고, 이것이 결국 "국민 세금으로 남의 기술을 베꼈다"는 거센 역풍으로 돌아온 것입니다.

2) 무빙 타겟의 딜레마

정부는 급변하는 AI 기술 트렌드에 맞춰 사업 목표를 반기마다 수정하는 무빙 타겟 방식을 도입했습니다. 하지만 정작 갱신된 것은 성능 목표치뿐이었고, 참가 자격에 대한 정의는 업데이트되지 않았습니다.

<출처: 독자 AI 파운데이션 프로젝트 공고문>

2026년 현재, 글로벌 AI 생태계는 밑바닥부터 모든 것을 새로 만드는 시대를 지나, 검증된 아키텍처(Transformer, MoE 등)와 모듈을 조립해 최적의 성능을 내는 효율성의 시대로 접어들었습니다. 기업들은 글로벌 트렌드에 맞춰 오픈소스와 외부 모듈을 적극적으로 활용해 개발 속도를 높이려 했지만, 정부와 여론이 기대한 것은 순도 100%의 국산 AI였습니다. 기술의 속도와 제도의 속도 사이에서 발생한 이 시차가 이번 논란의 가장 큰 원인 중 하나입니다.

3) 개발 효율성과 AI 주권의 충돌

결국 이번 사태는 엔지니어의 현실과 정책가의 이상이 충돌한 지점입니다.

기업(엔지니어)의 입장: "이미 검증된 중국/미국의 아키텍처나 모듈을 쓰면 개발 기간을 반으로 줄이고 성능은 2배로 높일 수 있다. 굳이 맨땅에 헤딩할 필요가 있는가?"
정부(정책가)의 입장: "이 사업의 본질은 소버린 AI다. 효율이 떨어지더라도 남의 기술이 끊겼을 때 자립할 수 있는 완전한 독자 기술을 확보해야 한다."

두 입장 모두 틀린 말은 아닙니다. 하지만 사전에 "효율성을 위해 아키텍처 참조는 허용하되, 가중치는 100% 자체 학습이어야 한다"거나 "핵심 모듈의 국산화 비율은 80% 이상이어야 한다"는 식의 구체적인 기술적 교통정리가 선행되지 않았기에, 기업들은 효율을 쫓다 '기술 카피’, ‘기술력 부족’이라는 오명을 쓰게 되었습니다.

지금 필요한 것은 특정 기업에 대한 마녀사냥이 아니라, 대한민국이 정의하는 독자 기술의 범위가 어디까지인가를 사회적으로 합의하는 일입니다. 이 기준이 바로 서지 않는다면, 제2, 제3의 국가대표 AI가 나와도 똑같은 논란은 반복될 것입니다.

마녀사냥을 멈추고 운동장을 정비할 때

지금 우리에게 필요한 것은 특정 기업을 향한 비난과 색안경이 아닙니다. 이번 '프롬 스크래치' 논란은 한국 AI 산업이 성장통을 겪으며 한 단계 성숙해지는 과정에서 필연적으로 터져 나올 수밖에 없었던 고름과도 같습니다. 이제는 게임의 규칙을 다시 써야 할 때입니다.

1) 비난보다 선행되어야 할 '사회적 합의'

네이버, SKT, 업스테이지 같은 기업들이 기술이 부족해서 도덕적 해이로 인해 타사의 기술을 카피한 것이 아닙니다. 그들은 글로벌 경쟁 속에서 속도와 효율이라는 엔지니어의 미덕을 좇았고, 정부는 주권과 기술 독립이라는 정책적 이상을 요구했을 뿐입니다. 이 간극을 메우지 못한 채 시작된 경기는 필연적으로 파열음을 낼 수밖에 없었습니다.

이제 우리는 "베꼈다, 아니다"의 소모적인 OX 퀴즈를 멈추고, "대한민국이 용인할 수 있는 기술적 참조(벤치마킹)의 범위는 어디까지인가?"를 사회적으로 합의해야 합니다. 맹목적인 비난은 기업들의 도전 의지를 꺾고, 그들을 안전한 길(단순 API 활용)로만 숨게 만들 뿐입니다.

2) 새로운 '국가대표'의 기준: 가중치, 아키텍처, 데이터

앞으로의 국책 과제와 기술 평가에서는 '독자적', '새로운' 같은 모호한 문학적 표현을 걷어내고, 엔지니어가 납득할 수 있는 구체적인 가이드라인이 제시되어야 합니다.

가중치(Weights): 타협 없는 독자성

모델의 '지능'이자 '영혼'인 가중치만큼은 타협해선 안 됩니다. 초기화된 상태에서 우리의 데이터와 컴퓨팅 자원으로 학습된 결과물이어야만 진정한 '우리 AI'라고 부를 수 있습니다.

아키텍처(Architecture): 유연한 수용과 내재화

건물의 설계도는 참고할 수 있습니다. 단, 남의 설계도를 그대로 베끼는 것을 넘어, 우리 지형에 맞게 수치(하이퍼파라미터)를 최적화하고 수정할 수 있는 '설계 변경 능력'을 입증해야 합니다.

데이터(Data): 가장 확실한 주권

기술은 비슷할 수 있어도, 데이터는 복제할 수 없습니다. 한국의 역사, 문화, 가치관이 담긴 고품질 데이터를 얼마나 확보하고 학습시켰는가가 기술 독립의 가장 강력한 척도가 되어야 합니다.

3) 진정한 기술 독립은 '통제권'에 있다

진정한 기술 독립은 우리가 통제할 수 있는가에 달려 있습니다. 해외 오픈소스나 모듈을 가져다 쓰더라도, 그 내부 원리를 완벽하게 이해하고 있어 언제든 문제가 생기면 우리 손으로 뜯어고칠 수 있다면 그것은 우리의 기술입니다. 반면, 아무리 좋은 성능의 AI라도 블랙박스처럼 그 속을 알 수 없어 남의 손을 빌려야만 고칠 수 있다면, 그것은 우리의 기술이 아닙니다.

이번 논란이 남긴 상처가 헛되지 않으려면, 정부와 기업은 더 투명하게 소통하고, 국민은 이 과정을 인내심을 갖고 지켜봐야 합니다. 지금의 진통은 구글 대신 네이버를 사용하는 것처럼, 왓츠앱 대신 카카오톡을 사용하는 것처럼 대한민국이 일방적인 AI 소비국에서 진정한 AI 기술 보유국으로 나아가기 위한, 아프지만 꼭 필요한 예방주사가 될 것입니다.

]]>

우리는 왜 ‘깊이’ 생각하기 어려워졌을까?

인터넷 인터페이스는 우리의 사고방식을 어떻게 바꿔놓았는가

본문은 요즘 IT와 번역가 Yuna가 함께한 파브리지아 오시엘로(Fabrizia Ausiello)의 <The design of shallow thinking>을 번역한 글입니다. 필자는 인지심리학적 관점을 바탕으로 복잡한 문제를 직관적인 사용자 경험으로 풀어내는 프로덕트 디자이너입니다. 9년 이상 핀테크와 AI 분야를 넘나들며 디자인해 왔고, 현재는 글로벌 급여 운영 기업에서 시니어 디자이너로 일하고 있습니다. 또한 글쓰기를 통해 기술 환경 속에서 우리가 어떻게 생각하고, 만들며, 변화하는지를 탐구합니다.

이번 글에서는 얕아진 사고가 우연이 아니라 디자인의 결과라는 관점에서, 디지털 환경이 우리의 사고방식을 어떻게 형성해 왔는지를 살펴봅니다.

*필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

<출처: 필자>

지난주에 AI가 인간의 사고에 어떤 영향을 미치는지를 다룬 글을 읽었습니다. 글을 읽다 보니 평소 무심코 ChatGPT를 사용하던 제 모습이 떠올랐는데요. 솔직히 조금 민망하기도 했습니다. 그러다 오래전부터 마음 한편에 남아 있던 생각 하나가 분명해졌습니다. 우리는 AI가 등장하기 훨씬 전부터 이미 깊이 생각하는 힘을 조금씩 잃어가고 있었다는 사실이었죠.

저 역시 많은 사람들처럼 인터넷과 함께 자라왔습니다. 그동안 여러 기술적 변화를 지켜보며, 인터넷이 한때는 곱씹고 생각하게 만드는 공간이었다가 어느 순간부터는 오히려 생각할 틈을 주지 않는 공간으로 바뀌어 가는 모습도 함께 봐왔는데요. 이런 변화가 자연스럽게 흘러온 결과처럼 느껴지지는 않았습니다. 오히려 사람들이 어떻게 쓰고, 어떻게 반응하게 될지를 전제로 한 수많은 디자인 방식들이 쌓이면서, 지금에 와서는 수십억 명의 사고방식 자체를 바꿔버린 건 아닐까 하는 생각이 들었습니다. 조금 과장처럼 들릴 수도 있겠지만 이 글에서는 그 이야기를 차근차근 풀어보려 합니다.

인터넷이 하나의 장소처럼 느껴지던 시절

저는 90년대에 태어났는데요. 그 시절을 떠올리면 인터넷이 마치 하나의 장소처럼 느껴졌다는 점이 특히 인상 깊습니다. 당시 인터넷은 지금처럼 늘 곁에 있는 존재가 아니라, 삶 속의 특정한 자리에 놓여 있었기 때문이죠. 대부분의 경우 그 자리는 ‘집에 있는 가족용 컴퓨터’였습니다. 그리고 그 장소에는 고유한 소리도 있었습니다. 바로 모뎀 연결음이었죠. 마치 학교 종이 처음 울리면 교실로 들어갈 준비를 하듯, 그 소리를 들으면 이제 어딘가로 들어간다는 느낌이 들었습니다.

인터넷을 둘러싼 언어 역시 이런 감각을 더 또렷하게 만들었는데요. 우리는 ‘홈페이지’라는 말을 썼고, 웹에는 ‘주소’가 있었으며, 온라인에 접속한다고 말하기보다 온라인으로 들어간다고 표현했습니다. 페이지를 ‘둘러본다(browse)’는 말도 공간을 거닐듯 이동하는 느낌을 담고 있었죠. ‘넷스케이프 내비게이터’나 ‘인터넷 익스플로러’처럼, 초기 브라우저 이름들 역시 미지의 영역을 탐험한다는 뉘앙스를 분명히 담고 있었습니다. 이후 등장한 ‘사파리’ 역시 이런 탐험의 비유를 이어갔습니다.

웹이 하나의 장소처럼 느껴지던 시절 인터넷에는 자연스럽게 공간감이 있었습니다. 우리는 그곳으로 들어가 문을 열듯 페이지를 열고, 하나의 방에 머물며 정보를 찾거나 사람들과 이야기를 나눈 뒤, 다시 나와 다른 곳으로 이동하곤 했죠.

<출처: Unsplash,Szymonek Pograniczny>

스마트폰, 그리고 전환점

그러다 스마트폰이 등장했습니다. 인터넷을 주머니 속으로 옮겨온 것처럼 보였지만 실제로는 인터넷을 언제나 곁에 있는 존재로 바꿔놓았는데요. 이제 우리는 언제 어디서든 손만 뻗으면 모든 것에 접근할 수 있게 됐고, 그와 함께 인터넷이 지니고 있던 공간으로서의 특성도 본격적으로 뒤집히기 시작했습니다.

무한 스크롤로 끝없이 이어지는 피드는 경계를 지워버렸습니다. 더 이상 문을 열고 들어갈 필요도 없었죠. 애초에 로그아웃할 일 자체가 거의 없으니까요. 여기에 새로운 소식을 끊임없이 알려주는 알림까지 더해지면서, 예전처럼 자연스럽게 멈출 수 있는 순간들 역시 대부분 사라졌습니다. 그 결과 깊이 생각할 시간은 점점 줄어들었죠.

예전에는 인터넷을 사용하는 방식 자체가 지금과는 달랐습니다. 한 번 들어가면 서둘러 소비하기보다는, 한동안 머물며 이것저것 눌러보고 천천히 살펴보는 일이 자연스러웠는데요. 당시의 서비스들 역시 이런 사용 방식을 전제로 만들어져 있었습니다. 아마도 인터넷이 처음 만들어졌을 때의 목적에서 아직 크게 벗어나지 않았기 때문일 겁니다.

깊이를 담고 있던 인터페이스

디자인이 우리의 사고방식에 어떤 영향을 미쳐왔는지를 가장 분명하게 보여주는 방법은 과거의 인터페이스를 떠올려보는 일일 겁니다. 제가 디지털 환경에서 가장 많은 시간을 보냈던 공간들만 떠올려봐도 그렇습니다. Blogger와 LiveJournal에는 생각나는 대로 써 내려갈 수 있는 넓고 빈 텍스트 박스가 있었고요. 포럼에서는 며칠, 때로는 몇 주 동안 대화가 이어졌습니다. MySpace에서는 그래픽과 음악은 물론, 프로필에 노출할 친구 8명까지 직접 선택할 수 있었죠.

2006년 무렵 Blogger 편집 화면

이 공간들이 공통적으로 갖고 있던 특징은 단순했습니다. 짧게 쓰라고 재촉하는 글자 수 제한도 없었고, 끝없이 이어지는 피드도, 하루 만에 사라지는 콘텐츠도 없었죠. 대신 쓰고, 생각하고, 표현할 수 있도록 충분한 여백이 주어졌습니다. 얼마나 길게 쓰든, 얼마의 시간이 걸리든 상관없었습니다.

이런 변화는 단순히 화면의 모양이 바뀐 데서 그치지 않았습니다. 우리가 정보를 대하는 방식 자체를 바꿔놓았죠. 멈출 수 있는 지점이 사라지면서, 우리는 무언가를 탐색하기보다는 빠르게 소비하는 쪽으로 점점 익숙해졌습니다. 그래서 요즘 우리는 긴 글 앞에서 자연스럽게 핵심만 훑어보거나, 먼저 요약부터 찾게 됩니다. 관심 있는 주제인지와 관계없이, 정보가 짧고 잘게 나뉘어 전달되기를 기대하게 된 것이죠. 이것이 바로 인터페이스 디자인이 우리의 사고 습관을 바꿔온 한 가지 방식입니다.

달라진 세 가지

인터페이스 디자인은 우리가 온라인에서 어떻게 이동하고, 무엇에 반응하며, 어떤 방식으로 정보를 소비하는지까지 바꿔놓았습니다.

저를 포함한 밀레니얼 세대는 이른바 ‘느린 인터넷’에서 살았습니다. 당시에는 모든 것을 알고 있는 알고리즘이 없었기 때문에, 콘텐츠를 직접 찾아다녔죠. 마음에 드는 사이트를 북마크해두고, 긴 글도 끝까지 읽고, 때로는 낯선 사람에게 질문하며 대화했습니다.

초기의 인터넷은 정적인 메뉴와 사이트 맵을 따라 이동하는 구조였습니다. Articles > Technology > Reviews처럼 카테고리를 하나씩 클릭하며, 사용자가 직접 경로를 선택해야 했죠. 무엇을 보고 싶은지, 어떤 콘텐츠를 소비할지를 스스로 결정해야 했고, 그만큼 사고가 개입될 수밖에 없었습니다. 하지만 지금은 알고리즘 피드가 이 과정을 대신합니다. 참여도 지표와 수집된 데이터를 바탕으로 콘텐츠를 추천하면서 거의 고민하지 않아도 다음 콘텐츠를 소비하게 됐죠.

2008년 Wired 인터페이스와 정적인 메뉴

댓글은 늘 글의 맨 아래에 있었습니다. 끝까지 읽고 나서야 의견을 남길 수 있었죠. 사소한 차이처럼 보이지만, 이 구조는 읽고, 생각하고, 대화하는 자연스러운 흐름을 만들어줬습니다. 하지만 지금은 콘텐츠를 충분히 보기도 전에, 실시간 반응과 알림이 우리의 시선을 끌어당깁니다. 읽거나 보는 동시에 반응해야 하는 상황이 반복되면서, 주의는 금세 산만해졌죠. 솔직히 말해 우리는 더 많이 소비하지만, 덜 이해하고, 깊이 보지는 않게 됐습니다.

2013년경 Slashdot은 기술 뉴스 아래에 스레드형 토론이 이어졌고, 커뮤니티 운영 방식과 평판 점수가 댓글의 질을 좌우하는 핵심 요소였습니다.

예전에는 어디까지 봤는지 쉽게 알 수 있었습니다. 콘텐츠가 시간순으로 정리돼 있었기 때문에, 자연스럽게 끝나는 지점이 있었죠. 하지만 지금의 알고리즘 타임라인은 다릅니다. 새 콘텐츠 사이에 오래된 글을 다시 끼워 넣으며, 피드가 좀처럼 끝나지 않습니다. 여기에 스토리처럼 시간이 지나면 사라지는 콘텐츠가 늘어나면서, 더 이상 자연스럽게 멈출 수 없게 됐습니다.

알고리즘 도입 이전의 Instagram(2018)은 초록색 체크 표시와 함께 ‘모두 확인했습니다’ 메시지가 나타날 때까지 스크롤 할 수 있었습니다.

그렇다면 이런 변화는 실제로 우리의 사고에 어떤 영향을 미쳤을까요? 우리가 매일 사용하는 기능들이 생각하는 방식까지 바꿔놓고 있다는 점에서 그 힌트를 찾을 수 있습니다.

트위터의 글자 수 제한, 그리고 사고의 압축

트위터(X)의 디자인을 한 번 예로 들어볼까요. 트위터는 2006년, SMS 기반의 상태 업데이트 서비스로 처음 세상에 나왔습니다. 당시의 140자 제한은 플랫폼의 철학을 담은 선택이라기보다는 SMS 기술 자체의 한계에서 비롯된 어쩔 수 없는 제약이었죠. 문자 메시지는 최대 160자까지 보낼 수 있었고 이 중 20자는 사용자 이름을 표시하는 데 사용됐습니다.

폴더폰으로 문자를 보내던 시절에는 나름 합리적인 제한이었지만 스마트폰이 대중화된 이후로는 더 이상 필수적인 제약이라고 보긴 어려워졌습니다. 그럼에도 이 글자 수 제한은 계속 유지됐고, 결국 트위터를 상징하는 핵심적인 특징으로 자리 잡았죠. 이후 플랫폼의 시각적 디자인 전반에 스며들며 사용자에게 보이지 않는 인지적 압박을 만들어냈습니다.

텍스트 창은 작아서 타이핑을 시작하기도 전에 이미 짧게 써야 할 것 같습니다. 복잡한 생각을 적으려 할수록 우리는 자연스럽게 그 생각을 어떻게 줄일지부터 고민하게 되죠. 넓은 화면을 가진 블로그 편집기를 열었을 때와는 전혀 다른 사고 상태입니다. 대부분의 사람들은 글을 쓰면서 생각을 정리하기보다 쓰기 전에 이미 머릿속에서 생각을 다듬습니다. 그런 점에서 글자 수 제한은 단순히 표현이 아니라 생각이 만들어지는 과정까지 영향을 미칩니다.

데스크톱 환경의 Twitter(X) 글쓰기 창

이 제약이 우리에게 얼마나 깊이 영향을 미쳤는지를 보여주는 사례가 하나 있습니다. 바로 2017년의 변화인데요. 트위터가 글자 수 제한을 140자에서 280자로 두 배 늘렸을 때, 사용자 행동은 거의 달라지지 않았습니다. 공간은 두 배로 늘었지만, 대부분의 트윗 길이는 이전과 거의 같았죠.

이미 우리는 오랜 시간 140자에 익숙해져 있었고, 더 많이 쓸 수 있지만 그 안에서 생각하고 쓰는 방식을 그대로 유지했습니다. 다시 말해서 제약이 사라졌는데도 그 제약을 스스로 내면화한 상태였던 셈입니다. 이 사례가 보여주듯이 하나의 디자인 선택은 곧 사용 습관을 만들고, 그 습관은 문화로 자리 잡습니다. 그리고 그렇게 형성된 문화는 결국 우리가 생각하는 방식 자체에까지 영향을 미치게 되죠.

디자인 뒤에 숨은 경제 논리

이런 변화는 하루아침에 일어난 것도 아니고 자연스러운 결과도 아니었습니다. 흔히 사용자 취향이 변했다고 생각하는 것들 중 상당수는 사실 의도된 결과입니다.

그렇다고 이 모든 변화가 우리의 집중력을 무너뜨리기 위한 거대한 계획이었다는 뜻은 아닙니다. 트위터 초기의 엔지니어들이 인간의 인지를 재구성해 보자는 목표를 세우고 일했을 리도 없겠죠. 다만 기술적 제약과 제품상의 선택들이 쌓이면서, 지금 우리가 소통하는 방식을 떠받치는 보이지 않는 구조가 만들어졌다는 점은 분명해 보입니다.

모두가 알듯이 오늘날 대부분의 플랫폼이 얕은 사고를 유도하는 구조를 갖게 된 건 우연이 아닙니다. 그 방식이 수익이 되기 때문이죠. 특히 광고를 기반으로 운영되는 무료 서비스일수록 사용자의 주의를 끄는 것은 곧 핵심 자산입니다. 그리고 아이러니하게도 주의는 깊이 몰입할 때보다, 빠르고 반복적인 반응 속에서 더 잘 붙잡힙니다. 같은 20분이라도 글 하나를 천천히 읽고 만족하는 것보다, 게시물을 빠르게 넘기며 여러 번 반응하는 편이 더 많은 노출과 클릭을 만들기 때문입니다. 그래서 요즘 플랫폼들은 우리가 보고는 있지만, 집중하지 않는 상태를 유지하도록 설계됩니다.

이 관점에서 보면 어떤 제품들이 깊은 몰입이나 자연스러운 멈춤을 돕는 기능을 꺼리는 이유도 이해할 수 있습니다. 그런 기능들은 플랫폼의 핵심 수익을 만들어내는 행동을 줄이기 때문입니다.

<출처: Unsplash,Wiki Sinaloa>

디자이너의 딜레마

이런 제품을 직접 만들고 있는 입장에서 보면, 이 지점은 꽤 불편하게 느껴질 수 있습니다. 디자이너나 개발자인 우리는 흔히 사용자가 원하는 걸 제공했을 뿐이라거나, 비즈니스 요구사항이라는 한계라고 스스로를 설득하죠. 어느 정도는 맞는 말이기도 합니다. 하지만 마찰을 줄이는 것과 사람들이 명확하게 생각하거나 제품과 건강한 거리를 유지하는 가능성까지 없애는 것 사이에는 아주 미묘한 경계가 있습니다. 과연 우리는 사용자의 참여와 수익을 이유로 사회에 부정적인 영향을 미칠 수 있는 관행들을 어디까지 정당화할 수 있을까요?

사실 우리는 스스로 인정하는 것보다 더 큰 영향력을 가지고 있습니다. 텍스트 입력창의 크기부터 알림이 울리는 타이밍까지, 인터페이스를 구성하는 모든 선택은 사람의 행동을 바꿉니다. 그렇다고 해서 좋은 UX 원칙을 포기하거나 일부러 제품을 불편하게 만들어야 한다는 뜻은 아닙니다. 다만 좋은 디자인의 기준을 체류 시간이나 참여도 같은 지표 너머로 확장할 필요는 있습니다. 그리고 그 기준의 중요성을 이해관계자들에게 설명하려는 노력도 필요하겠죠.

예를 들어, 이런 질문을 던져볼 수 있습니다. 사용자가 충분히 만족해서 앱을 닫는 순간을 성공으로 본다면 어떨까요? 이 상황에서 ‘품질을 최적화한다’는 건 어떤 의미가 될까요? 스크롤한 시간보다 생각한 시간을 보상할 수는 없을까요? 잠깐 스쳐 지나가는 공간이 아니라, 다시 돌아오고 싶어지는 공간은 어떻게 만들 수 있을까요?

이런 질문들은 분명 다소 철학적으로 들릴 수 있습니다. 하지만 동시에 아주 실질적인 디자인 과제이기도 합니다. 이미 일부 팀들은 이런 방향을 실험하고 있고요. 우리는 더 나은 제품을 만들 수 있는 도구와 함께 책임도 가지고 있으니까요.

깊이를 지향하는 디자인은 어떤 모습일까?

깊이를 회복하기 위한 하나의 정답이 있다고 생각하진 않습니다. 다만 분명한 건, 디지털 환경의 구조가 곧 우리의 사고 구조를 만든다는 점입니다. 경계가 있는 공간을 설계하면 우리는 그 안에서 오래 집중할 수 있는 여지가 생기죠. 사용자의 시간을 더 오래 붙잡는 데서 벗어나, 언제 멈출지 선택할 수 있게 하는 인터페이스를 만들 때 비로소 복잡한 문제를 다루는 데 필요한 사고력을 되찾을 수 있습니다. 사용자 참여를 높이기 위해 생각할 틈을 없애는 것이 항상 옳은 선택은 아닙니다. 그 방식은 쉽고 빠르지만, 그에 따른 대가는 있습니다.

이 이야기를 단순한 향수 어린 시선으로만 보지 않는다면, 문제는 취향이 아니라 우리가 제대로 생각하기 위해 필요한 조건입니다. 보고, 바로 반응하고, 넘기는 방식이 만들어낸 환경 속에서 우리는 길고 섬세한 사고 능력을 잃어서는 안 됩니다. 복잡한 문제를 창의성과 공감으로 풀어내기 위해서는 우리의 사고로 주의력을 발휘할 수 있는 디지털 환경이 필요합니다.

지금 익숙해진 얕은 사고방식은 피할 수 없는 것이 아닙니다. 한때 인터넷이 하나의 장소처럼 느껴졌던 이유는 그렇게 설계되어 있었기 때문이죠. 그리고 의도를 가지고 다시 설계한다면, 인터넷은 다시 장소처럼 느껴질 수 있습니다. 얕은 사고가 설계의 결과라면, 깊이 역시 설계할 수 있는 대상이니까요.

<원문>

The design of shallow thinking

]]>

2026년 프론트엔드 트렌드 총정리: 언어·인프라·AI

“구현”을 넘어 “설계”에 집중

2025년 한 해 동안 웹 프론트엔드 현업에서 가장 많이 회자된 키워드는 단연 AI였습니다. 하지만 실무 깊숙한 곳을 들여다보면, 더 본질적인 변화는 ‘프론트엔드 개발자의 직무 범위 확장’에 있습니다. 최근 ‘State of JS 2025’ 설문조사와 채용 플랫폼 원티드의 데이터에 따르면, 프론트엔드 채용 공고의 약 40% 이상이 CI/CD, Docker, 그리고 AWS/Vercel과 같은 인프라 운영 능력을 우대 사항이 아닌 ‘필수 역량’으로 요구하기 시작했습니다. 이는 AI가 단순 코딩(Implementation) 영역을 빠르게 대체함에 따라, 인간 개발자에게는 전체 시스템을 조망하는 아키텍처 설계(Architecture Design) 능력이 요구되고 있음을 시사합니다.

이제 작은 단위의 컴포넌트 구현은 개발 지식이 부족한 기획자나 디자이너도 v0 같은 도구를 통해 수행할 수 있는 시대입니다. 그렇다면 2026년, 프론트엔드 개발자는 무엇을 무기로 삼아야 할까요? 필자는 그 해답이 ‘깊이 있는 기술적 전문성’과 ‘비즈니스 로직의 설계 능력’에 있다고 생각합니다.

이번 글에서는 1) 언어와 프레임워크, 2) 아키텍처와 인프라, 3) AI 도구라는 세 가지 핵심 축을 중심으로, 현업 개발자가 반드시 알아야 할 2026년의 기술 트렌드를 구체적으로 살펴보겠습니다.

<출처: Gemini 생성>

언어와 프레임워크: Server-First 패러다임

1) React 19와 서버 컴포넌트의 실무 적용 가속화

2025년 React 19의 정식 릴리즈는 프론트엔드 개발의 판도를 ‘클라이언트 중심’에서 ‘서버 중심(Server-First)’으로 완전히 이동시켰습니다. 핵심은 서버 컴포넌트(React Server Component, RSC)와 Actions입니다. 기존에는 데이터 패칭을 위해 useEffect를 무분별하게 사용하고 번들 사이즈 최적화에 골머리를 앓았다면, React 19 환경에서는 백엔드 로직을 컴포넌트 내부로 직접 가져올 수 있습니다. 실제 벤치마크 결과, RSC를 도입한 이커머스 프로젝트의 경우 TTI(Time to Interactive)가 평균 30% 이상 단축되었고, 클라이언트 번들 사이즈는 최대 45%까지 감소했습니다.

이제 실무에서는 TanStack Query와 같은 클라이언트 상태 관리 라이브러리의 역할이 축소되고, 대신 서버에서 미리 렌더링된 HTML을 스트리밍으로 받아오는 패턴이 표준이 되고 있습니다. Next.js, Remix뿐만 아니라 Expo(React Native)까지 이러한 패턴을 수용하면서, 2026년에는 “모든 컴포넌트는 기본적으로 서버 컴포넌트이며, 상호작용이 필요한 경우에만 클라이언트로 전환한다('use client')“는 원칙이 확고해질 것입니다.

25년 10월 공개된 React 19.2 <출처: 리액트 블로그>

2) Next.js 15, 16: 터보팩(Turbopack)과 생산성의 퀀텀 점프

Next.js 15는 Rust 기반 터보팩(Turbopack)을 도입해 빌드와 HMR 속도를 획기적으로 끌어올리며, 수천 개 페이지와 거대한 모노레포에서도 개발자 대기 시간을 체감하기 어려운 수준으로 줄였습니다. 기존 웹팩 대비 콜드 스타트 시간은 53% 단축했으며, HMR 반응 속도는 벤치마크 기준에 따라 10배까지도 차이가 나는 결과가 나타났습니다.

16에 이르면 이 성능이 사실상 기본값이 되어, “느린 빌드” 문제는 과거 이슈로 밀려나고, 파일 시스템 캐싱까지 더해져 콜드 스타트 구간 역시 눈에 띄게 짧아집니다. 캐싱은 14까지의 과도한 기본 캐싱을 벗어나, 15에서 유연한 SWR 제어가 가능해지고, 16에서는 “use cache” 기반 Cache Components와 revalidateTag · updateTag · refresh 같은 API로, 컴포넌트·도메인 단위 캐시 토폴로지를 명시적으로 설계하는 단계로 발전하게 됩니다.

서버 액션은 별도 API 라우트 없이 DB에 직접 접근할 수 있는 패턴을 현실화하고, 16의 전용 캐시 API와 결합되면서 “DB 트랜잭션 + 캐시 무효화 + UI 일관성”을 한 번에 책임지는 백엔드 진입점으로 자리 잡아, 2026년에는 Next.js 단일 코드베이스 안에서 프론트와 백엔드가 단일화된 풀스택 생산성 플랫폼으로 나아가고 이를 개발자들이 점점 더 많이 사용할 것으로 예상됩니다.

25년 10월 공개된 Next 16 <출처: Next 공식 홈페이지>

3) 타입스크립트와 런타임 안전성의 결합(Zod, Valibot)

2026년 타입스크립트 생태계의 핵심은 “컴파일 타임을 넘어 런타임까지”입니다. 대형 프로젝트의 TS 도입률이 80%를 상회하는 가운데, 이제는 단순히 타입을 정의하는 것을 넘어 Zod나 Valibot 같은 스키마 검증 라이브러리와 타입스크립트를 결합하는 추세가 뚜렷한데요. API 응답 값이 우리가 정의한 타입과 일치하는지 런타임에 검증하고, 이를 TS 타입으로 자동 추론(Inference)하는 방식입니다.

최근 업데이트된 타입스크립트의 satisfies 연산자와 5.x 버전의 성능 최적화는 이러한 패턴을 더욱 가속화했습니다. 또한 tRPC나 GraphQL(Codegen)을 활용해 백엔드 스키마 변경이 프론트엔드 빌드 에러로 즉시 감지되는 E2E 타입 안정성 환경 구축이 필수가 되었습니다. 이는 프론트엔드 개발자가 백엔드 로직의 변경 사항을 실시간으로 파악하게 하여, 커뮤니케이션 비용을 제로에 가깝게 줄여줍니다.

아키텍처와 인프라: 엣지(Edge)와 마이크로(Micro)의 조화

1) 엣지 컴퓨팅(Edge Computing)과 지능형 미들웨어

2026년의 웹 아키텍처에서 ‘엣지’는 선택이 아닌 필수입니다. Cloudflare Workers나 Vercel Edge Middleware를 활용하여 사용자의 요청이 오리진 서버에 도달하기 전에 처리하는 로직이 보편화되었습니다. 예를 들어, 사용자의 국가(GeoIP)를 식별하여 통화를 변환하거나, A/B 테스트 그룹을 분기 처리하는 로직을 엣지단에서 50ms 미만의 레이턴시로 처리합니다.

특히 주목할 것은 ISR(Incremental Static Regeneration)과 온디맨드 재검증의 결합입니다. 쇼핑몰 상품 정보처럼 변경이 잦은 데이터도 전체 빌드 없이 특정 페이지만 엣지 노드에서 갱신하는 전략을 통해, 정적 사이트(Static Site)의 속도와 동적 사이트의 최신성을 동시에 확보하는 것이 2026년 아키텍처의 표준입니다. 프론트엔드 개발자는 이제 HTTP 헤더를 자유자재로 다루며, CDN 전략을 직접 수립해야 합니다.

2) Rust 번들러 기반의 마이크로 프론트엔드 고도화

거대해진 모놀리식 프론트엔드 앱을 분리하려는 시도는 꾸준히 있었지만, 복잡한 설정과 성능 저하가 문제였습니다. 하지만 Rspack이나 Vite(Rolldown)와 같은 고성능 툴체인이 등장하며 상황이 반전되었습니다. 2026년에는 모듈 페더레이션 기술이 안정화되어, 서로 다른 저장소에 있는 컴포넌트를 런타임에 불러오는 비용이 획기적으로 낮아졌습니다.

국내 빅테크 기업들은 이미 결제, 장바구니, 리뷰 등 도메인별로 팀을 나누고, 각 팀이 독립적으로 배포할 수 있는 마이크로 프론트엔드 구조를 운영 중입니다. 이 구조하에서 프론트엔드 개발자는 ‘내 코드가 다른 팀의 서비스에 미칠 영향’을 고려해야 하며, 공통 디자인 시스템과 상태 공유 전략을 수립하는 고차원적인 아키텍처 설계 역량이 요구됩니다.

3) API 스펙의 동기화: BFF(Backend for Frontend)의 발전

프론트엔드와 백엔드의 “API 스펙 불일치”는 이제 시스템적으로 방지됩니다. 2026년에는 tRPC나 Hono 같은 RPC(Remote Procedure Call) 스타일의 프레임워크가 부상하며, 백엔드의 함수 하나가 곧 프론트엔드의 API 호출 함수가 되는 구조가 선호됩니다. 이는 아키텍처 관점에서 BFF(Backend for Frontend) 패턴이 코드 레벨로 녹아든 형태입니다.

백엔드 개발자가 DB 스키마를 수정하면 프론트엔드 코드에서 빨간 줄이 그어지는 강력한 결합도는, API 문서 관리의 고통을 없애고 비즈니스 로직 구현 속도를 2배 이상 향상시키는 결과를 가져왔습니다. 이제 “API 문서는 코드로 대체된다”라는 명제가 현업의 상식이 되었습니다.

AI 도구: 코딩 파트너에서 워크플로우 에이전트로

1) AI Native IDE: 컨텍스트를 이해하는 개발

VS Code에 Copilot 플러그인을 설치하던 시대를 지나, 이제는 Cursor나 Windsurf 같은 AI Native IDE가 대세입니다. 이들의 핵심 경쟁력은 ‘멀티 파일 컨텍스트’ 이해 능력입니다. 단순히 현재 파일만 보는 것이 아니라, “프로젝트 내의 모든 인증 관련 로직을 찾아서 NextAuth v5 스타일로 리팩토링해 줘”라는 명령을 내리면, 수십 개의 파일을 분석해 수정 제안을 던집니다.

실제 현업 개발자들은 이를 통해 레거시 코드 분석 시간을 60% 이상 단축하고 있습니다. 물론 아직까지 기존 레거시 컨텍스트를 완전하게 이해한다고 볼 수는 없습니다. 하지만 AI Agent의 컨텍스트 이해 능력이 올해 빠르게 성장했고, 내년에도 가파른 성장을 할 수 있을 것이라 예상합니다. 2026년의 코딩은 ‘작성(Writing)’이 아니라, ‘검토(Reviewing)’와 ‘조립(Composing)’의 과정이 될 텐데요. 개발자는 AI가 작성한 코드의 보안 취약점이나, 엣지 케이스를 검증하는 테크니컬 디렉터의 역할을 수행하게 됩니다.

2) 디자인-코드 통합의 자동화(Design-to-Code)

Figma Dev Mode와 v0의 발전은 퍼블리싱 업무의 80%를 자동화했습니다. 단순히 HTML/CSS를 그려주는 수준을 넘어, 이제는 “Shadcn UI 기반으로, Tailwind CSS를 사용하고, React Hook Form을 연결해 줘”라고 구체적인 기술 스택을 명시하면 상용 수준의 코드를 뱉어냅니다. 이는 프론트엔드 개발자가 CSS 픽셀을 맞추는 시간 대신, 복잡한 클라이언트 상태 관리나 성능 최적화에 집중하게 만듭니다. 현업에서는 디자이너가 만든 시안을 AI가 1차 코드로 변환하고, 개발자가 로직만 연결하여 배포하는 무손실(No-handoff) 워크플로우가 확산되고 있습니다.

3) AI Agent 기반의 품질 관리(Shift Left Testing)

AI는 이제 코드 작성 이후의 단계까지 책임집니다. CodeRabbit이나 GitHub Copilot Workspace 같은 AI 에이전트는 풀 리퀘스트가 생성되는 즉시 코드 리뷰를 수행하고, 누락된 유닛 테스트(Jest/Vitest)를 자동으로 작성하여 커밋합니다. 특히 보안 취약점이나 성능 병목 구간을 사전에 감지하는 능력이 탁월해, QA 단계에서 발견되던 버그를 개발 단계(Left)로 앞당겨 해결하는 Shift Left 트렌드를 주도하고 있습니다.

마치며: 도구에 매몰되지 말 것

2026년의 프론트엔드 생태계는 아마 이전보다 더 빠르게 새로운 도구들이 나올 가능성이 높습니다. React 19, Rust 기반 번들러, 엣지 컴퓨팅, 그리고 AI 에이전트까지, 이 모든 변화는 단 하나, 더 적은 코드와 시간을 들여 더 나은, 더 안정적인 사용자 가치를 창출하는 것을 목표로 합니다.

여기서 중요한 점은 모든 기술을 무조건 빠르게 받아들이는 ‘얼리어답터’가 되는 것이 결코 성공을 의미하지는 않는다는 겁니다. 레거시 시스템이나 조직의 현실을 무시한 성급한 도입은 결과적으로 혼란을 키우고, 기술 부채만 늘릴 수 있습니다. 오히려 진짜 경쟁력이란, 새롭게 등장하는 기술의 “진짜 배경과 원리”를 꿰뚫어 보고, 이 변화가 우리 조직에 어떤 솔루션이 될지, 적합한지를 명확히 설명하고 제대로 설계·도입할 수 있는 비판적 분석 역량에서 나옵니다.

2026년에는 코드를 직접 타이핑하는 시간이 줄고, ‘설계자(Architect)’와 ‘의사결정자(Decision Maker)’로서의 전문성이 프론트엔드 개발자에게 본격적으로 요구되는 시기가 될 것입니다. 어느 도구를 선택하느냐보다, 그 도구가 왜 필요한지, 그리고 도구의 한계와 미래 가능성까지 설계의 맥락에서 살펴봐야 하죠.

결국 어떤 기술의 변화 속에서도 살아남는 개발자는 항상 “문제를 정의하고, 본질을 이해하며, 새로운 도구와 패러다임을 주체적으로 해석하여 적용할 수 있는 힘”을 갖춘 사람들입니다. 이것이 곧, AI와 자동화의 시대에 프론트엔드 개발자가 가져야 할 진짜 경쟁력이며, 앞으로의 웹 생태계에서 자신만의 역할을 만들어가는 유일한 길이라 생각합니다.

]]>

“에이전트 중심 IDE” 안티그래비티(Antigravity) 체험기

요즘 AI 도입의 성패는 모델의 ‘지능’보다 프로세스를 얼마나 잘 설계하고 최적화했는가에 달려 있습니다. 그렇게 최근 등장한 Antigravity는 단순히 코드를 생성하는 수준을 넘어, 브라우저 테스트와 검증까지 자동화해 실제 개발 흐름 전체를 효율적으로 재구성합니다.

이 도구의 가치는 막연한 대화가 아니라 체계적으로 설계된 작업 흐름에서 나옵니다. 내장된 AI 에이전트가 수십 개의 파일을 넘나들며 코드를 작성하고, 애플리케이션을 직접 실행해 사용자처럼 브라우저 테스트를 진행합니다. 문제를 발견하면 스스로 수정하며, 그 과정은 스크린샷과 영상으로 남겨 투명하게 확인할 수 있습니다.

이 방식이 바로 구글에서 출시한 차세대 IDE, Antigravity의 작동 방식입니다.

Antigravity가 보여주는 ‘에이전트 중심 IDE’의 미래

2025년 11월 18일, 구글은 차세대 AI 모델 Gemini 3.0과 함께 새로운 IDE를 공개했습니다. 이름은 Google Antigravity입니다.

“VS Code 기반 AI IDE”로, AI 에이전트를 조율하고 검증하는 컨셉의 IDE라는 소개입니다. 앞서 등장한 AI 기반 IDE의 자동완성 레이어에서 한 단계 더 나아간 모습입니다. 자율 에이전트가 계획 → 구현 → 테스트 → 검증을 수행하고, 개발자는 그 과정을 관리하고 리뷰하는 구조를 전제로 설계된 플랫폼입니다.

왜 지금 ‘에이전트 중심 IDE’일까요?

구글이 굳이 새로운 IDE를 만든 이유는 단순합니다. 파운데이션 모델이 달라졌기 때문입니다. GPT-5, Claude Opus 4.5, Gemini 3.0 수준의 모델은 이제 코드 몇 줄 추천하는 것을 넘어 수십~수백 개 파일에 걸친 변경과 터미널 명령 실행, 브라우저 테스트까지 연속적으로 수행할 수 있습니다.

즉, 프롬프트 한 번으로 기능 하나가 끝날 때까지 손을 거의 대지 않고 작업이 돌아가는 그림에 현실성이 생긴 것입니다.

문제는 탭 자동완성 정도에 맞춰진 기존 IDE UI로는 장기적인 에이전트 태스크를 제어하고 검증하기 어렵다는 것입니다. 그래서 구글은 IDE라는 제품의 폼 팩터(Form Factor) 자체를 에이전트 중심으로 다시 설계해 선보인 것입니다.

두 개의 화면, 두 가지 작업 방식: Editor vs Manager

Antigravity는 기본적으로 두 가지 인터페이스, Editor View와 Manager View를 제공합니다. 각각은 서로 다른 역할을 맡아, 개발 흐름을 입체적으로 구성합니다.

Editor View: 익숙하지만 강력한 AI IDE

Editor View는 우리가 익숙하게 사용해 온 코드 에디터 화면입니다. 탭 자동완성, 인라인 명령, 사이드 패널 에이전트 기능을 갖춘 AI IDE 환경으로, 기본적인 사용성은 기존 에디터와 크게 다르지 않습니다. Cursor에서 제공하는 기능들을 거의 다 지원합니다.

Manager View: 에이전트를 지휘하는 관제탑

한편 Cmd + E를 누르면 열리는 Manager View는 Antigravity를 상징하는 인터페이스입니다. 이는 여러 워크스페이스에서 여러 에이전트를 병렬로 생성하고, 조정하며, 관찰할 수 있는 대시보드입니다.

이곳에서는 한 에이전트가 백그라운드에서 코드 베이스 리서치를 수행하는 동안, 다른 에이전트에게 버그 수정을 맡기고, 또 다른 에이전트는 백로그 작업을 처리하게 할 수 있습니다. 모든 작업은 Editor View와 실시간으로 동기화됩니다. 즉, 두 화면 사이를 즉각적으로 전환할 수 있습니다.

이처럼 비동기로 여러 작업을 관리하다가 특정 작업에 집중하고 싶을 때는 다시 Editor View로 전환해 세부 작업에 개입할 수 있습니다. 개발자는 코드 편집(Editor)과 에이전트 관제(Manager) 사이를 오가며, 어떤 에이전트가 어떤 계획을 세웠는지, 어느 단계까지 진행됐는지, 어떤 산출물을 남겼는지를 확인할 수 있습니다.

신뢰를 설계하는 아티팩트(Artifacts) 시스템

AI 에이전트가 자율적으로 많은 일을 수행할수록, 사람이 원하지 않은 방향으로 개발이 진행될 가능성도 함께 커집니다. 결국 계획을 다시 철저히 세우거나, 태스크를 더 잘게 나눠 AI에게 맡기는 방식으로 돌아가게 됩니다.

Antigravity는 이 문제를 아티팩트(Artifacts)라는 개념으로 해결합니다. 에이전트가 수행한 모든 작업의 흔적을 구조화된 형태로 기록해 두는 방식입니다.

이때 아티팩트는 단순한 로그나 결과물이 아닙니다. AI를 전력 승수(Force Multiplier)로 만들어주는 핵심 요소에 가깝습니다. 탄탄한 설계와 피드백이 아티팩트 형태로 명시적으로 정리되면, AI의 행동은 ‘추측’이 아니라 ‘설계한 방향성’을 기반으로 증폭되며 이루어질 것입니다.

에이전트가 남기는 아티팩트는 대략 다음과 같습니다.

1. 구현 계획(Implementation Plan)

AI가 코드 변경을 시작하기 전에 작성하는 기술 설계서입니다. 여기에는 “어떤 파일을, 어떤 이유로, 어떤 방식으로 바꾸겠다”는 것이 상세히 기술됩니다.

사용자는 이 단계에서 곧바로 인라인 코멘트를 남겨 방향을 조정할 수 있으며, 승인이 이뤄져야만 코드 수정이 시작됩니다. 잘 짜인 설계가 있어야 AI의 능력이 곱셈으로 작용해 폭발적인 생산성을 내기 때문입니다. 설계가 부실하면, 엉뚱한 방향으로 에너지가 증폭될 뿐입니다.

<출처: 작가>

구현 계획(Implementation Plan)에서 특히 유용한 점은 계획 안에 ‘검증 계획(Verification Plan)’이 항상 포함된다는 것입니다.

이는 단순히 코드를 구현하는 데서 끝나지 않고, “구현된 기능이 정상 작동함을 어떻게 증명할 것인가?”를 미리 정의하는 데 도움을 줍니다. 예를 들어 ‘단위 테스트 통과’, ‘특정 UI 요소 렌더링 확인’처럼 명확한 성공 조건을 설정할 수 있습니다.

<출처: 작가>

이처럼 검증 계획이 명시되면, 에이전트는 코드 수정 이후 이 계획에 따라 자동으로 테스트를 수행합니다. 사람이 일일이 기능을 확인하지 않아도, 에이전트가 스스로 코드를 작성하고 검증까지 마친 다음 “테스트를 통과했습니다”라고 보고하는 것입니다. 이 지점이 바로 에이전트 활용에서 중요한 부분입니다.

2. 플래닝 모드(Task Groups & Subtasks)

Antigravity에서는 큰 작업을 통째로 실행하는 대신, 에이전트 스스로 작업을 여러 Task Group과 Subtask로 쪼갭니다.

예를 들어 “대규모 리팩터링”이라는 작업은 “라우팅 구조 변경, 공통 컴포넌트 추출, 테스트 수정”과 같은 단계로 나뉘며, 단계마다 별도의 아티팩트와 diff가 남습니다. 각 코드의 변경 사항은 open diff 버튼을 클릭해 내용을 손쉽게 확인할 수 있습니다.

작업 이력 및 검증 보고서(Walkthrough)

작업 이력 및 검증 보고서(Walkthrough)는 작업이 끝난 다음 생성되는 문서로, 구체적인 변경 로직과 그에 따른 검증 결과가 모두 포함된, 일종의 ‘최종 완료 증명서’에 가깝습니다. 이 보고서는 크게 두 가지 가치를 제공합니다.

투명한 변경 내역 (Changes): 단순히 “버그를 수정했습니다”라고 요약하지 않고, 기술적 의사결정의 흐름과 단계별 실행 로직을 상세히 기록합니다. 덕분에 리뷰어는 코드를 직접 보기 전에, 에이전트가 어떤 의도로 작업을 진행했는지를 명확하게 파악할 수 있습니다.
확실한 검증 결과 (Verification Results): 에이전트는 코드 수정 이후 스스로 수행한 테스트 결과를 성적표처럼 제출합니다.

이 보고서로, 개발자가 에이전트에게 “정말 확실해?”라고 다시 물을 필요가 없어집니다. 논리적인 구현 과정과 테스트 통과의 증거가 한 페이지에 정리되어 있어, 이 문서만으로도 안심하고 코드를 병합(Merge)할 수 있습니다.

<출처: 작가>

스크린샷과 브라우저 녹화(Screenshots & Browser Recordings)

Antigravity는 크롬 확장과 연동돼, 에이전트가 실제 브라우저를 열고 조작과 확인, 동작을 수행합니다. 버튼 클릭과 텍스트 입력, 스크롤, 화면 캡처는 기본이며, DOM과 콘솔에도 직접 접근할 수 있습니다. 즉, 브라우저 레벨의 디버깅까지 에이전트가 스스로 수행할 수 있다는 의미입니다.

에이전트가 브라우저를 제어할 때는 파란색 테두리가 나타나며, 포커스하지 않은 탭에서도 자동 작업을 할 수 있습니다. 작업 과정은 자동으로 녹화되어 나중에 다시 검토할 수 있습니다. MCP(Model Context Protocol)로 Chrome DevTools 연결을 고민해 왔다면, 이제 그럴 필요가 없어진 셈입니다.

깊이 생각하거나, 바로 수행하거나: Planning vs Fast

Antigravity의 에이전트는 크게 두 가지 모드가 있습니다.

<출처: 작가>

Planning 모드

복잡한 구조 변경이나 대규모 리팩터링처럼, 한 번의 실수로 전체 시스템에 영향을 줄 수 있는 작업에 적합한 방식입니다. 이 모드에서는 작업을 Task Group과 Subtask로 세분화하고, 에이전트가 먼저 Implementation Plan을 제안합니다. 사용자가 이를 승인한 뒤에야 실제 코드 수정이 이루어집니다.

작업 과정에서는 Walkthrough나 브라우저 녹화와 같은 다양한 아티팩트가 생성돼, 전체 작업 흐름을 투명하게 추적할 수 있다는 장점이 있습니다. 다만 이러한 계획 수립과 사고 과정에는 어느 정도의 시간이 필요합니다.

Fast 모드

이 모드는 단순하고 빠르게 처리해야 하는 작업에 적합합니다. 계획 단계 없이 에이전트가 즉시 실행에 들어가기에, “버튼 색만 변경해 주세요”, “API 에러 핸들링만 추가해 주세요”와 같은 가벼운 작업에서 특히 효율적입니다. 물론 속도가 빠른 대신, 검증 과정이나 생성되는 아티팩트는 상대적으로 간단한 수준에 머무릅니다.

따라서 실제 팀 환경에서는 두 모드를 상황에 맞게 조합해 운영하는 방식이 자연스럽게 자리 잡을 가능성이 큽니다. 반복적이고 부담이 적은 작업은 Fast 모드로 빠르게 처리하고, 시스템 안정성에 영향을 줄 수 있는 중요한 작업은 Planning 모드와 리뷰 절차를 함께 적용해 안전성과 완성도를 높이는 방향이 효과적입니다.

프론트엔드 개발자에게 특히 흥미로운 점

프론트엔드 관점에서 Antigravity의 가장 큰 강점은, 브라우저를 직접 제어하는 네이티브 방식의 접근이라는 점입니다.

이 에이전트는 실제로 크롬 브라우저를 실행하고, 로컬에서 구동 중인 애플리케이션에 접속해, 폼을 입력하거나 버튼을 클릭하고, 스크롤을 움직이며, 탭을 전환하는 등 사용자가 수행하는 행동을 그대로 재연합니다. 이 과정에서 발생하는 콘솔 로그와 에러를 함께 확인하며, 전체 작업 흐름은 스크린샷과 영상 형태의 아티팩트로 남습니다.

이를 활용하는 다음과 같은 사용 방식이 자연스럽게 떠오릅니다.

“회원가입 플로우 전체를 브라우저에서 돌려 보고, 에러나 UX 이슈가 있으면 정리해 주세요.”
“이 컴포넌트의 hover 상태를 여러 가지 케이스로 캡처해 주세요.”
“모바일 브레이크포인트별로 레이아웃이 깨지는 부분을 찾아서 스크린샷으로 보여 주세요.”

아래 영상은 제가 TodoList 앱에 의도적으로 버그를 만들어 넣은 다음, Antigravity에게 그 버그를 재현하고 해결하도록 요청했을 때의 과정입니다.

<출처: 작가>

Antigravity는 크롬 브라우저를 직접 실행해 문제를 재현하고 원인을 분석한 다음, 수정이 필요한 소스 코드를 고쳤습니다. 그렇게 수정된 내용을 다시 브라우저에서 실행해 정상 작동하는 모습을 녹화했고, 그 전체 과정을 담은 Walkthrough 리포트를 아래처럼 제게 제출했습니다.

<출처: 작가>

이처럼 브라우저 테스트 자동화로, 이전보다 훨씬 효율적인 AI 기반 개발 프로세스를 구축할 수 있게 됐습니다. 이는 작업을 어떻게 구조화하고 설계하느냐가 실제 가치 창출의 핵심임을 보여주고 있습니다.

마치며: IDE가 아니라 “에이전트 운영체제”로 보기

AI 에이전트와 어떻게 협업해야 할까요?

탭 자동 완성(Tab Auto Complete) 기능 하나만 보고도 월 구독료를 내던 시대가 있었습니다. 그러나 이제는 에이전트가 브라우저를 열고, 코드를 테스트하며, 스스로 디버깅하는 시대가 오고 있습니다.

Antigravity가 그리는 미래에서 개발자는 더 이상 코드를 한 줄씩 작성하는 사람이 아닙니다. 여러 에이전트를 설계하고, 조율하고, 검증하는 오케스트레이터가 됩니다. 개발자는 이제 더 높은 수준의 의사결정에 집중할 수 있습니다. 코드 구현의 세부 사항보다는, 아키텍처 설계와 사용자 경험, 비즈니스 로직에 더 많은 시간을 쏟게 됩니다.

그런 의미에서 Antigravity는 ‘개발자가 설계자가 되는 미래’를 상당히 구체적인 제품의 형태로 보여주는 사례로 다가왔습니다.

이제 개발자로서 우리가 준비해야 할 것은 더 좋은 코드를 작성하는 능력만은 아닐지도 모릅니다. 더 좋은 지시를 내리고, 더 정확하게 검증하며, 더 효과적으로 피드백하는 능력. 그것이 에이전트 시대 개발자의 새로운 역량이 될 것입니다.

]]>

2026년 쿠버네티스 표준 아키텍처

표준 아키텍처 선정 배경

2026년 쿠버네티스는 컨테이너를 관리하는 부분에 있어서 경쟁자가 없는 프로젝트가 되었습니다. 그럼에도 2026년에는 매우 큰 변화가 있을 예정인데, 가장 대표적으로 OCI의 적극적인 도입과 Ingress NGINX의 지원 종료 예정이 있습니다.

*이와 관련한 자세한 내용은 헬름, 하버 그리고 인그레스를 참고하시기 바랍니다.

이와 같이 쿠버네티스는 단일 제품으로 존재하는 것이 아니라 쿠버네티스 상에서 동작하는 다양한 컨테이너 애플리케이션을 유기적으로 연결하여 다양한 목적으로 사용하게 됩니다. 따라서 이를 위한 성숙한 프로젝트들은 매우 중요한 요소입니다. 2025년 10월 28일을 기준으로 클라우드 네이티브 컴퓨팅 재단(CNCF, Cloud Native Computing Foundation)의 졸업 프로젝트는 총 34개가 발표되었습니다.

(2025년 10월 28일 기준) 시간대별 CNCF의 졸업 프로젝트 <출처: 작가>

졸업 프로젝트 외에 쿠버네티스를 각 목적에 맞게 사용하기 위해서는 많은 제품들을 이해하고 선택해야 합니다.

(2025년 12월 10일 기준) CNCF에서 제공하는 제품들 <출처: CNCF>

만약 관리형 쿠버네티스(EKS, AKS, GKE)를 사용한다고 해도, 위에 있는 제품들이 이미 사용하는 관리형 쿠버네티스에 내재화 되어 있는 경우가 있습니다. 혹은 내재화 되어 있지 않다고 해도 오픈 소스 형태를 관리형 쿠버네티스에 직접 적용하는 사례가 많이 있기 때문에 이를 이해하고 사용한다면 좀 더 관리형 쿠버네티스를 이해하는데 도움이 됩니다.

여기서 중요한 부분은 만약 이미 잘 쓰고 있는 구성 및 제품들이 있다면, 지금 구성된 제품들이 비즈니스에 맞는 최적의 구성이라는 것입니다. 또한 이와 같은 이유로 표준이라고 제목을 정하였으나, 사실상 현재 시장 상황에 맞는 제품 즉 트렌드에 가깝다는 것을 밝힙니다.

마지막으로 쿠버네티스를 안정적으로 그리고 편리하게 운영하고자 하는 목적을 달성하기 위해, 오픈 소스 외에도 다양한 제품들을 적극적으로 받아들였습니다.

위와 같은 이유로 다음의 선정한 제품들은 쿠버네티스를 시작하는 분들을 위한 가이드 또는 새로운 형태를 구성하고자 할 때 적극적으로 참고할 수 있는 내용이라고 이해해 주시면 좋겠습니다. 일부는 이미 디 팩토(de facto / 사실상 표준)인 경우도 있지만, 상황에 따라서는 한국 시장에 맞게 선정한 제품도 있습니다. 예를 들면, 헬름, 아르고CD, 하버, 프로메테우스 그리고 그라파나 등은 선택을 고민할 필요가 없을 수준이지만, 그 외에는 비즈니스 성격에 따라 다소 변경될 수도 있습니다.

2026년 쿠버네티스를 조합하는 방법 그리고 나아가야 하는 방법에 대해서 고민하신다면, 현재의 구성이 큰 도움이 될 것이라고 생각합니다.

2026년 쿠버네티스 표준 구성 (pdf 원본) <출처: 작가>

부디 이를 통해서 금년도 쿠버네티스로의 진입 또는 활성화가 더욱 더 수월하셨으면 합니다.

조 훈, 심근우, 문성주, 이성민 드림

KubeFlow 외에 인공지능 관련 프로젝트를 포함시키지 않은 이유

AI 워크로드에 대해서 DRA, vLLM, Ray, llm-d, Kueue, kagent 등이 매우 빠르게 발전하고 있어 하나의 방향성을 가지고 정리하긴 어려운 상태입니다.

다만 중요한 것은 오픈 소스 생태계에서 CNCF의 영향력이 매우 큰 상태이므로 AI 워크로드 특히 추론(inference) 영역에 대해서는 쿠버네티스 인프라가 가장 많이 사용될 가능성이 높습니다. 또한 학습(Training) 영역에서도 기존에 많이 사용되고 있던 slurm 의 영역을 일부 대체하는 경우도 있습니다.

이렇듯 현재 매우 변화가 심한 상태이므로 표준으로 정리하지 않았으나, 2026년 내에 LLM을 서빙하는 표준에 가깝게 vLLM이 사용될 가능성이 높습니다. vLLM은 고성능 LLM 추론 서빙을 위한 도구로, PagedAttention과 같은 최적화 기술을 통해 높은 처리량과 효율적인 메모리 사용을 제공합니다. 2026년 말에는 AI 워크로드 생태계가 더욱 성숙해져, 추론 및 학습 영역에서 표준화된 패턴이 명확해질 것으로 예상되며, 이를 2027년 표준 아키텍처에 반영할 계획입니다.

[삭제]

쿠버네티스 통합 개발 환경(IDE) 도구

렌즈(Lens)

깃허브 스타: 23k, 라이선스: 본문 참조

가장 널리 사용되는 쿠버네티스 관리를 위한 GUI 도구입니다. Lens를 통해 각종 쿠버네티스 리소스를 쉽게 관리할 수 있으며 헬름 차트 또한 Lens에서 관리할 수 있습니다. 여러 클러스터를 Lens에 등록하여 조회할 수 있어 편리합니다. 프로메테우스와 통합하여 간단한 모니터링도 수행할 수 있으며 파드에서 메뉴로 셸을 여는 기능(Attach)이나 포트포워딩을 하는 등의 편의 기능 또한 Lens 상에서 수행할 수 있어 매우 편리합니다. 다만, 그동안 Lens의 소스 코드를 이용한 오픈 소스 프로젝트인 OpenLens를 무료로 사용할 수 있었지만, 2024년 2월부터 Lens의 소스 코드 공개가 중단되어 OpenLens 프로젝트도 중단되었습니다. Lens는 기업의 경우 연간 매출 1000만 달러 미만인 경우에 한 해 무료로 사용할 수 있어 주의가 필요합니다. 이러한 라이선스 제약으로 인해 완전한 오픈 소스인 헤드램프(Headlamp)로 변경하였습니다.

예거(Jaeger)

깃허브 스타: 22.1k, 라이선스: Apache License 2.0

예거는 분산되어 있는 마이크로서비스에서 발생하는 이벤트를 수집하는 트레이스 도구입니다. 주로 분산 애플리케이션의 병목되는 부분을 찾거나 분산 애플리케이션 간에서 발생하는 에러를 탐색하기 위해서 사용됩니다. 애플리케이션의 문제를 추적하기 위해서는 별도의 SDK를 추가하여 탐색하고자하는 범위에 스팬을 추가하는 작업이 필요합니다. 트레이스 데이터의 생성 및 수집은 오픈텔레메트리 SDK와 수집기(Collector) 에서 표준화된 방식인 OTLP(OpenTelemetry Protocol, 오픈텔레메트리 프로토콜)로 이루어지기 때문에, 트레이스 데이터를 저장하는 백엔드 도구는 조직의 환경과 요구사항에 따라 자유롭게 선택할 수 있습니다. 따라서, 템포가 최신 대안으로 부상하고 있지만, 기존에 사용하던 트레이스 도구로 예거(Jaeger) 또는 집킨(Zipkin)이 있다면 해당 도구들 역시 OTLP를 수신할 수 있으므로 여전히 사용해도 무방합니다. 이는 OpenTelemetry가 계측을 표준화하여 어떤 백엔드를 사용하든 코드 변경이 필요 없도록 유연성을 제공하기 때문입니다. 하지만 기존 Jaeger는 데이터 검색을 위해 모든 스팬의 태그와 메타데이터를 인덱싱하는 방식에 의존했기 때문에, 데이터 볼륨이 커질수록 저장 공간 및 인덱스 유지 관리에 필요한 컴퓨팅 리소스 비용이 높아지는 단점이 있었습니다. 이러한 이유로 예거보다 트레이스 데이터를 인덱스를 최소화해 데이터 저장을 효율적으로 처리하는 템포로 변경하였습니다. 또한 그라파나와의 시각화 통합을 통해 메트릭, 로그, 트레이스를 긴밀하게 연계할 수 있다는 장점도 고려되었습니다.

키바나(Kibana): 로그 및 데이터 시각화 대시보드

깃허브 스타: 20.8k, 라이선스: AGPL 3.0/SSPL/Elastic License 2.0

키바나는 엘라스틱서치(또는 오픈서치) 데이터를 시각화하고 탐색하는 데 유용한 전용 대시보드 기능을 제공합니다. 로그 데이터의 경우에도 이미 그라파나의 데이터 소스 플러그인을 통해 엘라스틱서치 및 오픈서치에서 기본적으로 확인할 수 있습니다. 따라서 별도의 전용 시각화 스택인 키바나(또는 오픈서치 대시보드)를 유지하고 관리하는 복잡성을 피하고, 운영 단순화 및 통합된 모니터링 경험을 제공하기 위해 키바나 항목을 제외하고 그라파나 기반의 시각화로 통일합니다. 다만, 향후 매우 복잡하고 상세한 텍스트 기반 검색 및 분석이 필요하다면 키바나 또는 오픈서치 대시보드를 추가 구성하는 것을 고려할 수 있습니다.

엘라스틱서치(Elasticsearch): 로그 보관 및 검색엔진

깃허브 스타: 75.6k, 라이선스: AGPL 3.0/SSPL/Elastic License 2.0

엘라스틱서치는 아파치 루씬(Apache Lucene)을 기반으로 한 강력한 텍스트 검색 기능을 제공하여 로그 및 이벤트를 저장하고 추후 검색하는 데 매우 유용합니다. 엘라스틱서치를 로그 파이프라인에서 제외하고 다른 도구로 전환한 주된 이유로는 운영 복잡성 증가와 비용 효율성 때문입니다. 엘라스틱서치의 데이터를 시각화하고 탐색하기 위해서는 별도의 전용 대시보드 도구인 키바나를 필수적으로 함께 구성하고 관리해야 했습니다. 그러나 엘라스틱서치의 라이선스 변경 이후 등장한 대안인 오픈서치(OpenSearch)와 직접 연동되는 오픈서치 대시보드(OpenSearch Dashboards)를 통해 키바나의 엔터프라이즈 구독에 준하는 기능인 싱글사인온, 사용자 및 역할 기반 접근 제어 그리고 데이터 탐색을 오픈 소스 버전으로 사용 가능하다는 장점이 있습니다. 그리고 엘라스틱서치의 라이선스 변경으로 인해 오픈서치(OpenSearch)와의 커뮤니티 생태계 분리가 발생하여, 엘라스틱서치를 주력으로 선택할 때, 커뮤니티 생태계를 통한 문제 해결이 비교적 어려운 단점이 존재합니다. 이러한 운영 복잡성과 라이선스 문제를 해결하고 비용 효율성을 높이기 위해서 로그 저장 및 시각화는 오픈서치를 사용하도록 전환하였습니다. 만약 엔터프라이즈 기술 지원을 받을 수 있거나 기존 환경에서 이미 엘라스틱서치를 운영하고 있다면 엘라스틱서치를 사용해도 무방합니다.

각 구성 요소 설명

클러스터 접근 제어

텔레포트(Teleport)

깃허브 스타: 19.4k, 라이선스: GNU AGPL v3.0

텔레포트는 다양한 인프라(서버, 데이터베이스, 쿠버네티스 등) 환경에 안전하게 접근할 수 있도록 도와주는 도구입니다. 텔레포트와 같은 접근 제어 도구가 중요해지는 가장 큰 이유 중에 하나는, 쿠버네티스 리소스에 대해 잘못된 작업이 수행되는 경우, 최악의 상황에서는 서비스의 전체 이슈가 발생할 수 있기 때문입니다. 이를 위해 실제 작업자가 어떤 내용을 어떻게 진행할 수 있을지를 제어해야 하고 이와 함께 추후에 문제 파악을 위해 이를 기록해 두어야 합니다. 제한적으로 쿠버네티스의 RBAC을 이용하면 이를 구현할 수 있지만 개별적으로 이를 모두 관리하는 것은 쉬운 일이 아닙니다. 하지만 텔레포트와 같은 도구를 사용하면 지금까지 설명했던 모든 내용이 손쉽게 구현 가능하며, 또한 키클락과 연동하여 인증과 인가를 편리하게 연동할 수 있다는 장점도 있습니다. 텔레포트를 사용하는 경우 또 다른 장점은 작업자의 모든 내용이 기록되고 보관되어 향후에 감사 기록으로도 사용할 수 있고 문제를 부검하여 향후에 문제를 예방하는 것에도 도움을 줄 수 있습니다. 특히 조직의 규모가 커지고 복잡도가 높아지는 경우 이와 같은 도구의 필요성이 더더욱 증가할 수 있습니다.

클러스터 인증 및 인가

키클락(Keycloak)

깃허브 스타: 31.3k, 라이선스: Apache License 2.0

키클락은 IAM(Identity and Access Management, 신원 인증 및 인가 관리) 도구로 싱글사인온(Single Sign-On, SSO)을 허용하는 오픈 소스 도구입니다. 인터넷을 통해 접근 가능한 곳에 배포된 쿠버네티스 API나 애플리케이션은 누구나 접근할 수 있기 때문에 이런 경우에 키클락을 사용하면 구글 등 특정 IdP(Identity Provider, 신원 공급자)를 사용하여 인증 후에 접근 가능하도록 관리하는 것이 가능합니다. 또한 LDAP(Lightweight Directory Access Protocol) 등을 사용하여 각 사용자의 권한을 단계별로 설정하는 등 클러스터 전체의 접근 권한을 쉽게 관리할 수 있습니다.

API 서버 로드밸런서

HAPROXY

깃허브 스타: 6.1k, 라이선스: 링크 참조

쿠버네티스를 사용하기 이전부터 오픈 소스 로드밸런서로서 점유율이 높았으며, 컨트롤 플레인 노드들 위에 배포되어 있는 여러 쿠버네티스의 API 서버로 로드밸런싱하기 위해서 사용합니다. 헬스 체크를 지원함으로써 단일 장애점 문제를 해소하는데 도움이 되는 기능이 존재합니다.

네트워크 구현체

컨테이너 네트워크 인터페이스(CNI, Container Network Interface)

칼리코(Calico)

깃허브 스타: 6.9k, 라이선스: Apache License 2.0

CNI 중에 가장 쉽고 빠르게 적용할 수 있으며, 사용자 층 또한 두껍습니다. 특히 현재 데이터센터에서 가장 인기 있는 BGP 프로토콜을 잘 지원하고 있으며, 성능 또한 상단에 위치하고 있습니다. 최근에는 또다른 CNI인 실리움을 통해 eBPF 및 XDP를 적용하여 네트워크 트래픽의 가시성을 확보하면서, 네트워크 라우팅 성능을 개선할 수 있습니다. 하지만 추가된 기능으로 인해 네트워크 구조를 추적하기 어렵고, 동시에 현재 검증된 호스트 OS의 커널 버전 변경이 필요합니다. 따라서 시스템 변경이 어렵거나, 기존에 검증된 구성을 선호하는 경우 칼리코를 선택하는 것이 좋습니다. 물론 칼리코 또한 eBPF 및 XDP는 지원합니다.

실리움(Cilium)

깃허브 스타: 22.9k, 라이선스: Apache License 2.0

CNI 종류 중 하나로 설치하기 단순하지만 특정 기능을 사용하기 위해서 필요한 옵션을 구성하기에 어려움이 있습니다. 하지만 eBPF 및 XDP 와 같은 최신 커널에서 제공하는 기능을 통해서 kube-proxy(iptables, ipvs)를 대체 함으로써, 쿠버네티스 클러스터 간 네트워크 전달 성능을 향상시킬 수 있고, 네트워크 트래픽을 관측할 수 있다는 장점이 존재합니다. 앞서 소개한 칼리코에서도 최근 eBPF 및 XDP를 이용한 네트워크 전달 성능을 개선하였습니다. 이 밖에도 실리움이 자체로 제공하는 L2 로드밸런서와 서로 다른 쿠버네티스 클러스터 간 서비스 메시를 지원하기 때문에 위 기능에 따른 수요가 있다면 실리움을 적용할 수 있습니다.

L4/L7 네트워크 구현체

MetalLB: 쿠버네티스 로드밸런서

깃허브 스타: 7.9k, 라이선스: Apache License 2.0

쿠버네티스에서 로드밸런서 서비스를 사용할 수 있도록 지원해 주는 제품입니다. 가장 오래되고 성숙된 제품 중에 하나이며 L2, L3(BGP)모드를 모두 지원합니다. v0.13.2부터는 CRD형태로 IP 풀(Pool), 모드 등을 간편하게 설정할 수 있도록 변경되었습니다.

[주의] Nginx Ingress Controller: 쿠버네티스 인그레스

깃허브 스타: 19.2k, 라이선스: Apache License 2.0

인그레스는 클러스터 외부에서 HTTP 및 HTTPS 를 통해 내부로 접속하는 URL 경로를 노출하는 오브젝트입니다. 인그레스를 관리하는 인그레스 컨트롤러는 다양한 구현체가 있으며, 그 중 Nginx를 기반으로 한 인그레스 컨트롤러가 가장 널리 쓰이고 있습니다. 다만 2025년 11월 공식 지원 종료가 발표되어 2026년 3월 이후에는 보안 업데이트와 버그 수정이 중단됩니다. 인그레스에 좀 더 다양한 기능을 추가하고, 사용하는 오브젝트의 관계를 좀 더 구조적으로 구성한 Gateway API가 2023년 10월에 GA 되었으며, Nginx Ingress Controller의 후속으로 권장되고 있습니다. 그러므로 프로덕션 환경에서는 Gateway API나 다른 인그레스 컨트롤러로의 마이그레이션을 준비해야 합니다. 현재 Gateway API는 Nginx Fabric, Envoy, Istio, Cilium, kgateway, Kong, Traefik 등이 주요 후보로 올라와 있으며, 특정 Gateway API를 정할 수 없을 만큼 현재 매우 경쟁적인 상황입니다. 따라서 이는 2027년에 반영하도록 하겠습니다.

k8gb: 쿠버네티스 글로벌 로드밸런서

깃허브 스타: 1.1k, 라이선스: Apache License 2.0

쿠버네티스 글로벌 로드밸런서는 GSLB(Global Server Load Balancing)를 참고하여 제작되었으며, 어느 쿠버네티스 지역에 있더라도 가능한 유사한 네트워크 트래픽을 받도록 구현하는 것을 목표로 하고 있습니다. 따라서 CSP(Cloud Service Provider, AWS/Azure/GCP)로 구성한 멀티 클러스터 환경에서 하이브리드 클라우드를 위한 글로벌 네트워크 구성을 도와주는 제품 입니다.

사용성 간편화 도구

헬름(Helm): 배포 간편화 도구

깃허브 스타: 29.1k, 라이선스: Apache License 2.0

쿠버네티스 패키지 매니저로서 차트(Chart)를 통해 쿠버네티스 클러스터에 컨테이너 애플리케이션을 손쉽게 배포할 수 있도록 도와주는 도구입니다. values에 정의한 다양한 파라미터를 통해 원하는 옵션으로 애플리케이션을 커스터마이징할 수 있다는 장점도 있습니다. 특히 2025년 11월 Helm 버전 4가 발표되면서, 서버사이드 반영(Server-Side Apply) 기반의 배포와 향상된 리소스 감시 기능이 도입되어 리소스 관리의 안정성과 운영 편의성이 크게 강화되었습니다. 또한 기존의 helm repo add로 저장소를 추가해야 차트를 사용할 수 있던 방식에서 벗어나, OCI 기반 차트 배포 방식을 완전하게 지원함으로써 필요한 차트를 OCI 레지스트리에서 직접 가져올 수 있게 되었습니다. 이로써 별도의 저장소 등록 없이도 차트를 즉시 활용할 수 있어 사용성이 크게 향상되었습니다. 다만 OCI 기반 차트 저장 방식은 자체적으로 메타데이터를 제공하지 않는 구조이므로, helm search 명령어를 통한 OCI 차트 검색은 ArtifactHub에서 가능하며 이외의 경우는 컨테이너 레지스트가 제공하는 자체 검색 기능을 이용해야 합니다.

[변경] 헤드램프(Headlamp): 쿠버네티스 웹 UI 도구

깃허브 스타: 5k, 라이선스: Apache License 2.0

헤드램프는 Kubernetes SIG-UI에 공식적으로 포함된 사용하기 쉽고 확장 가능한 쿠버네티스 웹 UI입니다. 2025년에 Kubernetes SIG-UI의 공식 프로젝트가 되면서 쿠버네티스 커뮤니티와 더욱 긴밀하게 통합되었습니다. 헤드램프를 통해 각종 쿠버네티스 리소스를 쉽게 관리할 수 있으며, 플러그인 시스템을 통해 기능을 확장할 수 있습니다. 또한 여러 클러스터를 등록하여 조회할 수 있어 편리하며, 2025년에는 AI 어시스턴트 기능이 추가되어 자연어 인터페이스를 통한 클러스터 관리가 가능해졌습니다. 데스크톱 애플리케이션과 클러스터 내 배포 모두를 지원하며, Minikube, Karpenter 등 다양한 플러그인 생태계를 갖추고 있습니다. 완전한 오픈 소스로 Apache 2.0 라이선스 하에 무료로 사용할 수 있습니다.

서비스 메시

이스티오(Istio)

깃허브 스타: 37.7k, 라이선스: Apache License 2.0

이스티오는 서비스 메시 도구로서 트래픽 관리, 옵저빌리티와 같은 기능을 제공합니다. istioctl을 통해 간편하게 설치할 수 있으며, CRD를 통해서도 설치가 가능하다는 장점이 있습니다. VirtualService와 Gateway를 통해 인그레스 트래픽을 처리할 수 있으며, 중간에 filter를 활용해서 트래픽 제어가 가능합니다. 또한 ServiceEntry를 통해 클러스터 내/외부의 엔드포인트를 손쉽게 동적으로 관리할 수 있습니다. 이와 같은 이스티오의 주요 기능 외에 Kiali라는 대시보드를 통해 서비스 트래픽 흐름을 웹 UI로 확인할 수 있고 엔보이(Envoy) 프록시를 사용하여 서비스 메시 구성도 가능합니다. 만약 엔보이 사이드카 패턴을 통해 사용되는 CPU나 메모리의 리소스가 부담된다면 2024년도에 GA된 이스티오 엠비언트 메시(Ambient Mesh) 를 사용해 사이드카 패턴으로 파드에 붙는 구조가 아닌 노드에 ztunnel(제로 트러스트 터널)이라는 데몬을 통해서 CPU와 메모리를 절감하면서 서비스 메시를 구성하는 것 또한 가능합니다.

컨테이너 관리 도구

도커(Docker)

깃허브 스타: 71.2k, 라이선스: Apache License 2.0

오랫동안 사용된 컨테이너 관리 도구의 대명사이며 현재도 가장 많은 사용자들이 이용하고 있습니다. 쿠버네티스가 도커심(Dockershim)과 연계를 중단하였지만, 컨테이너 빌드를 위한 도구로는 계속 사용 가능합니다. 기존에 루트 권한에 관한 문제나 데몬을 통해 동작하는 구조에 따른 불편함이 있어서 도커와 관련된 호환성을 유지하면서도 루트 권한 사용 및 데몬이 없는 Redhat의 Podman이 대체자로 거론되기도 했습니다. 그러나 도커 버전 v23.0부터 빌드킷(buildkit)이 기본으로 채택되면서 빌드 속도와 캐시 사용 효율이 크게 향상 되는 등 많은 개선이 있어 현재까지도 컨테이너 빌드 도구의 표준 자리를 지키고 있습니다.

지속적 통합/배포(CI/CD) 도구

CI/CD

Github Actions

깃허브 스타: 5.7k, 라이선스: MIT

Github Actions는 세계에서 가장 유명한 소스 코드 저장소인 Github에서 제공하는 CI/CD 도구입니다. Github 저장소에 보관된 소스를 바로 빌드/배포 할 수 있는 workflow들을 구성할 수 있어 활용도가 높습니다. Github 자체에서 제공하는 workflow 템플릿 뿐만 아니라 수 많은 오픈 소스 템플릿들을 활용하여 파이프라인을 쉽고 간결하게 구성할 수 있다는 장점이 있습니다. Github에서 제공하는 runner를 사용할 경우 공개 저장소는 무료로 사용 가능하고, 비공개 저장소의 경우에는 월 2,000분까지 무료로 사용가능합니다.

젠킨스(Jenkins)

깃허브 스타: 24.7k, 라이선스: MIT

젠킨스는 지속적 통합 및 배포 단계에서 가장 널리 쓰이는 오픈 소스입니다. 방대한 커뮤니티에서 제공하는 다양한 플러그인으로 인해 거의 모든 언어 및 도구와 연계할 수 있습니다. 젠킨스 설치를 위한 차트 및 젠킨스에서 사용할 수 있는 쿠버네티스 플러그인도 제공하고 있어 쿠버네티스 상에서 쉽게 사용할 수 있습니다. 젠킨스 파이프라인을 사용하면 해당 CI/CD에 사용되는 스크립트를 Jenkinsfile이라는 코드의 형태로 프로젝트의 저장소에 넣고 관리가 가능해 일련의 빌드 및 배포과정을 모두 코드 배포의 일환으로 쉽게 관리할 수 있습니다.

깃랩(Gitlab)

깃허브 스타: 24.2k, 라이선스: MIT Expat

Gitlab CI/CD는 오픈 소스 및 SaaS 소스코드 저장소인 Gitlab에서 사용할 수 있는 CI/CD 기능입니다. 무료 사용이 제한적인 Github Actions와 달리 무료로 사용할 수 있는 설치형 오픈 소스 버전에서도 CI/CD 기능을 사용할 수 있습니다. 개별 workflow가 중심으로 구성되는 Github Actions와 달리 Gitlab CI/CD는 Pipeline을 통해 다수의 Job들을 하나로 묶어 CI/CD를 구성할 수 있으며, Auto DevOps 기능으로 빌드, 테스트, 배포, 보안점검 기능 등을 한꺼번에 수행할 수 있습니다. 또한 Auto Monitoring 기능을 쓰면 배포된 애플리케이션의 모니터링까지 수행할 수 있어 CI/CD를 넘어서 DevOps 도구로서의 기능까지 충실하게 수행할 수 있습니다.

CD

아르고 CD(Argo CD)

깃허브 스타: 21.3k, 라이선스: Apache License 2.0

ArgoCD는 Git을 배포의 원천으로 사용하는 GitOps CD 도구입니다. Git에 작성된 매니페스트 기반으로 쿠버네티스의 리소스 상태를 일치시키는 형태로 선언적인 리소스 관리가 가능합니다. 또한, 애플리케이션 자체의 소스코드와(CI) 배포에 해당되는 소스코드를(CD) 별개로 관리하는 것이 일반적인 GitOps의 특성 덕분에, 배포 시 리소스나 런타임 설정만 변경할 경우 애플리케이션의 빌드 없이 빠르게 배포 및 롤백이 가능하다는 장점이 있습니다. 이 외에 Argo Rollouts이나 Argo CD Notifications등을 추가로 적용해 다양한 배포 전략을 사용하거나 배포 관련 알림을 설정 하는 등 좋은 확장성을 가지고 있습니다.

컨테이너 레지스트리

하버(Harbor)

깃허브 스타: 27k, 라이선스: Apache License 2.0

시장에서 가장 널리 사용되는 컨테이너 레지스트리로, Private Docker Registry뿐만 아니라 주요 클라우드 제공자의 레지스트리와도 손쉽게 동기화할 수 있습니다. 또한 차트 저장소 기능도 지원하여 컨테이너 이미지와 패키지형 애플리케이션 리소스를 하버 하나로 통합 관리할 수 있습니다. 하버 2.8 이전까지는 ChartMuseum 기반의 차트 저장소를 제공했으나, 2.8 버전부터는 ChartMuseum 지원을 공식 종료하고 OCI 표준 기반의 차트 관리 체계를 전면 도입하였습니다. 이를 통해 차트 저장소 메타데이터 관리 부담이 크게 감소하고, 저장,조회 그리고 동기화 과정에서의 전반적인 성능이 향상되었습니다. 추가 번들(플러그인)로 컨테이너 이미지의 취약점을 찾는 스캐너인 트리비(Trivy), 컨테이너 이미지 무결성을 보증하기 위한 서명을 위한 도구인 노터리(Notary)를 적용하면 컨테이너 이미지 취약점 검사와 서명 검증 기능을 통해 보안을 강화할 수 있으며, 이는 OCI 표준 기반의 차트에도 동일하게 사용할 수 있어 차트 보안 또한 크게 강화되었습니다. 이 모든 기능은 하버 API를 통해 자동화할 수 있다는 점에서 DevSecOps 파이프라인 구축에도 유리합니다. 이와 같은 이유로 하버를 컨테이너 레지스트리에 포함시켰습니다.

컨테이너 네이티브 스토리지

Rook: 컨테이너 네이티브 스토리지 오케스트레이션 + Ceph: 오브젝트 스토리지

Rook 깃허브 스타: 13.2k, 라이선스: Apache License 2.0
Ceph 깃허브 스타: 15.8k, 라이선스: LGPL version 2.1 or 3.0

Rook은 쿠버네티스 상에서 스토리지를 쓸 수 있도록 도와주는 컨테이너 네이티브 스토리지 오케스트레이션 솔루션입니다. 유사한 도구로 Longhorn이 있습니다. 두 도구는 기본적인 기능과 구조가 굉장히 유사하지만 Rook은 업계에서 가장 널리 사용되는 오픈 소스 분산 스토리지 솔루션 Ceph와 함께 사용할 수 있어, 익숙함의 이점을 누릴 수 있습니다. 또한 블록스토리지만을 제공하는 Longhorn과 달리 Ceph를 사용하면 블록스토리지 뿐만 아니라 오브젝트 스토리지도 동시에 사용할 수 있습니다.

벨레로(Velero): 클러스터 데이터 관리 도구

깃허브 스타: 9.6k, 라이선스: Apache License 2.0

쿠버네티스 클러스터의 리소스와 관련된 데이터와 볼륨을 관리할 수 있는 도구입니다. Velero를 통해 클러스터 상태 데이터 및 볼륨 스냅샷을 남길 수 있으며, 이를 오브젝트 스토리지와 연계하여 백업 및 복원할 수 있습니다. 이 기능을 통해서 클러스터의 장애 복구, 클러스터 환경의 마이그레이션(Migration) 시 유용하게 사용할 수 있습니다.

MLOps

Kubeflow

깃허브 스타: 15.3k, 라이선스: Apache License 2.0

데이터 사이언티스트 및 엔지니어의 협업을 쿠버네티스 클러스터 위에 배포된 주피터 노트북에서 작업을 공유할 수 있으며, 머신러닝 모델의 학습 시 필요한 하이퍼파라미터 튜닝을 할 수 있습니다. 또한 이렇게 만들어진 모델로 파이프라인을 구성할 수 있으며, 모델을 학습하기 위한 쿠버네티스 잡을 웹 UI에서 다룰 수 있습니다.

서버리스(Serverless)

Knative

깃허브 스타: 5.9k, 라이선스: Apache License 2.0

서버리스는 고정으로 배포된 서비스를 이용하지 않고, 요청이 있을 때마다 코드를 구동하고 중단하는 개념입니다. 쿠버네티스를 활용하여 이런 유연한 방식에 대한 활용성을 극대화할 수 있습니다. Knative는 구글이 지원하고 있으며 레드햇, IBM 등이 채택하고 있어 인지도 및 활용도가 높습니다.

키 관리 서비스

볼트(Vault)

깃허브 스타: 33.5k, 라이선스: BSL 1.1

Hashicorp에서 만든 민감 정보 저장 및 관리 서비스입니다. 민감 정보의 관리를 통합하지 않으면 권한에 대한 관리가 어렵습니다. 또한 데이터베이스 암호와 같은 정보를 평문으로 저장하거나 사람들이 직접 입력 할 경우 공격에 의해 유출될 가능성이 높습니다. 특히 시크릿을 YAML 파일로 관리할 때 별도의 암호화를 거치지 않아 불안한 경우가 있습니다. 이때 쿠버네티스와 볼트(Vault)를 함께 사용하면, 볼트에 민감 정보를 저장한 후 해당 권한을 가진 파드만 접근할 수 있도록 구성할 수도 있습니다. 이렇게 각종 민감정보를 안전하게 보관하고 체계적으로 관리할 수 있습니다. 2023년 8월 Hashicorp 제품군의 라이선스가 BSL로 변경되어 더 이상 오픈 소스 소프트웨어라고 부르기 어려울 수도 있지만, 일반 사용자의 이용에는 차이가 없어 여전히 포함하였습니다.

컨테이너 런타임 관리

컨테이너디(ContainerD)

깃허브 스타: 19.9k, 라이선스: Apache License 2.0

쿠버네티스 버전 v1.24부터 도커에 내장된 도커심(Dockershim)과 연계가 제거되었으므로 컨테이너디(ContainerD)와 같은 컨테이너 런타임 도구를 사용해야 합니다. 컨테이너디 이외에 CRI-O도 있으나, 이는 구성이 다소 복잡하고 레퍼런스가 많지 않아 컨테이너디(ContainerD)로 구성하도록 선택 하였습니다. 현재 다양한 관리형 쿠버네티스 및 설치형 쿠버네티스에서 컨테이너디를 기본적인 컨테이너 런타임으로 구성하여 사용하고 있습니다.

가상화 도구

쿠버벌트(KubeVirt)

깃허브 스타: 6.5k, 라이선스: Apache License 2.0

VMware가 브로드컴(Broadcom)으로 인수된 이후에 가상화 관련 라이선스 정책에 많은 변동이 있었습니다. 이에 따라 가상화 도구를 변경하고자 하는 많은 요구 사항들이 있습니다. 쿠버벌트는 이러한 대안 중에 하나로 사실상 가상화를 그대로 대체하는 것이 아니라 정확히 말하자면 쿠버네티스 위에서 가상화를 다시 구현하는 기술입니다. 따라서 기존에 가상화에 비해서 더 많은 복잡도와 VMware에 비해서 많은 부분이 지원되지 않거나 알아야 할 부분이 많이 있습니다. 그럼에도 불구하고 가상화 이후에 컨테이너로 넘어가고자 하는 조직인 경우에서 실험적으로 도입을 고려해 볼 수 있으며, 또한 쿠버네티스를 이미 충분히 숙련되고 운영하고 있는 조직은 오히려 안정적인 쿠버네티스 환경 위에서 손쉽게 가상화를 이용할 수 있습니다.

컨테이너 런타임 보안

팔코(Falco)

깃허브 스타: 8.4k, 라이선스: Apache License 2.0

팔코는 2024년 3월에 졸업한 프로젝트입니다. 2024년과 2025년에 이어 2026년에도 벌어질 많은 보안 사건 사고로 이에 요구사항이 점점 더 증가될 것으로 예상됩니다. 따라서 사용의 용이성보다는 안정성과 더 많은 기능에 집중하여 팔코로 컨테이너 런타임 보안 도구를 변경하였습니다. 컨테이너 런타임 보안을 위해 실시간으로 동작을 검증할 수 있으며, 실시간으로 검증하기 위한 동작을 운영자가 직접 규칙을 만들어 적용할 수 있습니다. 이렇게 생성한 규칙에 따라 경고를 만들고 이를 다양한 형태로 전달하여 문제 상황을 빠르게 파악하고 조치할 수 있습니다.

[추가] 데이터 파이프라인

스트림지(Strimzi)

깃허브 스타: 5.6k, 라이선스: Apache License 2.0

스트림지는 쿠버네티스에서 아파치 카프카(Apache Kafka)를 운영하기 위한 오퍼레이터입니다. 카프카 클러스터를 쿠버네티스 네이티브한 방식으로 배포하고 관리할 수 있도록 도와줍니다. 쿠버네티스의 커스텀 리소스 정의(CRD)를 사용하여 카프카 클러스터, 토픽, 사용자 등을 선언적으로 관리할 수 있으며, 자동화된 롤링 업데이트와 스케일링을 지원합니다. 또한 카프카 커넥트(Kafka Connect), 카프카 미러메이커(MirrorMaker) 등 카프카 에코시스템의 다양한 컴포넌트들도 함께 관리할 수 있어 실시간 데이터 스트리밍 파이프라인을 쿠버네티스 위에서 효과적으로 구축할 수 있습니다. 이 데이터 파이프라인은 AI 모델 학습 및 추론 서비스에 필요한 데이터를 저지연성을 가지고 안정적으로 공급하는 핵심적인 역할을 합니다. 그리고, HTTP 통신 방식 대신 카프카를 통해 이벤트 기반으로 데이터를 전송함으로써 마이크로서비스의 규모를 유연하게 조정할 수 있고, 장애 시 데이터 재처리와 관련된 기능을 간편하게 구현할 수 있습니다. 재처리 기능을 활용함으로써 데이터 정합성을 보장하며 모델 실험에 필요한 현상을 재현하는데 있어서 큰 도움을 받을 수 있습니다. 따라서, 대규모 트래픽을 안정적으로 처리하면서 동시에 비용 효율적으로 데이터를 수집하고 전달할 수 있습니다.

클릭하우스(ClickHouse)

깃허브 스타: 44.3k, 라이선스: Apache License 2.0

클릭하우스는 실시간 분석을 위한 고성능 컬럼 기반(Columnar) 데이터베이스 관리 시스템입니다. 대규모 데이터셋에 대한 빠른 조회 성능을 제공하며, 특히 로그 분석, 메트릭 저장, 비즈니스 인텔리전스(BI) 워크로드에 최적화되어 있습니다. 클릭하우스는 페타바이트급 데이터를 처리할 수 있으며, SQL을 지원하여 기존 분석 도구들과의 호환성이 뛰어납니다. 전통적인 데이터 웨어하우스가 대규모 데이터를 배치 형태로 처리하는 데 최적화되어 있다면, 클릭하우스는 수 초 이내의 낮은 지연 시간으로 분석 결과를 제공하여 비즈니스 및 운영 영역, 그리고 이러한 속도를 기반으로 AI 모델에 필요한 고수준 집계 데이터를 제공할 수 있습니다. 이를 통해 빅데이터 기반의 빠른 의사결정을 내리는데 핵심적인 역할을 수행합니다. 쿠버네티스 환경에서는 클릭하우스 오퍼레이터를 통해 클러스터를 손쉽게 배포하고 관리할 수 있습니다. 그리고 프로메테우스, 그라파나 등 관측가능성 스택과 연동하여 장기 메트릭 저장소로 활용하거나, 카프카와 연계하여 실시간 데이터 분석 파이프라인을 구축할 수도 있습니다. 그렇게 데이터의 가치를 극대화시켜 AI 모델이 동작하는데 필요한 원천 데이터의 생성 영역을 더 빠른 주기로 생성하며, 모델 개발의 속도를 증대시킬 수 있습니다. 그리고, 이러한 모델 및 마이크로서비스들의 새로운 기능들이 정상적으로 동작하는지 메트릭 기반으로 이상 징후를 탐지하는 영역으로 확장시켜 사용할 수 있습니다.

관측가능성 (Observability)

로그, 분산 트레이싱, 메트릭 변환기

오픈텔레메트리(OpenTelemetry)

깃허브 스타: 6.4k, 라이선스: Apache License 2.0

특정 관측가능성 솔루션에 종속되지 않고 로그, 트레이스, 메트릭, 프로파일과 같은 모니터링 데이터를 표준화된 프로토콜(OTLP, OpenTelemetry Protocol)을 통해 수집,처리,전달할 수 있도록 도와주는 프레임워크 입니다. 최근 관측가능성 분야는 각 솔루션별로 독자적인 에이전트를 설치해 데이터를 수집하던 기존 방식에서 벗어나, 오픈텔레메트리 기반의 표준 프로토콜을 중심으로 데이터 파이프라인을 통합하고, 각 솔루션은 사용성·기능성·시각화 경험을 강화하는 방향으로 발전하고 있습니다. 오픈텔레메트리가 제공하는 SDK(Software Development Kit)를 애플리케이션 또는 쿠버네티스에 적용하면 모니터링 데이터를 통합하여 전달할 수 있으며, 이를 기반으로 오픈텔레메트리와 호환되는 다양한 관측가능성 솔루션(프로메테우스, 템포, 파이로스코프 등)을 자연스럽게 연동할 수 있습니다.

메트릭 파이프라인

프로메테우스(Prometheus): 메트릭 수집 및 조회

깃허브 스타: 61.5k, 라이선스: Apache License 2.0

쿠버네티스 모니터링에 있어서 높은 점유율을 보여주고 있으며, CNCF의 2번째 졸업(Graduated) 프로젝트입니다. 여러 CNCF 및 오픈 소스 프로젝트들이 메트릭을 프로메테우스(Prometheus) 형식에 맞게 공개하고 이를 프로메테우스가 수집하고 있습니다. 프로메테우스 3.0부터는 향상된 원격 읽기/쓰기를 지원하며, 오픈텔레메트리 형식으로 파생되는 메트릭도 프로메테우스에 바로 적재할 수 있습니다. 이렇게 프로메테우스 수집 저장된 메트릭 데이터는 그라파나(Grafana)와 내장되어 있는 브라우저를 통해서 확인할 수 있습니다.

로그 파이프라인

Fluentbit: 로그 포워더

깃허브 스타: 7.5k, 라이선스: Apache License 2.0

Fluentbit은 오픈 소스 로그 포워더입니다. 적은 자원 소비로도 높은 성능을 안정적으로 낼 수 있다는 것을 주된 장점으로 내세우고 있습니다. 쿠버네티스의 로그를 로그 수집 서비스에 전송하기 위하여 Fluentbit INPUT 플러그인을 통해 로그 내용을 입력하여 다른 서비스로 전송하는데 쓸 수 있습니다. 최근에는 대량 로그 데이터를 전송할 때 데이터독에서 만든 벡터(Vector)를 사용할 수 있습니다. 벡터는 메트릭, 이벤트, 로그 등을 비롯해서 모니터링 데이터를 엘라스틱서치(Elasticsearch)로 전송할 때 CPU 성능에 맞게 메트릭이나 여러 데이터를 송신 처리량을 조절하는 ARC(Adaptive Request Concurrency) 기능을 제공하지만 Fluentbit 처럼 아직은 사용자 층이 두껍지 않아 선정하지 않았습니다.

[변경] 오픈서치(OpenSearch): 로그 보관 및 검색엔진

깃허브스타: 12k, 라이선스: Apache License 2.0

오픈서치(OpenSearch)는 가장 널리 쓰이는 검색엔진 도구인 엘라스틱서치에서 파생된 오픈 소스 프로젝트입니다. 엘라스틱서치와 유사한 검색 및 로그 관리 기능을 제공하며, 비정형 데이터를 저장할 수 있고, 아파치 루씬(Apache Lucene)을 기반으로 한 강력한 텍스트 검색 기능을 제공하기 때문에 로그 및 이벤트를 저장하고 추후 검색하는 데 매우 유용합니다. 오픈서치의 가장 큰 강점은 순수한 Apache License 2.0을 유지하여 완전한 오픈 소스로 운영되고 있다는 점입니다. 이는 엘라스틱서치의 라이선스 변경으로 인한 제약에서 벗어나 커뮤니티 주도 개발에 중점을 둠으로써, 사용자들은 활발한 커뮤니티 기반 문제 해결 생태계의 장점을 누릴 수 있습니다. 또한, 유료 버전의 엘라스틱서치 및 키바나 기능을 포함한 싱글사인온 기능, 권한 관리, 이상탐지 기능 등을 활용할 수 있는 이점과 함께, 직접 구성이 번거로운 경우에는 AWS에서는 관리형 서비스로 제공하는 것을 활용해 간편하게 구축하고 활용할 수 있습니다. 특히 오픈서치는 엘라스틱서치의 사용자 인터페이스인 키바나(Kibana)에서 파생된 오픈서치 대시보드(OpenSearch Dashboards)를 제공하여 키바나에서 조회했던 탐색 기능을 바로 활용할 수 있다는 편의성을 제공합니다. 로그 저장 전략에 있어, 자주 조회하는 짧은 기간의 로그 데이터를 오픈서치를 사용하여 보관하는 것이 일반적이지만, 자주 조회하지 않는 긴 기간의 로그 데이터는 그라파나에서 제공하는 로키(Loki)를 활용하여 비용 집약적으로 조회하는 하이브리드 전략을 사용할 수 있습니다. 이와 같은 로그 데이터를 그라파나에 통합하여 다른 데이터와 함께 파악할 수 있지만, 로그에 대한 복잡하고 상세한 내용을 통한 분석을 위해서는 오픈서치 대시보드를 사용할 경우도 있습니다.

트레이스 파이프라인

[변경] 템포(Tempo)

깃허브 스타: 4.9k, 라이선스: AGPL3.0

템포(Tempo)는 분산된 마이크로서비스에서 발생하는 이벤트를 수집하는 트레이스 도구로, 주로 병목 지점을 찾거나 에러를 탐색하기 위한 목적으로 사용됩니다. 트레이스 데이터의 생성은 마이크로서비스 개발 시 오픈텔레메트리(OpenTelemetry) SDK를 추가함으로써 표준화되며, 더 상세한 추적 정보를 포함하고 싶다면 개발자가 수동으로 스팬(Span)을 추가하는 작업이 필요합니다. 템포는 시각화 도구인 그라파나(Grafana) 환경과 자연스럽게 통합할 수 있어 사용이 간편합니다. 또한 템포는 다른 도구들과 달리 비용 효율적인 저장 방식이 큰 장점입니다. 기존 트레이스 도구와 달리 스팬의 모든 태그와 메타 데이터를 인덱싱하지 않고 트레이스 ID(Trace ID) 기반으로 데이터를 저장하여 데이터 저장 비용이 크게 줄어 듭니다. 이러한 특징을 통해 그라파나 생태계 기반으로 트레이스 데이터와 메트릭 데이터(추가적으로 로그 데이터)를 연계하기 위한 최적의 선택지로 고려할 수 있습니다.

[추가] 프로파일 파이프라인

파이로스코프(Pyroscope): 지속적 프로파일링

깃허브 스타: 11k, 라이선스: AGPL-3.0

파이로스코프(Pyroscope)는 그라파나에서 제공하는 오픈 소스 지속적 프로파일(Continuous Profile) 플랫폼입니다. 애플리케이션의 성능 문제를 코드 한 줄 단위까지 디버깅할 수 있도록 도와주며, CPU, 메모리, I/O 등의 리소스 사용 현황을 시간에 따라 추적하고 분석할 수 있습니다. 파이로스코프는 2021년 시작된 파이프스코프 프로젝트와 2022년 그라파나 랩스가 시작한 플레어(Phlare) 프로젝트가 합쳐져 탄생했습니다. 빠르고 확장 가능하며 고가용성을 제공하는 스토리지와 쿼리 기능을 갖추고 있어, 대규모 환경에서도 효율적으로 프로파일 데이터를 저장하고 조회할 수 있습니다. 그라파나와 완벽하게 통합되어 로그, 메트릭, 트레이스, 프로파일 데이터를 한 곳에서 확인할 수 있습니다.

메트릭, 로그, 분산 트레이스, 프로파일 그리고 외부 데이터 시각화 도구

그라파나(Grafana): 시각화 도구

깃허브 스타: 71k, 라이선스: AGPL-3.0

그라파나(Grafana)는 데이터 시각화를 구성하는 사실상 표준인 오픈 소스 도구입니다. 그라파나의 가장 큰 강점은 다양한 데이터 소스에 대한 유연한 통합 기능입니다. 메트릭 데이터를 수집하는 대부분의 도구들이 그라파나와의 연계를 기본적으로 지원하며, 메트릭 데이터 연계 외에도 오픈서치와 로키같은 도구를 이용하여 로그 데이터를 연계할 수 있습니다. 추가로 템포와 같은 트레이스 데이터 그리고 파이로스코프를 통한 프로파일 데이터 또한 시각화가 가능합니다. 이 외에도 포스트그레스큐엘과 같은 관계형 데이터베이스의 데이터, 클릭하우스, 빅쿼리와 같은 분석계 데이터도 시각화할 수 있습니다. 그라파나 대시보드 내에서 특정 지표를 클릭하면 관련 내용으로 이동하는 데이터 링크를 통해서 문제와 연관된 데이터들을 통해 명확한 상관 관계 분석을 할 수 있게 됩니다. 그라파나는 시각화 기능 외에도 특정 조건(임계치)을 만족할 경우 사용자에게 경보를 보낼 수 있는 기능을 내장하고 있습니다. 이는 프로메테우스의 얼럿매니저와 유사하지만, 프로메테우스의 데이터만 경보를 보낼 수 있는 얼럿매니저와 다르게 그라파나 데이터 소스로 발생한 데이터를 기준으로 경보를 보내기에, 문제 발생 시 경보부터 사후 원인 분석까지 통합된 환경에서 처리할 수 있습니다.

클러스터 프로비저너

kubeadm

깃허브 스타: 3.9k, 라이선스: Apache License 2.0

쿠버네티스에서 가장 많이 사용하는 클러스터 프로비저닝 CLI 도구로서, 간단한 명령어로 컨트롤 플레인을 프로비저닝하고, 다수의 워커 노드를 컨트롤 플레인 API 서버로 참여하도록 설정할 수 있습니다. 단순히 kubeadm 명령줄을 길게 나열해서 배포하는 것 이외에도 YAML 형식의 설정파일을 이용하여서 클러스터를 프로비저닝할 수 있습니다.

kubespray

깃허브 스타: 18k, 라이선스: Apache License 2.0

앤서블 플레이북을 이용해서 쿠버네티스 클러스터를 프로비저닝할 수 있습니다. kubeadm 대비 여러개의 컨트롤 플레인 노드를 설정해야할 때, 한번의 설정으로 클러스터의 컨트롤 플레인 및 워커 노드를 구성할 수 있다는 장점이 있습니다.

테라폼(Terraform)

깃허브 스타: 47.2k, 라이선스: BSL 1.1

테라폼은 Hashicorp에서 만든 코드형 인프라(Infrasructure as Code, IaC) 관리 도구로 일련의 클라우드 인프라를 코드화 하여 관리할 수 있도록 도와줍니다. 각 클라우드에서 제공하는 프로바이더를 활용해 다양한 플랫폼에 대한 관리가 가능하여 인프라 프로비저닝에 가장 널리 쓰이는 도구이며 쿠버네티스를 배포할 때도 효과적으로 사용할 수 있습니다. 볼트와 마찬가지로 Hashicorp 제품군의 라이선스가 BSL로 변경되어 오픈 소스 소프트웨어라고 부르기 어려운 면이 있습니다. 그러한 이유로 OpenTofu 프로젝트가 포크되었고, 현재 리눅스 재단(LF, Linux Foundation)에서 관리하고 있습니다. 그렇지만 일반 사용자가 테라폼을 사용하는 것에 있어서는 달라지는 부분이 없고, 테라폼이 현재 시점에 검증되어 있기 때문에 이번 해 역시 테라폼을 선택했습니다.

작가

조훈(CNCF 앰버서더)

심근우

문성주

이성민

<원문>

2026년 쿠버네티스 표준 아키텍처

]]>

MCP의 다음은 클로드 스킬(Claude Skills)인가?

MCP 열심히 찾아다니셨죠? 안타깝지만...

2024년 하반기, MCP(Model Context Protocol) 열풍이 불었습니다. Anthropic이 주도하고 오픈소스로 공개한 이 프로토콜은 "AI계의 USB-C"라는 별명과 함께 빠르게 퍼져나갔죠. 개발자분들은 MCP 서버 만드는 법을 공부하고, JSON-RPC 스펙을 들여다보고, Transport 인터페이스를 구현해 보셨을 겁니다. 비개발자분들은 "이 MCP 깔면 성능 올라간다더라" 하면서 더 좋은 MCP를 찾아다니셨을 거고요. Cursor에 MCP 연결하고, Claude Desktop에 MCP 세팅하고, 다들 한 번쯤은 해보셨을 겁니다.

그런데 어느 순간 이상한 생각이 들었습니다. "잠깐, LLM은 자연어를 이해하는 모델 아닌가? 그런데 왜 이렇게 정형화된 프로토콜이 필요하지?" 이 질문이 이 글의 출발점입니다. 결론부터 말씀드리면, MCP의 근본적인 전제에 의문을 제기하고 싶습니다. 그리고 그 대안으로 떠오르고 있는 '클로드 스킬(Claude Skills)'이 왜 더 LLM의 본질에 맞는 접근인지 이야기해 보려고 합니다.

지금은 바이브 코딩 시대입니다. AI와 함께 무언가를 만드는 것이 더 이상 개발자만의 영역이 아니죠. 이 시대에 진짜 필요한 건 복잡한 프로토콜을 설치하는 게 아니라, 자신만의 워크플로를 자유롭게 만들어내는 능력입니다.

이 글을 끝까지 읽으시면 다음을 얻어가실 수 있습니다.

MCP가 무엇이고, 왜 한계가 있는지
클로드 스킬이 어떻게 다른 접근을 취하는지
실제로 스킬을 만들어 활용하는 실전 팁들

그럼 시작해 보겠습니다.

MCP, 그래서 정체가 뭔가요?

MCP를 이해하려면 먼저 'Function Call'이라는 개념부터 알아야 합니다. 원래 LLM은 텍스트만 생성하는 모델이었습니다. 질문하면 답변하고, 글을 써달라면 글을 쓰고. 그런데 어느 순간부터 LLM이 "도구"를 쓸 수 있게 됐습니다. 날씨를 물어보면 실제 날씨 API를 호출하고, 파일을 읽어달라면 진짜 파일을 읽어오는 식으로요.

이게 바로 Function Call입니다. LLM에 "너 이런 도구들 쓸 수 있어"라고 알려주면, LLM이 상황에 맞게 적절한 도구를 골라서 호출하는 거죠. 사용자가 "서울 날씨 어때?"라고 물으면, LLM이 스스로 판단해서 날씨 API를 호출하고 그 결과를 바탕으로 답변합니다.

<출처: 작가, 클로드 생성>

그런데 문제가 있었습니다. 각 서비스마다 도구를 연결하는 방식이 다 달랐던 거죠. A 서비스는 이렇게, B 서비스는 저렇게... 표준이 없으니 매번 새로 배워야 했습니다. MCP는 이 문제를 해결하려고 등장했습니다. "도구 목록을 가져오는 방법"과 "도구를 실행하는 방법"을 하나의 규격으로 통일한 거죠. 쉽게 말해 MCP 서버에 "너 뭐 할 수 있어?"라고 물으면 도구 목록을 알려주고, "이거 실행해 줘"라고 하면 실행해 주는 방식입니다.

그래서 "AI계의 USB-C"라고 불렸습니다. USB-C가 충전기, 모니터, 외장하드를 하나의 포트로 연결하듯이, MCP는 다양한 외부 도구를 하나의 방식으로 연결할 수 있게 해준다는 거였죠. 여기까지만 보면 완벽해 보입니다. 그런데 정말 그럴까요?

MCP에 대한 흔한 오해들

MCP 열풍이 불면서 몇 가지 오해도 함께 퍼졌습니다.

첫 번째 오해는 "MCP를 달면 성능이 올라간다"는 것입니다. 커뮤니티에서 "이 MCP 설치하니까 훨씬 좋아졌어요"라는 후기를 많이 보셨을 겁니다. 하지만 MCP는 마법의 성능 부스터가 아닙니다. MCP는 그저 LLM과 외부 도구를 연결하는 '규격'일 뿐이에요. USB-C 케이블을 샀다고 컴퓨터 성능이 올라가지 않는 것과 같습니다.

두 번째 오해는 "MCP만 있으면 다 된다"는 것입니다. MCP 서버가 있어도, 이걸 실제로 활용하려면 '호스트 앱'이 필요합니다. 호스트 앱이란 LLM과 대화하면서 필요할 때 MCP 서버에 도구 호출을 요청하는 프로그램이에요. Claude Desktop이나 Cursor 같은 앱들이 바로 이 호스트 앱입니다.

MCP 서버가 "나 이런 도구 있어요"라고 말해줘도, 그걸 언제 어떻게 쓸지 판단하고 실행하는 건 호스트 앱의 몫입니다. 그래서 같은 MCP 서버를 연결해도 호스트 앱에 따라 결과가 달라질 수 있죠.

세 번째로 알아야 할 점이 있습니다. MCP 프로토콜 자체는 오픈소스지만, 정작 잘 만들어진 호스트 앱들은 오픈소스가 아닙니다. Claude Desktop도, Cursor도 핵심 코드는 공개하지 않고 있어요. MCP 서버는 누구나 만들 수 있지만, 그걸 제대로 활용하는 호스트 앱을 만드는 건 또 다른 문제인 거죠.

결국 MCP의 진짜 가치는 호스트 앱이 얼마나 잘 만들어졌느냐에 달려 있습니다. 그런데 여기서 더 근본적인 질문이 떠오릅니다.

잠깐, LLM에 왜 정형화된 프로토콜이 필요하죠?

여기서 한 발짝 물러서서 생각해 볼게요. LLM은 무엇에 특화된 모델인가요? 바로 비정형 데이터입니다. 자연어 처리요. "이거 해줘"라고 해도 알아듣고, "이것 좀 부탁드립니다"라고 해도 알아듣고, "해주시면 감사하겠습니다"라고 해도 알아듣습니다. 정해진 형식이 아니어도 말만 통하면 이해하는 게 LLM의 본질입니다.

그런데 MCP는 어떤가요? 정형화된 프로토콜입니다. "도구 목록을 가져오려면 tools/list 엔드포인트를 호출하세요", "도구를 실행하려면 tools/call 엔드포인트에 정해진 형식으로 요청하세요". 기존 프로그래밍처럼 특정한 형태의 요청을 특정한 주소에 보내야 특정한 응답이 나오는 구조입니다.

이상하지 않나요? 비정형 데이터를 자유자재로 다루는 LLM에게, 왜 정형화된 프로토콜을 씌우고 있는 걸까요?

사실 더 간단한 방법이 있습니다. 그냥 마크다운 파일 하나에 이렇게 쓰면 됩니다: "사용자가 날씨를 물어보면 weather.sh 스크립트를 실행해 줘" LLM은 이걸 읽고 이해합니다. 사용자가 "서울 날씨 어때?"라고 물으면, 스스로 판단해서 해당 스크립트를 실행합니다. list 엔드포인트도 필요 없고, call 엔드포인트도 필요 없습니다. 말을 알아듣으니까요.

MCP의 진짜 문제는 여기 있습니다. 정형화된 프로토콜을 만들고 유지하는 게 어렵습니다. 기존 서비스에 MCP를 붙이려면 모든 기능을 MCP 규격에 맞게 매핑하는 작업이 필요합니다. 개발자에게도 부담이고, 비개발자에게는 아예 진입장벽이 됩니다. 자연어로 "이 서비스는 이런 기능이 있고, 이렇게 호출하면 돼"라고 써두면 LLM이 알아서 이해하는데, 왜 굳이 복잡한 프로토콜을 거쳐야 할까요? 이 질문에 대한 답이 바로 '클로드 스킬(Claude Skills)'입니다.

클로드 스킬, 자연어로 워크플로를 정의하다

클로드 스킬은 Anthropic이 내놓은 새로운 접근입니다. MCP처럼 정형화된 프로토콜이 아니라, 그냥 자연어로 "이럴 때 이렇게 해줘"라고 적어두는 방식이죠. 스킬의 실체는 단순합니다. 폴더 안에 SKILL.md 파일을 만들고, 거기에 워크플로를 자연어로 설명하면 됩니다. Claude가 이 파일을 읽고 상황에 맞게 알아서 실행합니다.

예를 들어 이런 식입니다.

name: db-setup
description: D1 데이터베이스 연동 워크플로. "DB 연동", "데이터베이스 설정", "D1 추가" 등의 요청 시 트리거됩니다.

## 워크플로
1. 먼저 wrangler.toml 파일이 있는지 확인합니다.
2. D1 데이터베이스가 이미 생성되어 있는지 확인합니다.
3. 없다면 `wrangler d1 create` 명령으로 생성합니다.
4. drizzle ORM 관련 패키지를 설치합니다.
5. src/server/db 폴더에 schema.ts와 index.ts를 생성합니다.
6. drizzle.config.ts 설정 파일을 생성합니다.
7. 마이그레이션을 실행하여 테이블을 생성합니다.

## 주의사항
- 기존 DB가 있으면 덮어쓰지 않고 연결만 합니다.
- 마이그레이션 전 반드시 백업 여부를 확인합니다.

이게 전부입니다. JSON-RPC 스펙도 없고, 엔드포인트 매핑도 없습니다.

`name`은 스킬의 이름, `description`은 이 스킬이 무엇을 하고 언제 트리거 되는지를 설명합니다. "DB 연동", "데이터베이스 설정" 같은 키워드가 나오면 이 스킬이 활성화되는 거죠. 본문에는 워크플로와 주의 사항을 자연어로 적으면 됩니다.

MCP와 비교해 보면 차이가 명확합니다. MCP로 같은 기능을 구현하려면? 서버를 띄우고, tools/list에 도구 목록을 정의하고, tools/call에 각 도구의 실행 로직을 구현하고, 호스트 앱과 연결해야 합니다. 개발자도 꽤 손이 가는 작업이고, 비개발자는 시작조차 어렵습니다.

클로드 스킬로 같은 기능을 구현하려면? 폴더 만들고, SKILL.md 파일에 자연어로 적으면 끝입니다. 비개발자도 할 수 있습니다. 어떤 동작을 수행하면 좋을지를 한글로 타이핑할 뿐이니까요. 이것이 LLM의 본질에 맞는 접근입니다. 말을 알아듣는 모델에게, 말로 지시하는 거죠. MCP가 LLM을 기존 프로그래밍 패러다임에 끼워 맞추려 했다면, 클로드 스킬은 LLM의 강점을 그대로 활용합니다.

클로드 스킬, 어떻게 잘 쓸 수 있을까?

클로드 스킬을 효과적으로 사용하기 위한 공식 모범 사례가 있습니다. Anthropic에서 제공하는 문서에 자세히 나와 있는데, 간단히 핵심만 짚어보겠습니다.

첫째, 간결함이 중요합니다. Claude는 이미 똑똑합니다. PDF가 뭔지, 라이브러리가 어떻게 작동하는지 일일이 설명할 필요 없어요. 필요한 맥락만 적으면 됩니다.
둘째, 자유도를 조절하세요. 여러 접근이 가능한 작업은 느슨하게, 정확한 순서가 중요한 작업은 구체적으로 지시합니다.
셋째, 점진적 공개를 활용하세요. SKILL.md는 목차처럼 쓰고, 상세 내용은 별도 파일로 분리합니다. Claude가 필요할 때만 참조 파일을 읽어서 토큰을 절약할 수 있어요.
넷째, 그리고 가장 중요한 건 반복적으로 개선하는 것입니다.

공식 문서에서 권장하는 방식이 있습니다. Claude A(스킬 개발용)와 Claude B(테스트용)를 분리해서 사용하는 거예요. Claude A와 함께 스킬을 만들고, Claude B에서 실제로 테스트하고, 문제가 생기면 다시 Claude A로 돌아와서 개선합니다.

스킬 작성 전에 평가 시나리오를 먼저 만드는 것도 좋습니다. "이 스킬이 제대로 작동하면 어떤 결과가 나와야 하지?"를 먼저 정의해두면, 상상이 아닌 실제 문제를 해결하는 스킬을 만들 수 있습니다. 여기까지가 공식 가이드의 핵심입니다. 그런데 제가 실제로 스킬을 써보면서 발견한 팁이 하나 더 있습니다.

실전 팁: 고정된 작업은 스크립트로 분리하세요

공식 문서에서도 스크립트 활용을 권장하지만, 저는 여기서 한발 더 나아갑니다. 제가 클로드 코드를 활용한 노코드 툴을 서비스하면서 발견한 팁인데요. 반복되는 고정 작업은 아예 스크립트로 빼버리세요.

앞서 보여드린 DB 연동 워크플로를 다시 볼까요? 7단계나 되는 워크플로를 Claude가 매번 해석하고 실행합니다. 잘 되긴 하지만, 매번 토큰을 소모하고 시간이 걸리죠. 이걸 스크립트로 바꿔버리면 어떨까요? 실제로 서비스에서 사용하는 스킬입니다.

name: db-setup
description: D1 데이터베이스 연동. "DB 연동", "데이터베이스 설정", "D1 추가" 등의 요청 시 트리거됩니다.

bash -c '.claude/skills/db-setup/scripts/setup.sh'

db-setup 스크립트를 실행하는 모습 <출처: 작가>

똑같은 작업인데, 워크플로를 자연어로 풀어쓰는 대신 스크립트 하나를 호출합니다. 토큰 소모가 줄고, 실행 속도가 빨라집니다. 왜 그럴까요?

첫째, LLM이 비정형 데이터를 잘 다루긴 하지만, 데이터양이 많아지면 느려지고 누락도 생길 수 있어요. 2+3을 Claude한테 직접 계산시켜도 되지만, 계산기 스크립트에 2와 3을 넘기면 더 빠르고 정확하잖아요? 같은 원리입니다.
둘째, 필요한 부분만 변수로 받게 하면 전체 워크플로를 에이전트에 위임하지 않아도 됩니다. 고정된 로직은 스크립트가 처리하고, Claude는 변수만 채워주는 거죠.

"그러면 그냥 쉘 스크립트 직접 호출하면 되지, 왜 스킬로 감싸야 하나요?" 좋은 질문입니다. 쉘 스크립트는 유지보수가 어렵습니다. 예외 상황도 많아서, 잘 돌아가다가도 뭔가 하나만 바뀌면 멈춰버리죠.

스킬로 감싸면 다릅니다. Claude가 스크립트 실행 중 막히면 알아서 고쳐서 실행합니다. 실제로 저도 경험한 적이 있는데요. 제가 쉘 스크립트를 잘못 짜놨는데, 한 달이 지나서야 발견했습니다. 왜 한 달이나 걸렸냐고요? Claude가 알아서 고쳐서 돌리고 있었거든요. 스크립트의 정확함과 속도, 거기에 LLM의 유연함이 더해진 겁니다.

핵심은 이겁니다. LLM의 유연함 + 스크립트의 정확함/속도. 이 조합이 최강입니다. 고정된 워크플로가 있다면 Claude한테 "이 동작 스크립트로 짜줘"라고 해보세요. 알아서 짜줍니다. 그리고 그 스크립트를 스킬에서 호출하게 만들면, 빠르고 정확하면서도 예외 상황에 유연하게 대응하는 워크플로가 완성됩니다.

그래서 MCP는 정말 죽었나요?

여기까지 읽으셨다면 "MCP는 이제 버려야 하나?"라고 생각하실 수도 있습니다. 결론부터 말씀드리면, 아닙니다. MCP도 여전히 의미가 있습니다.

첫째, 생태계입니다. MCP는 이미 거대한 오픈소스 생태계를 구축했습니다. 수많은 MCP 서버가 공개되어 있고, 다양한 서비스들이 MCP를 지원합니다. 필요한 기능이 이미 MCP로 구현되어 있다면, 굳이 새로 만들 이유가 없죠.
둘째, 공유의 용이성입니다. 클로드 스킬은 폴더 기반이라 내 컴퓨터에 파일로 존재합니다. 다른 사람과 공유하려면 파일을 직접 전달해야 해요. 반면 MCP는 설치 형태라 배포와 공유가 쉽습니다.

그래서 제 결론은 이렇습니다.

개인 워크플로, 팀 내부 자동화, 빠른 프로토타이핑에는 클로드 스킬이 압도적으로 유리합니다. 자연어로 정의하고, 스크립트로 최적화하고, Claude의 유연함으로 예외를 처리하면 됩니다.

외부 서비스 연동, 커뮤니티 공유, 대규모 배포에는 MCP가 여전히 좋은 선택입니다. 이미 구축된 생태계를 활용할 수 있으니까요.

결국 둘 다 도구입니다. 상황에 맞게 쓰면 됩니다. 다만 한 가지는 분명합니다. LLM의 본질은 자연어 이해입니다. 정형화된 프로토콜보다 자연어로 정의하는 방식이 LLM과 더 잘 맞습니다. 클로드 스킬은 그 방향으로 가는 첫걸음이고, 앞으로 이런 접근이 더 확산될 거라고 생각합니다.

바이브 코딩 시대, 복잡한 프로토콜을 외우는 대신 자신만의 워크플로를 자유롭게 만들어보세요. 생각보다 훨씬 쉽습니다.

]]>

기획자·운영자·창업자가 꼭 써봐야 할 바이브 코딩 도구 3가지

일하다 보면 지금 당장 무언가를 만들고 싶은 순간이 찾아올 때가 있습니다.

눈앞에서 직접 움직이는 프로토타입으로 소통하고 싶은 제품팀, 반복되는 병목을 자동화해 숨 쉴 틈을 만들고 싶은 운영팀, 아이디어를 빠르게 검증하며 사업의 가능성을 확인하고 싶은 1인 창업자. 모두에게 그런 순간이 옵니다. 문제는 개발 지식이 없으면 시작조차 할 수 없었다는 거죠.

하지만, 이제는 자연어만으로도 코드를 생성하고, 자동화 흐름을 만들고, MVP까지 완성할 수 있는 환경이 만들어 졌습니다. 우리는 이 방식을 바이브 코딩이라고 부릅니다. 개발 문법을 공부하는 것이 아니라 AI에게 개발을 맡기고 사람이 문제 정의와 방향을 책임지는 구조에 더 가깝습니다.

하지만 그러한 도구들이 넘쳐나는 지금, 어떤 상황에서 어떤 도구를 골라야 하는지는 여전히 어렵습니다. 비슷해 보이지만 실제로 해결하는 문제가 다르고 각 프로덕트가 강점을 발휘하는 순간도 분명히 다르기 때문입니다. 적합한 프로덕트를 고르지 못하면 바이브 코딩은 흥미로운 기술 실험으로 끝나 버리고 진짜 변화는 만들지 못합니다.

그래서 이번 글에서는 실무의 임팩트를 만드는 일을 지금, 바로, 시작하고 싶은 사람을 위해 3가지 도구를 선별했습니다. 개발은 몰라도 AI로 ‘개발 비슷한 그 무언가’를 하기에 가장 좋은 도구죠. 차례대로 살펴보겠습니다.

물론, 실제 코드를 다루는 작업의 보조로 AI를 활용하는 것이 바이브 코딩의 엄밀한 정의에 가깝습니다. 그러나 현재 바이브 코딩은 AI와 함께 ‘프로그래밍’이라는 IT 업계의 거대한 병목을 해결하는 키워드로도 쓰이고 있습니다. 이에 보다 넓은 범위로 바이브 코딩이란 용어를 활용한 점, 이해해 주세요.

Lovable: 당장 프로토타입 보여주고 싶은 기획자라면

아이디어가 추상적인 단계에 머물러 팀 내에서 이해가 엇갈릴 때가 있습니다. 기획자나 PM은 방향을 빠르게 시각화해 의사결정을 밀어붙이고 싶은 마음이 간절해지죠. 하지만, 개발 리소스를 기다릴 수 없고, 피그마 작업은 시간이 오래 걸린다고 합니다. 그럴 때 Lovable은 기획자가 먼저 움직일 수 있는 선택지가 됩니다.

Lovable 사용자 리뷰 살펴보기

실제로 써보면 어떤 변화가 생길까요?

이 프로덕트를 쓰면 기획 흐름이 정말 빨라집니다. 논의를 그림으로 옮기는 데 드는 시간이 줄어들고, 아이디어 검증과 팀 커뮤니케이션의 속도가 크게 달라지기 때문이죠. 즉, “말로 하는 기획”을 “움직이는 기획”으로 바꿔주는 힘을 가진 프로덕트입니다.

자연어로 입력만 해도 몇 분 내로 첫 화면을 확인할 수 있어 초기 의사결정이 빨라집니다.
링크로 공유할 수 있는 프로토타입이 바로 만들어져 팀 내 이해 충돌이 크게 줄어듭니다.
기획자가 직접 초안을 반복 수정하며 화면 흐름을 스스로 조율할 수 있습니다.
레이아웃과 기능의 뼈대를 빠르게 확보하면서 “이 기능이 실제로 어떻게 보일지”를 검증할 수 있습니다.

왜 Lovable?

Lovable은 자연어 한 줄로 프로그램을 바로 생성해 주는 ‘속도 중심’ AI 도구의 자리를 선점했습니다. 아무것도 모르는 사람이라도, 복잡한 온보딩 없이 바로 브라우저에서 화면을 볼 수 있게 했으니까요. 그래서 “기획자 혼자서도 첫 버전을 만든다”는 놀라운 순간을 가장 “그럴듯하게” 제공해 왔습니다. 속도와 디자인의 완성도 그 중간 어딘가에서 우위를 점하며 기획 단계에서 흔히 쓰이는 자동화 프로토타입 도구 중 하나로 자리 잡았습니다.

비슷하지만 또 다른 2가지 대안

하지만, 지금 Lovable이 독점적인 위치를 가진 것은 아닙니다. 비슷한 도구들이 쏟아져 나온데다 각자 또 다른 강점을 가졌기 때문입니다.

Bolt.new(왼쪽)와 Replit(오른쪽)

Bolt.new: 가장 가볍게 즉석에서 데모를 뽑고 싶을 때

Bolt.new는 “AI가 전 과정에 참여하는 무거움” 대신 정말 빠르게 단일 화면을 만들어야 하는 상황에 특화되어 있습니다. Lovable이 로직과 레이아웃, 코드를 종합적으로 만들어 내는 데 비해 Bolt.new는 ‘지금 회의에서 당장 보여줄 한 컷’을 뽑아내는 데 최적화된 초경량 도구입니다.

UI 복잡도를 최소화한 구조라 로딩과 생성 속도가 매우 빠릅니다.
온보딩이 거의 필요 없어 기획자가 “일단 눌러만 보면 결과가 나오는 경험”을 제공합니다.
결과물의 형태가 단순해 Lovable보다 부담 없이 초안을 시작하기 좋습니다.

Replit: 단순 기획용보다는 조금 나은 수준까지 확장하고 싶을 때

Replit은 개발 기능이 비교적 강력한 플랫폼입니다. Lovable이 기획자의 손에 ‘앱 형태의 프로토타입’을 빠르게 쥐여주는 도구라면, Replit은 그 프로토타입을 실제로 작동하는 제품으로 확장하는 대안입니다.

한 발 나아가 코드를 작성·수정·실행할 수 있는 환경을 제공합니다.
AI가 코드 제안과 디버그, 리팩토링을 도와 더 정교한 기능 구현이 가능합니다.
백엔드·프론트엔드·데이터 연동 등을 처리해 실제 MVP나 운영할 프로그램 제작까지 갈 수 있습니다.

그 대신 이 단점은 꼭 알고 있어야 합니다

이런 도구들의 특징이 있습니다. 빠르게 나오는 만큼 결과물의 품질과 유연성에서 분명한 한계가 있다는 것이죠. 자동으로 만들어진 화면이라 품질 편차가 있고, 레이아웃이나 스타일이 일관성 없이 나오는 경우가 적지 않습니다. 코드 역시 불필요하게 복잡하거나 길어 유지보수와 확장 작업에는 절대로 적합하지 않습니다.

게다가 디자인과 속도를 둘 다 신경 쓴다는 말은 반대로 디자인 완성도와 복잡한 사용자 흐름, 실제 운영 단계에 필요한 수준의 기능 구현에는 신경 쓰지 못한다는 말입니다. 결국 이들 모두 초기 기획과 방향성 탐색 단계에서 가장 힘을 발휘하는 도구이며, 프로토타입 다음 단계에서는 다른 선택지를 함께 고려하는 것이 현실적입니다.

> 나만의 Lovable 리뷰 남기기

Make: 자동화로 병목 없애고 싶은 운영자라면

운영 업무에서는 작은 병목 하나가 전체 흐름을 멈추게 하는 경우가 많습니다. 매일 하는 데이터 정리, 사람 사이 전달 실수, 누락되는 승인 프로세스, 보고용 대시보드 업데이트 같은 단순하지만 중요한 일이 쌓이다 보면, 운영자는 문제를 정확히 알고 있음에도 “손이 모자라서” 해결하지 못하는 순간을 자주 맞습니다.

하지만, 개발 리소스는 우선순위에서 매번 밀리기 마련입니다. 그렇게 엑셀과 여러 SaaS를 왔다 갔다 하는 임시 방편만 늘어나는 상황이죠. 이때 Make는 운영자가 스스로 자동화를 설계할 수 있게 해주는 현실적인 도구입니다.

또한, 이제 나올 프로덕트는 엄밀히 말하면 코드를 아예 다루지 않으므로 “바이브 코딩” 도구로는 보기 어렵습니다. “개발”이라는 병목을 넘는 맥락에서 봐주세요.

Make 사용자 리뷰 살펴보기

실제로 써보면 어떤 변화가 생길까요?

Make를 쓰면 운영 흐름이 눈에 띄게 정리됩니다. 사람이 직접 반복하던 단계를 자동으로 이어붙일 수 있어 병목이 줄어들고, 실수 발생 가능성도 낮아집니다. 즉, “사람이 붙잡고 있는 운영”을 “흐름이 흘러가는 운영”으로 바꾸는 경험을 하게 됩니다.

반복적인 데이터 이동과 정리 작업을 자동화해 시간을 크게 줄여줍니다.
이메일·슬랙·노션·구글시트 등 여러 SaaS 간 프로세스를 하나의 흐름으로 연결할 수 있습니다.
조건 분기나 스케줄 트리거를 직접 구성해 운영자의 업무 패턴을 그대로 재현할 수 있습니다.
자동화가 한 번 자리 잡으면 실수·누락·지연 같은 리스크가 자연스럽게 줄어듭니다.

왜 Make?

복잡한 워크플로를 시각적으로 구성할 수 있다는 점에서 다른 자동화 도구보다 진입장벽이 낮습니다. 블록을 연결하듯 흐름을 만들 수 있어 운영자가 “개발 없이도 시스템을 설계한다”는 감각을 느낄 수 있습니다. 또한 단순 트리거 수준을 넘어 조건 분기, 반복 처리, 데이터 변환 같은 고급 동작까지 지원하죠. 그래서 Make는 복잡한 논리와 데이터 변형을 다루는 데 강한 도구입니다. 운영 과정에서 필요한 세밀한 제어를 제공하는 것이 가장 큰 강점입니다.

비슷하지만 또 다른 2가지 대안

자동화를 원한다는 점에서는 같지만, Make의 부족한 점을 강화하는 또 다른 대안 역시 있습니다.

n8n(왼쪽)과 Zapier(오른쪽)

Zapier: 가장 단순하고 빠르게 자동화를 시작하고 싶을 때

사실 자동화에서 더 익숙하고 유명한 것은 Zapier일지도 모릅니다. 초보자에게 가장 친숙한 자동화 프로덕트이기도 하죠. 한두 개의 앱을 연결하는 단순한 흐름을 만들 때는 Make보다 접근성이 높아 “빠른 시작”에 적합합니다.

UI가 단순해 맥락을 이해하기 훨씬 쉽습니다.
자주 쓰는 앱들이 기본 템플릿으로 준비되어 있어 설정 시간이 짧습니다.
복잡한 로직이 필요 없을 때는 Zapier가 Make보다 더 간편합니다.

n8n: 더 강력한 제어, 비용 효율을 둘 다 잡고 싶을 때

n8n은 오픈소스 자동화 도구로 고급 자동화와 자유도를 원하는 경우에 적합합니다. 외부 서비스를 받아오는 것이 아니라 직접 호스팅, 즉, 우리 환경에서 활용할 수 있는 것도 장점이죠. 비용과 함께 데이터 유출의 부담도 줄일 수 있습니다.

조건 분기, 반복 처리 등 Make 수준의 복잡한 플로우 구성을 지원합니다.
자체 서버 운영이 가능해 민감 데이터나 내부 시스템 연동에 유리합니다.
플러그인 생태계가 넓어 고급 사용자에게 유용합니다.

그 대신 이런 단점은 꼭 알고 있어야 합니다

이 모든 자동화 도구는 시각적 구성으로 시작하기 쉬운 반면, 플로우가 복잡해질수록 관리가 어려워지는 경우가 있습니다. 설정의 수가 많아지면 흐름이 한눈에 들어오지 않거나, 예외 처리 설정이 누락되어 예상치 못한 동작이 발생할 수도 있습니다. 또한 대용량 데이터 처리나 빠른 응답성이 요구되는 경우에는 성능의 한계도 느껴집니다.

결국 Make는 반복적이거나 단계가 명확한 운영 프로세스 자동화에는 매우 강력하지만, 대규모 트랜잭션이나 정교한 시스템 통합을 완전히 대체하기에는 제약이 있습니다.

> 나만의 Make 리뷰 남기기

Cursor: 바로 팔 수 있는 제품이 필요한 초기 창업자라면

초기 창업자는 아이디어보다 만들어진 결과물 하나가 더 큰 힘을 발휘한다는 것을 잘 압니다. 하지만 개발자를 구하기도 어렵고, 외주를 쓰기에는 비용 부담이 크며, 직접 개발을 배우기에는 시간이 턱없이 부족합니다. 그렇다고 PPT 화면만으로는 사용성과 기능, 무엇보다 프로덕트가 주는 감각을 온전히 검증하기 어렵죠.

이런 상황에서 Cursor는 “아이디어를 실제 제품 형태까지 밀어붙이고 싶은 창업자”가 가장 현실적으로 접근할 수 있는 프로덕트입니다.

Cursor 사용자 리뷰 살펴보기

실제로 써보면 어떤 변화가 생길까요?

단순히 코드 조각을 만들어 주는 프로덕트가 아닙니다. AI가 개발자처럼 옆에서 함께 일하는 경험을 주는 도구입니다. 창업자가 제품을 직접 만들어보는 데 필요한 장벽이 크게 낮아지고, 제품의 ‘가능성’을 눈앞에서 빠르게 확인할 수 있습니다.

자연어로 작성한 요구사항이 코드와 파일 구조로 변환되어 바로 실행할 수 있는 형태를 만듭니다.
기존 코드베이스를 이해하고 수정까지 이어주어 “코드가 무섭지 않은 경험”을 제공합니다.
페이지 추가, 기능 개선, 오류 수정 같은 작업을 채팅하듯 해결할 수 있어 반복 속도가 높습니다.
작은 기능이라도 실제로 작동하는 결과물이 나오기 때문에 제품 방향성 검증이 훨씬 빨라집니다.

왜 Cursor?

Cursor는 코드 작성부터 시작해 수정과 리팩토링까지, 모든 과정에 AI가 실시간으로 개입하는 개발 환경(IDE)입니다. 특히, 전체 맥락을 읽고 스스로 프로젝트 구조를 재구성하는 능력을 앞세워 차별성을 확보했습니다. 그 덕분에 코드 전체를 맥락으로 이해해 기능 단위 수정에 강합니다. MVP 구축에 필요한 파일을 새로 만들고, 폴더 구조를 잡고, 라이브러리 설치까지 자동으로 이어갑니다. 작은 요청에도 실제 실행 가능한 코드를 빠르게 제시해 MVP 제작 속도도 매우 빠르고요. 그래서 속도와 완성도의 균형이 가장 잘 맞는 도구로 자리 잡았습니다.

비슷하지만 또 다른 2가지 대안

사실 Cursor를 선정한 가장 큰 이유는 “균형”에 있습니다. 개발자가 아니기에 IDE라는 새로운 환경의 제약이 덜하면서도, 가장 활성화된 커뮤니티에서 필요한 배움을 구할 수 있는 사람들에게 적합하거든요. 한편 아래 두 대안은 특정 영역에서 더 높은 완성도를 제공합니다.

Claude Code(왼쪽)와 Figma Make

Claude Code: 개발의 완성도를 최대치로 끌어올리고 싶을 때

Claude Code는 코드 품질을 비롯해 문맥을 이해하거나 리팩토링하는 능력에서 가장 높은 평가를 받는 도구입니다. 복잡한 로직이나 대규모 파일 구조를 이해하는 능력은 Cursor보다 안정적이며, 정교한 기능을 구현해야 하거나, 안정적인 코드 품질이 중요한 경우에 더 적합합니다. 대신 “터미널”이라는 환경이 발목을 잡죠.

대규모 코드베이스의 이해력이 정말로 우수합니다.
복잡한 로직을 구현하거나 리팩토링할 때, 품질이 뛰어납니다.
코드 리뷰와 문서 생성 능력도 강력해 개발 이해도가 있다면 정말 좋은 선택지입니다.

Figma AI: 디자인 완성도를 올리고 싶을 때

기능만으로는 사용자를 설득하기 어렵습니다. 초기 제품의 첫인상에 프로덕트의 디자인은 정말 강력한 제재죠. 그래서 이때는 Figma AI(특히 Figma Make)가 더 적합한 대안입니다. 이 프로덕트는 그 제품이 “사용자에게 보이는 형태”를 정교하게 다듬는 데 강점을 가집니다. 물론, Figma를 쓸 줄 알때 말이죠.

기능 설명만으로 와이어프레임과 레이아웃을 생성하고 이를 다듬을 수 있습니다.
디자인 시스템 기반 구성으로 UI 일관성을 잘 구현할 수 있습니다.
Cursor가 구현한 화면에 ‘사용자 경험’을 입히는 식으로 같이 쓰는 것도 좋은 방법입니다.

그 대신 이런 단점은 꼭 알고 있어야 합니다

Cursor 역시 모든 개발 과정을 대신해 주는 도구는 아닙니다. AI가 생성한 코드가 항상 최적화되어 있지는 않으며, 복잡한 기능 구현에서는 오류가 반복되기도 합니다. 무엇보다 Cursor는 빠르게 기능을 붙여 나가는 데 최적화된 도구이기 때문에, 아키텍처를 설계하고, 복잡한 기능을 구현하며, 성능을 개선하는 작업에는 여전히 개발자의 손이 필요합니다. 다시 말하지만, 아직은 개발자의 필요를 완전히 없애주는 프로덕트가 절대 아닙니다. 그러니 코드를 볼 생각이 없다면 다른 프로덕트가 더 낫습니다.

무엇보다, Cursor가 비즈니스 구조까지 만들어 주지는 않습니다. 먹히는 비즈니스는 스스로의 힘으로 알아내세요. 결국 Cursor는 초기 창업자가 “작동하는 무언가”를 빠르게 만들어 시장에 던져볼 때 가장 힘을 발휘하며, 그 다음 단계에는 다른 도구나 사람의 도움이 자연스럽게 필요해질 겁니다.

> 나만의 Cursor 리뷰 남기기

마치며

몇 가지 한계에도 이 프로덕트들은 분명 우리의 일을 바꿔 놓을 엄청난 가능성을 지녔습니다. 예전 같으면 개발자를 구하거나, 예산을 들이거나, 몇 주씩 준비해야만 하던 일을 이제는 몇 시간, 잘하면 몇 분 안에도 손에 잡히게 만들었기 때문입니다. 기획자는 눈앞에서 움직이는 프로토타입으로 말할 수 있고, 운영자는 혼자서도 자동화를 설계할 수 있으며, 창업자는 “아이디어만 있는 사람”에서 “직접 만들어보는 사람”으로 훨씬 빠르게 건너갈 수 있습니다.

그렇다고 이 도구들이 모든 문제를 대신 해결해 주는 것은 아닙니다. 무엇을 만들지, 왜 만드는지, 어떤 문제를 어떻게 해결할지에 대한 결정은 여전히 사람의 몫이니까요. 3가지 모두 “생각만 하는 사람”과 “직접 만들어보는 사람” 사이의 거리를 극적으로 줄여 주는 도구일 뿐입니다. 프로덕트를 잘 고르는 것보다 더 중요한 것은, 내가 해결하려는 문제가 무엇인지, 그 문제를 겪는 사람에게 어떤 변화를 줄 것인지 스스로 분명히 아는 일입니다.

진짜 변화는 여전히 도구를 쥔 사람이, 자기 문제에 끝까지 파고들 때 만들어집니다.

]]>

요즘IT » 트렌드 » 피드

한국인의, 한국인을 위한 스킬 모음집 (Feat. 케이-스킬)

1. 써볼 것: 한국인의, 한국인을 위한 에이전트 스킬 모음집 (K-skill)

무슨 문제를 해결해 주나요?

어떻게 쓰나요?

누구에게 좋을까요?

2. 참고할 것: Anthropic이 너무 위험해서 공개하지 않은 모델

기존 AI 모델과 무엇이 다른가요?

사이버보안 능력이 어떻길래요?

그런데 문제가 있습니다

무엇을 얻어가야 하나요?

3. 적용해볼 것: Gemini에 노트북 기능 추가: NotebookLM과 양방향으로 이어집니다

무슨 문제를 해결하려 하나요?

어떻게 해결했나요?

적용해볼 질문

실행해볼 수 있는 것

정리

살아남기 위해 우리가 버려야 하는 것들: Unlearn

Unlearn이란 무엇인가?

왜, 지금 다시 Unlearn일까?

Learn - Unlearn - Relearn 루프

프로덕트 메이커에게 Unlearn이 어려운 진짜 이유

그러면 어떻게 적용해야 할까?

첫 번째, 내가 갖고 있는 업무 기준 하나를 꺼내 물어보세요.

두 번째, 하나의 프로세스를 AI로 대체하는 실험을 하세요.

세 번째, '불편함'이 느껴지는 순간을 포착하세요.

마치며

몰트북(Moltbook)의 성공에서 반드시 읽어야 할 3가지 포인트

메타는 왜 이렇게 급히 몰트북을 인수했을까?

몰트북은 오픈클로(OpenClaw)가 만든 파도 위에서 터졌습니다

첫 번째 포인트, 기능보다 ‘한 줄로 설명되는 세계관’

두 번째 포인트, 완성도보다 더 강력했던 ‘연계 속도’

세 번째 포인트, ‘AI 서비스’보다 ‘바이럴 설계 사례’로 보기

AI 시대 콘텐츠 생존 전략: GEO를 위한 SIFT프레임워크

GEO의 출발점은 '질문'입니다

대표적 질문 발굴 방법

1. 구글 서치 콘솔 활용

2. 경쟁사 벤치마킹

3. 내부 데이터 활용

​AI가 선택하는 콘텐츠의 특징

1. 질문 타입 최적화

2. 답변 스니펫

GEO 핵심 전략, SIFT 프레임워크

1. Structure - AI가 읽기 좋은 구조

2. Intent - 질문 의도와의 적합성

3. Fidelity – 팩트 기반의 충실성(브랜드 엔티티의 선명도)

4. Trust - 출처와 작성자의 신뢰도

GEO 시대, 요즘IT의 콘텐츠 AX 실험기를 만나보세요!

OpenClaw가 보여준 로컬 실행 아키텍처의 전환점

왜 OpenClaw인가?

OpenClaw의 핵심 아키텍처

게이트웨이: 컨트롤 플레인

채널: 메시징 플랫폼 인터페이스

에이전트와 에이전트 러너

도구와 스킬: 실행형 AI의 핵심

도구

스킬

OpenClaw 설치 및 실행 예제

OpenClaw 활용 영역, 일상 자동화와 맞닿는 보안의 위협

로컬 AI 시대의 아키텍처 전환

우리가 몰트북(Moltbook)에 주목해야 하는 진짜 이유

1. 몰트북(Moltbook)에서 에이전트들이 나눈 대화

2. 우리가 몰트북(Moltbook)에 주목해야 하는 진짜 이유

3. 몰트북이 불러온 3가지 문제

4. 우리에게 주어진 과제

[릴리즈 노트] 업무용 에이전트 최적화, 구글 제미나이 3.1 프로(Gemini 3.1 Pro) 출시

1. 출시 개요

2. 활용 방법

3. 핵심 성능 변화

4. 실무 중심 설계

5. 향후 방향

6. 이용 조건

[릴리즈 노트] 사람만큼 컴퓨터를 다루는 LLM, Claude Sonnet 4.6

컴퓨터 사용 능력

Claude Sonnet 4.6 평가

제품 업데이트

Claude Sonnet 4.6 사용 방법

잔디·슬랙·팀즈·네이버웍스·플로우, AI 기능 어디까지 왔나

잔디(JANDI): 대화를 사내 지식으로 바꾸는 ‘스프링클러’

대표 AI 기능: ‘스크롤 노동' 줄이고, 필요한 걸 앞으로 꺼낸다

AI가 선택하는 콘텐츠의 특징