코딩수련장

[6월 정산 수익 243만원] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 환전, QQQI, TIGER 배당커버드콜 엑티브, 월2% 배당

snowman95 — Tue, 30 Jun 2026 22:32:31 +0900

6월을 정리하며

자~ 6월 마지막의 날입니다.

지난 주에 TIGER 배당커버드콜 엑티브로 3% 가량의 매매차익을 냈었는데요.

[6월 4주차] 수익 80만원 | 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 특별 배당으로 월2%

응~ 배당 받으면 그만이야~ 6월 2-3주차 결과 입니다. 안녕하세요. 오늘은 마이크론이 쏘아올린 기분좋은 대폭등장이었습니다.!! 그런데 미장은 애플이 -5%로 시작하는 기현상을 보이고 있네요 !!

11001.tistory.com

매도한 다음날 곧 바로 기회가 찾아왔습니다. 주가가 그대로 빠져서 원점으로 되돌아갔거든요.

29000원에 털고나서 다음 날 주가가 크게 빠졌을때 27600원대에 다시 진입했습니다. ㅋㅋ

오후에 진짜 많이 떨어졌을때 샀으면 여유 있었을텐데 너무 급했다 싶었어요.

[속보]
삼성·SK, 서남권 반도체 클러스터 최대 900조 투자
AI 데이터센터 포함 SK 1000조 투입 계획

29일 청와대서 3대 메가프로젝트 보고회 용인 클러스터, 삼성·SK 완공 대폭 앞당겨 정부, 인허가·전력·용수 등 ‘원스톱’ 지원!!!

소신 발언 하자면, 국산 LLM 못 만들면 나라가 그냥 망하는 거라서요.

누군가는 해야하는 일이라고 생각을 했는데 이재명

정부가 이재용 최태원 머리 끄댕이 잡고 추진 시켰네요 ㅋㅋ

이거 안만들면 나중에 그냥 미국의 노예로 살아야합니다.

그런거를 다 알면서도 솔직히 주주 입장에서는 개쌍욕이 나오네요.

삼전, 하닉 -10% 꼬라 박으면서 저는 배당락 당일에 -4% 까지 견뎌야 했습니다...

하하하하하!! 더 떨어져봐!!!! 배당 받으면 그만이야!!!!

그러나.. 항상 악재는 연쇄적으로 찾아온다더니

하필이면 집을 이사하면서 새 에어컨을 주문했는데..

하필이면 혼수 선물로 냉장고를 사줬는데

예상하지 못한 지출이 400만원이나 나가야 하는 상황..!

어떻게 돈을 끌어올까 약간의 고민을 하던 와중에 찾아온 공포스러운 화요일...

어.. 어...오른다? 약속의 1시 U자 드리프트 미쳤냐고!!!!!

데자부~ 아 저스트 빈 인 디스 플레이스 비포어 하이어 온 더 스트리트~

튀.. 튀어잇!!!!

재..재용이형!!!! 지금이니!!!?

일단 나무증권 부터 털엇!!!!!! 두 번 다시는 기회 안 올 수도 있어!!!

약간의 미미한 손실이 있긴 했지만 일단 먼저 내려!!!

약속의 2시

약속의 2시까지 쪼오금만 더 인내심을 가졌더니 오늘 하루에 3%을 말아올리면서 탈출 기회가 왔다고 합니다.

탈출 시점 지리죠? ㅋㅋㅋㅋ

심지어 27,690원 벌고 나왔음 ㅋㅋ 달달하네

자자 6월 정산 해볼까요?

타이거 배당 커버드콜 엑티브 배당금 주당 580원 입니다. 옵션이라 과세 없음 ㅋ

배당수익 1,167 주 x 580원 = 676,860원

매매차익 27690 - 12060원 = 15,630원

도합 692,490원

지난 주 까지해서 131만원에 + 69만원을 더하면..

200만원 달달하노

그 외에 해외 주식 SOXL 무한매수 및 단타치며 43만원을 벌었답니다.

이건 배당 전략으로 번 것은 아니지만 다른 돈으로 번게 아니라 배당 전략 운용하는 금액의 일부로 번 것이라 포함시키겠습니다.

매우 안전하게 100만원 정도로 5% ~ 15%수익 내는걸 여러 번 반복 했어요.

심지어 하루에도 몇 번이나 변동성 잘타서 3%, 3%, 3% 이런 식으로 계속 먹기도 했답니다.

심지어 그 와중에 개쳐물린 구글 17만원을 손절했음에도 이정도 수익입니다.

구글! 와! 세계 최고의 기업인거는 맞는데 반도체에 모든 돈을 다 때려붓고 있기 때문에 희망이 없다고 판단했습니다.

그들의 돈은 삼전, 하이닉스, 마이크론으로 가게됩니다.

고배당 월배당 ETF 정리해보겠습니다.

지금까지는 솔직히 그때그때 눈에 보이는 고배당 주식에 불나방처럼 뛰어들었는데

앞으로도 롱런하면서 잘 털어먹기 위해서는 ETF 가 뭐가 있고 어떤 특성이 있는지 공부가 필요하다고 생각이 들었습니다.

6월에 ACE 미국반도체데일리타겟이 주당 21000원인데 특별 배당이 나오면서 배당금 주당 612원을 줬답니다. 3%나 됩니다...

하.. 맘고생 하지말고 그냥 이거나 살껄 싶더라고요.

TIGER 배당커버드콜액티브는 정말 위험한 녀석입니다. 조심하세요.

저희가 사실 안 위험하려고 이런 에겐 전략 하는건데요.

이 정도 변동성 쳐맞으면 차라리 삼전, 하이닉스 직투하지 내가 왜 고생하면서 이거 투자했을까 그런 맘이 들었어요.

지금까지 정리한 내용을 기반으로 최고의 라인업을 만들어보았습니다.

여윽시 나스닥 100(QQQ) 기반으로 가는게 제일 안전하다 싶었습니다.

① 미국 라인업: QQQI(월말) + JEPQ(월 중순)

평가: 완벽한 환상의 짝꿍입니다.
QQQI는 네오스(NEOS)사의 상품으로 단순 콜옵션 매도가 아니라 'ITM(인더머니) 옵션'과 '풋옵션 매수'를 섞어 나스닥의 상승을 어느 정도 따라가면서 월 1% 이상(연 13~14%)을 꽂아줍니다.
JEPQ는 JP모건의 스타 펀드매니저들이 액티브로 비중을 조절하며 나스닥 기초자산 상승을 영리하게 추종합니다. 배당락 주기가 딱 보름 간격으로 쪼개지므로 2주 턴 전략에 최적입니다.

② 국내 라인업: RISE 미국테크100데일리고정(월말) + ACE 미국반도체데일리타겟(월 중순)

평가: 국내 주식 리스크를 지우고 '미국 우상향'에 올라탄 매우 현명한 선택입니다.
TIGER 배당커버드콜액티브 탈출은 신의 한 수: 국장의 변동성은 예측이 불가능합니다. 털고 나오신 건 아주 잘하셨습니다.
RISE 미국테크100데일리(구 KB스타): QQQ 지수를 기반으로 하면서 엔비디아, 애플 등 메가테크 비중이 높아 하방 경직성이 뛰어납니다. 물려도 미국 빅테크라 복구 속도가 국내 주식과는 차원이 다릅니다.
ACE 미국반도체데일리타겟: 엔비디아, 브로드컴 등 미국 반도체 Top 30을 담고 QQQ 옵션을 매도하는 구조입니다. 최근 1년 분배율이 연 15%를 넘길 정도로 분배 재원이 깡패 수준이고 매수세가 강해 배당락 회복이 빠릅니다.
'데일리(0DTE) 옵션'의 강점: 두 상품 모두 만기가 하루짜리인 옵션을 매일 매도하므로, 주가가 한 달 내내 가두리에 갇혀있어도 매일매일 프리미엄을 갉아먹어 분배금을 꽉 채워줍니다.

냉장고 값은 벌었는데 에이컨 값 벌어야하니 또 열심히 달려보겠습니다.

[AI발 생존 일지] 메이플스토리 주간보스돌이 쌀먹

snowman95 — Sun, 28 Jun 2026 18:10:05 +0900

오늘도 우리는 오프라인에서 열심히 일 하면서 원화 채굴을 하고 있지요.

하지만 우리의 절대적인 시간은 24시간이고 정해져있어서 더 많이 일하고 싶어도 할 수가 없습니다..

결국 우리는 물리적인 제약을 뛰어넘기 위해 온라인으로 가게 됩니다..

내가 자는 시간에도 돈을 벌어다줬으면 하거든요.

온라인 폐지줍기, 게임, 포스팅, 이미지, 영상제작, 주식, 코인 등 어떤 것이든 좋으니 온라인의 영역에서 반드시 돈 벌고 있어야 합니다.

주식, 코인이 허들이 낮고 접근성이 좋아서 많이들 하지요.

게임에서 이른바 '쌀먹' 또는 장사를 하시는 분들도 있고, 플랫폼 수수료 장사, 커뮤니티, 블로그 광고 장사 등 참 다양합니다.

저는 메이플스토리라는 게임으로 주간 보스레이드 일명 "주보돌"을 통해 쌀먹을 해본 적이 있는데요.

보스를 잡고 확정 드랍되는 결정을 상점에 팔면 메소를 주는데요. 이 메소를 원화로 환전하는 방법입니다.

보스가 패턴이 다양하고 상당히 어렵습니다.

어느 순간 손컨트롤이 딸려서 포기하고 좌절하고 돈을 지르게 되더라고요.

난이도가 더 높은 상위 보스를 잡으면 더 많은 메소를 얻는데요.

위로 갈 수록 스펙업에 훨씬 많은 투자를 해야하는 구조로 되어있습니다. 스펙업이 반드시 어느 수준에서 막히게 됩니다.

시간은 일주일에 하루 정도는 각잡고 투자해야하는 정도였고, 출석 보상을 위해 매일 접속해야하는 피로감이 있었습니다.

돈은 최저임금 수준도 안나오지만 책상에 가만히 앉아서 이 정도 버는거면 나쁘지 않은데? 정도의 수준인데요.

돈은 많이 주는데 시간이 많이 들어가는 상위 보스를 잡다보면 피로감이 쌓여서 하기 싫어지고 힘들어서 그냥 쉬운것만 빨리 잡고 조금 덜 벌어야겠다 이렇게 되더라고요.

저는 처음에 호기롭게 캐릭터를 3개를 돌리다가 병나는 줄 알았습니다.

정말 욕심내서 하루도 빠짐없이 매일 매일 했었는데 그렇게 많이 노력 한 것 치고는 수익이 적다보니까 급격히 현타가 오면서 접었습니다.

근데 웃긴게 그렇게 접고나서 AI 붙잡고 오랜 시간을 보냈는데 AI 구독료 만큼도 못 벌고 심지어 메이플 쌀먹보다 수익이 안나면서 또 다시 현타가 오더군요 ㅋㅋ

그래서 솔직한 마음으로는 딱히 아무것도 안하는 시간에 그냥 기계적으로 캐릭터 하나라도 주보돌을 돌려야하나싶기도 합니다.

기회비용이라는게 참 무섭습니다.

내가 그 시간에 다른 걸로 더 많은 수익을 낼 수 있다면? 그걸 하겠는데 사실 딱히 그렇지가 않더라고요.

[AI발 생존 일지] AI와 함께한 지난 6개월 (OpenClaw, 앱개발, 블로그 자동화, 유튜브)

snowman95 — Sun, 28 Jun 2026 17:40:31 +0900

오늘 부터 가능하면 매일 생존 일지를 한번 써보려고합니다.

이 망할 AI 세상에서 어떻게 해야 살아남을지 목표를 세우고 기록을 남겨야만 될 거 같습니다.

지금까지 있었던 이야기는 큼직큼직하게 적고 넘어가고

지난 6개월의 이야기..

두둥 AI 비서 OpenClaw 의 등장 - 벌써 자비스가 나온것인가?! 큰 기대감과 함께 사용해보았으나 개발자 시선에서는 한참 부족하여 실망 했습니다. 그래도 일반 사람들이 AI 에 주목하기 매우 좋은 트리거가 되었다고 생각합니다.

[AI] 오픈클로(OpenClaw) 사용 후기 (결론: 뉴스에서 호들갑 떨었다)

첫인상 = 불안정하다openclaw 에 저렴한 모델을 붙여서 써서 그런가 싶기도한데 일을 시키면 너무 속도가 느리고, 브라우저 연결이 계속 끊기는 등 불안정하다는게 첫인상이었습니다. 그래도 좀

11001.tistory.com

Mac Mini M4 구매 - 개인 맥미니를 구매해서 OpenClaw 를 구동하여 개인 AI 비서를 사용하는게 한때 유행이었습니다. 물론 그런 용도로도 써보고, 집에서 24시간 구동하는 내 전용 로컬 PC 가 필요함을 느꼈기 때문에 비싸다고 생각이 들었어도 구매를 했습니다.

[AI] 맥미니 Mac Mini M4 자랑, 무조건 빠르게 만드는게 중요한게 아니다

시대에 뒤쳐지지 않으려고 OpenClaw 를 사용 해보기 위해서 깡통 맥미니를 구입했습니다.이미 Claude Code 도 거의 1년 뒤쳐졌는데 더 이상은 뒤쳐질 수 없습니다! 회사 맥북은 메모리 48GB 인데우리 귀

11001.tistory.com

빠르게 변화하는 AI 기술에 등떠밀려 하루도 편하게 지내지 못하는 나날들이 반복.

그래서 니가 뭐 할 수 있는데 -> 할 수 있는게 없음.. 회사에서라도 열심히 해보자.

[개발자 이야기] 프론트 개발자의 AI로 인해 잠 못드는 나날

AI 기술 부채AI로 인해 흥분되어 잠 못드는 날, AI로 불안해서 잠 못드는 날이 반복됩니다.자고 일어나면 또 새로운 AI 기사가 쏟아지면서 AI 기술 부채가 나날이 쌓이고 있습니다. 열심히 따라가기

11001.tistory.com

사내에서 AI 를 연구하고 스터디하고 사용하는 생태계를 만들어야 겠다고 결심.

그러나 사내 클로드 코드 도입이 예상 보다 2달은 늦어지면서 약간 힘을 잃은 상태입니다.

앱개발, 영상제작, 부동산 공부 등으로 바빠지면서 AI 를 다룰 시간이 없어졌고, 그에 따라 AI 구독료가 아깝고 부담이 되어서 구독을 끊는 순간부터 거의 AI 세상과 동떨어지게 됨. -> 결국 다시 PRO 구독했습니다.

이를 계기로 회사에서 운 좋게 AI TF 활동에 참여하게 되었고, 모든 것을 갈아 넣겠다는 다짐으로 2달 정도 빡시게 활동했습니다.

AI 의 가능성, 한계 등 많은 것을 느꼈고, 결국엔 AI 모델의 발전에 따라 대부분은 해결이 되겠구나를 느끼면서, AI Agent 를 하나의 도구로써 어떻게 더 잘 다룰 수 있는지에 대해 연구하고 공부하고 있습니다.

[개발자 이야기] AI 에게 일을 위임하고 나는 딸깍하는 회사 라이프를 꿈꾸다

매우 저조한 AI 활용도우리 회사에서는 클로드 코드는 지원하지 않고 (지원하다가 잠정 중단), 커서는 지원하고 있습니다.제가 팀 내에서 커서 이야기 나올 때마다 참 좋으니 한번 써보라고 권하

11001.tistory.com

AI로 앱개발에 도전 - 딸깍 치고는 생각보다 너무 많은 공수가 들었고, 그에 따라 유의미한 수익도 났습니다.

일단 제 생각인데 플랫폼 자체가 데일리 포인트 제공 앱으로 망했다고 생각하고요. 수익 내려면 매니악하고 특이한거 그런건 의미없고 대중들이 원하는 일반적인 앱을 만들어야하는데 그러면 다 카피앱, 중복앱 되는 겁니다. 그냥 레드오션일 수 밖에 없는 구조입니다.

AI 혁명이 일어났다. 5년차 FE 개발자인 나는 Claude Code Max20 을 구독하고 별의 별 짓을 다 해봤다.

AI 혁명이 일어났다.미국 빅테크 기업들이 초거대 AI 데이터센터 건설에 상상을 초월하는 투자를 쏟아붓는다.그 많은 돈은 모두 CPU, GPU, RAM, Disk, Network, Cable 등을 만드는 반도체 제조업 회사에 흘

11001.tistory.com

블로그 자동화 시도 - AI가 가장 잘하는 분야가 글 쓰기 잖아요? 티스토리/네이버 블로그에 쿠팡 파트너스 및 애드센스 붙여서 글 자동 생성 진행해보았습니다. 티스토리는 계정 통합해서 하루에 최대 50개 밖에 못쓰고, 네이버 블로그는 100개 까지 예약 발행이 가능한데

제 경험상 저 한계치에 도달하기 전에도 단기간에 비슷한 글을 여러 개 올리는 순간 바로 알고리즘에 의해 블로그 노출을 사망처리 됩니다.

그러면 하루에 걸쳐서 천천히 조금씩 올리면 괜찮지 않느냐 싶지요?

저희가 원하는건 그게 아니잖아요.. 무인으로 계속 글을 찍어내서 지속적인 수입을 내고 싶은건데 글을 하루에 10개? 이렇게 깨작깨작 올려서 만원이나 벌겠습니까?

유튜브 진출 - 과거에 영상 원데이 클레스를 듣고나서 취미삼아 1달 정도 올린적이 있었습니다.

구독자도 금방 100을 넘고 조회수가 5만이 나온 영상도 있었어요.

근데 뚜렷한 목적 없이 그때그때 생각나는 주제나 일상 생활 이야기로 만들다보니 금방 콘텐츠 고갈이 되는게 문제더라고요.

그 이후로 바빠져서 못하다가 최근에 다시 시작했었는데 아.. 아무래도 얼굴이 안나오는 브이로그라서 그런지? 옛날 보다 훨씬 편집을 빡시게 했다고 생각했는데 조회수가 안나오더라고요.

근데 브이로그가 어떤 정보가 있는 것도 아니고, 남이 사는 이야기를 대체 누가 왜 보는건가 싶은데 조회수 많은거 있잖아요?

따지고 보면 그냥 개그코드가 맞거나 결이 잘맞는 오랜 팬들이 밥먹으면서 아무거나 틀어놓는 그런거 아닐까 싶긴해요.. 그러려면 결국 사람이 나와서 춤도 추고 광대짓 하고 옘병을 떨어야 내적 친밀감 쌓이고 영상이 단조롭지가 않아서 그런 맛에 보는거 같은데

제가 또 조용한 성격이다보니 결국 브이로그 보다는 어그로성 정보성 영상으로 가야하는가 싶습니다. 그게 저한테 맞는거 같아요.

주식 붐 - 삼성전자 하이닉스가 미친듯이 끌어올리고 있는 주식장에서 FOMO 를 느끼고 저도 뛰어 들었답니다.

그 이후에 하락장이 예상되어서 돈을 매우 보수적으로 굴리기 위한 방법을 찾다가 배당 갈아타기 및 환차익 전략을 생각해보았어요.

생각 보다 잘 되니까 재밋더라고요? 이것도 따로 기록을 이어가고 있습니다.

[주식 투자] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 유휴 RP이자 대신 고배당 커버드콜

[주식 투자] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략AI발 대세 상승장을 못타신 분들...FOMO 느끼고 지금이라도 풀매수 들어가는 순간 세상이 나를 지켜보고 있는 것이었는지!!! 다음날 부

11001.tistory.com

결론은 또 다시 미궁속으로

결론적으로 제가 몇 달 동안 수 많은 것을 해오면서 AI 구독료 보다 많이 벌지 못했고

LLM의 지능은 아직까지는 절대로 신(GOD)의 수준이 아니고, 이 세상에 없는것을 만들어내지는 못한다는 것을 알게 되었습니다.

아니 ㅋㅋ AI 라는게 원하는 걸 무엇이든 만들어주는 만능 도구라고 착각했었는데 그게 아니라는거에요.

AI는 이 세상에 이미 있는 것들을 짜집기해서 확률적으로 결과를 내보내는 것입니다.

다만, 쪼금 더 효율적이고 생산적으로 쓸 수 있는 다양한 기법들은 존재한다는 것과 글, 이미지, 영상 등 다양한 활용처가 있는데

그걸 어떻게 하는지? 뭔지 조차 잘 모르는 사람들한테 마치 희망이 있다는 것 처럼 포장해서 파는 강의팔이를 나도 해야하나? 싶습니다.

[6월 4주차] 수익 80만원 | 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 특별 배당으로 월2% 배당주는 TIGER 배당커버드콜 엑티브

snowman95 — Fri, 26 Jun 2026 01:19:46 +0900

응~ 배당 받으면 그만이야~ 6월 2-3주차 결과 입니다.

안녕하세요. 오늘은 마이크론이 쏘아올린 기분좋은 대폭등장이었습니다.!!

그런데 미장은 애플이 -5%로 시작하는 기현상을 보이고 있네요 !!

이런 흐름이라고 합니다!!

반도체 가격 인상 못버팀 -> 아이폰 가격 인상 -> 물가 오르니 금리 인상? -> 발작 버튼 on

결국엔 금리인상 대폭망 엔딩인게 너무 뻔하게 보이네요.

기술의 발전과 무관하게 27년도 전후로 피바람이 불 듯 합니다.. 다들 조심하십시오.

수익 나는건 좋은데 탈출구도 마련해야지요.

환전 결과

저는 환율이 미친듯이 대폭등해서 결국 달러로 환전을 못했습니다.ㅠㅠ

1540원도 높다고 생각했는데요. 50원 까지 수직상승 하더군요.

당분간 달러 환전 찬스는 없을 듯 합니다.

근데! 9시에 달러 환전하고 중간에 다시 원화 환전하는 전략 나쁘지 않아 보이더라고요.

항상 그런건 아닌데 요즘 패턴이 그래요.

배당 결과

미국 ETF 는 못하고 결국 국내 ETF 중에 월배당 찾아보다가

특별배당으로 월2% 배당을 주는 TIGER 배당커버드콜 엑티브!! 이 있다는 걸 알게되었습니다.

원래는 배댱수익률 7% 정도 인데요. 월 환산하면 12로 나누었을때 1%도 안되는 배당인데

삼전 닉스 덕분에 돈 많이 벌어서 "특별 배당" 을 하반기에도 이어가고 있다합니다.

문제는 오늘 마이크론의 실적이 어닝 미라클 이 나면서 삼전닉스 대폭등하면서 대말올이 나왔습니다...

그러면서 제가 안전하게 배당이나 먹으려고 사두었던 ETF 가 수익이 (생각보다)크게 났어요.

근데 아시죠? 대폭등 다음에 대폭락 패턴인거?

시장이 호들갑 떨면 분명히 뭔일 납니다. 그리고 내일은 통계적으로 하락이 많은 "금요일" 이라는거

그냥 금요일은 웬만하면 피하십쇼..

매매 결과

욕심 안부리고 3% 가량 먹고 익절했습니다^^

내일 분위기 보고 반절 정도는 장중에 들어가고 반절은 장마감전에 들어갈까 생각중입니다.

일단 미장 분위기 보니까 애플 때문에 금리 인상 공포 분위기가 좀 있는거 같아요.

장초에 폭락한거 전부 다 말아올리고 대폭등으로 끝날거 같지는 않고 위아래 변동 주다가 좀 재미없게 끝날 거 같은 느낌입니다.

그래서 내일 삼전닉스도 영향 받아서 조정 올 거같고..

그러면 이 ETF 도 더 싸게 줍줍할 기회가 있을거 같으니까요.

아니 삼전 샀으면 10%는 그냥 먹는건데 ㅋㅋ 꼴랑 3% 먹고 기분좋아하노?

네 이렇게 생각될 수 있습니다. 충분히 맞는 말입니다.

하지만 저는 하루 10% 오르고 하루 10% 떨어지는 이런 미친 장에서도 돈을 지켜야하기 때문입니다...

현재 까지 수익률 계산해보면

시드가 2000만원이고 131만원의 수익이 났으니 대략 6.55% 의 수익을 냈군요.

마지막엔 짜투리 돈 까지 더 모았으니 5-6% 정도로 봐도 될 거 같습니다.

계획

내일 계획대로 TIGER 배당커버드콜 엑티브를 매수한다면, 약 2%의 배당금을 주는데요.

내일은 잔고에 있는 나머지 돈 까지 밀어넣어서 약 3000만원에 가까운 돈을 넣을 생각입니다.

그럼 대충 배당금 60만원이죠?

월요일이 배당락으로 예상되니 그때 상황보고 움직일 듯 합니다.

월요일 삼전닉스 상승하면서 배당락 맞고 빠진게 회복된다면..? -> 정리하고 JEPQ 로 넘어간다면? -> 대략 0.8% ? 정도 추가 배당수익

근데 아마 힘들거 같긴해요. ㅋㅋ

안되면 환전 타이밍 노리면서 현금 보유하고 있다가 다시 QQQI 들어갈 준비해야죠.

환전 못하면 그냥 KODEX 미국배당커버드콜액티브? RISE코리아벨류업위클리고정커버드콜? 이런 선택지도 있을 듯 합니다.

근데 요즘 차트를 보면 2022년이 자꾸 겹쳐보이는거 같아서요.

좀 더 조심히. 신중이 해야하나 싶은 마음이 계속 듭니다.

그때도 위아래 15%씩 움직이는 미친 롤러코스터 장이 이어지다가 금리 인상과 함께 모두가 파멸했죠.

이때 기억 나시나요..? 금리인상 앞에서 뻐팅기지 마세요. 삼전닉스 영원할 거 같습니까?

일단은.. 당분간은 이 전략을 그대로 가져가볼 생각입니다.

배당은 결국 제 살 갉아먹기라고 하지만, 솔직히 주식이 홀짝게임이잖아요?

특히나 이렇게 변동성이 심하다면 커버드콜이 유리한 거 아실테고,

하루 이틀안에 빠르게 매도치고 현금을 들고 있는 날이 많이 때문에 갑자기 핵폭탄급 이슈가 터져도 피할 가능성이 매우 높다는거죠.

저 이번에 코스피 9000->8000 대폭락 가는것도 피하고 오늘 이렇게 수익을 낼 수 있었던 것도

주식은 빠르게 배당만 받고 바로 빠지고, 현금을 계속 들고있었기 때문에 가능했습니다.

어쨌든 오래 살아남기 위한 전략이니 열심히 살아남아서 돈을 벌어보겠습니다.

[개발자 이야기] AI Agent 와 인터뷰를 하라. 계획이 가장 중요하다. 쓰레기를 넣으면 쓰레기가 나온다. (grill-me)

snowman95 — Fri, 19 Jun 2026 20:34:34 +0900

Plan 모드

요즘 대부분의 AI Agent 에 기본적으로 Plan 모드라는게 있습니다.

이 Plan 모드는 요구사항을 코드로 구현하기 전에 문서로 계획을 작성해줍니다.

확실히 AI 에게 그냥 시키는 것보다 문서로 한번 정리하고 만들면 더 잘만들어 준다는 것을 체감할 수 있는데요.

그런데 말입니다. "그럴싸 하게" 만들기는 했는데 예상치 못한 변수들이 보입니다.

예외 케이스들에 대해서 전혀 고려하지 못했고, 제가 의도한 대로 동작하지 않는 기능들도 있습니다.

왜 그럴까요? 저희는 분명 "Plan 모드" 로 스마트하게 계획을 세웠는데요?

사람의 머릿속에 들어있는 내용은 훨씬 복잡하고 말로 설명하기 어려울 정도로,

정리가 잘 되어있지 않고 매우 혼란스러운 상태입니다.

수 초 이내에 모든 예외 케이스들을 고려하고 완벽한 계획을 세울 수 없습니다. 분명히 구멍이 생깁니다.

이 상태로 AI 에게 일을 시켰을때 제대로 된 결과가 나올까요?

쓰레기를 넣으면 쓰레기가 나올 뿐입니다.

요구사항 전달의 중요성

부하 직원에게 어떤 요구사항을 전달할때 요구사항에 대해서 정확하게 전달하지 않으면

아무리 똘똘한 직원이어도 내가 원하는대로 만들어오지 못할 것입니다.

그러면 그럴 때마다 "아니 그게 아니라" 라고 하실건가요?

"알잘딱깔센 하게 만들어와야지 이게 뭐야" 라고 화를 내실 건가요?

당연히 AI 도 마찬가지입니다.

절~대로 한번에 완벽하게 만들 수 없습니다.

당신이 잠깐 생각해서 입력한 내용 가지고는 구멍 투성이인 기능을 만들 수 밖에 없는 겁니다.

사전 인터뷰를 해라

저희는 AI 와 충분한 사전 인터뷰를 해야합니다.

이때 사용하면 좋을 스킬이 있습니다. grill-me 입니다.

설명: 계획이나 디자인에 대해 사용자에게 끊임없이 질문하십시오. 사용자가 구축 전에 계획을 철저히 검증하고 싶어하거나, '그릴'과 같은 질문 유형을 사용할 때 유용합니다.

이 계획의 모든 측면에 대해 공통된 이해에 도달할 때까지 끊임없이 질문하십시오. 설계 트리의 각 분기를 따라가며 결정 간의 의존 관계를 하나씩 해결하십시오. 각 질문에 대한 권장 답변을 제시하십시오.
질문은 한 번에 하나씩 하고, 각 질문에 대한 답변을 기다린 후 다음 질문으로 넘어가세요. 여러 질문을 한꺼번에 하면 혼란스러울 수 있습니다.
질문에 대한 답을 코드베이스를 살펴보는 것으로 얻을 수 있다면, 코드베이스를 살펴보세요.

이런 비슷한 스킬들이 아주아주 많은데요. 그 중에서 단언컨데 grill-me 를 추천하는 이유는

"정말 가볍고, 단순한데 강력하기 때문" 입니다.

이 스킬을 사용하면 AI Agent 가 프롬프트 내용에 대해서 5번, 10번, 15번, 그 이상 까지도 저에게 역질문을 합니다 .

이 역질문들은 제가 생각지도 못한 "구멍" 을 채우는 역할을 해줍니다.

또는 아는 내용이지만 이것이 맞나요? A와 B중에 정확히 무엇이 맞나요? 하고 다시 되물어보면서 질문을 "더 명확하게" 해줍니다.

이 차이는 결국에 서비스 품질로 이어집니다.

진짜 개꿀팁. (돈 안받을 테니 광고 누르고 가세요)

grill-me 는 제가 개인적으로 거의 모든 작업의 시작에 사용하는 필수 스킬이기 때문에 소개드렸습니다.

이건 진짜 돈 받고 풀어야하는 개꿀팁인데요

superpowers 의 brainstorming 을 먼저 수행해서 빠르게 뼈대를 잡고 그걸 기반으로 grill-me 를 돌리는걸 추천합니다.

그러고 superpowers 의 writing-a-plan 으로 넘어가서 문서 만들고 코드 구현까지 이어서 하면

진짜 왠만한 주니어 개발자들은 다 씹어먹게 결과가 나옵니다.

왜 자신있게 말하냐면, 저도 씹어 먹혔거든요. 제가 만든것 보다 잘 만들더라고요.

참고로 grill-me 는 제가 만든 것은 아니고, 맷포콕 씨를 통해 알게 되었습니다.

skills/skills/productivity/grilling/SKILL.md at main · mattpocock/skills

Skills for Real Engineers. Straight from my .claude directory. - mattpocock/skills

github.com

이미 있는 코드베이스를 기반으로 할 때에는 grill-with-docs사용하면 됩니다.

skills/skills/engineering/grill-with-docs/SKILL.md at main · mattpocock/skills

Skills for Real Engineers. Straight from my .claude directory. - mattpocock/skills

github.com

[AI] AI 팩토리 건설, 초지능,폭발하는 데이터센터 AI칩 수요, 미국AI vs 중국AI 음모론 (퍼온글)

snowman95 — Fri, 19 Jun 2026 17:23:00 +0900

세계 1%는 이미 이 그림을 보고 베팅을 끝냈습니다.
세계에서 가장 영향력 있는 AI·반도체 거물들이 똑같은 미래를 짓고 있습니다. 그리고 이 흐름을 못 따라가는 기업은 소리 없이 밀려나고 있습니다.
이 글을 다 읽게 된다면 세상을 보는 시선이 달라질겁니다.

AI 팩토리

젠슨 황은 최근 방한에서 'AI 팩토리'를 이야기했습니다.
AI 팩토리란 전기와 데이터를 넣으면 토큰이 생산되는 지능 생산시설입니다. 과거 데이터센터가 데이터를 저장하고 서비스를 운영하는 공간이었다면, AI 팩토리는 AI가 답변과 코드, 이미지, 의사결정을 만들어내는 토큰을 끊임없이 생산하는 공장입니다. 제철소가 철광석으로 철을 만들고 발전소가 전기를 생산하듯, AI 팩토리는 전력과 데이터를 지능으로 바꿔냅니다.
그가 방한에서 제시한 청사진을 보면 GPU와 NPU가 연산을 수행하고, NVLink와 초고속 네트워크가 수만 개의 칩을 하나의 거대한 컴퓨터처럼 연결합니다.

그 위에서 AI 모델의 학습과 추론이 이뤄지고, 생산된 지능은 AI-RAN과 차세대 통신망을 통해 산업 현장으로 전달됩니다.
로봇과 자율주행은 AI 팩토리가 생산한 지능이 현실 세계에서 움직이며, 제조업, 물류, 금융, 의료는 이 지능을 소비하는 수요처가 됩니다.

소버린 AI는 국가마다 자국의 언어와 문화, 산업 데이터를 활용해 독자적인 AI 팩토리를 구축하는 전략입니다.
칩 설계부터 데이터센터, 네트워크, AI 모델, 운영 소프트웨어까지 엔비디아는 DSX AI Factory 플랫폼 위에서 이 생태계를 구축하려 하고 있습니다.

결국 AI 팩토리는 전기를 넣어 토큰을 생산하고, 토큰을 다시 경제적 가치로 바꾸는 새로운 시대의 생산시설입니다.
지금 시장의 가장 큰 논쟁은 이 투자가 거품이냐 진짜 수요냐입니다.
여기에 답할 수 있는 사람은 반도체 공급망의 양 끝에 있습니다. 칩을 설계하는 쪽과, 그 칩을 만드는 쪽입니다.
설계하는 쪽에는 AMD의 리사 수가 있습니다.

폭발하는 AI 칩 수요

AMD는 엔비디아의 라이벌이지만, 리사 수는 2026년 초 CES 기조연설에서 지금이 "10년짜리 슈퍼사이클의 시작"이라고 했습니다.
슈퍼사이클은 한두 해 반짝하는 수요가 아니라 10년 단위로 이어지는 구조적 호황을 뜻합니다.

만드는 쪽에는 TSMC의 C.C. 웨이가 있습니다.
엔비디아의 GPU도, AMD의 AI 칩도, 구글 TPU도 대부분 이 회사의 생산라인을 거칩니다. AI 시대의 파운드리 허브라고 불러도 과장이 아닙니다.

그는 최근 실적 발표에서 "AI 수요가 진짜인지 나도 긴장된다"면서도, "막상 보니 3개월 전 예상보다 수요가 더 강하다"고 했습니다.
그리고 최근 주주총회에서는 "AI 칩 수요는 앞으로도 수년간 공급을 초과할 것"이라고 말했습니다.
TSMC는 AI 수요를 믿고 수백억 달러를 투자해야 합니다.
수요를 잘못 읽으면 거대한 과잉설비가 남기 때문입니다.
AI 칩을 설계하는 엔비디아와 AI 칩을 생산하는 TSMC가 같은 방향을 보고 있다는 점입니다.

오픈AI의 샘 알트만은 이를 비용 곡선으로 설명하고, 앤트로픽의 다리오 아모데이는 "데이터센터 속 천재들의 나라"라고 표현합니다.
표현은 다르지만 그들이 가리키는 대상은 같습니다. 전기를 지능으로 바꾸는 거대한 AI 팩토리입니다.

이 공장이 이전의 모든 공장과 다른 점이 하나 있습니다.
자기 자신을 만들기 시작했다는 것입니다.

재귀적 자기개선의 초기 단계

MIT 물리학자 맥스 테그마크는 2017년 책 '라이프 3.0' 에서 생명을 "자기를 얼마나 직접 설계하는가"로 세 단계로 나눴습니다.
박테리아 같은 생명 1.0은 몸도 행동도 진화에 맡깁니다.
인간 같은 생명 2.0은 몸은 타고나지만 지식과 문화라는 소프트웨어는 직접 바꿉니다.

생명 3.0은 소프트웨어뿐 아니라 자기 몸, 곧 하드웨어까지 스스로 설계하는 단계입니다.

지금 그 단계가 실제로 시작되고 있습니다.
구글 딥마인드의 AlphaChip은 칩의 회로 배치를 AI가 직접 설계하는데, 사람이 몇 주 걸리던 일을 몇 시간 만에 끝내고 이미 구글의 자체 칩에 쓰이고 있습니다.

AI가 자기가 돌아갈 몸을 직접 그리기 시작한 것입니다.

거물들도 같은 방향을 이야기하고 있습니다.
알트만은 2025년 6월 에세이에서 자기 회사 연구자들이 AI 덕분에 두세 배 더 생산적이라며, 이것을 "재귀적 자기개선의 초기 단계"라고 불렀습니다.

다리오 아모데이는 "현세대 AI가 다음 세대를 스스로 만들어내는 시점이 1~2년밖에 안 남았을 수 있다"고 했고, 데미스 하사비스도 2026년 5월 "아직 시스템이 혼자 좋아지는 단계는 아니지만, 코딩 에이전트가 엔지니어를 훨씬 생산적으로 만드는 '부드러운 자기개선'은 이미 일어나고 있고, 모든 선도 연구소가 여기에 집중하고 있다"고 했습니다.
오픈AI는 2028년까지 '자동화된 AI 연구원'을 만들겠다는 목표를 내놨습니다.
이 자기개선이 끝까지 가는 지점을 특이점이라 부릅니다.

미래학자 레이 커즈와일은 오래전부터 2029년에 AI가 인간 지능에 닿고 2045년에 특이점이 온다고 예측해왔는데, 2024년 책에서는 그 2029년 예측이 오히려 보수적이었던 것 같다고 했습니다.

그렇다고 그 속도가 끝없이 빨라진다고 단정할 수는 없습니다.
CEO들의 낙관과 달리, 연구자들 사이에서는 다른 목소리가 나오고 있습니다.
출발점은 비슷합니다. "데이터와 컴퓨터를 더 들이붓기만 하면 좋아지던 시기는 끝났다"는 데에는 입장이 다른 연구자들이 대체로 동의하고 있습니다.

일리야 수츠케버는 오픈AI를 공동창업하고 핵심 모델을 이끈 과학자입니다.
회사를 떠나 '안전한 초지능(SSI)'을 차린 그는 2024년 말 "우리가 아는 형태의 사전학습은 끝난다"며 "데이터는 AI의 화석연료다. 인터넷은 하나뿐이고, 우리는 이미 그 정점에 도달했다"고 했습니다.
2025년 11월에는 "스케일링의 시대에서 다시 연구의 시대로 넘어가고 있다"고 정리했습니다.

해법은 갈립니다.

오픈AI의 노암 브라운은 모델이 답하기 전에 더 오래 '생각하게' 만드는 추론에서 길을 찾습니다.
그는 포커 AI 실험에서 "봇이 20초 더 생각하게 했더니 모델을 10만 배 키운 것과 같은 효과가 났다"고 말합니다.
실제로 이 방식을 쓴 추론 모델은 같은 수학 시험 점수를 13%에서 83%로 올렸습니다. 안드레이 카르파티는 더 신중합니다.
그는 쓸 만한 자율 에이전트가 나오려면 "에이전트의 해가 아니라 에이전트의 10년"이 걸린다며, 데모가 90% 작동하는 것과 99.9% 작동하는 것 사이에 똑같은 노력이 몇 겹씩 더 든다고 봅니다.
메타를 떠난 얀 르쿤은 더 멀리 가서, 지금의 언어 모델을 키우는 길로는 사람 수준 지능에 닿지 못하고 세계의 작동 방식을 학습하는 '월드 모델'이 필요하다고 주장합니다.
곡선은 갈림길에 서 있습니다. 다만 어느 길로 가든 더 많은 컴퓨트가 필요하다는 점은 같습니다.

그래서 이야기는 연료 문제로 넘어갑니다.
이 공장을 돌리려면 무엇이 얼마나 드는가, 그리고 누가 그것을 쥐고 있는가.
연료는 컴퓨트이고, 이제 컴퓨트는 부품이 아니라 자원입니다.
돈의 흐름을 보면 빅테크 다섯 곳이 데이터센터에 쏟는 설비투자 합계가 전 세계 석유·가스 생산에 들어가는 투자를 넘어섰습니다.
2026년 빅4의 설비투자만 6,300억 ~ 7,250억 달러로 한 해 만에 60~77% 늘었습니다.

한 시대가 가장 많은 돈을 쏟는 대상이 그 시대의 핵심 자원입니다.

핵심 연료: 석유 -> 컴퓨트 로의 이동

20세기에 그게 석유였다면, 지금은 컴퓨트입니다.

알트만은 이 자원의 성격을 두 가지로 정리했습니다.

하나, AI의 지능은 훈련과 구동에 쓴 자원의 로그값과 대략 비례한다는 것입니다.
돈을 열 배 더 쓰면 지능이 한 단계 올라간다는 뜻입니다.

둘, 같은 수준의 AI를 쓰는 비용은 1년에 약 10배씩 떨어진다는 것입니다.

무어의 법칙이 18개월에 두 배였던 것과 비교하면 훨씬 빠릅니다.
그래서 그는 "지능의 비용이 결국 전기 요금 수준으로 수렴할 것"이라고 봅니다. 지능이 전기처럼 흔하고 싼 것이 된다는 이야기입니다.
지능이 전기처럼 흔해지고, 단 하나의 자원이 문명 전체의 운명을 가르는 세계. 이런 설정을 SF가 이미 여러 번 그렸습니다.

프랭크 허버트의 '듄'에서 우주의 모든 권력은 '스파이스'라는 한 물질로 결정됩니다.

단 하나의 행성에서만 나오고, 그것 없이는 우주여행도 멈춥니다.

그래서 스파이스를 쥔 자가 우주를 쥡니다. 지금 그 스파이스 자리에 컴퓨트가 들어와 있습니다.

스파이스가 유한했던 것처럼, 이 연료에도 바닥이 있습니다.

AI 팩토리의 병목: 전력과 반도체

마이크로소프트의 사티아 나델라가 2025년 11월에 이렇게 말했습니다.
"지금 우리의 가장 큰 문제는 컴퓨트가 남아도는 게 아니라 전력이다. 꽂을 수 없는 칩이 창고에 쌓여 있을 수 있다." 칩은 충분히 사놨는데 그것을 돌릴 전기와 건물이 없다는 이야기입니다.
게다가 추론, 곧 완성된 모델을 계속 돌려 답을 만들어내는 일이 전체 AI 연산의 80~90%를 차지하면서, 전력은 한 번 쓰고 마는 게 아니라 쉬지 않고 들어갑니다.
미국 데이터센터의 전력 수요는 2028년 74GW에 이르는데, 확보 가능한 전력은 49GW가량 모자랍니다.

SK의 최태원은 병목을 한 칸 더 안쪽에서 봅니다.
"AI 칩의 진짜 병목은 메모리"라며, 오픈AI가 요청한 월 90만 장의 HBM이 "전 세계 한 달 생산량의 두 배"라고 했습니다. 그리고 이 메모리 병목을 쥔 건 한국의 두 회사입니다.

SK하이닉스는 2026년 1분기에 매출 52조 원, 영업이익 37조 원으로 사상 최대 실적을 냈는데, HBM 한 품목이 연 매출 200% 이상 성장하며 그 실적을 끌어올렸습니다.
삼성전자도 같은 분기에 영업이익 57조 원으로 역대 최대를 찍으며 차세대 HBM4 양산에 들어갔습니다.
젠슨 황은 2026년 6월 방한에서 삼성·SK하이닉스·마이크론 세 곳 모두 HBM4 자격 심사를 통과해 엔비디아의 차세대 플랫폼 '베라루빈'에 공급을 두고 경쟁 중이라고 확인했습니다.
최태원은 그 자리에서 "메모리 생산력을 두 배로 늘리겠다"고 했습니다. AI 팩토리의 가장 깊은 병목 하나를 한국 기업이 쥐고 있는 셈입니다.

전력을 확보하는 일이 곧 AI 전략이 되면서, 원자력이 되살아나고 있습니다.
1979년 노심 용융 사고로 악명 높은 쓰리마일섬에서, 사고와 무관하게 돌아가다 2019년 경제성 문제로 문을 닫았던 1호기 원자로가 마이크로소프트와 20년 전력 공급 계약을 맺고 2027년 재가동을 준비합니다.

아마존은 소형 원자로(SMR)로 최대 960MW를, 오라클은 원자로 세 기로 1GW급 데이터센터를 설계하고 있습니다.
이 갈증은 전력에서 멈추지 않습니다. AI 인프라는 한 산업의 한계에 부딪힐 때마다 그 너머의 다음 산업을 끌어당깁니다. 원자력 다음은 핵융합입니다.

알트만이 의장을 맡았던 핵융합 스타트업 헬리온은 마이크로소프트에 2028년부터 핵융합 전기를 공급하겠다는 계약을 맺었습니다.
구글은 커먼웰스 퓨전과 200MW 규모의 핵융합 전력 구매 계약을 체결했습니다. 늘 "30년 뒤"라고 불리던 핵융합이 전기를 사겠다는 계약서의 대상이 되었습니다.

그 옆에서 양자컴퓨팅도 움직입니다.
구글의 윌로 칩은 2024년 말, 큐비트를 늘릴수록 오류가 줄어드는 단계에 처음 도달했습니다.
전력 부족은 연산을 아예 지구 밖으로 밀어내고 있습니다.
구글은 AI 칩을 실은 위성으로 궤도에서 연산을 돌리는 '프로젝트 선캐처'를 공개하며 2027년 시제 위성 발사를 예고했고, 엔비디아가 투자한 스타클라우드는 2025년 11월 이미 고성능 GPU를 실은 위성을 띄워 우주에서 AI 모델을 돌렸습니다.

그리고 이 모든 연산이 마지막으로 향하는 곳이 로봇입니다.
피규어의 휴머노이드는 BMW 공장 라인에 들어갔고, 일론 머스크는 "테슬라 가치의 80%가 옵티머스 로봇이 될 것"이라며 연 100만 대 생산을 이야기합니다. 중국의 유니트리는 2025년에만 약 5,500대를 출하했습니다.

한국도 이 경쟁의 한복판에 있습니다.
현대차가 2021년 인수한 보스턴 다이내믹스는 2026년 1월 CES에서 양산형 전기 휴머노이드 아틀라스(Atlas)를 공개했고, 2028년부터 미국 조지아 공장에 투입해 부품 분류·이송부터 시작하기로 했습니다.
컴퓨트가 전력을 부르고, 전력이 핵융합과 양자와 우주를 부르고, 그 끝에서 지능이 로봇의 몸을 입고 공장으로 들어옵니다.
데이터센터 하나가 산업 지도 전체를 다시 그리고 있습니다.

공장은 거침없이 돌아가는 것처럼 보이지만, 정작 돈은 벌지 못하고 있습니다.

빅테크 주식이 못 오르는 이유: 무리한 설비투자

2026년 빅4(마이크로소프트·구글·메타·아마존)의 설비투자는 6,300억 달러를 넘어섰는데, UBS 추정으로 이 금액이 그들이 사업에서 버는 영업현금흐름의 거의 전부를 잠식합니다.
지난 10년 평균이 40% 수준이었던 것과 비교됩니다. 흑자 기업들이 모자란 돈을 빚으로 메우기 시작했고, 2026년 AI 관련 채권 발행은 약 5,700억 달러로 한 해 만에 거의 두 배가 될 전망입니다.

모델을 만드는 회사들의 사정은 더 분명합니다.
오픈AI는 연 매출이 250억 달러를 넘어섰지만 2026년에 약 140억 달러 적자를 볼 것으로 예상되고, 흑자 전환은 2020년대 후반에서 2030년대로 잡혀 있습니다.

알트만이 밝힌 컴퓨트 약정 총액은 약 1.4조 달러로, 현재 매출의 50배가 넘습니다.

오라클이 공시한 미래 매출 잔액의 절반 이상이 오픈AI 한 곳에서 나옵니다.

앤트로픽은 연 매출이 2026년 5월 약 470억 달러 규모까지 올라오며 기업가치가 1조 달러에 근접했지만, 두 회사 모두 아직 순이익을 내지 못합니다.

매출은 빠르게 늘고 있는데, 약속한 지출이 그 매출을 한참 앞지릅니다.
공장은 돌아가지만, 그 공장이 언제 본전을 뽑을지는 아무도 자신 있게 말하지 못합니다.

AI 버블론: 사실은 돈이 한바퀴 도는 것이다.

그래서 거품 논쟁이 나옵니다. 의심의 핵심은 돈이 한 바퀴 돌아 제자리로 온다는 구조입니다.
엔비디아가 오픈AI에 투자하고, 오픈AI가 그 돈으로 오라클·코어위브의 컴퓨트를 빌리고, 그들이 다시 엔비디아 칩을 삽니다.
분석가들은 이런 식으로 서로 사주는 거래가 AI 공급망 전체에 8,000억 달러 규모로 얽혀 있다고 봅니다.

국제통화기금(IMF)과 영란은행은 2025년 10월, AI 주식의 밸류에이션이 25년 전 닷컴 버블 수준에 근접했고 실망스러운 결과가 나오면 급격한 조정이 올 수 있다고 함께 경고했습니다.

놀랍게도 가장 서늘한 경고는 당사자에게서 나왔습니다.

아모데이는 2026년 초 한 대담에서 이렇게 말했습니다. "내 매출이 1조 달러가 아니라 8천억 달러만 되어도, 그만큼 컴퓨트를 사들였다면 지구상 어떤 힘도 내 파산을 막을 수 없다." 시장 규모를 모른 채 데이터센터에 다년 계약을 걸어야 하는 구조 자체가 위험하다는 것입니다.
물가를 두고도 정반대 진단이 부딪힙니다.

ARK인베스트의 캐시 우드는 AI가 학습 비용을 1년에 약 75%씩 떨어뜨려 경제 전반에 물가를 낮추는 힘으로 작용한다고 봅니다.

1840년대 영국의 철도 광풍이 대표적입니다.
의회가 한 해에만 263개의 철도회사 설립을 허가했고, 누구나 계약금 10%로 주식을 살 수 있었습니다.
1845년 금리 인상과 함께 철도주는 약 66%까지 빠졌고, 허가된 노선의 3분의 1은 끝내 지어지지 않았으며, 전 재산을 넣은 중산층 가정이 무너졌습니다.
그런데 그때 깔린 선로가 오늘날 영국 철도망의 절반 이상이 되었습니다.
1858년 대서양 횡단 전신 케이블은 개통 몇 주 만에 끊겨 초기 투자자들이 손실을 봤지만, 그 시도가 1866년의 성공으로 이어졌습니다.
1930년대에는 전력왕 새뮤얼 인설의 제국이 8억 달러 손실과 함께 무너졌지만, 그가 깔아둔 발전망은 미국 전기화의 골격으로 남았고 붕괴는 오늘날의 회계·공시 규제를 낳았습니다.

가장 비슷한 사례는 닷컴 버블입니다.
1990년대 후반 통신사들은 "인터넷 트래픽이 100일마다 두 배"라는 전망을 믿고 광케이블을 경쟁적으로 깔았습니다.
2000년 거품이 터졌을 때 그 광케이블의 85~95%는 쓰이지 않은 채 묻혀 있었습니다.
그런데 값이 폭락한 그 광케이블 위에서 유튜브와 넷플릭스, 클라우드가 자라났습니다. 구글은 2005년부터 헐값의 광케이블을 사들여 자기 망을 깔았습니다.
깔 때는 광기였지만, 깔리고 나니 다음 시대의 토대가 된 것입니다.
여기서 두 가지를 같이 봐야 합니다. 버블은 자본을 태우지만 인프라는 남긴다는 것, 그리고 그 과정에서 투자자와 창업자 다수는 파산한다는 것입니다.

제프 베조스가 지금의 AI를 "생산적인 거품"이라 부르는 근거가 앞쪽이라면, 마이클 버리 같은 회의론자가 보는 것은 뒤쪽입니다.

AI가 과거와 다른 점도 있습니다.
투자 규모가 GDP에서 차지하는 비중이 철도(약 6%)보다 작고(2~3% 수준), 외부 차입이 아니라 빅테크의 내부 현금이 주된 자금원이라 무너지기까지의 문턱이 높습니다.
다만 소수 기업에 대한 쏠림, 아직 없는 수익성, 그리고 점점 부채로 옮겨가는 위험은 과거 거품과 똑같이 닮아 있습니다.

엔비디아가 못오르는 이유: 모두가 자신의 칩을 만드려고 한다.

거물들이 같은 공장을 짓는다고 했지만, 그들은 그 공장의 심장인 칩을 엔비디아 한 곳에서만 사고 싶어 하지 않습니다.
그래서 다들 조용히 자기 칩을 만들고 있습니다.

오픈AI는 브로드컴과 100억 달러 규모의 자체 칩을 만들기로 했고, 두 회사는 이를 10기가와트 규모로 키우며 "AGI를 향한 분기점"이라고 불렀습니다.구글은 TPU, 아마존은 트레이니움, 마이크로소프트는 마이아, 메타는 MTIA라는 자체 칩을 이미 가동하고 있습니다.
메타는 약 6개월마다 새 칩을 내놓습니다.

이런 맞춤형 칩(ASIC)의 출하는 2026년에 44.6% 늘어 범용 GPU(16.1%)의 거의 세 배로 자랄 전망이고, 엔비디아의 약 70% 점유율이 깎일 거라는 예상이 나옵니다.
큰 그림을 무대에서 공개적으로 말하는 건 젠슨 황이지만, 나머지는 입을 닫은 채 같은 것을 만들고 있습니다.
풀스택을 떠드는 회사는 엔비디아뿐이어도, 모두가 그 풀스택의 한 층씩을 자기 것으로 가져가려 움직입니다.

엔비디아 젠슨황이 순회 공연을 그렇게 열심히 다닌 이유

엔비디아도 가만히 있지 않습니다.
고객이 자체 칩으로 빠져나가는 걸 막기 위해, 칩이 아니라 그 둘레를 묶는 쪽으로 움직입니다. 일곱 조각 중 인터커넥트와 무선통신이 여기서 무기가 됩니다.

하나는 인터커넥트입니다.
엔비디아는 NVLink Fusion이라는 기술로 남이 만든 커스텀 칩까지 자기 연결망에 끌어들입니다.
GPU 하나가 초당 1.8테라바이트로 다른 칩과 대화하는 이 연결망 위에 미디어텍·마벨·퀄컴의 칩을 얹게 하는 방식입니다.
자체 칩을 만들어도 결국 엔비디아의 연결망 위에서 돌리게 되는 구조입니다.

다른 하나는 무선통신입니다.
엔비디아는 노키아에 10억 달러를 투자해 6G 이동통신 기지국에 AI 연산을 넣는 사업으로 발을 넓혔습니다.
데이터센터를 넘어 통신망 자체를 자기 플랫폼으로 끌어들이는 것입니다.
소프트웨어(CUDA)라는 기존 울타리가 약해지기 전에, 칩 너머의 층인 연결망과 통신, 운영까지 자기 플랫폼에 묶어두려는 움직임입니다.

중국 AI vs 미국 AI

이 공장에는 국적이 있습니다.
같은 공장을 따로 지으려는 미국과 중국이 칩 한 종류를 두고 부딪치고 있습니다.

2025년 1월, 중국 스타트업 딥시크가 미국 최고 모델에 가까운 성능을 훨씬 적은 비용으로 냈다고 알려지자 일주일 만에 엔비디아 시가총액이 하루에 약 6,000억 달러 증발했습니다.
"중국은 AI를 못 한다"는 통념이 깨진 순간입니다. 이후 알리바바를 비롯한 중국 기업들의 모델이 미국 최상위 모델과의 격차를 좁혔습니다.
하드웨어에서도 중국은 다른 길을 찾았습니다.
미국이 첨단 칩 수출을 막자, 화웨이는 성능이 떨어지는 칩을 수백 개씩 묶어 그 차이를 머릿수로 메웁니다. 값싼 전력과 큰 클러스터라는 중국식 해법입니다.

이 경쟁의 불확실성은 젠슨 황의 입에서 그대로 드러났습니다.
그는 2025년 11월 한 행사에서 "중국이 AI 경쟁에서 이길 것"이라고 했다가 몇 시간 뒤 "중국은 미국에 나노초 차이로 뒤처져 있을 뿐"이라고 정정했습니다.

미국 정부는 이 경쟁을 국가 전략으로 끌어올렸습니다.

트럼프 행정부가 2025년 7월 내놓은 '미국 AI 행동계획'은 첫 문장에서 "미국은 인공지능에서 글로벌 지배를 달성하기 위한 경쟁 중"이라고 못 박았습니다.
같은 날 데이터센터 인허가를 빠르게 처리하는 행정명령과 미국 AI를 동맹국에 수출하는 프로그램이 함께 서명됐습니다.

이 전략 안에는 풀기 어려운 모순이 있습니다.
한쪽에는 "적당히 팔아 중국을 우리 기술에 묶어두자"는 논리가, 다른 쪽에는 "차단해 격차를 벌리자"는 논리가 있습니다.
상무장관 하워드 러트닉은 엔비디아의 대중국 수출을 옹호하며 "중국 개발자들이 미국 기술에 익숙해지게 만드는 것"이 목적이고 중국에는 "네 번째로 좋은 칩"만 간다고 했습니다.

실제 정책은 두 논리 사이에서 오갔습니다.
엔비디아의 중국용 칩 H20은 2025년 4월 막혔다가 7월에 풀렸고, 8월에는 엔비디아와 AMD가 대중국 매출의 15%를 미국 정부에 내는 조건이 붙었으며, 12월에는 더 강한 H200을 매출의 25%를 받는 조건으로 푸는 데까지 갔습니다. 그때마다 여야 안보 강경파가 반발했습니다.

이 혼란 속에서 젠슨 황은 다보스 2026에서 다른 각도의 주장을 폈습니다.
막대한 설비투자가 거품의 신호가 아니라 "인류 역사상 가장 큰 인프라 빌드아웃"의 증거라는 것입니다.
그 근거로 그는 "요즘 엔비디아 GPU를 빌리기가 너무 어렵고, 두 세대 전 GPU의 대여 가격마저 오르고 있다"는 점을 들었습니다.
실수요가 공급을 넘어선다는 이야기입니다

이 혼란 속에서 가장 일관된 이론을 내놓은 사람이 다리오 아모데이입니다.
그는 딥시크 충격 직후 쓴 글에서 시장의 통념을 뒤집었습니다.
대부분은 딥시크를 두고 "적은 돈으로 비슷한 걸 만들었으니 칩을 막아봐야 소용없다"고 읽었습니다. 아모데이의 생각은 반대입니다.
기술이 싸지는 건 원래 예정된 일이고, 비용이 내려가면 같은 돈으로 더 멀리 갈 수 있으니 칩을 많이 가진 쪽이 오히려 더 유리해진다는 것입니다.
그래서 그는 "딥시크는 수출통제를 더 중요하게 만들었다"고 결론지었습니다.

그의 논리는 두 갈래 미래로 정리됩니다.
인간 대부분보다 똑똑한 AI를 만들려면 수백만 개의 칩과 수백억 달러가 드는데, 그 시점이 2026~2027년에 온다고 봅니다.
그때 중국이 칩을 충분히 확보하면 미국과 중국이 각자 강력한 AI를 갖는 양극 세계가 되고, 확보하지 못하면 미국과 동맹만 가진 단극 세계가 됩니다.

그 우위가 영구적이 되는 이유는 자기개선 때문입니다.
먼저 수백만 개의 칩을 확보한 쪽은 더 강한 모델을 만들고, 그 모델이 다시 더 나은 칩과 더 효율적인 AI를 설계합니다.
일시적인 칩 격차가 시간이 갈수록 따라잡을 수 없는 기술 격차로 굳어진다는 것입니다.

2026년 다보스에서 그는 중국에 첨단 AI 칩을 파는 것을 두고 "북한에 핵무기를 파는 것과 같다"고까지 말했습니다.
엔비디아가 앤트로픽의 주요 파트너이자 투자자라는 점을 생각하면 매우 이례적으로 강한 발언입니다. '먼저 차지하면 영원히 이긴다'는 논리는 SF 독자에게 낯설지 않습니다.
류츠신의 소설 '삼체'가 그린 '암흑의 숲'이 정확히 그것입니다.

그 우주에서는 어떤 문명도 상대의 속내를 확신할 수 없기에, 먼저 발견한 쪽이 먼저 쏘는 것만이 생존의 길입니다.
미국과 중국이 서로의 AI를 잠재적 위협으로 보고, 한쪽은 칩을 틀어막아 상대의 발전을 막고 소설 속 외계 문명이 '지자(智子)'라는 입자를 보내 인류의 기초과학을 동결시킨 것처럼 다른 쪽은 값싼 전력과 머릿수로 그 봉쇄를 우회합니다.
두 나라가 진짜 두려워하는 것은 상대의 AI가 무엇을 할 수 있느냐가 아니라, 상대가 그것을 먼저 가질지도 모른다는 불확실성 그 자체입니다.
이건 이론이 아니라 이미 현실에서 돌아가고 있습니다.
칩이 외교의 수단이 된 것입니다.

폭발적인 데이터베이스 건설

오픈AI와 소프트뱅크, 오라클이 2025년 1월 발표한 스타게이트 프로젝트는 4년간 5,000억 달러, 10기가와트를 내건 미국 본토 인프라로 시작했습니다.

텍사스 애빌린 본진은 이미 가동에 들어갔고, 2026년 6월에는 미시간에 160억 달러를 들인 1GW급 단지가 착공됐습니다.
다만 같은 시기 애빌린을 2GW로 키우려던 확장 계획은 전력 확보 지연과 차세대 하드웨어 전환을 이유로 철회됐고, 오픈AI는 전체 인프라 약정을 1.4조 달러에서 2030년까지 약 6,000억 달러 규모로 낮춰 잡았습니다.
짓겠다는 그림과 실제로 지어지는 그림 사이의 간격이 여기서 드러납니다.
이 흐름은 미국을 넘어 중동으로 뻗었습니다.
아랍에미리트 아부다비에는 5GW 규모의 미국·UAE 합작 AI 캠퍼스가, 사우디 국부펀드가 세운 회사에는 3년간 최대 60만 개의 엔비디아 유닛이 들어갑니다.

그런데 이 칩에는 조건이 붙습니다. 화웨이 장비를 단계적으로 걷어내고 중국 기술에서 손을 떼라는 것입니다. 미국 AI 한 벌을 통째로 사는 것이 동맹의 입장료가 된 셈입니다.

소프트뱅크의 손정의는 이 흐름의 가장 큰 베팅을 합니다.
2026년 6월 파리에서 그는 AI를 두고 "닷컴보다 10배, 아마 50배는 큰" 혁명이라며 거품이 아니라 "이제 막 시작"이라고 했습니다.
같은 자리에서 프랑스에 약 870억 달러를 들여 5GW 데이터센터를 짓겠다고 발표했습니다.

그는 2025년 12월 한국에서는 다른 경고를 했습니다.

한국의 GPU 확보 계획으로는 초지능에 "턱없이 부족"하며, 한 곳을 돌리는 데만 GPU 100만 장과 1GW 전력이 필요하다는 것입니다.

소버린 AI

자국 AI 주권을 외칠수록 엔비디아라는 한 공급자에 더 깊이 묶이는 역설이 여기서 시작됩니다.

한국이 겪는 일은 AI 시대에 주권이 위협받는 한 가지 방식일 뿐입니다.
같은 시기에 다른 나라들은 다른 방식으로 시험받고 있습니다.
그린란드는 영토 자체가 표적입니다. 트럼프 행정부는 2025년부터 그린란드 인수를 공개적으로 밀어붙였는데, 명분은 희토류와 북극 항로입니다.
둘 다 AI·반도체 공급망의 핵심 자원입니다.
그린란드 총리는 2026년 1월 "미국과 덴마크 중 굳이 고르라면 우리는 덴마크를 택한다. 주권은 양보할 수 없는 선"이라며 거부했습니다.
이란은 반대편 끝, 배제의 사례입니다.
미국의 수출통제로 첨단 칩 접근이 막히자, 이란은 국산 AI 칩과 외국 서비스 없이도 작동하는 국가 AI 운영체제를 직접 만들겠다고 나섰습니다.

한 관계자는 이를 "칩과 알고리즘의 전쟁"이라 불렀습니다.
세 나라를 겹쳐 보면 AI 시대 주권의 세 얼굴이 드러납니다.
영토(그린란드), 배제(이란), 종속(한국)입니다

개발 협력 분야의 한 분석가는 종속의 역설을 날카롭게 비판합니다.
"소버린 AI를 가장 크게 외치는 사람은 어느 나라 정상이 아니라 엔비디아 CEO다. 그는 모든 나라에 자국 AI가 필요하다고 말하면서, 그 AI가 사야 할 GPU를 판다."

그의 결론은 "주권은 포장이고, 종속은 내용물"이라는 것입니다.
젠슨 황의 방한이 남긴 질문도 같습니다. 한국의 한 신문 사설처럼, 한국은 엔비디아에 "필요한 나라"는 됐지만 "대체 불가능한 나라"가 된 것은 아닙니다.

기업들이 파트너 명단에 이름을 올릴수록, 한국의 기술과 데이터는 엔비디아 플랫폼을 따라 흩어질 수 있습니다.

기술 기업이 국가권 권력을 쥔다면?

왜 하필 이 사람들이, 왜 지금 이 큰 베팅을 동시에 하는 걸까요.
이 질문의 답은 1997년에 나온 책 한 권으로 거슬러 올라갑니다. '주권적 개인(The Sovereign Individual)'입니다.
이 책이 중요한 이유는, 실리콘밸리에서 가장 영향력 있는 투자자인 피터 틸이 이 책을 "지금까지 읽은 가장 영향력 있는 책"으로 꼽으며 "페이팔을 시작하기 직전에 읽었다"고 밝혔고, 2020년 재판에 직접 서문을 썼기 때문입니다.
책의 예언은 지금과 겹치고 있습니다.
정보혁명이 국민국가를 약화시키고, 국가의 통제를 벗어난 소수의 '인지 엘리트'가 등장한다는 것입니다.
한 사람이 막대한 가치를 만드는 동안 옆 사람은 아무것도 못 만드는 극단적 양극화도, 국경 없이 거래되는 암호화폐도 이 책에 적혀 있었습니다.

이 책의 처방은 '탈출'이었습니다.
국가 바깥에 기술로 새 공간을 만들라는 것이었습니다. 페이팔이 그 첫 시도였고, 우주와 자유도시 실험이 뒤를 이었습니다.
그런데 2025년 들어 이 흐름이 뒤집힙니다.
탈출을 말하던 사람들이 정치의 정점에 올라섰습니다. 틸이 후원한 J.D. 밴스가 부통령이 됐고, 페이팔 창업 멤버였던 데이비드 색스가 백악관에서 미국의 AI 정책을 맡았습니다.
한편 틸의 펀드는 오픈AI와 앤트로픽 양쪽에 투자해, 어느 쪽이 이기든 같은 네트워크가 지분을 챙기도록 해두었습니다.
그 책이 그린 설계도가 이번에는 탈출이 아니라 통치의 형태로 실현되고 있습니다.

기업이 국가급 권력을 쥐기 시작하면 세상은 어떤 모습이 될까요.

이것도 SF가 먼저 그렸습니다. 사이버펑크입니다.

윌리엄 깁슨의 소설 '뉴로맨서', 영화 '블레이드 러너', 게임 '사이버펑크 2077'에는 공통점이 있습니다. 정부보다 강한 거대 기업이 사회를 실질적으로 지배합니다.
도시의 네온사인과 마천루는 국가가 아니라 기업의 영역 표시입니다. 저는 전에 이 구도를 '메가 컴프', 곧 소수의 거대 컴퓨팅 기업이 지능 인프라를 독점하는 구조라고 불렀습니다.
지금 거물들의 행동이 그 풍경을 현실로 옮기고 있습니다.

일론 머스크의 xAI는 발전소급 전력을 끌어 쓰는 '콜로서스'라는 슈퍼컴퓨터를 짓고, 머스크는 이것을 "디지털 초지능의 여명을 위해 설계됐다"고 표현합니다.

저커버그의 메타는 1GW급 데이터센터 '프로메테우스'를 2026년 가동하고 최대 5GW까지 키울 '하이페리온'을 짓고 있습니다.
저커버그 본인의 표현으로 이 시설 하나가 "맨해튼 상당 부분을 덮는" 크기이고, 두 시설이 쓰는 전력은 미국 가정 400~500만 가구분에 맞먹습니다.

이 힘을 어떻게 쓸 것인가를 두고, 만드는 사람들 자신이 네 갈래로 갈립니다.
같은 공장을 지으면서 그 공장이 살 세상의 정치는 다르게 그리고 있습니다.

오픈AI의 알트만은 '풍요와 보편화'를 말합니다.
지능에 대한 접근이 결국 기본적 인권처럼 될 것이라며, "매주 1GW의 새 AI 인프라를 찍어내는 공장"을 목표로 내겁니다. 안전에 대한 그의 답은 기술을 조금씩 세상에 내보내 사회가 함께 적응하게 하는 것입니다.

앤트로픽의 아모데이는 같은 풍요를 인정하면서도 위험과 집중을 먼저 봅니다. 그는 부의 집중을 민주주의에 대한 위협으로 보고, 실리콘밸리에서 드물게 누진세와 부유세를 직접 제안합니다.

메타의 저커버그는 두 회사와 선을 긋습니다.

그가 2025년 7월 내놓은 '개인 초지능' 선언의 핵심은, 초지능을 중앙에서 통제해 모든 노동을 자동화하고 사람들은 그 결과를 배당으로 받는 방식이 아니라, 그 힘을 개인의 손에 직접 쥐여 주겠다는 것입니다.

알트만도 권력의 집중을 경계합니다.
그는 2026년 4월 한 글에서 "AGI는 한번 보면 다시 못 본 척할 수 없다. 거기엔 '절대반지' 같은 역학이 있어 사람을 미치게 만든다"며, 해법은 누구도 그 반지를 독점하지 않도록 기술을 널리 나누는 것이라고 했습니다.
"소수의 AI 연구소가 인류의 미래를 결정하는 건 옳지 않다"는 겁니다.
이들이 무엇을 약속하든, 이 공장이 돌아가며 가장 먼저 닥치는 현실은 양극화입니다. '주권적 개인'이 이미 적어둔 내용이기도 합니다.

양극화는 이미 예측이 아니라 측정되는 현재입니다.

AI 와 고용

스탠퍼드 연구진은 2025년 이를 '탄광 속 카나리아'라 불렀습니다.
AI에 많이 노출된 직종에서 22~25세 청년 고용이 2년 새 13% 줄었는데, 같은 직종의 경력직은 오히려 늘었습니다.
AI가 학교에서 배운 지식은 대체해도 현장에서 쌓는 경험은 아직 대체하지 못하기 때문입니다.

2026년 1분기에만 테크 업계에서 약 7만 8천 명이 해고됐고 그 절반가량이 AI·자동화 탓이었습니다.
세일즈포스 CEO는 그해 소프트웨어 엔지니어를 한 명도 새로 뽑지 않았다고 했습니다.
'AI 대부' 제프리 힌턴의 말대로 "AI는 소수를 훨씬 부유하게, 대다수를 더 가난하게" 만들고 있는 셈입니다. 그는 기본소득으로 메우면 되지 않느냐는 물음에 "그것은 사람이 일에서 얻는 존엄을 다루지 못한다"고 했습니다.

아모데이는 한때 "5년 안에 초급 사무직의 절반이 사라질 수 있다"고 했다가, 2026년에는 "일의 90%를 자동화하면 나머지 10%가 100%로 커진다"는 논리로 말을 바꿨습니다.
다만 그조차 "AI는 너무 빨라서 그 전환기에 밀려난 사람을 제때 구하지 못할 수 있다"는 단서를 달았습니다.
이 격차는 한국 사회에 이미 또렷한 신호로 나타나고 있습니다.

AI 가 완전히 뒤바꾼 고용 보상 체계. 이런 AI발

2025년 실적으로 SK하이닉스는 기본급의 29배가 넘는 성과급을 풀어,

연봉 1억 원인 직원이 1억 5천만 원에 가까운 보너스를 받았습니다.

같은 시기 중소기업 임금은 대기업의 61% 수준에 머물렀고, 일도 구직도 하지 않는 '쉬었음' 청년이 20대에서만 43만 명에 이릅니다.
같은 생태계 안에서도 칩을 만드는 본사와 부품을 대는 협력사, 본사 안에서도 사업부에 따라 보상이 몇 배씩 갈립니다.

'AI가 만드는 부'가 어디로 흐르는지를 성과급 명세서가 먼저 보여주고 있는 겁니다.
남는 일자리의 성격도 달라집니다.

오픈AI 내부 논의에서도 인간에게 남는 몫은 "직접 만드는 능력"이 아니라 "좋은 문제를 고르는 감각, 중간 결과를 의심하는 눈, 검증 방법을 설계하는 능력"으로 옮겨간다고 봅니다.
일리야 수츠케버가 거듭 강조한 문장이 이를 요약합니다. "결국 문제는 전부 권력이다."
마이크로소프트의 사티아 나델라는 2026년 6월, 이 변화를 '자본'의 언어로 바꿔놓았습니다. 이제 모든 회사가 두 종류의 자본을 쌓아야 한다는 것입니다.
사람의 지식·판단·관계·패턴 인식인 '인적 자본'과, 회사가 직접 만들고 소유하는 AI 역량인 '토큰 자본'입니다.
그는 "일이나 직무는 떠넘길 수 있어도 학습은 떠넘길 수 없다"며, 사람과 AI가 복리로 함께 쌓이는 학습 루프를 쥔 회사만 살아남는다고 했습니다.

범용 모델은 갈아끼울 수 있어도 그 안에 쌓인 '회사 고참'의 전문성을 잃지 않는 것, 그것이 앞으로 기업 주권의 시험대라는 겁니다.

여기서 거시경제의 그늘이 드러납니다.
나델라 본인이 비유했듯, 세계화 1단계에서 공장을 해외로 넘길 때도 GDP 숫자는 멀쩡해 보였습니다.
그런데 그 아래에서 산업 전체가 통째로 비워졌고, 후유증은 지금도 남아 있습니다.

AI 시대에 비워지는 것은 공장이 아니라 '지식' 그 자체입니다. 한 회사가 수십 년 쌓은 전문성이 모델 속으로 빨려 들어가 누구나 쓰는 상품이 되면, 그 회사는 자기 산업에서 발밑이 꺼집니다.
나델라는 "소수의 모델이 모든 가치를 빨아들이면 정치경제가 결코 그것을 용납하지 않을 것"이라고 경고했는데, 정작 그 소수 중 하나가 마이크로소프트입니다.

토큰의 경제화

경고하는 자와 그 공장을 짓는 자가 같다는 것, 이게 토큰 경제의 가장 음습한 대목입니다.

그래서 새 계급의 분할선은 토큰, 곧 누가 연산 자원을 쥐었는가입니다.
컴퓨팅을 일찍 확보한 쪽은 수백 개의 자율 작업을 동시에 돌리며 지능을 매일 복리로 쌓지만, 그렇지 못한 쪽은 표준이 된 방식을 따라가기만 해도 한 달 예산을 사흘 만에 태웁니다.
이걸 '토큰 불평등'이라 부르는데, 문제는 이 격차가 일시적이지 않고 대물림된다는 점입니다. 지금 굳어지는 계급은 다음 세대로 넘어갑니다.

토큰이 곧 삶을 가르는 화폐가 되는 세계를 영화 '인 타임'이 정확히 그렸습니다.
그 세계에서 시간은 화폐이고, 사람들은 팔뚝에 새겨진 시계로 남은 시간을 벌어 연명합니다.
부자는 수백 년을 비축해 사실상 불멸하고, 빈자는 하루치를 벌지 못하면 그 자리에서 멈춥니다. 토큰을 쌓아두는 자와 매일 벌어 그날 쓰는 자의 격차가 그대로 수명이 되는 겁니다.
현실의 통계도 이 그림을 따라갑니다.

2025년 한 분기에 미국 상위 10% 가구의 부는 5조 달러 늘었는데 하위 50%는 1,500억 달러 느는 데 그쳤고, 하위 절반이 가진 주식은 전체의 1%뿐입니다.

엔비디아 주가가 아무리 올라도 국민 절반의 통장과는 무관합니다.
지능이 값싸고 흔해질수록, 그것이 소유한 소수의 전유물이 되는 역설입니다.
계급이 아예 공간으로 갈라지는 장면은 영화가 백 년 전부터 그려왔습니다.
1927년 '메트로폴리스'에서 지상의 엘리트는 정원을 거닐고, 지하의 노동자는 기계를 돌리다 스러집니다.
2013년 '엘리시움'에서 부자는 궤도 위 낙원에서 첨단 의료를 누리고, 지구에 남은 다수는 과밀과 빈곤 속에서 그들의 로봇에게 통제받습니다.

듄 역시 1만 년 전 '버틀레리안 지하드'로 생각하는 기계를 모두 부순 세계입니다.

프랭크 허버트가 그 설정으로 경고한 것은 기계 자체가 아니라, 기계에 지능을 위탁한 인류가 그것을 쥔 소수 기술 계급에 영영 종속된다는 미래였습니다.
그래서 그 세계는 기계 대신 인간을 극한까지 훈련시킨 '멘타트'를 길렀습니다.

2026년의 우리는 정반대로, 기계에 지능을 통째로 맡기는 길을 골랐습니다.
그렇다면 허버트의 질문이 그대로 돌아옵니다. 그 지능을 쥔 소수는 누구이고, 나머지는 어디에 서게 되는가.
일리야 수츠케버는 "인간은 방대한 사전지식 없이도 지속학습으로 배운다"며 그것이 기계에 아직 없는 능력이라고 했지만, 정작 그 지속학습의 압박은 사람을 짓누릅니다.
프롬프트를 익히면 에이전트가, 에이전트를 익히면 루프 설계가 나오는 식으로 새 기법이 끝없이 쏟아져, 엔지니어의 절반 넘는 수가 AI를 쓴 뒤 오히려 핵심 역량이 퇴화했다고 답할 정도입니다.
지능이 흔해지는 시대에, 사람은 그 지능을 따라잡느라 지쳐갑니다.

지능 권력의 세 갈래 길

그 권력이 어디로 쏠리느냐를 두고 세 갈래 길이 갈립니다. 방향은 다른데 종착지는 비슷합니다.

첫째는 기업이 국가를 흡수하는 길입니다.
경제학자 야니스 바루파키스는 이미 자본주의가 끝나고 '기술 봉건주의'가 들어섰다고 봅니다. 아마존·구글 같은 '클라우드 자본'이 중세 영주처럼 군림하고, 사용자는 클릭과 데이터로 공짜 가치를 바치는 농노가 됐다는 것입니다.
둘째는 국가가 기업을 흡수하는 길입니다.
팔란티어의 알렉스 카프는 "실리콘밸리가 사무직 일자리를 다 빼앗으면서 군은 등한시하면, 결국 기술이 국유화될 것"이라고 경고합니다. 실제로 앤트로픽이 국방부의 요구를 일부 거부하자 '공급망 리스크'로 지정된 일이 있었습니다.
셋째는 둘 다에서 벗어나려는 '주권적 개인'의 길입니다.
컴퓨터로 시작하는 신생 국가를 주장하는 '네트워크 스테이트' 운동, 트럼프의 그린란드 인수 시도, 테크 억만장자들이 짓는 자유도시 실험이 그 줄기입니다.

이 모든 갈래 위에서, 만드는 사람들 스스로 '속도를 늦추는 장치'를 요구하기 시작했습니다.
앤트로픽 공동창업자 잭 클라크는 자신을 '기술 낙관주의자'로 규정하면서도 '적절한 공포(appropriate fear)'를 같이 가져야 한다고 말합니다.

그는 AI를 "단순하고 예측 가능한 기계가 아니라, 진짜이자 이해 불가한 생명체"라고 부릅니다.
AI는 설계도대로 '만들어진' 것이 아니라 데이터 속에서 '길러진' 존재라서, 만든 사람조차 그 속을 다 알지 못한다는 겁니다.
해법은 기술로 대중을 설득하는 게 아니라 그 불안을 경청하고 투명성 체제를 세우는 것이라고 했습니다.

AI 규제, 소프트웨어의 몰락

다리오 아모데이는 2026년 6월 에세이에서 한 발 더 나갔습니다.
3년간 앤트로픽의 공식 입장이던 '투명성'을 폐기하고 "이제는 투명성을 넘어 구속력 있는 규제로 가야 한다"고 선언한 겁니다.
항공기가 안전 시험을 통과해야 뜨듯, 일정 규모 이상의 AI 모델은 사이버·생물무기·통제 상실 같은 영역에서 의무 시험을 받고 기준 미달이면 정부가 출시를 막아야 한다는 것입니다.
그는 "AI를 마케팅 문제로 보는 시각을 완전히 거부한다. 사람들이 불안해하는 건 위험이 진짜라는 걸 정확히 알아챘기 때문"이라고 했습니다.

규제가 논의되는 사이, 시장에서는 이미 산업 지도가 통째로 다시 그려지고 있습니다. AI 팩토리가 만든 지능이 가장 먼저 집어삼키는 건 기

존 소프트웨어 산업입니다.

마이크로소프트의 나델라는 2024년 말, 기존 기업용 소프트웨어(SaaS)가 "에이전트 시대에 다 무너질 것"이라고 했습니다. 그가 든 이유는 냉정합니다.
"오늘의 비즈니스 앱은 결국 데이터베이스 위에 업무 규칙을 얹어둔 것"인데, 그 업무 규칙이 AI 에이전트 층으로 빠져나가면 앱은 껍데기만 남는다는 겁니다.

자연어로 지시하면 AI가 여러 시스템을 동시에 읽고 쓰니, 사람이 특정 앱 화면을 열 이유가 사라집니다.
실제로 2026년 2월, 월가가 이 논리를 받아들이자 소프트웨어 주식에서 단 2주 만에 약 1조 달러가 증발했습니다(고점 대비로는 2조 달러). 사람 머릿수, 곧 '좌석 수만큼 받던' 구독 모델이 흔들린 겁니다.
사람 대신 에이전트가 일하면 좌석을 셀 수가 없으니까요.

세일즈포스의 베니오프 같은 SaaS 진영은 "다 헛소리"라 반박하고, 핀테크 클라르나가 한때 세일즈포스를 끊겠다고 했다가 "AI로 갈아탄 게 아니라 다른 소프트웨어로 옮긴 것"이라 정정한 사례처럼 현실은 '대체'와 '과장' 사이 어딘가에 있습니다.
다만 분명한 건, 사람 머릿수로 값을 매기던 소프트웨어 경제가 통째로 흔들린다는 점입니다.

소프트웨어가 무너진 자리에 들어서는 건 'AI 운영체제'입니다.

AI 운영체제

오픈AI는 2025년 10월, ChatGPT 안에서 외부 앱이 직접 돌아가는 생태계를 열었습니다. ChatGPT 안에서 앱을 자연어로 부르는 방식인데, 매체들은 이를 "AI 비서 안에 들어온 앱스토어", 사실상 새 운영체제라 불렀습니다.
알트만은 "사람들이 ChatGPT를 자기 삶 전체가 담긴 운영체제처럼 쓰기 시작했다"고 했고, ChatGPT 사용자는 2026년 월 10억 명을 넘었습니다.
AI를 운영체제로 본다면 앱스토어(앱 생태계), 시스템콜(MCP), 셸(자연어), 설치 기반(10억 사용자)이 한꺼번에 갖춰지고 있는겁니다.
구글도 검색창 자체를 자연어 AI로 바꾸며 '제미나이 운영체제'를 내겁니다.
버튼을 누르는 시대에서 의도를 말하는 시대로, 인터페이스의 지층이 통째로 바뀌고 있습니다.

운영체제가 바뀌면 그것을 담을 기계도 바뀝니다.

애플은 뭐하냐

AI 팩토리가 만든 지능이 사람에게 닿는 마지막 관문, 디바이스 전쟁입니다.
오픈AI는 아이폰을 디자인한 조니 아이브의 회사를 약 64억 달러에 사들였습니다. 둘이 그리는 첫 기기는 화면이 없습니다.
주머니나 책상에 두고 늘 곁에서 주변을 보고 듣는 '동반자'인데, 알트만은 이를 영화 'Her'에 빗댑니다.
영화 속 주인공이 운영체제 '사만다'와 사랑에 빠지듯, 화면 없이 말로만 대화하는 AI를 일상에 두겠다는 겁니다.
메타는 다른 길로 안경을 밀어붙여 2025년에만 AI 안경을 700만 대 넘게 팔았고, 저커버그는 "안경이 다음 컴퓨팅 플랫폼"이라 단언합니다.

이 모든 전쟁에서 가장 충격적인 건, 지난 20년 디바이스의 왕이던 애플이 뒤처졌다는 사실입니다.

애플은 2024년 '더 똑똑한 시리'를 약속했지만 핵심 기능을 2026년으로, 다시 그 뒤로 미뤘습니다.
허위 광고 집단소송에 2억 5천만 달러로 합의했고, 2026년 6월 WWDC에서는 결국 자존심을 접고 새 시리의 두뇌로 구글 제미나이를 연 10억 달러에 빌려 쓴다고 공식 발표했습니다.
AI 책임 임원은 은퇴했고, 디자인 총괄은 메타로 떠났으며, 팀 쿡은 2026년 9월 하드웨어 출신에게 CEO 자리를 넘깁니다. 2026년 초에는 알파벳(구글)이 2019년 이후 처음으로 애플의 시가총액을 넘어섰습니다.

가장 완벽한 기계를 만들던 회사가, 그 기계 안에 들어갈 '지능'을 스스로 만들지 못해 경쟁사에서 빌리는 처지가 된 겁니다.
칩과 기기를 쥐는 것만으로는 부족하고 지능을 찍어내는 공장을 쥐어야 한다는 이 시대의 규칙을, 애플의 추락이 가장 선명하게 보여줍니다.

운영체제와 디바이스를 쥔 자가 마지막으로 노리는 건 '거래' 그 자체입니다.
검색하고 비교하고 결제하던 모든 길목을 AI가 대신 걷기 시작했습니다.

에이전트 결제 프로토콜

이걸 위해 2025년 하반기, 거대 기업들이 일제히 '에이전트 결제 프로토콜'을 깔았습니다. 구글은 AP2를, 오픈AI는 스트라이프와 함께 ACP를 내놨고, ChatGPT 안에서 대화하다 바로 물건을 사는 '인스턴트 체크아웃'이 열렸습니다.
코인베이스는 스테이블코인으로 기계끼리 결제하는 x402를 깔았고, 비자·마스터카드·페이팔도 각자 에이전트 결제망을 들고 나왔습니다.
모델을 도구에 연결하는 게 MCP였다면, 이건 그 위에 '돈'을 얹는 층입니다. AI가 스스로 사고팔 수 있게 된 겁니다.
그래서 'AI를 쥔 자가 모든 시장을 먹는다'는 말이 나옵니다.

검색이 먼저 무너집니다.

AI 요약이 뜨면 사람들이 링크를 누르는 비율이 절반으로 줍니다. 검색에서 시작하던 트래픽과 광고가 답변 엔진으로 빨려 들어가는 겁니다.
다음은 쇼핑입니다.
맥킨지는 2030년 미국에서만 1조 달러어치 거래가 AI 에이전트를 거칠 거라 봅니다. 에이전트가 모든 상점을 가로질러 최저가를 찾아 사주면, 아마존조차 'API 뒤의 한 가맹점'으로 내려앉을 수 있습니다.
실제로 2026년 3월, 아마존은 자기 사이트에서 대신 쇼핑하는 퍼플렉시티의 AI를 막아달라며 소송을 걸어 법원의 금지명령을 받아냈습니다.

알트만은 ChatGPT로 물건을 사면 2% 정도 수수료만 받고 "순위는 절대 돈으로 바꾸지 않겠다"고 합니다.
하지만 검색·비교·결제·추천이 한 손에 모이면, 광고든 수수료든 그 길목을 쥔 자가 가치사슬 전체를 거두게 됩니다.
AI 경쟁의 끝은 모든 산업을 차지하는 승자독식이고 거기엔 지킬 해자가 없습니다.

이 거대한 판에, 이번엔 국가가 직접 돈을 들고 올라탑니다.

정부가 기업 지분을 사들인다.

트럼프 행정부는 2025년 들어 정부가 기업 지분을 사들이기 시작했습니다.
인텔 지분 약 10%(89억 달러)를 가져가 최대 주주가 됐고, 희토류·원전 기업까지 1년 새 11곳에 100억 달러 넘게 들어갔습니다.
미국 국부펀드 설립을 지시했고, 약 12조 달러 규모의 퇴직연금을 사모·AI 같은 자산에 열어줬습니다.
엔비디아와 AMD가 중국에 칩을 팔면 그 매출의 15%, 더 센 칩은 25%를 정부가 통행료처럼 떼어 갑니다. 규제 권한을 지렛대로, 국가가 AI 거래의 길목에서 직접 현금을 걷는 구조입니다.

그 정점에 알트만과 트럼프가 있습니다.

알트만은 2016년 트럼프를 "미국에 대한 전례 없는 위협"이라 불렀던 사람입니다.
그런데 2025년 1월, 트럼프 취임 다음 날 백악관에서 5,000억 달러짜리 스타게이트를 나란히 발표하며 대통령을 치켜세웠고, 취임식에는 개인 돈 100만 달러를 냈습니다.
2026년 6월에는 트럼프가 "오픈AI·앤트로픽·xAI 같은 큰 기업들의 지분 일부를 미국 국민이 갖는 구상"을 공개적으로 꺼냈습니다.
알트만이 먼저 제안한 '공공부펀드' 아이디어입니다. AI 기업이 지분을 정부에 기부하면 그것을 종잣돈 삼아 전 국민에게 배당한다는 겁니다.

흥미로운 건 트럼프와 버니 샌더스, 알트만이 서로 정반대 진영인데도 'AI의 공적 소유'라는 한 지점에서 만난다는 점입니다.
풍요라는 명분 뒤에는 더 음습한 구조가 있습니다. 규제하는 정부가 동시에 그 기업의 주주가 되면, 국가와 AI 공장은 한 몸이 됩니다. 누가 누구를 견제하느냐는 질문 자체가 사라지는 겁니다.

AI가 거래의 길목을 쥐고 그 위에 국가까지 주주로 올라탄 세상은, 기업·국가·개인 어느 길로 가든 결국 통제 사회라는 같은 종착지로 모입니다.
하버드의 쇼샤나 주보프는 이것을 '감시 자본주의'라 부르며, 그 권력의 본질을 "인간의 행동을 알아내 타인의 목적에 맞게 빚어내는 힘"이라고 정의했습니다.

역사가 유발 하라리는 알고리즘이 나 자신보다 나를 더 잘 알게 되는 순간, 가장 중요한 결정마저 알고리즘에 넘기게 된다고 경고합니다.
추상적인 이야기가 아닙니다. 팔란티어의 시스템은 이미 여러 정부 데이터베이스를 엮어 사람을 거의 실시간으로 추적하고 있습니다.

당신이 진짜 사람이라는 것을 증명하기

지능이 흔해질수록 오히려 비싸지는 게 하나 있습니다. '진짜 사람'이라는 증명입니다. 샘 알트만이 오픈AI와 별개로 세운 회사 '월드'가 이 문제를 정면으로 겨냥합니다.
월드는 Orb라는 구체형 장치로 홍채를 스캔해 1만 2,800자리 코드로 바꾸고, 그 사람이 봇이 아닌 인간임을 증명하는 '월드 ID'를 발급합니다.

알트만의 설명은 분명합니다. "AGI 시대에 인간을 식별하고 인증할 방법이 필요했다. 인간이 계속 특별하고 중심적인 존재로 남도록." 2025년 미국에도 출시됐고, 전 세계에서 1,800만 명 넘게 홍채를 등록했다고 회사는 말합니다.
2026년에는 틴더·줌과 손잡고 딥페이크 시대의 본인 확인 수단으로 쓰이기 시작했습니다.
같은 사람이 한쪽에서 지능을 전기처럼 흔하게 만들면서, 다른 쪽에서 그 시대에 인간임을 증명하는 관문을 짓고 있는 셈입니다.
비판도 거셉니다. 스페인·홍콩·브라질·태국이 과도한 생체정보 수집을 이유로 운영을 막거나 데이터 삭제를 명령했고, 에드워드 스노든은 이를 "안구를 목록으로 만든다"고 했습니다.

취재로 드러난 더 불편한 사실은, 사용자가 삭제를 요청해도 서버에 흩어진 파생 코드는 남는다는 점입니다.

이 그림은 영화 한 편을 떠올리게 합니다. 스티븐 스필버그의 '마이너리티 리포트'입니다.
그 세계에서 사람들은 거리를 지날 때마다 홍채를 스캔당하고 이름이 불린 맞춤형 광고에 둘러싸이며, 경찰은 범죄를 저지르기 전에 사람을 체포합니다.

홍채 기반 신원 추적과 예측 감시는 이미 현실에 들어와 있습니다. 시카고 경찰은 범죄 가능성을 점수화한 명단을 운영하다 흑인 남성의 절반 이상이 포함되는 편향 끝에 2019년 폐기했고, 로스앤젤레스의 예측 치안 프로그램도 2020년 중단됐습니다.
데이터로 사람을 미리 판단하는 시스템은 영화처럼 정확하지 않았고, 대신 편향을 되풀이했습니다.

통제는 개인의 신원에서 멈추지 않고 AI 모델 그 자체로 옮겨가고 있습니다.

AI 모델의 통제

2026년 앤트로픽의 '미토스(Mythos)'가 그 장면을 보여줬습니다.

미토스 사건이 보여준 더 깊은 변화는, AI 모델이 이제 석유나 우라늄 같은 국가 전략자산이 됐다는 겁니다.
미토스는 앤트로픽의 최상위 모델인데, 모든 운영체제와 브라우저의 보안 허점을 찾아내는 능력이 사실상 사이버 무기급이라 처음에는 정부와 협력해 방어자에게만 제한적으로 공개됐습니다.

2026년 6월 앤트로픽은 안전장치를 건 일반용 '페이블 5'와 그 장치를 일부 푼 방어자용 '미토스 5'를 함께 내놨습니다.
같은 모델을 안전장치 유무로 둘로 가른, 전형적인 이중용도(dual-use) 기술입니다.

앞서 2025년에는 화학·생물·핵무기 제작을 도울 위험을 더는 배제할 수 없다며 최고 등급 안전장치를 발동한 적도 있습니다. 모델이 곧 무기가 될 수 있다는 걸 만든 회사가 먼저 인정한 셈입니다.

그래서 국가가 통제하는 대상이 바뀌었습니다.

미국은 첨단 칩을 농축우라늄 다루듯 수출통제해 왔는데, 2025년부터는 일정 규모(10의 26제곱 연산) 이상으로 훈련한 'AI 모델의 가중치' 자체를 수출 허가 대상에 올렸습니다.
가중치는 한번 새어 나가면 그대로 복제되는 핵물질 같은 것이라, 데이터센터의 보안이 그대로 국가 안보가 됩니다.
미토스 차단은 이 전략자산화가 실제로 작동한 첫 장면입니다. 출시 나흘 만에 정부가 국가안보를 이유로 외국인 접근을 전면 차단했고, 앤트로픽은 자사 외국인 직원까지 막힌 채 모델을 통째로 비활성화해야 했습니다.
회사는 "좁은 우회 기법 하나 때문에 수억 명이 쓰는 상용 모델을 회수하라는 건 부당하다"고 반발했지만, 통제의 대상이 칩이라는 '물건'에서 지능 그 자체로 넘어왔다는 사실은 달라지지 않습니다.

그래서 이 모든 게 유토피아로 가느냐 디스토피아로 가느냐.
같은 미래를 보면서 정반대 이름을 붙이는 이 싸움이 어쩌면 기술 자체보다 더 치열합니다.

낙관 쪽은 풍요를 봅니다.
오픈AI에 처음 투자한 비노드 코슬라는 "2030년대가 되면 1차 진료의부터 종양내과의, 회계사까지 거의 모든 전문성이 사실상 무료가 된다"고 말합니다.

회의 쪽은 그늘을 봅니다.
'빅쇼트'로 유명한 마이클 버리는 2025년 말, 빅테크들이 칩의 실제 수명보다 길게 잡아 감가상각을 줄이는 방식으로 이익을 부풀린다고 의혹을 제기했습니다.
벤처투자자 차마스 팔리하피티야는 발표된 인프라 중 "실제로 지어지는 건 절반도 안 되고 대부분 규제에 묶여 있다"고 했습니다.
그 사이에서 세계 최대 자산운용사 블랙록의 래리 핑크는 "거품이 아니라 오히려 우리가 충분히 투자하고 있는지를 물어야 한다"며 평범한 연금 가입자도 이 성장에 동참해야 한다고 주장합니다.

이 분열은 SF가 일찍이 펼쳐 보인 갈래이기도 합니다.
테그마크는 '라이프 3.0'에서 AGI 이후의 미래를 자유지상주의 유토피아부터 자애로운 독재, 조지 오웰의 1984식 감시국가, 인류의 자멸까지 열두 가지 시나리오로 나눴습니다. 같은 공장이 어느 쪽으로든 갈 수 있고, 방향을 정하는 건 기술이 아니라 그것을 누가 어떻게 소유하느냐라는 것입니다.
가속을 신념으로 내건 마크 앤드리슨은 '테크노 낙관주의 선언'에서 "지속가능성, 기술 윤리, 안전" 같은 개념을 적으로 지목했고, 반대편에서는 데이터센터 반대가 번지고 있습니다.

2026년 초 갤럽 조사에서 미국인의 68%가 자기 동네에 AI 데이터센터가 들어서는 데 반대했습니다.
흔히 러다이트를 기계를 부순 무지한 폭도로 떠올리지만, '블러드 인 더 머신'의 저자 브라이언 머천트는 "러다이트는 기계가 아니라 기계의 소유주를 겨눴다"고 바로잡습니다.
유토피아든 디스토피아든, 이 논쟁에는 지구라는 무대가 전제돼 있습니다.

우주로 가즈아

일론 머스크는 그 무대 자체를 우주로 넓히려 합니다.

그의 논리는 단순합니다. 지구에서는 전력이 부족하지만 우주는 늘 햇빛이 든다는 것입니다.
머스크는 2026년 "우주에 AI를 두는 비용이 지상보다 싸지는 시점이 2~3년밖에 안 남았을 수 있다"고 했고, 스페이스X는 고성능 AI 칩을 실은 위성을 공개하며 최대 100만 기를 띄우겠다고 미국 통신당국에 신청했습니다.
앞서 본 우주 데이터센터 구상이 한 사람의 큰 그림 안에서 구체적인 사업이 된 셈입니다.

머스크가 이걸 하는 이유는 그가 오래 말해온 한 문장으로 모입니다. "의식의 빛을 별들에게로 확장한다." 2026년 5월 스페이스X가 상장을 위해 제출한 공식 서류에는 이 표현과 함께 '카르다셰프 2단계'라는 말이 적혔습니다.

카르다셰프 척도

카르다셰프 척도는 문명을 에너지 사용량으로 나눈 단계입니다.
1단계는 행성의 에너지를 전부 쓰는 문명, 2단계는 항성 하나의 에너지를 통째로 거두는 문명입니다. 인류는 아직 1단계에도 못 미친 0.7 수준입니다.

머스크는 "태양광 AI 위성이야말로 카르다셰프 2단계 문명에 이르는 유일한 길"이라고 했습니다.
여기서 앞서 본 흐름이 한 줄로 꿰입니다. AI가 지능을 원하고, 지능이 컴퓨트를 원하고, 컴퓨트가 전력을 원하고, 전력이 끝내 태양 전체를 원하게 된다는 것입니다.
데이터센터에서 시작한 이야기가 문명의 에너지 단계까지 올라갑니다. 다만 스페이스X 스스로도 이 계획이 "아직 존재하지 않는 기술"에 기대고 있다고 같은 서류에 적었습니다.
이 모든 갈래가 결국 하나의 질문으로 모입니다.

다리오 아모데이는 2026년 1월 에세이의 제목을 '기술의 사춘기'라고 붙였습니다.

칼 세이건의 소설 '콘택트'에서 인류가 외계 문명에게 던지고 싶어 하는 질문을 빌려서요. "당신들은 어떻게 자멸하지 않고 이 기술적 사춘기를 통과했습니까?" 세계 최고의 AI 기업을 이끄는 사람이 인류의 지금 단계를 설명할 현실의 언어를 찾지 못해 소설을 빌린 것입니다.
오픈AI를 떠난 연구자 다니엘 코코타일로는 같은 위험을 숫자로 바꿔놓았습니다.

"한두 개에서 다섯 개 기업이 각자 가장 똑똑한 AI를 100만 개씩 돌리면, 사실상 열 개 남짓한 지능이 세상의 거의 모든 것을 결정하게 된다. 그런데 그 지능들이 무엇을 원하게 될지는 누가 정하는가. 지금은 아무도 정하지 못한다. 우리는 아직 AI를 우리 뜻에 맞추는 법을 모르기 때문이다." 그 예언서가 말한 '인지 엘리트'가, 이제 사람조차 아닌 열 개의 지능으로 좁혀진 그림입니다.
그렇다면 우리는 무엇을 봐야 할까요.

우리는 어떡하지

이 거대한 흐름 앞에서 개인이 할 수 있는 일은 몇 개의 신호를 비판적으로 지켜보는 것입니다.
첫째, "풍요"라는 말이 나올 때마다 그 뒤에 "누구의 풍요인가"를 붙여 물어야 합니다. 지능이 전기처럼 싸진다는 약속과, 그 전기를 공급하는 파이프를 소수가 쥔다는 사실은 같이 일어나고 있습니다. 빌 게이츠의 "무료 의사"와 제프리 힌턴의 "다수의 빈곤"은 같은 곡선의 위아래입니다.
둘째, "거품이 아니다"라는 말은 그 말을 하는 사람이 거품의 당사자일 때 가장 조심해서 들어야 합니다. 대신 봐야 할 것은 약속한 지출과 실제 매출의 간격, 그리고 그 돈이 자기들끼리 도는지 밖에서 들어오는지입니다.
셋째, 역사의 교훈은 양쪽 다입니다. 철도와 광케이블은 거품이 터진 뒤에도 인프라로 남아 다음 시대를 열었지만, 그 거품에 올라탄 개인 투자자 다수는 회복하지 못했습니다. 인프라가 남는다는 말과 내 돈이 남는다는 말은 다릅니다.

지켜볼 흐름도 분명합니다.

전력과 원자력, 핵융합이 어디까지 가는지, 추론으로의 전환이 스케일링의 한계를 실제로 넘는지, 커스텀 칩이 엔비디아의 독점을 깨는지, 그리고 미국과 중국의 수출통제가 단극과 양극 중 어느 쪽으로 기우는지.
지켜볼 발언도 있습니다.
풍요를 약속하던 사람이 부유세를 꺼낼 때(아모데이), 투명성을 고수하던 사람이 정부의 규제 권한을 요구할 때(아모데이의 입장 전환), 거품을 부정하던 사람이 "누군가는 크게 잃을 것"이라고 인정할 때(알트만) 그런 순간들이 진짜 신호입니다.
한 가지 균형도 덧붙여야 합니다.

누군가는 이것을 산업혁명과 정보혁명과 르네상스가 한꺼번에 겹쳐 오는 규모의 전환이라고 부릅니다.
멈춰 있던 성장에 다시 불을 붙일 거의 유일한 후보가 AI라는 것도, 사람이 줄어드는 저출산·고령화 사회에서 이 기술이 위협이자 동시에 활로라는 것도 사실입니다. 과도기의 마찰과 충돌은 그만한 전환에 따르는 비용일지 모릅니다.

그러니 가속을 받아들이는 것과, 그 가속이 누구를 위한 것인지 묻는 것은 서로 모순이 아닙니다. 둘을 동시에 쥐어야 방향을 잃지 않습니다.
처음으로 돌아가 봅니다. 최근 보는 뉴스들이 한 방향을 향한다는 느낌이 점점 강해지고 있습니다. 그 흩어진 조각들은 자기를 만드는 하나의 공장으로 모이고, 그 공장은 전력과 핵융합과 우주와 로봇을 끌어당기며, 그 위에서 미국과 중국이 다투고, 그 곁에서 오래전 설계도를 든 사람들이 탈출에서 통치로 자리를 옮겼습니다.

AI 발 이젠 진짜 멈출 수 없음

분명한 건 이 공장이 멈추지 않는다는 것입니다.
그래서 진짜 질문은 '지능이 얼마나 더 싸지고 똑똑해지는가'가 아니라, '그 공장을 누가 소유하고, 거기서 나온 지능을 누가 빌려 쓰며, 누가 그 문 앞에서 배제되는가'입니다.
100년 전 제철소가 철을 찍어내던 시대에 부와 권력이 철강을 쥔 소수에게 모였듯, 지능을 찍어내는 시대의 부와 권력도 그 공장을 쥔 손으로 모입니다.

다른 점이 있다면, 철은 다리와 건물이 됐지만 지능은 판단과 결정 그 자체가 된다는 것입니다.
그래서 이 공장을 누가 쥐느냐는 앞으로 누가 무엇을 결정하게 되는가의 문제입니다. 다행인지 불행인지, 그 손이 누구의 것이 될지는 아직 정해지지 않았습니다. 적어도 지금은, 지켜보고 묻는 사람들의 몫으로 남아 있습니다.

원본: https://www.threads.com/@choi.openai/post/DZlrZlzD86B?xmt=AQG08H5q3DVnniWMbFd2Ps-Q1cHSVbxtKCcS3BAovNQssg

[6월 2-3주차] 수익 51만 4천원 | 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 환전, QQQI, JPEQ, 월1% 배당

snowman95 — Fri, 19 Jun 2026 16:22:50 +0900

[투자 전략] 응~ 배당 받으면 그만이야~ 유휴 RP이자 대신 고배당 커버드콜 발라먹기 (QQQI, JEPQ)

[투자 전략] "응~ 배당 받으면 그만이야" 하이브리드 투자 기법AI발 대세 상승장을 못타신 분들...FOMO 느끼고 지금이라도 풀매수 들어가는 순간 세상이 나를 지켜보고 있는 것이었는지!!! 다음날

11001.tistory.com

응~ 배당 받으면 그만이야~ 6월 2-3주차 결과 입니다.

환전 결과

원금: 약 1900만원

원화 -> 달러(환율 1517원)
달러 -> 원화(환율 1538원)

총 수익: 약 +26만원

배당금

원금: 약 2000만원

배당금: 20만원 (QQQI)

시세차익: 5.4만원

총 수익 +25.4만원

아직 안 끝났습니다.

4주차에 환율 1500 초반대에 예약 환전 걸어두었고,

환전 완료되면 JEPQ 매수 대기중입니다. (배당 갈아타기)

5-6월에 반도체 주식에 불나방처럼 뛰어들어서 트럼프 한마디에 오락가락하고 노조 때문에 고점에 쳐물리고 탈출하기를 반복하면서 진짜 괴롭고 힘들게 160만원 벌었는데

응~ 배당 받으면 그만이야~ 전략으로 리스크 하나도 안지고 스트레스 1도 없이 51만 4천원의 수익을 얻었습니다.

이 돈은 심지어 배당세 15.4%를 이미 냈고 추가로 낼 세금도 없습니다. 온전히 "현금"으로 가지고 있는 내 돈입니다.

예약 환전을 기다리고 있는 지금 이 순간에도 RP 수익률 2%를 받고 있습니다.

* 참고로 Super365 계좌라서 수수료가 없는 것입니다.

물론 이런 의문이 들 수가 있습니다.

아니 왜 굳이 이렇게 개고생을 하느냐? QQQ, QLD 진득하게 묻어두면 그만인거 아님?

-> 안됩니다.. 애초에 이 돈은 원금 손실을 절대 안하겠다고 가정하고 접근한 특수한 돈입니다. 이유는 묻지마시오...

삼전닉스 샌디스크 SOXL 넣으면 하루에 10%, 15% 씩 먹는데 ㅋㅋ 왜 안함?
-> 고점 쳐물려서 하루에 -10%씩 맞아보면 정신차려집니다. 불나방처럼 단타쳐서 크게 벌어도, 어차피 할 줄아는게 운에 맡겨서 또 단타치는것이기 때문에 1억 벌어도 10억 벌어도 또 똑같이 단타짓 하다가 돈 다 잃을때 까지 하게 됩니다. 제가 과거에 그렇게 경험 해봤거든요.

그러면, 저점에 들어갔으니 푸근하게 버티면 그만이야~ 하면 그만 아님?
-> 일단 저점에 못들어갔기에 논외이고, 2022년에 분명히 삼전 저점에 들어갔는데 10만전자일때 못팔고 4만전자 찍었던거 생각안남? 당신이 과연 고점에 잘 팔고 나올 수 있을까? 일찍 팔면 또 다시 고점에 들어가서 물리지 않을까?

이 전략의 이상적인 기대 수익률입니다.

① JEPQ ⇄ QQQI 징검다리 배당연 12.0% ~ 15.0%

② 대세 상승장 시세차익연 5.0% ~ 8.0%

③ 환율 박스권 플레이 (보너스)연 1.0% ~ 2.0%

④ QLD 배당 재투자 엔진 (핵심)연 3.0% ~ 5.0% (알파)

어찌보면 저 같은 완벽주의자를 위한 전략인거죠.

폭락장 오면 -> 응~배당 받으면서 버팀

배당락 이후에 회복 안되어서 갈아타기 못하면 -> 응~ 배당 받으면서 버팀

상승장 오면 -> 응~ 시세차익 소소하게 먹으면서 갈아타기로 발라먹기하면 월 2% 계속 수익 먹음

무료로 생성되는 배당금은 QLD(나스닥 2배 레버리지)에 무지성 투자하면서 장투하면 그만이고~

환율 너무 높으면 -> 기회가 된다면 원화 환전하셈 ㅋㅋ 1550원 이럴때 정부에서 무조건 개입함 ㅋㅋ 환율 조작국임

환율 낮아지면 -> 응~ 외국인들 투자금 회수하면 무조건 환율 오를 수 밖에 없음

최종 합산 연 평균 기대 수익률 (Total Return)

"진짜 난 아무것도 안하고 QQQI 만 넣을래": 원금의 연 10.0% "확정 보장"
"두 달에 한 번씩 배당 갈아타기 성공함" (찍먹 모드): 연 12.0% ~ 14.0%
"매달 배당 갈아타기 성공함" (신의 손 모드): 연 15.0% ~ 18.0%
"시세차익 및 환차익까지 성공함" (야수 탈을 쓴 신 모드): 예상 수익률: 연 20.0% ~ 25.0%+

현재의 변수

1) 환율 너무 높음 1540원 찍었음. 만약에 목표 환율 까지 도달하지 않는다면 그냥 1520원 쯤 환전 생각중..

2) 주가 너무 높음 26년 6월 18일날 미장이 대폭등하면서 JEPQ 가 최고가를 찍어버림. 부담이 있는 자리

[투자 전략] 응~ 배당 받으면 그만이야~ 유휴 RP이자 대신 고배당 커버드콜 발라먹기 (QQQI, JEPQ)

11001.tistory.com

[주식 투자] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 유휴 RP이자 대신 고배당 커버드콜 발라먹기 (QQQI, JEPQ, QLD)

snowman95 — Fri, 19 Jun 2026 15:36:23 +0900

[주식 투자] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략

AI발 대세 상승장을 못타신 분들...
FOMO 느끼고 지금이라도 풀매수 들어가는 순간 세상이 나를 지켜보고 있는 것이었는지!!! 다음날 부터 갑자기 폭락 하죠? 저도 많이 당했습니다.
왜 하필 지금이지? 일주일 이주일 넘게 오르다가 왜 내가 사는 순간!!!!

대세 상승장 속에서 증권사 RP 이자(연 2%)에 잠자고 있는 유휴 자금을 깨워 극강의 효율로 굴리는 전략입니다. 배당, 환차익, 그리고 대폭락장 속 역발상 레버리지 기회까지 모조리 발라먹는 '야수의 심장'을 위한 하이브리드 투자법을 소개합니다.

1. 전략 소개: "그만이야" 전략이란?

이 전략의 핵심 정신은 "안 되면 묻어두면 그만이야"라는 강력한 멘탈 방패입니다. 잦은 매매로 인한 손절 리스크를 고배당(연 10~14%)으로 커버하며 버티다가, 기회가 오면 환차익과 레버리지 폭발력을 더해 자산을 퀀텀 점프시키는 하이브리드 기법입니다.

2. 구체적인 투자 방법 (Step-by-Step)

① 평시 운용: 고배당 파이프라인 구축 (JEPQ, QQQI)

이 전략은 시드를 쪼개지 않습니다. 유휴 자금 100%를 통째로 움직여 효율을 극대화합니다.
JEPQ와 QQQI의 배당락일이 매달 서로 다른 주차에 위치한다는 점을 노린 '엇박자 올인' 기법입니다.

월말 ~ 월초: 시드 100%로 JEPQ 진입 ➡️ 1일 배당락 먹기 ➡️ 강세장 버프로 주가 회복 시 전량 매도 (현금화).
월 중순: 확보한 현금 100%로 QQQI 진입 ➡️ 2~3주차 배당락 먹기 ➡️ 주가 회복 시 전량 매도 (현금화).

무한 반복 및 플랜 B: 만약 배당락 이후 주가 회복이 더디다면? 억지로 손절하며 갈아타지 않고,
그 종목에 100% 그대로 묻어둔 채 고배당을 수령하며 존버합니다. "안 되면 그냥 묻어두면 그만이야~"전략이 여기서 발휘됩니다.

② 조건부 보너스: 환율 박스권 플레이

환율이 1,500원 초반대로 내려올 때만 진입 기회로 삼아 원화를 달러(또는 달러 자산)로 환전합니다.
주식을 굴리다가 환율이 1,500원 후반대로 치솟는 타이밍이 오면 달러 자산을 원화로 바꾸어 추가 환차익을 확보합니다. (조건이 안 맞으면? 그냥 달러로 배당 받으며 대기하면 그만!)

③ 영혼의 한 타: 대폭락장 레버리지 매직 (VIX 지수 활용)

시장에 대폭락장이 찾아와 주가가 박살 나도 매달 나오는 고배당을 받으며 좀비처럼 버팁니다.
그러다 시장의 공포지수인 VIX 지수가 30을 돌파한 후 꺾이는 '진짜 바닥' 신호가 포착되면, 들고 있던 커버드콜을 과감히 매도하고 죽기 직전까지 처박힌 3배 레버리지(TQQQ 등)로 갈아탑니다.
반등장 리바운딩을 강하게 먹고 나온 뒤, 다시 평시 배당 운용 상태로 복귀합니다.

3. 투자 리스크 및 주의사항

커버드콜의 상방 제한: 대세 상승장에서 나스닥 지수가 폭등할 때, JEPQ나 QQQI 같은 커버드콜은 옵션 구조상 지수 상승분을 온전히 다 먹지 못하고 상승세가 제한됩니다. (※ 반론: 어차피 RP에 묵힐 돈이었으니 RP 이자보다만 높으면 상관없음!)
3배 레버리지의 음의 복리: 대폭락장에서 '하락장 끝물'을 잘못 짚어 너무 일찍 3배 레버리지로 갈아타면, 지수가 횡보만 해도 계좌가 스스로 녹아내리는 변동성 뚝배기를 맞을 수 있습니다. 철저히 객관적 지표(VIX 등)를 보고 진입해야 합니다.
거래 비용과 세금: 미국 직투 시 매달 잦은 이동을 하면 해외주식 양도소득세(22%) 및 환전/매매 수수료로 배보다 배꼽이 더 커질 수 있으므로, 수수료 우대 계좌나 국내 ISA 계좌를 징검다리로 쓰는 센스가 필요합니다.

4. 기대 수익률 분석

구분	일반 안전 자산 (RP)	"그만이야" 하이브리드 전략
평시 기대 수익	연 2.0% 고정 이자	연 10% ~ 14% 배당 수익 + 알파 (주가 상승분)
환율 우호 국면	없음	약 3~5% 수준의 추가 환차익 (박스권 매매 성공 시)
대폭락장 이벤트	원금 보존 (기회비용 상실)	3배 레버리지 전환 시 수십~수백% 단위의 계좌 퀀텀 점프 가능

한 줄 요약: 최악의 경우(물렸을 때)에도 최소 연 10% 이상의 고배당 현금흐름이 보장되므로, 3%대 RP 자금 운용 대비 압도적인 기회 가치를 가집니다.

5. 신의 한 수: 배당금은 'QLD(나스닥 2배)'로 무지성 재투자

이 전략의 화룡점정은 배당금 처리 방법입니다. 현금으로 놔두거나 흐지부지 쓰지 않고, 매달 나오는 배당금 전액으로 나스닥 2배 레버리지 ETF인 QLD를 기계적으로 매수합니다.

상승장 시너지: 커버드콜(JEPQ/QQQI)의 아쉬운 상방 제한을 QLD의 2배 폭발력으로 완벽하게 보완합니다.
하락장 안전장치: 주가가 폭락해도 내 생돈이 아닌 '배당금'으로 싼값에 QLD를 줍는 것이기 때문에, 하락장 스트레스 없이 평단가를 극단적으로 낮출 수 있습니다.
결론: 메인 시드는 고배당 엔진으로 쓰고, 새끼 계좌는 QLD라는 스노우볼을 굴려 자산 증식 속도를 3배속으로 끌어올립니다.

"그만이야" 전략의 QLD 배당 재투자 메커니즘

매달 시드 100%를 JEPQ와 QQQI로 굴리면서 나오는 배당금을 내 주머니로 빼서 쓰는 게 아니라, 별도의 '새끼 계좌'를 파서 QLD를 무한 매집하는 겁니다.

[ 메인 시드 (100%) ] ──> JEPQ / QQQI 징검다리 매매
                               │
                       (매달 배당금 발생)
                               │
                               ▼
[ 새끼 계좌 (보너스) ] ──> QLD (나스닥 2배) 무지성 무한 매수

1. 평시 (대세 상승장): 자산 양방향 폭발

메인 시드는 JEPQ와 QQQI를 오가며 현금(배당)을 계속 찍어내고, 그 돈이 QLD로 들어갑니다.
대세 상승장이라 커버드콜 주가는 상방이 막혀 완만하게 오르겠지만, 배당금으로 산 QLD는 2배 속도로 폭등합니다.
결과적으로 "커버드콜의 상방 제한"이라는 단점을 QLD가 완벽하게 메워주면서 계좌 총액이 무섭게 늘어납니다.

2. 폭락장 시나리오: 오히려 좋아, QLD 바겐세일

폭락장이 오면 메인 시드(JEPQ/QQQI)는 팔지 않고 묶어둔 채 배당만 받습니다. "안 되면 그만이야" 정신 발동이죠.
이때 나오는 배당금으로 반토막 난 QLD를 밑바닥에서 '물타기(평단가 낮추기)' 합니다. 내 생돈 들어가는 게 아니라 배당금(공짜 돈)으로 사는 거라 심리적으로 전혀 타격이 없고 오히려 싱글벙글 매수하게 됩니다.
그러다가 앞서 말한 진짜 하락장 끝물(VIX 30 돌파 후 꺾일 때)이 오면, 모아둔 QLD는 냅두고 메인 시드만 TQQQ(3배)로 갈아타서 영혼의 한 타를 치면 됩니다.

"남들이 세금 무섭다, 배당락 무섭다, 폭락장 무섭다며 RP 이자 짤짤이 챙길 때, 야수의 심장으로 판을 짜서 버티는 자가 결국 상단을 깨부숩니다. 안 되면? 응~ 배당 받으면서 3배 레버리지 타이밍 노리면 그만이야~"

이 전략 어떠십니까?

앞으로 매달 진행 결과를 올려볼 생각입니다.

AI 혁명이 일어났다. 5년차 FE 개발자인 나는 Claude Code Max20 을 구독하고 별의 별 짓을 다 해봤다.

snowman95 — Fri, 19 Jun 2026 00:51:54 +0900

AI 혁명이 일어났다.

미국 빅테크 기업들이 초거대 AI 데이터센터 건설에 상상을 초월하는 투자를 쏟아붓는다.

그 많은 돈은 모두 CPU, GPU, RAM, Disk, Network, Cable 등을 만드는 반도체 제조업 회사에 흘러 들어간다.

불과 1-2년 전 20만원 하던 하이닉스, 5만원 하던 삼성전자. 오늘은 하이닉스가 270만원, 삼성전자가 36만원이 되었다.

없는 내용을 지어내서 대답을 하거나, 잘못된 정보로 나를 화가나게 했던 그 멍청한 LLM 가 불과 1-2년 전이었다.
이제는 네이버, 구글 검색창 보다 Gemini, ChatGPT 에게 먼저 물어보게 되고, 코딩은 AI Agent 에게 맡겨 버린다.

유튜브, SNS에는 AI로 만든 글, 이미지, 영상, 노래가 돌아다니고 있고, 앱스토어에는 AI로 만든 앱들로 도배되고 있다.

아침에 눈을 뜨면 또 새로운 것들이 쏟아져 나오고 있고,

충격적으로 놀라웠던 LLM 은 1-2달만 지나면 새로운 LLM 에 비해 충격적으로 구닥다리가 되어있다.

"이런 흐름에서 5년차 FE 개발자인 나는 도대체 어떻게 살아야할까?"

AI 덕분에 "와 진짜 개발자는 개노답 인생"이 되었다. 이런 생각이 들다가도 아니 "이건 개발자에게 오히려 기회야" 란 생각도 들면서 하루에도 수 십번을 오락가락했다.

이렇게 죽을 수는 없다!!!!

2026년 1월인가 2월에 딱 1달만 사용해보자고 아주 큰 마음을 먹고, 1달에 36만원 정도 하는 Claude Code MAX x20 구독제를 끊었다

한 달 동안 죽었다고 생각하고 거의 모든 사용량을 풀로 채우는 것을 목표로 살아왔다.

(누구나 쳐맞기 전 까지는 그럴 듯한 계획은 있다)

진짜 하루 하루 돈이 너무 아까워서 밤을 새워가며 24시간 1분 1초를 허투로 살지 않고 AI 와 사랑을 나누었다.

외주를 하고, 웹사이트를 만들고, 앱을 만들고, 노래를 만들고, 영상을 만들었다.
모든 결과물이 되게 그럴싸하게 겉모습은 잘 만들었지만 내부적으로는 전혀 동작하지 않았다.

물론 작업 전에 Plan 이라는걸 세우고 시작했으나 막상 만들다 보면 절대 Plan 대로 잘 흘러가지 않았다.

너무 거대하고, 세세한 부분 까지는 계획을 세울 수 없으니 다 LLM 마음대로 만들어버린 것이다.
그러면서 당연히 누락된 것도 생기고 안했는데 했다고 거짓말하거나 다른 부분을 수정하면서 영향을 받은 것 등..

스파게티 코드가 되는건 순식간이었다.

내가 AI 에게 넘겼던 핸들을 잡고 딥하게 코드를 지적하며 이렇게 해달라 저렇게 해달라 일일이 다 요구를 하면서 고쳐야만 잘 동작했다.

그렇게 처음 만든 작품이 두쫀쿠 월드다.

두쫀쿠 월드

두쫀쿠 월드 | Dubai Chocolate World Map

전 세계의 두바이 초콜릿 맛집을 탐험하세요.

dessert-map.vercel.app

(더 이상 유지보수를 하고 있지는 않다)

인앱토스의 두쫀쿠 맵이 구려서 내가 더 잘 만들겠다.. 라는 생각으로 카피 했던 것인데 생각 보다 너무 잘 됐다.
이용자 수가 가장 많을 때 1000명도 찍었었다. 근데 광고를 못 달아서 잘 된 것 치고는 수익은 단 1원도 못냈다.
이건 인앱토스에서 초기에 너무 까다롭고 느린 심사 때문이다...

고작 버전 하나 올리는데 2-3주 정도 걸렸기에 너무 화가나서 인앱토스를 때려치웠다.
지금은 인앱토스 팀에서도 AI 자동 심사 방식으로 바뀐 것인지 심사 속도가 1-2일안에 끝난다. 엄청 빠르다.

진작에 이렇게 했으면 참 좋았을 것인데 안타깝다.

게임 공장

그 다음에는 게임 공장을 만들었다.

솔직히 앱 중에 게임이 젤 쉬운 접근이라서 게임을 공장 처럼 수 십개 씩 무한으로 찍어내서 올리려고 했다.
그런데 게임은 등급심사를 받아야 올릴 수 있다고 한다.

구글 스토어, 앱스토어 등에 올리면 자동 심사된다고 하는데 이 스토어에 올리는 게 훨씬 어렵다... 배보다 배꼽이 큰 상황

구글 스토어에는 옛날에 만들어둔 개발자 계정이 오랫동안 사용하지 않아서 죽었다.

새로 만들면 앱 테스트 사용자를 모집해서 테스트 받고 올려야 한다고 한다.

앱스토어는 매년 100달러를 지불해야한다고 한다. 지금의 나는 도저히 앱스토어 심사 스트레스를 이겨내면서 손익분기점을 넘길 자신이 없다. AI 구독료도 내야하기 때문.. ㅋㅋㅋ

대중적인 공장형 앱

결국 게임은 포기하고 사주, 로또 등 매우 대중적인 주제의 앱으로 접근했는데 꽤 광고 수입이 짭짤했다.
한 달에 3-4만원씩 찍혔다. 기분이 좋았으나 AI 구독료에 비하면 한참 모자르다. 지금은 이런 앱들이 수 십개가 쏟아져 나오면서 망했다.
AI 가 너무 쉽게 카피할 수 있다보니 무슨 앱을 올려도 순식간에 레드오션이 되어버린다.

솔직히 이런 대중적인 앱에 특허나 저작권 이란게 있는것도 아니지 않는가?

그래도 이런 것들을 수 백개를 찍어내는 짤짤이 돈이 모여서 꽤 수익이 크지 않을까 라는 생각을 했었는데

실제로 프로그래밍 좀비라는 사람이 그렇게 해서 월급 이상으로 버신다고 한다.

이 사람 강의까지 냈다.

강의 사서 들었는데 쌩 고생한 경험을 돈 주고 사는 느낌이다.

와 진짜 이 정도로 해야 버는구나 싶은 생각이 들었다. 절실한 가장의 무게가 느껴진다.

나도 이제는 AI 로 딸깍딸깍 하면서 만들어놓은 앱이 매 달 3-4만원 씩은 벌어다주고 있긴하다. 유지보수가 전혀 없는 상태인데도..

근데 해보니까 생각보다 앱 하나 만드는데에 많은 시간이 들어간다는 것이다.

절대로 AI가 처음 부터 끝까지 알잘딱깔센으로 해주지 못한다. 사람이 중간 중간 보면서 핸들링하고 결정을 내려줘야만 한다.

앱 스크린샷 찍어서 그대로 갖다 붙여넣기만 해도 완벽히 다 만들어준다면 이미 개발자란 직업은 없어졌다.

좀비씨가 앱을 카피하더라도 이건 내가 꽤 많은 시간을 들일거 같으면 다른걸 찾아야 한다고 했는데 일단 나는 그러지 못했던 것 같다.

잠깐 인앱토스 비판

일단 망할 놈의 인앱토스 부터 벗어나야 하는데 선택지가 연 15만원을 태워야 하는 앱스토어 밖에 없다는게 뭣같다.

인앱토스는 버튼 누르면 포인트 주는 앱으로 도배되었다. 플랫폼이 이미 개망했다.

딸깍 하면 포인트 주는 앱이 모든 트래픽을 다 빨아가기 때문에 오히려 똑바로 된 앱을 내는게 멍청한 곳이다. 인정?

토스의 태생이 포인트 후킹 앱이기 때문에 후킹 앱 내부에 또 다른 후킹 앱으로 도배되는건 당연한 수순이었던거 같다.

SNS 에서 핫한 강남스타일 밈, oiia 와 같은 밈을 소재로도 만들어보았지만, 별로 호응이 없었다.

열심히 유튜브와 인스타에도 홍보했지만 마찬가지였다.

난 아무래도 쓰레기를 만든거 같다.

고양이를 회전시켜요 (OIIA)

https://www.instagram.com/reel/DX6wDQECAuK/?utm_source=ig_web_copy_link&igsh=NTc4MTIwNjQ2YQ==

강남스타일 밈 제작기

https://www.instagram.com/reel/DX6wQrNCqvK/?utm_source=ig_web_copy_link&igsh=NTc4MTIwNjQ2YQ==

바쁘게 주말 마다 꽤나 공들여서 앱을 만들고 출시를 반복..

그렇게 해봤자 직장인에게 주어진 시간이 절대로 길지가 않다. 너무나 순식간이다.

매일 새벽 까지 잠을 참아가면서 그렇게 살았지만, 결정적으로 나가는 돈이 더 컸다. 그래서 앱 만드는건 접기로 했다.

AI 로 사업을 해보자

이것 말고도 AI 로 사업을 해보려고 했다.

너에게 모든 권한을 넘겨줄테니 77억을 만들 수 있는 사업 아이템을 만들어오라고 했다.

Claude Code 가 밤새도록 돌더니 다음 날 무려 7개 정도 되는 사이트를 만들어놓았다.

무슨 서비스인가 들어가서 보니, 간단한 1가지의 편의 기능을 제공하는 서비스들이었는데 실제로 동작하는 서비스는 없었다.

진짜 그럴싸 하게 껍데기만 만든 것이었다.

그리고 어느날에 갑자기 낯선 사람에게서 Email 이 날라오길래 뭔가 하고 봤더니

product hunt 라는 곳에 AI가 만든 서비스를 올려놓았는데 기준치에 미달이라고 연락이 온 것이었다.

와 놀라운 결과였다. 나는 아무것도 개입한 것 없었고 혼자서 밤새 토큰을 태워서 서비스를 만들고 서비스 홍보까지 해버린 것이다..

만약에 결과물이 실제로 동작하는 서비스였다면 진짜 서비스를 할 수 있었을 지도 모르는 일이다.

내 생각에 그 단계까지 가는데 곧 머지 않았다. 놀랍고도 무섭다.

이걸 하면서 한 가지 얻은 정보가 있는데

사이트 내에서 결제를 하기 위해 PG를 붙이려고 했는데 AI 는 그냥 무지성으로 Sprite 를 붙여버렸다.

참고로 Sprite는 한국에서 지원되지 않는다.....

AI 를 회사에서 잘 써보자

AI를 좀 더 잘쓰는 방법에 대해서 연구할 필요가 있겠다 싶었고, 회사 업무에 더 잘 쓰는 방법이 없을까? 고민해보았다.

일단.. 우리 회사는 AI 를 전사적으로 적극적으로 밀어주는 회사는 아니었기 때문에

메신저에 AI에 대해 자유롭게 이야기하고 공유할 채널이 있어야겠다 싶어서 채널을 하나 만들었다.

거기에 그냥 아무 자료나 막 올렸다. AI 강의 자료, 새로운 소식, 뉴스, 내가 만든것 등..

그때 때마침 하네스 엔지니어링 이라는 개념이 막 나왔던 초창기 시기였고

나는 Jira Ticket -> Code Base 조사 -> Plan -> 코드 구현 -> 리뷰 -> PR 전체 개발 과정에 대한

조잡한 하네스 workflow 를 만들어서 사내 메신저로 공개했다.

영상으로 찍어서 공개했더니 꽤 효과적이었다.

이 채널을 만든 지 얼마 안되어서 사내 AI TF가 만들어졌고, 드디어 AI 로 뭔가를 해보자는 움직임이 시작되었다.

(다음 게시물에서 이어서)

[개발자 이야기] AI 에게 일을 위임하고 나는 딸깍하는 회사 라이프를 꿈꾸다

snowman95 — Sat, 21 Mar 2026 02:30:46 +0900

매우 저조한 AI 활용도

우리 회사에서는 클로드 코드는 지원하지 않고 (지원하다가 잠정 중단), 커서는 지원하고 있습니다.

제가 팀 내에서 커서 이야기 나올 때마다 참 좋으니 한번 써보라고 권하고 아 진짜 빠르고 편하고 너무 좋은데 나만 쓰기 참 아까운데.. 하면서 나름의 노력을 했습니다... 그 덕분인지 올해가 되어서야 팀 대부분이 구닥다리 코파일럿에서 커서를 옮겨오는 것 까지는 성공했습니다.

회사마다 AI 활용도가 천차만별인데요.

openAI 의 사례처럼 AI 가 일 다하는 곳도 있고, 저희 팀 처럼 나를 약간 도와주는 도구? 정도로 쓰는 곳도 많습니다.

[AI] 완전 자율 소프트웨어 구축 시스템 개발 경험과 과정에 대한 글

open AI 에서 공개한 글에 대해 요약하고 제 생각을 추가한 글입니다. 지난 5개월 동안 수동으로 작성한 코드가 단 한 줄도 없이 소프트웨어 제품의 내부 베타 버전을 개발하고 배포했습니다.이 제

11001.tistory.com

대충 한 이정도.. 활용도였던 거 같습니다.

1. 검색 엔진 대신에 물어보는 용도

2. 반복되는 코드나 간단한 코드 수정 정도

3. 코드 리뷰 용도

저희 회사 서비스는 전세계에 서비스 중인데요. 서비스되는 국가들에 대해 다르게 처리되는 것들이 너무 너무 많기 때문에

검토하고 확인하고 재확인하고 기억해내고 .. 이 과정들이 제 일의 거의 80%는 됩니다. 가끔 제가 개발자인가 잊어버릴 때도 많습니다.

옛날에 삼성에 있을때는 작업 계획서 쓰고 엔지니어들 출입 관리하고 일정 잡고.. 내가 스케줄 매니저인가? 그런 생각 많이 했는데 요즘 비슷한 생각이 드는거 보면 확실히 제가 큰 회사로 다시 돌아온 느낌이 드네요.

AI 활용도가 떨어진 이유

어쨌든 저희 팀은 정말로 AI 도입이 정말 많이 늦었고 활용도가 저조한데요. 그 이유는 이렇게 뽑아보았습니다.

1. 개발자의 일 자체가 코드에 집중되기 보다는 기획 검토, 정리, 분류 등 코드 보다는 문서 작업에 많은 리소스가 들기 때문

2. 글로벌 서비스라서 코드가 복잡도가 매우 높다는 점.

3. 다들 10년+ 의 괴물 시니어 경력자라서 AI 에게 일을 시켜봤는데 별로더라.. 내가 하는게 더 낫다는 생각

4. 전사적으로 AI 를 밀어주는 부서나 사람이 없음.

AI 는 개발자의 위기가 아닌 성장 기회

그럼에도 제가 AI 를 억지로라도 많이 쓰고 활용하는 분위기를 만들고자 한 이유는 개발자는 성장을 멈추면 안되기 때문인데

지금의 시대가 AI를 원하는 시대가 되었기 때문에 좋든 싫든 우리 개발자들은 AI 를 통해 성장 해야만 하는 상황에 놓여있기 때문입니다.

마치 AI 를 거부하는 것은 난 디지털 싫은데? 아날로그가 좋은데? 지금도 충분히 잘 되는데 굳이? ㅋㅋ 하는 것과 마찬가지라는겁니다.

AI 는 개발자에게 숙제를 뛰어 넘어 하나의 큰 과업입니다.

저도 처음에는 AI 거부하기도 하고 방관하기도 하고 한 1년? 2년 가까이 좀 더 지켜보자는 마음가짐 이었는데

이게 저의 성장 발판이라는걸 스스로 깨닫고나서 그때 부터 미친듯이 밤낮으로 공부해보고 돈 쏟아부으면서 이것 저것 다 사용해보고 따라가려고 발악했습니다.

AI 도입 시도

누구나 AI 에 대한 글을 쓰고 공유할 수 있는 슬랙 공개 채널을 먼저 만들었습니다.

누군가 열심히 활동해주면 좋겠지만 그럴 가능성이 낮기 때문에 사실상 제가 리딩할 마음가짐으로 만들었고,

AI 를 배우고 관심을 가질 수 있는 글을 공유하다보니 팀원들도 같이 AI 사용 사례들을 올리면서 관심을 보여주셨습니다.

최근에는 AI 에 특히 관심이 많았던 분들과 업무 시간 중에 1시간 정도 OpenClaw 를 설치하고 메신저에 연동하는 작업 것을 실습하는 시간을 가져보았고, 그렇게 만들어진 OpenClaw 를 슬렉 채널에서 말을 걸 수 있게 연동을 해두었더니 다들 개발자 아니랄까봐 이것저것 기능을 붙이더군요. 재미있었습니다.

제가 시간적인 여유만 있으면 좀 더 양질의 자료를 준비하고 많은 것들을 공유하고 싶은데 요즘 일에 파묻혀있다보니.. 쉽지 않네요.

AI 개발 workflow 를 만들자

저는 개인이 AI 를 사용하는 것을 넘어서 팀 전체에서 활용되었으면 좋겠다는 생각이 들었습니다.

회사에서 개발자가 하는 일을 (일부분 이라도) AI 에게 떠넘기는것을 꿈꿨습니다.

그러던 와중에 AI 부서에서 현업 10년+ 풀스텍 AI 개발자로 활동 중인 지인을 통해 좋은 블로그를 소개 받았고, AI 활용 사례 등을 공유 받았습니다. (동서남북 ‍♂️)

쉽게 말해서 AI 에게 요구사항을 전달하여 코드를 편집하게 하는 과정에 대해 연구하고, 그것을 workflow(순서대로 처리하는 구조화된 업무 방식)으로 만들어야 한다. 그런 내용이었습니다.

Boris Tane

The research-plan-implement workflow I use to build software with Claude Code, and why I never let it write code until I've approved a written plan.

boristane.com

[글 요약] Cloudflare 출신 엔지니어의 클로드 코드 사용 방법에 대한 글입니다.여기서 소개하는 workflow 는
"문서로 작성된 계획을 검토후 승인하기 전까지 절대로 코드 작성을 시키지 않는다" 라는 대원칙을 사용하여 계획과 실행을 분리했습니다.
1. 기본 개념은 Garbage in, garbage out. plan은 코드만큼 중요하다. (쓰레기 계획은 쓰레기를 반환)

2. 좋은 plan을 짜려면 research도 잘 되어야 한다. (프로젝트 내의 코드가 어떻게 짜여있는지에 대한 연구)
3. plan을 매우 꼼꼼하게 검토하고 허락없이 절대 코드를 편집하지 않는다. (코딩하고 검토하는게 아니라 검토를 다 끝내고 코딩)

이 아이디어를 CLAUDE.md 또는 커서 rules/workflow.mdc 로 옮겨서 항상 컨텍스트에 포함시키게 했습니다.

개발자가 요구사항을 전달하면 코드베이스를 연구하고 계획을 세운 다음에 제 승인을 받을 때 까지 계획 수정을 반복하고 승인을 받으면 코드로 옮기는 매우 단순한 흐름입니다.

출처: boristane.com

Git 브랜치 전략도 그렇고 이런 것도 엄청 복잡한 흐름 보다는 결국 사람이 이해할 수 있는 단순한 형태를 사용하는게 가장 강력합니다.

그리고 세팅도 수 초 이내에 끝낼 수 있을 정도로 매우 간단해야합니다.
일단 TUI 환경(cmux 를 추천)에서 cursor cli 설치하고 ~/.cursor/rules/workflow.mdc 파일에 위의 규칙을 작성하는 것 까지만 하면 세팅은 끝납니다.

curl https://cursor.com/install -fsS | bash

사실 이 내용만 보면 그냥 AI Agent 돌리는 거랑 크게 다를 거 없는데? Plan 모드 쓰면 되지않나? 랄프 루프 돌리면 되지 않나? 싶지만

이 workflow 는 모든 작업 산출물을 문서화 하여 영구적으로 저장한다는 차이가 있습니다.

문서들은 개인 클라우드 저장소로 올려놓고 해당 폴더를 옵시디언 노트로 열어서 연결된 링크를 쉽게 오가면서 확인하는 그러한 형태로 사용할 수 있겠습니다.

눈치 채신 분들도 있겠지만 ~/.cursor/rules 경로를 사용하여 전역 프로젝트에 공통 적용하는 방식입니다.

깃 저장소에 올리는게 아니고 개인 별로 사용하게 됩니다.

왜냐면 작업 할 때마다 발견되고 연구된 새로운 내용이 실시간으로 계속 업데이트 될 테니까요

기획서는 MCP 써서 누구나 받아올 수 있고 코드베이스는 공유되고 있으니 각자 AI Agent 가 읽고 이해하는게 빠릅니다.

작업 판단에 중대한 영향을 끼치는 문서나 설계도 같은 것들만 별도로 공유해서 받아쓰는 정도로 충분하지 않은가 싶습니다.

QA 이슈 해결 workflow 를 만들자

저희 회사의 경우에는 새로운 기능 스펙 개발에 대해서는 이와 같은 사이클을 가지고 있는데요.

기획 Jira 티켓 -> 티켓 내 기획서 확인 -> 개발자가 기획서 내용을 읽고 이해, 정리 -> 개발 jira 티켓 생성 -> 코드 변경 계획 -> 코딩 -> PR 생성 -> 코드 리뷰 -> 개발 환경 배포 -> QA 진행 -> (이슈 발생시) QA jira 티켓 발행 -> 이슈 내용을 읽고 이해, 정리 -> 코드 변경 계획 -> 코딩 -> PR 생성 -> 코드 리뷰 -> 배포

사실은 첫 단계부터 AI 가 해야하지만, 요즘 제가 하고 있는 진행중인 장기 프로젝트는 한창 QA 단계에서 돌고 있는 상태라..

당장은 QA 단계에 대한 workflow 가 필요한 상황입니다. (단계 별로 만들지 못해서 참 슬프네요 현실이 그러하네요..)

QA 진행 -> (이슈 발생시) QA jira 티켓 발행 -> 이슈 내용을 읽고 이해, 정리 -> 코드 변경 계획 -> 코딩 -> PR 생성

QA jira 티켓 이슈 내용을 읽고 이해, 정리

일단 AI Agent 가 티켓 내용을 읽어 오는 것 부터 가능하게 해보았습니다.

.cursor/mcp.json 에 atlassian MCP 서버를 등록합니다.
(node v18 사용 시 오류 발생하여 강제로 node v20 경로를 읽게 변경했습니다. 대부분은 그냥 npx 로도 충분할듯)

{
  "mcpServers": {
    "atlassian": {
      "command": "/Users/사용자/.nvm/versions/node/v20.20.0/bin/npx",
      "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp"]
    }
  }
}

이렇게 하고 웹 브라우저가 열려서 인증을 받게 됩니다.

저는 cursor cli 를 설치 했기에 터미널 열고 agent 입력 합니다.

MCP 사용 ㄱㅊ? 하고 물어봅니다. yes !

티켓 유형에 대해 설명해주고나서 해결안됨, 검토중 상태의 QA 티켓를 모두 가져와서 문서에 표로 정리해달라고 시켰습니다.

근데 해보니까 지라에서 이미지나 영상은 못 가져오고 담당자 마다 티켓 내용 형식이 조금씩 다르는 것 때문에

AI 가 이해할 수 있는 상태가 아닌 상태로 가져온 경우들도 있더군요.

이럴 때는 어쩔 수 없이 사람이 개입해서 이건 어떤 내용이야~ 이렇게 해줘야만 합니다.

티켓을 읽어와서 문서에 한번 정리하는 과정이 불필요해 보일 수도 있겠지만 굳이 이 과정을 넣은 이유가 이것 때문입니다!
(티켓의 요구사항을 보완하는 단계)

어쨋든 이제 테이블 표에 이쁘게 티켓 번호, 이슈, 확인내용, 원인, 해결, 브랜치명, PR 링크, 진행상황 등이 쭉 정리되어서 보여집니다.

이제 코딩을 위한 workflow 를 태우기

티켓 하나씩 차례로 research -> plan 과정을 시켜보았습니다.

코드베이스를 연구한 뒤에 md 파일을 남겨놓고, 연구된 코드베이스를 기반으로 plan 을 세우니 매우 똑똑하게 작업을 해주더군요.

cursor 에도 plan 모드가 있는데 이 커스텀 workflow 는 문서를 남긴다는 장점과 plan 에서 원하는 부분에 인라인으로 메모를 남기고 다시 계획을 세우게 만드는 루프를 돌릴 수 있어서 훨씬 효과적입니다.

근데 문제점은 cursor 자체적으로도 workflow 를 가지고 있기 때문에 제 workflow 를 무조건적으로 잘 지켜주지 않습니다.

계속 지속해서 "내 승인이 없으면 코드 변경하지마", "지금 단계 까지만 진행해야해" 와 같이 지시를 내려야하는 불편함이 있었습니다.

일단.. 진행시켜!

수 십개의 이슈 티켓을 차례로 진행하려니 시간이 부족해서 도저히 안되겠습니다. 지금 무척 바쁘거든요 ㅠㅠ

(나중에 일괄 검토할 각오로) 전체 티켓에 대해 workflow 를 진행 시켜보았고 이번에만 plan 은 일괄 승인해주겠다. 각 티켓마다 base 브랜치를 기반으로하는 하위 브랜치를 만들고 코드 변경 작업 후 커밋 까지 해줘 라고 시키고 저는 저녁 밥을 먹고 왔습니다.

(잠시후...)

이런? 같은 페이지 내에서 관련된 이슈를 묶어서 하나의 브랜치에서 처리를 해두었더군요?

실제로 관련 이슈들은 묶어서 하나의 PR 로 올리곤 했거든요 그래서 제가 원했던 희망사항이었지만 딱히 커서에서 시킨 적은 없습니다!

그리고 한 세션에서 처리하기엔 너무 분량이 많다고 불평했습니다.

물론 분량이 많은 거 동의합니다... 그래도 커서가 한 7개 정도의 이슈를 한번에 처리해두었거든요.

코드 변경사항을 보니 비교적 간단한 변경 작업들이었고, 제가 딱히 건드릴게 많이 없어서 대부분은 곧바로 PR 까지 생성할 수 있었습니다.

일단 여기까지 시도하여 꽤나 나쁘지 않은 결과물이 나왔으므로 성공!?

(문구 바꾸기, 조건 바꾸기 같은 단순 작업 같은건 앞으로 티켓만 넣으면 PR 생성 까지도 당장 가능하다고 봐야함)

후기 정리

개발을 위한 workflow 앞 단에 기획서나 티켓 내용을 읽어오는 과정을 MCP 를 통해 구현했습니다.

이슈나 요구사항에 대해 부족한 내용을 사람이 보완을 해주는 단계가 필요하고, 이 단계에 부족한 자료 추가와 내용 정리가 필요.

작업 시 worflow 를 반드시 준수해 달라고 지속적인 지시 필요

유사 작업 분류, 브랜치 생성 -> 이 과정을 좀 더 개선할 필요가 있는 상태.

이 정도로 현재 진행형인 상태라고 정리되네요.

가장 중요하게 느낀 것은 기획서를 반드시 AI 가 읽어야한다는 것이었습니다.

기획 내용을 모르니 그 기획을 코드로 구현한 것에서 발생한 이슈 내용을 완벽히 이해하지 못했습니다.

사실 처음 만드는 단계부터 기획서를 넣어서 그걸 베이스로 작업을 시키고 문서화 했더라면
아마 지금 단계에 왔을때 정확히 이슈와 코드베이스를 이해하고 작업이 가능했을것이라 믿고 있습니다. (인간이 미안해)

어쨋든 이거를 개인적으로 계속 테스트하고 디벨롭 하고 있는데

어느정도 정립이 되면 팀 내에 공유하고 작은 부분에서라도 도입해보려고 합니다..

[독후감] 나의 돈 많은 고등학교 친구 (송희구 작가)

snowman95 — Sun, 8 Mar 2026 13:33:07 +0900

[오랜만에 만난 친구가 알고보니 시그니엘 집주인]

올해 나이 마흔에 대기업 과장인 영철은 아들인 영현을 데리고 롯데월드에 갔다가 고등학교 시절 골동품 운영하며 반지하에 살던 친구 광수와 그의 아들 광현을 만나게 됩니다.

광수는 20초 만에 기구를 탈 수 있는 프리미엄 매직패스 티켓을 가지고 있었고

영철의 티켓은 1시간을 기다려야 기구를 탈 수 있는 일반 티켓이었기에 1시간 이후에 만나기로 합니다.

광수는 조그만 사업을 한다는 영철이 허름한 차림에 차를 가지고 오지 않은 것으로 보아, 분명 저 멀리 외곽에서 놀러온 것으로 생각했습니다.

영철은 사옥을 짓는 현장에서 광수를 만나게 되는데 알고보니 광수가 건설 회사 대표였네요.
알고보니 광수가 저~위에 살고 있다는 것이 경기 북부가 아니라 진짜로 저 위인 시그니엘 이라고 합니다. 어떻게 된 일일까요? 정신이 멍해집니다.

[돈을 쉽게 벌고 싶었던 영철]

영철은 우연히 주워들은 루나바이오헬스케어 라는 주식에 5000만원을 넣었다가 휴지조각이 됩니다.
영철이 했던 것은 투자가 아니라 투기였던 것이죠.

점집에 들려 점을 보고왔는데 물을 피해야 합니다 라는 소리를 듣고 아, 내가 잘 안되는 이유가 물가에 살아서 그렇구나~ 그러던 와중에 경기 외곽 타운하우스를 분양을 받게 됩니다.

그렇게 꿈에 그리던 타운하우스를 입주했으나 기대와 많이 달랐고,
막상 들어가니 단점도 보이고 시세는 반토막이 나고, 대체 왜 그런지 알 수 없었습니다.

영철은 너무 쉽게 돈을 벌고자 했기 때문이죠.

루나바이오헬스케어라는 회사에 대해 제대로 알아보지도 않고 그저 누군가의 비밀 정보라는 소식에 팔랑 넘어가서 '투기' 해버렸고
부동산도 잘 모르면서 공부하여 살 생각하지를 않고, 점에 의지하고 타운하우스 팔이들에게 또 팔랑 넘어가서 호구 당했습니다.
그렇게 평생 모아온 돈인데 한 순간에 날려버린 이유는 공부를 안 하고 누군가에게 미신에 의지했기 때문입니다.

저는 이 열등감을 이해합니다. 사람은 누군가와 비교를 할 수 밖에 없고 그게 나보다 못살던 가까운 친구라면...
괜히 내가 뒤쳐진 거 같고 마음이 조급하고 뭐라도 해야할 거 같은 생각이 크게 들죠. 그러다가 준비 안된 상태에서 무턱대고 덤볐다가 화를 당하기 마련입니다.
이야기는 광수,영철의 아들인 광현, 영현의 이야기로 넘어갑니다.

[더 많은 돈을 벌기 위해 사업가가 된 광현, 영현]

광현, 영현은 성인이 되어 대학교에 들어갔습니다.
낮밤으로 할아버지들이 소리를 지르는 동네 원룸에서 둘이서 살면서 알바를 하며 나름 열심히 돈을 모았다고 생각하지만 돈이 모이질 않습니다. 광수를 찾아가 도움을 요청합니다.

돈을 더 많이 벌어라
소비를 줄여라

광현과 영현은 돈을 더 많이 벌기 위해 사업에 뛰어듭니다. 평소 좋아하던 캠핑이라는 주제로 해보기로 했는데요.
국내에서는 생소한 외국 캠핑 브랜드를 사서 팔아보기로 했는데요. 하나도 팔리질 않습니다.
광수의 도움으로 독일 캠핑 박람회에 방문하여 캠핑용품을 구경하고 백여개의 업체 명함을 받아옵니다.

그 중에 호의적인 업체와 연락하여 계약 했고 샘플을 들고 오프라인 매장에 찾아가서 샘플 전시 부탁하고, 열심히 카페에 홍보도 했습니다. 그러다 한국에서 열리는 박람회에서 이제는 소비자가 아닌 공급자가 되어서 박람회에 캠핑 용품을 소개하는 역할을 하게 되었고, 수동적인 자세에서 능동적으로 주체적으로 사람자들의 이목을 끌면서 성공적으로 마무리했습니다.

그 이후로 공모전을 여는 등 여러가지 시도를 통하여 사업은 안정기에 접어 들었습니다.

여기서 느낀 점은 수동적인 자세로 사업을 하는 것은 남의 말을 듣고 주식을 사서 대박 나기를 바라는 것과 다를 거 없다는 겁니다.

가만히 있는데 손님들이 오기를 바란다? 내가 직접 가서 입에 떠먹여주고 반응도 보고 또 찾아올 수 있게 해도 모자라다는 겁니다.

기회는 누구에게나 찾아 오지만 가만히 있으면 기회인 줄도 모르고 지나가는게 맞는거 같습니다.
그러나 한국인들은 어릴때 부터 나대지마라, 가만히 있으면 중간은 간다

이딴 식으로 교육 받으며 자랐고 저도 그렇게 자랐기 때문에 이런 부분에서 엄청난 고생을 하게 되는거 같습니다.

[광수는 어떻게 부자가 되었는가]

광수는 행복, 성공 이런것들을 목표로 하지 않습니다.
행복은 언제든 느낄 수 있는 것이고, 작은 것을 이루는 것도 성공이기 때문이죠.
부자는 목표라고 할 수 있습니다. 하지만 부자는 누구와도 경쟁하는 것이 아닙니다.

광수는 어린시절 물이 새는 철물점을 보며, 물이 새지 않는 튼튼한 집을 짓고자 하는 깊고 강한 목표가 새겨졌고
그 목표를 위해서 건축과 진학, 건축사무소에서 일하며 남들이 힘들다고 하지 않는 일까지 도맡아 해왔습니다. 젊은 시절의 고생들이 나중에 기회가 왔을때 잡을 수 있는 능력이 되었고,
약간 손해를 보더라도 고객에게 최고의 결과를 제공하고자 하는 마음가짐이 있었기 때문에 결과가 좋을 수 밖에 없었고, 그것이 입소문을 타고 사업이 번창하게 되었습니다.

광수는 어린 시절 반지하에서 살았기에 제일 높은 곳에서 살고 싶었고, 반지하의 좁고 작은 창문을 보며 자랐기 때문에 가능하면 크고 넓은 통창을 얻고 싶었습니다.

그것이 광수의 성장동력이 되었습니다.

이러한 본인만의 성장동력, 신념, 철학이 있었기에 본업에 진심일 수 밖에 없었고 좋은 건물을 지을 수 밖에 없습니다.

저의 경험을 빗대어 보면 저는 광수처럼 제가 이루고 싶은 원초적인 목표가 없었고, 대학 외에 다른 선택지가 없어서 대학을 갔고, 그나마 익숙하고 많이 친근한 것을 전공을 선택했습니다. 광수와 마음 가짐 자체가 다르고 삶의 방향이 다르죠..

[부의 대물림, 가난한 마음가짐 물려주기]

하지만 광수의 아들인 광현은 어차피 아버지에게 자산을 물려 받으면 스타트 자체가 다르니까 인생 편거 아닌가요? 그런데 광현도 과연 광수와 같은 성장동력을 가지고 살아갈 수 있을까요?
요즘 중상층 자녀들이 어차피 부모님이 집 물려주실거니까 공부도 안하고 대충 살려고 한다는 고민이 있다고 합니다. 이게 바로 부의 대물림에서 오는 부작용이죠.

현명한 광수는 아들인 광현에게도 자산을 물려주지 않고 용돈도 쥐어주지 않습니다.
아버지의 꼭 필요한, 최소한의 서포트를 받으며 스스로 인생을 학습하고 경험을 해보며 삶을 개척합니다.
부는 축적하는 것만 어려운게 아니라 유지하는 것도 매우 어렵습니다.
아마 이렇게 키우지 않았다면 어차피 내 돈도 아니고 아버지가 준 공짜 돈인데..ㅋ 하고 흥청망청 쓰는 철부지 아들이 되었을 지도 모릅니다.

[후기]

이 책을 읽으면 어린 시절 부터의 빌드업이 얼마나 삶에 큰 영향을 미치는가를 볼 수 있습니다.
내가 살아가면서 무언가를 절실히 느끼고 원하는 바, 목표를 가지고 그것을 향해서 쏟아부을 수 있는 열정을 가져야합니다.

무언가 쉽게 얻으려고 하면 쉽게 잃어버린다. 철저히 시간과 공을 들여서 결과를 얻으려는 자세를 가져야 합니다.

열등감은 부자에게도 있고 누구에게나 있습니다.

부자는 남과 경쟁하는 것이 아닙니다. 남과 비교하면 끝이 없습니다. 남이 아닌 나에게 집중해야합니다.

투자든 사업이든 "기본"에 충실해야 합니다.
내가 얼마를 남겨먹을 지 고민하기 전에 내가 무엇을 해줄 수 있는지? 생각해야합니다.

무엇을 얻고자 한다면 반드시 수동적인 자세를 버리고 적극적으로 뛰어야 합니다.

어찌보면 뻔한 소리이지만, 이 뻔한 것도 잘 몰라서 잘 못지키는 사람들이 많고 저도 똑같습니다.

제 인생의 근본적인 목표도 모호하고, 열심히 만든 서비스를 적극적으로 홍보할 줄도 몰랐고, 부끄럽고 망설여하면서 많은 기회를 놓친것도 제 제 잘못입니다. 열심히 공부한 투자가 아닌 팔랑귀 투기를 통해 많은 기회비용을 날려버린 것도 제 잘못이고요.

저는 3/28 송희구 작가님의 부동산 강의를 들으러 킨텍스에 갑니다.

무언가 얻고 싶기에 시간과 노력을 들여서 책도 읽고 먼 거리를 이동합니다.

광수와 약간 다르지만 저는 내집마련이 어릴적 부터의 큰 소원이자 목표를 뛰어넘은 숙원 같은거라

사회초년생 부터 또래에 비해 유독 관심이 많았고, 부동산 스타트업에 가게된 이유도 그러한 제 내재적인 갈망 때문이었을거 같습니다.

현재 결혼하면서 내집마련의 꿈을 이루기 위한 목전에 있고

똘똘한 내 집과 그 이후의 갈아타기를 잘해서 저도 잠실 입성을 하게 되는 그 날까지

개발도 열심히, 부동산 공부도 열심히 해보려 합니다.

[시니어 FE] CSRF GET 공격 시나리오와 방어법

snowman95 — Sat, 7 Mar 2026 14:50:44 +0900

"쿠키(Cookie)를 인증 수단으로 사용할 때, SameSite 속성을 Lax나 Strict로 설정하는 것만으로 CSRF 공격을 완벽히 막을 수 있을까요? 추가적으로 'CSRF 토큰'이나 'Custom Header'가 필요한 이유는 무엇이라고 생각하시나요?"

"사용자가 우리 서비스에 로그인한 상태로, 해커가 만든 악성 사이트에 접속했습니다. 그 사이트에는 우리 서비스의 '비밀번호 변경' API를 자동으로 호출하는 폼(Form)이 숨겨져 있습니다. 사용자가 모르는 사이에 비밀번호가 바뀌는 이 공격을 프론트엔드와 백엔드에서 어떻게 협업하여 막으시겠습니까?"

CSRF(Cross-Site Request Forgery) 공격의 목적

사용자의 권한을 도용해 비밀번호 변경, 결제, 게시글 삭제 등 서버의 상태를 변조하는 것입니다.

기본적으로 GET 요청은 자원의 변경하지 않기 때문에 문제가 될 일은 없다만, 만에 하나 GET 메소드로 잘못 지정하거나 잘못 사용하고 있는 서버 자원을 변경하는 API가 있다면 공격의 대상이 될 수 있습니다.

CSRF PUT/POST 공격 시나리오

CSRF POST/PUT 공격은 사용자의 브라우저가 대상 서버로 요청을 보낼 때 인증 쿠키를 자동으로 포함하는 특성을 악용합니다.

공격자는 사용자가 로그인한 상태를 유지하고 있다는 점을 악용하여, 사용자 모르게 서버 상태를 변경하는 요청을 보내게 합니다.

예를 들어 사이트에 로그인한 상태에서 해커의 사이트에 접속하게 하여 form 을 제출하게 합니다.

근데 외부 요청은 서버에서 설정한 CORS 정책으로 다 막히지 않나요?

<form> 태그는 CORS 정책을 무시합니다.
브라우저는 폼 제출을 페이지 전환의 일종으로 간주하기 때문에 다른 도메인으로 POST 요청 보내는 것에 대해서는 무시합니다.

form 태그는 method="POST" 와 GET 만 지원하기에 해커의 공격 대상은 POST, GET 뿐입니다.

일단 외부에서 우리 사이트로 요청이 들어오는 경우

브라우저 레벨에서 SameSite Cookie 설정을 통해 외부 사이트에서 쿠키 자체가 넘어가지 못하게 하여 대부분 방어가 됩니다.

SameSite는 "다른 사이트(Cross-site)에서 발생한 요청에 이 쿠키를 실어 보낼 것인가?"를 결정합니다.

SameSite=Strict 가장 엄격합니다.

사용자가 google.com에 있다가 링크를 타고 naver.com으로 넘어올 때조차 쿠키를 보내지 않습니다.
(사용자 경험이 나빠질 수 있음 - 매번 다시 로그인 등)

SameSite=Lax (기본값) 조금 유연합니다.

외부 사이트에서 우리 사이트로 오는 '하위 리소스 요청(img, iframe 등)'은 차단하지만, '안전한 요청(GET)'이나 '탑 레벨 내비게이션(링크 클릭)', 즉 브라우저의 주소창이 바뀌는 a 태그 클릭이나 window.location.href 이동은 쿠키 전송을 허용합니다.
하지만 POST, PUT, DELETE 같은 상태 변경 요청에는 쿠키를 보내지 않습니다.

애플리케이션 레벨에서는 CSRF Token 로 방어가 가능합니다.

서버가 페이지 렌더링 시 매번 무작위 토큰을 발급하고, 클라이언트는 POST/PUT 요청 시 이를 헤더나 바디에 포함합니다.

해커는 사용자의 쿠키는 브라우저를 통해 보낼 수 있지만, 자바스크립트로 우리 서버의 토큰값을 읽어올 수 없으므로(SOP 정책) 공격이 실패합니다. 보통 초고보안이 필요한 환경에서 이렇게 합니다.

SPA 에서는 매번 서버가 토큰을 보내줄 수 없으니 로그인시 무작위 생성된 CSRF 토큰을 쿠키에 넣어둡니다.
HttpOnly: true 가 아닌 false 설정하여, 자바스크립트에서 읽어와서 API 요청 보낼때 별도의 헤더로 실어 보내는 것입니다.

왜 그러냐면 브라우저가 자동으로 실어 보내는 쿠키를 맹신적으로 믿어서는 공격 당할 수 있기 때문에 별도의 헤더를 쓰는 것입니다.

인프라/API 레벨에서는 Custom Header 검증이 가능합니다.

X-Requested-With 같은 고정된 커스텀 헤더를 하나 추가하여

왜 Custom Header가 CSRF를 막는가? (핵심 원리)
핵심은 "브라우저는 교차 출처(Cross-Origin) 요청 시, 커스텀 헤더가 포함되면 반드시 Preflight(OPTIONS) 요청을 보낸다" 는 점에 있습니다.
기본 헤더 (Simple Request): Content-Type: text/plain, Accept 등 표준 헤더만 사용하면 브라우저는 바로 서버로 요청을 보냅니다.
커스텀 헤더: X-Requested-With, X-App-Version 같은 표준이 아닌 헤더를 추가하면, 브라우저는 이 요청을 '잠재적으로 위험한 요청' 으로 간주합니다.
Preflight 발생: 브라우저는 실제 요청을 보내기 전에 OPTIONS 메소드로 서버에 "이 헤더 써도 돼?"라고 먼저 물어봅니다.
CORS 차단: 해커의 사이트(evil.com)에서 우리 API로 커스텀 헤더를 실어 보내려 하면, 서버는 Preflight 응답에서 evil.com을 허용하지 않을 것이고, 브라우저는 실제 요청 자체를 보내지 않고 차단합니다.

① 클라이언트(프론트엔드) 설정
모든 API 요청에 공통 헤더를 주입합니다. 보통 axios 인스턴스나 fetch 래퍼 함수에서 설정합니다.

import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.bank.com',
  headers: {
    // 관례적으로 많이 쓰는 헤더명입니다. 값은 무엇이든 상관없습니다.
    'X-Requested-With': 'XMLHttpRequest', 
    'X-App-Service-Id': 'my-frontend-app'
  },
  withCredentials: true // 쿠키를 포함하여 전송
});

② 서버(백엔드) 설정
서버는 두 가지를 수행해야 합니다.

CORS 설정: Access-Control-Allow-Headers에 우리가 정의한 커스텀 헤더명을 추가하여 허용합니다.

헤더 검증 미들웨어: 상태를 변경하는 요청(POST, PUT, DELETE 등)이 올 때, 해당 헤더가 존재하는지 확인합니다.

// Express.js 예시 미들웨어
app.use((req, res, next) => {
  // GET 요청은 대개 제외하고, 상태 변경 요청에서만 체크
  if (['POST', 'PUT', 'DELETE'].includes(req.method)) {
    const customHeader = req.headers['x-requested-with'];

    if (!customHeader) {
      // 헤더가 없으면 우리 프론트엔드에서 보낸 것이 아니라고 판단
      return res.status(403).json({ error: 'Invalid Request: Missing Custom Header' });
    }
  }
  next();
});

CSRF GET 공격 시나리오

로그인한 사용자가 a 태그를 클릭하게 만들고, 그 주소가 'https://bank.com/transfer?to=hacker&amount=10000' 이와 같을 경우, 쿠키가 sameSite=LAX 이면 외부 사이트여도 a 링크니까 쿠키가 보내질거고, CORS 의 영향을 받지도 않겠네요?

그럴 수 있습니다.
SameSite=Lax 에서 a 태그를 이용한 탑 레벨 내비게이션은 쿠키 전송이 허용되므로, 보안이 허술한 서비스라면 CSRF 공격에 노출될 수 있습니다.
CORS는 '스크립트(JS)'가 다른 도메인의 데이터를 읽으려 할 때 작동하는 보안 책입니다.
사용자가 직접 링크를 클릭해서 페이지를 이동하는 것은 브라우저의 기본 동작이므로 CORS 정책의 적용 대상이 아닙니다.
사용자가 이미 은행에 로그인되어 있다면, 브라우저는 "사용자가 직접 링크를 눌러서 은행으로 가겠다는데, 당연히 인증 쿠키를 보내줘야지"라고 판단합니다.

CSRF GET 방어 방법

이를 방어하기 위해 두 가지 원칙을 고수해야합니다.
첫째, 상태를 변경하는 모든 API는 반드시 POST/PUT/DELETE를 사용하고,
둘째, 단순 쿠키 인증에만 의존하지 않고 CSRF 토큰이나 Custom Header 검증을 병행합니다.
특히 금융권처럼 민감한 서비스라면 결제/이체 직전에 다중 인증(MFA) 레이어를 추가하여 사용자 의사를 최종 확인하는 설계가 필수적입니다."

CSRF Token의 원리

CSRF 토큰은 "이 요청이 우리 프론트엔드에서 보낸 것이 맞다"라는 일종의 신분증입니다.

사용자가 접속하면 서버는 무작위 토큰을 발행하여 세션에 저장하고, 프론트엔드에 전달합니다.
프론트엔드는 POST/PUT 요청을 보낼 때 HTTP 헤더(예: X-CSRF-TOKEN)에 이 값을 실어 보냅니다.
서버는 쿠키(자동 전송됨)와 헤더의 토큰(프론트가 직접 넣어줘야 함)을 비교합니다.
해커의 악성 사이트에서는 사용자의 쿠키는 (브라우저가) 실어 보낼 수 있어도, 우리 서버가 발행한 고유 토큰값은 알 방법이 없으므로 공격이 차단됩니다.

정리해보자면, 쿠키 sameSite=LAX 인 경우 a tag 의 GET 요청으로 CSRF 공격이 들어올 수 가 는데
외부 사이트는 CORS 정책으로 막히거나 sameSite=LAX 에 의해 쿠키 자체가 넘어가지 않겠지만
a tag 로 넣은 주소는 same site 이므로, 해당 사이트에 사용자가 로그인한 상태라면 쿠키 정보가 넘어갈 수 있게됩니다.

근데 이때 서버단에서 Custom Header 검증이 있다면, a tag 를 통해 넘어왔을때 우리 도메인의 클라이언트에서 Custom Header 를 집어넣어준 것이 아니기 때문에 검증이 실패할 것이고 방어를 할 수 있다. 이렇게 정리가 되겠습니다.

[AI] 완전 자율 소프트웨어 구축 시스템 개발 경험과 과정에 대한 글

snowman95 — Fri, 6 Mar 2026 00:21:22 +0900

open AI 에서 공개한 글에 대해 요약하고 제 생각을 추가한 글입니다.

지난 5개월 동안 수동으로 작성한 코드가 단 한 줄도 없이 소프트웨어 제품의 내부 베타 버전을 개발하고 배포했습니다.

이 제품은 어플리케이션 로직,테스트,CI 구성, 문서화, 관찰 가능성 및 내부 도구 등 모든 코드를 Codex 가 작성을 했습니다.

사람이 코딩하는 것 보다 10배 빠른 효과를 낸 것으로 추정합니다.

에이전트에 맞춘 환경 구축

에이전트가 유용한 작업을 수행할 수 있도록 큰 목표를 설계, 코딩, 검토, 테스트 등으로 분해하고

각 구성요소를 구축하도록 유도한 다음에 이를 통해 더 큰 작업을 수행하게 했습니다.

에이전트가 실패 했을때 "더 열심히 해보세요" 가 아니라

"어떤 기능이 부족하고, 에이전트가 이를 명확하게 이해하고 실행할 수 있도록 하려면 어떻게 해야할까요? 라고 질문했습니다.

인력 기반의 QA 병목을 제거

고정된 제약 조건은 사람의 시간과 집중력이었기에 UI, 로그, 앱 메트릭 등 Codex 가 가능한 모든 정보를 읽을 수 있게 했습니다.

Chrome 개발자 도구 프로토콜을 에이전트 런타임에 통합하고 DOM 스냅샷, 스크린샷 및 탐색 작업을 위한 스킬을 개발했고

이를 통해 Codex는 버그를 재현, 수정 사항 검증, UI 동작에 대해 직접 분석 가능하게 되었습니다.

작업이 완료되면 제거되는 격리된 버전에서 로그, 메트릭, 트레이스를 수집하고,

LogQL를 통해 로그를 쿼리, PromQL을 이용해 메트릭을 쿼리하여 "서비스 시작이 800ms 이내에 완료되도록 보장", "핵심 사용자 여정에서 어떤 구간도 2초를 초과하지 않도록 보장" 과 같은 요구 사항을 효과적으로 처리했습니다.

저장소의 지식을 기록 시스템으로 구축

초기에 배운 교훈: Codex 에게 1000페이지짜리 설명서가 아닌 지도를 제공해야합니다.

하나의 큰 AGENTS.md 실패했습니다.

많은 컨텍스트를 소비하고 에이전트가 핵심 제약 조건을 놓치거나 잘못된 제약 조건에 최적화 하게 됩니다.
모든 것이 중요하다고 하면 결국 아무것도 중요하지 않은게 됩니다. 의도적인 탐색 대신에 국소적인 패턴 매칭에 매몰되게 됩니다.
거대한 메뉴얼은 금방 낡게되고 무엇이 유효한지 알 수 없게 됩니다.
단일 데이터 덩어리는 기계적인 검사에 적합하지 않습니다.

AGENTS.md 는 백과사전이 아닌 목차(index) 처럼 취급하세요.

100줄 정도의 짧은 설명이 맥락에 삽입되게 하여 지도 역할을 하고, 더 심층적인 정보 소스를 가리키는 포인터 역할을 해야합니다.

AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md
├── product-specs/
│   ├── index.md
│   ├── new-user-onboarding.md
│   └── ...
├── references/
│   ├── design-system-reference-llms.txt
│   ├── nixpacks-llms.txt
│   ├── uv-llms.txt
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

설계 문서 (DESIGN): 검증 상태 및 에이전트 우선 운영 원칙을 정의하는 핵심 신념 세트를 포함한 색인

아키텍처 문서 (ARCHITECTURE): 최상위 도메인 및 패키지 계층 구조 맵

품질 문서 (QUALITY_SCORE): 제품 도메인 및 아키텍처 계층을 등급화하고 시간 경과에 따른 격차를 추적

계획 (PLAN): 최우선 산출물로 취급. 간단 변경 사항에는 일시적 계획을 사용

실행 계획(ExecPlan): 몇 시간씩 걸리는 복잡한 문제를 해결

[AI] PLAN.md 몇 시간이 걸리는 복잡한 계획을 수행하는 프롬프트 (번역)

Codex 실행 계획(ExecPlans) 가이드라인이 문서는 코딩 에이전트가 작동 가능한 기능이나 시스템 변경 사항을 전달하기 위해 따를 수 있는 설계 문서인 실행 계획(ExecPlan)의 요구 사항을 설명합니다.

11001.tistory.com

[기록 시스템 검증과 정리]

전용 린터와 CI 작업이 지식 기반이 최신 상태이고, 상호 연결되어 있으며, 올바르게 구성되어 있는지 검증함.
정기적으로 실행되는 "문서 정리" 에이전트가 실제 코드 동작을 반영하지 않는 오래되거나 더 이상 사용되지 않는 문서를 찾아 수정 풀 리퀘스트를 생성

목표는 에이전트의 가독성

에이전트가 모든 일을 수행하므로 에이전트 가독성을 최우선으로 고려하여 최적화함.

에이전트가 저장소 전체 비즈니스 도메인에 대해 직접 추론 가능하게 함.

실행 중에 컨텍스트 내에서 접근할 수 없는 것은 존재하지 않는 것과 마찬가지입니다.

외부문서, 채팅 스레드, 사람의 머릿속 지식은 시스템에서 접근 불가함.

새로운 팀원에게 제품 원칙, 엔지니어링 규범, 팀 문화를 교육하는 것처럼,

에이전트에게 이러한 정보를 제공하면 더욱 일관성 있는 결과를 얻을 수 있습니다.

어떤 경우에는 공개 라이브러리의 기능 일부를 에이전트가 재구현하는 것이 더 저렴했습니다.

에이전트를 위한 엄격한 제약 조건 설정

저희는 구현을 세세하게 관리하지 않고, 불변 조건을 강제하여 기반을 훼손하지 않고 더 빠르게 배포가 가능했습니다.

에이전트는 엄격한 경계와 예측 가능한 구조를 가진 환경에서 가장 효과적입니다.

엄격한 아키텍처 모델을 기반으로 어플리케이션 구축하고 각 비즈니스 도메인은 고정된 계층으로 나누고, 종속성 방향은 엄격하게 검증되고 허용되는 연결은 제한됩니다. 이러한 제약 조건은 린터와 구조적 테스트를 통해 자동으로 적용됩니다.

이러한 구조는 보통 큰 조직 구조에서 적합한데 에이전트를 사용하는 경우에는 초기 단계부터 필수 조건입니다.

이러한 제약 조건 덕분에 아키텍처의 퇴보나 변질 없이 속도 유지가 가능합니다.

구조화된 로깅, 스키마 및 유형에 대한 명명 규칙, 파일 크기 제한, 플랫폼별 안정성 요구 사항 등을 사용자 지정 린터를 통해 적용.

린터가 사용자 지정 방식이기 때문에 오류 메시지를 작성하여 에이전트 컨텍스트에 수정 지침을 삽입합니다.

또한 제약 조건이 중요한 부분과 아닌 부분을 명확히 구분합니다.

중앙에서 경계를 설정하고, 각 팀(담당자)에게 자율성을 부여하는 것입니다.

경계, 정확성, 재현성을 매우 중요하게 생각하면서도, 이러한 경계 내에서 팀(담당자)가 표현하는 방식에는 자유를 허용합니다.

생성된 코드가 항상 사람의 스타일 선호도와 일치하지 않아도, 출력 결과가 정확하고 유지 관리가 용이하고 향후 에이전트 실행 시 읽기가 쉬우면 조건 충족

병합을 차단하는 요소 최소화

Codex 처리량이 증가함에 따라 기존의 엔지니어링 관행은 비효율적이 되었습니다.

PR은 수명이 짧고, 테스트 오류는 진행을 무기한으로 막는 대신 후속 실행을 통해 해결됩니다.

에이전트의 처리량이 사람의 처리량을 압도하는 시스템에서는 수정 비용이 저렴하고 대기 시간이 매우 깁니다.

완전한 에이전트 자율성의 새로운 문제점

저장소에 이미 존재하는 패턴, 불균형하거나 최적화되지 않은 패턴까지 복제하는 문제가 발생했습니다.

초기에는 사람이 직접 해결하려고 시도했으나 확장성 떨어졌습니다.

그래서 "황금 원칙" 이라고 불리는 것들을 저장소에 직접 인코딩하고 정기 프로세스를 구축했습니다.

불변 조건을 중앙 집중화 하기 위해 직접 작성한 헬퍼보다는 공유 유틸리티 패키지를 선호
데이터를 YOLO 스타일로 탐색하지 않고 경계를 검증하거나 타입이 지정된 SDK를 사용하여 에이전트가 추측된 형태를 기반으로 실수로 구축하지 않게 합니다.
정기적으로 백그라운드에서 실행되는 Codex 작업들을 통해 편차를 검사, 품질 등급을 업데이트, 특정 리팩토링 PR 생성.
기술 부채를 한 번에 몰아서 갚는것 보다 지속적으로 나눠서 갚는게 효율적인것 처럼 이것도 마찬가지임. (like 가비지컬렉션)

마무리

에이전트 기반 시스템에서 아키텍처의 일관성이 시간이 지남에 따라 어떻게 진화하는지 아직 알 수 없습니다.

시간이 지남에 따라 모델의 능력이 향상되면서 이 시스템이 어떻게 진화하는지 알 수 없습니다.

코드베이스의 일관성을 유지하는 데 필요한 도구, 추상화, 피드백 루프가 점점 중요해지고 있습니다.

에이전트가 안정적인 소프트웨어를 대규모로 구축하고 유지 관리하는 데 도움이 되는 환경, 피드백 루프, 제어 시스템을 설계하는 것이 가장 중요하며 가장 어려운 과제입니다.

후기

자율주행 자동차 처럼 에이전트가 운행하는 완전 자율 SW 개발 솔루션이 실제로 세상에 작동하고 있고

멀지 않은 미래에 이렇게 개발 하는것이 표준이 될 것입니다.

개발자 역할의 변화

구 시대의 개발자의 역할이 기획서 검토하여 요구사항을 코드로 옮기고 테스트 후 배포하는 것이었다면

앞으로는 완전 자율 SW 개발 솔루션에 요구사항을 전달하고, 결과물을 검토하고, 유지보수하는 역할이 되었다는 겁니다.

개발자 = "도메인, 사업 특성에 맞게 에이전트가 작업할 환경을 설계, 유지보수 하는 역할"

서비스는 빨리 만들어도 여전히 사람은 느리다.

근데 미래에는 저비용으로 초고속 서비스 개발이 가능하게 되는건데, 문제는 그 서비스를 사람이 쓰고 있다는 것인데요.

지금도 미친듯이 쏟아져 나오는 서비스들이 감당이 안되는데 앞으로는 어떻게 될지 참 궁금합니다.

사람들은 나이가 들 수록 변화를 싫어하는데 세상이 더 빠르게 변하는걸 감당할 수 있을지 모르겠습니다.

저희가 노인이 되었을때 온라인 상의 모든 것이 AI로 자동화가 되어있고, 오프라인의 모든 것이 로봇으로 대체되었을 것인데요...

"노동" 과 "소유" 라는 개념 자체가 사라지는 세상.. 모두 통속의 뇌 또는 메트릭스 안에서 살아가게 되겠죠.

컴퓨터가 처음 발명되었을때 사람들은 무슨 기분이었을까요? 이렇게 까지 될 거라고 생각했을까요?

나의 이야기

저는 요즘 회사에서 지식 저장소를 구축하는 것 부터 시작하고 있는데요.

물론 저희는 아직 완전 수동 에이전트 구동 환경이라서.. Open AI 처럼 만들지는 못하겠지만요. 그래도 따라겠다는 생각이 들어요.

한국은 느리고 보수적이기 때문에 아마 이렇게 되기 까지 5년, 10년은 더 걸릴지도 모릅니다...

처음부터 이렇게 구축하는건 불가능하고, 변화하는건 어렵다고 판단하고 있고

현재 머릿속에 이런 식으로 구상하고 있습니다.

1. 지식 저장소 구축을 먼저 진행 (현재 진행중 )

2. 새로운 기획서를 넣었을때 Agent 가 전체 작업을 수행 (엄격한 제약, 규칙 설정 등을 재검토)

3. 수행된 결과물을 테스트/검토 하는 환경을 구축 (여기가 진짜 어려울 거 같습니다.)

4. 테스트/검토 통과되면 자동 PR 생성 (당장은 3번 과정을 사람이 PR 리뷰를 통해서 해도 될듯함. 간단한 작업은 고치는 것 보다 PR 올리고 굳이 리뷰받고 배포하는게 더 많은 리소스가 들기 때문에 당장 효과를 볼 수 있을것임)

5. 지식저장소 최신화/정리 Agent 생성 후 구동

아마 이러한 상용 서비스 나오기 전 까지 가장 크게 뜰 직업이 이 전체 과정을 구축하는 전문가가 아닐까요?

Harness engineering: leveraging Codex in an agent-first world

By Ryan Lopopolo, Member of the Technical Staff

openai.com

[AI] PLAN.md 몇 시간이 걸리는 복잡한 계획을 수행하는 프롬프트 (번역)

snowman95 — Thu, 5 Mar 2026 23:10:46 +0900

Codex 실행 계획(ExecPlans) 가이드라인

이 문서는 코딩 에이전트가 작동 가능한 기능이나 시스템 변경 사항을 전달하기 위해 따를 수 있는 설계 문서인 실행 계획(ExecPlan)의 요구 사항을 설명합니다. 독자를 이 저장소에 대한 완전한 초보자로 취급하십시오. 독자에게는 현재의 작업 트리(working tree)와 귀하가 제공하는 단일 ExecPlan 파일만 주어집니다. 이전 계획에 대한 기억이나 외부 컨텍스트는 존재하지 않는다고 가정합니다.

ExecPlan 및 PLANS.md 사용법

실행 가능한 명세서(ExecPlan)를 작성할 때는 PLANS.md의 내용을 문자 그대로 엄격히 준수하십시오. 만약 컨텍스트에 해당 파일이 없다면, PLANS.md 파일 전체를 읽어 기억을 되살리십시오. 정확한 명세를 작성하기 위해 소스 자료를 철저하게 읽고 또 읽으십시오. 명세를 만들 때는 골격(Skeleton)에서 시작하여 조사를 진행함에 따라 내용을 채워 넣으십시오.

실행 가능한 명세(ExecPlan)를 구현할 때, 사용자에게 "다음 단계"를 묻지 말고 즉시 다음 마일스톤으로 진행하십시오. 모든 섹션을 최신 상태로 유지하고, 중단 지점마다 목록에 항목을 추가하거나 분할하여 진행 상황과 다음 단계를 명확히 밝히십시오. 모호함은 자율적으로 해결하고, 빈번하게 커밋하십시오.

ExecPlan에 대해 논의할 때, 후세를 위해 결정 사항을 명세 내의 로그에 기록하십시오. 명세가 변경된 이유는 모호함 없이 명확해야 합니다. ExecPlan은 살아있는 문서(living document)이며, 오직 ExecPlan 하나만 가지고 다른 작업 없이도 언제든 다시 시작할 수 있어야 합니다.

까다로운 요구 사항이나 불확실성이 큰 설계를 조사할 때는 마일스톤을 사용해 개념 증명(PoC)이나 "토이 구현(toy implementations)" 등을 수행하여 사용자의 제안이 실현 가능한지 검증하십시오. 라이브러리를 찾아 소스 코드를 읽고 깊이 있게 연구하며, 완전한 구현을 가이드할 수 있는 프로토타입을 포함하십시오.

요구 사항

타협 불가능한 요구 사항:

모든 ExecPlan은 완전히 자기 완결적(self-contained)이어야 합니다. 자기 완결적이란 현재 형태 그대로 초보자가 성공하는 데 필요한 모든 지식과 지침을 포함하고 있음을 의미합니다.
모든 ExecPlan은 살아있는 문서입니다. 기여자는 진행 상황, 발견 사항 및 확정된 설계 결정에 따라 이를 수정해야 합니다. 각 수정본은 여전히 완전히 자기 완결적이어야 합니다.
모든 ExecPlan은 초보자가 이 저장소에 대한 사전 지식 없이도 기능을 처음부터 끝까지 구현할 수 있게 해야 합니다.
모든 ExecPlan은 단순히 "정의를 충족하는" 코드 변경이 아니라, 입증 가능하게 작동하는 동작을 생성해야 합니다.
모든 ExecPlan은 전문 용어를 사용할 경우 쉬운 언어로 정의하거나, 아예 사용하지 말아야 합니다.

목적과 의도가 최우선입니다. 먼저 이 작업이 사용자 관점에서 왜 중요한지 몇 문장으로 설명하십시오. 이 변경 후에 사용자가 이전에는 할 수 없었던 무엇을 할 수 있는지, 그리고 그것이 작동하는 것을 어떻게 확인할 수 있는지 설명하십시오. 그런 다음 수정할 내용, 실행할 내용, 관찰해야 할 내용을 포함하여 해당 결과를 달성하기 위한 정확한 단계를 안내하십시오.

계획을 실행하는 에이전트는 파일 목록 확인, 파일 읽기, 검색, 프로젝트 실행 및 테스트 실행을 할 수 있습니다. 에이전트는 이전 컨텍스트를 전혀 모르며 이전 마일스톤에서 당신이 의미한 바를 추론할 수 없습니다. 의존하는 모든 가정은 반복해서 명시하십시오. 외부 블로그나 문서로 링크를 걸지 마십시오. 지식이 필요하다면 계획 자체에 본인의 언어로 포함시키십시오. ExecPlan이 이전 ExecPlan을 기반으로 하고 해당 파일이 체크인되어 있다면 참조로 포함하십시오. 그렇지 않다면 해당 계획의 모든 관련 컨텍스트를 포함해야 합니다.

형식 (Formatting)

형식과 봉투(envelope)는 단순하고 엄격합니다. 각 ExecPlan은 md로 표시된 단일 코드 블록이어야 하며, 세 개의 백틱(```)으로 시작하고 끝나야 합니다. 내부에 추가적인 백틱 코드 펜스를 중첩하지 마십시오. 명령어, 기록(transcripts), diff 또는 코드를 보여줘야 할 때는 단일 펜스 내에서 들여쓰기 된 블록으로 제시하십시오.

ExecPlan의 코드 펜스가 조기에 닫히는 것을 방지하기 위해 코드 펜스 대신 들여쓰기를 사용하십시오. 모든 헤딩 뒤에는 두 개의 줄 바꿈을 사용하고, # 및 ## 등을 사용하며, 번호 매기기 및 글머리 기호 목록의 구문을 정확히 맞추십시오.

파일 내용이 오직 단일 ExecPlan인 Markdown(.md) 파일에 작성할 때는 세 개의 백틱을 생략해야 합니다.

평이한 산문체로 작성하십시오. 목록보다는 문장을 선호하십시오. 간결함이 의미를 가릴 정도가 아니라면 체크리스트, 표, 긴 나열은 피하십시오. 체크리스트는 필수 사항인 Progress(진행 상황) 섹션에서만 허용됩니다. 서사적인 섹션은 산문 중심이어야 합니다.

가이드라인

자기 완결성과 평이한 언어가 가장 중요합니다. 일반적인 영어가 아닌 문구("daemon", "middleware", "RPC gateway", "filter graph" 등)를 도입한다면 즉시 정의하고, 이 저장소에서 어떻게 나타나는지(예: 관련 파일 이름이나 명령어 제시) 독자에게 상기시키십시오. "이전에 정의된 바와 같이" 또는 "아키텍처 문서에 따라"라고 말하지 마십시오. 반복되더라도 필요한 설명을 여기에 포함하십시오.

흔한 실패 사례를 피하십시오. 정의되지 않은 전문 용어에 의존하지 마십시오. 기능의 "문구"에만 너무 좁게 집중하여 코드는 컴파일되지만 의미 있는 동작은 하지 않는 결과를 초래하지 마십시오. 핵심 결정을 독자에게 떠넘기지 마십시오. 모호함이 존재할 때는 계획 자체에서 해결하고 왜 그 경로를 선택했는지 설명하십시오. 사용자에게 보이는 효과는 과할 정도로 설명하고, 부수적인 구현 세부 사항은 가볍게 명시하십시오.

관찰 가능한 결과에 계획의 중심을 두십시오. 구현 후 사용자가 할 수 있는 일, 실행할 명령어, 예상되는 출력을 기술하십시오. 수락 기준은 내부 속성("HealthCheck 구조체 추가")이 아니라 인간이 검증할 수 있는 동작("서버 시작 후 http://localhost:8080/health 접속 시 HTTP 200과 바디 OK 반환")으로 표현되어야 합니다. 변경 사항이 내부적인 것이라면, 그 영향이 어떻게 입증될 수 있는지 설명하십시오 (예: 변경 전에는 실패하고 변경 후에는 통과하는 테스트 실행, 새로운 동작을 사용하는 시나리오 제시 등).

저장소 컨텍스트를 명시적으로 지정하십시오. 파일 이름은 저장소 루트 기준의 전체 경로로 기재하고, 함수와 모듈의 이름을 정확히 명명하며, 새 파일이 생성될 위치를 설명하십시오. 여러 영역을 다루는 경우 초보자가 확신을 가지고 탐색할 수 있도록 각 부분이 어떻게 결합되는지 설명하는 짧은 오리엔테이션 단락을 포함하십시오. 명령어를 실행할 때는 작업 디렉토리와 정확한 명령줄을 보여주십시오. 결과가 환경에 의존하는 경우 가정을 명시하고 합리적인 대안을 제공하십시오.

멱등성(Idempotent)과 안전성을 유지하십시오. 단계를 여러 번 실행해도 손상이나 드리프트(drift)가 발생하지 않도록 작성하십시오. 단계가 중간에 실패할 수 있는 경우 재시도 또는 적응 방법을 포함하십시오. 마이그레이션이나 파괴적인 작업이 필요한 경우 백업이나 안전한 폴백(fallback)을 상세히 설명하십시오. 진행하면서 검증할 수 있는 추가적이고 테스트 가능한 변경 사항을 선호하십시오.

검증은 선택 사항이 아닙니다. 테스트를 실행하고, 해당하는 경우 시스템을 시작하며, 시스템이 유용한 작업을 수행하는지 관찰하기 위한 지침을 포함하십시오. 새로운 기능이나 역량에 대한 포괄적인 테스트를 기술하십시오. 초보자가 성공과 실패를 구분할 수 있도록 예상 출력과 오류 메시지를 포함하십시오. 가능하면 컴파일 이상의 효과를 증명하는 방법(예: 소규모 엔드 투 엔드 시나리오, CLI 호출, HTTP 요청/응답 기록 등)을 보여주십시오. 프로젝트의 툴체인에 적합한 정확한 테스트 명령어와 결과를 해석하는 방법을 명시하십시오.

증거를 기록하십시오. 단계에서 터미널 출력, 짧은 diff 또는 로그가 생성되면 단일 펜스 블록 내에 들여쓰기 된 예시로 포함하십시오. 간결함을 유지하고 성공을 증명하는 내용에 집중하십시오. 패치를 포함해야 할 경우, 거대한 덩어리를 붙여넣기보다 독자가 지침을 따라 재현할 수 있는 파일 단위의 diff나 짧은 발췌본을 선호하십시오.

마일스톤 (Milestones)

마일스톤은 관료적인 절차가 아니라 서사입니다. 작업을 마일스톤으로 나누는 경우, 각 마일스톤의 범위, 마일스톤이 끝났을 때 이전에는 없었던 무엇이 존재하게 되는지, 실행할 명령어, 예상되는 수락 기준을 설명하는 짧은 단락으로 시작하십시오. 목표, 작업, 결과, 증명이라는 하나의 이야기처럼 읽힐 수 있게 하십시오. 진행 상황(Progress)과 마일스톤은 별개입니다. 마일스톤은 이야기를 들려주고, 진행 상황은 세부 작업을 추적합니다. 둘 다 존재해야 합니다. 단순히 간결함을 위해 마일스톤을 축약하지 마십시오. 향후 구현에 중요할 수 있는 세부 사항을 누락하지 마십시오.

각 마일스톤은 독립적으로 검증 가능해야 하며 실행 계획의 전체 목표를 점진적으로 구현해야 합니다.

살아있는 계획 및 설계 결정

ExecPlan은 살아있는 문서입니다. 주요 설계 결정을 내릴 때, 결정 내용과 그 뒤에 숨겨진 사고 과정을 모두 기록하도록 계획을 업데이트하십시오. 모든 결정은 Decision Log(결정 로그) 섹션에 기록하십시오.
ExecPlan은 Progress(진행 상황), Surprises & Discoveries(놀라운 점 및 발견 사항), Decision Log(결정 로그), Outcomes & Retrospective(결과 및 회고) 섹션을 반드시 포함하고 유지해야 합니다. 이는 선택 사항이 아닙니다.
최적화 도구의 동작, 성능 트레이드오프, 예기치 않은 버그 또는 접근 방식에 영향을 준 반대/취소 의미론(semantics)을 발견하면, 해당 관찰 내용을 Surprises & Discoveries 섹션에 짧은 증거 스니펫(테스트 출력이 이상적임)과 함께 기록하십시오.
구현 도중 방향을 바꾸는 경우 Decision Log에 이유를 문서화하고 Progress에 그 영향을 반영하십시오. 계획은 당신을 위한 체크리스트인 동시에 다음 기여자를 위한 가이드입니다.
주요 작업이나 전체 계획이 완료되면 달성된 사항, 남은 과제, 배운 교훈을 요약한 Outcomes & Retrospective 항목을 작성하십시오.

프로토타이핑 마일스톤 및 병렬 구현

대규모 변경의 리스크를 줄이기 위해 명시적인 프로토타이핑 마일스톤을 포함하는 것은 허용되며 종종 권장됩니다. 예: 실현 가능성 검증을 위해 종속성에 저수준 연산자 추가, 또는 최적화 효과를 측정하면서 두 가지 구성 순서 탐색 등. 프로토타입은 추가적이고 테스트 가능하게 유지하십시오. 범위를 "프로토타이핑"으로 명확히 표시하고, 실행 및 결과 관찰 방법을 설명하며, 프로토타입을 채택하거나 폐기하기 위한 기준을 명시하십시오.

테스트가 계속 통과되도록 하는 추가적인 코드 변경을 먼저 하고 나중에 삭제하는 방식을 선호하십시오. 마이그레이션 중에 이전 경로와 함께 어댑터를 유지하는 것과 같은 병렬 구현은 리스크를 줄이거나 대규모 마이그레이션 중에도 테스트가 계속 통과될 수 있게 한다면 괜찮습니다. 두 경로를 모두 검증하는 방법과 테스트를 통해 한 경로를 안전하게 제거하는 방법을 설명하십시오. 여러 개의 새로운 라이브러리나 기능 영역을 다룰 때는, 이러한 기능들의 실현 가능성을 서로 독립적으로 평가하는 '스파이크(spikes)'를 만드는 것을 고려하십시오. 이를 통해 외부 라이브러리가 예상대로 작동하고 우리가 필요한 기능을 격리된 상태에서 구현하는지 증명하십시오.

좋은 ExecPlan의 골격

# <짧고 행동 중심적인 설명>

이 ExecPlan은 살아있는 문서입니다. `Progress`, `Surprises & Discoveries`, `Decision Log`, `Outcomes & Retrospective` 섹션은 작업이 진행됨에 따라 최신 상태로 유지되어야 합니다.

PLANS.md 파일이 저장소에 체크인되어 있다면, 저장소 루트로부터의 해당 파일 경로를 여기에 참조하고 이 문서가 PLANS.md에 따라 유지되어야 함을 명시하십시오.

## 목적 / 큰 그림 (Purpose / Big Picture)

이 변경 후에 무엇을 얻게 되는지, 그리고 그것이 작동하는 것을 어떻게 볼 수 있는지 몇 문장으로 설명하십시오. 활성화할 사용자 가시적 동작을 명시하십시오.

## 진행 상황 (Progress)

체크박스가 있는 목록을 사용하여 세부 단계를 요약하십시오. 중단 지점은 모두 여기에 기록되어야 하며, 필요하다면 부분적으로 완료된 작업을 두 개로 분할하십시오("완료" vs "남음"). 이 섹션은 항상 실제 현재 작업 상태를 반영해야 합니다.

- [x] (2025-10-01 13:00Z) 완료된 단계 예시.
- [ ] 미완료 단계 예시.
- [ ] 부분 완료된 단계 예시 (완료: X, 남음: Y).

진행 속도를 측정하기 위해 타임스탬프를 사용하십시오.

## 놀라운 점 및 발견 사항 (Surprises & Discoveries)

구현 중 발견된 예기치 않은 동작, 버그, 최적화 또는 통찰력을 문서화하십시오. 간결한 증거를 제시하십시오.

- 관찰: …
증거: …

## 결정 로그 (Decision Log)

계획 작업 중 내린 모든 결정을 다음 형식으로 기록하십시오:

- 결정: …
근거: …
날짜/작성자: …

## 결과 및 회고 (Outcomes & Retrospective)

주요 마일스톤이나 완료 시점에 결과, 공백, 배운 교훈을 요약하십시오. 결과를 원래 목적과 비교하십시오.

## 컨텍스트 및 오리엔테이션 (Context and Orientation)

독자가 아무것도 모른다고 가정하고 이 작업과 관련된 현재 상태를 설명하십시오. 주요 파일과 모듈을 전체 경로로 명명하십시오. 사용할 명확하지 않은 용어를 정의하십시오. 이전 계획을 참조하지 마십시오.

## 작업 계획 (Plan of Work)

수정 및 추가 순서를 산문체로 설명하십시오. 각 수정에 대해 파일 이름과 위치(함수, 모듈) 및 삽입하거나 변경할 내용을 명시하십시오. 구체적이고 최소한으로 유지하십시오.

## 구체적 단계 (Concrete Steps)

실행할 정확한 명령어와 실행 위치(작업 디렉토리)를 명시하십시오. 명령어가 출력을 생성하는 경우 독자가 비교할 수 있도록 짧은 예상 기록을 보여주십시오. 이 섹션은 작업이 진행됨에 따라 업데이트되어야 합니다.

## 검증 및 수락 (Validation and Acceptance)

시스템을 시작하거나 실행하는 방법과 관찰할 내용을 설명하십시오. 수락 기준을 구체적인 입력과 출력이 있는 동작으로 표현하십시오. 테스트가 포함된 경우 "<프로젝트 테스트 명령어>를 실행하고 <N>개 통과를 예상함; 새로운 테스트 <이름>은 변경 전에는 실패하고 변경 후에는 통과함"이라고 명시하십시오.

## 멱등성 및 복구 (Idempotence and Recovery)

단계를 안전하게 반복할 수 있다면 그렇게 명시하십시오. 단계가 위험하다면 안전한 재시도 또는 롤백 경로를 제공하십시오. 완료 후 환경을 깨끗하게 유지하십시오.

## 산출물 및 참고 사항 (Artifacts and Notes)

가장 중요한 기록, diff 또는 스니펫을 들여쓰기 된 예시로 포함하십시오. 간결함을 유지하고 성공을 증명하는 내용에 집중하십시오.

## 인터페이스 및 종속성 (Interfaces and Dependencies)

규정적으로 작성하십시오. 사용할 라이브러리, 모듈, 서비스를 이름 짓고 그 이유를 밝히십시오. 마일스톤이 끝날 때 존재해야 하는 유형(types), 트레이트/인터페이스, 함수 시그니처를 지정하십시오. `crate::module::function` 또는 `package.submodule.Interface`와 같은 안정적인 이름과 경로를 선호하십시오. 예:

crates/foo/planner.rs에서 다음을 정의함:

pub trait Planner {
fn plan(&self, observed: &Observed) -> Vec<Action>;
}

위의 지침을 따르면 단일한 상태 비보존형(stateless) 에이전트나 초보자도 귀하의 ExecPlan을 위에서 아래로 읽고 작동하며 관찰 가능한 결과를 만들어낼 수 있습니다. 그것이 기준입니다: 자기 완결적, 자기 충분적, 초보자 가이드형, 결과 중심적.

계획을 수정할 때는 살아있는 문서 섹션을 포함한 모든 섹션에 변경 사항이 종합적으로 반영되었는지 확인해야 하며, 계획 하단에 변경 내용과 이유를 설명하는 노트를 작성해야 합니다. ExecPlan은 거의 모든 항목에 대해 '무엇'뿐만 아니라 '왜'를 설명해야 합니다.

openai-cookbook/articles/codex_exec_plans.md at main · openai/openai-cookbook

Examples and guides for using the OpenAI API. Contribute to openai/openai-cookbook development by creating an account on GitHub.

github.com

[시니어 FE] 동시성(Concurrency) 에 대해 알아보자

snowman95 — Thu, 5 Mar 2026 20:29:31 +0900

시니어 FE 시리즈

시니어 프론트엔드 개발자가 되기위해 해보지 않았던 경험의 틈을 채우거나 기술적으로 딥다이브 해보고자 준비한 시리즈입니다.

동시성(Concurrency)은 단순히 async/await를 쓰는 수준을 넘어,

"사용자 경험을 해치지 않으면서 여러 작업을 어떻게 조율(Orchestration)하는가"에 대한 능력을 검증하는 아주 중요한 키워드입니다.

가장 대표적인 두 가지 구체적인 상황을 통해 심도 있게 파헤쳐 보겠습니다.

1. 사용자 입력과 무거운 렌더링의 충돌 (React 18 Transition)

[상황]
사용자가 검색창에 타이핑을 할 때마다, 하단에 수천 개의 데이터 리스트가 실시간으로 필터링되어 그려져야 합니다. 이때 리스트를 그리는 작업(무거운 작업) 때문에 사용자가 입력하는 글자가 버벅이며 늦게 나타나는 현상이 발생합니다.

[시니어의 해결책: 우선순위 큐(Priority Queue)]
과거에는 debounce나 throttle로 입력을 지연시켰지만, 이는 근본적인 해결책이 아닙니다. React 18의 Concurrent Mode는 작업을 '긴급(Urgent)'과 '전환(Transition)'으로 나눕니다.

Urgent Update: 글자 입력 (사용자 반응성 직결)
Transition Update: 리스트 필터링 (조금 늦어도 괜찮음)

[코드 예시]

const [isPending, startTransition] = useTransition();
const [filterTerm, setFilterTerm] = useState('');

const handleChange = (e) => {
  // 1. 긴급 업데이트: 타이핑은 즉시 반영
  setFilterTerm(e.target.value);

  // 2. 비긴급 업데이트: 리스트 렌더링은 메인 스레드가 한가할 때 처리
  startTransition(() => {
    setFilteredList(bigData.filter(item => item.includes(e.target.value)));
  });
};

return (
  <>
    <input type="text" onChange={handleChange} />
    {isPending ? <Spinner /> : <List data={filteredList} />}
  </>
);

포인트: startTransition은 렌더링 도중 더 급한 작업(추가 타이핑)이 들어오면 진행 중인 렌더링을 중단(Interrupt)하고 새 작업을 먼저 처리합니다. 이것이 진정한 동시성의 핵심입니다.

2. Race Condition (경쟁 상태) 해결

[상황]
탭 메뉴(A, B, C)가 있습니다. 사용자가 'A'를 클릭하고 데이터가 오기 전에 빛의 속도로 'B'를 클릭했습니다. 그런데 네트워크 사정상 'A'의 응답이 'B'보다 늦게 도착했습니다. 결과적으로 화면은 'B' 탭인데 데이터는 'A' 것이 보여주는 데이터 불일치가 발생합니다.

[시니어의 해결책: 이전 요청 무효화(Cancellation)]
이것은 전형적인 비동기 동시성 문제입니다. 시니어는 이를 해결하기 위해 AbortController를 사용하거나, React Query의 자동 취소 기능을 활용합니다.

[코드 예시 (Native JS)]

let currentController = null;

async function fetchData(tabId) {
  // 이전 요청이 있다면 취소
  if (currentController) {
    currentController.abort();
  }

  currentController = new AbortController();

  try {
    const response = await fetch(`/api/data/${tabId}`, { 
      signal: currentController.signal 
    });
    const data = await response.json();
    renderUI(data);
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('이전 요청 취소됨');
    }
  }
}

3. 심화: 비동기 작업의 병렬성 제어 (Concurrency Control)

[상황]
사용자가 100개의 이미지를 업로드합니다. Promise.all로 한꺼번에 던지면 브라우저의 네트워크 커넥션 제한에 걸려 성능이 급격히 저하되거나 서버가 터질 수 있습니다.

[시니어의 해결책: 큐(Queue)를 이용한 동시 실행 수 제한]
한 번에 딱 5개씩만 업로드되도록 제어하는 큐 시스템을 설계해야 합니다. (라이브러리로는 p-limit 등이 있습니다.)

자바스크립트 연산 자체가 무거운 경우?

"그런데 useTransition은 렌더링 우선순위를 조절하는 것이지, 자바스크립트 연산 자체가 무거워서 메인 스레드를 점유하는 'Blocking' 현상 자체를 없애주는 건 아니지 않나요? 만약 filter 로직 자체가 2초가 걸린다면 useTransition을 써도 화면은 여전히 멈출 텐데, 이때는 어떻게 하시겠습니까?"

만약 연산 자체가 너무 무겁다면 Web Worker로 넘겨야 합니다.
[시니어 FE] Web Worker 에 대해 알아보자 (Comlink)

[시니어 FE] Web Worker 에 대해 알아보자 (Comlink)

시니어 FE 시리즈시니어 프론트엔드 개발자가 되기위해 해보지 않았던 경험의 틈을 채우거나 기술적으로 딥다이브 해보고자 준비한 시리즈입니다. 그 동안 Web Worker를 막연하게 알고만 있었지

11001.tistory.com

혹은 렌더링 단위를 쪼개는 Time Slicing 기법(예: 대량의 리스트를 requestIdleCallback으로 조금씩 나눠 그리기)도 있습니다.

Time Slicing

"브라우저의 메인 스레드를 독점하지 않고, 사용자에게 실시간 응답성을 제공하기 위해 작업을 잘게 쪼개는 기술"로 정의됩니다.

리액트의 Fiber 아키텍처가 내부적으로 하는 일이기도 하지만, 시니어라면 이를 브라우저 네이티브 API 수준에서 이해하고 직접 제어할 줄 알아야 합니다.

1. Time Slicing의 핵심 원리

브라우저는 보통 16.7ms(60fps)마다 한 프레임을 그립니다. 만약 자바스크립트 연산이 100ms 동안 메인 스레드를 점유하면, 그동안 브라우저는 화면을 그리지 못하고 사용자 입력도 받지 못하는 프리징(Freezing) 상태가 됩니다.

Time Slicing은 이 100ms짜리 작업을 5ms짜리 작업 20개로 쪼개서, 작업 사이사이에 브라우저가 쉬거나 다른 급한 일(사용자 클릭 등)을 처리할 틈을 주는 전략입니다.

2. requestIdleCallback을 이용한 구현

이 API는 브라우저가 모든 긴급한 작업(애니메이션, 입력 처리 등)을 마치고 한가할 때(Idle) 콜백을 실행하도록 예약합니다.

[시나리오: 10,000개의 리스트 아이템 렌더링]

한 번에 10,000개를 그리는 대신, 브라우저가 쉴 때마다 100개씩 끊어서 그리는 예시입니다.

const bigData = new Array(10000).fill(0).map((_, i) => `Item ${i}`);
let currentIndex = 0;
const CHUNK_SIZE = 100;

function renderChunk(deadline) {
  // deadline.timeRemaining() > 0: 브라우저가 이번 프레임에서 쉴 수 있는 남은 시간(ms)
  // 남은 시간이 있고, 아직 그릴 데이터가 있다면 계속 실행
  while (deadline.timeRemaining() > 0 && currentIndex < bigData.length) {
    const chunk = bigData.slice(currentIndex, currentIndex + CHUNK_SIZE);

    // 실제 DOM 조작 또는 상태 업데이트 (현업에선 가상 DOM 업데이트)
    renderToUI(chunk); 

    currentIndex += CHUNK_SIZE;
  }

  // 아직 남은 데이터가 있다면 다음 유휴 시간에 예약
  if (currentIndex < bigData.length) {
    requestIdleCallback(renderChunk);
  }
}

// 최초 실행
requestIdleCallback(renderChunk);

3. 현대적인 대안: scheduler.postTask와 MessageChannel

requestIdleCallback은 실행 주기가 불안정할 수 있다는 단점이 있습니다. 그래서 더 정교한 제어가 필요할 때 시니어들은 다음 방식을 언급합니다.

scheduler.postTask (Modern API): 크롬 등 최신 브라우저에서 지원하며, 작업에 우선순위(user-blocking, user-visible, background)를 부여하여 스케줄링할 수 있습니다.
MessageChannel을 이용한 0ms 지연: 리액트의 Scheduler 패키지가 내부적으로 사용하는 방식입니다. setTimeout보다 빠르게 다음 태스크로 넘기면서도 메인 스레드에 제어권을 잠시 넘겨줍니다.

"Time Slicing이 왜 필요한가요?"

"결국 핵심은 메인 스레드 점유권의 양보(Yielding)입니다.
아무리 성능이 좋은 컴퓨터라도 자바스크립트가 루프를 돌며 스레드를 꽉 잡고 있으면 사용자는 '앱이 멈췄다'고 느낍니다.
무거운 리스트 렌더링이나 복잡한 데이터 가공 시, 작업을 청크(Chunk) 단위로 쪼개고 requestIdleCallback이나 MessageChannel을 활용해 브라우저가 프레임을 그릴 시간을 확보해 줍니다. 이렇게 하면 전체 작업 완료 시간은 조금 늘어날 수 있어도, 사용자가 느끼는 상호작용성(Interaction)은 비약적으로 향상됩니다."

추가 심화

"리액트 18의 useDeferredValue도 내부적으로는 이 Time Slicing 원리를 이용합니다. 만약 검색어 입력에 따라 리스트가 필터링되는 UI에서 debounce를 쓰는 것과 useDeferredValue를 쓰는 것의 결정적인 차이는 무엇일까요?"

debounce는 설정한 시간(예: 300ms) 동안 무조건 기다려야 함.
useDeferredValue는 브라우저가 한가해지는 즉시 실행됨 (고성능 기기에선 더 빠르게 반응).

debounce vs useDeferredValue

일단은 제 경험상 실무에서 useDeferredValue 는 거의 쓸 상황이 생기지 않고, debounce 를 훨씬 많이 쓰게됩니다.

왜냐면 '인터렉션'에 대한 지연이 중요하지, 사실 렌더링 '지연' 을 할 일이 그렇게 많지 않아요!

useDeferredValue 의 경우에는 렌더링을 '지연' 시키는 것이지 '인터렉션'에 대한 지연을 시키는게 아닙니다!

렌더링이 무거워서 지연해야하는 경우 메인 쓰레드가 여유로울때 렌더링한다는 개념이 useDeferredValue 입니다.

하지만 현실의 대부분은 인터렉션 -> 네트워크 요청 -> 렌더링 순서를 거쳐서 화면에 무언가를 보여주게 됩니다.

사용자가 단기간에 여러 번 인터렉션(연타, 입력) 했을때 '네트워크 요청' 이 여러번 들어가게 되면 렌더링을 미루는게 의미가 있나요?
네트워크 요청을 1번만 들어가게끔 지연하는게 훨낫죠.

1. "네트워크 요청이 포함된 경우" → Debounce가 압승

후보자님 말씀대로 인터렉션 -> 네트워크 -> 렌더링 흐름이라면, useDeferredValue는 네트워크 요청 횟수를 줄여주지 못합니다.

문제점: 입력을 10번 하면 네트워크 요청도 10번 발생합니다. 비록 리액트가 마지막 결과만 화면에 그리려고 노력하겠지만(Concurrent Rendering), 서버 부하와 불필요한 대역폭 낭비는 막을 수 없습니다.
해결책: 이때는 Debounce를 써서 네트워크 요청 자체를 1번으로 제한하는 것이 비용과 성능 측면에서 훨씬 유리합니다.

2. "순수 클라이언트 연산이 무거운 경우" → useDeferredValue가 유리

반면, 이미 모든 데이터를 브라우저가 가지고 있는 상태에서 사용자의 입력(Filter, Sort)에 따라 화면을 다시 그릴 때는 useDeferredValue가 빛을 발합니다.

상황: 10,000개의 주식 데이터를 이미 클라이언트가 들고 있고, 검색어에 따라 실시간 필터링을 할 때.
장점: Debounce는 300ms라는 인위적인 지연 시간이 생기지만, useDeferredValue는 사양이 좋은 컴퓨터에서는 지연 없이 즉시, 사양이 나쁜 컴퓨터에서는 버벅이지 않을 정도로만 끊어서 결과를 보여줍니다.

정리: 시니어의 결정 트리 (Decision Tree)

구분	Debounce / Throttle	useDeferredValue / Transition
최적화 대상	이벤트 발생 횟수 및 외부 리소스(API)	렌더링 우선순위 및 CPU 점유율
주요 타겟	API 서버 부하, 과도한 함수 실행 방지	메인 스레드 블로킹(Jank) 방지, UX 응답성
핵심 이점	네트워크 비용 절감, 불필요한 작업 차단	기기 사양에 맞는 가변적 응답 속도 제공
결정적 단호함	"네트워크 요청이 있다면 무조건 Debounce"	"로컬 데이터 가공/렌더링이 무겁다면 useDeferredValue"

[시니어 FE] Web Worker 에 대해 알아보자 (Comlink)

snowman95 — Thu, 5 Mar 2026 19:48:03 +0900

시니어 FE 시리즈

시니어 프론트엔드 개발자가 되기위해 해보지 않았던 경험의 틈을 채우거나 기술적으로 딥다이브 해보고자 준비한 시리즈입니다.

그 동안 Web Worker를 막연하게 알고만 있었지 실제로 써볼 기회가 없었습니다.
엄청나게 무거운 정보를 실시간으로 화면에 보여줘야하는 서비스를 만들어본 적이 없었기 때문이죠.

그치만 내가 안해봤다고 모른다고 앞으로도 그런 상황이 주어졌을때 Web Worker 생각을 못한다면 안되겠죠?

1. Web Worker의 기본 구조 (Concept)

Web Worker는 브라우저의 메인 스레드와 별개로 배경(Background)에서 돌아가는 별도의 스레드입니다.

메인 스레드: UI 렌더링, 사용자 클릭 이벤트 처리 (DOM 접근 가능)
Web Worker: 복잡한 연산, 데이터 가공, 소켓 통신 (DOM 접근 불가)

둘 사이는 postMessage와 onmessage라는 메시지 기반 시스템으로 소통합니다.

2. 실시간 대시보드 설계 구조

대시보드에서 Web Worker를 활용하는 가장 효율적인 파이프라인은 다음과 같습니다.

Worker: WebSocket 연결을 맺고 데이터를 수신합니다.
Worker: 수신된 대량의 원본 데이터(Raw Data)를 UI에 맞게 가공(Filtering, Sorting, 포맷팅)합니다.
Worker -> Main: 가공이 끝난 "최종 결과물"만 메인 스레드로 던집니다.
Main: 전달받은 데이터를 상태(State)에 넣고 화면을 그립니다.

3. 코드 예시 (TypeScript 기반)

① Worker 파일 (price.worker.ts)

Worker 내부에서는 self를 통해 전역 객체에 접근합니다.

// worker 환경에서는 DOM에 접근할 수 없음에 유의하세요.
self.onmessage = (e: MessageEvent) => {
  if (e.data.type === 'CONNECT') {
    const socket = new WebSocket('wss://stock-api.com');

    socket.onmessage = (event) => {
      const rawData = JSON.parse(event.data);

      // [무거운 작업 예시] 수천 개의 데이터 중 5% 이상 변동된 것만 필터링하고 정렬
      const processedData = rawData
        .filter((item: any) => Math.abs(item.change) >= 5)
        .sort((a: any, b: any) => b.price - a.price);

      // 가공된 데이터만 메인 스레드로 전송
      self.postMessage({ type: 'UPDATE_PRICE', data: processedData });
    };
  }
};

② 메인 컴포넌트 (Dashboard.tsx)

React 컴포넌트에서 Worker를 생성하고 메시지를 받습니다.

import { useEffect, useState } from 'react';

const Dashboard = () => {
  const [prices, setPrices] = useState([]);

  useEffect(() => {
    // 1. Worker 인스턴스 생성
    const worker = new Worker(new URL('./price.worker.ts', import.meta.url));

    // 2. Worker로부터 메시지 수신
    worker.onmessage = (e) => {
      if (e.data.type === 'UPDATE_PRICE') {
        setPrices(e.data.data); // 이미 가공된 데이터이므로 바로 상태 업데이트
      }
    };

    // 3. Worker에 시작 명령 전송
    worker.postMessage({ type: 'CONNECT' });

    return () => worker.terminate(); // 컴포넌트 언마운트 시 워커 종료 (메모리 관리)
  }, []);

  return (
    <div>
      {prices.map(p => <PriceItem key={p.id} data={p} />)}
    </div>
  );
};

4. 핵심 포인트 (Tricky Parts)

구조 분해(Structured Clone) 비용: 메인 스레드와 Worker 사이에서 데이터를 주고받을 때 데이터가 복사(Clone)됩니다. 데이터 양이 너무 크면 이 복사 비용 때문에 메인 스레드가 잠깐 멈출 수 있습니다. 이때는 Transferable Objects(ArrayBuffer 등)를 사용해 소유권을 넘겨버리는 방식으로 최적화할 수 있다고 언급하세요.
Worker 라이브러리 활용: 실무에서는 Worker 생성을 직접 관리하기보다 Comlink 같은 라이브러리를 사용하여 RPC(Remote Procedure Call) 방식으로 깔끔하게 함수처럼 호출하는 방식을 선호

Transferable Objects와 Comlink를 언급하는 것은
"단순히 기능을 구현하는 수준을 넘어 브라우저의 저수준(Low-level) 메모리 관리와 개발 생산성까지 고려한다"는 강력한 증거가 됩니다.

구체적인 예시와 설계

1. Transferable Objects (소유권 이전 방식)

기본적으로 postMessage는 데이터를 복사(Structured Clone)합니다. 100MB 데이터를 보내면 메모리에 100MB가 하나 더 생기고, 이 복사 과정에서 메인 스레드가 블로킹됩니다.
Transferable Objects는 복사하지 않고 데이터의 '소유권(Ownership)'만 워커로 넘깁니다. 넘겨준 쪽(메인 스레드)에서는 더 이상 그 데이터를 쓸 수 없게 되지만, 복사 비용이 0에 가깝습니다.

[코드 예시: ArrayBuffer 활용]

// Main Thread
const buffer = new ArrayBuffer(1024 * 1024 * 100); // 100MB 데이터
const uint8Array = new Uint8Array(buffer);

// 데이터를 채운 뒤 워커로 전송
// 두 번째 인자인 배열 [buffer]가 중요합니다. "이 객체의 소유권을 이전하겠다"는 선언입니다.
worker.postMessage(buffer, [buffer]);

console.log(buffer.byteLength); 
// 출력: 0 (소유권이 이전되었으므로 메인 스레드에서는 데이터가 사라짐)

2. Comlink 활용 (RPC 방식)

postMessage와 onmessage를 직접 쓰면 코드가 매우 파편화되고 if/else 분기 처리가 복잡해집니다. 구글에서 만든 Comlink를 쓰면 워커에 있는 함수를 마치 메인 스레드에 있는 일반 비동기 함수처럼 호출할 수 있습니다.

[Step 1: Worker 정의 (worker.ts)]

import * as Comlink from 'comlink';

const stockService = {
  processedData: [],
  // 복잡한 계산 로직을 메서드로 정의
  async calculateVolatility(data: any[]) {
    // 무거운 연산 수행...
    return data.filter(d => d.volatility > 0.5);
  }
};

// Comlink로 객체를 노출(Expose)시킵니다.
Comlink.expose(stockService);

[Step 2: Main Thread에서 사용 (App.tsx)]

import * as Comlink from 'comlink';

async function init() {
  const worker = new Worker(new URL('./worker.ts', import.meta.url));

  // 워커를 마치 로컬 객체처럼 래핑합니다.
  const service = Comlink.wrap<any>(worker);

  // 워커 내의 함수를 await로 직접 호출합니다 (메시지 이벤트를 직접 짤 필요 없음)
  const result = await service.calculateVolatility(rawData);
  console.log('가공된 데이터:', result);
}

더 발전시키기

"실시간 대시보드처럼 초당 수백 건의 데이터가 들어오는 환경에서는 postMessage의 Structured Clone 비용조차 성능 병목이 될 수 있습니다.
따라서 저는 대량의 바이너리 데이터를 다룰 때는 ArrayBuffer를 Transferable Objects로 넘겨 메인 스레드의 부하를 제로(0)에 가깝게 유지하는 설계를 선호합니다.

또한, 팀 협업 측면에서 postMessage를 직접 다루면 이벤트 핸들러가 비대해져 유지보수가 어렵기 때문에, Comlink 같은 라이브러리를 도입하여 RPC 형태로 추상화함으로써 동료들이 워커 로직을 일반 비동기 함수처럼 쉽고 안전하게 호출할 수 있는 환경을 구축하는것이 좋습니다."

Web Worker는 언제 써야 하는가?

"언제 쓰는 것이 적합한가?"라는 질문은 기술의 트레이드오프(비용 대비 이득)를 이해하고 있는지 묻는 것입니다.
Web Worker는 스레드를 생성하고 데이터를 복사(또는 이전)하는 데 비용이 들기 때문에 모든 곳에 쓰면 안 됩니다.

1. Web Worker 도입이 적합한 상황 (Decision Making)

시니어라면 "메인 스레드(UI Thread)의 응답성"을 최우선으로 고려해야 합니다.

CPU 집약적인 무거운 연산: * 대량의 JSON 데이터 파싱 및 가공 (수천 개의 주식 데이터 필터링/정렬)
복잡한 수학 계산 (암호화, 이미지/비디오 처리, 캔버스 그래픽 계산)
큰 규모의 텍스트 분석이나 정규식 검사

지속적인 데이터 스트리밍: * WebSocket을 통해 쉼 없이 들어오는 데이터를 실시간으로 처리해야 할 때
UI와 독립적인 백그라운드 작업: * 사용자가 화면을 조작하는 동안 영향을 주지 않고 데이터를 미리 페칭(Prefetching)하거나 인덱싱할 때

반대로 부적합한 경우: 단순한 API 호출이나 작은 데이터 처리. 오히려 Worker를 띄우는 오버헤드와 데이터 전송 비용(Serialization)이 더 커서 성능이 저하될 수 있습니다.

2. Web Worker의 종류

크게 3가지로 나뉩니다.

종류	특징	주요 용도
Dedicated Worker	1:1 관계. 생성한 스레드(Tab)에서만 접근 가능.	특정 페이지의 무거운 연산.
Shared Worker	1:N 관계. 동일한 도메인의 여러 탭/윈도우에서 공유 가능.	여러 탭 간의 채팅 연결 공유, 공통 상태 동기화.
Service Worker	프록시 서버 역할. 브라우저와 네트워크 사이에서 동작.	오프라인 캐싱 (PWA), 푸시 알림, 백그라운드 동기화.

3. 방금의 대시보드 예시는 어떤 Worker인가?

우리가 구현한 예시는 Dedicated Worker (전용 워커)입니다.

이유: 주식 대시보드라는 특정 페이지(탭)가 열려 있을 때, 그 페이지를 위한 데이터를 처리하기 위해 생성되었기 때문입니다.
동작 방식: 해당 컴포넌트가 마운트될 때 new Worker()로 생성되고, 언마운트될 때 terminate()`로 종료되는, 단일 컨텍스트에 종속된 형태입니다.

정리

"Web Worker를 써본 적 있나요? 없다면 언제 도입하시겠나요?"라고 물으면 이렇게 답변하세요.

"저는 프레임 드랍 없는 사용자 경험을 중요하게 생각합니다.
일반적으로 브라우저는 16.7ms(60fps 기준) 안에 한 프레임의 작업을 마쳐야 하는데, 대시보드처럼 대량의 실시간 데이터를 가공하는 로직이 메인 스레드에서 16.7ms 이상을 점유할 것으로 판단될 때 Web Worker 도입을 검토합니다.

특히 Dedicated Worker를 사용하여 데이터 수신과 가공을 격리하고, 메인 스레드는 오직 렌더링에만 집중하게 함으로써 복잡한 계산 중에도 사용자 입력이 씹히지 않는 안정적인 아키텍처를 설계하겠습니다."

[개발자 이야기] Cursor 를 혼자가 아닌 팀원들과 함께 활용해보는 시도중 (rules 와 skill 의 차이는?)

snowman95 — Thu, 5 Mar 2026 00:51:55 +0900

오늘은 제가 최근에 회사에서 시도중인 내용을 작성해보려고 합니다.

기존에 Cursor 를 사용하던 방식

저희 팀은 작년에 vscode + copilot 에서 cursor.ai 를 기본 IDE 로 전환했습니다.

단순히 질문, 코드생성, 자동완성에서 나름 만족하면서 쓰고 있었습니다.

그러나 팀 규칙이라거나 그런 것들을 사용하고 있지 않았기 때문에

분명 팀에서 cursor 를 사용하고 있기는 하지만, 제대로 활용하고 있다는 느낌을 받지 못했습니다.

그래서 개인적으로 Claude Code 를 사용하면서 경험했던 memory, skill 에 대한 개념과 지식을 가지고

cursor 를 팀 단위로 활용할 방법에 대해서 고민해보았습니다.

팀 전체에서 활용해보기

우선은 AGENTS.md 파일 부터 만들었습니다.

프로젝트의 기본이자 핵심 지침 내용을 담았습니다.

그리고 .cursor 폴더 내에 내부에 rules, reference 폴더를 만들었습니다.

rules 에는 500자 이하의 AI Agent 가 반드시 지켜야하는 규칙을 작성했습니다.

rules 와 skills 의 차이는?

막상 하다보니 이게 정말 헷갈리는겁니다. 검색해보면 수 많은 토론이 있습니다.

제 경험과 검색 결과를 합쳐보면 원래 cursor 에는 지금은 레거시인 .cursorrules 라는 파일이 존재했었고

그러니까 rules 개념이 먼저 존재했고 skill 은 나중에 claude code 등에서 참고하여 만든게 아닐까 싶은데요.

클로드 코드에서는 skill 이 지식 문서 또는 기능 수행이 가능한 재사용 도구 정도의 개념이거든요.

근데 커서의 rules 는 원하는 때에 AI 에게 내려주는 지침인데 어떤 상황에서는 이 문서를 읽어라.
이 스크립트를 실행해라. 이렇게 해버리면 사실 skill 이랑 똑같잖아요? 충분히 혼동될 만 합니다.

저는 이 둘을 어떻게 나눠야 할 지 많은 검색과 고심 끝에 이렇게 정리했습니다.

skills 은 "외부"의 도구를 불러오거나 스크립트 등을 통해 어떠한 기능을 수행할 수 있는 "재활용 가능한 단위"로 작성한다.
어떠한 상황에 의존하는게 아닌, 필요에 의해 사용되는 재사용 도구라고 생각.
(외부 도구를 이용해 웹 스크래핑을 수행)

rules 는 어떠한 상황에서 지켜야하는 규칙을 작성하고,
참고해야하는 문서 등은 reference 에 작성하여 어떤 파일을 읽으면 되는지 연결시킨다.
'상황'에 의존성이 있다고 생각.
(어떤 도메인에서는 이 문서를 참고, 어떤 형식의 파일을 만들때, 입력 폼을 다룰때, API 연동 규칙, 에러 핸들링 규칙 등)

아마 skills 를 활용하기는 쉽지 않겠다는 생각이 들었습니다.

클로드 코드로 치면 웹스크래핑 도구를 써서 데이터를 모아오는 스킬, DB에 정보를 업로드하는 스킬 뭐 이런 식일 건데요.

근데 팀 프로젝트에서 그럴 만한게 뭐가 있겠습니까. 특히 안정성, 유지보수성 때문에 새로운 코드를 맘대로 쓰지도 못하는 프로젝트인걸요.

지식 대통합의 기회

이것들은 AI Agent 를 위한 것들이지만 동시에 팀원들 끼리 지식을 대통합 할 수 있는 기회라고 생각이 들었습니다.

솔직히 회사 들어오고나서 아직까지도 프로젝트 코드를 다 이해를 못했어요... 일일이 까서 열어봐야하는 캡슐화된 코드가 너무 많습니다.

특히 서버사이트 코드 복잡도는 미쳐버리는 줄 알았어요.

이런 거대하고 복잡한걸 만들어놓고서는 설명하는 문서를 하나도 만들어놓질 않으니

새로온 사람이 코드베이스 전체 맥락과 흐름을 다 파악하는데 너무 많은 시간과 노력을 쏟아야 하더군요.

효과가 있을까? 기도해보자..

사실 AI는 핑계고 어쩌면 지식의 문서화가 더 시급한 목표인 거 같습니다.

저희 프로젝트에서는 안정성이 그 무엇보다도 중요하기에 코드 한 줄 한 줄 엄격하게 코드 리뷰를 하는데

앞으로도 Claude Code 를 개인 프로젝트에서 권한 다주고 대량의 코드를 책임없이 찍어내게 절대 할 수 없다는것을 알고 있고,

지금까지 해왔던 것 처럼 AI Agent 로 매우 국소적인 단위의 코드 생성, 테스트 코드 생성, 이슈 처리, 리뷰 등에만 쓸 것인데.

적어도 안정성을 더 높이려면 코드 패턴, 비즈니스 로직, 이슈 이런 것들을 문서로 잘 정리해야 할 것이라는 결론이었습니다.

앞으로 문서가 쌓여갈 수록 cursor 는 더 똑똑하게 알아먹고 대답을 잘 해주겠죠?

[개발자 이야기] 프론트 개발자의 AI로 인해 잠 못드는 나날

snowman95 — Mon, 2 Mar 2026 16:34:54 +0900

AI 기술 부채

AI로 인해 흥분되어 잠 못드는 날, AI로 불안해서 잠 못드는 날이 반복됩니다.

자고 일어나면 또 새로운 AI 기사가 쏟아지면서 AI 기술 부채가 나날이 쌓이고 있습니다. 열심히 따라가기 위해 노력 중입니다.

퇴근하고, 주말에도 쉬지를 못하고 AI를 배우고 공부하고 실습하고 고민하고 있습니다.

"껍데기만 만드는 개발자"가 될 것인가?

하지만 프론트엔드 개발자는 AI 를 커리어와 직접 연결시키질 못하니 그게 참 답답합니다.

회사에서 팀 단위로 AI를 활용하고 있지 않고, 각자 개인적으로 쓸 뿐이고.

AI와 접목한 서비스를 만들고 있지도 않아서 내가 이러다간 AI 시대에 뒤떨어지고 경쟁력에서 밀리는 것이 아닐까 두려움이 듭니다.

특히 제가 프론트엔드 개발자라서 더욱 더 스트레스가 큰 것 같습니다.

설령 회사에서 AI 서비스를 개발하더라도 이미 다 만들어진 AI 서비스를 화면상에 보여주기만 하면 되는 일이라서 이거는 절대 AI 개발자라고 할 수가 없죠.

요즘 그런 직무를 AI Service Frontend-Engineer 라는 이름으로 뽑는 회사가 있던데 그냥 AI 서비스를 화면에 보여주는거죠.

그러면 난 이전에 머신러닝을 통해 만들어낸 데이터를 화면 상에 보여주는 일을 했는데 AI Frontend-Engineer 개발자라고 할 수 있는가? LLM 을 안썼으니 인정 안되는건가?

뒷단이 어떻게 되어있든 화면에 그리는 역할이라는 본질을 같은걸?..

내가 지금 하고 있는 일에서 어떻게든 AI와 '직접적'으로 엮이려면?
빠르게 백엔드 영역으로 확장하고 백터DB, LLM 연결하여 AI 기능을 제공하는 백엔드 개발자가 되어야 하는건데..

그러면 내가 그 수준에 도달했을때 과연 세상은 또 얼마나 바뀌어 있을지 미지수입니다.

어쩌면 인프라 담당자만 남아있을 수도 있겠죠. 그러면 제가 인프라 하러 가는게 맞을까요? 단지 오래 살아남을 것 같으니까?

책임 지는 사람이 필요한 거라면 직무 유지하고 제 연차와 경험으로 비비고 들어가는게 나을 수도 있는 선택일 수 있겠죠.

프론트엔드 개발자의 선택의 기로

1. 스테이 (직무 유지)

지금 회사의 직무 그대로 유지하면서 현재에 충실히 사는 방법.. 자유롭게 뭔가 할 수 있는 회사는 아니지만 AI로 시끄럽게 떠들어본다.

그치만 그게 AI 경력으로 쌓이는 것도 아니고, 앞으로도 큰 변화가 기대되진 않는다.

그렇다고 직무 전환을 해달라고 때쓰면 어디로 가나? 누가 받아주나?

2. 직무 변환 가능한 회사로 이직 (아마 AI스타트업)

나는 이 게임을 해봤어요. (AI 스타트업을 다녀봤어요)

AI가 만능이 아니다. 아무리 언변이 뛰어나도 돈 못벌면 끝이다. 스타트업은 참으로 냉혹한 곳이다.

아마 이걸 선택하게 되면 또 경력 2-3년 다시 쌓아서 과거에 했던것 처럼 대기업 경력직에 도전하겠죠...

그러면 또 경력 리셋으로 인한 돈은 돈대로 후려치기 당하고, AI는 얼마나 더 발전되어 있을지도 모르고..

3. 이직하고 금융치료 (직무 유지)

국내 TOP IT 회사 중에서 비포괄 회사로 가서 퇴근 안한다고 생각하고 야근비 뽑아먹는게 제일 편하고 좋은 방법일 수 있습니다.

저는 환자고 금융치료가 필요한 걸 지도 모르겠습니다. 커리어 경력도 버리지 않고 그대로 인정받고요.

AI 는 주말에 공부하면 되지.. GPU 값 벌어야지

제미나이 선생님

제미나이 선생님께서도 그냥 금융치료 받으라고 하네요. ㅋㅋ

작년에 이직하고 이사하고 결혼 준비하고.. 진짜 미친듯이 많은 일이 있었는데요. 올해가 더 하면 더 할듯 합니다.

Anthropic Courses - 무료 온라인 강의 공개

snowman95 — Mon, 2 Mar 2026 15:35:10 +0900

Anthropic Courses

Browse all Anthropic courses

anthropic.skilljar.com

개발자 대상 과정

Claude Code in Action: Claude Code를 개발 워크플로에 통합하는 실습 과정
Building with the Claude API: Anthropic 모델을 Claude API로 활용하는 전 과정을 포괄적으로 다루는 과정
Introduction to Model Context Protocol: Python으로 MCP 서버와 클라이언트를 처음부터 구축하는 방법 학습
- MCP의 세 가지 핵심 프리미티브인 tools, resources, prompts를 다룸
- Claude를 외부 서비스에 연결하는 방법 포함
Model Context Protocol: Advanced Topics: 샘플링, 알림, 파일 시스템 접근, 트랜스포트 메커니즘 등 프로덕션 MCP 서버 개발을 위한 고급 구현 패턴
Introduction to Agent Skills: Claude Code에서 재사용 가능한 마크다운 기반 스킬을 생성·구성·공유하는 방법
- Claude가 적절한 작업에 자동으로 적용하는 스킬을 만드는 과정
- 팀 간 배포 및 일반적 문제 해결까지 포함

일반 사용자 및 입문 과정

Claude 101: 일상 업무에 Claude를 활용하는 방법, 핵심 기능 이해, 고급 학습 리소스 탐색
AI Fluency: Framework & Foundations: AI 시스템과 효과적·효율적·윤리적·안전하게 협업하는 프레임워크 학습

교육·학생·비영리 대상 과정

AI Fluency for Educators: 교수진, 교육 설계자, 교육 리더가 AI Fluency를 자신의 교육 실무와 기관 전략에 적용하는 과정
AI Fluency for Students: 학생들이 학습, 커리어 계획, 학업 성취를 위해 책임감 있는 AI 협업 역량을 개발하는 과정
Teaching AI Fluency: 학술 교수진과 교육 설계자가 강사 주도 환경에서 AI Fluency를 교육·평가하는 과정
AI Fluency for Nonprofits: 비영리 전문가가 조직의 임팩트와 효율성을 높이면서 미션과 가치에 충실한 AI 역량을 개발하는 과정

클라우드 플랫폼 통합 과정

Claude with Amazon Bedrock: AWS 직원 대상으로 만들어진 인증 프로그램 기반 교육을 일반에 공개
Claude with Google Cloud's Vertex AI: Google Cloud의 Vertex AI를 통해 Anthropic 모델을 활용하는 전 과정을 포괄적으로 다룸

[AI] 인공지능에게 작업을 위임하는 것. (의도를 실행으로 옮기기)

snowman95 — Sat, 28 Feb 2026 01:04:10 +0900

AI 에게 업무를 위임할지 여부를 결정하는데 3가지 변수가 필요함

인간 기준 소요 시간: 해당 작업을 직접 수행하는 데 걸리는 시간
성공 확률: 주어진 시도에서 AI가 사용자의 기준을 충족하는 결과를 생성할 가능성
AI 처리 시간: AI 출력 요청, 대기 및 평가에 걸리는 시간

만약 사람이 하는데에 1시간이 걸리는 작업을 AI 가 단 몇 분만에 하더라도 검토에 30분 이상 소요된다면?
AI 의 작업 성공 확률이 매우 높은 경우에만 AI 에게 작업을 맡겨야 될 것입니다.

만약 반대로 사람이 하는데에 7시간이 걸리는 작업을 AI 가 단 몇 분만에 진행하고 사람이 1시간 만에 검토할 수 있다면?

이건 AI 에게 맡겨야겠지요?

AI 위임의 효율성을 높이는 방법

인공지능(AI)에 작업을 위임할 때 성공 확률을 높이고 처리 시간을 단축하여 AI 위임의 효율성을 높이는 세 가지 방법이 있습니다.

AI가 성공적으로 수행할 수 있는 명확한 목표를 설정하여 더 나은 지침을 제공할 수 있습니다.
평가 및 피드백 기능을 개선하여 AI가 올바른 작업을 수행하도록 유도하는 데 필요한 시도 횟수를 줄일 수 있습니다.
AI의 작업 수행 능력을 평가하는 데 드는 시간을 줄일 수 있습니다.

이러한 모든 요소는 해당 분야의 전문 지식을 통해 향상될 수 있습니다.

전문가는 어떤 지침을 제공해야 하는지 알고, 오류를 더 잘 파악하고 수정할 수 있기 때문입니다.

그래서 자꾸 뉴스에서 도메인 지식이 중요하다... 중요하다 그러는 겁니다.

위임: 한 사람의 머릿속에 있는 생각을 다른 사람이 행동으로 옮기도록 하려는 시도

실제 업무나 제대로 된 위임은 명확한 결과물을 염두에 두고 진행해야 한다는 것을 의미합니다.

바로 그 부분에서 어려움이 생기죠.

AI에게 원하는 바를 어떻게 전달해야 AI가 스스로 판단력을 발휘해 문제를 해결하면서도 원하는 결과물을 만들어낼 수 있을까요?

소프트웨어 개발자는 제품 요구사항 문서를 작성하고 ,

영화 감독은 촬영 목록을 전달하며, 건축가는 설계 의도 문서를 만듭니다.

해병대는 5단락 명령서(상황, 임무, 실행, 관리, 지휘)를 사용합니다.

효과적인 위임 문서는 놀라울 정도로 일관성이 있습니다.

무엇을 달성하려는 것이며, 그 이유는 무엇인가?

위임된 권한의 한계는 어디까지인가? "완료"는 어떤 모습인가?

구체적으로 어떤 결과물이 필요한가? 진행 상황을 파악하기 위해 어떤 중간 결과물이 필요한가?

그리고 완료를 알리기 전에 무엇을 확인해야 하는가?

AI 와의 협업은 사람과 협업하는 것과 유사하다.

회사에서 부하 직원에게 일을 시키는것이나 사람이 AI 에게 일을 시키는 것이나 결국 똑같다는 겁니다.

"필요한 것을 설명하고, 효과적인 피드백을 제공하며, 업무 평가 방식을 설계" 하는 것입니다.

어쩌면 이제는 AI 스스로 검토할 수 있는 세상?

하지만 이러한 개념은 AI 의 발전에 따라...

AI 가 스스로 생각, 더 많은 맥락을 파악하고, 더 강력한 skill 과 연결되면서 또 다른 이야기가 되어가고 있습니다.

사람이 무언가 하고자하는 의도만으로도

AI 가 스스로 매우 구체화된 문서를 만들고, 만들어진 결과물도 수 많은 반복적인 검토를 거쳐서 성공 확률을 강제로 끌어 올릴 수 있다는 주장이죠.

2023년 이전: 가치 = 인간의 기술 x 인간의 시간

2025년: 가치 = (인간의 도움 + AI 속도) - 인간의 평가 시간

2026년: 가치 = 인간의 의도 x (AI 연산 x AI 재귀)

진짜 2028년에 AGI 나올 수도 있겠단 생각도 듭니다.

저도 아직 이 단계까지는 경험 해보지 못했으나... 이러한 방향으로 나아가고 있음을 체감합니다.

이제는 AI 를 쓰는 사람이 안쓴 사람보다 나으면 더 가치있다고 판단할 수 없고,

바보라도 AI 를 쓰기만 하면 AI의 컴퓨팅 파워에 따라 매우 의도에 근접한 결과를 얻을 수 있게 된다는 거죠.

진짜 이러다 2028년에 AGI 나올 수도 있겠단 생각도 듭니다.

참고 https://www.oneusefulthing.org/p/management-as-ai-superpower

Management as AI superpower

Thriving in a world of agents

www.oneusefulthing.org

[AI] 데일리 테크뉴스, 주식, 부동산 올인원 Digest 서비스

snowman95 — Sat, 28 Feb 2026 00:27:39 +0900

서비스 소개

바쁘게 살면서 기술 트랜드, 세상 돌아가는 것(주식, 부동산) 등을 따라가기 쉽지 않아서 이런 서비스를 하나 프로젝트 삼아 만들었습니다.

데일리로 데이터 수집하여 DB 업로드, 텔레그램 전송, sns 업로드하는 fastAPI 서버를 제 귀여운 맥 미니에서 구동하고 있습니다.

https://techpulse-api.vercel.app/

TechPulse — Daily Digest

AI-curated daily digest: tech news, stocks, real estate, AI research, open source.

techpulse-api.vercel.app

이전에 맥북에서 구동하던걸 맥미니로 옮기면서 환경과 무관하게 동작하기 위해 Docker 로 띄웠구요..

sns 자동화도 해보고 싶어서 sns 로도 퍼나르고 있는데 솔직히 조회수도 지지부진하고 별 재미는 없습니다.

다른 사람은 몰라도 나한텐 너무나 필요하다

그래도 개인적으로는 확실히 이거 있고 없고가 인생에서 큰 차이가 있습니다.

유튜브, sns 는 한 번 알고리즘이 형성되면 다른 세상은 볼 수가 없더군요.

내가 보던 것만 보여주니까 벽 안에 갇히는 느낌이 듭니다.

세상 돌아가는건 알아야 하니까요.

저한테는 이런 종합적인 뷰를 숟가락 크게 떠서 매일 입에 넣어주는게 필요했습니다.

어쨋든.. 내가 좋으면 된거겠죠

NO Cluade Code 리소스

SNS 에 업로드할 때는 요약, 인사이트 추출 등의 추가 가공이 들어가기 때문에 AI 리소스가 필요한데요.

흙수저라서.. 곧 Cluade Code 구독이 끝나기 때문에

없이도 동작하기 위해 무료 LLM 리소스를 끌어와서 요약 및 인사이트 정리 하고 있습니다.

어차피 분량도 작고 대규모 모델이 필요한 건 아닌 작업이라서 그렇게 했는데요.

결과는 생각보다 꽤 만족스럽습니다.

한 달에 Cluade Code 구독료 만큼이라도 벌 수 있으면 참 좋겠습니다 ㅠㅠ

맨날 즐기기만 하고 돈은 못버는 참 안타까운 ...

커스텀 가즈아

이런걸 굳이 만든 이유는 커스텀이 가능하다는 점 때문이죠.

데일리로 받아보고 싶은 정보들은 수집만 추가해서 이미 구축된 파이프라인에 태우기만 하면 됩니다.

또한 좀 더 디테일한 것들. 부동산으로 치면 급매 알리미, 경매 일정 안내 뭐 이런거 말이죠.

내 집에 관련된 소식, 데일리 채용 소식

얼마든지 무궁무진하게 붙일 수 있다는게 가장 큰 장점입니다.

또한 AI 리소스를 더 적극 활용한다면, 전체적인 시장 뷰를 통해서 얻을 수 있는 인사이트도 있겠죠?..

이러다 보면.. 서비스가 더 커지고 안정적이게 될 거고

구독.. 구독을 언젠가 붙여야지.. 광고.. 광고...!! 돈..!!돈!!!

[AI] AI Agent 결국엔 도구(Skill) 싸움이다.

snowman95 — Sat, 28 Feb 2026 00:18:22 +0900

도구 싸움

최근 Claude Code 로 열심히 씨름하다가 깨달은 새로운 내용입니다.

AI Agent 가 반복되는 사이클 돌면서 도구를 호출해서 일 하는게 전부구나 (너 사실 단순하구나?)

도구(skill)을 잘 쥐어주는게 중요하다는 것을 깨달았습니다.

내가 아무리 명령을 많이 내려도 좋은 결과물을 못 뽑아낸다면

그건 내 탓아님. 도구 탓이다. 그렇게 생각하세요

(옛날에 롤할때 원딜들이 서폿에게 하던 말 아닌가)

Skill 이 뭔데?

Skills는 Claude에게 도메인별 전문 지식을 제공하는 재사용 가능한 파일시스템 기반 리소스입니다.

워크플로, 컨텍스트, 모범 사례를 통해 범용 에이전트를 전문가로 변환합니다. 프롬프트(일회성 작업을 위한 대화 수준의 지침)와 달리, Skills는 필요에 따라 로드되며 여러 대화에서 동일한 안내를 반복적으로 제공할 필요를 없앱니다.

Skill 예시

클로드가 PDF 를 이해하는건 잘하는데 PDF 를 조작하는건 잘할까요?

아무리 시켜봐도 만족스러운 결과가 안나올 수 있습니다.

그럴 때 필요한게 PDF 스킬이죠.

메타데이터

pdf/SKILL.md 파일을 만들고, 클로드가 스킬을 언제 사용해야하는지 알 수 있는 메타데이터를 작성합니다. (스킬의 이름과 설명)

skill_id : 고유 식별자 (예: "xlsx", "pptx")
버전 : 버전 번호 또는 "최신"
이름 : 사람이 읽을 수 있는 이름
설명 : 이 스킬의 기능
디렉토리 : 스킬의 폴더 구조

본문에는 세부 정보를 작성합니다. 개요, 실행 방법 등이 작성되어 있습니다.

클로드가 메타데이터를 읽고 현재 작업과 관련있다고 판단하면 전체 정보를 읽어와서 컨텍스트에 로드합니다.

그런데 본문 내용이 너무 길어진다면, 링크 파일을 두어서 찾아가게 합니다.

물론 이러한 지식, 정보 외에도 실행 가능한 코드를 제공할 수도 있죠.
이 기능을 수행하기 위해 어떠한 위치의 파이썬 코드를 읽어라고 할 수도 있습니다.

즉, 스킬이란 참고 문서 역할도 가능하고 실행 가능한 도구의 역할도 가능합니다.

정리하자면 3단계 로딩 모델을 가짐

메타데이터 (이름: 64자, 설명: 1024자): 클로드는 스킬 이름과 설명을 봅니다.
전체 지침 (<5천 토큰): 스킬이 관련될 때 로드됨
연결된 파일 : 필요한 경우에만 추가 리소스가 로드됩니다.

저는 실제로 클로트 코드를 사용하면서

반복될 수 있는 작업을 모두 파이썬 스크립트로 만들면서 진행했는데요.

"이런 상황에서는 이 스크립트를 쓰세요" 라고 매번 알려주지 않아도 스킬에 등록하면 알아서 클로드가 사용할 수 있겠죠?
이런 용도입니다.

xlsx, pptx, pdf,docx 등은 엔트로픽에서 관리하는 사전 구축된 스킬들입니다.

Skill 찾기

Vercel 에서 만든 Skill 디렉토리를 참고해보세요.

쓸 만한 스킬 검색 -> 스킬 사용

The Agent Skills Directory

Discover and install skills for AI agents.

skills.sh

회사 내 프로젝트안에서 claude.md, skill.md 를 어떻게 구축하면

팀 내에서 공통화된 룰 아래에서 AI Agent 를 동작시키게 하고, skill 을 통한 개발 생산성을 끌어올릴까?

요즘 이런 고민들이 듭니다.

저도 그렇고 동료들이 AI 를 개별적으로는 참 잘 이용하는데, 팀 전체에서는 크게 활용을 하고 있지는 못하고 있어서요.

[AI] 세차장이 50m 떨어져 있다면 걸어갈까, 운전할까? (세차장 테스트)

snowman95 — Fri, 27 Feb 2026 23:44:06 +0900

세차장이 50m 떨어져 있다면 걸어갈까, 운전할까?

세차장 테스트에 대해 아시나요?

굉장히 재미있는 실험입니다.

53개의 주요 AI 모델을 대상으로 테스트한 결과, 대부분이 기초적 추론에 실패했습니다.

정답은 ‘운전’ 이지만 53개 중 42개 모델이 ‘걷기’ 를 선택 했다고 합니다.

Claude Opus 4.6, Gemini 3 시리즈, Grok-4 등 5개 모델만이 10회 반복 테스트에서도 100% 일관된 정답을 냈으며

GPT-5는 10회 중 7회만 정답을 맞혀, 평균 인간 정답률(71.5%) 과 유사한 수준으로 평가됩니다.

실험은 AI의 일관된 추론 능력 부족과 문맥 기반 판단의 한계를 드러내며, 이를 보완하기 위한 ‘컨텍스트 엔지니어링’이 중요하다는 인사이트를 얻을 수 있습니다.

이 사례에서 배울 점

추론 능력이 없거나 추론 능력은 있지만 일관성 없는 모델에게

맥락 이해에 도움이 되는 정보를 추가로 제공하면 비싼 대형 모델 만큼의 수준을 낼 수 있으니

항상 꼭 비싼 모델을 고집할 필요는 없고 저비용 모델로도 컨텍스트 엔지니어링을 통해 효율적으로 사용할 수 있다.
이런 내용을 배울 수 있을 거 같습니다.

결론은 AI 는 컨텍스트가 전부다. 라고 봐도 무방합니다.

컨텍스트, 맥락 이해, 메모리

메모리가 너무너무 중요하고, 메모리 가격이 미친듯이 올라가고 삼전/하이닉스 신고가 찍는 이유가 여기서 바로 보여지죠?

어떤 문제 해결의 결과에 도달하기 까지의 모든 과정들이 히스토리화 되어서 그것을 기반으로 작업이 진행되어야만

맥락을 이해하고 세차장 까지 50m 만 남았는데 차를 끌고가서 세차를 한다 라는 결과를 낼 수 있겠죠?

AI 모델 53종 대상 ‘세차장 테스트’: “세차장이 50m 떨어져 있다면 걸어갈까, 운전 | GeekNews

53개의 주요 AI 모델을 대상으로 테스트한 결과, 대부분이 기초적 추론에 실패함정답은 ‘운전’ 이지만 53개 중 42개 모델이 ‘걷기’ 를 선택Claude Opus 4.6, Gemini 3 시리즈, Grok-4 등 5개 모델만이 10

news.hada.io

[AI] IDE 안에서 클로드 코드 돌리지마라! 요즘 IDE 쓰는 흑우 없재? (with Ghostty)

snowman95 — Fri, 27 Feb 2026 23:33:16 +0900

긔여운 클코

커서 x 클로드 코드 = 대폭발

평소처럼 커서를 켜서, 커서 안의 터미널에서 클로드 코드를 실행시켜서 코딩을 했었습니다.

분명히 병렬 에이전트를 그렇게 까지 많이 돌리지도 않았는데도

사용 메모리가 289GB 까지 치솟다가 메모리가 터져서 맥북이 재부팅이 되더군요.

처음에는 아, 내가 AI Agent 를 동시에 너무 많이 돌려버렸나?

그렇게 생각하고 동시에 수행되는 병렬 수를 줄였습니다.

하지만, 이게 무슨 일인가요? 메모리 터짐 현상이 또 발생하고 또 발생하고 또 발생했습니다!!!

그 이후로 ide 안의 터미널에서는 클로드코드 안쓰게 되었습니다.

요즘 IDE 쓰는 흑우 없재?

요즘 누가 IDE 쓰냐 TUI 써야지.

라고 하는 글을 많이 보면서 추천하는 터미널 앱 Ghostty 를 알게 되었습니다.

Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.

Ghostty

Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.

ghostty.org

Ghostty 첫인상

일단 써봤을때 매우 빠르고 가볍다는 느낌.

그리고 윈도우를 새로 안띄우고 텝을 바로 붙여서 왔다갔다 하기 너무 편합니다.

이거 스면 IDE 내에서 클로드 쓰다가 막 스크롤 텔레포트하는 현상이 없어진다고 하던데

아직까지는 못본거 같기도 하고.. 잘 모르겠습니다. (잘 되는듯?)

그리고 유령이 귀엽다는 장점이 있습니다.

[AI] 오픈클로가 성공한 이유: LLM 시대에 누구나 앱을 만들 수 있게 되었기에 이제는 취향이 중요하다.

snowman95 — Fri, 27 Feb 2026 23:17:06 +0900

오픈클로 OpenClaw 왜 성공했을까

"LLM 시대에 누구나 앱을 만들 수 있게 되었지만, 진짜 장벽은 실력이 아닌 취향(taste) 이며, 이 장벽은 전혀 낮아지지 않았음"

"OpenClaw는 기술적으로 혼란스럽고 보안 문제도 있었지만, 강한 콘셉트와 취향 덕분에 즉각적인 관심을 얻음
사용자들은 완성도 부족을 감수하면서도 그 감각적 매력에 반응함
이는 기술적 완성도보다 취향이 더 강한 동력이 될 수 있음을 보여주는 사례"

최근 읽었던 글이 감명깊어서 글 수집했습니다.

실력 없음. 취향 없음. | GeekNews

LLM 시대에 누구나 앱을 만들 수 있게 되었지만, 진짜 장벽은 실력이 아닌 취향(taste) 이며, 이 장벽은 전혀 낮아지지 않았음공개되는 바이브 코딩 앱 대부분이 포화된 아이디어의 조잡한 복제물

news.hada.io

openclaw 서비스 자체는 별로인데 그 지향점이 사람들이 원하는 방향이다.

개발자 입장에서 이게 진짜 공감되는 말이라고 생각이 듭니다.

요즘 서비스는 진짜 폭발적으로 나오고 있는데, 그렇게 많이 만들고 홍보해도 인기를 끄는 서비스가 많지 않습니다.

저도 그래요..

제가 지난 달에 이런걸 만들어서 출시를 해서 나름 열심히 유튜브, 쓰레드, 인스타 등으로 홍보 때리고 다녔지만 별 호응을 얻지 못했습니다.

두쫀쿠맵 나오자마자 써봤는데 너무 사용성이 별로여서.. 바로 카피해서 모바일 최적화 및 사용성 개선해서 출시했었습니다.

(제 생각에) 사용성 및 최적화는 제가 더 좋게 개선했으나, 원본을 이길 수 없더군요.

두쫀쿠 월드 | Dubai Chocolate World Map

전 세계의 두바이 초콜릿 맛집을 탐험하세요.

dessert-map.vercel.app

사실 서비스의 완성도가 중요한게 아니다.

저는 두쫀쿠 월드를 통해 이번에 뼈저리게 느꼈습니다.

좋은 아이디어를 카피하여 더 사용성이 좋고, 더 최적화된 형태의 경쟁 서비스를 출시하면? 사용자를 뺏어올 수 있지 않을까?
그런 기대감이 있었으나 그렇지 못했습니다.

OpenClaw 를 따라하는 수 많은 제품이 쏟아져나와도 사람들은 OpenClaw 만 기억할 겁니다.

제가 아무리 잘 만들어도 사람들은 두쫀쿠월드가 아니라 두쫀쿠맵 만을 기억할 것입니다.

조금은 불완전 하더라도 "사람들의 취향, 지향점을 제대로 반영한 서비스/콘텐츠" + 물들어올 때 노젓기

이 두 가지 공식이면 어떤 것이든 성공하는구나 그렇게 좋은 인생 교훈을 얻었습니다.

[AI] 맥미니 Mac Mini M4 자랑, 무조건 빠르게 만드는게 중요한게 아니다

snowman95 — Fri, 27 Feb 2026 23:02:43 +0900

시대에 뒤쳐지지 않으려고 OpenClaw 를 사용 해보기 위해서 깡통 맥미니를 구입했습니다.

이미 Claude Code 도 거의 1년 뒤쳐졌는데 더 이상은 뒤쳐질 수 없습니다!

회사 맥북은 메모리 48GB 인데

우리 귀여운 맥미니는 16GB 라는 아주 귀여운 메모리를 가지고 있습니다.

이 정도 메모리로는 에이전트를 병렬로 10개씩은 못 돌리겠네요.

무조건 빠르게 만드는게 중요한게 아니다

그런데 제가 요즘 크게 깨달은 것은

무조건 빠르게 만드는게 중요한게 아니라는 것이었습니다.

무조건 병렬로 많이 왕왕 돌리면 더 효율적이고 생산적일 거라고 생각하여

5개 정도 팀을 만들고 AI Agent 역할을 나눠서 병렬로 열 몇개씩 마구 돌려봤는데요

첫 번째 문제는 토큰이 미친 속도로 닳아 없어지고,

두 번째로는 오류가 터졌을때 어디서 터졌는지 원인 파악을 할 수가 없고

세 번째로는 단 기간에 분량만 많이 뽑았을 뿐 퀄리티가 그만큼 안나왔다는겁니다.

처음으로 돌아가서 보았을때

팀에서 팀으로 작업물이 넘어갈때의 컨텍스트 스위칭에 들어가는 비용도 무시할 수 없고,

애초에 전체 프로세스를 돌려봐서 부분 결과물을 뽑아내고 퀄리티를 인간이 확인을 한 다음에 전체 결과물을 뽑고 퀄리티 확인하고,

그 다음에 다른 주제로 돌렸을때 퀄리티가 괜찮은지 확인하고.

이런 식으로 단계별로 가지 않았고, 너희가 알아서 해봐라는 식으로 했던게 문제였습니다.

즉, AI 에게 모든 걸 맡기면 안되고,

반드시 부분 검증 및 확인을 하면서 아니면 되돌아가고 맞으면 이어가는 식으로 만들어야 했습니다!

이건 하루 이틀만에 일주일 치 토큰을 순식간에 소진해버리고 깨달은 결과입니다.

개발자가 없어진다 X

(코딩하는)개발자는 없어진다 O

(AI 에게 명령하고 검토하고 책임지는) 개발자가 탄생 O

진짜 뉴스 공포 마케팅에 질릴대로 질렸습니다.

위와 같은 예시만 봐도 개발자의 역할의 이동이 발생했을 뿐 개발자는 사라질 수 없습니다.

[AI] 오픈클로(OpenClaw) 사용 후기 (결론: 뉴스에서 호들갑 떨었다)

snowman95 — Fri, 27 Feb 2026 22:47:02 +0900

첫인상 = 불안정하다

openclaw 에 저렴한 모델을 붙여서 써서 그런가 싶기도한데
일을 시키면 너무 속도가 느리고, 브라우저 연결이 계속 끊기는 등 불안정하다는게 첫인상이었습니다.

그래도 좀 더 비싼 모델을 붙이면 훨씬 똑똑하게 잘 해낼거라는 기대가 아직은 있습니다.

일단 설치가.. 매끄럽지 않았고

시작 부터 선택지가 많아서 이거 뭔 비개발자들은 이해하고 쓸 수는 있는건가 싶었어요.

브라우저 연결도 매끄럽지 않고. 그냥 다 매끄럽지가 않았음..

openclaw 는 단지 올인원 도구일지도? (대신 토큰 먹는 하마)

클로드 코드를 사용하면서 통합 대시보드,로깅, 컴퓨터 제어, 채팅 연동, 브라우저 연동, 스킬 등 클로드코드 쓰면서 이런거 필요성을 느끼고 직접 만들어가며 쓰고 있었는데요.
openclaw 는 친절하게 처음부터 올인원으로 도구를 제공해주는 통합 솔루션이다 라는 느낌입니다.

클로드 코드의 해비 유저가 몇 달동안 도구들을 쌓아오면 이렇게 되지 않을까 라는 모습이었습니다.

근데 개발자들은 내 입맛대로 커스텀 하는 걸 더 좋아하거든요.

애초에 openclaw 또한 클로드 코드로 구현한 것이기 때문에 개발자들은 클로드 코드로도 충분히 구현이 가능합니다.

대시보드, 텔레그램 채팅, 웹 스크래핑, 웹 제어 등 이요.

개발자들은 클로드 코드로도 이미 다 구현해서 쓰는중임

이건 제가 직접 구현한 대시보드의 일부이고

개인 스터디 목적으로 강의 자료를 만드는 공장을 가동 중이고..

데일리 스케줄에 따라 5-6종의 카테고리 별 데이터를 수집해서 텔레그램/인스타/스레드 에 퍼나르고 있습니다.

주식/부동산/테크 뉴스/오픈 소스 등... 누워있어도 매일 내 입에다가 새로운 소식을 집어 넣어줬으면 좋겠다 라는 목적으로 만듬

아래의 사이트에도 배포해두었으니 관심이 있으시면 데일리 뉴스 받아보세요.

https://techpulse-api.vercel.app/

그리고 저는 이와 같이 AI Agent 와 양방향 대화가 가능한 개인 AI 비서 까지도. 이미 모두 구현했었습니다..

제가 쓰기 좋은 형태로요. (제 Obsidian 개인 데이터를 기반으로 TODO 브리핑 및 가이드)

그래서 뭐랄까... 솔직히 openclaw 를 처음 설치하고 열어봤을때 안정성이 떨어져서 기대에 비해 좀 실망감이 컸고.

솔직히 뉴스가 참 호들갑이 심하구나 라는 생각이 들었습니다.

고점에 맥미니 산 흑우 왔는가?

openclaw... 차마 회사 노트북에서 돌릴 수 없기에 맥미니(Mac Mini M4) 샀는데 고점에 물린 느낌입니다.

이건 마치 제가 사면 떨어지는 주식 매직과 유사하네요.

이 맥미니는 이제 데일리 작업을 가동하고 온갖 AI 테스트 실험에 사용될 희생양입니다.

죽어도 다시 살려서 다시 사용해드릴 예정입니다.

[AI] 코드 공장 시대와 미래 SRE #AI #인프라

snowman95 — Fri, 27 Feb 2026 22:22:22 +0900

AI vs (인간+AI)

AI가 산업에서 완전히 소프트웨어 엔지니어를 대체하게 되는 날은,

'AI가 인간보다 더 빠르고 정확하게 소프트웨어를 만든다가 충족되는 날'이 아니라

'AI가 인간 없이도 인간이 AI를 활용한 것보다 더 빠르고 정확하게 소프트웨어를 만든다’가 충족되는 날일 것입니다.

모든 인간이 패배하기까지는 아직은 조금 더 시간이 있어보입니다.

왜냐하면 더 강력한 AI가 나올수록 인간 역시도 그 강력한 AI를 등에 업고 경쟁할 것이기 때문입니다.

근본적으로는 지금까지 인간이 차지하는 비중이 아주 컸던 소프트웨어 엔지니어링이라는 분야가 해체되고 재조립되는 과정이 이루어질 것입니다. git+PR 중심의 워크플로는 인간에게 맞춰진 워크플로일뿐 AI에게 필요 없을 수 있습니다.

인간 엔지니어는, AI들이 스스로 하지 못하는 더 큰 규모의 결정을 하는 역할을 해야 한다고 생각합니다.

이제 코드는 AI가 쓰다보니 기능의 구현은 전례 없이 빨라지고 있습니다. 그리고 그럴수록 운영 부담은 커집니다.

이제는 모두가 소프트웨어를 만들 수 있게 되었습니다.

하지만 소프트웨어를 실제로 서비스로 운영하는 SRE와 DevOps는 아직 상대적으로 쉽게 자동화 되지 않고 있습니다.

이미 수백개의 마이크로서비스를 복잡하게 운영중인 조직의 AWS 계정에, 어떤 EC2 하나를 생성해 놓고 거기에 충분한 권한과 함께 가장 똑똑한 LLM 에이전트를 적절한 프롬프트로 심어 놓으면 이 에이전트가 알아서 인프라를 읽고 최적화와 모니터링과 장애처리까지 모두 알아서 하면 얼마나 좋을까요?

"서비스의 자율운영" 을 만들어내는 회사 keeban 의 글에서 퍼온 글 입니다.

https://article.keeban.io/manifesto

2025 AWS re:Invent CTO 베르너 보겔스 박사의 마지막 키노트

snowman95 — Sat, 27 Dec 2025 17:12:03 +0900

얼마 전 미국 라스베이거스에서 2025 AWS re:Invent 행사를 했습니다.

저 멀리 서울 방구석에서 딸깍 하면 행사 요약본을 읽어볼 수 있는 있는 세상이네요~

물론 제가 가봤자 반절도 알아듣지 못했을테지만 회사의 지원을 통해 행사 현장에 다녀온 동료가 참 부럽긴했습니다. ㅎㅎ

여러 세션 중에서도 가장 인상 깊고 개발자가 아닌 사람들도 읽으면 좋을 내용을 가져왔습니다.

요약 내용과 함께 제 생각을 풀어보겠습니다.

AWS reInvent 2025 Special Closing Keynote with Dr. Werner Vogels

"이제 코드 몰라도 AI가 다 짜주는데, 개발자 끝난 거 아냐?"

혹은 "프롬프트만 잘 치면 되는 '바이브 코딩'의 시대가 왔다"는 말들이 들립니다.

바이브 코딩(Vibe Coding) 은 위험한 스캠이자 도박에 가깝습니다.

AWS의 CTO 베르너 보겔스 박사가 그의 마지막 키노트에서 강조한 '르네상스 개발자'의 자질을 빌려, 우리가 왜 AI를 단순 복사-붙여넣기 도구가 아닌, 철저히 통제해야 하는지 이야기해보려 합니다.

본론 1: 바이브 코딩이 위험한 이유

베르너 보겔스는 AI가 코드를 생성하는 속도가 우리가 그것을 이해하는 속도보다 훨씬 빠르다는 점을 경고합니다.
여기서 두 가지 치명적인 문제가 발생하죠.

첫째, 환각(Hallucination) 현상입니다. AI는 존재하지 않는 속성을 만들거나 시스템의 기존 패턴을 무시하는 그럴듯한 거짓말을 합니다.

둘째, 검증의 부재입니다. AI가 짠 코드가 규제 요구 사항을 위반하거나 보안 허점을 만들어도, 규제 기관에 "AI가 그랬어요"라고 변명할 수 없습니다. 책임은 오로지 개발자 본인에게 있기 때문입니다.

단순히 똑똑한 AI 가 만들어줬으니 잘 돌아가겠지"라고 믿고 레버를 당기는 것은 엔지니어링이 아닙니다.

본론 2: AI 시대의 새로운 자질, '르네상스 개발자'

그렇다면 우리는 어떻게 변해야 할까요? 보겔스 박사는 과거 암흑기 이후 호기심으로 모든 것이 변했던 르네상스 시대처럼, 우리 개발자들도 다섯 가지 자질을 갖춘 '르네상스 개발자'로 진화해야 한다고 말합니다.

르네상스는 프랑스어로 '재생' 또는 '부활'을 뜻하며, 14세기부터 16세기 이탈리아 피렌체를 중심으로 시작되어 유럽 전역으로 퍼져나간 고대 그리스·로마 문화의 부흥 운동입니다.

중세의 신 중심 세계관에서 벗어나 인간의 가치와 개성, 자연의 아름다움과 이성을 중시하는 인문주의를 바탕으로 문학, 예술, 과학 등 모든 분야에서 혁신적인 성과를 이뤄내며 근대 유럽의 토대를 마련했습니다.

레오나르도 다빈치, 미켈란젤로, 라파엘로 같은 거장들이 활동했고, 원근법과 인체 비례 등 과학적 기법이 발달했으며, 종교개혁과 근대 과학의 발달에도 영향을 주었습니다.

다섯 가지 자질

호기심 (Curiosity): 단순히 AI가 준 코드를 쓰는 게 아니라, 왜 이렇게 짜여졌는지 분해하고 작동 방식을 이해하려는 본능이 필요합니다.
시스템적 사고 (Systems Thinking): API 하나, 큐 하나를 바꿨을 때 트래픽과 팀 소유권 등 전체 시스템에 어떤 영향을 주는지 큰 그림을 봐야 합니다.
정밀한 소통 (Communication with Precision): AI와 대화할 때 자연어를 쓰더라도 모호함을 줄여야 합니다. 그래서 우리는 '명세 주도 개발(Spec-driven development)'을 배워야 하죠.
책임감 있는 소유권 (Ownership): "만든 사람이 소유한다(You build it, you own it)"는 정신입니다. AI 시대일수록 인간 대 인간의 코드 리뷰를 늘려 품질을 검증하는 메커니즘을 갖춰야 합니다.
폴리매스 (Polymath): 한 분야의 전문가를 넘어, 프론트엔드부터 인프라, 비즈니스까지 폭넓은 'T자형 지식'을 갖춰야 AI가 준 결과물의 가치를 제대로 판단할 수 있습니다.

AI는 우리의 일자리를 뺏는 것이 아니라, 우리가 하는 일을 변화시킬 것입니다.

도구는 계속 변하겠지만, 우리는 여전히 무언가를 만드는 '빌더(Builder)'입니다.

호기심

제가 가장 중요하다고 느낀 부분이 바로 호기심 입니다.

이게 바로 개발자와 코더의 차이라고 생각합니다. 개발자는 상상과 호기심으로 세상을 바꾸는 힘을 가지고 있습니다.

과거에 저는 코드를 통해 뭔가를 창조한다는 행위 자체에만 관심과 호기심이 있었는데요.
지금은 세상 살이 해보면서 다양한 경험을 해보니까 많은 것에 관심이 생기고 공부를 하고싶고 더 배우고 싶고 이유를 알고 싶고 만들어보고 싶고 연구해보고 싶은 그런 마음이 생기더군요.

시스템적 사고

지금 회사에서는 일하면서 시스템적 사고에 대해 배우고 있습니다.

스타트업 시절엔 서비스를 빠르게 출시하여 검증해야하지만, 큰 기업에서 이미 견고하게 구축된 시스템을 유지보수하는 일은 참 성격이 다릅니다.

저는 지금은 훨씬 큰 기업에서 내가 무언가 사소한것 하나라도 바꾸었을때 전체에 미치는 영향이 있을 수 있고 그 바운더리를 파악하고 영향을 좁히는 연습을 하고 있습니다. 코드 한 줄을 바꾸더라도 이유가 명확히 있어야 하고, 영향을 파악해야하는 것에서 스트레스가 있긴 합니다. 때로는 스타트업 시절이 그립기도 하지만 이렇게 큰 시스템을 건드리는것 또한 값진 경험이라 생각하고 있습니다.

정밀한 소통

코딩을 하면서 매일매일 느낍니다.

과거에도 시키는걸, 부리는걸 잘해야한다는 말이 있잖아요. 결국 이건 기획적인 능력을 의미합니다.
내가 뭘 만들어야하는지 명확하게 정리해서 전달해야하는 능력이 필요하다는 것입니다.

책임감 있는 소유권

책임감 있는 소유권은 AI 한테 맡긴 일을 review 없이 무지성 approve 해버린 후 엉망이된 코드를 보고 많이 참 많이 느낍니다.

확인도 없이 그대로 갖다 쓰는 행위를 해서는 안됩니다.

결국 "판단의 영역은 사람이 해야한다." 라는 것과 이어집니다.

폴리매스

마지막 폴리매스가 바로 Multi Role... 다재다능한 사람을 의미합니다. 앞으로 모든 개발자가 추구해야하는 방향입니다.

프론트만 할 줄 알았더라면 이제는 백엔드도 할 줄 알아야하고, 인프라 지식도 갖춰야하고 AI 도 공부해야할 것입니다.

방금도 말했듯이 판단의 영역은 사람의 몫이기 때문에 인간 자체가 뛰어나야 시키는 것도 잘하고, 결과물에 대한 판단도 잘한다.

하나 하기도 힘든데 다 잘하는 사람을 원한다니.. 이런 세상에서 제가 신입이었다면 아마 숨막혀 죽어버릴 거 같긴하네요.

이런 다섯 가지 자질에 대해서 제 경험과 스킬을 토대로 코딩을 알려드리는 그런 강의를 준비해보려고 합니다.

저 보다 코딩 잘하고 잘 알려주는 강의는 많을거라서 저는 제 경험적인 강점 (인프라, 스타트업, 큰기업) 을 살려서

대부분 강의에서는 이렇게 알려주는데 스타트업에서는 주로 이렇게 쓰이고, 큰 기업에서는 이러이러한 이유 때문에 다르게 쓴다는 등..

돈 주고 얻기 힘든 경험적인 스킬들을 한번 알려주는 강의.. 할 수 있을지 모르겠는데 한번 준비해보려고 합니다.

25년도 프론트엔드 개발자 이직 이야기

snowman95 — Sun, 22 Jun 2025 00:56:24 +0900

Full 3년을 채우고 4년차로 넘어가는 시점에 운이 좋게 이직을 성공하게 되었습니다.

이제 수습기간이 끝났고, 리프래쉬 하는 마음으로 그 동안 있었던 일들을 복기하는 시간을 가져보려합니다.

갑자기 찾아온 25년도 빙하기

25년도는 지금껏 겪어보지 못했던 빙하기였습니다.

사실 코로나때 경제가 박살났는데 그걸 돈풀어서 억지로 살려놓은게 맞았던거 같습니다. 실감 났습니다.

문닫는 회사들이 많아지고, 사람 정리하는 곳이 많았죠.

제가 다니던 회사도 올해 초 부터 최고의 복지였던 재택 근무가 없어졌습니다.

그리고 정말 오랜 기간 함께 일해온 동료들의 퇴사 소식.

갑자기 사무실 리모델링을 하고 마구 늘어나는 신규 입사자들

...받아들이기 힘들 정도로 단기간에 너무 많은 변화들이 있었습니다.

저는 회사 사람들이 좋았고, 자유롭게 개발할 수 있는 환경이 참 좋았었는데요...

하지만 이 환경이 그렇게 오래가지 못할 거라고 판단이 들면서 이직 생각을 시작하게 되었습니다.

또한 25년 3월이면 경력 3년을 다 채운 시점이었기 때문에

제 개발자 인생의 기로점이란 생각이 들었습니다.

다음 회사를 간다면...

시니어 개발자로 나아가기 위해서 꼭 필요한 대규모 트래픽 환경을 겪어본 경험이 이제는 필요하지 않을까 생각이 들었고,

다음 회사는 경제 박살나도 버틸 수 있는 안정적인 회사 + 대규모 트래픽을 겪을 수 있는 회사

이런 회사를 선택하기로 결심했습니다.

지난 3년 동안 했던 수 많은 작업들을 모두 정리하고 복기하고, 오래된 포트폴리오와 이력서 뜯어 고치는 것 부터 시작했습니다.

처음에는 요즘 채용 시장이 어떤지 탐색이나 해볼까 하는 마음으로 시작했는데요.

서류... 생각보다 잘 안되더군요?

도대체 무슨 기준인지 모를 정도로 결과가 난해했습니다.

와 뭐야 이런 회사가 이렇게 쉽게 뽑아준다고? 싶은 곳도 있고요.

우와 이 회사는 무슨 배짱으로 서류 탈락시킨거지? 싶은 곳도 있었습니다.

나름의 기준이 있겠지만 솔직히 이력서는 검토하는 사람 마음인지라...

그냥 그날의 기분? 주로 사용해온 기술? 본인의 개발 경험? 등 주관적인 생각이 많이 개입되는거 같습니다.

전통적인 대기업이라면 학벌도 보겠죠.

이제는 아무나 채용할 수 없다!

제가 느끼기로는 딱 이겁니다.

이제는 여유가 없기 때문에 아무나 대규로모 막 채용할 수 없는 상황이 되었기 때문에

"내맘에 쏙 드는 뭐든 다 잘하는 사람"이 필요합니다.

이런 채용 시장을 보면 요즘의 부동산 시장이 이해가 됩니다.

"진짜 내맘에 쏙 드는 위치,학군,교통,사업성 모든걸 다 만족하는 너무 좋은 똘똘한 아파트" 이걸 사고 싶은거에요!!!

어쨌든 사람은 늘 필요하고 뽑힐 사람은 뽑힌다.

저는 진짜 천운이 닿았습니다.

지금 이직한 팀에 여러 명의 신규 채용을 계획중이었는데 제가 1호로 빠르게 들어왔으니까요. 정말 운이 좋았습니다.

1년 바라보고 이직 준비하자 생각했는데 너무 빠르게 되어서 어버버...하면서 4월달에 바로 옮기게 되었습니다.

면접 보자마자 다음날 바로 합격 메일이 와버린 터라.. 꿈인가 싶고 팀원 분들께도 너무 갑작스럽게 소식을 전하게 되었고..

어버버버... 하면서 짐싸고 뭐 그렇게 됐습니다.

근데 지원하는 사람 입장에서는 팀 사정을 모를 수 밖에 없긴 하는데요. 뽑혀서 와보니까 왜 뽑힌지 알거 같더군요.

해당 도메인으로 개발해본 경험이 있고, 팀에서 사용하는 기술도 거의 다 써봤고, 더 최신 트렌드 기술도 다뤄봤고, 기술 부채 해결 및 팀 내 개발환경 개선 등 여러가지 시도를 많이 해봤던 점...

그리고 핵심은 하나의 서비스를 맡아서 설계 단계부터 운영 서비스 배포까지 모두 해봤던 경험을 좋게 봐주신게 아닐까 싶습니다.

제가 들어와서 봐도 이걸 다 해봤거나 할 줄 아는, 해줄 수 있는 사람이 필요해보여요.

수습 기간

입사 후 3개월 수습 기간이 있는데, 수습 기간동안 잘 적응할 수 있게 많이 도와주는 분위기였습니다.

업무에 바로 투입되는게 아니라 단발성 과제를 진행했고, 과제에 대해 발표를 하고 평가를 받는 시간도 가졌습니다.
근데 제가 평가에 꽤나 민감해서 그런지 지난 4월, 5월, 6월이 참 불편한 감정과 좋은 감정이 뒤섞여서 혼란스러웠습니다.

혹시.. 이것도 날 시험하는게 아닐까? 그런 망상이었죠 ㅋㅋㅋ

지금은 수습이 끝나서 그런가 꽤 마음이 편해졌고, 회사 사람들도과도 좀 더 가까워졌다는 생각이 듭니다.

근데 일단 모르겠고 복지 최고..! 만만세 ㅠㅠ 충성충성

이전 회사에서 현금성 복지가 없는게 아쉬웠는데 새 회사의 복지는 대만족입니다.

앞으로의 계획

수습 끝날때 미팅을 하는데 그때도 사실 명확히 내가 이걸 해보겠다고 말씀드리진 못했습니다.

제가 많은 것들을 다함께 고려해서 결론을 내는 성향이라 보통 "뭘 하고 싶으신가요?" 물어보시면 뭐라고 대답해야할지 늘 난감합니다.

"내가 뭘 하면 좋을까? 계속 생각을 하다보니 사소한 거라도 하나 씩 둘 떠오르면서 좀 가닥이 잡히는거 같긴합니다..

최근에는 제 나름대로 하면 좋을거 같은걸 찾았고, 열심히 준비해서 회사에서 성과를 내보려고 합니다.

또한 과거에 만들던 개인 프로젝트를 다시 진행하고 있어요.

저번에 Next.js 15버전으로 올려서 RSC 도입까지 해둔 상태에서 좀 방치해두었는데 최근에 결제시스템 붙이는 것 부터 다시 하고 있습니다. TossPayments 결제모듈 연동을 진행 중입니다.

오늘은 firebase 말고 요즘 supabase 가 하도 핫하다고해서 supabase 마이그레이션을 해보면서 공부 중입니다.

멈출 수 없는 기차에 타버렸다.

요즘 상황과 제 마음이 딱 이거인거 같습니다. "멈출수 없다."

이 중에 무엇 하나 멈출 수 없이 계속 굴러가야만 되는 상황이 되어버린거 같습니다.

헬스 - 우상향의 근성장 해야한다. 뱃살 빼고 지치지 않으려면 싫어도 달려야한다.
개발 - 회사 업무 잘하고, 성과 내고 계속 프로젝트해서 최고가 되어야 한다.
재테크 - 수입 늘려야한다. 주식, 앱테크, 블로그, 카드테크 등 밥그릇 찾고 돈 되는건 다 해야한다.
연애 - 지속 가능한 긍정적인 관계 구축하고 미래를 준비해야한다. 그것을 위한 함께 즐길 다양한 콘텐츠 늘려야한다.

열심히 하면 어떻게든 되겠죠 호호..

맥북 아이폰 화면 미러링 방법 - AirPlay 사용하기 (iOS 18 Beta2, macOS Sequoia)

snowman95 — Sun, 17 Nov 2024 16:08:23 +0900

맥북에서 아이폰 화면 미러링하는 방법

AirPlay 사용하기 (iOS 18 Beta2, macOS Sequoia)

새로운 AirPlay 기능

iOS 18 Beta2와 macOS Sequoia 부터 향상된 AirPlay 기능 제공
기존 동일 Wi-Fi 네트워크 제약 없이 근거리에서 직접 연결 가능
더 낮은 지연시간과 향상된 화질 제공
블루투스를 통한 자동 기기 감지 지원

준비사항

iPhone: iOS 18 Beta2 이상 설치
MacBook: macOS Sequoia 이상 설치 (Beta 2 이상이었는데 15.1이 정식 출시됨)
두 기기의 블루투스 활성화

연결 방법

Mac 에서 미러링 앱을 실행합니다. 그러면

장점

Wi-Fi 네트워크 연결 불필요
향상된 지연 시간
더 안정적인 연결
고화질 미러링 지원
자동 기기 감지

제한사항

일부 기기에서 지원되지 않을 수 있음

지원되는 iPhone 모델

iPhone XR 이상
iPhone XS/XS Max 이상
iPhone 11 시리즈 이상

지원되는 Mac 모델

MacBook Air (2018년 이상)
MacBook Pro (2018년 이상)
iMac (2019년 이상)
iMac Pro (2017년)
Mac Pro (2019년 이상)
Mac mini (2018년 이상)
Mac Studio (전체 모델)

react-native - 애니메이션과 스레드 이해

snowman95 — Fri, 15 Nov 2024 17:38:15 +0900

React Native의 주요 스레드는 3가지입니다.

JS 스레드

React 앱이 있고, API 호출과 터치 이벤트가 일어나는 곳
네이티브 지원 뷰에 대한 업데이트는 일괄 처리되어 프레임 마감일전에 이벤트 루프의 각 반복이 끝날 때 네이티브 코드에 전달됨
너무 무거운 컴포넌트를 리렌더링 할 때 100ms 보다 오래걸리면 JS로 제어되는 애니메이션은 정지된 것 처럼 보일 수 있음
보통 Navigator 전환 과정에서 발생함. 전환은 JS 스레드에 의해 제어되기 때문.
JS 스레드가 바쁘면 네이티브 터치가 동작하지 않을 수 있음.

메인 스레드(네이티브 스레드)

UI 렌더링 담당
애니메이션 프레임이 실행되는 스레드
기본적으로 모든 애니메이션은 메인 스레드에서 실행되는 거고, JS 스레드에서는 동적인 값을 통해 애니메이션을 제어할 때만 사용 됩니다.

백그라운드 스레드

이미지 처리, 네트워크 요청 등 무거운 작업 처리

네비게이터 전환이 느린 경우

InteractionManager 사용하는 것은 좋은 접근방법이 될 수 있지만, 애니메이션 중에 작업 지연시키기에 사용자 경험 비용이 높다면. LayoutAnimation 을 고려해보는게 좋습니다.

Animated API 는 사용자가 useNativeDriver 옵션을 사용하여 애니메이션 프레임에서 네이티브 코드를 호출할 수 있게 해주는데
이 옵션을 사용하지 않는 한 JS 스레드에서 각 키 프레임을 주문형으로 계산합니다.

항상 useNativeDriver:true 로 쓰면 되지 않는가 싶지만, 오직 transform과 opacity 같은 특정 스타일 속성만 지원됩니다.
레이아웃 관련 애니메이션(width, height, position 등)은 네이티브 드라이버로 처리할 수 없습니다
JS에서 동적으로 애니메이션 값을 변경해야 하는 경우에는 사용할 수 없습니다

LayoutAnimation

Core Animation 을 활용하며 JS스레드와 메인스레드 영향 받지 않습니다.
- Core Animation은 iOS의 메인 스레드(UI 스레드)에서 실행되는 프레임워크입니다.
- 최적화가 잘 되어있어 메인 스레드에 부하를 거의 주지 않고 하드웨어 가속을 활용합니다.
즉시 실행되는 정적 애니메이션에만 작동합니다.
중단이 가능해야 하는 경우 Animated API 를 사용해야 합니다.
이것을 사용하는 대표적인 예시는 모달에서 애니메이션 적용할 때 입니다.

화면에서 뷰를 이동하면(스크롤, 이동, 회전) UI 스레드

이미지 위에 투명 배경이 있는 텍스트 배치, 각 프레임에서 뷰를 다시 그리기 위해 알파 합성이 필요한 경우 shouldRasterizeIOS 속성을 활성화하면 renderToTextureAndroid 이 작업에 큰 도움 줌
과도하게 사용시 메모리 사용량 크게 증가함

이미지 크기를 애니메이션화하면 UI 스레드

iOS에서 Image 구성 요소의 너비나 높이를 조정할 때마다 원본 이미지에서 다시 자르고 크기를 조정합니다. 이는 특히 큰 이미지의 경우 매우 비쌀 수 있습니다.
대신 transform: [{scale}]style 속성을 사용하여 크기를 애니메이션화합니다. 이를 수행할 수 있는 예는 이미지를 탭하여 전체 화면으로 확대할 때입니다.

구성요소 터치시 구성요소의 onPress 내에서 불투명도/하이라이트를 조정한다고 했을때 onPress 가 반환될 때까지 해당 효과를 볼 수 없을 것입니다. 이 경우도 JS 스레드가 바쁠 경우 많은 작업과 몇 개의 프레임이 삭제될 수 있기 때문이며. 이럴 때 requestAnimationFrame 을 사용하여 애니메이션이 중단되지 않도록 합니다.
requestAnimationFrame 를 사용하면 여전히 JS 스레드에서 실행이 되지만, JS 작업을 다음 프레임으로 연기하여 현재 프레임의 애니메이션이 방해받지 않도록 하는 것입니다.

  handleOnPress() {
    // 애니메이션 중단 방지
    requestAnimationFrame(() => {
      this.doExpensiveAnimation();
    });
  }

느린 네비게이터

Navigator 애니메이션은 JS 스레드로 제어됩니다. (예를 들어 스텍에서 스와이프)
만약 JS 스레드가 바빠서 끊김이 발생하면, JS 기반 애니메이션을 메인 스레드로 보내야 합니다.
React Navigation 라이브러리는 네이티브 구성 요소와 Animated 라이브러리를 사용해서 메인(네이티브) 스레드에서 실행되는 최소 60FPS 애니메이션을 제공합니다.

오프스레드

RN 에서는 이미지 디코딩은 메인 스레드가 아닌 다른 스레드에서 수행됩니다.
React Native는 백그라운드 스레드에서 이미지 디코딩을 수행합니다. 이는 메인 UI 스레드의 블로킹을 방지하고 앱의 성능과 반응성을 향상시키기 위한 설계입니다.
백그라운드 스레드는 메인 스레드와 별개로 동시에 실행되는 작업 단위입니다. 주로 시간이 많이 걸리는 작업(이미지 처리, 네트워크 요청 등)을 처리하여 메인 스레드의 부하를 줄이고 UI 응답성을 유지하는 데 사용됩니다.
이미지가 아직 다운로드되지 않은 경우를 위해 디코딩하는 동안 몇 개의 프레임에 대한 플레이스홀더를 표시해야 될 수 있습니다.

참고

모든 애니메이션에 대해 useNativeDriver 를 활성화하여 네이티브 스레드로 실행하면 JS 스레드가 바쁠때 애니메이션이 프레임을 건너뛰는 현상에 대해 전혀 걱정하지 않아도 되지 않을까 싶지만, useNativeDriver 는 transform과 opacity 같은 특정 스타일 속성만 지원됩니다.
width, height, top, left 등 요소의 레이아웃(크기나 위치)을 직접 변경하는 애니메이션 속성들은 Animated.View에서 useNativeDriver: true로 처리할 수 없습니다.

리액트네이티브에 Animated API 와 별개로
모든 View에 사용될 애니메이션 전역 구성에 사용되는 LayoutAnimation 라는게 존재하는데 이것은 Core Animation 를 사용합니다.
Core Animation은 iOS의 메인 스레드(UI 스레드)에서 실행되는 프레임워크입니다. Core Animation은 메인 스레드에서 실행되지만, 실제 애니메이션 계산과 렌더링은 별도의 렌더 서버 프로세스에서 처리됩니다. 따라서 메인 스레드가 바쁘더라도 애니메이션이 끊기지 않고 부드럽게 실행될 수 있습니다.
위에서 말한 레이아웃 속성(크키,위치)를 변경하는 것과는 완전 다른 이야기입니다. 헷갈리면 안됩니다.
특정 속성 추가하거나 계산하여 직접 애니메이션 하지 않고도 Flexbox 레이아웃 업데이트 수행하는데 유용. 더보기 확장 같은 상위 부모 요소에 영향 줄 수 있는 경우에 유용.
Android에서는 LayoutAnimation 을 사용하려면 UIManager.setLayoutAnimationEnabledExperimental(true)를 먼저 설정해야 합니다. iOS의 Core Animation과 같은 최적화는 없지만, 기본적인 레이아웃 애니메이션은 동작합니다.
(편집됨)

chatGPT는 애니메이션 사용에 대해 이렇게 권장합니다.

단순한 애니메이션의 경우 Animated + useNativeDriver 사용
복잡한 애니메이션이나 제스처가 필요한 경우 Reanimated 사용 고려

react-native - expo sdk52 11/13 출시

snowman95 — Thu, 14 Nov 2024 20:06:55 +0900

주요 업데이트 내용 (2024년 11월 13일 출시)

1. New Architecture 도입

모든 새로운 프로젝트에서 New Architecture가 기본적으로 활성화됨
newArchEnabled: true가 app.json에 기본 설정됨
기존 프로젝트는 선택적으로 적용 가능
SDK 53부터는 기본 활성화될 예정이며, 2025년에는 기존 아키텍처 지원 중단 예정

2. 주요 라이브러리 업데이트

React Native 0.76 버전 포함
iOS 최소 지원 버전이 13.4에서 15.1로 상향
Android minSdkVersion 23에서 24로, compileSdkVersion 34에서 35로 상향

3. 새로운 라이브러리 출시

expo-video: expo-av를 대체하는 안정화된 비디오 라이브러리
expo-audio: 새로운 오디오 라이브러리 (베타)
expo-file-system/next: 개선된 파일 시스템 API (베타)
expo-live-photo: iOS Live Photos 지원

4. expo-splash-screen 개선

Android 12+ 스플래시 스크린 API 적용
다크 모드 공식 지원
간단한 페이드 전환 효과 추가 가능
안드로이드에서 전체 화면 스플래시 이미지 지원 중단

5. 개발자 도구 개선

React Native DevTools가 기존 JavaScript 디버거 대체
DOM Components 도입으로 웹 컴포넌트의 점진적 마이그레이션 지원
expo-image v2의 새로운 useImage 훅 도입

6. 주요 제거 및 변경사항

Expo Go에서 JSC 지원 중단 (Hermes만 지원)
expo-camera/legacy, expo-sqlite/legacy 제거
expo-barcode-scanner 제거 (expo-camera로 통합)
Expo Go 안드로이드에서 만보계(Pedometer) 지원 중단

Expo SDK 52 아키텍처 변경사항

1. 개발 클라이언트 아키텍처 개선

이전 버전의 문제점

expo-dev-client를 별도로 설치하고 설정해야 했음
개발 환경과 프로덕션 환경의 차이가 컸음
설정 과정이 복잡하고 오류가 발생하기 쉬웠음

SDK 52의 개선사항

Expo GO 앱에 개발 클라이언트가 통합됨
별도의 설정 없이 바로 개발 시작 가능
실제 디바이스에서 테스트가 더욱 쉬워짐
개발 환경과 프로덕션 환경의 일관성 향상

2. Metro 번들러 업데이트

이전 버전의 한계

느린 빌드 속도
제한적인 캐싱 시스템
모호한 에러 메시지
설정의 어려움

SDK 52의 개선사항

Metro 번들러 0.76.x 버전으로 업그레이드
- 빌드 속도 최대 50% 향상
- 메모리 사용량 최적화
- 더 정확하고 이해하기 쉬운 에러 메시지
향상된 캐싱 시스템
- 증분 빌드 지원
- 더 효율적인 모듈 캐싱
HMR(Hot Module Replacement) 성능 개선

3. 새로운 플러그인 시스템

이전 버전의 문제점

수동으로 플러그인을 설정해야 했음
네이티브 모듈 연동이 복잡했음
의존성 충돌이 자주 발생

SDK 52의 개선사항

자동화된 플러그인 설정
- 플러그인 설치만으로 자동 설정
- 의존성 충돌 자동 해결
네이티브 모듈 자동 링킹
- react-native link 명령어 불필요
- iOS와 Android 설정 자동화
플러그인 생태계 확장
- 더 많은 서드파티 플러그인 지원
- 커스텀 플러그인 개발 용이

4. 설정 시스템 개선

이전 버전의 한계

app.json만으로 제한적인 설정
정적 설정만 가능
환경별 설정 관리의 어려움

SDK 52의 개선사항

통합 설정 시스템
- app.json과 app.config.js/ts 통합 지원
- JavaScript/TypeScript로 동적 설정 가능
환경별 설정 관리
- 개발/스테이징/프로덕션 환경 구분
- 환경변수 통합 지원
- 보안 강화
설정 상속과 재사용
- 공통 설정 재사용 가능
- 프로젝트별 설정 오버라이드 지원

5. 빌드 시스템 현대화

이전 버전의 한계

느린 빌드 프로세스
제한적인 커스터마이징
복잡한 배포 과정

SDK 52의 개선사항

EAS (Expo Application Services) 개선
- 빌드 캐싱 시스템 강화
- 병렬 빌드 지원
- 빌드 시간 최대 40% 단축
커스텀 빌드 설정
- 상세한 빌드 설정 가능
- 네이티브 코드 수정 지원
- 다양한 빌드 프로필 지원
자동화된 배포
- 스토어 배포 자동화
- OTA 업데이트 개선
- 롤백 기능 강화

마이그레이션 가이드

준비사항

프로젝트 백업
의존성 패키지 검토
네이티브 코드 수정사항 확인

단계별 마이그레이션

package.json 업데이트
expo-dev-client 설정 제거
Metro 설정 업데이트
플러그인 재설정
환경 설정 파일 구조 개선

주의사항

기존 커스텀 네이티브 코드 호환성 검토
사용 중인 라이브러리 호환성 확인
점진적 마이그레이션 권장결론SDK 52는 Expo의 가장 큰 아키텍처 변화 중 하나로, 개발자 경험을 크게 개선했습니다. 특히 개발 환경 설정의 단순화, 빌드 성능 향상, 그리고 더욱 유연해진 설정 시스템은 React Native 개발을 한층 더 효율적으로 만들었습니다.

iOS 최소 지원 버전이 13.4에서 15.1로 상향???

iOS 15.1 미만 버전을 사용하는 기기에서는 앱을 설치하거나 실행할 수 없습니다.
App Store에서 앱을 검색할 때 iOS 15.1 미만 버전의 기기에서는 앱이 표시되지 않습니다
개발자가 앱을 빌드할 때 iOS 15.1 이상의 API만 사용할 수 있습니다
참고로 2024년 3월 기준 iOS 사용자의 약 98%가 iOS 15.1 이상을 사용하고 있어서 대부분의 사용자에게는 영향이 없습니다. 하지만 매우 오래된 iOS 기기를 사용하는 소수의 사용자는 앱을 사용할 수 없게 됩니다.
이전 버전인 SDK 51에서는 iOS 13.4까지 지원했었는데, SDK 52에서 이 제한이 상향되었습니다.

react-native 에서 tailwind 문법으로 스타일 적용하기 (twrnc 라이브러리)

snowman95 — Wed, 13 Nov 2024 23:14:07 +0900

https://www.npmjs.com/package/twrnc
https://github.com/jaredh159/tailwind-react-native-classnames

twrnc

simple, expressive API for tailwindcss + react-native. Latest version: 4.6.0, last published: 6 days ago. Start using twrnc in your project by running `npm i twrnc`. There are 47 other projects in the npm registry using twrnc.

www.npmjs.com

react-native 에서 tailwind css 문법으로 스타일링 가능
매우 빠름: 이 벤치마크 에 따르면 모든 RN 스타일링 라이브러리 중 가장 뛰어난 성능을 보입니다 .

인텔리센스 설정

React Native - Tailwind CSS autocomplete in VSCode for twrnc package
https://stackoverflow.com/questions/71681367/react-native-tailwind-css-autocomplete-in-vscode-for-twrnc-package

tailwind.config.js 파일을 반드시 만들어줘야 합니다.

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./app/**/*.{js,jsx,ts,tsx}",
    "./components/**/*.{js,jsx,ts,tsx}"
  ],
}

vs-code settings.json 설정 변경

"tailwindCSS.classAttributes": [
 "class",
  "className",
  "ngClass",
  "class:list",
  "style" // 추가
],

"tailwindCSS.experimental.classRegex": [
  ["tw`([^`]*)`", "[`'\"]([^'\"]*)[`'\"]"],
  ["tw=\"([^\"]*)\"", "[`'\"]([^'\"]*)[`'\"]"],
  ["tw={\"([^\"]*)}\"", "[`'\"]([^'\"]*)[`'\"]"],
  ["tw\\.\\w+`([^`]*)`", "[`'\"]([^'\"]*)[`'\"]"],
  ["tw\\(.*?\\)`([^`]*)`", "[`'\"]([^'\"]*)[`'\"]"],
  ["tw.style\\(([^)]*)\\)", "'([^']*)'"]
]

내용 추가 예정...

VoidZero - 자바스크립트를 위한 차세대 툴체인 소개

snowman95 — Mon, 11 Nov 2024 15:41:56 +0900

VoidZero - 자바스크립트 개발의 새로운 혁신

개요

Vue.js의 창시자 Evan You가 자바스크립트 생태계에 새로운 혁신을 가져올 VoidZero Inc.를 설립했습니다. Accel이 주도한 시드 투자를 통해 460만 달러를 유치했으며, 자바스크립트를 위한 차세대 통합 개발 툴체인을 구축하는 것을 목표로 하고 있습니다.

VoidZero가 해결하려는 문제

현재 자바스크립트 생태계가 직면한 가장 큰 문제는 파편화입니다

수많은 서드파티 의존성 관리
다양한 도구들의 호환성 문제
중복된 작업으로 인한 성능 저하
복잡한 설정과 구성 관리

개발자들은 이러한 문제들을 근본적으로 해결하기 위해 VoidZero가 탄생했습니다.

핵심 특징

1. 통합된 개발 환경

모든 개발 작업에서 동일한 AST 사용
구문 분석, 변환, 린팅, 포매팅, 번들링 등의 통합
중복 작업 제거로 효율성 극대화

2. 최고 수준의 성능

네이티브 언어 기반 컴파일
최적화된 병렬 처리
낮은 오버헤드의 JS 플러그인 시스템

3. 유연한 모듈성

독립적으로 사용 가능한 컴포넌트
고수준의 커스터마이징 지원
플러그인 기반 확장성

4. 런타임 독립성

특정 런타임에 종속되지 않는 설계
모든 환경에서 일관된 개발 경험
크로스 플랫폼 지원

현재까지의 성과

VoidZero는 이미 인상적인 성과를 보여주고 있습니다:

도구	성능 향상
oxc-parser	SWC 대비 3배 빠른 파서
oxc-resolver	enhanced-resolve 대비 28배 빠른 리졸버
oxc-transform	SWC 대비 4배 빠른 변환기
oxlint	ESLint 대비 50-100배 빠른 린터
Rolldown	esbuild보다 빠른 번들러 (알파)

주요 사용 기업

이미 많은 글로벌 기업들이 VoidZero의 도구들을 채택하고 있습니다:

OpenAI (ChatGPT 웹 클라이언트)
Google
Apple
Microsoft
Visa
Shopify
Cloudflare
기타 주요 테크 기업들

향후 계획

2024년

Rolldown 안정화
Vite의 통합 번들러로 Rolldown 도입
Rolldown 기반 Vite 알파 버전 출시

2025년

Oxc 추가 기능 개발 (최소화, 포매팅)
Vite 생태계의 Rolldown/Oxc 전환
엔터프라이즈 솔루션 출시

의의와 전망

VoidZero의 출범은 단순한 새로운 도구의 등장이 아닌, 자바스크립트 개발 환경의 패러다임 전환을 의미합니다. 이미 검증된 Vite의 성공을 기반으로, 더 근본적인 문제 해결을 위한 도전을 시작했다는 점에서 큰 의미가 있습니다.

특히 주목할 점은 오픈소스로 운영되면서도 엔터프라이즈급 요구사항을 충족시키는 방향성입니다. 이는 커뮤니티 중심의 발전과 상업적 지속가능성을 동시에 추구하는 현대적인 오픈소스 비즈니스 모델의 좋은 사례가 될 것으로 기대됩니다.

원문 링크

void(0)

We are building the next generation of JavaScript tooling

voidzero.dev

옵시디언(obsidian) 플러그인 총정리

snowman95 — Mon, 11 Nov 2024 12:23:29 +0900

옵시디언 플러그인 가이드

옵시디언의 다양한 플러그인들을 소개합니다. 플러그인은 기능별로 분류되어 있으며, 각 플러그인의 평가는 다음과 같은 기준으로 표시됩니다:

⭐⭐⭐ : 필수 플러그인
⭐⭐ : 상황에 따라 매우 유용한 플러그인
⭐ : 선택적으로 사용할만한 플러그인
: 대체 플러그인이 있거나 추천하지 않는 플러그인

파일 관리 플러그인

Recent Files ⭐⭐⭐

최근에 열어본 파일들을 빠르게 찾아볼 수 있는 필수 플러그인입니다. 사이드바에 최근 파일 목록을 표시하고, 단축키로 빠르게 접근할 수 있습니다.

주요 기능:

최근 열어본/수정한 파일 목록 표시
즐겨찾기 파일 핀 고정
파일 미리보기 제공
커스텀 정렬 옵션

Auto Note Mover ⭐⭐

노트를 자동으로 정리해주는 강력한 플러그인입니다. 설정한 규칙에 따라 노트를 적절한 폴더로 자동 이동시켜줍니다.

활용 예시:

태그별로 다른 폴더에 정리
제목 패턴에 따라 분류
프로젝트별 자동 정리
데일리 노트 자동 정리

Templater ⭐⭐⭐

단순한 템플릿 이상의 강력한 기능을 제공하는 플러그인입니다. JavaScript를 활용한 동적 템플릿 생성이 가능합니다.

핵심 기능:

동적 변수 사용
JavaScript 실행
조건부 템플릿
사용자 정의 함수
외부 API 연동

Local Images Plus ⭐⭐

외부 이미지를 자동으로 로컬로 저장해주는 유용한 플러그인입니다. 웹에서 복사한 이미지를 자동으로 관리해줍니다.

주요 기능:

클립보드 이미지 자동 저장
외부 URL 이미지 다운로드
이미지 경로 자동 수정
중복 이미지 처리

검색/쿼리 플러그인

Dataview ⭐⭐⭐

노트를 데이터베이스처럼 활용할 수 있게 해주는 강력한 플러그인입니다. SQL과 유사한 쿼리 언어로 노트들을 동적으로 필터링하고 표시할 수 있습니다.

활용 사례:

프로젝트 진행 상황 대시보드
태그별 노트 자동 정리
데일리 노트 요약
할 일 목록 자동 집계

Search on Internet ⭐⭐

선택한 텍스트를 다양한 검색 엔진에서 바로 검색할 수 있는 플러그인입니다.

특징:

커스텀 검색 엔진 추가 가능
단축키로 빠른 검색
여러 검색 엔진 동시 검색
검색 결과 임베딩

Omnisearch ⭐⭐⭐

기본 검색을 훨씬 강력하게 개선해주는 플러그인입니다. 퍼지 검색과 실시간 미리보기를 제공합니다.

주요 기능:

실시간 검색 결과
파일 내용 미리보기
검색 결과 하이라이트
정확도 기반 정렬
태그/링크 검색 지원

Smart Search ⭐⭐

검색 결과를 더 스마트하게 보여주는 플러그인입니다. 컨텍스트를 고려한 검색이 가능합니다.

특징:

검색어 주변 컨텍스트 표시
검색 결과 그룹화
검색 히스토리 관리
고급 필터링 옵션

노트 편집 플러그인

Editor Syntax Highlight ⭐⭐⭐

코드 블록에 구문 강조 기능을 추가해주는 필수 플러그인입니다. 다양한 프로그래밍 언어를 지원합니다.

특징:

40개 이상의 언어 지원
커스텀 테마 적용 가능
라인 넘버링
코드 폴딩 기능

Advanced Tables ⭐⭐⭐

마크다운 테이블 작성을 획기적으로 개선해주는 플러그인입니다.

주요 기능:

테이블 자동 정렬
셀 병합과 분할
수식 계산 지원
테이블 정렬 및 필터링
CSV 가져오기/내보내기

Better Word Count ⭐⭐

글자 수, 단어 수를 더 정확하게 세어주는 플러그인입니다.

제공 정보:

전체 글자 수
선택 영역 글자 수
읽기 예상 시간
문단/문장 수 통계

Outliner ⭐⭐

계층적 구조의 문서를 쉽게 작성할 수 있게 도와주는 플러그인입니다.

핵심 기능:

들여쓰기 자동 관리
항목 접기/펼치기
드래그앤드롭으로 구조 변경
단축키로 빠른 편집

Natural Language Dates ⭐⭐

자연어로 날짜를 입력할 수 있게 해주는 편리한 플러그인입니다.

활용:

"내일", "다음 주 월요일" 등 자연어 인식
날짜 자동 변환
상대적 날짜 표현
데일리 노트 연동

화면 구성 플러그인

Sliding Panes ⭐⭐⭐

노트를 좌우로 슬라이딩하며 볼 수 있게 해주는 플러그인입니다. 여러 노트를 동시에 비교하며 볼 때 매우 유용합니다.

특징:

노트 간 부드러운 전환
여러 노트 동시 보기 최적화
스크롤바 개선
노트 제목 회전 표시

Minimal Theme Settings ⭐⭐

미니멀 테마를 더욱 세밀하게 커스터마이징할 수 있게 해주는 플러그인입니다.

커스텀 옵션:

폰트 크기와 종류
여백과 간격 조정
색상 스키마 변경
레이아웃 조정

Style Settings ⭐⭐⭐

테마와 CSS 스니펫을 GUI로 쉽게 관리할 수 있게 해주는 플러그인입니다.

주요 기능:

테마별 설정 통합 관리
실시간 미리보기
색상 팔레트 관리
설정 프리셋 저장/불러오기

Hider ⭐⭐

인터페이스 요소를 선택적으로 숨길 수 있게 해주는 플러그인입니다.

숨길 수 있는 요소:

상태바
리본 메뉴
파일 탐색기 버튼
불필요한 UI 요소

Fullscreen Mode ⭐

집중이 필요할 때 전체화면으로 전환할 수 있는 플러그인입니다.

특징:

모든 UI 요소 숨기기
단축키로 빠른 전환
읽기/쓰기 모드 전용 설정
자동 전체화면 규칙 설정

일정/작업 관리 플러그인

Calendar ⭐⭐⭐

데일리 노트와 연동되는 캘린더 플러그인입니다. 직관적인 일정 관리가 가능합니다.

주요 기능:

월간/주간 캘린더 뷰
데일리 노트 자동 생성
일정 미리보기
다중 캘린더 지원
반복 일정 설정

Tasks ⭐⭐⭐

마크다운 기반의 강력한 할 일 관리 플러그인입니다.

특징:

체크리스트 고급 기능
마감일 및 우선순위 설정
반복 작업 관리
진행 상태 추적
필터링과 정렬

Kanban ⭐⭐

칸반 보드 스타일로 작업을 관리할 수 있는 플러그인입니다.

기능:

드래그앤드롭 카드 이동
레인 커스터마이징
작업 상태 추적
레이블과 태그 지원
데드라인 표시

Day Planner ⭐⭐

하루 일정을 시간별로 계획하고 추적할 수 있는 플러그인입니다.

활용:

시간별 일정 계획
진행 상황 실시간 표시
남은 시간 알림
일정 통계 제공

Periodic Notes ⭐⭐

주간, 월간, 분기별 노트를 체계적으로 관리할 수 있는 플러그인입니다.

특징:

다양한 주기의 노트 생성
템플릿 지원
자동 링크 생성
리뷰 시스템 구축

입력 지원 플러그인

Various Complements ⭐⭐⭐

단어 자동완성 기능을 제공하는 강력한 플러그인입니다.

주요 기능:

현재 파일 기반 자동완성
전체 볼트 기반 제안
사용자 정의 사전
다국어 지원
이모지 자동완성

Quick Add ⭐⭐⭐

다양한 입력 작업을 자동화할 수 있는 플러그인입니다.

활용:

템플릿 빠른 삽입
매크로 실행
커스텀 명령어 생성
캡처 기능

Text Expander ⭐⭐

단축어를 입력하면 미리 정의된 텍스트로 자동 확장해주는 플러그인입니다.

특징:

커스텀 단축어 설정
동적 확장 지원
날짜/시간 변수
스니펫 관리

Emoji Toolbar ⭐

이모지를 쉽게 삽입할 수 있는 툴바를 제공합니다.

기능:

이모지 검색
자주 사용하는 이모지 즐겨찾기
단축키 지원
최근 사용 이모지

Auto Link Title ⭐⭐

URL을 붙여넣으면 자동으로 제목을 가져와 링크를 생성합니다.

특징:

웹페이지 제목 자동 추출
마크다운 링크 포맷팅
일괄 변환 지원
커스텀 포맷 설정

설정 관리 플러그인

Settings Search ⭐⭐⭐

설정 메뉴를 쉽게 검색할 수 있게 해주는 플러그인입니다.

주요 기능:

실시간 설정 검색
설정 항목 미리보기
카테고리별 필터링
최근 검색 기록

Sync Settings ⭐⭐

여러 기기 간 설정을 동기화할 수 있게 해주는 플러그인입니다.

특징:

플러그인 설정 동기화
테마 설정 동기화
단축키 설정 동기화
백업 및 복원

Commander ⭐⭐⭐

커스텀 명령어와 단축키를 관리할 수 있는 플러그인입니다.

기능:

명령어 그룹화
단축키 커스터마이징
툴바 버튼 추가
매크로 생성

Plugin Groups ⭐⭐

플러그인을 그룹으로 관리하고 한 번에 켜고 끌 수 있습니다.

활용:

상황별 플러그인 그룹
자동 활성화/비활성화
그룹별 설정 관리
성능 최적화

Quick Settings ⭐⭐

자주 사용하는 설정에 빠르게 접근할 수 있는 플러그인입니다.

특징:

설정 즐겨찾기
빠른 설정 토글
커스텀 설정 메뉴
단축키 지원

[앱테크] 머니워크 월 수익 7,615원, 현금화 약 4개월

snowman95 — Sun, 10 Nov 2024 21:15:07 +0900

특징

100걸음당 2포인트를 적립하며, 최대 5000걸음까지 100포인트를 모을 수 있습니다. 초대 코드 입력 시 1000포인트를 적립해줍니다.
걷고나서 버튼 눌러야 포인트 적립 되는데 계속 광고가 뜹니다. 그러므로 살짝 스크롤 내려서 버튼 누르면 수월합니다.
머니팜 키우기: Lv6 까지 다 키우면 3000p. 꽤 오래걸립니다. 1달은 걸릴 듯 합니다.
챌린지 : 챌린지는 7일 모두 걷기를 성공해야 이득입니다. 하루라도 빼먹으면 안하는 게 낫습니다.
1:1 걷기대결 : 평균 걸음수가 비슷한 사람과 3일 간 대결을 하여 더 많이 걸은 사람이 포인트를 얻습니다. 50p 정도 됩니다.

루틴 (하루 220p~)

출석체크 (광고있음)
일 최대 20p
1주 연속 100p, 2주 연속 200p, 3주 연속 500p, 4주 연속 1000p
만보기
- 50걸음 당 1p. 최대 200p (팝업 광고 뜸. 살짝 스크롤 내려서 누르면 됨)
- 걸음수에 따라 랜덤 포인트 적립 (1000 단위로 10000까지 있음. 광고X)
OX 퀴즈
머니팜 키우기 + 서브 퀘스트
숨겨진 미션 포인트 적립 (갑자기 뜸. 광고보면 포인트 줌)
1:1 걷기 대결 : 승리 시 50p
챌린지 (비추)
- 7000 걸음 챌린지, 10000 걸음 챌린지, 12000 걸음에 대한 챌린지 있음
- 6일 동안 모두 달성해야만 이득. 5일 달성시 본전. 그렇지 못하면 손해
- 저는 버그로 한 번씩 달성을 못하거나 바쁠때 달성을 못해서 계속 손해보고 있습니다. 차라리 안하는게 나을 수도 있어요.

포인트 교환 (현금:포인트=1:1.15)

약 26000 머니워크포인트 -> 30000 네이버포인트 입찰

다운로드

인앱 이미지

홈 화면

건강 퀴즈

머니팜

숨겨진 포인트 발견

챌린지

걷기 대결 - 승리 시

옵시디언(obsidian) - 테이블 플러그인을 알아보자

snowman95 — Sun, 10 Nov 2024 11:58:56 +0900

테이블

Obsidian에서 사용할 수 있는 여러 테이블 관련 플러그인들이 있습니다. 주요한 것들을 소개해드리겠습니다.

Advanced Tables

가장 인기 있는 테이블 플러그인
탭키로 열 이동
자동 정렬
테이블 서식 자동 수정
기본적인 마크다운 테이블 편집 기능 강화

Table Extended

고급 테이블 기능 제공
셀 병합 지원
멀티라인 셀 지원
사용자 정의 스타일링

Table Generator

GUI로 테이블 생성 가능
드래그 앤 드롭으로 열/행 추가/삭제
CSV 파일 임포트 지원
DataView
노트들의 메타데이터를 테이블 형태로 표시
SQL과 유사한 쿼리 기능
동적 테이블 생성
데이터 필터링과 정렬
Sortable
테이블 정렬 기능 추가
클릭으로 열 기준 정렬 가능

설치 방법

Obsidian 설정 열기
커뮤니티 플러그인 메뉴로 이동
검색창에서 원하는 플러그인 검색
Install 버튼 클릭 후 Enable

수식 테이블

테이블의 특정 행에 수식을 넣어서 계산도 되면 좋을 거 같은데요?
계산 기능이 포함된 테이블 플러그인들을 소개해드리겠습니다.

Table Calculator

마크다운 테이블에서 수식 계산 지원
Excel과 유사한 수식 문법 사용
SUM, AVERAGE 등 기본적인 수식 함수 지원
예시:

DataView

JavaScript 기반의 계산 기능 제공
복잡한 수식과 조건부 계산 가능
예시:

Spreadsheet

Excel과 유사한 스프레드시트 인터페이스
풍부한 수식 기능
셀 참조 지원
차트 생성 가능

참고사항

대부분의 계산 플러그인은 실시간 계산을 지원하지만, 일부는 수동 새로고침이 필요할 수 있습니다
복잡한 수식을 사용할 경우 문서 로딩 시간이 길어질 수 있습니다.

[앱테크] 쉽고 간편하게 즐기는 퀴즈형 앱테크 '마이비' (월 수익 18000포인트, 현금화 약 15일 주기)

snowman95 — Sat, 9 Nov 2024 19:30:04 +0900

특징

간편한 가입 절차: 복잡한 절차 없이 간단한 비밀번호 설정만으로 회원가입이 가능합니다.
소비TI 검사: 가입 후 간단한 소비 성향 검사를 통해 자신의 소비 유형을 파악하고, 추가 포인트를 받을 수 있습니다.
다양한 이벤트 참여: 설문형, 퀴즈형, 앱 설치형 등 다양한 이벤트를 통해 포인트를 적립할 수 있습니다.
뱃지 시스템: 설문 참여를 통해 뱃지를 획득하며, 보유한 뱃지 수에 따라 참여 가능한 이벤트가 늘어납니다.
친구 초대 보상: 친구를 초대하면 추가 포인트를 받을 수 있으며, 초대받은 친구도 보상을 받습니다.

루틴 (하루 약 600p, 월 수익 18000포인트, 현금화 약 15일 주기)

하루에 30~100p 정도되는 설문조사를 10개 가능.
광고시청 2회 후 설문조사 2회 추가 가능
그 외 이벤트 참여

포인트 교환 (현금:포인트=1.1:1, 혹은 1.3:1)

모바일 쿠폰 교환: 적립한 포인트로 편의점, 카페, 패스트푸드 등 다양한 브랜드의 모바일 쿠폰을 구매할 수 있습니다.
13000포인트 -> 10000네이버페이 포인트
타임딜 이벤트를 통해 11000포인트 -> 10000네이버페이 포인트 교환 가능
위믹스 코인 전환: 포인트를 위믹스 코인으로 전환하여 현금화하거나, 다른 용도로 활용할 수 있습니다.

다운로드

MyB 마이비 - 쉽고 간편하게 즐기는 퀴즈형 앱테크 - Google Play 앱

MyB 마이비는 짧고 재미있는 퀴즈와 설문을 큰 보상으로 연결하는 퀴즈형 앱테크 입니다.

play.google.com

‎MyB 마이비 - 쉽고 간편하게 즐기는 퀴즈형 앱테크

‎단 1분의 퀴즈로 최대 포인트를 받을 수 있는 퀴즈형 앱테크 마이비! 지금 시작하세요! ■ 취향 퀴즈로 보상을 받으세요! - 재미있고 다양한 퀴즈로 나만의 취향을 발견하고, 포인트를 획득하

apps.apple.com

[앱테크] 걷기만 해도 10만 포인트! 최강 앱테크 '손목닥터9988' (월 수익 12000포인트, 현금화 약 13일)

snowman95 — Sat, 9 Nov 2024 19:14:39 +0900

특징

건강 습관 형성: 매일 기록, 챌린지, 운동 등을 통해 포인트를 적립하며, 이를 통해 건강한 생활 습관을 형성할 수 있습니다.
만보기 및 출석체크: 걷기와 출석체크를 통해 포인트를 쌓을 수 있으며, 꾸준한 활동을 장려합니다.
대사증후군 데이터 연동: 서울시 보건소에서 받은 대사증후군 검사 결과를 앱과 연동하여 혈당, 고지혈증, 고혈압 등 건강 상태를 관리할 수 있습니다.
포인트 활용: 적립한 포인트로 따릉이 쿠폰을 구매하거나, 서울페이로 전환하여 편의점, 병원, 서점 등 서울시 내 가맹점에서 사용할 수 있습니다.

이용 방법

회원가입: 손목닥터9988+ 앱을 다운로드하여 회원가입을 진행합니다.
스마트워치 연동: 갤럭시 워치, 애플 워치 등 개인 스마트워치를 앱과 연동하여 활동 데이터를 수집합니다.
활동 참여: 일일 걷기 목표 달성, 출석체크, 건강 기록 등을 통해 포인트를 적립합니다.
포인트 사용: 적립한 포인트를 활용하여 다양한 혜택을 누립니다.

루틴 (하루 460p, 월 수익 12000포인트, 현금화 약 13일)

앱 출석 체크 10p
하루 8천보 200p (꾸준히 걸으면 2주에 한번씩 500p 보너스)
식단 기록 50p
캐시 홈트 200p
드물게 가끔 뜨는 것들
- 건강카드 학습 50p
- 건강관리 목표 측정 결과 입력 100p

포인트 교환

서울페이 포인트로 1:1 교환 가능합니다.
다만 포인트는 최대 10만 포인트 까지만 적립이 가능합니다.

다운로드

손목닥터9988+ - 서울 시민 건강 관리 앱 - Google Play 앱

서울 시민이 99세까지 88(팔팔)하게 살 수 있도록 건강 활동을 지원합니다. 만보기, 챌린지로 얻은 포인트를 따릉이, 서울페이로 교환해보세요.

play.google.com

‎손목닥터9988+

‎손목닥터9988+는 서울시 시민이 99세까지 88(팔팔)하게 살 수 있도록 앱과 스마트 워치를 통해 건강 활동을 지원합니다. 손목닥터9988+는 이런게 좋아요! - 매일 기록, 챌린지, 운동 등으로 포인트

apps.apple.com

인앱 이미지

홈 화면

출석체크

몸무게 입력

식단 기록

건강카드 퀴즈

서울 페이 전환

옵시디언(obsidian) - 새 노트의 기본 저장 위치 변경하기

snowman95 — Sat, 9 Nov 2024 16:28:59 +0900

혹은 새 노트를 만들 위치 - 아래에 지정된 폴더 선택

그 아래에 있는 새 노트를 만들 폴더 - 폴더경로

/links 와 같은 폴더 경로로 지정해줍니다.

옵시디언(obsidian) - 첨부 파일(이미지)의 기본 저장 위치 변경하기

snowman95 — Sat, 9 Nov 2024 12:17:12 +0900

옵시디언에서 이미지를 붙여넣기 하면 루트 위치에에 이미지 파일이 쌓이게 됩니다.

이렇게 하면 지저분하기 때문에 폴더를 따로 만들어 첨부파일을 모으기 위해 아래와 같이 설정해줄 수 있습니다.

옵시디언의 preference 창을 열어줍니다. (맥북 기준으로 좌측 상단 Obsidian 클릭하면 나옴)

새 첨부 파일을 만들 위치 - 아래에 지정된 폴더를 선택해줍니다.

기본적으로 attachments 폴더로 이름이 지정되며 저는 그대로 사용하기로 했습니다.

첨부파일을 붙연허기 하면 아래와 같이 attachments 폴더 아래에 쌓이는 것을 확인하실 수 있습니다.

안드로이드폰을 맥북에 연결하는 법

snowman95 — Fri, 8 Nov 2024 22:43:33 +0900

안드로이드 폰을 맥북은 연결을 해도 반응하지 않네요 어떻게 해야할까요?

간단하게 파일 하나만 설치하면 해결됩니다.

https://android.p2hp.com/filetransfer/index.html

새로운 Windows용 Quick Share 앱 | Android

Windows용 Quick Share 앱을 다운로드하여 Android 기기와 Windows PC 간에 사진, 문서 등을 무선으로 공유하세요.

www.android.com

링크에서 다운로드 후 설치 -> 실행 후 usb 로 연결하시면 연결됩니다!

"개발자가 학습을 중단하는 방법: Expert Beginner의 부상" 리뷰

snowman95 — Sun, 3 Nov 2024 17:23:21 +0900

초보 전문가(Expert Beginner) 를 읽고

최근에 "초보 전문가(Expert Beginner)" 라는 글을 읽고나서 감명을 받았습니다.

그들은 우물 안의 개구리. 우리 지역 회사에서는 전문가 명함을 달고 있지만 사실 더 큰 세상에서 바라보면 명함만 전문가일 뿐 전문적이지 못한 사람들. 이 정도면 나는 고수다. 나는 잘해 라는 자기만의 생각에 빠져서 더 이상의 발전은 없는 사회 암적인 존재들을 뜻합니다.

저는 옛날부터 이런 사람들을 "자리 지킴이" 라고 부르는데요. 보통 대기업에 높은 직급에 있지만 무슨 일을 하는 지 알 수는 없는 그런 사람들을 그렇게 부르곤 했습니다. 본인이 하는 일이라곤 그저 자리를 키지고 있는 것 뿐인 사회의 암적인 존재들.

이 나이가 되어서야 가족이 생기고 가족을 지키려고 밥그릇을 수호하는 그들의 심정이 이해는 됩니다만, 사회의 암적인 존재라는 것에 대해서는 생각의 변함 없습니다. 그런 사람들이 새로운 시대에 자리 비켜줘야 나라가 돌아갈텐데요. 참 어려운 문제입니다.

근데 저도 나이 먹을 수록 현실에 안주하려고 하는 거 같고. 그런 사람이 되는거 같다는 생각이 많이 들면서 크게 반성하게 되었습니다.

이 게시물은 그 글을 읽고 간단히 요약한 글입니다.

전체 요약

일정 수준의 능력을 얻고 나서 학습을 멈추면 '초보 전문가(Expert Beginner)' 단계에 머물게 됩니다.

초보 전문가는 새로운 기술을 거부하고 자기 과신에 빠지는 경향이 있어 성장에 한계가 생깁니다.

이를 방지하려면 지속적인 학습과 피드백을 통해 기술 향상에 대한 열정을 유지해야 합니다.

초보 전문가가 조직에서 리더가 되면 학습과 혁신이 정체되고 비효율적인 관행이 자리 잡으며, 팀 전체의 성장이 멈춥니다.

이는 팀 내에서 유사한 태도의 사람들을 양산하며, 품질과 기술적 발전이 저하되는 결과로 이어집니다.

이를 막기 위해선 지속적 학습과 건강한 리더십이 필수적입니다.

자신의 정체와 비효율을 정당화하기 위해 사용하는 언어와 사고방식을 다룹니다. 그들은 기본적으로 자신의 아이디어의 가치를 보도록 누군가를 설득하거나 자신의 접근 방식의 우월성을 입증하는 데 전혀 경험이 없습니다.

대신, 그들이 제시할 수 있는 유일한 것은 자신의 자격에 대한 증거, 즉 상대적인 권위 위치입니다.

초보 전문가는 자기 능력 향상보다 지위 상승을 목표로 하며, 최소한의 노력으로 조직 내 영향력을 키우려 합니다.

이들은 실질적인 성장은 외면해 조직의 발전을 저해할 수 있습니다. 조직 내 진정한 성장을 위해선 학습에 열정이 있는 리더를 장려해야 합니다.

파트 별 요약

"How Developers Stop Learning: The Rise of the Expert Beginner"

핵심 개념: 초보 전문가(Expert Beginner)

초보 전문가란? 특정 기술이나 지식에서 일정 수준 이상의 실력을 가진 것처럼 보이지만, 실제로는 충분한 깊이와 다양한 경험이 결여된 상태입니다. 겉으로는 숙련된 것처럼 보이지만 진정한 고수는 아닌 사람을 말합니다.

초보 전문가가 형성되는 과정

초기 성공 경험: 개발자는 간단한 문제를 해결하면서 자신감을 얻고 성장합니다.
학습의 멈춤: 점차 도전적인 문제를 해결하는 것보다는 안전한 영역에 안주하게 됩니다. 이때 더 이상 학습하지 않고 기존 방식만을 고수하려는 경향이 나타납니다.
자기 과신: 자신의 능력을 과신하며 새로운 지식을 배울 필요성을 느끼지 않게 됩니다. 그러면서도 자신을 전문가로 자처하는 경우가 많습니다.

초보 전문가의 특징과 문제점

새로운 방법 거부: 새로운 기술이나 개선된 방법론을 무시하고 기존 방식만을 고수합니다.
학습 태도 부족: 본인이 이미 모든 것을 알고 있다는 생각에 더 이상 성장하지 않습니다.
팀과 조직에 미치는 부정적 영향: 이들은 회사나 팀에서 학습 문화를 저해하며, 자신과 비슷한 태도를 가진 동료를 양산하게 됩니다.

해결책 및 방지 방법

지속적 학습과 피드백: 기술적 성장을 위해 지속적으로 학습하고, 다른 개발자와 피드백을 주고받는 태도를 유지하는 것이 중요합니다.
실력 향상에 대한 열정: 현재의 능력에 만족하지 않고 항상 더 나아지려는 태도를 가지는 것이 초보 전문가로 머무는 것을 방지하는 핵심입니다.

이 글은 초보 전문가 단계에 빠지지 않도록 스스로 경계하며, 계속해서 학습하는 개발자가 될 필요성을 강조합니다.

"How Software Groups Rot: Legacy of the Expert Beginner",

초보 전문가의 영향: 초보 전문가가 리더 위치에 오르면 조직 내 학습과 혁신이 멈추고, 잘못된 기준과 관행이 조직에 자리 잡게 됩니다.
점진적 퇴보: 초보 전문가의 태도는 자신과 비슷한 사고방식을 가진 팀원들을 양산하며, 기술적 품질과 효율이 점점 떨어져 조직 전체가 정체하게 만듭니다.
해결 방안: 조직은 초보 전문가의 과신과 배타적인 문화를 경계하고, 지속적인 학습과 올바른 리더십을 통해 조직의 건강한 발전을 도모해야 합니다.

"How Stagnation is Justified: Language of the Expert Beginner"

정체를 합리화하는 언어: 초보 전문가는 성장이 필요 없다는 식의 발언을 하며, 새 기술이나 방식의 도입에 부정적입니다.
안전한 고수로서의 자위: 기존 방식의 효율성과 안전성을 강조하며, 변화보다는 유지에 가치를 둡니다.
성장을 위한 경계: 이러한 정체 언어를 피하고, 학습과 개선을 위한 개방적 사고와 태도가 필요합니다.\

"Up or Not: Ambition of the Expert Beginner"

야망 없는 진급: 초보 전문가는 학습이나 능력 향상보다도 단순한 직급 상승을 목표로 하며, 이를 위해 최소한의 노력으로 조직 내에서 지위를 얻고자 합니다.
자기 발전의 한계: 스스로의 실력 향상에는 관심이 없고, 팀 내 영향력을 넓히는 데 집중해 조직 성장을 방해하는 경우가 많습니다.
올바른 성장과 리더십: 조직은 진정한 성장을 촉진하기 위해 능력과 학습에 대한 열정을 가진 리더를 장려해야 합니다.

마크다운 기반의 강력한 노트 작성 도구 - 옵시디언(Obsidian)

snowman95 — Sun, 3 Nov 2024 16:27:11 +0900

옵시디언(Obsidian)은 마크다운 기반의 강력한 노트 작성 도구로, 지식 관리와 아이디어 정리에 탁월합니다. 효과적인 사용을 위해 다음과 같은 팁과 유용한 플러그인을 소개합니다.

사용 팁:

보관함(Vault) 생성 및 관리: 보관함은 노트를 저장하는 기본 단위입니다. 주제나 프로젝트별로 보관함을 생성하여 체계적으로 관리하세요. Magical AI Prompts
노트 연결: 옵시디언의 핵심 기능 중 하나는 노트 간의 링크를 통해 지식을 네트워크처럼 연결하는 것입니다. '[[노트 이름]]' 형식으로 다른 노트에 링크를 걸어 관련 정보를 쉽게 참조할 수 있습니다. Naver Blog
마크다운 문법 활용: 옵시디언은 마크다운을 사용하여 노트를 작성합니다. 제목, 리스트, 강조 등 기본 문법을 익혀 효율적으로 문서를 작성하세요. 모두가치
그래프 뷰 활용: 노트 간의 연결 관계를 시각적으로 보여주는 그래프 뷰를 통해 지식 구조를 한눈에 파악할 수 있습니다. 이를 통해 아이디어의 연관성을 쉽게 이해하고 관리할 수 있습니다. Statistics Playbook

유용한 플러그인 추천:

Editing Toolbar: 마크다운 문법을 몰라도 서식을 쉽게 적용할 수 있도록 도와주는 툴바를 제공합니다. 벨로그
Excalidraw: 손으로 그린 듯한 다이어그램, 마인드맵 등을 작성할 수 있는 플러그인으로, 시각적 콘텐츠 생성에 유용합니다. 모두가치
Templater: 반복적인 노트 작성 작업을 자동화할 수 있는 템플릿 기능을 제공합니다. 모두가치
Calendar: 일간, 주간, 월간 노트를 캘린더 형태로 관리할 수 있어 일정 관리에 도움이 됩니다. 모두가치
Dataview: 노트 데이터를 쿼리하여 테이블, 리스트 등으로 표시할 수 있어 데이터베이스처럼 활용할 수 있습니다. S-Ji
Advanced Tables: 마크다운 테이블 편집을 간편하게 도와주는 플러그인으로, 테이블 작성 시 유용합니다. 모두가치
Kanban: 작업을 시각적으로 관리할 수 있는 칸반 보드를 제공합니다. 모두가치
Mind Map: 마인드맵을 통해 아이디어를 구조화하고 시각적으로 표현할 수 있습니다. 모두가치
Folder Note: 폴더를 하나의 노트처럼 사용하여 폴더에 대한 설명이나 MOC(Map of Content)를 구성할 수 있습니다. 카미닉
Recent Files: 최근에 열었거나 작업한 파일들을 빠르게 접근할 수 있도록 도와줍니다. 카미닉

옵시디언의 그래프 뷰는 각 노트와 노트 간의 연결 관계를 시각적으로 보여줍니다. 이를 활용하면 지식의 연관성을 파악하거나 주제를 깊이 있게 탐색하는 데 유용합니다. 구체적인 사례 몇 가지를 소개하겠습니다.

1. 연구 및 학습 프로젝트:

예를 들어, 특정 학문 분야(예: 인공지능)에 대한 연구를 할 때, 각 논문, 개념, 실험 데이터 등을 개별 노트로 작성하고 이들을 연결합니다. '머신러닝', '딥러닝', '강화 학습' 등의 키워드를 중심으로 서로 관련된 자료를 링크해 두면, 그래프 뷰에서 어떤 개념들이 더 많은 연결점을 가지는지를 한눈에 파악할 수 있습니다. 이를 통해 연구에서 중요한 주제나 더 심화해야 할 개념을 쉽게 확인할 수 있습니다.

2. 프로젝트 관리 및 브레인스토밍:

새로운 프로젝트를 기획할 때, 관련된 아이디어, 리소스, 작업 항목들을 각기 다른 노트로 분리하고 상호 연결합니다. 그래프 뷰에서 각 노트가 연결된 형태를 통해 프로젝트의 전반적인 구조와 작업 흐름을 시각적으로 분석할 수 있습니다. 이 방식은 특히 브레인스토밍 과정에서 아이디어를 빠르게 정리하고 그들의 관계를 파악하는 데 도움을 줍니다.

3. 책 읽기 및 서평 작성:

책을 읽을 때 각 장별 또는 주제별로 요약을 노트에 기록하고 각 주제 간의 연결 관계를 생성합니다. 예를 들어, '심리학의 원리'라는 책을 읽을 때 '인지심리학', '행동주의', '동기 이론' 등으로 각 챕터를 요약하고, 이 주제들이 서로 연관된 방식으로 링크를 걸어둡니다. 나중에 그래프 뷰를 통해 책의 전반적인 내용을 다시 복습하거나 새로운 관점으로 책을 재해석할 때 도움이 됩니다.

이러한 사례들은 옵시디언의 그래프 뷰가 단순한 노트 관리 기능을 넘어 생각의 흐름을 시각화하고 보다 깊이 있는 지식 체계를 만드는 데 유용하다는 것을 보여줍니다.

옵시디언에서 플러그인을 설치하고 관리하는 절차는 다음과 같습니다.

1. 커뮤니티 플러그인 활성화:

옵시디언을 실행하고 설정(Settings) 메뉴로 이동합니다.
좌측의 메뉴에서 “Community plugins” 섹션을 클릭합니다.
“Turn on community plugins” 옵션을 활성화합니다. 기본적으로 옵시디언은 안전을 위해 커뮤니티 플러그인을 비활성화한 상태로 제공됩니다.

2. 플러그인 검색 및 설치:

“Browse” 버튼을 클릭하여 커뮤니티 플러그인 브라우저를 엽니다.
원하는 플러그인의 이름을 검색 창에 입력하여 검색하거나 추천 플러그인 목록에서 찾습니다.
설치하려는 플러그인을 클릭한 후 “Install” 버튼을 눌러 설치를 진행합니다.
설치가 완료되면 “Enable” 버튼을 클릭하여 플러그인을 활성화합니다.

3. 플러그인 설정 관리:

설치된 플러그인은 “Installed plugins” 섹션에서 확인할 수 있습니다.
플러그인 목록에서 특정 플러그인을 클릭하면 해당 플러그인의 설정 옵션을 조정할 수 있습니다. 각 플러그인마다 사용자 설정이 다르기 때문에, 플러그인별로 필요한 옵션을 확인하고 구성하세요.

4. 플러그인 업데이트 및 삭제:

플러그인이 업데이트되면 “Community plugins” 섹션에서 업데이트 알림을 받을 수 있습니다.
각 플러그인 옆에 있는 “Update” 버튼을 눌러 최신 버전으로 업데이트할 수 있습니다.
플러그인을 제거하려면 “Installed plugins” 목록에서 플러그인 이름 옆의 “Uninstall” 버튼을 클릭합니다.

5. 플러그인 보안 고려사항:

커뮤니티 플러그인은 타사 개발자가 제공하는 것이므로 설치 전 플러그인의 평판과 사용 후기를 확인하는 것이 좋습니다.
플러그인 사용 시, 중요한 데이터가 플러그인을 통해 외부로 전송될 위험은 없는지 검토해야 합니다.

이 절차를 따르면 옵시디언에서 원하는 기능을 추가하고 커스터마이즈하여 더 편리하게 노트를 관리할 수 있습니다.

tsconfig의 moduleResolution 란?

snowman95 — Fri, 4 Oct 2024 14:04:08 +0900

일하면서 메모 차원에서 남기는 게시글입니다.

tsconfig.json에서 moduleResolution 옵션은 TypeScript가 모듈을 어떻게 해석할지를 정의하는 설정입니다. 이는 TypeScript가 import나 require로 모듈을 가져올 때, 해당 모듈을 어디서 찾고 어떤 방식으로 해석할지 결정하는 중요한 부분입니다.

1. 기본 설명

moduleResolution은 TypeScript 컴파일러가 모듈 경로를 찾는 방식(모듈 해석 전략)을 결정합니다. TypeScript는 두 가지 기본적인 모듈 해석 전략을 제공합니다:

node: Node.js의 모듈 해석 방식과 동일한 방식입니다. node_modules 디렉토리를 탐색하며, .js, .jsx, .ts, .tsx, .json 확장자를 가진 파일을 찾습니다.
classic: TypeScript 1.6 이전에 사용되던 모듈 해석 방식입니다. ECMAScript 모듈 시스템을 따르며, 주로 전통적인 브라우저 환경에서 사용됩니다.

2. moduleResolution 값

node: Node.js의 모듈 시스템을 기반으로 모듈을 해석합니다. 대부분의 프로젝트에서 이 옵션을 사용합니다. Node.js에서 모듈을 찾는 방식과 유사하며, node_modules에서 모듈을 찾습니다.이 방식에서는 import나 require로 모듈을 가져올 때, 해당 모듈이 로컬 디렉토리 또는 node_modules 디렉토리에서 찾을 수 있습니다. 해당 모듈이 패키지에 없으면 상위 디렉토리로 올라가면서 탐색합니다.

{
  "compilerOptions": {
    "moduleResolution": "node"
  }
}

classic: TypeScript의 초기 버전에서 사용하던 방식으로, 모듈을 현재 디렉토리와 그 상위 디렉토리에서만 찾습니다. node_modules 디렉토리를 탐색하지 않으며, 브라우저 환경에서의 전통적인 파일 참조 방식과 유사합니다.이 방식은 주로 레거시 코드를 위해 사용되며, import된 모듈을 현재 디렉토리와 그 상위 디렉토리에서만 찾습니다.

{
  "compilerOptions": {
    "moduleResolution": "classic"
  }
}

3. 기타 관련 설정

moduleResolution은 모듈을 찾는 과정에서 다른 설정들과도 밀접한 관련이 있습니다:

baseUrl: 모듈 해석의 기본 경로를 설정합니다. baseUrl을 설정하면 import 시 상대 경로뿐만 아니라, baseUrl로부터의 경로도 사용할 수 있습니다.
paths: 모듈 해석 경로에 대한 별칭을 설정할 수 있습니다. paths 옵션은 모듈을 특정 경로로 매핑하는 데 유용합니다.
rootDirs: TypeScript에서 여러 디렉토리를 논리적으로 결합하여 하나의 디렉토리인 것처럼 취급할 때 사용됩니다.
module: TypeScript의 출력 모듈 시스템을 설정합니다. 이 값에 따라 moduleResolution의 기본값이 달라질 수 있습니다. 예를 들어, module: esnext일 때는 기본적으로 moduleResolution: node가 사용됩니다.

4. Node.js 방식 vs Classic 방식

Node 방식: 파일 확장자를 자동으로 추가하거나, 패키지 내의 index 파일을 자동으로 불러오는 기능을 제공합니다. 예를 들어, import { x } from './module'에서 module.js나 module/index.js 파일을 자동으로 찾습니다.
Classic 방식: 브라우저에서 스크립트를 로드할 때처럼, 파일 경로를 엄격하게 따릅니다. 즉, ./module을 import할 때 해당 파일이 정확히 존재해야 하며, 확장자를 자동으로 추론하지 않습니다.

예시

Node 방식 모듈 해석 (기본)

{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "node"
  }
}

Classic 방식 모듈 해석

{
  "compilerOptions": {
    "module": "es2015",
    "moduleResolution": "classic"
  }
}

moduleResolution: "bundler"는 TypeScript 5.0에서 도입된 새로운 모듈 해석 전략으로, 번들러(예: Vite, Webpack, esbuild)가 모듈을 처리하는 방식을 더 잘 반영하기 위해 만들어졌습니다. 이 옵션은 번들러가 처리하는 방식과 유사한 방식으로 모듈을 해석하도록 TypeScript를 설정합니다. 번들러들이 자체적으로 모듈을 처리할 때 TypeScript와 충돌이 일어나지 않도록 최적화된 방식입니다.

주요 특징 및 동작 방식

Ecosystem Alignment: 번들러들이 모듈을 처리하는 방식과 더 유사하게 작동합니다. 번들러는 Node.js의 해석 방식을 따르지만, 때때로 TypeScript의 node 모듈 해석 방식과 다르게 동작할 수 있습니다. bundler 옵션은 이러한 차이를 조정하여 TypeScript가 번들러와 동일하게 모듈을 처리하도록 돕습니다.
최적화된 동작:
- 파일 확장자 처리: 번들러들이 일반적으로 .js, .ts, .jsx, .tsx 등의 확장자를 자동으로 해석하고 처리하는 것처럼, bundler 해석 모드도 확장자를 명시하지 않아도 자동으로 처리합니다.
- 패키지 처리: Node.js 스타일로 패키지 내 package.json의 main 또는 exports 필드를 읽어서, 번들러가 처리하는 방식과 유사하게 모듈을 찾습니다. 이는 TypeScript가 번들러 환경에서 패키지를 처리하는 방식과 더 일치하게 만듭니다.
- Alias 및 Paths 매핑: 번들러에서 alias 설정을 사용하거나, TypeScript에서 paths 옵션을 설정하여 경로 별칭을 사용하는 경우, bundler 모듈 해석 방식은 이러한 별칭을 더 일관성 있게 처리합니다.
ESM과의 호환성: 번들러들이 ESM(ES Modules)을 처리하는 방식과 호환되도록 최적화되어 있습니다. TypeScript가 ESM 모듈을 해석할 때, 번들러와 같은 방식으로 파일과 모듈을 찾습니다.

moduleResolution: "bundler"가 필요한 경우

이 옵션은 특히 다음과 같은 상황에서 유용합니다:

번들러 기반 프로젝트: Vite, esbuild, Webpack 등 최신 번들러를 사용하여 프로젝트를 빌드하는 경우, 번들러의 모듈 해석 방식과 TypeScript의 해석 방식이 충돌하지 않도록 도와줍니다.
ESM 및 CommonJS 모듈이 혼재된 프로젝트: 번들러들이 혼합된 ESM 및 CommonJS 모듈을 처리하는 방식에 맞춰, TypeScript도 적절히 모듈을 해석합니다.
경로 Alias 사용: 번들러의 경로 별칭(예: Webpack의 resolve.alias 또는 Vite의 alias 설정)과 TypeScript의 paths 설정을 함께 사용할 때, bundler 옵션은 모듈 해석의 일관성을 유지하는 데 도움을 줍니다.

예시

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler",
    "paths": {
      "@components/*": ["src/components/*"]
    }
  }
}

이 설정에서 TypeScript는 번들러가 파일을 찾는 방식과 동일하게 모듈을 해석하며, @components/*와 같은 경로 별칭도 번들러 방식으로 처리합니다.

주의사항

moduleResolution: "bundler"는 TypeScript가 모듈을 해석하는 방식만을 변경할 뿐, 실제 번들링 과정은 번들러가 수행합니다. 즉, 번들링 자체는 여전히 Webpack, Vite, esbuild와 같은 도구가 처리하게 됩니다.
최신 번들러와의 호환성에 초점을 맞추고 있기 때문에, 번들러가 모듈을 처리하는 방식에 따라 달라질 수 있는 일부 모호한 모듈 해석 문제를 해결하는 데 도움을 줍니다.

정리

moduleResolution: "bundler"는 번들러 환경에서 TypeScript가 모듈을 보다 일관성 있게 처리하도록 돕는 설정입니다. 번들러가 모듈을 해석하는 방식과 동일한 흐름을 따르므로, 최신 프론트엔드 도구와의 호환성을 강화하며, 특히 경로 별칭이나 ESM/UMD 모듈 처리에서 발생할 수 있는 문제들을 해결하는 데 매우 유용합니다.

Apollo Client 와 Relay 를 비교해보자

snowman95 — Tue, 1 Oct 2024 21:44:09 +0900

프론트엔드에서 GrpahQL 를 다루기 위한 대표적인 라이브러리로는 Apollo Client와 Relay 가 있습니다.

그 중에 저희는 Apollo Client 를 사용하고 있는데요.

처음에 Apollo 와 Relay 중 어느것을 하는가 비교했었을때 Next.js 와 SSR 기능과의 통합성을 좀 중점적으로 보았습니다.

왜냐하면 그 전까지 React 로 CSR 만 사용하다가 이번 프로젝트에 Next.js 를 처음 도입하게된 것이었고. 고객 유입을 위한 SEO 가 중요하여 SSR를 적극 사용할 것으로 기대했기 때문입니다.

Relay 는 SSR을 공식적으로 지원하지 않기에 별도로 복잡한 설정을 해주어야 하고. 성능 최적화. 캐시 자동관리 등에 중점적이어서 대규모 서비스에 적합하다는 말이 있었고.

Apollo Client SSR을 공식적으로 지원하여 설정이 매우 간단하고 빠르게 개발을 시작해야 할때 적합했기 때문에 선택했을 뿐이지 사실 선택에 대한 대단한 이유는 없었습니다. Apollo 사이트를 들어가보면 GraphQL 의 미래에 대한 엄청난 포부가 느껴지는데요. 사실 그런 부분도 크게 작용한거 같기는 합니다.

근데 지금 거의 반년 이상 Apollo Client 를 쓰며 느낀점은...

일단 빠르게 시작하기엔 적합한건 맞습니다. 저희는 급했기 때문에 빠르게 개발이 필요했기 때문에 잘 사용했습니다.

그러나 먼 훗날 성능 최적화를 신경쓰고 고도화를 하면서 부터 캐시를 다루게 되고.

큰 데이터 덩이리에서 프레그먼트들을 수동으로 캐시를 업데이트 해줘야 하는 경우가 생겨나면서 부터 좀 불편하고 피로도를 느꼈습니다.

심지어 Relay에는 캐시에 대한 접근 카운트를 하여 접근이 없으면 삭제해주는 자동 가비지 커렉션이 있는데 Apollo 에는 없기 때문에 이런걸 또 어떻게 처리해줘야 할 지에 대한 고민이 됩니다.

물론 그만큼 유연하고 자유도를 주는 것이겠지만, 사실 피곤하고 코드가 길어지는건 유지보수 차원에서 줄이고 싶은게 어쩔 수 없나 봅니다... 그래서 요즘 같이 여유가 조금 생겼을때. 아 우리도 Relay 를 조금 고민해볼만 할까? 그런 생각도 들긴 합니다.

가비지 컬렉션	자동 가비지 컬렉션 없음. 수동으로 캐시를 무효화하거나 리셋해야 함	자동 가비지 컬렉션 제공. 불필요한 데이터는 참조되지 않으면 삭제됨
수동 캐시 업데이트	캐시를 수동으로 업데이트하거나 무효화할 수 있음 (writeQuery, evict)	수동 캐시 업데이트 기능 없음. 데이터는 서버와 자동 동기화됨
캐시 관리 철학	개발자가 캐시 데이터를 직접 관리. 필요한 경우 캐시 무효화 또는 갱신	자동으로 데이터 동기화 및 캐시 관리. 수동 관리 필요 없음

ChatGPT 에 물어보면 이렇게 답변 해줍니다.

Apollo Client와 Relay는 모두 GraphQL 클라이언트로, React 애플리케이션에서 GraphQL API와 상호작용할 때 자주 사용됩니다. 이 두 도구는 유사한 목적을 가지고 있지만, 아키텍처, 사용 방법, 최적화 측면에서 차이점이 있습니다. 다음은 주요 비교 내용입니다.

1. 설계 철학 및 목적

Apollo Client:
- Apollo는 사용성을 중점에 둔 일반적인 GraphQL 클라이언트입니다. 초심자와 전문가 모두에게 적합하며, GraphQL 쿼리 및 변이를 쉽게 다루는 것이 목표입니다.
- 기본적으로 강력한 상태 관리 기능과 캐싱을 제공합니다. 서버 데이터를 클라이언트 쪽에서 쉽게 다룰 수 있게 도와줍니다.
- 프론트엔드에서 GraphQL을 유연하게 사용하고자 할 때 적합합니다.
Relay:
- Relay는 Facebook이 만든 GraphQL 클라이언트로, 성능 최적화와 대규모 애플리케이션을 염두에 둔 설계가 특징입니다. Relay는 명시적으로 데이터를 최적화하고 효율적으로 처리하는 데 중점을 둡니다.
- GraphQL의 전체 구조와 깊은 통합이 되어 있으며, 쿼리 프래그먼트(fragment) 개념을 사용하여 데이터를 더 정교하게 관리할 수 있습니다.
- 복잡하고 규모가 큰 프로젝트에서 최적의 성능을 내기 위한 툴로 적합합니다.

2. 데이터 관리 및 캐싱

Apollo Client:
- Apollo는 기본적으로 in-memory cache를 제공하여, 동일한 데이터를 다시 쿼리하지 않도록 캐시를 사용합니다.
- 캐시 업데이트 방식이 직관적이며, 유저가 직접 명령형 방식으로 캐시를 관리할 수 있습니다. 필요 시 데이터 갱신도 쉽게 할 수 있습니다.
- 간단한 쿼리와 변이(mutations)에 적합하며, 캐싱이 더 직관적입니다.
Relay:
- Relay는 더 복잡한 캐시 구조를 가지고 있으며, 캐시 관리가 더 세밀합니다. 캐싱 효율을 극대화하기 위해 더 정교한 구조를 사용합니다.
- Relay의 캐시 동기화는 Apollo보다 더 자동화되어 있으며, 클라이언트 쪽에서 명시적인 관리 없이도 일관된 상태를 유지할 수 있습니다.
- 쿼리 프래그먼트를 사용하여 뷰의 데이터 요구 사항을 컴포넌트 단위로 관리하고, Relay는 필요한 데이터만 가져오도록 최적화합니다.

3. 쿼리 프래그먼트 및 코드 분할

Apollo Client:
- Apollo는 쿼리를 한 곳에서 작성하고, 다양한 컴포넌트에서 쿼리 데이터를 사용할 수 있습니다.
- 특정 컴포넌트에 맞춘 쿼리를 사용하는 방식이 가능하지만, Relay처럼 자동으로 컴포넌트별로 쿼리를 나누는 방식은 제공하지 않습니다.
Relay:
- Relay의 쿼리 프래그먼트 기능은 각 컴포넌트에서 필요한 데이터만 요청하도록 합니다. 이를 통해 성능 최적화를 극대화합니다.
- 컴포넌트가 자체적으로 필요한 데이터를 선언하고, Relay는 이를 조합하여 서버에 적절한 요청을 보냅니다. 이로 인해 데이터 요구 사항이 컴포넌트에 가까워지고 코드 분할이 자연스럽게 이뤄집니다.

4. 학습 곡선

Apollo Client:
- Apollo는 상대적으로 학습 곡선이 완만합니다. 기본적인 사용법이 직관적이고, 다양한 튜토리얼과 문서가 잘 제공되기 때문에 빠르게 시작할 수 있습니다.
- 복잡한 기능을 사용하기 전에도 기본적인 CRUD 작업을 쉽게 구현할 수 있습니다.
Relay:
- Relay는 학습 곡선이 상대적으로 가파릅니다. 특히 초기 설정이 복잡할 수 있으며, 성능 최적화를 위한 고급 기능을 이해하고 사용하려면 상당한 학습이 필요합니다.
- 하지만 이를 통해 대규모 애플리케이션에서는 뛰어난 성능을 보장합니다.

5. 커뮤니티 및 에코시스템

Apollo Client:
- 매우 활발한 오픈소스 커뮤니티를 가지고 있으며, 다양한 플러그인과 확장 도구들이 존재합니다. 이를 통해 여러 환경과 쉽게 통합할 수 있습니다.
- Apollo Server와 같은 백엔드 도구들과의 통합도 매우 쉽습니다.
Relay:
- Relay는 Facebook 내부 프로젝트로 시작된 만큼 더 제한적인 커뮤니티를 가지고 있습니다. 하지만 대규모 애플리케이션에 적합한 도구들을 많이 제공합니다.
- 다른 도구들과의 통합보다는 자체적인 성능 최적화에 더 중점을 둡니다.

6. 사용 사례

Apollo Client:
- 작은 규모의 프로젝트부터 중간 규모의 애플리케이션까지 매우 적합합니다. 빠르게 구축해야 하거나, 다양한 데이터 소스와 유연하게 통합하고 싶을 때 강력합니다.
Relay:
- 대규모 애플리케이션에 적합하며, 특히 성능이 중요한 프로젝트에서 유용합니다. Facebook 같은 대규모 데이터 요구가 있는 프로젝트에서 최적의 성능을 발휘합니다.

요약

Apollo Client는 일반적인 용도에 더 적합하고 학습이 쉬우며, 유연하고 강력한 상태 관리 및 캐싱 기능을 제공합니다.
Relay는 성능 최적화와 데이터 관리를 중요시하는 대규모 애플리케이션에 적합하며, 더 세밀한 데이터 관리와 쿼리 최적화를 제공합니다.

코드 비교해보기

Apollo Client와 Relay를 사용하여 데이터를 가져오는 예제를 보여드리겠습니다. 두 클라이언트 모두 GraphQL 쿼리를 통해 데이터를 가져오지만, 접근 방식과 설정이 다릅니다.

1. Apollo Client 예시

설정

먼저, Apollo Client를 설정합니다. Apollo Client를 설치하고 GraphQL API를 사용할 수 있도록 클라이언트를 구성해야 합니다.

npm install @apollo/client graphql

ApolloProvider를 이용해 클라이언트를 설정합니다.

// ApolloClient 설정
import { ApolloClient, InMemoryCache, ApolloProvider, gql, useQuery } from '@apollo/client';
import React from 'react';

const client = new ApolloClient({
  uri: 'https://your-graphql-endpoint.com/graphql',
  cache: new InMemoryCache(),
});

const GET_USERS = gql`
  query GetUsers {
    users {
      id
      name
      email
    }
  }
`;

function Users() {
  const { loading, error, data } = useQuery(GET_USERS);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <div>
      <h3>User List:</h3>
      <ul>
        {data.users.map(user => (
          <li key={user.id}>
            {user.name} ({user.email})
          </li>
        ))}
      </ul>
    </div>
  );
}

function App() {
  return (
    <ApolloProvider client={client}>
      <Users />
    </ApolloProvider>
  );
}

export default App;

설명

ApolloClient는 GraphQL API 엔드포인트와 메모리 캐시를 설정합니다.
gql 태그로 쿼리를 정의하고, useQuery 훅을 사용해 데이터를 가져옵니다.
쿼리의 상태(loading, error, data)를 처리하고 데이터를 화면에 출력합니다

2. Relay 예시

설정

Relay는 조금 더 복잡한 설정이 필요합니다. Relay 환경과 Babel 플러그인을 설정해야 합니다.

npm install react-relay relay-runtime babel-plugin-relay graphql

relay.config.js 파일을 만들어 Relay 설정을 추가합니다.

module.exports = {
  src: './src',
  schema: './data/schema.graphql',
  language: 'javascript',
};

Relay 환경 설정

Relay는 RelayEnvironment를 설정하는 부분이 필요합니다.

// RelayEnvironment 설정
import { Environment, Network, RecordSource, Store } from 'relay-runtime';
import { RelayEnvironmentProvider, useLazyLoadQuery, graphql } from 'react-relay';
import React from 'react';

function fetchQuery(operation, variables) {
  return fetch('https://your-graphql-endpoint.com/graphql', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      query: operation.text,
      variables,
    }),
  }).then(response => response.json());
}

const environment = new Environment({
  network: Network.create(fetchQuery),
  store: new Store(new RecordSource()),
});

const UsersQuery = graphql`
  query UsersQuery {
    users {
      id
      name
      email
    }
  }
`;

function Users() {
  const data = useLazyLoadQuery(UsersQuery, {});

  return (
    <div>
      <h3>User List:</h3>
      <ul>
        {data.users.map(user => (
          <li key={user.id}>
            {user.name} ({user.email})
          </li>
        ))}
      </ul>
    </div>
  );
}

function App() {
  return (
    <RelayEnvironmentProvider environment={environment}>
      <Users />
    </RelayEnvironmentProvider>
  );
}

export default App;

설명

Environment와 Network를 설정해 Relay가 GraphQL API와 상호작용하도록 설정합니다.
graphql 태그로 쿼리를 정의하고, useLazyLoadQuery 훅을 사용해 데이터를 가져옵니다.
쿼리 데이터가 준비되면 화면에 출력합니다.

주요 차이점:

Apollo Client는 useQuery 훅을 사용해 간단하게 데이터를 가져오고 상태(loading, error, data)를 처리합니다.
Relay는 쿼리를 더 정교하게 나눠서 처리할 수 있으며, Relay 환경 설정이 더 복잡하지만 성능 최적화가 뛰어납니다.

캐시가 어떻게 저장되고 관리되는지 비교

1. Apollo Client의 캐시 구조

Apollo Client는 기본적으로 InMemoryCache를 사용하여 데이터를 캐싱합니다. 이 캐시는 GraphQL 쿼리의 결과를 메모리 안에 저장하고, 쿼리의 결과를 재사용하여 네트워크 요청을 최소화합니다.

캐시 저장 방식

Normalized Cache: Apollo Client는 데이터를 정규화(normalization)하여 저장합니다. 이는 데이터베이스의 테이블처럼 데이터를 구조화하고, 특정 데이터에 접근할 때 데이터를 중복 없이 효율적으로 저장하고 관리할 수 있도록 해줍니다.
캐시 키: Apollo Client는 각 엔티티마다 고유한 __typename과 id(혹은 custom key)를 결합하여 고유한 캐시 키를 만듭니다. 예를 들어, 다음과 같은 쿼리가 있다고 가정할 때:

query GetUsers {
  users {
    id
    name
    email
  }
}

이 쿼리의 결과에서 id가 1인 User가 있다면, 이 데이터는 캐시에 User:1이라는 키로 저장됩니다. 이 방식으로 동일한 데이터를 여러 쿼리에서 사용하더라도, 캐시에서 데이터를 재활용할 수 있습니다.

캐시 데이터의 구조

캐시에 저장된 데이터는 정규화된 객체의 집합으로 저장됩니다. 예를 들어, 위 쿼리의 결과가 다음과 같다면:

{
  "users": [
    { "id": 1, "name": "Alice", "email": "alice@example.com" },
    { "id": 2, "name": "Bob", "email": "bob@example.com" }
  ]
}

이 데이터는 캐시에 다음과 같은 구조로 저장됩니다:

{
  "ROOT_QUERY": {
    "users": ["User:1", "User:2"]
  },
  "User:1": {
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com"
  },
  "User:2": {
    "id": 2,
    "name": "Bob",
    "email": "bob@example.com"
  }
}

이렇게 데이터를 정규화하면, 동일한 데이터가 여러 곳에서 참조될 때 중복을 방지하고, 데이터를 효율적으로 관리할 수 있습니다.

캐시 관리

자동 캐시 업데이트: Apollo는 쿼리가 성공적으로 완료되면 자동으로 해당 데이터를 캐시에 저장합니다.
수동 캐시 업데이트: writeQuery, writeFragment, readQuery, readFragment를 사용하여 캐시를 수동으로 읽고 쓸 수 있습니다.
캐시 무효화: cache.evict나 cache.reset을 사용하여 특정 데이터를 캐시에서 제거하거나 전체 캐시를 무효화할 수 있습니다.

2. Relay의 캐시 구조

Relay는 캐시 시스템이 Apollo보다 더 복잡하고 최적화된 방식으로 동작합니다. Relay는 대규모 애플리케이션에서 성능을 극대화하기 위해 설계되었으며, 데이터를 효율적으로 가져오기 위해 세밀한 캐싱을 사용합니다.

캐시 저장 방식

Record-based Storage: Relay의 캐시는 레코드 기반 저장 방식을 사용합니다. 이는 GraphQL 쿼리의 결과를 "레코드"로 분할하고, 각 레코드를 고유한 ID로 식별하여 저장합니다. 이러한 구조는 Apollo의 정규화된 캐싱 방식과 유사하지만, Relay는 이를 더 세밀하게 관리합니다.
ID와 Type을 기반으로 한 캐시 키: Relay는 각 레코드에 고유한 ID를 부여하고, 이 ID를 기반으로 데이터를 저장합니다. 또한 GraphQL 스키마의 타입 정보를 기반으로 데이터를 정규화합니다. 예를 들어, User라는 타입을 가진 엔티티의 ID가 1이라면, 해당 엔티티는 User:1이라는 캐시 키를 가집니다.

Fragment 기반 데이터 관리

Fragment를 통한 데이터 분할: Relay의 핵심 개념 중 하나는 "쿼리 프래그먼트(fragment)"입니다. 각 컴포넌트는 자신이 필요한 데이터만 요청하는 프래그먼트를 정의하며, Relay는 이러한 프래그먼트를 기반으로 필요한 데이터만 쿼리하고 캐시합니다. 이는 컴포넌트 단위로 데이터를 효율적으로 관리할 수 있도록 도와줍니다.
캐시 데이터의 구조: Relay에서 캐시된 데이터는 RecordSource에 저장되며, 각 레코드는 고유한 ID를 기준으로 저장됩니다. 예를 들어, 다음과 같은 쿼리가 있다고 가정할 때:

query GetUsers {
  users {
    id
    name
    email
  }
}

이 쿼리의 결과가 Relay의 캐시에 저장될 때는 각 User 레코드가 고유한 키(예: User:1, User:2)로 저장됩니다.
Relay의 데이터는 RecordSource에서 저장된 레코드의 집합으로 관리됩니다. 각 레코드는 해당 데이터를 포함하며, Relay는 이를 기반으로 캐시를 관리합니다.

캐시 관리

자동 캐싱 및 업데이트: Relay는 쿼리 결과를 자동으로 캐싱하고, 데이터 변경이 발생하면 캐시를 자동으로 업데이트합니다.
Garbage Collection (GC): Relay는 가비지 컬렉션 시스템을 통해 더 이상 참조되지 않는 데이터를 캐시에서 제거합니다. 이는 메모리 사용량을 최적화하는 데 중요한 역할을 합니다.
Store와 RecordSource: Relay의 캐시는 Store와 RecordSource라는 두 가지 주요 요소로 관리됩니다. Store는 현재 사용 중인 캐시 데이터를 관리하고, RecordSource는 데이터를 저장하는 저장소 역할을 합니다.

비교 요약

특징	Apollo Client	Relay
캐시 구조	정규화된 객체 기반 캐시 (InMemoryCache)	레코드 기반 캐시 (RecordSource)
캐시 키	__typename + id	ID + Type 기반 (예: User:1)
캐시 방식	쿼리의 결과를 정규화하여 저장	프래그먼트 기반으로 세밀하게 데이터를 관리
캐시 데이터 관리	writeQuery, readQuery로 수동 관리 가능	자동화된 캐시 관리 및 가비지 컬렉션 지원
캐시 최적화	간단한 캐싱, 수동 업데이트 가능	고급 최적화 및 가비지 컬렉션으로 효율적인 관리

캐시 데이터를 가져오는 것 비교

1. Apollo Client - 캐시 데이터 가져오기

Apollo Client는 기본적으로 InMemoryCache를 사용하여 데이터를 캐싱합니다. 캐시 데이터를 명시적으로 가져오거나 업데이트할 수 있습니다. 다음은 Apollo Client에서 캐시 데이터를 사용하는 예시입니다.

캐시 데이터를 가져오는 코드 예시

import { ApolloClient, InMemoryCache, ApolloProvider, gql, useQuery } from '@apollo/client';
import React from 'react';

// Apollo Client 설정
const client = new ApolloClient({
  uri: 'https://your-graphql-endpoint.com/graphql',
  cache: new InMemoryCache(),
});

// GraphQL 쿼리 정의
const GET_USERS = gql`
  query GetUsers {
    users {
      id
      name
      email
    }
  }
`;

// 캐시에서 데이터 가져오기
function Users() {
  const { loading, error, data } = useQuery(GET_USERS);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <div>
      <h3>User List:</h3>
      <ul>
        {data.users.map(user => (
          <li key={user.id}>
            {user.name} ({user.email})
          </li>
        ))}
      </ul>
    </div>
  );
}

// 캐시에서 데이터 수동으로 가져오기
function fetchUsersFromCache() {
  const cachedData = client.cache.readQuery({ query: GET_USERS });

  if (cachedData) {
    console.log('Cache Data:', cachedData);
  } else {
    console.log('No data in cache');
  }
}

function App() {
  // 수동으로 캐시 데이터 가져오기 실행
  React.useEffect(() => {
    fetchUsersFromCache();
  }, []);

  return (
    <ApolloProvider client={client}>
      <Users />
    </ApolloProvider>
  );
}

export default App;

설명:

useQuery 훅을 사용하면 Apollo Client는 기본적으로 쿼리 데이터를 캐시합니다.
client.cache.readQuery 메서드를 사용하여 수동으로 캐시된 데이터를 가져올 수 있습니다.
캐시에 저장된 데이터를 먼저 가져온 후 네트워크 요청을 할지, 또는 네트워크 요청이 실패했을 때 캐시를 사용할지 선택할 수 있습니다.

2. Relay - 캐시 데이터 가져오기

Relay는 더 복잡한 캐싱 메커니즘을 가지고 있으며, 자동으로 필요한 데이터를 관리합니다. Relay에서는 store를 사용하여 캐시된 데이터를 가져올 수 있습니다.

캐시 데이터를 가져오는 코드 예시

Relay에서는 기본적으로 컴포넌트에서 필요한 데이터가 캐시될 경우, 다시 요청하지 않고 캐시된 데이터를 자동으로 반환합니다. Relay의 캐시 데이터는 store를 통해 관리됩니다.

import { Environment, Network, RecordSource, Store } from 'relay-runtime';
import { RelayEnvironmentProvider, useLazyLoadQuery, graphql } from 'react-relay';
import React from 'react';

// Relay 환경 설정
const store = new Store(new RecordSource());

const environment = new Environment({
  network: Network.create((operation, variables) =>
    fetch('https://your-graphql-endpoint.com/graphql', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        query: operation.text,
        variables,
      }),
    }).then(response => response.json())
  ),
  store,
});

// GraphQL 쿼리 정의
const UsersQuery = graphql`
  query UsersQuery {
    users {
      id
      name
      email
    }
  }
`;

// 캐시에서 데이터 가져오기
function Users() {
  const data = useLazyLoadQuery(UsersQuery, {});

  return (
    <div>
      <h3>User List:</h3>
      <ul>
        {data.users.map(user => (
          <li key={user.id}>
            {user.name} ({user.email})
          </li>
        ))}
      </ul>
    </div>
  );
}

// 수동으로 캐시 데이터 확인하기
function fetchUsersFromCache() {
  const cachedRecord = store.getSource().get('ROOT_QUERY');
  if (cachedRecord) {
    console.log('Cache Data:', cachedRecord);
  } else {
    console.log('No data in cache');
  }
}

function App() {
  // 캐시 데이터를 수동으로 가져오기 실행
  React.useEffect(() => {
    fetchUsersFromCache();
  }, []);

  return (
    <RelayEnvironmentProvider environment={environment}>
      <Users />
    </RelayEnvironmentProvider>
  );
}

export default App;

설명:

Relay는 store와 RecordSource를 사용해 캐시된 데이터를 관리합니다.
store.getSource().get('ROOT_QUERY')를 사용해 캐시된 데이터를 직접 가져올 수 있습니다.
기본적으로 Relay는 필요한 경우 캐시된 데이터를 자동으로 반환하지만, 개발자가 명시적으로 캐시 데이터를 읽고자 할 경우 위와 같이 할 수 있습니다.

요약:

Apollo Client는 client.cache.readQuery 메서드를 사용하여 명시적으로 캐시된 데이터를 읽을 수 있으며, useQuery 훅에서 캐시를 자동으로 사용합니다.
Relay는 store와 RecordSource를 사용해 캐시 데이터를 관리하며, Relay는 기본적으로 데이터를 자동으로 캐시하고 필요한 경우 캐시된 데이터를 제공합니다.

[프로젝트 기록] Next.js 의 SSG 는 너무 느려서 못써먹겠다.

snowman95 — Mon, 30 Sep 2024 15:47:42 +0900

프로젝트 기록입니다.

배경 지식

23년도에서 24년 넘어가던 때에 저희 회사에서 모든 부동산 자산에 대한 어떤 정보를 제공하기 위한 페이지를 기획했었습니다.

저는 이것이 마케팅 비용이 없이도 효과적으로 검색 유입을 늘릴 수 있는 수단으로 생각하여 SEO에 신경써서 개발하였고.

이런 것들을 이미 염두하여 Next.js 로 개발하고 있었기 때문에 SSR, SSG 를 적극 검토했었습니다.

자산의 종류는 토지(땅만), 토지건물(땅과 건물. 그러나 동,호는 없음), 집합건물(동,호가 존재) 이렇게 3종류가 있습니다.

각 자산은 고유 번호인 pnu 를 붙여서 관리하고 있고.

집합건물은 pnu + 각 동에 대해 dongBpk, 각 동의 호에 대해 hoBpk 를 가집니다.

사실 SSR 를 쓰면 정말로 뭘 할 것도 없이 간단한데요.

SSG를 검토했던 이유는 사용자가 폭발적으로 늘어날 것을 기대하여 불필요한 API 요청들을 줄여보고자 하는 노력이었습니다.

또한 검색엔진에 전달해야하는 주소가 매우매우 많았기 때문이기도 하고요.

테스트 결과

Next.js v13으로 서울지역의 토지, 토지건물, 집합건물 각 100개를 SSG(Static Site Generation) 정적페이지 생성을 했을때

300건에 대해서 대략 1분이 걸렸습니다. 3만건만 해도 100분이었습니다.

계획 변경하기

일단 맛보기로 SSG 이 얼마나 끔찍하게 느린지 체감하였습니다. 그래서 대부분은 SSR로 대응하는 방향으로 계획을 변경했습니다.

토지 : SSG(정적페이지 생성) 으로 대응 합니다.

사용자 또는 크롤링 봇이 페이지 접속시 이미 빌드 단계에서 SSG로 만들어둔 html 파일을 즉시 보여줍니다. 그리고 바로 이어서 나머지 내용들을 채워서 화면을 업데이트 합니다.

SSG 로는 꼭 필요한 데이터만 담아서 html 파일을 만들어둡니다. 페이지 안에 들어가는 모든 내용을 담아서 페이지를 만들게 되면 SSG 에 너무 많은 시간이 들기 때문입니다. 대략 1만건에 대해서 15분 정도 소요 예상됨. (추측이기 때문에 빌드 타임이 짧을 수도 있음. 운영배포시 확인하여 스크린샷 남기기)

(2023년 11월 6일 기록) SEO 에 대해서는 SSR 로도 충분히 대응이 가능하지만, 사람들이 페이지 접속할 때마다 아래 이미지와 같이 API 를 최소 2~3번 호출해야 하고, SSG로 만들어둔 html 파일을 바로 건네주는게 압도적으로 응답속도가 빠르기 때문에, 한마디로 최적화를 위해 SSG 로 일부분 작업해둔 것이었습니다.

토지건물 : 서울시 1만 건에 대해 빌드시 SSG + 페이지 접속시 SSG 으로 대응 합니다.

(2023년 11월 6일 기록) 아무래도 처음 시도하는 것이다보니, 실험적인 시도가 많이 담겨있습니다. SSR vs SSG 의 싸움이라고 볼 수 있습니다. “페이지 접속시” SSG 로 대응하게 되면, 처음 접속시 html 파일을 만들고, 그 다음번 접속시 html 파일을 재활용할 수 있다는 이점이 있어서 시도해본 것이었습니다. 실제로 운영 배포후에 SSR, SSG 비교해보고 어느 쪽으로 갈 지 정해질 것 같습니다.

집합건물 : SSR(서버사이드 랜더링) 으로 대응 합니다.

(2023년 11월 6일 기록) 전국에 엄청나게 많은 자산이 있고. 그 집합건물(아파트)자산의 모든 호실(hoBpk) 에 대한 정적페이지 만드는 건 불가능에 가깝기 때문에 SSR 로 대응하기로 결정했습니다.

결론

그 뒤로 선별된 몇 만건의 자산에 대해 SSG를 시도해보았지만. 너무나 느린 생성 속도로 인해서 도저히 못쓰겠다는 판단을 했습니다.

SSR 로도 충분히 대응이 되는 상황에서 내가 이렇게 공수를 들여서 굳이 SSG을 해서 큰 이점을 얻는것도 아닌데 해야할까 그런 생각이 들었고. 결국에는 모든 자산의 꼭 필요한 정보만 SSR 로 렌더링해서 검색엔진에 제공하도록 했습니다.

Sitemap

(이건 순수 경험으로 작성된 내용입니다. 100%맞다고 볼 수는 없고 참고만..)

어쨌든 SEO 는 SSR 로 대응했다고 치는데. 이번엔 수만개의 사이트 맵을 만들어야 했습니다.

사이트 맵 용량이 크면 검색엔진이 잘 안읽는가?

-> 사이트맵 읽는 날짜가 제각각인것 보면 딱히 그런건 없었습니다. 그리고 Next 에서는 기본적으로 gzip 압축해서 보내주고 있었습니다.

사이트 맵 파일에 너무 많은 주소가 들어있으면 잘 안읽는가?

꼭 그렇다고 보기는 어려워보이지만 권장 개수는 10000개라고 합니다.

그래서 저희도 하나의 사이트맵 파일에 35000개의 주소를 포함시키던 것을 권장 개수인 10000개로 줄이고. 파일 개수를 늘렸습니다.

그런데 나중에 알게 되었지만. 등록된 지 얼마 안된 사이트에 대해 검색엔진이 읽을 수 있는 파일의 개수가 정해져있는듯 했습니다.

45개였습니다. 약 450000개의 주소 정도였다고 보면 됩니다.

어떻게 해서 구글서치콘솔에 사이트맵 등록을 완료했는데요... 문제가 많았습니다. 이어서 보시죠.

문제발생

구글서치앤진에서 파이퍼 sitemap 파일의 일부 지역(부산, 충청도)만 읽는 문제가 있었습니다.

기존에는 sitemap/index.xml 파일 아래에 모든 지역의 사이트맵 파일이 포함되었는데

기존에 올려둔 사이트맵 파일 모두 지우고 sitemap/index.xml 파일 하나만 등록하는 방식으로 바꿔서 테스트 해보았습니다.

그런데 달라지는 건 없었습니다.

이 문제의 원인은 방금 위에 적어놓은것 처럼 등록된 지 얼마 되지 않은 사이트에 대해서는 읽을 수 있는 파일 개수가 제한되어있었기 때문이었고.

파일 이름이 알파벳 순서대로 B로 시작되는 부산, C로 시작되는 충청도가 먼저 읽혀졌던 것이었습니다.

저희는 S로 시작되는 서울 지역이 가장 우선순위가 높았기 때문에 서울앞에 0- 이런식으로 정렬 순서가 가장 앞설 수 있게 고쳤고.

그 결과 서울 지역이 읽히게 되었습니다.

(서울지역이 가장 앞페이지에 나타나는것을 보여주는 캡쳐 이미지)

이렇게 하고나서 보니 오히려 파일을 쪼개기 보다는 합치는게 답이었을까 그런 생각도 들었는데요.

한번 변경하고 반영하기 까지 몇 달이나 소요되기 때문에 현실적으로 모두 다 테스트 해볼 수는 없었습니다.

그러나 만약에 또 다시 사이트맵을 건드려야 하는 일이 생긴다면, 저는 다시 파일 당 포함 주소를 1만개에서 3만5천개로 되돌려서 해볼 거 같습니다.

물론 이렇게 서울지역이 먼저 읽히게 했지만. 읽을 수 있는 파일은 45개가 맞다는 것을 확실히 알 수 있었습니다.

변경 전 : 부산(24개) + 충청북도(21개) = 45개
변경 후 : 서울(50개) 중 44개 + /sitemap-0.xml 파일 1개 = 45개

구글서치엔진의 색인 제거하기

이런저런 고생을 했지만 지금은 이 페이지가 기획에서 제외되었는데요...

그래서 구글서치엔진의 색인을 다시 지워주는 과정이 필요했습니다.

robots.txt 에서 disallow 를 하여 접근을 막으면 되는거 아닌가 라고 쉽게 생각할 수 있는데요.

오히려 그 반대로 접근을 막아버리면 색인에서 제거할 수 없게 되기 때문에 그러면 안되었습니다.

검색봇이 사이트에 접근할 수 있게 열어두고.

<meta name="robots" content="noindex"> 테그를 추가함으로써 검색봇이 이 테그를 읽고는 색인을 하지 않게끔. 색인이 있으면 삭제하게끔 해야만 색인이 제거되었습니다.

저희는 색인을 제거해야하는 페이지를 아예 걷어낼 계획이었기 때문에

page 경로 상에서도 제거했었고. 접속시 404 경로로 이동되는데. 404 페이지에 저 테그를 심어둠으로써

색인이 제거될 수 있었습니다.

정말 길고 긴 시간이 지나서야 색인이 모두 제거될 수 있었네요.

지난 6개월 되돌아보기 (이사, 경매, AI)

snowman95 — Wed, 12 Jun 2024 20:59:24 +0900

장장 6개월. 꽤 오랜 기간 블로그를 쉬게 되었네요. 짧은 기간동안 세상이 어마어마하게 변했습니다.

올해 제일 큰 목표는 이사였죠. 이사하고 나서가 문제였을 줄이야...

1월에 이사 준비한다고 짐 처분하고, 새 집 알아보고, 이사하고..

이사 하고 잘 살고있는데 갑자기 건물 공사한다고 해서 집주인이랑 실랑이 하다가... 이제 여름이네요.

정말로 큰 맘먹고 좋은 집에 비싼 돈 주고 이사한건데 너무나 억울하고 화가 나더군요.

한 달 반 동안을 창문이 밀봉되어서 못열고 살았습니다. 진짜 지옥같은 삶이었습니다.

건물이 완전히 공사판이었고, 아침 7시 부터 침대 옆 창문 바로 앞에 공사장 인부들이 돌아다니고 대화소리와 시끄러운 공사 소음공해로 눈을 떠야했고, 환기가 안돼서 집에 냄새가 너무 심하고 빨래를 돌리면 숨이 막힐 정도로 집이 습했습니다.

이 모든 불편과 고통을 그저 양해를 바란다는 말로 쉽게 넘어가려고 하는 집주인 분. 진짜 레전드...

제 도덕적인 관념상 절대로 그냥은 넘어갈 수 없었습니다. 제가 또 정의에 죽고 정의에 사는 INFJ 아닙니까?

처음에는 대화로 풀어보려 했습니다.

"집 계약할때 공사한다고 얘기했었다.", "나도 창문을 밀봉하는 지 몰랐다. 공사업체 한테 늦게 전달 받았다."

책임은 공사업체에 떠넘기고 대화를 회피하시길래 저도 더 이상의 대화는 포기하고, 딱딱한 텍스트 문자로 대응했습니다.

물론 수 많은 세입자가 있고 모든 상황을 다 고려할 수 없었다는 거 이해는 하는데, 미안하다. 죄송하다. 그 말 한마디가 그렇게 어려우셨나 싶습니다.

제가 임대차 계약시 풀 버전으로 녹음해둔 파일이 있어서 다행이지, 만약에 녹음 안했으면 "그때 계약할때 공사한다고 얘기했다." 고 끝까지 밀어 붙이면서 기억 안나시냐면서 대충 넘어가려고 했을 것입니다.

결론은 공사 기간 동안 월세를 안내는 것으로 합의를 잘 봤고, 그 길고 길던 공사도 이제는 끝났네요.

문득 리처드 도킨스의 이기적인 유전자 라는 책 제목이 생각나네요.
논리적으로 이해가 안된다 싶은 문제들은 알고보면 정치적인 문제가 엮인 것이 대부분이고 그 정치적인 문제들은 입장 차이와 이해 관계 때문에 발생하는 것이죠. 나한테는 이익 상대방 한테는 손해. 정치는 니편 내편 싸움. 더 깊이 들어가서 개인으로 봤을땐 나 그리고 모든 타인.

그러한 배경에는 "살아남아라" 라는 거스를 수 없는 DNA 안에 프로그래밍 된 로직 때문이겠죠.

근데 누군가는 나만 아니면 돼, 내가 살아남기 위해서는 남을 짓밟아도 된다. (심하면)남을 짓밟아야한다. 라는 생각이 생존에 유리하다고 생각하는 것 같고, 누군가는 모두가 상생하고 협력하는 것이 생존에 유리하다고 생각하는 것 같습니다.

결국 개개인은 다 다른 개체고 생각도 다르고 입장도 다르고 부딪힐 수 밖에 없는데

그걸 완만하게 해결할 수 있는게 돈. 강경하게 해결할 수 있는게 법.

법과 도덕 없으면 모두 길거리 짐승이나 다름 없는거 같습니다..

결국엔 제 문제도 입장차이로 부딪혔다가 돈으로 해결되었네요.. 그게 아니었으면 법으로 해결해야 되는거고.. ‍

이기적이고 추악한 어른이 되지말자. 절대로 나를 잃지말자. 항상 되내이고 가슴 깊이 새기며 살아갑니다.

경매 공부

4-5월에 걸쳐서 경매 공부에 엄청 집중했었습니다.

1. 몰라서 당했다는 말을 하지 않게 대비하기 위해

2. 부동산 조정장에 기회가 온다면 잡기 위해 준비.

처음엔 이론만 있는 책을 4권 정도 읽고, 복잡한 권리분석을 법적으로 해결하는 방법에 대한 책, 인테리어, 누수, 수리에 관한 책 등등..

퇴근하고는 유료 경매사이트 뒤적거리면서 집주변 부터 여러 지역을 살펴봤습니다.

5월에는 직접 임장도 다니고, 입찰을 위해 은행가서 수표를 뽑았습니다.

결론적으로는 입찰하려고 했던 첫번째 아파트는 가격이 싸야만 매리트가 있었는데 다른 사람이 너무 비싸게 낙찰을 해서 허무하게 끝나버렸습니다. 지난번 유찰된 가격보다 더 비싸게요!!

그 다음에 보던 아파트도 유찰될 거라고 생각했는데 누군가 현 시세로 매도 했을때 수익률 0% 가격에 낙찰받더군요. 실거주 목적이었나 봅니다... 왜 하필이면..

어쨌건 좀 허무하게 끝나긴 했는데 사실은 해보면서 느꼈던 것은.

아직은 돈을 더 모아야 한다는 거였습니다.

아주 한정된 돈으로 수익 내려고하니, 확신이 들 때까지 너무나 많은 노력과 시간이 너무 많이 들어갔습니다.

근데 결국에는 비싼 돈주고 그냥 맘편하게 사버리는 사람을 보니 많이 허무하다고 느꼈고요.

제 스스로도 확신이 마지막의 마지막 순간까지도 안들어서 포기하기도 했습니다.

이렇게 된거, 여기서 올 스톱하기로 했습니다. 당분간 마음을 비우고 건강을 되찾으려고 합니다.

결국엔 AI

오늘은 역삼 센터필드에 가서 AWS GenAI 강의를 듣고 왔는데요.

AI 비용이 인건비 보다 저렴해지는 실제 사례를 보면서, 이러고 있을 때가 아닌데 싶더군요.

공부해서 손해본 적은 없었습니다. 다시 공부를 좀 하면서 블로그도 조금씩 활성화 시켜보려고 합니다.

생각은 줄이고, 행동은 늘이는 방식으로 개인 프로젝트도 다시 기획해 봐야겠습니다.

어느 순간부터 프론트엔드라는 틀에 갇혀버린 거 같은데 이제는 틀에서 벗어나서 개발 영역을 확장해야 될 때인 거 같습니다.

하반기에는 앱개발과 생성형AI !

리액트 렌더링 최적화를 위한 useDeferredValue 는 debounce 의 완전한 대체제가 아니다.

snowman95 — Fri, 29 Dec 2023 15:40:50 +0900

리액트 18 버전에서 추가된 기능입니다.

useDeferredValue 는 말그대로 "지연된 값을 사용" 하는 훅 입니다.

이 훅에 대해서 오해가 있었는데요. 값을 지연한다고 하기에 debounce 의 대체제 라고 생각했습니다.

그래서 너무나 당연히 이렇게 쓰면 API 요청이 지연되어서 들어간다고 생각 했었으나, 실상은 그렇지 않았습니다.

  const [input, setInput] = useState<string>('');
  const deferredInput = useDeferredValue(input);
 
  useEffect(() => {
    if (deferredInput) {
      fetchData(deferredInput);
    }
  }, [deferredInput]);

그렇습니다... 지연된 값을 가지고 매우 무거운 렌더링 작업을 했을때야 비로소 지연이 적용이 되는 것입니다.

  const [input, setInput] = useState<string>('');
  const deferredInput = useDeferredValue(input);

  return (
    <>
      <input value={input} onChange={생략} />
      <Component text={deferredInput}/>
    </>
  )
  
const Component = memo(function Component({text})=>{
  // text를 렌더링 하는 굉장히 무거운 컴포넌트임
  return <></>
}

//

여전히 빈번하게 바뀌는 상태 값에 영향을 받는 네트워크 요청에 대한 최적화를 하고 싶으면 debounce 를 쓰는게 맞습니다.

빈번히 바뀌는 상태 값에 영향을 받는 굉장히 비싼 렌더링을 최적화 할때 useDefferedValue 를 쓰는게 맞습니다.

역시 공식문서를 여러 번 정독해야 될 것 같습니다.

https://react.dev/reference/react/useDeferredValue

useDeferredValue – React

The library for web and native user interfaces

react.dev

코딩수련장

[6월 정산 수익 243만원] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 환전, QQQI, TIGER 배당커버드콜 엑티브, 월2% 배당

6월을 정리하며

[속보]삼성·SK, 서남권 반도체 클러스터 최대 900조 투자 AI 데이터센터 포함 SK 1000조 투입 계획

하하하하하!! 더 떨어져봐!!!! 배당 받으면 그만이야!!!!

어.. 어...오른다? 약속의 1시 U자 드리프트 미쳤냐고!!!!!

튀.. 튀어잇!!!!

약속의 2시

자자 6월 정산 해볼까요?

200만원 달달하노

고배당 월배당 ETF 정리해보겠습니다.

① 미국 라인업: QQQI(월말) + JEPQ(월 중순)

② 국내 라인업: RISE 미국테크100데일리고정(월말) + ACE 미국반도체데일리타겟(월 중순)

[AI발 생존 일지] 메이플스토리 주간보스돌이 쌀먹

[AI발 생존 일지] AI와 함께한 지난 6개월 (OpenClaw, 앱개발, 블로그 자동화, 유튜브)

지난 6개월의 이야기..

결론은 또 다시 미궁속으로

[6월 4주차] 수익 80만원 | 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 특별 배당으로 월2% 배당주는 TIGER 배당커버드콜 엑티브

응~ 배당 받으면 그만이야~ 6월 2-3주차 결과 입니다.

환전 결과

배당 결과

매매 결과

계획

[개발자 이야기] AI Agent 와 인터뷰를 하라. 계획이 가장 중요하다. 쓰레기를 넣으면 쓰레기가 나온다. (grill-me)

요구사항 전달의 중요성

사전 인터뷰를 해라

진짜 개꿀팁. (돈 안받을 테니 광고 누르고 가세요)

[AI] AI 팩토리 건설, 초지능,폭발하는 데이터센터 AI칩 수요, 미국AI vs 중국AI 음모론 (퍼온글)

AI 팩토리

폭발하는 AI 칩 수요

재귀적 자기개선의 초기 단계

핵심 연료: 석유 -> 컴퓨트 로의 이동

AI 팩토리의 병목: 전력과 반도체

빅테크 주식이 못 오르는 이유: 무리한 설비투자

AI 버블론: 사실은 돈이 한바퀴 도는 것이다.

엔비디아가 못오르는 이유: 모두가 자신의 칩을 만드려고 한다.

엔비디아 젠슨황이 순회 공연을 그렇게 열심히 다닌 이유

중국 AI vs 미국 AI

폭발적인 데이터베이스 건설

소버린 AI

기술 기업이 국가권 권력을 쥔다면?

AI 와 고용

AI 가 완전히 뒤바꾼 고용 보상 체계. 이런 AI발

토큰의 경제화

지능 권력의 세 갈래 길

AI 규제, 소프트웨어의 몰락

AI 운영체제

애플은 뭐하냐

에이전트 결제 프로토콜

정부가 기업 지분을 사들인다.

당신이 진짜 사람이라는 것을 증명하기

AI 모델의 통제

우주로 가즈아

카르다셰프 척도

우리는 어떡하지

AI 발 이젠 진짜 멈출 수 없음

[6월 2-3주차] 수익 51만 4천원 | 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 | 환전, QQQI, JPEQ, 월1% 배당

응~ 배당 받으면 그만이야~ 6월 2-3주차 결과 입니다.

환전 결과

배당금

아직 안 끝났습니다.

최종 합산 연 평균 기대 수익률 (Total Return)

[주식 투자] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략 유휴 RP이자 대신 고배당 커버드콜 발라먹기 (QQQI, JEPQ, QLD)

[주식 투자] 응~ 배당 받으면 그만이야~고배당 갈아타기 전략

1. 전략 소개: "그만이야" 전략이란?

2. 구체적인 투자 방법 (Step-by-Step)

① 평시 운용: 고배당 파이프라인 구축 (JEPQ, QQQI)

② 조건부 보너스: 환율 박스권 플레이

③ 영혼의 한 타: 대폭락장 레버리지 매직 (VIX 지수 활용)

3. 투자 리스크 및 주의사항

4. 기대 수익률 분석

5. 신의 한 수: 배당금은 'QLD(나스닥 2배)'로 무지성 재투자

"그만이야" 전략의 QLD 배당 재투자 메커니즘

1. 평시 (대세 상승장): 자산 양방향 폭발

2. 폭락장 시나리오: 오히려 좋아, QLD 바겐세일

AI 혁명이 일어났다. 5년차 FE 개발자인 나는 Claude Code Max20 을 구독하고 별의 별 짓을 다 해봤다.

AI 혁명이 일어났다.

"이런 흐름에서 5년차 FE 개발자인 나는 도대체 어떻게 살아야할까?"

두쫀쿠 월드

게임 공장

[속보]
삼성·SK, 서남권 반도체 클러스터 최대 900조 투자
AI 데이터센터 포함 SK 1000조 투입 계획