1. 셋로그(Setlog)는 매 시간 2~4초 영상만 찍으면 하루가 자동으로 브이로그가 되는 앱입니다. 2025년 12월 출시 후 애플 앱스토어 전체 인기 순위 1위와 소셜 네트워킹 부문 1위를 동시에 기록했습니다.
2. Z세대가 인스타그램을 지우고 셋로그로 간 이유는 꾸밈 없는 진정성에 있습니다. 필터도, 편집도, 해시태그 고민도 없이 ‘지금 이 순간’만 기록합니다.
3. 셋로그의 유행은 단순히 새로운 앱이 떴다는 이야기가 아닙니다. SNS 패러다임이 ‘완벽한 나’에서 ‘있는 그대로의 나’로 바뀌고 있다는 신호입니다.

결론부터 말하면

셋로그가 유행하는 건 ‘새로운 기능’ 때문이 아닙니다. 오히려 기능을 덜어냈기 때문입니다. 편집, 필터, 보정, 좋아요, 팔로워 — 기존 SNS가 쌓아온 모든 것을 벗어던지고 “그냥 찍기만 해”라고 했더니, Z세대가 열광한 겁니다.

setlog 로고

셋로그가 뭔데

셋로그(Setlog)는 미국 스타트업 New Chat Inc.가 만든 소셜 브이로그 앱입니다. 2025년 12월 24일 iOS 전용으로 정식 출시했고, 출시 직후 애플 앱스토어 전체 인기 순위 1위와 소셜 네트워킹 부문 1위를 동시에 기록했습니다. 현재 평점 4.3, 버전 2.1.4까지 업데이트되었습니다.

작동 방식은 이렇습니다:

1. 친구들과 ‘로그’라는 단체방을 만듭니다 (최대 12명)
2. 매 시간(또는 3시간 간격) 알림이 옵니다
3. 알림이 오면 2~4초 영상을 찍어 올립니다
4. 하루가 끝나면 영상이 자동으로 브이로그로 합성됩니다

이름은 ‘하루를 세팅한다(Set)’ + ‘기록한다(Log)’의 합성어입니다. 원래 3명이 함께한다는 콘셉트(셋=3)로 시작했으나, 업데이트를 거치며 최대 12명까지 확장되었습니다. 2026년 4월 말에는 그동안 기다리던 안드로이드(갤럭시) 베타 출시도 앞두고 있어, 구글 플레이스토어에서 사전 등록이 진행 중입니다.

왜 유행하는가 — 세 가지 이유

1. 인스타 피로감이 한계에 달했다

Z세대 사이에서 “인스타 삭제”는 이미 2024년부터 트렌드였습니다. 스크롤 압박, 비교 심리, 콘텐츠 제작 피로 — 인스타그램이 주던 즐거움보다 스트레스가 커진 것입니다.

한 번 올릴라 치면 이런 과정을 거쳐야 합니다:

• 어디서 찍지?
• 어떤 필터 쓰지?
• 보정은 얼마나?
• 문구는 뭐라 쓰지?
• 해시태그는?
• 좋아요 얼마나 올라가나?

셋로그는 이 모든 단계를 2~4초 찍기 하나로 줄여버렸습니다. 선택의 피로가 사라진 겁니다.

2. ‘꾸밈없음’이 진정성이 된 시대

2020년대 초반까지 SNS의 화두는 ‘어떻게 더 완벽하게 보일 것인가’였습니다. 보정 앱은 필수였고, 릴스·쇼츠는 편집 기술의 경쟁장이었습니다.

근데 2025~2026년, 흐름이 완전히 반대로 갑니다. ‘꾸미지 않은 것’이 오히려 믿을 수 있는 콘텐츠가 되는 시대입니다.

셋로그의 핵심 문장은 이겁니다:

“필터도 편집도 없이, 지금 이 순간만 찍는다.”

이건 셋로그만의 전략이 아닙니다. BeReal(2022년 프랑스)이 ‘하루 한 번, 보정 없이 사진 찍기’로 전 세계 Z세대를 사로잡았고, Locket Widget(2022년 미국)은 홈화면에서 친구에게 바로 사진을 공유하는 방식으로 인기를 끌었습니다. 셋로그는 이 흐름을 영상 기반 + 그룹 공유로 발전시킨 완성형입니다.

3. ‘소수와의 진짜 연결’이 대세다

셋로그는 팔로워도, 공개 프로필도, 탐색 탭도 없습니다. 오직 초대받은 친구들과만 영상을 공유합니다.

이건 우연이 아닙니다. Z세대 SNS 사용 패턴이 이미 이렇게 바뀌었습니다:

카카오톡 방에서 사진 한 장 공유하던 것을, 셋로그는 영상 브이로그로 자동 완성해주는 겁니다. 실제로 사용자들 사이에서 “카톡 + 카카오스토리 합친 느낌”이라는 평이 많습니다.

셋로그 열풍이 보여주는 사회적 시사점

SNS 피로증후군이 현실이 됐다

SNS가 주는 비교 심리, FOMO(놓칠까 두려움), 자아 존중감 하락은 이미 여러 연구에서 입증되었습니다. 특히 10대~20대에서 SNS로 인한 불안·우울 비율이 높게 나옵니다.

셋로그의 유행은 “더 완벽해지고 싶지 않다”는 세대의 집단적 선택으로 읽힙니다. 연출된 삶이 아니라 촬영된 삶, 보정된 얼굴이 아니라 있는 그대로의 얼굴 — 이것이 새로운 가치 기준이 되고 있습니다.

영상 소통이 일상화됐다

셋로그 이전에도 짧은 영상은 있었습니다. 하지만 ‘제작’이 전제된 영상이었습니다. 셋로그는 영상을 텍스트 메시지만큼 가볍게 쓰는 것을 보여줍니다. 사진 한 장 보내듯 3초 영상을 보내는 문화가 정착되고 있습니다.

다음 SNS 전쟁의 신호탄

셋로그 자체가 메가 플랫폼이 될 수도 있고, 아닐 수도 있습니다. 하지만 ‘진정성 기반 SNS’라는 카테고리가 시장에 자리잡았다는 점은 분명합니다.

메타(인스타그램)와 바이트댄스(틱톡)도 이 흐름을 무시할 수 없습니다. 이미 인스타그램이 ‘Close Friends’ 기능을 강화하고, 비공개 계정 사용자가 늘어나는 것도 같은 맥락입니다.

앞으로 전망

자주 묻는 질문 (FAQ)

Q1. 셋로그는 무료인가요?

네, 현재 모든 기능이 무료입니다.

Q2. 갤럭시에서도 쓸 수 있나요?

2026년 4월 말 안드로이드 베타가 출시 예정입니다. 구글 플레이스토어에서 사전 등록 가능합니다.

Q3. 인스타그램이랑 뭐가 다른가요?

가장 큰 차이는 ‘편집 없음’과 ‘공개 없음’입니다. 필터·보정 없이 찍은 대로 올리고, 초대한 친구들만 볼 수 있습니다.

Q4. 왜 2~4초밖에 안 찍나요?

짧은 시간이기 때문에 오히려 꾸밀 수 없습니다. 의도한 연출이 불가능한 길이여서 진짜 ‘지금 이 순간’만 담기게 됩니다.

Q5. BeReal이랑 비슷한가요?

철학은 비슷합니다. 다만 BeReal은 사진 1장, 셋로그는 영상이며 그룹 단위 기록과 자동 브이로그 합성이 차별점입니다.

Q6. 완성된 브이로그를 다른 곳에 올릴 수 있나요?

네, 내보내기 후 인스타 릴스, 틱톡, 유튜브 쇼츠 등에 올릴 수 있습니다. 이것도 하나의 재미 요소입니다.

Q7. 셋로그가 계속 유행할까요?

단기적으로는 안드로이드 출시로 더 커질 겁니다. 장기적으로는 ‘꾸밈없는 소통’이라는 트렌드 자체가 지속될 것이고, 셋로그가 아니어도 이 방향의 서비스는 계속 나올 것입니다.

참고 자료

• 셋로그 App Store
• New Chat Inc. 개인정보 처리방침
• 위키트리 — 셋로그 뜻·찍는법·오류까지…갤럭시 출시 앞두고 관심 급증

이 글은 2026년 4월 25일 기준으로 작성되었습니다.

The post 셋로그 왜 유행함? 인스타 지운 Z세대가 선택한 ‘있는 그대로’ SNS appeared first on .

1. 제9회 국제인공지능대전(AI EXPO KOREA 2026)이 5월 6일~8일 서울 COEX에서 열리며, 알파고 이후 10년을 기념하는 컨퍼런스 ‘Beyond AlphaGo: Our way’가 개최된다
2. 삼성SDS가 AI 에이전트 플랫폼 ‘패브릭스’를 공개하고, AWS는 “2026년은 에이전트의 해”라고 선언하는 등 에이전트 경쟁이 본격화된다
3. 에이프리카·누리에에이아이·베슬에이아이 등 국내 스타트업도 에이전트 인프라, GPU 클라우드, 마케팅 자동화 등 실전 투입 가능한 솔루션을 대거 선보인다

결론부터 말하면

아시아 최대 규모 인공지능 전시회 AI EXPO KOREA 2026이 2026년 5월 6일부터 8일까지 서울 COEX 1층 Hall A에서 개최된다. 올해로 9회째. 18개국 300여 기업·기관이 참가하며, 핵심 화두는 단 하나 — 에이전트(Agent)다.

삼성SDS는 업무 설명만 하면 AI가 알아서 처리하는 ‘패브릭스’를 선보이고, 구글 클라우드는 에이전트 전략으로 AWS·Azure를 추격한다. AWS는 공식적으로 “2026년은 에이전트의 해”라고 선언했다. 국내 스타트업들도 에이전트 인프라, GPU 클라우드, 마케팅 자동화 등 실전 즉시 투입 가능한 솔루션을 쏟아낸다.

AI EXPO KOREA 2026 이란?

AI EXPO KOREA는 아시아 최대 규모의 AI 종합 전시회다. (사)한국인공지능협회와 ㈜서울메쎄가 공동 주최하며, 2026년 5월 6일(수)부터 8일(금)까지 3일간 서울 삼성동 COEX 1층 Hall A 전관에서 개최된다. 올해 9회째로, 전 세계 18개국 300여 기업·기관이 참가한다.

특히 올해는 알파고 이후 10년을 기념하는 메인 컨퍼런스 ‘Beyond AlphaGo: Our way’가 열린다. 화두는 ‘AI 활용국’에서 ‘AI 주권국’으로의 전환. 과거 AI가 “도구”였다면, 2026년의 AI는 “에이전트”다. 스스로 판단하고, 실행하고, 학습하는 자율형 AI가 실무에 투입되는 전환점을 보여주는 행사다.

주목할 AI 에이전트 5선

1. 삼성SDS — 패브릭스 (Fabrix)

삼성SDS는 AI 에이전트 플랫폼 패브릭스를 소개했다. 핵심은 “업무를 설명하면 AI 비서가 알아서 처리”하는 것. 실무형 AI 에이전트 사례를 구체적으로 공개한 점이 인상적이다.

기업의 실제 업무 프로세스에 AI 에이전트를 어떻게 통합하는지, 어떤 성과를 내는지를 실증 자료와 함께 제시했다. 엔터프라이즈 환경에서 AI 도입을 고민하는 기업에게 가장 구체적인 로드맵을 제공한 발표로 평가받는다.

2. 에이프리카 — 비즈니스 최적화 AI 에이전트

에이프리카는 비즈니스 프로세스 최적화에 특화된 AI 에이전트를 공개했다. 기존 RPA(로봇 프로세스 자동화)를 넘어, AI가 스스로 업무 흐름을 분석하고 개선안을 제안하는 수준까지 발전한 것.

3. 누리에에이아이 — VaultSage (에이전트 드라이브)

누리에에이아이는 VaultSage라는 “에이전트 드라이브”를 선보였다. 에이전트 시대에 필요한 전용 인프라를 제공하는 것이 핵심이다. AI 에이전트가 안전하게 데이터에 접근하고, 실행하고, 결과를 저장하는 환경을 제공한다. “에이전트 시대 전용 인프라”를 표방한다.

4. 구글 클라우드 — 에이전트 기반 클라우드 전략

구글 클라우드가 ‘AI 에이전트’를 앞세워 AWS와 Azure를 추격한다. 에이전트가 클라우드 리소스를 스스로 프로비저닝하고, 애플리케이션을 배포하고, 장애를 복구하는 방향으로 발전하고 있다. 클라우드 점유율 3위인 구글이 차별화 전략으로 “에이전트”를 선택한 것은 업계 파급력이 크다.

5. AWS — “2026년은 에이전트의 해”

AWS는 공식적으로 “2026년은 에이전트의 해”라고 선언했다. AI 경쟁이 모델 성능에서 데이터·실행 역량으로 재편되고 있다는 분석이다. 가장 강력한 클라우드 인프라를 가진 AWS가 에이전트에 올인하겠다는 것은, 에이전트가 클라우드 시장의 다음 전장임을 확인하는 것이다.

국내 스타트업 — 실전 즉시 투입 가능한 솔루션

빅테크뿐 아니라 국내 스타트업도 파격적이다.

왜 2026년이 에이전트의 해인가

2025년까지 AI는 “질문에 답하는 도구”였다. ChatGPT에게 물어보고, Claude에게 코드를 짜달라고 하고, Gemini에게 요약을 맡기는 식이었다.

2026년은 다르다. AI가 스스로 판단하고 실행한다.

• 삼성SDS 패브릭스: 업무를 설명하면 AI가 알아서 처리
• 에이프리카: 비즈니스 프로세스를 AI가 분석·최적화
• 누리에에이아이 VaultSage: 에이전트 전용 인프라 제공
• 보다파크 AI: 마케팅을 AI가 자동으로 기획·실행

“AI가 추천해준다”에서 “AI가 대신 해준다”로의 전환이다. 그리고 이 전환은 이미 시작됐다.

일반인에게 의미 있는 것은?

“에이전트”라는 단어가 기업용처럼 들리지만, 이미 일상에 스며들고 있다.

• 갤럭시 S26에 탑재된 퍼플렉시티 AI 에이전트: 스마트폰에서 AI가 앱을 직접 조작
• GPT-5.4: 컴퓨터를 직접 조작하는 AI (이전 포스팅 참고)
• 마케팅 자동화: 보다파크 AI처럼 개인도 마케팅을 AI에게 맡길 수 있다

에이전트 시대의 수혜자는 대기업만이 아니다. 개인과 소상공인도 AI 에이전트를 활용해 업무 효율을 극대화할 수 있다.

자주 묻는 질문 (FAQ)

Q. AI EXPO KOREA 2026은 언제, 어디서 열리나요?

A. 2026년 5월 6일(수)~8일(금), 서울 삼성동 COEX 1층 Hall A에서 열린다. 3일간 진행된다.

Q. 일반인도 참관할 수 있나요?

A. 가능하다. 사전 등록을 통해 무료 참관이 가능하며, 일부 컨퍼런스는 별도 결제가 필요하다. 공식 사이트(aiexpo.co.kr)에서 사전 등록할 수 있다.

Q. “에이전트”가 기존 AI와 뭐가 다른가요?

A. 기존 AI는 질문에 답하는 “도구”였다면, 에이전트는 스스로 판단하고 실행하는 “자율형 AI”다. 예를 들어, 기존 AI는 “이메일 초안을 작성해줘”에 반응하지만, 에이전트는 “오늘 회의 내용을 정리해서 참석자에게 이메일을 보내줘”를 스스로 수행한다.

Q. 소상공인도 AI 에이전트를 쓸 수 있나요?

A. 가능하다. 보다파크 AI 같은 마케팅 자동화 에이전트는 소상공인도 바로 활용할 수 있다. 비용도 월 구독 수준으로 합리적이다.

Q. 한국 AI 기술 수준은 어느 정도인가요?

A. AI 활용 분야에서는 세계 최고 수준이다. 이번 엑스포에서 공개되는 국내 스타트업 솔루션들은 글로벌 경쟁력을 갖추고 있다. 다만 기초 모델 개발에서는 미국 기업이 여전히 앞서 있다.

Q. AI 에이전트가 내 일자리를 위협하나요?

A. 단기적으로는 “대체”보다 “보조”에 가깝다. 반복적이고 규칙적인 업무는 에이전트가 대신하지만, 창의적 판단과 전략적 의사결정은 여전히 사람의 영역이다. 다만 에이전트를 다룰 줄 아는 사람과 모르는 사람의 격차는 빠르게 벌어질 것이다.

참고 자료

• AI EXPO KOREA 2026 공식 사이트
• 한국인공지능협회 행사 페이지
• 인공지능신문 — AI EXPO KOREA 2026 개최 안내
• 전자신문 — 삼성SDS 패브릭스 소개
• 조선비즈 — 구글 클라우드 에이전트 전략
• 테크월드 — AWS 에이전트 선언

이 글은 2026년 4월 22일 기준으로 작성되었습니다. AI EXPO KOREA 2026은 5월 6일 개막 예정이며, 행사 기간 중 추가 소식은 후속 포스팅에서 다룹니다.

The post AI EXPO KOREA 2026 총정리 — 알파고 이후 10년, 에이전트 시대의 도래 appeared first on .

1. Claude Code는 정확도와 프로젝트 이해력 1위, Gemini CLI는 무료 1,000회/일로 진입장벽 제로, Codex는 샌드박스 격리로 안전성 최강
2. SWE-bench 기준 Claude Opus 4.6(80.8%)과 Gemini 3.1 Pro(80.6%)가 거의 동급, 실사용 체감은 Claude Code가 한 수 위
3. 하나만 고를 필요 없다 — 탐색은 Gemini CLI, 본격 개발은 Claude Code, 자동화는 Codex로 조합하는 게 최적

결론부터 말하면

세 도구를 수개월간 실무에서 돌려본 결론은 명확하다. 복잡한 프로젝트를 맡길 땐 Claude Code, 빠른 실험과 탐색은 Gemini CLI, 안전한 자동화 파이프라인은 Codex. 만능은 없다. 각자 철학이 다르고, 그 철학이 실사용에서 고스란히 드러난다.

왜 지금 CLI 에이전트인가

Cursor, Windsurf 같은 IDE 기반 도구와 달리, CLI 에이전트는 터미널에서 직접 돌아간다. GUI가 없다. 그 대신 프로젝트 전체를 읽고, 파일을 수정하고, 테스트를 실행하고, 결과를 보고 스스로 수정한다.

2025년까지는 “자동완성 잘 되는 IDE”가 주류였다면, 2026년은 “시키면 알아서 하는 에이전트”의 시대다. GitHub Copilot도 Agent Mode를 추가했고, Cursor도 Background Agent를 출시했다. 업계 전체가 에이전트로 수렴하고 있다.

그 중심에 있는 3대 CLI 에이전트를 직접 비교한다.

Claude Code — 일 잘하는 시니어 개발자

Anthropic이 만든 Claude Code는 현재 개발자 점유율 46%로 1위를 달리고 있다. Cursor(19%), GitHub Copilot(9%)을 큰 차이로 앞선다.

실사용 체감

처음 쓰면 좀 느리다는 인상을 받는다. 다른 도구들이 바로 코드를 뱉어내는 것과 달리, Claude Code는 먼저 프로젝트 구조를 파악한다. CLAUDE.md를 읽고, 디렉토리를 탐색하고, 기존 패턴을 학습한 다음에야 코드를 작성한다.

그 대신 결과물의 정확도가 확실히 다르다. 기존 코드 스타일을 따르고, 파일 간 의존성을 이해하고, 변경 사항이 다른 부분에 미치는 영향까지 고려한다. 대규모 리팩토링에서 이 차이가 극명하게 드러난다.

강점

시맨틱 프로젝트 그래프: Claude Code는 프로젝트의 의미 구조를 파악하는 내부 그래프를 구축한다. 덕분에 1M 토큰 컨텍스트를 다 채우지 않아도 관련 파일만 정확히 찾아낸다. “이 함수를 수정하면 어디가 영향받지?” 같은 질문에 정확히 답할 수 있는 이유다.
멀티 에이전트 워크플로우: 서브 에이전트를 병렬로 띄워서 독립적인 작업을 동시에 처리할 수 있다. PR 리뷰를 맡기면 보안, 성능, 코드 스타일을 각각 다른 에이전트가 검토한다.
프롬프트 캐싱: 세션 내에서 시스템 프롬프트와 프로젝트 컨텍스트가 캐싱되어 입력 비용이 80~90% 절감된다. API로 쓸 때 비용 차이가 크다.

단점

무료 티어 없음. 최소 Pro $20/월이 필요하다. 그마저도 Opus 4.6를 많이 쓰면 며칠 만에 한도에 걸린다. 제대로 쓰려면 Max $100/월은 각오해야 한다.
독점 소스. 내부에서 무슨 일이 일어나는지 볼 수 없다. 엔터프라이즈 환경에서 보안 감사가 필요한 경우 걸림돌이 된다.
변경 전 매번 확인 요청. 안전하지만 느리다. 자동 승인 모드가 있긴 하지만, 처음 쓰는 프로젝트에서는 일일이 확인하게 된다.

Codex — 안전 제일주의자

OpenAI의 Codex는 철학부터 다르다. 모든 코드 실행을 샌드박스 안에서 한다. 실수로 프로덕션 DB를 날릴 걱정이 없다는 뜻이다.

실사용 체감

Codex에 작업을 던지면 레포를 클론해서 격리된 환경에 넣고, 거기서 파일을 수정하고 테스트를 돌린다. 완료되면 diff를 보여주고, 사용자가 확인한 후에 반영된다.

안전하다. 확실히 안전하다. 하지만 이 안전함이 속도를 먹는다. 매번 샌드박스를 띄우고 환경을 세팅하는 오버헤드가 있다. 빠른 반복 작업에는 답답함을 느낄 수 있다.

강점

OS 수준 샌드박스: macOS에서는 Apple의 Seatbelt 프레임워크, Linux에서는 Landlock과 seccomp을 사용한다. 읽기 전용(suggest), 작업공간 쓰기(기본), 전체 접근(danger) 세 단계의 권한 모델이 있다. CI/CD 파이프라인에 통합하기 좋은 구조다.
오픈소스(Apache 2.0): 코드를 직접 읽고, 포크하고, 기여할 수 있다.
ChatGPT 생태계 통합: ChatGPT Plus/Pro 구독만 있으면 별도 설정 없이 바로 쓸 수 있다. 웹 UI에서 작업을 시작하고 CLI에서 이어가는 것도 가능하다.

단점

컨텍스트 윈도우가 상대적으로 작다. 192K~400K 토큰으로, Claude Code와 Gemini CLI의 1M에 비하면 절반 이하다. 대형 모노레포에서는 프로젝트 전체를 한 번에 파악하지 못한다.
품질 저하 보고. OpenAI 커뮤니티 포럼에서 “Codex is rapidly degrading”이라는 스레드가 주목받았다. 최근 몇 주간 출력 품질이 떨어졌다는 다수의 개발자 보고가 있다. 존재하지 않는 동시성 버그를 잡아냈다고 했는데 30분 확인해보니 환각(hallucination)이었다는 사례도 있다.
샌드박스 우회 이력. v0.106.0에서 zsh 샌드박스 우회 취약점이 패치됐다. 보안이 핵심 셀링포인트인 도구에서 이런 이력은 신뢰에 금이 간다.

Gemini CLI — 파격적인 무료 플레이어

Google이 오픈소스로 공개한 Gemini CLI는 무료로 하루 1,000회 요청이 가능하다. 신용카드 등록도 필요 없다. 개인 Google 계정만 있으면 된다.

실사용 체감

처음 써보면 “이게 진짜 무료?”라는 생각이 든다. Gemini 3.1 Pro와 1M 토큰 컨텍스트가 무료로 풀려있다. 설치도 npm install -g @anthropic-ai/claude-code… 가 아니라 npm install -g @google/gemini-cli 한 줄이면 끝이다.

v0.34.0부터 Plan Mode가 기본이다. 코드를 바로 수정하지 않고, 먼저 코드베이스를 읽고 변경 계획을 제안한다. 계획을 확인한 후에야 실행으로 넘어간다. 안전하면서도 Codex처럼 샌드박스 오버헤드가 없다.

강점

파격적 무료 티어: 60회/분, 1,000회/일. 대부분의 개인 개발자는 이 한도 안에서 충분히 쓸 수 있다. 유료 전환 없이도 실전 프로젝트에 투입 가능한 수준이다.
Google Search grounding: 다른 CLI 에이전트에 없는 기능이다. 코딩 중에 최신 라이브러리 문서나 API 변경 사항을 실시간으로 검색해서 반영한다. 빠르게 변하는 프레임워크를 다룰 때 유용하다.
1M 컨텍스트 + 오픈소스: Claude Code와 동일한 1M 토큰이면서, 소스 코드가 공개되어 있다. 엔터프라이즈에서 보안 감사를 통과해야 할 때 큰 장점이다.
MCP(Model Context Protocol) 지원: 커스텀 도구를 MCP 서버로 연결해서 확장할 수 있다. 사내 API, DB, 모니터링 도구 등을 에이전트가 직접 호출하도록 설정 가능하다.

단점

자율 실행 능력은 Claude Code에 미치지 못한다. 복잡한 멀티파일 리팩토링에서 간혹 엉뚱한 파일을 수정하거나, 기존 코드 패턴을 무시하는 경우가 있다. Claude Code가 프로젝트 구조를 의미적으로 이해하는 것과 대조된다.
컨텍스트 활용 방식. 1M 토큰이라는 거대한 창문이 있지만, 어떤 파일에 집중해야 하는지는 개발자가 명시적으로 알려줘야 할 때가 많다. 창문은 크지만 초점이 흐릴 수 있다.
무료 티어의 함정. 1,000회가 많아 보이지만, 에이전트가 내부적으로 여러 번 API를 호출하기 때문에 복잡한 작업 몇 개면 소진될 수 있다. 실질적으로는 하루 중간 규모 작업 10~15건 정도다.

비용 비교 — 월 얼마나 드나

구독 기준

API 토큰 기준 (100만 토큰당)

토큰 단가만 보면 Gemini가 가장 저렴하다. 하지만 Claude Code의 프롬프트 캐싱(80~90% 절감)을 고려하면 실사용 비용 차이는 줄어든다.

현실적인 월 비용 시나리오

취미 개발자 (주 5~10시간 코딩): Gemini CLI 무료 티어로 충분하다. 비용 $0.
풀타임 개발자 (주 30시간+): Claude Code Max 5x $100/월이 가성비가 좋다. Codex Pro $200/월은 같은 돈 대비 쓸 수 있는 양이 적다.
팀/회사: API 기반으로 가는 게 낫다. Gemini 3.1 Pro가 토큰 단가 최저, Claude Code가 품질 최고. 작업 유형에 따라 라우팅하는 팀이 늘고 있다.

벤치마크 — 숫자로 보는 성능

SWE-bench Verified는 실제 GitHub 이슈를 해결하는 능력을 측정한다. Claude와 Gemini가 0.2%p 차이로 거의 동급이다. 반면 Codex는 터미널 자동화(Terminal-Bench)에서 강세를 보인다. 추상적 추론(ARC-AGI-2)은 Gemini가 압도적이다.

벤치마크 점수가 비슷하다고 체감이 같은 건 아니다. 실무에서는 프로젝트 맥락을 얼마나 잘 이해하느냐, 첫 시도에 동작하는 코드를 내놓느냐가 더 중요하다. 이 부분에서는 Claude Code가 아직 한 수 위라는 게 다수의 의견이다.

어떤 상황에서 어떤 도구를 쓸까

Claude Code가 맞는 경우

• 대규모 코드베이스 리팩토링
• 기존 프로젝트의 아키텍처를 이해하고 수정해야 할 때
• 코드 리뷰 자동화가 필요할 때
• “한 번에 제대로 동작하는 코드”가 중요할 때
• 비용보다 품질이 우선인 프로젝트

Codex가 맞는 경우

• CI/CD 파이프라인에 AI를 통합할 때
• 프로덕션 환경에서 절대 사고가 나면 안 될 때
• 이미 ChatGPT Pro를 쓰고 있을 때
• 웹 UI → CLI 전환이 자연스러운 워크플로우를 원할 때

Gemini CLI가 맞는 경우

• AI 코딩 에이전트를 처음 써보는 경우 (무료 진입)
• 빠른 프로토타이핑과 탐색이 목적일 때
• 최신 라이브러리/API 문서가 필요한 작업 (Search grounding)
• 오픈소스 + 보안 감사가 필수인 엔터프라이즈 환경
• 비용에 민감한 개인 개발자나 학생

실전 팁 — 같이 쓰면 더 좋다

세 도구 중 하나만 고르라는 법은 없다. 실제로 2026년 개발자들 사이에서는 2~3개를 작업 유형별로 나눠 쓰는 패턴이 자리잡고 있다.

추천 조합:

• 탐색/프로토타이핑: Gemini CLI (무료 + Search grounding)
• 본격 개발/리팩토링: Claude Code (정확도 + 프로젝트 이해)
• 배포/자동화: Codex (샌드박스 안전성)

이렇게 쓰면 Gemini CLI로 비용을 아끼면서, 핵심 작업은 Claude Code의 품질로 처리하고, 자동화 파이프라인은 Codex의 안전망 위에서 돌릴 수 있다.

자주 묻는 질문 (FAQ)

Q. 비개발자도 쓸 수 있나?

A. 세 도구 모두 터미널 기반이라 CLI에 익숙하지 않으면 진입 장벽이 있다. 비개발자라면 Cursor나 Windsurf 같은 IDE 기반 도구가 더 적합하다.

Q. 셋 중 하나만 골라야 한다면?

A. 돈을 쓸 수 있다면 Claude Code. 무료로 시작하고 싶다면 Gemini CLI. 안전이 최우선이면 Codex.

Q. 한국어 코드 주석이나 문서 작성은 잘 되나?

A. Claude Code가 한국어 처리에서 가장 자연스럽다. Gemini CLI도 무난한 수준. Codex는 영어 중심으로 최적화되어 있어 한국어 주석 품질이 상대적으로 떨어진다.

Q. 기존 IDE(VS Code 등)와 같이 쓸 수 있나?

A. 세 도구 모두 터미널에서 독립적으로 동작하므로 어떤 IDE와도 병행 가능하다. Claude Code와 Codex는 VS Code 확장도 지원한다.

참고 자료

• Claude Code 공식 문서
• OpenAI Codex 개발자 문서
• Gemini CLI GitHub 저장소
• SWE-bench Verified 리더보드
• AI Coding Benchmarks 2026 (byteiota)

이 글은 2026년 3월 기준 정보입니다. AI 코딩 에이전트는 빠르게 업데이트되므로, 각 도구의 공식 문서에서 최신 정보를 확인하세요.

The post AI 코딩 에이전트 비교 – Claude Code vs Codex vs Gemini CLI, 뭐가 다를까? appeared first on .

1. ZeroClaw는 Rust 기반 3.4MB 바이너리로, OpenClaw 대비 메모리 200배 적게 사용하며 라즈베리 파이에서도 구동된다.
2. OpenClaw에서 원클릭 원격 코드 실행(CVE-2026-25253) 등 심각한 보안 취약점이 연달아 발견되면서 경량 대안에 대한 수요가 폭증했다.
3. 둘은 대체재가 아닌 보완재로, 맥미니에서 동시 실행하면 OpenClaw의 풍부한 기능 + ZeroClaw의 가벼운 자동화를 함께 쓸 수 있다.

결론부터 말하면

ZeroClaw는 OpenClaw의 경량 대안이 아니다. 완전히 다른 설계 철학을 가진 별개의 도구다.

• OpenClaw: 풍부한 기능, 거대한 생태계, 하지만 무겁고 최근 심각한 보안 취약점 노출
• ZeroClaw: 3.4MB 바이너리 하나로 끝. 메모리 5MB, 부팅 10ms. 라즈베리 파이에서도 돌아감

맥미니로 OpenClaw 서버를 구축한 사람이라면, ZeroClaw가 왜 한 달 만에 GitHub 28,000 스타를 찍었는지 이해할 수 있을 것이다.

핵심 스펙 비교

메모리 사용량 차이가 압도적이다. OpenClaw 1GB vs ZeroClaw 5MB, 200배 차이. 맥미니 M4 16GB에서 OpenClaw를 돌리면 시스템 리소스의 6%를 에이전트 런타임이 잡아먹지만, ZeroClaw는 0.03%만 사용한다. 나머지를 전부 LLM 추론에 쓸 수 있다는 뜻이다.

OpenClaw의 보안 위기

2026년 초, OpenClaw에서 연달아 심각한 보안 취약점이 발견됐다.

CVE-2026-25253 (원클릭 원격 코드 실행, CVSS 8.8)

OpenClaw Control UI가 URL 파라미터의 gatewayUrl을 검증 없이 신뢰하고 자동 연결하는 문제. 악성 웹페이지를 한 번 클릭하는 것만으로 공격자가 피해자의 인증 토큰을 탈취하고, 시스템을 완전히 장악할 수 있었다. 2026년 2월 3일 공개 시점에 인터넷에 노출된 OpenClaw 인스턴스가 40,000개 이상, 이 중 63%가 취약한 상태였다.

CVE-2026-26327 (인증 우회)

mDNS/DNS-SD 서비스 디스커버리의 인증되지 않은 TXT 레코드를 신뢰하는 문제. 같은 네트워크에 있는 공격자가 자격증명을 가로챌 수 있다. 카페 와이파이, 코워킹 스페이스 같은 공유 네트워크에서 특히 위험하다.

두 취약점 모두 v2026.1.29에서 패치됐지만, 이 사건은 TypeScript 기반 대형 코드베이스의 공격 표면이 얼마나 넓은지를 보여줬다.

ZeroClaw의 보안 접근: 명시적 허가 기반. 작업 디렉토리 제한, 명령어 허용목록, 암호화된 시크릿, 페어링 인증. 공격 표면 자체를 최소화하는 설계다.

ZeroClaw가 빠른 이유

Rust라서 빠른 게 아니다. 불필요한 것을 전부 뺐기 때문에 빠르다.

OpenClaw는 “할 수 있는 모든 것”을 담았다. 웹 UI, 플러그인 마켓, 다중 에이전트, 메시징 통합, 대시보드. 풍부하지만 무겁다.

ZeroClaw는 반대 방향을 택했다. AI 에이전트가 실제로 필요한 것만 남겼다.

• LLM 호출: OpenAI, Anthropic, Ollama 등 22개 프로바이더 네이티브 지원
• 도구 실행: 셸, 브라우저, 파일 시스템
• 메모리: 자체 벡터 검색 엔진 내장 (Pinecone, Elasticsearch 불필요)
• 채널: CLI, HTTP, WebSocket

이게 전부다. 웹 UI도 없고, 플러그인 마켓도 없다. 대신 3.4MB로 끝난다.

어떤 사람에게 맞는가

OpenClaw가 맞는 경우

• ClawHub 플러그인 생태계가 필요하다
• 웹 UI로 시각적으로 관리하고 싶다
• 여러 명이 사용하는 팀 환경이다
• 이미 OpenClaw에 투자한 시간이 많다

ZeroClaw가 맞는 경우

• 라즈베리 파이, NAS 같은 저전력 기기에서 에이전트를 돌리고 싶다
• 맥미니의 메모리를 LLM에 최대한 할당하고 싶다
• 보안이 최우선이다 (금융, 의료 등)
• SSH로 서버에 바이너리 하나 올리고 끝내고 싶다
• 항상 켜져 있는 백그라운드 에이전트가 필요하다

맥미니 사용자라면

맥미니 M4로 OpenClaw를 구축한 사람이 가장 많이 묻는 질문이 있다.

“ZeroClaw로 갈아타야 하나?”

정답은 “둘 다 쓰면 된다”다.

ZeroClaw는 5MB밖에 안 쓴다. OpenClaw와 동시에 돌려도 부담이 없다. 실제로 이런 조합이 가능하다.

• OpenClaw: 메인 에이전트. 텔레그램/디스코드 연동, ClawHub 플러그인 활용
• ZeroClaw: 보조 에이전트. 파일 모니터링, cron 기반 자동화, 보안이 중요한 작업

16GB 맥미니 기준, OpenClaw(1GB) + ZeroClaw(5MB) + Ollama(10~12GB) = 충분히 돌아간다.

설치 비교

OpenClaw:

# Docker 기반 (권장)
docker pull openclaw/openclaw
docker run -d -p 3100:3100 openclaw/openclaw

의존성: Docker, Node.js 런타임, 수백 MB 이미지

ZeroClaw:

# 바이너리 다운로드 한 줄
curl -fsSL https://get.zeroclaw.net | sh
zeroclaw pair

의존성: 없음. 바이너리 하나가 전부.

성능 요약

전망

OpenClaw는 300,000 스타의 거대한 생태계를 가지고 있다. 당장 사라지지 않는다. 하지만 보안 사고가 연이어 터지면서 기업 환경에서의 신뢰가 흔들리고 있다.

ZeroClaw는 출시 한 달 만에 28,000 스타를 찍으며 “작은 것이 아름답다”를 증명했다. Rust의 메모리 안전성과 최소주의 설계가 보안에 민감한 사용자를 빠르게 흡수하고 있다.

로컬 AI 에이전트 시장은 이제 “기능이 많은 것” vs “가볍고 안전한 것”으로 갈라지고 있다. 맥미니 대란으로 시작된 개인 AI 서버 시대가, 이제 소프트웨어 선택의 시대로 넘어가고 있다.

참고 자료

• ZeroClaw 공식 사이트
• ZeroClaw vs OpenClaw 공식 비교
• OpenClaw RCE 취약점 분석 (CVE-2026-25253)
• OpenClaw 인증 우회 취약점 (CVE-2026-26327)
• 2026 AI 에이전트 프레임워크 종합 비교
• ZeroClaw + Ollama 5분 설치 가이드

이 글은 2026년 3월 21일 기준으로 작성되었습니다. 오픈소스 프로젝트 특성상 기능과 스펙은 빠르게 변경될 수 있습니다.

The post ZeroClaw vs OpenClaw 전격 비교 – 3.4MB Rust의 도전장 appeared first on .

1. Temporal API가 TC39 Stage 4에 도달하며 ES2026 표준에 정식 포함된다. ECMAScript 역사상 가장 큰 단일 추가(약 4,500개 테스트)다.
2. 30년간 개발자를 괴롭혀 온 Date 객체의 가변성, 0-based 월, 타임존 미지원 문제를 근본적으로 해결한다.
3. Chrome 144, Firefox 139, Edge 144에서 이미 사용 가능하며, Temporal.PlainDate, Temporal.ZonedDateTime 등 용도별 8개 타입을 제공한다.

결론부터 말하면

JavaScript의 Date 객체는 1995년 Java에서 급하게 포팅된 이후 30년간 변하지 않았다. Temporal API는 불변 객체, IANA 타임존 네이티브 지원, 나노초 정밀도, 용도별 분리된 타입을 제공하며 이 문제를 완전히 해결한다. 2026년 3월 Stage 4에 도달했고, 주요 브라우저에서 이미 지원 중이다.

Temporal API란?

Temporal은 JavaScript의 Date 객체를 대체하기 위해 설계된 새로운 날짜/시간 API다. TC39(ECMAScript 표준 위원회)에서 2017년 Stage 1으로 시작해 9년간 개발되었으며, 2026년 3월 Stage 4에 도달하면서 ES2026 표준에 포함이 확정됐다.

Date 객체 하나로 모든 날짜/시간 개념을 처리하던 기존 방식 대신, Temporal은 상황에 맞는 8개의 독립된 타입을 제공한다. 모든 객체는 불변(immutable)이며, 시간대 처리가 내장되어 있다.

Bloomberg, Google, Mozilla, Microsoft, Igalia 등이 공동으로 개발에 참여했으며, Test262 기준 약 4,500개의 테스트가 추가되어 ECMAScript 역사상 가장 큰 규모의 기능 추가다.

기존 Date 객체의 문제점

Date가 왜 교체 대상이 되었는지 구체적으로 살펴보자.

가변성(Mutability)

const meeting = new Date(2026, 2, 15, 14, 0); // 3월 15일

scheduleMeeting(meeting);

// meeting 객체가 함수 내부에서 변경되었을 수 있다
console.log(meeting); // 예측 불가

Date 객체는 setMonth(), setDate() 등으로 원본이 직접 변경된다. 여러 곳에서 같은 객체를 참조하면 의도치 않은 버그가 발생한다.

0-based 월 인덱싱

new Date(2026, 0, 1);  // 1월 1일 (0 = 1월)
new Date(2026, 11, 1); // 12월 1일 (11 = 12월)

1월이 0이고 12월이 11이다. 이 설계는 off-by-one 에러의 대표적 원인이다.

브라우저별 파싱 차이

new Date("2026-01-01"); // 어떤 브라우저는 UTC로, 다른 브라우저는 로컬 시간으로 해석

같은 문자열이 환경에 따라 다른 결과를 반환한다. 날짜 문자열 파싱 규칙이 명확하지 않기 때문이다.

타임존 지원 부재

const date = new Date();
date.getTimezoneOffset(); // 오프셋만 반환, IANA 타임존 이름은 없음

Date는 타임존이 아닌 오프셋만 지원한다. “Asia/Seoul”이나 “America/New_York” 같은 IANA 타임존을 다룰 방법이 없다. DST(서머타임) 전환도 제대로 처리하지 못한다.

날짜 전용 타입 없음

생일처럼 시간 정보가 불필요한 경우에도 Date는 항상 시간과 타임존 정보를 포함한다. “3월 15일”이라는 단순한 날짜를 표현할 깔끔한 방법이 없다.

Temporal의 8가지 타입

Temporal은 용도에 따라 정확한 타입을 선택해서 사용한다.

핵심 코드 예시

PlainDate — 시간대 없는 날짜

// 생성
const birthday = Temporal.PlainDate.from("2026-03-15");
const today = Temporal.Now.plainDateISO();

// 불변 연산 — 원본은 변하지 않는다
const nextWeek = today.add({ days: 7 });
console.log(today.toString()); // 원본 그대로
console.log(nextWeek.toString()); // 7일 후

// 두 날짜 사이의 간격
const diff = today.until(birthday);
console.log(diff.days); // 남은 일수

ZonedDateTime — 타임존 포함 날짜/시간

// 서울과 뉴욕의 같은 '순간'
const seoul = Temporal.ZonedDateTime.from(
  "2026-03-15T09:00:00+09:00[Asia/Seoul]"
);

const newYork = seoul.withTimeZone("America/New_York");

console.log(seoul.toString()); // "2026-03-15T09:00:00+09:00[Asia/Seoul]"
console.log(newYork.toString()); // "2026-03-14T19:00:00-05:00[America/New_York]"

// DST 자동 처리
const london = Temporal.ZonedDateTime.from(
  "2026-03-29T00:30:00+00:00[Europe/London]"
);

const plus1h = london.add({ hours: 1 }); // "2026-03-29T02:30:00+01:00[Europe/London]"
// 01:30은 DST 전환으로 존재하지 않으므로 자동 건너뜀

Instant — 절대 시점

// 서버 이벤트 기록
const eventTime = Temporal.Now.instant();
console.log(eventTime.epochMilliseconds); // Unix 타임스탬프 (ms)

// 특정 시점을 각 시간대로 변환
const instant = Temporal.Instant.from("2026-03-15T00:00:00Z");
const inSeoul = instant.toZonedDateTimeISO("Asia/Seoul");
const inTokyo = instant.toZonedDateTimeISO("Asia/Tokyo");
console.log(inSeoul.hour); // 9 (UTC+9)
console.log(inTokyo.hour); // 9 (UTC+9)

Duration — 시간 간격 계산

const projectStart = Temporal.PlainDate.from("2026-01-10");
const deadline = Temporal.PlainDate.from("2026-03-31");
const remaining = projectStart.until(deadline);

console.log(remaining.toString()); // "P80D" (80일)

// Duration을 다른 단위로 변환
const duration = Temporal.Duration.from({ hours: 130, minutes: 20 });

console.log(duration.total({ unit: "second" })); // 469200

Date vs Temporal 비교

브라우저 지원 현황 (2026년 3월 기준)

Safari를 제외한 주요 브라우저에서 이미 사용 가능하다. Safari도 Technology Preview에서 테스트할 수 있으며, 정식 지원은 2026년 내 예상된다.

프로덕션 환경에서 모든 브라우저를 지원해야 한다면 @js-temporal/polyfill 또는 temporal-polyfill을 사용할 수 있다.

npm install @js-temporal/polyfill

import { Temporal } from "@js-temporal/polyfill";

const now = Temporal.Now.plainDateISO();

console.log(now.toString()); // 폴리필로 모든 환경에서 동일하게 동작

기존 코드 마이그레이션 가이드

Date에서 Temporal로 전환할 때 자주 쓰는 패턴을 정리했다.

// (Before) Date — 현재 날짜
const today = new Date();
const year = today.getFullYear();
const month = today.getMonth() + 1; // 0-based 보정 필요

// (After) Temporal — 현재 날짜
const today = Temporal.Now.plainDateISO();
const year = today.year;
const month = today.month; // 1-based, 보정 불필요

// (Before) Date — 날짜 비교
const d1 = new Date("2026-03-15");
const d2 = new Date("2026-04-01");
const diffMs = d2 - d1;
const diffDays = Math.floor(diffMs / (1000  60  60 * 24)); // 직접 계산

// (After) Temporal — 날짜 비교
const d1 = Temporal.PlainDate.from("2026-03-15");
const d2 = Temporal.PlainDate.from("2026-04-01");
const diff = d1.until(d2);

console.log(diff.days); // 17 — 내장 메서드로 바로 계산

// (Before) Date — 타임존 변환
// 외부 라이브러리(moment-timezone, date-fns-tz) 필수

// (After) Temporal — 타임존 변환
// 외부 라이브러리 없이 네이티브로 처리
const seoul = Temporal.Now.zonedDateTimeISO("Asia/Seoul");
const london = seoul.withTimeZone("Europe/London");

Moment.js, date-fns는 이제 필요 없나?

State of JS 조사에서 날짜 처리는 “정적 타입 부족” 다음으로 두 번째 고통 포인트로 꼽혔다. 이 문제를 해결하기 위해 Moment.js(2011), date-fns, Luxon 같은 라이브러리가 등장했고, 현재 npm에서 주당 8천만 다운로드를 기록하고 있다.

Temporal이 표준화되면서 이 라이브러리들의 핵심 기능(타임존 처리, 불변 연산, 포매팅)이 네이티브로 대체된다. 다만 Moment.js의 상대 시간 표현(3일 전)이나 date-fns의 풍부한 유틸리티 함수처럼 Temporal이 직접 제공하지 않는 편의 기능도 있다.

당장 기존 프로젝트의 라이브러리를 걷어낼 필요는 없지만, 새 프로젝트에서는 Temporal 네이티브로 시작하는 것이 번들 크기와 유지보수 측면에서 유리하다.

9년의 여정 — 주요 마일스톤

Bloomberg의 금융 시스템에서 나노초 단위의 시간 정밀도와 IANA 타임존 지원이 필요했던 것이 Temporal 개발의 핵심 동력이었다. Bloomberg 엔지니어 Philipp Dunkel이 스펙 챔피언을, Jason Williams가 TC39 위원으로 표준화를 이끌었다.

참고 자료

• Temporal: The 9-Year Journey to Fix Time in JavaScript — Bloomberg Engineering
• Temporal — MDN Web Docs
• TC39 Proposal: Temporal
• Temporal API — Can I Use
• ES2026 Solves JavaScript Headaches — The New Stack

The post JavaScript Temporal API – 9년 만에 Date를 대체하는 새 표준 appeared first on .

지난 2월, GPT-5.2와 Claude Opus 4.5, Gemini 3 Pro를 비교한 글을 올렸다. 한 달밖에 안 지났는데 세 회사 모두 신모델을 쏟아냈다. AI 업계의 속도가 이 정도다.

OpenAI는 3월 5일 GPT-5.4를 공개하며 컴퓨터 사용과 1M 컨텍스트를 내장했다. Anthropic은 2월에 Claude Opus 4.6과 Sonnet 4.6을 연달아 출시한 데 이어, 3월 13일 두 모델 모두 1M 컨텍스트를 추가 비용 없이 정식(GA) 지원하기 시작했다. Google은 Gemini 3 Flash에 이어 3.1 Pro까지 출시하며 추론 성능을 대폭 끌어올렸다.

이 글에서는 2026년 3월 16일 기준, 세 진영의 최신 모델을 벤치마크 데이터와 실제 사용 경험을 바탕으로 비교한다.

3줄 요약

1. GPT-5.4는 AIME 100%, OSWorld 75%, 1M 토큰 컨텍스트 + 컴퓨터 사용까지 지원하며 범용 AI 에이전트로 진화했다
2. Claude Opus 4.6은 SWE-bench 80.8%로 코딩 최강을 유지하면서 1M 컨텍스트를 정식 지원(GA)하기 시작했고, Sonnet 4.6이 79.6%로 거의 동급 성능을 1/5 가격에 제공한다
3. Gemini 3.1 Pro가 ARC-AGI-2 77.1%, GPQA 94.3%로 18개 벤치마크 중 12개 1위를 차지하며 추론 성능의 새 기준을 세웠다

비교 대상 모델

2월 대비 무엇이 달라졌나

불과 한 달 사이에 일어난 주요 변화를 먼저 짚어본다.

OpenAI: GPT-5.2 → GPT-5.3 → GPT-5.4로 한 달에 두 번 업데이트. 컨텍스트가 400K에서 1M으로 확대됐고, 네이티브 컴퓨터 사용 기능이 추가됐다. OSWorld 점수가 47.3%에서 75%로 껑충 뛰며 인간 평균(72.4%)을 넘었다.
Anthropic: Claude 4.5에서 4.6 세대로 업그레이드. Opus 4.6은 METR 기준 14시간 30분 연속 작업이 가능한 에이전트가 됐다. 가장 큰 변화는 Sonnet 4.6의 등장으로, Opus에 거의 근접한 코딩 성능을 1/5 가격에 제공한다. 3월 13일에는 Opus 4.6과 Sonnet 4.6 모두 1M 컨텍스트를 추가 비용 없이 정식(GA) 지원하기 시작했다. MRCR v2에서 76%(8개 needle, 1M 토큰)를 기록하며 초장문 처리 능력을 입증했다.
Google: Gemini 3 Flash가 2월 포스팅에서 다뤘던 Gemini 3 Pro를 SWE-bench에서 앞지르는 이변을 만들었다. 여기서 끝이 아니다. 2월 19일 출시된 Gemini 3.1 Pro가 ARC-AGI-2에서 77.1%(3 Pro 대비 2배 이상), GPQA Diamond 94.3%를 기록하며 18개 추적 벤치마크 중 12개에서 1위를 차지했다. 3.1 Flash-Lite까지 빠르게 후속 출시됐다.

주요 벤치마크 비교

2월 대비 변화 포인트:

• GPT: 5.2 → 5.4, OSWorld 47.3% → 75%로 급상승
• Claude: Opus 4.5(80.9%) → 4.6(80.8%) 성능 유지, Sonnet 4.6(79.6%) 신규 등장
• Gemini: 3 Flash(SWE-bench 78%)가 3 Pro(76.2%)를 역전, 3.1 Pro가 ARC-AGI-2 77.1%로 추론 최강 등극
• GPT-5.4에 네이티브 컴퓨터 사용과 1M 컨텍스트 추가
• Claude Opus/Sonnet 4.6 모두 1M 컨텍스트 GA (3/13), MRCR v2 76%로 초장문 처리 입증

분야별 최적 모델

코딩 작업

이번 세대에서 가장 큰 변화가 있었던 분야다.

Sonnet 4.6의 등장이 게임 체인저다. Claude Code 테스트에서 개발자들이 Sonnet 4.6을 이전 플래그십 Opus 4.5보다 59% 더 선호했다. Opus급 코딩 성능을 $3/$15라는 가격에 쓸 수 있게 된 것이다.

수학/추론

GPT-5.4가 AIME에서 만점을 기록하며 수학 추론의 격차를 벌렸고, Gemini 3.1 Pro는 ARC-AGI-2와 GPQA Diamond에서 모두 1위를 차지하며 범용 추론 분야의 새 기준을 세웠다.

에이전트/자동화

이번 세대의 가장 큰 화두는 에이전트 능력이다.

GPT-5.4는 화면을 인식하고 마우스와 키보드를 직접 조작할 수 있는 네이티브 컴퓨터 사용을 지원한다. OSWorld 75%는 인간 평균 72.4%를 넘어선 수치다.

Claude Opus 4.6은 다른 방향으로 에이전트에 접근한다. METR 평가에서 14시간 30분 연속 작업이 가능한 것으로 측정됐으며, 장기적이고 복잡한 개발 작업에 최적화되어 있다.

가격 비교

API 가격 (1M 토큰당, USD)

2월 대비 변화:

• GPT-5.4 입력 가격 $2.50 (GPT-5.2 대비 상승)
• Claude Opus $5 유지, Sonnet 4.6이 $3으로 가성비 선택지 추가
• Gemini 3 Flash가 기존 Flash와 동일 가격($0.30)에 Pro급 성능 제공

월 구독 상품 (일반 사용자용)

가성비 분석:

• 일반 사용자: ChatGPT Plus, Claude Pro, Google AI Pro 모두 $20 수준으로 동일
• 파워유저: Claude Max ($100~200) 또는 ChatGPT Pro ($200)
• API 최저가: Gemini 3.1 Flash-Lite ($0.10 input)
• API 가성비: Gemini 3 Flash ($0.30에 Pro급 성능)

모델별 핵심 강점

GPT-5.4

• AIME 100% (수학 추론 만점)
• OSWorld 75% (인간 평균 초과, 컴퓨터 사용)
• 1M 토큰 컨텍스트 (API/Codex)
• 네이티브 컴퓨터 사용 + 도구 검색
• 사실 오류 33% 감소 (GPT-5.2 대비)

Claude Opus 4.6

• SWE-bench 80.8% (코딩 1위 유지)
• Terminal-Bench 65.4% (터미널 작업 최고)
• METR 14.5시간 연속 작업 (업계 최장)
• 에이전트 팀 기능 지원
• 1M 컨텍스트 정식 지원 (GA, 추가 비용 없음)
• MRCR v2 76% (8개 needle, 1M 토큰 — Sonnet 4.5의 18.5% 대비 압도적)

Claude Sonnet 4.6

• SWE-bench 79.6% (Opus와 1.2%p 차이)
• OSWorld 72.5% (에이전트 능력)
• Opus 대비 1/5 가격 ($3/$15)
• 개발자 70%가 Sonnet 4.5보다 선호
• claude.ai 무료/Pro 기본 모델

Gemini 3 Flash

• GPQA Diamond 90.4% (PhD급 추론)
• MMMU Pro 81.2% (멀티모달 최고)
• SWE-bench 78% (2.5 Pro 능가)
• 2.5 Pro보다 3배 빠른 속도
• 30% 적은 토큰으로 동일 성능

선택 가이드

2월과 달라진 추천

코딩이 주 업무라면: Claude Sonnet 4.6 (변경)

• 2월엔 Opus 4.5가 유일한 선택이었지만, 이제 Sonnet 4.6이 거의 동급 성능을 1/5 가격에 제공한다
• Opus 4.6은 14시간 이상의 장기 에이전트 작업이 필요할 때만 선택

AI 에이전트를 원한다면: GPT-5.4 (신규)

• 네이티브 컴퓨터 사용은 GPT-5.4만의 차별점
• 화면 인식 + 마우스/키보드 조작으로 실제 업무 자동화 가능

정확성이 최우선이라면: GPT-5.4 (유지)

• 사실 오류 추가 33% 감소
• 수학 만점, 환각률 최저 유지

대용량 처리가 필요하다면: 세 진영 모두 1M 지원 (변경)

• GPT-5.4, Claude Opus/Sonnet 4.6, Gemini 3.1 Pro/3 Flash 모두 1M 컨텍스트 지원
• 초장문 정확도는 Claude Opus 4.6 (MRCR v2 76%), 속도와 가격은 Gemini 3 Flash가 우위

비용 최적화가 중요하다면: Gemini 3 Flash (변경)

• $0.30 input에 이전 세대 Pro를 능가하는 성능
• 가성비 면에서 압도적

멀티 모델 전략 (2026년 3월 업데이트)

작업별로 최적 모델을 조합하는 전략은 여전히 유효하다. 다만 조합이 달라졌다.

2026년 2월 조합:

• 코딩/개발: Claude Opus 4.5
• 복잡한 추론: GPT-5.2
• 대용량 문서/멀티모달: Gemini 3 Pro

2026년 3월 조합:

• 일반 업무 + 자동화: GPT-5.4
• 코딩 (일상): Claude Sonnet 4.6
• 코딩 (고난도/장기): Claude Opus 4.6
• 대량 처리 + 속도: Gemini 3 Flash
• 최저 비용: Gemini 3.1 Flash-Lite

핵심 변화는 Anthropic의 2단 전략이다. Sonnet으로 일상 코딩을 커버하고, Opus는 장기 에이전트 작업 전용으로 포지셔닝했다. 대부분의 개발자에게 Sonnet 4.6이면 충분하다.

결론

2026년 3월은 에이전트의 시대가 본격적으로 열린 시점이다.

GPT-5.4는 컴퓨터를 직접 조작하는 범용 에이전트로 진화했고, Claude Opus 4.6은 14시간 넘게 혼자 일하는 개발 에이전트가 됐다. 단순히 질문에 답하는 챗봇을 넘어, 실제로 작업을 수행하는 도구로 LLM이 변하고 있다.

모델 선택의 기준도 달라졌다. “어떤 모델이 더 똑똑한가”보다 “어떤 모델이 내 작업을 대신해줄 수 있는가”가 핵심 질문이 됐다.

• GPT-5.4: 범용 AI 에이전트의 기준을 세운 모델. 수학 만점, 컴퓨터 사용, 1M 컨텍스트까지 갖췄다
• Claude 4.6: 코딩 최강의 자리를 굳히면서 Sonnet의 가성비 혁명을 일으켰다
• Gemini 3/3.1: 3.1 Pro가 추론 벤치마크 12관왕을 달성했고, Flash는 속도와 가격의 강점을 유지했다

지난달에는 “코딩은 Claude, 추론은 GPT, 대용량은 Gemini”가 결론이었다. 한 달 만에 그 구도가 한층 선명해지면서도 새로운 변수가 생겼다. 코딩에는 Claude(이제 Sonnet이면 충분하고 1M 컨텍스트까지 GA), 자동화에는 GPT(컴퓨터까지 조작), 추론에는 Gemini(3.1 Pro가 12관왕), 속도와 비용에는 Gemini Flash. 특히 세 진영 모두 1M 컨텍스트를 지원하게 되면서 “대용량 처리”는 더 이상 차별화 요소가 아니다. 다음 경쟁은 에이전트 성능과 실제 업무 자동화 능력에서 갈릴 것이다.

참고 자료

공식 발표

• OpenAI – Introducing GPT-5.4
• Anthropic – Claude Sonnet 4.6
• Google – Gemini 3 Flash
• Anthropic – 1M Context GA
• Google – Gemini 3.1 Pro

벤치마크 및 분석

• Vellum – Claude Opus 4.6 Benchmarks
• DataCamp – GPT-5.4 Overview
• Artificial Analysis – Gemini 3 Flash

가격 정보

• OpenAI Pricing
• Anthropic Claude Pricing
• Google AI Plans

작성일: 2026-03-10 (최종 업데이트: 2026-03-16)
기준 모델: GPT-5.4, Claude Opus/Sonnet 4.6 (1M GA), Gemini 3.1 Pro, Gemini 3 Flash

The post 2026년 3월 주요 LLM 비교 총정리: GPT-5.4 vs Claude 4.6 vs Gemini 3 appeared first on .

1. 랄프 위검 루프는 AI 코딩 에이전트에 같은 프롬프트를 무한 반복 투입해, 사람 없이도 코드를 완성하는 자율 개발 기법이다
2. 호주의 염소 농장주 겸 개발자 Geoffrey Huntley가 5줄짜리 bash 스크립트로 시작했고, 5만 달러 규모 프로젝트를 297달러에 완성한 사례로 유명해졌다
3. 2026년 현재 Claude Code 공식 플러그인으로 채택되었으며, 시간당 약 10달러의 비용으로 밤새 자율 코딩이 가능하다

결론부터 말하면

퇴근할 때 AI에게 작업을 맡기고, 아침에 출근하면 코드가 완성되어 있다. 공상과학이 아니라 2026년 현재 실제로 가능한 일이다. ‘랄프 위검 루프(Ralph Wiggum Loop)’라 불리는 이 기법은 AI 코딩 에이전트를 무한 루프로 돌리면서, 에이전트가 스스로의 실수를 보고 고치고, 다시 시도하기를 반복하게 만든다. 개발자가 잠든 사이에도 AI는 묵묵히 코드를 짠다.

심슨 가족의 랄프 위검, AI 코딩의 아이콘이 되다

이름부터 특이하다. ‘랄프 위검’은 애니메이션 심슨 가족에 등장하는 캐릭터다. 똑똑하지는 않지만 절대 포기하지 않는, 낙천적이고 끈질긴 성격으로 유명하다. “I’m in danger”라는 밈의 주인공이기도 하다.

이 캐릭터의 이름이 AI 코딩 기법에 붙은 이유가 있다. 랄프 위검 루프의 핵심이 바로 끈질긴 반복이기 때문이다. AI가 코드를 잘못 짜면? 다시 시도한다. 에러가 나면? 에러 메시지를 보고 또 시도한다. 성공할 때까지 멈추지 않는다. 마치 랄프 위검처럼.

염소 농장에서 탄생한 혁신

이 기법을 만든 사람은 호주의 오픈소스 개발자 Geoffrey Huntley다. 그는 시골에서 염소 농장을 운영하면서 소프트웨어 개발을 병행하고 있었다. 컴퓨터 앞에 오래 앉아 있을 수 없는 환경이 문제였다.

기존 AI 코딩 도구의 한계는 명확했다. AI가 코드를 작성하면 개발자가 결과를 확인하고, 수정 지시를 내리고, 다시 확인하는 과정을 반복해야 했다. 이른바 ‘human-in-the-loop’ 방식. 염소를 돌보면서 이 과정을 계속할 수는 없었다.

Huntley의 해결책은 놀라울 정도로 단순했다. 5줄짜리 bash 스크립트를 작성한 것이다.

while :; do cat PROMPT.md | claude-code ; done

이게 전부다. AI 에이전트에게 같은 프롬프트를 무한히 반복 투입하는 것. 에이전트가 한 번 작업을 마치면, 다시 처음부터 같은 지시를 받고 이전 작업 결과물 위에서 계속 작업한다. Huntley는 이 스크립트를 돌려놓고 염소를 돌보러 갔다. 돌아왔을 때, 수천 달러 가치의 코딩 작업이 완료되어 있었다.

어떻게 작동하는가

랄프 위검 루프의 작동 원리는 직관적이다.

핵심 아이디어: 진행 상황을 LLM의 컨텍스트 윈도우가 아니라 파일 시스템과 git 히스토리에 저장한다.

일반적인 AI 채팅에서는 대화가 길어질수록 AI가 앞부분을 잊어버린다. 컨텍스트 윈도우에 한계가 있기 때문이다. 랄프 루프는 이 문제를 우회한다. 매 반복마다 AI는 새로운 컨텍스트로 시작하지만, 이전 반복에서 수정한 파일과 git 커밋 기록을 그대로 본다.

컨텍스트 관리 방식도 체계적이다.

• 토큰 사용량 60% 미만: 정상 작업 진행
• 60~80%: 현재 작업 마무리 후 전환 준비
• 80% 초과: 강제로 새 컨텍스트로 교체

컨텍스트가 교체되어도 작업 결과는 파일에 남아 있으니, 새 에이전트는 이전 에이전트가 멈춘 지점에서 자연스럽게 이어간다.

297달러로 5만 달러짜리 프로젝트를 완성하다

가장 유명한 사례는 Huntley 자신의 경험이다. 5만 달러 규모의 MVP 프로젝트를 랄프 루프로 실행한 결과, API 비용 297달러에 완성했다. 99% 이상의 비용 절감이다.

Y Combinator 해커톤에서도 비슷한 결과가 나왔다. 참가 팀들이 랄프 루프를 활용해 하룻밤 사이에 6개 이상의 레포지토리를 완성했고, API 비용은 297달러에 불과했다.

더 인상적인 사례도 있다. Huntley는 랄프 루프를 3개월간 연속 실행해 완전한 프로그래밍 언어(CURSED)를 만들어냈다. 또 다른 개발자는 Fruit Ninja 클론 게임을 1시간 만에 완성했는데, 충돌 감지, 점수 시스템, 사운드 이펙트까지 갖춘 완전한 게임이었다. 에이전트는 그 사이 8번의 컨텍스트 교체를 거쳤다.

시간당 비용은 Sonnet 모델 기준 약 10.42달러다. 한화로 약 1만 4천원. 최저임금보다 저렴한 비용으로 24시간 쉬지 않고 코딩하는 ‘개발자’를 고용하는 셈이다.

Claude Code 공식 플러그인이 되기까지

https://github.com/anthropics/claude-plugins-official/tree/main/plugins/ralph-loop

Huntley의 5줄짜리 스크립트는 빠르게 개발자 커뮤니티에 퍼졌다. 2025년 말, Anthropic의 Claude Code 책임자 Boris Cherny가 이 기법을 공식 플러그인으로 정리했다.

공식 플러그인의 작동 방식은 원본보다 정교하다.

1. Claude가 작업을 수행한다
2. Claude가 “끝났다”고 판단하면 종료를 시도한다
3. Stop Hook이 종료를 가로채고, 실제로 작업이 끝났는지 검증한다
4. 검증 실패 시 다시 작업으로 돌아간다. 성공 시에만 종료를 허용한다

‘완료 약속(Completion Promise)’이라는 개념도 추가됐다. 에이전트가 특정 단어(보통 “complete”)를 출력해야만 진짜 종료로 인정한다. 이 장치가 있어야 AI가 대충 “끝났다”고 선언하고 도망가는 것을 막을 수 있다.

설정 예시:

completion_promise: "complete"
max_iterations: 25

최대 반복 횟수를 설정해 무한 루프에 빠지는 것도 방지한다. 기본값은 20~25회 정도다.

잘 되는 작업, 안 되는 작업

랄프 루프가 만능은 아니다. 잘 맞는 작업과 맞지 않는 작업이 명확히 나뉜다.

잘 되는 작업:

• 대규모 리팩토링 (프레임워크 마이그레이션, 코드 현대화)
• 테스트 커버리지 확대
• API 구현
• 데이터베이스 마이그레이션
• 명확한 명세가 있는 신규 기능 개발
• 반복적인 배치 작업

맞지 않는 작업:

• 주관적 판단이 필요한 UX/디자인 결정
• 대규모 코드베이스의 전체적 이해가 필요한 작업
• 미묘한 뉘앙스가 중요한 작업
• 명세가 모호한 작업

핵심은 성공 기준이 명확한가다. “테스트 100개가 모두 통과”처럼 기계적으로 판단할 수 있는 기준이 있으면 랄프 루프가 빛을 발한다. “사용자 경험이 좋아야 한다”처럼 주관적인 기준은 AI가 판단하기 어렵다.

실전 활용 팁

랄프 루프를 제대로 쓰려면 몇 가지 원칙이 있다.

1단계: 계획 먼저, 구현은 나중에

대화를 통해 명세를 만들고, 구현 계획을 수립한다. 이 계획 문서만 가지고 새로운 컨텍스트에서 자율 루프를 실행한다. 계획과 구현을 분리해야 컨텍스트 오염을 방지할 수 있다.

2단계: 검증 수단을 반드시 마련한다

Boris Cherny가 강조하는 원칙이다. 테스트 코드를 먼저 작성하고, AI가 테스트를 통과할 때까지 구현을 반복하게 하는 TDD 방식이 가장 안정적이다. 검증 수단 없이 랄프 루프를 돌리면, AI가 엉뚱한 방향으로 열심히 달려갈 수 있다.

3단계: 명세를 고정한다

AI가 마음대로 기능을 추가하는 것을 막아야 한다. 구체적인 파일 참조와 함께 “무엇을 하지 말 것”도 명시한다. 랄프 루프를 돌다 보면 AI가 요청하지 않은 기능을 만들어내는 경우가 있다.

개발자의 역할이 바뀐다

랄프 위검 루프가 시사하는 것은 단순한 자동화 도구 이상이다. Huntley는 이렇게 표현했다. “개발자는 더 이상 코드를 작성하는 사람이 아니라, AI에게 작업을 위임하고 관리하는 사람이 된다.”

과장이 아니다. 랄프 루프를 쓰면 개발자의 하루가 이렇게 바뀐다.

• 오전: 어제 밤 AI가 작업한 결과물 리뷰
• 오후: 다음 작업의 명세 작성, 테스트 코드 설계
• 퇴근 전: 랄프 루프 실행
• 밤: AI가 자율적으로 작업 수행

물론 모든 코딩 작업이 이렇게 대체되는 것은 아니다. 시스템을 설계하고, 명세를 작성하고, “완료”를 정의하고, 최종 결과를 검토하는 것은 여전히 사람의 몫이다. 다만 반복적인 구현과 디버깅, 새벽 2시의 삽질은 AI가 대신한다.

비용과 한계

현실적인 비용을 정리하면 다음과 같다.

저렴하다고만 할 수는 없다. 하지만 동일한 작업을 프리랜서 개발자에게 맡기는 비용과 비교하면 확연히 차이가 난다. Huntley가 5만 달러 프로젝트를 297달러에 끝낸 것은 극단적 사례이지만, 비용 효율성의 방향은 분명하다.

한계도 있다. 토큰을 대량 소비하므로 무제한 요금제나 충분한 API 크레딧이 필요하다. 작업 도중 예상치 못한 오류로 루프가 헛돌 수도 있다. 결과물에 대한 최종 검토는 반드시 사람이 해야 한다.

전망

2025년 말 바이럴을 탄 랄프 위검 루프는 2026년 들어 AI 코딩의 표준 기법으로 자리잡았다. Anthropic은 Claude Code 공식 플러그인으로 채택했고, Cursor도 자체 구현을 내놓았으며, Vercel은 AI SDK용 랄프 루프 에이전트를 오픈소스로 공개했다.

5줄짜리 bash 스크립트에서 시작된 아이디어가 AI 코딩의 패러다임을 바꾸고 있다. “자는 동안 AI가 코딩한다”는 말이 더 이상 과장이 아닌 시대. 개발자에게 남은 질문은 “이게 가능한가”가 아니라 “어떤 작업을 맡길 것인가”다.

참고 자료

• Ralph Wiggum as a “software engineer” (Geoffrey Huntley 공식)
• Claude Code Ralph Wiggum Plugin (Anthropic GitHub)
• 2026 – The year of the Ralph Loop Agent (DEV Community)
• Claude Code Ralph Wiggum: Run Autonomously Overnight
• How Ralph Wiggum went from The Simpsons to the biggest name in AI (VentureBeat)
• Vercel Ralph Loop Agent (GitHub)

이 글은 2026년 3월 6일 기준으로 작성되었습니다. AI 코딩 도구와 관련 비용은 빠르게 변할 수 있습니다.

The post 랄프 위검 루프 – 자는 동안 AI가 코딩하는 시대가 왔다 appeared first on .

이전 포스팅에서 집에 굴러다니는 미니PC들로 쿠버네티스 클러스터를 구축한 이야기를 했었다.

쿠버네티스 클러스터 둘러보기

그때 설치한 버전이 v1.30.4였는데, 그 뒤로 Jenkins, Kafka, MySQL InnoDB Cluster, Redis 같은 것들을 하나씩 올리면서 “잘 돌아가는데 굳이 건드려야 하나” 싶어서 업그레이드를 계속 미뤄왔다. 근데 v1.30 지원 종료(EOL)도 되었고(on-prem은 2025년에 만료), CKA 시험 준비를 하면서 kubeadm 업그레이드를 공부하다 보니 이참에 직접 해보자 싶었다.

실제 프로덕션 워크로드가 돌아가는 환경에서 하는 거라 우려했는데, 막상 절차대로 하니까 생각보다 어렵지 않았다. 그 과정을 기록해둔다.

3줄 요약

• Kubernetes는 한 번에 1 마이너 버전씩만 업그레이드할 수 있다 (v1.30 → v1.31 OK, v1.30 → v1.32 불가. 도대체 왜 이렇게 만든건가?)
• 반드시 control-plane 먼저, worker 나중에 순서를 지켜야 한다
• 업그레이드 전 etcd 백업은 필수 – 실패 시 복구할 수 있는 유일한 보험

Kubernetes 클러스터 구성

업그레이드 대상 클러스터 구성은 이렇게 생겼다:

Kubernetes Cluster v1.30.4

Control Plane (3대)

• luckys-worker0
  • ingress-nginx-controller
  • redis-node-0
  • mysql-operator
• luckys-worker1
  • ingress-nginx-controller
  • dev-mysql-cluster-0
• luckys-worker2
  • kafka-controller-2
  • redis-node-2

Worker (3대)

• luckys-worker3 – 사망
• luckys-worker4
  • kafka-controller-1
  • prod-mysql-cluster-1
  • loki (로그 수집)
• luckys-worker5
  • kafka-controller-0
  • prod-mysql-cluster-2
  • prometheus, alertmanager
  • redis-dev-master (standalone)
• luckys-worker6
  • prod-mysql-cluster-0
  • ingress-nginx-controller
  • jenkins
  • nexus, openclaw, grafana

주요 워크로드: Jenkins, Kafka, MySQL InnoDB Cluster, Redis Sentinel, Longhorn, MetalLB, Ingress-Nginx, 이외 다수 Application

OS는 Ubuntu 24.04 LTS, 컨테이너 런타임은 containerd.

사전 준비

1. 현재 버전 확인

kubeadm version
# kubeadm version: v1.30.4

kubelet --version
# Kubernetes v1.30.4

kubectl version

2. 업그레이드 가능한 버전 확인

v1.31 저장소를 추가하고 사용 가능한 버전을 확인한다:

# v1.31 저장소 추가
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring-v1.31.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' \
  | sudo tee /etc/apt/sources.list.d/kubernetes-v1.31.list

# GPG 키 등록
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key \
  | sudo gpg --dearmor --yes -o /etc/apt/keyrings/kubernetes-apt-keyring-v1.31.gpg

sudo apt update
sudo apt-cache madison kubeadm | head -5

참고: 기존 v1.30 저장소의 GPG 키가 만료되어 apt update 시 에러가 발생할 수 있다. v1.31 저장소만 정상이면 업그레이드 진행에 문제없다.

3. etcd 백업 (필수!)

업그레이드 전 반드시 etcd를 백업한다. 문제가 생기면 이 백업으로 클러스터를 복구할 수 있다.

# 인증서 경로 확인
kubectl describe pod etcd-luckys-worker0 -n kube-system

# etcd 백업 실행
export ETCDCTL_API=3
etcdctl snapshot save /opt/etcd-backup-before-upgrade.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# 백업 확인
etcdctl snapshot status /opt/etcd-backup-before-upgrade.db --write-out=table

etcdctl이 설치되어 있지 않다면 kubectl exec으로 etcd Pod 안에서 실행하거나, etcd 바이너리를 직접 설치하면 된다.

4. 노드별 워크로드 분포 확인

drain 하면 영향받는 워크로드를 미리 파악해야 한다:

# 각 노드에서 돌아가는 Pod 확인
kubectl get pods -A -o wide --field-selector spec.nodeName=luckys-worker0 | grep -v kube-system

# Taint 확인 (control-plane에 Taint가 없으면 일반 워크로드도 올라가 있을 수 있음)
kubectl describe node luckys-worker0 | grep -i taint

내 클러스터는 control-plane에 Taint가 설정되어 있지 않아서(마스터도 예외 없다) 일반 워크로드도 control-plane 노드에서 실행되고 있었다. MySQL InnoDB Cluster, Redis, Ingress 등의 분포를 확인하고 drain해도 프로덕션에 영향이 없는지 검증한 후 진행했다.

업그레이드 시 안전도

비교적 안전

• luckys-worker0 (prod 1개뿐, MySQL/Kafka 없음)
• luckys-worker2 (워크로드 적음)

우려됨

• luckys-worker1 (prod 앱 + ingress)
• luckys-worker5 (모니터링 + MySQL + Kafka)

매우 우려됨

• luckys-worker4 (워크로드 최다 + MySQL + Kafka)
• luckys-worker6 (prod 앱 많음 + MySQL + Jenkins + Ingress)

사실 다른 것도 그렇지만, Longhorn 으로 데이터가 서로 다른 노드에 동기화 되어야 하는데, upgrade로 인한 중단 시 쓰기 지연이 발생할 경우 클러스터 전체의 성능이 대폭 하락하는 문제가 있어서 이 지점이 가장 골머리 아프다.

업그레이드 순서

반드시 control-plane → worker 순서로 해야한다. kubelet은 apiserver보다 높은 버전일 수 없기 때문이다.

1. Control Plane #1 (luckys-worker0) ← 첫 번째는 kubeadm upgrade apply
2. Control Plane #2 (luckys-worker1) ← 이후는 kubeadm upgrade node
3. Control Plane #3 (luckys-worker2)
4. Worker #1 (luckys-worker4)        ← 전부 kubeadm upgrade node
5. Worker #2 (luckys-worker5)
6. Worker #3 (luckys-worker6)

Control Plane 첫 번째 노드 업그레이드

첫 번째 control-plane 노드만 kubeadm upgrade apply를 사용한다. 나머지는 전부 kubeadm upgrade node를 쓴다.

Step 1: kubeadm 업그레이드

# kubeadm 패키지 잠금 해제 → 설치 → 다시 잠금
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.31.14-1.1 && \
apt-mark hold kubeadm

Step 2: 업그레이드 계획 확인 및 실행

# 버전 확인
kubeadm version

# 업그레이드 계획 확인
sudo kubeadm upgrade plan

# 업그레이드 실행
sudo kubeadm upgrade apply v1.31.14

kubeadm upgrade plan은 현재 상태를 분석해서 업그레이드 가능 여부를 보여준다. 문제가 없으면 apply로 실제 업그레이드를 진행한다.

Step 3: 노드에서 Pod 퇴거 (drain)

kubeadm upgrade 후, kubelet 업그레이드 전에 drain한다.

kubectl drain luckys-worker0 --ignore-daemonsets

• --ignore-daemonsets: DaemonSet Pod(모니터링, 네트워크 등)은 무시
• emptyDir 사용하는 Pod 때문에 실패하면 --delete-emptydir-data 추가

Step 4: kubelet & kubectl 업그레이드

# 패키지 잠금 해제 → 설치 → 다시 잠금
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.31.14-1.1 kubectl=1.31.14-1.1 && \
apt-mark hold kubelet kubectl

# kubelet 재시작
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Step 5: 노드 복귀 (uncordon)

kubectl uncordon luckys-worker0

Step 6: 업그레이드 확인

kubectl get nodes
# luckys-worker0의 VERSION이 v1.31.14로 변경되었는지 확인

나머지 Control Plane 노드 업그레이드

두 번째, 세 번째 control-plane 노드는 kubeadm upgrade node를 사용한다. apply가 아닌 점에 주의. kubeadm upgrade plan도 불필요하다.

각 노드에 SSH 접속 후:

# 1. kubeadm 업그레이드
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.31.14-1.1 && \
apt-mark hold kubeadm

# 2. 노드 업그레이드
sudo kubeadm upgrade node          # ← apply가 아닌 node!

# 3. drain (다른 control-plane 노드에서 실행)
kubectl drain luckys-worker1 --ignore-daemonsets

# 4. kubelet & kubectl 업그레이드
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.31.14-1.1 kubectl=1.31.14-1.1 && \
apt-mark hold kubelet kubectl

sudo systemctl daemon-reload
sudo systemctl restart kubelet

# 5. uncordon (다른 노드에서 실행)
kubectl uncordon luckys-worker1

luckys-worker2도 동일하게 진행한다.

Worker 노드 업그레이드

Worker 노드도 거의 동일하다. kubeadm upgrade node를 사용한다.

# 1. kubeadm 업그레이드
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.31.14-1.1 && \
apt-mark hold kubeadm

# 2. 노드 업그레이드
sudo kubeadm upgrade node

# 3. drain (control-plane에서 실행)
kubectl drain luckys-worker4 --ignore-daemonsets

# 4. kubelet & kubectl
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.31.14-1.1 kubectl=1.31.14-1.1 && \
apt-mark hold kubelet kubectl

sudo systemctl daemon-reload
sudo systemctl restart kubelet

# 5. uncordon (control-plane에서 실행)
kubectl uncordon luckys-worker4

luckys-worker5, luckys-worker6도 동일하게 진행한다.

전체 업그레이드 완료 확인

kubectl get nodes -o wide

NAME             STATUS   ROLES           VERSION    OS-IMAGE
luckys-worker0   Ready    control-plane   v1.31.14   Ubuntu 24.04 LTS
luckys-worker1   Ready    control-plane   v1.31.14   Ubuntu 24.04 LTS
luckys-worker2   Ready    control-plane   v1.31.14   Ubuntu 24.04 LTS
luckys-worker4   Ready    <none>          v1.31.14   Ubuntu 24.04 LTS
luckys-worker5   Ready    <none>          v1.31.14   Ubuntu 24.04 LTS
luckys-worker6   Ready    <none>          v1.31.14   Ubuntu 24.04 LTS

주의사항 & 삽질 기록

GPG 키 만료 문제

v1.30 저장소의 GPG 키가 만료되어 apt update 시 에러가 났다:

EXPKEYSIG 234654DA9A296436 isv:kubernetes OBS Project

v1.31 저장소를 새로 추가하고 키를 등록하면 해결된다. 기존 v1.30 저장소 에러는 무시해도 된다.

1. v1.31 GPG 키 다운로드 및 등록

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring-v1.31.gpg

2. v1.31 저장소 추가

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring-v1.31.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes-v1.31.list

control-plane에 Taint가 없는 경우

일반적으로 control-plane 노드에는 NoSchedule Taint가 설정되어 있어서 일반 워크로드가 배치되지 않는다. 근데 내 클러스터처럼 Taint가 없으면 MySQL, Redis, Ingress 등이 control-plane에서도 실행된다.(Taint를 설정하기엔 비용 이슈가..)

drain 전에 반드시 해당 노드의 워크로드를 확인하고, 프로덕션 영향을 검토해야 한다:

kubectl get pods -A -o wide --field-selector spec.nodeName=<노드명> | grep -v kube-system

drain vs cordon

• kubectl drain: 기존 Pod를 다른 노드로 퇴거시키고 스케줄 차단
• kubectl cordon: 새 Pod 스케줄만 차단, 기존 Pod는 그대로

프로덕션 영향이 걱정되면 cordon만 하고 업그레이드를 진행하는 방법도 있다. kubelet 재시작 시 잠깐 중단되지만 Pod가 다른 노드로 이동하지는 않는다.

MySQL InnoDB Cluster 고려

MySQL InnoDB Cluster는 3개 인스턴스가 서로 다른 노드에 분산되어 있어서, 한 노드를 drain해도 나머지 2개가 쿼럼을 유지한다. drain 전에 어떤 노드에 어떤 인스턴스가 있는지 확인하자:

kubectl get pods -A -o wide | grep mysql
kubectl get innodbcluster -A

한 대씩, 확인하면서

절대 여러 노드를 동시에 drain하지 말자. 특히 control-plane은 etcd 쿼럼(과반수) 유지가 필수다. 3대 중 2대가 동시에 내려가면 클러스터가 멈춘다.

한 대 업그레이드 완료 → kubectl get nodes로 Ready 확인 → 다음 노드

업그레이드 절차 요약

[사전 준비]
  etcd 백업 → 저장소 추가 → 워크로드 분포 확인

[Control Plane 첫 번째 노드]
  kubeadm 설치 → kubeadm upgrade apply → drain → kubelet kubectl 설치 → restart → uncordon

[Control Plane 나머지 + Worker 전체]
  kubeadm 설치 → kubeadm upgrade node → drain → kubelet kubectl 설치 → restart → uncordon

[완료]
  kubectl get nodes로 전체 버전 확인

마치며

막상 해보니 절차만 지키면 크게 어렵지 않아서 이걸 왜이리 미뤄왔나 싶다.

핵심은 세 가지다:

1. etcd 백업: 만약을 위한 보험
2. 순서 준수: control-plane 먼저, worker 나중에
3. 한 대씩: 확인하고 넘어가기

CKA 시험에서도 kubeadm 업그레이드는 거의 매번 출제되는 문제라고 한다. 실제 클러스터에서 한 번 해보면 시험에서도 별 문제 없이 풀 수 있을 것 같다.

참고 링크

• Kubernetes 공식 문서 – Upgrading kubeadm clusters
• Kubernetes Version Skew Policy
• CKA 시험 공식 페이지
• 홈 서버 쿠버네티스 클러스터 구축기

The post Kubernetes 온프레미스 클러스터 업그레이드하기 appeared first on .

1. 오픈소스 AI 에이전트 플랫폼 OpenClaw의 폭발적 인기로 맥미니가 품귀 현상을 빚고 있으며, 중고 시장에서도 매물이 올라오면 수 시간 내 거래가 완료된다

2. 맥미니가 AI 서버로 선택받는 이유는 대기 전력 4~7W의 초저전력, 89만원부터의 합리적 가격, 그리고 DDR5/SSD 가격 폭등으로 자작PC 대비 가성비가 역전됐기 때문이다

3. OpenClaw를 클라우드 API로 사용한다면 M4 기본형(89만원)이면 충분하고, 로컬 LLM까지 돌리려면 M4 Pro 이상이 필요하다

맥미니, 왜 지금?

2026년 1월, 맥미니 품귀 사태

2026년 초, 개발자 커뮤니티에서 이상한 현상이 발생했다. 번개장터와 중고나라에 올라온 맥미니 매물이 몇 시간 만에 사라지기 시작한 것이다. 애플 공식 스토어에서도 일부 모델의 배송이 지연됐고, 쿠팡과 다나와에서는 가격이 오히려 올라가는 기현상까지 벌어졌다.

원인은 하나다. OpenClaw라는 오픈소스 AI 에이전트 플랫폼이 등장하면서, 사람들이 “개인 AI 서버”를 구축하기 위해 맥미니를 대량으로 구매하기 시작한 것이다.

DDR5, SSD 가격 폭등의 반사이익

때마침 2025년 하반기부터 DDR5 메모리와 SSD 가격이 급등하면서, 자작 PC 조립 비용이 크게 올랐다. 반면 맥미니 M4는 16GB 통합 메모리에 256GB SSD를 탑재하고도 89만원. 같은 사양의 미니 PC를 직접 조립하면 비슷하거나 오히려 더 비싼 상황이 된 것이다.

결과적으로 맥미니가 “AI 시대의 가성비 끝판왕”이라는 타이틀을 얻게 됐다.

OpenClaw란 무엇인가

개요

OpenClaw(구 Clawdbot, 구 Moltbot)는 오픈소스 AI 에이전트 플랫폼이다. 이름이 두 번이나 바뀐 이유는, 최초 이름인 ‘Clawdbot’이 Anthropic의 Claude와 유사하다는 이유로 명칭 변경을 요구받았기 때문이다.

쉽게 말하면, PC에 상주하면서 사용자 대신 컴퓨터를 조작하는 AI 비서다. WhatsApp, Telegram, Slack, Discord, iMessage 같은 메신저로 명령을 보내면, AI가 알아서 실행한다.

주요 기능

OpenClaw가 할 수 있는 것들:

• 웹 검색 및 정보 수집: “내일 서울 날씨 알려줘” 수준이 아니라, 복잡한 리서치를 알아서 수행
• 이메일 관리: 메일 분류, 답장 초안 작성, 스팸 정리
• 파일 관리: 문서 정리, 변환, 백업
• 터미널 명령어 실행: 개발자라면 서버 관리까지 위임 가능
• 일정 관리: 캘린더 확인, 일정 조율, 리마인더 설정
• 새로운 스킬 학습: 사용자가 가르치면 새로운 작업을 배움

설치 요구사양

OpenClaw 자체는 Node.js 기반으로 매우 가볍다. 하지만 사용 방식에 따라 요구사양이 완전히 달라진다.

중요한 포인트: 대부분의 사용자는 클라우드 API 방식으로 사용한다. 이 경우 맥미니는 24시간 켜두는 중계 서버 역할만 하기 때문에, 기본형으로도 충분하다.

로컬 LLM을 제대로 돌리려면 공식 권고 기준으로 M3 Ultra / 512GB 통합 메모리를 갖춘 맥 스튜디오급 사양이 필요하다. 맥미니로 로컬 LLM을 돌리겠다는 기대는 현실적이지 않다.

맥미니 모델별 스펙 비교

현행 라인업 (Apple Silicon)

전력 소비 비교 (Apple 공식)

이 표가 맥미니가 AI 서버로 선택받는 핵심 이유다.

M4 맥미니의 대기 전력은 4W다. 이건 LED 전구 하나 수준이다. 24시간 365일 켜놔도 전기세가 거의 나오지 않는다.

전기세 비교: 맥미니 vs 일반 PC vs 클라우드

24시간 상시 가동 기준으로 비용을 계산해보면 맥미니의 가성비가 드러난다.

월간 전기세 (24시간 가동)

OpenClaw 같은 AI 에이전트는 대부분의 시간을 대기 상태로 보낸다. 명령이 들어올 때만 잠깐 CPU를 쓰고, 나머지는 idle 상태다. 실사용 평균 전력을 기준으로 계산하면:

클라우드 대비 비용

클라우드 VPS로 같은 일을 하면 어떨까?

2년 차부터 맥미니가 AWS보다 저렴해진다. 3년이면 클라우드 대비 약 7~67만원을 아낄 수 있다. 게다가 맥미니는 3년 후에도 중고로 팔 수 있다.

용도별 추천 모델

OpenClaw (클라우드 API 방식) – 대부분의 사용자

추천: M4 기본형 (16GB / 89만원)

• OpenClaw + 클라우드 API는 RAM 4GB면 충분
• 16GB는 OpenClaw 외에 다른 용도로도 여유 있게 사용 가능
• 대기 전력 4W로 전기세 부담 없음
• 가장 합리적인 선택

홈서버 + 개발 환경

추천: M4 기본형 (16GB) 또는 M4 24GB 옵션

• Docker 컨테이너 여러 개 운영 가능
• 간단한 웹서버, DB 서버로 활용
• Home Assistant, Plex 등 홈 자동화까지

로컬 AI 모델 실험

추천: M4 Pro 24GB (209만원) 이상

• Ollama로 7B급 모델은 M4 기본형에서도 가능하지만 느림
• 13B급 이상은 M4 Pro 48GB 이상 권장
• 본격적인 로컬 LLM은 맥 스튜디오 영역

중고 구매 시

가성비 추천: M2 16GB 중고 (50~60만원대)

• 클라우드 API 방식 OpenClaw용으로 충분
• 대기 전력 7W로 M4(4W)보다 약간 높지만 큰 차이 없음
• 신품 대비 30만원 이상 절약 가능

비추천: M1 8GB

• 8GB RAM은 macOS 자체가 4~5GB를 사용하므로 여유가 없음
• OpenClaw + 브라우저 + 기타 서비스 동시 운영 시 스왑 발생
• 가격이 싸더라도 장기적으로 불만족스러울 가능성 높음

구매 전 알아야 할 것들

OpenClaw의 보안 리스크

OpenClaw는 컴퓨터의 키보드, 마우스, 파일 시스템에 접근 권한을 가진다. 이 말은 곧:

• 이메일, 파일, 개인 데이터에 AI가 접근 가능
• 의도하지 않은 잘못된 동작의 위험
• 악의적 프롬프트 주입(Prompt Injection) 공격 가능성

권장사항: OpenClaw 전용 계정을 만들어 권한을 분리하고, 민감한 데이터가 없는 환경에서 운영하는 것이 안전하다.

“로컬 LLM을 돌리고 싶다”는 환상

SNS에서 “맥미니로 로컬 AI를 돌린다”는 글이 많이 보이지만, 현실은 다르다.

• 기본형 16GB로는 7B급 모델이 겨우 돌아가는 수준
• 체감 성능은 Claude나 GPT API를 쓰는 것에 비해 한참 떨어짐
• 공식 권고: 로컬 LLM을 제대로 돌리려면 맥 스튜디오 M3 Ultra 512GB급 사양 필요

맥미니를 산다면 클라우드 API 중계 서버로 쓴다는 생각이 현실적이다.

M5를 기다려야 할까? [3월 업데이트]

2026년 3월, 애플이 M5 칩을 공식 발표했다. MacBook Air와 MacBook Pro에 먼저 탑재되어 3월 11일부터 판매가 시작됐다. 맥미니 M5는 2026년 상반기~WWDC(6월) 전후 출시가 예상된다.

결론부터 말하면, 지금 당장 필요하면 M4를 사라. OpenClaw를 클라우드 API 방식으로 쓰는 용도라면 M4와 M5의 차이가 체감되지 않는다. 맥미니는 대부분의 시간을 idle 상태로 보내기 때문이다. AI 작업 성능 향상은 로컬 LLM을 돌릴 때나 의미가 있고, 클라우드 API 중계 서버에는 과분한 성능이다.

다만 로컬 AI 모델을 돌리려는 사용자라면 M5 맥미니를 기다리는 것이 합리적이다. M5의 메모리 대역폭 향상(153GB/s)과 AI 성능 개선은 로컬 추론 속도에 직접적인 영향을 미친다. M5 출시 예고로 리셀러 채널에서 M4 재고를 할인 판매하는 경우도 늘고 있으므로, 급하지 않다면 이 시점을 활용하는 것도 방법이다 (Apple 공식가는 변동 없음).

중고 구매 체크리스트

맥미니 중고를 구매할 때 확인해야 할 항목:

2026년 3월 업데이트

OpenClaw v2026.3.13 보안 강화

2026년 3월 13일 릴리즈된 OpenClaw v2026.3.13에서 보안 구조가 크게 개선됐다. 기존에는 /pair 설정이나 QR 코드 방식이 자격증명을 그대로 노출하는 문제가 있었는데, 이번 업데이트로 단기 부트스트랩 토큰 방식으로 전환됐다. 한 번 사용하면 만료되는 토큰을 써서 초기 설정 과정에서의 노출 위험을 차단한 것이다.

이외에도 Chrome DevTools MCP 연동이 추가됐고, Docker 컨테이너의 타임존 고정 문제가 해결됐으며, Dashboard UI 안정성이 개선됐다. 홈서버로 장기 운영하는 사용자라면 업데이트를 권장한다.

지원 플랫폼 확대

OpenClaw의 공식 지원 플랫폼이 대폭 확대됐다. 맥미니 없이도 OpenClaw를 운영할 수 있는 선택지가 늘어난 것이다.

• QNAP NAS: 기존 NAS를 AI 에이전트 서버로 전환 가능
• Synology NAS: DSM 환경에서 Docker 컨테이너로 운영
• Raspberry Pi 5: 저전력 ARM 환경 공식 지원
• Intel AI PC: NPU 가속을 활용한 로컬 추론 지원

맥미니가 여전히 가성비 우위를 점하고 있지만, 이미 NAS를 보유한 사용자라면 별도 하드웨어 없이 OpenClaw를 시작해볼 수 있게 됐다.

ZeroClaw: 경쟁자 등장

2026년 2월, Rust 기반의 오픈소스 AI 에이전트 플랫폼 ZeroClaw가 등장해 빠르게 주목받고 있다. GitHub 스타가 출시 한 달 만에 19,000개를 돌파했다.

ZeroClaw는 리소스가 제한된 환경에서 강점을 가진다. 단, 생태계 성숙도와 플러그인 수는 아직 OpenClaw에 비해 부족한 편이다.

MLX 프레임워크로 추론 속도 높이기

맥미니에서 로컬 LLM을 돌린다면 MLX 프레임워크를 고려할 만하다. Apple Silicon의 통합 메모리 구조에 최적화된 MLX는 같은 하드웨어에서 Ollama 대비 추론 속도를 20~30% 높여준다.

• Apple에서 직접 개발한 머신러닝 프레임워크
• CPU와 GPU를 동시에 활용하는 통합 메모리 최적화
• mlx-lm 패키지로 Hugging Face 모델 바로 실행 가능
• Ollama와 병행 사용 가능 (용도별 선택)

M4 Pro 이상 맥미니에서 13B급 모델을 돌린다면, Ollama 대신 MLX를 써보는 것이 체감 성능 차이를 만들어준다.

정리: 이 돈이면 이거 사라

가장 많이 팔리는 조합: M4 16GB 신품(89만원)으로 OpenClaw를 클라우드 API 방식으로 운영. 이게 현재 가장 현실적인 “개인 AI 서버” 구성이다.

참고 자료

• Apple 공식 Mac mini 스펙
• Apple Mac mini 전력 소비 정보
• OpenClaw 공식 사이트
• 바이라인네트워크 – 맥미니 품귀 일으킨 클로드봇
• Scientific American – OpenClaw AI Agent
• GeekNews – OpenClaw는 Apple Intelligence가 되었어야 할 모습
• Apple Newsroom – M5 MacBook Air 발표 (2026.03.03)
• 정보 기준일: 2026-02-08 (업데이트: 2026-03-21)

The post 맥미니 대란 – OpenClaw가 만든 AI 서버 시대, 모델별 구매 가이드 appeared first on .

“AI에게 서버 관리를 맡길 수 있을까?”

최근 AI 에이전트 기술이 빠르게 발전하면서, 단순한 챗봇을 넘어 실제 인프라를 관리하는 AI에 대한 관심이 높아지고 있습니다. 이번 글에서는 오픈소스 AI 자동화 프레임워크인 OpenClaw을 Kubernetes 클러스터에 설치하고, 코드 작성 → GitHub 푸시 → Jenkins 빌드 → K8s 배포까지 자율적으로 수행하는 DevOps 에이전트를 구축한 과정을 공유합니다.

전체 구현 과정은 Claude Code(Anthropic의 CLI 기반 AI 코딩 도구)와 함께 진행했으며, 설정 파일 작성부터 트러블슈팅까지 실시간으로 협업하며 완성했습니다.

핵심요약

• 쿠버네티스 클러스터 내에 pod 로 실행중
• 슬랙과 연동해서 대화형으로 구성
• GLM-4.7 (영균매니저님이 소개해준 Z.AI)을 main model 로 사용
• pod 에서 상위 레벨인 node 상태와 클러스터 제어를 위해 권한 부여(service account의 RBAC 설정)
• GLM 모델 특성(원래 느림)도 있겠지만 상호작용이 개느림, 답답

OpenClaw ?

OpenClaw은 2026년 초 등장한 오픈소스 AI 자동화 프레임워크입니다. 주요 특징은 다음과 같습니다:

• 다양한 LLM 지원: Anthropic Claude, OpenAI GPT, Google Gemini, Z.AI GLM 등
• 멀티 채널: 웹 UI, Slack, Discord, WhatsApp 등으로 대화 가능
• 도구 실행: 셸 명령어, 파일 조작, 웹 브라우저 자동화 기능 내장
• Helm Chart 제공: Kubernetes 배포를 위한 공식 Helm 차트 지원

핵심은 AI가 단순히 텍스트를 생성하는 것을 넘어, 실제 명령어를 실행하고 시스템을 제어할 수 있다는 점입니다.

최종 아키텍처

구축 완료 후의 전체 아키텍처는 다음과 같습니다:

┌─────────────────────────────────────────────────────────┐
│  Kubernetes Cluster (v1.30.4, 6 nodes)                  │
│                                                         │
│  ┌─────────── openclaw namespace ──────────┐            │
│  │  ┌──────────────────────────────────┐   │            │
│  │  │  OpenClaw Pod (2 containers)     │   │            │
│  │  │  ├─ main: OpenClaw Agent         │   │            │
│  │  │  │   ├─ kubectl (RBAC)    ──────────────→ K8s API │
│  │  │  │   ├─ helm              ──────────────→ K8s API │
│  │  │  │   ├─ git               ──────────────→ GitHub  │
│  │  │  │   └─ curl              ──────────────→ Jenkins │
│  │  │  └─ chromium: Browser Sidecar    │   │            │
│  │  └──────────────────────────────────┘   │            │
│  │  ServiceAccount: openclaw-sa            │            │
│  │  ClusterRole: Full K8s Access           │            │
│  └─────────────────────────────────────────┘            │
│                                                         │
│  ┌─── corpbreak-com-ingress ns ───┐                     │
│  │  ExternalName Svc + Ingress    │                     │
│  │  → openclaw.corpbreak.com      │                     │
│  └────────────────────────────────┘                     │
└─────────────────────────────────────────────────────────┘
         ↕                    ↕                ↕
    [Slack Bot]         [Web UI HTTPS]    [Jenkins API]

주요 구성 요소

구현 과정

Step 1: Helm으로 기본 설치

먼저 OpenClaw의 공식 Helm 차트를 이용하여 기본 설치를 진행했습니다.

# Helm 레포지토리 추가
helm repo add openclaw https://serhanekicii.github.io/openclaw-helm
helm repo update

# 네임스페이스 생성 및 설치
kubectl create namespace openclaw
helm install openclaw openclaw/openclaw -n openclaw -f values.yaml

LLM은 Z.AI의 GLM 4.7 모델을 선택했습니다. OpenClaw은 zai를 빌트인 프로바이더로 지원하기 때문에, API 키만 환경변수로 설정하면 됩니다.

Step 2: 첫 번째 장애 – Gateway Token

설치 직후 Pod가 CrashLoopBackOff 상태에 빠졌습니다.

Config invalid
Problem: Gateway auth is set to token, but no token is configured

OpenClaw의 Gateway는 인증 토큰이 필수입니다. openssl rand -hex 32로 토큰을 생성하고 Secret에 추가한 후, 설정 파일에서 환경변수로 참조하도록 수정했습니다.

"gateway": {
  "auth": {
    "token": "${GATEWAY_TOKEN}"
  }
}

Step 3: HTTPS Ingress 구성

기존 인프라의 패턴에 맞춰 ExternalName Service + Ingress 조합으로 외부 접근을 구성했습니다.

# ExternalName Service (cross-namespace routing)
apiVersion: v1
kind: Service
metadata:
  name: openclaw-external
  namespace: corpbreak-com-ingress
spec:
  type: ExternalName
  externalName: openclaw.openclaw.svc.cluster.local

OpenClaw의 WebUI는 WebSocket을 사용하므로, Ingress에 다음 annotation이 필수입니다:

nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

Step 4: WebSocket 연결 오류 해결

접속 시도 시 여러 WebSocket 에러가 연이어 발생했습니다:

각 오류를 하나씩 해결한 끝에 웹 UI 접속에 성공했습니다.

Step 5: Slack 연동

OpenClaw은 Slack Socket Mode를 지원합니다. Slack App을 생성하고 다음 두 토큰을 Secret에 추가하면 됩니다:

• App-Level Token (xapp-): Socket Mode 연결용
• Bot Token (xoxb-): 메시지 송수신용

"channels": {
  "slack": {
    "enabled": true,
    "appToken": "${SLACK_APP_TOKEN}",
    "botToken": "${SLACK_BOT_TOKEN}"
  }
}

설정 후 OpenClaw 로그에서 socket mode connected 메시지를 확인할 수 있습니다.

Step 6: 브라우저 자동화 설정

OpenClaw의 브라우저 기능을 활성화하려면 두 가지가 필요합니다:

1. Chromium Sidecar Container: CDP(Chrome DevTools Protocol) 서버 제공
2. Playwright 브라우저 바이너리: Main 컨테이너에서 직접 브라우저 실행

Chromium Sidecar는 Helm Chart에서 자동 생성되지만, Playwright 바이너리는 Init Container로 별도 설치가 필요했습니다.

initContainers:
  install-browser:
    image:
      repository: ghcr.io/openclaw/openclaw
      tag: "2026.2.3"
    command:
      - sh
      - -c
      - |
        PLAYWRIGHT_BROWSERS_PATH=/home/node/.openclaw/browsers \
        node /app/node_modules/playwright-core/cli.js install chromium

Step 7: DevOps 도구 설치 (kubectl, helm)

OpenClaw Pod 안에서 클러스터를 관리하려면 kubectl과 helm이 필요합니다. 이들도 Init Container로 설치했습니다.

initContainers:
  install-tools:
    image:
      repository: alpine
      tag: "3.21"
    command:
      - sh
      - -c
      - |
        # kubectl 설치
        wget -q "https://dl.k8s.io/release/v1.30.4/bin/linux/amd64/kubectl" \
          -O /home/node/.openclaw/bin/kubectl
        chmod +x /home/node/.openclaw/bin/kubectl

        # helm 설치
        wget -q "https://get.helm.sh/helm-v3.17.1-linux-amd64.tar.gz" \
          -O /tmp/helm.tar.gz
        tar -xzf /tmp/helm.tar.gz -C /tmp
        mv /tmp/linux-amd64/helm /home/node/.openclaw/bin/helm

이 바이너리들은 PVC에 저장되므로, Pod가 재시작되어도 다시 다운로드할 필요가 없습니다.

Step 8: RBAC 설정 – Pod에서 클러스터 제어하기

Kubernetes에서 Pod가 클러스터 API에 접근하려면 ServiceAccount + ClusterRole + ClusterRoleBinding이 필요합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: openclaw-cluster-role
rules:
  - apiGroups: [""]
    resources: ["nodes", "pods", "pods/log", "services",
                "configmaps", "secrets", "namespaces"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

이렇게 설정하면 OpenClaw이 Pod 내부에서 kubectl get nodes, kubectl get pods -A 등을 자유롭게 실행할 수 있습니다.

Step 9: 시스템 프롬프트 주입 (Bootstrap File)

OpenClaw이 DevOps 작업을 정확히 수행하려면, 프로젝트 구조와 CI/CD 파이프라인에 대한 지식이 필요합니다.

처음에는 에이전트 설정에 systemPrompt 필드를 직접 추가했으나, “Unrecognized key” 오류로 Pod가 크래시했습니다. OpenClaw은 시스템 프롬프트를 설정 파일이 아닌 Bootstrap 파일로 주입하는 방식을 사용합니다.

Workspace 디렉토리에 AGENTS.md 파일을 생성하면, OpenClaw이 자동으로 이를 감지하여 시스템 프롬프트에 포함시킵니다.

/home/node/.openclaw/workspace/AGENTS.md

이 파일에 다음 정보를 포함했습니다:

• 도구 경로 (kubectl, helm, git)
• 클러스터 정보 (노드 구성, StorageClass, Registry)
• GitHub 인증 방법
• 전체 서비스 목록과 도메인 매핑
• Jenkins API 사용법 (빌드 트리거, 상태 확인, Job 생성)
• Blue-Green 배포 파이프라인 구조
• deploy-config YAML 템플릿

주요 설정 파일 구조

values.yaml (Helm Values)

최종 values.yaml의 핵심 구조는 다음과 같습니다:

configMode: overwrite

app-template:
  controllers:
    main:
      serviceAccount:
        name: openclaw-sa          # RBAC 연결
      containers:
        main:
          envFrom:
            - secretRef:
                name: openclaw-env-secret  # API 키, 토큰
          env:
            PATH: /home/node/.openclaw/bin:...  # kubectl, helm 경로

      initContainers:
        install-browser: ...       # Playwright Chromium
        install-tools: ...         # kubectl, helm + AGENTS.md

  configMaps:
    config:
      data:
        openclaw.json: |
          {
            "gateway": { ... },
            "browser": { ... },
            "agents": {
              "defaults": {
                "workspace": "/home/node/.openclaw/workspace",
                "model": { "primary": "zai/glm-4.7" }
              }
            },
            "channels": {
              "slack": { "enabled": true, ... }
            }
          }

  persistence:
    data:
      type: persistentVolumeClaim
      size: 5Gi
      storageClass: longhorn

Secret 구성

# openclaw-env-secret에 포함된 키들
ZAI_API_KEY: ...          # GLM 4.7 API 키
GATEWAY_TOKEN: ...        # Gateway 인증 토큰
SLACK_APP_TOKEN: ...      # Slack Socket Mode
SLACK_BOT_TOKEN: ...      # Slack Bot
GITHUB_TOKEN: ...         # GitHub PAT (코드 push)
JENKINS_URL: ...          # Jenkins API URL
JENKINS_USER: ...         # Jenkins 사용자
JENKINS_TOKEN: ...        # Jenkins API 토큰

OpenClaw이 할 수 있는 일

구축이 완료된 후, OpenClaw은 Slack 메시지 하나로 다음 작업들을 수행할 수 있습니다:

1. 클러스터 모니터링

사용자: "현재 corpbreak-dev 네임스페이스 Pod 상태 확인해줘"
OpenClaw: kubectl get pods -n corpbreak-dev 실행 → 결과 보고

2. 코드 작성 및 GitHub Push

사용자: "exchange-service에 새 API 엔드포인트 추가해줘"
OpenClaw: git clone → 코드 수정 → git commit → git push

3. Jenkins 빌드 트리거

사용자: "checklist 서비스 dev 환경에 배포해줘"
OpenClaw: Jenkins API 호출 → 빌드 트리거 → 상태 모니터링

4. 새 서비스 생성 (E2E)

사용자: "새로운 survey-service를 만들어줘"
OpenClaw:
  1. 스켈레톤 프로젝트 클론
  2. 패키지명/설정 변경
  3. deploy-config YAML 작성
  4. GitHub에 Push
  5. Jenkins Job 생성
  6. 빌드 트리거 및 배포 확인

Claude Code와 함께한 구현 과정

이번 구축의 특별한 점은, 전체 과정을 Claude Code와 실시간으로 협업하며 진행했다는 것입니다.

Claude Code는 Anthropic이 만든 CLI 기반 AI 코딩 도구로, 터미널에서 직접 파일을 읽고, 수정하고, 명령어를 실행할 수 있습니다. 이번 작업에서 Claude Code가 수행한 역할:

• 리서치: OpenClaw 설치 방법 웹 검색 및 문서 분석
• 설정 파일 작성: values.yaml, RBAC, Ingress 등 모든 K8s 매니페스트 생성
• Helm 명령 실행: helm install, helm upgrade 직접 실행
• 트러블슈팅: Pod 로그 분석, 에러 원인 파악, 설정 수정
• 검증: kubectl exec로 Pod 내부 확인, API 테스트

사실상 Claude Code가 모든 것을 만들었다..!

총 10번의 Helm revision을 거치며, 각 단계에서 발생한 오류를 Claude Code가 실시간으로 진단하고 수정했습니다. 특히 “systemPrompt 필드가 인식되지 않는 문제”처럼 공식 문서에도 명확히 나와있지 않은 이슈를 웹 검색과 문서 분석을 통해 해결한 과정이 인상적이었습니다.

삽질 기록: 이것만은 알고 시작하세요

구축 과정에서 겪은 주요 실수들을 정리합니다:

1. bjw-s app-template의 ServiceAccount 설정

OpenClaw Helm 차트는 내부적으로 bjw-s app-template 차트를 사용합니다. ServiceAccount를 연결할 때 일반적인 spec.serviceAccountName이 아닌, 차트 고유의 경로를 사용해야 합니다.

# 틀린 방법들
defaultPodOptions:
  serviceAccountName: openclaw-sa  # Error: additional properties not allowed

serviceAccount:
  name: openclaw-sa  # Error: got string, want object

# 정답
controllers:
  main:
    serviceAccount:
      name: openclaw-sa

2. OpenClaw 에이전트 설정

에이전트 설정을 위해서는 workspace의 Bootstrap 파일(AGENTS.md, SOUL.md 등)을 사용해야 합니다.

3. nginx-ingress의 configuration-snippet 차단

nginx-ingress v1.11.2부터 보안상 configuration-snippet annotation이 기본 차단됩니다. WebSocket 지원은 proxy-http-version: "1.1" annotation만으로 충분합니다.

4. Alpine에서 git 바이너리 복사 불가

Alpine Linux에서 설치한 git은 공유 라이브러리에 의존하므로, 바이너리만 복사하면 동작하지 않습니다. 다행히 OpenClaw 이미지에는 /usr/bin/git이 이미 포함되어 있었습니다.

보안 고려사항

AI 에이전트에게 클러스터 접근 권한을 부여할 때는 보안에 특별히 주의해야 합니다:

• 최소 권한 원칙: 필요한 리소스와 동작만 RBAC으로 허용
• 프로덕션 보호: 시스템 프롬프트에 “prod 배포는 반드시 사용자 확인 후 진행” 명시
• Secret 관리: API 키와 토큰은 모두 Kubernetes Secret으로 관리
• 감사 추적: OpenClaw의 로깅 설정으로 모든 도구 실행 기록 보관
• 네트워크 격리: OpenClaw이 접근할 수 있는 외부 엔드포인트 제한 고려

마치며

AI 에이전트가 실제 인프라를 관리하는 시대가 이미 시작되었습니다. OpenClaw은 아직 초기 단계의 프로젝트이지만, Kubernetes 클러스터 위에서 실제 DevOps 작업을 수행할 수 있다는 가능성을 보여주었습니다.

물론 아직 개선할 점이 있습니다. 브라우저 스크린샷 기능이 완벽하지 않고, 복잡한 멀티스텝 작업에서 간혹 컨텍스트를 놓치기도 합니다. 하지만 “Slack으로 메시지 하나 보내면 서비스가 배포된다”는 경험은 충분히 인상적입니다.

단, 이미 충분히 지식이 있고, Claude Code 를 이용한 자동화를 구축해둔 상황이라면, 굳이 OpenClaw 를 설치해서 사용할 필요가 있나? 싶은 생각도 들었습니다. (아직 사용을 제대로 해보지 못해서 그런 것인지.. 맥미니가 다시 중고로 쏟아지지 않을까.!?)

이번 구축 과정에서 Claude Code의 역할도 매우 컸습니다. Helm 차트 분석, YAML 설정 작성, 실시간 트러블슈팅까지 – AI와 함께 AI를 설치하는 재미있는 경험이었습니다.

혹시 비슷한 환경을 구축해보고 싶으신 분이 계시다면, 이 글이 시행착오를 줄이는 데 도움이 되길 바랍니다.

참고 링크

• OpenClaw GitHub: https://github.com/openclaw/openclaw
• OpenClaw Helm Chart: https://github.com/serhanekicii/openclaw-helm
• OpenClaw 공식 문서: https://docs.openclaw.ai
• Claude Code: https://claude.com/claude-code

The post OpenClaw – Kubernetes 클러스터에 구축기 with Claude Code appeared first on .