개발자 어썸블로그

번역서 "다중 에이전트 시스템을 위한 컨텍스트 엔지니어링" 출간 소식 전합니다.

2026-06-20T12:37:00+09:00

새 번역서 ["다중 에이전트 시스템을 위한 컨텍스트 엔지니어링"](/book/context-engineering)이 며칠 전 나왔습니다. ...

오늘도 열심히 했다

2026-06-15T16:07:00+09:00

마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까?

저에게는 그런 날은 하루도 없었던 것입니다.
이 정도면 뭐 할만한 것 아닌가?

이 이야기를 황영조 선수가 유튜브에서 직접 언급하셨네요.

좀 더 열심히 살아야겠다는 동기부여를 받았습니다.

저는 세계 챔피언이 될 생각은 없기 때문에 죽고 싶을 정도로 힘든 날은 경험하지 못하겠지만…
그래도 자기 전에 누웠을 때,
‘아, 오늘도 열심히 했다. 기분 좋다.’
매일 이런 마음으로 잠들 수 있었으면 좋겠습니다.

함께 읽으면 좋은 글:

죽을만큼 힘든 날은 없었다

기술 뉴스 #296 : 2026-06-16

2026-06-16T03:03:20+09:00

웹개발 관련

JavaScript Temporal API: Fixing Everything That Was Wrong With Date : JavaScript의 Date 객체의 현대적 대안인 Temporal API의 기본적인 사용법과 타임존 사용, 날짜 계산, 포매팅 등의 사용법을 설명한다.(영어)
원활한 PWA 출처 이전: 사용자를 잃지 않고 도메인 변경 : Chrome 150부터 프로그레시브 웹 앱(PWA)의 출처 이전을 지원해서 이제 도메인을 바꾸는 경우에도 기존에 설치된 PWA를 이동시킬 수 있게 되었다. 새 앱에 migrate_from을 추가하고, 이전 출처의 .well-known에 마이그레이션을 지정한 뒤 강제로 바꾸게 할지 제안만 할지 선택할 수 있다.(한국어)
Upcoming breaking changes for npm v12 : npm이 7월에 출시될 다음 메이저 버전 v12에서 의존성 설치와 관련된 변경 사항을 예고했다. allowScripts가 기본으로 꺼져서 의존성의 스크립트를 자동으로 실행하지 않고, --allow-git과 --allow-remote도 none이 되어 Git 의존성이나 원격 URL 의존성을 처리하지 않는다.(영어)
Introducing the MDN MCP server : MDN의 문서를 AI가 활용할 수 있도록 MDN에서 MCP 서버를 공개했다.(영어)

그 밖의 개발 관련

A new era for software testing : Redis를 만든 antirez가 AI를 활용한 소프트웨어 개발에서 품질과 시간 사이에 트레이드오프가 있지만, QA와 테스트 분야에서는 품질을 타협하지 않고 프로세스를 자동화하고 있다고 얘기한다. LLM에 테스트 외의 QA를 지시해서 소프트웨어 품질을 높일 수 있다.(영어)
Grit: rewriting Git in Rust with agents : Scott Chacon이 실험적인 목적으로 LLM을 사용해서 Git을 Rust로 재작성한 Grit을 작성했다. Git의 테스트를 이용했고 대부분의 테스트는 통과했지만, 복잡한 push, fetch 기능은 다른 도구에 통합하기 좋게 개선하고 WASM 빌드가 가능해지면서 Edge Function 같은 곳에서 Git 명령어를 모두 사용할 수도 있을 것으로 예상한다. Grit을 만들면서 에이전트가 편법으로 테스트를 통과시키는 걸 막느라 고생했고, 에이전트가 스스로 뭘 망가뜨리는지 알지 못해 중간에 테스트가 크게 깨지기도 했다. 병렬로 오래 돌리는 작업을 하면서 작업 목록 관리가 쉽지 않았고 여러 곳에서 병렬로 실행하는데 자원을 많이 사용해서 고생했다. 이 작업을 하면서 처음에는 OpenClaw에 Claude Code를 연결해서 사용했지만 비용도 비용이고 문제가 계속 발생해서 Cursor 클라우드 에이전트를 사용했는데 꽤 만족했다고 한다.(영어)
Loop Engineering : 루프 엔지니어링은 프롬프트를 직접 입력하는 대신 프롬프트를 입력하는 시스템을 설계하는 방식이다. 루프에는 자동화, 워크트리, 스킬, 플러그인/커넥터, 서브에이전트 다섯 가지 요소와 정보를 기억할 수 있는 메모리가 필요하다. 루프 엔지니어링이 미래라고 생각하지만 여전히 검증은 사람이 해야 한다. 루프를 구축하되 엔지니어로 남으려는 사람처럼 구축해야 한다.(영어)
Agentic Code Review : 코드 작성 비용은 줄어들었지만 코드를 리뷰하는 비용은 그대로인 상황이다. Faros AI에 따르면 AI로 인한 결함과 리뷰 시간이 증가했고, 리뷰 없이 머지된 PR도 증가한 것으로 나타났다. CodeRabbit도 AI가 작성한 코드에서 문제가 많이 발생한다고 얘기하고, GitClear는 10%의 생산성 향상을 위해 4배의 코드를 더 생산한다고 밝혔다. AI 코드 리뷰 도구들은 서로 같은 라인에 리뷰를 남기지 않으므로 최고의 도구 하나를 선택하기보다는 두 가지 도구를 함께 실행하는 것이 더 좋다. 사람이 모든 줄을 읽는 시대는 끝났고, 한 단계 위로 이동해서 모델이 책임지지 못하는 영역을 책임져야 한다고 주장한다.(영어)
I Built an Agentic Harness From Scratch. That Taught Me What Agents Actually Are : Python으로 만든 코딩 에이전트 하네스인 AgentForge를 만들면서 깨달은 점을 정리한 글이다. 파이썬 코드를 예시로 보여주면서 에이전트를 함수처럼 취급하지 않고, 제어 시스템을 구축해 도구를 제공하고 승인하는 방식을 설명한다.(영어)
Porting our Django backend to Rust improved the infra usage by 90% : Wasmer에서 패키지 정보를 제공하기 위해 운영한 Django 백엔드가 Python 개발자도 부족하고 부하가 너무 커져서 3개월간 1명이 AI를 이용해서 Rust로 전환했다. 전환 후 CPU는 220개에서 24개로, 평균 CPU 사용률은 80%에서 30%로, RAM은 800GB에서 64GB로 줄었고 성능도 훨씬 좋아졌다. Rust도 기존 저장소를 같이 사용하고 데이터베이스 모델과 로직을 같이 사용하며 검증기를 별도로 구축했으며 새로운 기능도 양쪽 모두에 같이 구축하면서 마이그레이션했다.(영어)
OpenAI Codex Sites : Codex에서 OpenAI가 호스팅하는 서버에 배포할 수 있는 Sites 플러그인을 미리보기로 출시했다.(영어)
Claude Client SDK CLI : Anthropic이 Claude의 모든 API를 CLI로 직접 사용할 수 있는 ant CLI를 출시했다.(영어)
Windsurf is now Devin Desktop : 작년 7월 Cognition이 Windsurf를 인수하고 이 Windsurf를 Devin Desktop으로 새로 런칭했다. Devin Desktop은 ACP(Agent Client Protocol)을 지원해서 다른 호환 에이전트와 같이 사용할 수 있다.(영어)
Introducing Vercel Drop : Vercel에서 Git이나 CLI를 사용하지 않고 그냥 파일이나 폴더를 브라우저에서 드래그 앤 드롭하면 배포할 수 있는 Vercel Drop을 공개했다.(영어)
MiMo Code: Scaling Coding Agents to Long-Horizon Tasks : Xiaomi의 MiMo 팀이 OpenCode를 기반으로 터미널 기반 코딩 에이전트를 오픈소스로 공개했다.(영어)

AI 관련

Claude Fable 5 and Claude Mythos 5 : Anthropic의 차세대 모델로 알려진 Mythos 계열의 모델인 Claude Fable 5가 출시되었다. 지금까지 공개된 모델보다 성능이 뛰어나고 사이버 보안 등에 끼칠 안전장치로 특정 주제에 대해서는 Claude Fable 5이 직접 대답하지 않고 Opus 4.8이 응답하도록 구성되어 있다. 그리고 보안업계를 위해 안정장치가 제거된 Claude Mythos 5로 Project Glasswing을 통해 배포했다. 공개한지 3일만에 미국 정부의 수출 통제 지침에 따라 모든 외국인의 Fable 5와 Mythos 5 접근이 전면 중단되었다.(영어)
MiniMax M3: Frontier Coding, 1M Context, Native Multimodality — All in One Model : MiniMax의 새 오픈 웨이트 모델 M3가 나왔다. 새로운 어텐션 아키텍처인 MSA(MiniMax Sparse Attention)를 적용해서 1M 컨텍스트를 지원하고 이미지와 동영상을 같이 사용할 수 있는 네티이브 멀티모달을 지원하고 코딩 능력 벤치마크에서도 GPT-5.5와 Gemini 3.1 Pro보다 좋게 나오고 Opus 4.7과 비슷하게 나왔다. M3가 나오면서 MiniMax Code도 공개했다.(영어)
Introducing Gemma 4 12B: a unified, encoder-free multimodal model : Google이 오픈 웨이트 모델인 Gemma 4 12B를 추가로 공개했다. Gemma 4 12B는 처음으로 오디오 입력을 지원하고 새로운 통합 아키텍처를 사용해서 다중 모달 인코더가 없으면 260억 파라미터 모델에 근접한 벤치마크를 보여주면서도 16GB의 VRAM으로 로컬에서도 실행할 수 있다.(영어)
Kimi-K2.7-Code : Moonshot AI에서 Kimi K2.6 기반으로 코딩에 특화된 에이전틱 모델 Kimi-K2.7-Code를 공개했다.(영어)
GLM-5.2 : Z.ai에서 새로운 플래그십 모델 GLM-5.2을 발표했다.(영어)
Fluid, natural voice translation with Gemini 3.5 Live Translate : Google이 실시간 음성 번역용 오디오 모델인 Gemini 3.5 Live Translate를 출시했다. 이 모델은 70개 이상의 언어를 자동으로 감지해서 화자의 억양, 속도, 음높이를 유지하면서 번역 음성을 생성할 수 있다.(영어)

인프라 관련

Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify : Spotify는 에이전트가 등장하기 이전부터 개발자들이 의존성 관리나 마이그레이션, 취약점 패치 등 운영 작업에 많은 시간을 쓰는걸 알게되고 Fleetshift라는 시스템으로 유지 보수 작업을 자동화했다. 하지만 이는 단순한 작업만 자동화할 수 있었는데 LLM이 성숙해 지면서 백그라운드 코딩 에이전트인 Honk를 만들어서 Claude로 실행하도록 했고 Fleetshift와 함게 동작하면서 코드를 수정한다. 이를 통해 Claude가 참고할 코드가 많고 일관성이 있을 때 더 뛰어난 성능을 발휘한다는 것을 깨달았다.(영어)
The war on vibe coding – What belongs in the enterprise toolkit? : 바이브 토딩이 가벼운 데모나 실험에서는 훌륭하게 동작하고 작은 스타트업이라면 괜찮지만 규제를 받는 기존 기업에서는 AI 모델 자체보다 수많은 접근 제어, 승인 절차, 데이터 이력 관리 등 거버넌스와 운영사으이 제약을 뛰어넘는게 더 어려운 일이다. AI 네이티브 엔지니어링에서도 핵심은 속도가 아니라 반복 가능하고 통제된 배포에 있다. 그에 맞게 워크플로우를 재설계하여 초기부터 컴플라이언스와 보안을 참여시키고 시스템을 자동화해서 감독하에 AI의 성과를 낼 수 있게 되었다.(영어)
Your AI bill is out of control. Cloudflare can fix it now. : 회사에서 AI를 사용하면서 공용키를 많이 사용하기 때문에 전체 금액만 알수 있을 뿐 그 이상의 정보는 알기가 어려웠다. Cloudflare AI Gateway를 사용하면 게이트웨이를 통해서 AI를 사용하게 할 수 있는데 여기에 모델이나 프로바이더, 사용자나 팀 별 속성으로 지출 한도를 지정할 수 있고 사용자별로 사용량도 파악할 수 있게 되었다.(영어)
Building ClickCannon - a tool for benchmarking ClickHouse : ClickHouse에서 옵저버빌리티 워크로드의 벤치마크 도구인 ClickCannon을 오픈소스로 공개했다. ClickCannon을 이용해서 처리량을 제어하고 실제 사용자나 쿼리 패턴을 시뮬레이션해서 벤치마크 결과를 분석/비교할 수 있다.(영어)

보안 및 장애

Meta AI chatbot enabled hackers to access others' Instagram accounts : Meta가 지난 3월 AI 지원 챗봇을 통해 Facebook과 Instagram의 계정 관리를 지원하게 된 이후 해커들이 이용해서 특정 계정의 이메일 주소를 변경해 달라고 속여서 유명 Instagram 계정을 탈취했다. 현재 이 문제는 해결된 것으로 알려졌다.(영어)

볼만한 링크

The Intent Debt : Margaret-Anne Storey의 삼중 부채 모델에 따르면 기술적 부채, 인지적 부채, 의도 부채가 있다. 기술적 부채는 코드에 존재하고 인지적 부채는 사람안에 존재하고 의도 부채는 산출물에 존재한다. 의도 부채는 이 산출물이 왜 이런 모습이 되었는지에 대한 근거 등이 소실된 상태를 얘기한다. 이 세가지 부채중 의도 부채는 에이전트가 해결해 줄수 없는 영역이고 그동안은 사람의 머릿속에 의도가 있었기에 어느정도 의도 부채를 버틸수 있었는데 에이전트는 속도가 빠르고 의도가 없기 때문에 의도 부채는 더 빠르게 커지게 된다. 이를 해결하기 위해 의도에 대한 명세를 작성하고 결정할 때마다 그 내용을 기록해서 의도를 기록해야 한다.(영어)
Show Your Work : 과거 소프트웨어는 바이너리로 배포되었고 그 내용을 볼수 없었지만 오픈소스는 소스 코드를 공개해서 투명성을 제공했다. AI의 오픈 웨이트 모델은 바이너리로 제공하는 것과 똑같아서 그 안을 볼수 없다. 그래서 AI 모델이 데이터 출처부터 추적할 수 있게 공개하고 학습에 동의할 수 있는 프레임워크를 구축해서 편향이 생기지 않도록 삼사를 할 수 있어야 한다. 이러한 윤리를 지키려고 하는 회사는 그렇지 않은 회사보다 느리고 비용이 클것이므로 규제를 통해서 이를 따르도록 해야한다고 얘기한다.(영어)

IT 업계 뉴스

Anthropic confidentially submits draft S-1 to the SEC : Anthropic이 미국 증권거래위원회(SEC)에 기업 공개(IPO)를 위한 S-1 양식의 초안을 비공개로 제출했다.(영어)
SpaceX IPO : SpaceX가 기업 공개(IPO)를 위해 사이트를 열었다. 투자 설명서 IPO 관련 정보를 볼 수 있다.(영어)
VoidZero is Joining Cloudflare : Vue.js를 만든 Evan You가 Vite를 만들고 나서 자바스크립트 생태계의 통합 툴체인을 구축하기 위해 설립한 VoidZero가 Cloudflare에 인수되었다. VoidZero는 Vite, Vitest, Rolldown, Oxc를 만들었지만 오픈소스를 통한 수익화는 쉽지 않았고 Cloudflare를 통한 Vite 배포 플랫폼을 만들 던 중 인수되었다.(영어)
NVIDIA and Microsoft Reinvent Windows PCs for the Age of Personal AI : NVIDIA에서 개인용 에이전트 전용으로 설계된 RTX Spark 칩을 발표했고 Windows PC에 탑재될 예정이다.(영어)

프로젝트

Odysseus : 직접 운영할 수 있는 AI 워크스페이스로 채팅과 에이전트 등 다양한 작업을 한 곳에서 할 수 있다.
Velopack : 크로스 플랫폼 데스크톱 어플리케이션의 설치 및 자동 업데이트 프레임워크.
Magenta RealTime 2 : 로컬 라이브 뮤직 모델을 사용해서 악기를 연주할 수 있는 앱으로 Google이 공개했다.
kage : 헤드리스 Chrome으로 페이지에서 자바스크립트를 제거하고 똑같은 사이트를 만들어서 오프라인에서 실행할 수 있게 만들어준다.

버전 업데이트

Angular v22.0.0 : JavaScript 프레임워크, 릴리스 공지
Homebrew v6.0.0 : OS X 패키지 매니저, 릴리스 공지
Elixir v1.20.0 : 프로그래밍 언어, 릴리스 공지
Lynx v3.8 : 웹 기술로 Android, iOS, 웹 어플리케이션을 만들 수 있는 기술, 릴리스 공지
Grafana Tempo v3.0.0 : 분산 트레이싱 백엔드, 릴리스 공지
- 오브젝트 스토리지 비용을 절감할 수 있는 새로운 아키텍처 도입
- TraceQL 메트릭 정식 출시
Node.js v26.3.0 : 자바스크립트 런타임, 릴리스 공지
ClickHouse v26.5 : 컬럼형 데이터베이스, 릴리스 공지
Spring Vault v4.1 : 스프링 시크릿 관리, 릴리스 공지
Spring Modulith v2.1 : 모듈화된 스프링 부트 애플리케이션을 만들어주는 도구, 릴리스 공지
Spring HATEOAS v3.1 : Spring에서 HATEOAS를 따르는 REST API를 만들 수 있는 라이브러리, 릴리스 공지
Spring AI v2.0.0 : AI 엔지니어링을 위한 Spring의 어플리케이션 프레임워크, 릴리스 공지
Phoenix LiveView v1.2.0 : Phoenix 서버의 서버렌더링으로 웹 페이지를 만드는 기능, 릴리스 공지
Spring Tools v5.2.0 : Spring 코딩 환경을 위한 도구, 릴리스 공지
React Native v0.86.0 : React를 이용한 모바일 앱 개발 프레임워크, 릴리스 공지
FastAPI v0.137.0 : Python 웹 프레임워크, 릴리스 공지
Gukhanmun v0.2.0 : 국한문혼용체를 한국전용으로 바꿔주는 Rust/JavaScript 라이브러리, 릴리스 공지
Biome v2.5.0 : 프론트엔드 툴체인, 릴리스 공지

엔지니어의 경영에 대한 생각

2026-06-19T08:45:43+09:00

회사를 경영하는 경영진과 엔지니어가 온전히 같은 생각을 가지고 나아가기는 쉽지 않은 것 같다. 서로의 배경과 목표가 조금씩 다른 것이다. 주니어 시절에는 회사의 경영적인 의사결정을 접할 기회가 거의 없었다. 연차가 올라가면서 경영진들의 상황과 결정에 대해서 더 많이 듣고 접하게 된다. 그런 경험 가운데 이런건 좋았고, 이런건 이렇게 하면 좋겠다고 생각한 것들이 있어 정리해 본다.

1. 재활용에 목숨 걸기

회사에 아직 안정적으로 수익을 내는 제품이 존재하지 않을 때 경영진들은 어떻게든 새로운 일을 만들고 여러 프로젝트를 동시에 진행하려 한다. 반면 엔지니어들은 한 번에 한 가지 프로젝트에 집중하기 원한다. 엔지니어들은 대게 회사가 새로운 판을 벌이고 싶으면 이전 판을 접고 피벗을 하길 원하고, 기존 것을 유지하면서 새판을 벌이고 싶다면 새로운 팀을 두기를 원한다. 어느 회사에 가더라도 이 두 조직은 정도는 다르지만 크고 작은 이런 의견 충돌을 겪는다. 회사는 회사 나름대로 사업을 확장해야만 하고 엔지니어들은 전혀 다른 두 가지를 동시에 하는데 한계를 느낀다. 새 일을 위해 새 팀을 만드는 건 비용이 많이 들고 리스크가 크다. 그렇다고 하나의 사업만 하는 것도 회사 생존의 문제가 있고 똑같이 위험하다. 이런 상황이라면 재활용에 목숨을 걸고 새로운 사업을 만들고 확장해 나갈 필요가 있다고 생각한다. 기존 제품에서 재활용할 수 있는 부분을 극단적으로 늘리고 변경은 최소화하여 일을 확장할 수 있는 전략을 모색하는 것이다. 그래서 사업이 늘어나도 우리의 기반으로부터 하나의 탑이 일관되게 쌓여가는 느낌이 들게 하고, 계속 제품이 선형적으로 성장해 나가는 느낌이 들게 하는 것이다. 이것 저것 계속 기반만 닦고, 똑 같은 길을 도도리표처럼 다른 방법으로 반복하는 느낌이 들면 안된다고 생각한다. 이건 그냥 느낌의 문제가 아니라 제한된 자원으로 목표를 달성하는 효율의 문제이다.

2. 투자해서 굴러오게 하기

경영진들은 엔지니어들에 비해 회사의 재무 상황에 큰 압박을 받는다. 엔지니어들은 월급이 잘 나오면 상대적으로 돈에 대한 스트레스는 덜 받는다. 경영진들은 엔지니어들에 비해 더 큰 리스크를 안고 사업을 시작했고, 엔지니어들은 상대적으로 리스크가 더 적다고 느낀다. 그래서인지 경영진들은 종종 무리를 해서라도 무언가를 지금 당장 빨리 얻고 싶어 했다. 이런 결정은 대부분 실제 일을 하는 엔지니어들의 공감을 얻지 못했고 두 조직 사이에 갈등을 일으켰다. 급하게 먹으면 체하곤 한다. 뭔가를 급히 얻는 선택 대신, 그것을 얻는데 필요한 일에 투자를 하는데 집중하는게 정도라는 생각이 든다. 씨를 뿌리고 열매가 맺히길 기다리는 마음으로 원하는 곳에 투자를 하고 결과가 굴러오지 않을 수 없게 만드는 것이다. 나는 사실 이 부분에 대한 나의 의견이 정답이라고 생각하지는 않는다. 급하게 먹는게 좋지 않은 걸 알지만 어떤 경우는 그렇게라도 먹어서 힘을 내야 하는 경우도 있기 때문이다. 다만 그렇게 급하게 먹어야 하는 상황을 만들지 않도록 관리를 해야한다는 방향성을 가지고 사업을 하면 좋겠다. 그리고 급하게 먹는데 넘지 말아야 할 선은 있다. 그 선을 넘지는 말아야 한다.

3. 내일 이루면 의미가 달라진다

무언가를 무리해서 당장 해야한다는 경영진의 설명 중에 가장 설득력 있었던 말이 생각난다. 그때 그는 똑같은 일을 오늘 하는 것과 내일 하는 것은 시장에서 완전히 다른 의미를 가진다고 했다. 시장을 선점하는 것이 중요하다는 취지의 말이었다. 이미 누가 해본 걸 나도 내일 했다고 말하는 건 매력이 없다는 것이다. 그 말에 설득되어 내가 할 수 있는 최선을 다해서 일을 이루기 위해 노력했던 적이 있다. 그러나 무리해서 일하는 것에 한계가 있음을 다시 말하지 않을 수 없다. 정말 오늘 이루고 싶다면 어제부터 준비하고 투자를 했어야 한다. 기초 공사를 하지 않고 높은 건물을 올릴 수 있는 길은 없다. 기초 공사 없이 높은 건물을 올리기 시작하면 곧 무너질 일만 남는다.

소통이 설계를 결정한다

2026-06-15T22:08:54+09:00

사람들은 흔히 시스템 설계 품질은 설계자의 기술적인 역량에 의해 결정된다고 믿습니다. 세상의 많은 책과 교육들이 그것을 다루고 있으며 실제로 사실이기도 합니다. 그러나 현실에서 프로젝트가 진행되는 것을 진지하게 관찰해보면 설계자의 기술 역량은 조직 내에 숨겨져 있는 다른 무언가에 의해 제한되는 것을 관찰할 수 있습니다.

1. 소통이 시스템을 망친다

해외 기업과 협력해 제품 개발을 한 적이 있습니다. 그런데 프로젝트 초기 단계부터 그들과 소통이 삐걱되기 시작했습니다. 우리의 중요한 설계 결정 사항들이 그들에게 의존하고 있었는데 메일로 질문을 하면 답이 잘 오지 않았고, 기술적으로 애매한 영역에 대해 질문하면 합리적인 이유 없이 안된다는 답변이 돌아왔습니다. 그로 인해 우리는 몇 가지 중요한 주제에서 제품 설계를 결정하기 어려운 상황에 놓였고, 어쩔 수 없이 시스템을 매우 보수적으로 설계하기 시작했습니다. 중요한 설계 결정에서 그들이 기능을 제공하지 않을 수 있다는 가정을 가지고 설계를 했고, 그들이 제공하기로 한 중요한 기능의 스펙은 제안 단계에 가볍게 정의했던 최소한의 수준으로 제약했습니다. 이후에 기적 같이 제품이 완성되었고 실제 운영도 하게 되었는데, 후에 본 그들의 시스템은 훨씬 많은 일을 하고 있었고 제품 스펙도 기대 이상으로 좋았습니다. 하지만 그런 정보를 설계 단계에 제공 받지 못한 우리는 그들이 이미 하고 있는 일을 이중으로 구현했고, 실제로 훨씬 오랜 시간 운영 가능했지만 거의 1/6 수준의 스펙으로 운영할 수 있게 모든 관련 설계가 제한되어 버렸습니다.

2. 사회적 역량

시스템 설계자는 하얀 도화지 위에 시스템을 그린다고 믿지만, 사실은 조직 내 구성원들 간에 소통 경로라는 좁은 길을 따라 펜을 움직일 수밖에 없습니다. 우리는 시스템을 설계할 때 한 개인이 모든 것을 통제할 수 없는 시스템의 경계를 마주하게 되는데, 이 경계에서는 혼자서 무엇이든 결정할 수 없고 반드시 인접한 구성원과의 소통을 통해 의사결정을 내려야 합니다. 조직 내 수 많은 경계에서 원활한 소통이 일어나고 이를 통해 제품 개발에 필요한 정보 교환과 결정들이 원활히 이루어질 때 우리는 그 조직의 사회적 역량이 높다고 말합니다. 사람들은 흔히 이 사회적 역량이 좋은 설계에 영향을 미치는 중요한 요소임을 간과합니다. 하지만 조직의 사회적 역량은 조용하지만 강력하게 시스템 설계에 영향을 미칩니다. 조직 내 수 많은 소통 채널에서 이루어지는 모든 기술적 의사결정들의 합이 곧 시스템의 설계 품질로 이어지기 때문입니다.

3. 조직의 특징들

사회적 역량이 낮은 조직에서는 몇 가지 공통된 특징들이 나타납니다. 이런 특징들은 사람들 사이에 대화의 장벽을 만들고, 사람들이 불편한 대화보다는 “그냥 내 선에서 적당하게 처리하자”는 선택을 하게 만듭니다. 결국 시스템은 파편화되고 기형적인 해결책들로 서서히 망가져 가게 됩니다. 제가 지난 커리어 기간 동안 관찰한 몇 가지 특징들을 정리해 봅니다. 혹 우리 조직에 이런 모습이 만연해 있지 않은지 돌아볼 수 있으면 좋겠습니다.

나만 좋으면 돼

소통이 안되는 조직에는 자신의 편의만을 우선시하는 문화가 만연해 있습니다. 이런 조직에서 소통은 '나의 일을 남에게 떠넘기기 위한 논쟁'으로 변질되곤 합니다. 내가 구현하기 힘든 기능을 인접한 다른 파트로 미루거나, 타 파트에 미칠 영향을 고려하지 않고 자기 파트에 유리한 쪽으로 설계 변경을 단행합니다. 이러한 자기중심적 소통은 인터페이스의 일관성을 해치고 전체 시스템의 안정성을 위협합니다. 한때 배달의 민족이라는 회사에 걸려있는 문구로 유명했는데, 조직을 구성하는 우리는 타인의 입장을 생각하는 마음의 중심을 가질 수 있어야 합니다. (우아안 기술블로그 참고)

근거 없는 대화

조직이 함께 문제를 해결하기 위해서는 필연적으로 서로에게 문제를 설명하고 해결책을 설득하는 과정을 거쳐야 합니다. 이때 설명하는 측은 상대방이 이해할 수 있는 합리적인 근거를 가지고 설명할 수 있어야 합니다. 이것은 말하는 사람의 기술적 역량과 말하는 커뮤니케이션 역량 모두를 요구합니다. 듣는 사람 역시 상대의 설명을 이해할 수 있는 기술적 배경과 듣는 커뮤니케이션 역량을 함께 가지고 있어야 합니다. 말하는 사람과 듣는 사람 모두 기술과 커뮤니케이션 역량 어느것 하나 빠지면 소통이 어려워집니다. 소통이 잘되는 조직의 구성원들은 기술적인 성숙도와 커뮤니케이션 능력을 두루 가지고 합리적인 대화를 이끌어 갑니다.

배타적 태도

어떤 문제에 대해 함께 문제를 해결하려는 태도는 소통의 기본이 됩니다. 네 쪽에서 드러난 문제는 너 혼자 해결하고 내 쪽에서 드러난 문제는 나 혼자 해결한다는 식의 배타적인 태도는 균형잡힌 최선의 해결책을 찾는데 걸림돌이 됩니다. 시스템은 유기적으로 동작하기에 함께 대안을 생각할 때 최적의 해답이 나올 수 있습니다.

지나친 의존관계

반대로 소통이 필요 이상으로 일어나는 경우에도 조직의 사회적 역량을 떨어뜨리는 이유가 됩니다. 앞서 소개한 배타적인 태도와는 반대되는 상황인데, 문제 해결 과정에서 문제 원인이나 해결책이 어느 정도 식별되고 나면 그 다음부터는 문제가 드러난 파트에서 문제 해결을 전담하면 됩니다. 그런데 아직 성숙되지 못한 초기 조직은 시스템이 잘 나누어져 있지 않아 파트 간에 강한 의존관계를 가지고 있는 경우가 많습니다. 그래서 특정 파트의 개발과 시험을 위해서 다른 파트 엔지니어가 계속 지원을 해주어야 하는 경우가 생기고, 지원하는 쪽에서는 자신의 파트를 설계하고 개발하는데 써야할 시간을 상당 부분 빼앗기게 됩니다. 이런 현상이 지나치게 자주 나타나면 이제 시스템의 각 파트가 독립적으로 개발하고 시험할 수 있게 시스템을 고도화 해야할 때라는 신호입니다. 조직과 설계자가 이 신호를 무시한다면 지원하는 파트에서 개발에 필요한 충분한 시간을 사용하지 못하게 되고 궁극적으로 시스템에 좋지 않은 영향을 미치게 됩니다.

문맥에서 벗어난 의견

때때로 사람들은 자기에게 주어진 역할을 넘어 다른 사람의 일에 지나치게 참여하고자 하는 경우가 있습니다. 다른 사람의 문제 해결을 함께 고민하고 결과에 대한 리뷰 의견을 주는 것은 분명 좋은 것인데, 어떤 경우 이런 행동은 일을 주도하는 조직을 방해합니다. 이것 역시 잘못된 방향의 소통이라 할 수 있습니다. 일이 방해되도록 의견을 주는지, 일의 도움이 되도록 의견을 주는지 판단할 수 있는 좋은 기준이 한 가지가 있습니다. 일에 방해가 되도록 의견을 주는 사람은 일을 주도하는 팀의 문맥을 알지 못하고 단편적인 현상만 보고 자기 의견을 냅니다. 예를들면 엔지니어는 바꿀 수 없는 이런 저런 악조건 속에서 최선의 선택을 한 것인데, 악조건에 대해서는 알지 못하면서 최선의 선택이 왜 최고가 아닌지 피드백을 주는 경우가 있습니다. 엔지니어들끼리 불편한 의견을 나누고 치열하게 토론하는 것은 좋은 일이지만 일을 주도하는 조직의 문맥을 알지 못하고 이런저런 의견을 내는 것은 팀에 도움이 되지 않습니다. 어떤 일에 함께 참여하길 원한다면 나의 의견을 말하기 전에 상대의 문맥을 이해하는데 먼저 시간을 써야합니다. 소통이 잘되는 조직은 활발한 의견이 오가기 전에 상대의 문맥을 이해하는 조용한 시간에 충분한 시간을 할애합니다.

바꿀 수 없어

대화를 통해 좋은 해결책이 도출되더라도 이를 시스템에 적용할 수 없다면 소통은 무의미한 에너지 소모가 됩니다. 수주 사업처럼 계약 범위에 묶여 좋은 아이디어가 있어도 시스템에 적용할 수 없거나, 이미 구축된 부실한 서브 시스템이 '변경 불가'라는 성역이 되어버린 경우가 대표적 경우입니다. 이러한 경직성은 설계자가 더 나은 구조를 제안할 의지를 꺾고, 시스템이 나쁜 구조 위에서 계속 비대해지도록 방치합니다.

느린 응답

소통의 '골든 타임'을 놓치는 것도 큰 장애 요소입니다. 담당자들이 너무 많은 프로젝트에 참여하고 있어 요청에 대해 시기적절하게 응답하지 못하면, 무한정 기다릴 수 없는 상대 팀은 임의의 가정을 가지고 개발을 진행하기도 합니다. 이러한 응답의 지연은 문제가 뒤 늦게 발견되게 하고 이후에 수정 비용을 기하급수적으로 높이는 원인이 됩니다. 조직이 시기적절하게 문제를 함께 논의하고 응답할 수 있도록 일의 양이나 동시성을 제어하는 것도 좋은 소통 채널을 만들기 위한 중요 요소가 됩니다.

휘발되는 소통

소통이 안 되는 조직의 또 다른 특징 중 하나는 "말로만 하고 끝나는 것"입니다. 메신저나 말로 나눈 대화는 시간이 지나면 각자의 기억 속에서 다르게 해석되거나 소멸됩니다. 문서화된 합의점이 없기에 과거의 논의를 반복하거나, 서로 다른 이해를 가진 채 개발을 진행하다가 통합 단계에서 예상치 못한 이해 충돌을 맞닥드리기도 합니다. 정리되어 기록되지 않는 소통은 조직의 지식을 축적하지 못하게 하고 아키텍처의 근거를 모호하게 만듭니다. 좋은 소통 채널에서의 소통은 잘 정리되고 기록됩니다. 경험에 의하면 회의에서 모두가 동의한 것 같아도 문서로 다시 정리한 내용을 읽어보면 몇 가지 사실을 다르게 이해한 경우가 많았던 것 같습니다.

4. 맺으며

시스템 설계는 기술이라는 도구로 조직의 소통을 기록하는 행위로 표현될 수 있습니다. 소통의 실패는 시스템에 지울 수 없는 비효율의 흔적을 남깁니다. 따라서 좋은 시스템 설계를 원하는 조직이라면 이제 기술문서와 코드를 들여다 보는 것을 넘어 조직 내 소통 그래프를 들여다 보아야 합니다. 원하는 시스템의 모습대로 조직의 소통 채널을 건강하게 유지하는 것이 최선의 설계를 완성하는 시작이 될 것입니다.

[SE-0531] Literal Expressions

2026-06-21T05:47:30+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0531 — Literal Expressions에 대해 정리해보겠습니다

Intro

Proposal: SE-0531
Authors: Artem Chikin, Doug Gregor
Review Manager: Ben Cohen
Status: Active Review (May 18...29, 2026)

Motivation

Swift에는 정수 리터럴 값만 허용하는 세 가지 문법 컨텍스트가 있습니다.

generic value arguments(SE-0452), @section 변수(SE-0492), enum raw value.

지금까지는 개발자가 직접 값을 계산해서 bare literal로 손수 옮겨 적어야 했어요.

이 과정에서 값이 의미하는 바가 사라지고, 코드 전반에 "매직 넘버"가 퍼지게 됩니다.

@section과 컴파일타임 초기화

@section은 페이지 크기, 레지스터 오프셋처럼 다른 상수로부터 값이 파생되는 시스템/임베디드 환경을 겨냥한 어트리뷰트입니다.

하지만 지금은 연산자나 변수 참조를 전혀 허용하지 않아요.

@section("__DATA,config") let pageSize = 4096
@section("__DATA,config") let bufferSize = 65536
@section("__DATA,config") let c = 1 + 1  // ❌ error: operators not allowed

4096이 4 × 1024라는 사실도, bufferSize가 16 × pageSize라는 관계도 코드만 봐서는 전혀 알 수 없었어요.

Enum raw value

Swift 1.0부터 enum raw value는 순수 리터럴만 허용했습니다. bit-flag enum처럼 shift 표현이 자연스러운 경우조차 표현할 방법이 없었어요.

enum Permissions: Int {
  case read = 1
  case write = 2
  case execute = 4
}
// 1 << 0, 1 << 1, 1 << 2 라고 쓰는 게 훨씬 의도가 명확한데도 불가능했어요

정수 제네릭 인자

SE-0452가 도입한 정수 제네릭 파라미터도 마찬가지로 bare integer literal만 허용합니다.

let schemaRowSize = 32

// 원하는 것: InlineArray<(2 * schemaRowSize), UInt8>
let buffer: InlineArray<64, UInt8>  // 64 == 2 * 32 이길 바랄 뿐...

세 가지 컨텍스트 모두 같은 근본적인 제약을 공유합니다.

개발자가 사람 계산기 역할을 해야 했고, 그 값이 왜 그 숫자인지에 대한 의도는 사라져버렸어요

Proposed Solution

이 제안은 Literal Expression(리터럴 표현식)을 도입합니다.

표준 라이브러리 정수 타입의 리터럴, 산술/비트 연산자, 그리고 컴파일타임에 알려진 다른 정수 변수 참조로 구성된 표현식이에요.

이 표현식은 컴파일 타임에 단일 리터럴 값으로 상수 폴딩됩니다.

// @section — 연산과 변수 참조 모두 가능
@section("__DATA,config") let pageSize = 4 * 1024
@section("__DATA,config") let bufferSize = 16 * pageSize

// enum raw value — shift 표현이 가능
enum Permissions: Int {
  case read    = 1 << 0
  case write   = 1 << 1
  case execute = 1 << 2
}

// 정수 제네릭 — 괄호로 감싼 표현식 허용
let schemaRowSize = 32
let buffer: InlineArray<(2 * schemaRowSize), UInt8>

중요한 점은, literal expression을 사용해 컴파일된 모듈은 개발자가 직접 미리 계산한 리터럴을 쓴 모듈과 완전히 동일한 산출물을 만들어낸다는 거예요.

Detailed Design

Literal Expression의 문법

literal-expression → integer-literal
literal-expression → unary-operator literal-expression
literal-expression → literal-expression binary-operator literal-expression
literal-expression → '(' literal-expression ')'
literal-expression → identifier

지원하는 연산자: 산술(+ - * / %), wrapping(&+ &- &*), 비트(& | ^), shift(<< >>), masking shift(&<< &>>), 단항(+ - ~).

일반 산술 연산자는 오버플로우를 컴파일 타임에 진단하고, wrapping 연산자는 결과를 타입의 비트 너비로 silent하게 모듈러 처리합니다.

let a = 4 * 1024                  // ✅ 산술
let b = 1 << 12                   // ✅ 비트 시프트
let c = (0xFF & mask) | base      // ✅ 비트 연산 + 괄호
let d = -1                        // ✅ 단항 부정
let w: UInt8 = 250 &+ 10          // ✅ wrapping 덧셈, 4로 폴딩
let e = Int.max / 2               // ❌ 프로퍼티 접근 불가
let f = a +% b                    // ❌ 사용자 정의 연산자 불가

연산자 lookup은 Swift의 일반 name lookup 규칙을 그대로 따릅니다. 만

약 lookup이 사용자 정의 오버로드로 해석되면, 표준 라이브러리 오버로드가 스코프에 같이 있더라도 전체 표현식이 거부됩니다.

Literal Expression 내 변수 참조

literal expression은 다른 변수를 이름으로 참조할 수 있습니다.

단, 그 변수가 let 바인딩이고, 기본 초기화 값 자체도 literal expression이어야 해요.

let pageSize = 4 * 1024
let bufferSize = 16 * pageSize             // ✅ pageSize 참조

import CSystem
let systemBuffer = 4 * SYSTEM_PAGE_SIZE    // ✅ C 상수

var mutableSize = 4096
let derived = 2 * mutableSize              // ❌ var는 참조 불가

let computed: Int = { 4096 }()             // ❌ 초기화식이 literal expression이 아님
let derived2 = 2 * computed

주의할 점 — public, package, open 접근 수준의 변수는 literal expression에서 참조할 수 없습니다.

폴딩이 일어나면 해당 변수의 초기화식이 모듈의 ABI 표면에 노출되는 셈인데, 이는 이 제안의 "ABI 변경 없음" 원칙과 충돌하기 때문이에요.

@section 변수 초기화식

@section("__TEXT,config") let pageSize = 4 * 1024
@section("__TEXT,config") let bufferSize = 16 * pageSize
@section("__TEXT,config") let systemPage = PAGE_SIZE    // C 상수

원본 표현식은 진단과 IDE 인덱싱을 위해 AST에 보존되지만, .swiftinterface 파일에는 출력되지 않습니다.

Enum raw value

enum Permissions: UInt8 {
  case read    = 1 << 0    // 1
  case write   = 1 << 1    // 2
  case execute = 1 << 2    // 4
}

enum Example: Int {
  case a = 2 + 2    // 4
  case b            // 5
}

정수 제네릭 인자

generic-argument → type
generic-argument → '-'? integer-literal
generic-argument → '(' literal-expression ')'   // 새로 추가된 형태

제네릭 인자 위치에서는 <, >, , 토큰이 구분자 역할을 하기 때문에, literal expression은 반드시 괄호로 감싸야 합니다.

let schemaRowSize = 32
let buffer: InlineArray<(2 * schemaRowSize), UInt8>    // ✅
let flags: InlineArray<(1 << 4), Bool>                 // ✅
let small: InlineArray<5, Int>                         // ✅ 기존처럼 괄호 없이도 동작

폴딩된 값이 곧 타입 동일성을 결정합니다.

InlineArray<(2 + 3), Int>와 InlineArray<5, Int>는 동일한 타입이에요.

컴파일타임 진단

let x: UInt8 = 100 * 3    // ❌ error: integer overflow
let y = 10 / 0           // ❌ error: division by zero
let z = 10 % 0           // ❌ error: division by zero

@section("__TEXT,data") let a = abs(-1)    // ❌ error: not supported in a literal expression

Source Compatibility

이번 변경은 세 가지 표현식 컨텍스트를 확장할 뿐, 다른 곳에서 받아들여지던 표현식 형태를 제거하거나 바꾸지 않습니다.

흥미로운 케이스 하나는 제네릭 인자 목록의 모호성 해소입니다.

컴파일러는 괄호 안의 내용을 먼저 타입 표현식(튜플)으로 해석을 시도하고, 실패할 때만 literal expression으로 해석합니다.

예를 들어 Foo<(a < b, c > .d)>(x) 같은 코드는 기존의 체이닝 비교 연산으로 폴백되어 의미가 바뀌지 않습니다.

ABI Compatibility

literal expression은 컴파일러 프론트엔드 내에서 완전히 폴딩되며, 코드 생성·런타임·심볼 맹글링에 변화가 없습니다.
정수 제네릭 인자의 경우 폴딩된 값이 모듈 인터페이스에 타입의 일부로 나타납니다 (예: InlineArray<5, Int>).
@section 변수와 enum raw value는 원본 표현식도, 폴딩된 상수도 모듈 인터페이스에 나타나지 않습니다.

Implications on Adoption

이 기능은 LiteralExpressions 실험적 기능 플래그로 게이팅되어 있습니다.

폴딩이 컴파일 타임에 일어나고 생성되는 코드가 직접 작성한 리터럴과 동일하기 때문에, 최소 배포 타겟 제약이 없습니다.

Future Directions

괄호 제약 완화 — 제네릭 인자 위치에서 >, ==, , 를 stop 토큰으로 처리해 InlineArray<2 + 3, Int>처럼 괄호 없이도 파싱 가능하게 만드는 방향
부동소수점 literal expression — Float, Double에 대한 산술 연산 지원
문자열 literal expression — 컴파일타임 문자열 연결 및 보간
비교 연산자 및 표준 함수 지원 확대 — ==, min(), max() 등, 나아가 컴파일타임 Bool을 활용한 삼항 연산자 및 if/else 표현식
컴파일타임 프로그래밍 — SE-0359와 연계해 사용자 정의 순수 함수, 풍부한 데이터 타입까지 포괄하는 일반적인 컴파일타임 프로그래밍 모델로의 확장

Alternatives Considered

참조되는 모든 변수에 명시적 어노테이션 요구

@const 같은 명시적 어노테이션을 요구하는 방식도 고려되었습니다.

하지만 SE-0359 리뷰에서 이런 어노테이션의 "전염성(virality)"이 핵심 우려로 지적된 바 있어요.

literal expression의 경우 어노테이션이 컴파일러가 이미 알고 있는 정보 이상을 제공하지 않기 때문에, 추론만으로 충분하다고 판단해 채택하지 않았습니다.

"Constant Expression" 대신 "Literal Expression" 용어 사용

C/C++의 전통을 따라 "constant expression"이라는 용어를 쓰는 방법도 있었지만, 스코프와 과대 약속의 위험이라는 두 가지 이유로 "literal expression"을 선택했습니다.

Swift가 향후 더 큰 컴파일타임 개념을 도입할 때를 위해 "constant expression"이라는 이름을 아껴두는 것이 합리적이라고 판단했습니다.

Conclusion

지금까지 @section, enum raw value, 정수 제네릭 인자는 모두 "사람이 직접 계산해서 bare literal로 옮겨 적어야 하는" 동일한 제약을 공유하고 있었어요

Literal Expression은 이 세 컨텍스트에 산술·비트·단항 연산과 변수 참조를 허용함으로써, 코드에 값의 의도를 직접 드러낼 수 있게 해줍니다.

그러면서도 컴파일 타임에 완전히 폴딩되기 때문에 ABI나 런타임에는 전혀 영향이 없다는 점이 인상적이에요.

매직 넘버 대신 16 * pageSize, 1 << 2처럼 의미가 드러나는 코드를 쓸 수 있게 되는, 작지만 가독성 측면에서 정말 실용적인 변화라고 생각합니다

References

swift-evolution/proposals/0531-literal-expressions.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

짚을 것과 넘길 것

2026-06-20T09:00:00+09:00

요즘 들어 리뷰를 하다 말고 멈칫하는 순간이 잦아졌다.

도구가 코드를 빠르고 정확하게 내놓는다. 예전 같으면 한참 들여다봐야 했을 코드가, 이제는 꽤 표준적인 모습으로 단숨에 나온다. 그 코드를 앞에 두고 나는 자주 묻게 된다. 이걸 어디까지 봐야 하는가. 한 줄 한 줄 의도를 따지는 일이 아직 내 몫인가, 아니면 이미 도구에게 넘겨도 되는 일인가.

리뷰가 느려 보이기 시작할 때

생산 속도가 빨라지면, 꼼꼼히 보는 일이 어느 순간 흐름을 막는 것처럼 보이기 시작한다. 다들 빠르게 짓고 빠르게 넘기는데, 거기서 멈춰 "이건 왜 이렇게 하셨어요"라고 묻는 사람은 자칫 속도를 갉아먹는 사람이 된다.

그래서 편한 결론이 하나 있다. 동작에 문제가 없고 도구가 내놓을 법한 표준적인 모양이면, 그냥 합의하고 넘어가자는 것이다. 틀린 말은 아니다. 다만 나는 그 결론이 너무 빨리 내려질 때 마음이 불편하다. '동작에 문제가 없다'와 '이 자리에 맞다'는 같은 말이 아니기 때문이다.

실제로 1억 5천만 줄의 코드를 분석한 한 조사는, AI 도구가 퍼진 뒤 작성된 지 2주도 안 돼 되돌려지거나 갈아엎어지는 코드의 비율이 뚜렷이 늘었다고 보고한다(GitClear, 2024–25). 빠르게 나온 코드가 늘 맞는 코드는 아니었던 셈이다.

그리고 하나는 분명히 해두고 싶다. 도구가 코드를 더 많이 쏟아내는 것을, 우리는 너무 쉽게 '생산성이 올랐다'고 말한다. 하지만 2주도 못 가 지워질 코드를 더 빨리, 더 많이 만든 것이 대체 어떤 의미의 생산성인가. 그건 생산성이 아니라 그냥 양(量)이다. 측정하기 쉬운 숫자를, 측정해야 할 가치와 바꿔치기한 것에 가깝다. 쏟아낸 줄 수가 늘었다는 사실 자체는 아무것도 증명하지 않는다. 생산성은 코드의 양이 아니라, 그 코드가 무엇을 풀었고 얼마나 오래 살아남았는가로만 매겨진다.

"내 능력의 90%는 가치가 0달러로 떨어졌다. 남은 10%의 영향력은 1000배가 됐다. 다시 보정해야 한다."
— 켄트 벡(Kent Beck), 「90% of My Skills Are Now Worth $0」(2023)

리뷰는 원래 무엇을 보는 일이었나

생각해보면 리뷰는 오타나 문법을 잡는 일이 아니었다. 그런 것은 가장 값싼 축에 속하고, 지금은 도구가 가장 잘하는 일이기도 하다.

"AI가 내놓는 한 조각 한 조각을, 코드 양으로는 무척 생산적이지만 어딘가 미덥지 않은 동료가 보낸 풀 리퀘스트처럼 다뤄야 한다."
— 마틴 파울러(Martin Fowler), The New Stack 인터뷰(2026)

리뷰가 진짜로 하는 일은 의도와 코드 사이의 거리를 좁히는 것이었다. 이 코드가 우리가 생각한 그것을 정말로 말하고 있는지, 놓일 자리에 맞게 쓰였는지를 맞춰보는 일. 그건 규칙을 대조하는 일이 아니라 판단하는 일이다.

그렇다면 도구가 규칙 대조를 가져갈수록 리뷰의 가치는 사라지는 게 아니라 위로 옮겨간다. 기계가 채워주는 표준이 흔해질수록, 사람이 보아야 할 것은 오히려 또렷해진다. 옳은 코드인지가 아니라, 지금 여기에 맞는 코드인지.

경계는 양이 아니라 종류의 문제

그래서 질문을 바꿔야 한다고 생각하게 됐다. "얼마나 리뷰할 것인가"는 틀린 질문이다. 많이 보느냐 적게 보느냐의 문제가 아니다. 진짜 질문은 "무엇은 사람만이 볼 수 있는가"이다.

기계적이고 표준적인 것은 도구에 맡긴다. 사람의 주의는 의도와 맥락, 트레이드오프, 정답이 하나로 떨어지지 않는 것들에 아껴 쓴다. 경계는 리뷰의 분량을 줄이는 선이 아니라, 무엇을 어느 쪽에 둘지 가르는 선이다.

"LLM이 코드의 모든 줄을 썼더라도, 당신이 그 전부를 리뷰하고 테스트하고 이해했다면 그것은 바이브 코딩이 아니다."
— 사이먼 윌리슨(Simon Willison), 「Not all AI-assisted programming is vibe coding」(2025)

같은 이유로, 내가 남기는 코멘트도 두 종류로 나뉜다. 하나는 명백한 것 — 약속한 의도와 코드가 어긋나 있는 지점. 다른 하나는 갈릴 수 있는 것 — 취향이나 무게가 사람마다 다른 지점. 이 둘을 같은 강도로 들이밀 때 리뷰는 무거워진다. 앞엣것은 분명히 짚고, 뒤엣것은 가볍게 건넨다. 경계를 잘 긋는다는 건, 모든 관찰에 같은 무게를 싣지 않는 일이기도 하다.

혼자 그은 선은 반드시 부딪힌다

여기까지는 나 혼자의 정리다. 그리고 정작 어려운 건 그다음이었다.

경계는 내가 혼자 그을 수 있는 것이 아니었다. 누군가는 "이 정도는 당연히 봐야지"라는 선을 말없이 긋고, 누군가는 "그건 도구한테 맡기고 넘기면 되지"라는 선을 말없이 긋는다. 두 개의 보이지 않는 선은 언젠가 반드시 부딪힌다. 말로 꺼내지 않은 기준은, 미뤄둔 갈등일 뿐이다.

그러니 경계를 어디에 둘지는 끝내 도구의 문제가 아니라 사람 사이의 문제다. 팀이 함께 합의해야 하고, 처음 같이 일하는 사이라면 서로의 기준부터 맞춰두어야 한다. 그 대화를 미루면, 매번 작은 코멘트 하나가 기준에 대한 큰 다툼으로 번진다.

그렇다면 그 합의는 코드가 올라온 뒤가 아니라 그 전에 이뤄지는 게 낫다. 무엇을 풀려 하고 왜 이렇게 접근하는지를 먼저 맞춰두면, 리뷰는 한 줄 한 줄을 심문하는 일에서 합의한 방향과 어긋난 곳을 찾는 일로 바뀐다. 그제야 리뷰는 코드 한 줄이 아니라 전체 변경의 흐름을 본다. 방향을 맞추지 않은 채 코드부터 내미는 것은, 요청만 던지고 알아서 해두라고 맡긴 AI에게 결과물을 받아 든 것과 그리 다르지 않다 — 사람이 쓴 코드라도 그렇다.

물론 반대 방향의 함정도 있다. '이건 이제 안 봐도 된다'는 합의는 늘 한쪽으로만 굴러가기 쉽다. 도구에 맡길 수 있는 영역은 분명 늘겠지만, 안 보기로 한 목록은 근거에 따라 다시 줄어들 수도 있어야 한다. 줄어들 줄 모르는 목록은 합의가 아니라 방심이다.

도구가 코드를 대신 써주는 일은, 사실 그렇게 두려운 변화가 아닐지도 모른다. 그것은 도리어 우리가 미뤄두었던 질문을 되묻게 한다. 코드를 짜는 행위 너머에 있는 의도, 맹목적인 속도보다 중요한 방향.

결국 도구의 시대에 우리가 다시 마주해야 하는 것은, 다름 아닌 '사람의 일'이 아닐까.

옳은 코드와 맞는 코드

2026-06-18T09:00:00+09:00

오래 지켜보며 갖게 된 생각이 하나 있다.

코드를 정말 잘 짜는 사람이 있다. 구조도 깔끔하고 추상화도 정교하다. 그런데 그 옆에는 어딘가 엉성하게, 대충 짜는 것처럼 보이는 사람이 있다. 흥미롭게도 시간이 지나고 보면 조직에서 더 신뢰받는 쪽은 종종 후자다. 설계의 순수성을 끝까지 지키려던 사람이 오히려 변두리로 밀려나는 일을, 나는 여러 번 보았다.

흔히들 운이나 사내 정치 때문이라고 말하면 편하겠지만, 나는 거기에 다른 본질적인 이유가 있다고 생각한다.

이미 건너간 강에 다리를 놓는 일

순수성을 지키려는 쪽이 빠지기 쉬운 함정이 있다. 모두가 이미 건너간 강에 혼자 남아, 세상에서 가장 튼튼한 다리를 놓겠다고 고집하는 모습이다.

기한이 코앞인데도 설계를 다시 손보는 일을 멈추지 못한다. 사업의 방향이 이미 다른 곳을 향하는데도 지금 짜고 있는 코드의 우아함을 놓지 못한다. 쓰는 사람이 몇십 명뿐인 서비스에 거대한 트래픽을 가정한 구조를 욕심내고, 곁에서 함께 일하는 동료의 숙련도는 배제한 채 본인이 익히고 싶은 신기술을 밀어붙인다. 그러다 누군가 속도와 타협을 이야기하면 '품질'이라는 단어를 방패처럼 빼든다.

본인은 그것을 신념이라 부를 것이다. 하지만 내가 보기엔 신념이라기보다, 어느 순간 비용과 효용의 계산을 멈춰버린 맹목에 가깝다. 아무리 튼튼한 다리라도 건너야 할 사람이 남지 않은 곳에 놓고 있다면, 그건 솜씨가 아니라 헛수고일 뿐이다.

그리고 정작, 그렇게 완벽을 좇는 사람이 끝내 완벽한 무언가를 내놓는 것을 나는 본 기억이 없다. 완벽은 늘 다음 버전에, 리팩토링이 끝난 다음에, '조금만 더 시간이 있었다면'의 저편에 머물러 있었다.

품질을 어디에 쓸 것인가

나는 품질이 그 자체로 목적이 될 수는 없다고 생각한다. 적어도 누군가의 시간과 자본으로 굴러가는 조직 안에서는 그렇다.

품질은 모든 곳에 똑같이 쏟아붓는 것이 아니라, 어디에 집중하고 어디에서 손을 뗄지 고르는 '선택'의 문제다. 평소에는 약속한 기한을 지켜 신뢰를 쌓아두고, 정말로 시스템이 무너질 것 같은 치명적인 순간에 그 신뢰를 담보로 설계를 지켜낸다. 매 순간 모든 코드에 최고치만 욕심내는 사람에게는, 정작 진짜 버텨야 하는 순간에 끌어다 쓸 신뢰의 잔고가 남아있지 않다.

대충 짜는 것처럼 보였던 그 사람은, 아마 어디에 힘을 주고 어디에서 힘을 빼야 할지를 누구보다 잘 알고 있었을 것이다.

옳은 코드와 맞는 코드

요즘은 AI가 더없이 표준적인 코드를 순식간에 내놓는다. 깔끔하고, 모범적이며, 어지간한 사람보다 낫다.

그런데 그 코드는 회사에 남은 시간이 얼마인지 모른다. 이 기능이 다음 분기를 무사히 넘길 수 있을지, 당장 이번 주에 무엇을 포기해야 하는지도 모른다. 코드가 옳은지는 알지만, 그 코드가 놓일 자리에 맞는지는 모른다는 뜻이다.

상황을 보지 않는 완벽주의는 실력이라기보다 일종의 자기만족에 가깝다. 도구가 표준을 대신 채워주는 시대가 올수록, 옳은 코드 그 자체는 점점 흔해지고 값이 싸질 것이다.

무엇을 버려야 하는가

"완벽함이란 더 보탤 것이 없을 때가 아니라, 더 덜어낼 것이 없을 때 도달하는 것이다."
— 앙투안 드 생텍쥐페리

오래도록 좋아하는 문장이다.

진짜 실력은 '더할 게 없는 상태'를 만드는 데서 증명되지 않는다. 지금 무엇을 덜어내야 하는가를 정하는 자리에서 증명된다. 도구가 날카로워질수록, 개발자는 코드를 더 잘 짜는 일이 아니라 더 높은 곳에서 결단을 내리는 일로 떠밀려 간다. 무엇을 포기하고, 무엇을 미루고, 어디에서 멈출 것인가.

깊이 고민해야 하는 건 코드의 우아함이 아니라, 이 코드가 다른 무엇을 포기하게 만드는지, 그리고 '지금이 그것을 할 때인지'라고 믿는다.

그래서 잘 짜인 코드를 홀로 오래 들여다보는 사람을 보면, 가끔 대신 묻고 싶어진다.

그 고집은 지금 곁에 있는 사람들을 함께 끌어올리고 있는가.

아니면, 그 자신을 외딴섬에 홀로 세워두고 있는가.

디지털 시대의 아버지, 클로드 섀넌(Claude Shannon)

2026-06-15T00:00:45+09:00

Anthropic이 제공하는 에이전틱 코딩 도구의 이름은 클로드 코드(Claude Code)입니다. 이때 클로드가 사람 이름인 것을 알고 계셨나요? 클로드는 정보이론의 아버지로 불리우며, 현 디지털 정보 시대의 초석을 놓은 인물로 평가받고 있습니다.

1916년 미시간에서 태어난 클로드는 어릴때부터 기계와 전기 분야에 재능을 보였다고 합니다. 집에서 무선 조종 비행기, 보트를 만들었고, 800미터 떨어진 친구 집을 철조망으로 연결하여 전신 시스템 비슷한 장치를 만들면서 놀았다고 합니다. 어린 시절 발명왕 토머스 에디슨을 존경했는데, 두사람 모두 존 오그던의 후손입니다. 발명가의 피가 흐르는 집안이 있는걸까요?

1936년 미시건대학교에서 전기공학과 수학을 전공한 클로드는 MIT에서 전기공학 석사과정을 시작합니다. 이듬해 석사학위논문인 '릴레이 및 스위칭 회로의 기호 해석(A Symbolic Analysis of Relay and Switching Circuits)"을 작성했는데, 이 논문은 디지털 공학을 만든 논문으로 평가받고 있습니다. 이 논문 이전에는 전기회로를 설계할 때 숙련된 감각이나 복잡한 물리적 실험에 의존했습니다. 하지만 새넌은 스위치가 닫혀서 전기가 흐르는 상태를 1, 열려서 전기가 흐르지 않는 상태를 0으로 정의합니다. 이는 곧 True/False와 마찬가지라는 뜻이지요. 회로의 연결을 논리 연산으로 치환하여, 직렬연결은 논리곱(AND), 병렬연결은 논리합(OR)연산과 같다는 발견을 통해 복잡한 전기회로를 기호로 이루어진 수식으로 바꿀 수 있음을 보여주었습니다. 불 대수가 전기 회로에 접목되면서 복잡한 수식을 대수법칙으로 간단하게 정리할 수 있게 되었고, 실제 물리적인 회로도 불필요한 스위치와 배선을 제거할 수 있게 되었습니다.

우리가 사용하는 모든 디지털컴퓨터는 전기스위치를 사용하여 논리를 구현하고 있습니다. 섀넌의 연구는 디지털 회로 설계의 기초가 됩니다. 그래서 애니악 개발에 참여했던 허먼은 "디지털 회로 설계를 예술에서 과학으로 바꾸는데 기여한 논문"이라고 평가합니다.

제2차 세계대전중에는 영국의 수학자였던 앨런 튜링을 만나서 독일 해군의 암호 해독 방법을 함께 연구했다고 합니다. 그때 튜링이 범용 튜링 머신 아이디어를 정의한 논문을 섀넌에게 보여주었다고 합니다. 섀넌은 벨 연구소에서 암호화에 관련된 몇가지 증명을 수행합니다. 이후 CIA의 특수 암호학 자문 그룹(SCAG)의 일원으로도 활동합니다.

외발 자전거를 타면서 저글링하는 클로드 섀넌

섀넌은 아내와 함께 테세우스(Theseus)라는 이름의 학습 기계를 설계하여 제작합니다. 이 기계는 미로를 통과하는 기계 쥐의 경로를 추적하면서 학습하여, 미로의 임의 위치에 쥐를 놓으면 미로를 통과하는 최단 경로를 학습하여 빠져나올 수 있게 만든 장치였습니다. 일종의 인공 학습장치로 보입니다. 섀넌은 '체스 게임을 위한 컴퓨터 프로그래밍', '컴퓨터와 오토마타'와 같은 인공지능 관련 논문을 여러편 작성했습니다.재기발랄한 섀넌은 궁극의 기계(Ultimate Machine)를 만들었는데요. 이 장치는 스위치를 켜면, 박스에서 손이 나와서 스위치를 다시 꺼버립니다. 그외에도 저글링 공을 튕겨내는 저글링 로봇, 로마숫자로 계산을 수행하는 트로박(THROBAC) 등을 개발했습니다.

섀넌은 투자도 잘한 것으로 알려져 있는데요. 1950년 후반부터 86년까지 그의 포트폴리오를 65년부터 95년까지 워렌버핏의 포트폴리오와 비교해 보면 새년의 수익율이 28%였고, 버핏은 27%였답니다. 섀넌의 투자 방법은 현금과 주식을 같은 비율로 구성하고 정기적으로 리밸런싱하면서 주가의 변동성을 활용하는 방법이라고 합니다. 주식 투자는 물리학의 천재 뉴턴도 망했던 분야인데 말이죠.

그는 2001년 향년 84세로 세상을 떠났는데, 조각가 유진 다웁(Eugene Daub)에 의해 그의 동상 6개가 만들어졌고, 미시건 대학교, MIT 정보 및 의사결정시스템 연구소, 고향 미시건주 게일로드, UC 샌디에고, 벨연구소, AT&T 섀넌 연구소에 있습니다. AI업체인 앤트로픽은 그를 기려 LLM 이름을 Claude로 짓습니다.

정보는 불확실성을 해소하는 열쇠이다.( “Information is the resolution of uncertainty.”)

우리는 과거를 알지만 통제할 수 없습니다. 우리는 미래를 통제할 수 있지만, 알 수는 없습니다.

저는 응용 분야에는 거의 관심이 없습니다. 오히려 문제의 우아함에 더 관심이 많습니다. 좋은 문제인지, 흥미로운 문제인지에 관심이 갑니다.

The Bit Player - Claude Shannon documentary film

www.youtube.com

수학적 커뮤니케이션 이론 | 클로드 섀넌 - 교보문고

수학적 커뮤니케이션 이론 | 『수학적 커뮤니케이션 이론』은 인간과 사회의 커뮤니케이션 과정을 수학으로 설명할 수 있다고 주장하는 최초의 언론학 모형이다. 커뮤니케이션 과정을 어떻게

product.kyobobook.co.kr

내가 생각하는 좋은 회의

2026-06-14T18:00:00+09:00

사람과 함께 일한다는 건 생각보다 어렵다. 일을 시작할 때 우리는 대개 문제를 풀러 모인다. 더 좋은 제품을 만들고 싶고, 더 나은 결과를 내고 싶고, 맡은 몫을 잘 해내고 싶다. 그런데 한동안 일하다 보면, 일을 정말로 어렵게 만드는 건 문제가 아니라 사람이라는 걸 알게 된다. 같은 문제를 보면서도 각자 중요하게 여기는 지점이 다르고, 같은 설명을 듣고도 전혀 다른 결론에 이른다. 그래서 조직에서 일한다는 건 문제를 푸는 일인 동시에, 서로 다른 머릿속을 맞춰 가는 일이기도 하다. 한때 나는 좋은 회의란 가장 논리적인 사람이 나머지를 설득하는 자리라고 생각했다. 근거가 가장 탄탄한 의견이 채택되고, 모두가 거기에 고개를 끄덕이는 과정이라고 믿었다. 지금은 조금 다르게 본다. 기억에 남는 회의들을 떠올려 보면, 이상하게도 누가 이겼는지가 기억나지 않는다. 누구의 안이 통과됐는지조차 흐릿한 경우가 많다. 대신 이런 장면이 남는다. 누군가 말을 하다 잠깐 멈추고 "아, 그러면 이건 안 되겠네요" 하며 자기 말을 스스로 접는다. 그 한마디에서 대화의 방향이 살짝 틀어지고, 거기에 다른 사람의 우려가 얹히고, 비어 있던 자리가 채워지면서, 처음보다 조금 나은 생각이 만들어진다. 회의가 끝날 무렵이면 처음의 의견은 이미 여러 번 모양을 바꾼 뒤다. 누구의 생각이었는지 가려내기 어려울 만큼 서로 섞여 있다. 좋은 회의는 아마 그런 것 같다. 내 생각을 지켜내는 일이 아니라, 같이 생각을 키워 가는 일이다. 그런데 이게 말처럼 쉽지가 않다. 많은 토의를 해온 사람도, 스스로 이성적이라고 생각하는 사람도, 나도 모르게 내면에서는 그렇지 않을 때가 많다. 오래 다듬은 아이디어일수록 비판은 생각에 대한 이야기가 아니라 나를 건드리는 것처럼 느껴진다. 앞에서 말한 것처럼 내가 스스로 '이건 안 되겠다'고 접을 때와, 남이 그렇게 말할 때는 다르다. 회의 전에는 아이디어와 사람을 분리하자, 개인적으로 받아들이지 말자는 말이 반복된다. 그런데 그렇게 말해도, 사람은 감정적으로 반응하기 마련이다. 그 말은 반응을 없애는 방법이 아니다. 반응이 올 수 있다는 걸 알면서도, 과제 중심으로 말하자는 약속에 가깝다. 어쩌면 그럼에도 토의를 계속해야 하기에 꺼내는 말일지도 모른다. 그래서 좋은 토의에는 논리만으로는 부족하다. 내가 맞을 수도 있지만 아닐 수도 있다는 마음, 설득하기 전에 먼저 이해해 보려는 마음, 더 나은 생각이 나타났을 때 내 것을 내려놓을 수 있는 여유가 필요하다. 회의에서 A 기술이 맞다, B는 안 된다고 말할 때도, 나도 그랬다. 그런데 돌이켜보면, 내가 아는 게 진짜 다 아는 건 아니었다. 내 경험이 내 지식의 경계를 그리고, 그 안에서만 주장을 계속했던 경우가 많았다. 그것만 써 봤고, 다른 선택지는 제대로 모르고 있었는데도, 옳다고 믿는 것과 내가 아는 범위 안에서 옳아 보이는 것을 같은 말로 착각하기 쉽다. 그래서 요즘은 주장하기 전에 반대로 생각해 본다. 왜 내가 이쪽을 편들고 있는지, 경험의 편향 때문은 아닌지. 그리고 저 사람은 왜 저런 이야기를 하는지, 그 상황에서 무엇을 보고 말하는 건지. 내가 모르는 쪽에서 다시 짚어 본다. 그런데 더 큰 문제는, 그렇게 강하게 논의했던 것들이 시간이 지나면 의미가 없었던 경우가 많다는 것이다. A로 하든 B로 하든, 이쪽이든 저쪽이든 상관없었던 일이 생각보다 훨씬 많았다. 오히려 그 논의가 업무 진행을 막고, 딜레이만 만들었던 경우도 적지 않았다. 물론 정말로 중요한 결정도 있지만, 차이를 만든 건 선택 자체가 아니라, 실행하고 배우고 고치는 속도였다. 우리는 정답을 알아서 토의하는 게 아니다. 오히려 정답을 모르기 때문에 토의한다. 토의는 정답을 고르기보다, 결정에 앞서 서로의 우려를 꺼내 두고 같이 이해해 두기 위해서다. 그래야 막상 움직일 때 모두가 같은 속도로 갈 수 있다. 완벽한 답보다, 충분히 괜찮은 답을 고르고 빠르게 움직이고 필요하면 다시 손보는 쪽이 더 중요하다. 좋은 팀은 누가 더 옳은지를 증명하기보다 함께 앞으로 나아가는 데 힘 쓰는 곳이다. 함께 일한다는 건 같은 생각을 하게 되는 일이 아니라, 다른 생각을 가진 사람들이 같은 방향을 바라보는 일이다. 충분히 고민해 결정하고, 결정했으면 함께 움직이고, 그 과정에서 배우는 것이다. 어쩌면 좋은 팀이란 늘 정답을 맞히는 팀이 아니라, 함께 배우며 앞으로 나아갈 수 있는 팀인지도 모른다.

개발자 어썸블로그

번역서 "다중 에이전트 시스템을 위한 컨텍스트 엔지니어링" 출간 소식 전합니다.

오늘도 열심히 했다

기술 뉴스 #296 : 2026-06-16

웹개발 관련

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

엔지니어의 경영에 대한 생각

1. 재활용에 목숨 걸기

2. 투자해서 굴러오게 하기

3. 내일 이루면 의미가 달라진다

소통이 설계를 결정한다

1. 소통이 시스템을 망친다

2. 사회적 역량

3. 조직의 특징들

나만 좋으면 돼

근거 없는 대화

배타적 태도

지나친 의존관계

문맥에서 벗어난 의견

바꿀 수 없어

느린 응답

휘발되는 소통

4. 맺으며

[SE-0531] Literal Expressions

Intro

Motivation

@section과 컴파일타임 초기화

Enum raw value

정수 제네릭 인자

Proposed Solution

Detailed Design

Literal Expression의 문법

Literal Expression 내 변수 참조

@section 변수 초기화식

Enum raw value

정수 제네릭 인자

컴파일타임 진단

Source Compatibility

ABI Compatibility

Implications on Adoption

Future Directions

Alternatives Considered

참조되는 모든 변수에 명시적 어노테이션 요구

"Constant Expression" 대신 "Literal Expression" 용어 사용

Conclusion

References

짚을 것과 넘길 것

리뷰가 느려 보이기 시작할 때​

리뷰는 원래 무엇을 보는 일이었나​

경계는 양이 아니라 종류의 문제​

혼자 그은 선은 반드시 부딪힌다​

옳은 코드와 맞는 코드

이미 건너간 강에 다리를 놓는 일​

품질을 어디에 쓸 것인가​

옳은 코드와 맞는 코드​

무엇을 버려야 하는가​

디지털 시대의 아버지, 클로드 섀넌(Claude Shannon)

내가 생각하는 좋은 회의

리뷰가 느려 보이기 시작할 때

리뷰는 원래 무엇을 보는 일이었나

경계는 양이 아니라 종류의 문제

혼자 그은 선은 반드시 부딪힌다

이미 건너간 강에 다리를 놓는 일

품질을 어디에 쓸 것인가

옳은 코드와 맞는 코드

무엇을 버려야 하는가