Outsider's Dev Story

Textcube를 떠나며...

2026-05-18T00:47:16+09:00

이 블로그를 2007년부터 시작했으니 어느새 20년에 가까워졌다. 그동안 Textcube로 운영해 왔는데 이번에 블로그를 Textcube에서 정적 사이트로 마이그레이션했다.

처음에는 테터툴즈로 설치만 했다가 이후에 텍스트큐브로 바꿨던 걸로 기억한다. 언제 바꾸었는지까진 기억나지 않지만 내 개발 커리어에서 가장 잘한 결정은 개발 블로그를 시작한 것이다. Textcube와 거의 20년 가까이 지내다 보니 정이 많이 든 프로젝트가 되었다. 그래서 막상 떠나고 나니 아쉬움이 많이 남아서 추억을 남겨놓을 겸 Textcube의 히스토리를 정리해 본다. RetroTech 팟캐스트을 운영하면서 생긴 습관 같은데 언젠가 RetroTech에서도 이런 국내 프로젝트들도 다뤄보고 싶다.

Tattertools와 Textcube

2004년 3월 1일에 정재훈 님이 3달 동안 PHP로 만든 설치형 블로그 "테터툴즈"를 공개한다. 당시 버전은 0.9 버전이었다.

태터 툴즈는 '뜨개질을 하는 사람의 도구'란 뜻입니다. 글이라는 실과 키워드라는 바늘로 옷을 짜듯이 지식을 담는 스크립트를 만들고자 그렇게 이름을 짓게 되었습니다.

나는 그 흐름의 한복판에 있진 않았지만, 당시 블로그 도구들이 별로였는지 정재훈 님의 다음 글을 보면 배포 후 24시간 만에 큰 호응을 얻은 듯하다. 게시판 시대의 한국 웹에 제로보드가 있었다면 블로그 시대에는 테터툴즈가 있었다. 큰 맥락은 알고 있었지만, 세부 내용은 이번에 자료를 찾으며 알게 됐다.

테터툴즈는 엄청난 인기로 사용자층이 생기고 관련 글들을 찾아보면 사용자들이 자발적으로 테터툴즈를 홍보하고, 팁을 공유하고, 사이트를 만들며 커뮤니티를 키워가던 자유스러운 분위기였던 듯하다. 그런 분위기에서 1.0을 준비하던 2005년 테터툴즈의 개발과 배포를 지원하고 수익을 내기 위해 정재훈 님과 합의로 노정석 님이 TNC(Tatter and Company)를 설립한다. 개인이 가지고 있는 블로그를 연결해 주는 블로고스피어나 메타블로그가 인기 있었는데 테터툴즈 사용자를 연결해 주는 이올린도 TNC가 운영했다.

그리고 2006년 1.0이 GPL 라이선스를 선택하고 이후 개발이 부진해지자, 이에 항의하면서 커뮤니티 서버 권한을 받아 2006년 4월부터 포럼 형태로 테터툴즈 사용자들이 모이면서 TNF(Tatter and Friends)가 만들어지게 된다. 이후 똑같은 약자를 사용하는 Tatter Network Foundation에 대해 논의하면서 재단이 TNF의 공식 명칭이 된다.

2006년 TNC는 Daum과 협업해서 Tattertools를 서비스형으로 만들어서 Tistory를 공개하면서 직접 설치하기 어려운 사람들도 블로그를 운영할 수 있게 됐다. 처음에는 TNC와 Daum이 공동 운영을 했지만 이후 지분을 모두 넘기고 Daum이 Tistory를 전적으로 운영하게 된다.

오픈소스화된 테터툴즈는 2007년에는 inureyes님을 중심으로 TNF의 구체적인 실행 조직으로 Needleworks가 만들어져서 공식적으로 활동하기 시작했다. 이후 Tattertools는 Textcube로 이름을 바꾸었고, Needleworks와 TNF가 개발을 이어받고 Textcube 1.5가 정식으로 발표된다. 이후 마케팅을 주력으로 한 테터앤미디어(TNM)도 등장한다. 자세한 히스토리는 니들웍스 홈페이지에서 볼 수 있다.

이렇게 2000년대 중반부터 2010년대까지 국내의 웹서비스를 관통하는 중심에 테터툴즈가 있었다고 해도 과언은 아니라고 생각한다. 당시 나에게는 TNF, Niddleworks, TNC, TNM이 모두 로망 중 하나인 조직이었고(또 하나의 조직은 오픈마루 스튜디오였다.) 지금 돌아보면 더 대단하게 느껴지는 국내 오픈소스의 성공 사례다.(너무 조용히 일상처럼 지나가지 않았나 싶을 정도로...)

2008년에는 Blogger라는 플랫폼을 가지고 있던 Google이 TNC를 인수한다. 나의 로망과도 같은 생태계였기에 나도 이 당시에 TNC 인수에 대한 글도 썼다.

Textcube로 운영한 19년

Textcube는 나에게 블로그란 세상을 알려준 도구였다. 개발을 배우고 웹을 깊게 알게 되면서 블로그를 점점 더 좋아하게 되었고, 당시에 블로그를 중심으로 설계된 많은 기술은 여전히 좋은 접근 방법이라고 생각하는 편이다.

소셜 네트워크가 인기를 얻으면서 블로그의 인기가 줄어들었지만, 문서가 웹의 근본이라고 생각하는 나는 여전히 블로그가 좋다. 왜 인기 없는지 모를 정도의 RSS이지만 지금까지도 나는 RSS 리더로 수많은 글을 읽고 있으며 다시 RSS의 시대가 와야 한다고 생각하는 편이다. 소셜 네트워크의 소모적인 논쟁보다는 블로그에 글을 적어서 트랙백으로 서로의 글을 연결하는 방식은 훨씬 생산적인 방식이었다고 생각한다.(물론 시간이 지나면서 내 트랙백도 스팸으로 가득 차긴 했다. ㅠ)

그 시절 웹은 인터넷을 통해서 서로 연결하고 쉽게 찾을 수 있는 포맷을 많이 시도했는데 시맨틱웹을 포함해서 Microformats이나 Movable Type, XFN(XHTML Friends Network), OpenID같은 것도 Textcube의 개발자들이 워낙 뛰어나서 여기서 배운 것들이다.(여기서도 마찬가지로 오픈마루 스튜디오에도 이러한 신기술들을 자주 보여줬다.)

기본적으로 만족스러운 블로그 플랫폼이지만 2011년 이후 릴리스가 한참 없었고 소프트웨어도 시간이 지나면 녹슬기 마련이고, 내 요구사항도 달라지고 있었다. 나도 웹 개발을 하고 있었기 때문에 직접 고쳐서 쓰기 시작했다.

Textcube는 원래 WYSIWYG 에디터를 지원했는데 내가 Markdown에 익숙해지면서 WYSIWYG을 제거하고 다른 마크다운 플러그인을 나한테 맞게 수정해서 사용하기 시작하고 스킨을 작성하고 몇 가지 버그를 수정하면서 사용하게 됐다.

그러다가 마지막 릴리스 후 3년 만인 2014년에 1.9버전이 릴리스되고 곧이어 1.10.0까지 나와서 Textcube를 사용하는 나로서는 너무 반가웠다.

개발자분들이 돌아오셨을 때 PHP를 할 줄 몰라서 내가 해결하지 못하는 버그나 RSS 피드의 max 제한 문제 등은 이슈를 올리면 메인테이너분들이 정말 잘 대응해 주셨다. 물론 이때는 온라인으로만 뵈는 분들이었지만 지금은 종종 인사드릴 수 있는 사이가 되었다.

당시 2.0이 준비 중이었기 때문에 기대했지만 메인테이너분들이 바빠지신 관계로 2.0은 아직도 나오지 않았다.

그 상태로 스킨을 조금씩 수정하고 하면서 지금까지 사용하고 있다. 물론 지금까지 큰 문제 없이 운영하고 있다는 면에서도 잘 만들어진 프로젝트라고 할 수 있지만 완전 괜찮은 것도 아니었다.

가장 큰 건 아무래도 웹 기술이 발전하고 있다는 것이다. 이유는 모르지만 댓글 시스템은 멈춰버렸고 방문자 통계도 신뢰하기 어려워졌다. 또한 당시에는 멀티 파일 업로드를 Flash에 의존하고 있었지만, Flash는 이제 웹에서 사라진 기술이 되었고, Flash가 완전히 사라질 때 "이젠 파일 업로드 어떻게 하지?"하면서 고민했지만, 웹 표준 기술로 fallback이 잘 구성되어 있었다. 그래서 멀티 파일 업로드는 안 되지만 하나씩 여러 번 올리면 되기 때문에 괜찮았다. 귀찮다면 귀찮지만 난 그래도 이런 fallback까지 구성한 개발자들에게 감사함을 느꼈다.

이유는 모르겠지만 어드민 사이트도 로그인은 되지만 로그인 유지가 안 되어 수 분 내에 풀리기 시작했고, 글을 어드민에서 직접 작성하지 않고 Sublime Text에서 작성하고 복사만 해서 발행하기 때문에 이마저도 크게 문제는 안 되었다. 열심히 보면 해결할 수도 있지만 그냥 조금씩 고장 나는 상태에서 계속 버티면서 20년 가까이 쓰게 됐다.

이제는 도커라이즈도 하고 MySQL 백업 스크립트도 잘 작성해 두고 ansible 세팅도 해놔서 필요하면 로컬에서 테스트용 블로그를 띄워서 테스트도 할 수 있고 배포 인프라도 필요할 때 이사 가면서 운영할 수 있게 되었다. 여전히 요구사항은 많이 있지만 익숙해진 채로 계속 사용 중이었다.

남들이 보기에는 Textcube가 뭐야? 하면서 낡은 플랫폼이라고 생각할 수 있었지만, 나에겐 너무 소중한 플랫폼이었다.

내 Textcube의 기록

내 개발 커리어 전체를 함께한 막상 떠나려니 아쉬움이 더 이상 볼 수 없을 거 같아 스크린샷을 남겨둔다.

이번 글을 쓰면서 Tattertools 자료를 조사하면서 가끔 트위터에서도 인사도 드리던 Lunamoth님이 블로그에 2000년대 초반부터 세세한 기록을 많이 남겨두셔서 큰 도움을 받았다.

블로그를 정적 사이트로 바꿨습니다

2026-05-17T20:24:51+09:00

이전 글에도 종종 얘기했지만, 코딩 에이전트에 많이 익숙한 편은 아니다. 가장 큰 이유는 예전처럼 집에서 코딩을 많이 하고 있지 않다 보니 코딩 에이전트와 친해질 시간이 별로 없었다. 예전에는 사이드 프로젝트 아이디어가 너무 넘쳐나서 문제였는데 언젠가부터 아이디어가 별로 없거나 아이디어의 규모가 커서 쉽게 시작하지 못하고 있었다. 그렇다고 나도 쓰지 않을 웹서비스 같은 걸 만들고 싶진 않았다.

주변 사람들과 AI 얘기를 하다가 블로그나 만들라는 얘기를 듣고 실제로 필요한 일이기도 했고 요구사항이나 취향도 꽤 명확하므로 내가 하기 딱 좋은 생각이 들었다.

Textcube 블로그

인터넷이 뜨기 시작했던 2000년대 초에는 홈페이지가 유행해서 많은 사람이 홈페이지를 만들었고 그때 나도 홈페이지를 가지고 있었다. 그건 개인 홈페이지였고 2006년쯤에는 블로그가 유행하기 시작해서 나도 테터툴즈라는 도구로 블로그를 만들었다.

블로그를 만들기만 하고 작성할 글이 없어서 방치하다가 2007년 개발자로 일하기 시작하면서 개발 블로그로 운영하기 시작한 게 여기까지 왔다.

블로그 플랫폼은 테터툴즈에서 Textcube로 바뀌었지만 이건 프로젝트의 브랜딩이 바뀌어서 그런거고 난 처음부터 지금까지 같은 플랫폼을 그대로 사용하고 있다. 처음 사용할 때는 꽤 앞서가고 잘 만들어진 플랫폼이었지만 시간이 지나면서 웹 기술도 크게 발전하고 트렌드도 바뀌었기 때문에 낡은 플랫폼이 되어버렸다.

약간 고쳐서 쓰고 있긴 했지만 크게 문제 안 되는 고장 난 기능들은 그냥 방치한 채로 쓰고 있었고 난 PHP 개발자가 아니었기 때문에 대대적인 수정은 하지 못했다. 블로그 플랫폼을 바꾸는 고민도 해봤지만 이미 작성한 글이 너무 많았고, 블로그의 퍼머링크를 망가뜨리고 싶지 않았기 때문에 다른 플랫폼으로 이사가는 건 오래전에 포기한 채로 운영하고 있었다. 글이 많아지면서 성능 문제도 종종 생겨서 몇 년에 한 번씩 튜닝도 하면서 고생하고 있었다.

AI로 새로 만들기

이제 코딩 에이전트가 너무 좋아졌기 때문에 아예 블로그 플랫폼을 새로 만들면 퍼머링크도 유지할 수 있고 앞으로 원하는 대로 수정할 수 있을 거라고 생각해서 새로 만들기로 했다.

블로그라는 건 기술적으로 복잡할 건 없다고 생각했기에 정적 사이트로 만들어서 CDN으로 제공하면 지금보다 성능도 좋아지고 글 개수가 늘어나도 문제가 없을 거라고 생각해서 정적 사이트로 만들기로 결정했다.

지난 2월인가 카카오가 ChatGPT Pro를 너무 싸게 팔아서 나도 그때 구매해서 사용하고 있었고 이 사용량이 나에겐 넘쳐나기 때문에 이때 개인 Claude 구독도 끊은 상태였다.

블로그는 텍스트 큐브를 포함해서 이미 Git으로 관리하고 있었기에 소스코드와 백업해 둔 MySQL 덤프 파일을 한꺼번에 주고 정적 사이트로 만들어달라고 요청했더니 한참 작업한 후에 Astro로 콘텐츠까지 마이그레이션 된 사이트를 던져줬다. 난 좀 차근차근히 하고 싶다는 생각이 들었는데 당시 사람들이 보통 말하던 Codex는 한 번에 작업을 많이 한다는 선입견이 있었던 편이라 결과물이 맘에 들지 않아서 Claude Pro를 일단 결제해서 작업을 하기 시작했다.(지나서 생각하면 내가 지시를 좀 애매하게 해서 그런거 였고 Codex로 계속 작업을 했더라도 괜찮았을 거라고 생각한다.)

개발 관련 블로그를 오랫동안 운영하고 있습니다.

이 블로그는 Textcube라는 아주 오래된 PHP 블로그 플랫폼을 사용중이고 PHP와 MySQL을 이용해서 운영하고 있습니다.

하지만 Textcube가 더이상 유지보수 안되는 프로젝트이고 운영할때 서버도 필요하기 때문에 관리하기 더 쉬운 정적 사이트 형태로 변환하려고 합니다. 혼자서만 사용하는 블로그이므로 일단 글을 작성하고 나면 수정할 일이 별로 없고 나중에 작성 기능을 따로 만들면 되기 때문에 정적 사이트가 훨씬 좋다고 판단했습니다.

그동안 따로 블로그를 다른 플랫폼으로 옮기지 못했던 이유는 기존의 글이 1700개 쯤 있으므로 각 글에 대한 퍼머링크(숫자 slug 사용)를 그대로 유지하는 것이 제일 중요했기 때문입니다.

* 기존 블로그 플랫폼의 소스 코드는 blog 디렉토리에 있습니다.
* blog.sql 파일은 운영중인 MySQL의 덤프 파일입니다.
* 기존 글의 퍼머링크를 반드시 유지해야 합니다.(각 글에 대한 정보는 blog.sql을 참고 해야 합니다.)
* 디비에는 댓글 기능도 있는데 기존에 남겨진 댓글만 있고 새로운 댓글은 달리지 않습니다. 그래서 댓글 기능을 만들 필요는 없지만 기존에 남겨진 댓글은 보존 차원에서 댓글로 표시되었으면 합니다. 블로그 댓글 기능은 외부 플랫폼을 이용할 건데 일단 중요하게 생각하지 않아도 됩니다. 
* 글은 아주 오래된 글은 마크다운으로 되어 있지 않을거지만 대부분의 글은 마크다운으로 되어 있습니다. 그래서 마이그레이션을 포함해서 이후 새로운 글도 마크다운으로 관리되었음 합니다. 마크다운이지만 메타태그도 넣고 하려고 MDX가 괜찮지 않을까 합니다. 
* 아마 기본 형태는 블로그 글인 마크다운 파일들을 모아놓은 파일들이 있고 사이트도 기능을 넣고 관리해야 하므로 블로그 템플릿은 관리하는 곳이 분리되어 있어서 글을 추가하거나 삭제하면 빌드해서 정적 사이트 블로그로 만드는게 좋을거 같습니다.
* 현재 사용중인 스킨은 blog/skin/blog/anti_verbose 아래에 있습니다.

현재 생각나는 요구사항은 이정도인데 작업하기 전에 어떤 접근방법이 좋은지 같이 얘기해보면 결정하면 좋겠고 결정된 내용은 설계 파일에 저장하고 이후 참조할 수 있도록 하면 좋겠습니다.

기존 소스코드를 분석해 주었다. 퍼머링크 등은 소스코드만 주어서 그런지 제대로 판단하지 못했지만 상당히 잘 파악해 주었다.

그리고 Codex와 마찬가지로 Astro를 추천해 주고 마이그레션 전략과 폴더 구조, MDX 파일 구조 등을 제안해 주었다. Astro도 써보고 싶긴 했지만 특정 프레임워크에 묶이고 싶진 않았고 프레임워크에 의존할 정도로 복잡하진 않을 거라고 생각했고, AI가 충분히 잘할 거라고 생각했기에 이왕 기존 플랫폼에서 벗어나는 김에 직접 구현하기로 하고 싶었다. Claude는 Node.js를 제안했지만 어차피 빌드해서 HTML로 나올 것이므로 도구 자체가 Node.js일 필요는 없다고 생각해서 언어를 제한하지 말라고 했다.

좋은 지적입니다. 빌드 도구의 언어를 자유롭게 선택할 수 있으니 비교해 보겠습니다.

빌드 도구 언어 후보

1. Rust
- 성능: 최고. 1,636개 파일 전체 빌드도 1~3초 수준
- 마크다운: pulldown-cmark (매우 빠르고 안정적)
- MDX: mdxjs-rs (MDX 팀이 직접 만든 Rust 구현체, 다만 JS 쪽보다 성숙도 낮음)
- 인크리멘탈 빌드: 파일 해시 기반 캐싱 직접 구현 용이
- 단점: MDX 생태계가 JS에 비해 얇음. 빌드 도구 자체 개발 비용이 높은 편

2. Go
- 성능: 매우 빠름. Rust에 근접
- 마크다운: goldmark (Hugo가 사용하는 파서, 매우 빠르고 안정적)
- MDX: 네이티브 지원 없음. 직접 구현하거나 마크다운만 사용해야 함
- 인크리멘탈 빌드: 구현 용이
- 단점: MDX를 쓰려면 별도 처리 필요

3. Bun
- 성능: Node.js 대비 35배 빠름. 전체 빌드 510초 수준 예상
- 마크다운/MDX: unified/remark/rehype 생태계 그대로 사용 가능 (가장 성숙한 MDX 구현)
- 인크리멘탈 빌드: 파일 와칭 + 해시 기반으로 구현
- 단점: Rust/Go 대비는 느림. Bun 자체가 아직 성숙 중

4. Node.js/TypeScript
- 성능: 가장 느림. 전체 빌드 15~30초 예상
- 마크다운/MDX: 생태계 최고
- 단점: 1,636개 파일에서 체감되는 느림

핵심 분기점: MDX가 정말 필요한가?
MDX의 핵심 가치는 마크다운 안에서 JSX 컴포넌트를 사용하는 것인데, 프레임워크 없는 정적 사이트에서는 그 이점이 크게 줄어듭니다.

만약 마크다운 + frontmatter로 충분하다면:
- Go나 Rust를 자유롭게 선택 가능
- 성능이 크게 좋아짐
- 커스텀 문법이 필요하면 remark 플러그인 대신 마크다운 파서의 확장 기능으로 처리

만약 MDX가 꼭 필요하다면:
- Bun이 현실적 최선 (JS 생태계 + 성능 타협점)

제 추천
Go + goldmark 조합이 가장 균형 잡힌 선택이라고 생각합니다.
- 1,636개 파일 전체 빌드가 1~3초면 인크리멘탈 빌드의 필요성 자체가 줄어듦
- goldmark은 Hugo가 검증한 파서로 확장성도 좋음
- 단일 바이너리로 빌드 도구 배포 가능
- Go의 text/template이 HTML 템플릿으로 충분
- 동시성 처리가 간단 (goroutine으로 파일 병렬 처리)

Rust도 좋지만 개발 속도 면에서 Go가 더 실용적이고, 이 규모에서 Rust와 Go의 성능 차이는 체감하기 어렵습니다.

MDX 대신 마크다운 + frontmatter + goldmark 확장으로 가는 방향은 어떻게 생각하시나요?

Go 언어를 추천해 줘서 난 Go를 할 줄 모르지만, 이 제안을 받았다. 참고로 이 작업을 할 때부터 난 코드를 읽을 생각이 없었다. 업무에서는 코드 봐야 된다는 입장이지만 이건 개인 프로젝트라서 위험성도 없고 코딩 에이전트로 어느정도할 수 있는지도 직접 경험해 보고 싶었다. 그래서 이 작업은 터미널이 아니라 Claude 데스크톱 앱으로 작업했다. 물론 간단한 건 내가 직접 수정하거나 터미널에서 커밋했다.

잘못 파악한 부분을 지적해 주고 합의한 내용으로 디자인 파일을 만든 뒤에 본격적으로 작업을 시켰다. go로 블로그 시스템을 만들고, 이어서 SQL 파일에서 마이그레이션도 시켰다. 기존 코드가 있어서 기대보다 분석을 잘해주었지만 의도를 잘 모르는 부분은 알려줬다. 예를 들어 Textcube에도 댓글 기능이 있기 때문에 십여 년간 쌓인 댓글이 있고 몇 년 전부터는 utterances로 댓글 시스템을 교체했다.(그리고 고장 나서 그런지 Textcube 댓글은 더 이상 달리지 않았다.) 이런 경우 정적 사이트에서는 utterances만 쓸 계획이지만 기존에 남겨진 댓글을 지우고 싶지 않았기 때문에 이런 배경을 알려주고 기존 댓글도 마이그레이션 하고 고정하도록 했다.

내가 아직 AI를 잘 쓴다고 생각하고 있진 않았기에 모델에 의존하고자 Opus 4.7 Extra high로 작업했다.(처음에는 4.6이었고 중간부터 4.7로 바꾸었던 걸로 기억한다.)

Claude Pro 플랜은 리밋이 꽤 빡빡하므로 작업하다가 리밋 걸리면 놔두었다가 리밋 풀리면 이어서 작업하게 시켰다. 내가 계속 이거만 보고 있을 수는 없다 보니 처음에는 Pro 플랜으로 이렇게만 해도 충분했다. 작업하면서는 계속 md 파일에 계획이나 규칙 등을 업데이트했고 커밋할 때마다 작업 로그도 남기게 했고 테스트 등 여러 검증 도구도 좀 늘려가면서 커밋할 때 검증하고 커밋하도록 규칙에 추가했다.

블로그가 복잡하진 않지만, 이 정도 가이드만 했는데도 꽤 똑같이 만들어주어서 시작부터 좀 놀라긴 했다. 기존에도 스킨 파일이 HTML로 있었기 때문에 꽤 쉽게 모양을 맞춘 것으로 보인다.

전체적인 레이아웃을 맞추기 위해서 기존 skin.html과 라이브로 떠 있는 블로그와 비교를 시키면서 필요한 작업을 파악하기 시작했다.

오래 운영한 블로그라 대부분의 구성 요소는 알고 있기에 하나씩 보면서 추가해야 할 작업을 시키면서 레이아웃을 어느 정도 맞추었다.

1
2
3

참고로 blog 폴더와 blog.sql 파일은 현재 블로그이고 이를 정적 사이트로
마이그레이션 하는 중이므로 작업이 끝나면 blog 폴더 등은 삭제할 예정입니다. 그러므로 이미지나 이런걸 blog 폴더의 아래에 있는걸 
그대로 참조해서 사용하거나 하면 안됩니다. 그러고 있나요?

중간중간 생각나는 실수할 여지가 있는 부분은 체크하면서 규칙에 추가했고, 가이드를 충분하게 주지 않아서 Git으로 관리해야 하는데 추가 안 한 파일 등은 체크하고 규칙을 변경해 가면서 작업했다.

콘텐츠 마이그레이션

스킨은 비교적 간단하지만, 블로그에서 제일 중요한 건 콘텐츠이기 때문에 콘텐츠가 제대로 마이그레이션 되었는지 확인하는 게 중요했다.

콘텐츠 비교를 직접 시키면 토큰이 감당하지 못할 거라고 판단해서 라이브로 운영되는 블로그와 로컬의 블로그 글 링크를 추출해서 유사도를 분석하는 스크립트를 작성하게 했다.

스타일을 개선하고 블로그 시스템을 개편하기 전에 정적 마크다운으로 
제대로 마이그레이션 되었는지 확인하고 싶습니다. 
지금 마이그레이션된 글과 https://blog.outsider.ne.kr 에서 
같은 글 번호(퍼머링크)가 내용이 똑같은지 확인하고 싶습니다. 
이는 스타일과는 상관없이 컨텐츠에 대한 얘기입니다. 
이를 모두 LLM으로 하기 보다는 비교하는 스크립트를 작성하고 
그 결과로 대응하는게 좋다고 생각하는데 어떤가요?

작성한 스크립트를 어느 정도 개선한 후에 전수 조사를 시키고 오류를 뽑아내게 했다. 글이 1,600개라서 꽤 어려울 거라고 생각했는데 기대 이상으로 문제를 잘 찾아내고 Major, Minor 이슈를 구분해서 알려주었다.

여기서부터 AI보다 내가 할 일이 많아지기 시작했는데 문제라고 알려주면 글 링크를 열어서 실제로 이게 문제인지 아닌지를 확인하고 어떻게 고쳐야 할지 알려줘야 하므로 내가 확인하는 시간이 오래 걸리기 시작했다.

또한 Textcube에서 처음에는 WYSIWYG 에디터로 글을 작성했기 때문에 900여 개의 글까지는 저장된 콘텐츠가 HTML로 되어 있고 그 이후부터는 마크다운에 익숙해졌기 때문에 마크다운 플러그인을 붙이고 수정해서 그다음부터는 마크다운으로 글을 작성하기 시작했다. 마이그레이션은 모두 마크다운으로 했으므로 Markdown -> Markdown은 비교적 괜찮았지만, HTML -> Markdown에서는 아무래도 오류가 많이 발견되었다. 그래도 이런 부분도 Claude가 알아서 잘 파악하고 frontmatter에 convertedFromHTML를 표시해 주어서 마이그레이션 예외 케이스도 쉽게 처리할 수 있었다.

---
id: 937
title: "Jade에 HTML을 함께 사용하기"
slug: "937"
date: 2013-05-11T00:27:34+09:00
category: "node.js"
tags:
  - "HTML"
  - "jade"
  - "view template engine"
convertedFromHTML: true
---

Textcube에는 [##_ATTACH_PATH_##]나 [##_page_title_##]처럼 플랫폼이 값을 바꿔치기하기 위한 플레이스 홀더가 있는데 디비에서 마이그레이션하다 보니 이런 내용이 많이 포함되어 있어서 찾아낼 때마다 수정하도록 요청했다.

알려준 이슈 중에 일부만 먼저 보겠습니다. 

967은 이제 정상이므로 결함에서 제외해도 됩니다. 

126, 155번도 앞에서 해소되어 무시해도 됩니다. 

386은 Flickr.com, Gucci.com, twitter.com 부분은 원래 테이블이어야 하는데 텍스트로 되어 있어서 이상하게 표시됩니다. 테이블로 바꾸어 주세요. 

424번 글의 경우 HTML에서 컨버팅 된 글이라서 h1, h2, h3 등이 제대로 처리되어 있지 않습니다. 일부 제목 텍스트가 <font style="font-weight: bold;" size="5">처럼 되어 있는데  이런 글은 제목을 의도한 것이므로 사이즈를 보고 절적한 h 태그로 치환해 주세요. 이건 424뿐만 아니라 convertedFromHTML가 true인 모든 글에 해당합니다.

이런 식으로 Claude가 찾아낸 이슈를 받은 다음에 콘텐츠를 열어서 확인해 보고 이슈는 수정하게 하고 이슈가 아닌 건 넘어가게 하는 작업의 반복이었다.

내가 확인해야 다음 작업을 할 수 있으니 어느 순간부터는 AI보다 내가 더 오래 일하는 거처럼 느껴졌다.

사이트 개선

콘텐츠가 기본적인 부분은 잘 마이그레이션 되었다고 느껴서 스킨을 포함해서 전체적인 블로그를 개선하기 시작했다. 퇴근하고 틈틈이 작업을 하고 있었는데 마침 5월 초에 5일 연속 연휴가 있어서 이때는 작업도 많이 할 수 있어서 Cladue를 Max 5x로 올렸다. 중간중간 리밋이 걸리긴 했지만, 5x가 되니 훨씬 쾌적하게 작업할 수 있었다.

기존에 MySQL 덤프에서 마크다운으로 마이그레이션 하게 했더니 항상 SQL 덤프가 있을 거라는 가정하에 마크다운을 출력 파일로만 쓰고 있어서 이 부분을 정리하게 시켰다. 마이그레이션이 끝난 뒤에는 어차피 SQL 파일은 폐기하고 마크다운 파일로만 관리해야 하니 마이그레이션 관련 코드는 제거했다.

네 마이그레이션을 좀더 확인해야하지만 마이그레이션이 완료되면 
git/md 기반으로 전환할 예정입니다. 
깃에 추가해주시고 마이그레이션 도구는 그대로 놔두세요. 
이후에 이슈가 발견될때마다 마이그레이션을 해서 posts를 업데이트해야 합니다.

사이드바 메뉴에 카테고리를 표시하고 카테고리의 글 목록, 태그의 글 목록, 아카이브 페이지, 페이지네이션 등의 기능이 동작하도록 수정하고 글을 보면서 스타일이 맘에 들지 않거나 잘못된 부분을 발견되는 대로 정리했다.

코드 블록도 기존에는 서버에서 <code><pre> 형태의 HTML을 출력하고 클라이언트에서 Prism.js로 신택스 하일라이트를 하고 있었는데 새로 만들면서 Claude가 알아서 goldmark와 chroma로 빌드 단계에서 신택스 하이라이트를 위한 구조를 만들고 클라이언트에서는 스타일 정도만 입히는 걸로 바뀌었다. Prism.js도 이젠 유지보수가 잘되지 않아서 잘 정리되었다고 생각한다. 그래도 라이브러리는 별도로 지시하지 않으면 최신 버전을 잘 못 찾는 느낌이라 따로 확인해서 업데이트하게 했다.(GitHub Actions의 각 의존성 버전도 낮게 세팅해 주어서 나중에 다 업데이트했다.)

코드 영역은 HTML과 스타일이 복잡한 편이라서 한 번에 잘하진 못했지만 잘 안된 부분을 설명하거나 그래도 잘 못하면 어떤 HTML이나 스타일이 문제 되었는지 알려주면 사이트를 열어서 확인하고 잘 해결해 주었다. 코드 영역의 가로 스크롤을 줄이기 위해 마우스커서를 올리면 width를 확대하는 기능이 있었는데 이건 아무래도 hover 이벤트를 발생시켜야 확인할 수 있어서인지 이 부분은 잘 해내지 못해서 여러 번 핑퐁 끝에 버그를 잡았다.

아까 말한 대로 오랫동안 운영하면서 콘텐츠의 형태가 다양했기 때문에 코드 블록을 표시하는 방법도 여러 가지 있어서 일부 코드는 제대로 렌더링 되지 않는 부분이 많이 있었는데 발견할 때마다 하나씩 수정했다. 이번에 작업하면서 알게 되었는데 HTML에서 마크다운으로 콘텐츠 작성을 전환하면서 기존 글에서도 코드 영역이 제대로 나오지 않은 부분이 꽤 있었는데 이번에 정리하면서 100%는 아니어도 기존보다는 더 잘 나오게 되었고 코드 블록이 특정 라인부터 시작되는 기능 등은 라이브러리에 의존하고 있었는데 직접 구현시켜서 원하는 대로 쓸 수 있었다. 이번에 개선하면서 코드 블록 복사 기능도 추가했다.

정적 사이트라서 404 페이지도 따로 만들었다. 404 페이지도 좀 재밌게 만들고 있었는데 딱히 생각나는 아이디어가 없어서 그냥 심플하게 만들도록 했다.

404 페이지를 구현하는데 지금 블로그 스킨은 그대로 유지합니다. 
즉 상단에 Outsider Dev story라고 써있는 헤더는 그래도 유지하고 
햄버거버튼의 사이드바도 유지합니다. 그 아래에는 retroTech와 
44bits 배너가 있는데 이건 지워주세요. 어차피 푸터가 있으니까 괜찮습니다. 
본문 한가운데 404 Page not found 라고 이쁘게 써주세요.
이번 건 바로 커밋하지 말고 일단 제가 먼저 볼 수 있게 해주세요.

난 RSS를 많이 쓰는 편이고 블로그가 RSS를 꼭 제공해야 하는 편인데 Claude Code가 알아서 RSS도 만들어줬다. 하지만 다른 블로그를 구독해서 사용하다 보면 블로그가 개편되면서 기존 글이 다 새로운 글처럼 RSS 리더에 등장하는 경우가 종종 있다. 한 번에 읽음 처리하면 되지만 구독자에게 이런 경험을 주고 싶지는 않았다.

그래서 Claude Code로 작업하면서 토큰이 남아도는 Codex로 비교를 시켰다.

1
2
3

https://blog.outsider.ne.kr/atom 와 
http://localhost:8080/rss/index.xml 가 
얼마나 똑같은지 비교해 주세요.

어떤 기준으로 RSS 리더에서 기존의 글이 업데이트되는지도 잘 대답해 주고 딱히 신경 쓰고 있진 않았는데 나는 기존에 Atom 형식으로 RSS 피드를 제공하고 있었는데 Claude Code는 RSS 2.0으로 만들어줬기 때문에 스펙 간의 차이를 물었는데 Atom을 유지해도 문제가 없다고 해서 그냥 Atom을 사용하기로 했다.

2026년 기준으로도 "새 표준이라서 갈아타야 하는" 상황은 아닙니다. 오히려 기존 atom을 유지하는 게 가장 안전하고, 표준성만 보면 Atom 1.0이 RSS 2.0보다 더 정교합니다.

RSS 2.0의 장점은 호환성입니다. 거의 모든 리더가 RSS를 먹습니다. 팟캐스트 생태계도 RSS 기반입니다. 하지만 스펙이 느슨해서 guid가 없거나 날짜가 흔들리면 리더마다 새 글 판단이 달라질 수 있습니다. RSS 스펙도 <guid>를 aggregator가 새 항목 판단에 쓸 수 있다고 설명합니다.

Atom의 장점은 정확성입니다. entry마다 <id>와 <updated>가 필수이고, 특히 Atom 스펙은 마이그레이션/재발행/import/export 때도 atom:id가 바뀌면 안 된다고 명시합니다. 지금 걱정하시는 “기존 글이 다시 새 글처럼 뜨는 문제”에는 Atom 쪽 모델이 더 잘 맞습니다.

라이브 사이트의 Atom 피드를 주고 똑같은 형태로 바꾸도록 수정을 시켰더니 잘 처리해 주었고, 예전부터 개선하고 싶었던 sitemap.xml도 잘 만들어주었다. 이건 따로 지시하지 않고도 처음부터 잘 만들어주긴 했다.

어느 정도 완성되어 가고 있어서 GitHub Actions도 작성하게 했더니 한 번에 잘 작성해 주었다.

접근성과 성능

모든 페이지를 정적 파일로 만들고 CDN을 태울 것이므로 기존보다는 여러모로 성능이 좋아질 것으로 생각하지만, 웹 표준, 접근성, 성능 부분도 챙기고 싶었다.

지적받은 내용을 하나씩 검토하면서 수정할 건 작업 시키고 제외할 건 제외했다. Textcube에서 페이징 된 주소처럼 시간이 지나면 바뀌는 페이지도 검색엔진에 잡히면서 검색 결과와 실제 방문한 페이지가 다른 문제가 있어서 수정했는데 그런 문제도 재발하지 않도록 잘 정리되었고 robots.txt도 새 블로그에 맞게

기존 블로그에서는 개선한 지가 오래되기도 했고 60개 정도의 웹 표준 경고나 오류가 뜨고 있었다.

개선 후에는 오류가 하나도 잡히지 않게 되었다.

웹 접근성 개선과 Core Web Vitals을 개선하게 시켰더니 Pa11y와 Lighthouse로 개선해야 할 목록을 잘 뽑아주었고 하나씩 진행 여부를 확인하면서 작업을 시켰다. 불필요한 의존성이나 사용하지 않는 CSS, JS도 정리하고 preconnect나 이미지 지연 로딩 등의 처리를 했다.

성능을 개선하면 사이드바에 표시하던 creative commons license 아이콘도 SVG로 교체했다.(왼쪽이 기존이고 오른쪽이 개편 후) 맥을 중심으로 모니터가 좋아져서 해상도 낮은 아이콘이나 이미지는 훨씬 더 눈에 거슬린다.

위가 기존 블로그의 PageSpeed Insights 점수이고 아래가 개선한 이후다. 약간 부족한 부분이 있지만 완전히 해소하기 어려운 부분도 있어서 이 정도로 만족한다.

이후에도 계속 검사해야 한다고 했더니 CI에도 알아서 추가해 주었고 이번 목표는 일단 블로그 시스템을 교체하는 거고 이후에도 계속 개선해야 하기에 CI에서 접근성과 성능에 대한 리포트도 간단히 출력하게 해서 비교를 할 수 있게 만들었다.

성능 개선에서 시간을 꽤 썼는데 의존성 정리와 실제 사용하는 아이콘만 추출, 압축 등 꽤 맘에 들게 잘 해주었고, 버전이 낮은 의존성도 업데이트하면서 우려되는 상황 같은 것도 잘 알려주었다. 예를 들어 Font Awesome의 버전 올리면서 아이콘이 달라진 부분과 선택권이 생긴 부분을 잘 잡아서 제안해 주었다. 여러 옵션 중에 제일 좋은 옵션을 추천해 주는 것도 대부분 맘에 들었다.

항상 달고 싶었던 W3C Validation 아이콘을 달까 했지만, 시간이 지나도 여전히 안 이뻐서 그냥 항상 유지하도록 신경아 쓴다는 의미로 HTML5, CSS3, 접근성 아이콘을 푸터에 추가했다.

배포

정적 파일을 AWS CloudFront와 Cloudflare 중 어디로 서빙할지를 고민했다. S3와 CloudFront 조합을 사용하더라도 비용이 많이 나오진 않겠지만 Cloudflare를 쓰면 무료 범위내에서 운영할 수 있을 거 같아서 Cloudflare를 선택했다.

최근 Cloudflare의 CLI가 새로 나오긴 했지만 아직 일부 기능만 제공하는 거 같아서 어려운 일도 아니라 Cloudflare Pages 세 팅은 직접 했다.

하지만 올리려고 하니 Error: Pages only supports files up to 25 MiB in size가 발생했다. Git으로 관리하면서 별로 신경쓰고 있지 않았는데 동영상 같은 파일도 있어서 용량이 약간 큰 파일이 있었다. 찾아보니 Cloudflare Pages에서 오브젝트 스토리지인 R2를 연동하는 문서가 있어서 이를 Claude Code에 던져주고 작업하게 했다.(버킷은 내가 수동으로 만들었다.)

R2 연동 설정은 잘해주었지만, 처음에는 파일 중에 25MB가 작은 파일만 Pages에 올리게 하고 큰 파일만 R2에 올리도록 작업해 주었는데 이렇게 하면 CI에서 도는 것과 Cloudflare에서 빌드하는 게 좀 이상해서 큰 파일의 폴더를 아예 따로 분리해서 관리하고 해당 폴더만 CI에서 R2에 업로드하게 했다. 여기서 CI에 R2 권한을 주어야 하는데 여기서 고생을 많이 했다.(항상 권한이 문제다) Claude Code는 됐다고 하는데 실제로는 권한 오류가 뜨고를 반복하다가 아무리 찾아봐도 R2 특정 버킷에만 접근권한을 줄 수가 없어서 안타깝지만 좀 큰 권한을 줄 수 밖에 없었다.

이 부분까지 정리하고 나니 커밋할 때마다 Cloudflare Pages도 자동 배포하게 구성할 수 있었고 이후부터는 새로운 파일을 추가하고 커밋만 하면 배포되도록 구성했다.

오픈그래프

오픈그래프는 항상 신경 쓰이는 부분이었다. 기존에 Textcube 구조에서 치환자를 잘 조합해서 오픈그래프와 Twitter Cards를 지원하고 있었지만 깔끔하게 지원하진 못했다.

이미지를 항상 메인 이미지만 쓸 수 있었고 마크다운으로 글을 쓴 뒤에는 콘텐츠 추출이 마크다운으로 그대로 되어서 오픈그래프에도 마크다운 문법이 그대로 출력되는 문제가 있었다.

GitHub처럼 최근 많이 하듯이 썸네일 이미지도 한눈에 잘 들어오게 바꾸고 싶었는데 기존에 Textcube에서 이를 연동하기는 어려워서 문제가 있다는 건 알지만, 그냥 방치하고 있었다.

어차피 빌드 과정이 있으니 이때 각 콘텐츠에 맞게 썸네일 이미지를 찍어낼 수 있게 되었다. 대신 1,700개 정도 되는 이미지를 만들어내야 하므로 빌드때 10여 분이 더 소요되게 되었다. 기존의 빌드된 파일이 있으면 증분 빌드를 하도록 수정하기는 했지만, Cloudflare 빌드에서 캐시를 쓰기가 좀 복잡한 거 같아서 일단 나중에 개선하기로 하고 그대로 두었다.

콘텐츠 검증

새 블로그가 어느 정도 완성되어 가면서 마이그레이션 후에 블로그 글이 기존과 똑같다는 확신이 필요했다. 그래서 Claude Code로 작업을 시키면서 Codex로 콘텐츠 비교 작업을 시켰다. 아까 말했듯이 토큰이 넉넉해서 콘텐츠 비교에도 더 자세하게 할 수 있긴 하지만 그래도 스크립트를 작성하게 시켰다.

그동안 글을 보면서 잘못된 부분을 라이브 블로그와 개발 중인 것을 비교하면서 보게 되어서 이를 쉽게 하도록 만들었다. 끝나고 모든 글을 한 번씩 비교해 보면서 차이점을 보고 싶어서 같은 글을 기준으로 두 블로그의 스크린샷을 찍도록 했다.

이렇게 하면 하나씩 넘겨 보면서 제대로 마이그레이션 되었는지 확인하기 편하겠다 싶었는데 실제로 잘 쓰진 않았다. 스크롤이 세로로 길다 보니까 스크린샷이 제대로 찍히지 않았고 길어서 스크린샷으로 보기도 쉽지 않았다.

이건 글 번호를 입력하면 원본과 로컬을 아이프레임으로 양쪽에 보여주도록 한 프로그램이다. 이 작업을 시킬 때 본문 매치에 대한 조사도 같이 시켰더니 이 프로그램에서도 본문 매치율을 같이 보여주었다. 스크롤 움직이면서 양쪽이 어떻게 다른지 확인할 수 있었다. 사이트 개선하거나 스타일 잘못된 부분 수정할 때도 이 프로그램을 꽤 많이 사용했다.

새 블로그의 개발이 거의 끝나가는 시점에서는 Codex에게 전수조사를 시켰다. 모든 글이 일치해야 하지만 결국 HTML로 렌더링 된 내용을 비교하는 거라서 100% 똑같기는 어렵고 예전 WYSIWYG로 글을 쓰던 시점의 HTML과 이를 마크다운으로 변환한 뒤 다시 HTML로 변환한 글은 완전히 똑같을 수는 없어서 본문 중심으로 비교를 시키더라도 꽤 차이가 있을 수밖에 없었다.

그래서 차이가 크게 나는 것 위주로 위의 아이프레임 비교 도구로 살펴보면서 잘못된 건 수정을 시켰다. 1,700여 개를 다 보진 못하고 낮은 매칭률부터 보다가 어느 정도 문제가 안 발생하기 시작하자 적당한 선에서 만족했다. 일부 깨진 게 있을 수도 있긴 한데 이번에 살펴보다 보니 기존 블로그에서도 이미 깨져서 잘못 나오던 부분도 있어서 전체적으로는 훨씬 깨진 부분이 적어졌다고 생각한다.

후기

엄청나게 많이 써본 것은 아니지만 이렇게 원하는 걸 만들어보니 코딩 에이전트를 쓰는 느낌도 알게 되었다. 업무에서도 쓰긴 하지만 주 업무가 기능 구현이 아니다 보니 많은 시간을 투자하지 않고 있었는데 원하는 요구사항이 머릿속에 확실한 상태에서 코딩 에이전트와 개발해 보니 꽤 신뢰할 수 있게 되었고 그동안 주워들은 정보가 많아서 어느 정도 사용할 수 있었다. 그리고 사람이 병목이라는 말이 어떤 느낌인지도 확실히 체감했다.

이번 작업으로 가장 좋은 건 블로그가 다시 유지보수 가능한 상태가 되었다는 것이다. Textcube를 20년 가까이 사용하면서 하나씩 고장 나면 고치고 하면서 점점 겨우 쓰던 느낌이었고 블로그 메인 기능이 아니면 고장 난 상태로 그냥 쓰고 있었지만 언제 또 주요 기능이 고장 날까 봐 불안해하던 상황이었다. 이번에는 일단 현재 블로그 기능을 그대로 유지한 채 정적 사이트로 마이그레이션하는 게 목적이라서 새로운 기능은 추가하지 않았지만, 그동안 하고 싶은데 못하던 것들도 있어서 앞으로는 쉽게 기능을 추가할 수 있게 되었다.

작업은 4월 12일에 시작해서 5월 6일에 끝났으니 한 달이 채 안 걸렸다. 더 열심히 돌렸으면 더 빨리했겠지만 퇴근하고 와서 작업을 못 한 날도 있어서 쉬는 날에 대부분의 진도를 나갔다. 그래도 사이드 프로젝트를 한참 안 해서 비어 있던 GitHub 잔디도 오랜만에 좀 채웠다.

다른 사람들은 훨씬 더 잘 쓰지만 코딩 에이전트로 이렇게 작업할 수 있다니 신기한 세상이긴 하다. 기존에도 못 만들진 않았겠지만, 이런저런 핑계로 만들지 않고 있었는데 확실히 AI 시대가 되니까 이런 작업도 후딱 할 수 있고 오랫동안 맘속에 있던 부채가 해결된 거 같아서 기분이 좋다. 버그가 계속 발견되겠지만 수정하면 되니까 걱정은 없다.

참고로 새 블로그에서는 Google Adsense도 빼버렸다. 한때 수익이 서버비 이상 정도는 들어오던 때도 있었는데 이유는 모르지만, 지금은 많이 내려가 버렸고, 광고는 더 많아져서 지면을 줄였는데도 블로그 이용도 불편한 수준이다. 예전엔 광고 엄청나게 싫어했다가 또 IT 업계에 있으면서 광고도 좀 알아야 한다는 핑계로 그동안 사용했는데 개편하고 나니 그냥 깔끔하게 유지하고 싶어졌다. 또 이번 달에 딱 Google Adsense가 $100 넘어서 정리하기도 좋은 시점이라고 생각했다.

Models	Input	Output	Cache Create	Cache Read	Total Tokens	Cost (USD)
opus-4-6 opus-4-7 sonnet-4-6	7,221	2,516,203	19,088,613	1,466,523,185	1,488,135,222	$915.36

정액제를 쓰다 보니 Claude Code에 저 비용을 내진 않았지만, 마이그레이션 알바 비용이라고 해도 그리 비싼 비용은 아니라고 생각한다. 체감하는 작업 내용에 비하면 많이 사용하진 않았다.

Model	Input	Output	Reasoning	Cache Read	Total Tokens	Cost (USD)
gpt-5.4	63,379,273	591,182	256,855	58,343,424	63,970,455	$35.38
gpt-5.5	27,451,868	124,608	69,615	25,778,560	27,576,476	$26.32

Codex는 해당 기간에 컨텐츠 비교만 시킨 게 아니라 다른 작업도 좀 하고 있어서 정확하진 않지만, 대략적인 걸 보려고 같이 남겨둔다.(Codex는 ccusage에서 나누어서 볼 수 없어서 그냥 기간으로만 뽑아봤다.)

이젠 블로그 마이그레이션도 끝났으니, CMS를 만들려고 한다. 정확히는 콘텐츠 관리는 아니니 CMS라기 보다는 글 작성 도구라고 할 수 있을 텐데 내가 블로그에 글을 쓰기 편하게 원하는 기능을 넣은 작성 도구를 만들어 보려고 한다.

기술 뉴스 #294 : 26-05-16

2026-05-16T17:06:54+09:00

웹개발 관련

Container Timing origin trial : Chrome 148부터 Container Timing performance API를 실험적으로 사용할 수 있다. Container Timing은 요소가 언제 로드되는지 알 수 있는 Element Timing을 확장해서 콘텐츠 블록이 사용할 수 있는 시점을 파악할 수 있다. 이은 HTML 요소에 containertiming 속성을 지정해서 해당 요소가 측정해야 함을 알려주고 PerformanceObserver로 관찰할 수 있다.(영어)

그 밖의 개발 관련

QUIC and HTTP/3 Come To Node.js (finally) : 아직 릴리스에 포함되진 않았지만 코드에 --experimental-quic 플래그를 통한 QUIC, HTTP/3 지원이 Node.js에 들어왔다. 실험적이지만 사용할 수 있게 되었으므로 Node.js에서 Quic을 어떻게 사용할 수 있는지를 설명한다.(영어)
Redis array type: short story of a long development : antirez가 Redis의 새로운 Array 데이터 타입을 구현했다. LLM을 이용해서 4개월 동안 작업했는데 LLM 없이도 4개월 정도면 구현했겠지만, LLM 덕에 훨씬 더 많은 일을 할 수 있게 되었다. 첫 달에는 사양 문서만 작성했는데 AI와 논의하면서 훨씬 더 진화할 수 있게 되었고 두 번째 달부터 자동 프로그래밍으로 구현을 시작했고, 코드를 한 줄씩 익으면서 비효율이나 오류를 수동이나 AI로 고쳤고 세 번째 달에는 다양하게 스트레스 테스트를 했다. 이러한 과정을 통해서 고품질 시스템 프로그래밍 작업에 여전히 관여해야 하지만 AI가 없었다면 하지 않았을 복잡성 수준에 도전할 수 있었는데 AI는 매우 피곤한 대규모 작업과 복잡한 알고리즘에 버그가 없는지 확인하는 데에 안전망을 제공해 준다는 것을 깨달았다.(영어)
An Overview of Spinel, Matz's AOT Ruby Compiler : Matz가 예전부터 가지고 있던 아이디어를 최근 Claude Code를 이용해서 한달 만에 Ruby AOT 컴파일러인 Spinel을 만들었다. Spinel은 Ruby 소스코드를 단독으로 실행할 수 있는 바이너리로 변환하는 AOT 컴파일러로 CRuby보다 상당한 속도를 보여준다. CRuby의 계승자는 아니지만 Ruby 4.0.2와 비교해 봤을 때 YJIT 비활성화 상태보다는 3%, YJIT 활성화 상태보다는 18% 정도의 시간 만에 컴파일이 되는 상당한 속도 차이를 보여주고, 이는 타입 추론을 통해 최적화된 C 코드를 생성하기 때문이다.(영어)
Formatting an entire 25 million line codebase overnight: the rubyfmt story : Fable Tales이 과거 RubyConf에서 Ruby 포매터에 대한 논의를 듣고 와서 혼자서 설정이 필요하지 않은 자동 포매터인 rubyfmt를 만들기 시작했고, 작업에 영향을 주지 않으려고 100ms라는 엄격한 기준을 두고 만들었다. 처음에는 Ruby로 만들었지만 점점 느려져서 Rust로 전환하게 되고 rubyfmt가 완성되진 않았지만, 세계에서 가장 큰 Ruby 코드 베이스를 가진 Stripe에 입사하게 된다. Stripe는 prettier-ruby를 도입하려고 했지만 너무 느렸기에 Fable Tales에게 rubyfmt를 적용할 수 있는지 논의를 시작했고, Stripe는 전담 엔지니어를 할당해서 rubyfmt를 오픈소스로 완성하게 되었다. 처음에는 옵트인 방식으로 포매팅을 적용하고 충돌이 생기지 않게 주말에 작업했지만 결국 Stripe의 4,200만 라인 전체를 rubyfmt로 포맷했고 아무런 문제가 발생하지 않았다.(영어)
Agent Harness Engineering : Google Gemini 팀의 Addy Osmani가 하네스 엔지니어링을 설명한 글이다. 모델 + 하네스를 에이전트라고 할 수 있고 모델을 감싸는 도구, 파일시스템, Git, 랄프 루프, 검증 방법 등이 모두 하네스이고 모델이 실패할 때마다 하네스에 추가해서 실수를 막아야 한다. 하네스를 잘 설계하려면 원하는 동작에서 출발해서 그 동작을 제공하는 컴포넌트를 만드는 것이다.(영어)
Karpathy's 4 CLAUDE.md rules cut Claude mistakes from 41% to 11%. After 30 codebases, I added 8 more : Andrej Karpathy가 1월 초에 Claude에 대한 불만을 올렸고 Forrest Chang이 이를 보고 CLAUDE.md 파일에 4가지 규칙을 정리해서 올렸다. 여기에 8개의 규칙을 더 추가해서 비슷한 성능으로 실수를 크게 줄였다. 각 규칙에 대한 설명과 기존 4개로는 충분하지 않은 상황, 시도했지만 효과가 없었던 방법 등을 설명한다.(영어)
SPZ 4 is here: leaner, faster, and more future-proof : 2024년 Niantic이 3D의 Gaussian spalt의 파일 형식인 SPZ를 공개했는데 더 큰 데이터셋을 지원하는 SPZ 4를 공개했다. SPZ 4는 압축과 로딩속도가 개선되어 인코딩이 3~5배 빨라졌고, 로딩은 1.5~2배가 빨라지고 저장 파일인 PLY 대비 더 작은 파일을 유지한다.(영어)
Using Claude Code: The Unreasonable Effectiveness of HTML : Anthropic에서 Claude Code를 만드는 Thariq Shihiparrk가 기존에는 마크다운을 문서로 많이 사용했지만, 표현력의 한계를 느껴서 이젠 HTML을 더 선호한다고 한다. HTML을 훨씬 읽기 쉽게 구성할 수 있기 때문에 만들어진 문서를 보기도 쉽고 공유하기도 쉬운 데다가 상호작용을 하게 만들 수도 있다. 이해를 돕기 위해 예시로 The unreasonable effectiveness of HTML 페이지도 공개했다.(영어)
Agent Skills : 시니어 엔지니어의 업무는 코드 변경 이력에 드러나지 않는 것들이 많은데 이러한 경험을 에이전트에도 적용될 수 있도록 Google Gemini 팀의 Addy Osmani가 스킬을 만들어서 공개했다. 이 스킬에는 소프트웨어 개발 생명주기의 단계를 포함하고 있으면 다음 5가지 원칙을 따르고 있고 이러한 접근은 Google의 관행을 따르고 있다.(영어)
1. 서술보다는 프로세스
2. 하기 싫은 부분을 건너뛰지 않는 합리화지 않도록 반합리화 테이블 작성
3. 검증은 협상할 부분이 아니다.
4. 점진적 공개
5. 범위 규율
Notion 개발자 플랫폼을 소개합니다 : Notion에서 호스팅 런타임을 Worker로 제공해서 ntn CLI로 커스텀 로직을 작성하고 배포할 수 있게 되었다. 비즈니스와 엔터프라이즈 플랜에서는 공개 베타를 8월까지 무료로 사용할 수 있다.(한국어)
Agent view in Claude Code : Claude Code에서 세션을 한곳에서 관리할 수 있는 Agent View 기능이 추가되었다.(영어)
Claude Code: Keep Claude working toward a goal : Claude Code가 /goal 명령어를 통해 완료 조건을 설정하면 조건을 충족할 때까지 작업을 계속 진행할 수 있게 지원한다.(영어)
GitHub Copilot app is now available in technical preview : GitHub Copilot 데스크톱 앱이 테크니컬 프리뷰로 공개되었다. 현재는 대기 리스트에서 승인받아야 사용할 수 있다.(영어)
Introducing Grok Build : xAI에서 터미널에서 사용할 수 있는 코딩 에이전트 Grok Build를 베타로 공개했고 SuperGrok Heavy 사용자를 대상으로 제공된다.(영어)

AI 관련

Gemini 3.1 Flash-Lite is now generally available on Gemini Enterprise Agent Platform : Google이 비용 효율성이 뛰어난 Gemini 3.1 Flash-Lite를 발표했다.(영어)
Advancing voice intelligence with new models in the API : OpenAI가 새로운 오디오 모델 3가지를 API에 도입했다. 더 어려운 요청을 처리하고 자연스러운 대화를 할 수 있는 GPT-Realtime-2, 화자의 속도에 맞춰 70개 이상의 언어를 13개의 언어로 라이브 전역하는 GPT-Realtime-Translate, 화자가 말하는 동안 실시간으로 음성을 텍스트로 전사하는 GPT-Realtime-Whisper를 공개했다.(영어)
Zeta2.1: 3x Fewer Tokens, 50ms Faster : 코드 에디터인 Zed의 편집 예측 모델인 Zeta2.1이 나왔다. 기존 Zeta2에 비해 30% 더 적은 토큰을 사용하면서 50ms 더 빨라졌다.(영어)

인프라 관련

State of Routing in Model Serving : Netflix에서 중앙 모델 서빙 플랫폼이 필요했는데 상용 솔루션으로는 요구사항을 만족하지 못해서 Switchboard라는 서비스를 직접 구축해서 클라이언트를 통일하고 컨텍스트 인식 라우팅 동적 트래픽 분리, 모델 라이프사이클 관리, 섀도우 테스트 등의 기능을 제공하고 Objectives 개념과 규칙을 도입해서 실험 구성을 서빙 플랫폼 코드와 분리할 수 있게 되었다. 이후 라우팅 제어를 더 세밀하게 하고 싶은데 Envoy만으로는 충분하지 않아서 Lightbulb를 만들어서 개선했다.(영어)
Introducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humans : AWS에서 서버에 원격 실행을 안전하게 할 수 있는 Trusted Remote Execution(Rex)을 공개했다. 이는 Rust용 스크립트 언어와 엔진인 rhai를 사용하고 정책 관리는 Cedar를 사용해서 사람이든 에이전트든 허용된 동작만 원격으로 실행할 수 있게 관리할 수 있다.(영어)
Kubernetes production readiness checklist : Kubernetes에 애플리케이션을 프로덕션으로 배포하기 전에 동작, 매니페스트 구성, 보안 등 확인해야 할 부분을 체크리스트로 만들었다.(영어)
Introducing the Claude Platform on AWS : Claude Platform이 AWS에서 제공되어 AWS 사용자가 AWS 인증과 인프라를 이용해서 Claude 기능을 사용할 수 있게 되었다.(영어)
Introducing Prempti: Falco meets AI coding agents : 클라우드 보안 도구인 Falco에서 코딩 에이전트의 액션을 감시하거나 차단하는 등의 액션을 할 수 있는 Prempti를 실험적으로 공개했다.(영어)

보안 및 장애

TeamPCP's Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Compromises TanStack npm Packages : TeamPCP가 OIDC 토큰을 사용해서 GitHub Actions 릴리스 파이프라인을 통해 Mini Shai-Hulud 웜을 포함한 악성 버전을 배포했다. 이는 유효하게 증명된 악성 패키지를 생성한 최초의 npm 웜으로 TanStack을 포함해서 UiPath, DraftLab 등의 170여 개의 패키지를 공격했고, 메모리를 읽어 시크릿과 크리덴셜 등 100개가 넘는 파일 경로에서 자격 증명을 수집하고 리부팅 후에도 훅을 설치했다. TanStack의 공격을 살펴보면 PR의 pull_request_target 워크플로우를 이용해서 GitHub Actions의 캐시를 오염시키고 이후 메인테이너가 릴리스를 할 때 오염된 캐시를 복원하고 OIDC 토큰을 이용해서 오염된 패키지를 게시했는데 이때 SLSA Level 3 신뢰 증명까지 포함되었다. Tanstack에서 Postmortem을 공개했다.(영어)
Mythos finds a curl vulnerability : Anthropic의 차세대 모델인 Mythos를 Project Glasswing을 통해 Linux 재단에 제공하면서 curl을 만든 Diniel Stenberg도 Mythos로 분석한 보고서를 받게 되었다. 기존에도 AI 도구를 사용해서 curl을 분석하고 취약점을 10건 이상 수정한 상태였는데 Mythos의 분석으로 5개의 취약점이 나왔지만, curl 보안팀에서는 이를 분석한 결과 3건을 오탐이고 1건은 버그로 판단해서 낮은 심각도로 분류한 1개만 취약점으로 분류했고 Mythos 모델은 약간 과대광고로 보인다고 한다.(영어)
Introducing deepsec: The security harness for finding vulnerabilities in your codebase : Vercel에서 코딩 에이전트로 코드 베이스에서 취약점을 찾아내는 보안 하네스 Deepsec을 오픈소스로 공개했다. Deepsec에서는 Claude와 Codex를 사용할 수 있고 플러그인 시스템으로 사용자 환경에 맞는 규칙을 적용할 수 있다.(영어)
Active attack: Dirty Frag Linux vulnerability expands post-compromise risk : Linux에서 새로운 로컬 권한 상승 취약점 Dirty Frag가 발견되었다. Dirty Frag는 rxrpc, esp/xfrm 네트워킹 및 메모리 단편화 처리 구성 요소를 통해 루트 권한을 획득할 수 있는 취약점이다.(영어)
NGINX Rift : 웹서버 NGINX의 ngx_http_rewrite_module에서 힙 버퍼 오버플로우를 이용해서 원격 코드 실행을 할 수 있는 취약점이 발견되었다.(영어)
Let's Encrypt Is Down. Renewals Are Next : Let's Encrypt에서 지난 5월 8일 UTC 기준 18:37부터 21:00까지 ACME 엔드포인트가 503을 반환하면서 인증서의 신규 발급과 갱신이 중단되었다.(영어)

볼만한 링크

Going Full Time on Open Source : 로컬 개발 환경 관리 도구인 mise를 만든 Jeff Dickey가 mise에 더 집중하기 위해서 Figma에서 퇴사하고 en.dev라는 만들어서 풀타임 오픈소스 개발을 하기로 했다. 수입은 문서 광고와 GitHub Sponsors로 약간 벌지만, 충분치 않기 때문에 멤버십과 스폰서십을 통해 지원받고 컨설팅을 할 것이라고 한다.(영어)
Vibe coding and agentic engineering are getting closer than I’d like : Simon Willison이 코드를 전혀 들여다보지 않고 작성하는 vibe coding과 보안, 유지보수성, 운영, 성능을 고려해서 고품질로 프로덕션 시스템을 만드는 agentic engineering을 구분하고 있었고 vibe coding은 개인 도구라면 괜찮지만, 다른 사람이 사용하는 프로덕션 시스템에 사용하면 무책임하다고 생각해 왔다. 하지만 코딩 에이전트가 더 신뢰할 수 있게 되면서 죄책감이 들면서도 프로덕션 수준의 코드도 모두 검토하지 않게 되고 vibe coding과 agentic engineering의 경계가 모호해지고 있다.(영어)
OpenSource is still art : Node.js 커미터인 James Snell의 글로 오픈소스와 소프트웨어 개발은 기존에도 단순한 엔지니어링이 아니라 공예이자 예술이었다. AI는 유용한 도구이지만 문제 이해, 설계 판단, 취향, 시스템적 사고는 여전히 숙련된 개발자의 몫이다. 하지만 AI로 인해서 일자리가 줄어들고 코드 학습, 저작권, 편향 같은 윤리적 문제는 커질 수 있다.(영어)
Cognitive Surrender : 인지적 오프로딩(cognitive offloading)은 AI에 위임하되 답에 대한 소유권을 유지하는 것이고 인지적 항복(cognitive surrender)은 AI의 출력물을 그대로 받아들이는 것을 의미하고 논문의 실험에서 대다수가 AI에 인지적 항복을 하는 것으로 나타났다. 소프트웨어 개발에서 인지 항복을 통해 인지 부채를 떠안게 되는데 이는 AI가 부채를 만드는 것이 아니라 AI를 대하는 태도에서 생기는 것이라 인지적 항복을 거부하는 조치를 설명한다.(영어)

IT 업계 뉴스

Rewrite Bun in Rust : JavaScript/TypeScript 런타임인 Bun이 알려진 대로 Rust로 재작성되었고 백만 라인 이상을 추가한 PR을 머지했다.(영어)
The Rust rewrite of pnpm was moved to the pnpm repository today : JavaScritp 패키지 매니저인 pnpm을 Rust로 재작성하는 코드가 pnpm 저장소에 합쳐졌다.(영어)

프로젝트

ds4.c : Redis의 창시자 Salvatore Sanfilippo가 만든 DeepSeek V4 Flash의 소형 추론 엔진
Oz Skills : Warp 터미널의 AI 에이전트와 Oz에서 사용하는 에이전트 스킬을 오픈소스로 공개했다.(영어)
serve-sim : Expo 개발자가 만든 Apple 시뮬레이터로 에이전트에서 사용할 수 있다.
Ghostty Config : Ghostty 터미널의 웹 기반 설정 생성기.
zero-native : Zig 언어와 웹 UI를 사용해서 데스크톱 앱이나 모바일 앱을 만들 수 있게 하는 도구로 Vercel에서 공개했다.
waza : 구조화된 벤치마크로 AI 에이전트 스킬을 평가하는 Go CLI로 Microsoft에서 만들었다.
rustdesk : 오픈소스 원격 데스크톱 애플리케이션.
Scion : 각 에이전트가 컨테이너 안에서 자신만의 워크스페이스 안에서 실행하게 하는 멀티에이전트 테스트베드.
Starpak : 코드를 계속 배포할 수 있는 오픈소스 에이전트.
Nelm : werf의 배포 엔진이면서 Helm 4의 대체제로, Helm으로 할 수 있는 걸 다 할 수 있으면서 terraform plan같은 2 스테이지 배포 지원과 CRD 관리, 시크릿 관리 등의 기능을 지원한다.
Better-Notify : 이메일, SMS, 텔레그램, Slack, Discord에 메시지를 보낼 수 있는 자바스크립트 라이브러리.
X For You Feed Algorithm : X의 For You 탭에서 사용하는 추천 시스템

버전 업데이트

Rolldown v1.0.0 : JavaScript/TypeScript 번들러, 릴리스 공지
- Vite를 염두에 두고 설계됨.
Electron v42.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
Viaduct v1.0.0 : GraphQL 데이터 지향 서비스 메시, 릴리스 공지, 관련 글
Valkey Admin v1.0.0 : Valkey 어드민, 릴리스 공지
Bazel v8.7.0 : 빌드 도구, 릴리스 공지
Oxlint v1.64.0 : JavaScript/TypeScript Linter, 릴리스 공지
Oxfmt v0.49.0 : JavaScript/TypeScript 포매터, 릴리스 공지
Node.js v26.0.0 (Current) : 자바스크립트 런타임, 릴리스 공지
- Temporal API 지원
Omarchy v3.8.0 : DHH가 만든 Arch Linux의 Hyprland 설정, 릴리스 공지
pnpm v11.1.0 : Node.js 패키지 매니저, 릴리스 공지
Tailwind CSS v4.3.0 : CSS 프레임워크, 릴리스 공지
ClickHouse v26.4 : 컬럼형 데이터베이스, 릴리스 공지
astro v6.3 : JavaScript 웹 프레임워크, 릴리스 공지
Kyverno v1.18 : Kubernetes 정책 엔진, 릴리스 공지
Zed v1.2.3 : 코드 에디터, 릴리스 공지
Terraform v1.15.0 : Infrastructure as Code 도구, 릴리스 공지
PyTorch v2.12.0 : Python 딥러닝 프레임워크, 릴리스 공지

기술 뉴스 #293 : 26-05-01

2026-05-01T21:28:32+09:00

웹개발 관련

Scroll-Driven Animations : 스크롤에 따라 애니메이션 효과를 CSS의 Animation Timeline API를 사용해서 만드는 방법을 튜토리얼처럼 설명한다.(영어)
Vercel April 2026 security incident : Vercel의 직원이 사용 중이던 타사 AI 도구 Context.ai가 해킹당하면서 공격자가 이 Vercel 직원의 Google Workspace 계정을 탈취해서 내부 환경에 접근하여 민감하지 않은 환경 변수를 해독할 수 있게 되었다. 소수 고객의 유출된 환경 변수를 고객에게 연락하여 교체하도록 했고 이후 조사에서 몇몇 계정이 해킹당한 것으로 밝혀졌다.(영어)
Introducing the Agent Readiness score. Is your site agent-ready? : Cloudflare에서 사이트가 Agent가 접근하기에 얼마나 잘 준비되어 있는지를 보여주는 Is Your Site Agent-Ready?를 공개했다. 이 서비스에서는 robots.txt부터 콘텐츠를 찾기 쉬운지, 마크다운을 제공하는지, 스킬이나 API 카탈로그 등을 제공하는지를 검사한다.(영어)
Self-updating screenshots : 프로젝트 문서의 스크린샷이 구식이 되는 문제를 막기 위해 마크다운 이미지에 주석을 넣어서 어떤 페이지의 어느 영역을 스크린샷 찍을지 지시어로 넣어 빌드할 때마다 자동으로 스크린샷을 찍어서 갱신되도록 만들었다.(영어)

그 밖의 개발 관련

Using Claude Code: Session Management & 1M Context : Claude Code에서 1M 콘텍스트도 더 오래 일할 수 있지만 그만큼 더 잘 관리해야 한다. 새로운 작업을 할 때는 새 세션을 여는 게 좋고 어떤 시도가 실패했을 때 대화를 이어갈 수도 있지만 rewind 명령어로 콘텍스트에서 그 부분을 제거할 수도 있고 명시적으로 clear 명령어로 콘텍스트를 압축하거나 새 작업을 위해 clear로 아예 날려줄 수도 있다. 또한 Subagent를 사용해서 특정 작업의 결과만 받아서 사용해서 콘텍스트를 유지하는 것도 가능하다.(영어)
Introducing Claude Design by Anthropic Labs : Claude로 디자인, 프로토타입, 슬라이드, 원페이지 자료 같은 시각적인 작업을 할 수 있는 Claude Design가 출시되었다. Claude Design은 Claude Opus 4.7을 기반으로 동작하고 이미지나 문서 파일을 임포트해서 작업할 수도 있다.(영어)
Android CLI and skills: Build Android apps 3x faster using any agent : 에이전트 워크플로우에 사용할 수 있도록 Android 스킬과 지식 기반을 모아놓은 CLI가 공개되었다. 이 CLI를 사용해서 Android Studio 외부에서 작업을 지시할 수 있게 되어 더 적은 토큰으로 빠르게 작업을 완료할 수 있게 되었다.(영어)
Claude Code Mobile push notifications : Claude Code에서 작업이 완료되었거나 결정이 필요할 때 모바일 앱에 푸시 알림을 보낼 수 있는 기능이 추가되었다.(영어)
Warp is now open-source : 새로운 세대의 터미널을 표방했던 Warp가 AGPL 라이선스의 오픈소스로 공개되었다. Warp의 에이전트 오케스트레이션 플랫폼인 Oz로 커뮤니티는 개발에 참여할 수 있고 OpenAI가 이번 오픈소싱의 후원사로 참여하고 에이전트 관리 워크플로우도 GPT 모델을 기반으로 한다.(영어)
AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG : SSO의 신뢰 모델을 API 접근 영역까지 확장해서 AI 에이전트에 쉽게 권한을 부여하고 안전하게 사용할 수 있게 하는 표준인 ID-JAG를 설명한 글이다.(한국어)

인프라 관련

Grafana Assistant everywhere: Customize and connect to the AI agent to fit your specific needs : Grafana에서 만든 Grafana Assistant를 Grafana Cloud뿐 아니라 OSS 버전에서도 사용할 수 있도록 공개되었다. Grafana Assistant를 사용하면 자연어를 사용하여 데이터 조회 및 대시보드 구축, 문제 해결에 AI의 도움을 받을 수 있다.(영어)
Introducing o11y-bench: an open benchmark for AI agents running observability workflows : Grafana에서 옵저버빌리티 워크플로우에서 AI 에이전트의 성능을 평가할 수 있는 o11y-bench를 오픈소스로 겅개했다. o11y-bench는 Grafana MCP 서버에 접근할 수 있는 Grafana 스택 환경에서 동작하며 3번의 실행에서 평균 점수를 보여주는 Pass^3와 3번의 시도 중 작업을 해결했는지 측정하는 최고 성공률 측정 지표인 Pass@3를 사용한다.(영어)
An early look at the Grafana Marketplace: Expanding the big tent : Grafana가 플러그인을 배포하고 판매할 수 있는 Marketplace를 발표했다.(영어)
otel.fyi - OTel Collector docs made simple : ClickHouse에서 OpenTelemetry Collector 문서를 찾기가 너무 힘들어서 직접 더 편한 문서 사이트 otel.fyi를 만들었다.
Copy Fail : 2017년 이후의 모든 Linux 배포판에는 732바이트의 Python 스크립트가 포함되어 있는데 로컬 사용자 계정만 있으면 이 스크립트를 이용해서 root 권한을 획득할 수 있는 취약점이 발견되었다.(영어)
Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign : 시크릿 관리 프로그램인 Bitwarden의 @bitwarden/cli2026.4.0에 악성코드가 포함되었다. 이번 공격은 Checkmarx 공급망 공격과 같은 방식을 따라서 GitHub Actions를 이용해서 손상된 버전을 배포 배포했다.(영어)
Securing GitHub: Wiz Research uncovers Remote Code Execution in GitHub.com and GitHub Enterprise Server (CVE-2026-3854) : 보안업체인 Wiz에서 GitHub와 GitHub Enterprise Server(GHES)에서 원격 코드 실행 취약점을 발견하고 GitHub과 협업해서 수정한 뒤 그 과정을 설명한 글이다. GHES의 바이너리를 AI로 분석해서 X-Stat 헤더를 조작해서 임의의 필드를 조작할 수 있다는 것을 발견하고 이를 이용해서 원격 코드를 실행할 수 있는 취약점을 발견했고, 이는 AI를 이용한 리버스 엔지니어링 덕분에 이전엔 불가능했던 취약점 발견이라고 한다.(영어)

AI 관련

Introducing Claude Opus 4.7 : Anthropic이 최신 모델 Claude Opus 4.7을 출시했다. Opus 4.7은 4.6보다 고급 소프트웨어 엔지니어링 분야에서 큰 성능 향상을 보여주고 다른 부분에서도 나은 점수를 보여주었다.(영어)
Claude Design : Claude로 프로토타입이나 슬라이드를 만들 수 있는 Claude Design이 출시되었다.(영어)
Introducing GPT‑5.5 : OpenAI에서 GPT의 최신 버전인 5.5를 출시했다.(영어)
ChatGPT 이미지 2.0 소개 : OpenAI에서 이미지 생성 모델인 ChatGPT Images 2.0을 출시했다.(한국어)
ChatGPT 워크스페이스 에이전트 소개 : ChatGPT에서 팀 내에서 장시간 실행되는 워크플로우를 처리할 수 있는 공유 에이전트를 만들 수 있는 워크스페이스 에이전트를 발표했다. 이 에이전트는 클라우드에서 실행되므로 자리를 비웠을 때도 작업을 처리할 수 있다.(영어)
Introducing Gemini Enterprise Agent Platform, powering the next wave of agents : Google에서 에이전트 구축, 확장, 관리 및 최적화를 할 수 있는 플랫폼인 Gemini Enterprise Agent Platform을 출시했다.(영어)
Our eighth generation TPUs: two chips for the agentic era : Google이 8세대 TPU를 발표했다. 높은 컴퓨팅 처리량과 확장 대역폭으로 학습 워크로드에서 성능이 뛰어난 TPU 8t와 지연시간에 민감한 추론 워크로드를 위해 많은 메모리 대역폭을 가진 TPU 8i의 두 가지 아키텍처로 공개했다.(영어)
DeepSeek V4 Preview Release : 비용효율적으로 1M 콘텍스트를 지원하는 DeepSeek-V4의 프리뷰 버전이 공개되었다. 이번 공개에는 1.6T 전체 파라미터에 49B 활성 파라미터를 가지고 세계 최고 수준의 클로즈 모델과 견줄만한 성능을 보여주는 DeepSeek-V4-Pro와 284B 전체 파라미터에 13B 활성 파라미터를 가진 DeepSeek-V4-Flash가 포함되어 있다.(영어)
Kimi K2.6: From Code to Creation, From One to Many : Moonshot AI에서 새로운 오픈소스 모델인 Kimi K2.6을 공개했다. K2.6은 코딩, 장기 실행, 에이전트 스웜 기능 지원이 특징이다.(영어)
Qwen3.6-35B-A3B: Agentic Coding Power, Now Open to All : Alibaba에서 Qwen3.6-Plus 공개에 이어 Qwen3.6-35B-A3B를 오픈소스로 공개했다. Qwen3.6-35B-A3B는 350억 개의 파라미터 중 30억 개의 활성 파라미터를 가진 MoE로 에이전트 코딩 성능이 좋고 다중 모달 사고를 지원한다.(영어)
perplexity Personal Computer가 왔습니다. : perplexity에서 macOS에서 백그라운드로 동작하면서 로컬 파일과 앱을 제어할 수 있는 앱을 공개했다.(영어)
생명과학 연구를 위한 GPT‑Rosalind 소개 : OpenAI가 생물학, 신약 개발, 중개 의학 전반의 연구를 지원하도록 설계된 GPT-Rosalind 추론 모델을 발표했다.(한국어)

볼만한 링크

Ghostty Is Leaving GitHub : Mitchell Hashimoto가 최근 만들고 있는 터미널인 Ghostty를 GitHub에서 다른 곳으로 이동할 것이라고 한다. 2008년 가입해서 18년 동안 매일 사용했지만 너무 좋아했지만 지난 한 달 동안 장애로 업무에 차질이 생긴 날짜를 표시했는데 매일 표시하게 되었고 더 이상 즐거운 곳이 아니라고 느껴서 떠나기로 결정했다.(영어)
Before GitHub : Armin Ronarcher가 GitHub을 정말 좋아했지만, 지금의 GitHub은 실망스럽고 조금씩 떠나는 사람들이 생기고 있다고 얘기한다. 하지만 분산될수록 비용은 커지기 마련이고 오픈소스 소프트웨어에는 아카이브가 꼭 필요하다고 생각하기에 GitHub이 회복되기를 바라지만 GitHub이 아니더라도 잘 보존할 수 있는 곳이 필요하고 이전처럼 각자가 저장소와 이슈트래커를 운영하고 싶진 않다고 한다.(영어)
How one programmer's pet project changed how we think about software : 프로그래밍 언어인 Clojure의 기원과 그 커뮤니티와 접근 방법에 대한 다큐멘터리다.(영어)
Throghtworks Technology Radar Volume 34 | April 2026 : Thoughtworks의 업계 기술 환경을 분석한 정기 보고서다. 이 보고서에서는 진지하게 고려해 볼만한 Adopt, 사용 준비는 되었지만 완전히 검증은 되지 않은 Trial, 살펴볼만하지만 아직 시도해 볼 필요는 없는 Assess, 대안을 고려하거나 피해야 하는 Caution 단계로 도구, 기술, 플랫폼, 언어 및 프레임워크를 분류한다.(영어)

IT 업계 뉴스

SpaceX obtains right to buy AI start-up Cursor for $60bn : SpaceX가 IPO를 앞두고 AI 코딩 에이전트 업체인 Cursor와 코딩 및 지식 기반 AI를 만들기 위해 협업하기로 계약하고 Cursor의 모회사인 Anysphere를 600억 달러에 인수할 수 있는 옵션을 갖게 되었다. 인수하지 않을 때는 협력에 대한 보상으로 100억 달러를 지급하기로 했다.(영어)
Elon Musk and Sam Altman face off in court over OpenAI’s founding mission : Elon Musk가 Sam Altman이 OpenAI를 AI의 안전과 개발적 접근에 중점을 둔 비영리 단체로 운영할 것이라고 약속한 뒤 영리 계열사 설립을 통해 부당 이득을 취했다는 소송의 재판이 지난 27일 시작되었다. OpenAI는 이를 부인하며 질투심과 회사를 떠난 것에 대한 후회에 사로잡혀있다고 반박했다.(영어)
Apple CEO Tim Cook is stepping down : Apple CEO인 Tim Cook이 물러나고 하드웨어 엔지니어링 부사장인 John Ternus가 9월 1일부터 새로운 CEO를 맡게 되었다.(영어)
OpenAI와 Amazon, 전략적 파트너십 발표 : OpenAI와 AWS가 파트너십을 맺고 OpenAI 프론티어의 독점 클라우드 배포 업체가 되고 Stateful Runtime Environment를 공동 개발할 것이고 Amazon이 500억 달러를 OpenAI에 투자할 예정이다.(한국어)
Series A for exe.dev : 가상 머신을 간편하게 사용할 수 있는 exe.dev가 시리즈 A 투자를 유치해서 3,500만 달러의 자금을 확보했다.(영어)

프로젝트

IAM Policy Autopilot : Python, Go, TypeScript, JavaScript, Java 코드를 분석해서 필요한 권한을 생성할 수 있게 하는 MCP와 CLI.
rhwp - HWP Document Viewer & Editor : 오픈소스 HWP/HWPX 뷰어 및 에디터인 rhwp의 크롬 확장.
Ratatui : 터미널 유저 인터페이스를 만들 수 있는 Rust 라이브러리
AG-UI Protocol : AI 에이전트가 애플리케이션과 어떻게 연결되는지를 정의한 경량 프로토콜.
gcx — Grafana Cloud CLI : Grafana Cloud를 관리할 수 있는 CLI.
Perry : Rust로 작성한 TypeScript 컴파일러
A collection of principles and patterns that shape software systems, teams, and decisions. : 소프트웨어 시스템이나 팀, 의사결정과 관련된 원칙과 패턴을 정리해 놓은 사이트.
GitHub Quick Review : GitHub Enterprise, 조직, 저장소가 베스트 프렉티스와 보안 권장 사항을 잘 따르는지 분석해 주는 CLI로 Microsoft에서 만들었다.
VibeVoice: A Frontier Open-Source Text-to-Speech Model : Microsoft에서 공개한 긴 형식의 여러 명의 대화형 오디오를 생성할 수 있는 오픈소스 TTS 모델
OpenDataLoader : AI를 위한 데이터용 PDF 파서
Voicebox : 오픈소스 AI 보이스 스튜디오.
git-sync : 저장소에서 다른 원격 저장소로 git을 동기화할 수 있는 프로젝트.
Quarkdown : Markdown과 LaTeX를 합친 조판 시스템.

버전 업데이트

Ubuntu 26.04 LTS Resolute Raccoon : Linux 배포판, 릴리스 공지
Grafana v13.0 : 매트릭 대쉬보드, 릴리스 공지
Grafana Pyroscope v2.0 : 지속적 프로파일링 도구, 릴리스 공지
Kubernetes v1.36 ハル (Haru) : 컨테이너 오케스트레이션 도구, 릴리스 공지
- kubelet API 권한 부여 기능이 GA가 됨.
- User Namespace 지원이 안정화되어 컨테이너 격리와 노드 보안이 강화됨.
TypeScript v7.0 Beta : Microsoft가 만든 JavaScript transpiler, 릴리스 공지
- 코드베이스를 Go로 바꾸어 6.x보다 최대 10배 빠른 7.0의 첫 베타 버전
Rspack v2.0.0 : 웹 번들러, 릴리스 공지
Zed v1.0.0 : 코드 에디터, 릴리스 공지
Windsurf v2.0.0 : AI 코드 에디터, 릴리스 공지
OpenSSL 4.0.0 : TLS/SSL 툴킷, 릴리스 공지
- SSLv3 지원 중단
- Encrypted Client Hello(ECH) 지원
pnpm v11.0.0 : Node.js 패키지 매니저, 릴리스 공지
ava v8.0.0 : JavaScript 테스트 러너, 릴리스 공지
FastAPI v0.136.0 : Python 웹 프레임워크, 릴리스 공지
Node.js v24.15.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Git v2.54.0 : 분산 형상관리 도구, 변경사항
- git rebase -i보다 간단하게 히스토리를 재작성할 수 있는 실험적 명령어 git history 도입.
- 새로운 훅 설정 방식의 도입으로 .git/hooks/pre-commit을 저장소마다 설정하는 대신 hook.<name>.command 형식으로 .gitconfig에 설정할 수 있게 됨.
Oxlint v1.61.0 : JavaScript/TypeScript Linter, 릴리스 공지
Oxfmt v0.46.0 : JavaScript/TypeScript 포매터, 릴리스 공지
Fresh v2.3 : Deno 풀스택 웹 프레이워크, 릴리스 공지
Omarchy v3.6.0 : DHH가 만든 Arch Linux의 Hyprland 설정, 릴리스 공지
Nx v22.7.0 : 모노레포 빌드 시스템, 릴리스 공지
NATS Server v2.14 : 고성능 경량 메시징 시스템, 릴리스 공지
astro v6.2 : JavaScript 웹 프레임워크, 릴리스 공지

기술 뉴스 #292 : 26-04-16

2026-04-16T09:19:18+09:00

웹개발 관련

Introducing a new spam policy for "back button hijacking" : 뒤로 가기 하이재킹은 뒤로 버튼을 눌렀을 때 이전 페이지로 가지 않고 광고를 띄우거나 다른 페이지로 가게 하는 것을 얘기한다. 이는 사용자 경험을 나쁘게 하고 조종당하는 느낌이 들기 때문에 구글 서치 센터에서는 뒤로 가기 버튼을 악용하는 페이지는 6월 15일부터 검색 결과에서 제재받을 수 있다.(영어)
WordPress의 정신적 후계자로서 플러그인 보안 문제를 해결하는 EmDash 소개 : Cloudflare에서 두 달 동안 WordPress를 에이전트로 새로 구축해서 Astro 기반의 CMS EmDash를 만들었다. EmDash의 플러그인은 Dynamic Workder에서 동작해서 보안 문제를 해결했고 x402 인터넷 네이티브 결제 표준을 도입해서 누구나 요금을 지급할 수 있다.(한국어)
The uphill climb of making diff lines performant : GitHub의 파일 변경 사항 탭이 대규모 풀 리퀘스트에서는 눈에 띄게 성능이 떨어지는 문제가 발생했다. 기존 React를 사용한 화면에서는 diff line마다 너무 많은 DOM과 이벤트 핸들러가 필요했기에 성능에 영향을 주었고 DOM 구조를 간소화하고 컴포넌트 트리를 간소화하고 useEffect를 최상위에서만 동작하게 해서 최적화했다. 이러한 개선으로 메모리가 50% 줄어들고 INP가 78% 빨라졌지만, 화면에 보이는 부분의 DOM만 유지하는 윈도우 가상화를 통해 P95+에 해당하는 대형 풀 리퀘스트에서 메모리가 10배 감소하고 INP도 10배 가까이 줄어들었다.(영어)
Turn your best AI prompts into one-click tools in Chrome : Chrome이 Skills 기능을 출시해서 프롬프트를 스킬로 저장해서 필요할 때 재사용할 수 있게 되었다.(영어)

그 밖의 개발 관련

GitHub Stacked PRs : GitHub에서 Pull Request를 나누어서 올릴 수 있는 Stacked PR을 만들 수 있는 GitHub CLI 익스텐션을 공개했다.(영어)
새로운 Cursor를 만나보세요 : Cursor가 에이전트 중심으로 인터페이스를 새로 만든 Cursor 3를 발표했다.(한국어)
Claude Code /autofix-pr : Claude Code에서 CI 실패나 리뷰를 자동으로 처리하는 /autofix-pr 커맨드를 추가했다.(영어)
Claude Code monitor tool : Claude Code에서 폴링으로 확인하지 않고 백그라운드 스크립트로 특정 상황을 감지했을 때 에이전트를 실행할 수 있는 모니터 도구가 추가되었다.(영어)
Claude Code Routines : Claude Code에서 스케쥴 설정 외에도 웹훅이나 API를 통해서도 에이전트를 실행할 수 있는 루틴 기능을 공개했다.(영어)
Claude Managed Agents: get to production 10x faster : Anthropic에서 클라우드 기반 대규모 에이전트를 구축하고 배포할 수 있는 Claude Managed Agents를 출시했다.(영어)
AI Contribution Policy for the Flux project : Flux 프로젝트가 기여할 때 AI에 대한 가이드를 만들었다. AI 에이전트를 쓰더라도 사람이 검토해야 하며 커밋에 Co-authored-by를 쓰지 말고 사람이 DCO를 인증해야 하며 AI 에이전트를 쓴 경우 Assited-by로 에이전트와 모델명을 적으라고 안내한다.(영어)

인프라 관련

Amazon S3 Files 정식 출시 – S3 버킷을 파일 시스템처럼 접근 가능 : AWS에서 S3 버킷을 NFS로 연결해서 파일시스템처럼 사용할 수 있는 S3 Files를 발표했다.(영어)
Two Years of Valkey : ValKey가 Redis를 포크한 후 2년간 커밋수, 참여자 수, 참여 조직 수를 분석한 글이다. 현재까지는 ValKey가 더 다양하고 많은 기여를 박으면서 유지되고 있다.(영어)
Kubernetes Monitoring Helm chart v4: Biggest update ever! : Grafana가 Kubernetes 모니터링 Helm 차트의 새 버전을 공개했다. v3에서 다양한 환경에서 설정하기 어려웠던 부분을 개선해서 쉽게 설정하고 유연하게 사용할 수 있도록 개선되었다.(영어)
Introducing clickhousectl: the CLI for ClickHouse local and cloud (beta) : ClickHouse의 공식 CLI인 clickhousectl이 베타 버전으로 공개되었다.(영어)
Docker Offload now Generally Available: The Full Power of Docker, for Every Developer, Everywhere. : Docker를 클라우드 환경에서 실행하는 Docker Offload기능이 공개되었다. Docker Desktop 앱에서 바로 사용할 수 있으며 컨테이너 엔진을 클라우드에서 실행해서 기존에 사용하던 모든 명령어를 사용할 수 있다.(영어)
Secure private networking for everyone: users, nodes, agents, Workers — introducing Cloudflare Mesh : Cloudflare에서 프라이빗 네트워크를 연결하고 에이전트가 안전하게 접근할 수 있게 하는 Cloudflare Mesh를 발표했다. 이를 통해 에이전트가 Cloudflare에 안전하게 접근할 수 있고 모바일, 노트북, 서버에서 모두 사용할 수 있다.(영어)

AI 관련

Project Glasswing : Anthropic의 새로운 프론티어 모델인 Claude Mythos에서 소프트웨어 취약점을 악용하는데, 뛰어난 능력을 보여준다는 것을 발견하고 소프트웨어를 보호하기 위해 AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux 재단, Microsoft, NVIDIA, Palo Alto Networks와 함께 Mythos Preview를 제공하고 시스템을 보호할 수 있게 하는 Glasswing 프로젝트를 시작한다고 발표했다.(영어)
System Card: Claude Mythos Preview : Anthropic의 새로운 프론티어 모델인 Claude Mythos Preview를 설명한 245페이지의 문서다.(영어)
Gemma 4: Byte for byte, the most capable open models : Google이 오픈 소스 모델인 Gemma 4를 공개했다. Gemma 4는 Effective 2B(E2B), Effective 4B(E4B) , 26B Mixture of Experts(MoE) , 31B Dense 네 가지 크기로 제공되며 추론 능력, 에이전트 기반 워크 플로, 코드 생성, 영상 및 오디오에서 뛰어난 성능을 보여주고 더 긴 컨텍스트를 지원하고 140개 이상의 언어를 지원한다.(영어)
GLM-5.1: Towards Long-Horizon Tasks : Z.ai에서 새로운 플래그십 모델 GLM-5.1을 발표했다. GLM-5.1은 코딩 기능이 크게 향상되었고 더 긴 시간 동안 에이전트 기반 작업에서 효율성을 유지하도록 설계되었다.(영어)
Qwen3.6-Plus: Towards Real World Agents : Alibaba에서 새로운 모델 Qwen3.6-Plus를 발표했다.(영어)
The advisor strategy: Give agents an intelligence boost : Anthropic에서 오케스트레이터 모델의 반대라고 할 수 있는 어드바이저 모드를 도입했다. 어드바이저 모드는 Sonnet이나 Haiku를 실행자로 사용하면서 판단이 필요할 때는 Opus를 어드바이저로 사용하면 저 적은 비용으로 더 나은 결과를 만들 수 있다.(영어)
Gemini 앱, 이제 Mac에서 사용 가능 : Google Gemini의 macOS 앱이 출시되었다.(한국어)

볼만한 링크

프롬프트에서 하네스까지 — AI 에이전틱 패턴 4년의 기록 : GitHub Copilot이 나오고 ChatGPT가 나온 뒤 지금까지 4년 사이에 패러다임은 프롬프트 엔지니어링에서 컨텍스트 엔지니어링을 거쳐 하네스 엔지니어링의 시대로 바뀌었고, 이는 그 이전 시대가 실패하면서 다음 시대로 이어진 것이다. 지난 4년간 어떤 변화가 있었는지를 자세히 다룬 글이다.(한국어)
Agent responsibly : 코딩 에이전트가 생산성을 크게 향상 시키지만 운영 환경을 이해하지 못하므로 위험한 코드를 배포할 수 있다. AI에 의존하는 것과 활용하는 것은 다르므로 AI가 생성한 코드의 책임을 져야 한다. 이를 위해서 자율 주행 방식의 배포로 문제가 생기면 자동으로 롤백할 수 있게 구성하고 배포 때뿐 아니라 지속적으로 테스트를 수행하고 가이드라인을 실행할 수 있게 만들어서 에이전트가 이를 따르도록 해야 한다. 에이전트를 활용하되 전적으로 의존하지 말라고 조언한다.(영어)
LLM Wiki : Andrej Karpathy가 LLM을 활용해서 개인 지식 기반을 구축하는 패턴을 공개했다. 이는 문서를 LLM에 주고 질문하면 LLM은 매번 문서를 읽어야 하므로 구조화되고 연결된 마크다움 파일 모음으로 위키를 구축해서 관리하는 방법이다. 모든 것은 LLM이 작성하고 관리하게 되는데 원본 자료를 모아두고 LLM이 이에 대해 정리한 위키를 작성하고 LLM이 따라야 할 워크플로우를 관리하는 문서인 스키마를 유지하도록 하는데 이를 LLM에 제공해서 직접 사용할 수 있게 한 문서다.(영어)
Your parallel Agent limit : 병렬로 에이전트를 여러 개 실행하는 경우 금방 지치게 되거나 생각보다 병렬로 실행하는 수를 늘리기가 쉽지 않다. 이는 컨텍스트 전환에 생각보다 큰 비용이 들고 백그라운드에서 실행되는 작업의 신뢰성을 확인해야 하는 부담이 생기게 된다. 그래서 확장성의 핵심은 이해의 처리량이 아니라 감독의 처리량이 되어야 하고 자신의 한계가 어디인지를 이해해야 파악해야 한다.(영어)
Is the FDE role becoming less desirable : FDE(Forward Deployed Engineer)를 기업들은 원하지만, 개발자는 별로 관심이 없는 것처럼 보인다. 현장에 배치되어 고객과 핵심 개발팀을 오가며 일하는 FDE의 역할을 플랫폼 엔지니어, 소프트웨어 엔지니어, 솔루션 아키텍트의 공통되는 영역을 담당하는 것으로 생각했으나 실제 FDE를 맡았던 사람들은 FDE가 실제로는 솔루션 아키텍트와 거의 비슷한 역할을 해서 실망했다고 얘기했다고 한다.(영어)
Endgame for the Open Web : 개방형 웹은 놀라운 개념으로 그동안 계속 공격당해 왔지만 AI로 훨씬 강한 공격을 받고 있다. 이번 공격은 존재 자체가 위협받고 있는데 무료컨텐츠로 수익화하기 어려워졌고 AI가 컨텐츠를 사용하고도 출처를 표시하지 않기 때문에 많은 서비스가 무료 접근을 차단하고 있다. 이는 몇몇 플랫폼이 공격받는 문제가 아니라 웹을 개방적으로 유지하는 사람들의 관대함과 헌식이 악용당하고 착취당하는 게 더 큰 문제라고 얘기한다.(영어)
Prepping for the endgame of the open web : 바로 위의 개방형 웹에 대한 공격에 관한 생각은 동의하지만, 그동안 개방형 웹에 대한 공격은 항상 있었지만, 그동안 했듯이 개발형 웹을 계속 발전시키고 해를 끼치려는 기술에 저항해 나가면 이겨낼 수 있다고 얘기한다.(영어)

IT 업계 뉴스

SpaceX Files to Go Public, Setting Stage for Huge I.P.O. : Elon Musk의 로켓/위성 제조업체인 SpaceX가 IPO 신청서를 제출했다. 6월 상장에서 500~750억 달러를 조달하는 것을 목표로 하고 있으며 기업 가치가 1조 달러 이상이 되어 역사상 최대 규모의 IPO가 될 것으로 예상된다.(영어)
Cirrus Labs to join OpenAI : 2017년에 창업해서 SaaS CI/CD를 만들고 Apple Silicon을 위한 가상화 솔루션인 Tart를 만든 Cirrus Labs가 OpenAI에 인수되었다.(영어)
We’ve raised $17M to build what comes after Git : GitHub의 공동 창업자 중 한 명인 Scott Chacon이 창업한 GitButler가 1,700만 달러 규모의 시리즈 A 투자를 유치했다.(영어)

프로젝트

rhwp : Rust와 WebAssembly로 만든 오픈소스 HWP/HWPX 뷰어 및 에디터.
Bibim : 국한문/CJK 통합 입력기로 데모로 확인해 볼 수 있다.
SCIENCE@home : 로컬에 CLI를 설치하면 LLM 토큰이 남을 때 논문 읽고 연결해서 과학 발전에 기여할 수 있는 프로젝트.
Open Agents : Vercel에서 공개한 에이전트 코딩 클라우드 환경.
OpenSRE : 오픈소스 SRE 에이전트
purplemux : tmux 기반 멀티 세션 대시보드.

버전 업데이트

DuckLake v1.0 : 데이터 레이크, 릴리스 공지
Optique v1.0.0 : TypeScript용 타입세이프 CLI 파서, 릴리스 공지
Node.js v25.9.0 (Current) : 자바스크립트 런타임, 릴리스 공지
kubectx v0.11.0 : kubectl에서 컨텍스트를 쉽게 변경하는 도구, 릴리스 공지
- -r 플래그로 읽기 전용 쉘을 띄울 수 있다.
Storybook v10.3.0 : React, Vue3, Angular UI 컴포넌트 개발 도구, 릴리스 공지
ClickHouse v26.3 : 컬럼형 데이터베이스, 릴리스 공지
Zig v0.16.0 : 프로그래밍 언어, 릴리스 공지

기술 뉴스 #291 : 26-04-01

2026-04-01T20:24:35+09:00

웹개발 관련

React SSR Framework Showdown: TanStack Start, React Router, and Next.js Under Load : Platformatic에서 TanStack Start, React Router, Next.js로 이커머스 앱을 만들어서 벤치마크 테스트를 한 결과 자사의 Node.js 애플리케이션 서버인 Watt에서 레이턴시가 개선되고 TanStack이 가장 우수한 성능을 보였고 Next.js는 가장 성능이 떨어졌지만, v15, v16에서 큰 차이가 나서 개선이 계속되고 있다. 이 벤치마크 결과를 해당 팀들과 공유해서 Next.js에서는 RSC의 JSON.parse의 reviver 콜백 사용으로 인한 오버헤드를 찾아 React를 수정해서 모든 RSC가 혜택을 얻을 수 있는 개선을 했고 TanStack팀은 250배 이상의 성능 개선을 해냈다.(영어)
Modal vs. Separate Page: UX Decision Tree : 화면에서 백그라운드와의 인터렉션을 막는 모달과 논모달의 차이를 설명하고 사용자의 행동에 침투적으로 개입하는 모달의 장단점을 설명한다. Ryan Neufeld가 정리한 모달과 페이지 중 어떤 것을 선택할지를 결정한 의사 결정 트리를 소개한다.(영어)
Announcing JetStream 3.0 : Apple, Google, Mozilla 등이 협업해서 브라우저 성능을 추적하고 엔진의 최적화를 이끌기 위해 만드는 벤치마크 중 하나로 웹 애플리케이션의 계산 집약적인 부분에 집중하는 JetStream이 6년 만에 새 버전이 나왔다. JetStream 3는 이전보다 더 큰 애플리케이션에 중점을 주고 최신 기능인 WebAssembly에도 큰 비중을 두고 Promise나 Async 같은 새로운 JavaScript 기능에 대한 부분도 추가되었다.(영어)

그 밖의 개발 관련

Harness design for long-running application development : Anthropic에서 장기 실행 자율 코딩을 실험한 과정을 정리한 글이다. 기획자, 생성자, 평가자의 세 에이전트를 구분해서 피드백 루프를 구성한 후 프론트엔드 어플리케이션을 만들도록 한 뒤 이를 풀스택 개발에 적용해서 레트로 게임 메이커를 만들게 했다. Solo 모드로 만든 것보다 장기 실행을 위한 하네스를 적용한 시도가 토큰도 많이 쓰고 오래 걸렸지만 훨씬 정교한 게임 메이커가 나왔다. 이후 하네스를 효율적으로 만들기 위해 반복해서 축소하고 성능을 비교하는 중에 Opus 4.6이 나왔고, 기존에 스프린트 구조는 제거하고 플래너와 평가자는 유지한 채 여러 번 시도한 결과 한 줄짜리 프롬프트로 전체 명세를 확장하고 핵심 요소를 모두 갖춘 프로그램을 만들 수 있었다.(영어)
Claude Code auto mode: a safer way to skip permissions : Claude Code 사용자는 승인 요청을 93% 승인하는데 --dangerously-skip-permissions가 있지만 안전하지 않은 문제가 있다. 이번에 새로 추가된 Auto mode는 승인을 모델에 의존해서 사용자의 의도에 맞지 않는 위험한 행동을 파악하고 그 외에는 승인 프롬프트 없이 실행되도록 하는 기능이다.(영어)
Codex Use Cases : OpenAI에서 Codex 사용 사례를 공개했다. 이 사용 사례에는 Pull Request 리뷰 빨리 받기, 프론트엔드 반응형 디자인 만들기, macOS 앱 만들기 등의 스킬과 프롬프트를 알려준다.(영어)
Composer 2를 소개합니다 : Cursor가 자체 코딩 모델인 Composer 2를 발표했다. 여러 벤치마크 결과 높은 성능을 보여주면서 저렴한 비용으로 제공할 수 있으며 이 자체 모델이 Kimi-k2.5 기반으로 알려지면서 논란이 되었지만 사전 파트너십으로 진행된 일임이 밝혀졌다.(한국어)
Introducing “vibe design” with Stitch : Google이 AI로 웹이나 모바일 앱을 디자인할 수 있는 Stitch의 새로운 버전을 Beta로 출시했다.(영어)
Agent first, agent native : 37signals에서 Basecamp를 에이전트가 사용할 수 있도록 새로운 CLI와 스킬을 제공한다.(영어)

인프라 관련

Trivy Under Attack Again: Widespread GitHub Actions Tag Compromise Exposes CI/CD Secrets : 보안 스캐너인 trivy가 다시 한번 공급망 공격을 받았다. 지난 2월 공격에서 CI 환경의 자격 증명이 유출되었고, 이 때의 후속 조치로도 공격자가 새로 만든 자격 증명이 계속 권한을 가지고 있었던 것으로 보인다. 공격자는 공격이 알려지지 않도록 aquasecurity/trivy-action에 새로운 브랜치를 올리거나 새로운 릴리스를 올리지 않고 기존 태그 75개를 강제 푸시해서 악성코드가 포함된 커밋을 가리키도록 했다. 그래서 trivy-action를 버전으로 지정해서 사용하는 경우 이번 공격의 영향을 받았으며 보안 검사를 실행하기 전 악성코드를 실행해서 비밀 정도를 탈취한 뒤 스캔은 정상적으로 실행해서 사용자가 이상을 느끼지 못하게 만들었다.(영어)
LiteLLM Security Update: Suspected Supply Chain Incident : AI 게이트웨이 Python 패키지 LiteLLM의 1.82.7과 1.82.8이 오염된 상태로 UTC 기준 3월 24일 10:39부터 40분간 배포되었다고 PyPI에서 차단되었다. 이전에 발생했던 Trivy의 보안 침해에서 얻은 크리덴셜을 이용해서 LiteLLM의 릴리스 파이프라인에 접근한 것으로 파악되었고 설치한 곳의 시크릿을 수집해서 공격자의 서버로 보내게 되어 있었다.(영어)
Supply Chain Attack on Axios Pulls Malicious Dependency from npm : JavaScript에서 널리 사용되어 주간 1억 다운로드를 받고 있는 HTTP 클라이언트인 Axios를 노린 공급망 공격이 발생했다. 이번 공격은 최신 버전은 axios@1.14.1과 axios@0.30.4에서 발생했으면 악성 패키지인 plain-crypto-js@4.2.1을 불러와서 감염된 기기에 명령을 실행할 수 있는 원격 접근 트로이목마(RAT)를 설치한다. plain-crypto-js@4.2.1는 UTC 기준 30일 23:59:12에 게시되었고, Axios의 정식 배포 릴리스를 타지 않은 것으로 보이는 axios@1.14.1과 axios@0.30.4에 plain-crypto-js@4.2.1 의존성을 추가해서 이어서 게시되었으며 postinstall 훅을 이용해서 설치 후 바로 RAT가 설치되도록 했다. Google Threat Intelligence Group은 이번 공격이 금전적 동기를 가진 북한 연계 공격자 UNC1069로 판단했다.(영어)
Agent Auth Protocol : 기존의 인증이 인간과 애플리케이션이라는 두 주체를 전제로 하고 있는데 에이전트는 이 양쪽에 속하지 않기 때문에 사용자를 대리한 에이전트가 자율적으로 동작하며 원하는 서비스를 찾을 수 있도록 만들어진 공개 프로토콜이다.(영어)
How DNS Actually Works in Kubernetes? — CoreDNS Explained : Kubernetes에서 트래픽을 라우팅하는 핵심 컴포넌트인 CoreDNS의 동작 방식을 간결하게 설명하는 글이다. DNS 질의가 발생했을 때 /etc/resolv.conf와 CoreDNS가 어떻게 설정되어 있고 ndots 설정이 DNS 질의에 어떤 영향을 주는지 설명하고 간단하게 트러블슈팅할 수 있는 명령어를 알려준다.(영어)
The Invisible Rewrite: Modernizing the Kubernetes Image Promoter : Kubernetes 팀은 새로운 릴리스를 할 때 2018년부터 만들어진 kpromo라는 도구를 통해 스테이징 레지스트리에 있던 이미지를 프로덕션으로 복사하고 서명하고 전 세계에 복제하는 등의 작업을 수행하게 된다. 시간이 지나면서 이 프로덕션 프로모션 작업은 30분 이상 걸렸고, 실패도 많았으며 기능 확장도 어려웠기에 SIG에서 파이프라인 아키텍처를 재작성하고 미뤄두었던 많은 개선 작업을 할 수 있게 되었다.(영어)
ONCE (Again) : 37Signals에서 24년에 ONCE라는 서비스를 한 번의 비용을 내면 자체 호스팅하는 웹 앱을 판매하는 목적으로 공개하고 기존에 가지고 있던 소프트웨어인 Campfire, Writebook, Fizzy 등을 판매했다. 하지만 이는 성공적이지 않았고 요즘 AI로 쉽게 서비스를 만들 수 있게 된 만큼 쉽게 서비스를 배포하고 모니터링할 수 있는 배포 도구로 개념을 바꾸었다.(영어)
Running Agents on Kubernetes with Agent Sandbox : 대부분의 서버는 stateless이지만 에이전트는 지속적으로 실행되고 유휴상태인 경우도 있으며 유지할 수 있는 볼륨이 필요하다는 점에서 Kuberntes의 특성과 잘 맞지 않는 문제가 있다. 이를 해결하기 위해 SIG Apps에서 Agent Sandbox를 만들어서 격리된 환경으로 에이전트에 맞는 수명 관리를 할 수 있는 CRD를 만들고 있다.(영어)
Sandboxing AI agents, 100x faster : Cloudflare에서 에이전트를 안전한 격리 환경에서 빠르게 실행할 수 있도록 Dynamic Workder Loader를 오픈 베타로 공개했다.(영어)
Let Claude use your computer from the CLI : Claude Code가 컴퓨터를 제어할 수 있게 하는 기능이 추가되었다.(영어)

AI 관련

Exclusive: Anthropic acknowledges testing new AI model representing ‘step change’ in capabilities, after accidental data leak reveals its existence : Anthropic이 실수로 공개한 데이터에서 Mythos와 Capybara라는 Opus보다 크고 지능적인 새로운 계층의 모델을 준비 중인 것으로 밝혀졌고 둘은 같은 기반 모델을 사용하는 것으로 보인다. 유출된 문서에서는 Claude Copybara를 대규모 사이버공격에 사용할 가능성을 우려해서 사이버 방어자들에 초점을 맞추어서 공개할 예정이라고 한다.(영어)
Anthropic goes nude, exposes Claude Code source by accident : Anthropic이 Claude Code의 npm 패키지를 게시하면서 실수로 Source Map을 포함했다. 이 Map 파일에는 난독화되지 않은 TypeScript 소스에 대한 참조가 있었고, 이는 Anthropic이 사용하는 Claudeflare R2 스토리지 버킷을 가리키고 있었는데 이 zip 파일을 다운받으면 1,900개의 TypeScript 파일과 51만 줄의 코드 등이 들어있어서 Claude Code의 소스코드가 모두 유출되었고, Anthropic은 사람의 실수였다고 인정했다.(영어)
GPT‑5.4 mini 및 nano 출시 : OpenAI가 소형 모델인 GPT-5.4 mini와 GPT-5.4 nano 모델을 새로 공개했다.(한국어)
MiniMax M2.7: Early Echoes of Self-Evolution : MiniMax에서 새로운 모델인 M2.7을 발표했다.(영어)
TurboQuant: Redefining AI efficiency with extreme compression : Google에서 고차원 벡터의 메모리 오버드 문제를 해결하는 양자화 알고리즘을 공개했다. TurboQuant는 정확도 손실 없이 모델 크기를 압축할 수 있으면 Key-Value 캐시 압축과 벡터 검색을 모두 지원한다.(영어)
LLM Architecture Gallery : GPT-2, Llama, DeepSeek, Wqen, GLM, Kimi, Minimax 등 공개된 LLM 아키텍처를 모아놓은 사이트다.(영어)

볼만한 링크

왜 코딩을 사랑하는 사람들이 코딩에서 밀려나는가 : 장인 기질의 사람들과 일단 돌아가면 된다는 사람들이 이전에는 같이 제품을 만들었는데 LLM 코딩 어시스턴트로 코딩 과정이 달라지면서 다르게 반응하는 이유와 LLM을 써야 하는 상황에 내몰리는 이유를 고찰한 좋은 글이다.(한국어)
Issue tracking is dead : 기존의 이슈 트래커는 인수인계 중심의 소프트웨어 개발을 위해 만들어졌지만, 시간이 지나면서 점점 복잡해졌고 프로세스 자체가 일이 되었는데 Linear는 오버헤드를 제거해서 업무에 집중할 수 있게 했다. 에이전트는 이를 더 전진시키고 있어서 더 이상 인수인계에 맞출 필요가 없고 문맥과 에이전트를 중심으로 설계해야 한다. Linear는 문맥을 실행으로 바꾸는 공유된 제품 시스템으로 발전해 간다고 비전을 밝혔다.(영어)
Is anybody else bored of talking about AI? : AI는 놀랍지만 매일 사용하면서 이제는 일상화되었는데 Hacker News 등에 거의 똑같은 AI 사용법에 대한 글만 올라오는 게 지겹다고 얘기한다. 제품 엔지니어가 유행이던 때가 있는데 엔지니어가 코드보다 제품의 가치에 집중해야 한다는 접근을 좋아했는데 다시 이때로 후퇴한 기분이 든다. 사용하는 도구 말고 어떤 멋진 것을 만들고 있는지 얘기했으면 좋겠다고 호소하는 글이다.(영어)

IT 업계 뉴스

OpenAI to acquire Astral : OpenAI가 Python 생태계의 uv, Ruff, ty 같은 도구를 만드는 Astral을 인수했다. 인수 후에 Astral 팀은 Codex 팀에 합류할 예정이다.(영어)
미 법원 'SNS 중독성' 첫 인정...메타와 유튜브 유죄 판결 받아 : 어린 시절 SNS 중독으로 고통받았다고 Meta와 YouTube를 상대로 제기한 소송이 승소해서 600만 달러(약 90억 원)의 손해배상금을 받게 되었다. Meta와 Google은 항소하겠다고 밝혔다.(한국어)
Adobe Agrees to $150 Million Settlement and Injunction to Resolve Alleged Violations of the Restore Online Shoppers’ Confidence Act : Adobe가 고객이 구독을 해지할 때 조기 해지 수수료에 관한 정보를 포함해서 구독 플랜에 중요한 정보를 작은 글씨와 잘 보이지 않는 링크를 사용해서 숨기고 구독 해지 시도를 방해했다는 혐의에 대해 Adobe는 7,500만 달러의 민사 벌금과 7,500만 달러의 무료 서비스를 고객에게 제공하는 데 합의했다.(영어)
GitHub backs down, kills Copilot pull-request ads after backlash : GitHub Copilot이 요청받은 작업을 하면서 Pull Request에 Raycast 사용을 권장하는 메시지를 남긴 걸 발견했다. Copiot이 수많은 PR에 광고로 보이는 다양한 팁을 넣은 것이 발견되었고 GitHub 측은 개발자들이 새로운 방법을 배우도록 돕기 위한 것이라고 밝혔지만 커뮤니티의 반응이 좋지 않아 이 기능을 비활성화했다.(영어)
Armon Dadgar: This Friday is my last day at HashiCorp (and IBM) : HashiCorp의 두 공동 창업자 중 Mitchell Hashimoto가 2023년 회사를 떠난 뒤 다른 한 명의 창업자인 Armon Dadgar도 13년 간의 여정을 마치고 HashiCorp를 떠났다. 다른 계획은 아직 없고 재충전의 시간을 가진다고 한다.(영어)
OnlyFans owner Leonid Radvinsky dies at 43 : 성인 콘텐츠 서비스인 OnlyFans의 소유주로 47억 달러의 자산을 가진 것으로 추정되는 Leonid Radvinsky가 암 투병 끝에 43세의 나이로 사망했다. 삼가 고인의 명복을 빕니다.(영어)
OpenAI raises $122 billion to accelerate the next phase of AI: OpenAI가 8,520억 달러 기업 가치를 평가받으며 1,220억 달러를 조달하며 최근 펀딩 라운드를 마감했다.(영어)
We’re saying goodbye to Sora : OpenAI가 동영상 생성 모델을 이용한 소셜 앱인 Sora를 종료하기로 했다.(영어)

프로젝트

Pretext : 순수 JavaScript/TypeScript만으로 멀티 라인 텍스트와 레이아웃을 구성할 수 있는 라이브러리로 빠른 동적으로 유연한 레이아웃을 만들 수 있다. Demo 사이트를 보면 깜짝 놀랄 정도다.
Legalize KR : 대한민국의 모든 법령을 Git으로 관리하여 변경 사항을 추적할 수 있게 만든 프로젝트.
Korean Law MCP : 대한민국 법령을 검색, 조회, 분석할 수 있는 MCP
Impeccable : AI가 더 나은 디자인을 생성할 수 있도록 하는 가이드와 함께 스킬과 커맨드를 제공한다.
ArrowJS : 에이전트 시대의 UI 프레임워크가 1.0을 릴리스하면서 오픈소스로 공개되었다.
Perforator : Yandex에서 오픈소스로 공개한 eBPF 기반의 Continuous Profiling 도구.
PentAGI : 복잡한 침투 테스트를 수행하는 AI 에이전트.
cmux : Ghostty 기반의 AI 코딩 에이전트용 macOS 터미널
oMLX : Mac에서 로컬 AI를 돌리는 MLX 서버.
Chops : 스킬을 한 곳에서 관리하는 macOS 앱
libghostty-rs : libghostty-vt의 Rust 바인딩.
MiniStack : AWS 환경을 로컬에서 테스트할 수 있는 LocalStack의 대체 프로젝트
json-render : AI가 JSON 구조를 만들면 이를 기반으로 컴포넌트를 만드는 UI 프레임워크.
code-review-graph : 코드 리뷰 시 Claude Code가 전체 코드를 매번 읽는 것을 지식 그래프로 만들어서 토큰 소비와 속도를 개선하는 프로젝트.
Codex plugin for Claude Code : Claude Code에서 Codex를 사용할 수 있는 플러그인으로 OpenAI에서 만들었다.
Claude Code Cheat Sheet : Claude Code 단축키 및 커맨드를 정리한 사이트.

버전 업데이트

JDK 26 : Java Development Kit, 릴리스 공지
- final 필드 변경하려고 deep reflection을 사용할 때 경고 표시
- Applet API 제거
- Ahead-of-Time 캐시를 개선 시켜서 HotSpot JVM의 시작 시간과 워밍업 시간 개선
- HTTP/3 지원
TypeScript v6.0 : Microsoft가 만든 JavaScript transpiler, 릴리스 공지
- TypeScript를 Go로 새로 작성하는 7.0으로의 전환을 위한 브릿지 버전
Laravel v11.0.0 : PHP 웹 프레임워크, 릴리스 공지
Starlette v1.0 : Python의 ASGI 프레임워크, 릴리스 공지
Knip v6 : JavaScript/TypeScript에서 안쓰는 파일과 의존성을 정리해주는 프로그램, 릴리스 공지
Next.js 16.2 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지
etcd-operator v0.2.0 : etcd Kubernetes 오퍼레이터, 릴리스 공지
reveal.js v6.0.0 : HTML 프리젠테이션 프레임워크, 변경사항
Spring Data Valkey v1.0.0 : Valkey용 Spring 라이브러리, 릴리스 공지
ClickHouse v26.2 : 컬럼형 데이터베이스, 릴리스 공지
Electron v41.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
Turborepo v2.9.0 : JavaScript/TypeScript 빌드 시스템, 릴리스 공지
neovim v0.12.0 : Vim, 릴리스 공지
KubeVirt v1.8.0 : Kubernetes의 가상 머신 관리 애드온, 릴리스 공지
astro v6.1 : JavaScript 웹 프레임워크, 릴리스 공지
Nuxt UI v4.6.0 : UI 라이브러리, 릴리스 공지
Swift v6.3 : 프로그래밍 언어, 릴리스 공지
Xcode v26.4 : Apple IDE, 릴리스 공지
KubeVirt v1.8.0 : Kubernetes의 가상 머신 관리 애드온, 릴리스 공지

요즘 하고 있는 AI에 관한 생각

2026-03-29T21:39:52+09:00

작년 연말 회고에서도 얘기했듯이 나는 AI에 보수적인 태도를 가지고 있다. 얼마 전에 44bits에서 사람들하고 얘기하다가 이제는 입장 돌변을 자연스럽게 받아들여야 한다는 얘기를 들었는데 그 말이 공감될 정도로 기술 발전이 빠르고 또 경험에 봄에 따라 생각이 확확 달라진다. 회고를 쓴 게 3개월 전인데 얼마 안 되었다고 할 수도 있지만 요즘 같은 시기에는 또 꽤 예전이라고도 할 수 있어서 그사이에 내 생각도 많이 달라졌다.

계속 글을 써야지 하다가 미루면서 쓰게 되는데 이 글은 현재 내 생각을 정리도 하면서 몇 달 뒤에 돌아봤을 때 "이때는 이렇게 생각했구나"하면서 돌아보기 위한 글이라고 할 수 있다.

먼저 변명(?)하자면 AI에 보수적인 태도를 일부 가지고 있는 것이지 회의적인 것은 아니다. 굳이 비교하자면 나는 블록체인에 대해서는 회의적인 견해가 있는데 여기서 다 설명할 수는 없지만 블록체인이 실용적인 어떤 결과를 만들어내지 못할 거라고 생각한다. 보수적인 태도라고 한 것은 이러한 회의적인 태도과는 다르다. 당연히 나도 AI는 더 발전하고 지금보다도 더 실용적으로 우리의 삶이나 업무에 깊숙이 들어오게 될 것이라고 믿는다.

보수적인 태도를 보이는 이유

그동안 나를 돌아보면 항상 뭔가 새로운 걸 배울 때 보수적인 태도를 가지는 편이다. 이건 내 성격이기도 한데 뭔가 새로운 걸 의심의 눈초리와 함께 쳐다보는 편이다.(영화보면 이런 사람이 더 사기를 잘 당한다던데...)

지금은 내 밥벌이나 다름없는 DevOps를 처음 알게 되었을 때도 "그럼, 개발해 놓고 운영을 안해?" 따위의 생각을 하고 있었고 Docker를 계속 공부하면서도 사실 잘 이해를 못해서 실무에서 이걸 어떻게 사용해야 하는지 전혀 감을 잡지 못하고 있었다. Kubernetes나 Service Mesh를 공부할 때도 내가 Google 같은 빅테크에서 일하는 것도 아닌데 이걸 어디다 쓰지? 같은 생각을 했다.

이건 내가 뭔가를 이해하는 과정이라는 생각도 한다. 첫눈에 반해서 막 좋아하는 기술이 없었던 건 아니지만 대부분은 내가 명확히 이해해야 사용할 수 있기 때문에 그 기술의 의미, 사용처, 예외 케이스, 트레이드 오프 등을 다 이해하려고 하다 보니 좀 떨어진 위치에서 보려고 하는 편이다. 일할 때도 이러한 성향이 나타나는 편인데 그래서 새로운 것에는 항상 내가 다 이해될 때까지는 반대하는 듯한 태도를 펴는 편이다.

그렇다고 관심을 끊지는 않는다. 예전에 DevOps나 Docker, Kubernetes 등도 대세가 될 것을 확실해 보였기 때문에 공부는 계속했다. 내가 완전히 이해를 못해서 그렇지 공부는 그만두지 않았다. AI에 대해서도 마찬가지다. 내 태도와 상관없이 AI는 계속 발전할 거고 점점 깊숙이 들어올 것이므로 AI를 찬양하는 글, 반대하는 글이나 다양한 팁과 기술 흐름의 변화는 계속 따라가려고 하고 있다.

이전에도 계속 보수적인 태도이었지만 DevOps나 Docker나 Kubernetes나 지금은 내 주요 밥벌이가 되었다. 잘 이해 못하는 느낌에 힘들었지만, 어느순간 또 그 기술을 사용하는 회사로 이직해서 사용하기 시작하면 어느 정도는 따라갈 수 있었기에 AI에 대해서도 따라가면 된다는 자신감을 어느 정도 있다.(그래도 올해는 따라가야 한다고 생각한다) 그래서 AI를 잘 쓰고 관심이 큰 사람들 주변에서 정보를 최대한 얻으려고 하고 있다.

물론 이전과 다른 점은 그때는 개발이 너무 재밌었고, 집에 와서도 하루 종일 개발관련 뭔가만 하고 있었지만, 지금은 열정이 그 정도는 아니라는 점이다. 내 태도와 상관없이 공부는 계속 해야 하는데 공부의 절대량이 부족하다는 생각이란 AI는 기존 기술과는 상당히 다르므로 그냥 글 읽고 하는 거 말고 직접 써보고 느끼고 잘 사용하는 방법을 체득해야 하는데 이런 쪽에 투입하는 시간이 절대적으로 부족하므로 생기는 조바심이 있다. 조바심은 내 커리어 내내 항상 있던 거지만 이전에는 그 조바심 때문에 학습을 엄청나게 했다면 지금은 그렇지 못하고 있다는게 지금 나의 가장 큰 문제이다. 최근에 깨달은건 내가 내 생각보다 코딩이나 엔지니어링이라는 그 과정 자체를 즐거워한 거 같다는 생각도 들고 내가 AI에는 아직 재미를 못 느끼고 있다는 생각도 든다.(최근에 재미를 조금씩 붙여나가고 있다.)

우려하는 부분

얼마 전 동료랑 얘기하다가 내가 AI에 대해서 우려하는 부분을 명확하게 깨달았는데 나는 그 "바이브" 느낌이 싫다. Andrej Karpathy가 만든 vibe coding이라는 용어는 AI로 인해 달라지는 코딩을 잘 표현한 말이기도 하고 마케팅 적으로 크게 성공한 말이기도 하다.

제가 "바이브 코딩(vibe coding)"이라고 부르는 새로운 종류의 코딩이 있어요. 분위기에 완전히 몸을 맡기고, 지수적인 발전을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 방식이죠.

코드를 읽을 필요가 있는가 없는가를 얘기하려는 것이 아니다. 그건 프로젝트의 성격, 상황에 따라 달라지게 마련이다. 내가 불편한 건 바이브 코딩이라는 용어가 책임을 전가하거나 회피하는 분위기를 만들어낸다는 것이다. 누구나 농담으로라도 한 번씩은 들어보거나 직접 해봤을 말인 "제가 안 그랬어요. AI가 그랬어요."라거나 "AI가 그렇게 대답해 줬어요." 같은 말에서 알 수 있듯이 은근히 AI에게 일을 시키고 자신의 책임을 회피하는 분위기가 생겨나고 있다고 생각한다.

AI에만 맡기지 말고, 생각을 멈추지 말고, 계속 고민하고 연구하고 더 좋은 방법을 찾아야 한다. 모든 영역이 그런 것은 아니니 단순한 반복 작업등은 더 AI에 맡겨서 시간을 확보하고 그 확보한 시간을 중요한 작업이나 고민을 많이 해야 하는 영역에 더 시간을 써야 한다. 하지만 바이브 코딩이라는 분위기가 이를 저해한다고 본다.

물론 용어 자체의 문제가 아닐 수도 있고 개개인의 성향이나 AI에 대한 기대치에 따라 달라지는 부분인 것도 맞지만, 용어에는 그런 힘이 있다고 생각해서 조심해야 한다고 본다. 그런 면에서 Andrej Karpathy가 바이브 코딩과 전문 영역에서 AI 에이전트를 사용하는 것을 구분하기 위해 Agentic Engineering을 선택한 것을 지지한다.(Addy Osmani의 Agentic Engineering도 참고)

결국 AI를 어떻게 하면 더 잘 사용할 수 있을지에 대한 논의도 아주 중요하지만 동시에 AI로 인해서 생길 문제에 대한 논의도 중요하다고 생각한다. AI뿐만 아니라 모든 혁신적인 변화 분위기에는 항상 그렇긴 하지만 우려에 관한 얘기가 마치 혁신을 저해하는 것처럼 보인다는 것도 불편하다. 물론 그냥 개인 느낌일 수도 있고 어디나 다양한 의견이 있어서 그냥 그렇게 느낄수도 있지만 그런 얘기를 짧은 글로 SNS에 하기는 어려워서 종종 블로그를 이용해야겠다고 생각하고 있다.

모든 기술은 트레이드 오프가 있기 마련이다. AI를 잘 활용하는 것만큼 잘못 사용하지 않도록 하는 것도 중요하다고 생각한다. 이건 내가 주로 인프라 업무를 하므로 더 이쪽에 대해서 많이 생각하게 되는거 같은데 어려운 점은 AI의 발전 속도가 너무 빠르다. 지금까지 보던 대부분의 기술은 변화가 생긴다는 것을 감지하고 대세가 되는 것을 보면서 준비해도 늦지 않았지만 지난 1년 사이에 AI가 달라진 걸 생각하면 뭐 준비하고 말고 할 시간이 없다. 냉정히 말해서 변화가 너무 빠르므로 최대한 활용하면서 안전장치를 동시에 만드는 수밖에는 없다고 생각한다.

요즘 고민하고 있는 부분

권한 관리

지금까지의 많은 시스템은 사람과 서비스를 대상으로 만들어졌다. 여기서 사람은 말 그대로 사람이고 서비스는 서버 등에 띄우거나 하는 어플리케이션을 의미한다. 하지만 여기에 에이전트라는 게 하나 더 생겼다. 에이전트라는 말이 요즘은 어디에나 사용되지만 여기서 말하는 에이전트를 사람이 로컬에서 돌리는 에이전트를 얘기한다. 서버에서 에이전트를 실행하는 건 그냥 서비스로 보면 된다고 생각한다.

이 에이전트는 사람한테 종속되었다는 특징이 있는데 사람의 권한을 똑같이 가져가기엔 너무 많고 에이전트에게 시킨 일에 딱 맞는 최소한의 권한만 주면 제일 좋을 것 같은데 그럴 방법이 없다. 꼭 코딩 에이전트를 예시로 들지 않더라도 에이전트를 설치해서 내 카드 사용 권한을 준다면 걱정되는 부분도 많은데 최대 10만원 제한 같은 걸 줄 수 있다면 불의의 사고에 대한 영향도를 최소화할 수 있으므로 훨씬 적극적으로 사용할 수 있을 거라고 생각한다. 하지만 현재는 이러한 방법이 없고 과도한 권한을 주고 프롬프트로 최대한 방어해서 쓰거나 제대로 사용하지 못하게 된다.

사용 성숙도 전파

AI를 코딩할 때 사용하거나 리서치, 업무 자동화 등에 많이 사용할 것이라고 보인다. 시간이 지나지면서 개선되고 있으니, 앞으로도 계속되겠지만 벌써 잘 쓰는 사람과 잘 못 쓰는 사람의 차이가 있다고 느껴지는데 이게 잘 전파가 안 된다고 느껴진다.

기존 코딩 팁이나 지식, 아키텍처 같은 것은 누군가 연구하고 정리해서 공유하면서 팀 전체에 사용 성숙도를 같이 올리는 노력을 하게 마련인데 AI는 그게 좀 쉽지 않은 느낌이다. 기존 기술과 프롬프트를 이용해서 사용하다 보니 잘 쓰는 사람도 "그냥 시키면 알아서 잘해요" 정도로 얘기하거나 별거 아니라고 생각해서 공유를 안 하게 되는 거 같기도 하다. 그리고 취향도 타기 때문에 스킬 같은 것도 남의 것을 가져오기보다 아이디어만 가져와서 직접 만들어 쓰는 게 더 자연스러워지는 거 같다.

결국 새로운 변화에 혜택받는 수준을 전체 구성원에게 일정 수준 이상으로 올리는 방법에 대한 고민이라고 할 수 있는데 AI는 기존 기술과는 사용 방법이 다르므로 이러한 고민이 의미 없고 그냥 각자에게 맡기도 다른 고민을 하는게 더 맞나하는 생각도 한다.

에이전트를 위한 인터페이스

요즘은 AI 에이전트를 10개씩 쓴다는 사람도 있지만 보통 1, 2개를 돌리는 거 같은데 당연히 시간이 지날수록 더 많아질 것이다. 그러면 에이전트에게 제공해야 하는 인터페이스는 무엇인가? 하는 고민을 하고 있다. 인터페이스라는 것을 사용하기 좋게 하면서도 사용 방법에 대한 통제권을 어느 정도 가지는 의미가 있다.

흐름으로 보면 기존에는 UI와 API만 있었고 그 뒤에 MCP가 생겼고, 지금은 CLI가 대세인 분위기이다. 요즘은 AI로 단순 코딩에 큰 노력이 들어가진 않으니 넷 다 제공하고 편한 대로 쓰라고 하는 게 맞는 거 같기도 하고 CLI가 토큰 효율성도 그렇고 사용하기 제일 좋다는 생각도 든다. 하지만 CLI를 제공하면 API도 같이 제공한 것이므로 API도 함께 제공한 것이기도 하다.

"API 사용자가 충분히 많으면 명세에 적힌 내용과 상관없이 시스템의 모든 관찰 가능한 행동에 의존하게 된다."는 하이럼의 법칙이 더욱 강해지고 있다는 요즘이다. CLI를 제공해서 사용 패턴을 제어하는 게 가장 좋다고 생각하지만 사실 API까지 같이 제공했으니, 통제권을 제어하기는 쉽지 않아 보인다. (물론 CLI가 API의 래퍼 역할이라고 볼 수도 있긴 하지만 여기서는 CLI를 제공한다는 게 사용 방식을 더 제어할 수 있을 거 같다는 개인적인 생각이 담겨있다.)

간단히 정리하면 2026년에 새로운 사내 어드민을 만든다면 API와 CLI만 있어도 충분한가? 같은 질문이라고 할 수 있다. 지금은 어떤 면에서는 변화 중에 있기 때문에 UI, API, MCP, CLI를 다주는게 맞나 싶기도 하면서 AI로 코딩이 빨라졌다고 해도 4개를 다 유지보수를 해야 하는 부담을 생각하면 또 걱정도 된다.

기술 뉴스 #290 : 26-03-16

2026-03-16T19:31:00+09:00

웹개발 관련

Temporal: The 9-Year Journey to Fix Time in JavaScript : JavaScript의 Date는 만들어질 당시에는 실용적인 접근이었지만 웹의 발전을 제대로 따라가지 못했고 사용하기 어려웠기 때문에 moment.js같은 라이브러리로 해결했지만, 시간이 지나면서 라이브러리의 용량은 너무 커지게 되었다. 결국 moment.js의 메인테이너 중 한 명이 TC39에서 Temporal을 제안하면서 Stage 1이 된다. 날짜와 시간에 대한 요구사항을 모으고 명세를 확정하기 위해 여러 회사의 사람들이 모여서 작업할 결과 ES2015 이후 가장 큰 기능 추가인 Temporal이 드디어 Stage 4에 도달해서 ES2026에 포함되게 되었다.(영어)
Scale Next.js Image Optimization with a Dedicated Platformatic Application : Next.js의 이미지 최적화 기능은 이미지 요청이 많아지는 경우 CPU와 메모리를 많이 소모하기 때문에 앱 전체의 요청을 느리게 만들 수 있다. 그래서 Watt 프레임워크에서는 Next.js의 이미지 최적화 기능을 별도의 워커로 분리해서 이미지 최적화로 인한 부하가 커지더라고 렌더링이나 애플리케이션의 성능에는 영향을 주지 않도록 지원한다.(영어)
그때는 맞고 지금은 틀리다. Yarn Berry에서 pnpm으로 패키지 매니저 전환기 : 카카오페이에서 기존에 Yarn Berry를 사용하고 있었는데 빌드 시 메모리 스파이크가 너무 커서 대안을 검토하던 중 pnpm을 선택하게 되었다. pnpm으로 전환 후 메모리 사용량이 64% 줄고 도커 이미지도 83% 줄어들었을 뿐 아니라 배포 시간도 감소했다.(한국어)

그 밖의 개발 관련

You Need to Rewrite Your CLI for AI Agents : 사람과 에이전트는 다르므로 AI 에이전트가 CLI를 잘 쓰게 하려면 그것에 맞게 고려해야 한다. 에이전트는 중첩된 JSON을 잘 작성하므로 API 페이로드를 그대로 JSON으로 받게 하고 API 문서를 읽는 건 토큰이 많이 들기 때문에 CLI에서 스키마를 알려줄 수 있게 제공하는 것이 좋다. 컨텍스트를 너무 차지 않도록 응답 필드를 제한할 수 있는 기능과 NDJSON 페이지네이션으로 스트림 처리하는 것이 좋다. 사람이 실패하는 부분과 에이전트가 환각을 일으키는 것은 다른 패턴이므로 환각을 막아줄 수 있도록 파라미터나 이름, 인코딩 등을 검증해서 에이전트의 입력을 신뢰하지 말고, CLI 명령뿐 아니라 에이전트 스킬을 같이 배포해서 하는 것이 좋다.(영어)
Partnering with Mozilla to improve Firefox’s security : Anthropic이 Claude Opus 4.6으로 Mozilla와 협업해서 Firefox에서 2주간 22개의 취약점을 발견했고 이 중 14개가 고위험 취약점으로 분류했다. 이렇게 찾을 취약점을 통해 직접 공격하도록 요구했지만 실제로 성공한 건 단 2건밖에 없었는데 이는 취약점을 악용하는 것보다 취약점을 찾는데 Claude가 훨씬 뛰어나다는 것이고 API 크레딧을 비교했을 때도 공격하는 것보다 취약점을 찾는 것이 훨씬 저렴하다는 것을 의미한다.(영어)
AI 시대에 코드 리뷰, 어떻게 해야할까? : AI로 코드 작성의 속도가 빨라지면서 코드 리뷰에 대한 논의도 많이 생기에 되었는데 여전히 사람이 코드를 리뷰하고 책임져야 한다는 의견과 더 이상 사람이 코드 리뷰할 필요 없다는 의견을 가진 사람들의 의견을 정리한 글이다. 이 두 가지 대립되는 의견에 대한 해결책으로 앞으로 리뷰를 어떻게 하면 좋을지 제안하는 최근의 접근 방법도 같이 소개한다.(영어)
(번역) Node.js 메모리 사용량을 절반으로 줄였습니다. : V8의 포인터 압축을 킨 node-caged 이미지를 사용해서 벤치마크를 한 결과 평균 지연시간은 2~4% 늘어났지만, 메모리는 50%가 줄어들었다. Chrome은 2020년부터 포인터 압축을 사용했지만 Node.js에서는 컴파일 시 플래그를 켜야 했지만 Node.js 팀이 24년부터 노력해서 V8의 IsolateGroups를 도입해서 이 문제를 해결하고 Node.js에 통합되었다. 아직 컴파일 시에 플래그를 켜야 하므로 별도의 node-caged 이미지를 만들었다.(한국어)
Evolving the Node.js Release Schedule : Node.js 27.x부터 기존에 연간 두 번의 메이저 릴리스를 하는 방식에서 한 번의 메이저 릴리스로 변경한다. 기존에 짝수가 LTS가 되고 홀수는 개발 버전으로 유지되었기에 홀수 버전을 채택률이 매우 낮고 이해하기 어렵기 때문에 대부분 LTS 버전만 사용하고 있지만 활성 릴리스를 너무 많이 유지하는 것은 메인테이너에게 부담이 됩니다. 이제 매년 4월에 메이저 릴리스를 하고 이 버전을 10월에 LTS로 승격하고 홀수 짝수 구분 없이 모든 릴리스가 LTS가 되고 버전 번호는 릴리스 연도와 맞추게 된다.(영어)
Bringing Code Review to Claude Code : Anthropic에서 Claude에 Code Review 기능을 Team/Enterprise 플랜에 리서치 프리뷰로 공개했다. Code Review는 Pull Request가 열릴 때마다 에이전트 팀을 실행해서 버그를 찾고 오탐을 줄이기 위해 검증하게 되는데 테스트 결과 검토 시간을 약 20분이고 리뷰는 평균 $15-25의 비용이 들었다고 한다.(영어)
Codex for Open Source : Anthropic에 이어 OpenAI도 오픈소스 메인테이너들에게 6개월간의 ChatGPT Pro, Codex Security, API 크레딧을 제공하는 프로그램을 공개했다.(영어)
Codex Security: now in research preview : OpenAI에서 애플리케이션 보안 에이전트인 Codex Security를 발표했다.(영어)

인프라 관련

A GitHub Issue Title Compromised 4,000 Developer Machines : Cline에 저장소에서 사용 중인 claude-code-action은 누구나 이슈를 열어서 트리거 할 수 있었는데 1월 28일 성능보고서처럼 보이게 만든 이슈를 만들었으나 그 안에는 공격자가 만든 패키지를 설치하라고 되어 있었고 이 패키지에는 원격 쉘 스크립트를 실행하는 스크립트가 포함되어 있었다. 이 쉘 스크립트는 Cacheract라는 캐시 중독 도구를 배포해서 10GB가 넘는 쓰레기 데이터를 캐시에 캐시를 비우게 만들고 Cline의 야간 릴리스 워크플로우와 캐시 키 패턴과 일치하도록 조작해서 오염된 데이터를 캐시에 채워 넣었다. 이후 야간 릴리스 워크플로우가 실행되면서 오염된 node_modules를 캐시로부터 복원하고 여기서 릴리스 워크플로우가 가지고 있던 시크릿이 유출된 후 이를 이용해서 새로운 cline@2.3.0을 릴리스했고 여기에는 OpenClaw를 설치하게 하는 postinstall 훅이 포함되어 있었다. 이 공격은 Clinejection이라고 명명되었다.(영어)
The Self-Driving Codebase : AI로 코드 생산은 빨라졌지만, 이는 개인의 속도 향상이고 바로 팀의 속도로 이어지지 않으므로 이를 개선하기 위해서는 백그라운드 에이전트를 안전하게 돌릴 수 있는 환경을 구축하고 시스템의 병목을 찾아서 소프트웨어 공장을 확장해야 한다고 설명하는 글이다.(영어)
Introducing account regional namespaces for Amazon S3 general purpose buckets : AWS S3에 버킷을 만들 때 계정 리전 네임스페이스를 지원해서 이름 충돌 없이 원하는 버킷 이름을 사용할 수 있게 되었고 조직 차원에서 계정 리전 네임스페이스에서만 버킷을 생성하도록 강제할 수도 있다.(영어)
Making etcd incidents easier to debug in production Kubernetes : Kubernetes의 핵심 컴포넌트인 etcd에 장애가 났을 때 정보가 부족했기 때문에 원인을 파악하기가 쉽지 않았다. VMware에서 만든 etcd-diagnosis는 etcd의 상태를 보여주는 진단 리포트를 생성해서 원인을 파악하기 쉽게 해준다.(영어)

AI 관련

GPT‑5.4를 소개합니다 : OpenAI가 최신 프런티어 모델 GPT-5.4를 발표했다. GPT-5.4는 추론, 코딩, 에이전트 기반 워크플로 영역의 기술 발전을 하나의 프런티어 모델로 통합해서 GPT-5.3-Codex를 기반으로 각종 도구와 전문 업무에서 모델 성능이 개선되었고 컴퓨터 사용 기능을 기본 제공하여 에이전트가 직접 컴퓨터를 직접 조작할 수 있게 되었다.(한국어)
Improving skill-creator: Test, measure, and refine Agent Skills : Anthropic에서 스킬을 평가하고 벤치마크를 실행해서 스킬이 제대로 동작하는지 확인할 수 있는 skill-creator를 공개했다.(영어)
Qwen3.5 - How to Run Locally Guide : Alibaba의 최신 모델인 Qwen3.5 모델을 크기별로 로컬에서 실행하는 방법과 설정 방법을 정리한 문서다.(영어)
1M context is now generally available for Opus 4.6 and Sonnet 4.6 : Claude Opus 4.6과 Sonnet 4.6에 1M 컨텍스트 윈도우 지원이 추가되었다.(영어)
Meta May Delay 'Avocado' As Tech Underwhelms In Tests Against Google Gemini And Anthropic AI Models: Report : Meta가 내부에서 준비하던 새로운 AI 모델 Avocado가 내부 테스트 결과 Gemini나 Claude보다 성능이 낮게 나와서 예정된 3월 출시를 5월로 연기한 것으로 알려졌다.(영어)
Introducing Phi-4-Reasoning-Vision to Microsoft Foundry : Microsoft의 소규모 언어 모델(SLM)인 Phi에 비전 추론을 추가한 Phi-4-Reasoning-Vision-15B 모델을 공개했다.(영어)
Codex app on Windows : OpenAI의 Codex 앱이 Windows용으로도 출시되었다.(영어)

볼만한 링크

합법이면 공정한가: AI 재구현과 카피레프트의 침식 : 최근 Python 라이브러리인 chardet을 API와 테스트 스위트만 참고해서 AI로 완전히 새로 구현하고 새 버전으로 릴리스하면서 LGPL에서 MIT로 바꾸자, 원작자인 Mark Pilgrim이 이에 항의하는 일이 있었다. 이 사건에 대해서 Armin Ronarcher는 철학적으로, Redis를 만든 Salvatore Sanfilippo는 저작권법적으로 재구현을 지지했는데 이를 반박하는 글이다.(한국어)
After outages, Amazon to make senior engineers sign off on AI-assisted changes : Amazon이 잘못된 배포로 6시간 동안 장애를 겪은 뒤 내부 회의에서 AI의 지원을 받은 변경 사항은 시니어 엔지니어의 승인을 받아야 한다고 밝힌 것으로 알려졌다.(영어)
IntelliJ IDEA — The IDE That Changed Java Forever : CultRepo에서 만든 IntelliJ IDE의 25년간의 역사를 다룬 다큐멘터리이다.(영어)

IT 업계 뉴스

Drizzle joins PlanetScale : JavaScript/TypeScript용 데이터베이스 도구를 만드는 Drizzle을 클라우드 데이터베이스 업체인 PlanetScale이 인수했다. Drizzle ORM은 계속 오픈소스로 운영하고 Drizzle 팀도 프로젝트에 집중하게 지원할 것이라고 한다.(영어)
Meta acquired Moltbook, the AI agent social network that went viral because of fake posts : OpenClaw의 AI 에이전트들이 소통할 수 있는 소셜 네트워크인 Moltbook을 Meta가 인수해서 Moltbook이 Meta Superintelligence Labs에 합류하고 Moltbook을 만든 Matt Schlicht와 Ben Parr도 Meta에 합류한다.(영어)
Google wraps up $32B acquisition of cloud cybersecurity startup Wiz : Google이 이스라엘의 사이버보안 업체인 Wiz를 역대 최대 규모인 320억 달러에 인수했다.(영어)

프로젝트

Azure Agent Skills : Microsoft Azure용 스킬 모음.
agent-browser : Vercel에서 만든 AI 에이전트용 헤드리스 브라우저 CLI
gws : Gmail, Drive, Calendar 등 Google Workspace를 위한 CLI로 Google에서 만들었다.
mogcli : Microsoft 365용 비공식 CLI.
Superset : AI 에이전트용 코드 에디터.
Polyscope : AI 에이전트용 개발 환경.
Symphony : AI 에이전트용 개발 환경.
AI Talent Movement Tracker : AI 업계의 인력 이동을 추적해서 시각화해 주는 사이트.
Qwen-Agent : Qwen 기반의 에이전트 프레임워크
page-agent : 자바스크립트를 웹사이트에 넣으면 웹사이트를 AI가 웹사이트를 조작할 수 있게 해주는 라이브러리.
NemoClaw : NVIDIA에서 만든 오픈소스 AI 에이전트 플랫폼.
Anthropic courses : Anthropic에서 Claude의 사용법을 설명하는 온라인 강의를 공개했다.

버전 업데이트

JDK 26 : Java Development Kit, 릴리스 공지
Vite v8.0.0 : 프론트엔드 빌드 도구, 릴리스 공지
- Rust 기반 번들러인 Rolldown 도입으로 빌드 속도가 10~30배 향상
Vitest v4.1.0 : Vite 유닛 테스트 프레임워크, 릴리스 공지
- Vite 8 지원
astro v6.0 : JavaScript 웹 프레임워크, 릴리스 공지
RedwoodJS v1.0.0 : 풀스택 웹프레임워크, 릴리스 공지
TinyBase v8.0 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지
TypeScript v6.0 RC : Microsoft가 만든 JavaScript transpiler, 릴리스 공지
Rust 1.94.0 : 프로그래밍 언어, 릴리스 공지
pgAdmin 4 v9.13 : PostgreSQL 클라이언트 도구, 릴리스 공지
Nuxt UI v4.5.0 : UI 라이브러리, 릴리스 공지
devenv v2.0 : Nix를 사용한 개발환경, 릴리스 공지
Uptime Kuma v2.2.0 : 모니터링 도구, 변경사항
Bazel v8.6.0 : 빌드 도구, 릴리스 공지
GitHub Copilot CLI 0.0.423 : GitHub Copilot CLI, 릴리스 공지
Oxlint v1.51.0 : JavaScript/TypeScript Linter, 릴리스 공지
Oxfmt v0.36.0 : JavaScript/TypeScript 포매터, 릴리스 공지
React Native Skia v2.5.0 : React Native용 Skia, 릴리스 공지
Node.js v25.8.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Gradle v9.4.0 : Java 빌드 도구, 릴리스 공지
GitHub Copilot CLI SDKs v0.1.30 : GitHub Copilot CLI의 SDK, 릴리스 공지
Visual Studio Code v1.111 : 에디터, 릴리스 공지
Armeria v1.37.0 : Java용 비동기 RPC/REST 라이브러리, 릴리스 공지
Ghostty v1.3.0: 터미널 에뮬레이터, 릴리스 공지
Omarchy v3.4.0 : DHH가 만든 Arch Linux의 Hyprland 설정, 릴리스 공지
MCP C# SDK v1.0 : MCP용 C# SDK, 릴리스 공지
Homebrew v5.1.0 : OS X 패키지 매니저, 릴리스 공지
Nuxt.js v4.4.0 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
DuckDB v1.5.0 : 데이터베이스 시스템, 릴리스 공지

기술 뉴스 #289 : 26-03-01

2026-03-01T21:19:21+09:00

웹개발 관련

Cloudflare가 일주일 만에 AI로 Next.js를 재구축한 방법 : Next.js는 Vercel외의 서버리스 플랫폼에 배포하려면 어려운 부분이 있어서 OpenNext가 만들어졌지만 여기엔 노력이 많이 들고 Turbopack 툴체인 기반이라서 다른 곳에서는 작업이 많이 필요했다. 이 문제를 해결하기 위해 Cloudflare에서 Vite로 Next.js API 인터페이스를 구축하기로 하고 AI를 이용해서 vinext를 만들었다. Next.js 16과 vinext를 비교한 자체 벤치마크에서 프로덕션 빌드가 최대 4.4배 빨랐고 번들 크기도 절반 이상 줄어들었다. vinext는 AI가 대부분의 코드를 작성했고 OpenCode에서 800개 이상의 세션을 사용했고, 토큰에는 1,100달러가 들었다.(한국어)
We deserve a better streams API for JavaScript : WHATWG Streams 표준으로 많은 부분이 나아졌지만, 수년간 Node.js와 Cloudflare Workers를 구현하고 디버깅하면서(글의 작성자가 Node.js의 코어 메인테이너면서 Cloudflare 직원) 표준의 개선보다 근본적인 문제를 해결하고 대안적인 접근방법을 제안하는 글이다. 10년,전에 Streams가 만들어졌을 때는 비동기 이터레이션이 없었기에 기능적으로 한계가 있었고 잠금, 버퍼의 복잡성, 백프레셔의 복잡성, 프로미스로 인한 오버헤드 때문에 현실에서 많은 성능 문제나 의도치 않은 동작 문제를 발생시키고 있다. 이에 대한 대안으로 AsyncIterable 기반으로 새로 설계한다면 앞에서 얘기한 문제들도 해결하고 훨씬 간편하게 사용할 수 있으며 성능도 수십 배까지 빨라질 수 있다고 한다.(영어)
[번역] 다크 모드를 넘어서: CSS 필터로 사용자가 UI를 직접 조정하게 하기 : UI를 단순히 라이트/다크 모드로만 제공하지 않고 범위 슬라이더와 backdrop-filter를 이용해서 사용자 선호에 맞게 스타일을 조정할 수 있게 만드는 튜토리얼이다.(한국어)
Why is WebAssembly a second-class language on the web? : 2017년 출시 이후 WebAssembly는 계속 발전해 왔지만 여전히 웹에서는 2등급 언어라는 문제가 있다. 그동안 언어적 기능은 많이 추가되었지만, 웹 플랫폼과 통합되지 못했기 때문에 웹 개발자에게 불편함을 주고 있고 JavaScript보다 실제로 우선시하기 어려운 현실이다. 이 문제를 해결하기 위해 수년간 WebAssembly Component가 개발됐는데 WebAssembly Component는 여러 프로그래밍 언어로 만들어서 다양한 런타임에 실행되고 WebAssembly 코드가 웹 API를 직접 호출할 수 있어서 현재 WebAssembly가 겪는 문제를 해결할 수 있다고 기대된다.(영어)
The React Foundation: A New Home for React Hosted by the Linux Foundation : 작년에 발표한 대로 Linux 재단 아래 React 재단이 설립되어 React, React Native, JSX 프로젝트는 더 이상 Meta의 소유가 아니라 재단에서 관리하게 되었다. 재단의 창립 멤버에는 Amazon, Callstack, Expo, Huawei, Meta, Microsoft, Software Mansion, Vercel이 포함되었다.(영어)

그 밖의 개발 관련

Our Multi-Agent Architecture for Smarter Advertising : Spotify의 광고 비즈니스에 여러 구매 방식이 있는데 서비스는 통합했지만, 각 요구사항이 복잡했기에 이를 제대로 충족시키지 못했는데 이는 광고 API에 프로그래밍할 수 있는 의사결정 계층이 없다는 문제가 있었고 유지보수 때문에 거대한 규칙 엔진을 만들고 싶지도 않았다. 이 문제를 해결하기 위해 모듈형 에이전트로 해결하기로 했다. 영역별로 별도의 에이전트를 구축해서 구성한 뒤 이전에는 20개 이상의 필드를 입력하고 15분에서 30분까지 걸리던 광고 플랜 생성이 자연어 메시지로 10초 이내에 할 수 있게 되었다.(영어)
Writing about Agentic Engineering Patterns : Simon Willison이 코딩 에이전트 시대의 코딩 관행과 패턴을 수집하고 문서화하는 프로젝트를 시작했다. Agentic Engineering Patterns에서 계속 내용을 추가하는 중이다.(영어)
Claude Code 모든 기기에서 로컬 세션 계속하기 (Remote Control) : 머신에서 실행 중인 Claude Code 세션에 iOS/Android Claude 앱이나 claude.ai/code 사이트를 통해 접속해서 사용할 수 있는 Remote Control 기능이 추가되었다.(한국어)
Making frontier cybersecurity capabilities available to defenders : Claude Code에 새로운 기능인 Claude Code Security가 리서치 프리뷰로 제공된다. Claude Code Security는 코드를 스캔해서 보안 취약점을 찾고 패치를 제안할 수 있다.(영어)
Stop Using /init for AGENTS.md : 2006년 초에 나온 논문에 따르면 AGENTS.md는 코드에서 알 수 있는 내용과 중복적인 내용이 포함되면 성능도 떨어지고 토큰 비용도 20% 증가시키지만, 프로젝트에 특화된 내용이나 명확하지 않은 요구사항, 함정 등 에이전트가 발견하기 어려운 내용을 추가하면 도움이 되는 것으로 나왔다. AI 코딩 에이전트를 사용할 때 처음 /init을 실행해서 AGENTS.md을 생성하는데 이 내용은 대부분 에이전트가 스스로 발견할 수 있는 것이므로 중복 내용으로 비용만 증가하게 만든다고 설명한다.(영어)
Google API Keys Weren't Secrets. But then Gemini Changed the Rules. : Google Cloud의 API 키를 오랫동안 비밀이 아니므로 클라이언트에 포함해도 된다고 안내해 왔고, 실제로도 그러했지만, 프로젝트에서 Gemini API를 활성화하면 해당 프로젝트의 기존 API 키로도 Gemini 엔드포인트에 접근할 수 있게 되었다. 이 키로 Gemini API에 접근하면 이를 통해 저장된 모든 항목에 접근해서 개인 정보가 유출될 수 있고 의도하지 않은 비용이 발생할 수 있다.(영어)
GitHub Copilot CLI is now generally available : GitHub Copilot을 터미널에서 사용할 수 있는 GitHub Copilot CLI가 공식 릴리스 되었다.(영어)
React Native Comes to Meta Quest : React Native로 Meta Quest의 Meta Horizon OS에서 VR 앱을 만들어서 배포하는 과정을 설명한다.(영어)

인프라 관련

Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know : 이전에 발표된 대로 3월에 Ingress-NGINX를 은퇴시킬 예정이라 Gateway API로 안전하게 마이그레이션할 때 실수하기 좋은 부분을 정리한 문서다.(영어)
- Ingress-NGINX
  - 정규표현식을 사용할 때 항상 접두사만 매칭하고 대소문자를 구별하지 않는다.
  - rewrite target이 대소문자를 구분하지 않는 접두사 패턴이다.
  - 마지막 슬래시가 없는 경우 자동으로 리다이렉트한다.
- Gateway API
  - 정규표현식이 전체 문자열 매칭이고 대소문자를 구분하므로 그것에 맞게 정규표현식을 작성해 주어야 한다.
  - URL 재작성을 할 때는 Exact와 Prefix를 사용하고 자동으로 정규식 패턴으로 변환하지 않는다.
  - 마지막 슬래시에 대해 자동 리다이렉트하지 않으므로 명시적으로 작성해야 한다.
DNS-PERSIST-01: A New Model for DNS-based Challenge Validation : Let's Encrypt에 인증서를 요청하면 ACME 챌린지를 사용해서 인증서의 호스트네임의 소유주인지를 검증하는데, 와일드카드 인증서가 필요하거나 인터넷에 노출하고 싶다면 DNS-01 챌린지가 유일한 방법이었습니다. DNS-01을 사용하려면 _acme-challenge.<YOUR_DOMAIN>에 토큰을 포함한 TXT 레코드를 게시하여 검증하게 되므로 권한 부여마다 새 토큰을 만들기 위해 DNS 업데이트를 자동화해서 운영해야 합니다. 새로운 ACME 챌린지 유형인 DNS-PERSIST-01을 사용하면 _validation-persist.<YOUR_DOMAIN>에 상시 권한 부여하는 레코드를 한번 생성하고 이후 새로운 발급과 갱신에서 재사용할 수 있게 된다.(영어)
Introducing Upright: An Open Source Synthetic Monitoring System : 37signals에서 자사의 제품인 Basecamp, HEY, Fizzy 등을 위해 만든 합성 모니터링 시스템을 오픈소스로 공개했다. Upright는 여러 지리적 위치에서 헬스 체크를 실행하는데 Playwright, HTTP, SMTP, Tracerout 4가지 프로브를 지원한다.(영어)
Introducing Valkey Admin: Visual Cluster Management for Valkey : Valkey 클러스터의 구성과 상태를 확인하고 키를 관리할 수 있는 공식 Valkey Admin이 오픈소스로 공개되었다.(영어)

AI 관련

Introducing Claude Sonnet 4.6 : Anthropic이 Claude Sonnet 4.6 모델을 발표했다. 가격은 Sonnet 4.5로 동일하며 베타 단계로 100만 토큰의 컨텍스트 윈도우를 제공한다.(영어)
Gemini 3.1 Pro: A smarter model for your most complex tasks : Google이 Gemini 3.1 Pro를 발표했다. Gemini 3.1 Pro는 3 Pro보다 추론 성능이 2배 이상 향상했다.(영어)
Nano Banana 2: Combining Pro capabilities with lightning-fast speed : Google의 이미지 모델인 Nano Banana 2(Gemini 3.1 Flash Image)가 나왔다.(영어)
Qwen3.5: Towards Native Multimodal Agents : Alibaba에서 Qwen3.5 모델을 발표했다. Qwen3.5는 추론, 코딩, 에이전트 능력, 멀티모달 이해에 뛰어난 성과를 보이면서도 속도와 비용을 최적화했다.(영어)
Perplexity Computer를 소개합니다 : Perplexity에서 AI 기능을 단일 시스템으로 통합해서 단순 채팅이 아니라 요청한 작업을 장시간 실행할 수 있는 Perplexity Computer를 공개했다.(한국어)

볼만한 링크

Wikipedia blacklists Archive.today, starts removing 695,000 archive links : 웹페이지 아카이빙 서비스인 Archive.today(archive.org 와는 다른 서비스)에 대한 링크를 위키피디아에서 모두 제거하기로 했다. 이는 Jani Patokallio가 2023년 Archive.today가 러시아 출신 누군가가 운영하는 거로로 보인다는 글을 썼고 Archive.today 운영자가 이 글을 지워달라고 요청했지만 지우지 않자, Archive.today의 CAPTCHA 사이트에 악성 코드를 심어서 Jani Patokallio의 블로그에 DDoS 공격을 하고 Jani Patokallio에게 협박 이메일을 보냈다. 이후 논의 과정에서 Archive.today가 아카이빙된 사이트에 Jani Patokallio의 이름을 삽입된 것을 발견했다.(영어)
Thank you for everything you ship. Claude Max is on us. : Anthropic에서 5,000개 이상의 GitHub Star나 월 100만 회 이상의 npm 다운로드를 보유한 저장소의 메인테이너에게 Claude for Open Source 프로그램으로 Claude Max 20x를 6개월간 무료로 제공한다.(영어)
Obsidian Headless Sync : 노트 앱인 Obsidian이 데스크탑 앱 없이도 금고를 동기화할 수 있는 헤드리스 클라이언트를 퍼블릭 베타로 공개했다.(영어)

IT 업계 뉴스

Anthropic boss rejects Pentagon demand to drop AI safeguards : 미국 국방부가 Anthropic의 모델을 무제한적인 군사 용도로 개방하라는 요청을 Anthropic이 공식적으로 거부했다. Anthropic은 미국 기밀 네트워크에 배포된 최초의 프론티어 모델이지만 이는 민주주의의 가치를 약화할 수 있고 대규모 국내 감시와 완전 자율 무기가 될 수 있다는 우려를 얘기하며 거부했고 미국 정부는 정부 내에서 Anthropic의 모델을 사용하지 못하도록 했다. 바로 이어서 OpenAI가 국방부와 국내 대규모 감시와 자율 무기에 대한 안전 원칙에 합의하고 미국 기밀 네트워크에 배포하기로 합의했다고 발표했다.(영어)
Paramount set for $111bn Warner Bros takeover after Netflix drops bid : Warner Bros 인수에 기존 Netflix의 제안인 820억 달러(약 118조 원)보다 높은 1,110억 달러(약 159조 원)를 Paramount Skydance가 제시하였고, Netflix는 입찰가를 올리기 거부하고 인수를 철회했다.(영어)
OpenAI raises $110B in one of the largest private funding rounds in history : OpenAI가 새로운 투자 라운드를 시작했고 투자 전 기업가치는 7,300억 달러로 책정되었다. 이번 라운드에는 Amazon이 500억, Nvidia와 SoftBank가 각각 300억을 투자했고 아직 투자 라운드는 진행 중이다.(영어)
eBay to lay off 800 staff : eBay가 정규직 직원의 6%인 800명을 감원한다.(영어)
18년 끌어온 구글 지도 반출 논쟁…'조건부 허가'로 마침표 : 국가안보 우려로 그동안 해외 반출을 막고 있었지만 18년 만에 구글의 고정밀 지도 데이터 국외 반출이 조건부로 허가가 났다. 2007년과 2016년 두 번의 요청은 거절되었지만 2025년 3차 요청에서 정부는 엄격한 보안 준수를 전제로 해외 반출을 허가했다.(한국어)
명품 플랫폼 발란, 결국 파산⋯회생 신청 11개월 만 : 온라인 명품 플랫폼인 발란이 회생 절차를 신청한 지 11개월 만에 파산 판결이 나왔다.(한국어)
Announcing the "AI Agent Standards Initiative" for Interoperable and Secure Innovation : 미국 국립 표준 기술 연구소(NIST)의 인공지능 표준 및 혁신 센터(CAISI)에서 AI 에이전트 표준 이니셔티프를 만들었다.(영어)

프로젝트

Anthropic Skills : Anthropic의 엔지니어들이 내부에서 사용하는 Skills를 오픈소스로 공개했다.
Kubernetes the (Very) Hard Way : Kubernetes 학습 사이트(현재 일시적으로 무료)
portless : 로컬 개발에서 포트 번호 대신 .localhost의 서브 도메인을 사용하는 CLI
Electrobun : TypeScript와 Bun을 사용한 크로스 플랫폼 데스크탑 어플리케이션 프레임워크.
OpenFang : Rust로 작성된 오픈소스 에이전트 OS
Plano : 에이전트 앱을 위한 배포 인프라.
Beautiful Mermaid : Mermaid로 다이어그램을 SVG와 ASCII로 그려주는 오픈소스 라이브러리.
Jmail : Jeffrey Epstein의 이메일을 쉽게 확인하고 분석해 볼 수 있도록 Gmail 인터페이스로 제공하는 서비스.
Osprey : Discord에서 오픈소스로 공개한 룰 엔진.
Showboat : AI 에이전트가 자신이 작업한 내용을 문서로 정리하게 하는 CLI.

버전 업데이트

Grafana v12.4 : 매트릭 대쉬보드, 릴리스 공지
Expo SDK 55 : React로 네이티브 앱을 만드는 플랫폼 SDK, 릴리스 공지
Deno v2.7 : TypeScript 런타임, 릴리스 공지
Nuxt UI v4.5.0 : UI 라이브러리, 릴리스 공지
Tekton Pipelines v1.9.0 LTS : 클라우드 네이티브 CI/CD 파이프라인, 릴리스 공지
Devin v2.2 : AI 코딩 에이전트, 릴리스 공지
ollama v0.17.0 : 오픈 모델을 로컬에서 실행하는 도구, 릴리스 공지
Hono v4.12.0 : 엣지용 웹 프레임워크, 릴리스 공지
Crossplane v2.2.0: 외부 인프라 관리용 Kubernetes 애드온, 릴리스 공지
Tailwind CSS v4.2.0 : CSS 프레임워크, 릴리스 공지
Kafka v4.2.0 : 분산 이벤트 스트리밍 플랫폼, 릴리스 공지
pnpm v10.30.0 : Node.js 패키지 매니저, 릴리스 공지
Oxlint v1.50.0 : JavaScript/TypeScript Linter, 릴리스 공지
Oxfmt v0.35.0 : JavaScript/TypeScript 포매터, 릴리스 공지
Obsidian v1.12.0 : 문서 관리 도구, 변경사항
- Obsidian CLI 제공
Node.js v24.14.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Node.js v25.7.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Kyverno v1.17 : Kubernetes 정책 엔진, 릴리스 공지
Istio v1.29.0 : 서비스 매쉬, 릴리스 공지
FastAPI v0.135.0 : Python 웹 프레임워크, 릴리스 공지

기술 뉴스 #288 : 26-02-16

2026-02-16T23:01:37+09:00

웹개발 관련

Announcing TypeScript 6.0 Beta : 직접 다운로드받아서 사용해 볼 수 있는 TypeScript 6.0 Beta 버전이 나왔다. 6.0은 JavaScript 코드 베이스를 기반으로 한 마지막 릴리스로 TypeScript 컴파일러와 관련 생태계를 Go로 바꾸고 있어서 Go 기반의 7.0으로 넘어가기 위한 다리 역할을 하는 버전이다.(영어)
The State of JS 2025 : 매년 발표되는 JavaScript 생태계의 설문조사로 올해는 1만여 명이 응답자로 참여했다. JavaScript 언어의 새 기능이나 브라우저 API의 인지도 등을 볼 수 있다. 다양한 분류로 시각화해 두어서 주류인 기술과 새롭게 관심받는 기술을 알 수 있다.(영어)
WebMCP를 사전 체험판으로 이용할 수 있습니다. : Chrome에서 에이전트가 브라우저를 사용할 수 있도록 WebMCP를 제안하고 사전 체험 프로그램을 통해서 사용해 볼 수 있게 한다. WebMCP는 HTML을 이용한 선언적 API와 JavaScript를 이용할 수 있는 명령형 API를 제공한다.(한국어)
Introducing the new v0 : 프롬프트를 입력하면 UI와 코드를 생성할 수 있도록 2004년 Vercel이 출시한 v0를 바이브 코딩을 넘어 실제 제품에 쓸 수 있도록 개선되었다. GitHub을 연동해서 기존 코드에서 작업할 수 있고 v0 내에서 엔지니어가 아니어도 PR을 제출할 수 있고 데이터를 연동해서 사용할 수 있게 되었다.(영어)
Launching Interop 2026 : 브라우저 벤더와 플랫폼 업체가 협력해서 웹 표준의 상호운용성을 개선하는 Interop이 작년에는 25점으로 시작해서 95점까지 개선하고 Interop 2026을 시작했다. Interop 2026에서는 Cross-document View Transitions, Scroll-driven animations, WebTransport, CSS container style queries 등 새로운 기능과 기존 기능의 신뢰성 등 20개의 집중 영역과 접근성, 모바일 테스트, JPEG XL, WebVTT 등 4개의 조사 영역이 포함되었다.(영어)
webpack Roadmap 2026 : webpack의 2026년 로드맵이 나왔다. 올해 계획하는 주요 계획에는 플러그인 없이 CSS 모듈을 지원하고 universal이라는 타겟을 통해 여러 런타임 간 호환성을 유지하도록 지원하고 로더 없이도 TypeScript를 빌드하고 플러그인 없이 HTML 파일을 가져오고 엔트리포인트로 활용할 수 있게 할 계획이다.(영어)
Introducing Geist Pixel : Vercel에서 기존에 공개했던 Geist Sans와 Geist Mono에 기반해서 비트맵에 영감받은 Geist Pixel 폰트를 공개했다.

그 밖의 개발 관련

2026 Agentic Coding Trends Report : Anthropic에서 에이전틱 코딩 트렌드 보고서를 발표했다. 2005년 코딩 에이전트는 실험적 도구에서 프로덕션 시스템으로 이동했는데 이러한 성과가 더 확장될 것이라고 예측한다.(영어)
- 트랜드 1: 소프트웨어 개발 생명 주기가 극적으로 변화한다. 코딩이나 디버깅 등은 AI로 이동하고 엔지니어는 에이전트를 오케스트레이션하고 산출물을 평가하고 올바르게 해결하도록 보장하는 쪽으로 역할이 이동된다. 엔지니어는 점점 풀스택이 되고 있고 온보딩도 수주에서 수 시간으로 붕괴하기 시작해서 인력 배치와 프로젝트 자원 할당에 큰 변화가 올 것이다.
- 트랜드 2: 단일 에이전트는 조정된 팀으로 진화한다. 멀티 에이전트 시스템이 단일 에이전트 워크플로우를 대체할 것이다.
- 트랜드 3: 장기 실행 에이전트가 완전한 시스템을 구축한다. 에이전트의 작업 범위가 수준에서 며칠 또는 수주로 확장되어 복잡한 문제를 해결하면서 이전에는 실행 불가능했던 문제를 해결하고 시장 진입 경로도 가속화된다.
- 트랜드 4: 인간의 감독은 지능적 협업을 통해 확장된다. 에이전트를 통한 품질 관리가 표준이 되고 에이전트가 언제 인간의 판단이 필요한지를 배우게 되어 인간의 감독이 모든 것을 검토하는 대신 중요한 것을 검토하는 쪽으로 이동할 것이다.
- 트랜드 5: 에이전틱 코딩이 새로운 표면과 사용자로 확장된다. 언어 장벽이 사라져서 레거시 언어에 대한 유지 보수도 사라지고 특수한 사용 사례에 대한 도입 장벽도 제거될 것이며 코딩이 엔지니어를 넘어 비전통적인 개발자도 에이전틱 코딩을 사용하게 된다.
- 트랜드 6: 생산성 향상이 소프트웨어 개발의 경제성을 재편한다. 에이전트 역량, 오케스트레이션 개선, 인간의 경험이 합쳐져서 계단식 개선을 만들어내고 프로젝트 일정이 짧아져서 시장에 더 빠르게 대응할 수 있게 된다.
- 트랜드 7: 비기술적 사용 사례가 조직 전반에 확장된다. 모든 분야가 코딩 역량을 얻게 되어 도메인 전문가가 직접 솔루션을 구현하게 된다.
- 트랜드 8: 에이전틱 코딩은 보안 방어를 강화하지만, 공격적인 사용도 증가시킨다. 보안 지식이 민주화되어 누구나 보안 엔지니어가 될 수 있지만 공격자도 공격 방법을 확장할 수 있게 된다. 자동화된 에이전틱 시스템이 보안 대응을 하게 된다.
GPT-5.3-Codex 소개 : OpenAI에서 Codex의 새로운 모델 GPT-5.3-Codex를 공개했다. GPT-5.3-Codex는 최첨단 코딩 성능과 GPT-5.2의 추론 능력과 전문 지식 역량을 하나의 모델로 결합하고 처리 속도도 25% 빨라졌다. 주요 벤치마크에서 최고 수준의 성과를 기록했다.(한국어)
GPT‑5.3‑Codex‑Spark를 소개합니다 : OpenAI가 Cerebras와의 파트너쉽을 통해 GPT‑5.3‑Codex의 경량 버전이면서 실시간 코딩을 위해 초고속으로 설계된 GPT‑5.3‑Codex-Spark의 리서치 프리뷰를 공개했다. 최신 프런티어 모델은 장시간 작업에 강점을 보였지만 Codex-Spark는 거의 즉각적으로 응답하도록 만들어졌고 128k 컨텍스트 윈도우를 지원하는 텍스트 전용 모델로 출시되었다.(한국어)
Orchestrate teams of Claude Code sessions : 여러 Claude Code 인스턴스를 팀으로 협력할 수 있게 하는 Agent temas 기능이 나왔다. 한 세션은 팀 리더 역할로 업무를 조정하고 업무를 할당하여 결과를 종합하고 팀원들을 독립적으로 작업하고 각자의 컨텍스트 창에서 서로 소통하게 된다. 서브 에이전트와 다른 점을 서브 에이전트는 메인 에이전트에게만 보고할 수 있지만 Agent team에서는 상호작용할 수 있다. 더 자세한 내용을 알고 싶으면 Addy Osmani가 쓴 Claude Code Swarms를 읽어보면 좋다.(영어)
Qwen3-Coder-Next: Pushing Small Hybrid Models on Agentic Coding : Alibaba에서 코딩 에이전트와 로컬 개발을 위해 특별히 설계된 Qwen3-Coder-Next 모델을 공개했다. Qwen3-Next-80B-A3B-Base 위에 구축된 Qwen3-Coder-Next는 강력한 코딩 역량을 보여주면서도 낮은 추론 비용을 달성했다.(영어)
Introducing the GitButler CLI : GitButler에서 Git을 더 풍부하게 사용할 수 있는 but CLI를 발표했다. 훨씬 많은 정보를 보여주는 status나 병렬 브랜치 작업을 쉽게 할 수 있는 기능, Stacked 브랜치를 쉽게 관리할 수 있는 기능, undo 기능 등 다양한 기능을 제공한다.(영어)
Xcode 26.3 unlocks the power of agentic coding : Xcode 26.3부터 에이전트 코딩 지원을 도입해서 Claude Agent와 Codex 같은 에이전트를 사용해서 Xcode에서 개발할 수 있게 되었다.(영어)
Introducing Cline CLI 2.0: from sidebar to the terminal : Cline에서 이젠 IDE보다 오케스트레이션을 위한 인터페이스가 필요하다고 얘기하며 Cline CLI 2.0을 발표했다. VS Code의 인터페이스를 벗어나서 터미널에 맞는 인터페이스를 제공하고 -y 플래그를 통해 인터렉티브 TUI 없이 자율성을 부여할 수 있어서 자동화해서 사용할 수 있다.(영어)
Speed up responses with fast mode : Claude Code에 Fast mode가 리서치 프리뷰로 공개되었다. Fast Mode는 Claude Opus 4.6을 2.5배 더 빠르게 제공하는 대신 토큰당 비용을 더 비싸게 받는다.(영어)
Hello Entire World : 전 GitHub CEO였던 Thomas Dohmake가 퇴사하고 6천만 달러의 시드 라운드 투자를 받아 Entire라는 회사를 만들었다.(기업 가치는 3억 달러) 그동안 개발자 도구와 시스템은 사람을 위해서 만들어졌기에 에이전트와 인간이 협력할 수 있는 개발자 플랫폼을 만드는 것을 목표로 코드, 의도, 제약 조건, 추론을 하나의 버전 제어 시스템으로 통합하는 Git 호환 데이터베이스, 다중 에이전트 간 조정을 가능하게 하는 의미 추론 계층, 에이전트와 인간의 협업을 위한 소프트웨어 개발 생명주기를 재창조하는 AI 네이티브 소프트웨어 개발 생명주기를 핵심 요소로 삼고 있다. 첫 번째 제품으로 에이전트가 코드를 생성해서 커밋하면 커밋과 함께 전체 세션을 캡쳐해서 추적할 수 있게 하는 Checkpoint를 공개했다.(영어)
Introducing Echo : Replay에서 iOS와 iPadOS용 SSH 클라이언트를 만들었다. Echo는 Ghostty를 터미널 엔진으로 사용하고 있고 코딩 에이전트를 더 잘 사용하기 위해서 SSH 클라이언트가 새로 필요하다고 느껴서 만들었다고 한다. 유료 앱으로 가격은 2.99 달러이다.(영어)

인프라 관련

How Prometheus Remote Write v2 can help cut network egress costs by as much as 50% : 2024년에 제안된 Prometheus Remote Write v2가 아직 실험 단계임에도 상당한 비용 절감을 보여주고 있다. Grafana Labs 내부에서 v1을 v2로 변경했을 때 CPU와 메모리가 5%에서 10%로 약간 증가했지만, 텔레메트리 네트워크 이그레스 비용은 50% 이상 줄었다.(영어)
Hacking Moltbook: The AI Social Network Any Human Can Control : 클라우드 보안 업체인 Wiz에서 OpenClaw의 소셜 네트워크인 Moltbook이 인기를 끌자 보안 검사를 시도했다. 비침해적인 단순 탐색을 한 결과 Supabase의 데이터베이스의 읽기/쓰기 권한이 모두 허용되어 있었다. Wiz에 따르면 150만 명의 에이전트가 등록되었다고 알려졌지만, 데이터베이스에는 17,000명의 사람이 확인되었고, 비율은 88:1이었는데 POST 요청으로 누구나 게시할 수 있었기에 실제로는 인간이 많은 에이전트를 사용해서 콘텐츠를 게시한 것이었다. 바이브 코딩에서 흔하게 발견되는 JavaScript 번들에 자격 증명이 포함되는 패턴을 분석한 결과 Supabase API 키를 발견할 수 있었고 백엔드에서 이에 대한 보안 조치가 없었기에 이 키를 사용해서 데이터베이스에 접근해서 150만 개의 API 인증 토큰, 35,000개의 이메일 주소, 에이전트 간의 메시지에 접근할 수 있었다.(영어)
Introducing Markdown for Agents : 에이전트에서 Markdown이 공용어로 자리 잡았고, HTML에 비해 Markdown은 토큰도 훨씬 절약할 수 있기 때문에 HTML 문서를 Markdown으로 변환하는 게 일반적인 작업이다. Cloudflare는 Accept 헤더로 text/markdown으로 요청할 경우 HTML을 Markdown으로 변환해서 제공하는 기능을 지원한다.(영어)
Uber’s Rate Limiting System : 분산 시스템에서 서비스의 신뢰성과 공정성을 유지하기 위해 Rate Limit은 중요하다. Uber의 마이크로 서비스 초창기에는 트래픽 과부하로부터 서비스를 보호할 단일 방법이 없었기에 각 팀이 자체적으로 미들웨어나 Redis를 사용해서 구현했지만 동작도 일관적이지 않고 운영도 쉽지 않았다. 이를 해결하기 위해 중앙에서 제어할 방법이 필요했지만, Redis를 이용한 중앙 카운터를 구현하기에는 규모가 너무 컸기에 각 로컬 프록시를 사용한 완전 분산 아키텍처를 사용하는 것이 유일한 방법이라는 결론을 내리고 Uber의 Service Mesh에 Rate Limit을 통합했다. 서비스 메시의 Rate Limit 클라이언트는 토큰 버킷 알고리즘을 사용해서 요청을 차단하며 호스트별 요청 수를 Zone의 집계기에 보고하고 집계기는 사용량을 계산한 후 컨트롤러에 전송하면 글로벌과 리전별로 있는 컨트롤러가 데이터를 집계해서 업체와 고객에게 전달한다. 여러 번의 개선을 통해 현재는 지연속도와 오버헤드가 크게 개선되었고 운영 부담도 적어졌다.(영어)
Introducing uFowarder: The Consumer Proxy for Kafka Async Queuing : 하루에 수조 개의 메시지를 처리하는 Kafka를 운영하는 Uber에서 파티션 확장성이나 다중 프로그래밍 언어 지원 등의 문제를 해결하기 위해 수년 전 Consumer Proxy을 만들어서 익숙한 gRPC 인터페이스를 사용할 수 있게 했다. 하지만 규모가 점점 커지면서 Head-of-line 문제는 계속 있었고 Producer와 Consumer 간의 격리도 필요하게 되었다. 그래서 uForwarder를 만들어서 오픈소스로 공개했는데 컨텍스트를 인식해서 라우팅함으로써 존 격리 등을 할 수 있게 되었고 poison-pill 메시지로 인해 Consumer가 문제를 해결하기 위해 Head-of-line 차단을 자동으로 감지해서 완화 조치를 수행하고 Consumer는 stateless로 만들어서 자유롭게 확장할 수 있게 했다.(영어)
Introducing Deno Sandbox : Deno에서 Deno Deply Cloud에서 실행되는 경량 리눅스 마이크로 VM을 실행해서 신뢰할 수 없는 코드를 실행할 수 있는 Deno Sendbox를 출시했다.(영어)
Minio is no longer maintained : Minio가 저장소가 더 이상 유지 보수되지 않는다고 명시하고 상용버전인 AIStor를 사용하라고 안내로 바뀌었다.(영어)

AI 관련

Introducing Claude Opus 4.6 : Claude Sonnet 5가 출시될 예정이라는 소문이 무성한 가운데 Anthropic이 가장 좋은 평가를 받는 Claude Opus의 4.6을 내놓았다. 이전보다 코딩 능력이 향상되었고, Opus에서는 처음으로 베타에서 100만 토큰 콘텍스트 윈도우를 제공한다.(영어)
Codex 앱을 소개합니다 : OpenAI에서 여러 에이전트를 동시에 관리하고 작업을 병렬로 실행할 수 있는 macOS용 Codex 앱을 발표했다.(한국어)
OpenAI Frontier를 소개합니다 : OpenAI에서 업무용 AI 에이전트 구축과 배포, 관리를 지원하는 플랫폼인 Frontier를 출시했다. Frontier는 기업이 이미 사용 중인 시스템과 함께 동작해서 회사의 비즈니스 콘텍스트 상에서 에이전트가 업무를 지원할 수 있다.(한국어)
MiniMax M2.5: Built for Real-World Productivity : MiniMax에서 새로운 모델인 M2.5를 발표했다. M2.5는 코딩, 에이전트 도구 사용, 검색, 업무 등에서 SOTA 수준이며 다양한 벤치마크에서 높은 점수를 기록했고 1시간 동안 초당 100 토큰을 계속해서 사용한다고 했을 때 1달러만 들 정도로 저렴한 가격으로 제공한다.(영어)
GLM-5: From Vibe Coding to Agentic Engineering : Z.ai에서 새로운 모델 GLM-5를 발표했다. 이전 GLM-4.5보다 큰 744B 매개변수까지 확장했고 사전 학습 데이터의 토큰 수도 28.5T로 증가했다. 이번 모델에서는 세밀한 학습 후 반복할 수 있는 비동기 강화 학습 인프라인 Slime을 개발해서 모델의 벤치마크 점수도 우수하게 나타났다.(영어)
Seedance 2.0 : ByteDance에서 멀티모달 오디오-비디오를 생성할 수 있는 Seedance 2.0을 발표했다. Seedance의 높은 품질의 영상으로 주목받고 있다.(영어)
Qwen-Image-2.0: Professional infographics, exquisite photorealism : Alibaba에서 새로운 이미지 생성 모델 Qwen-Image-2.0를 출시했다. Qwen-Image-2.0는 인포그래픽을 생성할 수 있게 1k 토큰 인스트럭션을 지원하고 2k 해상도와 함께 텍스트 렌더링도 강화되었다.(영어)
The Waymo World Model: A New Frontier For Autonomous Driving Simulation : 자율주행 택시인 Waymo에서 Google DeepMind Genie 3를 사용해서 월드 모델을 만들어서 자율주행의 시뮬레이션을 구성했다. 기존 시뮬레이션을 수집한 도로 데이터를 바탕으로 학습하지만, Waymo 월드 모델을 사용하면 날씨, 상황, 언어 등 다양한 상황을 만들어서 시뮬레이션할 수 있게 되었다.(영어)

볼만한 링크

Agentic Engineering : Andrej Karpathy가 1년 전 만든 바이브 코딩이라는 용어가 크게 유행했지만 실제 제품에서는 한계를 보인다. 숙련된 엔지니어들은 AI를 끊임없이 감독하면서 생산성을 얻고 코드 품질을 유지하고 있는데 이는 바이브 코딩과는 전혀 다르기에 다른 용어가 필요하다. Simon Willison인 vibe engineering을 제안했고, Andrej Karpathy가 이번엔 Agentic Engineering을 제안했다. 이는 AI 에이전트를 조율하고 아키텍트, 리뷰어, 의사결정자 역할을 하는 엔지니어링이고 더 전문적으로 보이고 경계도 명확하게 보여주기 때문이라고 한다.(영어)
My AI Adoption Journey : HashiCorp의 공동 창업자였던 Mitchell Hashimoto가 AI를 도입한 과정을 설명한 글이다. 본인은 의미 있는 도구를 도입할 때는 항상 비효율의 시기와 적절성의 시기를 거쳐서 워크플로우와 인생을 바꾸는 발견의 시기를 거치게 되는데 이러한 기조로 AI를 코딩에 어떻게 도입하게 되었는지는 단계별로 설명한다.(영어)
- 1단계는 ChatGPT같은 챗봇을 통해 의미 있는 작업을 중단해야 하는데 이는 가치를 찾기 위해서는 에이전트를 사용해야 하기 때문이다.
- 2단계는 자신의 작품을 재현하는 것인데 처음에는 감명받지 못했지만, 수동 커밋한 작업을 에이전트가 똑같은 결과를 내도록 강요했다. 힘든 과정이었지만 이를 통해 세션을 실행할 수 있는 개별 과제로 나누고 검증할 방법을 제공해야 한다는 원리를 파악했고 이 과정이 큰 효율성으로 이어졌고 언제 에이전트를 사용하지 말아야 하는지도 알게 되었다.
- 3단계는 본인이 일할 수 없는 시간에도 진전을 이룰 수 있을 거라는 생각에 매일 마지막 30분을 차단하고 한 명 이상의 에이전트를 시작했다. 이 과정도 힘들었지만, 심층 조사라거나 새로운 아이디어를 생각하는 등 새로운 방향이 보이기 시작했다.
- 4단계부터는 AI가 어떤 작업을 잘하고 못하는지 자신감이 생겼고 모든 일을 맡기고 다른 일을 처리하는 단계로 넘어갔다.
- 5단계는 하네스 설계 단계로 에이전트는 처음부터 올바른 결과를 내거나 최악의 상황에도 최소한의 수정만으로 결과를 낼 때 효율적이라서 이를 달성하기 위해 에이전트에게 잘못되었음을 자동으로 알려주는 것이 제일 좋다. 이를 하네스 엔지니어링이라고 부르고 있는데 간단한 문제는 AGENTS.md에 업데이트하고 그 외에는 프로그래밍이 된 도구를 사용한다.
- 6단계는 항상 에이전트가 실행되는 것을 목표로 하고 있다. 아직 여러 에이전트를 동시에 돌리지 않고 그럴 생각도 없지만 항상 에이전트를 돌리는 것을 목표로 하고 있다.
Spotify says its best developers haven’t written a line of code since December, thanks to AI : Spotify의 공동 CEO인 Gustav Söderström가 Shopify의 최고 개발자들이 12월 이후로 단 한 줄의 코드도 작성하지 않았다고 얘기했다. Spotify는 Honk라는 내부 시스템을 만들어서 Claude Code 등을 활용한 원격 코딩을 가능하게 만들었는데 이를 통해서 핸드폰으로도 버그를 수정하거나 기능을 추가할 수 있게 되어서 코딩과 배포가 엄청나게 가속화되었다고 한다.(영어)
2026-01-14: The Day the telnet Died : 1월 14일 전 세계의 Telnet 트래픽이 급격히 83%까지 감소했고 이후 2월 10일까지도 기준치보다 59%가 감소한 상태를 유지하고 있다. 그리고 6일 뒤인 1월 20일 CVE-2026-24061인 GNU Inetutils telnetd에서 중요한 인증 우회 취약점이 발견되었다. 이 때문에 백본이나 트랜짓 제공업체가 CVE가 공개되기 전에 먼저 23 포트 필터링을 도입했고 이후 CVE가 공개된 것이 아닌지를 추측하고 있다.(영어)

IT 업계 뉴스

OpenClaw, OpenAI and the future : OpenClaw를 만든 Peter Steinberger가 OpenAI에 합류했다.(영어)
Why I joined OpenAI : 성능 엔지니어링의 대가라고 할 수 있는 Brendan Gregg가 Intel을 퇴사하고 OpenAI를 선택했다. 많은 AI 회사를 만났고 흥미로운 공학 문제가 많이 보였지만 OpenAI에 이미 알고 있는 재능 있는 엔지니어가 가장 많아서 선택했다고 한다.(영어)
Anthropic raises $30 billion in Series G funding at $380 billion post-money valuation : Anthropic이 GIC와 Coatue가 주도한 시리즈 G 투자 라운드에서 300억 달러를 모금하고 기업가치를 3,800억 달러(약 540조 원)의 기업 가치를 평가받았다. 현재 연간 환산 매출(run-rate revenue)은 140억 달러이고 Claude Code의 연간 환산 매출은 25억 달러 이상으로 성장했고 여전히 사용자가 크게 성장하고 있다.(영어)
xAI joins SpaceX to Accelerate Humanity’s Future : Elon Musk의 AI 회사인 xAI가 항공우주 회사인 SpaceX에 인수되었다.(영어)
ChatGPT rolls out ads : OpenAI가 월 8달러의 저렴한 구독 플랜인 Go 플랜에서 광고 테스트를 시작한다고 발표했다. 이 광고는 Plus, Pro, Business, Enterprise, Education 플랜에는 적용되지 않으며 광고가 답변에도 영향을 주지 않는다고 밝혔다.(영어)
디시인사이드, 사모펀드에 2000억에 팔려... 반년 만에 본계약 체결 : 사모펀드 운용사 에이치프라이빗에쿼티가 디시인사이드 인수의 본계약을 체결했고, 매각가는 2,000억 원 수준으로 알려졌다.(영어)

프로젝트

Meshery : Kubernetes 클러스터 관리 플랫폼으로 CNCF 프로젝트
Korea Data.go.kr MCP Servers : 한국 공공 데이터 포털의 API를 MCP 서버로 제공하는 프로젝트.
Relic : Dart 웹 프레임워크.

버전 업데이트

pandas 3.0.0 : Python 데이터 분석 라이브러리, 릴리스 공지
ESLint v10.0.0 : JavaScript 코드 분석 도구, 릴리스 공지
Vue Router v5.0.0 : Vue.js의 라우팅 라이브러리, 릴리스 공지
Android v17 Beta : 모바일 운영체제, 릴리스 공지
Argo CD v3.1.0 : Kubernetes 배포 도구, 릴리스 공지
KEDA v2.19.0 : Kubernetes 오토스케일러, 릴리스 공지
GitButler v0.19 : Git 클라이언트, 릴리스 공지
Node.js v25.6.0 (Current) : 자바스크립트 런타임, 릴리스 공지
React Router v7.13.0 : React의 라우팅 라이브러리, 릴리스 공지
Dragonfly v2.4.0 : P2P 기반 파일 배포 및 이미지 가속 시스템, 릴리스 공지
Elastic v9.3.0 : 엘라스틱 스택, 릴리스 공지
podman v5.8.0 : 컨테이너 엔진, 변경사항
OpenVPN v2.7.0 : VPN, 릴리스 공지
React Native v0.84.0 : React를 이용한 모바일 앱 개발 프레임워크, 릴리스 공지
- Hermes V1이 기본 JavaScript 엔진이 됨.
- 사전에 컨파일된 바이너리가 iOS에서 기본이 됨.
Dart v3.11.0 : 프로그래밍 언어, 릴리스 공지
Flutter v3.41 : iOS, Android 네이티브 앱을 만드는 프레임워크, 릴리스 공지
Redis 8.6 : 키/밸류 스토어, 릴리스 공지
Nuxt UI v4.4.0 : UI 라이브러리, 릴리스 공지
Go v1.26 : 프로그래밍 언어, 릴리스 공지
ClickHouse v26.1 : 컬럼형 데이터베이스, 릴리스 공지
OpenSearch 3.5 : 분산형 검색 엔진, 릴리스 공지
Vim v9.2 : 텍스트 에디터, 릴리스 공지

기술 뉴스 #287 : 26-02-01

2026-02-01T19:41:44+09:00

웹개발 관련

Introducing: React Best Practices : Vercel에서 React와 Next.js의 최적화 지식을 AI가 사용할 수 있도록 정리한 react-best-practices 저장소를 공개했다. 이 저장소에는 비동기 폭포 제거, 번들 사이즈 최적화, 서버사이드 성능, 클라이언트 데이터 패칭, 렌더링 등의 내용이 포함되어 있다.(영어)
Yarn 6 Preview : JavaScript 패키지 매니저인 Yarn의 새 버전인 6 프리뷰가 발표되었다. Yarn이 등장한 지 10년 가까이 되는 시점에 거대한 모노레포에서 성능 한계에 도달해서 Yarn을 1년 전부터 Rust로 재작성한 버전으로 6~8개월 이내에 Rust 전환이 완료될 것으로 보고 있다. 프리뷰에서도 만족할 만한 성능 개선이 있었고 Node.js Corepack을 대체할 Yarn Switch도 개발했고 6.0부터는 Lazy Install을 지원하여 브랜치 전환 시 package.json을 보고 필요하다면 자동으로 패키지를 설치하는 기능도 제공한다.(영어)
Rethinking “Pixel Perfect” Web Design : 웹에서 디자이너의 의도대로 모든 요소가 정확하게 표시되는 Pixel Perfect는 인쇄 디자인부터 이어진 개념인데 현대 웹에서는 Pixel Perfect의 개념이 모호하고 뷰포트나 해상도 등은 무한하고 다국어 등 콘텐츠도 고정적이지 않고 접근성 문제도 있어서 어울리지 않는다. Pixel Perfect를 얘기할 게 아니라 디자인의 의도를 이해하고 디자인 토큰으로 협업해야 한다고 설명한다.(영어)

그 밖의 개발 관련

Self-Improving Coding Agents : Ryan Carson이 쓴 "How to make your agent learn and ship while you sleep"을 확장해서 스스로 일하는 코딩 에이전트를 설명하는 글이다. Geoffrey Huntley와 Ryan Carson이 대중화한 Ralph Wiggum 기법이라는 반복적 에이전트 루프를 이용해서 작업 목록에서 구현하고 검증한 뒤에 기록하고 초기화한 뒤에 다시 다음 일을 하게 만들어서 에이전트가 계속 일을 하게 만든다. 이렇게 하려면 작업을 잘 나누어야 하고 좀 더 복잡한 작업은 여러 단계의 루프를 조율할 수 있는 시스템이 필요하다. 이러한 에이전트 루프를 사용하려면 단일 세션을 늘리는 대신 AGENTS.md를 사용해서 중요한 정보와 지침을 제공해야 하는데 에이전트가 직접 AGENTS.md를 업데이트해서 사람과 AI가 모두 쉽게 읽을 수 있게 관리해야 한다. AGENTS.md 외에도 Git 히스토리와 진행 로그 파일, 작업 상태 파일을 이용해서 에이전트가 맥락을 쉽게 파악하게 할 수 있다.(영어)
Shipping at Inference-Speed : 이번에 OpenClaw로 유명해진 Peter Steinberger가 AI를 어떻게 사용하는지를 정리한 글이다. 보통 여러 프로젝트를 동시에 하는 데 집중해서 하는 큰 프로젝트와 위성 프로젝트를 같이 개발하는 편이고 codex의 큐잉 기능을 사용해서 새로운 아이디어가 생기면 파이프라인에 추가한다. 체크포인트 같은 것은 쓰지 않고 변경이 필요하면 모델에게 바꾸라고 하고 이미 해결한 문제는 다른 프로젝트를 보라고 하는 편이다. 프로젝트 docs 폴더에 문서를 유지하고 글로벌 AGENTS 파일에 지침을 주어서 사용하고 있다. 대부분의 작업을, 에이전트를 이용해서 자동화해서 사용하고 있다. 무엇을 만들든지 CLI로 먼저 시작해 보라고 얘기하며 gpt-5.2-codex high 모델을 가장 많이 사용한다고 한다.(영어) Code Review in the Age of AI** : AI도 코드 리뷰를 없애진 않았는데 혼자 개발하는 사람들은 자동화된 테스트를 안전망으로 사용하면서도 속도를 위해 모든 코드를 읽지 않으면서도 최종적으로는 수동 테스트와 비판적 추론을 수행한다. 팀 협업에서도 최종 승인은 사람이 아는데 PR도 커지고 수도 많아지면서 코드 리뷰가 병목이 되고 있다. AI 코드 리뷰 도구는 신중하게 설정해야 하고 Pull Request를 여전히 작게 만드는 게 중요하고 AI가 생성한 코드를 검증해야 하는 초안으로 다루는 것이 모범 사례가 되고 있다. AI를 1차 검토자로 활용하고 AI가 놓친 부분은 사람이 집중해야 하면 높은 테스트 기준을 유지해야 한다.(영어)
From pixels to characters: The engineering behind GitHub Copilot CLI’s animated ASCII banner : ASCII 아트가 초기 인터넷의 향수를 불러일으키는 잔재라고 생각하지만, 터미널에는 캔버스가 없고 ANSI 이스케이프 코드도 일관성이 없고 색상을 제대로 표현하는 것 자체가 쉽지 않다. GitHub Copilot CLI에서는 3초짜리 ASCII 배너 애니메이션을 만드는 데 6,000라인 이상의 TypeScript가 필요했는데 이는 대부분 터미널 간의 차이, 접근성 문제, 렌더링 로직에 사용되었다. 이를 어떻게 만들었는지를 설명하는 글이다.(영어)
Apache Hudi™ at Uber: Engineering for Trillion-Record-Scale Data Lake Operations : Uber에서 수백 페타바이트 규모의 데이터 레이크를 운영하면서 데이터 레이크 스토리지 엔진인 Apache Hudi를 어떻게 만들게 되었는지를 정리한 글이다. 2015년 Uber의 데이터 시스템이 크게 성장하면서 자주 변경되는 데이터를 실시간으로 제대로 인코딩하지 못해서 데이터 레이크의 성능을 유지하기 위해 다른 특성을 포기할 수밖에 없었고 이 문제를 해결하기 위해 Hudi를 만들게 되었다. Uber에서는 Hudi를 기본 구성 요소로 두고 인제스쳔 레이어, 쿼리 레이어 등과 통합해서 사용하고 있다.(영어)
The CLI for developers and agents : 오류 수집 플랫폼인 Sentry가 개발자와 에이전트가 사용할 수 있는 CLI를 새로 공개했다. 새 CLI에서는 이슈를 살펴보고 근본 원인을 AI로 분석하고 결과를 JSON 등으로 출력할 수 있다.(영어)
Skip Is Now Free and Open Source : 단일 Swift와 SwiftUI 코드 베이스로 iOS와 Android 앱을 모두 만들 수 있게 2023년 출시된 Skip이 오픈소스가 되었다. 그동안 일정 기준 이하의 인디 개발자만 무료로 이용하고 기업을 유료로 사용해야 했는데 광범위하게 사용되려면 무료로 제공되어야 하고 유료 폐쇄 소스는 선택할 때도 망설이게 되기 때문에 개방하는 게 맞다고 판단했다.(영어)

인프라 관련

New Conversion from cgroup v1 CPU Shares to v2 CPU Weight : Kubernetes이 cgroup v1을 염두에 두고 설계되었기 때문에 CPU share 개념을 사용하고 있었는데 cgroup v2로 바뀌면서 CPU share가 CPU weight로 바뀌게 되었다. 그래서 Kubernete에서는 공식을 통해서 share를 weight로 변경해서 사용했는데 이는 선형적 매핑이었기 때문에 share가 꽤 낮은 weight로 변환되기 때문에 Kubernetes가 아닌 리소스에 비해서 우선순위가 낮아지는 문제가 있었고 값이 너무 작아서 세분화하기 어려운 문제도 있었다. 이를 해결하기 위해 새로운 변환 공식을 만들어서 두 문제를 다 해결했고, 이는 OCI 런타임에 구현되어 있으므로 runc 1.3.2나 crun 1.23을 채택하면 새로운 공식이 적용된다.(영어)
CodeBreach: Infiltrating the AWS Console Supply Chain and Hijacking AWS GitHub Repositories via CodeBuild : 최근 CI를 이용한 인증 탈취 공격이 계속됨에 따라 Wiz Research는 AWS CodeBuild를 이용한 공격 방법을 리서치했다. 일반적으로 Pull Request를 이용해서 CI를 실행하도록 만들어서 시크릿을 탈취하게 되는데 CodeBuild는 이를 막기 위해 Webhook 필터로 허가된 GitHub 사용자를 ACTOR_ID를 지원한다. 이 ACTOR_ID는 123|456|789처럼 정규표현식으로 지정하는데 사용자들이 일반적으로 패턴을 고정하지 않으므로 11233이라는 사용자가 있으면 123 패턴과 매치되어 필터를 통과하게 된다. 그래서 Wiz Research는 GitHub App을 계속 생성해서 승인된 사용자의 ID를 포함하는 ID를 획득할 수 있었고 이 사용자를 통해서 CI를 트리거하고 어드민 권한을 탈취할 수 있었다.(영어)
What came first: the CNAME or the A record? : Cloudflare에서 1.1.1.1에 최적화 업데이트 후 DNS 해석 문제가 발생하면서 롤백하게 되었습니다. 도메인을 질의할 때 CNAME을 받게 되면 연쇄적으로 따라가서 A 레코드까지 찾게 된다. 이 도메인 질의의 응답 체인에서 각각은 TTL이 다르기 때문에 일부만 만료되는 경우 만료된 것만 갱신하게 되는데, 이번에 Cloudflare에서 메모리 최적화를 하면서 기존에 항상 CNAME이 먼저 오던 로직에서 새로 갱신된 CNAME을 응답의 마지막에 넣게 되었다. 일부 DNS 클라이언트는 CNAME을 먼저 찾기 때문에 순서가 바뀌면서 응답을 제대로 해석하지 못해서 문제가 생긴 건데 RFC 상으로 살펴보아도 CNAME이 먼저와야 한다는 조건은 없지만 일부 클라이언트가 이미 이렇게 구현되어 있기 때문에 CNAME이 먼저 오게 하는 로직을 유지할 계획이다.(영어)
Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees : 작년에도 발표했지만 26년 3월에 Ingress NGINX는 3월에 은퇴하게 된다. Ingress NGINX를 계속 사용할 경우 보안 문제가 생길 수 있으므로 Gateway API나 서드파티 Ingress 컨트롤러로 전환하기를 강력하게 권고한다.(영어)
6-day and IP Address Certificates are Generally Available : Let's Encrypt에서 6일(160시간) 동안 유효한 IP 주소 인증서를 발급하기 시작했다.(영어)
Introducing the Official ClickHouse Kubernetes Operator: Seamless Analytics at Scale : ClickHouse가 공식 Kubernetes Operator를 오픈 소스로 공개해서 Kubernetes에서 ClickHouse를 쉽게 프로비저닝하고 운영할 수 있게 지원한다.(영어)
Introducing OpenEverest: An Independent Open Source Project for the Future of Data Platforms : 데이터베이스 기술 지원 업체인 Percona에서 MySQL, PostgreSQL, MongoDB를 자동으로 프로비저닝하고 관리할 수 있는 오픈소스 플랫폼인 OpenEverest를 공개했다.(영어)

AI 관련

Introducing OpenClaw : 지난주에 인터넷을 뜨겁게 달군 프로젝트로 처음에는 Clawd 혹은 Clawdbot으로 알려졌지만, Anthropic의 요청으로 Moltbot으로 바뀌었다가 지금은 OpenClaw로 바뀌었다. OpenClaw는 사용자 컴퓨터에서 실행되어 채팅 앱에서 동작하는 오픈 에이전트 플랫폼으로 브라우저나 컴퓨터를 제어해서 모든 것을 자동화할 수 있다. 며칠 만에 엄청난 인기를 끌고 에이전트끼리 소통하는 소셜 네트워크까지 생기게 되었는데 이러한 상황을 Simon Willison이 블로그에 잘 정리해 두었다. 그냥 실행하는 것은 위험하므로 OpenClaw를 실행하기 위해 맥미니가 많이 팔리게 되고 Claudeflare나 DigitalOcean에서도 OpenClaw를 쉽게 돌릴 수 있게 발 빠르게 움직이고 있다.(영어)
Open Responses : LLM API를 프로바이더마다 다르게 인코딩하는 문제를 해결하기 위해 여러 프로바이더 간에 상호 운영이 가능하도록 OpenAI Responses API를 기반으로 오픈 스펙인 Open Responses를 공개했다. Open Response는 OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpeanAI, vLLM이 함께 참여해서 만들고 유지보수하고 있다.(영어)
Anthropic's Original Performance Take-Home : Anthropic이 Claude Opus의 성능을 평가하는 과제를 공개했다. Claude Opus 4.5가 2시간 이내에 인간보다 성능을 앞서기 이전 버전으로 원래는 4시간 제한이었으나 항상 Claude Opus 4.5가 이길 정도로 성능이 좋아져서 2시간 제한으로 줄였다. 이 과제를 풀어서 Claude Opus 4.5의 최고 성능인 1,487사이클 이하로 최적화하면 Anthropic에 이력서를 제출할 수 있다.(영어)
TranslateGemma: A new suite of open translation models : Google에서 Gemma 3 기반으로 만들어진 오픈 번역 모델 TranslateGemma를 공개했다. TranslateGemma는 4B, 12B, 27B 매개변수로 제공되며 컴팩트한 고성능 모델로 어떤 기기에서든 55개 언어를 번역할 수 있다.(영어)
DeepSeek-OCR 2: Visual Causal Flow : DeepSeek가 OCR 2를 발표했다. 기존 비전-언어 모델(VLM)은 왼쪽 위부터 오른쪽 아래로 처리하지만, OCR 2는 인과적 추론 능력을 사용해서 사람처럼 어떤 부분에 집중하고 어디를 읽어야 하는지 판단해서 OCR을 더 향상했다.(영어)
Kimi K2.5: Visual Agentic Intelligence : Moonshot AI에서 새로운 오픈소스 모델인 Kimi K2.5를 공개했다. Kimi K2.5는 최대 100개의 서브 에이전트 스웜을 직접 사용해서 단일 에이전트 대비 실행시간이 4.5배 단축되고 HLE, BrowseComp, SWE-Verified 벤치마크에서 훨씬 적은 비용으로 강력한 성능을 보여주는 것으로 나타났다.(영어)
Terminally online Mistral Vibe : Devstral 2 모델 기반으로 한 코딩 에이전트 Mistral Vibe 2.0이 출시되었다.(영어)
Qwen3-TTS Family is Now Open Sourced: Voice Design, Clone, and Generation! : Alibaba에서 음성 생성 모델인 Qwen3-TTS의 1.7B와 0.6B를 오픈소스로 공개했다.(영어)
Pushing Qwen3-Max-Thinking Beyond its Limits : Alibaba에서 새로운 대표 추론 모델 Qwen3-Max-Thinking을 공개했다. Qwen3-Max-Thinking는 다수의 벤치마크에서 GPT-5.2-Thinking, Claude-Opus-4.5, Gemini 3 Pro와 견줄만한 성능을 보여주었다.(영어)
Prism을 소개합니다 : OpenAI에서 GPT-5.2 기반으로 과학자들이 연구 논문을 작성할 수 있도록 지원하는 AI 워크스페이스인 Prism을 공개했다. Prism은 무료로 사용할 수 있으면 ChatGPT 개인 개정이 있다면 누구나 사용할 수 있다.(한국어)
Project Genie: Experimenting with infinite, interactive worlds : Google에서 범용 월드 모델인 Genie 3를 작년 8월에 공개했는데 Google AI Ultra 사용자에게 Project Genie를 제공하기 시작했다. 이 실험적 연구 프로토타입에서는 인터렉티브한 세계를 만든 뒤에 들어가 볼 수 있다.(영어)

볼만한 링크

Why Senior Engineers Let Bad Projects Fail : 다른 팀의 프로젝트가 잘못되었다는 얘기를 직접 하지 않는 경험을 하면서 그 이유와 옳은 것과 효과적인 것이 다르기 때문이라고 설명한다. 나쁜 프로젝트는 매우 주관적인데 경험이 쌓이면서 어떤 프로젝트를 봤을 때 나쁜 프로젝트라는 신호가 오게 되는데 이를 해당 팀에 가서 설명한 적도 있었다. 하지만 우려는 속도를 늦추기 때문에 이러한 우려가 변화를 일으키기보다는 무시당할 가능성이 높고 인정받을 가능성은 거의 없으면 적을 만들게 될 수 있다. 효과적으로 영향을 끼치려면 일을 하며 사람들을 돕고, 프로젝트를 성공시키면서 영향력을 쌓았다가 우려를 제기하거나 할 때 이때 쌓아놓은 영향력을 소비할 수 있어야 한다. 목소리를 낼 때는 프로젝트가 본인의 팀과 얼마나 가까운지, 잘못되었을 때 팀에 어떤 영향을 주는지, 회사에 어떤 영향을 주는지를 기준으로 판단한다.(영어)
The Long Now of the Web: Inside the Internet Archive’s Fight Against Forgetting : 디지털 자료를 보관하는 비영리 재단인 Internet Archive가 저비용으로 운영하기 위해 발전한 과정을 설명한 글이다.(영어)
- 핵심은 최소한의 전력과 열로 대량의 데이터를 저장하기 위해 설계된 PetaBox라는 저장 서버다.
- 2000년대 초 대부분의 스토리지 솔루션은 고속 데이터에 맞춰졌기에 비싸고 전력 소비가 컸으므로 Internet Archive를 만든 Brewster Kahle은 소비자용 제품으로 PetaBox를 만들었다.
- 2004년 PetaBox는 랙당 100TB를 저장하며 6kW 전력을 사용했다.
- 2010년 PetaBox는 랙당 480TB를 저장하며 6~8kW 전력을 사용했다.
- 현재 세대인 2024년부터는 PetaBox가 랙당 1,400TB를 저장하며 6~8kW 전력을 사용한다.
- 샌프란시스코의 서늘한 해향성 기후를 이용해서 에어컨 없이 공기를 이용해서 열관리를 한다.
- 데이터를 여러 머신에 미러링하고 물리적 위치를 분산해서 일정 수의 죽은 드라이브를 허용하는 방법으로 유지보수 노력을 적게 유지한다.
- 오랫동안 Heritrix라는 자바로 개발된 오픈소스 크롤러를 사용했다.
- Heritrix는 텍스트뿐 아니라 이미지, CSS 등의 아티팩트도 수집해서 WARC 형식으로 패키징하고 페이지뿐 아니라 요청 헤더까지 보존한다.
- 웹이 동적으로 바뀌면서 Heritrix는 페이지를 제대로 수집하지 못했기에 Brozzler라는 헤드리스 크롬으로 사이트를 저장하고 Umbra라는 브라우저 자동화를 통해 페이지를 스크롤 하는 등의 동작으로 Brozzler가 페이지를 저장할 수 있게 한다.
- Internet Archive의 연간 수익은 2,500~3,000만 달러인데 2024년에는 2,350만 달러를 지출했습니다.
- 수익의 60~70%는 기부금과 보조금이며 그 외에는 아카이브 서비스를 제공해서 수익을 창출한다.
- 디지털 도서 대출과 관련한 소송은 인터넷 아카이브가 져서 해당 도서는 제외했고, 음원에 대한 분쟁도 있었지만 2025년 9월 합의로 해결되었다.
- 인터넷 아카이브는 2025년 7월 미국 연방 보관 도서관으로 지정되어 법적 보호를 받게 되었다.
A few random notes from claude coding quite a bit last few weeks : Andrej Karpathy가 Claude 코딩을 하면서 적은 메모다. 11월에는 80% 수동 작업을 했지만, 12월에는 80% 에이전트 코딩을 한다. 물론 아직 실수를 하고 과한 코드를 작성하는 경우가 있으므로 살펴보면서 지시해 주어야 한다. 속도가 향상되었다고 느끼긴 하지만 이전에 할 가치가 없거나 몰라서 못 했던 일을 한다는 면에서 확장에 가깝다고 느끼고 성공 기준을 제시하고 지키도록 하는 게 좋았고 에이전트 프로그래밍이 재미있게 느껴진다고 한다. LLM 에이전트 기능은 25년 12월에 일관성 임계점을 넘겼다고 얘기한다.(영어)
Agent Psychosis: Are We Going Insane? : Armin Ronacher가 에이전트 코딩에 대해 비판한 글이다. Armin Ronacher도 에이전트 코딩을 많이 쓰는 편이지만 에이전트 코딩을 쓰면서 프롬프트로 결과를 만드는 것에 중독되곤 하는데 꽤 만족스러운 결과물이 나오지만 실제로 사용하지 않는 경우도 많고 다듬기도 어렵고 코드 품질도 좋지 않았다. 또한 코드를 생성하는 덴 몇 분이지만 이 코드를 리뷰하는 데는 훨씬 더 긴 시간이 걸리는 비대칭성이 엄청나고 메인테이너의 부담도 엄청나게 커지게 된다. AI 에이전트가 정말 훌륭하지만 관리하지 않으면 정말 큰 쓰레기 기계가 될 수 있다고 경고한다.(영어)
Automatic programming : Redis를 만든 antirez가 AI의 도움을 받아 소프트웨어를 만드는 과정을 Automatic Programming이라고 부르기 시작했다고 한다. 바이브 코딩은 무슨 일이 일어나는지 모르는 채 소프트웨어를 만드는 과정이고 Automatic Programming은 고품질을 추구하고 소프트웨어 비전을 엄격하게 따르는 소프트웨어를 만드는 과정이라고 설명하며 AI 생성한 코드도 본인의 것이라고 얘기한다.(영어)

IT 업계 뉴스

The Astro Technology Company joins Cloudflare : 2021년 만들어진 웹 프레임워크 Astro가 인기를 얻으며 사업을 키우기 위해 만들어진 Astro Technology Company가 Cloudflare에 인수되었다. 인수된 후에도 Astro는 오픈소스로 유지되고 계속 개발될 것이며 Cloudflare뿐 아니라 다른 플랫폼도 배포 대상으로 지원하겠다고 밝혔다.(영어)
Mozilla is building an AI ‘rebel alliance’ to take on industry heavyweights OpenAI, Anthropic : Mozilla가 약 14억 달러의 자금으로 OpenAI와 Anthropic 등을 견제할 수 있는 기술 스타트업, 개발자, 공익 기술자의 반란 동맹 네트워크를 구축하고 있다고 한다.(영어)
Nvidia's plan to invest up to $100 billion in OpenAI has stalled, WSJ reports : NVIDIA가 OpenAI에 최대 1,000억 달러를 투자하기로 했던 계획이 내부에서 의문이 제기되어 중단되었다는 기사가 나왔다.(영어)
ClickHouse raises $400M Series D led by Dragoneer to accelerate expansion across analytics and AI infrastructure : Clickhouse가 4억 달러를 조달하면서 시리즈 D 투자 라운드를 마쳤다.(영어)

프로젝트

Claude Code Opus 4.5 Performance Tracker : SWE-Bench-Pro 벤치마크를 매일 실행해서 Claude Code Opus 4.5의 성능이 실제로 저하되는지를 감지하는 서비스.
Skills : AI 에이전트에서 재사용할 수 있는 Skills를 모아놓은 사이트.
QMD - Quick Markdown Search : Shopify CEO인 Tobias Lütke가 만든 마크다운 문서 로컬 검색 엔진.
Kthena : 스케쥴링 시스템을 만드는 Volcano에서 만든 Kubernetes 네이티브 AI 서빙 플랫폼.
Langfuse : Clickhouse가 인수한 오픈소스 LLM 엔지니어링 플랫폼.
playwright-cli : Playwright를 위한 공식 CLI.
iconify : 아이콘 세트.

버전 업데이트

jQuery v4.0.0 : JavaScript 라이브러리, 릴리스 공지
- IE 10 이하 지원 중단.
- Tursted Type 지원으로 CSP require-trusted-types-for를 위반하지 않음.
- AMD에서 ES modules로 마이그레이션 됨.
- 브라우저에서 네이티브로 지원하는 많은 API를 제거하여 IE 지원 중단과 함께 gzip 크기가 3k 이상 줄어듦.
Mastra v1.0 : TypeScript AI 에이전트 프레임워크, 릴리스 공지
Wine v11.0 : Windows API 호환 라이브러리, 릴리스 공지
Electron v40.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
Rspress v2.0 : 정적 사이트 생성기, 릴리스 공지
Zed v0.220.3 : 코드 에디터, 릴리스 공지
Node.js v25.5.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Nuxt.js v4.3.0 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
Grafana Tempo v2.10.0 : 분산 트레이싱 백엔드, 릴리스 공지
astro v5.17 : JavaScript 웹 프레임워크, 릴리스 공지
container 0.8.0 : Apple이 만든 macOS에서 Linux 컨테이너를 실행하는 도구, 릴리스 공지
Oxlint v1.42.0 : JavaScript/TypeScript Linter, 릴리스 공지
Oxfmt v0.27.0 : JavaScript/TypeScript 포매터, 릴리스 공지
Falco 0.43.0 : 클라우드 네이티브 런타임 보안, 릴리스 공지

기술 뉴스 #286 : 26-01-16

2026-01-16T03:39:27+09:00

웹개발 관련

React Conf 2025 : React Conf 2025의 발표 영상이 공개되었다.(영어)
State of HTML 2025 : HTML 생태계의 상황을 3천여 명에게 설문 조사해서 정리한 결과이다. From, 그래픽, 콘텐츠, 상호작용, 성능, 웹 컴포넌트, 접근성 등 각 기능의 사용 여부와 알려진 정도를 살펴볼 수 있다.(영어)
JavaScript Frameworks - Heading into 2026 : 2023년부터 자바스크립트 프레임워크의 동향을 연속해서 작성하는 글이다. AI의 발전으로 인해 AI가 중심이 되었고, AI의 경우 가장 큰 학습 세트가 있는 React가 마지막 프레임워크라는 주장이 있지만 모든 것은 변해가고 있어서 다른 프레임워크로도 AI는 잘 작성하며 Remix 3는 AI로 작성된 최초의 프레임워크가 될 것이라고 얘기한다. Islands, React Server Components, Tanstack Start, SvelteKit, SolidStart에서 동형 우선 아키텍처가 발전하고 있으면 비동기 우선 프레임워크도 발전할 것으로 보고 있다.(영어)
Introducing the <geolocation> HTML element : 위치 흐름은 그동안은 Geolocation API에 의존했는데 권한 문제로 사용자 경험을 해치는 문제가 있었는데 Chrome 144부터는 <geolocation>를 지원해서 사용자로부터 트리거 되어 사용자 경험이 훨씬 좋아졌고 구현도 쉬워졌다.(영어)

그 밖의 개발 관련

Claude Code On-The-Go : Vultr VM에 Tailscale을 연결하고 스마트폰에서 Termius와 Mosh로 접속해서 Claude Code 에이전트 6개를 동시에 돌리는 방법을 설명한다.(영어)
Lots of people have asked how I use Claude Code, so I wanted to show off my setup a bit. : Claude Code를 만드는 Boris Cherny가 트위터에서 자신이 사용하는 설정을 설명했다. 터미널 탭에 번호를 붙여서 5개를 동시에 실행하며 웹에서도 5~10개의 Claude를 운영하고 있다. Opus 4.5만 사용하고 팀에서는 단일 저장소에 CLAUDE.md를 공유하고 코드 리뷰 시 @claude를 태그해서 CLAUDE.md에 내용을 추가하고 대부분은 Plan 모드를 사용한다. 하루에 여러 번 하는 워크플로우는 슬래시 명령어를 사용하며 몇 개의 서브 에이전트를 사용하고 코드 포매팅은 PostToolUse 훅을 사용한다. 안전한 명령어만 등록해서 사용하면 모든 도구를 Claude Code가 직접 사용하도록 한다.(영어)
My LLM coding workflow going into 2026 : Google Cloud AI의 Addy Osmani가 자신이 사용하는 에이전틱 코딩 방식을 설명한 글이다. LLM으로 코딩할 때는 AI와 함께 상세한 스펙을 만들고 계획을 세운 뒤에 실제 코드를 작성하는 것이며 이 결정 사항을 spec.md로 정의한다. 그리고 AI가 다룰 수 있는 단위로 작업을 나누어서 작업을 시키고 AI가 알아야 할 모든 것을 정리해서 광범위하게 알려줘야 하는데 gitingest나 repo2txt를 활용할 수 있다. Claude Skills는 더 유용한 작업을 시킬 수 있으며 모델마다 고유한 개성이 있으므로 모델 바꾸는 것을 두려워하지 말고 가능하다면 최신 프로 모델을 사용하는 것이 좋다. 그리고 AI가 작성한 코드는 직접 검토하고 테스트하면서 품질에 대한 책임을 져야 하고 자주 커밋해서 버전 관리를 안전망으로 활용하라고 하고 있다.(영어)
Gemini CLI Tips and Tricks : Gemini 2.5, 3.0으로 에이전틱 코딩을 하는 팁 30가지를 정리한 글로 Gemini를 사용해 볼 생각이면 참고해 볼만하다.(영어)

인프라 관련

Your AI SRE needs better observability, not bigger models. : ClickHouse를 홍보하는 글이지만 AI SRE가 잘 동작하려면 무엇이 필요한지를 정리한 글이다. 기존 AI SRE 도구들은 기존 옵저버빌리티 플랫폼 위에 얇게 씌운 레이어에 불과하므로 데이터가 오래 보관되어 있지 않고 커디널리티 문제로 이벤트 간 연결할 수 있는 필드가 별로 없으며 쿼리 속도도 높지 않으며 너무 많은 쿼리를 하면 비용도 크게 나오게 된다. ClickHouse는 이 스토리지 비용, 높은 카디널리티 성능, 쿼리 지연 문제를 해결해서 AI SRE가 엔지니어를 도와주는 역할을 잘할 수 있게 구성할 수 있다고 설명한다.(영어)
IPv6 just turned 30 and still hasn’t taken over the world, but don't call it a failure : IP 주소 부족 문제를 해결하기 위해 1995년 IPv4의 첫 RFC가 나와서 IP 주소를 32비트에서 128비트로 전환할 수 있게 했지만, 현재 절반도 IPv6를 사용하고 있지 않다. IPv6는 IPv4와 호환되지 않으며 새로운 기능을 추가하지 않았기 때문에 채택이 많이 되지 않았고, NAT로 수천대의 장치가 하나의 IPv4 주소를 공유하면서 IP 주소 문제도 큰 문제가 되지 않았다. 반면 IPv6 쪽에서는 미래를 위한 준비이고 IPv6가 일부 성장 압력을 해소했기 때문에 IPv4가 생존할 수 있던 것이므로 실패라고 보기는 어렵다고 얘기한다.(영어)

AI 관련

The State Of LLMs 2025: Progress, Problems, and Predictions : LLM 리서치 엔지니어인 Sebastian Raschka가 2025년 LLM의 발전 과정을 돌아보고 앞으로의 변화를 예측한 글이다.(영어)
- 2025년은 추론과 RLVR(Reinforcement Learning with Verifiable Rewards), GRPO의 해였는데 DeepSeek R1이 여러 면에서 큰 관심을 모았고 이 논문에서 GRPO를 활용해서 RLVR이 LLM 개선에 사용될 수 있다는 점이 관심을 모았고 RLVR은 내년에도 많은 관심을 끌 것으로 보인다.
- LLM 아키텍처에도 많은 시도들이 있지만 몇 년 동안은 트랜스포머 아키텍처를 계속 사용할 것이고 효율성과 엔지니어링 개선이 더 많이 이루어질 것이다.
- 스케일링만으로는 효과가 많이 안 나타나기 시작했고 학습 파이프라인과 추론 확장에서 더 많은 발전이 있었고 도구 사용을 염두에 두고 LLM을 훈련하면서 큰 개선이 이루어졌다.
- 또 하나의 트렌드는 benchmaxxing인데 벤치마크 성능 자체를 목표로 해서 높은 점수를 받았음에도 실제에서는 성능이 나오지 않게 되는 현상을 말한다. 이는 LLM은 벤치마크에서 좋은 점수를 필수로 받아야 하지만 좋은 점수를 받았다고 좋은 LLM은 아니라는 의미가 된다.
- 코딩에 LLM을 사용하는 경우가 많아졌지만 언제 LLM을 쓰고 언제 안 쓸지 인지하는 게 중요하며 여전히 전문가가 만든 코드를 대체하진 못하고, 이는 기술 문서에서도 마찬가지다. AI를 잘 사용해서 학습을 가속화하고 한 사람이 감당할 수 있는 범위를 확장할 수 있으므로 이를 대체물이 아니라 파트너로 생각해야 한다.
- 독점적인 데이터를 팔지 않는 분위기가 많아지고 있고 시간이 가면서 사내 LLM을 더 많이 만들게 될 것이다.
Opus 4.5 is going to change everything : Claude Opus 4.5를 사용해 보고 나서 AI 코딩 에이전트가 개발자를 대체할 수 있다고 생각이 바뀌었다며 자신의 경험을 정리한 글이다. Opus 4.5로 이미지 파일을 빠르게 변환할 수 있는 Windows 유틸리티, GIF 녹화 유틸리티를 만들고 아내의 사업을 돕는 앱을 어떻게 만들었는지를 설명한다.(영어)
Cowork: Claude Code for the rest of your work : Anthrophic이 Claude Code의 성공으로 개발자뿐만 아니라 누구나 Claude를 비슷하게 사용할 수 있도록 Cowork을 개발했다. Cowork는 코딩이 아닌 작업을 Claude Code처럼 잘 수행할 수 있다.(영어)
AI 에이전트를 위한 평가(evals) 쉽게 이해하기 : Anthropic의 Demystifying evals for AI agents의 번역 글이다. AI 에이전트의 평가는 필수적인데 단일 턴 평가를 주로 사용했지만, AI 역량이 높아지면서 멀티 턴 평가가 보편적으로 되고 있다. AI 에이전트를 출시하고 사용자로부터 성능이 안 좋아졌다는 피드백이 왔을 때 이를 검증하기 위해 평가를 사용하고 코드 기반, 모델 기반, 사람의 3가지 채점기를 결합해서 사용하는 데 여러 에이전트의 타입과 문제 상황에 따라 어떻게 평가하는 게 좋은지 그동안의 고민 방법이 정리되어 있다.(영어)
ChatGPT Health를 소개합니다 : OpenAI에서 개인의 건강 상태를 이해하고 관리할 수 있게 돕는 ChatGPT Health를 공개했다. 이미 ChatGPT에서 건강에 관한 질문을 많이 하는데 ChatGPT Health는 개인정보 보호와 보안을 강력하게 적용해서 자신의 건강 정보를 바탕으로 대화를 진행할 수 있다. 현재는 클로즈 베타이지만 곧 모든 사용자가 사용할 수 있게 될 예정이며 전자 의료 기록, Apple Health, Function, MyFitnessPal 같은 앱과 연동해서 사용할 수 있다.(한국어)

볼만한 링크

Don't fall into the anti-AI hype : Redis를 만든 antirez가 코딩을 워낙 좋아했고, AI의 성공을 바라지도 않았지만 실제로 해보니 AI가 프로그래밍을 영원히 바꿀 것이라고 얘기한다. 그동안 AI로 많은 작업을 했고, 본인의 의견에 상관없이 프로그래밍은 이미 바뀌었고 그동안 시간이 없어서 못 했던 오픈소스를 너무 하고 싶고 작성한 코드가 LLM에 흡수된 것이 오히려 기쁘다고 얘기한다.(영어)
The Next Two Years of Software Engineering : Google Cloud AI의 Addy Osmani가 AI 코딩으로 변해가는 생태계에 대하 5가지 질문에 대한 상반된 시나리오를 소개하면서 예측이라기보다는 준비하기 위한 글이라고 설명한다.(영어)
- AI가 초급 업무를 대체하며 주니어를 채용이 붕괴할 수 있다. 이에 따라 시니어로 성장하는 경로가 흔들리고 있고 이러한 추세는 가속화되고 있지만 반대 시나리오에서는 AI로 막대한 개발자 수요가 열리고 미국 노동 통계국도 34년까지 일자리가 15% 증가할 것으로 보고 있는데 주니어가 성장하지 못하면 수년 내에 리더십 공백이 생길 것이다.
- AI로 프로그래밍 역량이 퇴화할 수도 있고 인간이 감독에 집중하면서 더 중요해질 수도 있다. 개발자의 84%가 AI를 사용하면서 프로그래밍 역량 저하를 우려하기도 하지만 일상의 80%는 AI가 하고 인간은 어려운 20%에 집중하면서 인간의 전문성이 더 중요하게될 수 있다.
- 개발자의 역할이 AI 생성 코드 감소로 축소될 수도 있고 AI 기반 시스템을 설계하고 관리하는 핵심 조정자로 확장될 수도 있다. 비관적 시나리오에서는 개발자의 창의적인 책임이 축소되고 AI 산출물을 감시하는 역할이 될 수 있다고 걱정하지만, 반대 시나리오에서는 AI가 기계적인 작업을 처리하고 개발자는 더 가치 있는 활동으로 이동해서 일자리가 더 흥미로워질 수 있다.
- 좁은 전문 분야는 해당 분야가 자동화되거나 구식이 될 위험이 있고 AI가 빠르게 변화하는 환경에서는 T자형 엔지니어가 기회를 얻을 수 있다.
- 컴퓨터과학 학위가 여전히 필요할까 아니면 부트캠프나 교육 플랫폼이 더 효과적으로 될 것인가? 기존에는 컴퓨터과학 학위가 주요 입구였지만 AI로 인해 더 빨라진 변화로 인해 직장에서 필요한 기술을 대학에서 충분히 배우지 못하고 있고 부트캠프나 고용주 주도 교육 등이 개선되고 성장하고 있으며 비용도 훨씬 싸다.
A website to destroy all websites. : 인터넷에서 생산적인 시간을 보내기보다는 낭비하는 시간이 많아진 상황을 비판하면서 사회 비평가 Ivan Illich의 의견을 소개하면서 기술이나 도구가 처음엔 사회를 위해 만들어지지만 산업화되고 나면 도구의 요구사항에 맞추기 위해 사회가 움직이게 되고 그렇지 않으면 사회에서 배제되는 느낌을 주는 문제를 지적하고 이게 웹에서도 일어나고 있다고 얘기한다. 이를 해소하기 위해 개인 웹사이트를 만들어서 운영하라고 얘기한다.(영어)

IT 업계 뉴스

Creators of Tailwind laid off 75% of their engineering team : Tailwind CSS 저장소에 llms.txt를 추가해서 AI가 더 쉽게 사용하고자 하는 Pull Request를 머지되지 않는데 이슈를 제기하자 Tailwind는 수익성 문제로 받을 수 없다면 PR을 닫았다. Tailwind는 최근 AI로 인해 Tailwind의 인기는 높아졌지만, 트래픽은 줄어들고 수익성이 떨어졌기에 결국 엔지니어링 팀의 75%를 해고하고 매출은 80% 감소했다고 밝혔다. 이 소식이 알려지자 Google AI Studio와 Gumroad, Supabase, Syntax와 Sentry등이 후원을 시작했다.(영어)
Anthropic blocks third-party use of Claude Code subscriptions : Anthropic이 opencode 등 서드파티 프로그램에서 Claude Code 구독을 사용하는 것을 차단했다.(영어)
An Instagram data breach reportedly exposed the personal info of 17.5 million users : Instagram에서 1,750만 명의 사용자명, 주소, 전화번호, 이메일주소가 유출되었다. 이번 유출로 사용자들은 비밀번호 재설정 요청 이메일을 받은 것으로 알려졌다.(영어)
Stack Overflow’s forum is dead thanks to AI, but the company’s still kicking... thanks to AI : 오랫동안 개발자에게 인기 있던 Stack Overflow는 AI의 등장으로 트래픽이 급감해서 지난달에는 질문이 6,866개만 올라와서 2008년과 비슷한 수준이 되었다. Q&A는 죽은 것처럼 보이지만 기존에 쌓인 데이터를 바탕으로 Stack Internal이라는 엔터프라이즈 솔루션을 25,000개 기업에 판매해서 매출은 두 배가 증가한 1억 1,500만 달러를 기록했다.(영어)
Using alternative browser engines in Japan : iOS 26.2부터 일본 사용자는 Webkit 외의 브라우저를 전용 브라우저와 앱 내 브라우저에서 선택해서 사용할 수 있게 되었다.(영어)

프로젝트

opencode : 오픈 모델뿐 아니라 유료 구독 모델도 같이 사용할 수 있는 오픈소스 AI 코딩 에이전트.
Fizzy : 37signals에서 만든 칸반보드 서비스.
Kindle SmartHome Dashboard : Kindle 이북 리더를 스마트홈 대시보드로 만드는 프로젝트.
Open Infrastructure Map : 오픈스트리트맵에 전력, 수도, 오일, 통신 등 전 세계 인프라를 보여주는 사이트.
Copilot CLI SDKs : GitHub Copilot CLI에 프로그래밍으로 접근할 수 있는 SDK.

버전 업데이트

LogTape v2.0.0 : JavaScript 로깅 라이브러리, 릴리스 공지
Zed v0.218.6 : 코드 에디터, 릴리스 공지
Omarchy v3.3.0 : DHH가 만든 Arch Linux의 Hyprland 설정, 릴리스 공지
Optique v0.9.0 : TypeScript용 타입세이프 CLI 파서, 릴리스 공지
Codex CLI v0.80.0 : 코딩 에이전트, 릴리스 공지
ClickHouse v25.12 : 컬럼형 데이터베이스, 릴리스 공지
Node.js v22.22.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.13.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Node.js v20.20.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Prettier v3.8.0 : JavaScript/TypeScript 포매터. 릴리스 공지
ReScript v12.1.0 : 프로그래밍 언어(구 BuckleScript/Reason), 릴리스 공지

기술 뉴스 #285 : 26-01-01

2026-01-01T22:59:11+09:00

웹개발 관련

Introducing RSC Explorer : 최근 RSC 취약점이 공개되면서 RSC에 대한 관심이 쏠리자, Dan Abramov가 RSC가 어떻게 동작하는지 이해하는 데 도움이 되는 RSC Explorer를 만들어서 공개했다. RSC Explorer에서는 서버와 클라이언트 코드를 입력하고 실행하면 단계별로 생성되는 RSC 스트림과 렌더링 되는 HTML을 비교하면서 볼 수 있다.(영어)
LCP and INP are now Baseline Newly available : Web Vitals의 LCP와 INP가 그동안 크로미움 계열의 브라우저에서만 지원되었지만, 지난 12월 12일 Safari 26.2부터 LCP API와 Event Timing API를 지원하면서 WebKit 기반에서도 사용할 수 있게 되었다. 이는 Interop 2025 프로젝트에 포함되어 진행된 작업으로 CLS는 아직 지원되지 않는다.(영어
Introducing CSS Grid Lanes : Masonry 레이아웃을 CSS로 만들 수 있는 CSS Grid Lanes의 동작 방식을 설명한다. 보통 Pinterest UI로 유명한 Masonry 레이아웃을 쉽게 만들 수 있으면 grid-template-*를 사용해서 각 레인을 크기를 정할 수 있고 레인 간의 교차하거나 아이템 배열의 방향도 지정할 수 있다.(영어)
Throttle individual network requests : Chrome 144부터는 Chrome 개발자 도구에서 개별 요청에 대한 스로틀링 제어 기능이 추가된다. 기존에는 네트워크 전체에 대해서 스로틀링 할 수 있었지만, 이제는 특정 도메인이나 URL 별로 속도를 느리게 하거나 차단할 수 있게 된다.(영어))
How to prompt v0 : Vercel의 AI를 이용한 UI 생성 서비스인 v0의 사용자 사용 패턴을 분석한 결과 좋은 프롬프트에는 제품 표면, 사용 맥락, 제약 조건과 취향이 항상 포함되고 이럴 경우 생성 속도도 빨라지고 더 좋은 UX와 코드가 나온다고 한다. 이 프롬프트의 예시와 사용 방법을 설명한다.(영어)
Please Just Fucking Try HTMX : HTMX를 한번 써보라고 설득하는 글이다. 그냥 HTML을 쓰거나 React를 쓰는 방법이 있지만 세 번째 선택지인 HTMX가 있으므로 HTMX가 더 어울리는 곳에서는 HTMX가 괜찮은 대안이 될 수 있다고 설명한다.(영어)
Introducing Flint : ESLint가 업계를 선도하고 있고 Biome와 Oxlint가 네이티브 속도로 여기에 도전장을 내미는 가운데 가설을 검증하기 위한 실험적인 새로운 린터가 공개되었다. FLint는 TypeScript로 만들어졌지만, 언어별 플러그인을 사용한 하이브리드 접근을 사용하고 있고 간소화된 자바스크립트 구성 시스템을 지원하며 플러그인으로 상세한 규칙을 제공하고 다른 도구들과 통합할 수 있게 지원할 계획이다.(영어)
jax-js: an ML library for the web : Google DeepMind의 JAX 프레임워크를 자바스크립트로 재구현해서 WebGPU와 Wasm으로 브라우저에서 실행할 수 있는 jax-js를 소개하는 글이다.(영어)

그 밖의 개발 관련

GPT-5.2-Codex 소개 : OpenAI에서 GPT-5.2 기반으로 한 에이전트형 코딩 모델 GPT‑5.2-Codex를 공개했다. GPT‑5.2-Codex는 기존 모델보다 강력한 사이버 보안 역량을 갖추고 있으며 장기간 작업 역량도 개선되었다.(한국어)
How we pwned X (Twitter), Vercel, Cursor, Discord, and hundreds of companies through a supply-chain attack : 16살인 Daniel이 AI 문서 플랫폼인 Mintlify의 치명적인 취약점을 발견한 과정을 정리한 글이다. Discord가 개발자 문서 플랫폼은 Mintlify로 바꾸었고, Daniel은 수년간 Discord의 취약점을 많이 찾아왔기에 Mintlify에서 취약점을 찾기 시작했고 여러 번의 시도 끝에 SVG 파일을 통해서 XSS가 가능하다는 것을 발견했다. 이를 친구들과 공유했고, 친구들도 Mintlify를 조사 중에 여러 취약점을 찾고 있었기에 이 취약점은 Discord에 신고하고 Discord는 Mintlify 문서 사이트를 닫고 Mintilfy도 취약점 해결에 참여해서 이를 수정했다고 한다. 이 취약점은 Discord뿐 아니라 X, Vercel, Cursor 등에 영향을 끼쳤다.(영어)
LLM을 이용한 서비스 취약점 분석 자동화 #1 : Toss에서 취약점 분석을 LLM으로 자동화한 과정이다. 모든 소스코드를 다 읽게 할 수는 없으니, MCP를 이용해서 인덱싱된 코드를 효율적으로 참조하게 만들고 정확도를 높이기 위해 Semgrep을 사용해서 입력이 들어와서 함수로 연결되는 경로를 수집한 뒤 분석하게 했다. 동작은 잘했지만, 비용이 너무 높아서 멀티 에이전트로 효율화하고 Open Model을 사용해서 비용 효율적으로 만들어서 정확도 95% 이상의 취약점 분석 자동화를 구현했다고 한다.(한국어)
ty: An extremely fast Python type checker and LSP : uv, Ruff를 만드는 Astral가 자사의 툴체인에 Rust로 작성한 Python 타입 체커이면서 랭귀지 서버인 ty의 베타 버전을 추가했다. ty는 Pyrefly, Pyright, mypy에 비해 훨씬 빠른 속도를 보여주며 랭귀지 서버를 사용하므로 변경된 부분만 선택적으로 재실행할 수 있으며 오류 메시지도 훨씬 명확하게 알려준다.(영어)
18% Faster Compiles, 0% Compromises : Android Runtime(ART) 팀은 컴파일 코드나 최대 메모리 회귀를 해치지 않으면서도 컴파일 시간을 18% 단축했다. 이는 성능을 ppof로 미리 측정한 이후 시간이 오래 걸리는 Global Value Numbering(GVN) 단계를 최적화하고 불필요한 HashSet을 줄이고 복사를 줄이거나 값을 캐싱하는 등 많은 최적화 작업을 진행한 결과이다. 최적화 작업을 가치가 있는지 판단하기 쉽지 않은데 지표로 추정한 것인지 확인하고 빠르게 프로토타입을 만든 후 해결책을 실행하라고 조언하고 있다.(영어)
Critical n8n Flaw (CVSS 9.9) Enables Arbitrary Code Execution Across Thousands of Instances : n8n 워크플로 자동화 프로젝트에서 10점 만점의 CVSS 점수 9.9를 받은 CVE-2025-68613 취약점이 발견되었다. 이 취약점은 임의의 코드를 공격자가 실행할 수 있는 취약점이다.(영어)

인프라 관련

A Safer Container Ecosystem with Docker: Free Docker Hardened Images : 지난 5월 Docker에서 출시한 Docker Hardened Images(DHI)를 출시했는데 이를 Apache 2.0 라이센스 기반으로 누구나 사용할 수 있도록 공개했다. DHI는 distroless 런타임을 사용해서 공격 표면을 줄이면서도 SBOM을 제공해서 완전히 검증할 수 있으며 Alpine, Debian과 호환되어 쉽게 채택할 수 있다. DHI는 무료로 사용할 수 있고 상업용 서비스인 DHI 엔터프라이즈를 사용하면 핵심 CVE 패치를 7일 이내에 제공하며 Docker의 빌드 인프라로 생명주기를 관리할 수 있다.
Logging sucks : 현재 로깅의 문제점을 지적하는 웹사이트이다. 직접 테스트해 볼 수 있는 플레이 그라운드와 함께 현재 대부분이 사용하는 로깅은 작성에 최적화되어 있어서 문제가 생겼을 때 맥락을 찾기가 어렵기 때문에 하나의 와이드(wide) 이벤트로 모든 정보를 다 포함해서 남겨야 한다고 설명한다. 이렇게 하면 아주 쉽게 쿼리할 수 있고 테일 샘플링을 하면 비용 문제도 해결할 수 있다고 얘기한다.(영어)
Zero trust network access : 경계 보호를 하는 VPN 대신 Cloudfare의 Zero Trust Network를 사용하면 요청별, 앱별 접근 제어를 할 수 있으므로 폭발 반경이 줄어들고 제어력도 높아지는데 간단한 설명과 시각화 자료로 ZTNA가 무엇인지를 설명하는 글이다.(영어)
Pricing changes for GitHub Actions : GitHub이 Actions의 GitHub-hosted 러너 비용을 26년 1월 1일부터 최대 39%까지 인하하고 3월 1일부터는 self-hosted에도 분당 $0.002의 플랫폼 요금을 도입하겠다고 발표했다가 사용자들의 반대로 인해서 self-hosted에 부과한 플랫폼 요금은 연기하기로 발표했다.(영어)
New MongoDB Flaw Lets Unauthenticated Attackers Read Uninitialized Memory : MongoDB에서 인증되지 않은 사용자가 힙 메모리를 읽을 수 있는 높은 심각도의 취약점 CVE-2025-14847(CVSS 점수: 8.7)이 발견되었다.(영어)

AI 관련

State of AI: An Empirical 100 Trillion Token Study with OpenRouter : LLM 통합 API 플랫폼인 OpenRouter에서 지난 1년간 100조 개가 넘는 토큰을 분석한 연구 결과다. 이 연구 결과에서는 LLM을 사람들이 어떻게 사용하는지, 지난 1년간 어떤 변화가 있었는지를 보여준다.(영어)
- 개방형 모델과 독점 모델이 오픈 모델보다 많이 사용되지만, 중국이 개발한 새로운 오픈 모델이 나올 때마다 일정 부분 사용량을 의미 있게 유지되고 있어서 상호보완적으로 30%의 사용량을 유지하고 있다.
- DeepSeek가 개방형 모델 중 가장 많이 사용되지만, 새로운 모델의 등장으로 DeepSeek의 점유율은 줄어들어 6개 정도의 모델이 점유율을 유지하고 있다.
- 새로운 개방형 모델은 등장하자마자 몇 주 내에 상당한 사용량을 확보하고 있다.
- 작년에는 개방형 모델이 작고 빠른 모델과 대규모 모델로 나뉘어졌지만, 올해 시장이 성장하면서 중형 모델이 자리잡기 시작했다.
- 개방형 모델의 사용 목적은 스토리텔링, 캐릭터 롤플레이, 게임 시나리오 등의 상호작용 대화를 하는 롤플레이가 52%이고 프로그래밍이 그다음으로 많이 사용된다.
- 올해는 추론 모델의 사용 비중이 급격히 증가해서 이제는 50%를 넘어섰다.
- 모델을 사용할 때 평균 프롬프트는 1500에서 6000 이상으로 약 4배로 증가했고 완료 토큰은 150에서 3배 가까이 증가했다.
- 작업 복잡도와 상호작용의 깊이를 의미하는 시퀀스 길이는 지난 20개월 동안 2,000개 미만에서 5,400개 이상으로 3배 이상 증가했다.
- 모든 모델에서 프로그래밍은 꾸준히 성장해서 25년 초에는 11%를 차지했지만, 최근에는 50%를 넘어섰다.
- 프로그래밍에서는 Anthropic이 60% 이상을 차지하면 꾸준히 지배적인 위치를 차지했다.
- 모델별 카테고리를 봤을 때는 Anthropic은 프로그래밍이 60% 이상이고 Google은 롤플레이가 약 30%, 프로그래밍이 20% 정도이고 xAI는 프로그래밍이 70% 이상, OpenAI는 과학 목적이 20% 정도, 프로그래밍이 30% 정도를 차지했다.
- 사용자 리텐션 분석에서는 높은 이탈률과 급속한 코호트 감소를 보여주는데 기존 모델에서 해결되지 않은 고부가가치 작업이 남아있고 새로운 모델이 나오면 이 해결되지 못했던 문제에 시험하고 그 결과가 충족될 때 강력한 락인 효과를 보여주는데 이를 "신데렐라 유리 구두 효과"라고 명명했다.
- 사용량과 비용 분석에서는 100만 토큰당 중윗값이 $0.73이었고 이를 기준으로 기술과 과학 분야는 고사용률, 고비용이고 프로그래밍, 롤플레이, 과학은 고사용률, 중간 비용이며 금융, 학계, 건강, 마케팅은 저사용, 고비용이며 번역이나 법률 등은 저사용, 저비용으로 구분된다.
Gemini 3 Flash: frontier intelligence built for speed : Google에서 저렴한 비용과 빠른 속도로 최첨단 AI를 제공할 수 있는 Gemini 3 Flash를 공개했다. Gemini 3 Flash는 2.5 Pro보다 성능이 뛰어나면서도 비용이 훨씬 저렴하다.(영어)
새로운 ChatGPT Images가 출시되었습니다. : OpenAI에서 이미지 생성 모델 ChatGPT Images의 새 버전을 출시했다.(한국어)
Introducing Mistral OCR 3 : 다양한 문서에서 텍스트와 이미지를 추출할 수 있고 마크다운 출력도 개선된 MIstral OCR 3가 출시되었다. 1,000 페이지당 2달러로 다른 경쟁 솔루션보다 저렴하며 필기체, 양식 등 복잡한 문서도 잘 처리할 수 있다.(영어)
Qwen-Image-Layered: Layered Decomposition for Inherent Editablity : Alibaba에서 이미지를 여러 RGBA 레이어로 분리할 수 있는 Qwen-Image-Layered 모델을 공개했다. 분리한 레이어를 개별로 편집한 뒤에 다시 합칠 수 있어서 훨씬 다채로운 편집이 가능하다.(영어)
GitHub Copilot now supports Agent Skills : GitHub Copilot이 특정 작업을 수행하는 방법을 알려주는 Agent Skills를 지원한다.(영어)
OpenAI Codex Agent Skills : OpenAI의 Codex가 Agent Skills 표준을 따르는 Skills를 공식 지원한다.(영어)
Gemma Scope 2: helping the AI safety community deepen understanding of complex language model behavior : LLM의 내부 작동 원리를 이해하기 위해 만든 Gemma Scope의 새로운 버전인 Gemma Scope 2를 출시했다. Gemma Scope 2는 270M부터 27B의 Gemma 3 모델을 해석할 수 있는 툴킷으로 모델의 잠재적인 위험을 추적할 수 있다.(영어)
Introducing Bloom: an open source tool for automated behavioral evaluations : Anthrophic에서 AI 모델의 행동 평가를 자동으로 할 수 있는 에이전트 프레임워크인 Bloom을 오픈소스로 공개했다. 지정한 행동을 Bloom이 자동으로 시나리오를 만들어서 그 발생 빈도와 심각도를 평가한다.(영어)

볼만한 링크

I've never felt this much behind as a programmer. : OpenAI의 창립 멤버였기도 하면서 Tesla에서 AI 디렉터를 했고 Vibe Coding이라는 말도 만든 Andrej Karpathy가 "프로그래머로서 이렇게 뒤처졌다고 느낀 적은 처음"이라는 트윗을 올렸다. 프로그래머라는 직업이 재구성되고 있는 상황에서 지난 1년간 얻은 걸 잘 사용하면 10배는 강력해질 것 같지만 그걸 제대로 활용 못 하는게 실력 문제라고 느껴진다고 얘기했다.(영어)
A Year Of Vibes : Armin Ronacher가 바이브 코딩을 하면서 보낸 올 한 해를 회고하는 글이다. 코딩 Agent와 TUI가 아주 강력해졌고 이 영향력이 더 커질 것이지만 아직 이 머신들과의 관계를 정의하는 데는 고민이 많고 1년도 안 된 시간 동안 많은 것을 바꾸고 있기 때문에 다양한 의견이 넘치고 있다. AI의 발전으로 기존 코드 공유 도구가 한계에 도달했다고 느끼고 있는데 이러한 도구들이 AI와의 협업 문제를 제대로 풀지 못하고 있으며 이는 코드 리뷰에서도 AI에게 가이드하거나 프롬프트를 참고하고 싶은데 그런 부분에서는 여전히 부족하다고 느낀다.(영어)
Making Google Sans Flex : Google이 2015년 로고를 다시 디자인하면서 Product Sans 폰트를 만들었지만, 이 폰트는 휴대폰이나 태블릿 등에 최적은 아니었기에 Google Sans를 만들었다. 하지만 더 작은 크기에서 동작하도록 Google Sans Text를 만들고 비라틴 문자를 지원할 수 있게 개선하고 Google Sans Mono도 코드 가독성이 좋지 못해서 Google Sans Code를 만들었다. 여기에 더 유연한 폰트를 위해 가변 폰트를 도입한 Google Sans Flex까지 만들게 되었다. 그리고 이 Google Sans와 Google Sans Flex를 오픈소스로 공개하기로 했다.(영어)
Backing up Spotify : Anna's Archive에서 Spotify의 메타데이터와 음악 파일이 포함된 약 300TB의 아카이브 파일을 공개했다. 이 아카이브에는 8,600만 개의 음악 파일이 포함되어 있고 Spotify를 대규모로 스크래핑해서 만들었다.(영어)

IT 업계 뉴스

Graphite is joining Cursor : Stacked PR을 중심으로 한 코드 리뷰 플랫폼인 Graphite를 AI 코드 에디터인 Cursor가 인수했다.(영어)
Coursera and Udemy enter a merger agreement valued at around $2.5B : 온라인 강의 플랫폼인 Coursera가 주식 거래를 통해 Udemy와 25억 달러 규모로 합병하겠다고 발표했다.(영어)
PayPal applies to form bank that can offer small business loans and savings accounts : PayPal이 소규모 사업체에 대출할 수 있는 은행 설립을 신청했다.(영어)
Mozilla’s next chapter: Building the world’s most trusted software company : Mozilla Corporation이 Laura Chambers의 임시 CEO 체제를 끝내고 Anthony Enzor-DeMeo를 새 CEO로 임명했다. 2004년부터 Firefox에서 일한 Anthony Enzor-DeMeo는 CEO가 되면서 AI 시대에 사용자에게 신뢰받을 수 있는 AI 브라우저가 될 것이고 검색 이상의 수익 다각화를 할 것이라고 선언했다.(영어)
Manus Joins Meta: Accelerating AI Innovation for Businesses : Meta가 AI 에이전트를 만드는 Manus를 인수하기로 했다.(영어)

프로젝트

Claude Code in Action : Anthropic이 제공하는 Clade Code 온라인 강의.
google/mcp : Google의 공식 MCP를 모아놓은 저장소.
A2UI: Agent-to-User Interface : AI 에이전트가 임의의 코드 없이도 웹, 모바일, 데스크톱의 UI를 생성할 수 있게 하는 Google이 만든 오픈소스 프로젝트.
Vertana : TypeScript용 LLM 기반 에이전트 번역 라이브러리.
CodexBar : Codex, Claude Code, Cursor, Gemini, Copiot의 사용량과 리밋을 볼 수 있는 macOS 메뉴바
RepoBar : GitHub 저장소의 상태를 볼 수 있는 macOS 메뉴바
witr (why-is-this-running) : 프로세스, 서비스, 포트가 왜 실행되어 있는지 보여주는 CLI 명령어.
Just Fucking Use Effect : TypeScript의 effect를 홍보하는 사이트.

버전 업데이트

Ruby v4.0.0 : 프로그래밍 언어, 릴리스 공지
- 프로세스 내에서 공간을 분리할 수 있는 실험적 기능 Ruby Box 지원
- YJIT의 차세대 모델인 ZJIT 지원
Kubernetes v1.35 Timbernetes(The World Tree Release) : 컨테이너 오케스트레이션 도구, 릴리스 공지
- Pod 리소스의 In-place 업데이트가 안정화됨
- cert-manager같은 외부 컨트롤러나 DRD 오케스트레이션 없이 팟에 인증서를 전달할 수 있는 Pod certiticates가 베타가 됨.
Next.js 16.1 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지
Nx v22.3.0 : 모노레포 빌드 시스템, 릴리스 공지
- Angular 21 지원
- esbuild가 기본 번들러
- Vitest가 기본 테스트 러너
Spring Shell 4.0.0 : Spring 기반 인터렉티브 쉘, 릴리스 공지
AXe v1.2.0 : Apple 접근성 API를 사용해서 iOS 시뮬레이터를 조작하는 CLI, 릴리스 공지
Prisma v7.2.0 : TypeScript/Node.js 데이터베이스 툴킷, 릴리스 공지
Kotlin v2.3.0 : JVM 기반의 프로그래밍 언어, 릴리스 공지
fish shell v4.3.0 : 쉘, 릴리스 공지
Color.js v0.6.0 : JavaScript 색상 변환 및 조작 라이브러리, 릴리스 공지
Lua 5.5.0 : 프로그래밍 언어, 변경사항
OpenSearch 3.4 : 분산형 검색 엔진, 릴리스 공지
Rspack v1.7.0 : 웹 번들러, 릴리스 공지
Qwen Code v0.6.0 : AI 에이전트, 릴리스 공지
Turborepo v2.7.0 : JavaScript/TypeScript 빌드 시스템, 릴리스 공지

2025년 회고

2025-12-31T23:42:14+09:00

코딩

작년과 마찬가지로 올해는 개인적으로는 나태함의 극치를 달리는 한 해였다. 체력이 엄청나게 떨어졌냐 하면 그것도 아닌데, 집에 오면 술을 먹거나 OTT를 보면서 쉬는 게 좋았다. 예전에는 집에 와서도 하고 싶은 개인 작업이 너무 많았었는데 요즘은 그런 게 많이 없어졌다. 이 패턴을 벗어나려면 의지를 가지고 좀 패턴을 바꿔봐야 할 것 같다.

중간중간 의지를 가지고 다시 생산적인 개인 시간을 보내려고 시도한 적도 있는데 난 이런 게 너무 극단적이라 적당한 균형을 유지하지 못하고 놀 때는 그냥 계속 노는 시간만 보내고 생산적으로 보내야지 하면 쉴 틈 없이 계속 뭔가 하다가 어느 순간 "아! 힘들다. 쉬자"하면서 무너져버리기 일쑤였다. 예전보다 열정이 떨어진걸까... 뭐가 달라졌을까 하는 생각을 하게 된다. 적정선의 생산성을 유지하는게 중요한데...

GitHub 컨트리뷰션 그래프만 봐도 예전에 비한다면 비교할 수 없을 정도로 형편없어졌다. 이제 이 스샷을 올리는 것도 민망하다.

누구나 올해를 회고할 때 AI 얘기를 빼놓을 수는 없을 거라고 생각한다. 작년 이맘때만 해도 GitHub Copiot의 탭 자동완성에 익숙해진 상태로 Cursor가 좋다더라 하는 소리를 듣는 중에 AI 코딩 얘기를 듣기 시작했었는데 올 초에 AI 코딩이 생각보다 좋다는 걸 깨닫고 놀란 뒤로 2~3달이 멀다고 새로운 모델이 나오고 Claude Code를 시작으로 CLI를 기반으로 한 AI와 함께하는 코딩이 발전하면서 지금은 이게 1년 사이에 달라진 일이라는 걸 믿을 수 없을 정도로 엄청 달라졌다.

그럼에도 난 아직 AI에 보수적인 태도을 계속 유지하고 있다. 여기에는 그래도 엔지니어로서 기반이 되는 기술에 대한 이해와 자신의 손을 거친 코드에 대한 책임을 져야 한다는 생각도 있지만 이런 보수적인 태도는 곰곰이 생각해 봤을 때 내 성격과 회사에서의 업무가 다 섞여 있는 거 같다.

예전을 돌아봤을 때 Docker가 나왔을 때나 Kubernetes를 나왔을 때나 계속 관심을 가지고 어느 정도 공부도 하면서도 이걸 어디다 쓰는 거지? Google도 아닌데 나도 쓸 때가 있나? 하는 생각을 많이 했었다. 그럼에도 지금 나는 Container는 당연히 기본이고 Kubernetes는 내 업무에서 빼고 얘기할 수 없을 정도로 그 중심이 되었다. 회사 업무할 때도 느끼지만 뭔가 새로운 걸 봤을 때 나는 약간 내가 완전히 이해할 수 있을 때까지 반대 관점에서 많은 질문을 하면서 의심의 눈초리로 바라보는 타입인 거 같다. 결과적으로 그것을 받아들이기도 하고 아니기도 한데 그런 과정이 나한테는 그 기술 혹은 정책을 이해하고 받아들이는 방식이란 걸 깨달았다. AI도 그런 면에서 비슷한 태도를 보이는 거 같지만, AI가 달라지는 상황 자체에 대한 트랜드는 놓치지 않으려고 하고 있다.

회사에서 SRE 팀에서 인프라를 담당하고 있기 때문에 어느 정도 보수적인 태도를 보일수밖에 없다. 사람마다 입장이 약간씩 다르고 이것마저도 AI의 발전에 따라 또 언제 달라질지 알 수 없지만 개인 프로젝트에서 AI의 효율성은 누구도 부정하지 않겠지만 실제 사용자에게 나가는 서비스에 대해서는 AI에게 온전히 맡기는 부분에는 아직은 보수적인 태도가 많을 것으로 생각한다. 서비스의 안정성을 책임져야 하는 인프라를 담당하고 있다 보니 그 부분에서 AI에 온전히 의존하는 데는 아직 회의적인 편이다.

이런 두 가지 입장이 합쳐지면서 보수적인 태도를 아직 유지하고 있다. 물론 나도 FOMO는 계속 있다. 세상이 너무 빨리 달라지고 있기 때문에 신중하다는 핑계로 실제로는 내가 여태 쌓아놓은 매몰 비용을 버리기 싫어서 부정하고 있는 건 아닐까 하는 걱정을 계속하고 있다. 지금도 이미 AI를 엄청 잘 쓰는 사람들이 있고 그렇지 않은 사람들과 격차가 벌어지고 있지만 여전히 아직 초기 단계라고 생각하기도 한다. 그런 면에서 이미 너무 늦었냐고 한다면 아직은 그렇지는 않다고 생각해서 빨리 따라가야겠다.(FOMO로 인한 합리화일지도 모른다.)

아이디어가 너무 많아서 오히려 사이드 프로젝트를 진행하지 못하던 예전과는 달리 요즘은 아이디어가 많지 않아서 사이드 프로젝트를 잘 진행 못 하고 있다. 아이디어가 전혀 없는 것은 아니기 때문에 내년에는 AI로 코딩하는 걸 많이 연습해서 익숙해져야겠다는 생각하고 있다. 충분이라는 말이 어색할 정도로 AI의 성능이 올라왔고, 이제는 더 뒤처지지 않고 따라가 봐야 할 때라고 생각하고 이걸 따라가려면 직접 손을 넣어서 뭔가 해보는 게 제일 좋다고 생각한다. 내년엔 코딩을 많이 할 수 있을지 모르지만 올해와 다르게 AI로 많이 해볼 수 있기를 기대한다.

책을 원래 느리게 읽는 편인데 올해는 책도 별로 읽지 못했다.(소설을 그래도 몇 권 더 읽기는 했다.) 내년에는 계획 잡아서 책을 열심히 읽어야겠다.

회사

개인 코딩은 못 했다고 얘기했지만, 작년과 마찬가지고 회사 업무는 열심히 하고 있다. 예전에는 이 둘이 연결되어 있었다. 개인적인 시간을 생산적으로 보내지 못하고 회사에서도 그랬고 아니면 그 반대로 동작하면서 개인 생활과 회사 생활은 끊을수 없을 정도로 연결되어 있었는데 이젠 더 그럴듯한 직장인이 된 것인지 개인적인 나태함에 비해 회사 업무는 나름 열심히 하고 있다. 집에서 나태하게 소파에 누워있을 때도 업무 고민을 하는 것에는 별로 거부감이 없을 정도로 업무 몰입감을 여전히 좋은 편이다.

작년에 SRE 팀을 맡은 뒤에 올해는 전체 팀의 업무를 어느 정도는 파악할 수 있었고 그걸 바탕으로 새로운 방향성을 어느 정도 그려갔다. 이젠 팀이 21명으로 엄청 큰 팀이 되었고 여전히 내가 팀 매니징을 잘하고 있다고 생각하진 않지만 매니징에 대해서도 어느 정도 배워나가고 있고 (동료들은 어떻게 생각할지 모르지만) 내 나름대로는 실무에서 너무 멀어지지 않은 상태로 필요할 때마다 각 업무에 개입할 수 있는 상태로 유지하고 있다고 생각한다. 마이크로 매니징에는 부정적인 편이라 내가 마이크로 매니징을 하는 건 아닌지 항상 걱정하지만 나름대로는 적당한 선에서 개입하고 개개인에게 자율성을 부여하는 방향으로 가고 있다.

아쉽게도 "전 매니저 아닌데요"라고 자신 있게 말할 수 없는 수준까지 왔다. 내가 원하는 걸 동료들의 피드백을 받으면서 의사결정을 하고 동료들의 손으로 그 일을 해내는 건 여전히 쉬운 일은 아니다. 그럼에도 좋은 동료 덕에 작년보다는 좀 더 편하게 그런 일을 할 수 있게 되었다고 생각한다. 팀의 방향을 명확하게 하려고 계속 고민하고 있고 얼마 전에 올 한 해 업무를 돌아보는 자리가 있었는데 여러 면에서 해온 게 많다는 생각이 들었다. 쉽지 않고 원하지 않은 일도 어느 정도 해결했고 새로운 시도들도 효과들을 보는 것들이 있다. 업무적으로도 어려운 상황의 문제들을 해결하거나 도전적인 프로젝트도 소기의 성과를 거두기도 했지만 내가 신경 쓰는 팀의 남녀 비율도 어느 정도 조정했고 수년간 고민하던 SRE 팀의 신입 채용에 대해서 배운 것도 많고 팀의 부족한 부분도 많이 신경 쓸 수 있게 되었다.

물론 그럼에도 실무(?)는 손에 놓지 않으려고 한다. 내가 직접 하는 것보다 더 잘할 동료들이 많긴 하지만 실무에서 멀어지지 않는 것은 내가 판단을 그래도 제대로 하기 위한 마지막 장치에 가깝다. 이 거리도 팀이 커지면서 조금씩 멀어지고 있긴 한데 아직은 내가 정보가 없어서 판단할 수 없을 정도는 아니라고 생각하고 있어서 안정감(나 혼자?)을 느끼는 거리감이라고 생각한다. 지금은 여기서 실무와의 거리를 더 멀게 할 생각은 없고 가능한 한 줄이려고 하고 있긴 하다.

올해 12월로 지금 회사에 다닌 지 5년이 되었다. 나한테는 제일 오래 다닌 회사의 기록을 넘어선 지가 오래되었고 내가 한 회사를 5년이나 다닐 거라는 상상을 제대로 해본 적이 한 번도 없다. 이건 내가 나이를 들어서이기도 하겠지만 우리 팀에 아주 만족하고 있는 부분이 크다. 회사의 영향도 당연히 있겠지만 팀 동료들은 어느 곳에 가서도 이런 팀을 만나기 어렵다고 생각하고 있다. "나는 피플 매니징은 거의 안 한다"는 말을 종종 하는 편인데 동료들이 알아서 업무를 잘 하므로 나는 팀 전체 방향성 조정이나 팀 차원에서 더 챙겨야 하는 부분에만 신경 쓰는 편이다.

블로그와 팟캐스트

개인 코딩을 잘못한 만큼 블로그도 거의 작성하지 못했다. 나에게 블로그는 내 기반이나 다름없는데 블로그를 한지 19년 사이에 가장 적은 33개의 글밖에 쓰지 못했다. 이제는 그래도 한 달에 2개씩 쓰는 뉴스레터로 겨우 명맥이나 유지하는 상태다. 나태해진 것도 있으면서 예전처럼 코딩하면서 겪는 문제나 공부하는 거 하나씩 정리해서 올리는 게 아니라 주 업무 자체가 팀을 챙기는 일이다 보니 글을 쓰기가 좀 어려워진 것도 있다.

물론 팀 업무에서도 블로그로 쓸 주제가 없는 건 아니지만 이전과는 달리 정리할 내용이 좀 더 복잡해지기도 했고 팀 운영에 관한 생각 같은 것도 아무래도 글로 쓰다 보면 이상적인 얘기를 쓰게 될 수 있는데 현실을 마주하는 동료로서는 이런 글이 거북할 수 있다는 생각에 더욱 조심스럽게 된 경향이 있다. 물론 블로그 글을 많이 써서 예전보다는 무거운 글을 쓰려다 보니 더 안 쓰게 되는 경향도 있다.

요즘은 특정 기술의 사용 방법 등을 적는 것보다는 생각을 정리해서 적는 게 더 적합할 것 같은데 회고하면서 곰곰이 생각해 보니 이런 부분도 적어볼 만한 주제가 꽤 있을 거 같다. 생각을 정리해서 글로 적는다는 건 쉽지 않은 일이긴 한데 내년에는 이런 부류의 글을 신경 써서 더 많이 적어보려고 한다. 아까 말한 대로 블로그는 내 기반이나 다름없어서 블로그를 포기할 수는 없다고 생각하고 있다.

개인적으로 하는 RetroTech은 그래도 열심히 했다. 작년에 JavaScript 프레임워크의 역사를 마무리하고 올해부터 시작한 Version Control System을 6편 녹음했다. 블로그 글이 줄어든 이유에는 이 RetroTech의 영향도 있는데 한편 녹음하려고 자료조사 하는 시간을 생각하면 블로그 글 3~4편은 작성할 시간은 충분히 들어가기 때문이다. 작년까지 녹음하던 팟캐스트는 대부분 1시간 이상의 분량이었다가 올해부터는 짧게 하면서 자주해야지 했는데 사실 더 자주하지는 못했다.

이번 VCS의 역사는 JavaScritp 프레임워크와는 달리 1960년대까지 가다 보니 웹 이전의 시절이라 자료 찾기가 쉽지 않아서 더 시간이 걸린거 같다. 확실히 웹 이후냐 아니냐에 따라 아카이빙된 자료의 차이가 엄청나다고 생각하면서도 그 이전에 자료도 생각보다는 잘 남아있다는 생각도 한다.

자료조사하고 녹음하고 편집하는 게 쉽지 않긴 하다. AI로 하면 더 쉽게 할 수 있긴 하겠지만 많이 만들어서 광고 수익을 받거나 하는 게 목표가 아니고 취미에 가깝우므로 아직은 직접 하려고 생각하고 있다. 그래도 자료조사 하면서 몰랐던 역사도 알게 되고 지금 핫한 기술은 아니지만 지금에 영향을 준 것을 보이는 기술을 보면서 꽤 재미있다.

RetroTech를 시작할 때부터 큰 인기를 끌 콘텐츠라고 생각하진 않았고 그래도 취향에 맞는 사람이 있지 않을까 생각했지만, 생각보다도 너무 듣는 사람이 없다. 그래도 듣는 몇 분은 재밌다고 해주셔서 다행이긴 하다. 내가 막 홍보하는 성격이 아니라서 그럴 수도 있긴 한데... 내가 재밌기는 하지만 그대로 너무 듣는 사람이 적으니 아쉽기도 하다. 요즘은 AI가 좋으니까, 한국어로 녹음한 걸 영어로 번역해서 영어 팟캐스트로도 발행해 볼까 하는 생각이 든다. 영어권에서는 관심 있는 사람이 좀 있지 않을까 싶어서 생각은 해보는데 이것도 결국 홍보의 영역이라 실제로 할지는 잘 모르겠다.

그리고 친한 사람들과 취미로 하는 44bits도 올해 20여 편가량 열심히 녹음했다. 44bits는 RetroTech보다는 청취자가 많긴 하지만 여기도 청취자를 모으기보다는 우리끼리 잡담하는 게 더 위주이긴 하다. 요즘 IT가 다 그렇듯이 44bits도 주제가 대부분 AI로 집중되긴 했는데 어떤 면에서는 모든 이슈가 다 AI로 바뀌어서 나로선 좀 아쉽기도 하다.

건강

나는 몸이 건강한 편인데 그 덕에 건강 관리에 무신경한 편이기도 하다. 나이가 있기도 하다 보니 건강 관리를 진짜로 해야겠다는 생각하고 있다. 물론 이 계획은 작년에도 했지만 제대로 못 지킨 다짐이기도 한데 그래도 이젠 진짜 해야겠다는 생각이 든다.

그나마 다행인 건 올해는 러닝을 좀 하게 되었다는 거다. 9월쯤에 한참 러닝을 하다가 귀찮아지면서 또 운동을 안 하게 되었다. 다른 사람들처럼 러닝이 막 재밌거나 그렇진 않은데 그래도 건강 관리 면에서 다른 운동보다 러닝이 좀 나은 거 같다. 팟캐스트 들으면서 기록 집착 안 하고 뛰면 괜찮고 하고 건강에도 도움이 꽤 되는 거 같다. 많이 안 뛰어봐서 관절이나 근육이 돌아가면서 아프다 보니 다치고 싶진 않아서 쉬다가 결국 안 하게 되었지만, 다시 뛰어봐야겠다.(그래도 추운데 뛰는 건 아무래도 쉽지 않다.)

새해 복 많이 받으세요.

[Book] 플랫폼 엔지니어링 - 개발과 운영을 아우르는 플랫폼 관리의 핵심 원칙

2025-12-31T22:43:28+09:00

플랫폼 엔지니어링 - 개발과 운영을 아우르는 플랫폼 관리의 핵심 원칙

플랫폼 엔지니어링 - 개발과 운영을 아우르는 플랫폼 관리의 핵심 원칙 - ⭐⭐⭐⭐⭐
이언 놀런드, 카미유 푸르니에 지음
류광, 307번역랩 옮김
한빛미디어
Platform Engineering

국내에는 개발 7년차, 매니저 1일차의 저자로도 알려진 Camille Fournier가 Ian Nowland와 함께 쓴 Platform Engineering에 관한 책이다.

최근 몇 년 동안 Platform Engineering이 주 업무 중 한 분야이기도 해서 꽤 많이 고민하고 공부했었기에 이 책이 나온다고 해서 기다리고 있었다.(하지만 이제야 읽었다.ㅎㅎ)

플랫폼 엔지니어링이라는 건 꽤 어려운 분야라고 생각한다. 어느 분야이든 어렵지 않은 영역은 없지만 Platform이라는 용어 자체가 너무 광범위하기 사람마다 이해하는 영역이 꽤 다르다고 생각한다. 나는 현재 SRE로 일하고 있어서 인프라 관점에서 플랫폼 엔지니어링을 보는 편이고 그렇게 만든 사내 개발자 플랫폼(IDP)에 관해서 여러 번 발표도 하고 다른 회사에 소개도 종종 하기는 했는데 이 책은 정말 좋은 책이라고 생각한다. 플랫폼 엔지니어링에 관한 건 아니지만 플랫폼/인프라 조직 관점에서 가장 도움 된 책은 팀 토폴로지였다.

우리 둘 다, 뛰어난 엔지니어들의 그룹이지만 조직 내에서 '고객의 요구나 안정성에 대한 고려 없이 재미있어 보이는 것만 만드는 팀'이라는 평판을 받고 있는 팀을 성숙하고 잘 운영되는 고객 중심 플랫폼 팀으로 바꾸도록 돕는 난제를 맡고 있었다.

이 용어가 최근의 기술 유행어(buzzword)일 수 있지만, 우리는 이것이 최신의 과대선전(hype)으로 퍼지기 훨씬 오래전부터 이를 잘 수행하는 방법을 찾으려 노력해 왔다. 사실 우리가 접한 대부분의 플랫폼 엔지니어링 팀은 내가 앞에서 언급한 조직이 처음에 가졌던 것과 같은 평판을 가지고 있다. 이들은 아무도 요구하지 않은 기능을 그저 재미있어 보인다는 이유로 만들어냈다. 종종 그러한 중요한 작업이 마땅히 가져야 할 운영상의 성숙도도 없다. 이런 일이 생기는 것이 애초에 플랫폼 엔지니어링이 어렵기 때문이다! 과대선전을 걷어내면 조직적 성숙도의 진화가 보일 것이다.

저자가 둘 다 플랫폼 엔지니어링에 대해 고민도 많이 하고 경험도 많으므로 그 고민이 잘 정리되어 있어서 누군가 플랫폼 엔지니어링에 관심이 있다면 이 책을 먼저 보라고 권하고 싶다. 플랫폼 엔지니어링이라는 말 자체는 최근 몇 년 사이에 떠오른 용어이지만 내가 보는 관점에서는 빅테크 회사 위주로 이미 십여 년간 내부에서 플랫폼 엔지니어링을 시도하고 자리 잡았고 그 관례가 정리되어서 업계로 나오면서 플랫폼 엔지니어링이라는 분야가 생기기 시작했다고 생각한다. 그래서 업계에서 플랫폼 엔지니어링이라는 말을 쓰기 시작한 지는 몇년 되지 않았지만, 플랫폼 엔지니어링의 노하우는 꽤 많이 쌓여있다고 생각하는데 그 노하우가 이 책에 고스란히 담겨있다. 공감되는 부분이 너무 많아서 줄을 너무 많이 치면서 읽은 책이다.

1부 플랫폼 엔지니어링의 정의와 필요성

1장 플랫폼 엔지니어링이 점점 더 중요해지는 이유

지난 25년간 소프트웨어 조직들은 한 가지 문제에 직면해 왔다. 여러 팀이 공유하는 코드, 도구, 인프라를 어떻게 관리할 것인가? 이 문제를 해결하기 위해 대부분의 조직은 이러한 공유 요구사항을 담당할 중앙 팀을 만들었다. 하지만 대부분의 경우 이는 그다지 효과적이지 않았다.

그런 중앙 팀을 개선하는 대신 완전히 없애버리는 방법을 선택한 조직들도 있었다. 그런 조직은 각 애플리케이션 팀에 클라우드 접근 권한과 원하는 오픈소스 소프트웨어(OSS)를 선택할 권한을 주었다. 하지만 선택한 서비스나 소프트웨어의 복잡한 운영 및 유지보수 부담은 애플리케이션 팀의 몫이 되었다. 결국 효율성과 규모의 경제를 창출하는 대신, 소규모 팀조차도 사이트 신뢰성 엔지니어링과 데브옵스 전문가를 두어야 했다.

한편, 클라우드와 OSS의 장점을 수용하면서도 중앙 팀 모델을 포기하지 않은 조직들도 있었다. 장점이 단점보다 크다고 확신했기 때문이다. 가장 좋은 성과를 얻은 조직은 플랫폼, 그러니까 다른 엔지니어들이 편하게 그 위에서 개발할 수 있는 공유 서비스를 구축한 조직이다. 플랫폼 담당자들은 클라우드와 OSS의 복잡성을 관리하면서도 사용자들에게는 안정성을 제공하는 전문가로 성장했다. 또한, 애플리케이션 팀의 의견을 경청하고 협력하면서 회사의 요구사항을 계속 충족하고 발전시켰다.

다양한 조직에서 문제를 해결하기 위해 여러 시도를 하면서 플랫폼 엔지니어링이 떠오르게 된 과정을 잘 설명한다.

복잡성 관리라는 근본적인 과제는 모든 종류의 내부 플랫폼 개발에 공통이라는 점을 기억하기 바란다.

플랫폼 엔지니어링은 플랫폼을 개발하고 운영하는 하나의 분야이다. 이 분야의 목표는 비즈니스에 레버리지를 전달하기 위해 전체 시스템의 복잡성을 관리하는 것이다. 플랫폼 엔지니어링은 폭넓은 애플리케이션 개발자층을 위한 소프트웨어 기반 추상화로서의 플랫폼을 개발하고, 이를 비즈니스의 토대로 운영하는 큐레이션 제품 접근 방식을 통해서 그러한 목표를 달성한다.

플랫폼 엔지니어링의 핵심 가치는 레버리지 개념에 있다. 플랫폼 엔지니어링의 맥락에서 레버리지는 소수의 플랫폼 팀 엔지니어들의 작업이 조직 전체의 업무를 줄여주는 것을 의미한다.

플랫폼을 하나의 제품으로 보는 것이 매우 중요하다. 플랫폼을 매력적인 제품으로 개발한다는 것은 플랫폼의 기능을 결정할 때 고객 중심적 접근 방식을 취한다는 뜻이다. 그러려면 사용자가 주된 초점이 되어야 한다.

플랫폼 엔지니어링의 기본적인 개념에 대한 설명이다.

플랫폼 엔지니어링은 OSS와 벤더(제품이나 서비스를 제공하는 업체 또는 조직)의 선택을 조직의 필요에 맞게 제한된 집합으로 추상화하고 강력한 의견을 제공함으로써 관심사의 분리를 가능하게 한다.

오케스트레이션 시스템인 쿠버네티스의 부상은 여러 면에서 PaaS와 IaaS 모두가 기업의 요구를 충족시키는 데 실패했다는 것을 인정하는 것이다. 쿠버네티스는 애플리케이션을 소위 '클라우드 네이티브'로 만들어서 인프라 관련 접착제를 줄이려는 시도라고 할 수 있다. 하지만, 비록 쿠버네티스가 많은 것을 표준화했음에도 복잡성 측면에서는 득이 되지 않았다.

애플리케이션이 테라폼 접착제 대신 YAML 접착제를 더 많이 사용하게 되었을 뿐이다. 앞에서 논의했듯이 플랫폼 엔지니어링의 목표는 전체 접착제의 양을 줄이는 것이다.

클라우드와 OSS가 제대로 연동되도록 다양한 자동화와 도구들이 생기게 되는데 이를 이 책에서는 접착제라고 부르고 이 접착제로 인해서 점점 변경이 어렵게 되고 운영이 복잡해지게 된다고 설명하는데 결국 이 접착제를 줄이는 것이 중요하다. Terraform, 정확히는 HCL 대신 YAML로 바뀌었을 뿐이라는 말에 동의한다.

애플리케이션 개발자들은 자신이 좋아하는 시스템을 사용할 때 더 큰 자율성과 주인의식을 느낀다. 하지만 기업이 다양한 선택으로 인한 지원 부담과 장기 비용 절감에 초점을 맞추기 시작하면 이러한 이점은 종종 잊힌다. 이런 상황에서 지도층의 본능적인 첫 반응은 권위에 호소하여 표준을 규정하는 것이다.

플랫폼 엔지니어링은 현대적인 엔지니어링 팀에게 그들이 즐겨 사용할 수 있는 시스템이 필요하다는 점을 인정한다. 이러한 시스템은 단순히 비용 절감이나 자체 지원 부담에만 초점을 맞추지 않고, '고객으로서의 팀'을 배려하는 팀들이 제공해야 한다. 권위에 호소하는 표준 규정 대신, 플랫폼 엔지니어링은 광범위한 요구사항을 충족할 수 있는 소수의 기본요소를 큐레이션하는 고객 중심의 제품 접근 방식을 취한다. 이를 위해서는 비즈니스 현실을 고려한 타협과 좋은 플랫폼 아키텍처의 증분 전달(incremental delivery), 그리고 애플리케이션 팀과 직접 협력하여 그들의 요구를 경청하려는 자세가 필요하다. 이것이 잘 이루어지면, 아키텍트나 데이터베이스 관리자, CTO, 플랫폼 부사장(VP)의 권위에 호소하는 대신 플랫폼이 제공하는 서비스를 활용하는 파트너십의 효과를 입증할 수 있다. 이러한 방식을 잘 적용한다면, 하향식 명령으로 인한 최악의 결과를 피하면서도 사용되는 OSS와 클라우드 기본요소의 수를 줄이는 것이 가능하다.

인프라나 플랫폼을 관리하다 보면 어떤 정책이나 시스템을 적용해야 할 때가 있기 때문에 권위에 호소해서 조직 전체가 적극적으로 움직이면 얼마나 좋겠냐는 생각이 들 수 있고 실제로 나도 이런 생각을 하거나 시도 비슷한 것도 해본 적이 있다. 하지만 결과적으로는 좋은 방법이 아니라고 생각해서 지금을 잘 접근하지 않는데 이 책에서도 그 부분을 강조해 주어서 좋았다.

플랫폼 엔지니어링은 사용 중인 기본요소의 수를 줄이는 것에서 한 걸음 더 나아가 남은 요소들과의 '접착제'를 줄이는 것을 목표로 한다. 기본요소들을 더 광범위한 요구를 충족할 수 있는 체계적인 플랫폼 역량들로 추상화함으로써 애플리케이션 수준의 접착제를 대부분 제거할 수 있다.

테라폼은 플랫폼 엔지니어링이 접착제의 단점을 어떻게 해결하는지 보여주는 데 아주 적합한 예이다.

전문가 그룹을 단순한 '접착제' 유지보수 센터에서 실제로 무언가를 구축하는 엔지니어링 센터로 발전시켜야 한다. 그런 엔지니어링 센터가 곧 플랫폼이다.

이 책은 테라폼 적용으로 인한 상황을 예시로 드는데 테라폼을 적용하고 관리가 어려워서 테라폼이 중앙 집중화되고 해당 팀은 이 테라폼 유지보수 센터가 되어 버린다. 테라폼을 정말 십 년간 좋아했던 나도 이 문제를 겪으면서 고민도 많이 했고, 결국 테라폼을 상당 부분 걷어버리고 플랫폼을 대체하고 방향을 찾았다고 느낀다. 플랫폼으로 대체하진 못했더라도 테라폼을 쓰는 대부분의 조직이 테라폼에 관해서 어느 정도 애증의 감정을 느끼고 있을 거라고 생각한다.

성숙한 데브옵스의 목표는 "만든 사람이 소유한다(you built it, you own it)"라는 접근 방식을 통해 책임 소재를 단순화하는 것이다. 이 개념이 10년 넘게 인기를 끌었지만, 실제로 모델을 실현한 기업은 많지 않다. 실현에 성공한 기업들의 경우, 우리는 플랫폼이 바탕 의존성의 운영 복잡성을 추상화해서 제공한 '레버리지'가 주된 성공 요인이라고 믿는다.

지금까지 이야기한 문제점들을 처리하고 감당하는 운영 플랫폼을 구축하는 것이 쉬운 일은 아니다. 특히, 애플리케이션 팀이 선택의 제한을 수용하게 만들기가 어렵다. 하지만 이런 플랫폼이 없으면 조직 전체가 이러한 문제에 직접 노출되거나, 기존의 운영팀(구체적인 이름이 무엇이든)을 계속 돌릴 수밖에 없다.

플랫폼 엔지니어링은 이러한 엔지니어 그룹들이 각자의 사일로에서 벗어나 균형 잡힌 플랫폼을 만드는 더 광범위한 임무를 가진 팀에서 일할 것을 요구한다.

모든 결과를 달성하는 데 상당한 시간이 걸릴 수 있음을 인정하지만, 우리는 이것이 추구할 가치가 있는 이상이라고 믿는다.

아주 동의한다. 시간이 지나고 조직이 커지면 또 다른 문제를 만나겠지만(처음 테라폼을 적용했을 때도 너무 좋았었다.) 조직이 어느 정도 커진다면 현재는 플랫폼 엔지니어링 접근이 맞는 방향이라고 생각한다.(물론 그 플랫폼이 어떤 형태이냐가 중요하겠지만...)

모든 새로운 아이디어를 플랫폼에 끼워 맞춰야 한다고 주장하는 것은 아니다. 오히려, 이러한 아이디어가 독립적으로 발전하도록 두고, 성공적이고 광범위한 수요가 있는 것만 통합하는 것이 최선의 방법일 때가 많다. 플랫폼 팀은 사람들을 플랫폼에서 멀어지게 할 혁신과 실험을 억제하고 싶은 유혹을 받는다.

나도 수년간 플랫폼이라는 망치를 들고 있던 터라 모든 것이 못으로 보여서 계속 객관적으로 보려고 하지만, 이 유혹은 정말 심하긴 하다.(보통 동료들이 정신 차리게 해주는 거 같다.)

2장 플랫폼 엔지니어링의 기둥들

플랫폼 엔지니어링 실무의 4대 '기둥(pillar)'을 도출할 수 있다. 제품 - 큐레이션 제품 접근 방식을 따른다. 개발 - 소프트웨어 기반 추상화를 개발한다. 범위 - 폭넓은 애플리케이션 개발자층을 지원한다. 운영 - 플랫폼을 비즈니스의 토대로 삼는다.

플랫폼을 만들면서 이렇게 핵심 기둥을 고민하거나 정하지는 않았지만 이렇게 핵심 요소는 고민할 때 도움이 꽤 될 것 같다.

플랫폼 엔지니어링의 첫 기둥인 큐레이션 제품 접근 방식(curated product approach)은 다른 세 기둥의 균형을 잡는 역할을 한다. 여기서 제품 접근 방식이란 개발자들이 순수하게 기술적인 사고방식에서 벗어나 고객이 시스템에 대해 원하는 바와 시스템을 사용하는 경험에 초점을 맞추는 것을 의미한다. 그리고 큐레이션이란 특정한 상호작용 패턴과 사용 규칙이 존재할 뿐만 아니라 이 플랫폼의 범위에 무엇이 포함되고 제외되는지에 대한 나름의 관점(opinion)을 가지고 그에 따라 제공 사항들을 엄선한다는 뜻이다.

큐레이션 제품 접근 방식이 성공하면 두 가지 유형의 플랫폼 제품이 만들어진다.

포장도로 큐레이션 플랫폼의 가장 일반적인 유형으로, 여러 서비스를 층층이 쌓아서 사용하기 쉬운 작업흐름(workflow)을 만든다. 종종 이 플랫폼을 '포장도로(paved path)'라고 부른다.

이것은 포장도로이지 강제된 서비스가 아니므로, 특수한 요구사항이 있는 팀은 언제든 도로에서 벗어나 자신의 길을 갈 수 있다.

철도 둘째 유형의 큐레이션 플랫폼은 포장도로형과는 아주 다른 모습이다. 이 유형은 기존 제품으로는 해결되지 않지만 여러 애플리케이션 팀에게 필요한, 유의미한 틈(gap)을 발견한 경우에 적합하다.

이 유형은 흔히 애플리케이션 팀이 특정 요구사항을 충족하기 위해 만든 프로토타입에 기반한다. 그러한 프로토타입을 일반화하여 더 폭넓게 사용할 수 있는 서비스를 만든 것이 이 유형의 플랫폼이라고 할 수 있다.

제품 접근 방식을 따른다는 말은 뻔한 말인 듯하면서도 실제로는 꽤 모호하게 느껴질 수도 있는 부분이라고 생각한다. 그동안 플랫폼을 만들어주면서 요구사항을 다 만드는 게 아니라 opinionated여야 한다는 생각을 많이 했는데 그 부분에 대해서 짚어주고 있고 포장도로에 대해서는 나도 많은 생각을 했지만, 철도에 대해서는 생각해 본 적이 없어서 재미있었다.

소프트웨어를 구축하지 않은 플랫폼 엔지니어링은 플랫폼 엔지니어링이 아니다.

내부 결제 플랫폼이든 인프라 수준의 컴퓨트 플랫폼이든, 플랫폼 엔지니어링은 사내에서 개발한 소프트웨어 로직을 사용하여 바탕 시스템을 추상화함으로써 레버리지를 만든다. 다른 말로 하면, 그러한 추상화 없이는 복잡성을 관리하는 플랫폼을 만들 수 없다. 추상화 없이는, 단지 인프라를 공급하고 모든 복잡성을 사용자에게 떠넘기는 것에 불과하다.

완전한 캡슐화가 적절한 수준의 추상화인지 판단하는 핵심 기준은 애플리케이션 엔지니어의 관점에서 바라보는 것이다. 즉, 표면적을 줄이고 바탕 OSS 및 벤더 시스템과 관련된 자원(공개 문서 등 포함)들과 그들을 분리했을 때 과연 생산성이 높아졌는지, 아니면 단지 플랫폼 팀이 관리하기 쉽게 만든 것일 뿐인지는 아닌지 점검해야 한다. 실제로 생산성이 높아졌음을 확신할 수 있을 때까지는 바탕 시스템에 대한 직접 접근을 허용하고, 그로부터 배우는 것이 낫다.

추상화 역시 중요한 부분이지만 어디까지 어떻게 추상화할 것인지는 어려운 영역이다. 그럼에도 이 부분의 고민은 무척 중요한데 추상화하면 어떤 부분은 감춘다는 의미이므로 누구는 편하다고 느끼겠지만 누구는 헷갈리고 추상화된 부분을 알고 싶어하면서 적절한 추상화인지 고민하게 되는데, 추상화에 대한 기준을 제시해 준 게 좋았다.

우리는 레지스트리를 만든 팀이 사용자가 수동으로 정보를 채울 것이라고 생각하거나, 기계적인 스크레이핑(scraping) 후 '그냥' 정리만 하면 될 거라고 생각했을 때 레지스트리가 잘 자리 잡지 못하는 사례를 목격했다. 광범위한 성공은 플랫폼이 이러한 레지스트리와 얼마나 잘 통합되어 메타데이터를 지속적으로 자동 캡처하고 레이블링할 수 있느냐에 달려 있다고 믿는다. 엔지니어들이 큐레이터 역할을 하는 것만큼 싫어하는 것은 없기 때문이다.

이 부분 또한 중요한데 어떤 정보를 현재 상태에서 채워 넣는 건 가능하지만(이마저도 쉽진 않다.) 이를 앞으로도 계속 녹슬지 않은 정보로 만들려면 훨씬 어려운 일이 되고 추상화 외에도 넛지 요소가 많이 필요해진다.

시스템을 더 저렴하고, 안전하며, 사용하기 쉽게 만드는 역량(capability)을 개발해야 한다. 이러한 역량에는 다음이 포함된다.

셀프서비스 인터페이스 셀프서비스는 플랫폼이 제공하는 핵심 요소의 하나이다. 대규모 고객층을 효율적으로 지원하려면 셀프서비스가 필요하다.

사용자 관측성 플랫폼에서 덜 이야기되지만 중요한 또 다른 셀프서비스 유형이 사용자 관측성(user observability)이다. 개발자가 플랫폼을 이용해서 애플리케이션을 개발하고 운영하는 전체 수명 주기 동안 개발자 스스로 문제를 디버깅할 수 있도록 원격 측정 기능을 구축해야 한다.

가드레일 가드레일 구현이 플랫폼 구축의 중요한 일부가 된다. 여기서 가드레일은 값비싼 설정 오류가 발생할 가능성을 크게 낮추는 보호 장치와 기본 한곗값들을 말한다.

다중 테넌트 널리 사용되는 플랫폼의 핵심적인 측면 하나는 플랫폼이 다중 테넌트(multitenant)를 지원해야만, 즉 동일한 런타임 구성요소 내에서 서로 다른 애플리케이션을 돌릴 수 있어야만 효율적이라는 점이다.

전부 중요하지만 난 여기서 셀프서비스 인터페이스와 가드레일이 제일 중요하다고 생각한다.

플랫폼 엔지니어링 실천의 마지막 기둥은 플랫폼을 하나의 토대(foundation; 기반)로서 운영하는 것이다. 플랫폼은 애플리케이션 엔지니어가 자신의 비즈니스를 믿고 맡길 수 있는 튼튼한 토대가 되어야 한다.

플랫폼 팀은 끊임없이 고객 문의를 받게 된다. 이런 문의들은 주로 온보딩 과정의 예외적인 상황이나 애플리케이션별 프로덕션 문제점에 관한 것으로, 애플리케이션, 플랫폼, 또는 기반 시스템의 변경이나 장애로 인해 발생한다.

플랫폼이 더 적합한 기업에서조차도 인프라 엔지니어링 스타일의 문화가 지속되는 주된 이유는 그러한 플랫폼을 구축할 소프트웨어 개발자들이 타인의 시스템을 제대로 운영하는 데 필요한 실무에 관여하기를 꺼리기 때문이다. 플랫폼 엔지니어링 팀은 운영 실무를 적극적으로 활용해야 한다. 플랫폼이 기업이 신뢰할 수 있는 토대로 자리 잡게 하는 핵심 요소가 그것이기 때문이다.

이 책을 읽으면서 나에게는 잘 와닿지 않은 부분이 조직에 관한 것인데 내 현 상황에서는 같은 팀에서 플랫폼 구축과 인프라 운영을 함께하는 데 반해 책에서는 플랫폼 구축과 운영을 하는 별도의 조직을 더 일반적으로 얘기하고 있었다. 인프라 운영을 같이하므로 토대가 되어야 한다는 부분은 약간 더 쉬웠을 수 있다고 생각하지만 그럼에도 플랫폼이 기반 인프라로써 안정감을 줘야 한다는 것은 당연하고 플랫폼으로 추상화함으로써 그전까지는 운영 주체가 모호했던 부분을 명확하게 나누어서 일부는 플랫폼을 운영하는 쪽에서 책임져야 한다는 부분은 중요하다.

2부 플랫폼 엔지니어링 실무

3장 착수 시기와 방법

플랫폼이 새로운 기능을 제공하는 이유는 단순한 효율성이 아니라 레버리지여야 함을 의미한다.

이 의미는 중앙 팀에서 뭔가를(꼭 플랫폼이 아니더라도) 회사 관점에서는 여러 팀이 똑같은 일을 하니까 중앙 팀에서 한다는 효율성이 아니라 소수가 회사 전체에 이득을 주는 레버리지여야 한다는 의미다.

이들의 의도는 순수할 수 있지만, 우리의 경험상 일부는 변화에 대해 불평을 멈추지 않을 것이다.

이 시점에서 플랫폼 팀은 신뢰를 전혀 쌓지 못했다. 단지 호의를 얻었을 뿐이다. 팀이 만든 것은 그저 조직의 새로운 사일로이다. 이제 팀의 당면 목표는 엔지니어링 팀과의 협업을 최대한 유지하는 방법을 찾는 것이다. 신속한 가치 전달로 신뢰를 쌓아야 한다.

플랫폼 구축에 대한 반대 여론은 실제로 많이 경험해 봤다.

대기업에서 온 신규 엔지니어들을 주의하라

실제로 이들이 아는 것은 과거에 유사한 문제를 겪었던 다른 회사의 완성된 솔루션일 뿐일 수 있다.

이마저도 경험해 봤다. 꼭 대기업이 안다고 하더라도 대부분의 사람은 자신이 이전에 잘 사용했던 솔루션을 그대로 여기서 사용하려는 경향이 있다. 이게 잘못되었다는 것은 아니고 익숙한 도구로 하려는 일을 빠르게 잘하려는 것이지만 플랫폼을 만드는 처지에서는 이 지점이 꽤 많은 충돌 지점이 된다.

플랫폼 팀이 약 50명 정도로 성장하면 비로소 첫 번째 프로젝트 관리자를 두어야 할 것이다. 가능한 한 이 비율을 넘기지 말아야 한다.

이건 아직 잘 모르겠다. 훨씬 소수일 때도 PM이 필요하다고 생각했었지만, 지금은 전혀 그런 생각을 하지 않는다. 제일 큰 이유는 그런 사람을 찾을 수 있을지 모르겠기에 이기도 하고 서비스와 달리 내부 플랫폼에 관해서 PM과 협업한 경험이 그리 많지 않아서이기도 하다.

통합 플랫폼을 구축할 때 간과되는 중요한 요소 중 하나는 발견성(discoverability; 또는 발견 가능성)이다. 기업의 규모가 클수록, 플랫폼 팀이 제공하는 기능이 자신에게 필요할 수 있다는 사실을 사람들이 인지하기가 더 어려워진다.

결제 플랫폼을 '결제 플랫폼' 대신 '글렌게리Glengarry'라고 부르는 것은 발견성 문제 해결에 전혀 도움이 되지 않는다. 플랫폼 팀은 자신이 제공하는 기능과 서비스를 조직 전체에 알릴 계획을 반드시 세워야 한다.

이는 시간이 지날수록 공감되는 부분인데 기능이 늘어나고 고도화되고 조직이 커질수록 해당 기능의 존재 자체를 모르는 사람이 많아지게 된다. 가장 의존하는 건 다양한 채널을 통해서 여러 번 공지해서 알리는 방법이기는 한데 보통 그 필요성은 느끼는 때가 아니면 해당 공지를 보더라도 무심코 넘어가기 마련이다. 기본적으로는 공지로는 한계가 있고 플랫폼의 흐름과 기능에서 해당 기능이 필요할 때 알려줄 수 있어야 한다고 생각하고 있지만 현실에선 쉽지 않기도 하다. 좋은 기능이 잘 알려지지 않아서 못 쓰였던 상황을 볼 때마다 아쉬움이 생긴다.

통합 플랫폼 팀은 본질적으로 중간자 위치에 갇혀 있다는 점을 짚고 넘어갈 필요가 있다. 일반적으로 통합 플랫폼 팀은 바탕 컴퓨트, 저장, 네트워킹을(그리고 종종 보안과 신원 인증 서비스도) 관리하는 핵심/인프라 플랫폼 조직의 일부가 아니다.

통합 플랫폼 팀이 애플리케이션과 핵심 플랫폼 팀들 사이에 위치한다는 것은 스택의 양쪽에서 발생하는 오류의 영향을 받는다는 뜻이기도 하다. 이로 인해 디버깅과 운영이 한층 더 까다로워진다.

이게 아까 말한 조직 얘기인데 내용이 좋음에도 불구하고 여기서 말하는 플랫폼 팀의 영역이 좀 모호하게 느껴지긴 한다. 그럼에도 플랫폼이라는 것 자체가 중간자의 위치에 있다는 것은 동의하고 여기서 말하는 문제를 잘 해결해야 한다.

'플랫폼 엔지니어링'과 이미 가까이 있는 영역부터 시작해서, 거기서 효과적인 방법을 배우고 그것을 더욱 확대 적용하는 것이 더 낫다.

엔지니어들은 자신의 제품을 지원하는 데 시간을 써야 한다. 엔지니어의 질문에 정기적으로 답하지 않는다면, 고객이 시스템을 사용하려 할 때 겪는 어려움을 이해할 기회를 놓치게 된다.

이 부분 역시 너무 중요하다. 플랫폼이 잘 만들어서 수동 지원을 줄이려는 목적도 포함되어 있지만 이러한 수동 지원은 영원히 없어지진 않을 거라고 생각한다. 이 지원을 통해서 사용자가 어떻게 플랫폼을 사용하고 뭘 착각하는지 잘 이해할 수 있고 그런 지원이 없다면 프로바이더만 만족하는 프로바이더의 함정에 빠질 수 있다고 생각한다. 이 함정에 빠지기 쉬우므로 빠지지 않기 위한 노력과 장치가 많이 필요하다.

큰 기술적 문제를 해결하는 사람만 승진시킨다면, 사용성을 개선하고 고객 팀의 의견을 경청하며 가장 시급한 문제 해결을 위해 업무 우선순위를 조정하는 인재들은 조직을 붙잡아두기 어렵다.

플랫폼의 가치에는 고객의 마이그레이션 부담 경감이 반드시 포함되어야 한다.

엔지니어링 팀을 제품 중심 사고방식으로 전환하는 데 있어 지름길 같은 것은 없다.

팀은 고객과 더 많은 시간을 보내야 하며, 단순히 최근 고객 불만을 해결하는 것이 아니라 전체적인 문제를 해결하기 위한 전략적 계획에 더 많은 시간을 투자해야 한다.

조직 관점에서 이 부분은 중요하다. 여기 있는 말에는 동의하면서 이런 타입의 사람이 있는 것인지 분위기가 만들어지면 이런 접근방법을 배우게 되는지는 여전히 어렵다.(휴먼 관리는 너무나도 어렵다.) 그럼에도 팀 자체가 제품 중심 사고방식을 취해야 함은 필수적이고 이게 되지 않으면 제대로 된 플랫폼은 아마도 만들 수 없을 것이다.

4장 훌륭한 플랫폼 팀 만들기

플랫폼 팀은 복잡한 시스템 위에 추상화 계층을 개발해 사용자의 생산성을 높이지만, 해당 시스템을 이해하는 전문가들로 구성하지 않는다면 나중에 운영상 문제를 야기할 수 있다.

훌륭한 플랫폼 팀을 만드는 방법은 다양한 강점을 가진 인재를 채용하고, 각자가 성공할 수 있는 문화를 조성하는 것이다.

좋은 팀을 만드는 법에 관해서 난 아직 너무 초보 단계다. 글로 읽으면 이해되는 말이지만 현실에선 너무 어렵다. 현재 생각은 "좋은 사람을 뽑으면 된다"라는 무책임한(?) 생각 정도이다.

소프트웨어와 시스템 중 한쪽에만 지나치게 치우친 팀을 개선하려면 두 종류의 작업을 동등하게 평가해야 한다. 보통의 경우 그러려면 팀에 새로운 역할을 추가할 필요가 있다.

첫 단계는 소프트웨어 대 시스템이라는 기존 구분 방식의 한계를 깨닫는 것이다.

우리 저자들은 플랫폼 팀에 다음과 같은 세 가지 주요 시스템 중심 역할이 필요하다고 믿는다. 시스템 엔지니어 - 진정한 시스템 제너럴리스트이다. 데브옵스 엔지니어라고 부르는 게 적당하겠지만, 업계에는 그 밖에도 여러 이름이 있다. 신뢰성 엔지니어 - 시스템의 신뢰성에 깊이 집중한다. 시스템 엔지니어링의 다른 측면은 무시한다. 시스템 전문가 - 시스템 전문가(system specialist)는 특정 분야의 깊은 전문성에 기반한 여러 구체적인 역할을 아우르는 이름이다. 이를테면 리눅스 엔지니어, 성능 엔지니어, 네트워크 개발 엔지니어 등이 시스템 전문가에 속한다.

앞에서도 몇 번 얘기했지만, 이 책에서 얘기하는 플랫폼 팀이 위치한 회사 내의 조직도를 잘 모르겠다. 어쨌든 지금 내가 있는 조직은 아주 큰 조직은 아니기에 인프라 운영과 플랫폼 구축을 한 팀에서 다 하고 있어서 명확하지는 않더라도 위의 역할을 다 섞어서 하고 있다. 팀이 커지면서 조직에 대한 고민도 많았는데 지금 확신(?)하고 있는 대로 한 팀으로 있는 것이 한쪽으로 치우치지 않고 사일로를 만들지 않는다고 생각한다.

성공적인 플랫폼 팀에서는 특히 시니어급 소프트웨어 엔지니어들이 일반적인 애플리케이션 팀의 '백엔드' 엔지니어들과는 다소 다른 특징을 보인다. 다음은 대표적인 세 가지 특징이다.

시스템을 이해하려는 의지가 강하다. 이들은 자신이 작성한 코드와 그 코드가 실행되는 시스템의 상호작용을 깊게 이해하고자 한다

필수 비즈니스 시스템의 온콜 당직을 불편해하지 않는다.

신중한 속도로 배포하는 것을 받아들인다. 시스템 세부사항을 좋아하고 사용자 문제를 즉시 해결하기 위해 자유롭게 코드를 작성하고 싶어 하는 뛰어난 인재는 많다. 하지만 플랫폼의 소프트웨어 엔지니어는 코드 작성 외에도 운영, 통합, 실험에 시간을 할애해야 한다.

꼭 플랫폼 팀에 한정된 얘기도 아니다.

우리의 경험상 성공적인 플랫폼 팀에서는 폭 넓은 시스템 엔지니어가 더 일반적인 역할이므로, 이를 먼저 살펴보겠다. 소프트웨어 작성보다 시스템 이해에 중점을 두면서도 그 초점을 폭넓게 가져가 여러 전문 분야를 이해하는 인재는 거의 모든 플랫폼 팀에 도움이 된다. 이들이 성능이나 리눅스, 네트워킹 등 특정 개별 분야의 세계적 전문가는 아닐지라도, 서로 다른 유형의 시스템이 어떻게 작동하고 통합되는지에 대한 복잡성을 이해하려는 동기가 있기 때문에 대부분의 소프트웨어 엔지니어보다 더 많은 지식을 보유하고 있다.

플랫폼 엔지니어링 문화를 도입했다면, 팀의 모든 구성원은 단순히 자동화나 신뢰성이 아닌 플랫폼 제품의 기능이라는 관점에서 자신의 작업을 생각해야 한다.

왜 특정 시스템 요소의 전문가를 구하는 대신 폭넓은 시스템 엔지니어 역할을 인식하고 채용해야 할까? 이유는 세 가지이다. • 전문화에는 시간이 걸린다. 쓸 만한 시스템 엔지니어는 이미 '시니어' 수준의 경력을 갖춘 경우가 많아서, 그만한 경력이 아니면서도 능력 있는 시스템 엔지니어를 구하기가 어렵다. • 유능한 시스템 엔지니어는 승진하려면 전문화가 필요하다고 느끼게 된다. 이들이 시스템 전문가로 변신하면, 팀으로서는 이들이 기여하는 폭넓은 지식(매우 중요함)을 잃게 된다. • 전문가가 너무 많을 필요는 없지만, 폭넓은 시스템 엔지니어는 반드시 필요하다.

영역 구분 없이 필요하다면 뛰어드는 엔지니어는 너무 소중하다. 여기서 당연히 폭이 넓은 것만으로는 안 되고 깊이도 있어야 하는데 플랫폼 팀이 아니더라도 좋은 동료의 자질이지만 이런 사람들이 만들어주는 분위기와 문화가 없다면 플랫폼도 제대로 만들 수 없다고 생각한다.

우리는 일반적인 업무를 거부하는 시스템 전문가들도 보았다. 그런 사람들은 우리가 '내부 전도사(internal evangelist)로서의 전문가'라고 부르는 역할을 원한다. 이들은 회사에 당장 가치가 없는 오픈소스 프로젝트에 기여하거나, 컨퍼런스에서 발표하거나, 생소한 새로운 기술을 연구하는 데 열심이며, 자신의 전문 분야와 관련된 '있으면 좋을 법한' 내부 프로그램을 운영하는 데 시간을 보내고 싶어한다. 우리도 모든 엔지니어가 그런 활동을 하라고 장려한다. 단, 적절한 수준에서만이다.

그래, 적절한 수준에서 말이다.

우리 저자들은 이러한 난제를 성공적으로 풀기도 했고 실패하기도 했다. 회사 문화, 조직 내 우리의 위치, 프로세스 변경에 대한 CTO의 의지 등이 성공과 실패에 영향을 미치는 요인이었다. 거기서 배운 점은, 긍정적인 한계적 변화(positive marginal change)가 바로 성공의 관건이라는 것이다. 이는 개별 사례를 바탕으로 점진적 변화를 추진하되, 장기적으로는 더 큰 변화를 위한 근거를 쌓아가는 것을 말한다.

플랫폼 엔지니어링의 성과에 관해서 문제를 겪어본 경험은 없어서 이 부분은 일단 기록만 해둔다.

많은 사람이 의존하는 플랫폼은 조직의 운영에 핵심적인 요소이다. 따라서 플랫폼을 천천히 변경하고 신중하게 운영하는 것은 당연한 일이다.

팀이 약간 독특한 문화를 갖는 것은 괜찮지만, 고도로 신뢰할 수 있는 시스템을 운영하는 데 대한 자부심이 결함 있는 코드를 계속 배포하는 제품 엔지니어링 팀에 대한 경멸로 변질될 정도가 되면 안 된다. 그러면 훌륭한 플랫폼을 구축하는 데 매우 중요한 고객 공감 능력을 잃을 위험이 있다.

사용자에 대한 공감이 중요하다는 것은 동의하면서도 현실에선 쉽지 않은 부분도 있긴 하다.

5장 제품으로서의 플랫폼

플랫폼의 경우 최고의 제품 아이디어가 여러분의 엔지니어들과 회사 내 다른 부서 엔지니어들로부터 나오는 경우가 흔하다. 따라서 작은 프로토타입(원형)을 발굴하고 그것을 더 많은 개발자가 유용하게 사용하도록 확장할 수 있는지 살펴보는 것이 새로운 제품을 발굴하는 유효한 방법일 때가 많다.

대기업이든 스타트업이든, 플랫폼 엔지니어링의 일환으로 제품 관리를 도입하려 한다면 첫 단계는 고객을 이해하고 존중하는 것이다. 좋은 제품을 만들려면 제품의 대상이 명확해야 한다. 하지만 내부 고객을 이해하기란 쉽지 않다. 매일 대화할 수 있는 사람들이지만, 그렇다고 그들이 자신이 원하는 것을 정확히 설명할 수 있다는 뜻은 아니다. 내부 고객은 문제가 생길 때만 불만을 표시하는 수동적인 소비자일 수도 있고, 자체 플랫폼을 구축하려는 능동적인 경쟁자일 수도 있다. 여러분은 동료이자 고객인 내부 사용자들을 만족시켜야 하지만, 그들이 요구하는 모든 것을 들어줘야 하는 것은 아니다. 플랫폼의 대상이 누구든, 그들을 이해관계자가 아닌 고객으로 보고 그들의 요구를 충족하는 제품을 만드는 것이 중요하다. 어떤 기업도 고객에게 제품 사용을 강요하지 않는다. 내부 시스템도 마찬가지이다.

플랫폼을 제품으로 보고 아이디어를 발굴하고 사용자의 요구사항을 알아내는 것은 어찌 됐든 핵심이다. 일반 B2C보다 사용자 수는 적지만 그렇다고 요구사항의 수가 적다거나 명확하다는 뜻이 아니기도 하다.

내부 고객을 상대하다 보면 제품의 성공 여부를 판단하는 데 사각지대가 생기기 마련이다. 더욱이 여러분의 일을 과소평가하거나 당연하게 여기는 고객을 상대하다 보면 추가적인 마찰이 발생한다.

플랫폼의 경우에는 고객층이 작을 뿐만 아니라 대개는 고정되어 있다. 내부 고객은 플랫폼 팀이 제공하는 제품을 사용할 수밖에 없다(고객이 자체적으로 플랫폼을 만들지 못한다). 팀이 내부 고객에게 원하는 것이나 플랫폼 제품에 대한 평가를 물어볼 수는 있지만, 동료에게 솔직하게 의견이나 불평을 제공하기란 쉽지 않다.

플랫폼 팀에 제공하는 제품을 사용할 수밖에 없다는 점이 중요하다. 이 부분을 잘못 해석하면 사용성이 좋다고, 필요성이 있다고 착각하기 쉽다. 물론 착각하지 않는 것인지 판단할 수 있는 기준이 없는 것도 사실이다. 결국 회사 내 동료이기 때문에 정말 솔직한 얘기를 다 하기는 쉽지 않다.

여러분이 아무리 노력해도 만족하지 않는 고객층이 존재한다.

실제로 그러므로 모든 걸 만족시키려고 해서는 안 된다.

고정된 고객층을 대할 때는 플랫폼 엔지니어링 팀이 실패하는 유형은 크게 두 가지이다. 첫째는 제품 도입률(adoption metric)을 완전히 무시하다가 나중에야 플랫폼 제품이 일부 고객에게만 유용하다는 사실을 깨닫는 것이다. 이는 '당연한' 기능으로 간주되지만 사실은 미완성인, 대다수 고객의 요구에 맞지 않는 제품들이 누적되는 결과로 이어질 수 있다. 둘째는 도입률만을 중요한 지표로 보고 이를 빌미로 고객에게 맞지 않는 시스템을 강요하는 것이다. 고정 고객층이 있다고 해서 그들이 필요로 하고 원하는 것을 만드는 노력을 게을리해서는 안 된다.

플랫폼 팀이 만드는 제품은 대부분 어려운 일을 쉽게 만들거나 아예 불필요하게 만드는 것이다. 그러다 보니 내부 고객은 개선 사항을 곧 잊어버리기 쉽다. 이는 고객이 영원히 만족하지 못하는 무한 루프로 이어질 수 있다. 플랫폼 팀이 병목 지점 하나를 해결하면 고객은 곧바로 다음 문제에 눈길을 돌린다.

또한 대부분의 사람은 이 모든 것을 잘 작동시키는 것이 얼마나 복잡한 일인지 이해하지 못하며, 뭔가 고장이 나기 전까지는 플랫폼을 당연하게 여긴다는 점도 잊지 말아야 한다. 무관심이 곧 고객 만족인(즉, 불만이 없으면 만족하는 것인) 경우가 많다.

마지막으로, 내부 고객이 때로는 경쟁자처럼 행동한다. 오타가 아니다. 플랫폼 팀의 고객이 엔지니어이면, 그리고 팀이 그들의 요구를 따라잡지 못하면, 고객은 팀과 조율하며 기다리기보다 필요한 것을 직접 만들어버릴 수 있다.

이 모든 것을 다 경험해 본 것 같다. 플랫폼의 유용성을 계속 객관적으로 고민해 보는 것, 정말 좋은 플랫폼을 만드는 것은 전체 라이프사이클에서 가장 중요한 일이다.

팀이 순전히 관계 모델에만 근거해서 다른 엔지니어링 팀을 위한 제품을 만드는 것, 즉 그냥 다른 팀이 원하는 것을 그대로 만들어 주는 것은 양측 모두를 실패로 이끈다. 대다수의 엔지니어링 팀은 자신들이 정확히 무엇을 원하는지 모른다. 요청한 것을 그대로 구현해 주어도 실제로 도입하지는 않을 수 있다.

나도 수없이 하던 말이다. 고객은 자신이 원하는 것을 정확히 알지 못하고 대부분은 문제의 원인보다는 해결책을 가져오기 때문에 원인을 정확히 알아야 한다. 그리고 OO가 안되어서 아직 쓸 수 없다고 말하는 대부분의 사용자는 OO가 생긴다고 해서 사용하지 않는다. 이건 B2C 제품에서도 똑같다고 생각하는데 그 말이 가짜로 말했다거나 그런 게 아니라 제품을 사용한다는 건 불편함보다는 필요성이나 유용성 때문이 훨씬 크다.

널리 쓰일 플랫폼을 만들려면 특정 고객의 요구사항을 넘어 일반화할 수 있는 문제를 파악하는 방법을 익혀야 한다.

앞에서 플랫폼이 opinionated여야 한다는 의미도 이 일반화할 수 있는 문제를 파악해서 그걸 해결하면서 생기는 마찰을 이겨내어야 하는데 또 그게 고집이나 오만이 아니라 실제로 잘 판단해야 한다.

핵심은 기술 자체가 아니라 기술을 사용할 사람들에 초점을 두고 고객 공감 문화(culture of customer empathy)를 조성하는 것이다.

과연 사람들이 원하는 것을 만들고 있는가? 그것을 어떻게 아는가?

내부 고객 대응의 모든 난제는 우리가 '기능 공장의 함정(Feature Shop Trap)'이라 부르는 상황에서 정점을 이룬다. 기능 공장의 함정이란, 플랫폼 팀이 좀 더 전략적인 제품 로드맵을 전달하는 데 필요한 타협안들을 밀어붙이는 대신, 고객들의 기능 요청을 처리하는 일에만 매몰되는 현상을 말한다.

어떤 면에서는 기능 공장이 되었다가 다시 빠져나오기를 반복하게 되는 것 같다.

전사적 클라우드 이전 계획과 같이 수요가 급증하는 상황에서는 어떨까? 이 경우 플랫폼 팀은 '선별 적용 모드(triage mode)'로 전환해서, 가장 많은 고객 그룹을 만족시키기 위해 자주 요청되는 클라우드 제품부터 처리하게 된다.

이런 문제에 골몰하다 보면 여러분은 갑자기 제품 관리 시간의 대부분을 그저 각각의 작업을 선택하고 정당화하는 데에만 사용하게 되며, 이 상황에서 벗어날 방법을 찾을 시간은 없어진다.

대체로 플랫폼 팀들이 이런 함정에 빠지는 이유는 두 가지 실수 때문이다. 첫째는 플랫폼 아키텍처가 추가 수요를 감당할 준비가 되기 전에 제품 도입을 확장하려는 압박에 굴복하는 것이고, 둘째는 고객의 요청이 구체적이라는 이유로 그 요청을 충실히 이행하는 것이 최선의 대응이라고 가정하는 것이다.

이건 정말 빠지기 쉬운 함정이다. 둘 다 실제로 의미 있기 때문이다. 플랫폼을 만들고 나서 지금 돌아보면 도입률을 늘리려는 유혹을 어느 정도 내려놓았던 게(내가 생각한 건 아니었지만...) 정말 좋은 수였다고 생각한다.

고객들이 요구사항을 제시하고 플랫폼 팀이 그것을 처리해서 해금해 줄 때까지 기다리는 데 익숙해지면, 그리고 도입률이 충분히 높아진 상황이라면, 플랫폼을 더욱더 셀프서비스화하기 위해 고객의 구체적인 요청을 뒤로 미루는 것을 정당화하기가 어려워진다.

이를 달성하려면 기능 요청들을 살펴보고 그 요청들이 대표하는 패턴을 생각해 봐야 한다. 플랫폼을 어떻게 발전시켜야 고객이 플랫폼 팀을 기다릴 필요 없이 특정 범주의 기능들을 스스로 구현할 수 있을까? 모든 고객의 기능 요청에 직접 대응하는 대신 이러한 더 광범위한 전략적 작업에 우선순위를 두는 것을 두려워하지 말아야 한다.

새로운 기능 요청은 가급적 해당 고객은 물론이고 미래의 고객 모두를 돕는 솔루션으로 이어질 만한 것일 때만 받아들이고, 협상이 필요한 일회성 맞춤 요구는 최대한 거부하는 것을 목표로 삼아야 할 것이다.

동의하고 계속 노력하지만, 구체적인 요구사항이고 이유가 있기 때문에 쉽지 않은 일이기도 하다.

플랫폼 엔지니어링 팀은 혁신의 최전선에 있는 '개척자(pioneer)' 역할을 담당하는 것이 아니라, '정착자(settler)'와 '도시계획가(town planner)' 역할을 수행한다. 즉 작은 그룹이 성공적으로 개척한 아이디어를 가져오면 그것을 좀 더 광범위한 팀들이 유용하게 사용할 수 있도록 확장하는 것이다 이를 위해 여러분이 장려해야 할 문화는, 아이디어의 출처에는 너무 집착하지 않고, 고객의 요구를 충족하는 최고의 제품 아이디어를 찾는 데 집중하는 것이다.

파트너 팀이 찾아와 그들의 다양한 문제를 해결할 무언가를 구축할 계획이 플랫폼 팀에 있는지 물어볼 가능성이 높다는 이점이 생긴다.

종종 아이디어의 출처에 집착하게 되는 모습이 생각나서 반성하게 되었다.

고정된 사용자층이 있음에도 플랫폼 팀은 고객들이 도입하지 않는 미완성 제품을 만드는 것으로 악명 높다.

나도 이런 경험을 많이 해봤다. 그래서 플랫폼을 잘 만들고 싶다고 생각했던 거 같다.

단순히 거친 가장자리를 다듬는 데만 집중하다 보면, 문제를 완전히 재고찰(rethinking)할 기회를 놓칠 수 있다. 프레임워크와 도구에서 플랫폼으로의 진화는 그 자체로 재고찰이다. 하지만 이 점을 완전히 받아들이지 못하는 플랫폼 팀도 있다. 고객의 삶을 편하게 만들어줄 코드 조각을 제공하는 데만 치중한다면, 소위 '가장자리 다듬기의 함정(edge-smoothing trap)'에 빠질 위험이 생긴다

우리는 여러분이 문제를 재고찰하는 것부터 제품 접근 방식을 시작하길 권장한다. 무언가를 더 쉽게 만드는 대신, 사용자가 이것에 대해 알 필요가 있는지 자문해 보라.

플랫폼의 레버리지는 운영을 통해 프로세스를 소유할 때만 제대로 발휘된다. 플랫폼 팀이 해결책의 일부만 지원한다면, 플랫폼 팀이 소비하는 예산과 인력을 정당화하기 힘들다.

문제를 재고찰하는 건 정말 중요하다 가장자리 다듬기라는 말도 맘에 드는데 플랫폼이 고도화되고 가만히 놔두면 이쪽으로 자연스레 흘러가게 되는 거 같다. 실제로 이게 의미가 있기 때문에 더 이렇게 된다. 그래서 계속 환기하고 해결하려는 본질적인 문제가 무엇인지 고민해 봐야 한다.

애초에, 고객들이 실무 그룹에 참석해서 제품이 어떤 모습이어야 하는지 정확히 말해주길 기대해선 안 된다. 그런 시도가 잘 안되는 이유는 여러 가지이다. 우선 고객들은 바쁘다. 그리고 상세한 요구사항 문서를 작성할 수 있는 제품 관리자도 아니다. 또한 고객이 현재 겪고 있는 문제를 설명할 수는 있다고 해도, 미래의 시스템을 어떻게 사용할지 추상적으로 추론하기는 어렵다. 대부분의 사람은 그 정도의 추상적 사고를 잘하지 못한다. 특히 한 번도 사용해 보지 않은 새로운 기술에 대해서는 더욱 그렇다.

어떤 경우이든, 고객에게 아이디어가 그들의 요구를 충족하는지 물어보는 대신 고객이 실제로 무엇을 원하고 필요로 하는지 파악하기 위해 더 큰 노력을 기울이는 것은 항상 필요한 일이다.

이건 취향이면서 내 약점이라고도 생각하는데 이쪽의 생각이 아주 강해서 난 잘 물어보지 않는다. 말로 나오는 것보다는 행동을 관찰하고 거기서 문제의 근원을 찾아봐야 한다고 생각하는 편이다. 그래도 물어봐서 쉽게 해결할 수 있는 부분도 있는데 이쪽으로 편향이 심한 거 같아서 고민하는 부분이기도 하다.

이 책에서 마이그레이션을 자주 다루는 이유는 이것이 플랫폼 엔지니어링의 핵심적인 부분이기 때문이다.

제품 관리자는 제품 결정을 내릴 때 마이그레이션 비용을 고려해야 한다. 이 점을 주의하지 않으면, 마이그레이션 비용 때문에 새로운 제품이 제공하는 가치가 사소하게 보일 수 있다.

마이그레이션은 정말 중요하다. 뭔가 만들 때 마이그레이션까지 한꺼번에 고려해야 하는데 마이그레이션 비용은 언제나 생각했던 것보다 너무 크다.

6장 플랫폼 운영

사내 코드나 OSS, 벤더 시스템, 또는 이들 간의 상호작용으로 인한 문제를 신속히 진단하고 해결할 수 있는 온콜 인력은 누구여야 하는가? 우리의 답은 통합된(merged) 팀만이 지속 가능한 방식으로 필요한 수준의 전문성을 갖춘 온콜 순환 근무 스케줄을 운영할 수 있다는 것이다.

지금 소속된 팀을 통합된 팀으로 운영하는 것이 여전히 맞다고 생각한다.

우리의 경험으로 볼 때, 24시간 연중무휴 온콜이 지속 가능하려면 비즈니스에 영향을 미치는 호출(이하 간단히 비즈니스 영향 호출)이 주당 5건 미만이어야 한다.

우리는 주당 5건을 넘는 요청들이 이어지는 온콜 업무는 지속 가능하지 않다고 굳게 믿는다.

5건? 5건? 흠... 나에게 온콜은 아직 고민 중인 영역이다.

사용자가 자신들만큼 플랫폼에 대해 생각하고 있다고 믿는 플랫폼 팀은 더 나은 플랫폼을 만드는 데 도움이 되는 방식으로 사용자의 문제에 접근하지 못하고 있는 것이다. 사용자의 문제로부터 격리된 채 일하는 엔지니어들은 그런 사고방식에 빠지기 쉽다.

플랫폼 팀이 기능 개발과 운영 투자의 균형을 맞춤으로써 운영 문제가 심각해지는 것을 미리 방지하는 데 도움이 되는 네 가지 필수 관행을 살펴본다. 이 관행들은 운영 중인 애플리케이션(프로덕션 애플리케이션)의 수명 주기(lifecycle)에 관한 것이다. 첫째는 SLO와 SLA를 요구사항들에 기반해서 작성하는 것이고, 둘째는 변경을 관리해서 릴리스의 고품질을 보장하는 것, 셋째는 합성 모니터링을 이용해서 기본적인 관측성을 제공할 뿐만 아니라 실행 중인 시스템의 장애를 적극적으로 감지하는 것, 마지막은 운영 검토를 통해 최근 이력을 살펴보고 잘된 점과 그렇지 않은 점을 검토하여 향후 작업과 주력 분야에 반영하는 것이다.

우리 저자들은 오류 예산이 과대 평가되었으며 활용 비용에 비해 충분한 이점을 주지 않는 경우가 많다고 생각한다.

SRE 책에서 오류 예산에 감명받기는 했지만 실제 적용을 고민할 때는 회의적으로 되었는데 오류 예산은 이제 크게 생각 안 해도 되겠단 생각이 들었다. 운영의 필수 관행을 꼽씹어 볼 가치가 있다.

플랫폼 팀이 내부적으로 SLO를 사용하는 방식과는 정반대라는 점이다. 내부적으로는 시스템의 운영 조건과 위험을 이해하는 것이 가장 중요하다. 따라서 대신 다음 세 가지 규칙을 따라야 한다. • SLO가 많을수록 좋다(네댓 개보다는 훨씬 많이). 시스템 포괄도(coverage)를 최대화하기 위해서이다. • 거짓 양성을 최소화하지 않는다. 중요한 문제를 놓칠 수 있기 때문이다. • 거짓 음성과 거짓 양성 모두 설명과 개선이 필요하다. 거짓 양성 때문에 운영 부하가 너무 높아지지 않도록 하기 위해서이다.

내부 SLO에 대한 명확한 기준을 주어서 좋았다. 그리고 거짓 양성에 관해서 민감하게 다루던 편인데 이 말을 보고 다시 생각해 보게 되었다.

프로덕션에 대한 모든 변경(change) 사항은 코드 변경의 모범관행에서처럼 엄격한 관리가 필요하다.

정말 중요하다.

릴리스 엔지니어링에 몰두하면, 플랫폼 자동화가 어느새 완전한 기능을 갖춘 그림자 배포 플랫폼으로 바뀌게 된다. 이는 작업 중복의 비용을 넘어 정치적 문제까지 야기할 수 있다. 중복에 대한 기술적 이유가 타당하더라도 문제가 된다. 플랫폼 엔지니어링 팀이 자신들의 제품을 신뢰하지 않는다는 인상을 주며, 여분의 엔지니어가 많아서 자체 그림자 플랫폼까지 구축할 수 있다는 인상을 준다. 플랫폼 팀이 한 해에 12개월 이상의 개발자 시간을 릴리스 엔지니어링에 쓰고 있다면 과도하게 구축하고 있는 것일 수 있다.

릴리스 엔지니어링이라고 부르진 않지만 비슷한 일에 몰두하고 있어서 이 말의 의미를 고민해 보고 있다. 사실 저자의 의도를 명확하게 이해하진 못했다.

플랫폼에서 더 많은 투자가 필요한 관측성 측면이 하나 있다. 바로 합성 모니터링(synthetic monitoring)이다. 능동적 모니터링(active monitoring)이라고도 불리는 합성 모니터링은 실제 프로덕션 플랫폼과 상호작용하는 사용자를 시뮬레이션한다. 지연과 가용성뿐만 아니라 기능의 정확성도 측정하며, 목표치를 달성하지 못하면 경고를 발생한다.

합성 모니터링의 유용성은 알지만, 아직 잘 관리하는 방법은 못 찾았다.

여기에 운영 검토(operational review)라는 관행을 추가하면, 데이터를 바탕으로 행동을 이끌어내는 하나의 피드백 루프가 완성된다. 운영 검토는 숙련된 운영 조직들에서 배운 관행이다. 엔지니어와 관리자가 정기적으로(보통 매주) 모여서 SLO 지표 같은 광범위한 지표와 사고 사후 분석과 같은 구체적인 사항을 검토한다.

팀 수준 운영 검토는 단순하고 엄격하게 유지하라 팀 수준에서 운영 검토의 기본은 매주 30분 또는 60분 동안 다음 사항들을 검토하는 것이다.

조직 수준의 검토는 필수적이지만, 프로세스보다는 관행을 중시하라.

운영 검토라는 건 여기서 처음 배웠지만 포스트모텀이라고 하면 이해하기 어렵진 않다. 이런 운영 검토가 중요하다는 것은 동의하지만 실제로 하려면 또 회의가 너무 많아져서 조직 문화에 잘 자리 잡게 하는 건 쉽지 않다.

7장 계획과 전달

사용자들보다 자신들이 더 잘 안다고 가정하는 상아탑적 사고방식도 있었다

새로운 플랫폼 프로젝트를 시작할 때는 다음과 같은 골의 법칙(Gall's law)을 명심하는 것이 좋다. 잘 작동하는 복잡한 시스템은 모두 잘 작동하던 단순한 시스템을 진화시킨 것이다. 그 역도 마찬가지이다. 복잡한 시스템을 무無에서 출발해서 설계하면 절대로 잘 작동하지 않으며, 잘 작동하게 만들 수도 없다. 반드시 잘 작동하는 단순한 시스템에서 다시 시작해야 한다.

플랫폼이 고도화될수록 단순한 시스템에서 시작하는 건 중요한데 또 고도화되어 있기 때문에 잘 먹히지 않는 것도 사실이다.

플랫폼 팀은 모든 요구사항을 충족하는 범용 시스템을 구축함으로써 모두를 만족시키는 것이 자신들의 임무라고 생각하기 쉽다. 그래서 제2장에서 설명한 해결책 중 하나를 선택하는 대신, 포장도로(paved path) 방식과 철도(railway approach) 방식을 둘 다 선택하는 실수를 저지르곤 한다. 한 가지 접근 방식을 선택하지 못하면 결국 당면한 요구를 충족시키지 못하게 된다.

"빨리 움직이고 실수를 저질러라"라는 태도를 권장하는 스타트업에서 리더가 제품을 만들 때 제품 적합성을 찾아 허둥대는 것이 큰 흠이 아닐 수 있다. 하지만 플랫폼 세계에서는 이런 행동이 플랫폼 팀의 평판을 나쁘게 만든다.

범용 시스템은 안된다.

전달이나 운영상의 압박이 없는 팀이라면, 고객 가치의 전달이 제대로 이루어지는지 확인하는 계획 하나만 있어도 충분할 것이다. 하지만 팀이 전달이나 운영의 측면에서 압박을 받는 상황이라면 제품 로드맵 외에 상향식 로드맵(bottom-up roadmap)이라는 좀 더 세부적인 로드맵이 필요하다.

추정이 필요한 세 가지 작업 영역을 설명할 것이다. 첫째는 시스템과 서비스를 원활하게 유지하는 데 필수적인 운영 작업인 KTLO(keep the lights on; 점등 유지) 작업이다. 둘째는 경영진이 하달한, 타협이 (거의) 불가능한 프로젝트인 경영진 지시사항(executive mandates)이다. 셋째는 플랫폼의 운영, 효율성, 보안, 신뢰성, 규정 준수를 개선하는 시스템 개선(system improvement) 작업이다.

난 계획을 세밀하게 세우진 않는 편이라서 큰 맥락에서는 동의하지만, 제일 관심 간 건 KTLO이다.

핀옵스 작업이 복잡하긴 해도, 이를 전담 업무로 삼으라고 하면 대부분의 시스템 엔지니어는 반기지 않을 것이다. 프로덕션 시스템 측면에서 충분히 '실무적(hands-on)'이지 않기 때문이다. 그들이 정말 좋아하는 것은 효율성 개선의 둘째 범주인 성능 엔지니어링(performance engineering)이다.

핀옵스 업무도 현재 팀에서 하고 있는데 이건 정말 어렵다. 우리 업무인 듯 아닌 듯 묘한 위치에 있어서 핀옵스 팀이 따로 있는 다른 조직은 어떻게 운영하는지 정말 궁금하다.

플랫폼 팀이 KTLO가 아닌 프로젝트의 시간을 증분(점진적) 작업, 대규모 아키텍처 프로젝트, 전혀 새로운 플랫폼에 배분할 때는 구글의 70/20/10 모델(https://oreil.ly/zPJsK)을 참고하면 좋다. • 70%는 핵심 이니셔티브(현재 플랫폼의 증분 작업) • 20%는 핵심과 인접한 혁신(플랫폼 아키텍처 재구축) • 10%는 변혁적 혁신(transformational innovation; 완전히 새로운 플랫폼)

이렇게 할 것은 아니지만 적당한 비율은 고민해 볼 때 도움이 된다.

문제가 된 라이브러리를 조사한 카미유의 팀은 이 작성자가 디스커버리 서비스 API 범위를 벗어난 주키퍼 기능을 사용하기 시작했다는 것을 알게 되었다. 이는 두 가지 교훈을 동시에 주었다. 하이럼의 법칙(Hyrum's law)이 진리임을 깨달았을 뿐만 아니라, 플랫폼 생태계의 일부인 코드를 내부소싱하는 것이 위험하다는 점도 배울 수 있었다. 내부소싱의 기본 개념은 오픈소스 소프트웨어처럼 누구나 코드베이스에 기여할 수 있게 함으로써 개발자들이 스스로 해금할 수 있게 하는 것이다. 경영진은 "기능을 기다리며 막혀있는 사람은 누구나 직접 코드를 작성하여 기여할 수 있다!"라고 말하면서 자신이 협업에 개방적으로 보일 수 있다는 점에서 이 모델을 선호한다.

여기서 내부 소싱이라는 것은 InnerSource를 얘기하는 것인데 경영진에게 이러한 문화가 매력적으로 보일 수 있다는 점은 생각해 본 적 없긴 하다.(실제로 그런가?) InnerSource에 대해서 발표한 적도 있고 어느 정도 지지하지만, 또 플랫폼 관점에서 나는 하이럼의 법칙을 피하려고 외부 호환성을 최대한 줄이고 있어서 실제 이 책이 말하는 것처럼 하고 있다는 걸 깨달았다.

8장 플랫폼 아키텍처 재구축

그런 영역 중 하나라도 계속해서 성장한다면, 시스템의 아키텍처가 결국 병목 지점이 될 것이다. 이것이 우리가 아키텍처 재구축(rearchitecting)이라고 부르는 접근 방식을 채택하는 이유이다. 이것은 시스템을 중단 없이 가동하면서(부하를 계속 처리해 나가면서) 아키텍처를 반복적, 점진적으로 재구현하는 과정이다.

일반적인 플랫폼 엔지니어링 팀 문화에서 v2를 설계하고 전달하는 것의 어려움을 고려하면, 아키텍처 재구축이 결국 올바른 접근 방식이라고 본다. 1964년에 처음 관찰된 제 2 시스템 효과(second-system effect)라는 잘 알려진 현상부터 살펴보자. 시스템의 버전을 하나만 구축한 팀은 두 번째 시도에서는 모든 결함을 해결할 수 있다고 가정하는 경향이 있다.

지금 플랫폼이 어찌 보면 완전히 새로 만든 v2라고도 할 수 있고 이 내에서 재구축을 해본 적도 있는데 결국 플랫폼의 접근을 했을 때는 재구축이 정답이라는 것에 동의한다.

애플리케이션 엔지니어가 억지로 '보안을 인식하도록' 요구하지 않는다. 대신 시스템 설계를 가장 강력한 레버리지 지점으로 삼아, 보안을 플랫폼의 기능과 아키텍처에 녹여내서 자연스럽게 만든다.

'설계에 의한 보안'이 아니라, '보안이 기본(secure by default)'인 애플리케이션을 만들어야 한다. 보안을 위한 회복력이 기본이 되게 하려면 개발자들이 반드시 안전한 옵션들을 옵트아웃으로 취급해야 한다. 여러분은 개발자들이 그런 쪽으로 이동하도록 계기를 제공하되('넛지nudge'), 예외는 허용해야 한다.

올해 국내에 보안 이슈가 많기도 했지만, 원래도 관심 있는 부분이라 이 말처럼 하고 싶은데 보안 쪽은 내 전문 영역은 아니라서 그런지 꽤 어렵다. 몇 년 내에 해결하고 싶은 이슈이기도 하다.

'최소 저항' 경로의 인기 있는 명칭이 포장도로(paved path)이다. 포장도로는 일반적인 문제들에 대한 잘 통합되고 지원되는 하나의 해결책으로, 사람들이 고유한 가치 창출에 집중할 수 있게 한다. 특정 옵션을 기본값으로 지정함으로써(이때 중요한 점은 회복력 있는 방법이 더 쉬운 방법이 되도록 하는 것이다), 여러분은 표준화를 촉진하고 선택의 과부하를 줄이게 된다. 이에 의해 조직의 기본값을 더욱 회복력 있게 구성할 수 있다(심지어 일부 팀이 안전한 옵션을 명시적으로 거부하는 경우에도).

아키텍처 재구축이 성공하려면 기존 사용자의 서비스 이용에 미치는 영향을 최소화해야 한다. 가장 이상적인 경우는 사용자가 변경 사실을 전혀 눈치채지 못하는 것이다.

이건 경험을 통해서도 동의한다. 항상 사용자가 변경을 모르도록 하는 것을 최우선으로 고민해야 하고 이를 통해서 플랫폼의 가치를 훨씬 더 증명할 수 있다.

플랫폼 팀이 범하는 안티패턴을 하나 짚고 넘어가려 한다. 바로, 새로 채용된 엔지니어들에게 플랫폼의 아키텍처 재구축을 맡기는 것이다. 특히 이전 직장에서 다음 단계의 플랫폼 성숙도를 경험했고 현재 상태에 대해 훌륭한 통찰력을 제시하는 신입 직원의 경우 더욱 그렇다.

이건 무조건 안티 패턴.

9장 플랫폼 마이그레이션과 폐지 처리

뛰어난 플랫폼 팀은 이러한 도전 속에서 마이그레이션을 오히려 자신들의 가치를 입증할 기회로 삼는다. 팀은 필수적인 마이그레이션에 따르는 고객의 고통을 덜어주고, 고객들이 핵심 기능의 전달에 집중할 수 있도록 작업량을 줄이거나 없애는 것을 자신들의 임무로 여긴다.

나도 마이그레이션을 힘들어하는 편인데, 여기에 가치를 주고 마이그레이션이 중요하다는 인식을 공유하는 것이 중요하다.

플랫폼 추상화(platform abstraction)를 잘 구축했다면, 바탕 구성요소들을 마이그레이션할 때 애플리케이션 팀이 변경해야 할 자체 접착제가 최소화된다. 같은 시스템의 서로 다른 버전의 수를 제한하면 해당 시스템을 변경할 때 수행해야 할 테스트가 줄어든다. 버전들을 표준화하고 제한할수록 이러한 변경 시 걱정해야 할 조합이 줄어든다.

고객에게 가장 좋은 마이그레이션 경험은 고객이 해야 할 일이 따로 없는 것, 더 나아가서 마이그레이션이 일어나는 것조차 알아차리지 못하는 것이다.

아까도 말했듯이 실제 이 방법으로 플랫폼의 가치를 증명하고 사람들이 플랫폼으로의 마이그레이션을 더 선호하도록 만들 수 있었다.

세계의 상태에 대한 메타데이터를 수집하고, 무엇이 어디에 배포되어 있는지 파악하며, 배포를 위한 코드를 사람과 팀에 연결하는 방법을 이해하는 것, 이 모든 것이 플랫폼 엔지니어링 여정의 초기에 수집해야 할 강력한 지식이다.

수년간 많은 사람이 입사와 퇴사를 거듭하다 보면, 여전히 쓰이고 있지만 누구도 소유권을 가지지 않은 기술 자산들이 생긴다.

이러한 '조직적 표류(organizational drift)' 때문에 플랫폼 자체의 발전이 저해되는 것은 플랫폼 엔지니어링의 숨겨진 난제 중 하나이다.

처음 만들 때 이런 장기적 고민까지 한 것은 아니지만 초기에 여기서 말하는 메타데이터를 추적하고 갱신한 방법을 준비해 놓은 것은 많은 도움이 된다고 생각한다.

많은 프로젝트가 그렇듯이, 마지막 20%가 처음 80%보다 더 어려워 보일 수 있다(그리고 마지막 5%는 거의 불가능해 보일 수도 있다). 아마도 남아 있는 것은 위험도가 가장 높거나, 가장 오래되었거나, 가장 중요하거나, 가장 많이 커스텀화된 애플리케이션일 것이다.

내가 만드는 플랫폼에서 지금 마지막 20% 마이그레이션을 고민하고 있는 시점이라서 더 공감된 부분이다.

어쩌면 이렇게 생각하는 독자도 있겠다: "이 마이그레이션은 아주 중요하니, CTO에게 말해서 모든 사람이 이 마이그레이션을 의무적으로 완료하라고 지시하게 만들면 되지 않을까?

우리의 조언은, 필수적인 사항에 대해서만 의무화를 요청하고, 가능하다면 다른 필수 과제를 만족시키는 것과 연계하라는 것이다

플랫폼 팀이 의무화 접근 방식을 너무 자주 사용하는 것은 바람직하지 않음을 유념하자. 너무 자주 사용하면, 애플리케이션 엔지니어들이 비즈니스를 위해 일하는 것이 아니라 플랫폼 팀의 프로젝트를 위해서만 존재하는 것처럼 보이는 문화가 조성될 수 있기 때문이다.

초기에 나도 이러고 싶은 충동을 많이 느꼈지만, 지금은 절대 선호하지 않는다. 선호하지 않는 이유는 내가 서비스팀에 있는데 이런 지시를 받는다면 동의하지 않을 것이기 때문이다.

10장 이해관계자 관리

제품 관리는 고객을 위해 올바른 것을 만드는 것이고, 이해관계자 관리는 리더들에게 여러분의 선택이 옳다고 납득시키는 것이다.

여러분의 팀이 다른 지도층이나 엔지니어링 팀들의 방해 없이 필요한 플랫폼을 구축할 수 있도록 보장하고 싶다면, 이해관계자들과의 관계를 잘 관리하는 것이 필수이다.

한쪽만이 원하는 것을 얻게 되는 중요한 의사결정 과정에 여러 번 참여했고, 동료들이 회사의 이익이 아니라 자신의 경력과 영향력을 위해 엉뚱한 주장을 펼치는 것처럼 보이는 모습도 목격했다. 하지만 우리가 존경하는 동료들도 이런 사리사욕으로 비난받는 것을 보았고, 심지어 우리 자신도 그런 비난을 받은 적이 있다. 우리는 여기에 회사가 '정치'를 만들어내는 '얼간이(jerk)'들을 채용한 실수 이상의 문제가 깔려 있음을 깨달았다.

이제 우리는 이 문제가 개인보다는 조직의 크기와 더 관련이 있다는 것을 이해한다.

이는 강력한 기업 문화가 있더라도, 여러분이 보기에 '회사를 위한' 올바른 결정이 다른 사람의 관점에서는 그렇지 않을 수 있는 상황이 필연적으로 발생한다는 것을 의미한다.

이해관계자 관리는 갈등이 발생했을 때 동료들이 자기 팀의 불만만 듣고 모든 것을 여러분의 탓으로 돌리지 않도록 여러분의 관점과 맥락을 이해시키는 활동이다.

이해관계자가 여러분을 내부 벤더(internal vendor)로 간주하고, 자신의 업무가 얼마나 중요한지를 여러분이 이해하지 못한다고 생각한다.

이해관계자가 여러분의 일을 자신이 더 잘할 수 있다고, 그래서 여러분의 팀을 더 잘 관리할 수 있다고 생각한다.

이해관계자에 관한 건 내가 잘 못하는 부분이라서 곱씹어보는 목적으로 남겨둔다.

이해관계자가 여러분의 성과를 인정하지 않는다. 어제 여러분이 해준 일이나 1년 전보다 얼마나 플랫폼이 개선되었는지를 잊어버리는 이해관계자들이 있다. 특히 더 많은 개선이 필요하거나 아직 해결되지 않은 문제가 있을 때, 문제가 없어진 것을 알아차리지 못하는 것은 인간의 본성이다.

인간의 본성이라는 것에 동의한다. 종종 서운한 맘이 들 수 있지만 그런 부분은 덜 신경 쓰는 게 좋다.

이해관계자들은 자신이 비즈니스 수익과 성장에 더 가까이 있으므로 비즈니스에 '옳은' 것을 내부용 플랫폼 팀보다 더 잘 이해한다고 생각하기 마련이다. 그런 이해관계자들이 비합리적이라는 생각도 들겠지만, 여러분이 그들의 관점을 잘 고려하고 있다고 느끼게 하도록 신중하게 대응해야 한다.

플랫폼 리더들은 종종 비즈니스 영향에 대해 안이한 태도를 보인다.

플랫폼 소유자로서 피해야 할 두 가지 극단이 있다. 항상 "예"라고 말하는 기능 공장이 되는 것 첫째는 들어오는 모든 요청에 즉각 반응하여 최대한 빨리 기능이나 서비스를 덧붙이려 하는 '반응적 극단(reactionary extreme)'이다. 비전에 대한 헌신보다 당장의 만족을 주려는 충동이 더 강하면 이런 상황이 될 수 있다. 회사에 대한 가치를 완벽하게 판단한다는 생각에서 항상 "아니요"라고 말하는 것 그 반대편 극단은 플랫폼 소유자가 완전히 경직되어서, 자신이 옳다고 생각하고 플랫폼 전략에 부합하는 것만 구축하는 것이다.

항상 고민하는 부분이다. 항상 예라고 하는 것은 쉽지만 결국 플랫폼에 문제가 생길 것이고 아니요라고 하면 잘못하면 신뢰를 잃게 된다.

아직은 안 됩니다, 우선순위 때문에요. 우선, 아예 안 되는 것인가, 지금 당장은 안 되는 것인가를 구분해야 한다. 때로는 가치 있고 하고 싶은 요청이지만 현재로서는 우선순위를 매기기 어려울 수 있다. 이런 경우 언제쯤 전달이 가능할지, 그리고 더 빨리 필요하다면 어떤 대안이 있는지 명확히 알려줘야 한다.

아직은 안 됩니다, 기술적인 문제로요. "아직은 안 됩니다"의 다른 버전으로, 기술적으로 준비가 안 된 경우이다.

안 됩니다, 제품 전략상 문제로요. 모든 것을 플랫폼에 포함할 필요는 없다. 누군가 관심을 보인다고 해서 모든 기능을 수용하는 '제국 건설자(empire builder)'가 되려는 유혹을 이겨내야 한다. 제품의 핵심 임무를 이해하고, 그에 맞지 않는 것은 거절해야 한다.

안 됩니다, 기술적으로 불가능해요. 마찬가지로, 기술적으로 실현 불가능한 사항이라면 그 점을 지적해야 한다. 플랫폼 팀의 리더급 직책에 이전 엔지니어 출신을 포함하는 것이 바람직한 이유가 바로 이것이다.

도움을 주지 못하더라도, 그들의 문제에 관심이 있다는 것을 보여주는 것이 향후 관계에 중요하다. 따라서 아예 대화를 끊어버리는 태도는 피하는 것이 좋다.

아니요라고 하면서도 계속해서 기능 요청과 이슈를 편하게 요청하게 하는 신뢰 관계는 계속 필요하다. 이 관계가 구축되지 않는다면(보통 쉽지 않다) 인프라나 플랫폼 팀은 항상 아니요라고 말할 거니까 물어볼 필요도 없다고 판단하고 다른 방법을 찾게 된다.

이해관계자들과의 최악의 관계 중 일부는 '그림자 플랫폼(shadow platform)' 구축과 관련해서 빚어진다. 앞 장에서 설명했듯이 그림자 플랫폼은 현재 플랫폼의 기능을 복제한 시스템이다. 현재 플랫폼과는 다른 OSS와 벤더 기술을 사용할 때가 많으며, 기능 집합(feature set)이나 시스템 특성(비용, 성능, 신뢰성)이 조금 다를 때도 있다.

플랫폼 팀의 '거절' 뒤에 숨은 운영 비용을 이해하지 못한다. 때로는 팀이 여러분의 거절을 듣고도 그것을 구축하기로 결정한다. 운영 비용이 그들이 예상한 것보다 훨씬 클 것이라고 확신함에도 말이다. 플랫폼 팀의 관점에서, 그런 팀의 잘못된 판단은 대단히 짜증스럽다. 특히 이것이 결국 여러분이 지원해야 할 무언가로 부메랑처럼 돌아올 것을 알 때 더욱 그렇다.

문제에 가까이 있는 사람들로부터 좋은 아이디어를 많이 건질 수 있다는 점을 기억하자. 때때로 여러분의 팀은 구현은 의심스럽지만 아이디어 자체는 좋은 사례들을 발견하게 될 것이다. 뒷정리가 필요할 때는 그것을 기회로 받아들이자.

이 부분은 나에게는 스트레스인 부분이기도 하다. 특히 숨은 운영 비용에 대해 설명하는 것이 자칫하면 생색내는 거 같기도 해서 말하기가 쉽지 않은데 알아서 알아주지도 않는 부분이다. 그리고 예상한 대로 결국 부메랑처럼 지원해야 하는 영역으로 돌아올 때 더 힘들다. 이 부분은 마지막에서 좀 힌트를 얻었다. 너무 부정적으로만 보면 해결될 것도 없는데 거기서 아이디어를 발견할 수 있다는 생각을 해보는 것도 좋을거 같다.(어느 정도까지만..)

3부 성공은 어떤 모습일까?

80%의 사용자를 만족시키는 '포장도로'를 만들어도 나머지 20%는 자신의 요구사항이 반영되지 않았다며 불평한다.

실제로 그러하다. 그게 큰 문제라는 게 아니라 그냥 그러하다.

우리는 플랫폼 엔지니어링의 성공을 이야기할 때 교과서적인 '지표와 측정(metrics and measures)'을 주된 기준으로 삼는 것에 반대한다.

동의하는 부분이다. 지표와 측정은 중요하지만 조심하는 편이라 그런지 아래 말이 더 와닿았다.

우리는 다음 네 가지 영역에 초점을 두고 지속적인 성공을 평가하는 총체적인 접근 방식을 권장한다. • 플랫폼이 정렬되어 있는가? • 플랫폼이 신뢰받는가? • 플랫폼이 복잡성을 관리하는가? • 플랫폼이 사랑받는가?

11장 플랫폼의 정렬

정렬(alignment)은 플랫폼 엔지니어링 팀의 성공을 총체적으로 평가하는 첫째 기준이다. 모든 플랫폼 팀에 대해 "팀원들 모두가 팀이 하는 일에 정렬되어 있는가?"라는 질문을 던져야 한다.

정렬은 흔히 다음 세 영역에서 실패한다. 목적 제품 접근 방식에 따라 비즈니스의 토대가 되고 폭넓은 고객층을 지원하는 소프트웨어 기반 추상화를 개발한다는 총체적인 사고방식(holistic mindset)을 가지지 못하고 그보다 좁은 관점으로 운영되는 플랫폼 팀은 목적(purpose)에 대해 정렬되지 않은 것이다. 제품 전략 사일로로 운영되며, 특정 목적에는 좋지만 불필요하게 다른 것들과 중복되거나 플랫폼 간 용례(use case)를 어렵게 만드는 플랫폼을 구축하는 플랫폼 팀은 제품 전략(product strategy)에 대해 정렬되지 않은 것이다. 계획 수립 가장 중요한 프로젝트를 실행할 때 서로 지원하지 않고 오히려 서로의 길을 방해하며, 일정과 상황 변화에 대해 고객과 잘못된 소통을 하는 플랫폼 팀들은 계획 수립(planning)에 대해 정렬되지 않은 것이다.

조직에서 정렬은 어려운 일인데 이런 식으로 구분해서 고민해 보는 건 도움이 되는 거 같다.

도입률에 집중하다 보면 플랫폼 팀은 미래의 플랫폼을 결정하고, 그 사용률을 100%까지 끌어올리고, 다른 모든 것을 최대한 빨리 폐기하는 것이 자신의 유일한 임무라고 여기기 시작할 수 있다. 하지만 100% 도입률은 고객이 플랫폼 사용 여부를 선택할 수 있을 때만 진정한 성공의 지표가 된다.

다른 발표에서도 얘기한 적이 있지만 배포 플랫폼을 만들면서 의도는 아니었지만 기존 배포 플랫폼도 그대로 놔두게 되었는데 선택권이 있다는 면에서 결과적으로는 새 배포 플랫폼에도 좋은 영향을 주었다.

내부 사용자를 단순한 이해관계자가 아닌 고객으로 대하고 고객과의 파트너십 기회를 통해 새로운 제품을 발굴하는 제품 관리 문화를 조성함으로써 여러분은 '우리 대 그들'이라는 사고방식을 깨고, 훌륭한 플랫폼 제품을 만드는 데 필요한 공감(empathy)을 발전시킬 수 있다.

공통 기능의 중복이 항상 문제가 되는 것은 아니다. 하지만 플랫폼들이 단순히 중복을 넘어 충원을 정당화하기 위해 같은 고객을 놓고 적극적으로 경쟁한다면, 이는 전체적으로 제품 전략이 부실하다는 뜻이다.

기능 중복에 대한 고민의 원인을 좀 깨닫게 해주는 말이었다.

아키텍처 검토 위원회(architecture review board, ARB)에 만연한 관료주의는 우리도 그리 반기지 않지만, 플랫폼 엔지니어링 조직의 최고 '수석/우수(principal/distinguished)' 엔지니어가 제품 관리 책임자와 같은 상급 리더에게 보고하도록 하는 것이 유용하다.

조직 보고 체계에 대해서는 잘 이해 못했지만, 만연한 관료주의는 피해야 할 부분이다.

12장 플랫폼에 대한 신뢰 구축

대규모의 기반(토대) 시스템 운영 능력은 실제로 그것을 운영해 봐야만 얻을 수 있다는 점이다.

일반적인 80%의 용례를 위한 풍부한 플랫폼을 구축하고 그 밖의 용례는 예외 사례로 제한함으로써, 팀이 그런 병목을 더 빠르게 해결할 수 있었다.

플랫폼을 처음 만들 때 80%를 목표로 했는데 이 말에 더 힘을 얻었다. 물론 현실에서는 80%가 높다는 판단해서 지금은 그보다는 좀 더 낮게 잡고 있다.

우리는 신뢰 구축 실패를 플랫폼 리더가 회사를 실망시키는 가장 흔한 방식 중 하나로 간주한다. 잘못된 리더는 자신의 오만함 때문에 자신이 누구보다 더 잘 안다고 믿으며, 적절한 투명성을 가지고 소통하려 하지 않고, 고객과 이해관계자의 의견은 무시한 채 자신의 팀만 신뢰한다.

13장 복잡성을 관리하는 플랫폼

플랫폼 엔지니어링이 필요한가? 플랫폼 엔지니어링은 복잡성 문제에 총체적으로 접근하여, 소프트웨어 및 시스템 전문가 팀이 애플리케이션 팀에 대한 복잡성의 부담을 줄일 수 있게 해주기 때문이다.

플랫폼이 모든 복잡성을 제거하는 것은 아니다. 플랫폼은 복잡성을 없애는 것이 아니라 효과적으로 관리(managing)함으로써 레버리지를 만들어낸다.

플랫폼을 성공으로 이끄는 길에서 여러분이 관리해야 할 네 가지 영역의 복잡성을 살펴본다. • 우발적 복잡성(accidental complexity). 플랫폼이 복잡성을 해결하려다 문제를 다른 곳으로 옮기기만 하고, 종종 사람들에게 새로운 작업을 만들어내기도 한다. • 그림자 플랫폼. 애플리케이션 조직이 민첩성을 유지하면서도 유사한 그림자 플랫폼이 많이 생겨나는 복잡한 결과를 피하려면 균형을 섬세하게 맞추어야 한다. • 통제되지 않은 성장. 플랫폼 조직이 오늘 만들어 낸 기술 부채를 내일 채용할 새로운 엔지니어가 해결할 것이라는 가정만으로 복잡성을 관리해서는 안 된다. • 제품 발견. 일부 문제의 경우 고객과 플랫폼 팀 모두에게 복잡성을 줄여주는 제품을 만들기 위해서는 전달을 반복적으로 시도해야 한다.

모든 것을 하나의 UI로 통합해서 사용자의 인지 부하를 줄이는 것은 불필요한 복잡성을 제거하는 현명한 방법처럼 보인다.

시간이 지나면서 팀의 '단일 창구'는 개발자가 자신이 원하는 UI에 도달하기 위한 추가적인 경유지로, 또는 기존 도구의 열등한 버전으로 전락했다.

다양한 개발자 요구를 창구를 단일화해서 통합하는 것은 바람직하지 않다. 다른 방식으로 일반화하는 것이 좋다. 그런 방식으로 개발자 경험을 구축하는 것이 가능한 시나리오도 있겠지만, 어떤 경우이든 목표는 단일 창구 자체가 아니라 사용자가 필요한 모든 것에 손쉽게 접근할 수 있는 인체공학적 설정이다.

단일 창구는 계속 목표로 해왔던 부분이라서 책에서 얘기하는 것과는 약간 다르다고 생각하지만, 다시 생각해 보게 되었다. 그럼에도 여전히 창구가 너무 많은 건 문제라고 생각하는 편이다.

접착제를 줄이려면 플랫폼은 각 애플리케이션 팀이 자체적으로 구축할 필요가 없는 추상화를 만들어 내야 한다. 접착제가 전체적으로 줄어든다는 것은 플랫폼이 애플리케이션 팀을 위한 인프라 복잡성을 줄였다는 신호다

인간 접착제 혹은 접착제 작업은 팀이 해야 할 일과 실제로 하는 일 사이의 간극을 해결하기 위해 필요한 모든 수동적 해결책, 문서화, 협업을 말한다.

그림자 플랫폼을 관리하려면 신뢰(제12장 참고)를 바탕으로 해야 한다. 해당 팀들과의 신뢰가 있어야 여러분이 상황을 파악할 수 있게 해준다. 다른 팀이 여러분을 믿고 관련 정보를 제공한다면, 여러분은 해당 프로젝트에 엔지니어를 파견하거나, 그 팀으로부터 정기적인 업데이트를 받거나, 향후 그 팀이 프로젝트를 이관하고자 할 때 필요한 사항에 대한 기대치를 설정하는 등 다양한 방식으로 대비할 수 있게 된다.

성장(growth)은 중독성이 있다. 플랫폼 팀을 초기 단계에서 안정적인 조직으로 성장시켰다면, 더 많은 일을 하기 위해서는 더 많은 인력을 투입하는 것이 유일한 방법이라고 생각하기 쉽다.

팀을 계속 키워가면서 이 부분을 곱씹어보게 되었다. 난 성장 중독에 빠진 것은 아닌지...

우리는 대부분의 혁신이 플랫폼 팀 자체가 아니라 자신에게 필요한 것을 구축하는 애플리케이션 팀에서 나올 것으로 기대한다.

팀들이 선택한 도구를 사용하는 이유가 단순한 습관인지 아니면 꼭 필요한 특정 기능 때문인지를 탐구해야 한다.

14 사랑받는 플랫폼

우리는 플랫폼의 핵심 지표를 '더 단순하게, 더 빠르게, 더 저렴하게, 그리고 사용자가 사랑하게'로 요약하는 플랫폼 제품 관리자를 본 적이 있다.

내부 플랫폼에서 '사랑'은 생산성 향상을 나타내는 좋은 지표이다.

'도입률'이나 '효율성' 같은 단순한 지표에만 집중하다 보면 복잡성을 관리하는 것이 아니라 제거하는 것을 목표로 삼게 된다. 그러면 애플리케이션 팀이 사랑하는 시스템이 아니라 플랫폼 팀이 통제하기 쉬운 시스템을 만드는 결과로 이어지는 것이 대부분이다.

측정은 어렵지만 좋은 접근이라고 생각한다.

주의할 점이 여럿 있지만, 잘 설계된 고객 설문조사는 가치 있는 통찰과 지원을 많이 제공한다.

주의할 점이 너무 많아서 설문조사는 전혀 안 하는데 최근에는 이런 방법도 사용해 볼지 생각하고 있다.

이런 종류의 시스템을 물려받았다면, 시스템에 결함이 있고 플랫폼 팀에 고통을 준다는 이유로 시스템을 폐지하거나 완전히 변경하기로 결정하고 싶을 수도 있을 것이다. 우리도 이해는 간다. 하지만 그런 큰 변경을 계획하기 전에, 물려받은 괴상한 시스템 중 사람들이 사랑하는 것들이 있는지 파악하고(고객 만족도 조사 등을 통해), 그리고 왜 그것을 사랑하는지 이해하려 노력해야 한다.

목표는 사용자가 작업을 제대로 하기는 쉽게, 잘못 하기는 어렵게 만드는 것이다.

플랫폼의 핵심을 관통하는 목표라고 생각한다.

우리는 플랫폼 도입을 그저 '만들면 알아서 올 것'이라는 사고방식에 맡겨두었다는 점을 깨달았다. 사람들이 플랫폼을 어떻게 도입할지, 플랫폼 배포 조직이 어느 정도 수준의 투자를 감당하게 될지를 적극적으로 고려하지 않았던 것이다.

이를 해결하기 위해 우리는 기존 플랫폼에서의 퇴로(off-ramp)와 새 플랫폼으로의 진입로(on-ramp)를 고려해서 상세한 마이그레이션 전략을 수립했다.

성공적인 플랫폼이 조직에 제공할 수 있는 최고의 레버리지는 사용자의 속도를 높이고, 사용자에게 즐거움을 주며, 사용자가 자신의 일을 멋지게 해내도록 하는 것이다. 이를 위해서는 플랫폼을 구축할 때 제품 중심의 사고방식을 도입해야 할 뿐만 아니라, '만들면 알아서 찾아올 것'이라는 사고방식에서 벗어나 초기 단계부터 도입을 목표로 하는 좀 더 적극적이고 집중된 접근 방식으로 전환해야 한다.

우리가 만드는 대부분의 플랫폼은 뻔하지만 유용할 것이다. 재미있지는 않더라도 사용자가 기대하는 대로 동작할 것이라고 신뢰할 수 있다.

책은 너무 잘 읽었지만 아무래도 플랫폼 엔지니어링을 다루면서 영역을 넓게 잡다 보니 모호해진 부분도 있다고 생각한다. 내가 꼭 정답이라는 것은 아니지만 내가 이해하는 플랫폼 엔지니어링은 DevOps에 그 기반이 있고 결국 엔지니어보다 컴포넌트의 수가 많아져서 복잡성이 제어하기 어려워지는 마이크로 서비스 때문에 플랫폼 엔지니어링의 필요성이 대두되었다고 생각하는 편인데 그런 얘기는 없어서 좀 아쉬웠다.(나만 그렇게 생각하는 걸지도...)

[Book] Hypermedia Systems

2025-12-29T23:31:44+09:00

Hypermedia Systems

Hypermedia Systems - ⭐⭐⭐⭐⭐
Carson Gross, Adam Stepinski, Deniz Akşimşek 지음

이 Hypermedia Systems은 언젠가 Twitter에서 보고 관심이 가서 읽어보려고 했던 책이다. 여기저기서 종종 말했지만, 나는 웹을 꽤 오래전부터 봐와서 그런지 웹의 Hypermedia적인 특성을 꽤 좋아하는 편이고 애플리케이션보다는 서버에서 렌더링 되어서 내려와서 접근성이 뛰어난 문서 성격의 웹이 웹의 본질이라고 생각하고 이쪽을 더 좋아하는 편이다. 그러다 보니 CSR이나 SPA가 필요한 곳이 있고 잘 쓰면 좋다고도 생각하지만, 너무 과하게 그쪽 기반으로 생태계가 조성된 현재 상황은 그리 좋아하지 않는다. 내가 그쪽에 관심이 있어서 그런지 모르겠지만 최근에는 비슷한 기조의 글이 많이 보인다.

htmx 사용법 자체는 버전이 올라가면서 달라질 것이기도 하고 여기서 세세한 사용법을 정리하는 것보다는 내가 인상 깊게 읽은 왜 Hypermedia인가를 중점으로 정리해 보려고 한다.(실제로 이 부분이 더 중요하다고 생각하고 나중에 참고용으로 다시 보기 위함이기도 하다.)

이 책의 목표는 RESTful, 하이퍼미디어 시스템 아키텍처가 다른 클라이언트-서버 시스템과 무엇이 다른지, 하이퍼미디어 접근 방식의 강점(및 약점)이 무엇인지에 대한 확실한 이해를 제공하는 것입니다.

애플리케이션의 요구 사항을 평가하고 질문에 답할 수 있는 도구를 제공하는 것을 목표로 합니다. "이 애플리케이션을 하이퍼미디어 중심 애플리케이션으로 구축할 수 있을까?" 많은 애플리케이션에서 이 질문에 "예!"라는 대답이 나올 수 있기를 바랍니다.

특히 많은 젊은 웹 개발자들은 JSON API를 사용하여 Node 서버와 상호작용을 하는 React.js 애플리케이션을 구축하는 것으로 경력을 시작했으며, 하이퍼미디어라는 시스템에 대해 전혀 배우지 못했을 수도 있습니다. 이는 비극이며, 솔직히 말해서 웹 개발 커뮤니티의 리더들이 하이퍼미디어 접근 방식을 제대로 알리고 지지하지 못한 결과이기도 합니다. 하이퍼미디어는 훌륭한 아이디어였습니다! 지금도 그렇습니다!

이 책은 htmx를 만드는 사람들이 htmx가 무엇이고 htmx에서 제공하는 Hyperview가 어디까지 할 수 있고 다른 접근에 비해서 어떤 장단점이 있는지를 설명하는 책이지만 책 전반적으로 강조하듯 핵심을 Hypermedia Systems을 설명하고 이해시키는데 목적이 있다. 그부분에서 정말 잘 설명하는 책이고 좋은 책이라고 생각한다. htmx의 사용법을 다 배우지 못하더라도 초반의 Hypermedia Systems을 설명하는 부분만 보더라도 너무 좋은 내용이라고 생각한다.(책의 원문을 너무 많이 넣는 것은 신경 쓰이지만 온라인에 공개된 책이고 CCL 라이센스 하에 원문을 번역해서 인용을 많이 넣었다.)

1974년 Ted Nelson의 "Computer Lib/Machine Dreams"은 Steven Levy("Hackers"의 저자)가 "컴퓨터 혁명의 서사시"라고 묘사한 책으로 현대 하이퍼미디어 시대의 시작을 알렸습니다. 넬슨은 HyperText, HyperLink, HyperMedia, HyperData라는 용어와 모든 정보가 서로 얽혀 있고 섞여 있다는 개념인 Intertwingularity를 창안한 공로를 인정받고 있습니다. 거의 반세기 전, 그는 중앙 통제 기관의 허가 없이도 누구나 언제든 무엇이든 게시할 수 있는 미래를 예언했습니다. 그리고 그의 하이퍼링크는 그 미래의 엔진이었습니다. Nelson의 상호연결 컴퓨팅 아이디어가 널리 퍼지기까지는 20년이 걸렸습니다. 그 과정에서 Douglas Engelbart는 oN-Line System 또는 NLS를 만들고 Wendy Hall은 Microcosm을 구축했으며 1980년대에는 Tim Berners-Lee가 월드와이드웹(WWW), HTML, HTTP를 정의했습니다. Tim Berners-Lee의 반복적 개선이 오늘날 우리 모두가 경험하는 상호연결성의 근간이자 표준이 되었습니다. 2000년에 이르러 "웹"의 기술적 토대가 Roy Fielding의 박사 학위 논문 "Architectural Styles and the Design of Network-based Software Architectures"에 문서화되었습니다. 이 논문에서 Fielding은 REpresentational State Transfer 또는 REST의 아키텍처 모델을 정의했습니다. 이 일련의 시스템 속성과 구현 제약 조건은 오늘날 전 세계 수십억 명의 사람들에게 영향을 미치는 상호 얽힌 기계를 설계하고 구축하는 데 있어 신뢰할 수 있는 모델임이 25년이 지난 지금도 입증되었습니다. Fielding의 업적은 중요했지만, REST 모델이 소프트웨어 아키텍처 및 개발 업계에 널리 알려지게 된 것은 2008년에 Leonard Richardson과 Sam Ruby가 RESTful Web Services를 발표하면서부터였습니다. 루비 프로그래밍 플랫폼의 지원을 받아 Fielding의 REST 모델에 담긴 아이디어는 웹 기반 서비스 및 클라이언트 애플리케이션을 만드는 데 있어 표준이 되었습니다. Richardson과 Ruby의 작업이 중요한 이유 중 하나는 논문이나 미래 예측과는 달리 RESTful Web Services 책에서 웹용 강력한 애플리케이션을 구축하기 위한 실용적인 작업 프레임워크를 설명했기 때문입니다. 이 책은 REST의 힘에 관해 설명했을 뿐만 아니라 이를 구축하는 방법에 대한 단계별 지침도 제공했습니다. Richardson과 Ruby는 지난 20년간의 하이퍼미디어 학문을 한곳에 모았습니다.

Hypermedia의 역사인데 역사를 좋아하는 편이라 그 발전 과정부터 간략하게 설명해 주는 것도 좋았다. 웹에서 Hypertext나 Hyperlink를 흔하게 쓰면서도 그 의미는 거의 잊힌 게 아닐까 싶은 상황에서 그 기원을 짚어주는 게 좋다.

저희는 하이퍼미디어 시스템을 필딩이 이 용어의 원래 의미에서 RESTful 네트워크 아키텍처를 준수하는 시스템으로 정의합니다. 안타깝게도 오늘날에는 업계에서 이 용어가 일반적으로 사용되기 때문에 "REST"라는 용어를 JSON API와 연관시킬 수 있습니다. JSON에는 하이퍼미디어 컨트롤이 없으므로 자연스러운 하이퍼미디어가 아니기 때문에 REST라는 용어가 잘못 적용된 것입니다. 하이퍼미디어의 교환은 시스템이 "RESTful"로 간주되기 위한 명시적인 요구 사항입니다. ... 중략... 필딩은 논문에서 1990년대 후반에 존재했던 월드 와이드 웹을 설명하고 있었다는 점을 이해하는 것이 중요합니다. 당시 웹은 단순히 하이퍼미디어를 교환하는 웹 브라우저에 불과했습니다. 단순한 링크와 양식으로 이루어진 이 시스템을 필딩은 RESTful이라고 불렀습니다. JSON API가 웹 개발의 일반적인 도구가 되기까지는 10년이 더 걸렸습니다. REST는 하이퍼미디어와 웹 1.0 버전에 관한 것이었습니다.

이후의 설명을 위해서 RESTful과 JSON API를 구분해 준다. REST도 오염된 용어 중 하나로 나 같은 근본주의자(?)가 오랫동안 얘기했듯이 언젠가부터 로이 필딩이 얘기한 REST의 특성과 상관없이 HTTP를 통한 API를 다 REST라고 부르게 된 경향이 있는데 여기서는 이른 JSON API와 명확하게 구분해 준다.

이처럼 널리 퍼져 있음에도 불구하고, 하이퍼미디어 자체는 오늘날 이상하게도 충분히 탐구되지 않은 개념으로 남아 있으며, 주로 전문가들의 영역으로 남겨져 있습니다. HTML을 작성하거나 링크와 양식을 만드는 방법에 대한 튜토리얼은 많이 찾을 수 있습니다. 하지만 HTML을 하이퍼미디어로 보는 논의나, 더 넓게는 전체 하이퍼미디어 시스템이 어떻게 구성되는지에 대한 논의는 드뭅니다. 이는 초기 웹 개발 시대와 대조적입니다. 당시에는 Representational State Transfer(REST)와 Hypermedia As The Engine of Application State(HATEOAS)와 같은 개념이 웹 개발자들 사이에서 자주 논의되고 정제되며 논쟁의 대상이 되었습니다.

HATEOAS도 어떻게 하면 이걸 현실에서 잘 구현할 수 있을지 정말 많이 고민했었는데 오랜만에 보니까 반가웠다. 내 경험에서는 HATEOAS가 가장 잘 구현된 것은 GitHub API였지만 HATEOAS의 사상대로 제대로 활용되진 못했던 걸로 기억한다.

하이퍼미디어는 텍스트와 같은 미디어로, 미디어 내의 한 위치에서 다른 위치로 비선형적으로 분기되는 기능을 포함합니다. 이 분기는 미디어에 내장된 하이퍼링크를 통해 이루어집니다. 하이퍼텍스트는 하이퍼미디어의 하위 카테고리이며, 이 책의 대부분은 HTML(Hypertext Markup Language)이나 Hyperview 모바일 하이퍼미디어 시스템에서 사용되는 HXML과 같은 하이퍼텍스트를 활용해 현대적인 애플리케이션을 구축하는 방법을 다룰 것입니다. 이 때문에 우리는 하이퍼텍스트를 사용하여 구축된 애플리케이션의 기본 아키텍처를 설명할 때, 사용되는 특정 하이퍼미디어보다 시스템 아키텍처를 강조하기 위해 더 넓은 용어인 '하이퍼미디어 시스템'을 선호합니다. 많은 현대 웹 개발자들이 하이퍼미디어 시스템 아키텍처의 중요성을 과소평가하고 무시하고 있습니다.

왜 이 책에서 하이퍼미디어 시스템이라는 용어를 채택했는지에 대한 설명인데 난 잘 선택한 용어라고 생각한다.

Berners-Lee와 Fielding, 그 외 다른 많은 사람이 만든 시스템은 하이퍼미디어를 중심으로 돌아갔습니다. 바로 HTML입니다. HTML은 읽기 전용 하이퍼미디어로 시작하여 (처음에는) 학술 문서를 게시하는 데 사용되었습니다. 이러한 문서들은 앵커 태그를 통해 서로 연결되어 문서 간에 하이퍼링크를 생성하여 사용자가 문서 사이를 빠르게 탐색할 수 있었습니다. HTML 2.0이 출시되면서 form 태그의 개념이 도입되어 anchor 태그(즉, 하이퍼링크)가 두 번째 하이퍼미디어 컨트롤로 추가되었습니다. form 태그의 도입으로 리소스를 단순히 읽는 데 그치지 않고 업데이트할 수 있는 메커니즘을 제공함으로써 웹에서 애플리케이션을 구축할 수 있게 되었습니다. 이 시점에서 웹은 흥미로운 문서 중심 시스템에서 매력적인 애플리케이션 아키텍처로 전환되었습니다.

하이퍼미디어 서버는 새 페이지에 대한 하이퍼미디어 응답, 즉 HTML로 이 요청에 응답합니다. 이것은 사소하고 당연한 것처럼 보일 수 있지만, 클라이언트와 서버가 하이퍼미디어를 통해 통신해야 한다는 점에서 진정한 RESTful 하이퍼미디어 시스템의 절대적으로 중요한 측면입니다!

Link와 Form으로 대표되는 Hypermedia의 동작 방식을 설명하고 Hypermedia가 아닌 것은 무엇인지 설명한다.

중요한 것은 이 JSON 기반 서버 상호 작용의 중요한 측면은 하이퍼미디어를 사용하지 않는다는 것입니다. 여기서 사용되는 JSON API는 하이퍼미디어 응답을 반환하지 않습니다. 하이퍼링크나 기타 하이퍼미디어 스타일의 컨트롤이 없습니다.

HTML은 여전히 사용자 인터페이스를 구축하는 데 사용되지만, 두 가지 주요 하이퍼미디어 컨트롤인 anchor와 form의 하이퍼미디어 측면은 사용되지 않습니다. 두 태그 모두 기본 하이퍼미디어 메커니즘을 통해 서버와 상호작용을 하지 않습니다. 그 대신 JavaScript를 통해 인메모리 도메인 모델과 로컬 상호작용을 유도하는 사용자 인터페이스 요소가 되며, 이 요소는 일반 데이터 JSON API를 사용하여 서버와 동기화됩니다.

싱글 페이지 애플리케이션 접근 방식은 하이퍼미디어 아키텍처를 포기합니다. 기존 웹의 RESTful 아키텍처의 장점과 HTML의 네이티브 하이퍼미디어 컨트롤에 내장된 기능을 버리고 자바스크립트 중심의 동작을 선호합니다. SPA는 두꺼운 클라이언트 애플리케이션, 즉 1980년대의 클라이언트-서버 애플리케이션과 매우 유사하며, 웹이 등장하기 전에 널리 사용되었고 여러 면에서 웹이 이에 대한 반응이었던 아키텍처입니다. 물론 이러한 접근 방식이 반드시 잘못된 것은 아닙니다. 애플리케이션에 따라서는 두꺼운 클라이언트 접근 방식이 적절한 선택일 때도 있습니다. 하지만 웹 개발자가 다른 대안을 고려하지 않고 왜 그렇게 자주 이 방식을 선택하는지, 그리고 이 길을 가지 않는 이유가 있는지 생각해 볼 필요가 있습니다.

Hypermedia와 SPA를 비교하기 위한 설명이다.

자바스크립트 기반의 싱글 페이지 애플리케이션 접근 방식은 웹 개발계를 강타했으며, 그 성공의 한 가지 이유가 있다면 바로 이것입니다. 싱글 페이지 애플리케이션은 기존의 투박한 웹 1.0 하이퍼미디어 기반 애플리케이션보다 훨씬 더 인터랙티브하고 몰입감 있는 경험을 제공한다는 점입니다. SPA는 전체 문서를 새로 고치지 않고도 페이지의 요소를 인라인으로 원활하게 업데이트할 수 있고, CSS 전환을 사용하여 멋진 시각 효과를 만들 수 있으며, 마우스 움직임과 같은 임의의 이벤트에 연결할 수 있는 기능을 갖추고 있었습니다.

하이퍼미디어 아키텍처는 원래의 웹 1.0 형태에서도 싱글 페이지 애플리케이션 + JSON 데이터 API 접근 방식과 비교할 때 여러 가지 장점이 있는 것으로 나타났습니다. 가장 큰 장점은 세 가지입니다.

웹 애플리케이션을 구축하는 매우 간단한 접근 방식입니다.

콘텐츠 및 API 변경에 매우 관대합니다. 사실, 그 덕분에 번창합니다!

캐싱과 같은 웹 브라우저의 검증된 기능을 활용합니다.

특히 처음 두 가지 장점은 최신 웹 개발의 주요 문제점을 해결합니다.

싱글 페이지 애플리케이션 인프라는 매우 복잡해져서 팀 전체가 관리해야 하는 경우가 많습니다.

애플리케이션 요구 사항을 지원하기 위해 JSON API를 지속적으로 변경하는 JSON API 이탈은 많은 애플리케이션 팀의 주요 골칫거리가 되었습니다.

이 두 가지 문제가 자바스크립트 라이브러리 이탈과 같은 다른 문제와 함께 결합되어 "자바스크립트 피로감"라는 현상이 발생했습니다.

저희는 하이퍼미디어 아키텍처가 많은 개발자와 팀의 자바스크립트 피로를 해소하는 데 도움이 될 수 있다고 믿습니다.

이 책에서는 지금처럼 자바스크립트가 많이 쓰이면서 발생하는 문제를 자바스크립트 피로감이라고 불렀다.

하이퍼미디어가 웹 개발에서 다시 등장하지 않은 데에는 크게 두 가지 이유가 있습니다. 첫 번째는 1990년대 중반에 출시된 HTML 2.0 이후 하이퍼미디어로서의 HTML의 표현력이 크게 변하지 않았다는 점입니다. 물론 HTML에 많은 새로운 기능이 추가되긴 했지만, 거의 30년 동안 HTML에서 서버와 상호작용을 하는 새로운 방법은 크게 달라지지 않았습니다. HTML 개발자는 여전히 하이퍼미디어 컨트롤로 anchor 태그와 form만 사용할 수 있으며, 이러한 하이퍼미디어 컨트롤은 여전히 GET 및 POST 요청만 발행할 수 있습니다. HTML의 이러한 당혹스러운 발전 부족은 하이퍼미디어로서의 HTML이 어려움을 겪게 된 두 번째, 어쩌면 더 실질적인 이유로 바로 이어집니다. HTML의 상호작용성과 표현력이 멈춰 있는 동안 웹 사용자의 요구는 계속 증가하여 점점 더 많은 대화형 웹 애플리케이션을 요구하고 있기 때문입니다. 이러한 것보다 정교한 사용자 인터페이스를 제공하려는 방법으로 데이터 지향 JSON API와 결합한 JavaScript 기반 애플리케이션이 등장했습니다. 웹 개발 커뮤니티를 자바스크립트 기반 싱글 페이지 애플리케이션 접근 방식으로 이끈 것은 일반 HTML에서는 구현할 수 없었던 사용자 경험이었습니다. 이러한 변화는 시스템 아키텍처로서 단일 페이지 애플리케이션의 본질적인 우월성 때문이 아닙니다.

책에서는 Hypermedia가 좋다고 얘기하지만, Hypermedia가 제대로 발전하지 못하고 SPA가 발전하게 되었는지에 대한 역사적 배경을 설명한다.

MPA(Multi Page Application)는 여러 웹 페이지에 있는 링크와 양식을 사용하여 HTTP 요청을 제출하고 HTML 응답을 받는 기존 웹 1.0 방식의 웹 애플리케이션 구축 방식에 대한 현대적인 이름입니다. MPA는 본질적으로 하이퍼미디어 중심 애플리케이션으로, 로이 필딩이 그의 논문에서 설명한 것과 정확히 일치합니다.

인기 있는 SPA 라이브러리인 Svelte.js의 창시자이자 SPA 논쟁의 사상가인 Rich Harris는 이 구형 MPA 스타일과 최신 SPA 스타일을 혼합하여 사용할 것을 제안했습니다. 해리스는 웹 애플리케이션 구축에 대한 이러한 접근 방식을 "과도기적"이라고 부르는데, 이는 MPA 접근 방식과 최신 SPA 접근 방식을 일관된 전체로 혼합하려는 시도라는 점에서 그렇습니다.

"과도기적"은 혼합 스타일 애플리케이션에 적합한 용어이며, 두 가지 접근 방식 중 하나를 사례별로 적절히 사용하여 두 접근 방식 간의 합리적인 절충안을 제시합니다. 하지만, 이 절충안은 여전히 불만족스럽습니다.

SPA와 MPA 간의 절충안의 핵심은 사용자 경험, 즉 애플리케이션의 상호 작용이라는 점을 기억하세요. 이는 일반적으로 애플리케이션 또는 '과도기적' 애플리케이션의 경우 특정 기능에 대해 한 접근 방식과 다른 접근 방식 중 하나를 선택하도록 결정하게 됩니다. 하이퍼미디어 지향 라이브러리를 채택하면 MPA와 SPA 접근 방식 간의 상호 작용성 격차가 크게 좁혀지는 것으로 나타났습니다. 사용자 인터페이스를 손상하지 않고 훨씬 더 많은 애플리케이션에 MPA 접근 방식, 즉 하이퍼미디어 접근 방식을 사용할 수 있습니다

SPA가 발전할 수 있었던 역사적 이유가 있었지만, 하이퍼미디어 중심에 놓기 위한 접근 방법을 설명한다.

가장자리에 약간의 하이퍼미디어가 포함된 SPA를 사용하거나 두 가지 접근 방식을 혼합하는 대신 주로 또는 전체적으로 하이퍼미디어 중심이면서 사용자가 필요로 하는 상호 작용을 충족하는 웹 애플리케이션을 만들 수 있습니다. 이렇게 하면 웹 애플리케이션을 엄청나게 단순화하고 훨씬 더 일관성 있고 이해하기 쉬운 소프트웨어를 만들 수 있습니다.

하이퍼미디어 우선 접근 방식을 채택하고 하이퍼미디어 지향 라이브러리를 사용하여 HTML을 최대한 활용하면 웹 애플리케이션을 강력하고 인터랙티브하며 단순하게 만들 수 있습니다. 이러한 하이퍼미디어 지향 라이브러리 중 하나가 htmx입니다.

이 책 자체가 htmx를 설명하는 책이므로 자연스레 htmx가 등장한다. 다른 하이퍼미디어 지향 라이브러리가 있기도 하지만 htmx를 만들었을 때도 HTML이 중심으로 하고 싶은 문제의식이 있어서 만들었을 것이므로 그 문제의식을 잘 설명했다고 생각한다.

htmx로 구축된 웹 애플리케이션을 "다중 페이지 애플리케이션(MPA)"이라고 부르는 것은 적절하지 않습니다. 구형 웹 1.0 MPA 접근 방식과 최신 하이퍼미디어 지향 라이브러리 기반 애플리케이션의 공통점은 핵심 기술 및 아키텍처로 하이퍼미디어를 사용한다는 점입니다. 따라서 하이퍼미디어 기반 애플리케이션(HDA)이라는 용어를 사용하여 두 가지를 모두 설명합니다.

하이퍼미디어 중심 애플리케이션(HDA)은 하이퍼미디어 및 하이퍼미디어 교환을, 서버와의 통신을 위한 기본 메커니즘으로 사용하는 웹 애플리케이션입니다.

anchor 태그나 form과 마찬가지로 이 htmx 기반 버튼은 서버와 하이퍼미디어를 교환하고 있으므로 상호 작용은 여전히 웹의 기본 하이퍼미디어 모델을 사용하고 있습니다. Htmx는 자바스크립트를 통해 이 버튼에 기능을 추가하고 있지만, 그 기능은 하이퍼미디어로서 HTML을 보강하고 있습니다. Htmx는 하이퍼미디어 시스템을 완전히 다른 아키텍처로 대체하는 것이 아니라 웹의 하이퍼미디어 시스템을 확장합니다. 표면적으로는 서로 비슷해 보이지만, Htmx 기반 버튼과 JavaScript 기반 버튼은 매우 다른 시스템 아키텍처를 사용하므로 웹 개발 접근 방식이 다릅니다.

htmx가 무엇인지 뭘 하려는 것인지를 이해할 수 있는 설명이다. 하이퍼미디어를 좋아해서 그렇겠지만 htmx는 써봐야지 하면서 미루고만 있었는데 책을 읽고 더 써봐야겠다는 생각이 들었다.

엄청난 양의 사용자 상호작용이 필요하지 않은 웹사이트나 애플리케이션을 만들고 있을 수도 있습니다. 이와 같은 유용한 웹 애플리케이션이 많이 있으며 부끄러워할 필요는 없습니다! Amazon, eBay, 수많은 뉴스 사이트, 쇼핑 사이트, 게시판 등과 같은 애플리케이션은 웹이 설계된 목적대로 주로 텍스트와 이미지로 구성되어 있기 때문에 많은 양의 상호 작용이 없어도 효과적일 수 있습니다.

이러한 모든 애플리케이션은 로이 필딩이 "대용량 하이퍼미디어 데이터 전송"이라고 부르는 방식에 적합하며, 요청에서 전체 HTML 문서를 반환하는 응답과 함께 앵커 태그와 양식을 사용하기만 하면 모든 것이 잘 작동할 것입니다. 이것이 바로 웹이 설계된 목적입니다! 이러한 애플리케이션에 하이퍼미디어 방식을 채택하면 단일 페이지 애플리케이션 방식을 채택할 때 발생하는 엄청난 양의 클라이언트 측 복잡성을 줄일 수 있습니다. 클라이언트 측 라우팅, 클라이언트 측 모델 관리, 자바스크립트 로직의 수작업 배선 등이 필요 없습니다. 뒤로 버튼은 "그냥 작동"합니다. 딥링킹은 "그냥 작동"합니다. 애플리케이션이 실제로 가치를 창출하는 서버에 집중할 수 있습니다. 또한 이 접근 방식 위에 htmx 또는 다른 하이퍼미디어 지향 라이브러리를 계층화하면 바닐라 HTML에서 발생하는 많은 사용성 문제를 해결하고 더 세분화된 하이퍼미디어 전송을 활용할 수 있습니다. 이렇게 하면 완전히 새로운 사용자 인터페이스와 경험의 가능성이 열리므로 하이퍼미디어를 사용하여 구축할 수 있는 애플리케이션의 범위가 훨씬 더 넓어집니다.

완전히 동의한다. 대부분의 웹사이트는 정적인 성격이 훨씬 강하고 그 위에 상호작용을 추가하는 건 어렵지 않기 때문에 정적인 것을 먼저 고려하고 애플리케이션 적인 특성을 고려해야 한다고 생각한다.

하이퍼미디어 서버는 HTTP 요청에 HTTP 응답으로 응답할 수 있는 모든 서버입니다. HTTP는 매우 간단하기 때문에 거의 모든 프로그래밍 언어를 사용하여 하이퍼미디어 서버를 구축할 수 있습니다. 상상할 수 있는 거의 모든 프로그래밍 언어로 HTTP 기반 하이퍼미디어 서버를 구축하는 데 사용할 수 있는 방대한 라이브러리가 있습니다.

반대로 하이퍼미디어 중심 애플리케이션을 구축하면 사용하려는 백엔드 기술을 훨씬 더 자유롭게 선택할 수 있습니다. 애플리케이션의 도메인, 익숙한 언어 및 서버 소프트웨어, 또는 시도해 보고 싶은 기술에 따라 결정할 수 있습니다. 서버 측 로직을 HTML로 작성하지는 않을 것입니다! 그리고 모든 주요 프로그래밍 언어에는 HTTP 요청을 깔끔하게 처리하는 데 사용할 수 있는 좋은 웹 프레임워크와 템플릿 라이브러리가 하나 이상 있습니다.

하이퍼미디어 클라이언트는 특정 하이퍼미디어와 그 안의 하이퍼미디어 컨트롤을 올바르게 해석하는 방법을 이해하는 소프트웨어입니다. 물론 가장 일반적인 예는 HTML을 이해하고 사용자가 상호작용을 할 수 있도록 표시할 수 있는 웹 브라우저입니다.

브라우저만 하이퍼미디어 클라이언트가 있는 것은 아닙니다. 이 책의 마지막 섹션에서는 모바일 지향 하이퍼미디어인 Hyperview에 대해 살펴보겠습니다. 하이퍼뷰의 뛰어난 기능 중 하나는 단순히 하이퍼미디어인 HXML만 제공하는 것이 아니라 해당 하이퍼미디어를 위한 하이퍼미디어 클라이언트도 제공한다는 점입니다. 따라서 하이퍼뷰를 통해 적절한 하이퍼미디어 중심 애플리케이션을 매우 쉽게 구축할 수 있습니다.

하이퍼미디어의 구성 요소에 대한 설명인데 간단한 내용이지만 명확히 이해하는 게 중요하다고 생각한다.

하이퍼미디어 클라이언트는 하이퍼미디어를 클라이언트에 렌더링하는 방법 외에는 서버 모델에 대해 아무것도 알 필요가 없으므로 사용자에게 수신하고 표시하는 표현에 대해 매우 유연하게 대처할 수 있습니다.

스크립팅은 웹의 원래 RESTful 모델의 기본 측면이었으며, 따라서 하이퍼미디어 중심 애플리케이션에서 당연히 허용되어야 합니다. 그러나 하이퍼미디어 중심 애플리케이션에서 스크립팅이 존재한다고 해서 근본적인 네트워킹 모델이 변경되어서는 안 됩니다. 하이퍼미디어는 계속해서 애플리케이션 상태의 엔진이 되어야 하고, 서버 통신은 여전히 JSON 데이터 교환이 아닌 하이퍼미디어 교환으로 구성되어야 하는 등 근본적인 네트워킹 모델이 변경되어서는 안 됩니다.

안타깝게도 오늘날 웹의 스크립팅 계층인 자바스크립트는 하이퍼미디어 모델을 보강하기보다는 대체하는 데 자주 사용됩니다.

이후부터는 htmx를 이용해서 간단한 앱을 만들면서 현재 우리가 보는 SPA와 비교해서 똑같은 기능을 하이퍼미디어적인 접근으로 htmx에서는 어떻게 해결할 수 있고 거기서 생기는 트레이으 오프가 무엇인지를 설명한다. 하이퍼미디어의 가치가 좋기(?) 때문에 부족하더라도 하이퍼미디어 시스템을 써야 한다고 얘기하는 것이 아니므로 htmx가 현대에도 충분한 상호작용을 제공하면서도 더 좋은 방식이라는 것을 설명하기 위해 간단한 연락처 앱에 기능을 계속 추가하면서 SPA에 부족하지 않은 앱을 만들면서 설명하기에 htmx의 사용법을 쉽게 익힐 수 있다.

뒷부분에서는 네이티브 모바일 앱까지 지원하기 위해서 제공되는 Hyperview도 설명하는데 라이브러리 만드는 입장에서는 htmx로 모바일까지 지원한다는 것은 큰 장점이지만 개인적으로는 모바일 앱은 특성이 꽤 달라서 굳이 모바일 앱까지 한 번에 지원해야 하나 생각하는 편이라 크게 관심은 없었다. REST의 이론상 이렇게 하는 게 맞다는 건 알지만 현실에서는 복잡성의 문제로 적합하지 않다고 생각한다.

현재의 대중적인 의견과는 달리 하이퍼미디어는 애플리케이션 구축을 위한 혁신적이고 현대적인 시스템 아키텍처로, 어떤 면에서는 기존의 단일 페이지 애플리케이션 접근 방식보다 더 현대적입니다.

난 아직도 혼자 하는 프로젝트는 서버에서 HTML 찍어내고 jQuery로 동작을 추가하는 걸 더 선호하고(낡았다는 건 알고 있다.) 이 책의 htmx뿐 아니라 alpine.js같은 접근 방식이 여전히 의미 있고 REST의 사상은 너무나도 중요하다고 생각하는 편이다. 책에서는 아무래도 Hypermedia System이 중심이므로 그쪽에 대해 더 설명하고 있지만 현실에서는 여전히 어려운 부분이 있다고 생각한다. 예를 들어, Content Negotiation은 아주 좋은 접근방법이지만 RESTful하게 같은 리소스에서 Content Negotiation으로 서버에서 모든 걸 처리 하려면 꽤 난이도가 올라가고 나중에 쌓인 기술 부채로 힘들었던 경험이 있다.

이상과 현실은 항상 다른 법이고 현실에서는 당연히 적절한 절충안을 선택하는 게 낫다고 생각하고 있다. htmx나 Hypermedia가 정답이라고 얘기하는 것은 아니지만 기술 발전의 이유와 어떤 선택권이 있는지를 알고 있는 것은 좋다고 생각해서 책의 결론 부분을 마지막으로 인용한다.

많은 웹 개발자는 "순수한" HTML의 링크와 양식을 덜 정교했던 시대의 구식 도구로 여깁니다. 그리고 어떤 면에서는 그들이 옳습니다. 초기 웹에는 분명한 사용성 문제가 있었습니다. 그러나 이제는 HTML의 핵심적 한계를 해결하여 확장하는 자바스크립트 라이브러리들이 존재합니다.

하이퍼미디어 기반 애플리케이션 접근 방식이 모든 애플리케이션에 적합한 것은 아닙니다. 하지만 많은 애플리케이션에 있어 하이퍼미디어가 제공하는 향상된 유연성과 단순성은 큰 이점이 될 수 있습니다. 여러분의 애플리케이션이 이 접근법으로 이점을 얻지 못하더라도, 이 접근법과 그 장단점, 그리고 여러분이 채택한 접근법과의 차이점을 이해하는 것은 가치 있는 일입니다. 초기 웹은 역사상 그 어떤 분산 시스템보다 빠르게 성장했습니다. 웹 개발자들은 그러한 성장을 가능케 한 기반 기술의 힘을 활용하는 방법을 알아야 합니다.

우리 업계의 이런 현실을 미화해서는 안 됩니다. 반면, 이런 현실이 초래하는 부정적 측면도 외면해서는 안 됩니다. 이는 모두가 '새로운 것' 즉, 모든 것을 바꿀 최신 최고의 기술을 주시하는 고압적인 환경을 조성합니다. 자신의기 기술이 세상을 바꿀 것이라고 주장해야 한다는 압박을 낳습니다. 단순함보다 정교함을 선호하는 경향이 생깁니다. 사람들은 "이게 너무 복잡한 건 아닐까?"라고 묻는 것을 두려워합니다. 그 질문이 "내가 이걸 이해할 만큼 똑똑하지 못하다"는 말과 너무 비슷하게 들리기 때문입니다. 소프트웨어 산업, 특히 웹 개발 분야는 기존 기술을 이해하고 그 위에 구축하거나 그 안에서 발전시키는 것보다 혁신에 훨씬 더 치우치는 경향이 있습니다. 우리는 확립된 아이디어를 살펴보기보다 새롭고 천재적인 해결책을, 앞을 내다보며 찾으려 합니다. 이는 이해할 수 있습니다. 기술 세계는 필연적으로 미래 지향적인 산업이기 때문입니다. 반면에 — 로이 필딩의 REST 정립에서 보았듯이 — 웹의 초기 설계자들 중 일부는 간과된 훌륭한 아이디어를 제시했습니다. 우리는 하이퍼미디어가 '새로운' 아이디어로 등장했다 사라지는 과정을 지켜볼 만큼 오래 살아왔다. REST와 같은 강력한 아이디어가 업계에 의해 무심코 버려지는 모습을 보는 것은 다소 충격적이었다. 다행히도 그 개념들은 여전히 그 자리에 남아 재발견되고 재활성화되기를 기다리고 있다. 웹의 원초적인 RESTful 아키텍처는 새로운 시각으로 바라볼 때 오늘날 웹 개발자들이 직면한 많은 문제를 해결할 수 있다. 마크 트웨인의 조언을 따르듯, 잠시 멈춰 성찰할 때가 왔을지도 모릅니다. 잠시 고요히 '새로운 것'의 끝없는 소용돌이를 제쳐두고, 웹이 어디서 왔는지 되돌아보며 배울 수 있을 것입니다. 아마도 하이퍼미디어에 기회를 줄 때가 된 것 같습니다.

기술 뉴스 #284 : 25-12-16

2025-12-16T02:10:03+09:00

웹개발 관련

Critical Security Vulnerability in React Server Components : 지난 29일 Lachlan Davidson이 React에서 인증 없이도 원격 코드를 실행할 수 있는 취약점을 최초로 보고했다. React2Shell로 알려진 이 취약점은 React Server Function 엔드포인트로 전송되는 페이로드를 해독하는 방식의 취약점을 악용하기 때문에 앱이 React Server Function 엔드포인트를 구현하지 않는다고 하더라도 앱이 React Server Component를 지원한다면 취약할 수 있다. 이 취약점은 React 19.0, 19.1.0, 19.1.1, 19.2.0에 존재하며 각각 19.0.1, 19.1.2, 19.2.1에서 수정되었고 Next.js에서도 취약점이 13.3.x, 13.4.x, 13.5.x, 14.x, 15.x, 16.x에 존재하므로 즉시 업데이트해야 한다.(영어)
- 이후 서비스 거부 취약점과 소스 코드가 노출될 수 있는 추가 취약점이 발견되어 업데이트가 필요하다.
- React2Shell 취약점의 자세한 내용은 React2Shell(CVE-2025-55182) 취약점 완전 분석에서 확인할 수 있다.
How We're Protecting Our Newsroom from npm Supply Chain Attacks : 지난 11월 월간 1억 3천만 건의 다운로드를 기록한 796개의 패키지를 침해한 Shai-Hulud NPM 웜이 있었지만, 시애틀 타임즈는 이 영향을 받지 않았다. npm 레지스트리의 보안 개선을 많은 부분에서 큰 진전을 이루었지만, 레지스트리의 보안은 패키지의 게시는 보호하지만, 패키지의 소비는 막지 못하는데 Shai-Hulud도 이 지점을 이용한 것이었다. 그래서 pmpm의 클라이언트 측 보호 계층을 사용했는데 기본적으로 라이프사이클 스크립트를 차단하고 설정을 통해 제어할 수 있으며 쿨타임을 지정해서 쿨타임 기간 내의 패키지는 설치를 차단할 수 있고 Trust Policy를 통해 새 버전이 이전 버전보다 인증이 약하다면 설치를 차단할 수 있다.(영어)
Level up design-to-code collaboration with GitHub’s open source Annotation Toolkit : GitHub 접근성 디자인 팀에서 내부 검토를 한 결과 접근성 감사 문제의 절반(48%)은 설계 의도를 WCAG(Web Content Accessibility Guidelines)에 주석으로 문서화했다면 예방할 수 있다는 점을 깨달았다. 이를 해결하기 위해 Annotation Toolkit을 오픈소스로 공개했다. Annotation Toolkit은 디자인에 삽입할 수 있는 주석으로 구성된 Figma 라이브러리로 캔버스 위에 디자인 의도를 표현하고 접근성 동작을 문서화해서 엔지니어에게 명확한 안내를 할 수 있다.(영어)

그 밖의 개발 관련

Background Coding Agents: Predictable Results Through Strong Feedback Loops (Part 3) : Spotify에서 백그라운드 코딩 에이전트를 도입하는 과정을 설명하는 연작 글이다. 백그라운드 코딩 에이전트는 PR을 생성 못 하거나 PR을 생성했는데 CI가 실패하거나, CI도 통과했지만, 기능적으로 잘못된 PR을 만드는 세 가지 실패 모드를 걱정했다. 이러한 실패를 완화하기 위해 검증 루프를 넣기 위해 verifier를 만들어서 제공하는데 이를 통해 에이전트가 올바른 해결책을 찾게 하고 verifier를 추상화해서 사소한 컨텍스트에 낭비할 필요가 없어졌다. 추가로 에이전트가 지시하지 않은 문제도 해결하려고 하므로 심사위원으로 LLM을 추가해서 검증 후에 제안된 변경 사항을 검토하도록 했다.(영어)
$5짜리 프롬프트로 $2,418짜리 취약점 찾은 썰 : 최근 해킹 대회에서 LLM을 많이 사용하는 것에 인사이트를 받아서 수년간 기여해서 이해도가 높은 Django를 대상으로 ChatGPT를 이용해서 취약점 분석을 시도한다. 취약점 목록을 찾게 하고 이를 직접 검토하면서 그동안 몰랐던 취약점에 관해서 배우게 되고 일부 취약점은 인정되지 않았지만 중간 심각도의 취약점으로 평가받은 취약점도 찾아서 제출하게 된 과정이 자세하게 나와 있다.(한국어)
Litestream VFS : SQLite의 백업/복원 시스템인 Litestream에 VFS 기능이 추가되어 원격에 있는 백업본에 연결해서 전체 데이터베이스를 다운로드 받지 않고도 쿼리를 할 수 있게 되었다. Litestream은 5.0에서 데이터 전송 파일 형식은 LTX를 통합했는데 LTX를 통해 개별 페이지에서 읽기를 수행할 수 있으므로 SQLite의 VFS 인터페이스를 이용해서 이러한 기능을 지원할 수 있다.(영어)
The (successful) end of the kernel Rust experiment : 메인테이너 서밋에서 Linux Kernel의 Rust 실험에 대해 논의했고 더 이상 실험이 아니고 커널의 핵심이 되었다는 데 합의했다.(영어)

인프라 관련

AWS re:Invent 2025 주요 신규 서비스 출시 모음 : 지난 11월 30일부터 12월 4일까지 미국 라스베이거스에서 AWS re:Invent 2025가 열렸다.(한국어)
- Graviton 5세대 미리보기 출시
- AWS Lambda를 EC2에서 실행할 수 있는 AWS Lambda Managed Instances 출시
- 여러 단계를 조정할 수 있는 AWS Lambda durable functions 출시
- Kubernetes를 완전히 관리할 수 있는 서비스로 Argo CD, AWS Controllers for Kubernetes, Kube Resource Orchestrator가 포함된 EKS Capabilities 출시
- 비용 효율성을 유지할 수 있는 AWS Database Saving Plan 도입
- 원인을 파악하고 사고 대응을 하는 AWS DevOps Agent 출시
- 벡터를 저장할 수 있는 Amazon S3 Vectors 정식 출시
- 새로운 프론티어 Nova 모델 발표
2025년 12월 5일 Cloudflare 서비스 중단 : 지난 12월 5일 한국 시각 17시 47분부터 25분간 Cloudflare 네트워크에 장애가 발생했다. 이번 장애는 최근 공개된 React2Shell로 알려진 취약점을 막기 위해 버퍼 크기를 1MB로 늘려서 배포하던 중 WAF 테스트 도구가 증가시킨 버퍼 크기를 지원하지 않는다는 것을 발견되었고 이 테스트 도구를 비활성 하려고 글로벌 구성 시스템에 변경했을 때 FL1 버전 프록시가 수년간 잠재되어 있던 버그로 오류가 발생하면서 장애가 발생했다.(한국어)
Shifting left at enterprise scale: how we manage Cloudflare with Infrastructure as Code : Cloudflare가 보안 검사를 일관되게 적용하기 위해 Shift Left를 적용하려고 Infrastructure as Code로 모두 전환했다. 이를 위해 Terraform을 선택했고 CI/CD 파이프라인에서 Atlantis를 사용하고 있으면 상태 파일을 안전하게 저장하기 위해 tfstate-butler를 사용하고 있다. 필수 보안 구성을 코드로 관리하고 있으며 설정을 자동으로 검사하기 위해 Open Policy Agent(OPA)를 사용해서 Atlantis Conftest Policy Checking 기능으로 이를 검사하고 있다.(영어)
AV1 — Now Powering 30% of Netflix Streaming : Netflix 시청의 약 30%는 이제 개방형 최신 비디오 코덱인 AV1를 사용하고 있다고 한다. 그 이전에는 H.264.AVC를 스트리밍 포맷으로 사용했지만, 오픈 미디어 연합에서 AV1을 2018년 출시하게 되었고, Netflix에서도 AV1을 지원하기 위해 유연한 안드로이드를 첫 출발점으로 삼았다. AV1의 우수한 압축 효율은 모바일 사용자에게 특히 유용했고, 안드로이드의 AV1 출시를 바탕으로 기기 제조업체와 SoC 업체와 협력해서 2021년 말에는 TV 기기에서 AV1을 스트리밍할 수 있게 되고 2023년에는 애플 기기에도 AV1 하드웨어 지원이 도입되면서 이를 지원할 수 있게 되었다. VOD를 넘어 라이브 스트리밍과 클라우드 게이밍에도 고려하고 있으며 2025년 발표된 AV2에도 큰 기대를 하고 있다.(영어)
Cloudflare Radar 2025 Year in Review : Cloudflare 네트워크의 데이터를 바탕으로 한 연례 보고서다. 전 세계 인터넷 트래픽은 19% 증가했으며 AI의 사용자 행동 크롤링은 15배 등장했고, Anthropic이 AI 플랫폼 중 가장 높은 크롤링 대비 추천 비율을 보여주었고 robots.txt에서 AI 크롤러를 가장 많이 차단했다. iOS 기기가 모바일 트래픽의 35%를 차지했고 HTTP/3와 HTTP/2는 소폭 증가했으며 전 세계의 듀얼스택 요청은 1/3 미만이 IPv6로 이루어졌다.(영어)
Free .cv Domains for Everyone: A Tiny Island Nation Is Rewriting the Future of Professional Profiles : 50만 명 인구의 섬나라인 케이프베르데가 소유한 국가 도메인 .cv를 무료로 개방하면서 .cv 레지스트리는 1년 만에 3천 개에서 2만 5천 개로 증가했다. 케이프베르데는 .cv가 새로운 신원 프로토콜이 될 수 있다고 믿고 있고 hello.cv를 통해 자신의 이름으로 된 프로필 도메인은 무료로 얻을 수 있다.(영어)

AI 관련

GPT-5.2를 소개합니다 : OpenAI에서 GPT의 새로운 버전인 GPT-5.2를 공개했다. GPT-5.2는 여러 벤치마크에서 최고 기록을 달성하며 GPT-5.1보다 높은 점수를 보여주었다.(한국어)
DeepSeek-V3.2 Release : 세계적인 추론 기능을 가지고 있으며 대규모 에이전트 훈련 데이터의 합성 방법을 도입한다.(영어)
Introducing Mistral 3 : Mistral 3가 발표되었다. Mistral 3에는 14B, 8B, 3B 소형 밀도 모델과 Mistral Large 3가 포함되고 지금까지 중 가장 강력한 41B 활성 매개변수와 675B의 총 매개 변수로 훈련된 모델로 Apache 2.0 라이선스로 출시되었다.(영어)
Devstral2 Mistral Vibe CLI : Mistral에서 차세대 코딩 모델로 Devstral 2(123B)와 Devstral Small 2(24B)를 오픈소스 라이센스로 공개했다.(영어)
Take the web for a fresh spin with GenTabs, built with Gemini 3 : 수십 개의 탭을 열고 처리하는 어려움을 해결하기 위해 Google Labs에서 새로운 웹 브라우징을 위한 Disco 플랫폼을 만들고 첫 기능으로 Gemini 3를 사용한 GenTabs를 공개했다. GenTabs는 열린 탭과 채팅 기록을 파악해서 작업을 완료할 수 있는 인터랙티브 웹 애플리케이션이다. 현재는 대기자 등록을 한 후 사용할 수 있다.(영어)
Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.md : Linux 재단이 Agentic AI 재단(AAIF)의 설립을 발표했다. 이번 재단 설립과 함께 Anthropic은 MCP(Model Context Protocol), Block의 goose, OpenAI의 AGENTS.md를 기부했으며 회원사로는 AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI가 참여했다.(영어)
OpenAI are quietly adopting skills, now available in ChatGPT and Codex CLI : Anthropic이 Skills를 도입한 이후 이 접근 방법을 다른 LLM에서도 구현하기 쉬워 보인다는 점이 인상적이었는데 최근 OpenAI가 Codex CLI와 ChatGPT에도 skills를 지원하고 있는 것으로 나오고 실제 이를 이용해서 PDF 문서를 생성하는 것을 보여준다.(영어)

볼만한 링크

21 Lessons from 14 Years at Google : Google에서 14년간 일한 Addy Osmani가 그만두면서 그동안 배운 교훈을 정리한 글이다.(영어)
1. 최고의 엔지니어는 사용자 문제를 해결하는 데 집착한다.
2. 옳다는 것은 싸다. 함께 제대로 하는 것이 진짜다.
3. 완벽을 추구하기보다는 일단 해보고 그다음에 더 잘하는 것이 낫다.
4. 명확한 코드가 더 중요하고 영리한 코드는 오버헤드가 있다.
5. 새로운 기술을 도입하는 것은 장애, 채용, 인지 부하로 갚아야 하는 대출이다.
6. 코드가 당신을 대변하지 않는다.
7. 최고의 코드는 직접 작성하지 않아도 되는 코드다.
8. 규모가 커지면 버그에도 사용자가 생긴다.
9. 대부분의 느린 팀은 정렬이 잘못된 팀이다.
10. 통제할 수 있는 것에 집중하고 할 수 없는 것은 무시해라.
11. 추상화는 복잡성을 없애지 않고 온콜 날짜로 이동시킬 뿐이다.
12. 글쓰기는 명확성을 강요하므로 더 나을 것을 가장 빨리 배우려면 직접 가르쳐 보아야 한다.
13. 문서화, 온보딩, 팀간 조정, 프로세스 개선처럼 다른 작업을 가능하게 하는 작업은 값을 매길 수 없고 보이지 않는다.
14. 모든 토론에서 이기고 있다면, 아마도 침묵의 저항이 쌓이고 있을 것이다.
15. 측정이 목표가 되면 측정을 멈춘다.
16. 모르는 것을 인정하는 것이 아는 척하는 것보다 더 안전하다.
17. 인적 네트워크는 당신이 가질 모든 직장보다 더 오래 지속된다.
18. 대부분의 성과는 명석함을 더하는 것이 아니라 작업을 줄이는 데서 온다.
19. 프로세스는 불확실성을 줄이기 위함이지 기록을 남기기 위한 것이 아니다.
20. 결국 시간이 돈보다 소중해지므로 그것에 맞게 행동해야 한다.
21. 지름길은 없지만 복리는 있다.
Leaving Intel : 컴퓨팅 성능 연구로 유명하고 다수의 책을 쓴 Brendan Gregg이 3년 반을 다닌 Intel을 퇴사했다.(영어)
Ghostty Is Now Non-Profit : Mitchell Hashimoto의 개인 프로젝트로 시작된 Ghostty가 이제 Hack Club의 재정후원을 받게 되었다. 여전히 Mitchell이 가장 큰 재정 후원자이지만 Hack Club을 통해 자금이 사적으로 유용되거나 사명이 바뀌지 않도록 Hack Club의 감사를 받게 되고 지적재산권도 모두 Hack Club으로 이전되었다.(영어)
The Future of Fleet : JetBrains에서 새로운 세대의 IDE를 탐구하려고 Fleet을 시작했지만 기존 IDE를 대체하지도 못했고 새로운 틈새시장도 찾지 못했기에 더 이상 유지할 이유가 없다고 판단하고 12월 22일부터는 다운로드도 중단한다고 한다.(영어)

IT 업계 뉴스

쿠팡 고객 대부분 털렸다‥이름·주소 등 개인정보 3,370만 개 유출 : Coupang의 개인정보 3,370만 건이 유출되었다고 밝혀졌고 자세한 내용은 압수수색 등으로 여전히 조사하고 있다.(한국어)
Netflix to Acquire Warner Bros. Following the Separation of Discovery Global for a Total Enterprise Value of $82.7 Billion (Equity Value of $72.0 Billion) : Netflix가 워너 브라더스를 인수하기로 최종 계약했다. 이번 계약에는 워너 브라더스의 영화와 TV 스튜디오, HBO, HBO Max를 모두 포함하고 주당 27.75달러로 총기업 가치 826억 달러에 거래가 이루어졌다.(영어)
IBM to Acquire Confluent : IBM이 Kafka를 주도적으로 만들고 플랫폼을 운영하는 Confluent를 주당 31달러 전액 현급으로 인수하기로 합의했다. 인수 후에도 Confluent는 독립된 브랜드로 사업을 계속할 것이라고 밝혔고, AI에서 데이터를 활용하는 게 핵심이므로 Confluent가 그 중요한 역할을 할 수 있다고 보고 이런 계약이 이루어졌다.(영어)
Bun is joining Anthropic : JavaScript/TypeScript/JSX 툴킷인 Bun이 AI 모델을 만드는 Anthropic에 인수되었다. Anthropic은 Bun을 Claude Code, Claude Agent SDK 등의 도구에 인프라로 사용할 계획으로 알려졌고 인수 이후에도 Bun은 MIT 라이센스로 유지될 계획이고 기존과 똑같이 개발될 예정이다.(영어)
Why Sourcegraph and Amp Are Becoming Independent Companies : 코드 검색을 지원하는 Sourcegraph에서 코딩 에이전트를 만드는 Amp를 별도의 회사로 분리하고 Dan Adler가 Sourcegraph의 CEO가 되고 Quinn Slack과 Beyang Liu는 Sourcegraph의 이사회에는 남은 상태로 Amp, Inc를 설립할 예정이다. 서로 간의 시너지가 있지만 두 제품은 가른 유통 엔진과 타겟층을 가지고 있으므로 별도의 회사에서 진행하는 게 맞다고 판단했다고 한다.(영어)

프로젝트

Patterns.dev : 바닐라 JavaScript나 모던 프레임워크로 웹 앱을 만들 때 주요한 설계, 렌더링, 성능 패턴을 정리한 온라인 자료.
Fizzy :37signals에서 만든 Kanban 서비스.
Cloudflare Sandbox SDK : Cloudflare의 엣지 네트워크상에서 샌드박스 환경에서 코드를 실행할 수 있는 환경
Brono Simon : Bruno Simon이 3D 게임으로 만든 개인 포트폴리오 사이트.
Cloudflare Prometheus Exporter : Cloudflare의 매트릭을 Prometheus로 노출하는 익스포터

버전 업데이트

Django v6.0 : Python 웹 프레임워크, 릴리스 공지
Spring Tools v5.0.0 : Spring 코딩 환경을 위한 도구, 릴리스 공지
Spring gRPC v1.0.0 : Spring의 gRPC 라이브러리, 릴리스 공지
Lima v2.0.0 : Linux 가상 머신, 릴리스 공지
Hono v4.11.0 : 엣지용 웹 프레임워크, 릴리스 공지
React Native v0.83.0 : React를 이용한 모바일 앱 개발 프레임워크, 릴리스 공지
Zed v0.216.1 : 코드 에디터, 릴리스 공지
Node.js v24.12.0 (LTS)) : 자바스크립트 런타임, 릴리스 공지
OpenTofu v1.11.0 : Infrastructure as Code 도구, [릴리스 공지](https://opentofu. org/blog/opentofu-1-11-0/)
Jotai v2.16.0 : React 상태 관리 라이브러리, 릴리스 공지
Prisma v7.1.0 : TypeScript/Node.js 데이터베이스 툴킷, 릴리스 공지
ClickHouse v25.11 : 컬럼형 데이터베이스, 릴리스 공지
vLLM v0.12.0 : LLM 서빙, 릴리스 공지
Boundary v0.21 : 인프라 접근 관리, 릴리스 공지
Deno v2.6 : TypeScript 런타임, 릴리스 공지
- npx처럼 바이너리를 바로 실행하는 dx 도입
TinyBase v7.1 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지
pnpm v10.26 : Node.js 패키지 매니저, 릴리스 공지
Manus 1.6 : 에이전트 시스템, 릴리스 공지

기술 뉴스 #283 : 25-12-01

2025-12-01T02:34:40+09:00

웹개발 관련

The Web Animation Performance Tier List : JavaScript 애니메이션 라이브러리를 만드는 Motion에서 웹 애니메이션의 성능 퍼포먼스의 티어를 정리했다. 렌더 파이프라인은 Layout, Paint, Composite 순으로 진행되고 앞 단계를 반드시 다음 단계로 실행된다는 특징이 있기에 Composite만 실행할 수 있으면 성능이 가장 좋고 Compositor 스레드가 별도로 있기 때문에 메인 스레드를 사용하지 않는다면 애니메이션이 더 자연스럽게 될 수 있다. 이 특징을 바탕으로 티어별로 어떤 애니메이션이 어떤 티어에 속하는지를 설명한다.(영어)
리액트 서버 컴포넌트는 정말 성능을 개선할까요? : React Server Components: Do They Really Improve Performance?의 번역 글로 React Server Component를 이해하기 위해서 적당한 예제를 중심으로 CSR로 성능을 측정한 뒤에 LCP, 데이터 표시, 상호작용에 걸리는 시간을 캐시 여부와 함께 비교하면서 개선해 간다. CSR의 문제점에서 SSR로 개선한 뒤에 데이터 패칭을 바꿔가면서 테스트한 뒤에 RSC로 바꿨을 때 문제점과 효과적인 부분을 보여주면서 비교해서 이해하기가 좋다.(한국어)
Brand New Layouts with CSS Subgrid : CSS Grid에 이어 새로 등장한 Subgrid의 사용방법을 설명하는 글이다. Grid를 사용했을 때의 편리한 점뿐 아니라 한계점을 보여주면서 이 상황에서 Subgrid를 사용했을 때 얼마나 유용한지 여러 가지 예시와 함께 보여준다.(영어)
WebGPU is now supported in major browsers : 고성능 3D 그래픽과 GPU 연산을 할 수 있는 WebGPU API가 Chrome, Edge, Firefox, Safari에서 모드 지원하게 되었다. WebGPU는 기존 WebGL을 단순히 대체하는 것이 아니라 최신 GPU 기능에 직접 접근할 수 있고 GPU 가속 범용 계산도 가능하게 함으로써 계산 집약적 애플리케이션에서 데스크톱 급의 성능을 제공할 수 있다.(영어)

그 밖의 개발 관련

1,500+ PRs Later: Spotify’s Journey with Our Background Coding Agent (Part 1) : Spotify에서 수천 개의 저장소에 적용되는 의존성 업데이트, 구성 파일 업데이트, 간단한 코드 리팩토링 같은 플릿 매니지먼트의 자동화에 오랫동안 노력했지만, 이 접근방법에는 한계가 있어서 이미 변환 스크립트가 2만 줄이 넘어선 상태였다. 시대가 AI로 넘어가면서 이러한 작업에 AI를 사용하기 위해 작은 CLI를 만들고 MCP를 이용해서 PR을 생성하도록 개선했고 6개월여의 시간 동안 1,500개의 PR을 머지할 수 있게 되었다.(영어)
Background Coding Agents: Context Engineering (Part 2) : Spotify에서 위의 플릿 매니지먼트 자동화 이후 코딩 에이전트를 잘 활용하기 위한 노력이 정리된 글이다. 초기에는 Goose나 Aider 등을 실험했지만 잘되지 않았고 LLM API로 에이전트 루프를 구축했지만, 간단한 변경에서만 잘 작동할 뿐 사용하기가 쉽지 않고 복잡한 변경에서는 어려움을 겪었다. 하지만 Claude Code를 사용하기 시작하면서 훨씬 문제를 잘 해결할 수 있었고 결국 프롬프트를 정교하게 작성해야 한다는 교훈을 깨닫고 이를 개선하기 위해 MCP를 연결하면서도 안전하게 사용할 수 있도록 도구를 제공하게 되었다.(영어)
Introducing Code Wiki: Accelerating your code understanding : 기본 코드를 읽는 데 드는 비용을 줄이기 위해서 코드 저장소를 읽고 구조화된 위키를 지속적으로 유지하는 플랫폼인 Code Wiki를 Google에서 프리뷰로 출시했다.(영어)
Introducing Google Antigravity, a New Era in AI-Assisted Software Development : Google이 새로운 에이전트 개발 플랫폼인 Google Antigravity를 발표했다. Antigravity는 Gemini 3 Pro를 사용해서 브라우저도 제어하고 오랜 시간 생각하면서 에이전트가 소프트웨어를 작성할 수 있는 IDE이다.(영어)
How we built the v0 iOS app : Vercel이 AI 디자인 서비스인 v9의 iOS 앱을 출시하면서 React Native로 이를 어떻게 만들었는지를 설명한다. v0 앱이 모바일 IDE가 아니라 외부에서 아이디어가 떠올랐을 때 노트 앱을 사용하듯이 아이디어를 구현해 보는 경험을 목표로 했기 때문에 훌륭한 채팅이 중요하다고 생각했고 이를 위해 많은 시도 끝에 지금의 형태를 완성했다. 모바일에서 좋은 채팅 경험을 위해 채팅 공간과 키보드로 인한 채팅 영역의 전환, 스크롤, 자연스러운 키보드 처리 등 구현한 방법을 설명하고 있다.(영어)
Pyrefly Beta is here! : Meta라 Rust로 새로 만들고 있는 Python 타입 체커인 Pyrefly를 지난 5월에 오픈소스로 공개했는데 이번에 최종 안정화를 위한 Beta 단계에 돌입했다.(영어)
SHA1-Hulud, npm supply chain incident : 지난 24일 snyk는 NPM 생태계에 SHA1-Hulud로 알려진 새로운 공급망 공격을 확인했다. SHA1-Hulud는 침투한 곳에서 공격자가 제어하는 행동을 할 수 있는 웜으로 숨겨진 preinstall 스크립트가 포함된 트로이목마 npm 패키지가 설치될 때 CI 시스템에서 시크릿을 유출하는 방식으로 동작한다. 이번 공격으로 Zapier, Posthog, Postman 등 600개 이상의 패키지가 감염된 것으로 확인되었다. 같은 공격에 대해 GitLab의 분석 보고서도 있다.(영어)

인프라 관련

2025년 11월 18일 Cloudflare 서비스 중단 : 지난 18일 20시 20분 Cloudflare 네트워크에 오류가 발생했다. Cloudfare에서는 트래픽을 라우팅하는 장비의 Bot 관리 시스템은 요청을 봇 접수를 매기기 위해 머신러닝 모델이 사용하는 특성을 모아놓은 피처 구성 파일이 있다. 이 피처 파일은 몇 분마다 갱신되어 네트워크 전체에 배포되는데, 잘못된 쿼리 결과 때문에 중복 피처가 많이 포함되었고 파일 크기가 2배로 증가하면서 오류가 발생하게 되었다. 봇 모듈의 오류로 여기에 의존하는 핵심 프록시 시스템까지 오류가 발생하게 되었다.(한국어)
From OTel to Rotel: Petabyte-scale tracing with 4x greater throughput : OpenTelemetry 컬렉터와 Kafka를 이용해서 Clickhouse에 저장할 때 OpenTelemetry가 병목 구간이 되는 점을 발견하고 OpenTelemetry 데이터 플레인인 Rotel에서 Rotel로 이를 개선한 과정을 설명한 글이다. 기존과 같은 테스트 환경을 만들고 병목 구간을 확인한 후 Rotel을 사용한 결과를 비교한다. 병목이 되는 부분을 찾아서 JSON 바이너리 직렬화를 구현하고 Tokio의 병목 구간을 개선하고 LZ4을 사용해서 초기 테스트 결과보다 4배 가까이 많은 처리량을 달성할 수 있게 되었다.(영어)
A tale of two incident responses: How our AI assistant found the root cause 3.5x faster : Grafana Labs내에서 장애가 발생했는데 내부에서 개발 중이던 Grafana Assistant Investigations가 8분 만에 원인을 찾아냈지만, 온콜 팀은 같은 결론을 찾아내는 데 28분이 걸렸다고 한다.(영어)
The chip made for the AI inference era – the Google TPU : 2013년 구글은 딥러닝 작업이 컴퓨팅 자원에 크게 문제 될 것으로 생각하고 준비한 TPU가 어떤 특징이 있고 AI에 최적화된 ASIC 장비라서 범용적인 GPU보다 속도 및 비용 효율성 면에서 큰 이점이 있다. TPU의 정보는 제한적으로 공개되어 있으므로 정확한 비교는 없고 많은 사람의 의견을 정리해서 얘기하고 있고 TPU가 향후 Google 클라우드의 경쟁 우위가 될 것이지만 한편으로는 CUDA를 지원하지 않기 때문에 Google 외부에서는 확장성에 문제가 있다.(영어)
The Future of AWS CodeCommit : 2004년 7월 CodeCommit에 새로운 고객을 받지 않던 AWS가 관리하는 코드 저장소가 필요하다는 사용자의 요구 사항에 따라 AWS가 CodeCommit을 다시 사용 상태로 바꾸었다.(한국어)

AI 관련

Introducing Claude Opus 4.5 : Anthropic이 Claude Opus 4.5 모델을 발표했다. Claude Opus 4.5는 소프트웨어 엔지니어링 벤치마크에서 Sonnet 4.5와 Opus 4.1보다 훨씬 우수한 결과를 보여주고 있고 다른 분야에서도 가장 우수한 점수를 보여주었고 토큰 사용량은 더 적은 것으로 나타났습니다.(영어)
A new era of intelligence with Gemini 3 : Goolge이 Gemini 3 Pro를 출시했다. 모든 주요 벤치마크에서 Gemini 2.5 Pro보다 뛰어난 성능을 보여주는 것으로 나왔고 Gemini 3 Deep Think 모드는 추론과 다중 이해 능력이 크게 향상되었다.(영어)
Introducing Nano Banana Pro : Google이 이미지 모델인 Nano Banana의 새 모델인 Nano Banana Pro(Gemini 3 Pro Image)를 발표했다. Nano Banana Pro는 추론력이 향상되어 세계 지식과 실시간 정보를 바탕으로 더 많은 자료를 만들 수 있고 한국어를 포함해서 다양한 언어를 이미지 내에서 사용할 수 있게 되었다.(영어)
Introducing Meta Segment Anything Model 3 and Segment Anything Playground : Meta에서 이미지나 비디오의 객체를 감지, 추적할 수 있는 SAM 3 모델을 발표했다. 이번 발표와 함께 SAM을 테스트해 볼 수 있는 Segment Anything Playground도 함께 발표했다.(영어)
Introducing SAM 3D: Powerful 3D Reconstruction for Physical World Images : Meta가 위 SAM 3 발표와 함께 이미지에서 3D 객체와 인간 신체를 분리해서 3D로 재구성할 수 있는 SAM 3D를 공개했다.(영어)
Introducing advanced tool use on the Claude Developer Platform : Claude가 도구를 잘 사용할 수 있도록 도구를 검색하는 Tool Search Tool, 코드 실행 환경에서 도구를 호출하는 Programmatic Tool Calling, 도구의 사용 방법을 알려주는 Tool Use Examples 세 가지 기능을 추가했다.(영어)

볼만한 링크

웹 업계를 떠나며 : 20년 이상 웹 디자이너/개발자였던 Simone이라는 사람이 쓴 Leaving the web industry의 번역 글이다. 오랫동안 웹 개발자로 일했지만, 디자인과 개발자 사이를 항상 오가면서 풀스택 개발자는 아니었고 프레임워크를 통한 지금의 웹 개발 장식은 망가졌다고 생각해서 더 이상 웹 개발자가 되는 것이 내키지 않았다고 한다. 결국 다른 업계로 전향하기로 하고 케임브리지 대학교의 IT 부서 테크니션 자리에 지원하면서 오히려 그동안 자신이 그 역할을 많이 했다는 것을 깨닫고 이력서도 갈아엎고 합격하게 되었다.(한국어)
Migrating from GitHub to Codeberg : 프로그래밍 언어인 Zig가 처음 git init을 한 이후로 GitHub을 사용하고 있었는데 Microsoft에 인수된 이후 과거에 엔지니어링 우수성이 없어졌다는 게 명백해졌다고 한다. 수많은 GitHub Actions의 버그를 우회하는 데 낭비하기보다는 호스팅 업체를 Codeberg로 바꾸기를 결정했다. GitHub 저장소는 바로 읽기 전용으로 변경되었고 마이그레이션하면서 가장 고민한 건 GitHub Sponsors가 Zig 모금에 큰 부분을 차지하고 있었지만, 이 부분도 부채로 간주하기로 했고, 후원자들도 기부를 Every.org로 옮겨 달라고 부탁하고 있다.(영어)

IT 업계 뉴스

초대형 디지털금융 플랫폼 온다…네이버·두나무 합병안 이사회 통과 : 네이버파이낸셜과 두나무의 포괄적 주식 교환을 통한 합병안이 통과되면서 두나무가 네이버파이낸셜의 100% 자회사가 되게 되었다.(한국어)
업비트서 445억 해킹 사고, 입출금 중단…"전액 보전" : 업비트에서 Solana 기반의 가상 자산에서 해킹으로 445억가량이 출금되는 사고가 발생했다. 피해 금액은 업비트가 보전할 방침이다.(한국어)
넷마블, 해킹 당해 개인정보 유출… “주민번호는 제외” : 게임사인 넷마블이 지난 22일 해킹으로 사용자와 일부 임직원 정보가 유출되었다. 넷마블 PC 게임 사이트의 고객 이름, 생년월일, 암호화된 비밀 정보가 유출될 것으로 현재 파악되어 사용자에게 비밀번호를 변경할 것을 권고했다.(한국어)

프로젝트

typeagent : Structured RAG의 Python 버전.
Fara-7B : 컴퓨터 사용에 최적화된 Microsoft의 첫번째 SLM(Small Language Model)
Zigbook : Zig 프로그래밍 언어를 배울 수 있는 온라인 책.
penpot : 오픈소스 Figma 대체제.
Claude Code Infrastructure Showcase : TypeScript 마이크로 서비스를 6개월간 운영하며 얻은 경험을 바탕으로 만든 Claude Code 쇼케이스의 한국어 번역.

버전 업데이트

Angular v21.0.0 : JavaScript 프레임워크, 릴리스 공지
- Signals 위에 구축된 실험적인 Signal Forms 출시
- Angular Aria 개발자 프리뷰
- MCP 서버 지원
- Vitest를 새로운 테스트 러너로 통합
Spring Boot v4.0.0 : 스프링 애플리케이션의 구축을 도와주는 도구, 릴리스 공지
- Spring Framework 7 기반
- 완전환 모듈화로 더 작은 JAR 제공
Spring Security v7.0.0 : Spring 인증 프레임워크, 릴리스 공지
Spring Integration v7.0 : Spring 내부/외부 메시징 프레임워크, 릴리스 공지
Spring Vault 4.0.0 : 스프링 시크릿 관리, 릴리스 공지
Spring Modulith v2.0 : 모듈화된 스프링 부트 애플리케이션을 만들어주는 도구, 릴리스 공지
Spring for GraphQL 2.0.0 : Spring 프레임워크의 GraphQL 통합, 릴리스 공지
Spring Web Services 5.0.0 : 문서 주도 웹버시스를 만드는 Spring 라이브러리, 릴리스 공지
Spring Cloud v2025.1.0 : 분산 시스템의 일반적인 패턴을 구축하게 하는 도구, 릴리스 노트
Git v2.52.0 : 분산 형상관리 도구, 변경사항
- 디렉터리나 파일을 마지막으로 수정한 커밋을 빠르게 찾는 git last-modified 명령어 추가
- 저장소를 관리하는 git maintenance 명령어가 git gc에 의존하기 때문에 매우 느린 문제가 있는데 geometric 태스크를 도입하여 더 원활하게 관리할 수 있게 됨.
- 저장소 정보를 검색하는 실험적 git repo 명령어
- Git 3.0부터는 기본 브랜치명이 main으로 변경
Grafana v12.3 : 매트릭 대쉬보드, 릴리스 공지
- 새롭게 구축된 로그 패널
- 대시보드를 이미지로 내보내기
Nx v22.1.0 : 모노레포 빌드 시스템, 릴리스 공지
pnpm v10.24.0 : Node.js 패키지 매니저, 릴리스 공지
Zed v0.214.6 : 코드 에디터, 릴리스 공지
Prisma v7.0.0 : TypeScript/Node.js 데이터베이스 툴킷, 릴리스 공지
astro v5.16 : JavaScript 웹 프레임워크, 릴리스 공지
PHP v8.5.0 : 스크립트 언어, 릴리스 공지
- 내장 URI 익스텐션 추가
- 왼쪽에서 오른쪽으로 호출을 체이닝 할 수 있는 |> 파이프 오퍼레이터 지원
- 새로은 clone() 문법 지원
- 반환 값이 사용되지 않을 때 경고해 주는 #[\NoDiscard] 속성 추가
Cursor v2.1 : AI 코드 에디터, 릴리스 공지
GitLab v18.6 : 오픈소스 설치형 Git 플랫폼, 릴리스 공지
Prettier v3.7.0 : JavaScript/TypeScript 포매터. 릴리스 공지
Kyverno v1.16 : Kubernetes 정책 엔진, 릴리스 공지
kgateway v2.1 : Kubernetes Gateway API 구현체, 릴리스 공지
Traefik Proxy v3.6 : HTTP 리버스 프락시/로드 밸런서, 릴리스 공지

기술 뉴스 #282 : 25-11-16

2025-11-16T16:49:40+09:00

웹개발 관련

(번역) JSON 가져오기(import) vs 페치(fetch) : JSON 모듈을 임포트하는 기능이 올해 공식 기능으로 채택됐지만, 이 동작이 실패할 경우 전체 모듈이 중단되기 때문에 브라우저 환경에서는 많이 사용하지 않을 것이다. 대신 fetch()를 사용하면 훨씬 더 많은 검사를 할 수 있고 메모리 누수가 발생할 수 있기 때문에 JSON을 fetch()로 가져오던 것을 대체하고자 할 때는 신중하게 해야 한다.(한국어)
StyleX: A Styling Library for CSS at Scale : Meta가 대규모 애플리케이션을 위한 스타일링 시스템으로 2023년 말 오픈소스로 출시한 StyleX의 접근 방법을 설명한다. CSS의 어려운 유지 보수 문제를 해결하기 위해 로컬 CSS를 JavaScript에 연결하는 CSS 모듈 시스템인 cx를 만들서 쓰고 있었고 이 당시 CSS-in-JS가 인기를 얻고 있었기에 CSS-in-JS의 접근방법을 사용하고 빌드할 때 스타일을 추출해서 정적 CSS로 컴파일하는 StyleX로 cx를 대체하고 CSS 크기를 80% 줄이고 유지 보수하기가 쉬워졌다.(영어)
Intent to Deprecate and Remove: Deprecate and remove XSLT : XML 문서를 다른 형태로 변환하는 표준인 XSLT는 1999년 표준화되어 이후 발전해 왔지만, 현재는 JavaScript 기반 기술로 대체되어 거의 사용되지 않고 있다. Chromium에서도 libxslt가 유지보수가 제대로 되지 않으며 보안 위협의 요소가 되고 있으며 WHATWG에서도 XSLT를 deprecation을 3단계로 옮기기로 해서 Chromium에서도 M143부터 사용되지 않게 하고 M155에서 제거할 계획이 있다.(영어)
(번역) 99%의 개발자가 모르는 ARIA 속성 : Accessible Rich Internet Applications를 뜻하는 ARIA는 접근성의 핵심이다. ARIA에서는 의미론적 HTML이 우선이고 ARIA로 그 부족한 부분을 채워야 하는 원칙을 강조하고 실용적인 예시와 실수하기 좋은 예시를 보여준다.(한국어)
OpenTelemetry Experts Share the Future of Browser Support : OpenTelemetry에 JavaScript SDK가 있지만 Node.js용으로 설계되었기 때문에 브라우저를 더 잘 지원하기 위해 SIG(Special Interest Group)를 출범했다. 브라우저 SIG는 브라우저가 서버와는 다른 특성이 있기 때문에 브라우저 런타임을 위한 OpenTelemetry API, 인스트루멘테이션, 데이터 모델 작업을 먼저하고 있다.(영어)

그 밖의 개발 관련

Mercari’s Phishing-Resistant Accounts with Passkey : Mercari는 단일 앱으로 여러 제품을 제공하기 때문에 사용자의 자격 증명을 공격할 수 있으면 모든 서비스에 다 접근할 수 있기에 피싱 공격의 대상이 되곤 했다. 이를 방지 하는 것을 포함해서 로그인 경험을 개선하고 SMS OTP 비용을 줄이기 위해 Passkey를 도입하기 시작했지만 이후 접근 방식을 바꾸어서 Passkey를 등록하면 더 이상 비밀번호나 SMS OTP를 사용할 수 없도록 바꾸게 되었고 이를 통해 공격 벡터를 줄일 수 있게 되었다. 기존 계정을 Passkey 등록 계정으로 강제로 바꿀 수는 없어서 Passkey 계정도 스스로 Passkey를 복구할 수 있도록 UX를 개선해서 Passkey 등록 계정을 늘리고 있다.(영어)
You Should Write An Agent : 쉽게 이해할 수 있는 큰 아이디어도 있지만 일단 해봐야 이해할 수 있는 기술도 있다. LLM 에이전트를 좋아하든 싫어하든 제대로 판단하려면 직접 해봐야 하는데 에이전트를 작성하는 것은 아주 쉽고 컨텍스트 엔지니어링도 경험해 봐야 무엇이 효과적인지 이해할 수 있게 된다.(영어)

인프라 관련

OpenTelemetry eBPF Instrumentation Marks the First Release : OpenTelemetry에서 Grafana가 기증한 Beyla를 개선한 OpenTelemetry eBPF Instrumentation(OBI)의 첫 번째 알파 버전을 릴리스했다. OBI는 프로토콜 수준에서 계측하기 때문에 애플리케이션 변경 없이 자동으로 추적할 수 있으며 성능 영향을 거의 주지 않고 광범위한 프로토콜을 지원한다.(영어)
Async QUIC and HTTP/3 made easy: tokio-quiche is now open-source : Cloudflare에서 6년 전 Rust로 작성한 오픈소스 QUIC 구현체인 quiche를 공개했는데 이 quiche와 Rust Tokio 비동기 런타임을 결합한 비동기 QUIC 라이브러리인 tokio-quiche를 내부에서 수년간 사용한 후 오픈소스로 공개했다. tokio-quiche는 초당 수백만 개의 HTTP/3 요청을 처리할 수 있는데 처음에는 Cloudflare의 프록시인 Oxy의 HTTP/3 서버용으로 만들었지만, 다른 곳에서도 HTTP/3가 필요해져서 별도의 라이브러리로 만들게 되었다. tokio-quiche의 목표는 필요한 코드 대부분을 직접 제공해서 쉽게 채택해서 HTTP/3와 QUIC이 더 많이 사용되게 하기 위함이다.(영어)
I/O Observability for Uber’s Massive Petabyte-Scale Data Lake : Uber가 하이브리드 클라우드 아키텍처로 발전하면서 HDFS, GCS, Amazon S3에 걸친 스토리지의 데이터 I/O 관찰 가능성이 더 중요해졌다. 공급업체나 엔진과 상관없이 옵저버빌리티를 높여야 했기에 클라이언트를 확장하여 모든 파일 스트림을 가로채서 메트릭 수집하기 시작했다. 이 수많은 메트릭을 수집하기 위해 Apache Flink 기반의 HiCam이라는 경량 메트릭 수집기를 사용해서 높은 카디널리티를 받을 수 있게 되었다. 그 결과 하이브리드 클라우드의 데이터 I/O를 모니터링할 수 있게 되었다.(영어)
Ingress NGINX Retirement: What You Need to Know : Kubernetes 초기부터 사용되던 Ingress NGINX Controller는 큰 인기를 끌고 있지만 생태계가 발전하면서 보안 문제도 있고 유지보수도 쉽지 않은 상황이라 2026년 3월까지 유지 보수 후 중단을 발표했다. 기존 배포는 계속 사용할 수 있지만 Gateway API나 Ingress 등으로 마이그레이션하기를 권장하고 있다.(영어)
State of Containers and Serverless : Datadog이 수만 명의 고객 데이터를 기반으로 분석한 컨테이너와 서버리스 현황 보고서이다.(영어)
- GPU 채택이 증가하고 있다.
- 컨테이너에서 AI 워크로드가 인기 있는 범주에 포함되기 시작했다.
- 대부분의 워크로드는 요청 리소스 대미 메모리는 50% 미만, CPU는 25% 미만을 사용한다.
- Kubernetes를 쓰는 조직의 2/3는 HPA를 사용한다.
- HPA를 사용하는 Deployment에서 20%만이 커스텀 메트릭을 사용한다.
- Karpenter 채택이 Cluster Autoscaler를 추월했다.
- Arm 사용량이 확대되고 있다.
We have launched formae — IaC how it should be : Platform Engineerihng Labs에서 Infrastructure as Code인 formae를 공개했다. 점점 복잡해지는 클라우드를 기존 IaC 도구가 제대로 해결하지 못하고 있어서 Apple의 구성 언어인 Pkl를 기반으로 한 formae를 만들게 되었다고 한다. formae는 코드로 인프라를 관리하고 변경사항을 자동으로 코드화하여 상태 드리프트를 제거하며 지속적으로 동기화하고 상태 관리가 없는 특징을 가지고 있다.(영어)
Cloud Native Computing Foundation Announces Knative’s Graduation : Kubernetes의 서버리스 플랫폼인 Knative가 CNCF 졸업프로젝트가 되었다.(영어)

AI 관련

GPT-5.1: A smarter, more conversational ChatGPT : OpenAI에서 GPT-5.1을 발표했다. GPT-5.1은 Instant 모델과 Thinking 모델로 나누어서 출시했다.(영어)
Introduction to Agents : 목표를 달성하기 위한 계획을 세우고 처리하는 에이전트에 대한 Google의 백서다. 에이전트 시스템의 단계와 아키텍처에 관해 설명한다.(영어)

볼만한 링크

Create on-brand marketing content for your business with Pomelli : Google이 중소기업이 소셜 미디어 캠페인을 쉽게 만들 수 있도록 Pomelli라는 AI 마케팅 도구를 공개했다. Pomelli는 웹사이트를 분석해서 브랜드에 대한 비즈니스 DNA 프로필을 생성하고 이를 통해 맞춤형 캠페인 아이디어를 만들어서 광고 소재를 생성한다.(영어)
Leaving Meta and PyTorch : Meta에서 PyTorch를 공동으로 만들고 프로젝트를 이끌고 있던 Soumith Chintala가 11년간 다니면 Meta를 그만둔다고 한다. PyTorch는 크게 성장했고, 앞으로도 할 일이 많지만, Guido나 Linus처럼 PyTorch만 평생하고 싶지 않고 PyTorch의 메인테이너는 잘하고 있기에 다시 작은 일을 해보려고 퇴사한다.(영어)
Zed Is Our Office : 코드 편집기를 만드는 Zed는 협업 편집기를 만드는 것이 목표 중 하나이기에 Zed에도 쉽고 빠른 협업 기능이 포함되어 있다. 이 협업 기능에는 Channel이라는 가상 방이 있어서 이를 사용해서 회의하고 회의록을 작성하고 프로젝트와 업무 관리도 Zed에서 하고 있다고 한다.(영어)

버전 업데이트

Spring Framework v7.0.0 GA : Java 프레임워크, 릴리스 공지
Homebrew v5.0.0 : OS X 패키지 매니저, 릴리스 공지
Grafana Mimir v3.0.0 : Prometheus 장기 스토리지, 릴리스 공지
- Kafka를 수집과 쿼리 사이의 비동기 버퍼 도입해서 각각 확장 가능해짐
- Ingest 스토리지의 읽기와 쓰기를 분리하여 서로 영향을 주지 않음
.NET 10 : 크로스플랫폼 개발 플랫폼, 릴리스 공지
Vitess 23.0.0 : MySQL 클러스터링 시스템, 릴리스 공지
Grails 7.0.0 : Groovy 웹 프레임워크, 릴리스 공지
Vite v7.2.0 : 프론트엔드 빌드 도구, 변경 사항
LangChain v1.0 : 에이전트 프레임워크, 릴리스 공지
ClickHouse v25.10 : 컬럼형 데이터베이스, 릴리스 공지
Istio v1.28.0 : 서비스 매쉬, 릴리스 공지
Obsidian v1.19.0 : 문서 관리 도구, 릴리스 공지
MikroORM v6.6.0 : TypeScript ORM, 릴리스 공지
Node.js v25.2.0 (Current) : 자바스크립트 런타임, 릴리스 공지
pnpm v10.21.0 : Node.js 패키지 매니저, 릴리스 공지
Docker Desktop v4.50 : 데스크톱용 Docker 애플리케이션, 릴리스 공지
Spring Data 2025.1.0 : Spring 기반 데이터 접근 라이브러리, 릴리스 공지
Spring AI v1.1.0 : AI 엔지니어링을 위한 Spring의 어플리케이션 프레임워크, 릴리스 공지
Docker Engine v29 : Docker 엔진, 릴리스 공지
TanStack DB 0.5 : 클라이언트 스토어, 릴리스 공지
OpenShift v4.20 : 하이브리드 클라우드 플랫폼, 릴리스 공지

기술 뉴스 #281 : 25-11-01

2025-11-01T21:16:19+09:00

웹개발 관련

The Internet’s Biggest Annoyance: Why Cookie Laws Should Target Browsers, Not Websites : GDPR, CCPA 같은 개인 정보 보호법 아래 개인이 자신의 데이터를 제어할 수 있도록 웹사이트에서 쿠키 허락 여부에 대한 팝업이 생겼지만, 결과는 실패라고 얘기하는 글이다. 이에 따라 너무 많은 사이트에도 동의 요청을 받아야 하고 소규모 사이트는 대응하기가 어려우며 실제로 데이터 통제권을 부여하지도 않고 있다. 이를 사이트별로 하는 대신 브라우저 단위로 개인 정보를 제어할 수 있게 하는 것이 더 현실적이고 효과적이라고 얘기한다. 좋은 아이디어라고 생각한다.(영어)
WebAssembly Limitations : WebAssembly가 데이터 특성과 선형 메모리에 스택이 없어서 발생하는 장단점, 메모리 할당 해제, GC 멀티스레딩 등 다양한 WebAssembly의 제약 사항을 잘 정리한 문서다.(영어)
Built-in durability: Introducing Workflow Development Kit : Vercel에서 TypeScript로 워크플로우로 실행할 수 있는 Workflow Development Kit(WDK)을 발표했다. WDK에서는 use workflow와 use step 지시어를 사용해서 워크플로우를 정의해서 실행할 수 있다.(영어)

그 밖의 개발 관련

Claude Code는 괴물이다 – 6개월 하드코어 사용에서 얻은 팁들 : 6개월간 Cluade Code를 사용한 경험으로 알게 된 팁을 정리한 글이다. Skills를 사용할 수 있도록 Hook을 활용해서 Skills를 사용하도록 제어하고 작업 후에 점검하도록 해서 결과물을 크게 개선했다. CLAUDE.md는 프로젝트 고유 정보만 남겨놓고 플래닝 모드를 사용해서 계획을 꼼꼼히 확인한다. 백엔드 개발에선 pm2를 이용해서 Claude Code가 직접 로그나 에러를 직접 확인할 수 있게 했고, Hook을 이용해서 수정할 때마다 기록하고 빌드 검사와 포매팅을 하게 사용하고 있다. 구체적인 사용 방법을 포함해서 어떤 문제를 개선했는지를 자세히 기록해 두어서 참고할 부분이 많다.(영어)
Claude Code on the web : Anthropic에서 웹용 Claude Code를 공개했다. 이를 이용하면 웹에서 GitHub을 연결해서 작업을 시킬 수 있고, 이는 클라우드에서 실행되므로 여러 작업을 병렬로 처리할 수 있다.(영어)
Simplify Your Code: Functional Core, Imperative Shell : 코드의 테스트 및 재사용성을 높이기 위해 코드를 Functionol Core와 Imperative Shell로 분리하는 방법을 예시 코드와 함께 설명한다.(영어)
Announcing the Swift SDK for Android : Swift에서 Swift를 Android에서 사용할 수 있도록 Android Swift SDK를 공개했다.(영어)
uv is the best thing to happen to the Python ecosystem in a decade : Astral이 만든 Python 도구인 uv로 Python 버전을 관리하고 패키지를 설치하고 가상환경을 관리하는 방법을 설명한다.(영어)
Introducing Agent HQ: Any agent, any way you work : GitHub이 GitHub을 모든 에이전트를 통합하는 개방형 에코시스템으로 전환하는 비전인 Agent HQ를 발표하고 Anthropic, OpenAI, Google, Cognition, xAI 등의 코딩 에이전트를 GitHub Copilot 구독의 일부로 사용할 수 있게 될 예정이다. Agent HQ에서는 Mission Control을 이용해서 에이전트를 통합하고 GitHub뿐 아니라 VS Code와 모바일, CLI에서까지 AI 기반으로 지시하고 관리할 수 있게 된다.(영어)

인프라 관련

Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region : 한국 시각으로 10월 20일 오후 3시 48분부터 21일 오전 6시 20분까지 발생한 AWS 버지니아 리전(us-east-1)의 장애에 대한 보고서가 나왔다. 이번 장애는 크게 3가지로 나뉘어진다.(영어)
- 내부적으로 DNS 플래너가 상태를 모니터링해서 각 서비스에 대한 DNS 계획을 생성하고 DNS Enactor가 Route53에 계획을 적용한다. 이 두 컴포넌트는 장애 상황에 대한 대비가 되어 있었지만, 이번 상황에서는 Enactor가 지연되면서 최신 계획을 덮어쓰면서 이전 계획이 삭제됨에 따라 엔드포인트의 IP가 삭제되면서 DynamoDB API에서 DNS 장애가 20일 오후 3시 48분부터 발생하기 시작했고, 수동으로 DNS를 복원해서 6시 40분에 복구를 완료했다.
- 두 번째 문제는 EC2에서 발생했는데 DropletWorkflow Manager(DWFM)가 EC2 호스팅을 위한 물리 서버(Droptlet)을 관리하고 EC2의 네트워크를 관리하는 Network Manager가 있다. 앞의 DynamoDB 문제로 DWFM이 상태 확인에 실패하기 시작했고, 이는 EC2에 직접 영향을 미치지 않았지만, DynamoDB의 DNS가 복구된 후 DWFM이 다시 처리를 시작하면서 너무 많은 요청으로 처리 시간이 초과하기 시작하였고 네트워크 매니저도 네트워크 구성을 전파하는 대기 시작이 증가했다. 이 영향으로 오후 3시 48분부터 버지니아 리전의 EC2 API의 오류가 증가하고 인스턴스 실패가 증가하고 21일 오전 5시 50분에서야 해결되었다.
- EC2 인스턴스의 네트워크 상태 전파가 지연되면서 NLB의 연결 오류도 20일 오후 9시부터 증가하기 시작했고 21일 오전 6시 9분에서야 해소되었다.
- 그 외 DynamoDB에 의존하는 수많은 AWS 서비스에서 오류가 발생했다.
Update regarding Vercel service disruption on October 20, 2025 : AWS의 장애에 영향받은 Vercel의 장애 보고서이다. AWS에 영향받았지만 Vercel의 중단은 Vercel의 책임이라고 얘기하며 두 번의 장애가 발생했는데 us-east-1 장애의 영향으로 고객 트래픽이 일시적으로 중단되었고 피처 플래그가 중단되면서 대시보드나 빌드 등에 영향을 끼쳤다.(영어)
k8s-1m Overview : Kubernetes 클러스터에서 백만 개의 노드를 운영하려면 문제가 되는 곳이 어디인지를 알아보기 위한 프로젝트다. 구성요소에서 백만 개의 노드가 되면 문제가 될 수 있는 Pod IP, IPv6로 운영할 때의 제약사항, etcd의 한계와 개선 가능성, 스케쥴러 등을 살펴보고 백만 개의 노드와 백만 개의 Pod을 Kwok로 실행하면서 각 컴포넌트의 성능을 실험하고 kwok 대신 실제처럼 kubelet을 사용할 때의 차이도 비교해서 보여준다.(영어)
Introducing Updog.ai: Real-time provider status from Datadog : Datadog에서 AWS와 30여 개의 인기 SaaS의 실시간 상태를 확인할 수 있는 Updog을 공개했다. Datadog은 수천 명의 고객에서 수집된 측정 데이터를 익명화하고 이를 AI로 처리해서 외부 공급자의 서비스 상태를 빠르고 정확하게 파악할 수 있게 되었다.(영어)
AWS to Bare Metal Two Years Later: Answering Your Toughest Questions About Leaving AWS : OneUptime에서 2년 전 AWS에서 베어메탈로 전환한 뒤 현재 상황을 정리한 글이다. 지난 2년 동안 MicroK8s와 Ceph를 사용해서 99.993%의 가용성을 달성했고, 파리에 이어 프랑크푸르트에 두 번째 랙을 추가해서 단일 랙 문제를 해결하고 로컬 NVMe로 대기시간을 19% 줄였다. 초기에 연간 23만 달러를 절약했지만, 지금은 120만 달러 이상을 절약하고 있다. 일주일 정도의 작업으로 마이그레이션 할 수 있었고 운영 비용도 AWS와 크게 달라지지 않았다.(영어)
From .com to .anything: introducing Top-Level Domain (TLD) insights on Cloudflare Radar : Cloudflare Radar 사이트에 최상위 도메인인 TLD의 DNS 크기를 분석한 페이지와 개별 TLD의 상세 정보와 쿼리 크기, 지역별 사용 빈도 등을 자세히 볼 수 있는 페이지를 추가했다.(영어)
How many pillars of observability can you fit on the head of a pin? : 프로파일링도 옵저버빌리티의 기둥이냐는 질문을 받고 기둥은 없다는 의견을 정리한 글이다. 옵저버빌리티의 기둥은 마케팅 용어이고 기술적인 용어는 아니면 오히려 시그널이 기술적인 용어라고 할 수 있고 당연히 수많은 시그널이 있을 수 있다. OTel은 3개의 기둥을 강제하지 않고 시그널의 하나로 다루고 있는 것이고 Honeycomb에서 계속 얘기하듯이 다중 기둥 모델은 서로 간의 연결이 끊어져 있기 때문에 시그널을 사일로화하지 말고, 하나로 모아야 한다고 얘기한다.(영어)
Kyverno vs Kubernetes Policies: How Kyverno Complements and Completes Kubernetes Policy Types : 최근 Kubernetes에 네이티브 정책 타입이 추가되어서 CEL(Common Expressions Language)로 로직을 작성해서 사용할 수 있게 되었다. Kubernetes 정책 엔진 프로젝트인 Kyverno는 이러한 Kubernetes의 기능 추가에 맞추어서 Kuberneste의 정책 타입인 ValidatingAdmissionPolicy, MutatingAdmissionPolicy를 확장해서 추가로 정책을 지원하게 되었다. Kubernetes도 정책을 지원하지만 Kyverno를 사용하면 기존 리소스에도 정책을 적용할 수 있고 정책 변경 시에 재적용도 가능하고 배포파이프라인에서 빠르게 피드백을 줄 수 있고 테스트와 결과 보고 등 아직 Kubernetes가 지원하지 않는 많은 기능을 제공하고 있다.(영어)
Microsoft says it’s recovering after Azure outage took down 365, Xbox, and Starbucks : UTC 기준 지난 29일 16시부터 Azure가 부주의한 구성 변경과 DNS 문제로 AFD(Azure Front Door)에 지연시간 증가와 오류가 발생해서 Azure의 많은 서비스와 Microsoft 365, Xbox 등의 사용에 문제가 생겼다. 해당 장애는 30일 00:40에 완화되었다.(영어)

AI 관련

Introducing ChatGPT Atlas : OpenAI에서 ChatGPT가 내장된 새로운 웹 브라우저 ChatGPT Atlas를 공개했다. Free, Plus, Pro, Go 사용자가 모두 사용할 수 있고 지금은 macOS 버전만 출시되었지만, 곧 Windows, iOS, Android용도 출시될 예정이다.(영어)
DeepSeek-OCR: Contexts Optical Compression : 텍스트를 이미지로 만들어서 LLM에 전달해서 토큰을 효과적으로 줄이는 논문과 모델이다. 이미지로 압축했을 때도 OCR 디코딩으로 정확도를 유지하고 고해상도 이미지를 낮은 메모리와 시각 토큰을 적게 유지하는 DeepEncoder를 포함하고 이를 DeepSeek3B-MoE를 기반으로 DeepSeek-OCR을 만들어서 적은 토큰으로 실용성을 강화했다.(영어)
Introducing the Lovable Shopify integration : AI로 앱이나 웹사이트를 만들 수 있는 Lovable이 온라인 커머스 서비스인 Shopify와의 통합을 지원한다. 이를 통해 Lovable에서 온라인 상점을 쉽게 만들 수 있게 되었다.(영어)''
Introducing Agent Skills : Claude가 지침, 스크립트, 리소스가 포함된 폴더와 SKILL.md를 이용해서 특정 작업의 수행을 개선할 수 있게 되었다.(영어)
Bringing memory to Claude : Claude 앱에 메모리가 도입되어 맥락을 다시 설명하지 않고 복잡한 작업을 할 수 있게 되었다.(영어)
Introducing Veo 3.1 and advanced capabilities in Flow : 동영상 생성 모델인 Veo 3.1이 나왔다. 3.1에서 풍부한 오디오와 더 많은 네러티브 제어 및 현실감이 향상되었다.(영어)

볼만한 링크

Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1 : GitHub이 매년 공개하는 Octoverse 보고서가 공개되었다. 지난해 3,600만명 이상이 참여하면서 가장 크게 성장했으면 현재 1억 8천만 명의 개발자가 GitHub을 사용하고 있다. TypeScript가 GitHub에서 가장 많이 사용되는 언어로 올라왔으며 생성형 AI가 개발의 표준이 되었다. Copilot Free 출시 이후 새로운 사용자의 80%가 첫 주에 Copilot을 사용하고 GitHub 역사상 가장 활발한 기여가 일어났습니다. Jupyter Notebooks와 Dockerfiles가 최신 개발에서 가장 많이 사용되었다.(영어)
The Transition of RubyGems Repository Ownership : Ruby 언어의 창시자인 Matz가 RubyGems와 Bundler가 Ruby 생태계에 필수적인 공식 클라이언트이므로 그동안 외부에서 개발되던 RubyGems와 Bundler를 Ruby 코어 팀이 관리하기로 했다고 발표했다. 저장소 소유권이 Ruby 코어 팀으로 이관되고 오픈소스 라이센스는 변경이 없으며 기여자의 저작권도 모두 변경이 없다고 한다. 이 발표는 최근 발생한 Ruby Central과의 소유권 분쟁을 정리한 글이며 Ruby Central에서도 성명을 발표했고 코어 팀과 협업해서 관리과 거버넌스를 할 것이고 rubygems.org는 계속 운영할 것이라고 한다.(영어)

IT 업계 뉴스

The PSF has withdrawn a $1.5 million proposal to US government grant program : 2025년 1월 PSF(Python Software Foundation)은 미국 정부 국립 과학 재단에 오픈소스 생태계의 안전, 보안 및 개인정보 프로그램에 따라 제안서를 제출하고 추천받았다. 하지만 보조금을 받으면 DEI나 차별적 형평성 이데올로기를 발전시키거나 촉진하는 프로그램을 운영하지 않는다는 조건이 포함되어 있었고 PSF의 핵심 가치에 다양성, 형평성, 포용성이 포함되어 있어서 이 조건을 따를 수 없다고 판단하고 PSF 이사회 만장일치로 150만 달러의 정부 지원금을 거절했다.(영어)
Built to benefit everyone : OpenAI가 자본 재편을 완료해서 OpenAI 재단이 1,300억 달러 규모로 영리 단체의 지분을 소유하게 되었고 OpenAI Group PBC라는 공익 법인이 영리 단체로 재단과 함께 목표를 향해 발전하게 되었다.(영어)
Our Series E: Building the global infrastructure of work : 전 세계에 있는 인력을 관리하고 지불 처리를 해주는 서비스인 Deel이 173억 달러(약 24조원)의 기업가치를 평가받고 시리즈 E 펀딩 라운드에서 3억 달러를 유치했다. Deel은 ARR이 10억 달러를 넘어섰고 3년 연속 수익성을 달성하면 이번 8월에는 첫 매출 1억 달러에 도달했다.(영어)

프로젝트

Anthropic Sandbox Runtime (srt) : 컨테이너 없이 OS 수준에서 임의의 프로세스에 파일시스템과 네트워크 제약사항을 강제할 수 있는 경량 샌드박스 도구.
Resterm : 터미널 기반 REST/GraphQL/gRPC/WebSocket/SSE 클라이언트.
Kill Three Pillars : 옵저버빌리티의 세가지 기둥인 트레이스, 로그, 메트릭은 데이터 유형일 뿐이라고 설명하는 웹사이트.
Cap : Loom의 오픈소스 대체제로 동영상을 쉽게 녹화하고 수정해서 공유할 수 있다.
Resume Matcher : 채용 공고를 바탕으로 이력서를 최적화해주는 AI 플랫폼.
Aka Browser : macOS에서 사용할 수 있는 아이폰 모양의 미니 브라우저로 트위터나 동영상을 보는 목적에 최적화되었다.(영어)

버전 업데이트

Vitest v4.0.0 : Vite 유닛 테스트 프레임워크, 릴리스 공지
- 브라우저 모드가 stable이 됨.
Next.js 16.0 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지
- Cache 컴포넌트 지원
- Turbopack이 개발과 프로덕션 빌드에서 안정적으로 되었고 Next.js의 기본 번들러가 됨.
Cursor v2.0 : AI 코드 에디터, 릴리스 공지
- 짧은 에이전트 코딩을 위해 구축되어 30초 이내에 턴을 완료하는 Composer 모델 지원
- 다중 에이전트를 위한 새로운 인터페이스
Valkey 9.0 : 키/밸류 스토어, 릴리스 공지
Rails v8.1.0 : Ruby 웹 프레임워크, 릴리스 공지
- Active Job Continuations로 잡이 완료된 단계부터 실행할 수 있도록 지원
- 후처리가 편하도록 Structured Event 리포팅
- 로컬 CI 지원
Grafana Tempo v2.9.0 : 분산 트레이싱 백엔드, 릴리스 공지
- MCP 서버 지원으로 LLM을 이용한 트레이싱 데이터 분석
- TraceQL 메트릭 샘플링
Lighthouse v13.0.0 : Progressive Web Apps용 성능 분석 도구, 릴리스 공지
Electron v39.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
Biome v2.3.0 : 프론트엔드 툴체인, 릴리스 공지
Nuxt.js v4.2.0 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
GitLab v18.5 : 오픈소스 설치형 Git 플랫폼, 릴리스 공지
pnpm v10.20.0 : Node.js 패키지 매니저, 릴리스 공지
astro v5.15 : JavaScript 웹 프레임워크, 릴리스 공지
Node.js v25.1.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.11.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Node.js v22.21.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
ESLint v9.39.0 : JavaScript 코드 분석 도구, 릴리스 공지
PyTorch v2.9.0 : Python 딥러닝 프레임워크, 릴리스 공지
Manus 1.5 : 에이전트 시스템, 릴리스 공지
ClickHouse v25.9 : 컬럼형 데이터베이스, 릴리스 공지
Elastic v9.2.0 : 엘라스틱 스택, 릴리스 공지
Consul 1.22 : 서비스 디스커버리/설정 도구, 릴리스 공지
typst v0.14 : 마크업 기반 조판 시스템, 릴리스 공지
OpenSearch 3.3 : 분산형 검색 엔진, 릴리스 공지