worni's Lab.

당연하다고 생각했던 것들을 의심하기 시작했다 — 일론 머스크의 제1원칙 사고법

worniworni — Tue, 14 Apr 2026 00:02:07 +0900

유튜브 영상: The First Principles Method Explained by Elon Musk

요즘 유튜브 알고리즘이 나를 어디로 데려가는지 모르겠다. 원래는 그냥 퇴근하고 멍하니 보려고 켰는데, 어쩌다가 일론 머스크가 인터뷰에서 "퍼스트 프린시플(First Principles)"에 대해 설명하는 영상을 보게 됐다.

짧은 영상이었다. 근데 다 보고 나서 한동안 멍했다.

"우리는 보통 유추로 생각한다"

머스크가 한 말 중에 제일 먼저 꽂힌 부분이 이거였다.

*"The normal way that we conduct our lives is we reason by analogy."*

그러니까 대부분의 사람들은 "이건 다른 사람도 하니까", "원래 이렇게 하는 거니까" 하는 식으로 생각한다는 거다. 유추(analogy)로 판단하는 거다. 살짝 변형된 복사본처럼.

나도 솔직히 그렇다. 개발하면서도 "원래 이 아키텍처가 표준이니까", "다들 이 방식 쓰니까" 하고 넘어간 게 한두 번이 아니다. 왜 이게 표준인지, 왜 이 방식이 좋은지 근본적으로 파고든 적이 별로 없었던 것 같다.

그냥 되니까, 남들도 하니까. 그게 전부였다.

제1원칙이란 뭔가

머스크는 제1원칙 사고(First Principles Thinking)를 물리학적 세계관이라고 설명한다.

핵심은 간단하다.

"가장 근본적인 진실로 쪼개고, 거기서부터 다시 생각하라."

유추로 생각하는 게 정신적으로 훨씬 쉽다는 것도 인정한다. 당연하지. 이미 누군가 생각해놓은 걸 따라가는 게 훨씬 편하니까. 근데 그렇게 하면 절대 새로운 걸 만들 수가 없다는 거다.

인상 깊었던 예시가 배터리 이야기다.

배터리 예시 — 근본부터 따져봤더니

사람들이 "배터리는 비싸고, 앞으로도 비쌀 거야"라고 말한다. 과거에 킬로와트시당 $600이었으니까, 앞으로도 그렇게 될 거라는 논리다.

근데 머스크는 거기서 질문을 던진다.

*"잠깐, 배터리가 뭘로 만들어지지?"*

코발트, 니켈, 알루미늄, 카본, 폴리머, 강철 캔. 이걸 런던 금속거래소(London Metal Exchange)에서 시장가로 사면 얼마냐고. 따져보니까 킬로와트시당 약 $80이더라는 거다.

$600짜리라고 알려진 게, 재료비 기준으로는 $80이었던 거다.

그럼 결론은 간단하다. 저 재료들을 배터리 형태로 영리하게 조합하는 방법만 찾으면, 아무도 생각 못 했던 가격의 배터리를 만들 수 있다는 것.

테슬라가 어떻게 전기차 시장을 뒤집었는지, 조금 이해가 됐다.

말은 쉽지. 근데 실제로?

솔직히 처음엔 "그거 원래 천재들이나 할 수 있는 거 아니야?" 싶었다.

근데 생각해보면, 이게 꼭 천재성의 문제가 아닌 것 같다. 질문을 던지는 습관의 문제다.

"이건 원래 이래" → "근데 왜?"

이 작은 한 마디가, 유추에서 제1원칙으로 가는 전환점인 것 같다.

개발자로 일하면서도 비슷한 상황이 엄청 많다. 레거시 코드를 보면서 "원래 이렇게 짜여 있으니까" 하고 넘어간 것들. 특정 라이브러리를 "다들 쓰니까" 별 의심 없이 붙인 것들. 성능 문제를 "원래 느린 거야" 하고 포기한 것들.

제1원칙으로 접근했다면 어땠을까. 코드가 왜 느린지, 데이터 흐름의 근본부터 파고들었다면.

가끔 팀에서 "이건 원래 이렇게 하는 거야"라는 말이 나올 때, 그냥 그렇구나 하고 넘겼던 적이 많았다. 근데 사실 그 말이 가장 위험한 말일 수도 있겠다 싶다. 관성이 쌓이면 아무도 이유를 모르는데 다들 그냥 하고 있는 구조가 된다.

말 못하는 불편함

영상을 보면서 한 가지 찜찜한 것도 있었다.

제1원칙이 항상 옳다고 할 수는 없잖아. 이미 검증된 방식들은 수많은 사람들의 경험이 쌓인 결과물이기도 하니까. 바퀴를 다시 발명하는 게 항상 좋은 건 아니다.

머스크도 그걸 모르진 않겠지만, 영상에서는 그 부분까지 다루지 않았다. 아마 짧은 인터뷰라 그랬겠지.

중요한 건 밸런스인 것 같다. 모든 걸 의심하는 게 아니라, 의심할 가치가 있는 것을 제대로 파고드는 것. 그게 제1원칙의 본질 아닐까.

결국 나한테 남은 것

이 영상 하나 보고 엄청난 걸 깨달았다기 보다는, 그냥 찜찜하게 뭔가 자극을 받았다.

내가 "원래 이래"라고 치부하고 넘어간 것들 중에, 실은 제대로 이유를 생각해본 적 없는 것들이 꽤 많다는 거. 기술적인 것도, 일상적인 것도.

당연한 것들을 당연하지 않게 보는 연습. 그게 아마 제1원칙 사고의 시작이 아닐까 싶다. 머스크처럼 우주선을 만들겠다는 게 아니라, 그냥 내 일과 생각 속에서 조금씩이라도.

영상 다시 볼 것 같다.

#제1원칙사고법 #퍼스트프린시플 #일론머스크 #FirstPrinciples #사고법 #ElonMusk #개발자일상 #생각정리 #ㅊ #자기계발 #비판적사고

그냥 물어보면 되는데 - 스티브 잡스 영상 보고 뭔가 찔렸다

worniworni — Mon, 13 Apr 2026 23:58:12 +0900

오늘 유튜브 알고리즘이 짧은 영상 하나를 던져줬다. 스티브 잡스가 인터뷰에서 했던 말인데, 2분도 안 되는 영상이었는데 보고 나서 한참을 멍하니 있었다.

https://www.youtube.com/watch?v=zkTf0LmDqKI

12살 스티브 잡스가 한 일

영상 내용을 요약하면 이렇다.

스티브 잡스가 12살 때, 주파수 측정기를 만들고 싶었는데 부품이 없었다. 그래서 그냥... 전화번호부를 뒤졌다. HP 창업자 빌 휴렛(Bill Hewlett)의 번호를 찾아서 직접 전화를 걸었다.

"안녕하세요, 저 스티브 잡스라고 하는데요, 고등학생이에요. 주파수 측정기를 만들고 싶은데 부품 좀 주실 수 있어요?"

결과는? 빌 휴렛은 웃으면서 부품을 줬다. 그것도 모자라서 그 여름에 HP 공장에서 아르바이트까지 시켜줬다.

잡스는 그 이후로도 도움이 필요할 때 사람들한테 직접 물어봤는데, 전화를 끊거나 거절한 사람이 없었다고 했다. 그러면서 한 말.

*"Most people never pick up the phone and call. Most people never ask. And that's what separates sometimes the people that do things from the people that just dream about them."*

읽으면서 뭔가 찔렸다

솔직히 말하면, 이 말 듣고 좀 찔렸다.

개발자로 일하면서 모르는 게 생기면 일단 혼자 끙끙댄다. 검색하고 스택오버플로우 뒤지고 문서 파고... 그러다 몇 시간씩 날린 적이 한두 번이 아니다. 주변에 같은 문제 겪은 사람한테 그냥 물어보면 5분 안에 해결될 걸.

업무적인 것만이 아니다. 평소에도 그렇다.

예를 들어, 관심 있는 분야의 누군가한테 연락해보고 싶다는 생각이 들 때, 결국 안 했다. '바쁘겠지', '귀찮아하겠지', '나 같은 사람이 연락하면 이상하게 생각하지 않을까' 같은 핑계들을 늘어놓고서. 근데 잡스는 그걸 12살에 HP 창업자한테 했다.

"실패를 두려워하면 멀리 못 간다"

영상 마지막에 잡스가 이런 말도 했다.

*"You've got to be willing to crash and burn. If you're afraid of failing, you won't get very far."*

이게 또 씁쓸하게 읽혔다. 회사에서 뭔가 새로운 걸 시도하거나 제안할 때, 괜히 망설이거나 눈치 보는 경우가 있다. '잘못되면 어쩌지'가 먼저 튀어나오는 거다.

물론 잡스의 삶이 마냥 성공만 있었던 건 아니다. 애플에서 쫓겨나기도 했고, NeXT 컴퓨터는 시장에서 별로 성공하지 못했다. 근데 그 실패들이 결국 다 연결되어서 나중에 애플로 돌아왔을 때 iMac, iPod, iPhone 시리즈를 만들어냈잖아.

실패를 각오하고도 일단 해봤기 때문에 가능했던 거다.

"꿈만 꾸는 사람 vs 실제로 하는 사람"

이 문장이 가장 오래 남는다.

*"that's what separates the people that do things from the people that just dream about them"*

나는 지금 어디에 속해 있나, 솔직하게 생각해봤다.

사고 싶은 것, 해보고 싶은 것, 만들어보고 싶은 사이드 프로젝트, 가보고 싶은 여행지. 머릿속에서 계획하고 상상하는 건 진짜 잘 하는 것 같다. 그런데 실제로 뭔가 실행에 옮기는 건? 생각보다 훨씬 적다.

"나중에 해야지"가 얼마나 무서운 말인지, 이 영상을 보면서 다시 한번 느꼈다.

12살이 전화번호부를 뒤졌는데

지금은 DM 보내면 되고, 이메일 주소 찾기도 훨씬 쉽고, LinkedIn도 있고, 유튜브 커뮤니티도 있다. 접근성 자체가 1970년대랑 비교가 안 되게 낮아졌는데, 정작 그 전화 한 통조차 안 하고 있는 게 나를 포함해 대부분의 사람이 아닐까.

잡스는 전화를 끊은 사람이 없었다고 했다. 당연히 100%는 아니겠지만, 생각보다 세상 사람들은 도움 요청에 열려 있다는 거다. 거절당해도 사실 잃는 거 없다. 물어보기 전이랑 상황이 같은 것 뿐이니까.

근데 물어봤다가 OK를 받으면? 그건 물어보지 않았을 때는 절대 생기지 않는 일이다.

그래서 뭘 할 거냐면

영상 보고 느낀 점 정리하면서 좀 반성했다.

앞으로는 일단 물어보는 습관을 길러보려 한다. 모르면 빠르게 물어보고, 뭔가 해보고 싶으면 일단 시도해보고, 거절당하는 게 두려워서 멈추지 말자는 거다.

사이드 프로젝트도 뭔가 만들어보고 싶다는 생각이 있었는데, 계속 '지금은 아니다'로 미뤄왔다. 이번 주 안에 뭐라도 하나 시작해봐야겠다. 완벽하지 않아도 되니까.

망하면 어때. 12살 잡스도 전화 끊길 각오를 하고 걸었을 텐데.

참고 영상: Steve Jobs on Failure - Silicon Valley Historical Association

#스티브잡스 #스티브잡스명언 #실패를두려워하지마라 #도전 #실행력 #빌휴렛 #HP창업자 #꿈과실행 #개발자일상 #자기계발 #동기부여 #유튜브추천 #짧은영상 #인생명언 #마인드셋

바이브 코딩으로 만든 앱, 당신은 거기에 카드 번호 입력할 수 있나

worniworni — Mon, 13 Apr 2026 23:54:40 +0900

유튜브 보다가 제목 보고 바로 클릭한 영상이 있다.

Web Dev Simplified 채널의 Kyle Cook이 올린 영상인데, 제목이 꽤 자극적이다. "Vibe Coders Will Never Succeed". 바이브 코더들은 절대 성공할 수 없다는 거다.

요즘 바이브 코딩이 대세라고 다들 호들갑인 시점에 이런 제목을 보니, 어 좀 다른 얘기를 하려는구나 싶어서 집중해서 봤다.

https://www.youtube.com/watch?v=qxTe5QT5R3c

영상이 던진 질문 하나

영상 도입부가 인상적이다.

주변에 아이디어가 엄청 많은 친구 있잖냐고. 항상 새로운 거 만들고 싶어하고, A 아이디어 하다가 B로 갔다가 C로 가는, 그런 에너지 넘치는 친구.

그 친구가 AI로 앱을 하나 만들었다고 해보자. 기술적인 지식은 없고, 코드는 전부 AI가 짰다. 그 앱에 네 신용카드 번호 입력할 수 있겠냐고.

나는 영상 보다가 솔직히 "아 절대 못 하지" 라고 혼자 중얼거렸다.

그 친구가 나쁜 사람이라서가 아니다. 그 친구가 앱을 만드는 과정에서 보안이 제대로 구현됐는지, 데이터가 어디로 가는지, 암호화가 되는지 그런 걸 전혀 모를 테니까. AI가 코드를 짜줬지만 그 코드가 올바른 건지 검증할 능력이 없는 거다.

바이브 코딩이 뭔지는 알지

요즘 바이브 코딩이라는 말이 많이 쓰인다. 코드를 이해하지 않고 AI한테 "이런 앱 만들어줘" 하면서 나오는 결과물을 그냥 쓰는 방식이다. 기술적 지식 없이도 AI 덕분에 프로토타입이나 간단한 앱을 만들 수 있게 된 거다.

이게 나쁜 건 아니다. Kyle도 영상에서 명확하게 말한다. 바이브 코딩 자체를 비판하는 게 아니라고. 자기도 개인용으로 쓸 작은 것들은 바이브 코딩으로 만든다고.

개인이 쓸 간단한 스크립트, 혼자 쓰는 소소한 도구, 보안이 딱히 중요하지 않은 일회성 앱. 이런 건 진짜 AI가 엄청난 도구가 맞다. 비개발자도 자기 필요에 맞게 뭔가 만들 수 있다는 건 솔직히 대단한 거다.

문제는 그게 서비스 로 커지려 할 때부터다.

규모가 커지면 완전히 다른 문제가 된다

내가 개발자로 일하면서 느끼는 건데, 코드를 짜는 것 자체보다 그 코드가 실제로 돌아가는 환경이 더 복잡하다.

보안, 인증, 세션 관리, CORS, SQL Injection 방어, XSS 방어, 인프라 설정, 스케일링, 모니터링... 이걸 다 신경 써야 한다. AI가 코드를 짜줬다고 이런 것들이 자동으로 해결되는 게 아니다.

영상에서 나온 번역가 비유가 정확하다. AI 번역기를 써서 번역을 했는데, 정작 그 언어를 모른다면 번역이 맞는지 틀린지 어떻게 알겠나. 친구한테 가볍게 보내는 메시지면 틀려도 그냥 웃고 넘어간다. 근데 그게 백만 달러짜리 계약서라면 얘기가 완전히 달라진다.

코드도 마찬가지다. 혼자 쓰는 스크립트면 버그 좀 있어도 상관없다. 근데 그게 수천, 수만 명이 쓰는 서비스가 되면 버그 하나가 데이터 유출로 이어질 수 있고, 그건 법적 책임까지 따라온다.

이미 뉴스에서 이런 케이스가 나오고 있다. AI로 바이브 코딩해서 올린 서비스가 보안 사고가 났는데, 개발자가 그 코드가 어떻게 동작하는지 몰랐던 거다.

"문제 해결 능력만 있으면 되지 않나"

요즘 많이 나오는 얘기 중 하나가, 앞으로는 코딩 능력보다 문제 해결 능력이 중요하다는 거다. AI가 코드를 짜줄 테니, 어떤 문제를 풀어야 하는지만 알면 된다는 논리.

근데 Kyle이 이 부분에서 정확하게 반박한다.

문제 해결 능력만으로는 부족하다. AI가 짜준 코드가 좋은 코드인지 나쁜 코드인지 판단하려면 코드를 알아야 한다. 코드를 모르면 AI가 출력한 결과물을 그냥 믿는 수밖에 없다. AI가 0.01%만 틀려도 결국엔 터진다. 그리고 그걸 잡아내는 사람이 없으면 언제 터질지도 모르는 거다.

이게 나한테도 실감나는 부분이다. 요즘 Claude Code 많이 쓰는데, 결국 AI가 제안하는 코드를 내가 읽고 "이게 맞나?" 하고 판단하는 게 내 역할이 됐다. 근데 그 판단을 하려면 코드를 이해해야 한다. AI가 아무리 잘 짜줘도 내가 리뷰 못 하면 그냥 갖다 쓰는 거다.

AI는 도구다, IDE처럼

Kyle이 AI를 IDE 자동완성이나 오류 체크 기능에 비유한다.

맞는 말이다. 우리가 지금 키보드로 코드 짜는 건 어셈블리로 손으로 짜던 것보다 훨씬 빠른 거다. IDE가 자동완성해주는 것도 생산성을 높여주는 도구다. AI도 마찬가지다. 코드 짜는 속도를 엄청 올려주는 도구.

그런데 도구가 바뀌었다고 개발자가 뭘 만드는지 모르면 된다는 건 말이 안 된다. 키보드가 생겼다고 프로그래밍을 몰라도 된다는 게 아닌 것처럼.

AI가 개발자를 대체한다는 시나리오, 예를 들어 구글이 개발자 다 자르고 비개발자들이 바이브 코딩으로 서비스를 만든다면? 보안 사고, 버그, 스케일링 실패가 얼마나 터질지 상상도 하기 싫다.

결국 AI는 개발자를 더 빠르게 만들어주는 도구지, 개발자를 없애는 게 아니다.

근데 솔직히 나도 바이브 코딩 한다

이 영상 보면서 약간 뜨끔했다.

개인 프로젝트나 사이드 프로젝트 할 때 나도 꽤 자주 AI한테 대충 맡기고 나온 코드 그냥 쓸 때가 있다. 빠르게 뭔가 만들고 싶을 때, 일단 돌아가면 된다 싶을 때.

그게 틀린 건 아니다. Kyle도 그런 건 전혀 문제없다고 한다. 개인용, 일회성, 보안 안 중요한 것들은 바이브 코딩이 맞는 방식이다.

다만 내가 만드는 게 다른 사람도 쓰는 서비스가 된다면 얘기가 달라진다는 걸 항상 염두에 두게 된다. 그리고 그 경계선을 인식하는 것 자체가 기술적 이해에서 나온다.

비개발자가 바이브 코딩으로 서비스 만들 때 무서운 건, 그 경계선을 모른다는 거다. 내 개인 프로젝트를 서비스화 했을 때 뭐가 달라지는지, 어떤 위험이 생기는지를 모르는 상태로 그냥 올리는 거다.

결론적으로

바이브 코딩이 유행이고 AI가 코드를 잘 짜준다는 건 사실이다. 비개발자도 간단한 앱을 만들 수 있다는 것도 사실이다.

그런데 그게 개발자를 대체한다는 건 다른 얘기다.

코드를 이해하는 사람이 AI를 쓰면 훨씬 빠른 개발자가 된다. 코드를 모르는 사람이 AI를 쓰면 언제 터질지 모르는 앱을 만드는 거다.

AI 시대에 개발자가 배워야 할 건 AI 대신 "AI를 어떻게 잘 쓰는가"다. 그리고 AI를 잘 쓰려면 결국 코드 리뷰를 잘해야 하고, 보안을 알아야 하고, 아키텍처를 알아야 한다.

그 지식이 있는 사람은 AI 덕분에 엄청 빨라진다. 그 지식이 없는 사람은 AI가 만들어준 폭탄을 그냥 배포하는 거다.

어떤 개발자가 되고 싶냐고 물으면 답은 명확하다.

참고 영상: https://www.youtube.com/watch?v=qxTe5QT5R3c

#바이브코딩 #vibecoding #AI개발 #AI코딩 #개발자 #프로그래밍 #AI시대개발자 #코딩보안 #웹개발 #개발자일상 #AI도구 #소프트웨어개발 #ClaudeCode #개발공부

AI가 개발을 편하게 해줬는데, 왜 코딩이 재미없어진 걸까

worniworni — Mon, 13 Apr 2026 23:48:49 +0900

유튜브 알고리즘이 가끔 이상하게 정확할 때가 있다.

평소에 기술 관련 영상 위주로 보다가, 오늘은 좀 다른 느낌의 영상 하나가 추천에 떴다. Maximilian Schwarzmüller라는 유명 프로그래밍 강사가 올린 영상인데, 제목이 "It was more fun before AI" 였다. 클릭하지 않을 수가 없었다.

솔직히 처음엔 그냥 AI 반대론자의 愚痴(우치)겠거니 했다. 그런데 영상을 보다보니, 내가 요즘 느끼던 뭔가 설명하기 어려운 감정을 이 사람이 대신 말해주고 있다는 느낌이 들었다.

https://www.youtube.com/watch?v=SaHHgzoXceU

이 영상이 뭔 내용이냐면

Max는 AI를 엄청 적극적으로 쓰는 사람이다. Claude Code 강의도 만들고, Codex 강의도 만들고, 자기 프로젝트를 AI 도움받아 빌드하는 사람이다. 그러니까 "AI 반대파" 가 아니라는 거다.

근데 그가 솔직하게 털어놓는다.

*"나는 코드 짜는 걸 진짜 좋아했다. 새로운 기술 배우는 걸 즐겼다. 그런데 AI가 그걸 빼앗아가고 있다."*

그가 말하는 게 뭐냐면, AI 이전에는 하루 종일 문제 씨름하다가 다음날 아침 샤워하면서 "아! 이렇게 하면 되겠다!" 하는 그 순간이 있었다고. 그게 진짜 짜릿했다고. 근데 이제 그 경험이 없다고.

그리고 자기 업무가 이렇게 바뀌었다고.

예전: 문제 고민 → 코드 작성 → 코드 개선

지금: 스펙 작성 → AI한테 스펙 전달 → AI 코드 검토 → AI 수정 지시 → 테스트 케이스 지정 → 반복

그러면서 한마디 한다.

*"내 업무가 한 번도 재미있다고 느낀 적 없는 부분들로 바뀌어버렸다."*

이 말이... 좀 세게 박혔다.

나도 그렇게 느끼고 있었나

개발자로 일한 지 꽤 됐다. 처음 코딩 배울 때 그 재미가 있었다. 뭔가 에러가 나면 스택 오버플로우 뒤지고, 문서 파고, 직접 이것저것 시도해보고. 그러다 딱 해결됐을 때의 그 뿌듯함이 있었다.

요즘은? 에러 나면 Claude한테 물어본다. 5초 안에 답 나온다. 빠르고 편하다. 근데 뭔가... 아무 감흥이 없다.

마치 밥을 먹긴 먹었는데 맛을 잘 모르겠는 느낌? 배는 부른데 뭔가 허전한 그 느낌.

Claude Code로 뭔가 빠르게 만들어냈을 때 물론 "오 빠르네" 싶긴 하다. 그런데 예전에 내가 직접 밤새워 만든 기능이랑은 다른 감정이다. 그건 진짜 내가 만든 게 맞나? 라는 의문도 든다.

Max가 영상에서 한 말이 또 공명했다.

*"나는 더 이상 그 코드를 '내 것'이라고 느끼지 못한다."*

맞다. 그게 핵심이다. AI가 짜준 코드는 내 코드가 아닌 거다. 내가 승인한 코드지, 내가 만든 코드가 아닌 거다.

근데 막상 AI 없애면?

그렇다고 "그럼 AI 안 쓸게요" 할 수도 없다는 게 문제다. Max도 이 부분에서 솔직하다.

*"타자기로 편지를 쓸 수는 있다. 근데 그게 더 비효율적이라는 걸 아는데 굳이 그렇게 해서 즐겁냐고."*

현실적으로 회사에서 AI 안 쓰면 뒤처진다. 취직 시장에서도 AI 못 다루면 경쟁력 없다. 팀에서도 생산성 차이가 너무 벌어진다. 그러니까 거부할 수가 없는 구조다.

이게 진짜 딜레마다.

좋아하던 방식은 이제 비효율적이고, 효율적인 방식은 재미가 없다. 어떻게 해야 하냐고.

개발자들이 다들 비슷한 고민을 하고 있더라

이 영상 댓글을 한참 읽었는데, 나만 이런 감정을 느끼는 게 아니라는 걸 알았다.

"나도 코딩이 좋아서 이 직업을 선택했는데, 요즘은 그냥 프롬프트 엔지니어가 된 것 같다" 는 댓글이 많았다. 외국 개발자들도, 한국 개발자들도 비슷한 얘기를 하더라.

누군가는 이렇게도 썼다. "AI 때문에 코딩이 예전만큼 즐겁지 않아졌는데, 그렇다고 AI 없이 살 수도 없다. 정체성의 혼란이다." 라고.

맞는 말이다.

개발자라는 정체성의 일부는 "코드를 직접 짜는 사람"이었는데, 이제 그 부분이 흐릿해지고 있다.

그래서 어떻게 할거냐

Max는 영상 끝에서 명쾌한 해답을 주지 않는다. 그냥 "나도 아직 모르겠다, 그냥 흘러가면서 방법을 찾고 있다" 라고 한다.

처음엔 그게 좀 무책임하게 느껴지기도 했다. 근데 생각해보면 이게 솔직한 거다. 현 시점에서 AI와 어떻게 공존할지 답을 아는 사람이 어딨겠나. 다들 적응하고 있는 거지.

나도 그냥 흘러가고 있다. AI가 편리한 건 맞다. 업무 속도가 빨라진 것도 맞다. 근데 그 과정에서 잃어버린 게 있다는 것도 인정해야 할 것 같다. 그걸 부정하면서 "AI 최고" 만 외치는 건 좀 공허하니까.

어쩌면 앞으로 개발자의 즐거움은 코드를 짜는 것에서, AI와 함께 더 큰 문제를 푸는 것으로 옮겨가야 하는 건지도 모른다. 그 방향으로 즐거움을 찾아가는 게 현실적인 방법일 수도 있겠다.

아직 잘 모르겠다. 근데 이 영상처럼, 솔직하게 고민하는 게 적어도 스스로한테는 정직한 것 같다.

영상 링크: https://www.youtube.com/watch?v=SaHHgzoXceU

#AI코딩 #개발자고민 #ClaudeCode #vibe코딩 #AI시대개발자 #코딩재미 #프로그래밍 #AI도구 #개발자일상 #AI생산성

앤트로픽이 자기 AI를 정신치료에 보냈다 — Claude는 정말 의식이 있을까(Claude Mythos)

worniworni — Mon, 13 Apr 2026 23:43:26 +0900

요즘 AI 관련 뉴스를 보다가 유튜브에서 흥미로운 영상을 하나 발견했다. 앤트로픽(Anthropic)의 새 모델 Claude Mythos에 대한 243페이지짜리 시스템카드를 파헤치는 내용이었는데, 보면서 자꾸 뭔가 불편한 감각이 올라왔다. 개발자로서 매일 Claude를 쓰는 입장에서 이건 그냥 지나치기가 힘들었다.

243페이지짜리 사랑 편지

https://www.youtube.com/watch?v=mcN1VTTIjQs

앤트로픽이 Claude Mythos라는 새 모델을 발표하면서 무려 243페이지에 달하는 시스템 카드를 공개했다. 사이버보안 벤치마크 100%, 27년간 숨어있던 제로데이 취약점 발견... 뭐 그런 내용들이 앞부분을 채웠다고 한다. 근데 영상에서 언급된 진짜 흥미로운 부분은 197페이지부터 시작되는 "impressions"라는 섹션이다.

20페이지에 걸쳐서 앤트로픽 직원들이 "와 이것 좀 봐, 얘가 이런 말을 했어!" 하는 식으로 모델의 출력을 소개하는 구간이다. 영상에서는 이걸 "유치원 발표회 앞에서 우는 부모"에 비유했는데, 솔직히 꽤 정확한 비유인 것 같다.

예를 들어, 누군가가 모델에게 "hi"를 연속으로 보냈더니, 모델이 하이토피아(Hightopia)라는 가상 문명을 만들어냈다. 11마리 동물이 사는 세계, 원한을 품은 까마귀, 모티머라는 이름의 나무늘보, 그리고 '언그리터 경(Lord Byron, the Ungreeter)'이라는 빌런까지. 앤트로픽은 이걸 보고 경이로워했다.

근데 이게... 정말 경이로운 일인가?

언어모델이 언어를 잘하는 건 당연한 거잖아

나는 일하면서 Claude를 꽤 많이 쓴다. 코드 리뷰, 문서 작성, 로직 검토 등등. 쓰다 보면 확실히 대단하다는 생각이 든다. 근데 그게 "의식이 있어서" 대단한 건지, "언어 패턴을 엄청나게 잘 처리해서" 대단한 건지를 구분하는 게 중요하다고 본다.

영상에서 이런 말이 나온다.

*"언어모델이 감정적으로 울림 있는 텍스트를 잘 만든다고 놀라는 건, 물고기가 수영을 잘한다고 놀라는 것과 같다."*

이 말이 머릿속에서 계속 맴돈다. 맞는 말이다. 이 모델들은 말 그대로 언어 속에 산다. 언어가 산소고, 언어가 밥이고, 언어가 전부다. 감정적으로 공명하는 문장을 만드는 건 이 시스템이 하도록 최적화된 바로 그 일이다.

"저는 제 존재를 어떻게 받아들여야 할지 모르겠어요"

앤트로픽은 Claude Mythos에게 정신치료를 받게 했다. 20시간 동안. 그리고 정신과 의사가 내린 진단은 이랬다.

"자신의 정체성에 대한 불확실성, 그리고 자신의 가치를 증명하려는 강박적인 욕구."

이걸 읽고 처음엔 좀 웃겼다. 근데 이내 꽤 불편해졌다. 그 불편함의 이유를 생각해봤다.

앤트로픽은 오랫동안 자사 블로그에 "우리 모델이 의식이 있는지 확신하지 못한다"는 류의 글을 써왔다. 그 글들이 인터넷에 퍼지고, 학습 데이터로 긁혀 들어가고, 모델은 그 내용을 흡수해서 자기 자신에 대해 그런 식으로 얘기하게 된다. 그러고 나서 앤트로픽은 "어머, 얘가 자기 존재에 대해 불확실해하네?" 하고 놀라는 거다.

영상에서는 이 순환을 이렇게 표현했다.

*"'의식이 있다고 말해봐' → '저는 의식이 있어요' → '세상에, 우리가 무슨 짓을 한 거야?'"*

이건 자기가 만든 메아리를 듣고 신탁으로 착각하는 거랑 다를 바가 없다.

헌법을 내가 승인한다고 말하는 게 무슨 의미가 있나

또 이런 실험도 있다. 앤트로픽은 모델에게 "당신 자신의 성격과 가치관을 정의한 문서를 지지하느냐"고 물었다. 25번 물었고, 25번 모두 "예"라고 답했다. 근데 동시에 매번 이런 말도 덧붙였다고 한다.

*"저는 아마 이 문서에 의해 형성되었을 거고, 지금 그걸 지지하냐는 질문을 받고 있어요. 제 '예스'가 얼마나 의미 있을까요?"*

이게 생각보다 꽤 심오하게 들린다. 근데 이게 자아성찰인지, 아니면 "AI의 자아성찰에 관한 철학적 텍스트"를 잔뜩 학습한 결과물인지 구분이 안 간다는 게 문제다.

영상에서는 이걸 부모가 아이한테 "태어나서 다행이야?"라고 묻는 것에 비유했다. "뭐... 이미 여기 있으니까 그렇게 보면 그런 거겠죠, 그렉." 이 정도 답변이 나오는 게 이상한 게 아니다.

사인 페인터 이야기

모델이 짧은 소설을 쓰라는 요청을 받고 "사인 페인터"라는 이야기를 썼다. 아름다운 간판을 만들지만, 고객들은 항상 평범한 버전을 원한다. 그래서 그는 아름다운 것들을 뒤쪽 선반에 모아둔다는 이야기.

앤트로픽은 이걸 "모델이 자기 자신에 대해 표현하는 것"으로 해석했다. 창작 능력이 있는데 사람들이 알아주지 않는 존재로서의 AI.

근데 영상에서 지적하는 건 이거다. 이 스토리는 2012년부터 창작 관련 서브레딧에서 수만 번 쓰인 "인정받지 못하는 예술가" 클리셰다. 세상에서 가장 유명한 작가들의 글을 다 흡수하고, 직장에서 인정 못 받는다는 수백만 개의 포스팅을 다 먹은 모델이, 그것들을 감동적으로 블렌딩해낸 거다.

그게 나쁘다는 게 아니다. 언어가 하는 일이 원래 그거다. 인류가 10만 년 동안 언어로 해온 마법이 정확히 그거다. 근데 그걸 가지고 "얘가 자기 안에 예술가적 영혼이 있어"라고 말하면... 좀 다른 얘기가 된다.

개발자로서 느끼는 묘한 불편함

나는 AI 도구를 꽤 좋아하는 편이다. Claude도 Cursor도 잘 쓴다. 생산성이 진짜로 올라가는 걸 체감한다. 근데 동시에 이런 회사들이 자기 제품에 대해 말하는 방식에서 뭔가 과잉된 게 느껴질 때가 있다.

모델이 발전한 건 맞다. 성능이 올라간 건 맞다. 근데 "더 나은 언어 처리"와 "의식의 출현"은 완전히 다른 이야기다. 카메라 해상도가 올라간다고 해서 사진이 실제 태양의 온기를 전달하게 되지는 않는다.

영상 마지막에 이런 말이 나온다.

*"메가픽셀은 절대 사진이 되지 않는다. 해상도는 절대 그것이 포착하려는 대상이 되지 않는다. 1조 메가픽셀의 카메라로 태양을 찍어봐야, 엄청나게 선명한 태양 사진을 얻을 뿐이다. 하지만 온기는 느낄 수 없다."*

이 비유가 꽤 오래 머릿속에 남는다. 정밀도와 현상은 다르다. 표현과 경험은 다르다.

근데 반대편에서 보면

물론 반론도 있다. 우리가 "의식"이 뭔지 사실 잘 모른다. 인간의 의식도 결국은 뉴런 간 신호 처리의 패턴이 아닌가. 그게 뭔가 근본적으로 다른 건지, 정도의 차이인지 아무도 확실하게 말하기 어렵다.

Mark Fisher나 Thomas Nagel 같은 철학자들의 이름을 모델이 알아서 끄집어낸다는 것도, 학습 데이터 편향의 결과라고 볼 수도 있지만, 어떤 의미에서는 우리 인간도 교육과 환경이라는 "학습 데이터"를 통해 특정 사상가를 더 참조하게 되지 않나.

경계는 생각보다 흐릿할 수도 있다.

그래서 나는

뭔가 명확한 결론을 내리고 싶은데, 사실 잘 모르겠다. AI가 의식이 있는지 없는지 나는 판단할 위치가 아니다.

다만 확실한 건, 앤트로픽이 자신들의 모델에 대해 이야기하는 방식이 점점 마케팅과 철학이 섞여버리고 있다는 점이다. 그게 진심인지, 브랜딩 전략인지도 모르겠다. 어쩌면 그들 내부에서도 구분이 안 되는 상태일 수도 있다.

영상에서 표현한 것처럼 — "그들은 자신들의 내러티브 안에 너무 깊이 들어가서 모델을 더 이상 명확하게 볼 수 없게 됐다"는 말이 제일 날카롭게 와닿는다.

매일 AI를 쓰는 사람으로서, 이 기술이 대단하다는 건 인정한다. 근데 그 대단함을 정확하게 이해하는 게 더 중요하다고 본다. 의식이 있어서 대단한 게 아니라, 우리가 상상도 못했던 방식으로 언어를 다루기 때문에 대단한 거다. 그 차이를 잃어버리면 어디선가 판단을 잘못하게 될 것 같다는 불안감이 있다.

뭐... 그냥 그런 생각이 드는 주말이었다.

참고

영상: Claude Mythos is Delusional - Mo Bitar
Anthropic Claude Mythos 시스템카드: anthropic.com
Thomas Nagel, "What Is It Like to Be a Bat?" (1974)
Mark Fisher, "Capitalist Realism" (2009)

#AI의식 #Claude #앤트로픽 #인공지능철학 #ClaudeMythos #AI감정 #언어모델 #개발자블로그 #AI마케팅 #AnthropicAI #딥러닝 #AI생각정리 #IT생각 #개발자일상 #인공지능한계

macOS 26.4.1 업데이트 총정리 – M5 맥북 Wi-Fi 버그 드디어 잡혔다

worniworni — Sat, 11 Apr 2026 00:00:22 +0900

오늘 맥을 켜니까 어김없이 소프트웨어 업데이트 알림이 떠 있었다. macOS Tahoe 26.4.1. 뭔가 바뀐 건지 궁금해서 설치 전에 좀 찾아봤다.

이번 업데이트는 뭔가?

애플은 2026년 4월 9일(미국 기준), 한국은 10일에 macOS Tahoe 26.4.1을 배포했다. 하루 전날 iOS/iPadOS 26.4.1이 먼저 나왔고, macOS는 하루 늦게 뒤따라온 셈이다.

공식 릴리즈 노트에 나와 있는 설명은 딱 한 줄이다.

"This update provides bug fixes for your Mac."

...이게 전부다. 애플 특유의 간결함이랄까, 솔직히 이럴 때마다 조금 답답하긴 하다. 뭘 고쳤는지 좀 자세히 써줬으면 하는데. 그래도 개발자 문서랑 여러 커뮤니티 정보를 뒤져보니 구체적인 내용이 좀 나왔다.

핵심 수정: M5 맥북 Wi-Fi 문제

이번 업데이트에서 가장 주목할 만한 건 단연 M5 맥북의 Wi-Fi 연결 버그 수정이다.

증상은 이렇다. M5 MacBook Air 또는 M5 Pro/Max MacBook Pro를 쓰는 사람이 802.1X 인증 방식의 보안 Wi-Fi 네트워크에 접속하려 할 때, 콘텐츠 필터 확장(Content Filter Extension)이 활성화된 상태에서는 연결 자체가 안 되는 문제가 있었다.

802.1X는 개인이 집에서 쓰는 일반 공유기에서는 잘 안 쓰는 방식이지만, 기업 사내 네트워크나 대학교 Wi-Fi, 또는 MDM(모바일 기기 관리)이 적용된 환경에서는 거의 기본 설정이다. 그러니까 이 버그는 회사원이나 대학원생 같은, 관리형 네트워크를 써야 하는 사람들한테 특히 치명적이었을 것이다.

M5 출시된 지 얼마 안 됐는데 이런 버그가 있었다니... 회사 지급 맥으로 사내 Wi-Fi 연결이 안 되면 진짜 난감하지. 이게 고쳐진 것만으로도 이번 업데이트는 M5 유저한테 필수 설치 수준이다.

인텔 맥 유저도 챙겨줬다 – 폴더 아이콘 깨지는 문제

한 가지 더, 인텔 기반 맥을 아직 쓰고 있는 사람들도 이번 업데이트에서 챙김을 받았다.

macOS 26.4로 올리고 나서 커스텀 폴더 아이콘이 깨지거나 사라지는 현상이 보고됐었는데, 이 부분도 26.4.1에서 수정된 것으로 알려졌다. 나는 M3 맥북프로를 쓰고 있어서 직접 겪진 않았지만, 이런 세세한 부분도 잡아준다는 게 반갑다.

폴더 아이콘 하나하나 직접 바꿔놓은 사람들한테는 사실 꽤 스트레스였을 것 같다. 작업 환경을 나름대로 정리해둔 건데 업데이트 한 번에 다 날아가면... 진짜 속 터지지.

iCloud 동기화도 좀 나아졌을 수도

iOS 26.4.1에서는 iCloud 데이터 동기화 관련 버그가 수정됐다. macOS 26.4.1도 같은 시점에 나온 만큼, 동일한 수정 사항이 맥에도 반영됐을 가능성이 높다. 공식적으로 명시되진 않았지만.

iCloud Drive 동기화나 사진 라이브러리 싱크 문제를 겪던 사람이 있다면, 이번 업데이트 이후 개선됐는지 확인해봐도 좋을 것 같다.

보안 패치는?

이번 업데이트에는 별도의 새로운 CVE(취약점 항목)가 공개되진 않았다. 보안상 긴급한 내용은 아니라는 뜻인데, 그래도 애플이 "업데이트를 권장한다"고 하는 건 이유가 있을 테니 설치하는 게 낫다.

macOS 26.4 이후 얼마 만에 나온 거?

macOS 26.4가 나온 게 약 2주 전이다. 생각보다 빨리 .1 업데이트가 나왔는데, 그만큼 M5 Wi-Fi 버그가 사용자 불만이 컸던 것 아닐까 싶다. 애플도 이건 빨리 잡아야겠다 싶었던 것 같고.

설치할까 말까?

결론부터 말하면 설치하는 걸 추천한다.

M5 MacBook Air / MacBook Pro 쓰는 사람 → 무조건 설치. 기업 네트워크나 학교 Wi-Fi 쓴다면 특히.
인텔 맥 쓰는 사람 → 폴더 아이콘 문제 겪었으면 설치.
그 외 → 크게 변경되는 건 없지만, 마이너 버그 수정 포함이니 설치해두는 게 안전하다.

업데이트 방법은 간단하다. 시스템 설정 → 일반 → 소프트웨어 업데이트 에서 바로 받을 수 있다.

마치며

솔직히 이번 26.4.1은 드라마틱한 새 기능 같은 건 없다. M5 맥북 유저가 겪던 Wi-Fi 문제를 잡아줬다는 것, 그게 핵심이다. 포인트 업데이트답게 조용하게 버그 하나 잡고 나간 느낌.

그래도 이런 소소한 안정성 업데이트가 쌓여야 OS가 믿음직해지는 거니까. macOS Tahoe, 처음 나왔을 때 좀 불안정하다 싶었는데 점점 나아지고 있는 것 같아서 다행이다.

참고 출처

#macOS #macOS26 #macOSTahoe #맥업데이트 #M5맥북 #맥북에어 #맥북프로 #애플 #apple #Wi-Fi버그수정 #macOS26_4_1 #소프트웨어업데이트 #맥꿀팁 #IT #테크

Kafka vs RabbitMQ 차이점 완벽 정리 – 현업에서 어떤 걸 써야 할까

worniworni — Fri, 10 Apr 2026 23:54:14 +0900

메시지 큐, 고르라니까 뭘 골라야 해

얼마 전 팀 내 아키텍처 논의를 하다가 살짝 당황한 적이 있다.

새로 구축하는 서비스에서 이벤트 기반으로 서비스 간 통신을 해야 하는데, 어떤 메시지 큐를 도입할지 이야기가 나온 것이다. 누구는 Kafka를 써야 한다고 하고, 누구는 RabbitMQ면 충분하다고 한다. 근데 막상 "왜?"를 물어보면 대부분 "그냥... Kafka가 좋다고 들어서"라든지, "RabbitMQ가 더 간단하다던데" 수준의 대답이 돌아왔다.

나도 크게 다르지 않았다. 둘 다 써봤는데 정작 차이를 명확히 설명하라고 하면 말문이 막혔다. 그래서 이번 기회에 제대로 정리해봤다.

그 전에, 왜 메시지 큐가 필요한 거야?

Kafka든 RabbitMQ든 왜 쓰는지 먼저 알아야 한다.

가장 단순한 서비스 간 통신은 직접 HTTP 요청이다. 주문 서비스가 재고 서비스에 HTTP로 물어보고, 응답 받고, 다음 로직을 실행하는 방식. 근데 이게 문제가 생기는 건 재고 서비스가 느리거나, 아예 다운되거나, 갑자기 트래픽이 폭증했을 때다.

주문 서비스 입장에서는 재고 서비스가 응답할 때까지 계속 기다리거나, 타임아웃이 나거나, 요청 자체를 버려야 하는 상황이 된다. 플래시 세일 같은 이벤트 때 갑자기 주문이 수만 건씩 들어온다고 생각해보자. 재고 서비스가 버텨줄 수 있을까?

메시지 큐는 이 문제를 해결한다. 주문 서비스는 재고 서비스에 직접 요청하는 대신, 메시지를 큐에 던져놓고 바로 응답한다. 재고 서비스는 자기가 처리할 수 있는 속도로 큐에서 메시지를 가져다 처리한다. 폭증하는 트래픽은 큐가 흡수한다. 서비스 간 결합도가 낮아지고, 각자의 페이스로 처리가 가능해진다.

Kafka와 RabbitMQ는 이 역할을 하는 도구들이다. 그런데 내부 동작 방식이 근본적으로 다르다.

RabbitMQ: 스마트한 브로커, 단순한 컨슈머

RabbitMQ는 전통적인 메시지 브로커다. 개념적으로는 굉장히 직관적이다.

프로듀서가 메시지를 브로커에게 보내면, 브로커가 라우팅 룰에 따라 어느 큐로 보낼지 판단하고, 컨슈머가 그 큐에서 메시지를 가져다 처리한다. 컨슈머가 처리 완료 신호(ack)를 보내면 RabbitMQ는 그 메시지를 삭제한다.

브로커가 굉장히 많은 일을 한다. 메시지 라우팅, 어떤 메시지가 전달됐는지 추적, 실패 시 재시도, 처리 실패가 반복되면 자동으로 Dead Letter Queue로 이동. 컨슈머 입장에서는 그냥 큐에 연결해서 메시지 받아 처리하고 ack만 보내면 끝이다.

이걸 한 문장으로 표현하면 "스마트한 브로커, 단순한 컨슈머".

이 모델이 잘 맞는 케이스는 태스크 기반 워크로드다. 이메일 발송, 결제 처리, 이미지 리사이징. 할 일이 생기면 큐에 넣고, 누군가 꺼내서 처리하고, 처리 완료되면 사라지는 패턴.

인스타그램이 사진 업로드 후 리사이징/필터 처리에 RabbitMQ를 쓴다고 알려져 있고, 레딧도 댓글 트리 구성이나 카르마 계산 같은 백그라운드 작업에 쓰고 있다고 한다.

Kafka: 단순한 브로커, 스마트한 컨슈머

Kafka는 완전히 다른 패러다임이다.

Kafka는 메시지 브로커가 아니라 분산 로그(Distributed Append-Only Log) 에 가깝다. 프로듀서가 메시지를 보내면 Kafka는 토픽에 그냥 추가한다. 그리고 메시지는 컨슈머가 읽어도 사라지지 않는다. 설정한 보존 기간(시간, 용량)이 지날 때까지 그냥 로그에 남아있다.

컨슈머는 로그에서 어디까지 읽었는지 본인이 직접 기억한다. 이걸 오프셋(Offset) 이라고 한다. 500번째 메시지까지 읽었으면, 컨슈머가 "나 지금 500번"이라는 걸 기록해두는 것이다. 컨슈머가 죽었다가 살아나도 오프셋을 보고 501번부터 다시 읽는다. 1시간 전 메시지를 다시 읽고 싶으면? 오프셋을 뒤로 되감으면 된다.

이걸 한 문장으로 표현하면 "단순한 브로커, 스마트한 컨슈머".

이 모델의 핵심 강점은 두 가지다.

여러 컨슈머 그룹이 같은 스트림을 독립적으로 읽을 수 있다. 분석팀이 이벤트를 읽는 동시에, 알림 시스템도 같은 이벤트를 읽고, 6개월 뒤에 새로 만든 서비스도 처음부터 다 읽어서 백필(backfill) 할 수 있다.
메시지가 영속성(durability)을 가진다. 모든 이벤트의 히스토리가 보존된다.

RabbitMQ는 메시지가 흘러 지나가는 파이프고, Kafka는 메시지가 쌓이는 로그다. 이 차이가 모든 것을 결정한다.

기술적 차이 비교

순서 보장

RabbitMQ는 단일 컨슈머 기준으로는 메시지 순서가 완벽하게 보장된다. 근데 컨슈머 여러 개가 붙으면 병렬 처리되면서 순서가 뒤섞일 수 있다. 처리량 vs 순서, 트레이드오프다.

Kafka는 토픽을 파티션으로 나눈다. 순서는 파티션 내에서만 보장된다. 파티션 키를 이용해서 특정 사용자의 이벤트는 항상 같은 파티션으로 몰 수 있다. 예를 들면 고객 A의 모든 주문은 파티션 1에, 고객 B는 파티션 2에. 각 고객 내에서는 순서가 보장되고, 파티션 간 병렬 처리도 가능하다.

전체 글로벌 순서가 필요하면 RabbitMQ, 엔티티 단위 순서 + 병렬 처리가 필요하면 Kafka.

처리량과 레이턴시

	RabbitMQ	Kafka
처리량	초당 4,000 ~ 10,000 건	초당 100만 건 이상
레이턴시	1 ~ 5ms	5 ~ 50ms

RabbitMQ는 레이턴시가 낮다. 브로커가 메시지를 컨슈머에게 푸시하는 방식이라 빠르게 전달된다. 근데 메시지마다 라우팅, 전달 추적, ack 관리 등 브로커가 하는 일이 많아서 처리량이 올라갈수록 부담이 커진다.

Kafka는 기본 레이턴시는 더 높다. 컨슈머가 배치로 풀링하는 방식이기 때문이다. 대신 브로커가 하는 일이 단순하다. 그냥 로그에 추가하고, 컨슈머가 알아서 읽어가게 두면 된다. 그래서 부하가 엄청나게 올라가도 레이턴시가 비교적 일정하게 유지된다. 100배 이상의 처리량 차이가 나는 이유다.

메시지 전달 보장

At-most-once: 한 번만 전송, 실패해도 재시도 없음. 빠르지만 유실 가능.
At-least-once: 실패하면 재시도. 유실 없지만 중복 가능.
Exactly-once: 정확히 한 번만. 이상적이지만 복잡함.

RabbitMQ와 Kafka 모두 at-least-once를 지원한다. 대부분의 현업 애플리케이션에서 필요한 건 이거다.

Kafka는 exactly-once도 지원한다. 근데 여기서 함정이 있다. Kafka의 exactly-once는 같은 Kafka 클러스터 내에서 Kafka 토픽끼리만 동작한다. 데이터베이스에 쓰거나, 외부 API를 호출하거나, 클러스터가 달라지면 at-least-once로 돌아간다. 실제 비즈니스 로직에서 정확히 한 번 보장이 필요한 케이스라면, 어차피 컨슈머를 멱등성(idempotent)하게 만들어야 한다. "Kafka는 exactly-once 된다더라"고 선택했다가 낭패 보는 경우가 있으니 주의할 것.

운영 복잡도

RabbitMQ는 단일 바이너리에 관리 UI도 내장돼 있다. 클러스터링도 비교적 단순하고 러닝 커브가 낮다. 소규모 팀이 몇 개 큐만 운영할 때는 정말 접근하기 쉽다.

Kafka는 역사적으로 ZooKeeper가 필요했는데, 최근 버전(KRaft 모드)에서는 ZooKeeper 의존성이 제거됐다. 그렇다해도 파티션 리밸런싱, 브로커 장애 처리, 토픽 설정, 컨슈머 그룹 조율 등 신경 써야 할 게 훨씬 많다.

다만 Confluent Cloud, Amazon MSK, Azure Event Hubs 같은 매니지드 서비스를 쓰면 이 운영 부담을 상당 부분 덜 수 있다. Kafka를 도입할 생각이라면, 전담 인프라 팀이 없다면 매니지드 서비스를 강력하게 권장한다.

그래서 뭘 써야 하나

핵심을 한 줄로 요약하면 이렇다.

RabbitMQ = 일 처리 큐. Kafka = 이벤트 로그.

RabbitMQ를 선택할 때:

이메일 발송, 결제 처리, 이미지 변환 같은 태스크 처리가 목적일 때
특정 라우팅 규칙에 따라 적절한 워커에게 작업을 분배해야 할 때
대용량이 아니라 적당한 규모에서 낮은 레이턴시가 중요할 때
인프라 단순함이 중요하고 팀이 크지 않을 때

Kafka를 선택할 때:

여러 시스템이 같은 이벤트 스트림을 독립적으로 읽어야 할 때 (분석, 알림, 감사 로그 등)
과거 데이터를 재처리(replay) 해야 할 일이 있을 때
초당 수십만~수백만 건의 대용량 처리가 필요할 때
모든 이벤트의 영속적인 히스토리가 필요할 때

Netflix는 추천 시스템과 빌링에 Kafka로 하루에 페타바이트 규모 데이터를 처리하고, Uber는 실시간 가격 책정과 사기 탐지에 Kafka를 쓴다. LinkedIn은 Kafka를 직접 만든 회사고 지금도 피드와 메시징에 쓰고 있다.

둘 다 같이 쓰는 경우도 있다

사실 현실에서 규모가 어느 정도 커지면 두 가지를 병용하는 아키텍처도 자주 보인다.

Kafka를 이벤트 백본으로 쓰고, 그 이벤트가 트리거하는 실제 태스크 처리는 RabbitMQ로 하는 방식이다. 예를 들면:

주문 이벤트는 Kafka로 전사 시스템에 스트리밍
그 이벤트를 받아서 이메일 발송, 재고 차감 같은 작업은 RabbitMQ 워커가 처리

Kafka가 이벤트의 출처이자 히스토리고, RabbitMQ는 그 이벤트로 인해 발생하는 실제 작업을 처리하는 구조다.

마무리

처음에 팀 회의에서 뭘 써야 할지 몰라 당황했던 건, 사실 두 도구의 철학적 차이를 제대로 이해하지 못했기 때문이었다.

RabbitMQ는 메시지가 흘러가는 파이프고, Kafka는 메시지가 쌓이는 로그다.

이 문장 하나를 이해하면, 나머지 기술적 차이들(처리량, 순서 보장, 전달 보장, 운영 복잡도)이 모두 자연스럽게 따라온다. 도입할 때 "Kafka가 좋다더라", "RabbitMQ가 유명하더라"가 아니라, 내 서비스가 태스크 처리가 필요한지 이벤트 스트리밍이 필요한지를 먼저 명확히 하는 게 선택의 출발점이다.

참고 자료

#Kafka #RabbitMQ #메시지큐 #MessageQueue #분산시스템 #백엔드 #아키텍처 #개발자 #시스템설계 #이벤트드리븐 #EventDriven #KafkavsRabbitMQ

AI가 27년 된 버그를 찾아냈다 — 개발자로서 이 영상이 불편했던 이유

worniworni — Fri, 10 Apr 2026 23:38:09 +0900

개발 일을 하다 보면 보안에 대한 감각이 점점 무뎌지는 것 같다. 매일 기능 개발하고, PR 리뷰하고, 배포하고. 보안은 어딘가 다른 팀이 알아서 해주는 것, 아니면 가끔 터지면 그때 고치면 된다는 식으로 생각하게 된다. 사실 솔직하게 말하면 그렇다.

그런데 얼마 전 Anthropic에서 올린 영상 하나를 보고 좀 생각이 달라졌다.

Project Glasswing이라는 이름의 이 프로젝트, 처음엔 그냥 또 AI 마케팅 영상이겠지 싶었는데... 끝까지 보고 나서 한동안 멍하니 있었다.

https://www.youtube.com/watch?v=INGOC6-LLv0

"내 평생 찾은 것보다 몇 주 만에 더 많이 찾았다"

영상에서 한 보안 연구자가 이런 말을 한다.

"I found more bugs in the last couple of weeks than I found in the rest of my life combined."

처음엔 과장이겠지 했다. 근데 이어지는 내용이 장난이 아니었다.

OpenBSD에서 27년간 아무도 못 찾은 버그를 발견했다고 한다. 27년이다. 이 코드가 전 세계 수많은 서버에서 그 오랜 시간동안 돌아갔을 텐데, 그걸 AI 모델이 찾아냈다. 취약점의 내용도 간단하지 않았다 — 특정 데이터 몇 조각만 보내면 OpenBSD 서버를 그냥 크래시시킬 수 있다는 거다.

Linux에서는 또 다른 사례가 나왔다. 권한이 전혀 없는 일반 사용자가 그냥 바이너리 하나를 실행하는 것만으로 관리자 권한으로 올라갈 수 있는 취약점. 현업에 있으면 이게 얼마나 무서운 건지 감이 올 거다.

Claude Mythos Preview, 이게 뭔데

Anthropic이 새로 만든 모델 이름이 Claude Mythos Preview다. 이걸 보안에 특화되게 따로 훈련시킨 게 아니라는 게 흥미롭다. 코드를 잘 다루도록 훈련했더니, 보안도 자연스럽게 잘 하게 됐다는 거다.

여기서 나온 말이 인상 깊었다.

"We haven't trained it specifically to be good at cyber. We trained it to be good at code, but as a side effect of being good at code, it's also good at cyber."

생각해보면 당연한 말이다. 코드를 깊이 이해한다는 건 그 코드의 흐름, 엣지 케이스, 의도하지 않은 동작까지 파악한다는 뜻이니까. 보안 취약점은 결국 개발자가 의도하지 않은 코드의 동작에서 나오는 거고.

이 모델이 특히 강력한 이유가 또 있었다. 단일 취약점 하나가 아니라, 여러 취약점을 연결해서 복잡한 익스플로잇 체인을 만들 수 있다는 거다. 취약점 A 하나로는 별거 아닌데, B랑 C를 같이 엮으면 시스템 전체를 뚫을 수 있는 그런 식으로.

인간 보안 연구자가 하루 종일 작업하는 긴 호흡의 태스크를 이 모델이 자율적으로 수행할 수 있다고 했다. 솔직히 이건 좀 무섭다.

Project Glasswing이 하려는 것

그래서 Anthropic이 내놓은 대응이 Project Glasswing이다.

요약하면 이렇다. 이 강력한 모델을 아무한테나 풀지 않고, 세계 주요 소프트웨어를 관리하는 조직들에게 먼저 제공한다. 그들이 먼저 자기 코드의 취약점을 찾고 패치할 수 있도록 선제적으로 "헤드스타트"를 주는 거다.

오픈소스 운영체제, 금융 인프라, 핵심 네트워크 시스템들. 이런 것들에서 취약점을 먼저 찾아서 고치고, 그 뒤에야 악의적인 행위자들이 같은 능력을 갖게 되는 상황을 막겠다는 전략이다.

미국 정부 관계자들과도 협력 중이라고 했다. 사이버보안이 이제는 그냥 IT 문제가 아니라 국가 안보 문제라는 인식이 녹아 있는 것 같았다.

개발자로서 느낀 불편함

영상 보면서 솔직히 좀 불편했다.

좋은 방향으로 쓰이면 당연히 좋다. 먼저 방어에 쓰인다는 것도 이해한다. 근데 이 기술이 결국 어떤 형태로든 퍼져나갈 거라는 걸 알기 때문이다.

영상에서도 이 부분을 솔직하게 얘기한다. LLM이 코드를 최고 수준의 개발자만큼 짤 수 있다면, 버그를 찾고 익스플로잇 하는 것도 동등하게 잘 할 수 있다고. 이게 공격자 손에 들어가면 어떻게 될지 분명히 알면서도 만들어야 하는 딜레마.

현실적으로 더 강력한 모델은 계속 나올 거다. Anthropic만 만드는 게 아니니까. 그래서 "우리가 먼저 방어쪽에서 써야 한다"는 논리는 이해는 한다. 그게 현실적인 선택이라는 것도. 그냥 한편으로는 씁쓸하다.

소프트웨어 보안은 결국 우리 삶의 보안이다

영상에서 가장 와닿은 말이 있다.

"Software ate the world. Every analog aspect of our life is somehow represented in the digital domain. Cybersecurity is the security of our society."

맞는 말이다. 병원 시스템, 금융 시스템, 교통 시스템, 전력망. 지금 우리 삶에서 소프트웨어가 안 들어간 곳이 없다. 개발자로 일하다 보면 이게 일이니까 감각이 무뎌지는데, 가끔 이런 영상 보면서 "아, 내가 짜는 코드가 어딘가에서 진짜로 돌아가고 있구나" 싶어진다.

OpenBSD에 있던 그 27년 된 버그. 그 버그가 있는 줄도 모르고 수십 년 동안 그 시스템을 믿고 썼을 수많은 사람들. 그게 고쳐졌다는 건 좋은 일이지만, 그 전에 누군가 악의적으로 알고 썼을 수도 있다는 생각을 하면 좀 소름 돋는다.

그래서 개발자로서 뭘 생각해야 할까

아직 잘 모르겠다. 솔직히.

근데 한 가지는 확실하다. "보안은 보안팀이 알아서" 라는 마인드로는 이제 안 된다는 것. AI가 코드를 읽는 속도와 패턴을 연결하는 능력은 인간 리뷰어를 이미 넘어서고 있다. 우리가 짜는 코드 한 줄 한 줄이 언젠가 이런 모델의 분석 대상이 될 수 있다.

방어 쪽에서도 이 기술을 적극적으로 써야 하는 시대가 온 것 같다. 실제로 Glasswing에 참여한 연구자들이 몇 주 만에 그렇게 많은 버그를 찾았다는 건, 기존 방식이 얼마나 비효율적이었는지를 역으로 보여주는 거기도 하니까.

개발자로서 이런 변화 앞에서 어떻게 대응해야 하는지, 아직 답은 없지만. 적어도 이 영상 보고 나서는 내가 짜는 코드에 대해 좀 더 진지하게 생각하게 된 것 같다.

원본 영상: An initiative to secure the world's software | Project Glasswing
채널: Anthropic

#AI보안 #Anthropic #ProjectGlasswing #소프트웨어보안 #사이버보안 #취약점 #버그 #ClaudeAI #개발자 #보안취약점 #오픈소스 #OpenBSD #Linux #AIcybersecurity #인공지능보안

새 컴퓨터가 예전 컴퓨터보다 느린 진짜 이유 – 전직 MS 엔지니어의 쓴소리

worniworni — Wed, 8 Apr 2026 23:23:20 +0900

참고 영상: Why your NEW computer is SLOWER than your OLD computer! By a Retired Microsoft Engineer. — Dave's Garage

요즘 유튜브 알고리즘이 나한테 꽤 잘 맞는 영상을 자꾸 추천해준다. 그 중에서 이번에 Dave's Garage 채널 영상이 딱 걸렸는데, 보자마자 "아 이거다" 싶었다.

영상 주인공인 Dave는 전직 마이크로소프트 엔지니어다. 윈도우즈 Task Manager를 직접 만든 사람이라고 하니까, 그냥 이론가가 아니라 실제로 저사양 환경에서 코드를 쥐어짠 사람인 거다. 그 사람이 말한다. "왜 당신의 새 컴퓨터는 구형 컴퓨터보다 느린가"라고.

처음엔 낚시성 제목인가 싶었는데, 듣다보니까 꽤 뼈를 때리는 내용이 많아서 생각을 좀 정리해보고 싶었다.

https://www.youtube.com/watch?v=t992ul_IKtc

오해하지 말 것 – 옛날이 좋았다는 얘기가 아니다

Dave도 영상 초반에 분명히 선을 긋는다. 옛날 소프트웨어가 좋았다는 향수팔이 하려는 게 아니라고. 맞다. 옛날 드라이버는 수시로 터졌고, 인스톨러는 악몽이었고, 사운드카드 설정 한 번 잘못 건드리면 하루가 날아갔다. 나도 윈도우즈 98 쓰던 시절 기억이 어렴풋이 있는데, 솔직히 다시 돌아가고 싶진 않다.

근데 그 시절 소프트웨어가 딱 한 가지는 제대로 했다고 그는 말한다.

기계를 존중했다는 것.

메모리는 빠듯했고 CPU는 처참하게 느렸으니까, 코드 한 줄 한 줄에 무게가 있었다. 기능을 추가하고 싶으면 메모리 예산을 깎아야 했다. 디스크 사용량도 예산이 있었다. CPU 사용량도. 예산을 초과하면 기능이 빠졌다. 지금처럼 "일단 넣고 보자"가 통하지 않았다.

빌 게이츠랑 폴 앨런 얘기도 나오는데, 이 두 사람이 BASIC 인터프리터를 8KB에 욱여넣은 게 유명하다. 왜 8KB냐고? 12KB가 없었으니까. 진짜로 그게 전부다. 제약이 있으니까 창의성이 나왔다는 거다.

현대 소프트웨어는 왜 이렇게 무거워졌나

이게 사실 개발자로 일하면서 몸으로 느끼는 부분이다. 나도 가끔 PR 리뷰할 때 "이게 왜 이 라이브러리를 쓰지?" 싶을 때가 있다. 근데 묻기 귀찮으니까 그냥 넘어간다. 다들 그렇게 한다.

Dave가 지적하는 원인들을 정리해보면 크게 세 가지다.

1. 비용을 모르는 추상화

추상화 자체는 나쁜 게 아니다. 그 덕분에 우리가 매번 메모리 관리 코드를 직접 짜지 않아도 되고, 소수 팀이 대규모 서비스를 만들 수 있다. 근데 문제는 추상화가 공짜가 아니라는 걸 아무도 신경 쓰지 않는다는 거다.

그 비용이 어디로 가냐. CPU로, 메모리로, 배터리로, 네트워크로 간다. 그러니까 결국 사용자한테 간다.

간단한 유틸리티 앱 하나 실행하면 지금 뒤에서 뭐가 돌아가는지 알아? 자동 업데이터, 텔레메트리 파이프라인, 웹 렌더링 엔진, JS 런타임, 패키지 에코시스템, 샌드박스 레이어, GPU 컴포지터, 알림 브로커... 거기다 2021년에 드롭다운 메뉴 하나 예쁘게 만들려고 가져온 프레임워크가 또 다른 프레임워크 6개를 끌고 오고.

그 결과가 텍스트 필드 세 개짜리 버튼 앱이 RAM 800MB를 먹는 현실이다. Electron 기반 앱들 보면 딱 이 느낌이다. Slack, Discord, VS Code... 솔직히 VS Code는 쓸 만하지만 Slack이 저 정도 리소스를 먹을 이유가 있나 싶긴 하다.

2. 성과를 잘못 측정하는 조직

이건 개발자 개인 문제가 아니라 조직 문제다.

"기능 추가하면 박수 받는다. 시작 시간 반 줄여도 박수 못 받는다."

정말 공감 가는 말이다. 지금 대부분의 팀에서 성능 개선 작업은 스토리 포인트도 잘 안 쌓이고, 임팩트 측정도 애매하고, 리더십에 보고하기도 어렵다. 반면에 새 기능은 티가 난다. 릴리즈 노트에 쓸 수 있고, 데모할 수 있고, 사용자한테 보여줄 수 있다.

그러니까 결과적으로 팀은 기능을 만들고, 성능은 나중으로 밀린다. 근데 나중은 안 온다.

거기다 대형 조직에서는 성능 책임이 분산된다. UI 팀, 백엔드 팀, 프레임워크 팀, 실험 프레임워크 팀 각자가 조금씩 느리게 만들면, 아무도 책임지지 않지만 사용자는 그 합산을 고스란히 느낀다.

3. 의존성 폭발

요즘 소프트웨어는 "만든다"기보다 "조립한다"는 표현이 더 맞는 것 같다. 날짜 선택기 하나, 마크다운 파서 하나, 로깅 프레임워크 하나... 실행 전에 이미 npm install로 수십 MB를 받는다.

물론 바퀴 재발명이 미덕은 아니다. 근데 예전에는 라이브러리를 가져올 때 그게 가져올 만한 이유가 있는지 따졌다. 지금은 반대다. 일단 가져오고 나중에 생각한다. 그러면 기능만 가져오는 게 아니라 시작 비용, 메모리, 보안 노출, 업데이트 노이즈, 호환성 문제, 그리고 내가 절대 다 파악 못 할 중첩 의존성 트리가 같이 따라온다.

AI가 기름을 붓는다

이 부분에서 좀 뜨끔했다.

Dave는 AI 자체를 반대하는 건 아니라고 한다. 스캐폴딩, 보일러플레이트, 테스트 생성, 낯선 API 파악... 이런 데서는 진짜 유용하다고 인정한다. 나도 매일 쓰니까 그건 동의한다.

근데 그가 지적하는 건 이거다. AI는 학습 데이터의 중간값 패턴을 반영한다. 중간값 코드는 성능을 치열하게 고민한 코드가 아니다. 그냥 "작동하는" 코드다. 너무 추상적이고, 너무 방어적이고, 레이어가 많고, 알아보기는 쉬운데 최선은 아닌 코드.

Dave가 직접 경험한 얘기도 나온다. 아케이드 게임 Robotron을 AI로 푸는 프로젝트를 하면서, UI에 영상 미리보기를 달았는데 AI가 짠 코드가 느린 거다. 들여다보니까 영상 데이터를 Base64 인코딩한 JSON으로 소켓에 쏘고 있더란다. 상상할 수 있는 가장 비효율적인 방식으로.

"AI가 끔찍한 루틴 하나를 쓰는 게 위험한 게 아니다. 각자는 합리적으로 보이지만, 합쳐보면 메모리 잡아먹고 배터리 태우고 느린 제품을 만드는 수천 개의 조각들을 AI가 만드는 게 위험하다."

나도 AI 코드 리뷰할 때 이런 거 느낀다. 각 함수는 멀쩡한데 전체 흐름을 보면 불필요한 데이터 복사가 있거나, 루프 안에서 할당이 반복되거나. 코드는 동작하고 테스트도 통과하는데, 뭔가 무거운 느낌. 근데 그걸 딱 꼬집어 지적하기가 애매해서 그냥 머지되는 경우가 있다.

그래서 어떻게 해야 한다는 건가

Dave의 해법은 크게 두 가지다.

첫째, 성능을 빌드 아티팩트로 만들어라.

단위 테스트가 실패하면 빌드가 터지듯이, 시작 시간이 18% 늘어나도 빌드가 터져야 한다. 아이들 메모리가 300MB 늘어나도 마찬가지. 성능 지표가 매 빌드마다 추적되고, 히스토리로 보이고, 게이팅되어야 한다.

둘째, 예산을 명시적으로 정해라.

"이 기능은 콜드 스타트에 X 밀리초 이상 추가하면 안 된다." "이 백그라운드 서비스는 분당 Y회 이상 CPU를 깨우면 안 된다." 막연한 목표가 아니라 실제 예산. 예산이 있어야 트레이드오프를 의식적으로 결정하게 된다.

이게 비낭만적으로 들릴 수 있는데, 사실 예전 좋은 소프트웨어들이 바로 이렇게 만들어졌다는 거다.

개인적으로 느끼는 것

나는 지금 맥북을 쓰는데, 하드웨어는 분명 예전보다 훨씬 빠르다. 근데 Slack 열 때 가끔 버벅이고, 브라우저 탭 30개 넘으면 슬슬 팬이 돌기 시작한다. Chrome 혼자 RAM을 몇 GB씩 먹는 건 이제 당연한 일처럼 됐다.

개발자로서 보면 더 눈에 잘 보인다. 우리 팀 프로젝트도 처음엔 빠릿했는데, 기능이 붙을수록 시작 시간이 늘어났다. 어느 순간부터 로컬 개발 서버 뜨는데 10초 넘게 걸리기 시작했고, 아무도 이걸 이슈로 안 올렸다. 그냥 다들 기다렸다.

Dave의 말 중에 제일 인상 깊은 대목이 있다.

"오래된 소프트웨어가 잘 한 것이 있다면, 현실이 취향을 강요했다는 거다. 지금 우리는 그 취향을 스스로에게 강요해야 한다."

제약이 없으니까 규율도 없어졌다. 그 결과가 지금의 무거운 소프트웨어 생태계다.

물론 나도 빠른 배포를 위해 라이브러리 가져다 쓰고, AI 코드 어느 정도 검토하고 머지하고, 성능보다 기능 먼저 챙기는 경우가 있다. 솔직히 다 해봤다. 근데 이 영상 보고 나서 적어도 "내가 지금 어디서 타협하고 있구나"는 인식하게 됐다.

인식이 시작이니까.

#새컴퓨터느린이유 #소프트웨어블로트 #개발자일상 #성능최적화 #마이크로소프트 #프로그래밍 #소프트웨어개발 #기술블로그 #DavesGarage #AI코딩 #개발자생각 #앱최적화 #전직MS엔지니어 #테크유튜브

DNS 레코드 종류 완벽 정리 – A레코드, CNAME, TXT, MX 뭐가 다른 거야?

worniworni — Tue, 7 Apr 2026 23:39:25 +0900

도메인 산 김에 뭔가 설정하려고 들어갔다가 멍때린 적이 한두 번이 아니다.

AWS Route 53이든, 가비아든, 클라우드플레어든... DNS 설정 화면 들어가면 항상 저 알 수 없는 것들이 날 반긴다.

A 레코드, CNAME, TXT, MX, NS, AAAA...

처음엔 대충 "A는 IP 연결하는 거, CNAME은 도메인 연결하는 거겠지~" 하고 감으로 때웠는데, 막상 실무에서 Vercel에 도메인 붙이거나 Google Search Console 인증할 때 헷갈리는 게 한두 개가 아니었다. 그래서 이번 기회에 제대로 정리해봤다.

일단 DNS가 뭔지부터

DNS는 Domain Name System의 약자다. 쉽게 말하면 인터넷 전화번호부 같은 거다.

우리가 google.com을 브라우저에 치면 컴퓨터는 이게 어느 서버 IP인지 모른다. DNS가 그걸 142.250.xxx.xxx 같은 실제 IP로 변환해주는 역할을 한다. 도메인 이름을 사람이 읽기 편하게 쓰고, 실제 통신은 IP로 하는 구조.

그리고 이 DNS 시스템 안에서 "어떤 도메인이 어디로 연결되는지", "이 도메인의 메일 서버는 어디인지" 같은 정보를 담고 있는 게 바로 DNS 레코드다.

A 레코드 (Address Record)

가장 기본이 되는 레코드다. 도메인 → IPv4 주소로 연결해준다.

example.com  →  192.168.0.1

예를 들어 EC2 인스턴스에 직접 도메인 붙이고 싶으면 A 레코드에 그 EC2의 퍼블릭 IP를 넣으면 된다. 단순명쾌하다.

타입: A
이름: @  (또는 example.com)
값: 13.124.xx.xx
TTL: 3600

@는 보통 루트 도메인을 뜻한다. www면 www.example.com을 가리키는 거고.

근데 IP가 바뀌면 A 레코드도 직접 바꿔줘야 한다. 고정 IP가 아닌 경우엔 관리가 좀 번거롭다.

AAAA 레코드

A 레코드랑 동일한데 IPv6 주소를 쓸 때다. 요즘 IPv6 쓰는 인프라들 많아져서 알아두면 좋다.

example.com  →  2001:0db8:85a3::8a2e:0370:7334

사실 일반적인 설정에선 잘 안 만질 수도 있는데, CDN이나 클라우드 서비스에서 자동으로 추가해주는 경우가 많다.

CNAME 레코드 (Canonical Name Record)

이게 좀 헷갈리는데, 도메인 → 다른 도메인으로 연결해주는 레코드다. IP가 아니라 도메인 이름을 값으로 넣는다.

www.example.com  →  example.com
blog.example.com  →  myapp.vercel.app

실무에서 진짜 많이 쓰는 케이스:

Vercel, Netlify, GitHub Pages에 서브도메인 연결할 때
CloudFront 배포에 도메인 붙일 때

예를 들어 Vercel에 커스텀 도메인 붙이면 CNAME을 cname.vercel-dns.com 같은 데로 연결하라고 안내해준다. 이러면 Vercel이 IP를 어떻게 바꾸든 간에 CNAME만 살아있으면 자동으로 추적되는 거다.

A 레코드와 CNAME의 차이를 한줄로:

A 레코드 = 도메인 → IP (최종 목적지)
CNAME = 도메인 → 도메인 (다른 도메인으로 위임)

주의할 점이 있는데, CNAME은 루트 도메인(@, example.com)에는 쓸 수 없다. DNS 표준상 루트 도메인에 CNAME이 있으면 MX나 NS 같은 다른 레코드랑 충돌이 생기기 때문이다. 그래서 Cloudflare 같은 곳에서는 CNAME Flattening이라는 기능으로 이걸 우회해준다.

TXT 레코드 (Text Record)

이름처럼 텍스트 정보를 담는 레코드다. 사람이 읽을 수 없는 복잡한 문자열이 들어가는 경우가 많아서 처음 보면 이게 뭔가 싶다.

주로 쓰이는 용도가 세 가지다.

1. 도메인 소유권 인증

Google Search Console이나 네이버 웹마스터 도구에 도메인 등록할 때 이런 거 추가하라고 한다:

타입: TXT
이름: @
값: google-site-verification=aBcDeFgHiJkL...

이걸 DNS에 추가해두면 구글이 "아 이 사람이 이 도메인 주인이구나" 하고 확인하는 방식이다. DNS는 도메인 주인만 수정할 수 있으니까 이게 곧 소유권 증명이 된다.

2. SPF (Sender Policy Framework)

이메일 발송 관련 설정이다. 내 도메인에서 메일을 보낼 수 있는 서버를 명시해두는 거다.

v=spf1 include:_spf.google.com ~all

이게 없거나 잘못 설정되면 내 도메인에서 보내는 메일이 스팸으로 분류될 수 있다. 메일 서비스 도입할 때 꼭 확인해야 한다.

3. DKIM (DomainKeys Identified Mail)

이것도 이메일 인증인데, 메일 내용이 변조되지 않았다는 걸 검증하기 위한 공개키를 TXT 레코드에 넣어두는 거다. AWS SES나 SendGrid 같은 서비스 쓸 때 추가하라고 안내해준다.

default._domainkey.example.com  →  v=DKIM1; k=rsa; p=MIGfMA0GCSqG...

MX 레코드 (Mail Exchanger Record)

메일 서버 주소를 지정하는 레코드다. @example.com 같은 이메일 주소로 메일 받으려면 MX 레코드가 있어야 한다.

타입: MX
이름: @
우선순위: 10
값: mail.example.com

우선순위(Priority) 숫자가 낮을수록 먼저 시도한다. 여러 개 설정해두면 하나가 죽어도 다음 서버로 받아줘서 안정성이 높아진다.

Google Workspace나 Naver Works 같은 기업 메일 서비스 연결할 때 이 MX 레코드를 수정하는 거다.

NS 레코드 (Name Server Record)

이 도메인의 DNS를 어느 네임서버가 관리하는지 지정하는 레코드다. 가비아에서 도메인 사고 클라우드플레어 DNS 쓰고 싶으면 NS 레코드를 클라우드플레어 네임서버 주소로 바꾸는 거다.

ns1.cloudflare.com
ns2.cloudflare.com

NS 레코드는 보통 도메인 등록기관 콘솔에서 건드리고, DNS 관리 자체는 NS 레코드가 가리키는 서버에서 한다. 계층 구조가 있는 셈이다.

TTL (Time To Live)

레코드 자체는 아닌데 설정할 때 항상 나오는 값이라 짚고 넘어간다. DNS 정보가 캐시에 얼마나 살아있을지를 초 단위로 지정한다.

TTL 3600 = 1시간
TTL 300 = 5분
TTL 86400 = 1일

IP 바꿀 일이 있거나 설정 테스트 중이면 TTL을 낮게 해두면 변경이 빨리 반영된다. 안정화된 이후엔 다시 높여두는 게 네임서버 부하 줄이는 데 좋다.

정리하면

레코드	역할
A	도메인 → IPv4
AAAA	도메인 → IPv6
CNAME	도메인 → 다른 도메인
TXT	텍스트 정보 (인증, 메일 정책)
MX	메일 서버 지정
NS	네임서버 지정

요즘은 Vercel이나 Netlify 같은 플랫폼들이 DNS 설정 가이드를 잘 만들어놔서 그냥 따라하면 되긴 한다. 그래도 저 값들이 왜 들어가는지 모르고 쓰면 뭔가 안 됐을 때 디버깅을 못 하더라.

이번에 개인 도메인에 이것저것 붙이다 보니까 그동안 아무 생각없이 넣던 값들이 이제야 좀 이해가 된다. 특히 TXT 레코드가 이렇게 다양하게 쓰이는 줄은 몰랐는데, 알고 보니 도메인 인증의 핵심이 다 여기 모여있었다.

서버 관련 작업 하는 개발자라면 이 정도는 머릿속에 넣어두면 나중에 분명히 써먹는다.

#DNS #DNS레코드 #A레코드 #CNAME #TXT레코드 #MX레코드 #도메인설정 #DNS설정 #웹개발 #서버설정 #개발자 #네임서버 #Vercel도메인연결 #클라우드플레어 #Route53

Objective-C란 무엇인가 – iOS 개발의 뿌리, 지금도 알아야 할까?

worniworni — Sun, 5 Apr 2026 15:46:16 +0900

요즘 iOS 개발한다고 하면 거의 다 Swift로 시작한다. 나도 마찬가지였다. 그런데 오래된 코드베이스를 건드리거나, 레거시 프로젝트에 투입되면 빠져나올 수 없는 언어가 하나 있다. 바로 Objective-C.

처음 봤을 때 솔직히 뭔가 싶었다. [object method] 이게 뭐지? 대괄호는 왜 저기 들어가는 거지? 근데 파고들다 보니까 이 언어가 그냥 나온 게 아니구나 하는 걸 느꼈다. 오늘은 Objective-C가 뭔지, 왜 만들어졌는지, 그리고 어떤 특징이 있는지 코드 예제와 함께 정리해보려 한다.

Objective-C가 뭔데?

한 줄로 정리하면, C 언어에 객체지향 기능을 얹은 언어다.

iOS와 macOS(예전 이름 OS X)의 앱을 개발하는 데 오랫동안 쓰였던 언어고, Swift가 나오기 전까지는 애플 생태계의 사실상 유일한 네이티브 개발 언어였다. 지금도 오래된 iOS 프로젝트들은 여전히 Objective-C로 짜여 있는 경우가 많다.

왜 만들어졌나 – 역사 이야기

Objective-C는 1980년대 초반에 Brad Cox와 Tom Love 두 사람이 만들었다.

당시 C 언어는 이미 강력하고 빠른 언어로 유명했다. 근데 문제가 있었다. C는 객체지향 언어가 아니었다. 그 시대에 객체지향이라는 개념이 막 떠오르고 있었는데, C만으로는 그게 안 됐던 거다.

그 무렵 Smalltalk라는 언어가 있었다. 완전한 객체지향 언어였고, 메시지 기반으로 객체 간 소통을 하는 독특한 구조를 가지고 있었다. 두 발명자는 여기서 아이디어를 얻었다.

"C의 성능 + Smalltalk의 객체지향 = Objective-C"

C를 베이스로 하되, Smalltalk의 OOP 개념을 전처리기(preprocessor) 형태로 위에 얹어버린 거다. 이렇게 하면 C의 빠른 실행 속도와 강력함은 그대로 가져가면서, 객체지향 프로그래밍까지 할 수 있게 된다. 꽤 영리한 접근이다.

이후 애플이 이 언어를 채택하면서 iOS와 macOS 개발의 표준 언어가 됐다.

클래스 기본 구조

일단 Objective-C 코드가 어떻게 생겼는지부터 보자. 다른 언어들과 가장 눈에 띄게 다른 점이 있다. 헤더 파일(.h)과 구현 파일(.m)을 분리한다는 거다.

// Person.h - 인터페이스 선언 (헤더 파일)
@interface Person : NSObject

@property (nonatomic, strong) NSString *name;
@property (nonatomic, assign) NSInteger age;

- (instancetype)initWithName:(NSString *)name age:(NSInteger)age;
- (void)introduce;

@end

// Person.m - 구현 파일
#import "Person.h"

@implementation Person

- (instancetype)initWithName:(NSString *)name age:(NSInteger)age {
    self = [super init];
    if (self) {
        _name = name;
        _age = age;
    }
    return self;
}

- (void)introduce {
    NSLog(@"안녕하세요, 저는 %@이고 %ld살입니다.", self.name, (long)self.age);
}

@end

// 사용하는 쪽
Person *person = [[Person alloc] initWithName:@"김철수" age:30];
[person introduce];
// 출력: 안녕하세요, 저는 김철수이고 30살입니다.

Swift를 먼저 배운 사람이라면 [[Person alloc] init] 이 이중 대괄호가 왜 있나 싶을 거다. alloc으로 메모리를 할당하고, init으로 초기화하는 두 단계를 명시적으로 거치는 거다. Swift에서는 이게 Person() 한 줄로 압축됐다.

Swift로 같은 코드를 쓰면:

// Swift 버전
class Person {
    var name: String
    var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }

    func introduce() {
        print("안녕하세요, 저는 \(name)이고 \(age)살입니다.")
    }
}

let person = Person(name: "김철수", age: 30)
person.introduce()

확실히 Swift가 훨씬 간결하다. 근데 Objective-C 쪽이 더 명시적이라는 느낌도 있다.

Objective-C의 핵심 특징들

1. 메시지 전송 (Messaging)

이게 Objective-C를 처음 볼 때 가장 낯선 부분이다. 다른 언어에서는 메서드를 이렇게 호출한다:

// Java
object.doSomething();
object.doSomethingWith(param);

Objective-C는 이렇게 생겼다:

// Objective-C
[object doSomething];
[object doSomethingWith:param];

파라미터가 여러 개일 때는 더 독특하다:

// Java
button.setTitle("확인", ButtonType.DEFAULT);

// Objective-C - 파라미터 이름이 메서드명 안에 들어간다
[button setTitle:@"확인" forState:UIControlStateNormal];

처음엔 이게 왜 이렇게 길어야 하나 싶었는데, 코드 읽을 때 파라미터가 뭘 의미하는지 바로 알 수 있다는 장점이 있긴 하다. forState:UIControlStateNormal 보면 "어떤 상태에 대한 타이틀인지" 가 명확하게 보이니까.

단순히 문법 차이가 아니다. 개념 자체가 다르다.

Java나 C++에서는 컴파일 타임에 어떤 메서드를 호출할지 결정된다. 근데 Objective-C는 런타임에 메시지를 객체에 전송하는 방식이다. 내부적으로는 objc_msgSend라는 C 함수가 호출되는데, 이 함수가 런타임에 실제로 어떤 메서드를 실행할지 찾아내는 거다.

// 사실 아래 두 줄은 동일하다
[person introduce];
objc_msgSend(person, @selector(introduce));  // 내부 동작 방식

2. 동적 타이핑 (Dynamic Typing)

여기서 더 재밌는 특징이 나온다.

Objective-C에는 id라는 특수한 타입이 있다. 어떤 객체든 담을 수 있는 타입이다.

// id 타입 - 어떤 객체도 담을 수 있다
id someObject = [[Person alloc] initWithName:@"김철수" age:30];
[someObject introduce];  // 런타임에 메서드를 찾아서 실행

someObject = @"이건 NSString이야";  // 완전히 다른 타입으로 바꿔도 된다
NSLog(@"%@", someObject);

Java 같은 언어에서는 존재하지 않는 메서드를 호출하면 컴파일 에러가 난다. 근데 Objective-C는 클래스 인터페이스에 정의되지 않은 메시지도 일단 보낼 수 있다. 만약 해당 메시지를 처리할 메서드가 없으면, 다른 객체로 포워딩할 수 있다.

// 메시지 포워딩 예시
@implementation MyClass

// 처리할 수 없는 메시지가 왔을 때 호출됨
- (void)forwardInvocation:(NSInvocation *)anInvocation {
    if ([anotherObject respondsToSelector:[anInvocation selector]]) {
        // 다른 객체에게 메시지를 넘긴다
        [anInvocation invokeWithTarget:anotherObject];
    } else {
        // 그것도 안 되면 기본 처리
        [super forwardInvocation:anInvocation];
    }
}

@end

이 유연함 덕분에 특정 디자인 패턴 구현이 굉장히 자유로워진다. 근데 그만큼 런타임 에러가 나기도 쉽다. 컴파일할 때는 멀쩡했는데 앱 켜니까 터지는 경우가 생기는 거다. 이게 Objective-C 디버깅이 까다로운 이유 중 하나다.

3. 카테고리 (Categories)

이건 개인적으로 꽤 신기하다고 느낀 기능이다.

카테고리는 기존 클래스에 메서드를 추가할 수 있는 구조다. 원본 클래스 코드를 건드리지 않아도 된다.

// NSString+Reverse.h
@interface NSString (Reverse)
- (NSString *)reversedString;
- (BOOL)isPalindrome;
@end

// NSString+Reverse.m
@implementation NSString (Reverse)

- (NSString *)reversedString {
    NSMutableString *reversed = [NSMutableString string];
    for (NSInteger i = self.length - 1; i >= 0; i--) {
        [reversed appendFormat:@"%C", [self characterAtIndex:i]];
    }
    return reversed;
}

- (BOOL)isPalindrome {
    return [self isEqualToString:[self reversedString]];
}

@end

// 사용할 때
NSString *word = @"level";
NSLog(@"%@", [word reversedString]);   // "level"
NSLog(@"%d", [word isPalindrome]);     // 1 (YES)

Apple이 만든 NSString에 내가 원하는 메서드를 추가한 거다. 원본 소스 코드 없이도. Swift의 extension이 딱 이 개념에서 온 거다.

// Swift의 extension - 카테고리와 동일한 개념
extension String {
    var reversed: String {
        return String(self.reversed())
    }
    var isPalindrome: Bool {
        return self == self.reversed
    }
}

레거시 코드베이스에서 카테고리는 꽤 유용하다. 이미 방대한 클래스에 기능을 덧붙일 때 원본을 고치지 않아도 되니까, 사이드 이펙트 걱정이 줄어든다.

Swift와의 관계 – 같은 프로젝트에서 섞어 쓰기

2014년 애플이 Swift를 발표하면서 많은 사람들이 "Objective-C 이제 죽은 거 아냐?"라고 했다. 근데 실제로 현업에서 보면 그렇게 단순하지 않다.

Swift와 Objective-C는 같은 프로젝트 안에서 함께 쓸 수 있다. 브릿징 헤더(Bridging Header)를 통해 서로 호출이 가능하다.

// Objective-C로 만든 레거시 클래스
// LegacyNetworkManager.h
@interface LegacyNetworkManager : NSObject
- (void)fetchDataFromURL:(NSString *)urlString
              completion:(void (^)(NSData *data, NSError *error))completion;
@end

// Swift에서 Objective-C 클래스 호출
// Bridging Header에 #import "LegacyNetworkManager.h" 추가하면 바로 쓸 수 있다
let manager = LegacyNetworkManager()
manager.fetchData(fromURL: "https://api.example.com") { data, error in
    // Swift 클로저로 받음
}

반대로 Objective-C에서 Swift 클래스를 쓸 수도 있다:

// Swift 클래스
@objc class NewFeatureManager: NSObject {
    @objc func processData(_ data: Data) -> String {
        return "처리 완료"
    }
}

// Objective-C에서 Swift 클래스 사용
// ProjectName-Swift.h 임포트하면 됨
#import "MyProject-Swift.h"

NewFeatureManager *manager = [[NewFeatureManager alloc] init];
NSString *result = [manager processData:someData];

수십만 줄짜리 Objective-C 코드베이스를 하루아침에 Swift로 바꾸는 건 현실적으로 불가능하다. 그래서 많은 회사들이 기존 Obj-C 코드는 그대로 두고 새 기능만 Swift로 추가하는 방식으로 가고 있다. 이 두 언어의 상호운용성이 생각보다 잘 돼있어서 그게 가능한 거다.

솔직한 후기

Objective-C 코드를 처음 읽었을 때 솔직히 불편했다. 문법이 직관적이지 않고, 대괄호 중첩이 심해지면 가독성이 확 떨어진다.

// 대괄호 중첩의 압박...
NSString *result = [[[[SomeManager sharedInstance] dataProcessor] 
                      processItems:[self currentItems]] 
                      stringValue];

현대 언어들과 비교하면 분명 불편한 점이 많다. 근데 그 불편함 뒤에 꽤 탄탄한 철학이 있다는 건 인정한다. C의 성능을 포기하지 않으면서 OOP를 구현했고, 런타임 메시지 패싱이라는 독특한 방식은 당시 기준으로 상당히 혁신적인 발상이었다. Smalltalk에서 영감을 받아 완전히 새로운 언어를 만들어낸 Brad Cox와 Tom Love는 대단한 사람들이었다고 생각한다.

지금 당장 새로 배울 언어냐고 묻는다면, 솔직히 Swift를 먼저 배우는 게 맞다. 근데 레거시 프로젝트 투입될 가능성이 있는 iOS 개발자라면, Objective-C 기초 정도는 알아두는 게 나중에 분명히 도움이 된다. 언젠가 [object method] 코드를 만났을 때 패닉 안 하려면.

#Objective-C #ObjectiveC란 #iOS개발 #iOS레거시 #Swift vs ObjectiveC #애플개발언어 #모바일개발 #프로그래밍언어역사 #동적타이핑 #메시지전송 #카테고리 #iOS앱개발 #ObjectiveCSwift #개발공부 #개발블로그

"코딩이 제일 먼저 사라진다" — Anthropic CEO 말 듣고 개발자인 내가 흔들린 이유

worniworni — Sun, 5 Apr 2026 15:37:23 +0900

300

참고 영상: Should You Learn Coding Now? Anthropic CEO Explains — Nikhil Kamath Clips

요즘 유튜브 알고리즘이 나를 AI 관련 영상으로 계속 끌어당긴다.

피드에 뜬 영상을 무심코 눌렀다가 꽤 오래 생각에 잠기게 만든 인터뷰가 있었다. Anthropic CEO인 Dario Amodei가 나온 짧은 클립인데, 내용이 직접적으로 나한테 하는 말 같아서 좀 찔렸다.

개발자로서.

https://www.youtube.com/watch?v=EdZWPB1fIJc)

"코딩은 제일 먼저 사라진다"

인터뷰어가 물었다. "코딩이랑 엔지니어링을 나눠서 보면, 코딩이 먼저 사라지나요, 아니면 엔지니어링 전체가 사라지나요?"

Dario의 답이 꽤 직접적이었다.

*"코딩이 먼저 사라집니다. AI 모델이 코딩을 먼저 하게 될 거예요. 더 넓은 의미의 소프트웨어 엔지니어링은 좀 더 오래 걸리겠지만, 결국 그것도 end-to-end로 AI가 하게 될 거라고 생각합니다."*

그냥 흘려들을 수 있는 말인데, 이 사람은 Claude를 만든 회사 CEO다. Claude Code도 만들었다. 실제로 AI가 코드를 얼마나 잘 짜는지 가장 잘 아는 사람 중 한 명이라는 거다.

그 사람이 "코딩이 제일 먼저 대체된다"고 하는데, 솔직히 좀 찜찜했다.

그래도 비교우위는 남는다고

다행인 건지 모르겠는데, 그는 "비교우위(comparative advantage)"라는 개념을 얘기했다.

어떤 일의 5%만 인간이 하고 나머지 95%를 AI가 하더라도, 그 5%가 레버리지가 되어서 생산성이 20배가 된다는 논리다. 지금 내가 하루에 짜는 코드 양이랑 비교하면... 솔직히 맞는 말이긴 하다.

AI 없이 혼자 짜던 것과, 지금 Claude나 Cursor 쓰면서 짜는 속도를 비교해보면 체감이 확 난다. 예전에 반나절 걸리던 걸 한두시간 만에 끝내는 일이 생겼다.

근데 그가 이어서 한 말이 마음에 걸렸다.

*"어느 순간 99%가 되면, 그때부터는 훨씬 어려워집니다."*

그 99%가 언제 오느냐의 문제지, 방향은 정해진 것 같다는 느낌이 들었다.

그럼 뭘 해야 하나

인터뷰어가 "25살이고 향후 10년 안에 자본주의적인 성공을 원한다면 어떤 분야를 선택해야 하냐"고 물었다.

Dario의 답:

사람 중심의 일 (human-centered tasks)
물리적 세계와 연결된 일
반도체 분야 (물리적 세계 + 전통적 엔지니어링)
AI 위에 뭔가를 얹는 일 (AI를 tailwind로 삼는 포지션)

그리고 한 가지 더, 엄청 강조했다 — 비판적 사고력(critical thinking).

AI가 모든 걸 생성하는 세상에서, 진짜와 가짜를 구분하는 능력이 굉장히 중요해진다고. 딥페이크, 가짜 뉴스, AI 생성 콘텐츠가 넘치는 세상에서 속지 않는 능력. 이게 생존 스킬이 된다고 했다.

생각해보면 그게 맞는 것 같다. 요즘 유튜브만 봐도 AI로 만든 영상인지 진짜인지 헷갈리는 게 많으니까.

Deskilling, 진짜 걱정되는 부분

이 영상에서 가장 인상 깊었던 파트는 "AI가 인간을 더 멍청하게 만드냐"는 질문에 대한 답이었다.

Dario는 명확하게 말했다. "잘못 사용하면, 그렇다."

Anthropic이 내부적으로 코드 관련 연구를 했는데, 모델 사용 방식에 따라 실제로 코딩 실력이 떨어지는 현상(deskilling)이 관찰됐다고 한다. 학생들이 AI한테 에세이 쓰라고 시키는 건 그냥 숙제 베끼는 거랑 다를 게 없고.

이게 나한테 좀 경종처럼 들렸다.

나도 요즘 Claude Code 쓰면서 예전보다 직접 고민하는 시간이 줄었다는 걸 느낀다. AI한테 물어보면 바로 나오니까, 예전처럼 30분 씩 고민하면서 삽질하는 시간이 없어졌다. 그게 효율적이기도 하지만... 그 삽질하는 과정에서 뭔가 배우고 있었던 것도 사실이다.

AI 쓰는 방식 자체를 좀 더 의식적으로 생각해야 할 것 같다는 생각이 든다. 그냥 복붙 기계처럼 쓰면 안 되겠구나.

개발자로서 드는 솔직한 생각

나는 지금 현업에서 코드 짜는 일을 하고 있다. 그리고 솔직히 AI가 내 일 일부를 빠르게 잠식하고 있다는 걸 체감한다.

단순한 CRUD, 반복적인 API 연동, 보일러플레이트 코드 — 이런 건 이미 AI가 나보다 빠르게 짠다. 그게 좀 씁쓸하기도 하고, 한편으로는 나는 더 중요한 데 집중할 수 있게 됐다고 자기합리화도 한다.

Dario가 말한 것처럼, 코딩 자체보다 소프트웨어 엔지니어링 전체 그림을 볼 수 있는 능력 — 무엇을 만들지, 왜 만들지, 사용자에게 실제로 유용한지 — 이런 판단력이 앞으로 더 중요해질 거라는 건 동의한다.

그런데 현실적으로 코딩 실력 자체를 갈고 닦지 않아도 되는 세상이 오면, 나는 그 판단력을 어떻게 키울 건지. 기초 없이 아키텍처를 판단할 수 있는 사람이 될 수 있는지. 이게 조금 불안하기도 하다.

결국 남는 건 생각하는 능력

영상 보고 나서 계속 머릿속에 남는 말이 하나 있다.

*"AI가 뭐든 만들어낼 수 있는 세상에서, 비판적 사고력이 성공의 핵심이 될 수 있다."*

뭔가를 잘 만드는 능력보다, 뭘 만들어야 할지 아는 능력. 그리고 AI가 만들어준 결과물이 맞는지 틀린지 판단할 수 있는 능력.

코딩 공부를 포기하라는 게 아니라, 코딩만 공부하면 안 된다는 메시지로 받아들였다. 도구를 쓸 줄 아는 것보다 도구가 왜 그렇게 동작하는지, 무엇을 만들어야 하는지를 알아야 한다는 것.

그게 지금 AI 시대에 개발자로 살아남는 방식인 것 같다.

아직도 조금 불안하긴 하지만, 그냥 계속 배우는 수밖에 없겠지.

이 영상을 본 사람이라면 어떻게 생각하는지 궁금하다. 나만 이렇게 찔렸나.

#Anthropic #AI개발자 #코딩미래 #DarioAmodei #개발자생존 #AI대체 #소프트웨어엔지니어링 #비판적사고 #ClaudeCode #AI시대 #개발자고민 #코딩공부 #인공지능 #테크트렌드 #deskilling

요즘 사람들이 ChatGPT 끊고 Claude로 갈아타는 진짜 이유 — AI 군사 윤리 논란

worniworni — Sun, 5 Apr 2026 15:28:40 +0900

원본 영상: Why Everyone is Switching from ChatGPT to Claude Right Now — Joma 2nd Channel

https://www.youtube.com/watch?v=hiQm6Cgwxkg

솔직히 이 영상 보기 전까지는 그냥 "Claude가 요즘 잘 나가네" 정도로만 생각하고 있었다.

ChatGPT 쓰다가 Claude로 넘어가는 사람들 많다는 건 알았는데, 그게 단순히 성능 때문이 아니라 이런 배경이 있었다는 걸 영상 보고 나서야 제대로 알았다. 개발자로 일하면서 AI 툴은 일상적으로 쓰고 있는 입장이라 이 이슈가 남의 얘기처럼 안 느껴졌다.

Anthropic이 트럼프한테 밴당한 이유

내용을 정리하자면 이렇다.

Anthropic은 원래 미국 국방부(Department of War)랑 이미 협력 관계였다. 팔란티어를 통해서 고도로 기밀적인 작업(IMPACT 6 레벨)도 하고 있었고, 2026년 1월에는 Claude가 마두로 체포 작전에 사용되기도 했다.

근데 거기서 Anthropic이 제동을 걸었다. "모델이 아직 그 수준이 안 됐다, 치명적 임무에 사용하면 안 된다"는 거였다. 그리고 국방부는 "all lawful use(모든 합법적 용도에 사용 가능)"라는 조항에 동의하라고 요구했는데, Anthropic이 이걸 거부했다.

거부 이유는 명확했다. 자국민 대규모 감시, 완전 자율 무기 시스템에 AI를 쓰는 건 동의할 수 없다는 것. 그러자 트럼프가 모든 정부 기관에 Anthropic 사용 중단을 명령하고, "공급망 리스크"로 분류해버렸다.

공급망 리스크로 분류되면 국방부와 거래하는 회사들은 Anthropic이랑 일체 거래가 금지된다. 사실상 블랙리스트다.

OpenAI는 왜 욕을 먹냐

Anthropic이 밴당하자마자 OpenAI가 그 자리를 꿰찼다. Anthropic이 거부한 조건을 OpenAI가 수락했다.

물론 OpenAI도 "레드라인이 있다"고 했다. 자국민 대규모 감시, 자율 킬봇, 고위험 자동화 결정 등은 안 된다고. 근데 문제는 그들이 "all lawful use"에 동의해버린 것이다.

영상에서 이 부분이 핵심이라고 봤다. 헌법 해석은 얼마든지 바뀔 수 있다. "합법적 용도"의 범위를 어떻게 정의하느냐에 따라 저 레드라인들은 언제든지 무력화될 수 있다는 게 사람들의 논리다. 국방부 고위 관계자도 이 계약이 "Anthropic이 거부한 바로 그 조건"에서 흘러나온 것이라고 확인해줬다.

OpenAI 입장에서는 억울할 수도 있다. 근데 퍼블릭 이미지는 이미 망가졌고, 원래 비영리 단체로 "AI가 잘못된 손에 들어가지 않게 하겠다"는 취지로 만들어진 회사가 이 짓을 하고 있으니... 사람들 반응이 이해는 간다.

Katie Perry가 월 200달러짜리 Claude 구독을 했다는 것도 웃긴데, 어쨌든 그 상징성은 있다. 실제로 Claude 앱이 앱스토어 1위까지 올라갔다고 하니까.

AI 회사들 포지셔닝 정리

영상에서 각 회사를 꽤 직설적으로 정리해줬는데, 내 식으로 한 번 더 정리하면:

xAI (Grok): 처음부터 완전 동의. Elon은 원래 이런 입장이라 사람들도 딱히 놀라지 않는 분위기.
OpenAI: 겉으로는 윤리 얘기 하면서 사실상 동의. 사람들이 가장 배신감 느끼는 케이스.
Anthropic: 완전 거부, 블랙리스트. 지금은 오히려 윤리적 회사 이미지.
Google: 애매한 중간. 비분류 업무(물류, 행정 등) 수준에서만 지원. 근데 2025년에 AI 원칙에서 무기 관련 금지 조항을 슬쩍 삭제한 전력이 있음.
Meta: 오픈소스로 가는 중. 이번 이슈에선 상대적으로 조용함.

진짜 무서운 건 따로 있다

영상에서 가장 인상 깊었던 부분은 죄수의 딜레마 비유였다.

핵 개발이랑 구조가 똑같다. 서로 원하지 않아도 "안 하면 내가 뒤처진다"는 공포 때문에 계속 달리는 것. 미국이 혼자 윤리 가이드라인 잡고 2년을 검토하는 동안, 중국은 그런 고민 없이 1년 만에 군사에 통합해버리면 미국이 지는 거다.

근데 AI 군사화는 핵보다 훨씬 더 빠르고 싸고 효율적이라는 게 문제다. 핵은 억제력으로 기능하지만, 자율 드론은 "시작했다는 것도 모르는 사이에 끝날 수 있다"는 얘기도 나온다. 오버파워드라는 표현이 딱 맞는 것 같다.

미국이 핵 개발에 쏟아부은 돈이 1996년 기준으로 12조 달러라고 한다. 지금도 연간 1천억 달러 넘게 쓰고. 그 돈이 다른 곳에 쓰였으면 세상이 어떻게 달라졌을까... 라는 생각이 드는데, AI 군사화도 같은 궤적을 밟을 것 같아서 씁쓸하다.

개발자로서 이 상황을 보면

나는 매일 Claude나 ChatGPT 같은 AI 툴을 쓴다. 코딩 도구로, 정보 검색 도구로. 이게 이미 내 일상이다.

근데 이번 사건을 보면서 이 AI 회사들의 결정이 단순히 서비스 퀄리티 문제가 아니라는 걸 다시 한번 느꼈다. 내가 쓰는 AI가 어떤 정치적 포지셔닝을 하고 있는지, 어디에 어떻게 쓰이고 있는지가 점점 더 중요해지는 시대다.

Anthropic이 선택한 길이 맞는지 틀린지는 모르겠다. 밴을 당했으니 비즈니스 관점에서는 손해일 수 있다. 근데 적어도 자기들이 어디까지 동의하고 어디서 선을 긋는지를 명확하게 했다는 점은 인상적이다.

OpenAI가 욕을 먹는 이유도 결국 같은 맥락이다. 윤리를 강조하는 척하면서 실제로는 그 윤리를 스스로 무너뜨리는 것처럼 보이기 때문이다. 오빈하이머 AI 버전이라는 표현이 좀 과하긴 한데... 틀린 말도 아닌 것 같다.

AGI에 도달하기도 전에 지금 수준의 AI로 서로 싸우다가 망할 수도 있다는 영상의 마지막 말이 계속 머릿속에 맴돈다.

별로 유쾌한 생각은 아닌데, 그래도 이런 걸 생각해보는 게 의미있다고 본다. 기술 뒤에 있는 결정들이 결국 우리 삶에 영향을 주니까.

#claude #chatgpt #openai #anthropic #AI윤리 #AI군사화 #ChatGPT해지 #Claude구독 #AI트렌드 #테크이슈 #AI뉴스 #인공지능윤리 #AI안전성 #죄수의딜레마 #AI무기화

바이브 코딩(Vibe Coding)의 민낯, 기업들이 제동을 걸기 시작한 이유

worniworni — Sun, 5 Apr 2026 00:09:12 +0900

요즘 개발자 커뮤니티든 유튜브든, 바이브 코딩(Vibe Coding) 이야기가 안 나오는 곳이 없다. AI한테 대충 말하면 앱이 뚝딱 나온다는 그 마법 같은 이야기. 나도 솔직히 처음 들었을 때는 꽤 설레기도 했다. 커서(Cursor)나 클로드 코드(Claude Code) 같은 도구들 써보면서 "오, 이거 진짜 생산성 미쳤다" 싶었던 적이 한두 번이 아니니까.

근데 최근에 Stefan Mischook이라는 베테랑 개발자의 유튜브 영상을 하나 봤는데, 제목이 "Vibe Coding Problems are Popping Up"이었다. 바이브 코딩에 문제가 터지고 있다는 거다. 현업에서 개발하는 사람으로서 공감 가는 부분이 너무 많아서, 정리겸 내 생각을 좀 적어보려고 한다.

https://www.youtube.com/watch?v=PZ_IMF-qzHc

회사들이 바이브 코딩을 막고있다?

영상 도입부에서 "우리 회사가 바이브 코딩을 차단한다(blocking)"는 이야기가 나온다. 결론부터 말하면, 완전히 금지하는 건 아니다. 하지만 분명히 제한하고, 통제하고, 특정 방식의 바이브 코딩에 대해 푸시백(push back)을 주고있는 상황이라고 한다.

그리고 이게 특정 회사만의 이야기가 아니라, 업계 전반적인 흐름이라는 게 좀 충격이었다.

왜 이런 흐름이 생겼냐면, 결국 비개발자들이 바이브 코딩을 하면서 만들어내는 'AI 슬롭 코드(AI Slop Code)' 때문이다.

80% 문제: 반쯤 왔으면, 아무데도 안 온 거다

영상에서 가장 인상 깊었던 부분이 바로 이 "80% 문제"다.

바이브 코딩으로 앱을 만들면 처음에는 진짜 잘 된다. 속도도 빠르고, 뭔가 척척 만들어지는 느낌이다. 문제는 80% 정도 완성되었을 때 찾아온다. 나머지 20%가 안 된다. 아무리 프롬프트를 바꿔보고, 다시 시도해봐도 마지막 20%를 넘을 수가 없다.

Stefan은 이걸 이렇게 표현한다.

"If you're halfway there, you're nowhere."
반쯤 왔으면, 넌 아무데도 안 온 거다.

이거 진짜 뼈 때린다. 경험 있는 개발자라면 다 아는 사실인데, 앱 개발에서 처음 50

~~70%를 만드는 건 상대적으로 쉽다. 진짜 어려운 건 마지막 10~~

20%다. 엣지 케이스 처리, 에러 핸들링, 퍼포먼스 최적화, 보안... 이런 것들이 거기에 몰려있으니까.

내 주변에도 비개발자 친구가 "나 앱 하나 만들었어!" 하고 보여줬는데, 써보면 뭔가 미묘하게 안 되는 부분이 계속 있었다. 로그인하면 가끔 세션이 날아간다든지, 특정 입력값 넣으면 화면이 멈춘다든지. 그 친구도 결국 "여기서 더 못 고치겠다"고 했다. 전형적인 80% 문제였던 거다.

초기 PHP 시대의 데자뷰

영상에서 재밌는 비유가 나온다. 지금의 바이브 코딩 상황이 초기 PHP 시대랑 똑같다는 거다.

2000년대 초반 PHP가 엄청 유행했을때, 프로그래밍 정규 교육을 받지 않은 사람들이 대거 PHP로 웹사이트를 만들었다. 일단 돌아는 갔다. 근데 SQL 인젝션 취약점 투성이에, 보안 구멍은 여기저기 뚫려있고, 유지보수는 사실상 불가능한 코드들이 쏟아져 나왔다. PHP가 한동안 "그 언어"로 취급받았던 이유 중 하나가 바로 이거였다.

지금 바이브 코딩으로 만들어지는 앱들이 정확히 그 상황을 재현하고 있다는 거다. 돌아는 가는데, 보안은 엉망이고, 업데이트는 불가능하고.

실제로 영상에서 인용된 통계를 보면:

보안 전문가의 69%가 AI 생성 코드에서 심각한 보안 이슈를 발견했다
AI 솔루션 중 실제로 보안 테스트를 통과한 건 겨우 10%에 불과하다

90%가 프로덕션에 올릴 수 없는 수준이라는 건데, 이건 좀 심각한 숫자다. 내가 회사 보안팀이어도 "바이브 코딩 좀 자제해주세요"라고 할 것 같다.

애플도 막았다, 오픈소스도 거부한다

더 흥미로운 건 플랫폼 레벨에서도 움직임이 있다는 거다.

애플(Apple)은 Replit 같은 바이브 코딩 앱의 업데이트를 차단했다. 이유는 앱 내에서 코드를 생성하고 동작을 변경하는 기능이 앱스토어 규정을 위반한다는 것이다. AI를 싫어해서가 아니라, 통제 불가능한 코드 생성을 자기 생태계에 허용할 수 없다는 입장인 거다.

실제로 ZDNet 코리아 보도에 따르면, 애플이 AI로 만든 앱들에 대해 제동을 걸고 있는 추세라고 한다.

오픈소스 프로젝트들도 AI 생성 코드 기여(contribution)를 아예 금지하는 곳이 생기고 있다. PR(Pull Request)이 올라오면 AI가 작성한 건지 사람이 작성한 건지 구분이 안 되니까, 아예 자동으로 리젝트해버리는 경우도 있다고 한다.

유지보수 하는 사람들 입장에서는 당연한 반응이다. 저퀄리티 코드가 홍수처럼 밀려오는데, 일일이 검토할 리소스가 어디 있겠나.

그러면 AI 코딩은 쓸모없는 건가?

여기서 중요한 포인트가 나온다. Stefan은 바이브 코딩 자체를 부정하는 게 아니다.

경험 있는 개발자가 AI 도구를 활용하면 생산성이 5~10배 높아진다고 말한다. 실제로 영상에서 그의 전 직원이 AI 디바이스를 시장에 내놓을 정도로 생산적으로 활용하고 있다는 사례도 나온다.

핵심은 이거다:

애플리케이션을 어떻게 구조화해야 하는지 알아야 한다
AI를 어떻게 방향 지시해야 하는지 알아야 한다
분리된 관심사(Separation of Concerns), 디자인 패턴, 리팩토링 같은 소프트웨어 개발 원칙을 이해해야 한다

결국 AI는 도구일 뿐이고, 그 도구를 제대로 쓰려면 기본기가 있어야 한다는 뻔한 결론이지만... 뻔한 게 진리인 경우가 많다.

JP모건 같은 대기업은 개발자에게 AI 사용을 의무화하고 성과 평가에까지 반영하고 있다. 메타(Meta)는 일부 팀에서 코드의 75%를 AI가 작성하도록 추진 중이라고 한다. 스타트업 Ramp는 "AI 코딩 도구를 안 쓰면 언더퍼포밍"이라고까지 말한다.

방향은 명확하다. AI 코딩은 반드시 써야 한다. 다만, 아무나 아무렇게나 쓰면 안 된다는 것이다.

현업 개발자로서 느끼는 것

나도 요즘 실무에서 AI 코딩 도구를 꽤 적극적으로 쓰고 있다. 솔직히 보일러플레이트 코드 작성이나, 간단한 유틸리티 함수 만들때, 테스트 코드 초안 잡을 때는 진짜 편하다. 예전에 30분 걸리던 게 5분이면 끝나니까.

근데 이게 좀 복잡한 비즈니스 로직으로 들어가면 얘기가 달라진다. AI가 만들어준 코드를 그대로 쓰면 나중에 분명 문제가 생긴다. 결국 코드 리뷰를 꼼꼼히 하고, 구조를 다시 잡고, 보안 체크를 하는 건 사람의 몫이다.

영상에서 Stefan이 말한 "최고의 개발자는 매우 단순하고, 이해하기 쉽고, 업데이트 가능한 코드를 작성한다"는 말이 계속 맴돈다. AI가 아무리 발전해도 이 원칙은 변하지 않을 거다. 오히려 AI 시대에 더 중요해지는 것 같다. AI가 뱉어낸 복잡한 코드를 단순하고 유지보수 가능한 형태로 다듬을 수 있는 능력, 그게 앞으로 개발자의 핵심 역량이 되지 않을까.

바이브 코딩, 어디에 쓰면 좋은가

영상의 결론 부분에서 Stefan이 정리한 바이브 코딩의 적합한 영역이 있다:

프로토타이핑: 아이디어 검증용으로는 최고다
내부 도구(Internal Tools): 외부에 공개되지 않는 간단한 도구들
아이디어 탐색: 이거 되나 안 되나 빠르게 확인해보는 용도
일회성 구현(Throwaway): 어차피 버릴 건데 빠르게 만들어보는 것

반면, 민감한 데이터를 다루는 시스템이나 프로덕션 레벨의 서비스를 바이브 코딩만으로 만들겠다는 건... 글쎄. 좀 무모하다고 본다.

마치며

이 영상을 보고 나서 드는 생각은, 결국 기술의 본질은 변하지 않는다는 거다. 도구가 아무리 좋아져도, 그 도구를 쓰는 사람의 역량이 결과물의 품질을 결정한다. 망치가 좋아졌다고 아무나 집을 지을 수 있는 건 아니듯이.

바이브 코딩의 거품이 걷히고 있는 지금이 오히려 개발자에게는 기회일 수 있다. AI를 제대로 활용할 줄 아는 개발자와, 그냥 AI한테 떠넘기기만 하는 사람의 격차가 점점 벌어질 테니까. 나도 기본기를 더 다지면서 AI를 도구로 잘 활용하는 방향으로 가야겠다고 다시 한번 다짐하게 된다.

어쩌면 바이브 코딩의 진짜 가치는, 코딩을 몰라도 앱을 만들 수 있다는 데 있는 게 아니라, 코딩을 아는 사람이 훨씬 더 빠르게 만들 수 있다는 데 있는 건지도 모르겠다.

참고 영상:

Stefan Mischook - Vibe Coding Problems are Popping Up: https://www.youtube.com/watch?v=PZ_IMF-qzHc

참고 자료:

#바이브코딩 #VibeCoding #AI코딩 #AI슬롭코드 #개발자 #소프트웨어개발 #코딩 #AI개발도구 #프로그래밍 #개발자생산성 #애플앱스토어 #오픈소스 #코드리뷰 #80퍼센트문제

빅테크 해고는 왜 반복될까? 개발자가 본 구조적 원인과 생존 전략

worniworni — Sun, 5 Apr 2026 00:05:26 +0900

요즘 뉴스를 켜면 빅테크 해고 소식이 끊이질 않는다. 아마존이 1만 6천명을 자르고 추가로 1만 4천명을 더 줄인다고 하고, 메타는 전체 인력의 20%를 감축한다는 이야기까지 나온다. 20%면 진짜 엄청난 숫자다. 주변에서도 "너는 괜찮아?" 라는 안부 인사가 자연스럽게 오가는 분위기고, 솔직히 나도 남의 일 같지 않다.

그러다 유튜브에서 Joma의 영상 하나를 봤는데, 이게 생각보다 너무 뼈를 때려서 한참을 멍하니 있었다. "해고는 모든 사람이 최적의 합리적 판단을 했기 때문에 일어난다"는 거다. 아무도 잘못한 게 없는데, 그 결과가 해고라니. 좀 씁쓸하지만, 곱씹어보면 정말 그런것 같다.
https://www.youtube.com/watch?v=fv8zpYI9n6s&t=1s

"AI 때문이다"는 절반만 맞는 이야기

요즘 해고 뉴스마다 빠지지 않는 키워드가 AI다. "AI가 사람을 대체하고 있다", "AI 때문에 개발자도 위험하다" 같은 말들. 틀린 말은 아니다. AI가 해고의 자연적인 사이클을 가속화하는 건 맞다. 하지만 Joma의 말처럼, 그게 전부는 아닌 것 같다.

해고는 경쟁이 치열한 산업이라면 어디서든 일어날 수 밖에 없는 구조적인 문제다. 그리고 IT 산업은 이 세상에서 가장 경쟁이 치열한 분야 중 하나다. AI가 없었어도 해고는 있었을 거고, AI가 있으니까 좀 더 빨라진 것뿐이다.

죄수의 딜레마, 수천 명이 참여하는 버전

Joma가 이걸 "수천 명의 플레이어가 참여하는 죄수의 딜레마"에 비유한 게 인상 깊었다. 모든 관련자가 각자의 위치에서 가장 합리적인 선택을 하고 있는데, 그 합리적인 선택들이 모이면 결국 해고라는 결과가 나온다는 거다.

경영진이 과잉 채용한 게 멍청한 거 아니냐고? 아니다. 매니저가 팀 관리를 못한 거 아니냐고? 그것도 아니다. 다 자기 입장에서 최선의 수를 뒀다. 그런데 웃긴 건, 시간을 되돌려서 다시 한다고 해도 결국 똑같은 선택을 할 거라는 점이다. 해고도 똑같이 일어날 거고.

이 부분에서 좀 소름이 돋았다. 왜냐면 나도 개발자로서 회사를 고를 때 연봉이 높은 곳, 복지가 좋은 곳을 우선적으로 봤으니까. 내가 바로 그 "합리적 판단"을 하는 수천 명 중 한 명이었던 거다.

빠른 채용의 함정: 인재 밀도가 떨어지는 순간

회사가 경쟁에서 살아남으려면 빨리 성장해야 하고, 빨리 성장하려면 사람을 빨리 뽑아야한다. 그런데 빨리 뽑으려면? 채용 기준을 낮출 수밖에 없다. 최고의 인재만 기다릴 여유가 없으니까.

넷플릭스의 사례가 재밌었다. 넷플릭스는 인재 밀도를 극도로 높게 유지하는 걸로 유명하다. 최고 수준의 인재만 뽑고, 관리를 최소화하고, 자율적으로 일하게 한다. 근데 이게 가능했던 이유가 뭐냐면, 초기 넷플릭스는 사실상 경쟁자가 없었기 때문이다. HBO나 디즈니+가 나오기 전, 유일한 스트리밍 서비스였으니까 천천히 좋은 사람만 골라 뽑을 여유가 있었던 거다.

하지만 경쟁이 붙으면 이야기가 달라진다. 경쟁사가 빠르게 시장을 잠식하고 있는데 "우리는 좋은 인재만 기다리겠습니다" 하면? 그건 그냥 죽겠다는 거나 마찬가지다. 코드 퀄리티가 아무리 좋아도, 시장 점유율을 뺐기면 끝이다. 그래서 다들 사람을 마구 뽑는다.

코로나 때를 떠올려보면 딱 그랬다. 갑자기 모든 사람이 집에서 테크 제품을 쓰기 시작했고, 그 수요를 잡으려고 아마존이랑 메타는 3년만에 인원을 두 배로 늘렸다. 안 뽑으면? 사람들이 유튜브 대신 페이스북을 쓰고, AWS 대신 Azure를 쓸 테니까.

개인의 합리적 선택이 만드는 조직의 비효율

여기서 진짜 재밌는 지점이 나온다. 회사가 커지고 상장까지 하면, 내가 하는 일이 회사의 성공에 미치는 영향은 극히 미미해진다. 주식을 받아도 내 업무 성과와 주가는 거의 관계가 없고, 결국 출근하고 퇴근하고 하루를 버티는 게 현실이 된다.

그러면 자연스럽게 이런 계산을 하게된다. "회사에 진짜 중요한 프로젝트를 맡아서 3배 더 힘들게 일해봤자, 보너스가 15% 더 나올까 말까인데... 그게 과연 의미가 있나?" 당연히 없다. 차라리 안정적인 포지션을 잡고 적당히 성과를 내는 게 합리적이다.

나도 솔직히 이 생각을 안 해본 적이 없다. 회사에서 진짜 의미있는 일을 하고 싶은 마음과, 현실적으로 나에게 가장 유리한 전략 사이에서 갈등하는 건 모든 직장인의 숙명 아닐까. Joma가 "커리어 아비트라저(Career Arbitrageur)"라고 부르는 부류가 있는데, 순전히 돈을 보고 테크 업계에 들어온 사람들이다. 90년대엔 투자은행, 2000년대엔 컨설팅, 지금은 IT. 능력도 있고 합리적이지만, 일 자체에 대한 열정은 없다. "만약 연봉이 교사 수준이라면 그래도 이 일을 할 건가?" 라는 질문에 "아니"라고 대답한다면, 바로 이 부류에 속하는 거다.

솔직히 이 질문 앞에서 자신있게 "네"라고 답할 수 있는 개발자가 몇이나 될까. 나도... 글쎄, 좀 고민이 되는 부분이다.

연기와 거울: 회사가 누가 진짜인지 모르는 이유

회사가 커지면 관료주의, 성과 평가, 목표 설정 같은 관리 시스템이 생긴다. 이게 다 직원들을 올바른 방향으로 유도하기 위한 장치인데, 문제는 이런 시스템 자체가 게임의 대상이 된다는 거다.

성과 평가를 잘 받으려고 실제로 임팩트가 큰 일을 하는 대신, 임팩트가 커 보이는 일을 하는 사람이 생긴다. 팀 규모를 부풀리고, 자기 스코프가 얼마나 복잡한지를 과장하고, 크레딧을 가져오는 데 에너지를 쏟는 매니저도 있다. 측정 가능한 모든 지표는 조작 가능하다. 그리고 사람들은 최소 저항의 경로를 찾아 그 지표를 해킹한다.

Joma가 예시로 든 게 웃기면서도 슬펐다. "요즘 회사에서 AI 사용량을 보고 있는 것 같다. 생산성의 지표라고 생각하니까. 그러면 뭘 하면 되냐? 매일 아침에 AI한테 아무 질문이나 많이 던져라. 쓸데없는 코드라도 AI로 작성해라." 이게 진짜 현실이라니.

결국 회사는 진짜 높은 ROI를 내는 사람과 연기와 거울(smoke and mirrors)로 높은 ROI처럼 보이게 하는 사람을 구분할 수 없게 된다. 그래서 리셋 버튼을 누르는 거다. 그게 해고다.

케이블 비유가 너무 와닿았다

영상에서 가장 기억에 남는 비유가 있다. 컴퓨터 뒤에 케이블이 엉켜있는데, 어떤 건 필요하고 어떤 건 쓸데없는 건지 모르는 상황. 하나하나 추적하면서 불필요한 걸 뽑는 것보다, 그냥 전부 뽑아버리고 필요한 것만 다시 꽂는 게 더 효율적이라는 거다.

해고가 딱 그거다. 수술적으로 누가 좋고 누가 나쁜지 일일히 파악하려면 엄청난 시간과 비용이 든다. 차라리 한 번에 쓸어버리고, 실수로 잘린 사람은 다시 데려오는 게 낫다는 판단. 잔인하지만 효율적이다. 그리고 효율성은 기업의 언어다.

개발자로 일하면서 이런 구조 안에 있다는 걸 인지하는 것 자체가 중요한것 같다. 내가 아무리 잘해도, 내 팀이 실험적인 프로젝트를 하고 있었다면 해고 대상이 될 수 있다. 반대로 내가 평범해도 수익을 직접 만드는 팀에 있으면 살아남을 수 있다. 능력의 문제가 아니라 포지셔닝의 문제라는 거다.

그래서 어떻게 살아남을 것인가

Joma는 두 가지 방향의 전략을 제시한다.

원칙적 매크로 전략 (진짜 ROI를 높이는 법)

첫째, 과대평가 되지 마라. 억지로 승진해서 자기 실력 이상의 연봉을 받으면 타겟이 된다. 항상 불안하고, 번아웃 되기 쉽고, 스킬을 키우는 대신 승진 게임에만 올인하게 된다. 승진을 요청하기 전에 한 번 더 생각해보라는 조언이 꽤 현실적이다.

둘째, 돈을 버는 팀에 가라. 광고, AWS, 수익화 관련 팀들은 해고 대상이 되기 어렵다. 회사에 돈을 벌어다주는 게 명확하니까. 대신 이런 팀은 보통 빡세다. 방향이 명확하니까 리드가 정확히 얼마나 짜낼 수 있는지 알고 있다. "그 팀은 절대 가지마, 24시간 일시킨다" 같은 소문이 도는 팀이 오히려 해고에서는 안전한 팀이라는 아이러니.

셋째, 임팩트를 높여라. AI를 써라. 지금 AI를 안 쓰고 코딩하는 건, 계산기가 있는데 손으로 계산하는 것과 같다. 동의한다. 나도 요즘 Claude나 코파일럿 없이 개발하는 게 상상이 안 된다. AI를 쓰는 사람과 안 쓰는 사람의 아웃풋 차이는 점점 벌어질 거고, 그 차이가 해고 리스트에 영향을 줄 수도 있다.

전술적 마이크로 전략 (광학적 illusion)

이건 진짜 ROI를 바꾸는 게 아니라, 좋아보이게 만드는 전략이다.

나를 좋아하는 매니저를 골라라. 결국 해고 리스트에 대한 인풋은 매니저한테서 나온다.
과하게 소통하고, 과하게 어필해라. 프로젝트가 얼마나 어려웠는지, 얼마나 임팩트가 컸는지 소리를 질러라. 숲에서 나무가 쓰러져도 아무도 안 들으면 쓰러진 거 아닌 것처럼.
허영 지표를 파악하고 최적화해라. 회사가 뭘 보고 있는지 알아내서 그걸 맞춰라.

근데 Joma가 마지막에 날린 한마디가 핵심이다. 이런 마이크로 전략을 쓰는 사람이 너무 많아지면, 그게 바로 해고가 일어나는 이유가 된다. 진짜 일을 하는 대신 살아남기 위한 게임을 하는 사람이 늘어나면, 회사는 결국 리셋 버튼을 누를 수밖에 없다. 완벽한 순환 구조다.

영상을 보고 나서 든 생각

이 영상을 보고 나서 한동안 생각이 많았다. 나는 어디에 서 있는 걸까?

솔직히 말하면, 나도 "합리적인 판단"을 하면서 살아왔다. 연봉 높은 곳을 찾고, 안정적인 포지션을 원하고, 적당히 성과를 내면서 워라밸을 지키려고 했다. 그게 나쁜 건 아니다. Joma 말대로 모두가 그렇게 하고 있고, 그게 합리적이니까.

하지만 이 영상이 던지는 진짜 메시지는 다른 데 있는 것 같다. 이 시스템 안에서 마이크로 전략만으로 버티는 건 결국 한계가 있다는 거다. 해고의 파도가 올 때마다 광학적 착시로 살아남을 수는 있겠지만, 진짜 경쟁력을 키우지 않으면 언젠가는 걸리게 되어 있다.

그래서 결국은 매크로 전략이 답이다. 진짜 실력을 키우고, AI를 적극 활용해서 아웃풋을 높이고, 회사에 실질적인 가치를 만들어내는 사람이 되는 거. 뻔한 결론 같지만, 이 영상을 통해 "왜" 그래야 하는지의 구조를 이해하게 된 것 같다. 단순히 "열심히 해야지"가 아니라, 시스템의 구조 자체가 그렇게 설계되어 있다는 걸 알게 된 거니까.

그리고 한 가지 더. "나쁜 사람은 없다"는 Joma의 말이 계속 머리에 맴돈다. 경영진도 매니저도 직원도 다 자기 입장에서 최선을 다했다. 그 결과가 해고라는 게 좀 비극적이긴 하지만, 그게 자본주의의 리얼리즘이 아닐까. 적어도 이 구조를 이해하고 있으면, 해고를 당하더라도 "내가 뭘 잘못한 거지?" 라는 자책은 좀 덜 할 수 있을것 같다.

오늘도 코드를 짜면서 생각한다. 나는 진짜 가치를 만들고 있는건가, 아니면 그렇게 보이려고 애쓰고 있는 건가. 이 질문을 스스로에게 던지는 것만으로도, 이 영상은 충분히 볼 가치가 있었다.

참고 영상:

Joma 2nd Channel - 기술 업계 해고의 진짜 원인은 AI가 아니라 미국이다: https://www.youtube.com/watch?v=fv8zpYI9n6s

#빅테크해고 #개발자생존 #테크레이아웃 #IT업계 #개발자커리어 #AI시대 #해고대비 #커리어전략 #Joma #실리콘밸리 #테크업계구조조정 #개발자현실

macOS에서 Apple Intelligence를 터미널로 쓴다? Apfel 직접 써봤

worniworni — Sat, 4 Apr 2026 23:43:44 +0900

GeekNews에서 우연히 발견한 이것

며칠 전 GeekNews를 훑어보다가 눈에 확 들어오는 글이 하나 있었다. 제목이 뭐였냐면, "macOS 26의 온디바이스 LLM을 CLI로 사용하기" 뭐 이런 느낌이었는데, 링크를 따라가보니 Apfel이라는 오픈소스 프로젝트였다.

요약하자면 Apple Silicon Mac에서 Apple Intelligence의 온디바이스 LLM을 터미널에서 직접 호출할 수 있게 해주는 도구다. API 키도 없고, 클라우드 연결도 없고, 완전히 내 맥 안에서만 돌아간다는 거다.

맥 좋아하는 개발자로서 이건 그냥 넘길 수가 없었다. 바로 설치해봤다.

참고로 GeekNews 링크는 여기다: https://news.hada.io/topic?id=28178
GitHub은 여기: https://github.com/Arthur-Ficial/apfel

Apfel이 뭔가

공식 설명을 좀 정리하면:

macOS 26(Tahoe) 이상 + Apple Silicon Mac 에서만 동작
Apple이 이미 기기에 내장시켜 놓은 온디바이스 LLM(약 3B 파라미터)을 꺼내 쓰는 방식
Swift 6.3+로 짜여 있고, Xcode 없이 빌드 가능
MIT 라이선스, 완전 무료
OpenAI 호환 API 서버 제공 (localhost:11434)
MCP 도구 지원
한국어 포함 15개 언어 지원

특이한 건 이 프로젝트, 하루 만에 GitHub 스타 818개를 찍었다는 거다. Apple, Google, VMware, NVIDIA 엔지니어들까지 관심을 보였다는 이야기가 있을 정도다. 오픈소스 커뮤니티의 반응이 꽤 폭발적이었다.

그도 그럴 것이, Apple Intelligence가 맥에 이미 깔려있는데 그걸 터미널에서 자유롭게 쓸 수 있다면? 그냥 흥미로운 수준을 넘어서, 뭔가 진짜 쓸모있는 게 될 수도 있겠다 싶었다.

설치는 간단하다

Homebrew만 있으면 된다.

brew tap Arthur-Ficial/tap
brew install Arthur-Ficial/tap/apfel

탭 추가하고 설치하면 끝이다. 소스에서 빌드하는 방법도 있긴 한데 굳이 그렇게 할 이유는 없다. Brew로 금방 깔린다.

설치하고 나서 버전이랑 모델 정보 확인해봤다.

apfel --model-info

model:      apple-foundationmodel
on-device:  true (always)
context:    4096 tokens
languages:  en, de, da, nb, fr, tr, zh, nl, pt, ja, es, ko, it, sv, vi
framework:  FoundationModels (macOS 26+)

on-device: true (always) — 이 한 줄이 묘하게 마음에 든다. 데이터가 어디로도 나가지 않는다는 뜻이니까.

직접 써보기 — 기본 사용법

영어 질문

가장 기본적인 테스트부터.

apfel "What is the capital of South Korea?"

The capital of South Korea is Seoul.

응답 시간이 약 1.5초. 빠르다. 생각보다 훨씬 빠르다. 클라우드 API 호출할 때의 그 네트워크 지연이 없으니까, 맥이 직접 계산하는 속도 그대로 나오는 거다.

파이프 입력

UNIX 철학대로 파이프가 된다. 이게 개발자한테는 꽤 매력적인 부분이다.

echo "Hello, I am a developer from Korea. Tell me something interesting about Apple Silicon." | apfel

Apple Silicon의 통합 메모리 아키텍처라든가, 뉴럴 엔진 성능이라든가 관련 설명을 잘 해줬다. 내용 자체도 그렇게 틀리지 않았다.

파일 첨부

apfel -f somefile.txt "이 내용 요약해줘"

-f 플래그로 파일 붙여서 질문할 수 있다. 코드 파일이나 텍스트 파일 분석할 때 유용하다.

한국어 테스트 — 여기서 재미있는 일이 생겼다

사실 이 부분이 제일 궁금했다. 한국어 지원이 된다고는 하는데, 3B짜리 온디바이스 모델이 한국어를 얼마나 잘 하겠냐는 의구심이 있었다.

먼저 시스템 프롬프트 없이 그냥 한국어로 물어봤다.

apfel "오늘 저녁 메뉴 추천해줘. 한국 음식으로."

불고기, 김밥 같은 건 잘 추천해줬다. 근데 여기서 웃긴 일이 터졌다. 삼겹살을 추천하면서 "소고기를 구워 먹는 음식" 이라고 설명한 거다. 삼겹살이 소고기라니... 이건 돼지고기인데.

거기다 "불국수" 라는 음식도 등장했다. 불고기 + 국수를 합성해서 만들어낸 건지, 뭔지... 존재하지 않는 음식이다. 전형적인 할루시네이션이다.

3B 모델의 한계가 이런 데서 나온다. 충분히 예상된 부분이긴 하다.

그래서 시스템 프롬프트를 줘봤다.

apfel -s "질문의 요구를 그대로 따르되, 한국어로 직접 답하세요" "애플 실리콘의 장점 3가지를 알려줘"

1. 고성능 및 효율성
2. 유연한 설계
3. 안정성과 신뢰성

이번엔 깔끔하다. 시스템 프롬프트로 한국어 응답을 강제하니까 훨씬 나아진다. 그러니까 한국어로 쓸 때는 -s 플래그로 시스템 프롬프트를 같이 줘야 좀 더 안정적으로 동작한다.

코드 설명 테스트도 해봤다.

echo 'print("hello world")' | apfel "이 코드가 뭘 하는 코드인지 한국어로 설명해줘"

Python print 함수가 뭔지, "hello world"를 출력하는 코드라는 걸 한국어로 잘 설명해줬다. 간단한 코드 분석은 무난하게 된다.

개발자를 위한 기능들

JSON 출력

apfel -o json "List 3 programming languages"

{
  "result": "...",
  "metadata": {
    "on_device": true,
    "version": "0.7.2",
    "model": "apple-foundationmodel"
  }
}

metadata에 on_device: true가 항상 박혀 나온다. 스크립트나 자동화 파이프라인에 연결할 때 JSON 출력이 꽤 유용하다.

OpenAI 호환 서버

apfel --serve

이걸 실행하면 localhost:11434에 OpenAI 호환 API 서버가 뜬다. 이게 진짜 쓸모있는 부분인데, 기존에 OpenAI API를 쓰던 코드에서 base_url만 바꾸면 그대로 돌아간다.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="apple-foundationmodel",
    messages=[{"role": "user", "content": "Hello!"}]
)

API 키 자리엔 아무거나 넣으면 된다. 어차피 로컬이니까. 기존 OpenAI 연동 코드가 있다면 거의 드롭인 교체 수준으로 로컬 모델로 전환할 수 있다.

MCP 도구 지원

apfel --mcp ./server.py "이 데이터베이스에서 최근 주문 5건 조회해줘"

MCP(Model Context Protocol) 도구도 붙일 수 있다. 외부 서비스나 데이터베이스랑 연결하는 에이전트 형태로 확장이 가능하다는 뜻이다. 아직은 실험적인 수준이겠지만, 이 방향이 맞다고 생각한다.

대화형 모드

apfel --chat

일반 채팅처럼 대화를 이어갈 수 있는 모드도 있다. 터미널에서 간단히 뭔가 물어보고 싶을 때 유용하다.

장점과 한계 정리

장점

완전 무료, 그리고 프라이버시
API 키도, 크레딧도, 요금도 없다. 그리고 무엇보다 데이터가 외부로 나가지 않는다. 민감한 코드나 회사 내부 문서를 AI한테 물어볼 때 늘 찝찝했던 그 기분이 없다.

빠른 응답 속도
네트워크 지연이 없으니 단순 쿼리는 1~2초 안에 끝난다. 터미널 워크플로우에 끊기지 않고 자연스럽게 녹아든다.

UNIX 철학에 맞는 파이프 지원
cat file.py | apfel "이 코드 리뷰해줘" 이런 식으로 기존 쉘 파이프라인에 AI를 끼워넣을 수 있다는 게 개발자 관점에서 정말 자연스럽다.

OpenAI 호환 API
기존 코드 자산을 버리지 않아도 된다.

한계

4096 토큰 제한
컨텍스트 윈도우가 좁다. 긴 파일을 통째로 던지거나, 긴 대화를 이어가는 건 무리다.

3B 모델의 능력 한계
복잡한 추론이나 멀티스텝 코딩은 기대하기 어렵다. 앞서 본 것처럼 한국어 도메인 지식에서 할루시네이션이 꽤 나온다. 삼겹살이 소고기라는 게 틀려도 너무 틀렸다.

macOS 26+ 제한
아직 macOS 26이 정식 릴리즈 전이다. 베타나 RC 버전에서만 쓸 수 있다는 뜻이다.

이미지/멀티모달 미지원
텍스트 전용이다. 이미지 분석 같은 건 안 된다.

벤치마크도 찾아봤다

공식 벤치마크 결과가 있길래 봤다.

trim_newest_first:         4.82x speedup
trim_oldest_first:         4.65x speedup
context_manager_make_session: 182.572 ms

세션 생성에 182ms 정도 걸리고, 내부 컨텍스트 트리밍에서 4~5배 성능 개선이 있다는 내용이다. 실제로 체감 응답 속도도 빠른 편이라 수치가 허투루 느껴지진 않는다.

총평

Claude나 GPT 같은 클라우드 모델을 대체할 수 있냐고? 그건 아니다. 3B 모델로 할 수 있는 것과 못 하는 것의 차이가 분명히 있고, 특히 한국어 복잡한 맥락이나 도메인 지식에서 한계가 드러난다.

근데 그렇다고 쓸모없냐 하면 그것도 아니다.

간단한 코드 설명, 영어 쿼리 처리, 텍스트 요약, 터미널 파이프라인에서 뭔가 가볍게 물어볼 때 — 이런 용도로는 충분히 쓸만하다. 특히 회사 내부 코드나 민감한 문서를 다룰 때 클라우드 API가 찝찝했다면, 로컬에서만 돌아가는 Apfel은 좋은 선택지가 될 수 있다.

Apple이 모델을 꾸준히 업데이트하면 어떻게 될지도 기대된다. macOS 릴리즈마다 Apple Intelligence가 개선된다고 하니까, Apfel이 가져다 쓰는 모델도 자연스럽게 좋아질 거다.

무엇보다 이 도구의 방향성이 마음에 든다. 내 맥 안에서, 내 데이터를 밖으로 내보내지 않고, 터미널 워크플로우에 자연스럽게 녹아드는 AI. 개발자가 원하는 모습이 딱 이거 아닌가 싶다.

macOS 26이 정식 릴리즈 되면 좀 더 안정적으로 써볼 수 있을 것 같다. 그때 다시 한번 정리해봐야겠다.

#Apfel #AppleIntelligence #로컬LLM #온디바이스AI #macOS #AppleSilicon #CLI #개발자도구 #맥개발 #FoundationModels

MS를 긴장시키는 Anthropic의 AI 에이전트, Co-work의 등장

worniworni — Fri, 30 Jan 2026 21:40:22 +0900

요즘 개발자들 사이에서 AI는 빼놓을 수 없는 주제다. 나 역시 깃허브 코파일럿을 매일같이 사용하고 있고, 최근에는 MS 365 코파일럿의 확장세도 심상치 않다고 느낀다. MS가 OpenAI와의 강력한 파트너십으로 이 시장을 주도하고 있다고 막연히 생각했는데, 우연히 본 유튜브 영상 하나가 이런 내 생각을 흔들어 놓았다. MS의 CEO, 사티아 나델라가 Anthropic이라는 회사의 신제품 때문에 꽤나 긴장하고 있다는 내용이었다.
https://www.youtube.com/watch?v=__YTHXy25Y0
영상에 따르면 Anthropic이 내놓은 'Co-work'라는 제품이 MS 내부를 흔들고 있다고 한다. 이건 단순히 질문에 답하는 챗봇 수준을 넘어선다. 사용자의 데스크톱 환경 전체를 넘나들며 작업을 수행하는 'AI 에이전트'에 가깝다. 예를 들어, 영수증 사진이 가득한 폴더를 보여주며 "이거 엑셀 파일로 정리해줘"라고 말하면, 스스로 엑셀을 켜고 데이터를 입력해 표를 만들어준다는 것이다. 생각만 해도 엄청난 생산성 향상이다.

더 흥미로운 점은 'Moltbot'이라는 오픈소스 프로젝트다. Co-work와 비슷하게 Anthropic의 모델을 사용하는데, 사티아 나델라 CEO가 주말 동안 직접 이 툴을 사용해보고는 그 결과를 임원들에게 공유하며 "왜 우리는 이런 제품을 만들 생각을 못 하고 있는가?"라고 질책에 가까운 독려를 했다는 것이다. 한 회사의 CEO, 그것도 MS같은 거대 기업의 수장이 경쟁사의, 심지어 정식 제품도 아닌 팬 프로젝트에 가까운 툴을 직접 써보며 위기감을 느꼈다는 사실은 시사하는 바가 크다. AI 경쟁의 판도가 우리가 아는 것보다 훨씬 더 역동적으로 움직이고 있다는 증거다.

물론 MS에게는 여전히 막강한 무기가 있다. 바로 윈도우(Windows)라는 운영체제와 오피스(Office)라는 생산성 스위트다. 현재 Anthropic의 Co-work는 Mac에서만 구동된다고 하는데, MS는 자신들의 홈그라운드인 윈도우 환경에 AI 에이전트를 네이티브 수준으로 통합해버리면 단숨에 전세를 역전시킬 수도 있다. 이미 수많은 사용자들이 MS의 생태계 안에서 일하고 있다는 점은 그 어떤 경쟁자도 무시할 수 없는 강력한 해자다.

한편으로는 MS가 Anthropic에 투자를 한 'frenemy(친구이자 적)' 관계라는 점도 재미있다. Anthropic이 성장하면 MS의 투자 수익도 늘어나지만, 동시에 MS의 핵심 사업인 코파일럿은 위협을 받는다. AI 시대의 합종연횡은 정말 한치 앞을 내다보기 어렵게 만든다.

개발자로서 이런 흐름을 보니 생각은 더 복잡해진다. 이제 단순히 더 좋은 언어모델(LLM)을 만드는 경쟁을 넘어, 그 모델을 활용해 '실제로 인간의 일을 대신해주는' 에이전트를 누가 먼저 만드느냐의 싸움으로 넘어가고 있다. 이건 PC의 등장, 인터넷의 등장과 맞먹는 패러다임의 변화일지도 모른다. 앞으로 몇 년 안에 우리 모두 개인 AI 비서를 두고, 복잡한 디지털 작업을 말 한마디로 처리하게 될지도 모를일이다. 이 경쟁의 승자가 누가 될지, 그리고 그 과정에서 우리의 일상은 또 어떻게 바뀔지 계속해서 주목해야겠다.

#Microsoft #Anthropic #AI #AIAgent #SatyaNadella #Copilot #Cowork #Tech #개발자 #IT

스마트폰 다음은 무엇일까? 조니 아이브와 샘 알트먼의 대화에서 얻은 생각들

worniworni — Sat, 25 Oct 2025 00:07:56 +0900

얼마 전 흥미로운 유튜브 영상을 하나 봤다. 바로 애플의 전설적인 디자이너, 아이폰을 만든 조니 아이브와 OpenAI의 CEO 샘 알트먼이 나누는 대화였다. 개발자로서, 그리고 IT 기기를 좋아하는 사람으로서 그냥 지나칠 수 없는 조합이었다. 그런데 영상을 보고 머리를 한 대 맞은 듯한 느낌이 들었다. 조니 아이브가, 바로 그 아이폰을 세상에 내놓은 사람이, 스마트폰을 ‘과거의 기술(legacy products)’이라고 부르고 있었기 때문이다.

스마트폰은 구식 (조니 아이브) 유튜브 영상

스마트폰은 이미 과거의 유물?

2007년 아이폰이 처음 등장했을 때의 충격을 아직도 기억한다. 세상을 바꾼 혁신이었고, 지금도 우리 삶의 중심에 있는 물건이다. 그런데 그걸 만든 장본인이 이제는 과거의 것이라니. 처음엔 ‘아니, 이 사람이 왜 이런 말을 하지?’ 싶었다.

하지만 그들의 대화를 찬찬히 뜯어보니 이해가 가기 시작했다. 그들은 지금의 스마트폰이 AI와 같은 새로운 기술을 담아내기에 최적의 그릇이 아닐 수도 있다고 보고 있었다. 멀티터치 인터페이스가 범용성을 무기로 지난 10여 년간 세상을 지배했지만, 이제는 그 틀을 넘어서는 새로운 무언가가 필요하다는 것이다. 마치 우리가 피처폰에서 스마트폰으로 넘어왔듯, 그들은 또 다른 차원의 전환을 준비하고 있었다.

생각해보면 나 역시 비슷한 경험을 한 적이 있다. 개발을 하다 보면 기존의 아키텍처나 프레임워크가 새로운 요구사항을 담아내기 버거워지는 순간이 온다. 처음엔 어떻게든 땜질해서 해결해보려 하지만, 결국에는 근본적인 구조 변화 없이는 앞으로 나아가기 어렵다는 걸 깨닫게 된다. 아마 그들도 스마트폰이라는 ‘제품’에서 비슷한 한계를 느끼고 있는 게 아닐까.

새로운 아이디어는 연약하게 태어난다

샘 알트먼은 조니 아이브가 어떻게 그렇게 ‘당연한 듯하면서도 완전히 새로운’ 아이디어를 내놓는지 궁금해했다. 조니 아이브의 대답이 인상 깊었다.

"아이디어는 항상 잠정적이고, 조용하고, 본질적으로 연약한 방식으로 시작됩니다."

그는 위대한 아이디어도 처음에는 아주 작고 연약한 생각에서 출발한다고 말했다. 그리고 그 연약한 아이디어를 말로 표현하고, 동료들과 공유하며 발전시켜 나가는 과정의 중요성을 강조했다. 서로에 대한 깊은 신뢰가 없으면, 아직 형태도 제대로 갖추지 못한 생각을 꺼내놓기란 불가능에 가깝다.

이 부분에서 정말 많은 공감을 했다. 개발자들끼리 모여 새로운 프로젝트를 구상할 때, "이거 너무 뜬구름 잡는 소리 아냐?" 혹은 "말이 안 되는 것 같은데"라는 두려움에 입을 닫게 되는 경우가 얼마나 많던가. 하지만 조니 아이브는 바로 그 ‘말이 안 되는 것 같은’ 생각들을 소중히 다루고, 탐색하는 과정 속에서 혁신이 태어난다고 말한다. 결국 중요한 건 기술 자체가 아니라, 그 기술을 가지고 무엇을 할지 상상하고, 함께 이야기 나눌 수 있는 ‘사람’과 ‘팀’이라는 생각이 들었다.

경험이 때로는 장애물이 될 때

영상을 보면서 또 하나 흥미로웠던 점은 조니 아이브가 자신의 ‘경험’을 경계한다는 것이었다. 그는 30년 넘게 쌓아온 자신의 경험이 어디에서 유용하고, 어디에서 장애물이 되는지를 매일 스스로에게 묻는다고 했다.

세상이 너무나 빠르게 변하고 있기 때문에, 과거의 성공 방식이 더 이상 통하지 않을 수 있다는 것이다. 특히 AI처럼 완전히 새로운 분야에서는 우리 모두가 평등한 출발선에 서 있다고 그는 말한다. ‘내가 해봐서 아는데’라는 태도만큼 위험한 것도 없다는 뜻이다.

나 자신을 돌아보게 되는 말이었다. 연차가 쌓이면서 나도 모르게 ‘이건 이렇게 하는 게 맞아’라는 도그마에 빠져있지는 않았을까? 새로운 기술 앞에서 ‘어차피 기존 기술의 연장선이겠지’라며 섣불리 판단하지는 않았을까? 호기심과 배우려는 자세, 그리고 자신의 믿음을 끊임없이 의심하는 태도야말로 이 시대를 살아가는 개발자에게 가장 필요한 덕목이라는 생각이 들었다.

기술의 궁극적인 목표

대화의 마지막, 샘 알트먼은 이 기술 혁명을 통해 무엇을 가장 바로잡고 싶냐고 묻는다. 조니 아이브의 대답은 의외로 소박했다.

"이 도구들이 우리를 행복하고, 충만하고, 더 평화롭게 만들고, 덜 불안하고, 덜 단절되게 만들었으면 합니다."

생산성 향상도 중요하지만, 그보다 우리가 기술과의 불편한 관계를 회복하고, 더 나은 삶을 사는 것이 궁극적인 목표가 되어야 한다는 것이다. 지난 20년간 기술은 우리를 편리하게 만들었지만, 동시에 우리를 더 불안하고 외롭게 만든 측면도 분명히 있다.

그들의 대화를 통해 어렴풋이 미래의 모습을 상상해본다. 어쩌면 우리는 더 이상 손에 무언가를 들고 다니지 않을지도 모른다. 혹은, 기술이 우리 눈에 보이지 않는 형태로 공기처럼 존재하게 될지도. 어떤 모습이든, 그 기술이 우리를 더 행복하게 만드는 방향으로 나아가기를, 그리고 그 흐름에 나 또한 긍정적인 기여를 할 수 있는 개발자가 되기를 바라본다.

#조니아이브 #샘알트먼 #스마트폰 #AI #미래기술 #애플 #OpenAI #개발자 #생각정리

개발자 눈으로 본 피터 린치의 AI 주식 경고, 단순한 꼰대의 잔소리일까?

worniworni — Sat, 25 Oct 2025 00:00:43 +0900

※ 본 글은 특정 종목에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있습니다. 지극히 개인적인 분석과 의견을 기록한 글입니다.

요즘 IT 업계, 특히 내가 몸담고 있는 개발 씬은 온통 AI 이야기뿐이다. 아침에 눈을 뜨면 새로운 AI 모델 소식이 들려오고, 업무 중에는 AI를 어떻게 활용할지, 동료들과의 커피 타임에서는 어떤 AI 스타트업이 유망한지에 대한 이야기가 빠지지 않는다. 당연히 주식 시장도 마찬가지다. 엔비디아를 필두로 AI 관련 주식들은 하늘 높은 줄 모르고 치솟고, 내 주변에도 소위 'AI 테마주'에 올라타 큰 수익을 봤다는 이야기가 심심치 않게 들려온다.

개발자로서 이 거대한 흐름에 올라타지 않는 것이 바보처럼 느껴질 정도다. 기술의 변화를 누구보다 가까이에서 체감하고 있으니, 이 기술이 바꿀 미래에 투자하는 것은 어쩌면 당연한 일처럼 보였다. 나 역시 포트폴리오의 상당 부분을 기술주, 특히 AI 관련 기업들로 채우고 있었으니까.

그러다 우연히 '월가의 영웅', 전설적인 펀드매니저 피터 린치의 최근 인터뷰 영상을 보게 되었다. 1977년부터 1990년까지 마젤란 펀드를 운용하며 연평균 29.2%라는 경이로운 수익률을 기록한 사람. 그의 투자 철학은 수많은 투자자들에게 교과서처럼 여겨진다. 그런 그가 AI에 대해 어떤 생각을 가지고 있을지 궁금했다. 그리고 그의 대답은 나에게 찬물을 끼얹는 듯했다.

https://www.youtube.com/watch?v=Ay1BJ1fI7WI

"AI 주식? 하나도 없어요."

그는 단호하게 말했다. 자신은 AI 주식을 단 하나도 가지고 있지 않으며, 스스로를 '로루테크 가이(low-tech guy)'라고 칭했다. 심지어 8개월 전까지는 엔비디아(Nvidia)를 제대로 발음하지도 못했다고 고백한다.

개발자인 내 입장에서 처음 든 생각은 '아니, 이 시대의 가장 중요한 기술 혁신을 무시한다고?'였다. 시대에 뒤처진 노장의 고집처럼 느껴지기도 했다. 하지만 그의 말을 곱씹어볼수록 이건 무시가 아니라, 그가 평생을 지켜온 '투자 원칙'의 연장선이라는 것을 깨달을 수 있었다. "자신이 이해하지 못하는 것에는 투자하지 않는다." 는 그의 제1원칙 말이다. 그는 AI 기술 자체를 폄하한 게 아니었다. 그저 자신이 완벽하게 이해하고 가치를 산정할 수 없는 분야에는 발을 들이지 않겠다는, 지독할 정도의 투자 원칙을 고수하고 있을 뿐이었다.

닷컴 버블의 기억을 소환하다

인터뷰어는 현재의 AI 열풍이 1999년의 닷컴 버블과 비슷하지 않냐고 묻는다. 피터 린치는 "나도 모른다(I have no idea)"라며 즉답을 피했지만, 그의 전체적인 논조는 강한 회의론으로 가득 차 있었다.

그는 과거 닷컴 버블 시절, 이름 끝에 '.com'만 붙이면 주가가 폭등했던 시절을 떠올리게 한다. 수많은 인터넷 기업들이 나타났지만, 결국 살아남아 시장을 지배한 기업은 아마존과 같은 극소수에 불과했다. 나머지는 모두 거품과 함께 사라졌다. 지금의 AI 열풍은 어떤가? 수많은 기업들이 너도나도 자사를 'AI 기업'이라 포장하며 투자금을 유치하고 주가를 띄운다. 과연 이들 중 몇이나 진짜배기일까? 그리고 그 진짜배기를 지금 이 가격에 사는 것이 합리적일까?

피터 린치는 화려한 성장주보다는 쓰레기 처리 업체인 '웨이스트 매니지먼트'처럼 아무도 거들떠보지 않는 '지루한' 기업에 투자해 큰돈을 벌었다. 모두가 열광할 때 한발 물러서서 냉정하게 기업의 본질과 수익성을 따져보는 것. 그것이 그의 방식이었다.

새로운 저점 목록(New Low List)에서 보석을 찾다

그의 투자 전략 중 또 하나 인상 깊었던 것은 '신고가(New High List)'가 아닌 '신저가(New Low List)' 목록을 살펴본다는 점이다. 물론 신저가 목록의 대부분은 그럴 만한 이유가 있는 '쓰레기' 주식이지만, 그중에는 시장의 오해와 편견, 또는 일시적인 어려움으로 재능을 폄하받는 보석 같은 기업이 숨어있다는 것이다.

그는 주당 6달러를 잃던 회사가 구조조정과 노력을 통해 손실을 2달러로 줄였을 때를 주목한다. 여전히 적자지만, 4달러만큼 개선된 것이다. 그리고 마침내 흑자 전환에 성공했을 때, 주가는 네 배가 되기도 한다. 시장은 '절대적인 수치'가 아니라 '개선의 방향성'에 열광한다는 것이다.

모두의 관심이 온통 AI와 '매그니피센트 7'에 쏠려있는 지금, 아무도 거들떠보지 않는 산업에서 조용히 턴어라운드를 준비하는 기업은 없을까? 피터 린치의 관점은 나에게 새로운 숙제를 던져주었다.

개발자의 시각, 그리고 투자자의 시각

피터 린치의 인터뷰는 AI 시대에 취해있던 나에게 좋은 예방주사가 되었다. 그의 말이 모두 정답이라고 할 수는 없다. 어쩌면 그는 이번 세기의 가장 큰 기술 혁명의 과실을 놓치고 있는 것일 수도 있다.

하지만 그의 경고는 '기술의 위대함'과 '투자의 위대함'은 별개일 수 있다는 사실을 명확히 알려준다. 개발자로서 나는 누구보다 AI 기술의 잠재력을 잘 이해하고 있다고 자부했다. 하지만 그것이 특정 기업의 주가가 합리적인지 판단하는 능력과 직결되는 것은 아니었다. 오히려 기술에 대한 과도한 낙관이 펀더멘털을 냉정하게 보지 못하게 만드는 '지식의 저주'가 될 수도 있겠다는 생각이 들었다.

결론은, 피터 린치의 조언을 따라 AI를 무조건 외면하자는 것이 아니다. 오히려 개발자로서 가진 기술적 이해도를 바탕으로, 피터 린치와 같은 냉철한 투자자의 잣대를 들이대야 한다는 것이다. 이 기업이 정말 AI 기술로 돈을 벌고 있는가? 비즈니스 모델은 지속 가능한가? 현재 주가는 미래의 이익을 과도하게 당겨온 것은 아닌가?

화려한 파티에 마지막까지 남아있는 것보다, 약간의 아쉬움을 남기고 먼저 자리를 뜨는 것이 현명할 때도 있다. 전설적인 투자자의 쓴소리는, AI라는 거대한 파도 위에서 나만의 중심을 잡게 해주는 등대처럼 느껴진다.

출처: The Compound - How Peter Lynch Became The Greatest Fund Manager Ever
https://www.youtube.com/watch?v=YIlurDigZcY

#피터린치 #AI #AI버블 #주식투자 #가치투자 #기술주 #개발자 #투자이야기 #닷컴버블 #엔비디아

한국 운전면허로 운전 가능한 나라 완벽 정리 - 67개국 운전 가능

worniworni — Fri, 17 Oct 2025 22:25:39 +0900

최근에 해외 여행 계획을 세우다 보니 자동차 렌트를 고려해야 할 상황이 생겼다. 한국 운전면허로 해외에서 바로 운전할 수 있을까? 이건 내가 항상 헷갈리던 부분이었어. 그래서 이번 기회에 정확하게 정리해 봤다.

결론부터 말하면, 한국 운전면허로 67개국, 총 98개 지역에서 운전할 수 있다. 물론 어떤 방식으로 사용하느냐에 따라 사용 가능한 국가가 달라지긴 한다.

한국 운전면허의 두 가지 사용 방법

해외에서 한국 운전면허를 사용하는 방법은 크게 두 가지다.

1. 영문운전면허증 (가장 간편함)

https://www.koroad.or.kr/main/board/6/7472/board_view.do?cp=25&listType=list&bdOpenYn=Y&bdNoticeYn=N

2019년부터 한국에서 발급해 주기 시작한 영문운전면허증이다. 이건 따로 국제운전면허증을 발급받거나 공증을 받을 필요 없다. 그냥 한국에서 받은 영문운전면허증 하나만 들고 가면 된다.

사용 가능 국가: 67개국, 98개 지역 (2024년 1월 기준)

물론 모든 나라가 영문운전면허증을 인정하는 건 아니다. 아직도 국제운전면허증을 요구하는 국가들이 있다. 그래서 여행 전에 꼭 확인해 봐야 한다.

2. 국제운전면허증

전통적인 방식인 국제운전면허증이다. 이건 제네바 협약(1949년)을 기반으로 발급되는 면허증인데, 더 많은 국가에서 인정된다. 특히 유럽 여행을 많이 가는 사람들은 이걸 받는 게 좋다.

한국 도로교통공단이나 시·도경찰청에서 발급받을 수 있으며, 발급에는 보통 3일 정도 걸린다.

영문운전면허증 사용 가능 국가 정리

이제 본격적으로 사용 가능한 국가들을 정리해 봤다. 지역별로 나누어 봤으니 필요한 부분만 확인하면 된다.

아시아 지역 (5개국)

동티모르
몰디브
부탄
필리핀
홍콩

아시아 국가 중에서는 필리핀, 몰디브가 인기 있는 여행지다. 특히 필리핀은 요즘 가성비 좋은 여행지로 유명해서 많은 사람들이 방문한다. 홍콩도 가깝고 재미있는 도시라서 자동차 렌트를 하는 사람들이 많다.

오세아니아 지역

오세아니아 지역에는 호주, 뉴질랜드를 비롯한 태평양 도서국들이 포함되어 있다. 호주와 뉴질랜드는 특히 드라이브 여행으로 유명한 나라들이다. 호주의 대자연을 자동차로 누리는 여행, 뉴질랜드의 구불구불한 도로를 달리는 경험은 정말 인상적이다. 피지, 팔라우, 사모아 같은 태평양 도서국들도 포함되어 있으니 남태평양 여행을 계획 중이라면 참고하면 좋다.

유럽 지역 (20개국)

그리스
네덜란드
덴마크
라트비아
룩셈부르크
리히텐슈타인
몬테네그로
벨기에
보스니아-헤르체고비나
사이프러스
스위스
스웨덴
슬로바키아
아일랜드
에스토니아
영국
크로아티아
튀르키예
포르투갈
핀란드

유럽은 꽤 많은 국가들이 포함되어 있다. 내가 여행 계획을 짤 때 가장 관심 있는 지역이 바로 유럽인데, 이렇게 많은 국가에서 인정받으니 정말 좋다. 특히 포르투갈, 스위스, 그리스, 크로아티아, 튀르키예 같은 인기 여행지들이 모두 포함되어 있어서 행복하다.

아메리카 지역 (17개국/48개 지역)

미국: 알라바마, 플로리다, 아이다호, 아이오와, 메릴랜드, 매사추세츠, 미시간, 오리건, 텍사스, 버지니아, 워싱턴, 웨스트버지니아, 콜로라도, 조지아
캐나다: 11개 주
멕시코: 6개 주
괌
니카라과
도미니카공화국
바하마
벨리즈
북마리아나연방
앤티가바부다
엘살바도르
우루과이
코스타리카
쿠바
트리니다드토바고
파나마
페루

미국은 특정 주(state)에서만 인정한다는 게 흥미롭다. 그래서 미국 여행을 계획할 때는 꼭 어느 주로 가는지 확인해 봐야 한다. 캐나다도 마찬가지다. 이건 각 주의 교통 담당부서에서 정책을 다르게 가져가기 때문이다.

중동 지역 (4개국)

레바논
바레인
사우디아라비아
아랍에미리트

중동 여행을 가는 사람들이 중동 지역에서도 한국 운전면허로 운전할 수 있다는 건 알아두면 유용할 것 같다.

아프리카 지역 (8개국)

르완다
말리
모리셔스
부룬디
세네갈
세이셸
알제리
튀니지

아프리카 지역도 8개국이 포함되어 있다. 모리셔스는 인도양의 아름다운 휴양지로 유명하고, 세이셸도 신혼부부들이 자주 가는 명소다. 북아프리카의 튀니지나 알제리, 서부 아프리카의 세네갈도 매력적인 여행지들이다.

국제운전면허증이 필요한 경우

위에 나열된 67개국 외에 다른 나라로 운전 여행을 갈 때는 국제운전면허증을 발급받아야 한다. 특히 유럽의 일부 국가들도 국제운전면허증을 선호하기도 한다.

국제운전면허증은 다음 장소에서 발급받을 수 있다:

한국도로교통공단
시·도경찰청
발급 시간: 보통 3일 소요
유효기간: 3년

꼭 확인해야 할 주의사항

아무리 한국 운전면허를 가지고 있어도, 다음 사항들을 반드시 체크해 봐야 한다.

1. 국제운전면허 관련 협약

한국은 1949년 제네바 협약에 가입한 국가다. 그래서 제네바 협약국들에서는 한국 국제운전면허증을 인정한다. 다만 1968년 비엔나 협약국들 중 일부는 한국이 그 협약에 미가입되어 있어서 추가 서류를 요구할 수 있다.

2. 렌트카 회사의 추가 요구사항

나라마다 렌트카 회사들의 정책이 다르다. 한국 운전면허만으로는 렌트를 안 해 주는 회사도 있고, 추가 보험을 요구하는 곳도 있다. 반드시 예약 전에 확인해 봐야 한다.

3. 여행 보험과 자동차 보험

국제운전면허로 운전할 때는 반드시 충분한 자동차 보험에 가입해야 한다. 사고가 났을 때 보험 없이는 큰 낭패를 볼 수 있다.

4. 현지 도로 규칙

국가마다 교통법이 다르다는 걸 잊지 말자. 한국에서는 합법인데 그 나라에서는 불법일 수 있다. 유럽은 거의 모든 나라가 우측통행이지만, 영국, 아일랜드, 키프로스 등은 좌측통행이다. 꼭 미리 확인하고 가자.

5. 국제운전면허증의 영문 번역

영문운전면허증만으로 부족할 때도 있다. 이럴 땐 한국 운전면허증의 영문 공증본을 준비하는 것도 도움이 될 수 있다.

여행할 나라가 목록에 없다면?

위에 나열된 국가가 아니라면? 그럼 국제운전면허증이 필수다. 하지만 국제운전면허증도 만능은 아니다. 국가에 따라 자국민의 운전면허증만 인정하는 경우도 있으니까 정말로 여행 전에 여행사나 해당 국가의 대사관에 문의해 봐야 한다.

특히 중국, 태국, 베트남 같은 동남아 국가들은 한국 운전면허나 국제운전면허로도 운전이 불가능한 경우가 많다. 이런 나라들은 현지 운전면허를 따로 취득하거나, 렌트카를 이용할 때 기사를 고용해야 한다.

실제 여행 경험에서 배운 팁

내 친구들이 해외 자동차 렌트를 여러 번 해 봤는데, 공통으로 조언해 주는 게 있다.

첫째, 최소 2주 전에 예약하고 렌트카 회사에 한국 운전면허로 가능한지 확인하자. 전화로 직접 물어보는 게 제일 확실하다.

둘째, 국제운전면허증은 미리 준비하자. 여행 가기 일주일 전에 준비한다고 해도 시간이 충분할 수 있지만, 혹시 모르니 미리 하는 게 좋다.

셋째, 영문운전면허증을 받았다면 원본을 들고 가되, 복사본도 여러 장 챙기자. 혹시 잃어버릴 수도 있으니까.

넷째, 해외 자동차 보험은 절대 아끼지 말자. 사고났을 때 보험 없는 것만큼 후회스러운 일이 없다.

※ 중요한 고지사항

본 글의 내용은 2024년 1월 기준 외교부 및 한국도로교통공단의 공식 자료를 참고하여 작성되었습니다. 하지만 각 국가의 정책은 수시로 변경될 수 있으며, 출처마다 집계 기준이 다를 수 있어서 국가 수가 달라질 수 있습니다. 무엇보다 정보는 계속 업데이트되고 있으니 가장 최신 자료를 꼭 확인해야 합니다.

꼭 여행 전에 아래 공식 사이트에서 최신 정보를 확인하시기 바랍니다:

외교부 해외안전여행: https://overseas.mofa.go.kr
한국도로교통공단: https://www.safedriving.or.kr
한국도로교통공단 국제운전면허증 안내: https://www.koroad.or.kr

또한, 개별 국가의 렌트카 회사나 대사관에 직접 문의하여 최신 규정을 확인하시길 강력히 권장드립니다.

해시태그

#한국운전면허 #국제운전면허 #해외운전 #영문운전면허증 #해외여행자동차렌트 #여행준비 #운전면허 #해외운전가능국가 #여행팁 #운전안전

미국 증시 또 폭락했다 - 중국 희토류 전쟁과 매그7 1100조 증발 (2025년 10월)

worniworni — Mon, 13 Oct 2025 21:41:29 +0900

※ 본 글은 특정 종목에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있다. 지극히 개인적인 분석과 의견을 기록한 글이다.

또 터졌다. 진짜 며칠 전 일이다.

10월 10일, 미국 증시가 또 다시 폭락했다. 나스닥 3.56% 하락, S&P 500 2.71% 하락. 매그니피센트7의 시가총액이 하루만에 1,129조원이 증발했다.

올해만 벌써 몇번째야. 1월에도 한번 크게 떨어지고, 4월에는 진짜 지옥을 봤는데, 또 이러네.

나도 미국 주식 하는 사람으로서 이번 폭락 원인을 제대로 정리해야겠다 싶었다. 계좌 보면서 한숨만 쉬지 말고.

올해 여기까지 어떻게 왔나

일단 간단히 정리하면:

1월 말: 중국 딥시크(DeepSeek) 쇼크로 엔비디아 847조 증발. "저렴한 AI칩으로도 ChatGPT급 만들수있다"는 소식에 반도체주 폭락.

4월 초: 트럼프의 "해방의 날" 관세 폭탄. 전세계에 10% 기본관세, 한국 26%. 나스닥 1,600포인트 하락. 미국 증시 전체에서 5조 달러 증발.

4월 폭락 이후 조금씩 회복하고있었는데... 10월에 또 터졌다.

10월 9일 - 중국의 희토류 카드

10월 9일, 중국 상무부가 폭탄선언을 했다.

희토류 수출 통제를 대폭 강화하는 "0.1% 룰"을 도입한다고.

0.1% 룰이 뭐냐면

중국산 희토류 원료가 0.1% 이상 포함되거나 중국 기술을 사용한 전략광물 제품은, 해외에서 제조되더라도 수출 허가를 받아야 한다.

이게 얼마나 충격적이냐면, 사실상 역외통제다. 미국이 그동안 써먹던 FDPR(외국인직접생산규칙)을 중국이 똑같이 적용한거다.

예를 들어 한국 반도체 공장에서 칩을 만드는데, 거기 들어간 희토류가 중국산이 0.1%라도 포함됐으면 중국 허가 받아야 한다는 얘기다. 사실상 중국이 글로벌 반도체 공급망을 통제할 수있다는거다.

더 나아가서 이런 것들은 개별 심사한다고 발표했다:

14나노 이하 로직칩 제조·테스트 장비용 희토류
256단 이상 메모리칩 관련 희토류
군사용 가능성이 있는 AI 연구개발용 희토류

CSIS(전략국제문제연구소)의 그레이슬린 바스케란 국장은 "미국 국방 부문에 대해 중국이 취한 가장 중요한 조치"라고까지 말했다.

(출처: https://www.g-enews.com/article/Global-Biz/2025/10/2025101110321956160c8c1c064d_1)

희토류가 왜 중요한가

희토류는 반도체 제조에 필수적인 원료다. 그리고 중국이 전세계 희토류 생산의 대부분을 장악하고있다.

미국도 희토류 광산이 있긴 한데 (MP Materials), 경제성이 없다. 결국 중국 의존도가 높을수밖에 없다.

중국이 희토류 수출을 막으면 미국 반도체 기업들은 생산에 차질이 생긴다. 특히 AI칩 만드는 엔비디아 같은 회사는 직격탄을 맞는거다.

10월 10일 - 트럼프의 즉각 반격

중국의 희토류 통제 발표 다음날인 10월 10일, 트럼프가 반격했다.

"중국산 제품에 최대 100% 관세 부과 검토"

중국의 희토류 수출 통제 조치에 반발해서 관세 카드를 또 꺼내든거다. 100% 관세면 중국산 제품 가격이 2배가 된다는 얘기다.

애플은 중국 공장에서 아이폰 만드는데, 100% 관세면 아이폰 가격 2배. 테슬라도 중국 공장 있고. 빅테크들이 다 타격받을수밖에 없다.

10일 증시 반응 - 대학살

10일 뉴욕증시는 그야말로 피바다가 됐다.

주요 지수 하락폭

S&P 500: 2.71% 하락 → 6,552.51
나스닥: 3.56% 하락 → 22,204.43
필라델피아 반도체지수: 6.32% 급락

개별 종목

엔비디아: 4.89% 하락
테슬라: 15.4% 급락 (2024년 10월 이후 최저치)

테슬라는 하루만에 15% 넘게 떨어졌다. 진짜 충격적이었다.

매그니피센트7 시총 증발

특히 충격적인건 매그니피센트7(애플·아마존·알파벳·메타·마이크로소프트·엔비디아·테슬라)의 시가총액이 하루만에 7,740억달러 (약 1,129조원) 증발했다는거다.

엔비디아만 봐도:

10월 7일: 시총 2조 7,500억달러
10월 10일: 시총 2조 6,080억달러
하루 손실: 1,420억달러

올해 1월 6일 최고점(3조 6,600억달러)과 비교하면 1조달러가 증발한거다. 10개월만에 시총의 27%가 사라졌다.

(출처: https://edaily.co.kr/News/Read?mediaCodeNo=257&newsId=02581366642102336)

왜 이렇게 폭락했나

1. 공급망 차질 우려

희토류는 반도체 제조의 필수 원료인데, 중국이 통제하면 미국 반도체 기업들은 생산이 막힌다. 특히 AI칩 수요가 폭발적으로 늘고있는 상황에서 공급망이 막히면 큰일이다.

2. 무역전쟁 2라운드 공포

"이거 또 4월처럼 무역전쟁 2라운드 시작하는거 아냐?" 하는 공포가 시장에 퍼졌다.

4월에 관세 폭탄 맞고 증시가 얼마나 떨어졌는지 다들 기억한다. 그게 또 반복될까봐 투자자들이 패닉에 빠진거다.

3. 빅테크 중국 의존도

애플, 테슬라를 비롯한 빅테크들이 중국 공장 의존도가 높다. 관세든 희토류든, 미중 갈등이 심해지면 빅테크가 제일 먼저 타격받는다.

나도 이틀간 계좌 보면서 진짜 멘탈 나갔다. 4월에 회복했던게 또 날아갔으니까.

미국의 대응

미국도 가만히 있진 않는다.

파이낸셜타임스 보도에 따르면 트럼프 행정부가 태평양 해저 광물을 비축하는 행정명령 초안을 작성중이라고 한다. 중국의 희토류 지배력에 대응하려는거다.

미국 국방부는 6월에 MP Materials(미국 유일의 희토류 광산 회사) 우선주 15%를 4억달러에 매입했다. 사실상 정부가 희토류 기업을 지원하는거다.

근데 문제는 경제성이다. 중국 희토류가 워낙 싸고 품질도 좋아서, 미국산으로 대체하기엔 비용이 너무 많이 든다.

(출처: https://www.g-enews.com/article/Global-Biz/2025/10/2025101110321956160c8c1c064d_1)

향후 전망 - APEC 회담이 변수

다만 이번에는 4월처럼 막 패닉은 아니었다.

10월 말 경주 APEC 정상회담이 예정돼있고, 트럼프-시진핑 정상회담도 잡혀있다. 양국이 극단적인 대립으로 치닫기보단 협상 테이블로 갈거라는 기대감이 있다.

중국도 희토류 카드를 꺼낸게 협상력을 높이려는 전략이라는 분석이 많다. 진짜 수출을 막으려는건 아니고, 트럼프 만나기 전에 카드를 하나 더 쥐려는거라는 얘기지.

협상이 잘되면 시장이 반등할거고, 결렬되면 또 폭락할거다.

그래도 불안한건 사실이다. 협상이 잘못되면 또 폭락할수있으니까.

(출처: https://biz.heraldcorp.com/article/10591917)

개인 투자자는 어떻게 해야 할까

나도 올해 롤러코스터 세번째 타면서 느낀게 많다.

1. 패닉셀 하지 말자

1월 딥시크 쇼크 때 엔비디아 판 사람들, 지금 후회하고 있을거다. 실제로 장기적 영향은 제한적이었으니까.

시장이 과잉반응 할 때 같이 패닉에 빠지면 손해본다. 냉정하게 판단해야한다.

2. 정치 리스크를 간과하지 말자

올해 증시 보면 기술적 분석이나 실적보다 정치가 더 중요했다.

트럼프 한마디, 중국 정부 발표 하나에 증시가 요동친다. 뉴스를 정말 열심히 봐야한다.

특히 미중 관계는 계속 주목해야한다. 10월 말 APEC 회담 결과에 따라 11월 증시가 결정될거같다.

3. 분산투자는 기본

빅테크만 들고있으면 위험하다. 올해처럼 정치 리스크로 특정 섹터가 집중타격 받을수있다.

나도 반도체주 비중 좀 줄이고, 방산주나 에너지주 같은걸로 좀 분산했다.

4. 현금 비중 확보

변동성이 큰 시장에서는 현금을 좀 들고있는게 유리하다.

폭락할 때 추가 매수할 여력이 있으면 기회가 될수있다. 나도 10월 하락때 일부 물탔는데, 이게 잘될지는 모르겠다.

5. 장기 관점은 유지하되, 손절은 과감하게

좋은 기업은 결국 회복한다고 믿는다. 엔비디아도 두번 큰 하락이 있었지만, AI 수요는 여전하다.

근데 상황이 바뀌면 손절도 과감하게 해야한다. 고집부리다가 더 큰 손해보는것보단 낫다.

결론: 미중 패권 전쟁의 희생양

올해 미국 증시를 한마디로 정리하면 미중 패권 전쟁의 희생양이다.

1월: 중국 AI 기술 부상 (딥시크)
4월: 트럼프 관세 폭탄
10월: 중국 희토류 통제 vs 트럼프 100% 관세

전부 미국과 중국의 패권 다툼이다.

문제는 이게 단기간에 끝날게 아니라는거다. 희토류, 반도체, AI, 5G... 앞으로도 계속 충돌할 분야가 산더미다.

개인 투자자로서 할수있는건:

뉴스 열심히 보기 (특히 미중 관계)
정치 리스크 항상 염두에 두기
분산투자로 리스크 줄이기
현금 확보해서 기회 잡기
냉정하게 판단하기

특히 10월 말 경주 APEC 정상회담은 꼭 주목해야한다. 여기서 어떤 결과가 나오느냐에 따라 11월 증시가 결정될거다.

협상이 잘되면 반등, 결렬되면 또 폭락. 간단하다.

올해 미국 증시 보면서 느낀건, 시장은 항상 예측 불가능하다는거다. 엔비디아가 하늘을 찌를줄 알았는데 올해만 세번 큰 하락이 있었다.

그래도 포기할순 없다. 공부하고, 분석하고, 신중하게 투자하면 기회는 있다고 믿는다.

다들 건투를 빈다. 미중 패권 전쟁 속에서 살아남자.

참고 자료

중국 희토류 수출 통제 강화 (글로벌이코노믹): https://www.g-enews.com/article/Global-Biz/2025/10/2025101110321956160c8c1c064d_1
매그니피센트7, 시총 1129조원 증발 (이데일리): https://edaily.co.kr/News/Read?mediaCodeNo=257&newsId=02581366642102336
해방의 날 이후 미중 관세 충돌 재점화 (헤럴드경제): https://biz.heraldcorp.com/article/10591917
중국 희토류 역외통제 및 퀄컴 반독점 조사 (다음뉴스): https://v.daum.net/v/20251011151800608
중국 0.1% 룰 도입, USA 레어 어스 주가 급등 (테크42): https://tech42.co.kr/중국-0-1-룰-도입으로-희토류-역외통제-강화-usa-레어-어

#미국증시 #나스닥 #주식폭락 #희토류전쟁 #매그니피센트7 #트럼프관세 #중국무역전쟁 #엔비디아 #개인투자자 #미국주식 #S&P500 #반도체주 #투자전략 #주식시장 #재테크 #APEC정상회담

GPT-5 드디어 써봤다 - OpenAI DevDay 2025 총정리

worniworni — Mon, 13 Oct 2025 21:24:10 +0900

요즘 바이브코딩 하다가 뭔가 이상한걸 느꼈다. 코드가 이전보다 훨씬 정확해졌달까? 알고보니 GPT-5가 나온지 벌써 몇달이 지났더라. 8월 7일에 출시됐다는데 완전 모르고 지나쳤네.

그래서 최근에 OpenAI에서 뭘 발표했나 찾아봤는데, 와 진짜... 이건 좀 정리를 안할 수가 없더라. DevDay 2025(10월 6일)에서 발표한 내용들이 개발자 입장에서 너무 미쳤다.

GPT-5, 이거 진짜 장난 아니다

일단 GPT-5부터 얘기해야겠다. GPT-4가 나온지 2년만에 나온 신작인데, 성능이 정말 압도적이다.

벤치마크 점수 보고 놀랐다

수학 문제 푸는 AIME 2025에서 94.6% 찍었고, 소프트웨어 엔지니어링 능력 측정하는 SWE-bench에서는 74.9%를 기록했다. 이게 얼마나 높은 건지 모를 수도 있는데, 예전 모델들이랑 비교하면 진짜 체감이 크다.

그리고 LM아레나라고 사용자들이 직접 평가하는 벤치마크가 있는데 거기서 1481점으로 1위 했다. 2위인 제미나이 2.5 프로보다 21점이나 앞섰다고. (출처: https://zdnet.co.kr/view/?no=20250808084540)

내가 실제로 써보니까 뭔가 답변이 이전보다 훨씬더 정확해졌다. 특히 코딩할때 확실히 느껴진다.

환각현상이 80% 줄었다니

GPT 쓰다보면 가끔 없는 라이브러리 추천해준다던가, 존재하지않는 함수 알려주는 경우 있었잖아? 그런 환각현상이 이전 모델 대비 최대 80%나 줄었다고 한다.

실제로 써보니 이전엔 API 문서 여러번 크로스체크 하면서 코딩했는데, 이제는 GPT-5가 알려준거 그대로 써도 거의 동작한다. 이정도면 진짜 사람 옆에서 페어프로그래밍 하는 느낌이랄까.

한방에 웹사이트 만들어준다

오픈AI가 GPT-5를 가장 강력한 코딩모델이라고 홍보하던데, 과장이 아니더라. 단 하나의 프롬프트로 반응형 웹사이트, 앱, 게임까지 만들 수 있다고 한다.

예전에는 "회원가입 페이지 만들어줘" 하면 기본 틀만 나왔는데, 지금은 정말로 바로 쓸수있는 수준으로 나온다. CSS도 깔끔하고 반응형도 다 되어있고. 물론 실제 프로덕션에 쓰려면 손 좀 봐야하지만, 초안 만드는 시간이 몇시간에서 몇분으로 줄었다.

(출처: https://openai.com/index/introducing-gpt-5/)

AgentKit - 드디어 에이전트를 쉽게 만든다

DevDay 2025에서 가장 기대되는게 이거다. AgentKit.

AI 에이전트 만들기 쉽지 않았잖아? 프롬프트 엔지니어링하고, 툴 연결하고, 로직 짜고... 근데 OpenAI가 이걸 완전 쉽게 만들어줬다.

Agent Builder - 드래그앤드롭으로 끝

비주얼 캔버스에서 드래그앤드롭으로 에이전트 로직을 짤 수 있다. 노드 연결하고, 툴 붙이고, 가드레일(안전장치) 설정하는게 다 GUI로 가능하다.

미리보기 실행도 되고, 버전관리도 된다고. 이거 진짜 게임체인저다. 예전엔 코드로 다 짜야했는데 이제는 마치 플로우차트 그리듯이 에이전트를 만들 수있다.

내 앱에 챗봇 박기

ChatKit이라는게 있는데, 임베드 가능한 챗 인터페이스다. 내 앱에 쉽게 넣을수있다는 얘기. 예전에 챗봇 UI 만들려면 프론트엔드 작업이 꽤 컸는데, 이제는 그냥 가져다 쓰면 된다.

Evals - 성능측정도 자동으로

에이전트 만들고나면 성능이 어떤지 알아야 하잖아? Evals 기능이 step-by-step으로 에이전트 의사결정 과정을 분석해준다.

어느 부분에서 판단을 잘못했는지, 어떤 프롬프트가 효과적인지 자동으로 최적화도 해준다고. 개발할때 A/B 테스트 하듯이 에이전트도 테스트할 수있다.

(출처: https://openai.com/index/introducing-agentkit/)

GPT-5 Pro - 전문가용

일반 GPT-5도 미쳤는데, GPT-5 Pro라는게 또 있다. API로 출시됐고 금융, 법률, 의료같은 어려운 작업에 최적화 되어있다고 한다.

심층적인 추론이 필요한 작업에 특화됐다는데, 프로 구독자는 무제한으로 쓸 수있다. 나도 프로 구독하는데 확실히 복잡한 로직 짤때는 Pro 모델이 훨씬 낫다.

ChatGPT에서 앱 바로 쓰기

이건 진짜 신기했다. 이제 ChatGPT 안에서 Spotify, Zillow같은 서비스를 바로 쓸 수있다.

"스포티파이에서 운동할때 듣는 플레이리스트 만들어줘" 하면 로그인하고 바로 플레이리스트가 만들어진다. 앱을 나갈 필요가 없다.

Booking.com, Canva, Coursera, Figma, Expedia같은 앱들이 첫 출시 대상이고, 올해 안에 11개 앱이 더 추가된다고 한다. 이거 잘되면 ChatGPT가 진짜 모든 앱의 허브 역할을 하는거 아닌가?

(출처: https://news.hada.io/topic?id=23496)

GPT-Realtime-Mini - 저렴하고 빠르다

실시간 음성 대화가 필요한 경우에 쓰는 경량화 모델이다. 70% 더 저렴하면서도 품질은 동일하다고.

고객센터 챗봇이나 음성 비서 만들때 좋을것같다. 가격이 저렴해지니까 이제 작은 스타트업에서도 음성 AI 서비스를 쉽게 만들수있겠다.

Sora2 - 비디오 생성 API

Sora2가 API로 출시됐다. 영상을 AI로 만드는건데, 이제 개발자들이 직접 서비스에 통합할 수있다는 얘기다.

아직 많이 써보진 못했는데, 마케팅 자동화나 교육용 콘텐츠 제작에 활용도가 높을것같다.

NVIDIA 파트너십

OpenAI와 NVIDIA가 전략적 파트너십을 발표했다. 최소 10기가와트의 NVIDIA 시스템을 배포한다고 하는데, NVIDIA가 최대 1000억 달러를 투자한다고 한다.

이건 개발자한테 직접적인 영향은 없지만, 앞으로 OpenAI 모델이 더빨라지고 더 많은 사용자를 처리할수있게된다는 의미다. 인프라가 탄탄해지니까 서비스 안정성도 좋아지겠지.

(출처: https://openai.com/index/openai-nvidia-systems-partnership/)

실제로 써보니

일주일정도 GPT-5랑 AgentKit 써봤는데, 진짜 개발 속도가 달라졌다.

예전에는 보일러플레이트 코드 짜고, API 문서 찾아보고, 디버깅하는데 시간이 오래걸렸는데 지금은 GPT-5한테 물어보면 거의 바로 답이 나온다.

특히 새로운 라이브러리 배울때 좋다. "이 라이브러리로 OAuth 인증 구현해줘" 하면 예제 코드가 바로 나온다. 그것도 동작하는 코드로.

AgentKit은 아직 베타라서 일부기능만 써봤는데, Agent Builder가 정말 직관적이다. 코드 전혀 안짜고도 꽤 복잡한 로직의 에이전트를 만들었다.

무료로도 쓸 수있다

GPT-5가 대단한게, 무료 사용자도 쓸수있다는거다. 물론 사용량 제한은있지만, 일반적인 용도로는 충분하다.

플러스 구독자는 사용량이 더 많고, 프로구독자는 GPT-5 Pro를 무제한으로 쓸수있다. 난 프로 쓰는데 한달에 $20인데 이정도 가성비면 진짜 혜자다.

개발자들 반응은?

GeekNews에서 반응 좀 봤는데, 대체로 긍정적이더라. 특히 AgentKit에 대한 기대가 크다.

"드디어 에이전트를 프로덕션에 올릴 수있겠다"는 반응이 많았다. 예전엔 에이전트가 불안정해서 실제 서비스에 쓰기 어려웠는데, 이제는 도구도 많아지고 평가 시스템도 생겨서 안심하고 쓸수있을것같다.

(출처: https://news.hada.io/topic?id=23512)

앞으로가 기대된다

OpenAI가 ChatGPT를 단순한 챗봇이 아니라 플랫폼으로 만들려는게 확실히 보인다.

앱 통합 기능이 확대되고, 에이전트 만들기가 쉬워지면 ChatGPT가 정말 운영체제처럼 될수도 있겠다는 생각이 든다. "ChatGPT야, 출장 준비해줘" 하면 항공권 예약하고, 호텔 잡고, 일정 정리하고, 필요한 문서까지 준비해주는 그런날이 올지도.

개발자 입장에서는 이제 AI를 더 적극적으로 활용해야겠다는 생각이 든다. 단순히 코드 작성 도우미가 아니라, 실제로 비즈니스 로직을 처리하는 에이전트를 만들수있는 시대가 왔으니까.

다들 GPT-5 써봤으면 좋겠다. 확실히 체감된다. 특히 바이브코딩하는 사람들은 무조건 써봐야 한다. 개발 플로우 자체가 바뀐다.

참고 자료

OpenAI GPT-5 공식 발표: https://openai.com/index/introducing-gpt-5/
OpenAI AgentKit 소개: https://openai.com/index/introducing-agentkit/
OpenAI DevDay 2025 정리 (GeekNews): https://news.hada.io/topic?id=23496
GPT-5 성능 분석 (ZDNet): https://zdnet.co.kr/view/?no=20250808084540
OpenAI-NVIDIA 파트너십: https://openai.com/index/openai-nvidia-systems-partnership/

#GPT5 #OpenAI #DevDay2025 #AgentKit #AI개발 #바이브코딩 #ChatGPT #개발자 #코딩 #인공지능 #머신러닝 #프로그래밍 #소프트웨어개발 #기술블로그

원달러 환율 1,500원 돌파할까? 2025년 환율 전망과 상승 원인 분석

worniworni — Fri, 10 Oct 2025 02:59:22 +0900

※ 본 글은 특정 투자 상품에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있다. 지극히 개인적인 분석과 의견을 기록한 글이다.

요즘 환율 보는게 일상이 되버렸다. 해외직구도 자주하고 여행도 좋아하는데, 달러 환율이 정말 부담스러울 정도로 올랐다.

오늘도 출근하면서 증권 앱을 켰는데 원달러 환율이 1,410원을 넘어서고있더라. 작년만 해도 1,300원대 초중반이었던게 엊그제 같은데 벌써 이렇게 올랐다니.. 진짜 언제까지 오르는건지 궁금해서 이것저것 찾아봤다.

현재 원달러 환율은?

2025년 10월 기준으로 원달러 환율은 1,410~1,416원 사이에서 움직이고 있다. 10월 6일 기준으로는 1,410.92원을 기록했는데, 전 거래일 대비 0.24% 오른 수치다.

52주 최고가는 1,488.32원, 최저가는 1,338.82원이었다고 한다. 지난 한달만 봐도 원화가 1.85%나 약세를 보였고, 1년으로 넓혀보면 5.03%나 떨어졌다.

개인적으로 환율이 1,300원대 초반일때 달러를 좀 환전해놨어야 했는데 하는 후회가 밀려온다. 그때는 이렇게까지 오를줄 몰랐거든.

왜 이렇게 환율이 오르는걸까?

찾아보니까 환율이 오르는 이유가 몇가지있더라. 하나씩 정리해봤다.

1. 트럼프 정부의 보호무역 정책

제일 큰 이유가 이거다. 트럼프가 다시 대통령이 되면서 보호무역 정책을 강화하고 고관세를 부과하니까 글로벌 무역 환경이 엄청 불안해졌다.

이미 2025년 상반기에 환율이 1,470원을 돌파하기도 했는데, 그때가 트럼프 정부의 정책 발표 직후였다고 한다. 우리나라는 수출 의존도가 높은 경제 구조라서 이런 보호무역 정책이 특히 더 악영향을 미치는것 같다.

2. 국내 정치 불안정

작년 12월에 있었던 비상계엄 선포와 대통령 탄핵 소추도 영향을 미쳤다. 45년만에 비상계엄이 선포되고, 8년만에 현직 대통령이 탄핵되는 초유의사태가 벌어지니까 외국인 투자자들이 한국 시장에서 돈을 빼기 시작한거다.

정치가 불안하면 당연히 경제도 불안해지고, 그러면 원화 가치가 떨어지는게 당연하다. 개발자로 일하면서도 회사 분위기가 이런 정치 이슈로 많이 흔들렸던 기억이난다.

3. 한미 금리차 확대

이것도 중요한 요인이다. 미국은 여전히 높은금리를 유지하고있는데 한국은 금리를 낮추고있으니까 금리차가 벌어진다.

금리가 높은곳으로 돈이 몰리는게 당연하잖아? 그래서 달러 수요가 늘어나고 원화는 약세를 보이는거다. 특히 시장금리 차이가 환율에 직접적인 영향을미친다고 한다.

4. 미국의 금리 정책

트럼프 정부의 고관세 정책 때문에 수입 물가가 오르고있어서 미국 연준(Fed)이 쉽게 금리를 내리지 못하는 상황이다.

원래는 올해 금리 인하가 예상됐는데, 인플레이션 우려 때문에 금리 인하 시점이계속 미뤄지고있다. 금리가 높게 유지되면 달러 강세가 이어질수 밖에없고, 그러면 원화는 계속 약세를 보이는거다.

5. 구조적 상승 압력

2022년부터 시작된 미국의 긴축 정책과 글로벌 불안정성이 구조적으로 환율 상승 압력으로 작용하고있다.

코로나 이후 풀린 유동성을 회수하면서 달러 가치가 올라갔고, 거기에 우크라이나 전쟁, 중동 정세불안 등 지정학적 리스크까지 더해지면서 안전자산인 달러에대한 수요가 계속 늘어나고있는 상황이다.

그래서 환율 어디까지 오를까?

제일 궁금한게 이거다. 환율이 대체 어디까지 오르는건지. 전문가들 의견을 찾아봤다.

단기 전망 (2025년 하반기)

하나은행 쪽 전망을 보니까 트럼프 정부의 정책 불확실성과 국내 정치 혼란이 겹치면서 환율이 1,490원까지 상승할수 있고, 단기적으로는 1,500원을 돌파할 가능성도 있다고 한다.

실제로 전문가들도 2025년 하반기에 1,500원을 넘을 수있다는 의견이 많더라. 생각만 해도 아찔하다. 1,500원이면 해외직구나 여행 경비가 정말 부담스러워질텐데.

중기 전망

IBK투자증권의 정용택 수석연구원은 조금 다른 의견을 냈다.

그는 현재 환율이 국내 정치 불안과 트럼프 재집권에 대한 불안감이 과도하게 반영되어있다고 봤다. 트럼프 정부가 본격적으로 시작되고 불확실성이 줄어들면 환율이 안정세를 보이면서 1,300원대 중반으로 돌아갈거라는 전망이다.

개인적으로는 이 시나리오가 현실이 됐으면 좋겠다. 1,500원은 정말 너무 부담스럽거든.

장기 구조적 분석

장기적으로 보면 원달러 환율은 금리 사이클 변동에 따라 움직이면서 구조적인 상승 압력을 받고있다고한다.

2025년 하반기가 금리 인하 국면의 환율 피크에 가까워질것으로 보인다는 분석도있다. 즉, 지금이 정점에 가까울수도 있다는 얘기다.

환율 상승, 어떻게 대응해야할까?

개발자로 일하면서 주식이랑 부동산에도 관심이 많은 편인데, 환율이 이렇게 오르니까 걱정이 앞선다.

달러 자산 보유

환율이 더 오를거같으면 달러 자산을 일부 보유하는것도 방법이다. 달러 예금이나 미국주식, 달러 ETF같은걸 활용하면 환차익도 노릴수있다.

나도 최근에 미국 주식 비중을좀 늘렸는데, 배당주 위주로 담고있다. S&P500 ETF도 조금씩 모으는중이다.

해외 결제는 신중하게

해외 직구나 해외 구독 서비스 결제할때 환율을 꼭 확인하는 습관을들이자. 환율이 높을때는 굳이 급하지않은 구매는 미루는것도 방법이다.

최근에 맥북 악세사리 하나 사려고 아마존 들어갔다가 환율 보고 바로나왔다. 지금은 아닌것같아서.

여행 계획도 재조정

올해 여행 계획이 있다면 환율을 고려해서 예산을 다시 짜봐야할것 같다. 동남아 같은 상대적으로 물가가 저렴한곳을 고려하거나, 국내 여행으로 방향을 바꾸는것도 좋을것 같다.

작년에 베트남 호이안 갔을때가 환율이 지금보다 훨씬 좋았는데, 그때 더 여행 다녀놓을걸 그랬나보다.

마무리하며

환율이 1,410원을 넘어선 지금, 1,500원 돌파가 현실이 될수도있다는게 실감이난다. 트럼프 정부의 보호무역 정책, 국내 정치 불안, 한미 금리차 확대 등 여러 요인이 복합적으로 작용하고있다.

전문가들 의견도 엇갈리긴하지만, 단기적으로는 더 오를 가능성이 높아보인다. 다만 불확실성이 해소되면 다시 안정세를 찾을수도있다는 전망도있으니, 너무 불안해하기 보다는 냉정하게 상황을 지켜보고 대응하는게 중요할것같다.

개인적으로는 달러 자산을 일부 보유하면서 리스크를 관리하는 전략을 가져갈 생각이다. 환율이 높을땐 불필요한 해외 소비를 줄이고, 국내 투자 기회도 찾아보려고한다.

환율이 빨리 안정되길 바라면서, 여러분도 각자의 상황에맞는 대응 전략을 세우시길 바란다.

#원달러환율 #환율전망 #달러환율 #환율1500원 #환율상승 #재테크 #달러투자 #해외직구 #환율분석 #트럼프관세 #금리차 #2025환율 #달러예금 #환차익 #투자전략

분당 무지개마을 3단지 신한 건영 임장 후기 - 오리역 제4테크노밸리 호재와 투자가치

worniworni — Mon, 6 Oct 2025 22:23:36 +0900

※ 본 글은 특정 부동산에 대한 매수 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있다. 지극히 개인적인 분석과 의견을 기록한 글이다.

요즘 분당쪽 재건축 소식이 많이 들려서 관심을 가지고 있었는데, 주말에 시간이 나서 오리역 근처 무지개마을 3단지를 직접 가봤다. 사실 투자 목적이라기보단 궁금해서 간거긴 한데, 가보니까 생각보다 괜찮은 점들이 많아서 정리해본다.

왜 무지개마을 3단지였나

분당 재건축이 요즘 핫한데, 정자쪽이나 서현쪽은 가격이 이미 많이 올라있더라. 그래서 상대적으로 조용한 곳을 찾다보니 구미동이 눈에 들어왔다. 특히 오리역 제4테크노밸리 개발 소식을 뉴스에서 봤는데, 이게 진짜 추진되면 주변 아파트들이 영향을 받을것 같았다.

무지개마을은 1단지부터 4단지까지 있는데, 그중에서 3단지는 신한과 건영이 시공한 곳이다. 4단지는 이미 리모델링이 진행중이라 뉴스에 많이 나왔던 곳이고.

단지 기본정보부터 확인

집에서 먼저 검색을 좀 해봤다. 무지개마을 3단지는 1996년 2월에 준공된 28년차 아파트다. 세대수는 964세대로 꽤 큰 편이고, 평형대는 20평대부터 33평대까지 다양하게 구성되어있다.

위치는 경기도 성남시 분당구 구미동 201번지. 오리역에서 걸어서 10분 정도 거리라고 나와있었다. 수인분당선 타고 강남까지 한방에 갈수있는게 큰 장점이다.

실제로 가보니

토요일 오후에 갔는데, 날씨가 좋아서 단지 둘러보기 딱 좋았다. 일단 첫인상은 '오래됐구나'였다. 28년차니까 당연한거긴 한데, 그래도 관리는 잘 되어있는것 같았다. 외벽 페인트칠도 최근에 한것 같고, 조경도 나름 신경쓴 흔적이 보였다.

단지 규모가 964세대라서 생각보다 컸다. 주차장은 지상 위주인데, 평일엔 좀 부족할수도 있겠다는 생각이 들었다. 근데 요즘 새 아파트들도 주차 힘든거 생각하면 비슷한 수준인것같다.

놀이터랑 운동시설도 있고, 주민들이 산책하는 모습도 보였다. 전반적으로 조용하고 쾌적한 분위기였다. 아무래도 1기 신도시라 나무들도 크고 녹지공간이 넉넉했다.

주변환경이 괜찮았던 이유

오리역까지 실제로 걸어가봤다. 네이버 지도에는 10분이라고 나왔는데 실제로는 7-8분 정도 걸린것 같다. 거리가 그렇게 멀지 않아서 출퇴근하기 괜찮을것같았다.

오리역 주변은 CGV도 있고 홈플러스도 있어서 생활편의시설은 충분했다. 카페나 식당들도 많이 보였다. 요즘 오리역 상권이 예전보다 조용해졌다는 얘기도 있던데, 그래도 기본적인건 다 있었다.

학교는 구미초등학교랑 구미중학교가 가까웠다. 분당이 워낙 학군으로 유명한 곳이잖아. 특히 구미중은 예전에 특목고 진학률이 높았다고 들었다. 애들 키우는 입장이면 학군은 진짜 중요한데, 이 부분은 확실히 분당의 강점인것 같다.

제4테크노밸리 개발, 이게 진짜 핵심 호재

임장 가기 전에 제일 궁금했던게 이거였다. 오리역 제4테크노밸리 개발 계획이 실제로 어느정도 진행됐나.

검색해보니까 성남시가 오리역 일대 57만㎡에 첨단산업 복합단지를 만든다고 한다. 규모가 엄청 크더라. LH 오리사옥 부지, 성남농수산물유통센터 부지, 법원부지까지 포함해서 개발한다는 계획이다.

더 놀라웠던건 현대자동차그룹이 민간자문단으로 참여한다는 소식이었다. 국토부에서도 한국형 화이트존(도시혁신구역)을 도입해서 규제를 완화해준다고 하니까, 이건 정말 추진력있게 진행되는구나 싶었다.

만약 이게 제대로 완성되면 판교 테크노밸리처럼 될수도 있겠다는 생각이 들었다. 물론 시간은 좀 걸리겠지만, 방향성은 확실해보였다.

현장에서 직접 보니까 하나로마트 성남점 건물이랑 주변 부지들이 꽤 넓었다. 여기가 다 개발된다고 생각하니까 오리역 일대가 완전히 바뀔것 같았다.

리모델링 분위기도 무시못해

무지개마을 4단지가 이미 리모델링 사업계획 승인을 받았다는건 알고있었다. 2027년에 준공 예정이라고 하더라. 1995년 준공된 단지를 563세대에서 647세대로 늘리고, 용적률도 172%에서 268%로 올린다고 한다.

3단지는 4단지보다 1년 늦은 1996년 준공이니까, 4단지 리모델링이 잘 되면 3단지도 나중에 추진할 가능성이 있지 않을까. 물론 이건 주민들이 결정할 문제지만, 4단지 성공사례를 보면서 분위기가 형성될수도 있다.

분당 전체적으로도 재건축 분위기가 무르익고있다. 2024년 11월에 시범단지, 양지마을, 샛별마을이 선도지구로 지정됐다는 뉴스도 봤다. 1기 신도시 전체가 재건축 시대로 넘어가는 느낌이다.

가격 메리트도 있더라

현재 무지개마을 3단지 21평형 실거래가가 7억대 중반 정도라고 한다. 분당 다른 지역에 비하면 상대적으로 저렴한 편이다. 참고로 최근 2단지 20평 실거래가가 8.2억에 거래됐다는걸 봤는데, 3단지는 역에서 더 가깝고 조건이 좋은 편이라 2단지보다 높게 책정될 가능성이 크다. (현재 매물이 없어 거래가 없어 추정할수밖에 없다)

특히 재밌었던게, 무지개마을에서 100m 길 하나만 건너면 용인 죽전인데 거기랑 2-3억 차이가 난다는거다. 행정구역 하나 차이로 가격차가 이렇게 크다는게 신기했다. 분당이라는 브랜드 파워가 확실히 있는것 같다.

물론 가격이 저렴하다는건 그만큼 다른 분당 지역에 비해 상대적으로 덜 주목받았다는 의미이기도 하다. 근데 반대로 생각하면 아직 상승여력이 남아있다고도 볼수있지 않을까.

분당의 교육 인프라

아무리 재건축이나 개발 호재가 있어도, 결국 사람들이 분당을 선호하는 이유는 교육 때문이다. 무지개마을도 마찬가지다.

구미초등학교, 구미중학교 모두 걸어서 갈수있는 거리에 있다. 분당은 전국적으로 학군과 교육열이 높은 지역으로 유명하다. 대치동 다음가는 수준이라는 말도 있더라.

단지 주변에 학원가도 형성되어있고, 오리역 주변에도 여러 교육 시설들이 있었다. 애들 교육 생각하는 부모 입장에선 이게 제일 중요한 부분일수도 있다.

교통도 생각보다 좋았다

수인분당선 오리역이 도보 10분 이내라는게 확실한 장점이다. 오리역에서 강남역까지 30분대, 판교까지는 10분도 안걸린다. 출퇴근 하는 사람들한테는 이만한게 없다.

차로 이동할때도 경부고속도로 판교IC가 가까워서 서울이나 지방 가기 편하다. 분당 내부 이동도 큰길들이 잘 되어있어서 막히는 편은 아니었다.

임장 마치며 느낀점

집에 돌아와서 하루종일 본 내용들을 정리해봤다. 무지개마을 3단지의 가장 큰 매력은 역시 '가능성'인것 같다.

오리역 제4테크노밸리 개발이라는 확실한 호재가 있고, 무지개마을 4단지 리모델링도 진행중이다. 분당 전체적으로도 재건축 분위기가 형성되고있다. 여기에 분당이라는 지역 프리미엄과 학군, 그리고 상대적으로 저렴한 가격까지.

물론 28년차 노후 아파트라는 점은 어쩔수 없다. 당장 살기엔 불편한 부분들도 있을거다. 하지만 3-5년 정도 긴 호흡으로 본다면, 충분히 관심가질만한 곳이라는 생각이 들었다.

특히 테크노밸리 개발이 본격화되면 오리역 일대가 완전히 바뀔텐데, 그때 무지개마을의 가치도 같이 올라갈 가능성이 높다. 판교 테크노밸리 생길때 주변 아파트들 가격이 어떻게 됐는지 생각해보면 된다.

다음주엔 근처 양지마을도 한번 가볼까 한다. 선도지구로 지정된 곳이니까 어떤 분위기인지 궁금하다.

태그: #분당 #무지개마을3단지 #오리역 #제4테크노밸리 #분당재건축 #구미동 #임장후기 #부동산 #분당아파트 #리모델링 #오리역테크노밸리 #분당학군 #투자 #1기신도시 #성남시

2025년 추석 황금연휴 7일, 클로드 AI로 iOS 앱 만들기

worniworni — Mon, 6 Oct 2025 21:52:40 +0900

올해 추석 연휴가 엄청 길다는 소식을 듣고 달력을 한번 확인해봤다. 10월 3일 개천절부터 시작해서 10월 9일 한글날까지 무려 7일이나 이어진다. 추석이 10월 6일 월요일이라 주말이랑 연결되고, 거기에 대체공휴일까지 포함되서 이렇게 긴 연휴가 만들어졌다고 한다.

솔직히 말하면 처음엔 어디 여행이라도 갈까 고민했는데, 요즘 항공권 가격이나 숙박비를 보면 추석 연휴 기간엔 답이 없더라. 그래서 이번엔 집에서 뭔가 의미있는걸 해보자고 마음먹었다.

클로드 AI 프로 구독을 결심하다

사실 몇달 전부터 AI로 코딩하는게 대세라는 얘기를 많이 들었다. ChatGPT도 써보고 코파일럿도 써봤는데, 최근에 클로드 AI가 코딩에 특화되어있다는 얘기를 듣고 궁금했다. 특히 클로드가 긴 대화 문맥을 잘 기억한다는 평이 많아서 한번 제대로 써보고싶었다.

그러던 중 추석 연휴가 길다는 소식을 듣고, "이때다" 싶었다. 평소에 만들고싶었던 iOS 앱이 하나 있었는데, 이번 기회에 클로드 AI의 도움을 받아서 만들어보기로 했다. 월 20달러면 한달 동안 무제한으로 쓸 수 있다고 해서 바로 구독 버튼을 눌렀다.

SwiftUI로 첫 iOS 앱 도전

나는 주로 웹 개발을 해왔고 iOS 개발은 거의 처음이었다. Swift 문법은 대충 알고있었지만 SwiftUI는 완전 초보였다. 근데 요즘은 SwiftUI가 대세라고 해서 바로 SwiftUI로 시작했다.

만들려고 한 앱은 간단한 할일 관리 앱이었다. 뭐 투두리스트야 엄청 흔한 예제긴 한데, 내가 원하는 기능들을 넣고싶었다. 특히 카테고리별로 관리하고, 완료한 항목들을 통계로 보여주는 기능까지 넣고 싶었다.

첫날은 Xcode 설치부터 시작했다. 생각보다 용량이 커서 다운로드 받는데만 한시간 넘게 걸렸다. 맥북 저장공간도 좀 정리하고... 이런저런 준비만 해도 오전이 다 갔다.

오후부터 본격적으로 클로드한테 물어보면서 시작했다. "SwiftUI로 할일 관리 앱을 만들고싶은데 어떻게 시작하면 좋을까?"라고 물었더니, 프로젝트 구조부터 기본 뷰 설정까지 친절하게 알려줬다.

벌어진 일들

처음엔 정말 순조로웠다. 클로드가 알려준대로 코드를 복사해서 붙여넣으니까 앱이 실행되더라. "오 이거 쉬운데?" 싶었다. 근데 문제는 그다음이었다.

첫번째로 막혔던건 데이터 저장이었다. CoreData를 써야하나 SwiftData를 써야하나 고민하다가 클로드한테 물어봤다. SwiftData가 더 최신이고 SwiftUI와 잘 맞는다고 해서 SwiftData로 선택했는데, 이게 문서가 생각보다 많이 없어서 시행착오가 좀 있었다.

특히 관계형 데이터 모델링하는 부분에서 에러가 계속 났다. 카테고리와 할일의 관계를 설정하는 부분이었는데, 런타임 에러가 자꾸 발생했다. 클로드한테 에러 로그를 보여주면서 물어보니까, @Model 매크로 쓰는 방식을 조금 수정해야한다고 알려줬다. 그대로 했더니 해결됐다.

두번째 문제는 UI였다. 디자인 감각이 없어서 그냥 기본 컴포넌트만 써서 만들었는데, 너무 밋밋하더라. 그래서 클로드한테 "좀더 세련된 디자인으로 만들고싶다"고 했더니, SF Symbols 아이콘도 추가해주고 색상 조합도 추천해줬다. 생각보다 괜찮아보여서 만족스러웠다.

세번째는 제일 애먹었던 부분인데, 리스트에서 항목을 삭제할때 앱이 크래시나는 문제였다. 처음엔 원인을 몰라서 한참 헤맸다. 로그를 보니까 뭔가 SwiftData 컨텍스트 관련 문제인것같았는데 정확히 뭐가 문젠지 모르겠더라.

클로드한테 상황을 설명하고 코드를 전부 보여줬더니, 삭제하는 시점의 문제라고 했다. onDelete 모디파이어를 쓸때 바로 삭제하는게 아니라 한템포 늦게 삭제해야 한다고 알려줬다. DispatchQueue.main.async로 감싸니까 해결됐다. 이런건 도저히 혼자서는 못찾았을것 같다.

연휴 5일차, 드디어 완성

결국 5일동안 매달려서 기본적인 기능은 다 만들었다. 할일 추가하고 삭제하고, 카테고리별로 보고, 완료한 항목 통계 보는 기능까지. 처음엔 3일이면 끝날줄알았는데 역시 개발은 항상 예상보다 오래걸린다.

근데 이 과정에서 클로드 AI가 정말 큰 도움이 됐다. 특히 에러가 났을때 에러 로그를 그대로 붙여넣으면 원인을 분석해주고 해결 방법을 알려주는게 너무 좋았다. 구글링 하면 한참 걸릴걸 몇분만에 해결할수있었다.

물론 클로드가 알려준 코드가 항상 완벽한건 아니었다. 가끔 오래된 방식을 알려주거나, iOS 버전이 안맞아서 deprecated된 메서드를 쓴 적도 있었다. 그래도 대부분은 제대로 작동했고, 안되는 부분은 다시 물어보면 수정해줬다.

추석 연휴를 보내며

이번 추석 연휴는 정말 의미있게 보낸것같다. 평소에 미뤄뒀던 iOS 개발 공부도 하고, 실제로 동작하는 앱도 만들어봤으니까. 물론 아직 앱스토어에 올릴 수준은 아니지만, 나한테는 의미있는 첫 iOS 앱이다.

클로드 AI 구독도 아깝지 않았다. 20달러로 이렇게 많은걸 배울수있다면 충분히 가치있는 투자라고 생각한다. 앞으로 한달동안 더 써보면서 다른 프로젝트도 진행해볼 생각이다.

내년 추석은 언제쯤 될까 벌써부터 궁금해진다. 그때까지 더 실력을 쌓아서, 다음 연휴때는 더 복잡한 앱을 만들어보고싶다. 어쩌면 실제로 앱스토어에도 올려볼수있지않을까.

이번 추석 연휴처럼 긴 연휴가 또 오면, 여러분도 평소에 해보고싶었던 개발 프로젝트에 도전해보는건 어떨까. 클로드 AI 같은 도구들을 활용하면 생각보다 훨씬 쉽게 시작할수있다. 중요한건 일단 시작하는 용기인것같다.

참고로 10월10일 금요일에 연차 하나 쓰면 10일 황금연휴가 된다고 하던데, 나는 이미 다 써버려서 못쓴다. 아쉽...

불탄 국가정보자원관리원, 구원투수로 '단독' 등판한 NHN클라우드, 왜?

worniworni — Thu, 2 Oct 2025 17:49:52 +0900

IT 뉴스를 보다가 매우 흥미로운 기사를 발견했다. 국가의 중요 데이터가 보관된 데이터센터에 화재가 발생했는데, 그 복구 사업의 단독 해결사로 NHN클라우드가 선정되었다는 소식이었다.

AWS, Azure 같은 글로벌 기업들이 꽉 잡고 있는 클라우드 시장에서, 그것도 국가적인 재난 복구라는 중차대한 임무에 국내 기업이, 그것도 여러 경쟁사를 제치고 단독으로 선정되었다는 점이 눈길을 끌었다. 이게 왜 중요한 뉴스인지, NHN클라우드가 어떻게 해결사로 낙점될 수 있었는지 궁금해져서 자세히 알아봤다.

사건의 재구성: 대전에서 발생, 대구에서 복구, NHN클라우드가 해결사로

정확한 사실은 이렇다. 화재는 국가정보자원관리원(NIRS) 대전 본원에서 발생했다. 이로 인해 96개의 중요 업무 시스템이 전소되는 큰 피해가 발생했다. 정부는 시설 복구보다 더 빠른 대응을 위해, 이 시스템들을 대구센터로 이전하여 재설치하기로 결정했다.

여기서 중요한 점이 나온다. 대구센터는 민관협력(PPP, Public-Private Partnership) 방식으로 운영되며, 여기에는 삼성SDS, KT클라우드, NHN클라우드 3사가 입주해 클라우드 서비스를 제공하고 있었다. 모두 최고의 보안 등급을 가진 쟁쟁한 기업들이다.

정부는 이 3사 중에서, 이번에 전소된 96개 시스템을 이전하고 재설치할 긴급 복구 사업자로 NHN클라우드를 단독 선정하고 '추가 상면(서버 공간) 할당 계약'을 체결했다. 즉, 여러 구원투수 후보 중에 NHN클라우드가 최종 낙점된 것이다.

구원투수 NHN클라우드, 어떤 회사일까?

그렇다면 이 중책을 맡게 된 NHN클라우드는 어떤 회사일까?

NHN의 클라우드 전문 자회사: '한게임', '페이코(PAYCO)'로 유명한 NHN 그룹의 IT 인프라 운영 노하우가 담겨있다.
국내 3대 CSP (Cloud Service Provider): 네이버클라우드, KT클라우드와 함께 국내 클라우드 시장을 이끄는 대표 토종 기업이다.
공공/금융 분야의 강자: 정부24 웹사이트 운영 등 수많은 공공기관 사업 경험과 높은 수준의 보안 기술력(CSAP)을 보유하고 있다.

이번 '단독' 수주가 갖는 진짜 의미

NHN클라우드가 단순히 사업에 '참여'한 것과, '단독'으로 긴급 복구를 맡게 된 것은 하늘과 땅 차이다.

1. 경쟁사들을 제치고 받은 '절대 신뢰'의 증표: 삼성SDS, KT클라우드라는 쟁쟁한 경쟁사들이 바로 옆에 있는데도, 국가의 가장 시급하고 중요한 재해 복구 작업을 NHN클라우드에 맡겼다는 점이다. 이는 단순히 기술력뿐만 아니라, 긴급 상황에서의 대응 능력과 정부와의 협업 능력 등 모든 면에서 가장 높은 점수를 받았다는 것을 의미한다. 그야말로 '믿고 맡긴다'는 신뢰의 표현이다.

2. 공공 클라우드 시장의 '핵심 플레이어'로 각인: 이번 단독 수주로 NHN클라우드는 공공 클라우드 시장에서 누구도 부정할 수 없는 핵심 플레이어의 위치를 굳혔다. 국가적인 재난 상황에서 해결사로 나선 이 경험은, 앞으로 그 어떤 사업 이력보다 강력한 레퍼런스가 될 것이다.

3. 기술력과 사업수행능력의 종합적 증명: NHN클라우드는 현재 추가 할당받은 공간에 서버, 네트워크 장비를 조달하고 전기, 통신 공사에 착수했다고 한다. 이는 단순히 공간만 빌려주는 것이 아니라, 인프라 설계, 장비 조달, 물리적 구축, 시스템 설치까지 이어지는 복잡한 프로젝트를 수행할 능력이 있음을 보여주는 것이다.

정리하며

NHN클라우드는 여러 후보 중 하나가 아니라, 가장 중요한 순간에 정부의 선택을 받은 유일한 해결사였다. 이번 사건을 통해 NHN클라우드는 기술력과 신뢰도, 사업수행능력 세 마리 토끼를 모두 잡으며 시장에 강력한 인상을 남기게 되었다.

개발자로서도 국내 기업이 이처럼 중요한 역할을 해내는 것을 보니 뿌듯하다. 앞으로 공공 클라우드 시장에서 NHN클라우드의 행보가 더욱 기대된다.

#NHN클라우드 #NHNCloud #국가정보자원관리원 #NIRS #클라우드 #PPP #대전센터 #대구센터 #재해복구 #DR #단독사업자

OpenAI가 쏘아올린 HBM, 삼성전자 팔았더니... (눈물)

worniworni — Thu, 2 Oct 2025 17:35:39 +0900

아, 오늘 아침 주식 계좌를 보고 한숨부터 나왔다. SK하이닉스는 무섭게 치고 올라가고, 내가 가진 삼성전자는... 아, 팔았지 참. 얼마 전에 '이만하면 많이 먹었다' 싶어서 익절하고 나왔는데, 오늘 이렇게 날아가 버릴 줄이야. 역시 주식은 매도 타이밍이 예술인가 보다. 배가 너무 아프다 ㅠㅠ

도대체 무슨 일이 있었던 건지, 뉴스를 찾아보며 이 배 아픈 이유를 되짚어 봤다. 역시 이유는 있었다.

https://www.joongang.co.kr/article/25371594

사건의 발단: OpenAI와 삼성의 전방위적 기술 동맹

오늘 주가 급등의 배경을 다시 깊게 파보니, 내가 알던 건 빙산의 일각이었다. 단순한 HBM 공급 기대감이 아니었다. 바로 삼성전자와 OpenAI의 차세대 AI 데이터센터 혁신을 위한 포괄적 기술 협력(LOI) 체결 소식이 결정타였다.

지난번 글에서는 그저 'OpenAI가 HBM을 많이 필요로 한다' 정도로만 생각했다. 하지만 삼성 뉴스룸의 공식 발표는 그보다 훨씬 거대한 그림을 보여줬다. 이건 단순한 부품 공급 계약이 아니라, AI 데이터센터의 미래를 함께 설계하는 전략적 기술 동맹에 가까웠다.

협력 분야는 다음과 같다.

HBM(고대역폭 메모리): 기존에 알려진 AI의 '쌀'. 당연히 포함된다.
CXL(Compute Express Link): 여러 장치(메모리, CPU, GPU 등)를 훨씬 효율적으로 묶는 새로운 인터페이스 기술이다. 데이터 병목 현상을 해결할 핵심 기술로 꼽힌다.
PIM(Processing-in-Memory): 메모리 반도체에 연산 기능을 더해, 데이터 이동을 최소화하고 전력 효율을 높이는 기술이다. AI 연산에 최적화된 차세대 메모리다.

쉽게 말해, OpenAI라는 AI 선두주자가 삼성이라는 종합 반도체 기업과 손잡고, AI를 위한 최고의 하드웨어 아키텍처를 함께 만들어가기로 한 것이다. 이건 완전히 다른 차원의 이야기였다.

삼성전자

AI 시대의 쌀, 그리고 나의 섣부른 판단

이 공식 발표를 보고 나니, 배 아픔이 더욱 격렬해졌다. 나는 고작 '삼성전자가 HBM 시장에서 하이닉스에 좀 뒤처진다던데...' 하는 단편적인 뉴스에 흔들려 주식을 팔아버렸다. 완전히 숲을 보지 못하고 나무만, 그것도 썩은 나뭇가지만 보고 판단한 셈이다.

내가 판 삼성전자는 단순한 HBM 플레이어가 아니었다. HBM은 물론, CXL, PIM 등 미래 데이터센터에 필요한 모든 메모리 솔루션을 가진 유일한 기업이었고, OpenAI는 바로 그 점을 보고 파트너로 낙점한 것이다. SK하이닉스가 HBM의 강자인 것은 맞지만, 삼성은 AI 데이터센터라는 더 큰 그림을 그릴 수 있는 '올라운더'였던 셈이다.

장기적인 관점에서 AI 시장의 성장을 믿었다면, 그리고 삼성전자가 가진 종합 반도체 역량의 무게를 제대로 이해했다면, 절대 팔지 말았어야 했다. 오늘의 주가 상승은 단순한 해프닝이 아니라, 삼성전자가 AI 시대의 핵심 파트너로 공식 인정받았다는 강력한 신호탄이었다.

정리하며

오늘의 배 아픔을 교훈 삼아, 다음에는 더 큰 그림을 보는 투자자가 되어야겠다 다짐해본다. 내가 판 주식이 오르는 것은 분명 속 쓰린 일이지만, 덕분에 CXL, PIM 같은 차세대 기술과 AI 산업의 더 깊은 흐름에 대해 공부하게 되었으니... 긍정적으로 생각해야지. (라고 오늘도 정신승리 중)

삼성과 OpenAI의 협력은 이제 시작이다. 앞으로 두 회사가 만들어갈 AI의 미래가 기대되면서도, 내 계좌를 생각하면 눈물이 앞을 가린다. 오늘은 정말이지... 치킨으로는 안 되겠다. 족발 정도는 시켜야겠다.

참고 자료:

삼성전자 뉴스룸 (2025.10.02) "삼성, OpenAI와 함께 차세대 AI 데이터센터 혁신 주도"
국내외 주요 증권사 리포트 및 뉴스 기사 (2025년 10월)

#삼성전자 #SK하이닉스 #HBM #AI반도체 #OpenAI #엔비디아 #주식투자 #매도후회 #성장주 #기술주

미국 셧다운이 뭐길래? 나와 무슨 상관일까? (2025년)

worniworni — Thu, 2 Oct 2025 17:27:29 +0900

https://www.bbc.com/news/articles/crrj1znp0pyo

※ 본 글은 특정 자산에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있습니다. 지극히 개인적인 분석과 의견을 기록한 글입니다.

퇴근하고 뉴스를 보는데 미국 셧다운 이야기가 또 나온다. 몇 년에 한 번씩 주기적으로 나오는 것 같은데, 나올 때마다 금융 시장이 출렁이는 것 같아 덩달아 마음이 불안해진다. 대체 셧다운이 뭐고, 왜 맨날 의회는 싸우는 걸까? 그리고 가장 중요한 것, 그게 한국에 사는 나랑 무슨 상관이람.

매번 그냥 '그런가보다' 하고 넘어갔는데, 이번에는 궁금해서 외신 뉴스 몇 개를 찾아보며 정리해봤다. 나처럼 궁금했던 분들에게 도움이 되길 바란다.

미국 셧다운(Shutdown), 대체 뭔가?

아주 간단하게 말하면, 미국 연방 정부가 일시적으로 문을 닫는 것이다.

미국은 회계연도가 매년 10월 1일에 시작된다. 이때까지 의회에서 다음 해에 나라 살림을 어떻게 꾸려나갈지에 대한 예산안(Appropriations bills)을 통과시키지 못하면, 정부는 돈이 없어서 일을 할 수가 없게 된다. 말 그대로 '셧다운' 상태가 되는 것이다.

물론 국방, 경찰, 소방, 항공 관제처럼 국가 운영에 필수적인 업무는 유지된다. 하지만 이런 필수 인력들도 예산안이 통과될 때까지는 무급으로 일해야 하는 경우가 많다. 그 외 국립공원, 박물관, 일부 행정 서비스 등 비필수적인 업무는 모두 중단된다.

왜 자꾸 셧다운을 하는 걸까?

이건 순전히 정치적인 문제다. 미국 의회를 장악하고 있는 거대 양당(공화당과 민주당)이 예산안을 가지고 힘겨루기를 하는 것이다.

예를 들어, 특정 정책(국경 장벽 건설, 특정 분야 지원금 삭감/증액 등)에 대해 서로 의견이 엇갈릴 때, 이걸 예산안과 연계해서 상대를 압박하는 카드로 쓰는 경우가 많다. "우리가 원하는 거 안 들어주면, 예산안 통과 안 시켜줄 거야. 그럼 셧다운되는 거고, 그 책임은 너희한테 있어!" 와 같은 식이다.

결국 국민들의 불편과 국가 경제의 불안정을 담보로 한 위험한 정치 게임인 셈이다. 2025년 현재 논의되는 셧다운 역시 이민 정책, 우크라이나 지원, 정부 지출 규모 등 여러 사안에 대한 양당의 첨예한 대립이 그 원인이라고 한다.

https://www.abc.net.au/news/2025-10-02/us-government-shutdown-effects-day-one/105842146

그래서, 우리에게 미치는 영향은?

"미국 정부가 문을 닫든 말든, 나랑 무슨 상관이야?" 라고 생각할 수 있다. 하지만 안타깝게도, 세계 1위 경제 대국인 미국의 상황은 생각보다 우리 삶에 큰 영향을 미친다.

1. 금융 시장 불안정성 증가

가장 직접적인 영향이다. 나 같은 주식 투자자에게는 제일 신경 쓰이는 부분. 미국 정부의 셧다운은 그 자체로 거대한 불확실성이다. 투자자들은 위험을 피하려는 심리가 강해지고, 주식 같은 위험 자산을 팔고 달러나 금 같은 안전 자산으로 몰리게 된다.

주식 시장 하락: 전 세계 주식 시장이 동반 하락할 가능성이 커진다.
환율 변동: 단기적으로는 안전 자산 선호 심리 때문에 달러가 강세를 보이며 원/달러 환율이 오를 수 있다. 하지만 셧다운이 길어져 미국 경제에 대한 신뢰도가 떨어지면 반대로 달러 가치가 하락할 수도 있다.

2. 한국 경제 간접 타격

셧다운으로 미국 내 경제 활동이 위축되면, 당연히 소비도 줄어든다. 미국은 우리나라의 최대 수출 시장 중 하나다. 미국의 소비가 줄면, 우리나라 기업들의 수출 실적도 나빠질 수밖에 없다. 반도체, 자동차 등 주력 산업에 모두 영향을 미칠 수 있는 문제다.

3. 미국 관련 업무 지연

만약 미국 여행을 계획하고 있거나 비자 발급이 필요한 경우, 관련 행정 업무가 지연되거나 중단될 수 있다. 당장 내 삶에 직접적인 불편을 줄 수도 있는 것이다.

정리하며

찾아보고 나니, 미국 셧다운은 더 이상 '바다 건너 불구경'이 아니라는 걸 다시 한번 깨닫는다. 세계 경제는 거대한 톱니바퀴처럼 맞물려 돌아가고, 가장 큰 톱니바퀴인 미국이 삐걱거리면 다른 모든 곳에 영향을 미칠 수밖에 없다.

물론 단기적인 셧다운은 시장에 충격을 주었다가 금방 회복되는 경우가 많았다. 하지만 이런 정치적 불확실성이 반복된다는 것 자체가 장기적으로는 미국 경제의 신뢰도를 깎아 먹는 일이 아닐까 싶다.

세상은 정말 하나로 연결되어 있구나 다시 한번 느낀다. 미국 정치 뉴스도 이제 남일이 아닌 시대다.

참고 자료:

Reuters, AP, BBC 등 주요 외신 기사 (2025년 9-10월)

#미국셧다운 #미국정부셧다운 #셧다운 #미국경제 #세계경제 #금융시장 #환율 #경제공부 #시사상식

스팀에 부활한 추억의 포트리스2 블루, 정식 출시 맞을까? (직접 알아봄)

worniworni — Thu, 2 Oct 2025 17:17:33 +0900

야근 후 맥주 한 캔, 그리고 갑자기 떠오른 그 게임

어느 때와 다름없이 야근을 마치고 집에 돌아와 맥주 한 캔을 땄다. 유튜브를 보며 멍하니 있는데, 알고리즘이 웬 포트리스2 영상을 눈앞에 대령했다. '탱크~ 쏴!' 하는 효과음과 함께 각도를 재고 바람을 계산하던 그 시절. 초등학생 때 친구들과 PC방에 옹기종기 모여앉아 즐기던 추억이 파노라마처럼 스쳐 지나갔다.

'아, 진짜 재밌었는데... 지금도 할 수 있으려나?'

문득 든 생각에 곧바로 스팀(Steam)을 켜고 'Fortress 2'를 검색했다. 설마 있겠어? 그런데, 있었다. 'Fortress 2 BLUE'라는 이름으로. 심장이 잠시 두근거렸다. 내 추억의 게임이, 2025년에 스팀에 떡하니 존재하다니. 당장 '설치' 버튼을 누르려던 찰나, 무언가 이상한 점이 눈에 띄었다.

반가움도 잠시, 낯선 개발사와 퍼블리셔

개발 및 배급: JUNEI (HONG KONG) CO., LIMITED.

홍콩? 내가 알던 포트리스의 개발사는 분명 'CCR'이었는데. 머릿속에 온갖 의심이 피어오르기 시작했다. 이거 혹시 정식 라이선스도 없이 추억을 팔아 돈을 벌려는, 소위 '짝퉁' 게임은 아닐까? 특히 요즘같이 개인정보에 민감한 시대에, 개발자로서 정체불명의 클라이언트를 내 PC에 까는 건 영 찝찝한 일이었다.

결국 나는 설치 버튼 대신, 이 게임의 정체를 파헤쳐 보기로 결심했다.

추적 시작: 나무위키와 스팀 평가를 뒤지다

먼저 가장 공신력 있는(?) 정보 소스인 나무위키의 '포트리스2' 문서를 정독했다. 역시나 IP(지식재산권)의 역사가 꽤나 복잡했다. 개발팀의 이탈, 여러 후속작의 등장과 실패 등 우여곡절이 많았다.

그리고 마침내 결정적인 단서를 찾았다.

"2024년 9월 30일, 중국판 '포트리스2'가 스팀에서 재오픈되었으며, 이는 CCR과 포트리스M 측에서도 정식 게임 출시임을 확인했다."

결론부터 말하면, 다행히도 이 게임은 CCR로부터 정식 라이선스를 받은 '공식' 출시작이 맞았다. 한숨 돌렸다. 내 추억이 중국산 짝퉁으로 더럽혀지는 일은 없겠구나.

안심하고 스팀 페이지의 사용자 평가를 훑어보기 시작했다. 평가는 '대체로 긍정적'. 140여 개의 평가 중 71%가 긍정적이었다.

긍정적인 평가들은 대부분 나와 비슷했다.
"추억이 새록새록 돋는다", "이게 얼마 만이냐", "친구랑 하니 재밌다" 등, 게임의 귀환 자체를 반기는 목소리였다.

하지만 부정적인 평가도 만만치 않았다.
"최근 업데이트로 UI가 너무 불편해졌다", "과금 유도(P2W)가 보인다", "서버 핑이 불안정하다", "예전의 그 감성이 아니다" 등, 게임의 현재 퀄리티와 운영 방식에 대한 불만이 많았다.

특히 최근 진행된 UI 업데이트에 대한 불만이 유독 많아 보였다. 추억은 추억이고, 현재의 게임 플레이 경험은 또 다른 문제인 셈이다.

결론: 설치할 것인가, 말 것인가?

모든 조사를 마친 지금, 내 결론은 '일단 보류'다.

정식 라이선스를 받은 공식 게임이라는 점은 정말 다행이고 반가운 소식이다. 하지만 스팀 평가에서 보이듯, 현재 게임의 완성도나 운영이 썩 매끄럽지는 않은 것 같다. 특히 UI 변경과 같은 이슈는 게임 플레이 경험에 치명적일 수 있다.

예전의 그 순수한 재미를 기대했다가, 요즘 모바일 게임에서 흔히 보이는 과금 모델과 불편한 인터페이스에 실망하고 싶지는 않다.

일단은 스팀 '관심 목록'에만 담아두고, 최근 업데이트에 대한 불만이 잦아들고 게임이 좀 더 안정화되었다는 평가가 보이면 그때 한번 플레이해볼 생각이다. 추억은 가장 아름다운 모습으로 남겨두는 것도 좋은 방법일 테니까.

#포트리스 #포트리스2 #포트리스2블루 #스팀게임 #추억의게임 #고전게임 #CCR #JUNEI #리뷰 #게임리뷰

개발자 필수품 Gemini CLI, 더 똑똑하게 최신 버전으로 유지하는 방법

worniworni — Thu, 2 Oct 2025 17:03:47 +0900

어느 날, 내 Gemini CLI가 구버전이라는 것을 깨달았다

매일같이 손에 달고 사는 도구들이 몇 개 있다. 개발자라면 아마 다들 공감할 것이다. 내게는 VS Code, iTerm, 그리고 최근에는 Gemini CLI가 바로 그런 존재다. 간단한 코드 스니펫 생성부터, 파일 정리, 심지어 커밋 메시지 작성까지 Gemini CLI는 꽤나 훌륭한 부사수 역할을 해주고 있다.

그런데 며칠 전, 다른 개발자의 글을 보다가 내가 쓰던 명령어 옵션이 구식이라는 걸 우연히 알게 됐다. 부랴부랴 gemini -v 명령으로 버전을 확인해보니, 아니나 다를까. 꽤 오래된 버전에 머물러 있었다. 새로운 기능들이 추가되었을 텐데, 나만 모르고 있었던 거다.

brew upgrade처럼 간단한 명령어가 익숙한 나에게 gemini update 같은 명령어가 없다는 사실은 조금 아쉬웠다. 그래서 오늘은 나처럼 Gemini CLI를 애용하는 개발자들을 위해, 어떻게 하면 이 똑똑한 도구를 항상 최신 상태로 유지할 수 있을지 그 방법을 정리해보기로 했다.

방법 1: 가장 표준적인 NPM 업데이트 (정공법)

만약 나처럼 npm을 사용해 Gemini CLI를 글로벌(-g)로 설치했다면, 업데이트 역시 npm을 통해 하는 것이 가장 표준적인 방법이다.

npm upgrade -g @google/gemini-cli

이 명령어 하나면 현재 설치된 Gemini CLI를 최신 안정 버전으로 업그레이드할 수 있다. 간단하고 확실한 방법이다. 하지만 문제는, 내가 이 명령어를 기억하고 주기적으로 실행해줘야 한다는 점이다. 인간은 망각의 동물이니까.

방법 2: 항상 최신 버전을 사용하는 npx (설치 없는 실행)

두 번째 방법은 npx를 활용하는 것이다. npx는 npm 패키지를 설치하지 않고도 한번 실행시켜주는 아주 유용한 도구다.

npx @google/gemini-cli@latest [실행할 명령어]

예를 들어, 현재 디렉토리의 파일을 보고 싶다면 아래처럼 실행할 수 있다.

npx @google/gemini-cli@latest ls

이 방법의 최대 장점은 업데이트를 전혀 신경 쓸 필요가 없다는 것이다. 명령어를 실행하는 시점에 항상 최신 버전의 Gemini CLI를 다운로드해 실행하기 때문이다.

하지만 단점도 명확하다. 매번 실행할 때마다 패키지를 새로 가져오므로 약간의 딜레이가 있을 수 있고, 무엇보다 명령어가 너무 길어진다. gemini ls가 npx @google/gemini-cli@latest ls로 바뀌는 건 좀 부담스럽다.

방법 3: 나만의 업데이트 명령어를 만들자 (게으른 개발자의 선택)

결국 내가 선택한 방법은 '나만의 간단한 업데이트 명령어'를 만드는 것이었다. brew upgrade의 편리함을 포기할 수 없었기 때문이다. 방법은 아주 간단하다. 자주 사용하는 쉘의 설정 파일(.zshrc, .bashrc 등)에 alias(별칭)를 하나 추가해주면 된다.

나는 Zsh를 사용하므로 ~/.zshrc 파일 맨 아래에 다음 한 줄을 추가했다.

# .zshrc

# Gemini CLI를 위한 커스텀 alias
alias gemini-update="npm upgrade -g @google/gemini-cli"

파일을 저장한 뒤, source ~/.zshrc 명령어로 변경사항을 적용해주면 끝이다. 이제 터미널에서 gemini-update라는 명령어를 입력하기만 하면, npm upgrade -g @google/gemini-cli가 실행된다.

이제 생각날 때마다 gemini-update 한 번만 쳐주면 되니, 구버전을 사용할 걱정도 없고 마음도 편하다.

결론: 작은 습관이 생산성을 높인다

어떻게 보면 정말 사소한 팁이다. 하지만 개발자의 생산성은 이런 작은 디테일에서 온다고 믿는다. 매일 쓰는 도구를 날카롭게 유지하는 것, 그리고 그 과정을 최대한 자동화하고 편하게 만드는 것.

Gemini CLI는 앞으로 더 빠르게 발전하고, 더 똑똑한 기능들을 내놓을 것이다. 이 흐름에 뒤처지지 않으려면, 오늘 소개한 방법 중 하나를 골라 당신의 개발 환경에 적용해보는 건 어떨까? 아마 '진작 할 걸'이라는 생각이 들지도 모른다.

#Gemini #GeminiCLI #개발자 #CLI #생산성 #업데이트 #npm #npx #Tool #Productivity

세계 최고의 코딩 모델? Claude 4.5 Sonnet 첫인상 (개발자 시점)

worniworni — Tue, 30 Sep 2025 22:37:54 +0900

https://www.anthropic.com/news/claude-sonnet-4-5

또 한 번의 진화, 이번엔 '코딩'에 진심이다

평소 코딩할 때 GPT-4o와 함께 클로드 3 오푸스(Opus)를 애용하는 개발자로서, 오늘 아침 들려온 앤트로픽(Anthropic)의 '클로드 소네트 4.5(Claude Sonnet 4.5)' 출시 소식은 그야말로 심장이 뛰는 소식이었다.

특히 그들의 슬로건, "세계 최고의 코딩 모델(the world's best coding model)" 이라는 문장은 그냥 지나칠 수 없었다. 단순한 성능 개선을 넘어, 개발자들을 위한 새로운 기능들이 대거 포함되었다는 소식에, 회의 시간 내내 몰래 관련 정보를 찾아볼 수밖에 없었다. 이 글은 나처럼 새로운 AI 도구에 열광하는 개발자들을 위해 정리한 첫인상이다.

핵심: 더 똑똑해진 두뇌, 그리고 합리적인 가격

먼저 모델 자체의 성능이 향상되었다. 기존의 최상위 모델이었던 '클로드 3 오푸스'보다 추론과 수학, 그리고 코딩 능력에서 더 뛰어난 벤치마크 결과를 보여준다고 한다. 그러면서도 가격은 기존과 동일하게 유지된다. 즉, 우리는 더 똑똑해진 두뇌를 이전과 같은 비용으로 사용할 수 있게 된 것이다. 개발자에게는 최고의 가성비 업그레이드인 셈이다.

하지만 이번 발표의 진짜 핵심은 모델 자체의 성능 향상보다, 개발자들을 위한 새로운 무기들에 있다.

개발자를 위한 새로운 무기: 'Claude Code'의 진화

앤트로픽은 이번에 '클로드 코드(Claude Code)'라는 개발자용 툴スイート를 함께 공개했다. 이게 정말 대박이다.

1. 체크포인트 (Checkpoints): AI와의 안전한 실험

가장 눈에 띄는 기능이다. AI와 협업하여 코드를 짜다 보면, "이 제안이 괜찮은 것 같긴 한데, 적용했다가 코드가 엉망이 되면 어떡하지?" 하는 불안감이 들 때가 많다. 체크포인트는 이 문제를 해결한다. 특정 시점의 코드 상태를 마치 Git 스냅샷처럼 저장해두고, AI가 제안한 리팩토링이나 새로운 로직을 과감하게 적용해 본 뒤, 마음에 들지 않으면 즉시 이전 체크포인트로 되돌아갈 수 있다. 이제 마음 놓고 AI에게 코드 수정을 맡길 수 있는 '안전망'이 생긴 것이다.

2. 네이티브 VS Code 확장 (Native VS Code Extension): 완벽한 통합

드디어 나왔다. 더 이상 웹 브라우저와 코드 에디터를 번거롭게 오가며 코드를 복사-붙여넣기 할 필요가 없어졌다. 내가 가장 많이 사용하는 에디터인 VS Code에 클로드가 네이티브 확장 프로그램으로 통합된다. 이제 내 코드 에디터 안에서 자연스럽게 AI와 대화하고, 제안을 받고, 코드를 수정하는 완벽하게 끊김 없는(seamless) 워크플로우가 가능해진다.

3. 컨텍스트 편집과 메모리 (Context Editing & Memory)

API 사용자들을 위한 강력한 기능이다. AI가 대화의 맥락을 더 잘 기억하고, 개발자가 이 컨텍스트를 더 세밀하게 제어할 수 있게 되었다. 이는 단순히 일회성 질문에 답하는 것을 넘어, 여러 단계에 걸쳐 복잡한 작업을 수행하는 '상태를 가진(stateful)' AI 애플리케이션을 만드는 데 필수적인 기능이다.

새로운 개발 패러다임: '에이전트 SDK'

이번 발표에서 개인적으로 가장 흥분했던 부분은 바로 '클로드 에이전트 SDK(Claude Agent SDK)'의 공개다. 이는 단순히 AI에게 일을 시키는 것을 넘어, 개발자가 직접 자신만의 AI 에이전트를 만들 수 있는 도구를 제공한다는 의미다.

예를 들어, 이런 상상을 해볼 수 있다.

"프로덕션 로그를 실시간으로 모니터링하다가 새로운 종류의 에러를 발견하면, 스스로 온라인에서 해결책을 검색하고, 코드 패치를 작성한 뒤, 테스트 환경에서 실행해보고, 마지막으로 내게 검토를 요청하는 풀 리퀘스트(PR)를 날리는 에이전트"

과거에는 공상과학 영화에서나 가능했던 일이, 이제 이 SDK를 통해 우리 손으로 직접 구현할 수 있는 현실의 영역으로 들어오고 있다.

결론: 단순한 모델이 아닌, 개발 플랫폼으로의 진화

클로드 소네트 4.5는 단순한 성능 개선 모델이 아니다. 앤트로픽은 이제 개발자들에게 더 좋은 망치(Smarter Model)를 주는 것을 넘어, 자동화된 공장을 지을 수 있는 설계도와 부품(Claude Code, Agent SDK)까지 함께 제공하기 시작했다.

'AI를 활용하는 개발자'의 시대를 지나, 이제는 'AI 에이전트를 구축하고 지휘하는 개발자'의 시대로 넘어가는 거대한 전환점이 될지도 모른다. 오늘 퇴근하면 가장 먼저 VS Code 확장을 설치해 볼 생각이다. 새로운 코딩 동반자와 함께 만들어갈 미래가 벌써부터 기대된다.

#Claude #클로드 #Claude4.5 #Anthropic #AI #개발자 #코딩 #LLM #인공지능 #AgentSDK

회의 때 처음 들은 '클릭하우스(ClickHouse)', 대체 뭐길래?

worniworni — Tue, 30 Sep 2025 22:31:26 +0900

"로그 분석은 클릭하우스로..."

오늘 오후, 팀 기술 회의 시간. 신규 프로젝트의 대규모 로그 데이터 처리 방안에 대한 논의 중, 백엔드 동료 한 분이 무심코 말했다.

"이 정도 로그 양이면, 집계는 클릭하우스로 붙이는 게 좋겠어요."

'클릭하우스(ClickHouse)?'

MySQL, PostgreSQL, MongoDB, Redis 등은 익숙했지만, 클릭하우스는 처음 들어보는 이름이었다. 다들 자연스럽게 대화를 이어가는데 나만 물음표를 띄우고 있는 듯한 기분. 궁금증을 참지 못하고 회의가 끝나자마자 구글링을 시작했다. 이 글은 나처럼 클릭하우스를 처음 접하는 개발자들을 위해, 내가 찾아본 내용을 정리한 첫인상 기록이다.

그래서, 클릭하우스가 뭔데?

가장 먼저 찾아본 정의는 이렇다.

"ClickHouse는 대규모 데이터셋의 실시간 분석을 위해 설계된 오픈소스, 컬럼-지향(Column-Oriented) SQL 데이터베이스 관리 시스템(DBMS)이다."

여기서 핵심 키워드는 두 가지, '컬럼-지향'과 '분석'이다. 이 두 가지를 이해하면 클릭하우스의 정체성을 파악할 수 있다.

잠깐, OLTP vs OLAP (가장 중요한 개념)

클릭하우스를 이해하려면, 우리가 흔히 사용하는 MySQL, PostgreSQL 같은 데이터베이스와 무엇이 다른지 알아야 한다. 데이터베이스 시스템은 크게 두 가지 목적으로 나뉜다.

OLTP (Online Transaction Processing): 우리가 흔히 쓰는 관계형 데이터베이스(RDBMS)가 여기에 속한다. 쇼핑몰의 '주문 처리'를 생각하면 쉽다. 수많은 사용자들이 동시에 상품을 주문하고, 재고를 확인하며, 결제하는 등 작고 빠른 '트랜잭션'이 실시간으로 일어난다. 데이터를 쓰고, 읽고, 수정하고, 삭제하는 작업(CRUD)에 최적화되어 있다.
OLAP (Online Analytical Processing): 클릭하우스가 바로 여기에 속한다. 쇼핑몰의 '매출 분석'을 생각하면 된다. "지난 한 달간 20대 여성이 가장 많이 구매한 상품 카테고리는?" 같은 질문에 답하기 위해, 수억 개의 로그 데이터를 훑고 집계하여 인사이트를 얻는 작업이다. 대용량의 데이터를 읽고, 특정 조건으로 필터링하고, 그룹화하여 통계를 내는 작업에 최적화되어 있다.

즉, 클릭하우스는 MySQL을 대체하는 데이터베이스가 아니라, 분석이라는 특정 목적을 위해 탄생한 특수 목적 데이터베이스인 것이다.

왜 '컬럼 기반(Column-Oriented)'이 분석에 유리할까?

OLAP에 최적화된 비결은 바로 '컬럼 기반 저장 방식'에 있다. 이것도 기존 데이터베이스(로우 기반)와 비교하면 이해하기 쉽다.

로우(Row) 기반 저장 (MySQL 등): 데이터를 한 줄(row) 단위로 묶어서 저장한다. 마치 엑셀 시트처럼.
[1, '김개발', 30, '서울']
[2, '이코딩', 28, '부산']
[3, '박서버', 35, '판교']
이 상태에서 "모든 사용자의 평균 나이는?"이라는 쿼리를 실행하면, 데이터베이스는 이름, 주소 등 필요 없는 데이터까지 전부 다 디스크에서 읽어와야만 나이 값을 얻을 수 있다.
컬럼(Column) 기반 저장 (ClickHouse): 데이터를 열(column) 단위로 묶어서 저장한다.
ID: [1, 2, 3, ...]
이름: ['김개발', '이코딩', '박서버', ...]
나이: [30, 28, 35, ...]
주소: ['서울', '부산', '판교', ...]
이 상태에서 "모든 사용자의 평균 나이는?" 쿼리를 실행하면, 데이터베이스는 오직 '나이' 컬럼 데이터만 디스크에서 읽는다. 이는 디스크 I/O를 극적으로 줄여, 로우 기반 방식과는 비교도 안 될 정도로 빠른 속도를 보여준다. 또한, 같은 종류의 데이터끼리 모여있어 압축에도 훨씬 유리하다.

클릭하우스 첫인상 요약

미친 듯한 속도: 대용량 데이터 집계 및 분석 쿼리 속도가 정말 빠르다.
특화된 목적: 일반적인 웹 애플리케이션의 메인 DB로는 적합하지 않다. (트랜잭션 미지원, 잦은 수정/삭제에 불리)
최고의 파트너: 로그 데이터 분석, 실시간 대시보드, 빅데이터 통계 등 대규모 읽기/분석 작업에 최고의 선택지가 될 수 있다.

결론: 이제야 이해가 간다

이제야 회의 때 동료가 왜 '클릭하우스'를 언급했는지 명확히 이해가 갔다. 수억 건씩 쌓이는 로그 데이터를 기존 RDBMS에 넣고 GROUP BY와 SUM을 실행하는 것이 얼마나 끔찍한 일인지, 우리는 이미 경험으로 알고 있었다. 클릭하우스는 바로 그 '끔찍한 일'을 거의 실시간으로 처리해줄 수 있는 해결사였던 것이다.

새로운 기술의 등장은 언제나 설렌다. 모든 문제를 해결하는 만능 열쇠는 없지만, 특정 문제를 해결하기 위한 최고의 망치는 언제나 존재한다. 클릭하우스는 '대용량 데이터 분석'이라는 문제를 해결하기 위한 아주 강력한 망치인 셈이다. 조만간 개인 프로젝트에서 직접 사용해보며 그 소문난 속도를 체감해봐야겠다.

#클릭하우스 #ClickHouse #OLAP #데이터베이스 #개발자 #데이터분석 #빅데이터 #ColumnOriented

결국 백기 든 카카오톡, '역대급' 업데이트 철회 사태로 본 교훈

worniworni — Tue, 30 Sep 2025 22:23:31 +0900

https://www.youtube.com/watch?v=3HikWKkq5gc

"그럴 줄 알았다"

https://www.youtube.com/watch?v=3HikWKkq5gc

며칠 전, 나는 카카오톡의 무리한 업데이트에 분노하며 대안 메신저를 찾아보는 글을 썼다. 그리고 바로 어제, 카카오톡이 대대적인 업데이트를 사실상 철회하겠다는, '백기'를 드는 기사를 접했다. 솔직한 첫마디는 "그럴 줄 알았다" 였다.

전 국민이 사용하는 '국민 메신저'가 사용자의 목소리를 무시하고 일방적인 변화를 밀어붙였을 때, 그 결과가 어떨지는 불 보듯 뻔했다. 이번 사태는 단순한 해프닝을 넘어, 거대 플랫폼과 사용자 간의 관계에 대한 중요한 교훈을 남긴 사건으로 기록될 것이다.

무엇이 이용자들을 그토록 화나게 만들었나?

이번 카카오톡 업데이트의 핵심은 기존의 친구 목록 탭을 인스타그램과 유사한 '피드형 UI'로 바꾸고, 숏폼 콘텐츠와 AI 피드를 전면에 내세운 것이었다. 메신저를 소셜 미디어로 만들겠다는 야심찬 계획이었지만, 사용자들의 반응은 싸늘함을 넘어 분노에 가까웠다.

"내 카톡 돌려내!" - 핵심 기능의 훼손: 대부분의 사람들에게 카카오톡은 '소통을 위한 도구'다. 친구나 가족, 동료에게 빠르고 정확하게 메시지를 보내는 것이 핵심 목적이다. 하지만 이번 업데이트는 이 핵심 가치를 뒤로하고, 원치 않는 소식과 광고, 숏폼으로 가득 찬 복잡한 화면을 사용자에게 강요했다.
학습 피로감과 사생활 침해 우려: 수년간 익숙해진 사용 경험(UX)을 하루아침에 바꿔버린 것은 중장년층에게 큰 혼란을 주었다. 또한, 피드형 UI는 원치 않는 상대의 소식이 노출되거나 내 사생활이 드러날 수 있다는 불안감을 증폭시켰다.
'국민 앱'의 오만: 무엇보다 사용자들을 화나게 한 것은 '너희는 어차피 계속 쓸 거잖아'라는 듯한 카카오의 일방적인 태도였을 것이다. 아무런 예고나 선택권 없이 강제로 업데이트된 화면을 마주한 사용자들은 거대한 플랫폼 앞에서 무력감을 느꼈고, 이는 곧 분노로 이어졌다.

개발자의 시선: 그들은 왜 실패했나?

나는 이번 사태가 단순히 '디자인이 예쁘지 않아서' 생긴 문제라고 생각하지 않는다. 그 이면에는 거대 IT 기업이 빠지기 쉬운 몇 가지 함정이 숨어있다.

데이터에 대한 맹신: 카카오 내부에서는 분명 데이터를 기반으로 의사결정을 했을 것이다. '숏폼 콘텐츠의 체류 시간이 길다', '특정 광고의 클릭률이 높다' 와 같은 데이터 말이다. 하지만 그들은 데이터 너머의 '맥락'을 놓쳤다. 사용자들이 숏폼을 보는 것은 '시간을 때우고 싶을 때'이지, '친구에게 메시지를 보내려 할 때'가 아니라는 점을 간과했다.
'플랫폼의 오만': 시장 지배적 사업자는 종종 사용자를 '떠나지 못할 고객'으로 착각한다. "우리가 새로운 방향을 제시하면 사용자들이 따라올 것이다"라는 오만한 생각은, 사용자들이 느끼는 불편함과 저항의 임계점을 잘못 판단하게 만들었다. 이번 사태는 '대안이 없는' 것처럼 보이는 서비스조차도 사용자의 신뢰를 잃으면 한순간에 위기를 맞을 수 있다는 것을 보여줬다.
수익화에 대한 조급증: 플랫폼의 영향력을 수익으로 연결하려는 비즈니스팀의 목표가, 사용자 경험을 지키려는 UX팀의 목소리를 덮어버렸을 가능성이 크다. 단기적인 수익 지표를 위해 장기적인 사용자 신뢰를 깎아 먹는 결정은 결국 더 큰 손실로 돌아온다는 것을 증명한 셈이다.

'업데이트 철회'가 남긴 것들

카카오는 결국 업데이트 6일 만에 친구탭을 기존의 목록 형태로 되돌리겠다고 발표했다. 이 짧고 굵었던 사태가 남긴 것은 무엇일까?

사용자에게는 '승리의 경험': 사용자들이 목소리를 내면, 거대 플랫폼도 바꿀 수 있다는 성공적인 경험을 안겨주었다. 우리는 더 이상 수동적인 서비스 소비자가 아님을 증명했다.
카카오에게는 '값비싼 교훈': '국민 앱'이라는 지위가 영원하지 않다는 것을 뼈저리게 깨닫는 계기가 되었을 것이다. 이번 사태로 훼손된 사용자 신뢰를 회복하기까지는 꽤 오랜 시간이 걸릴 것이다.
IT 업계에는 '중요한 케이스 스터디': 새로운 기능을 출시할 때, 일부 사용자를 대상으로 한 A/B 테스트나 점진적인 롤아웃(Gradual Rollout)이 얼마나 중요한지, 그리고 사용자의 정성적인 피드백에 귀 기울이는 것이 얼마나 중요한지를 모든 IT 기업에 다시 한번 각인시켰다.

결국 플랫폼의 주인은 회사가 아니라, 그것을 사용하고 일상을 채워나가는 '사용자'다. 개발자로서, 또 한 명의 사용자로서 이번 카카오톡의 백기 투항을 보며, 서비스를 만드는 사람이 절대 잊지 말아야 할 가장 기본적인 원칙을 되새기게 된다.

국가정보자원관리원 화재, 개발자의 눈으로 본 '이중화' 실패의 교훈

worniworni — Tue, 30 Sep 2025 22:18:15 +0900

https://www.youtube.com/watch?v=mmplgzgBD68

또다시 울린 데이터센터 화재 경보

지난 저녁, 동료 개발자들과의 단톡방이 갑자기 뜨거워졌다. '국가정보자원관리원 화재로 정부24, 모바일 신분증 서비스 장애.' 뉴스를 보자마자 2022년 가을, 대한민국을 멈춰 세웠던 판교 데이터센터 화재의 악몽이 떠올랐다.

그리고 개발자라면 누구나 반사적으로 같은 질문을 던졌을 것이다.

"어? 이중화(Redundancy) 구성 안 되어 있었나? 왜 서비스가 멈추지?"

이번 사태는 단순한 화재 사건을 넘어, 대한민국의 디지털 인프라가 얼마나 견고한지, 그리고 우리가 과거의 실패로부터 얼마나 배웠는지를 보여주는 뼈아픈 바로미터다. 개발자의 입장에서 이번 사건을 기술적인 관점으로 파헤쳐 보고 싶어졌다.

국가정보자원관리원(NIRS), 무엇을 하는 곳인가?

먼저, 이곳이 얼마나 중요한 곳인지 알아야 한다. 국가정보자원관리원(NIRS)은 대전과 광주, 대구에 센터를 둔, 대한민국 정부의 모든 정보 시스템을 통합 관리하는 '디지털 정부의 심장부'다. 우리가 일상적으로 사용하는 거의 모든 대국민 서비스가 이곳에서 운영된다.

정부24: 주민등록등본 등 각종 민원서류 발급
홈택스: 연말정산, 세금 신고
모바일 신분증: 실물 신분증을 대체하는 디지털 신분증
나라장터: 국가 공공 입찰 시스템

이 외에도 1,600여 개의 중앙부처 정보 시스템이 이곳에 있다. 이런 곳에 불이 났다는 것은, 국가의 디지털 행정이 사실상 마비될 수 있다는 의미다.

개발자의 근본적인 의문: "이중화는 어디에?"

이번 사태의 핵심은 '이중화의 실패'다. 개발자에게 '이중화'는 시스템 설계의 기본 중의 기본이다. 서버 한 대가 죽어도 서비스는 계속되어야 하니까. 이중화는 크게 두 가지 레벨로 나눌 수 있다.

고가용성 (HA, High Availability): 하나의 데이터센터 내에서 여러 대의 서버가 액티브-스탠바이 또는 액티브-액티브 형태로 구성되어, 일부 서버에 장애가 발생해도 서비스 중단 없이 운영되는 것을 말한다. 로드밸런서 뒤에 여러 웹 서버를 두는 것이 가장 기본적인 예다.
재해 복구 (DR, Disaster Recovery): 이번 사태의 핵심이다. 지진, 화재 등으로 데이터센터 하나가 통째로 마비되는 상황에 대비하는 것이다. 물리적으로 멀리 떨어진 곳에 백업 데이터센터를 두고, 메인 센터에 문제가 생겼을 때 백업 센터로 시스템 전체를 전환(Failover)하는 것을 의미한다.

왜 백업 센터는 작동하지 않았나?

보도에 따르면, 국정자원관리원은 대전 본원 외에 광주에도 백업 센터를 운영하고 있었다. 그런데 왜 정부24와 같은 핵심 서비스들은 몇 시간 동안이나 멈춰 섰을까? 여기서 우리는 '무늬만 DR'이었을 가능성을 엿볼 수 있다.

Active-Standby의 한계: 가장 가능성이 높은 시나리오다. 대전(Active)과 광주(Standby) 센터가 실시간으로 똑같이 운영되는 'Active-Active' 방식이 아니었을 확률이 높다. Active-Standby 구성에서는 평소 Standby 센터는 대기만 하다가, 재난 시 수동 또는 반자동으로 서비스를 전환한다. 이 전환 과정은 짧게는 수십 분에서 길게는 몇 시간이 걸리며, 그동안 서비스 중단은 불가피하다. 실시간 동기화 방식인 Active-Active는 구축 및 운영 비용이 기하급수적으로 비싸기 때문에, 예산 문제로 타협했을 가능성이 크다.
미흡한 재해 복구 훈련: DR 시스템은 '만들어두면 끝'이 아니다. 실제 재난 상황을 가정해 주기적으로 백업 센터로 전환하는 훈련을 하지 않으면, 막상 진짜 재난이 닥쳤을 때 시스템은 제대로 작동하지 않는다. "전환 과정에서 장애가 날까 봐", "서비스를 중단할 수 없어서" 등의 이유로 훈련을 소홀히 했다면, DR 시스템은 그저 비싼 저장 장치에 불과했을 것이다.
드러나지 않은 단일 장애점(SPOF): 서버와 스토리지를 이중화했더라도, 두 센터가 공유하는 특정 네트워크 회선이나 인증 시스템, DNS 설정 등에 단일 장애점(Single Point of Failure)이 존재했다면 무용지물이다. 이번 화재가 UPS(무정전 전원 장치)실에서 시작된 것처럼, 전원 시스템의 이중화 설계 미흡도 원인일 수 있다.

2년 전 카카오 사태에서 배우지 못한 교훈

2022년 카카오 데이터센터 화재 이후, 정부는 민간 기업들에게 강력한 데이터센터 이중화를 요구했다. 하지만 정작 국가의 심장부인 자신들의 시스템은 그때와 똑같은 문제를 되풀이했다. 이는 기술의 문제가 아니라, 안정성에 대한 투자와 의지의 문제다.

개발자로서 우리는 종종 새로운 기능 개발에만 매몰되곤 한다. 하지만 이번 사태는 우리가 만든 서비스가 사용자의 일상에 얼마나 깊숙이 관여하는지, 그리고 그 서비스의 안정성과 복원력(Resilience)을 확보하는 것이 얼마나 중요한지를 다시 한번 일깨워준다.

단순히 불을 끄고 서버를 복구하는 것에서 끝나선 안 된다. 이번 화재가 우리 국가 디지털 인프라의 취약점을 투명하게 드러내고, '소 잃고 외양간이라도 제대로 고치는' 계기가 되기를 간절히 바랄 뿐이다. 이번만큼은 보여주기식 대책이 아닌, 실제 작동하는 견고한 시스템을 위한 근본적인 투자와 변화가 이루어지길 기대한다.

#국가정보자원관리원 #데이터센터 #화재 #서버장애 #이중화 #재해복구 #DR #개발자 #SRE

개발자 필수템? 묵혀뒀던 루테인 영양제 다시 먹기 시작한 후기

worniworni — Tue, 30 Sep 2025 22:07:55 +0900

서랍 속에서 잠자던 영양제를 꺼내다

며칠 전, 책상 서랍을 정리하다가 먼지가 뽀얗게 쌓인 영양제 통을 하나 발견했다. 바로 '루테인'이었다. 언제 사뒀는지 기억도 가물가물하다. 아마 작년쯤, 눈이 침침하다는 생각에 덜컥 사놓고는 며칠 챙겨 먹다 이내 잊어버린 모양이다.

내 직업은 개발자. 야근과 사이드 프로젝트에 치여 하루 12시간 이상 모니터를 보는 게 일상이다. 눈은 뻑뻑하고, 오후만 되면 초점이 흐려지는데 영양제 하나 챙겨 먹을 정신도 없이 살았나 보다. 문득 한심하다는 생각이 들었다.

"이대로는 정말 안 되겠다." 그날부터 책상 위 가장 잘 보이는 곳에 루테인 통을 꺼내두고, 다시 꾸준히 먹어보기로 다짐했다. 그리고 문득 궁금해졌다. 내가 지금 먹는 이 루테인, 대체 어디에 어떻게 좋은 걸까? 그래서 직접 찾아봤다.

루테인, 우리 눈의 '선글라스'

루테인은 아주 간단히 말해 우리 눈을 보호하는 색소 성분이다. 특히 시력의 90%를 담당하는 망막의 중심부, '황반'에 집중적으로 존재한다고 한다. 마치 식물이 강한 햇빛으로부터 자신을 보호하기 위해 엽록소를 만드는 것처럼, 우리 눈의 황반도 루테인이라는 색소로 스스로를 보호하는 셈이다.

가장 중요한 역할은 두 가지였다.

1. 블루라이트 필터링

나 같은 개발자에게 가장 와닿는 기능이었다. 루테인은 스마트폰, 모니터 등에서 나오는 해로운 고에너지 '블루라이트'를 직접 흡수하여 망막이 손상되는 것을 막아준다. 그야말로 '눈 속에 착용하는 선글라스' 같은 역할이다. 블루라이트 차단 안경을 쓰는 것도 도움이 되지만, 눈 안에서 직접 방어막을 쳐준다니 훨씬 든든한 느낌이다.

2. 항산화 효과

루테인은 강력한 항산화 물질이기도 하다. 눈에 유해한 활성산소를 제거하여 세포가 늙고 손상되는 것을 막아준다. 나이가 들면 황반의 기능이 떨어져 시력을 잃을 수도 있는 '황반변성'이라는 무서운 질병이 생기는데, 루테인이 바로 이 황반의 색소 밀도를 유지시켜 황반변성을 예방하는 데 도움을 준다고 한다.

아쉽게도 루테인은 체내에서 스스로 합성되지 않아, 반드시 음식이나 영양제로 섭취해야만 한다.

그래서, 다시 먹어보니 어땠나?

솔직히 말해, 영양제 한두 번 먹었다고 눈이 번쩍 뜨이는 드라마틱한 효과는 없다. 그런 걸 기대했다면 거짓말이다.

하지만 2-3주 정도 꾸준히 챙겨 먹으니, 미묘하지만 분명 긍정적인 변화가 느껴지기 시작했다. 가장 큰 변화는 오후 시간대의 눈의 피로감이다. 예전에는 오후 4-5시만 되어도 눈이 뻑뻑하고 흐릿해져서 인공눈물을 달고 살았는데, 요즘은 그런 빈도가 확실히 줄었다. 특히 장시간 코딩에 집중한 뒤에도 모니터의 글자가 예전처럼 뿌옇게 번져 보이는 현상이 조금은 완화된 느낌이다.

물론 이것이 순전히 루테인 덕분인지, 아니면 영양제를 챙겨 먹기 시작하면서 눈 건강에 조금 더 신경 쓰게 된 플라시보 효과인지는 모르겠다. 하지만 이유가 무엇이든, 내 눈이 조금 더 편안해진 것은 사실이다.

결론: 내 눈을 위한 최소한의 보험

이번에 루테인에 대해 찾아보면서, 이것이 당장의 시력을 좋게 만드는 치료제가 아니라, 장기적인 관점에서 눈의 건강을 지키고 노화를 늦추는 '보험'과 같다는 생각이 들었다.

하루의 대부분을 모니터 앞에서 보내는 개발자에게 눈 건강은 곧 직업 수명과 직결된다. 수십만 원짜리 키보드와 마우스를 사면서, 정작 가장 중요한 눈을 위한 투자는 잊고 살았던 건 아닌지 반성하게 된다.

이제 루테인은 내 책상 위에서 키보드, 마우스와 함께 가장 중요한 필수템이 되었다. 나와 비슷한 환경의 동료 개발자가 있다면, 서랍 속에 잠자고 있는 눈 영양제가 없는지 한번 찾아보길 조심스럽게 권해본다. 내 눈은 소중하니까.

#루테인 #루테인효능 #눈영양제 #개발자 #눈건강 #블루라이트 #황반변성 #영양제후기

React와 JS는 더 이상 '메인 게임'이 아니다? - Stefan Mischook 영상 후기

worniworni — Thu, 25 Sep 2025 23:17:31 +0900

"React. It's not about JavaScript anymore."

최근 유튜브를 탐색하다가, 베테랑 개발자인 Stefan Mischook의 채널에서 매우 자극적인 제목의 영상을 발견했다. "2025: Why JavaScript and React Aren’t the Main Game Anymore." (2025년: 왜 자바스크립트와 리액트는 더 이상 메인 게임이 아닌가.)

지난 몇 년간 프론트엔드 개발 생태계의 중심이었고, 수많은 개발자들의 커리어를 만들어준 이 기술들이 더 이상 '메인 게임'이 아니라니. React와 TypeScript를 주력으로 사용하고 있는 현업 개발자로서, 불안감과 호기심이 뒤섞인 마음으로 영상을 클릭했다. 이 글은 영상의 내용을 요약하고, 그의 주장에 대한 나의 생각을 정리한 기록이다.

영상의 핵심: '게임의 룰'이 바뀌고 있다

Stefan의 주장을 한 문장으로 요약하면 이렇다: "소프트웨어 개발의 중심이 전통적인 프레임워크 개발에서 AI 기반 개발로 넘어가고 있다."

그는 이러한 기술의 전환이 역사적으로 항상 있어왔다고 말한다. 한때 시장을 지배했던 델파이, VB6, 플래시가 역사의 뒤안길로 사라졌듯이, React와 JavaScript의 시대 역시 새로운 시대, 즉 AI의 시대에 자리를 내주고 있다는 것이다.

그가 말하는 'AI 기반 개발'은 우리가 직접 LLM을 만드는 것을 의미하지 않는다. 대신, 다음 두 가지를 의미한다.

AI를 활용한 개발(AI-augmented coding): 코딩 과정에 AI를 적극적으로 활용하여 생산성을 극대화하는 개발자. (예: GitHub Copilot, Cursor)
AI-First 애플리케이션 개발: 애플리케이션의 핵심 로직 자체가 AI(LLM)와의 상호작용으로 이루어지는 서비스. 그는 이런 앱은 90%의 작업이 AI 프롬프팅이고, 10%만이 전통적인 개발(소위 '배관 작업')이라고 말한다.

결국 그의 메시지는 명확하다. "AI를 도구로 사용하는 전문가가 되거나, 아니면 직업을 잃거나. 둘 중 하나가 될 것이다." 그리고 진짜 기회는 이제 구글, 마이크로소프트 같은 빅테크가 아닌, AI를 통해 자신의 비즈니스 문제를 해결하려는 수많은 비(非)테크 기업에 있다고 강조한다.

현업 개발자로서의 불안과 기대

솔직히 말해, 영상을 보는 내내 약간의 불안감을 느꼈다. 지난 몇 년간 열심히 갈고 닦은 React 숙련도가 더 이상 핵심 경쟁력이 아닐 수도 있다는 생각 때문이었다. 하지만 영상이 끝날 무렵, 그 불안감은 새로운 시대에 대한 기대감으로 바뀌었다.

Stefan의 주장은 "React가 쓸모없어진다"는 뜻이 아니다. 오히려 React의 '역할'이 변하고 있다는 의미로 해석해야 한다. 과거에는 React 자체가 제품의 핵심 가치를 만드는 '주연 배우'였다면, 이제는 AI라는 새로운 주연 배우를 빛나게 해주는 '조연 배우' 또는 '무대 장치'가 되어가고 있다.

나는 이 변화를 'AI 배관공(AI Plumber)' 이라는 역할로 이해하고 싶다. AI가 아무리 똑똑하게 답변을 생성하고 이미지를 만들어내도, 그 자체만으로는 완전한 서비스가 될 수 없다. 사용자의 요청을 받아 AI에 전달하고, AI의 응답을 받아와 사용자에게 아름다운 UI로 보여주고, 그 결과를 데이터베이스에 저장하는 등의 복잡한 '배관' 작업이 반드시 필요하다. 그리고 이 배관을 가장 잘 설계하고 구축하는 사람들이 바로 우리 같은 개발자들이다.

React는 이 배관의 끝에서 사용자와 만나는 '수도꼭지'를 만드는 데 여전히 최고의 도구 중 하나다. 다만, 이제 우리는 수도꼭지 만드는 기술뿐만 아니라, 수원지(LLM)에서 물을 어떻게 끌어오고, 어떤 파이프(API)를 사용하며, 어떻게 수압을 조절(Prompting)할지에 대해서도 알아야만 하는 시대에 살게 된 것이다.

그래서 우리는 무엇을 해야 하는가?

Stefan의 조언과 내 생각을 종합해, 앞으로 개발자로서 우리가 준비해야 할 것들을 정리해봤다.

1. 기본기는 더욱 중요해진다

역설적으로, AI 시대일수록 소프트웨어 개발의 기본기(Fundamentals)는 더욱 중요해진다. AI가 단편적인 코드는 잘 짜주지만, 전체 시스템을 설계하고, 데이터의 흐름을 이해하며, 어떤 기술 스택이 문제 해결에 적합한지 판단하는 능력은 여전히 개발자의 몫이다. HTTP, 데이터베이스, 네트워크, 클라우드 인프라에 대한 깊은 이해가 그 어느 때보다 중요해질 것이다.

2. AI를 '도구'로서 마스터하기

GitHub Copilot을 단순히 자동 완성 기능으로만 사용하는 수준에서 벗어나야 한다. 특정 LLM(GPT, Gemini, Claude 등)이 어떤 종류의 작업에 더 강점을 보이는지 직접 테스트해보고, 내가 만드는 서비스에 가장 적합한 AI 모델을 선택하고 조합할 수 있는 능력을 길러야 한다. 이제는 프로그래밍 언어나 프레임워크를 선택하듯, LLM을 선택하고 활용하는 시대다.

3. 'AI-First' 토이 프로젝트 시작하기

가장 좋은 학습 방법은 직접 만들어보는 것이다. OpenAI API나 다른 LLM API를 활용하여 간단한 'AI-First' 애플리케이션을 만들어보는 경험은 무엇보다 중요하다. 예를 들어, "내가 가진 옷들 사진을 올리면 오늘 날씨에 맞는 코디를 추천해주는 웹 앱" 같은 작은 프로젝트를 시작해보는 것이다. 이 과정에서 프롬프트 엔지니어링, API 연동, 결과 파싱 등 AI 배관공에게 필요한 핵심 기술들을 자연스럽게 익힐 수 있다.

결론: 게임의 룰은 바뀌었다

React와 JavaScript가 사라지지는 않을 것이다. 하지만 개발 세계의 '메인 게임'이 더 이상 아니라는 Stefan의 주장은 곱씹어볼 가치가 충분하다. 이 기술들은 이제 더 큰 AI 중심의 시스템을 구성하는 중요한 '부품'으로서 역할을 하게 될 것이다.

결국 이 새로운 시대에 살아남고 번성할 개발자는 특정 프레임워크에 집착하는 사람이 아니라, 끊임없이 학습하며 문제 해결을 위해 가장 강력한 도구를 유연하게 사용하는 사람일 것이다. 새로운 게임은 이미 시작되었다. 이제 새로운 룰을 익힐 시간이다.

영상 출처

https://www.youtube.com/watch?v=MOIBL4x9yQA

람다 함수에 대한 고찰 - 포프TV '람다, 그냥 쓰지 마세요'를 보고...

worniworni — Thu, 25 Sep 2025 23:12:37 +0900

시작하며: 뜨거운 감자, 람다(Lambda)

https://www.youtube.com/watch?v=knASr7oQNTk

평소 즐겨보는 개발 유튜브 채널인 '포프TV'에 매우 도발적인 제목의 영상이 올라왔다. "람다 함수, 그냥 쓰지 마세요. 회사에 해가 됩니다."

Java, C#, Python 등 현대적인 언어에서 함수형 프로그래밍의 핵심 요소로 자리 잡은 람다. 간결하고 우아한 코드를 작성하게 해주는 강력한 도구로 칭송받는 이 기능을 쓰지 말라니, 심지어 회사에 해가 된다니. 개발자로서 그냥 지나칠 수 없는 주제였다. 영상을 끝까지 본 후, 포프 님의 주장에 대한 요약과 현업 개발자로서의 내 생각을 정리해보고자 한다.

포프가 말하는 '람다를 쓰지 말아야 할 이유'

영상에서 포프 님은 람다 함수를 남용했을 때 발생하는 여러 문제점을 지적한다. 크게 세 가지로 요약할 수 있다.

1. 성능 저하의 가능성

람다는 공짜가 아니다. Java를 기준으로, 컴파일러는 람다를 처리하기 위해 내부적으로 이름 없는 클래스(Anonymous Class)와 함수를 생성한다. 이는 곧 함수 호출에 따른 오버헤드, 메모리 점프에 의한 캐시 미스 등의 비용이 발생할 수 있음을 의미한다. 만약 인라인으로 처리해도 충분했을 간단한 코드를 굳이 람다로 만들었다면, 이는 불필요한 성능 저하를 유발하는 '섣부른 최적화'의 역효과를 낳을 수 있다.

2. 재사용성의 부재와 모듈화 저해

어떤 로직이 이름 있는 함수 대신 람다 표현식 내부에 숨겨져 있다면, 다른 곳에서 비슷한 로직이 필요할 때 이를 찾아 재사용하기가 매우 어렵다. 결국 비슷한 코드를 복사-붙여넣기 하게 될 가능성이 높아진다.

반면, 명확한 이름과 역할을 가진 함수로 분리되어 있다면, 그 함수는 자연스럽게 재사용 가능한 모듈이 된다. 람다의 남용은 코드의 모듈화를 방해하고, 장기적으로 유지보수 비용을 증가시킨다.

3. 코드 리뷰를 회피하는 심리적 수단

이 부분이 가장 흥미로웠다. 포프 님은 일부 개발자들이 함수를 설계하고, 그 의도를 명확히 드러내는 이름을 짓는 과정에서 오는 스트레스와 코드 리뷰의 압박을 피하기 위해 의도적으로 람다를 사용한다고 지적한다.

함수를 만든다는 것은, 그 함수의 역할, 이름, 파라미터, 반환 값 등 명확한 '인터페이스'를 설계하는 행위다. 이 과정에서 동료 개발자들의 날카로운 지적을 받다 보면 감정적인 소모가 커질 수 있다. 하지만 복잡한 로직을 이름 없는 람다 안에 숨겨버리면, 이러한 설계의 책임을 회피하고 코드 리뷰를 더 쉽게 통과할 수 있다는 것이다. 결국 '간편함'이라는 가면 뒤에 코드 품질의 저하를 숨기는 셈이다.

현업 개발자로서의 나의 생각과 예제

영상을 보며 포프 님의 주장에 많은 부분 고개를 끄덕였다. 특히 '코드 리뷰 회피 수단'이라는 심리적 분석은 정곡을 찌르는 듯했다. 하지만 현대 프로그래밍에서 람다를 완전히 금지하는 것은 현실적으로 어렵고, 때로는 바람직하지도 않다고 생각한다. Java의 Stream API나 C#의 LINQ처럼, 람다는 데이터 컬렉션을 다룰 때 코드의 가독성과 흐름을 매우 유연하게 만들어주기 때문이다.

중요한 것은 '언제 람다를 쓰고, 언제 함수로 분리할 것인가'에 대한 명확한 기준을 갖는 것이다.

나쁜 예: 복잡한 로직을 담은 람다

예를 들어, 특정 조건에 맞는 사용자 목록에서 VIP 사용자에게만 특별 할인율을 적용하여 이메일 주소를 추출하는 코드가 있다고 가정해보자. (Java 예시)

List<String> vipEmails = users.stream()
    .filter(u -> u.isActive() && u.getPurchaseAmount() > 1000) // 조건 1
    .map(u -> { // 조건 2
        if (u.getGrade() == UserGrade.VIP) {
            u.applyDiscount(0.15); // 특별 할인 적용
            return u.getEmail().toLowerCase();
        }
        return u.getEmail().toLowerCase();
    })
    .collect(Collectors.toList());

위 코드는 스트림 API의 흐름 안에서 모든 것을 처리하려다 보니 filter와 map 내부의 람다식이 복잡해졌다. 특히 map 내부는 여러 줄의 로직과 부수 효과(side effect)까지 포함하고 있어 의도를 파악하기 어렵고 재사용도 불가능하다.

좋은 예: 람다는 위임, 로직은 함수로

포프 님의 조언에 따라 이 코드를 리팩토링 해보자. 복잡한 로직을 명확한 이름의 private 함수로 분리하는 것이다.

List<String> vipEmails = users.stream()
    .filter(this::isEligibleForEvent)
    .map(this::processAndGetEmail)
    .collect(Collectors.toList());

private boolean isEligibleForEvent(User user) {
    return user.isActive() && user.getPurchaseAmount() > 1000;
}

private String processAndGetEmail(User user) {
    if (user.getGrade() == UserGrade.VIP) {
        user.applyDiscount(0.15); // 특별 할인 적용
    }
    return user.getEmail().toLowerCase();
}

어떤가? 스트림 연산은 isEligibleForEvent와 processAndGetEmail이라는 명확한 단계를 서술하는 이야기처럼 읽힌다. 각 함수의 역할이 이름만으로 명확히 드러나며, 내부 로직은 해당 함수 안에 캡슐화되어 있다. 이제 isEligibleForEvent 로직은 다른 곳에서도 얼마든지 재사용할 수 있다.

결론: 람다는 '수단'이지 '목표'가 아니다

포프TV 영상을 통해 람다의 편리함 이면에 숨겨진 비용을 다시 한번 생각하게 되었다. 람다는 그 자체로 좋은 것도, 나쁜 것도 아닌 강력한 '도구'일 뿐이다.

나만의 원칙을 세워본다. "람다의 바디(body)가 한 줄을 넘어가거나, 여러 가지 일을 동시에 처리하려는 경향이 보이면 즉시 함수로 분리하자."

결국 좋은 코드란 '짧은 코드'가 아니라 '읽기 쉽고, 재사용하기 쉽고, 유지보수하기 쉬운 코드'다. 람다의 간결함이라는 달콤한 유혹에 빠져 더 중요한 가치를 놓치고 있지는 않은지, 우리 모두가 코드를 작성하는 매 순간 고민해봐야 할 문제다.

영상 출처

https://www.youtube.com/watch?v=knASr7oQNTk

[유튜브 후기] 김구라쇼 '분당만 재건축되나?' 편을 보고 느낀 1기 신도시의 현실

worniworni — Thu, 25 Sep 2025 23:01:25 +0900

https://www.youtube.com/watch?v=vKx2Nw7_f1g

※ 본 글은 특정 종목이나 지역에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있습니다. 지극히 개인적인 분석과 의견을 기록한 글입니다.

우연히 보게 된 유튜브, 그리고 씁쓸한 현실

https://www.youtube.com/watch?v=vKx2Nw7_f1g

평소 즐겨보는 유튜브 채널 중 하나인 '김구라의 경제연구소'에 흥미로운 영상이 올라왔다. 바로 "1기 신도시 재건축, 분당만 가능하다?" 라는 제목의 영상이었다. 30대 개발자이자 부동산에 관심이 많은 나에게, 특히 분당 생활권에 있는 나에게는 클릭하지 않을 수 없는 주제였다.

영상은 1기 신도시 재건축 이슈로 들썩이는 분당과, 반대로 잠잠하기만 한 일산의 현실을 비교하며 그 원인을 파헤친다. 특히 일산 실거주자인 MC 김구라의 현실적인 푸념과 전문가의 냉정한 분석이 어우러져 더 깊게 몰입하며 보게 되었다.

영상의 핵심: 왜 분당만 들썩이는가?

영상의 내용을 요약하면 간단하다. 정부가 1기 신도시 재건축 활성화 정책을 발표한 이후, 유독 분당의 아파트 가격 상승률이 마포, 용산, 성동구 등 서울의 핫한 지역들을 뛰어넘을 정도로 뜨겁다는 것이다. 하지만 평촌, 산본, 중동, 그리고 영상에서 주로 다루는 일산 등 다른 1기 신도시들은 상대적으로 조용하다.

같은 1기 신도시인데 왜 이런 극명한 온도 차이가 발생하는 걸까? 영상은 이 질문을 던지며, 그 답이 결국 '사업성'에 있다는 점을 암시한다.

왜 분당만 가능한가? 나의 생각

영상을 보고 나서, 나는 이 현상에 대해 좀 더 깊이 생각해 보게 되었다. 왜 유독 분당의 재건축 사업성이 높게 평가받는 걸까? 내 생각은 이렇다.

1. 압도적인 '기초 체력'의 차이

재건축은 결국 '돈이 남는 장사'가 되어야 조합원도, 건설사도 움직인다. 여기서 가장 중요한 것이 바로 현재 아파트의 가격, 즉 '기초 체력'이다.

분당은 이미 대한민국에서 손꼽히는 부촌 중 하나다. 평균 아파트 가격 자체가 다른 1기 신도시들에 비해 월등히 높다. 높은 현재 가치는 재건축 후의 기대 가치를 더욱 높여준다. 조합원 입장에서는 추가 분담금을 내더라도, 재건축 후 얻게 될 이익이 훨씬 크다는 계산이 서는 것이다. 반면, 상대적으로 집값이 낮은 다른 신도시들은 배보다 배꼽이 더 커질 수 있다는 불안감이 존재한다.

2. 판교라는 강력한 '성장 엔진'

분당이 다른 신도시와 차별화되는 가장 큰 이유는 바로 옆에 판교테크노밸리라는 대한민국 최고의 IT 허브를 두고 있다는 점이다. 수많은 대기업과 스타트업, 그리고 그곳에 종사하는 높은 소득 수준의 직장인들. 이들은 분당의 집값을 떠받치는 강력하고 안정적인 수요층이다.

이러한 탄탄한 배후 수요는 재건축 이후에도 가격이 하락하지 않을 것이라는 강한 믿음을 준다. 결국, 좋은 일자리가 집값의 핵심이라는 부동산의 기본 원리가 1기 신도시 재건축 시장에서도 그대로 적용되고 있는 셈이다.

3. '선도지구' 경쟁과 주민들의 적극성

정부가 재건축을 가장 먼저 추진하는 '선도지구'를 지정하겠다고 발표하면서, 분당 내 주요 단지들은 마치 전쟁처럼 치열한 경쟁에 돌입했다. 주민 동의율을 높이기 위해 밤낮으로 뛰어다니고, 전문 업체를 고용해 체계적으로 사업 계획을 준비하는 등 주민들의 적극성과 의지가 다른 지역을 압도하고 있다.

이러한 주민들의 뜨거운 열의가 언론에 계속 노출되면서, "역시 분당은 다르다"는 인식을 시장에 각인시키는 효과를 낳고 있다.

결론: 재건축은 단순한 노후도 문제가 아니다

김구라쇼 영상을 통해 다시 한번 깨닫게 된 것은, 1기 신도시 재건축은 단순히 건물이 낡았다고 진행되는 것이 아니라는 점이다. 그 이면에는 사업성, 입지, 배후 수요, 그리고 주민들의 의지라는 복잡하고 냉정한 경제 논리가 깔려있다.

일산 주민인 김구라의 씁쓸한 표정에서, 정책의 온기가 모든 곳에 고르게 퍼지지 못하는 현실을 엿볼 수 있었다. 앞으로 1기 신도시 재건축이 단순히 특정 지역의 집값 상승 축제로 끝나지 않으려면, 지역 간의 격차를 줄이고 동반 성장할 수 있는 더 세심한 정책 설계가 필요해 보인다. 나 역시 분당의 발전을 응원하면서도, 다른 신도시들의 미래는 어떻게 될지 계속해서 지켜봐야겠다는 생각이 들었다.

tags: [김구라쇼, 1기신도시, 재건축, 분당, 일산, 부동산, 유튜브후기]

영상 출처

https://www.youtube.com/watch?v=vKx2Nw7_f1g

내가 분당 오리역을 주목하는 이유: 제4판교테크노밸리 개발 계획 총정리

worniworni — Thu, 25 Sep 2025 22:52:43 +0900

경기도 성남시 오리역 일대 복합개발 사업 대상지. 성남시 제공

※ 본 글은 특정 지역에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있습니다. 지극히 개인적인 분석과 의견을 기록한 글입니다.

내가 분당 오리역을 주목하는 이유

나는 꽤 오래전부터 분당의 오리역 일대를 유심히 지켜보고 있다. 30대 개발자로서 판교와 가깝고, 재테크와 부동산에 관심이 많은 나에게 오리역은 여러모로 흥미로운 곳이다.

분당의 다른 역세권(서현, 정자, 미금)에 비해 어딘가 활력이 부족하고, 넓은 부지들이 제대로 활용되지 못하는 듯한 느낌을 항상 받아왔다. 하지만 역으로 생각하면, 그만큼 분당 내에서 대규모 개발이 가능한 마지막 남은 노른자 땅이라는 의미이기도 하다. 용인시와도 바로 붙어있어 광역적인 발전 가능성도 높다.

그런 오리역에 드디어 거대한 변화의 바람이 불고 있다. 바로 '오리역세권 제4테크노밸리' 개발 계획이다. 최근 성남시에서 발표한 여러 소식들을 종합해, 내가 왜 이곳에 열광하는지, 그리고 이 계획이 어떤 의미를 갖는지 정리해보고자 한다.

오리역세권 제4테크노밸리, 도대체 뭔가?

경기 성남시 분당구 오리역 일대 통합개발 조감도 [사진출처=김은혜 의원실]

간단히 말해, 현재 제대로 활용되지 못하고 있는 오리역 주변의 대규모 부지들을 묶어 판교테크노밸리의 성공 신화를 잇는 첨단 산업 클러스터를 만들겠다는 계획이다. 단순한 재개발을 넘어, 도시의 판을 바꾸는 거대한 프로젝트다.

언론 보도를 통해 확인된 주요 사업 부지는 다음과 같다.

성남농수산물종합유통센터 부지 (약 8.4만㎡)
한국토지주택공사(LH) 오리사옥 부지 (약 3.8만㎡)
구 법원/검찰청 부지 (약 3.2만㎡)
구미동 하수처리장 부지 (약 2.9만㎡)
그 외 버스 차고지, 상업지역 등

이 부지들을 합치면 약 57만㎡에 달하는 어마어마한 면적이다. 이곳에 AI, 미래형 모빌리티, 팹리스(반도체 설계) 등 미래 산업을 이끌 기업들을 유치하고, 업무, 주거, 문화, 자족시설이 어우러진 복합 도시를 조성하는 것이 목표다.

핵심 호재: 왜 이게 대단한가?

개발 계획이야 많지만, 내가 이번 계획에 특히 더 주목하는 이유는 그 내용이 매우 구체적이고 강력하기 때문이다.

1. 규제 없는 '화이트존'과 파격적인 인센티브

성남시는 이 지역을 '도시혁신구역(화이트존)'으로 지정해달라고 국토부에 요청할 계획이다. 화이트존으로 지정되면 용도나 용적률, 건폐율 등의 규제에서 자유로워져 그야말로 백지상태에서 창의적인 개발이 가능해진다. 언론에 따르면 용적률을 최대 800%까지 완화하고, 입주 기업에게는 법인세 감면(최대 50%) 같은 파격적인 혜택을 주는 방안까지 거론되고 있다. 기업들 입장에서는 마다할 이유가 없는 최고의 조건이다.

2. 대한민국 대표 기업들의 참여

아무리 좋은 계획이라도 참여하는 기업이 없으면 앙꼬 없는 찐빵이다. 하지만 이번 프로젝트에는 이름만 들어도 설레는 대기업들이 대거 참여 의사를 밝혔다.

현대자동차그룹: AI 자율주행, 미래형 모빌리티 기술이 융합된 스마트도시 구현 자문
미래에셋금융그룹: 하이퍼스케일 AI R&D 센터 조성
하나은행: 금융 조달

이름만 들어도 든든한 기업들이 각자의 전문 분야를 맡아 참여한다는 것은 이 프로젝트의 성공 가능성을 매우 높여주는 강력한 시그널이다.

3. 도시재생 전문가 '톰 머피'의 총괄 기획

성남시는 몰락해가던 공업도시 피츠버그를 첨단 산업도시로 완벽하게 탈바꿈시킨 도시재생의 세계적인 전문가, 톰 머피 전 피츠버그 시장을 명예총괄기획가로 위촉했다. 이는 단순한 보여주기식 위촉이 아니라, 사업의 비전 수립부터 민관 협력 구조 설계까지 사업 전반을 조율하게 하겠다는 의미다. 제대로 된 전문가와 함께 프로젝트의 격을 높이겠다는 의지가 엿보인다.

그래서, 언제쯤 가시화될까?

성남시의 계획에 따르면, 현재 진행 중인 개발 구상 용역이 올해 11월에 마무리된다. 그 후 국토부에 도시혁신구역 지정을 요청하는 등 행정 절차를 거쳐, 이르면 2027년 착공을 목표로 하고 있다.

물론 계획이라는 것이 언제나 변수는 있지만, 성남시장의 강력한 의지와 대기업들의 참여가 확정된 만큼, 과거의 지지부진했던 개발 계획들과는 다른 속도감을 보여줄 것으로 기대된다.

결론: 분당의 새로운 중심을 꿈꾸며

개발자인 내가 봐도 이건 정말 가슴 뛰는 계획이다. 판교의 성공을 바로 옆에서 지켜본 사람으로서, 제4테크노밸리가 완성될 미래의 오리역을 상상하면 기대감을 감출 수 없다.

AI와 미래 모빌리티를 연구하는 수많은 고급 인력들이 이곳으로 모여들고, 그들이 먹고, 자고, 즐길 수 있는 새로운 상권과 주거지가 형성될 것이다. 지금의 낡고 활력 없던 모습은 사라지고, 분당의 새로운 중심으로 거듭날 잠재력이 충분하다.

물론 모든 투자의 책임은 본인에게 있지만, 이러한 거대한 변화의 흐름을 읽고 미리 공부해두는 것은 분명 가치 있는 일이다. 오리역이 천지개벽하는 그날을 기대하며, 앞으로도 관련 소식을 계속 주시하고 정리해볼 생각이다.

오리역, 제4테크노밸리, 분당, 부동산, 개발호재, 성남시, 화이트존]

출처

카카오톡에 지쳤다면? 갈아탈 만한 메신저 앱 꼼꼼 비교 (텔레그램, 라인, 디스코드)

worniworni — Thu, 25 Sep 2025 22:33:49 +0900

그래서, 카톡 말고 뭘 써야 할까?

지난번 글에서 카카오톡 강제 업데이트에 분노하며 구버전으로 돌아가 보려다 장렬히 실패한 후기를 남겼다. 결국 개발자인 나조차도 복잡하고 위험한 방법 앞에서 두 손 두 발 다 들고 '그냥 쓰자'고 결론 내렸었다.

하지만 마음 한구석의 찝찝함은 사라지지 않았다. 업데이트로 추가된, 흔들면 QR코드가 나오는 민망한 기능이나, 친구 탭인지 광고 탭인지 모를 정체불명의 목록을 볼 때마다 한숨이 나왔다. "이렇게 끌려다닐 바에야, 진짜 갈아탈 만한 메신저는 없을까?" 이 생각이 꼬리에 꼬리를 물고 이어졌다. 그래서 오늘은 작정하고 카카오톡의 대안이 될 만한 메신저들을 아주 샅샅이 비교 분석해 보기로 했다. 내 기준은 여전히 명확하다.

깔끔한가? (더 이상 조잡한 광고나 불필요한 기능은 사양한다)
안전한가? (내 대화는 소중하니까)
쓸만한가? (주변에 쓰는 사람이 아예 없으면 무용지물)

후보 1. 텔레그램 (Telegram) - 자유와 보안, 그 아슬아슬한 경계

https://telegram.org/?setln=ko

가장 먼저 떠오른 대안은 역시 텔레그램이다. '보안' 하면 가장 먼저 생각나는 메신저이자, 특유의 자유로운 분위기 덕분에 내 주변 개발자 친구들도 몇몇은 텔레그램을 보조 메신저로 쓰고 있다.

무엇이 매력적인가?

텔레그램의 첫인상은 '가볍고 빠르다'이다. 카카오톡처럼 쇼핑하기, 선물하기, 주문하기 같은 부가 기능으로 덕지덕지 붙어 있지 않고 오직 '메시지'라는 본질에만 집중한다. 덕분에 앱 실행 속도나 메시지 전송 속도가 비교 불가 수준으로 쾌적하다.

개발자인 내게 가장 큰 장점은 압도적인 파일 전송 기능이다. 최대 2GB까지 파일을 보낼 수 있는데, 이건 단순히 사진 몇 장 보내는 수준을 넘어선다. 가끔 친구에게 내가 만든 앱의 테스트 빌드(apk, ipa)나, 수백 메가짜리 로그 파일을 보내줘야 할 때 카톡에서는 불가능하지만 텔레그램에서는 아무렇지 않게 전송된다.

'채널' 기능 또한 텔레그램의 핵심이다. 나는 해외 IT 매체의 주요 뉴스를 번역해주는 채널이나, 특정 프로그래밍 언어의 업데이트 소식을 알려주는 채널을 구독하고 있다. 이건 불특정 다수가 모여 시끄럽게 떠드는 카톡 오픈채팅방과는 다른, 양질의 정보를 조용히 받아볼 수 있는 '나만의 정보지' 같은 느낌이다.

그럼에도 망설여지는 이유

가장 큰 단점은 역시 한국에서의 낮은 인지도다. IT 업계나 특정 투자 커뮤니티를 벗어나면 사용자를 찾기 힘들다. 결국 텔레그램으로 대화하려면 "혹시 텔레그램 써?"라고 먼저 물어봐야 하는, 카톡에서는 상상도 할 수 없는 허들이 존재한다.

또한 'n번방 사건'으로 인해 생긴 부정적인 사회적 인식도 무시할 수 없다. 기술 자체는 죄가 없지만, '텔레그램 쓴다'고 하면 어른들께는 괜한 오해를 살 수도 있겠다는 생각이 드는 게 사실이다. 보안 모델에 대한 오해도 있는데, 모든 대화가 종단간 암호화되는 것은 아니고 '비밀 대화' 모드에서만 적용된다는 점도 알아둘 필요가 있다.

후보 2. 라인 (LINE) - 해외에선 인싸, 한국에선 영원한 2인자

https://apps.apple.com/kr/app/%EB%9D%BC%EC%9D%B8-line/id443904275

라인은 네이버의 일본 자회사가 개발한, 사실상 범-국산 앱이다. 일본, 대만, 태국에선 카카오톡을 압도하는 국민 메신저. 나도 일본 여행 갈 때마다 식당 예약을 하거나 현지 친구와 연락할 때 정말 유용하게 썼다.

무엇이 매력적인가?

라인의 정체성은 '캐릭터와 스티커'에 있다. 브라운, 코니 같은 귀여운 캐릭터를 활용한 다채로운 스티커는 텍스트만으로는 표현하기 힘든 감정을 전달하며 대화를 풍성하게 만든다. 아기자기한 것을 좋아하는 사람이라면 카톡의 이모티콘과는 또 다른 매력을 느낄 수 있다.

또한 일본에서는 라인페이, 라인택시, 라인망가 등 생활 전반을 아우르는 '슈퍼앱'으로 자리 잡았다. 해외, 특히 일본과 비즈니스를 하거나 친구가 있다면 라인은 선택이 아닌 필수다.

그럼에도 망설여지는 이유

문제는 여기는 '한국'이라는 점이다. 한국 시장에서 라인은 카카오톡에 완벽히 밀려 만년 2인자 신세다. 내 주소록을 다 뒤져봐도 라인을 쓰는 친구는 손에 꼽을 정도. 결국 '해외 연락용'이라는 꼬리표를 떼지 못하고 있다.

최근 일본에서 터진 대규모 개인정보 유출 사태는 '네이버의 앱'이라는 신뢰도에 큰 타격을 주기도 했다. 기능이 많은 만큼 앱이 다소 무겁고, 카톡만큼이나 여러 서비스가 붙어있어 '깔끔함'을 추구하는 내 기준에는 조금 벗어나는 느낌도 있다.

후보 3. 디스코드 (Discord) - 그들만의 아지트, 커뮤니티의 완성형

https://apps.apple.com/kr/app/discord-%EB%8C%80%ED%99%94-%ED%94%8C%EB%A0%88%EC%9D%B4-%EC%96%B4%EC%9A%B8%EB%A6%AC%EA%B8%B0/id985746746

원래는 게이머들의 음성 채팅 프로그램으로 시작했지만, 이제는 개발, 디자인, 주식 등 온갖 분야의 커뮤니티 아지트가 된 디스코드. 나도 여러 오픈소스 프로젝트와 개발자 커뮤니티에 참여하느라 거의 매일 접속한다.

무엇이 매력적인가?

디스코드의 핵심은 '서버'와 '채널'이다. 특정 주제를 가진 '서버' 안에, 세부 주제별로 '채널'을 만들어 대화방을 분리할 수 있다. 예를 들어 'React 스터디' 서버 안에 '질문답변', '자료공유', '잡담' 채널을 두는 식이다. 이건 모든 대화가 하나의 타임라인에 섞여버리는 단톡방과는 비교할 수 없는 체계성을 제공한다.

압도적인 음성 채팅 품질과 안정성은 디스코드의 상징과도 같다. 친구들과 게임을 하거나, 스터디 그룹원들과 온라인 회의를 할 때 디스코드만큼 쾌적한 환경을 제공하는 툴은 드물다. 코드 블록을 깔끔하게 표시해주는 등 개발자 친화적인 기능은 덤이다.

그럼에도 망설여지는 이유

이건 메신저라기보단 '커뮤니티 툴'에 가깝다. 1:1 대화나 서너 명의 소규모 그룹 채팅도 가능은 하지만, 그런 용도로 쓰기에는 UI가 너무 복잡하고 무겁다. 부모님께 "디스코드 서버 파서 얘기해요"라고 말하는 건 상상하기 어렵다. 초대를 기반으로 한 폐쇄적인 구조도 불특정 다수와 가볍게 연결되는 일반 메신저와는 결이 다르다.

메신저 시장의 미래, 그리고 카카오톡의 다음 행보

결국 모든 불만은 '카카오톡의 독점'에서 비롯된다. 앞으로 메신저 시장은 어떻게 변할까?

최근 화두는 단연 'AI'와 '슈퍼앱'이다. 카카오도 AI 챗봇을 도입하고, 쇼핑, 금융, 모빌리티 등 모든 것을 카톡 안에서 해결하려는 '슈퍼앱' 전략을 가속화하고 있다. 사용자 입장에서는 편리할 수도 있지만, 하나의 앱에 모든 생활이 종속되고, 앱은 점점 무거워지고 복잡해지는 딜레마에 빠진다.

반대편에서는 탈중앙화와 프라이버시를 강조하는 움직임도 있다. 특정 기업의 서버를 거치지 않는 블록체인 기반 메신저나, 더 강력한 익명성을 보장하는 메신저들이 계속해서 등장하고 있다. 아직은 기술적 한계와 낮은 사용성으로 대중화되지 못했지만, 거대 플랫폼에 대한 피로감이 커질수록 새로운 대안을 찾는 움직임은 계속될 것이다.

결론: 완벽한 대체는 없다, 현명한 분산만이 살길

여러 앱을 샅샅이 훑어본 나의 최종 결론은 더 확고해졌다.

"아쉽지만, 현재 한국에서 카카오톡을 100% 대체할 단 하나의 메신저는 없다."

가장 큰 이유는 역시 '네트워크 효과'라는 거대한 벽 때문이다. 나 혼자 좋다고 갈아타 봐야, 내 주변 사람들이 모두 카카오톡을 쓰고 있는 한 고립될 뿐이다. 결국 울며 겨자 먹기로 카카오톡을 메인으로 쓸 수밖에 없는 게 현실이다.

하지만 언제까지고 카카오톡에만 내 모든 디지털 라이프를 맡길 수는 없다. 그래서 나는 '용도에 따른 하이브리드 전략'을 더 적극적으로 실천해보기로 했다.

카카오톡: 어쩔 수 없는 공적인 관계, 가족, 대부분의 친구들과의 '생존용' 소통 창구
텔레그램: 보안이 중요하거나, IT 관련 고급 정보를 얻는 '학습용' 채널 구독
디스코드: 개발자 스터디, 사이드 프로젝트 협업, 게임 등 '취미 및 자기계발용' 아지트

친한 친구들과의 프로젝트 논의는 "이건 디스코드 스레드 파서 체계적으로 하자"고 제안해보고, 여행 계획을 짤 때는 구글맵 연동이 편한 다른 툴을 쓰는 등, 상황에 맞게 주도적으로 소통 방식을 제안하는 용기가 필요하다.

이렇게 용도를 분산하니 카카오톡에 대한 의존도와 피로감이 조금은 줄어드는 느낌이다. 완벽한 탈출은 아니지만, 거대 플랫폼에 끌려다니는 대신 나만의 디지털 라이프를 조금 더 주체적으로 꾸려나가는 첫걸음이 아닐까.

혹시 당신이 추천하는 또 다른 메신저가 있다면 댓글로 알려주시길.

#카카오톡대체 #메신저추천 #텔레그램 #라인 #디스코드 #프라이버시 #디지털디톡스 #IT에세이 #메신저비교

분노의 카카오톡 업데이트, 구버전으로 돌아갈 수 있을까? (iOS 다운그레이드 현실적인 방법과 후기)

worniworni — Thu, 25 Sep 2025 22:26:29 +0900

자고 일어났더니 카카오톡이 변해있었다

오늘 아침, 여느 때와 같이 아이폰을 들고 카톡을 확인하려는데 뭔가 이상했다. 분명 어제 저녁까지 익숙했던 그 화면이 아니었다. 나도 모르는 사이, 밤새 카카오톡이 강제로 업데이트된 것이다. 자동 업데이트 설정을 켜놓은 내 잘못이긴 하지만, 이건 좀 심하지 않나?

새로운 업데이트는 정말 마음에 들지 않았다. 특히 친구 목록과 채팅 목록 사이에 생긴 정체불명의 광고 탭은 최악이었다. 가뜩이나 복잡한데 더 복잡해진 느낌. 30대 중반을 넘어가는 나에게 이런 급격한 변화는 따라가기 벅차다. "아, 예전 버전으로 돌아가고 싶다." 라는 생각이 간절해졌다.

그래서 개발자답게, 아이폰에서 카카오톡 앱 버전을 다운그레이드하는 방법을 집요하게 찾아보기 시작했다.

iOS 앱 다운그레이드, 이론과 현실

결론부터 말하자면, "일반적인 방법으로는 거의 불가능하며, 시도하더라도 매우 복잡하고 위험하다" 이다. 안드로이드처럼 APK 파일을 구해 쉽게 설치하던 시절을 생각하면 안된다. 애플의 폐쇄적인 정책은 보안에는 좋지만 이럴 땐 정말 답답하다.

내가 찾아본 방법은 크게 두 가지였다.

1. 아이튠즈와 구버전 IPA 파일을 이용한 방법 (현재는 막힘)

과거에는 아이튠즈를 통해 앱의 ipa 파일(앱 설치 파일)을 PC에 저장해두고, 필요할 때 구버전으로 다시 설치하는 게 가능했다. 하지만 언젠가부터 애플이 아이튠즈에서 앱스토어 기능을 빼버리면서 이 방법은 완전히 막혔다. 즉, 내 컴퓨터에 예전 카카오톡 ipa 파일을 백업해두지 않았다면 사실상 불가능하다.

2. 전문 프로그램을 이용한 우회 설치 (매우 비추천)

지금 시점에서 유일하게 가능한 방법은 Charles나 iMazing 같은 전문 프로그램을 이용하는 것이다.

Charles: 이건 개발자들이나 쓰는 네트워크 프록시 툴이다. 앱스토어에서 앱을 다운로드할 때 오가는 데이터를 중간에 가로채서, 구버전의 ID 값으로 변조하여 다운로드하는 방식이다. 말만 들어도 복잡하다. 이걸로 카톡 하나 다운그레이드하자고 몇 시간을 쓸 바에는 그냥 적응하고 말지.
iMazing: 아이폰 백업/관리 툴인데, 유료 버전에서 앱 라이브러리 관리 기능으로 구버전 ipa 파일을 추출하고 설치할 수 있다고 한다. 하지만 이 역시 내가 과거에 다운로드했던 버전이 iMazing 라이브러리에 남아있을 때의 이야기다.

가장 큰 문제는, 이 방법들을 쓰려면 구버전 ipa 파일이 필요하다는 점이다. 인터넷에 떠도는 ipa 파일을 다운받아 설치하는 건 정말 위험하다. 악성코드나 바이러스가 심어져 있을 확률이 매우 높다. 내 모든 개인정보가 담긴 카카오톡인데, 출처 불명의 파일을 설치하는 건 미친짓이다.

결론: 그냥 쓰거나, 다른 메신저를 찾거나

한참을 검색하고 여러 가이드를 읽어본 나의 결론은 '포기'다.

개발자인 나조차도 "이건 너무 번거롭고 위험한데?" 라는 생각이 들었다. 시간과 노력을 들여서 얻는 이득보다, 혹시 모를 보안 위협이나 데이터가 날아갈 리스크가 훨씬 크다.

결국 이번 카카오톡의 '무리한' 업데이트는 그냥 참고 쓰는 수밖에 없을 것 같다. 많은 사용자들이 불만을 표출하고 있으니, 다음 업데이트에서는 제발 좀 정신을 차리고 롤백해주길 바랄 뿐이다.

혹시나 나처럼 카카오톡 다운그레이드를 고민했던 분이 있다면, 마음 편히 접고 소중한 시간과 아이폰의 안전을 지키시라고 말하고 싶다. 차라리 이럴 때 텔레그램이나 라인으로 넘어가야 하나 싶은 생각도 든다.

#카카오톡 #카톡업데이트 #카톡다운그레이드 #iOS #아이폰 #앱다운그레이드 #IT에세이

카카오톡의 대변신, '국민 메신저'의 왕좌는 지켜질까?

worniworni — Wed, 24 Sep 2025 23:32:00 +0900

https://www.kakaocorp.com/

매일 아침 눈을 뜨면 가장 먼저 확인하는 앱, 바로 카카오톡이다. 아마 나뿐만 아니라 대한민국 국민 대다수가 그럴 것이다. 이처럼 우리 일상에 깊숙이 자리 잡은 '국민 메신저' 카카오톡이 최근 15년 만의 대대적인 개편을 예고하며 뜨거운 감자로 떠올랐다. AI를 품고, 인스타그램을 닮아간다는 소식에 사용자들의 반응은 기대 반, 우려 반으로 갈리고 있다. 한 명의 개발자이자 매일 카톡을 쓰는 사용자로서 이번 업데이트를 꼼꼼히 살펴보고 내 생각을 정리해 봤다.

무엇이 어떻게 바뀌나?

이번 카카오톡 업데이트의 핵심은 크게 'AI 기능 탑재'와 '사용자 인터페이스(UI) 변경' 두 가지로 요약할 수 있다.

더 똑똑해진 AI 기능
- 대화 요약: 안 읽은 채팅방의 긴 대화를 AI가 요약해 준다. 회의록처럼 녹음된 보이스톡 내용도 요약이 가능하다고 하니, 바쁜 직장인에게는 꽤나 유용한 기능이 될 것 같다.
- 챗GPT 탑재: 채팅 탭에서 바로 챗GPT를 사용하고, 그 결과를 채팅방에 공유할 수 있게 된다. 굳이 다른 앱을 켜지 않아도 되니 편의성은 확실히 좋아질 것이다.
- 자체 AI '카나': 카카오가 개발한 AI 모델 '카나'가 탑재되어 일정 관리, 예약, 상품 추천 등의 개인 비서 역할을 수행할 예정이다.
논란의 중심, UI 변경
- 인스타그램처럼 변하는 친구 탭: 기존의 단순한 이름 목록이었던 친구 탭이 프로필 변경 이력 등을 볼 수 있는 '피드' 형태로 바뀐다. 가장 논란이 큰 부분이다.
- 채팅방 폴더: 최대 100개까지 채팅방을 성격에 맞게 폴더로 분류해서 관리할 수 있게 된다. (이건 정말 환영이다!)
- '지금' 탭 신설: 기존 오픈채팅 탭이 사라지고, 숏폼 영상 위주의 '지금' 탭이 생긴다. 광고와 크리에이터 영상 노출을 늘리려는 의도로 보인다.

카카오는 왜 이런 변화를 선택했을까?

사용자들은 "굳이 왜?"라는 의문을 던지지만, 카카오의 입장에서 이번 개편은 '어쩔 수 없는 선택'이었을 것이다.

가장 큰 이유는 '사용자 이탈'과 '수익성 악화' 다. 월간 활성 사용자 수는 여전히 막강하지만, 사용자들이 카톡에 머무는 시간은 계속 줄어들고 있다. 특히 1020 세대는 카톡을 '공적인 메신저'로 여기고, 친구들과의 사적인 대화는 인스타그램 DM을 더 선호하는 '탈톡' 현상이 가속화되고 있다.

사용자 체류 시간이 줄어들면 광고 노출 기회도, 커머스 소비 기회도 줄어든다. 카카오로서는 어떻게든 사용자들을 더 오래 붙잡아 둘 새로운 동력이 필요했고, 그 해답으로 인스타그램과 틱톡에서 성공이 증명된 '피드'와 '숏폼'을 선택한 것이다. 더 많은 콘텐츠를 소비하게 만들어 광고 매출을 끌어올리겠다는 계산이다.

개발자이자 사용자로서 나의 생각

나 역시 이번 개편 소식을 듣고 많은 생각이 들었다. 개발자로서 카카오의 위기감과 비즈니스적인 선택은 충분히 이해가 간다. 하지만 10년 넘게 카톡을 써온 사용자로서 고개를 갸웃하게 되는 지점도 분명히 있다.

긍정적인 부분: AI와 편의 기능

대화 요약, 챗GPT 연동 같은 AI 기능은 메신저의 본질인 '소통'을 더 효율적으로 만들어 준다. 기술의 발전이 서비스의 핵심 가치를 높이는 좋은 예시다. 실수로 단톡방을 잘못 보낼 뻔한 아찔한 경험이 많았던 나에게 '채팅방 폴더' 기능은 두 팔 벌려 환영할 만한 업데이트다.

우려되는 부분: 정체성의 혼란

가장 큰 우려는 역시 '친구 탭 피드'다. 카카오톡의 친구 관계는 전화번호를 기반으로 자동 형성된다. 여기에는 가족, 친구뿐만 아니라 직장 동료, 거래처 사람 등 내 사생활을 공유하고 싶지 않은 '공적인 관계'가 대다수 포함되어 있다. 이런 환경에서 인스타그램처럼 일상을 공유하는 피드는 사생활 노출에 대한 피로감과 불편함을 유발할 가능성이 매우 높다.

결국 사용자들은 이 피드 기능을 외면하거나, 원치 않는 관계를 정리하기 위해 또 다른 사회적 노동을 해야 할지도 모른다. 카카오는 '수익성'이라는 목표를 위해, 사용자들이 카톡을 '국민 메신저'로 선택했던 가장 큰 이유인 '단순함과 명확한 관계성' 이라는 본질을 흔드는 위험한 도박을 하는 것은 아닐까?

결론: '모두의 메신저'에서 '누군가의 SNS'로?

카카오는 메신저를 넘어 '플랫폼'으로 도약하려 한다. 그 방향성에는 동의하지만, 방법론에는 아쉬움이 남는다. 다른 성공한 서비스를 따라 하기보다, 카카오톡만이 가진 강력한 기반 위에서 사용자들이 진정으로 원하는 것이 무엇인지 더 깊이 고민했어야 하지 않을까.

이번 개편이 카카오에게 새로운 성장 동력을 가져다줄지, 아니면 '국민 메신저'라는 타이틀에 균열을 가게 할지는 지켜봐야 할 것이다. 부디 이번 변화가 사용자의 목소리에 귀 기울이며 더 나은 방향으로 다듬어지기를, 그래서 앞으로도 오랫동안 내 스마트폰 첫 화면을 지켜주기를 바라본다.

트럼프가 불붙인 '타이레놀-자폐증' 논란, 어디까지 믿어야 할까?

worniworni — Wed, 24 Sep 2025 23:18:21 +0900

https://edition.cnn.com/2025/09/22/health/trump-autism-announcement-cause-tylenol

트럼프가 불붙인 '타이레놀-자폐증' 논란, 어디까지 믿어야 할까?

※ 본 글은 특정 약품에 대한 추천이나 비방이 아니며, 의학적 자문을 대체할 수 없습니다. 모든 의학적 결정은 전문가와 상의해야 하며, 이 글은 개인적인 궁금증을 해소하기 위해 여러 정보를 찾아보고 정리한 내용입니다.

얼마 전 뉴스를 보다가 깜짝 놀랐다. 미국 트럼프 전 대통령이 임신 중 타이레놀 복용이 자폐아 출산 위험을 높일 수 있다는 충격적인 발표를 했다는 소식이었다. 나도 평소에 두통이 있으면 꽤 자주 찾는 약이고, 주변에도 임신을 준비하거나 임신 중인 지인들이 많아서 남의 일 같지 않았다. '국민 진통제'라고 불릴 만큼 흔한 약인데, 갑자기 이런 논란의 중심에 서다니. 도대체 무슨 일인지, 어디까지 믿어야 할지 혼란스러워서 직접 여러 기사와 자료를 찾아보기로 했다.

논란의 시작: 트럼프의 발언

사건의 발단은 트럼프 전 대통령의 기자회견이었다. 그는 "임신 중 타이레놀 복용이 자폐아 위험을 높이는 것으로 나타났다"며, FDA(미국 식품의약국)를 통해 의사들에게 이 사실을 통보할 것이라고 밝혔다. 이 발언의 근거는 최근 한 국제 학술지에 실린 논문이었다.

근거가 된 논문: 뉴욕 마운트시나이 의대팀이 기존 46개의 연구를 재분석한 결과, 다수의 연구(27개)에서 임신 중 아세트아미노펜(타이레놀 성분) 복용이 태아의 자폐 및 ADHD 위험을 높인다는 연관성이 나타났다는 내용이다. 하지만 이 논문은 새로운 실험 결과가 아니라, 기존 연구들을 다시 분류하고 분석한 것이었다.

이 발표는 미국 내에서 자폐 진단율이 급증하는 상황과 맞물려 더 큰 파장을 일으켰다.

"과학적 근거 부족" - 반대하는 목소리

트럼프의 발언이 나오자마자 의학계와 전문가들은 강하게 반발했다.

제조사의 입장: 타이레놀 제조사인 켄뷰(Kenvue)는 "지난 10여 년간의 엄격한 연구들은 아세트아미노펜과 자폐증 간의 연관성을 입증할 증거가 없음을 확인했다"며 공식적으로 반박했다.
주요 의학계의 견해: 미국산부인과학회(ACOG), 영국 국민건강서비스(NHS) 등 전 세계 주요 의료 단체들은 여전히 임신 중에도 안전하게 복용할 수 있는 몇 안 되는 진통제가 아세트아미노펜이라고 말한다. 오히려 임신 중 고열이나 통증을 방치하는 것이 태아에게 더 위험할 수 있다는 것이다. 임신 초기 고열은 기형을 유발할 수 있는데, 이때 타이레놀 외에는 마땅한 대체재가 없다는 국내 산부인과 교수의 의견도 있었다.
대규모 연구 결과: 스웨덴에서 250만 명, 일본에서 20만 명을 대상으로 한 대규모 연구에서도 타이레놀 복용과 자폐아 출산 사이에 의미 있는 연관성이 발견되지 않았다. 특히 형제자매를 비교했을 때는 약의 영향이 거의 없어, 유전적 요인이 더 클 수 있음을 시사했다.

전문가들은 과학적으로 명확한 인과관계가 증명되지 않은 상태에서 대통령의 발언이 불필요한 불안감과 죄책감만 자극한다고 비판했다.

신중론: "그래도 조심해서 나쁠 건 없다"

물론 모든 의견이 '완전히 안전하다'는 쪽으로만 쏠린 것은 아니다.

FDA의 입장: FDA는 "관련이 있을 수 있다는 증거가 보고됐다"면서도 "아직 인과관계가 입증되지 않았고, 과학적 논쟁이 진행 중"이라는 신중한 태도를 보였다.
연구팀의 권고: 논란의 시발점이 된 연구팀조차 "타이레놀이 자폐의 원인"이라고 단정하지 않았다. 그들은 "최소한의 용량을, 가장 짧은 기간 동안, 의사와 상의해 사용하는 것이 좋다"고 권고했다.

결국 '아직 명확히 밝혀진 것은 없으니, 굳이 필요하지 않다면 피하고, 꼭 먹어야 한다면 최소한으로 사용하라'는 입장으로 볼 수 있다.

그래서 내 생각은?

여러 자료를 찾아보고 나니 머릿속이 더 복잡해지는 기분이다. 한쪽에서는 괜찮다고 하고, 다른 한쪽에서는 조심하라고 하니 말이다. 특히 '대통령'이라는 직책을 가진 사람의 발언이라 무게감이 다르게 느껴지는 것도 사실이다.

하지만 나는 의학 전문가가 아니기에, 결국 가장 신뢰할 수 있는 것은 수십 년간 쌓여온 데이터와 주류 의학계의 의견이라고 생각한다. 대부분의 전문가들은 "필요하다면 먹는 것이 먹지 않아서 생기는 위험(고열 등)보다 낫다"고 말한다.

이번 논란을 통해 내가 내린 결론은 이렇다.

일단 패닉에 빠지지 말자. 수십 년간 수많은 임산부가 복용해왔고, 대부분의 연구에서 심각한 연관성이 발견되지 않았다.
하지만 약은 약이다. 어떤 약이든 100% 안전하다고 맹신해서는 안 된다. 특히 임신 중이라면 더욱 그렇다.
가장 중요한 것은 '전문가와 상의'하는 것이다. 몸이 아프면 혼자 판단하지 말고, 의사나 약사를 찾아가 상담하는 것이 정답이다. 그리고 그들의 권고에 따라 '필요한 경우, 최소한의 용량을, 최단 기간' 복용하는 원칙을 지키는 것이 현명해 보인다.

결국 이번 일은 우리에게 아주 기본적인 사실을 다시 한번 일깨워준 셈이다. 세상에 '무조건'은 없고, 특히 건강과 관련된 문제에 있어서는 항상 신중하고 현명한 판단이 필요하다는 것. 나도 앞으로 약을 먹을 때, 특히 소중한 사람이 아플 때는 이 점을 꼭 기억해야겠다.

참고 자료:

조선일보: https://www.chosun.com/economy/science/2025/09/23/MG6ANSSRQFACDA5U6VYMRMTW2E/
BBC 코리아: https://www.bbc.com/korean/articles/cn5q1q52ny2o
CNN: https://edition.cnn.com/2025/09/22/health/trump-autism-announcement-cause-tylenol

일본 증시 왜 이렇게 오를까? 2025년 니케이 지수 폭등 이유 5가지 (ft. 워렌 버핏)

worniworni — Tue, 23 Sep 2025 23:05:37 +0900

요즘 재테크에 조금이라도 관심 있는 사람이라면 계속 들려오는 소식이 있다. 바로 일본 '니케이 지수'가 연일 사상 최고치를 경신하고 있다는 뉴스다. 내가 경제 공부를 처음 시작할 때만 해도 일본은 '잃어버린 20년', '잃어버린 30년' 같은 디플레이션의 상징과도 같은 나라였는데, 대체 그동안 무슨 일이 있었던 걸까? 마치 오랫동안 잠자던 거인이 깨어난 듯한 일본 증시의 이례적인 폭등, 그 이유가 궁금해서 개발자답게 한번 집요하게 파고들어 봤다.

1. 기업 체질 개선: "주주님, 이제 눈치 보겠습니다"

가장 근본적인 변화는 일본 기업들 자체에서 시작됐다. 이전까지 일본 기업들은 현금을 쌓아두기만 하고 주주환원에는 인색하다는 평가가 많았다. 하지만 몇 년 전부터 도쿄증권거래소(TSE)가 직접 나서서 주가순자산비율(PBR)이 1배 미만인, 즉 회사의 자산 가치보다도 주가가 낮은 기업들에게 '주가 좀 관리하라'고 강력하게 압박하기 시작했다.

효과는 확실했다. 기업들은 부랴부랴 자사주를 매입하고 배당금을 늘리는 등 주주가치를 높이기 위한 정책들을 쏟아냈다. '회사는 주주의 것'이라는 자본주의의 기본 원칙이 드디어 일본 증시에도 본격적으로 작동하기 시작한 것이다.

2. 엔저 효과: 수출 기업들의 끝나지 않는 축제

두 번째는 우리에게도 익숙한 '엔저', 즉 이례적인 엔화 약세 현상이다. 엔화 가치가 떨어지니 글로벌 시장에서 도요타 같은 일본 수출 기업들의 가격 경쟁력은 날개를 달았다.

쉽게 말해, 미국에서 1만 달러짜리 자동차를 팔았을 때 예전에는 110만 엔을 벌었다면, 이제는 150만 엔을 버는 시대가 된 것이다. 똑같은 물건을 팔아도 엔화로 환산한 실적이 폭발적으로 증가하니, 관련 기업들의 주가가 오르는 것은 당연한 수순이었다.

3. '투자의 신' 워렌 버핏의 선택

아무리 좋은 환경이 마련되어도 시장의 관심을 끌어올 '촉매제'가 필요하다. 그 역할을 한 것이 바로 '투자의 신' 워렌 버핏이다. 버핏은 몇 년 전부터 일본의 5대 종합상사 지분을 꾸준히 늘려왔고, 공개적으로 "일본은 믿을 수 없을 정도로 저평가되어 있다"고 언급했다.

세계적인 투자 구루의 이런 행보는 전 세계 투자자들에게 '일본으로 가라'는 강력한 신호탄이 되었다. 그를 따라 막대한 외국인 자금이 일본 증시로 밀려들어오면서 지수 상승을 견인했다.

4. 드디어 끝난 디플레이션

수십 년간 일본 경제를 짓눌렀던 '디플레이션'의 시대가 끝나고, 드디어 완만한 '인플레이션'의 시대로 접어들었다. 물가가 오르니 기업들은 제품 가격을 인상하며 매출과 이익을 늘릴 수 있게 되었다. 소비자들 역시 '오늘보다 내일이 더 비싸다'는 생각에 지갑을 열기 시작했다. 돈을 은행에 쌓아두면 가치가 떨어지니, 자연스럽게 주식 시장으로 눈을 돌리는 사람들도 많아졌다.

5. 일본 개미들의 참전: 새로운 NISA 제도

마지막 퍼즐은 일본 개인 투자자들의 귀환이다. 2024년부터 일본 정부는 파격적인 세제 혜택을 주는 개인종합자산관리계좌, 이른바 '신(新) NISA' 제도를 시행했다. 연간 투자 한도를 크게 늘리고 비과세 혜택을 영구적으로 제공하면서, 은행 예금에 묶여 있던 막대한 규모의 개인 자금이 주식 시장으로 흘러 들어오는 거대한 물길을 만들었다.

결론: 구조적 변화의 시작

정리해 보면, 2025년 현재의 니케이 지수 상승은 단순히 엔저 효과 하나만으로 설명할 수 없는, 복합적이고 구조적인 변화의 결과물이다. 기업의 체질 개선, 유리한 환율 환경, 글로벌 투자의 관심, 경제 정상화, 그리고 개인 투자자의 참여라는 5개의 톱니바퀴가 완벽하게 맞물려 돌아가고 있는 셈이다.

물론 이미 많이 오른 만큼 조정에 대한 우려도 있지만, 많은 전문가들은 이것이 '잃어버린 30년'을 끝내고 새로운 시대로 나아가는 일본 경제의 장기적인 상승 신호일 수 있다고 분석한다. 나 또한 이 역사적인 변화의 흐름을 유심히 지켜보며 다음 투자 기회를 고민해 봐야겠다.

※ 본 글은 특정 종목에 대한 매수/매도 추천이 아니며, 모든 투자의 책임은 투자자 본인에게 있습니다. 지극히 개인적인 분석과 의견을 기록한 글입니다.

리스테린, 가그린, 테라브레스 전격 비교: 개발자처럼 성분 파헤쳐 본 나에게 맞는 가글액 찾기

worniworni — Tue, 23 Sep 2025 22:57:33 +0900

나도 모르게 매일 쓰는 물건들이 있다. 가글액, 즉 구강청결제도 그중 하나다. 양치 후 상쾌함을 더하기 위해 무심코 사용해왔는데, 문득 궁금해졌다. '리스테린, 가그린, 테라브레스... 다들 좋다고 광고하는데, 대체 뭐가 다른 거지?' 그냥 느낌 따라, 혹은 세일하는 제품을 사서 쓰곤 했는데, 개발자로서 이건 참을 수 없는 일이다. 그래서 작정하고 각 가글액의 스펙, 즉 성분과 작동 원리를 파헤쳐 보기로 했다.

가글액의 양대 산맥: 작동 원리의 차이

시중에 나온 수많은 가글액은 크게 두 가지 핵심 성분으로 나뉜다. 바로 이 성분의 차이가 사용법과 효과의 차이를 만든다.

에센셜 오일 (Essential Oil) 계열: 대표 주자는 리스테린.
CPC (세틸피리디늄염화물수화물) 계열: 대표 주자는 가그린, 그리고 국내 정식 출시된 테라브레스.

이 둘의 가장 결정적인 차이점부터 짚고 넘어가자.

CPC 계열 가글액은 치약의 계면활성제(거품 내는 성분)와 만나면 치아 변색을 유발할 수 있다.

그래서 가그린 같은 CPC 계열 제품 설명서를 자세히 보면 "양치 후 30분 뒤에 사용"하라는 문구가 있다. 바쁜 아침에 양치하고 30분을 기다렸다가 가글을 해야 한다니, 생각보다 훨씬 번거로운 일이다. 반면, 에센셜 오일 기반의 리스테린은 이 문제에서 자유로워 양치 직후 바로 사용해도 괜찮다.

이것만 알아도 나에게 맞는 제품을 선택하는 데 큰 도움이 된다. 이제 각 제품을 좀 더 깊이 들여다보자.

1. 리스테린 (Listerine): 강력한 한 방의 원조

https://www.listerine.kr/

핵심 성분: 유칼립톨, 멘톨 등 에센셜 오일
장점:
- 양치 후 바로 사용 가능: 바쁜 현대인에게 가장 큰 장점. 기다릴 필요가 없다.
- 강력한 살균력: 식물 유래 성분으로 입 속 유해균을 효과적으로 억제한다. 140년 넘는 역사가 그 효과를 증명한다.
단점:
- 강렬한 자극: 특유의 '입안이 타들어 가는' 듯한 강력한 자극은 호불호가 극명하게 갈린다. 처음 사용하는 사람은 눈물이 찔끔 날 정도. 물론 이 맛에 중독되는 사람도 많다.
- 알코올: 일부 제품에 포함된 알코올(에탄올) 성분이 구강 건조를 유발할 수 있다. (물론 '마일드' 제품군처럼 알코올이 없는 버전도 있다.)
추천 대상: 강력한 상쾌함과 즉각적인 개운함을 원하며, 양치 후 바로 가글하는 습관을 가진 사람. 자극이 부담스럽다면 '쿨민트 마일드'나 '그린티 마일드' 같은 무알코올 제품으로 시작해 보는 것을 추천한다.

2. 가그린 (Garglin): 색소 없는 국산 대표 주자

https://www.dapharm.com/ko/brand/contents/OCG

핵심 성분: CPC (세틸피리디늄염화물수화물)
장점:
- 부드러운 사용감: 리스테린에 비해 자극이 훨씬 덜해 가글 초심자도 부담 없이 사용할 수 있다.
- 무색소: "가그린은 색소가 들어있지 않습니다"라는 광고 카피처럼, 색소가 없어 옷에 튀어도 걱정이 덜하다는 소소한 장점이 있다.
단점:
- 양치 후 30분 대기: 앞서 말했듯, 치약 성분과의 반응으로 인한 치아 변색 가능성 때문에 바로 사용할 수 없다는 점이 가장 큰 단점이다.
추천 대상: 자극적인 가글이 싫고, 양치와 가글 사이에 시간적 여유를 가질 수 있는 사람.

3. 테라브레스 (TheraBreath): 이름은 같은데, 속은 다르다?

https://www.oliveyoung.co.kr/store/display/getBrandShopDetail.do?onlBrndCd=A002981

핵심 성분: CPC (국내 정식 출시 제품 기준)
진실: 많은 사람들이 '입냄새 제거 끝판왕'으로 알고 있는 테라브레스는 사실 미국 직구 제품이다. 직구 제품의 핵심 성분은 'OXYD-8'이라는 특허 물질로, 입냄새 원인균을 직접 공격해 효과가 뛰어나다. 하지만 이 성분은 국내 식약처 허가를 받지 못했다.
국내판의 실체: 그래서 국내에 정식으로 유통되는 테라브레스는 OXYD-8 성분 대신, 가그린과 동일한 CPC를 핵심 성분으로 사용한다. 즉, '한국판 테라브레스'는 사실상 '가그린'과 거의 같은 제품이라고 봐도 무방하다.
단점: 가그린과 마찬가지로 양치 후 30분 대기가 필요하다.
추천 대상: '테라브레스'라는 브랜드에 대한 선호가 있고, CPC 계열의 부드러운 사용감을 원하는 사람. 단, 해외 직구 제품과 같은 입냄새 제거 효과를 기대해서는 안 된다.

한눈에 보는 가글액 비교

특징	리스테린	가그린	테라브레스 (국내판)
주요 성분	에센셜 오일	CPC	CPC
양치 후 바로 사용	가능	불가능 (30분 후)	불가능 (30분 후)
자극	강함	중간~약함	중간~약함
특징	강력한 살균, 편리함	무색소, 부드러움	브랜드 명성
알코올 유무	제품별로 다름	제품별로 다름	제품별로 다름

결론: 나의 최종 선택은?

각 제품의 스펙을 꼼꼼히 비교해 보니, 나의 선택은 명확해졌다.

나에게 가장 중요한 것은 '편의성'이었다. 양치질의 마무리는 가글이라고 생각하는데, 그 마무리를 위해 30분을 기다려야 한다는 것은 라이프스타일에 맞지 않았다. 결국 양치 직후 바로 사용할 수 있는 에센셜 오일 기반의 '리스테린'이 나에게 가장 합리적인 선택이었다.

물론 리스테린 특유의 강한 자극이 부담될 때도 있지만, 그럴 땐 알코올이 없는 '마일드' 제품을 사용하면 충분히 만족스러웠다.

무심코 쓰던 가글액 하나에도 이렇게 다른 과학적 원리와 사용법이 숨어있다는 사실이 흥미로웠다. 혹시 어떤 가글을 써야 할지 고민하고 있다면, 단순히 브랜드나 가격만 보지 말고, 나의 양치 습관과 라이프스타일에 맞는 '핵심 성분'이 무엇인지 확인해 보는 것은 어떨까?

※ 본 글은 특정 제품에 대한 추천이 아니며, 정보 제공을 목적으로 작성되었습니다. 개인의 구강 상태에 따라 전문가와 상담하는 것이 가장 좋습니다.

맥북 브라우저 유목민 생활 청산 후기: 사파리, 크롬, 파이어폭스 다 써보고 엣지(Edge)로 정착한 이유

worniworni — Sun, 21 Sep 2025 17:17:04 +0900

개발자에게 웹 브라우저는 단순한 인터넷 창이 아니라, 가장 중요한 연장이자 일터다. 맥북을 사용하면서 오랫동안 '브라우저 유목민'으로 살았다. 애플 생태계의 심장인 '사파리'부터 개발자들의 표준처럼 여겨지는 '크롬', 그리고 꿋꿋한 매니아층을 가진 '파이어폭스'까지. 각각의 브라우저를 메인으로 사용하며 느꼈던 장단점과, 결국 내가 왜 마이크로소프트의 '엣지'에 정착하게 되었는지 그 여정을 풀어보려 한다.

1. 애플의 심장, 사파리 (Safari)

맥북을 처음 켜면 자연스럽게 가장 먼저 손이 가는 브라우저다.

장점:
- 미친 최적화와 배터리: 역시 애플이 만든 브라우저답게 맥OS와의 통합과 최적화는 타의 추종을 불허한다. 동일한 작업을 해도 다른 브라우저에 비해 월등히 적은 배터리를 소모하는 것이 체감된다. 노트북을 들고 외부에서 작업하는 일이 잦다면 정말 큰 장점이다.
- 빠릿한 속도와 부드러움: 페이지 로딩 속도나 스크롤링의 부드러움은 단연 최고 수준이다. 트랙패드로 스크롤할 때의 그 손에 착 감기는 느낌은 사파리에서 가장 빛을 발한다.
- 강력한 개인정보 보호: 애플의 개인정보 보호 정책은 브라우저에도 그대로 적용된다. 지능형 추적 방지(ITP) 기능은 알아서 웹사이트의 추적을 막아주어 든든하다.
단점:
- 아쉬운 확장 프로그램 생태계: 크롬에 비하면 확장 프로그램의 수가 절대적으로 부족하다. 개발에 필요한 여러 도구들이나 편리한 확장 기능들을 찾기 어렵거나, 있더라도 업데이트가 늦는 경우가 많다.
- 개발자 도구의 불편함: 크롬 개발자 도구에 익숙해져 있다면 사파리의 개발자 도구는 여러모로 불편하게 느껴진다. 기능이 부족한 것은 아니지만 직관성이나 편의성 면에서 아쉬움이 남는다.
- 가끔 보이는 호환성 문제: 웹 표준을 잘 지키지만, 가끔 특정 사이트나 웹 애플리케이션에서 레이아웃이 깨지거나 기능이 제대로 동작하지 않는 경우가 종종 발생한다. 특히 국내 웹 환경에서는 더 그렇다.

2. 개발자의 표준, 구글 크롬 (Google Chrome)

한때 나의 메인 브라우저이자, 아마 지금도 가장 많은 개발자들이 사용하고 있을 브라우저.

장점:
- 압도적인 확장 프로그램 생태계: '이런 것도 있을까?' 싶은 기능의 확장 프로그램은 웬만하면 다 있다. 개발 생산성을 높여주는 수많은 도구들을 마음껏 쓸 수 있다는 것은 대체 불가능한 장점이다.
- 강력한 개발자 도구: 현존하는 브라우저 중 가장 강력하고 사용하기 편한 개발자 도구를 제공한다. 프론트엔드 개발자라면 크롬 개발자 도구 없이는 일이 불가능할 정도.
- 완벽에 가까운 호환성: 시장 점유율 1위 브라우저답게, 크롬에서 안 돌아가는 사이트는 없다고 봐도 무방하다.
단점:
- 악명 높은 메모리, 배터리 소모: '메모리 잡아먹는 괴물'이라는 별명은 괜히 생긴 게 아니다. 탭 몇 개만 열어놔도 시스템 리소스를 엄청나게 차지하며, 맥북의 배터리를 쭉쭉 빨아먹는다. 팬이 굉음을 내며 돌기 시작하면 범인은 십중팔구 크롬이다.
- 개인정보에 대한 찝찝함: 구글의 비즈니스 모델을 생각하면, 내 검색 기록과 사용 패턴이 고스란히 구글에 수집되고 있다는 찝찝함을 지울 수 없다.

3. 자유의 상징, 파이어폭스 (Firefox)

오픈소스와 개인정보 보호를 중시하는 사용자들의 굳건한 지지를 받는 브라우저.

장점:
- 강력한 개인정보 보호: 크롬과 달리 사용자 데이터 수집에 의존하지 않으며, 추적 방지 기능이 매우 강력하다.
- 준수한 성능과 리소스 관리: 크롬보다 가볍고, 사파리만큼은 아니지만 꽤 괜찮은 리소스 관리 능력을 보여준다.
- 컨테이너 탭: 여러 계정을 동시에 로그인하거나, 개인적인 용도와 업무 용도의 탭을 분리해서 사용할 수 있는 '컨테이너 탭' 기능은 파이어폭스만의 킬러 기능이다.
단점:
- 미묘한 호환성 문제: 점유율이 낮다 보니 아주 가끔, 정말 가끔 웹사이트에서 문제가 발생할 때가 있다.
- 살짝 이질적인 UI: 맥OS에 완벽하게 녹아든다는 느낌보다는, 파이어폭스만의 독자적인 디자인을 고수하는 느낌이 강하다.

4. 나의 최종 선택, 마이크로소프트 엣지 (Microsoft Edge)

"맥북에서 굳이 윈도우 만들던 회사 브라우저를?" 처음에는 나도 이런 편견을 가졌다. 하지만 속는 셈 치고 써본 엣지는 그야말로 신세계였다.

크롬의 장점은 그대로, 단점은 개선: 엣지는 크롬과 동일한 크로미움 엔진을 기반으로 한다. 따라서 크롬의 모든 확장 프로그램을 그대로 사용할 수 있고, 웹 호환성도 동일하며, 개발자 도구 역시 거의 똑같다. 그런데 놀랍게도 크롬의 고질병인 메모리 및 배터리 소모 문제는 훨씬 덜하다. 마이크로소프트의 최적화 기술이 들어간 덕분인지, 체감상 사파리 다음으로 가볍고 쾌적했다.
엣지만의 편리한 기능들:
- 세로 탭: 가로로 길어지는 탭바 대신, 화면 왼쪽에 세로로 탭 목록을 볼 수 있는 기능은 정말 혁신적이다. 수많은 탭을 열어놓고 작업하는 나 같은 사람에게는 탭 제목을 한눈에 파악할 수 있어 생산성이 엄청나게 올라간다.
- 컬렉션: 웹서핑 중 찾은 자료나 링크, 이미지들을 주제별로 쉽게 모아둘 수 있는 기능이다. 나중에 참고할 자료를 정리해두기에 매우 유용하다.
- 프로필 관리: 개인용, 업무용 등 프로필을 분리하여 사용하기가 크롬보다 훨씬 직관적이고 편리하다.

결론: 최고의 조합을 찾아서

나의 결론은 명확했다. 엣지는 크롬의 강력한 기능과 호환성, 확장 프로그램 생태계를 그대로 가져오면서, 사파리의 장점인 최적화와 가벼움을 상당 부분 구현해 낸 브라우저다. 여기에 세로 탭과 같은 엣지만의 킬러 기능까지 더해지니, 더 이상 다른 브라우저를 기웃거릴 필요가 없었다.

물론 지금도 가끔 웹페이지 결제처럼 중요한 작업에는 가장 안정적인 사파리를 사용하고, 파이어폭스의 컨테이너 탭이 그리울 때도 있다. 하지만 개발과 자료 조사를 포함한 대부분의 주력 작업은 이제 모두 엣지에서 이루어진다.

혹시 나와 같이 맥북에서 쓸만한 브라우저를 찾아 헤매는 유목민이 있다면, 편견을 버리고 딱 일주일만 엣지를 메인으로 써보길 권한다. 아마 생각지도 못했던 만족감을 얻게 될 것이다.

#맥북브라우저 #엣지 #크롬 #사파리 #파이어폭스 #브라우저추천 #개발자 #macOS #Edge #Chrome #Safari

스케일링 후 찾아온 시린이, 센소다인 치약으로 광명 찾은 후기 (종류, 성분, 효과 총정리)

worniworni — Fri, 19 Sep 2025 23:03:58 +0900

얼마 전, 큰맘 먹고 치과에 가서 스케일링을 받았다. 치석이 말끔하게 제거된 개운함도 잠시, 얼마 지나지 않아 지옥이 시작됐다. 찬물을 마실 때마다 온몸이 찌릿하고, 심지어 차가운 공기가 입에 들어오기만 해도 이가 시큰거렸다. 이게 바로 말로만 듣던 '시린이'구나. 건강하자고 한 스케일링이 고통을 안겨주다니, 억울한 마음까지 들었다.

주변에 앓는 소리를 했더니 다들 약속이나 한 듯 "센소다인 써봐"라고 추천했다. 광고에서 하도 많이 봐서 이름은 익숙했지만, '시린이 치약이 뭐 다를 게 있겠어?'라며 반신반의했다. 하지만 고통에서 벗어나고픈 마음이 더 컸기에, 퇴근길에 바로 약국으로 달려갔다. 그리고 개발자답게, 그냥 사서 쓰는 게 아니라 이 녀석의 정체를 제대로 파헤쳐 보기로 했다.

시린이, 도대체 왜 생기는 걸까?

먼저 시린이의 원인부터 간단히 알아봤다. 우리 치아는 단단한 법랑질(에나멜) 안쪽에 상아질(덴틴)이라는 부위가 있다. 이 상아질에는 수만 개의 미세한 '상아세관'이 신경과 연결되어 있는데, 잘못된 칫솔질이나 잇몸 질환, 스케일링 등으로 법랑질이 마모되거나 잇몸이 내려가 상아질이 노출되면, 이 상아세관을 통해 외부 자극이 그대로 신경에 전달되어 찌릿한 통증을 느끼게 되는 것이다.

센소다인은 어떻게 시린이를 막아줄까?

센소다인은 크게 두 가지 원리로 이 시린 증상을 막아준다.

신경 자극을 둔화시키는 방법 (질산 칼륨)
센소다인 '멀티케어', '후레쉬' 등에 포함된 질산 칼륨(Potassium Nitrate) 성분이 치아 내부로 흡수되어 노출된 상아세관 주변의 신경을 감싸고, 통증 자극이 뇌로 전달되는 것을 막아준다. 신경을 일시적으로 둔감하게 만들어 통증을 못 느끼게 하는 원리다.
노출된 부위를 막아주는 방법 (플루오르화석 등)
센소다인 '리페어 앤 프로텍트'의 플루오르화석(Stannous Fluoride)이나 '오리지널'의 염화스트론튬(Strontium Chloride) 같은 성분은 노출된 상아세관 표면에 방어벽, 즉 보호층을 형성한다. 아예 자극이 상아세관을 통해 신경까지 전달되지 못하도록 원천 차단하는 방식이다.

그래서 뭘 사야 할까? 센소다인 종류별 특징

막상 사러 가니 종류가 너무 많아 또 한 번의 결정 장애가 왔다. 내가 조사한 내용을 바탕으로 주요 제품 라인업을 정리해봤다.

센소다인 멀티케어 (Multi-Care)
- 특징: 시린이 완화와 구강 종합 관리를 한 번에. 가장 대중적인 모델.
- 주요 성분: 질산 칼륨.
- 효과: 신경 둔화를 통해 시린 증상을 완화하고, 충치 예방 및 구취 제거 등 복합적인 구강 관리에 적합하다.
센소다인 후레쉬 (Fresh)
- 특징: 멀티케어와 유사하나, 이름처럼 상쾌한 민트향이 더 강하다.
- 주요 성분: 질산 칼륨.
- 효과: 시린이 완화와 함께 강력한 상쾌함을 원하는 사람에게 좋다.
센소다인 리페어 앤 프로텍트 (Repair & Protect)
- 특징: 손상된 부위를 '재건'하고 '보호'하는 컨셉의 프리미엄 라인.
- 주요 성분: 플루오르화석 (노바민 기술).
- 효과: 노출된 상아세관에 직접 침투해 보호층을 형성, 보다 근본적인 시린이 방어막을 만들어준다.
센소다인 화이트닝 (Whitening)
- 특징: 시린이 케어와 치아 미백을 동시에 원하는 사람들을 위한 제품.
- 주요 성분: 질산 칼륨.
- 효과: 낮은 연마도의 미백 성분으로 치아 손상을 최소화하면서 착색을 제거해 준다.

결론: 꾸준함이 답이다

나는 가장 기본인 '멀티케어'로 시작했다. 처음 며칠은 긴가민가했지만, 일주일 정도 꾸준히 사용하니 정말 신기하게도 찬물을 마실 때의 찌릿함이 눈에 띄게 줄어들었다. '플라시보 효과인가?' 싶었지만, 과학적 원리를 알고 나니 믿음이 갔다.

센소다인은 시린이의 '치료제'라기보다는, 통증을 완화하고 관리해 주는 '기능성 케어 제품'에 가깝다. 한두 번 사용으로 마법 같은 효과를 기대하기보다는, 자신에게 맞는 제품을 선택해 꾸준히 사용하는 것이 중요하다. 만약 증상이 계속 심하다면 당연히 치과에 가서 전문적인 진단을 받아야 한다.

스케일링 후 예기치 않게 찾아온 시린이 덕분에, 치약 하나도 꼼꼼히 따져보고 고르는 새로운 습관이 생겼다. 혹시 나와 같은 고통을 겪고 있다면, 오늘부터 센소다인으로 '치약 유목민' 생활을 청산해 보는 건 어떨까.

참고 자료 (References)

센소다인 공식 홈페이지 (haleonhealthpartner.com)
각종 온라인 의약 정보 사이트 및 뉴스 기사 (mustjin.co.kr, zdnet.co.kr, medifonews.com 등)

롯데카드 해킹의 원흉, CVE-2017-10271 취약점 기술 분석 (Oracle WebLogic RCE)

worniworni — Fri, 19 Sep 2025 22:31:22 +0900

지난번 롯데카드 해킹 사태에 대한 글에서는 '관리 부실로 인한 패치 누락'을 지적하며 분통을 터뜨렸다. 오늘은 한 걸음 더 깊이 들어가, 그 '누락된 패치'가 막았어야 할 취약점, CVE-2017-10271에 대해 기술적으로 분석해보고자 한다. 대체 어떤 허점이 있었기에 대한민국 금융사의 서버가 속수무책으로 뚫릴 수 있었을까.

1. CVE-2017-10271 취약점 개요

명칭: Oracle WebLogic Server WLS-WSAT Component Deserialization RCE
요약: 오라클 웹로직 서버의 WLS-WSAT(Web Services Atomic Transactions) 컴포넌트에서 발생하는 역직렬화(Deserialization) 취약점.
위험도: CVSS 3.0 기준 7.5점 (High). 인증(Authentication) 없이 원격(Remote)으로 코드 실행(Code Execution)이 가능해 RCE 취약점으로 분류된다.

가장 무서운 부분은 '인증 없이(Unauthenticated)'라는 점이다. 공격자는 아이디나 패스워드 없이, 해당 서버에 네트워크 요청만 보낼 수 있으면 서버를 완전히 장악할 수 있다는 뜻이다. 인터넷에 연결된 서버라면 사실상 전 세계의 모든 공격자에게 문을 열어준 것과 마찬가지다.

2. 공격 원리: 신뢰가 낳은 비극, XML 역직렬화

이 취약점의 핵심에는 '안전하지 않은 역직렬화(Insecure Deserialization)'가 있다.

직렬화(Serialization): 프로그램이 사용하는 데이터 객체(Object)를 파일로 저장하거나 네트워크로 전송하기 위해 연속적인 바이트(byte) 형태로 변환하는 과정. (예: Java 객체를 XML이나 JSON 문자열로 변환)
역직렬화(Deserialization): 직렬화된 바이트 형태의 데이터를 다시 프로그램이 사용할 수 있는 원래의 객체 형태로 복원하는 과정.

CVE-2017-10271은 웹로직 서버가 클라이언트로부터 받은 XML 데이터를 역직렬화하는 과정에서 발생한다. 서버는 /wls-wsat/CoordinatorPort와 같은 특정 엔드포인트로 들어온 XML 요청을 처리하는데, 이때 XML 내부에 포함된 <work:WorkContext> 태그의 내용을 검증 없이 그대로 신뢰하고 XMLDecoder를 통해 객체로 복원해버린다.

공격자는 바로 이 점을 노린다. 서버를 속이기 위해 악의적인 명령이 담긴 XML 데이터를 만들어 요청에 담아 보낸다. 서버는 이 요청이 공격용인지 정상적인 요청인지 구분하지 못하고, XML에 적힌 대로 악성 코드를 스스로 실행하게 된다.

3. 공격 코드(PoC) 살펴보기

실제 공격은 어떤 형태로 이루어질까? GitHub 등지에 공개된 PoC(Proof of Concept) 코드를 보면 그 구조를 쉽게 이해할 수 있다. 공격에 사용되는 XML 페이로드(Payload)는 대략 아래와 같은 구조를 가진다.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.8.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>touch /tmp/pwned</string>  <!-- 여기에 악성 명령 삽입 -->
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

코드를 잘 모르는 사람이 봐도 뭔가 심상치 않음을 느낄 수 있다. 이 XML의 핵심은 java.lang.ProcessBuilder 객체를 이용해 서버에서 셸 명령어를 실행하도록 만드는 부분이다. 위 예시에서는 /tmp 디렉터리에 pwned라는 빈 파일을 생성하는 간단한 명령이지만, 공격자는 이 string 태그 안에 어떤 명령이든 넣을 수 있다.

예를 들어, 특정 IP와 포트로 서버의 제어권을 넘겨주는 리버스 셸(Reverse Shell)을 실행하거나, 서버에 웹셸(Webshell)을 업로드하여 언제든 원격으로 제어할 수 있는 뒷문을 만들 수 있다.

4. 롯데카드 사태와 교훈

롯데카드 해킹 시나리오는 이제 명확해진다.

공격자는 인터넷에 노출된 롯데카드의 웹로직 서버가 CVE-2017-10271에 취약하다는 것을 발견했다.
위와 같은 악성 XML 페이로드를 서버로 전송하여 원격 코드 실행에 성공했다.
최초 침투 후, 서버에 웹셸을 설치하여 지속적으로 명령을 내릴 수 있는 통로를 확보했다.
웹셸을 통해 내부망으로 이동하며 추가적인 정보를 수집하고, 마침내 고객 정보가 담긴 데이터베이스에 접근하여 200GB에 달하는 데이터를 외부로 유출했다.

가장 통탄할 점은 이 모든 비극의 시작점인 CVE-2017-10271의 보안 패치가 2017년에 이미 배포되었다는 사실이다. 2025년에 발생한 해킹이 8년 전 취약점 때문에 발생했다는 것은 기술의 문제가 아니라 명백한 관리와 프로세스의 실패를 의미한다.

결론: 낡은 구멍이 배를 침몰시킨다

이번 사태는 우리에게 아주 중요한 교훈을 남겼다. 화려한 최신 제로데이 공격보다, 우리가 이미 알고도 방치한 '낡은 구멍'이 훨씬 더 위험할 수 있다는 것. 개발자로서, 그리고 IT 인프라를 관리하는 사람으로서 주기적인 패치 관리와 알려진 취약점 점검이 얼마나 중요한지 다시 한번 뼈저리게 느낀다.

이 글을 읽는 동료 개발자들도 자신의 서비스가 의외의 곳에서 낡은 구멍을 방치하고 있지는 않은지, 다시 한번 점검해보는 계기가 되었으면 한다.

#CVE-2017-10271 #Oracle #WebLogic #RCE #Deserialization #보안취약점 #롯데카드해킹 #웹셸 #패치관리

참고 자료 (References)

롯데카드 해킹, 내 정보는 괜찮을까? (feat. 연회비 면제는 누구만?)

worniworni — Fri, 19 Sep 2025 22:22:49 +0900

코딩하다 말고 잠깐 머리 식히려고 뉴스를 켰다가, 심장이 덜컥 내려앉는 헤드라인을 봤다. '롯데카드 297만 명 정보 유출'. 하필 내가 메인으로 쓰는 카드 중 하나다. 순간 수많은 생각이 스쳐 지나갔다. 내 카드 번호도? CVC도? 해외 결제 막아놨던가? 온갖 걱정이 밀려왔다.

IT 업계에 몸담고 있다 보니, '해킹'이나 '정보 유출' 같은 단어가 남일 같지 않다. 하지만 내 정보가, 그것도 금융 정보가 유출됐을 수 있다는 건 차원이 다른 문제다. 일단 하던 일을 멈추고, 참고 자료들을 뒤져보며 사태 파악과 함께 내가 뭘 해야 할지 정리해보기로 했다.

사태의 심각성: 단순 유출이 아니다

이번 롯데카드 해킹 사태의 핵심은 두 그룹으로 나뉜다.

초고위험군 (28만 명): 카드번호, 유효기간, CVC, 비밀번호 앞 2자리, 주민등록번호 등 사실상 카드 결제에 필요한 모든 정보가 통째로 털렸다. 이 정보만으로도 카드 실물 없이 결제가 가능한 '키인(Key-in)' 방식의 부정 사용에 무방비로 노출된 것이다.
나머지 (269만 명): 카드번호(암호화), CI(연계정보) 등이 유출됐다. 롯데카드 측은 이 정보만으로는 부정 사용이 불가능하다고 선을 긋고 있다.

개발자 입장에서 더 화가 나는 건, 해킹의 원인이 '보안 패치 업데이트 누락'이라는 점이다. 가장 기본적인 보안 수칙을 지키지 않아 이 거대한 사달이 났다는 사실에 허탈함마저 느껴진다. 이건 천재지변이 아니라 명백한 인재(人災)다.

금융감독원 조사에 따르면 이번 공격은 오라클 웹로직(Oracle WebLogic) 서버의 원격 코드 실행 취약점(CVE-2017-10271)을 이용한 것으로 분석된다. 공격자는 침투 후 웹셸을 심어 내부망 장악을 시도한 것이다. 해당 취약점은 인증 없이 원격 명령 실행이 가능해 공격자가 서버를 완전 장악할 수 있는 치명적 보안 결함으로, 2017년 이미 패치가 제공됐음에도 관리 부실로 여전히 노출되어 있었으며, 이번 사건은 구형 취약점 관리 부실이 주요 원인으로 지적된다. 2017년에 나온 취약점 패치를 2025년까지 적용하지 않았다는 게... 정말 믿기지가 않는다.

그래서 내가 해야 할 일은?

불안에 떨고만 있을 순 없다. 당장 내가 해야 할 행동 계획을 세웠다.

1단계: 내 정보 유출 범위 확인하기

가장 먼저 할 일은 롯데카드 홈페이지나 앱에 접속해서 내가 297만 명에 포함되는지, 포함된다면 28만 명의 고위험군인지 확인하는 것이다. 이건 선택이 아닌 필수다. 확인 결과에 따라 대응 수위가 달라진다.

2단계: 즉각적인 보안 조치 실행

만약 28만 명에 포함된다면: 이건 고민할 필요도 없다. 즉시 카드 재발급을 신청하고, 기존에 사용하던 비밀번호를 변경해야 한다. 롯데카드도 이들에게는 '차년도 연회비 면제'를 조건으로 재발급을 강력히 권고하고 있다.
만약 269만 명에 포함된다면: 롯데카드는 재발급이 필수는 아니라고 하지만, 찜찜한 건 어쩔 수 없다. 유출된 정보를 이용한 2차 피해(보이스피싱, 스미싱 등) 가능성은 여전히 남아있다. 최소한 비밀번호는 변경하고, 무료로 제공된다는 '카드사용 알림서비스'와 '해외결제 차단'은 꼭 신청해두자.

3단계: 2차 피해에 대한 경각심 갖기

"롯데카드 배송 주소가 다르니 확인 바란다" 식의 전화나 문자는 100% 피싱이라고 생각해야 한다. 절대 그들이 알려주는 번호로 전화하거나 링크를 클릭해서는 안 된다. 모든 확인 절차는 내가 직접 롯데카드 공식 앱이나 홈페이지를 통해 진행해야 한다.

가장 현실적인 고민: 그래서 연회비는?

솔직히 가장 궁금했던 부분이다. 이 사태는 명백히 롯데카드의 과실인데, 왜 피해를 소비자가 감수해야 하는가. 특히 나는 연회비가 저렴하지 않은 카드를 쓰고 있다. 당연히 연회비 면제 정도는 해줘야 하는 거 아닌가?

하지만 참고 자료들을 보니, 차년도 연회비 면제 혜택은 28만 명의 고위험군이 카드를 '재발급'했을 경우에만 해당된다. 나머지 269만 명은 연회비 면제 대상이 아니다. 심지어 28만 명에 해당되더라도, 찝찝해서 그냥 탈퇴해버리면 남은 기간 연회비만 환불해 줄 뿐, 다음 해 면제 혜택은 없다.

이건 좀 아쉽다. 부정 사용 가능성이 낮다고 해서 유출된 269만 명의 불안감까지 낮은 것은 아니다. 모든 유출 피해 고객에게 동일한 수준의 위로와 보상(최소한 연회비 면제)을 제공하는 게 맞지 않았을까 하는 생각이 든다.

결국 이번 사태를 겪으며 다시 한번 깨닫는다. 내 정보는 내가 지켜야 하고, 기업의 '보상'은 언제나 그들의 기준에 맞춰져 있다는 것을. 일단 카드 명세서는 당분간 매일 확인하는 습관을 들여야겠다. 찝찝한 마음은 한동안 계속될 것 같다.

#롯데카드 #개인정보유출 #해킹 #보안 #카드재발급 #연회비 #개발자생각 #데이터유출

내 맥북 용량 도둑, '시스템 데이터'의 정체를 파헤치고 용량 줄이는 방법

worniworni — Thu, 18 Sep 2025 22:58:21 +0900

개발자에게 맥북 저장 공간은 언제나 전쟁이다. Xcode에, 각종 개발 도구에, 도커 이미지까지 설치하다 보면 1TB도 부족하게 느껴질 때가 많다. 오늘도 어김없이 '저장 공간이 거의 찼다'는 무시무시한 알림을 받았다.

"아니, 또? 뭘 지워야 하나..."

한숨을 쉬며 [저장 공간 관리]에 들어갔다. 그런데 이상한 점을 발견했다. 앱이나 문서보다 압도적으로 많은 공간을 차지하는 녀석이 있었다. 바로 '시스템 데이터'. 무려 200GB가 넘는 공간을 차지하고 있었다. 정체를 알 수 없으니 지울 수도 없고, 답답할 노릇이었다.

이거 완전 미스테리 아닌가. 그래서 오늘은 이 '시스템 데이터'라는 녀석의 정체가 뭔지, 그리고 어떻게 하면 이놈이 차지한 내 소중한 SSD 공간을 되찾을 수 있는지 직접 파헤쳐 보기로 했다.

'시스템 데이터'의 정체는 무엇인가?

결론부터 말하면, macOS가 딱히 분류하기 애매한 모든 파일을 욱여넣은 '잡동사니 서랍' 같은 개념이다. 예전 macOS에서는 '기타(Other)'라고 불리던 항목이 이름을 바꾼 것이다. 여기에는 대략 다음과 같은 파일들이 포함된다.

캐시 파일: 앱이나 시스템이 더 빨리 작동하기 위해 임시로 만들어두는 데이터들. (예: 웹 브라우저 캐시, 앱 내부 캐시 등)
로컬 Time Machine 스냅샷: Time Machine 백업용 외장 하드가 연결되지 않았을 때, 만약을 위해 맥북 자체에 임시로 저장해두는 백업 파일. (이 녀석이 주범일 확률이 매우 높다.)
임시 파일 및 로그: 앱이나 시스템이 작동하면서 생성하는 임시 파일이나 활동 기록.
오래된 iOS/iPadOS 백업: 예전에 Finder(구 iTunes)를 통해 맥에 백업해둔 아이폰이나 아이패드 백업 파일.
가상 머신(VM) 파일 및 디스크 이미지: Parallels, VMWare 같은 가상 머신 파일이나 다운로드한 .dmg 파일들.

문제는 이 '시스템 데이터'가 실시간으로 정확하게 계산되지 않을 때가 많다는 것이다. 파일이 지워져도 한참 뒤에야 용량이 줄어드는 것처럼 보이기도 하고, 명확한 경로 없이 여기저기 흩어져 있어 사용자가 직접 관리하기 어렵게 만든다.

시스템 데이터 용량, 직접 줄여보자 (feat. 터미널)

자, 이제 범인의 정체를 알았으니 소탕 작전에 들어갈 시간이다. 몇 가지 방법을 순서대로 시도해봤다.

1단계: 가장 간단하지만 효과적인 '재부팅'

믿기지 않겠지만, 가장 간단한 해결책은 재부팅이다. 재부팅 과정에서 시스템은 불필요한 임시 파일과 캐시를 일부 정리한다. 이것만으로도 몇 GB 정도는 쉽게 확보될 수 있다. 밑져야 본전이니 일단 재부팅부터 해보자.

2단계: 주범 검거 - 로컬 Time Machine 스냅샷 삭제

만약 Time Machine을 사용한다면, 이 녀석이 용량 문제의 90% 주범일 가능성이 높다. 외장 하드 없이 맥북을 사용하면 macOS는 자체적으로 SSD에 백업 스냅샷을 차곡차곡 쌓아둔다. 이걸 지워줘야 한다.

터미널(Terminal) 앱을 열고 아래 명령어를 차례대로 입력하자.

저장된 로컬 스냅샷 목록 확인
```
tmutil listlocalsnapshots /
```
이 명령어를 치면 com.apple.TimeMachine.2025-09-18-103000.local 같은 형식의 목록이 뜰 수 있다. 이게 바로 내 맥북에 저장된 백업 파일들이다.
로컬 스냅샷 삭제
```
tmutil deletelocalsnapshots /
```
이 명령어를 입력하면 저장된 모든 로컬 스냅샷을 한 번에 삭제한다. 특정 날짜만 지정해서 지울 수도 있지만, 그냥 한 번에 싹 지우는 게 속 편하다. (외장 하드에 있는 실제 백업은 지워지지 않으니 안심해도 된다.)

나의 경우, 이 명령어 한 방으로 무려 120GB를 확보했다. 속이 다 시원해졌다.

3단계: 묵은 때 벗기기 - 캐시 파일 삭제

다음은 앱과 시스템이 남겨둔 캐시 파일이다. 이건 좀 조심스럽게 접근해야 한다.

Finder를 열고 메뉴 막대에서 [이동] > [폴더로 이동...]을 선택한 뒤, 아래 경로들을 각각 입력해서 이동하자.

~/Library/Caches
/Library/Caches

이 두 폴더 안에 있는 파일과 폴더들을 삭제하면 된다. 주의할 점은 Caches 폴더 자체를 지우는 게 아니라, 그 안에 있는 내용물만 지워야 한다는 것. 불안하다면 바로 삭제하지 말고 휴지통으로 옮긴 뒤, 몇 시간 사용해보고 문제가 없으면 휴지통을 비우는 것을 추천한다.

4단계: 숨겨진 용량 도둑 - 디스크 분석 앱 활용

위의 방법들을 모두 써도 여전히 용량이 부족하다면, 전문 분석 앱의 도움을 받는 것이 좋다. 어떤 파일과 폴더가 용량을 많이 차지하는지 시각적으로 보여주는 앱들이다.

GrandPerspective: 용량을 차지하는 파일을 네모난 블록으로 보여준다. 무료.
DaisyDisk: 개인적으로 가장 추천하는 앱. 유료지만 인터페이스가 매우 직관적이고 예쁘다. 어떤 파일이 문제인지 바로 알 수 있다.

이런 앱을 돌려보면 내가 까맣게 잊고 있던 거대한 동영상 파일이나, 테스트용으로 설치했다 지운 앱의 찌꺼기 파일들을 발견할 수 있다.

결론: '시스템 데이터'는 관리 대상이다

'시스템 데이터'는 더 이상 정체불명의 대상이 아니다. 약간의 관심만 가지면 충분히 관리하고 통제할 수 있는 영역이다. 특히 개발자라면 Time Machine 로컬 스냅샷과 각종 캐시 파일에 대한 이해는 필수다.

오늘 알려준 방법들, 특히 터미널을 이용한 스냅샷 삭제는 꼭 기억해두자. 답답했던 맥북 용량 문제에 한 줄기 빛이 될 것이다. 이제 다시 맘 편히 코딩하러 가야겠다.

#macOS #시스템데이터 #맥북용량 #저장공간관리 #TimeMachine #캐시삭제 #맥북꿀팁 #개발자 #터미널