Amoo

삼성전자 DS 실적은 회복인데 왜 인재는 떠날까, SK하이닉스·마이크론·해외 반도체 보상까지 한 번에 정리

dragom — Tue, 19 May 2026 11:50:36 +0900

삼성전자 DS 실적은 회복인데 왜 인재는 떠날까, SK하이닉스·마이크론·해외 반도체 보상까지 한 번에 정리

2026년 들어 삼성전자 반도체 사업부, 즉 DS(Device Solutions) 부문 숫자는 분명히 좋아졌습니다. 1분기 실적만 놓고 보면 삼성전자는 "반도체가 다시 돈을 벌기 시작했다"는 수준을 넘어, 회사 전체 실적을 사실상 끌어올린 주역이었습니다. 그런데 시장과 현장에서는 전혀 다른 질문이 동시에 나옵니다. 실적은 살아나는데 왜 사람들은 불만이 크고, 왜 경쟁사로 이동한다는 말이 계속 나올까 하는 점입니다.

이 글에서는 삼성전자 DS의 최근 실적과 기대치, SK하이닉스와 마이크론을 포함한 메모리 3강 비교, 양사의 최근 성과급 차이, TSMC와 엔비디아 등 해외 반도체 기업의 보상 구조, 그리고 삼성 내부에서 제기되는 핵심 인력 유출과 파업 이슈를 한 번에 정리해 보겠습니다.

Samsung Electronics semiconductor fab clean room

1. 삼성전자 DS 최근 실적, 숫자만 보면 확실히 반등했다

삼성전자가 2026년 1분기 실적 발표에서 공개한 내용에 따르면, DS 부문은 매출 81조7천억원, 영업이익 53조7천억원을 기록했습니다. 회사 전체 연결 매출은 133조9천억원, 영업이익은 57조2천억원이었는데, 이 가운데 대부분의 이익을 DS가 사실상 만들어냈다고 봐도 과장이 아닙니다.

삼성전자 DS 2026년 1분기: 매출 81.7조원, 영업이익 53.7조원
메모리 부문: HBM4, SOCAMM2, PCIe Gen6 SSD 등 AI 메모리 판매 확대
향후 전망: 삼성은 2026년 HBM 매출이 전년 대비 3배 이상 늘 수 있다고 제시
하반기 기대: 하이퍼스케일러의 AI 인프라 확장, LLM 서비스 확산, 서버 메모리 수요 강세 지속 예상

삼성의 공식 설명을 보면 방향은 분명합니다. AI 메모리, 서버용 고부가 제품, 차세대 SSD를 앞세워 다시 메모리 주도권을 확대하겠다는 것입니다. 특히 HBM4 양산 판매를 선도했다는 점, 2026년 하반기에도 서버 메모리 수요가 강할 것이라고 본다는 점은 시장 기대를 자극하는 요소입니다.

다만 DS 안에서도 온도차는 있습니다. 메모리 사업은 강하지만, 파운드리는 계절성 영향과 수익성 부담이 여전히 남아 있고, 시스템LSI도 메모리만큼 시장의 압도적 신뢰를 회복했다고 보기는 어렵습니다. 즉, 삼성 DS의 최근 반등은 분명하지만, 그 반등이 DS 전체의 구조적 안정을 곧바로 의미하는 것은 아닙니다.

2. SK하이닉스와 비교하면 무엇이 다를까

같은 시기 SK하이닉스는 더 선명한 "AI 메모리 승자" 이미지를 보여주고 있습니다. SK하이닉스는 2026년 1분기 매출 52조5763억원, 영업이익 37조6103억원, 영업이익률 72%를 기록했다고 발표했습니다. 절대 영업이익 규모는 삼성 DS가 더 컸지만, 수익성만 놓고 보면 SK하이닉스의 체감 우위가 매우 강합니다.

SK하이닉스 2026년 1분기: 매출 52.6조원, 영업이익 37.6조원, 영업이익률 72%
SK하이닉스 2025년 연간: 매출 97.1조원, 영업이익 47.2조원, 역대 최대
핵심 메시지: HBM과 고성능 서버 메모리 중심으로 기록적인 수익성 달성
시장 해석: AI 메모리 시장의 체감 리더십은 여전히 SK하이닉스가 강하다는 평가

여기서 중요한 포인트는 단순히 "누가 더 많이 벌었나"가 아닙니다. 시장은 보통 다음 네 가지를 함께 봅니다.

AI 메모리 실질 리더십
고객사 신뢰와 공급 안정성
영업이익률과 현금창출력
그 성과가 직원 보상으로 얼마나 연결되느냐

삼성은 최근 분기 기준 절대 이익 규모가 매우 커졌지만, SK하이닉스는 HBM 강자라는 상징성, 높은 이익률, 공격적인 보상 체계까지 동시에 가져가고 있습니다. 이 차이가 결국 인재 이동과 노사 갈등의 배경이 됩니다.

SK hynix HBM memory AI chips

3. 최근 성과급 비교, 체감 격차는 왜 이렇게 크게 느껴질까

직원들이 가장 민감하게 보는 지점은 결국 숫자입니다. 최근 공개된 보상 수준을 보면 두 회사의 체감 차이는 상당합니다.

3-1. 삼성전자 DS 최근 성과급

BusinessKorea 보도에 따르면 삼성전자 DS 부문 직원들은 최근 연봉의 43%~48% 수준 OPI(초과이익성과급)를 받게 됐습니다. 삼성의 OPI는 연 1회, 최대 연봉의 50% 범위에서 지급되는 구조입니다. 여기에 별도로 TAI(Target Achievement Incentive)가 있는데, 2025년 하반기 기준 DS 내에서도 차등이 있었습니다.

DS OPI: 연봉의 43~48%
메모리/반도체연구소 TAI: 월 기본급 100%
시스템LSI·파운드리 TAI: 월 기본급 25%
특징: DS 전체가 좋아졌어도 사업부별 체감 격차 존재

삼성 입장에서는 "반도체 혹한기 뒤 보상이 꽤 회복됐다"고 말할 수 있습니다. 실제로 DS는 2023 회계연도에 OPI가 0%였고, 그 뒤 회복 과정을 거쳐 이번에는 40%대 후반까지 올라왔습니다. 하지만 직원 체감은 다를 수 있습니다. 숫자가 회복된 것과 경쟁사보다 매력적인 보상이라고 느끼는 것은 전혀 다른 문제이기 때문입니다.

3-2. SK하이닉스 최근 성과급

반면 SK하이닉스는 2025년 실적을 바탕으로 월 기본급의 2964% 성과급을 지급하기로 했습니다. Korea Herald 보도에 따르면 이는 개편된 성과공유 제도에 따른 결과이며, 연봉 1억원 직원 기준 약 1억4820만원 보너스에 해당합니다. 여기에 반기 생산성 인센티브까지 포함하면 전체 성과보상은 월 기본급의 3264% 수준으로 제시됐습니다.

SK하이닉스 성과급: 월 기본급 2964%
총 성과보상: 월 기본급 3264%
연봉 1억원 직원 예시: 보너스 약 1억4820만원
배경: 영업이익의 10%를 성과급 재원으로 쓰고 상한을 없앤 구조

이 차이는 단순히 몇 퍼센트 차이의 문제가 아닙니다. 회사가 AI 메모리 호황에서 번 돈을 직원과 얼마나 직접적으로 나누느냐의 문제로 읽히기 때문입니다. 삼성 직원 입장에서는 "회사는 회복됐다는데 왜 체감 보상은 경쟁사만큼 폭발적이지 않나"라는 불만이 생기기 쉽습니다.

4. 삼성 vs 하이닉스 성과급, 같은 기준으로 보면 누가 더 센가

두 회사의 제도는 완전히 같지 않기 때문에 단순 수치 비교는 조심해야 합니다. 그래도 체감 비교를 위해 정리하면 아래와 같습니다.

항목	삼성전자 DS	SK하이닉스
주요 성과급 구조	OPI + TAI	영업이익 연동 PS + 반기 인센티브
최근 핵심 수치	연봉 43~48% OPI	월 기본급 2964%, 총 3264%
상한 구조	OPI 최대 연봉 50%	영업이익 10% 연동, 상한 폐지
직원 체감	회복은 됐지만 사업부별 편차 큼	호황 이익이 보상으로 직접 연결된다는 인식 강함

요약하면 이렇습니다. 삼성은 실적 회복형 보상, 하이닉스는 초호황 공유형 보상에 더 가깝습니다. 같은 메모리 업황을 타더라도 직원 입장에서 느끼는 매력은 후자가 훨씬 강할 수밖에 없습니다.

semiconductor engineers salary bonus comparison chart

5. 해외 반도체 회사들과 비교하면 더 선명해진다

이제 한국 밖으로 눈을 돌려보면, 삼성이 겪는 문제는 단순히 국내 경쟁사와의 비교에서 끝나지 않습니다. 반도체 인재는 글로벌 시장에서 움직이고, 보상 체계도 점점 글로벌 기준으로 비교되기 때문입니다. 특히 메모리 3강 구도에서 마이크론까지 같이 보면 삼성의 위치가 더 또렷하게 보입니다.

5-1. TSMC, 이익 공유 구조가 더 직접적이다

TSMC가 2026년 2월 미국 SEC 공시에서 밝힌 내용에 따르면, 2025년 직원 대상 사업성과 보너스와 이익배분 총액은 약 2061억4592만 대만달러였습니다. 이 가운데 절반은 분기별 사업성과 보너스, 절반은 2026년 7월 배분될 이익공유분입니다.

대만 언론 보도를 보면 평균 직원 기준 연간 보너스가 1인당 200만 대만달러 안팎으로 거론됩니다. 원화로 환산하면 대략 수천만 원 후반에서 1억원 안팎 규모로 체감될 수 있는 수준입니다. 즉, TSMC 역시 호황 이익을 직원과 크게 나누는 구조를 갖고 있습니다.

5-2. 마이크론, 메모리 3강 경쟁에서 존재감이 커지고 있다

마이크론도 이제 빼놓기 어렵습니다. CNBC가 전한 2026 회계연도 2분기 실적 기준으로 마이크론은 매출 238억6000만달러를 기록했고, 이는 전년 동기 80억5000만달러에서 거의 3배 가까이 늘어난 수준입니다. 같은 보도에서 마이크론은 다음 분기 매출 가이던스로 약 335억달러를 제시했습니다.

핵심은 역시 AI 메모리입니다. 마이크론은 엔비디아용 HBM4 대량 생산을 이미 시작했다고 밝혔고, AI 서버용 메모리와 NAND 수요 급증의 직접 수혜를 받고 있습니다. 로이터가 인용한 카운터포인트리서치 데이터에 따르면 2025년 3분기 HBM 시장 점유율은 SK하이닉스 53%, 삼성전자 35%, 마이크론 11%였습니다. 아직 절대 강자는 아니지만, 메모리 3강의 한 축으로서 존재감이 분명해진 셈입니다.

보상 구조도 한국 회사들과는 결이 다릅니다. 마이크론은 홈페이지에서 RSU(제한조건부주식) 제공, ESPP(임직원 주식매입제도) 15% 할인, 401(k) 매칭 등 미국식 장기 보상 구조를 전면에 내세웁니다. 즉, 삼성이나 하이닉스처럼 "이번에 성과급이 몇 %냐"보다 현금 보너스와 주식 기반 보상을 섞어 인재를 붙잡는 구조에 더 가깝습니다.

5-3. 엔비디아, 현금 보너스보다 주식 보상이 강하다

엔비디아는 삼성이나 하이닉스처럼 "몇 % 성과급" 중심 회사라기보다, 주식보상 중심의 인재 유지 구조가 강한 회사입니다. Fortune 보도에 따르면 엔비디아의 주식보상비용은 2025 회계연도 약 47억달러에서 2026 회계연도 64억달러로 약 35% 늘었습니다. 같은 기사에서는 2025년 기준 직원 1인당 주식보상 비용이 약 15만달러 수준이라는 해석도 나옵니다.

또 다른 집계 자료에서는 엔비디아의 2025년 직원 중간 총보상(median total compensation)이 30만1233달러로 제시됩니다. 즉, 엔비디아는 한국식 거액 성과급보다 주가 상승과 장기 보상을 통해 사람을 붙잡는 방식이 훨씬 강합니다.

5-4. 해외 기업 비교가 삼성에 주는 압박

중요한 것은 액수 그 자체보다 메시지입니다.

TSMC: 이익공유가 크고 제도적으로 명확함
마이크론: HBM 추격과 미국식 주식보상 구조로 메모리 3강 경쟁 압박
엔비디아: 주식보상이 강하고 성장 서사가 분명함
SK하이닉스: AI 메모리 호황 이익을 공격적으로 성과급에 반영
삼성전자: 실적은 회복 중이지만 보상과 자부심의 연결이 약하다는 불만 존재

결국 삼성의 문제는 "보상이 절대적으로 적다"기보다, 경쟁사가 더 설득력 있게 보상을 설명하고 있고 직원들이 그 차이를 너무 쉽게 체감한다는 데 있습니다.

6. 그래서 왜 인재가 이동하나, 핵심 인력 유출과 인재 고갈 이슈

최근 로이터는 삼성 내부의 깊은 분열과 이직 움직임을 다룬 보도에서, 노조와 직원들의 불만 배경으로 보상 격차와 경쟁사 이동 문제를 짚었습니다. 로이터와 포춘이 인용한 노조 측 설명에 따르면, 최근 4개월 동안 약 200명의 삼성 인력이 SK하이닉스로 이동했다는 주장도 나왔습니다. 숫자 자체는 노조 발언 기준으로 봐야 하지만, 상징성은 매우 큽니다.

이 문제가 무서운 이유는 단순 퇴사 숫자 때문이 아닙니다. 반도체는 특히 다음과 같은 분야에서 핵심 인력의 학습곡선과 현장 경험이 매우 중요합니다.

HBM 설계와 공정 최적화
수율 개선
패키징 및 테스트
대형 고객 대응과 제품 인증
파운드리 공정 전환과 고객사 수주 대응

이런 영역에서는 사람 한 명이 단순히 "1인력"이 아닙니다. 축적된 노하우, 고객 대응 경험, 팀 내 암묵지, 실패를 줄이는 감각까지 같이 움직입니다. 그래서 핵심 인력 이탈은 당장 숫자로 안 보여도 몇 분기 뒤 수율, 납기, 고객 신뢰, 후배 육성에서 훨씬 크게 돌아올 수 있습니다.

더 큰 문제는 "인재 고갈"이 단기간에 체감되지 않는다는 점입니다. 처음에는 몇몇 핵심 인력이 빠져도 조직은 버팁니다. 하지만 시간이 지나면 다음과 같은 현상이 누적됩니다.

고성과자에게 일과 책임이 더 몰린다
남은 인력 피로도가 높아진다
신규 인력의 온보딩 속도가 느려진다
결국 또 다른 이직 유인이 생긴다

삼성처럼 메모리, 시스템LSI, 파운드리까지 모두 가져가려는 "원스톱 반도체" 전략에서는 이 문제가 더 치명적일 수 있습니다. 사업 포트폴리오가 넓을수록, 핵심 인력 유지 실패의 파급범위도 더 넓어지기 때문입니다.

semiconductor engineers meeting in fab office

7. 삼성 파업 이슈, 실적보다 더 위험한 것은 신뢰 훼손이다

최근 로이터 보도를 보면 삼성 노조는 보상 격차 문제 등을 이유로 장기 파업 가능성을 계속 제기해 왔습니다. 보도 시점 기준으로는 5월 21일부터 18일간 파업 계획이 거론됐고, 협상이 불발되면 5만명 이상이 참여할 수 있다는 경고도 나왔습니다.

물론 실제 생산 차질이 어느 정도일지는 별개 문제입니다. 반도체 공장은 일반 제조업과 달리 완전 가동 중단이 쉽지 않고, 숙련도와 공정 특성상 파업의 영향도 라인별로 다를 수 있습니다. 하지만 시장이 보는 더 큰 위험은 생산량 몇 퍼센트보다도 신뢰의 문제입니다.

고객사는 공급 안정성을 가장 중요하게 본다
AI 메모리 수요가 강한 시기에는 납기 지연 우려가 더 민감하다
경쟁사는 이 틈에 고객과 인재를 동시에 흡수하려 한다
내부 사기는 떨어지고, 외부 이미지는 "사람이 흔들리는 회사"로 읽힐 수 있다

특히 지금은 단순 경기 사이클이 아니라 AI 반도체 주도권 경쟁 국면입니다. 이런 시기에 노사 갈등이 장기화되면, 실적 발표 숫자보다 더 오래 남는 상처가 될 수 있습니다. 메모리와 파운드리 모두에서 삼성의 전략은 결국 "사람"이 버텨야 실행되기 때문입니다.

8. 정리, 삼성 DS의 문제는 실적 부진이 아니라 성과의 분배와 신뢰다

정리하면 삼성전자 DS는 최근 실적만 보면 확실히 살아났습니다. 2026년 1분기 영업이익 53조7천억원은 그 자체로 매우 강한 숫자입니다. 하지만 경쟁은 이제 단순 실적 경쟁이 아닙니다.

SK하이닉스는 더 높은 수익성, 더 공격적인 성과급, 더 강한 AI 메모리 리더 이미지를 갖고 있고
마이크론은 HBM과 AI 서버 메모리 수혜를 바탕으로 메모리 3강 경쟁을 더 치열하게 만들고 있으며
TSMC는 이익공유 체계를 통해 글로벌 수준의 보상 설득력을 보여주고 있고
엔비디아는 주식보상과 성장 서사로 핵심 인재를 붙잡고 있습니다

반면 삼성은 실적 회복에도 불구하고, 직원들 입장에서는 "우리가 만드는 성과가 경쟁사만큼 보상과 자부심으로 연결되지 않는다"는 인식이 퍼질 수 있는 환경에 놓여 있습니다. 이 인식이 계속되면 핵심 인력 이동, 조직 피로, 인재 고갈 우려는 더 커질 수밖에 없습니다.

삼성전자는 여전히 막강한 기술력과 생산 기반을 가진 회사입니다. 그래서 더더욱 지금 중요한 것은 숫자 몇 개를 더 잘 찍는 것이 아니라, 성과를 조직 신뢰로 연결하는 일일지도 모릅니다. 이번 파업 이슈도 감정 싸움으로 길게 끌기보다, 실적 회복의 과실을 어떻게 공정하게 나누고 미래 경쟁력을 함께 만들지에 대한 해법으로 잘 풀리길 바랍니다.

참고 자료

Samsung Electronics Announces First Quarter 2026 Results, Samsung Newsroom
SK hynix Announces 1Q26 Financial Results, SK hynix Newsroom
SK hynix Posts Record Annual Financial Results in 2025, SK hynix Newsroom
Samsung Electronics Employees Celebrate Major Year-end Bonuses, BusinessKorea
SK hynix to pay record 2,964% bonus after record-high profits, The Korea Herald
Micron revenue almost triples, tops estimates as demand for memory soars, CNBC
Micron Benefits, ESPP and RSU information, Micron
TSMC Board of Directors Meeting Resolutions, SEC Form 6-K
Reuters 보도: 삼성 노사 갈등, 보상 격차, 인력 이동, AI 반도체 경쟁 관련 기사들 (2026년 4~5월)
Fortune, Nvidia stock-based compensation and talent retention article

caveman 공식 주소, 역할, 기능, 기대 효과, 사용자 반응, 그리고 OpenClaw 적용 방법 정리

dragom — Mon, 18 May 2026 11:28:13 +0900

caveman 공식 주소, 역할, 기능, 기대 효과, 사용자 반응, 그리고 OpenClaw 적용 방법 정리

AI 코딩 에이전트를 오래 써본 사람이라면 한 번쯤 이런 생각을 하게 됩니다. 답은 맞는데 너무 길다, 매번 비슷한 군더더기가 붙는다, 정작 중요한 내용은 몇 줄인데 토큰은 훨씬 더 많이 나간다, 같은 문제 말입니다.

이런 불만에 아주 밈스럽고도 실용적인 방식으로 접근한 프로젝트가 바로 caveman입니다. 이름 그대로 AI가 "원시인처럼" 짧고 거칠게 말하게 만들어 출력 토큰을 줄이는 도구인데, 단순한 농담 프로젝트로 끝나지 않고 Claude Code, Codex, Gemini, Cursor, OpenClaw 같은 다양한 에이전트 환경에 실제로 붙여 쓸 수 있게 설계되어 있습니다.

이번 글에서는 caveman의 공식 주소, 무슨 역할을 하는지, 어떤 기능이 있는지, 왜 주목받는지, 사용자들은 어떻게 반응하는지, 그리고 OpenClaw에 어떻게 적용하는지까지 한 번에 정리해 보겠습니다.

JuliusBrussee caveman GitHub repository screenshot

1. caveman 공식 주소

GitHub 저장소: https://github.com/JuliusBrussee/caveman
공식 소개 페이지: https://www.getcaveman.dev/
설치 문서: INSTALL.md
OpenClaw: https://openclaw.ai

2026년 5월 18일 기준 GitHub API에서 확인되는 caveman 저장소는 약 6.1만 stars, 3,400개 이상 forks를 기록하고 있습니다. 단기간에 이 정도 반응을 얻었다는 점만 봐도 단순한 장난감 프로젝트 이상이라는 것을 알 수 있습니다.

2. caveman은 무엇을 하는 도구인가

caveman의 핵심 역할은 간단합니다. AI의 답변에서 불필요한 말, 장황한 서론, 반복적인 친절 멘트, 과도한 문장 연결을 줄이고 기술적 핵심만 남기게 만드는 것입니다.

예를 들어 일반적인 에이전트가 다음처럼 답할 수 있습니다.

The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle...

caveman을 적용하면 이렇게 압축됩니다.

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.

핵심은 정답의 기술적 내용은 유지하면서 말만 짧게 만드는 것입니다. README에서도 같은 표현을 씁니다. Brain still big. Mouth small.

3. caveman의 주요 기능

caveman은 단순히 "짧게 말해" 정도의 프롬프트가 아닙니다. 여러 에이전트 환경에 맞게 쓸 수 있는 기능 세트로 구성돼 있습니다.

3-1. 기본 압축 모드

lite: 과한 수식어와 군더더기를 줄이되 문장형은 유지
full: 관사와 장식 표현을 크게 덜어내는 대표 모드
ultra: 훨씬 더 전보체처럼 압축하는 모드
wenyan: 더 강한 축약 버전까지 제공

즉, "짧게"에도 강도 조절이 있습니다. 상황에 따라 너무 거칠지 않게 줄일 수도 있고, 정말 토큰을 아끼는 방향으로 몰아갈 수도 있습니다.

3-2. 명령 단위 확장 기능

/caveman: 일반 응답 압축
/caveman-commit: 짧고 일관된 커밋 메시지 생성
/caveman-review: PR 코멘트를 한 줄 중심으로 요약
/caveman-stats: 세션에서 얼마나 토큰을 줄였는지 추적
/caveman-compress: 메모 파일이나 장문 컨텍스트 자체를 더 짧게 재작성

3-3. MCP와 서브에이전트 방향 확장

README 기준으로 caveman은 단일 말투 변경에 그치지 않고 MCP 서버 설명 압축, subagent 스타일 일관화, 메모리 파일 축약까지 이어집니다. 즉, 출력만 짧게 하는 것이 아니라 에이전트 생태계 전체에서 토큰 낭비를 줄이는 방향으로 확장되고 있습니다.

caveman token saving chart github

4. 기대 효과, 정말 체감될까

프로젝트가 강조하는 기대 효과는 크게 네 가지입니다.

4-1. 출력 토큰 절감

README에 공개된 벤치마크 기준으로 평균 약 65%의 출력 토큰 감소가 제시됩니다. 일부 작업은 80% 이상 절감되는 예시도 나옵니다. React 설명, PostgreSQL 설정, 보안 리뷰 같은 사례가 대표적입니다.

4-2. 체감 속도 개선

응답이 짧아지면 읽는 속도도 빨라집니다. 실제로 사용자가 매번 장문의 친절한 설명보다 핵심 수정 포인트만 받고 싶어 하는 경우, 작업 흐름이 훨씬 경쾌해집니다.

4-3. 가독성 향상

흥미로운 점은 caveman이 단순히 비용 절감 도구로만 받아들여지지 않는다는 것입니다. Hacker News 토론에서는 "오히려 핵심이 더 잘 보인다", "설명이 더 선명하게 느껴진다", "불필요한 포장을 벗겨내는 느낌이 있다"는 반응도 나왔습니다.

4-4. 문맥 관리 효율 증가

에이전트 작업은 한 번의 답변만 중요한 것이 아닙니다. 누적되는 메모, 프로젝트 지침, 세션 로그가 점점 커지는데, caveman 계열 도구는 이런 장기 컨텍스트 자체를 더 조밀하게 줄이는 방향까지 노립니다. 이 점은 대형 프로젝트일수록 의미가 커집니다.

5. 사용자 반응은 어땠나

caveman은 공개 직후부터 꽤 강한 반응을 끌어냈습니다.

GitHub Discussions에서 개발자는 caveman이 Hacker News 프론트 페이지에 올랐고 반응이 매우 컸다고 직접 언급했습니다.
LinkedIn 등 외부 반응에서도 "주말 사이 완전히 터졌다"는 표현이 나왔습니다.
GitHub star 수가 짧은 기간 안에 급증하면서, 단순 밈 프로젝트가 아니라 실제 설치해서 써보는 사람이 많다는 점이 확인됐습니다.

물론 반응이 모두 일방적으로 찬양 일색은 아닙니다. 대표적인 논쟁은 다음과 같습니다.

5-1. "짧게 말하면 성능이 떨어지는 것 아닌가"

이건 가장 자주 나오는 질문입니다. caveman 측의 입장은 분명합니다. 이 도구는 숨겨진 reasoning token을 줄이려는 것이 아니라, 사용자에게 보이는 출력 문장을 압축하려는 것이라는 설명입니다. 즉, "생각하는 뇌"를 줄이는 것이 아니라 "입 밖으로 나오는 말"을 줄인다는 주장입니다.

5-2. "모든 상황에 맞는 건 아니다"

이 지적도 타당합니다. 보안 경고, 삭제 확인, 다단계 절차 안내처럼 오해 가능성이 낮아야 하는 상황에서는 너무 압축된 말투가 오히려 위험할 수 있습니다. 실제 caveman 규칙에도 이런 상황에서는 일반적인 명료한 문장으로 돌아가라고 적혀 있습니다.

5-3. "출력 토큰보다 입력과 추론 토큰이 더 비싼 것 아닌가"

이 역시 중요한 지적입니다. caveman만으로 모든 비용 문제가 해결되지는 않습니다. 하지만 출력이 긴 에이전트 환경에서는 분명한 절감이 있고, 나아가 메모리 파일과 프롬프트 구조까지 줄이려는 확장 방향이 있기 때문에 완전히 가벼운 농담으로 끝날 프로젝트는 아니라는 평가도 가능합니다.

Hacker News caveman discussion screenshot

6. 어떤 사람에게 추천할까

caveman은 모든 사용자에게 똑같이 추천되지는 않습니다. 특히 아래와 같은 사람에게 잘 맞습니다.

6-1. 에이전트를 자주 쓰는 개발자

Claude Code, Codex, Cursor, Gemini CLI, OpenClaw 같은 도구를 계속 쓰는 개발자라면, 장황한 응답이 반복될 때 피로감이 큽니다. 이때 caveman은 꽤 실용적입니다.

6-2. 핵심만 빠르게 보고 싶은 사람

설명의 품질보다도 바로 수정 포인트, 바로 명령, 바로 판단을 원하는 스타일이라면 잘 맞습니다.

6-3. 채팅형 에이전트를 업무 도구로 쓰는 팀

슬랙, 디스코드, 텔레그램, OpenClaw 같은 채널 기반 에이전트 환경에서는 답변이 길수록 피로도가 올라갑니다. 이때 caveman은 팀 내 응답 톤을 정리하는 역할도 할 수 있습니다.

6-4. 토큰 비용과 지연 시간을 민감하게 보는 사용자

사용량이 크면 작은 압축도 장기적으로 차이를 만듭니다. 특히 반복 작업이 많은 경우 더욱 그렇습니다.

7. 반대로 이런 상황에서는 신중해야 한다

초보자 교육처럼 설명이 자세해야 하는 경우
법률, 보안, 삭제, 결제, 권한 변경처럼 오해가 치명적인 경우
팀 문화상 지나치게 거친 말투가 어색할 수 있는 경우
답변 길이보다 reasoning 품질 자체가 더 중요한 고난도 분석 작업

즉 caveman은 무조건 항상 정답이라기보다, 짧은 응답이 실제 생산성을 높이는 구간에서 강한 도구라고 보는 편이 정확합니다.

8. OpenClaw에는 어떻게 적용하나

OpenClaw는 여러 에이전트를 하나의 게이트웨이로 묶어 메신저와 연결해 주는 환경입니다. 이런 구조에서는 에이전트가 답을 너무 길게 하는 순간, 채팅 UX가 급격히 무거워집니다. caveman이 OpenClaw에서 특히 흥미로운 이유가 여기 있습니다.

8-1. 공식 설치 방식

npx -y github:JuliusBrussee/caveman -- --only openclaw

README와 INSTALL.md에 따르면 OpenClaw용 설치는 크게 두 가지를 수행합니다.

~/.openclaw/workspace/skills/caveman/SKILL.md 생성
~/.openclaw/workspace/SOUL.md 에 caveman 부트스트랩 블록 추가

왜 두 단계가 필요하냐면, OpenClaw는 스킬을 필요할 때 읽을 수 있어야 하고, 동시에 세션마다 기본 말투 지침도 주입해야 하기 때문입니다.

8-2. OpenClaw에 적용되면 기대할 수 있는 점

텔레그램, 디스코드, 슬랙 같은 채팅 채널에서 응답이 더 짧고 선명해짐
반복적인 친절 멘트나 장문 설명이 줄어듦
긴 작업에서도 사용자가 읽어야 할 양이 줄어듦
에이전트의 "업무형 비서" 느낌이 더 강해짐

8-3. 실제로 무엇이 바뀌는가

OpenClaw 적용 후의 핵심 변화는 단순합니다.

caveman 스킬이 워크스페이스에 설치된다.
SOUL.md에 "항상 짧게 말하라"는 성격 지침이 추가된다.
따라서 새 세션부터 에이전트가 기본적으로 더 짧고 밀도 있게 말한다.

중요한 점은 이 방식이 OpenClaw의 스킬 구조와 페르소나 주입 구조를 모두 활용한다는 것입니다. 그냥 프롬프트 하나 덧붙이는 수준보다, 환경에 맞춘 적용이라고 볼 수 있습니다.

OpenClaw workspace skills caveman SOUL diagram

9. OpenClaw 사용자 관점에서 기대와 한계

OpenClaw에 caveman을 붙였을 때 가장 기대되는 것은 채팅 기반 AI 비서의 응답 밀도 개선입니다. 메신저로 AI를 쓸 때 사용자는 대개 논문식 설명보다 실무형 정답을 원합니다. 그런 점에서 caveman은 꽤 잘 맞습니다.

다만 한계도 분명합니다.

짧아진 말투가 항상 더 친절한 것은 아니다
모든 사용자가 그 스타일을 선호하지는 않는다
경고나 절차 안내에서는 다시 일반 모드가 더 안전할 수 있다

그래서 가장 좋은 사용법은 보통 이렇습니다. 기본 응답은 짧게 유지하되, 위험한 작업이나 복잡한 설명에서는 자동으로 풀어 말하게 하는 것입니다. caveman 자체도 이미 이런 예외 상황을 염두에 둔 규칙을 포함하고 있습니다.

10. 정리

caveman은 처음 보면 농담처럼 보입니다. 이름도 그렇고 톤도 밈에 가깝습니다. 하지만 그 안쪽에는 꽤 진지한 문제의식이 있습니다. AI 에이전트는 너무 자주, 너무 길게, 너무 많은 토큰을 쓰며 말한다는 문제입니다.

그리고 caveman은 이 문제에 대해 매우 직접적인 답을 내놓습니다. "말을 줄여라. 하지만 핵심은 줄이지 마라."

짧은 답이 곧 좋은 답은 아닙니다. 하지만 좋은 답이 꼭 길 필요도 없다는 점은 많은 사용자가 이미 체감하고 있습니다. 그래서 caveman은 밈이면서도 실용적이고, 가볍게 시작했지만 생각보다 오래 살아남을 가능성이 높은 프로젝트로 보입니다.

특히 OpenClaw처럼 메신저 기반 AI 비서를 운용하는 환경이라면, caveman은 단순한 장난이 아니라 응답 품질의 체감 방식을 바꾸는 작은 구조 개선이 될 수 있습니다.

참고 링크

Codex CLI를 Proxmox, Home Assistant, Synology NAS, OpenCloud LXC에 설치해 쓰는 방법

dragom — Tue, 12 May 2026 12:09:30 +0900

Codex CLI를 Proxmox, Home Assistant, Synology NAS, OpenCloud LXC에 설치해 쓰는 방법

OpenAI의 Codex CLI는 터미널 안에서 코드 읽기, 수정, 명령 실행까지 이어지는 로컬 코딩 에이전트다. 직접 써보면 단순 챗봇보다 훨씬 실무적이고, 특히 홈랩이나 서버 운영 환경에서 진가가 나온다.

이번 글은 Proxmox, Home Assistant, Synology NAS, OpenCloud LXC 네 가지 환경에서 Codex CLI를 안정적으로 굴리는 방법을 정리한 것이다. 특히 많이 헷갈리는 부분인 AGENTS.md vs AGENT.md, Home Assistant에서 재부팅 후 설정이 날아가는 문제, Synology에서 Docker로 배포하면서 SSH 키를 안전하게 넣는 방법까지 같이 다룬다.

먼저 결론부터:

공식 설치 기본값은 npm i -g @openai/codex 이다.
파일명은 AGENT.md가 아니라 AGENTS.md 가 맞다.
Home Assistant의 Terminal & SSH 애드온에서는 /config 아래만 영속 경로로 생각하는 게 안전하다.
Synology는 직접 설치보다 Docker/Container Manager 컨테이너로 분리하는 편이 관리가 훨씬 낫다.

이번 수정본은 명령어와 설정 예시를 복붙하기 쉬운 코드 스니펫 형태로 다시 정리했다. 설명은 짧게, 코드는 바로 실행 가능한 형태로 최대한 유지했다.

OpenAI Codex CLI terminal screenshot

공식 기준으로 확인한 핵심 포인트

OpenAI 공식 문서는 Codex CLI 설치 방법으로 npm i -g @openai/codex 를 안내한다.
GitHub 저장소에는 npm 설치 외에도 플랫폼별 바이너리 릴리스 사용법이 있다.
커스텀 지시 파일 이름은 AGENTS.md 이며, Codex는 전역 ~/.codex/AGENTS.md 와 프로젝트별 AGENTS.md 를 읽는다.
Home Assistant 공식 Terminal & SSH 문서에는 설정 디렉터리가 /config 라고 명시되어 있다.

AGENT.md 말고 AGENTS.md가 맞는 이유

이 부분은 헷갈리기 쉬운데, 현재 Codex 공식 문서와 저장소 기준으로는 AGENTS.md 가 맞다. Codex는 작업 시작 전에 이 파일을 읽고, 전역 지침과 프로젝트별 지침을 계층적으로 합친다.

즉 아래처럼 두는 게 정석이다.

파일 경로

~/.codex/AGENTS.md
/path/to/project/AGENTS.md

예를 들어 홈랩용 공통 규칙은 전역에, 특정 리포지토리 전용 빌드/배포 규칙은 프로젝트 루트의 AGENTS.md 에 넣으면 된다.

공통 준비물

인터넷 연결
OpenAI API 키 또는 ChatGPT 로그인 가능한 계정
작업용 디렉터리 하나, 예: ~/workspace
SSH 키 한 쌍(원격 Git, 서버 접근용)
지속 설정용 AGENTS.md

추천 디렉터리 구조는 다음 정도면 충분하다.

디렉터리 구조 예시

~/workspace/
  AGENTS.md
  project-a/
  project-b/
~/.codex/
  AGENTS.md
  config.toml

1. Proxmox LXC에 Codex CLI 설치하기

Proxmox에서는 Ubuntu 24.04 또는 Debian 12 기반 LXC 에 설치하는 구성이 가장 단순하다. Codex CLI 자체는 무겁지 않아서, 별도 VM 없이 LXC로도 충분하다.

Proxmox VE dashboard

권장 컨테이너 조건

OS: Ubuntu 24.04 LTS 또는 Debian 12
vCPU: 2개 이상
RAM: 2GB 이상
Storage: 8GB 이상
SSH 접속 가능 상태

1-1. 기본 패키지 설치

bash

sudo apt update
sudo apt install -y curl git ca-certificates build-essential unzip

1-2. Node.js 22 계열 설치

Codex CLI는 공식적으로 npm 설치를 안내하므로, LXC에서는 Node.js를 먼저 안정적으로 넣는 게 좋다.

bash

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v
npm -v

1-3. Codex CLI 설치

bash

sudo npm install -g @openai/codex
codex --version

1-4. 전역 지침 파일 만들기

bash

mkdir -p ~/.codex
cat > ~/.codex/AGENTS.md <<'EOF'
# Global AGENTS.md

- Explain risky commands before running them.
- Prefer small, reviewable diffs.
- For homelab services, show rollback steps.
- Use Korean unless the repository already uses English docs.
EOF

1-5. 프로젝트 지침 파일 만들기

bash

mkdir -p ~/workspace/homelab
cat > ~/workspace/homelab/AGENTS.md <<'EOF'
# Homelab repo rules

- Always confirm systemctl unit names before editing.
- When editing docker compose files, validate indentation carefully.
- For reverse proxy changes, summarize exposed ports and domains.
EOF

1-6. 실행

bash

cd ~/workspace/homelab
codex

첫 실행에서는 로그인 또는 API 키 설정을 안내한다. 이 방식은 일반적인 Proxmox LXC에서 가장 무난하고, 업데이트도 단순하다.

2. Home Assistant Terminal & SSH에서 설치할 때, 왜 매번 초기화될까?

핵심은 간단하다. 애드온 컨테이너 내부 파일시스템은 휘발성으로 봐야 하고, /config만 영속 저장소로 취급해야 한다.

즉, 아래 경로에 뭔가를 설치하면 재시작/업데이트 때 사라질 수 있다.

휘발 가능 경로

/root
/usr/local
/tmp
/app
~

반대로 아래처럼 /config 아래에 Codex 관련 파일을 몰아두면 살아남는다.

영속 경로

/config/codex/bin
/config/codex/home
/config/codex/workspace
/config/.ssh

Home Assistant Terminal SSH addon interface

중요: Home Assistant에서는 npm 설치보다 바이너리 설치가 더 현실적일 때가 많다

공식 Terminal & SSH 애드온은 일반 리눅스 셸처럼 마음대로 패키지를 넣는 용도에 최적화되어 있지 않다. 그래서 Codex CLI 바이너리를 /config 아래에 저장하는 방식이 더 안정적이다.

2-1. 영속 디렉터리 준비

bash

mkdir -p /config/codex/bin
mkdir -p /config/codex/home
mkdir -p /config/codex/workspace
mkdir -p /config/.ssh

2-2. Codex CLI 바이너리 설치

Home Assistant 애드온은 Alpine 기반인 경우가 많아서, Linux musl 바이너리를 쓰는 쪽이 맞다.

bash

cd /config/codex/bin
curl -L -o codex.tar.gz \
  https://github.com/openai/codex/releases/latest/download/codex-x86_64-unknown-linux-musl.tar.gz

tar -xzf codex.tar.gz
mv codex-x86_64-unknown-linux-musl codex
chmod +x codex

2-3. 환경 변수 스크립트 만들기

bash

cat > /config/codex/env.sh <<'EOF'
export PATH="/config/codex/bin:$PATH"
export CODEX_HOME="/config/codex/home"
export WORKSPACE="/config/codex/workspace"
EOF

2-4. 세션마다 불러오기

bash

source /config/codex/env.sh
cd /config/codex/workspace
codex

2-5. Home Assistant에서 꼭 기억할 영속 경로

Codex 홈: /config/codex/home
작업 디렉터리: /config/codex/workspace
SSH 키: /config/.ssh
공통 지침 파일: /config/codex/home/AGENTS.md

즉, 용상님이 원하신 “재부팅 후 설정이 초기화되지 않게 하는 올바른 path”는 /config 아래 다.

2-6. Home Assistant용 AGENTS.md 예시

bash

cat > /config/codex/home/AGENTS.md <<'EOF'
# Home Assistant Codex rules

- Never modify YAML automations without showing the entity_ids involved.
- Prefer creating backups before bulk edits.
- For add-on troubleshooting, separate host issues from container issues.
- Keep examples compatible with Home Assistant OS paths under /config.
EOF

2-7. 좀 더 편하게 쓰고 싶다면

Community의 Advanced SSH & Web Terminal 애드온은 패키지 설치, init commands, SSH 키/설정 유지 등에서 더 유연하다. 다만 그래도 실제 영속 데이터는 /config에 두는 습관이 가장 중요하다.

3. Synology NAS에서는 직접 설치보다 Docker 배포가 낫다

Synology는 DSM 환경 자체에 직접 의존성을 섞기보다, Container Manager(Docker) 로 분리하는 쪽이 관리와 복구가 훨씬 쉽다. 특히 Codex CLI처럼 업데이트가 자주 있을 수 있는 도구는 컨테이너 격리가 잘 맞는다.

Synology DSM Container Manager

권장 호스트 경로

디렉터리 구조 예시

/volume1/docker/codex/
  compose.yaml
  ssh/
  codex-home/
  workspace/

3-1. NAS에서 SSH 활성화

DSM에서 제어판 → 터미널 및 SNMP → SSH 서비스 활성화 를 켠 뒤 NAS에 접속한다.

3-2. SSH 키 준비

호스트 또는 별도 관리 PC에서 키를 만들고, 컨테이너에 읽기 전용으로 마운트한다.

bash

mkdir -p /volume1/docker/codex/ssh
ssh-keygen -t ed25519 -f /volume1/docker/codex/ssh/id_ed25519
chmod 700 /volume1/docker/codex/ssh
chmod 600 /volume1/docker/codex/ssh/id_ed25519
chmod 644 /volume1/docker/codex/ssh/id_ed25519.pub

GitHub를 쓴다면 공개키 내용을 GitHub 계정의 SSH Keys에 등록하면 된다.

3-3. AGENTS.md 파일 준비

여기서도 파일명은 AGENTS.md 다.

bash

mkdir -p /volume1/docker/codex/workspace
cat > /volume1/docker/codex/workspace/AGENTS.md <<'EOF'
# Synology homelab workspace rules

- Assume files are on mounted NAS volumes.
- Avoid commands that can recursively alter /volume1 without confirmation.
- When suggesting Docker changes, include volume and permission notes.
EOF

3-4. compose.yaml 작성

yaml

services:
  codex:
    image: node:22-bookworm-slim
    container_name: codex-cli
    working_dir: /workspace
    stdin_open: true
    tty: true
    environment:
      CODEX_HOME: /home/codex/.codex
    command: >
      bash -lc "npm install -g @openai/codex && exec bash"
    volumes:
      - /volume1/docker/codex/codex-home:/home/codex/.codex
      - /volume1/docker/codex/workspace:/workspace
      - /volume1/docker/codex/ssh:/home/codex/.ssh:ro
    restart: unless-stopped

bash

cat > /volume1/docker/codex/compose.yaml <<'EOF'
services:
  codex:
    image: node:22-bookworm-slim
    container_name: codex-cli
    working_dir: /workspace
    stdin_open: true
    tty: true
    environment:
      CODEX_HOME: /home/codex/.codex
    command: >
      bash -lc "npm install -g @openai/codex && exec bash"
    volumes:
      - /volume1/docker/codex/codex-home:/home/codex/.codex
      - /volume1/docker/codex/workspace:/workspace
      - /volume1/docker/codex/ssh:/home/codex/.ssh:ro
    restart: unless-stopped
EOF

3-5. 컨테이너 실행

bash

cd /volume1/docker/codex
docker compose up -d
docker exec -it codex-cli bash

3-6. 컨테이너 안에서 초기 확인

bash

codex --version
ls -la /workspace
ls -la /home/codex/.codex

3-7. SSH known_hosts 등록

원격 Git 서버에 처음 붙을 때는 호스트 키를 등록해 둬야 덜 귀찮다.

bash

ssh-keyscan github.com >> /volume1/docker/codex/ssh/known_hosts
chmod 644 /volume1/docker/codex/ssh/known_hosts

이 구조의 장점은 분명하다.

Codex 설정은 /volume1/docker/codex/codex-home 에 남는다.
작업물은 /volume1/docker/codex/workspace 에 남는다.
SSH 키는 마운트만 바꾸면 손쉽게 교체 가능하다.
DSM 업데이트와 Codex 실행 환경을 분리할 수 있다.

4. OpenCloud LXC에서는 이렇게 잡으면 편하다

여기서는 Ubuntu/Debian 기반의 OpenCloud용 LXC 컨테이너 를 기준으로 설명한다. 사실 설치 자체는 Proxmox LXC와 거의 같고, 차이는 운영용 경로를 좀 더 명확하게 분리하는 데 있다.

Linux container terminal coding environment

권장 운영 경로

디렉터리 구조 예시

/opt/codex/bin
/opt/codex/home
/srv/codex/workspace

4-1. 시스템 패키지와 Node 설치

bash

sudo apt update
sudo apt install -y curl git ca-certificates build-essential
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

4-2. 전용 사용자 만들기

bash

sudo useradd -m -s /bin/bash codex
sudo mkdir -p /opt/codex/home
sudo mkdir -p /srv/codex/workspace
sudo chown -R codex:codex /opt/codex /srv/codex

4-3. Codex CLI 설치

bash

sudo npm install -g @openai/codex

4-4. 프로필 스크립트 추가

bash

sudo tee /etc/profile.d/codex.sh > /dev/null <<'EOF'
export CODEX_HOME=/opt/codex/home
export PATH="$PATH:/usr/bin"
EOF

4-5. 작업 지침 파일 추가

bash

sudo -u codex bash -lc 'cat > /opt/codex/home/AGENTS.md <<"EOF"
# OpenCloud LXC rules

- Prefer explicit service names and bind mounts.
- Before changing reverse proxies, summarize ports and domains.
- Keep rollback commands with every deployment plan.
EOF'

4-6. 실행

bash

sudo -u codex -H bash -lc 'cd /srv/codex/workspace && codex'

이 구성은 여러 프로젝트를 장기간 유지할 때 특히 좋다. 사용자 홈과 서비스용 데이터 경로가 명확히 분리되기 때문이다.

환경별 추천 방식 한눈에 보기

환경	추천 설치 방식	영속 경로	비고
Proxmox LXC	Node + npm 글로벌 설치	~/.codex, ~/workspace	가장 단순함
Home Assistant	바이너리 설치 권장	/config/codex, /config/.ssh	/config 밖은 날아갈 수 있음
Synology NAS	Docker/Container Manager	/volume1/docker/codex	호스트와 격리 쉬움
OpenCloud LXC	Node + npm 글로벌 설치	/opt/codex, /srv/codex/workspace	운영 경로 분리 추천

실제로 써보면 좋은 AGENTS.md 예시

아래 예시는 홈서버/셀프호스팅 작업에 맞춘 최소 규칙 세트다.

markdown

# AGENTS.md

- Use Korean for explanations unless the repo uses English docs.
- Before changing infra config, summarize ports, domains, volumes, and rollback steps.
- Ask before destructive deletes.
- Prefer compose diffs or exact file patches over vague guidance.
- After changing service configs, propose a verification checklist.

이 정도만 넣어도 Codex가 꽤 덜 엇나간다.

자주 하는 실수

AGENT.md 로 파일을 만들어 놓고 왜 안 읽냐고 하는 경우
Home Assistant에서 /root 나 ~ 에 설치해 두고 재부팅 후 사라졌다고 느끼는 경우
Synology 호스트에 직접 이것저것 설치해 DSM 업데이트와 충돌하는 경우
SSH 키를 컨테이너에 복사만 해두고 권한을 안 맞춰서 접속이 실패하는 경우

마무리

정리하면, Codex CLI는 어디서나 돌아가지만 환경별로 “어디에 설치하고, 무엇을 영속 데이터로 볼 것인가” 를 먼저 정리해야 오래 편하게 쓸 수 있다.

Proxmox LXC: 가장 표준적인 리눅스 방식
Home Assistant: /config 아래로 몰아넣기
Synology NAS: Docker로 분리, SSH 키는 볼륨 마운트
OpenCloud LXC: 운영 경로를 명확히 분리

그리고 마지막으로 다시 한 번. 파일명은 AGENTS.md 다.

참고 링크

Codex CLI를 Proxmox, Home Assistant, Synology NAS, OpenCloud LXC에 설치해 쓰는 방법

dragom — Sat, 9 May 2026 08:13:11 +0900

Codex CLI를 Proxmox, Home Assistant, Synology NAS, OpenCloud LXC에 설치해 쓰는 방법

먼저 결론부터:

공식 설치 기본값은 npm i -g @openai/codex 이다.
파일명은 AGENT.md가 아니라 AGENTS.md 가 맞다.
Home Assistant의 Terminal & SSH 애드온에서는 /config 아래만 영속 경로로 생각하는 게 안전하다.
Synology는 직접 설치보다 Docker/Container Manager 컨테이너로 분리하는 편이 관리가 훨씬 낫다.

OpenAI Codex CLI terminal screenshot

공식 기준으로 확인한 핵심 포인트

OpenAI 공식 문서는 Codex CLI 설치 방법으로 npm i -g @openai/codex 를 안내한다.
GitHub 저장소에는 npm 설치 외에도 플랫폼별 바이너리 릴리스 사용법이 있다.
커스텀 지시 파일 이름은 AGENTS.md 이며, Codex는 전역 ~/.codex/AGENTS.md 와 프로젝트별 AGENTS.md 를 읽는다.
Home Assistant 공식 Terminal & SSH 문서에는 설정 디렉터리가 /config 라고 명시되어 있다.

AGENT.md 말고 AGENTS.md가 맞는 이유

즉 아래처럼 두는 게 정석이다.

~/.codex/AGENTS.md
/path/to/project/AGENTS.md

예를 들어 홈랩용 공통 규칙은 전역에, 특정 리포지토리 전용 빌드/배포 규칙은 프로젝트 루트의 AGENTS.md 에 넣으면 된다.

공통 준비물

인터넷 연결
OpenAI API 키 또는 ChatGPT 로그인 가능한 계정
작업용 디렉터리 하나, 예: ~/workspace
SSH 키 한 쌍(원격 Git, 서버 접근용)
지속 설정용 AGENTS.md

추천 디렉터리 구조는 다음 정도면 충분하다.

~/workspace/
  AGENTS.md
  project-a/
  project-b/
~/.codex/
  AGENTS.md
  config.toml

1. Proxmox LXC에 Codex CLI 설치하기

Proxmox에서는 Ubuntu 24.04 또는 Debian 12 기반 LXC 에 설치하는 구성이 가장 단순하다. Codex CLI 자체는 무겁지 않아서, 별도 VM 없이 LXC로도 충분하다.

Proxmox VE dashboard

권장 컨테이너 조건

OS: Ubuntu 24.04 LTS 또는 Debian 12
vCPU: 2개 이상
RAM: 2GB 이상
Storage: 8GB 이상
SSH 접속 가능 상태

1-1. 기본 패키지 설치

sudo apt update
sudo apt install -y curl git ca-certificates build-essential unzip

1-2. Node.js 22 계열 설치

Codex CLI는 공식적으로 npm 설치를 안내하므로, LXC에서는 Node.js를 먼저 안정적으로 넣는 게 좋다.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v
npm -v

1-3. Codex CLI 설치

sudo npm install -g @openai/codex
codex --version

1-4. 전역 지침 파일 만들기

mkdir -p ~/.codex
cat > ~/.codex/AGENTS.md <<'EOF'
# Global AGENTS.md

- Explain risky commands before running them.
- Prefer small, reviewable diffs.
- For homelab services, show rollback steps.
- Use Korean unless the repository already uses English docs.
EOF

1-5. 프로젝트 지침 파일 만들기

mkdir -p ~/workspace/homelab
cat > ~/workspace/homelab/AGENTS.md <<'EOF'
# Homelab repo rules

- Always confirm systemctl unit names before editing.
- When editing docker compose files, validate indentation carefully.
- For reverse proxy changes, summarize exposed ports and domains.
EOF

1-6. 실행

cd ~/workspace/homelab
codex

첫 실행에서는 로그인 또는 API 키 설정을 안내한다. 이 방식은 일반적인 Proxmox LXC에서 가장 무난하고, 업데이트도 단순하다.

2. Home Assistant Terminal & SSH에서 설치할 때, 왜 매번 초기화될까?

핵심은 간단하다. 애드온 컨테이너 내부 파일시스템은 휘발성으로 봐야 하고, /config만 영속 저장소로 취급해야 한다.

즉, 아래 경로에 뭔가를 설치하면 재시작/업데이트 때 사라질 수 있다.

/root
/usr/local
/tmp
/app
~

반대로 아래처럼 /config 아래에 Codex 관련 파일을 몰아두면 살아남는다.

/config/codex/bin
/config/codex/home
/config/codex/workspace
/config/.ssh

Home Assistant Terminal SSH addon interface

중요: Home Assistant에서는 npm 설치보다 바이너리 설치가 더 현실적일 때가 많다

2-1. 영속 디렉터리 준비

mkdir -p /config/codex/bin
mkdir -p /config/codex/home
mkdir -p /config/codex/workspace
mkdir -p /config/.ssh

2-2. Codex CLI 바이너리 설치

Home Assistant 애드온은 Alpine 기반인 경우가 많아서, Linux musl 바이너리를 쓰는 쪽이 맞다.

cd /config/codex/bin
curl -L -o codex.tar.gz \
  https://github.com/openai/codex/releases/latest/download/codex-x86_64-unknown-linux-musl.tar.gz

tar -xzf codex.tar.gz
mv codex-x86_64-unknown-linux-musl codex
chmod +x codex

2-3. 환경 변수 스크립트 만들기

cat > /config/codex/env.sh <<'EOF'
export PATH="/config/codex/bin:$PATH"
export CODEX_HOME="/config/codex/home"
export WORKSPACE="/config/codex/workspace"
EOF

2-4. 세션마다 불러오기

source /config/codex/env.sh
cd /config/codex/workspace
codex

2-5. Home Assistant에서 꼭 기억할 영속 경로

Codex 홈: /config/codex/home
작업 디렉터리: /config/codex/workspace
SSH 키: /config/.ssh
공통 지침 파일: /config/codex/home/AGENTS.md

즉, 용상님이 원하신 “재부팅 후 설정이 초기화되지 않게 하는 올바른 path”는 /config 아래 다.

2-6. Home Assistant용 AGENTS.md 예시

cat > /config/codex/home/AGENTS.md <<'EOF'
# Home Assistant Codex rules

- Never modify YAML automations without showing the entity_ids involved.
- Prefer creating backups before bulk edits.
- For add-on troubleshooting, separate host issues from container issues.
- Keep examples compatible with Home Assistant OS paths under /config.
EOF

2-7. 좀 더 편하게 쓰고 싶다면

3. Synology NAS에서는 직접 설치보다 Docker 배포가 낫다

Synology DSM Container Manager

권장 호스트 경로

/volume1/docker/codex/
  compose.yaml
  ssh/
  codex-home/
  workspace/

3-1. NAS에서 SSH 활성화

DSM에서 제어판 → 터미널 및 SNMP → SSH 서비스 활성화 를 켠 뒤 NAS에 접속한다.

3-2. SSH 키 준비

호스트 또는 별도 관리 PC에서 키를 만들고, 컨테이너에 읽기 전용으로 마운트한다.

mkdir -p /volume1/docker/codex/ssh
ssh-keygen -t ed25519 -f /volume1/docker/codex/ssh/id_ed25519
chmod 700 /volume1/docker/codex/ssh
chmod 600 /volume1/docker/codex/ssh/id_ed25519
chmod 644 /volume1/docker/codex/ssh/id_ed25519.pub

GitHub를 쓴다면 공개키 내용을 GitHub 계정의 SSH Keys에 등록하면 된다.

3-3. AGENTS.md 파일 준비

여기서도 파일명은 AGENTS.md 다.

mkdir -p /volume1/docker/codex/workspace
cat > /volume1/docker/codex/workspace/AGENTS.md <<'EOF'
# Synology homelab workspace rules

- Assume files are on mounted NAS volumes.
- Avoid commands that can recursively alter /volume1 without confirmation.
- When suggesting Docker changes, include volume and permission notes.
EOF

3-4. compose.yaml 작성

cat > /volume1/docker/codex/compose.yaml <<'EOF'
services:
  codex:
    image: node:22-bookworm-slim
    container_name: codex-cli
    working_dir: /workspace
    stdin_open: true
    tty: true
    environment:
      CODEX_HOME: /home/codex/.codex
    command: >
      bash -lc "npm install -g @openai/codex && exec bash"
    volumes:
      - /volume1/docker/codex/codex-home:/home/codex/.codex
      - /volume1/docker/codex/workspace:/workspace
      - /volume1/docker/codex/ssh:/home/codex/.ssh:ro
    restart: unless-stopped
EOF

3-5. 컨테이너 실행

cd /volume1/docker/codex
docker compose up -d
docker exec -it codex-cli bash

3-6. 컨테이너 안에서 초기 확인

codex --version
ls -la /workspace
ls -la /home/codex/.codex

3-7. SSH known_hosts 등록

원격 Git 서버에 처음 붙을 때는 호스트 키를 등록해 둬야 덜 귀찮다.

ssh-keyscan github.com >> /volume1/docker/codex/ssh/known_hosts
chmod 644 /volume1/docker/codex/ssh/known_hosts

이 구조의 장점은 분명하다.

Codex 설정은 /volume1/docker/codex/codex-home 에 남는다.
작업물은 /volume1/docker/codex/workspace 에 남는다.
SSH 키는 마운트만 바꾸면 손쉽게 교체 가능하다.
DSM 업데이트와 Codex 실행 환경을 분리할 수 있다.

4. OpenCloud LXC에서는 이렇게 잡으면 편하다

Linux container terminal coding environment

권장 운영 경로

/opt/codex/bin
/opt/codex/home
/srv/codex/workspace

4-1. 시스템 패키지와 Node 설치

sudo apt update
sudo apt install -y curl git ca-certificates build-essential
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

4-2. 전용 사용자 만들기

sudo useradd -m -s /bin/bash codex
sudo mkdir -p /opt/codex/home
sudo mkdir -p /srv/codex/workspace
sudo chown -R codex:codex /opt/codex /srv/codex

4-3. Codex CLI 설치

sudo npm install -g @openai/codex

4-4. 프로필 스크립트 추가

sudo tee /etc/profile.d/codex.sh > /dev/null <<'EOF'
export CODEX_HOME=/opt/codex/home
export PATH="$PATH:/usr/bin"
EOF

4-5. 작업 지침 파일 추가

sudo -u codex bash -lc 'cat > /opt/codex/home/AGENTS.md <<"EOF"
# OpenCloud LXC rules

- Prefer explicit service names and bind mounts.
- Before changing reverse proxies, summarize ports and domains.
- Keep rollback commands with every deployment plan.
EOF'

4-6. 실행

sudo -u codex -H bash -lc 'cd /srv/codex/workspace && codex'

이 구성은 여러 프로젝트를 장기간 유지할 때 특히 좋다. 사용자 홈과 서비스용 데이터 경로가 명확히 분리되기 때문이다.

환경별 추천 방식 한눈에 보기

환경	추천 설치 방식	영속 경로	비고
Proxmox LXC	Node + npm 글로벌 설치	~/.codex, ~/workspace	가장 단순함
Home Assistant	바이너리 설치 권장	/config/codex, /config/.ssh	/config 밖은 날아갈 수 있음
Synology NAS	Docker/Container Manager	/volume1/docker/codex	호스트와 격리 쉬움
OpenCloud LXC	Node + npm 글로벌 설치	/opt/codex, /srv/codex/workspace	운영 경로 분리 추천

실제로 써보면 좋은 AGENTS.md 예시

아래 예시는 홈서버/셀프호스팅 작업에 맞춘 최소 규칙 세트다.

# AGENTS.md

- Use Korean for explanations unless the repo uses English docs.
- Before changing infra config, summarize ports, domains, volumes, and rollback steps.
- Ask before destructive deletes.
- Prefer compose diffs or exact file patches over vague guidance.
- After changing service configs, propose a verification checklist.

이 정도만 넣어도 Codex가 꽤 덜 엇나간다.

자주 하는 실수

AGENT.md 로 파일을 만들어 놓고 왜 안 읽냐고 하는 경우
Home Assistant에서 /root 나 ~ 에 설치해 두고 재부팅 후 사라졌다고 느끼는 경우
Synology 호스트에 직접 이것저것 설치해 DSM 업데이트와 충돌하는 경우
SSH 키를 컨테이너에 복사만 해두고 권한을 안 맞춰서 접속이 실패하는 경우

마무리

Proxmox LXC: 가장 표준적인 리눅스 방식
Home Assistant: /config 아래로 몰아넣기
Synology NAS: Docker로 분리, SSH 키는 볼륨 마운트
OpenCloud LXC: 운영 경로를 명확히 분리

그리고 마지막으로 다시 한 번. 파일명은 AGENTS.md 다.

참고 링크

데드데드 데몬즈 디디디디 디스트럭션: 작품 정보와 감상평 정리

dragom — Mon, 13 Apr 2026 22:59:21 +0900

데드데드 데몬즈 디디디디 디스트럭션: 세계관 정보 + 내 감상 정리

아포칼립스와 청춘 일상을 동시에 좋아한다면, 이 작품은 꽤 독특하게 꽂힌다. 거대한 모함이 도쿄 상공에 떠 있는 종말 직전의 분위기 속에서도, 소녀들의 일상과 관계가 계속 흘러간다. 그 이질감이 이 작품의 핵심 매력이다.

작품 기본 정보

원작: 아사노 이니오(浅野いにお) 만화, 전 12권
연재: 2014~2022 (빅 코믹 스피리츠)
애니 제작: Production +h.
감독: 쿠로카와 토모유키
각본: 요시다 레이코
영화판: 전/후편(2024.03.22 / 2024.05.24)
애니 시리즈판: 전 18화(2024년 전개)

왜 이 작품이 화제가 됐나

“외계 모함이 떠 있는 세상인데 사람들은 또 일상을 산다”는 설정 자체가 강력하다.
극장판과 시리즈판의 구성/결말이 완전히 같은 길로 가지 않아, 팬들 사이에서 비교 감상이 활발했다.
특히 0화를 먼저 배치한 구성은 호불호를 만들면서도, 시청 동기를 강하게 건드렸다는 반응이 많았다.

내 감상평 (정리본)

아포칼립스 장르를 좋아하는 내 취향에서는, 0화에서 던진 플롯이 끝까지 더 강하게 이어졌다면 훨씬 더 재밌었을 것 같다. 다만 반대로 생각하면, 0화가 없었다면 초반 인상만 보고 “소녀 사이의 순정물인가?”라고 오해해서 아예 안 봤을 가능성이 크다.

결국 이 작품을 계속 보게 만든 건, 0화가 던진 강한 끌림 위에 소녀들의 관계성과 감정선이 얹히고, 그게 다시 아포칼립스 세계관의 미스터리와 맞물려 돌아가는 구조였다. 초반에는 다소 어렵고 꼬여 보일 수 있지만, 후반에 왜 서사가 그렇게 꼬였는지 이해되고 나면 불편함은 크게 줄어든다.

정리하면, 끌어당기는 힘, 메시지, 세계관은 충분히 좋았다. 다만 결말은 개인적으로 조금 아쉽다. 더 장대하게 치고 올라가길 기대했는데, 어느 순간 급히 정리된 느낌이 남는다. 그럼에도 전체적으로는 충분히 볼만한 작품이다.

한 줄 결론

0화가 만든 강한 후킹 + 소녀 서사 + 종말 미스터리의 조합은 유효했고, 결말의 아쉬움만 감수하면 추천 가능한 작품.

참고/출처

스노우볼 어스 애니메이션 총정리: 방영일·주제·제작사·원작·기대 포인트

dragom — Sun, 12 Apr 2026 00:21:09 +0900

스노우볼 어스 애니메이션, 왜 지금 이렇게 재밌을까? (방영 정보·주제·제작진·원작·반응 정리)

요즘 스노우볼 어스(Snowball Earth)가 재미있다는 반응이 빠르게 늘고 있습니다. 저도 보고 나서, 이 작품이 왜 먹히는지 궁금해져서 방영 정보부터 주제/매력, 제작사, 원작, 초기 반응까지 한 번에 정리해봤습니다.

출처: TV 애니메이션 스노우볼 어스 공식 사이트

1) 언제 방영하나?

첫 방영: 2026년 4월 3일
편성: 매주 금요일 23:30 (JST), 닛폰TV계 FRIDAY ANIME NIGHT 블록
분량: 1화 약 23분, 13화 구성(공개 정보 기준)

즉, 전형적인 봄 시즌 화제작 타이밍에 맞춰서 들어왔고, 편성 슬롯도 메이저 시간대라 접근성이 좋습니다.

2) 주제는 뭐가 핵심인가?

SF × 괴수 × 로봇 액션이라는 익숙한 장르 조합인데, 배경을 지구 빙하기(스노우볼 어스)로 바꿔서 분위기를 완전히 새롭게 만들었습니다.

인류를 구하던 소년 파일럿이 귀환했더니, 지구는 눈과 얼음으로 뒤덮인 세계
전투물의 스케일과, "약속"/"상실" 같은 감정선이 같이 감
괴수전 + 메카물인데도 세계관 미스터리가 강한 타입

빙결된 세계관이 작품 분위기를 확 끌어올립니다.

3) 제작사는 어디? 스태프는?

애니메이션 제작: 스튜디오 KAI
감독: 사카이 무네히사(境宗久)
시리즈 구성: 무라코시 시게루(村越繁)
캐릭터 디자인/총작감: 코노 토시야
음악: 카토 타츠야, 츠츠미 히로아키, YUKI KANESAKA

공식 공개된 제작진 라인업만 봐도, 액션 연출 + 분위기 음악을 동시에 잡겠다는 의도가 분명합니다.

4) 원작은 어떤 작품인가?

원작: 츠지츠구 유우히로(辻次夕日郎)
연재: 쇼가쿠칸 「월간! 스피리츠」
연재 시작: 2021년 1월
코믹스: 2026년 4월 기준 11권(공개 정보 기준)

공식 사이트 기준으로는 시리즈 누계 80만부 돌파가 강조되고 있고, 해외(영문권) 단행본 발매도 진행되면서 인지도가 확 올라온 케이스입니다.

원작 팬층이 이미 형성되어 있어 애니 유입도 빠른 편입니다.

5) 사람들 기대/반응은 어떤가?

초기 반응은 요약하면 “설정/분위기 호평 + CG 호불호 공존”입니다.

Anime Corner 사전 기대 순위: 2026 봄 기대작 투표(11,000표+)에서 스노우볼 어스 54위(0.49%)
MAL 초반 지표: Score 6.62, Members 12,326 (조회 시점 기준)
커뮤니티 코멘트: 1화 기준 세계관 잠재력/감정선은 좋다는 의견이 많고, 일부는 CG 사용량에 아쉬움 제기

정리하면, 초대박형 스타트라기보다 “입소문형 성장작”에 가깝습니다. 대신 이런 작품은 중반 이후 전개가 터지면 체감 평가가 확 올라가는 경우가 많습니다.

6) 이런 분들께 특히 추천

괴수물, 메카물, 포스트 아포칼립스 세계관을 좋아하는 분
전투만 많은 작품보다, 캐릭터 심리/관계선도 같이 보는 분
초반 떡밥 회수를 기다리며 보는 타입

마무리

스노우볼 어스는 화려한 장르 포장보다도, “멸망 이후의 지구에서 약속을 지키려는 이야기”라는 중심축이 분명한 작품입니다. 지금 초반만 보고 판단하기엔 아까운 타입이라, 3~4화까지는 꼭 보고 결정해보시길 추천합니다.

참고/출처

TV 애니메이션 스노우볼 어스 공식 사이트: https://snowballearth.net/
TOHO animation Store 뉴스: https://tohoanimationstore.us/blogs/news/snowball-earth-anime-reveals-new-trailer-and-key-visual-ahead-of-april-premiere
MyAnimeList 작품 페이지: https://myanimelist.net/anime/62068/Snowball_Earth
Anime Corner 기대작 랭킹: https://animecorner.me/spring-2026-most-anticipated-anime-rankings/
Wikipedia (원작/애니 개요): https://en.wikipedia.org/wiki/Snowball_Earth_(manga)

※ 본문 수치(점수/멤버 수/랭킹)는 집계 시점에 따라 변동될 수 있습니다.

3D 프린터 워핑(Warping) 현상과 뱀부랩 출력 실패 방지 세팅

dragom — Sat, 11 Apr 2026 23:22:07 +0900

OpenClaw에 3D 프린터 워핑(Warping) 현상과 뱀부랩 출력 실패 방지 세팅

3D 프린팅에서 워핑(Warping, 위핑)은 출력물이 베드에 제대로 안착하지 못하고 모서리나 바닥면이 위로 들뜨는 현상입니다. 뜨거운 상태로 압출된 플라스틱이 상온에서 식으면서 수축(Shrinkage)하게 되는데, 이 수축 응력이 베드 접착력보다 강해질 때 발생합니다.

1. 취약한 재질 및 출력물 형태

워핑 현상은 특정 재질과 출력물 형태에서 특히 자주 발생합니다.

취약 재질: ABS, ASA, PC, Nylon 등 수축률이 높은 고온 필라멘트. (최근에는 PETG도 쿨링이나 베드 안착이 잘못될 경우 수축 응력으로 인해 베드에서 들뜨거나 베드 유리를 파손시키는 경우가 많아 위험 소재로 주의해야 합니다.)
취약 형태: 바닥 면적이 넓고 평평한 형태, 날카로운 직각 모서리를 가진 형태, 서포트가 부족한 오버행(Overhang) 구조

2. 뱀부랩(Bambu Lab)에서의 경고와 진짜 위험성

워핑으로 인해 출력물 모서리가 들뜨면, 그 부분의 높이가 예상보다 높아집니다. 뱀부랩 프린터에서는 이렇게 들뜬 부분에 노즐이 부딪히며 저항이 발생할 때, 이를 필라멘트 압출 불량으로 오인하여 아래와 같은 노즐 막힘(Nozzle Clog) 혹은 필라멘트 꼬임(Tangle) 경고를 띄울 수 있습니다.

(뱀부랩 프린터 화면이나 앱에 표시되는 Extruder Clog / Nozzle Clog 경고 메시지)

경고를 무시하고 인쇄를 계속(Resume)할 경우의 위험성:

진짜 노즐 막힘 발생: 들뜬 출력물이 노즐 구멍을 물리적으로 막은 상태로 압출이 시도되면서 익스트루더 기어가 갈리거나 실제 막힘이 발생할 수 있습니다.
출력물 탈락: 인쇄 중 노즐이 들뜬 모서리를 반복적으로 때리면서, 출력물 전체가 베드에서 완전히 떨어져 나가 인쇄가 완전히 실패할 수 있습니다.
구조물 훼손 및 뭉그러짐: 인쇄 높이의 오차로 인해 상층부 레이어가 심하게 짓눌리면서 예상치 못한 뭉그러짐이나 표면 파괴가 일어납니다.

3. 워핑 방지를 위한 뱀부 스튜디오(Bambu Studio) 세팅 가이드

이러한 현상을 막기 위해 뱀부 스튜디오에서 적용할 수 있는 핵심 세팅들을 소개합니다.

베드 온도(Bed Temperature) 조절: 기본 온도에서 5~10도 정도 올려 접착력을 강화하세요. (단, 필라멘트의 유리전이온도를 넘지 않도록 주의)
브림(Brim) 설정 활성화: 'Others' 탭에서 Brim Type을 'Outer brim only' 또는 수축이 심한 경우 'Outer and inner brim'으로 설정하세요. Brim width를 5~10mm 이상으로 넓게 주면 바닥을 꽉 잡아주어 들뜸을 방지합니다.
파트 쿨링 팬(Part Cooling Fan) 속도 감소: ABS, ASA, 그리고 PETG 출력 시 쿨링이 강하면 급격히 수축합니다. 필라멘트 설정에서 팬 속도를 낮추거나 아예 끄는 것을 권장합니다.
보조 팬(Auxiliary Fan) 끄기: 챔버 내부의 한쪽 방향에서 강한 바람이 불면 출력물 양쪽의 냉각 속도가 달라져 한쪽만 들뜨는 워핑이 발생합니다. 수축에 민감한 재질을 쓸 땐 꺼두는 것이 좋습니다.

올바른 세팅으로 노즐 막힘 경고와 출력 실패 스트레스에서 벗어나세요!

글로벌 에너지 생명선, 호르무즈 해협: 중요성과 이란 혁명수비대의 갈등

dragom — Thu, 26 Mar 2026 23:20:54 +0900

글로벌 에너지 생명선, 호르무즈 해협: 중요성과 이란 혁명수비대의 갈등

세계 경제와 에너지 안보를 논할 때 절대 빠지지 않는 지정학적 요충지가 있습니다. 바로 호르무즈 해협(Strait of Hormuz)입니다. 중동발 지정학적 위기가 고조될 때마다 국제 유가가 요동치는 가장 큰 이유 역시 이 해협의 봉쇄 가능성 때문입니다.

이번 글에서는 호르무즈 해협의 역할과 연평균 에너지 수송량, 그리고 이곳을 통제하고 있는 이란 이슬람 혁명수비대(IRGC)를 둘러싼 그간의 문제 상황들을 정리해 보겠습니다.

1. 호르무즈 해협의 역할과 지정학적 위치

호르무즈 해협은 중동의 페르시아만과 아라비아해로 이어지는 오만만을 연결하는 매우 좁은 바닷길입니다. 북쪽으로는 이란, 남쪽으로는 오만과 아랍에미리트(UAE)에 둘러싸여 있습니다.

이 해협은 사우디아라비아, 쿠웨이트, 이라크, 카타르, UAE 등 주요 산유국에서 생산된 원유와 천연가스가 전 세계로 뻗어나가는 사실상 유일한 해상 통로 역할을 합니다. 이 때문에 호르무즈 해협은 ‘세계 경제의 목줄’이자 ‘글로벌 에너지의 생명선’으로 불립니다.

2. 연평균 에너지 수송량: 전 세계 원유 물동량의 20%

호르무즈 해협의 중요성은 압도적인 에너지 수송량에서 나옵니다.

원유 수송량: 하루 평균 약 1,800만~1,900만 배럴의 원유 및 석유 제품이 통과합니다. 이는 전 세계 해상 원유 수송량의 약 20%에 해당하는 막대한 양입니다.
천연가스(LNG): 카타르 등에서 생산되는 액화천연가스(LNG) 역시 전 세계 물동량의 상당 부분이 이 해협을 거쳐갑니다.

대한민국 경제에 미치는 영향은 더욱 절대적입니다. 한국은 수입 원유의 70% 이상을 중동 지역에 의존하고 있습니다. 만약 호르무즈 해협이 단 며칠이라도 봉쇄된다면, 국내 에너지 수급은 물론 산업 전반과 물가에 치명적인 타격이 발생하게 됩니다.

3. 이란 이슬람 혁명수비대(IRGC)와 잦은 갈등 상황

호르무즈 해협의 가장 좁은 폭은 약 39km에 불과하며, 대형 선박이 안전하게 양방향으로 교행할 수 있는 수로는 폭 3.2km 남짓에 불과합니다. 이 좁은 길목의 북쪽 해역 통제권을 쥐고 있는 것이 바로 이란 이슬람 혁명수비대(IRGC) 해군입니다.

위기 때마다 등장하는 "해협 봉쇄" 카드

이란은 서방 국가(특히 미국, 이스라엘)와의 정치적, 군사적 갈등이 격화되거나 경제 제재가 심화될 때마다 “호르무즈 해협 봉쇄”를 강력한 비대칭 무기로 사용해 왔습니다.

그간 발생했던 주요 문제 상황들

민간 상선 및 유조선 나포: 이란 혁명수비대는 환경 오염, 통항 규정 위반, 밀수 단속 등 다양한 명분을 내세워 타국 국적의 유조선이나 컨테이너선을 나포하는 일종의 '인질 외교'를 벌여왔습니다. 과거 2021년 한국 국적 유조선인 '한국케미호'가 이란 혁명수비대에 나포되었던 사건도 호르무즈 해협 인근에서 발생했습니다.
그림자 전쟁과 선박 피격: 기뢰 공격이나 무인기(드론)를 활용해 이스라엘이나 서방과 연관된 상선을 공격하는 일이 빈번히 발생하며 긴장을 고조시켰습니다.
최근의 극한 갈등 (2026년 3월): 최근 중동 지역의 전운이 최고조에 달하며 상황은 더 심각해졌습니다. 이란 혁명수비대는 "호르무즈를 지나는 선박을 모두 불태우겠다"며 위협 수위를 높였고, 이란 해군에 의해 통과 허가 미비를 이유로 타국 컨테이너선이 추방당하는 일이 연이어 벌어졌습니다. 급기야 최근에는 이스라엘의 공습으로 호르무즈 해협 봉쇄를 실전 지휘해온 이란 혁명수비대 해군 사령관이 사망했다는 보도까지 나오면서, 언제 해상 무력 충돌이 터질지 모르는 일촉즉발의 화약고가 되었습니다.

4. 맺음말

호르무즈 해협은 대체할 수 있는 우회로가 매우 제한적이기 때문에, 이곳에서 벌어지는 이란 혁명수비대와 서방 간의 힘겨루기는 단순히 중동 내부의 갈등을 넘어 전 세계의 경제 안보와 직결됩니다. 에너지 수입 의존도가 절대적인 우리나라로서는 이곳의 정세를 늘 예의주시할 수밖에 없는 이유입니다.

OpenClaw 새 머신으로 옮기기 완전 정리

dragom — Fri, 20 Mar 2026 02:20:51 +0900

OpenClaw 새 머신으로 옮기기 완전 정리
(cmd by cmd + 폴더 구조 + 사전 체크리스트 + device approve까지)

노트북을 새로 샀거나, 서버를 옮겨야 할 때 “OpenClaw를 통째로 그대로 옮길 수 없을까?” 싶은 순간이 있습니다. 다시 온보딩하고, 채널 로그인(텔레그램/왓츠앱 등) 다시 하고, 세션 날려먹고… 이런 건 최대한 피하고 싶죠.

다행히 OpenClaw는 구조만 이해하면 “state 디렉토리 + workspace” 두 가지만 잘 옮기면 깔끔하게 마이그레이션이 가능합니다.

이 글에서는:

새 머신으로 옮기기 전에 무엇을 설치/확인해야 하는지
하나하나 cmd by cmd 예시와 그 명령이 뭘 하는지
폴더 구조가 어떻게 생겼는지
device approve(디바이스 승인)을 까먹지 않기 위해 무엇을 기억해야 하는지

까지 전부 정리해 보겠습니다.

1. 개념 먼저: OpenClaw가 어디에 무엇을 저장하는가?

OpenClaw를 옮길 때 핵심은 두 폴더입니다.

State 디렉토리 () – 기본값: ~/.openclaw/
Workspace 디렉토리 – 기본값: ~/.openclaw/workspace/

이 두 개를 그대로 새 머신으로 가져가면:

기존 세션, 기억, 설정, 채널 로그인까지 대부분 그대로 유지
사실상 “같은 OpenClaw를 다른 머신에서 이어 쓰는 느낌”으로 사용할 수 있습니다.

2. 폴더 구조 한 번 찍어보기

2-1. 구 폴더 구조 확인

ls -R ~/.openclaw

그리고 워크스페이스는:

ls ~/.openclaw/workspace

3. 본격 마이그레이션 전에: 새 머신 사전 체크리스트

3-1. OS & 권한

macOS / Linux / WSL2 / (서버의 경우 보통 Ubuntu LTS 권장)
새 머신의 사용자 계정이 정상적으로 홈 디렉토리를 가지고 있는지

3-2. Node & OpenClaw 설치 가능 여부

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw status

3-3. ssh / scp / rsync 준비

3-4. (중요) 노드/디바이스 승인 흐름 이해해 두기

마이그레이션 이후, 새 머신에서 처음으로 폰/다른 장비가 연결을 시도하면 승인(approve) 단계를 반드시 한 번 거쳐야 합니다.

4. 구 머신에서 할 일 (Step 0 ~ Step 2)

Step 0 — 게이트웨이 먼저 멈추기

openclaw gateway stop

Step 1 — state 디렉토리 아카이브하기

cd ~
tar -czf openclaw-state.tgz .openclaw

Step 2 — workspace 아카이브하기

cd ~
tar -czf openclaw-workspace.tgz .openclaw/workspace

Step 3 — 새 머신으로 파일 복사

scp openclaw-state.tgz openclaw-workspace.tgz newuser@newhost:~

5. 새 머신에서 할 일 (Step 1 ~ Step 3)

Step 1 — OpenClaw 설치

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw status

Step 2 — 아카이브 풀어서 덮어쓰기

cd ~
tar -xzf openclaw-state.tgz
tar -xzf openclaw-workspace.tgz

sudo chown -R ysyoo:ysyoo ~/.openclaw

Step 3 — Doctor로 마이그레이션 마무리

openclaw doctor
openclaw gateway restart
openclaw status

6. 흔한 함정(Footguns)과 회피 방법

6-1. 프로필 / state-dir 불일치

openclaw --profile work status
openclaw --profile work doctor

6-2. openclaw.json만 복사한 경우

반드시 ~/.openclaw 전체를 그대로 가져가야 합니다.

6-3. 권한 문제

sudo chown -R ysyoo:ysyoo ~/.openclaw

7. device approve(디바이스 승인) 잊지 않기

7-1. 왜 다시 승인이 필요할 수 있을까?

마이그레이션 후에는 게이트웨이 호스트가 바뀌었거나 세션이 리셋되면서, 노드 연결이 “새로운 연결”로 인식될 수 있습니다.

7-2. 체크리스트

openclaw status로 게이트웨이가 정상인지 확인
대시보드에서 기존 세션/메모가 잘 보이는지 확인
폰/다른 장비에서 한 번 요청해 보고 승인 메시지가 오는지 확인
보이면 Web UI 또는 CLI에서 해당 디바이스 승인

8. 최종 마이그레이션 체크리스트

openclaw status가 정상
대시보드에서 기존 세션/메모 확인
채널 로그인 상태(텔레그램/WhatsApp 등) 유지 여부
~/.openclaw/workspace 안에 기존 파일들 존재
필요 시 노드/디바이스 승인 완료

구글 안티그래비티 vs 오픈AI 코덱스: 내가 써본 솔직 비교

dragom — Wed, 18 Mar 2026 19:24:50 +0900

구글 안티그래비티 vs 오픈AI 코덱스
“나를 돕는 도구”와 “내가 고용한 프로그래머”의 차이

AI 코딩 도구 전성시대입니다. GitHub Copilot, Cursor, 다양한 에이전트 IDE들이 쏟아지는 가운데, 최근 가장 인상 깊었던 두 가지가 있습니다. 바로 구글의 안티그래비티(Antigravity)와 오픈AI의 코덱스(Codex)입니다.

두 도구 모두 “AI가 코드를 짜준다”는 공통점이 있지만, 실제로 써 보면 철학과 UX가 완전히 다릅니다. 이 글에서는 필자의 실제 사용 경험과 커뮤니티 평가를 바탕으로 두 도구를 비교해 봅니다.

1. 구글 안티그래비티: VS Code 같은 UI, 사람을 돕는 도구

안티그래비티는 한 줄로 요약하면 “VS Code에 구글 Gemini 기반 AI 엔지니어를 심어 놓은 IDE”입니다. 외형과 흐름이 VS Code와 거의 동일해 기존 VS Code 사용자라면 별도의 학습 없이 바로 적응할 수 있습니다.

VS Code 포크 기반이라 에디터, 파일 트리, 터미널 등 개발자가 익숙한 구성 그대로입니다.
기존 코드 위에서 강력합니다. 리팩토링, 버그 수정, 테스트 코드 생성 등 “이미 있는 코드”를 다듬는 데 특히 유리합니다.
큰 변경 전에는 항상 계획과 변경 내용을 먼저 설명하고, 동의를 요청합니다. 즉, 혼자 모든 걸 해버리기보다는 사용자의 리뷰와 승인을 전제로 움직입니다.

실제로 써보면 안티그래비티는 이렇게 느껴집니다.

“내가 주도권을 쥐고 있고, 안티그래비티는 옆에서 계속 코드를 봐주고 도와주는 시니어 도구 같다.”

2. 오픈AI 코덱스: 클라우드에서 대신 일하는 프로그래머

코덱스는 분위기가 완전히 다릅니다. UI도 에디터 중심이 아니라 대화형 챗 UI에 가깝고, 내 역할은 주로 방향과 목표를 말해 주는 것입니다.

“이 프로젝트를 Firebase로 자동 배포되게 만들어줘.”
“이 결제 로직 버그를 잡고 테스트까지 추가해줘.”
“이 리포지토리의 구조를 리팩토링해줘.”

라고 요청하면, 코덱스는 클라우드 컨테이너 안에서:

Git 리포지토리를 가져오고,
코드를 읽고 설계를 잡고,
파일을 생성·수정·삭제하고,
테스트를 실행하고,
Git 커밋과 푸시, CI/CD 구성까지도 처리

하는 식으로 정말 “대신 일하는 개발자”처럼 행동합니다.

“도구를 쓰는 느낌이 아니라, 원격 개발자 한 명을 고용해서 Slack으로 지시하는 느낌에 가깝다.”

물론 단점도 있습니다. 특히 복잡한 레거시 코드베이스에서는:

손대지 말라 한 영역까지 건드리거나,
연관 없는 파일까지 과하게 수정하는

경우가 가끔 있습니다. 다만 이런 상황은 보통 큰 규모의 수정에서 더 자주 나타나고, 일반적인 작업에서는 크게 문제 되지 않는 편이었습니다.

3. 클라우드 컨테이너와 스레드 구조: 왜 이렇게 디자인됐을까?

코덱스를 쓰면서 가장 인상 깊었던 부분은 클라우드 환경과 스레드 단위 작업입니다.

브라우저나 Slack에서 몇 줄만 입력하면,
코덱스가 Git에 연결된 프로젝트를 클라우드 컨테이너에 체크아웃하고,
그 안에서 수정·빌드·테스트·배포를 수행합니다.

각 스레드는 하나의 목표/작업에 대응합니다.

블로그 서비스 자동 배포 파이프라인 만들기
알림 시스템 버그 수정하기
대시보드 성능 개선하기

이런 스레드들을 여러 개 만들어 병렬로 돌리면, 현실 세계로 치면 여러 명의 프리랜서 개발자에게 각자 다른 일을 맡긴 느낌에 가깝습니다.

4. 내 실제 워크플로우: 안티그래비티 → 코덱스

나는 먼저 안티그래비티를 사용해 보고 퀄리티에 감탄해, 바로 구글 AI 유료 요금제를 결제했습니다. 일주일마다 리셋되는 한도를 꽉 채워 쓰면서 다음 리셋을 기다리던 중, 우연히 코덱스를 발견했고, 마침 1주일 무료 체험이어서 가볍게 시작해 봤습니다.

그 뒤 타임라인은 이렇습니다.

안티그래비티에 반해 구글 AI 요금제 결제
사용 한도 리셋을 기다리던 중 코덱스 발견
코덱스 1주 무료 체험 시작
3일 만에 ChatGPT Plus 유료 결제
현재는 Slack에 코덱스를 연동해, 야외에서도 본업을 하면서 대신 코딩해 주는 시스템 구축

이 시스템을 만들기 위해 내가 한 일은:

기존에 프라이빗하게 쓰던 코드에서 민감 정보를 모두 제거
그 코드를 Git 리포지토리로 정리해 푸시
코덱스에게 GitHub Actions와 Firebase 등을 활용한 자동 배포 파이프라인 구성을 요청

실제 구현과 설정의 대부분은 정말로 “코덱스가 다 해줬다”고 말해도 될 정도였습니다. 내가 한 일은:

“이렇게 해줘”라고 요청하고,
코덱스가 만든 걸 실제로 실행해 보고,
문제가 생기면 로그와 에러 메시지를 그대로 복붙해서 “이 에러를 해결해줘”라고 다시 요청하는 것

이 반복만으로, 예전 같으면 직접 많은 시간을 들여 설계·구현해야 했을 시스템을 비교적 짧은 시간 안에 갖출 수 있었습니다.

5. 정리: 언제 안티그래비티를, 언제 코덱스를 쓸까?

내 경험을 기준으로 정리하면:

안티그래비티는 VS Code에 익숙하고, “내가 코드를 직접 만지면서 AI의 도움을 받고 싶은 개발자”에게 잘 맞습니다.
코덱스는 Git 기반 프로젝트를 가지고 있고, “가능한 많은 작업을 AI에게 위임하고, 나는 방향과 검수에 집중하고 싶은 사람”에게 어울립니다.

지금 나는 두 도구를 이렇게 쓰고 있습니다.

세밀하게 구조를 보고 싶을 때, 혹은 IDE 안에서 생각을 정리하며 개발하고 싶을 때는 안티그래비티.
야외에서 본업을 하면서도, Slack과 브라우저만 켜 두고 코덱스에게 리포지토리 단위의 일을 맡길 때는 코덱스.

6. AI 발전 만세

결국 이 두 도구를 쓰면서 가장 크게 든 생각은 한 줄로 정리할 수 있습니다.

AI 발전 만세. 이제는 “도구를 얼마나 잘 다루느냐”를 넘어서, “AI 동료를 얼마나 잘 활용하고 협업하느냐”가 개발자의 중요한 역량이 되어 가는 것 같다.