개발자 어썸블로그

번역서 "에이전트 시대의 AI 시스템 설계" 출간 소식입니다.

2026-04-28T16:51:00+09:00

오라일리의 "Generative AI Design Patterns"를 옮긴 "에이전트 시대의 AI 시스템 설계"가 어제 출간되었습니다.

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

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

웹개발 관련

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

그 밖의 개발 관련

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

인프라 관련

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

AI 관련

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

볼만한 링크

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

IT 업계 뉴스

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

프로젝트

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

버전 업데이트

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

댓글 쓰기

Ruflo 톺아보기: Claude Code에 멀티 에이전트 오케스트레이션을 얹는다는 것

2026-05-04T11:30:00+09:00

단일 프로젝트를 넘어 팀의 통찰을 학습하는 Claude Code 워크플로 설계법.

정도현 - 로보코 수석 컨설턴트

Claude Code를 한 달만 써보면 한계가 명확해진다. 컨텍스트는 세션과 함께 사라지고, 작업을 분해하고 다시 합치는 일은 결국 사람 몫이다. 더 큰 문제는 프로젝트가 여러 개가 되고 개발자가 여러 명이 되는 순간 드러난다. A 프로젝트에서 얻은 테스트 전략, B 개발자가 발견한 리팩터링 패턴, C 저장소에서 검증된 아키텍처 판단이 서로에게 잘 흘러가지 않는다. ruvnet/ruflo(구 Claude Flow)는 이 빈자리를 정확히 노린다. 2026년 5월 4일 기준 GitHub에서 39.4k stars, 4.5k forks를 기록하고 있고, 최신 릴리스는 v3.6.27이다.¹² Ruflo는 Claude Code 위에 100여 개의 전문 에이전트, HNSW 벡터 메모리, 플러그인 시스템, 그리고 Zero-Trust 페더레이션을 얹은 오케스트레이션 레이어를 지향한다. 이 글은 Ruflo가 실제로 무엇을 해결하고 무엇은 해결하지 않는지를, 특히 여러 프로젝트와 여러 개발자가 획득한 통찰을 어떻게 유기적으로 재사용할 것인가라는 관점에서 정리한다.

해외 출장 중에 한국 게임하기 위한 WireGuard 설정

2026-05-03T20:43:19+09:00

넥슨에서 서비스 중인 게임들은 대부분 해외에서의 접속을 차단하고 있다. 작년에 회사 워크샵 갔을 때 가서는 로밍으로 잘 하다가, 돌아오는 비행기 안에서 게임에 접속해보려 했다가 실패했던 기억이 있다. sequenceDiagram actor User as 📱 내 폰 participant Plane as ✈️ 비행기 participant Starlink as 🛰️ Starlink 위성 participant Station as 🗼 지상국<br/>(미국 / 일본) participant Backbone as 🌐 인터넷 participant Game as 🎮 게임 서버 User->>Plane: 기내 Wi-Fi 연결 Plane->>Starlink: 위성 uplink Starlink->>Station: 위성 downlink Station->>Backbone: (L3) Backbone->>Game: 접속 시도 → 차단 ❌ 기내 Wi-Fi는 Starlink 위성을 거치고 CloudFlare Warp를 쓰거나하면 미국이나 일본 지상국을 통해 나오다 보니, 게임 서버 입장에서는 해외 접속이라고 끊어버린다.

기업이 감수할 리스크란 무엇인가?

2026-05-04T09:43:52+09:00

누군가 남긴 '리스크를 감수한다'는 표현을 곱씹으며 그의 표현이 참 기괴하다는 생각이 든다. 없는 것을 있는 것으로, 남의 것을 내 것으로, 문제가 있는 것을 없는 것으로 공표하고 앞으로 현실을 뒤집어 보겠다는 것이 리스크를 감수하는 것일까? 그건 사기꾼들이 범죄의 이익을 얻기 위해 거짓말이 탄로날 위험을 감수하는 리스크와 닮아 있다. 기업이 리스크를 감수한다는 건, 정직하게 투자한 시간과 돈에 비례해서 결과를 보장받지 못하는 불투명한 길, 아무리 열심히 해도 실패할 수 있는 길, 그런 길이지만 가치있다고 믿기에 용감하게 뛰어들어보는 것 아닐까? 생존과 성장을 위해 남을 속이고 어떤 것을 얻어내는 게 집단이 정의한 리스크라면 그 집단을 정상적인 기업이라고 보기 어렵다는 생각이 든다.

사람처럼 AI가 닿지 못하는 곳

2026-05-02T22:02:06+09:00

AI를 사용해 프롬프팅(내가 직접 글을 쓰지 않고, 가이드만 주며) 만으로 글을 써보니 이건 근원적으로 안되겠다는 생각이 듭니다. 글이라는 창작물은 일차적으로 자신의 마음과 온전히 하나가 되었다고 스스로 만족되어야 하는 것 같습니다. 적어도 저에게는 그런데요. AI를 아무리 돌려도 적당히 그럴싸한 건 나오는데 내 마음에 동화되는 글이 나오지 않습니다. 잘 생각해 보면 그게 당연한 것도 같습니다. 내가 말해준 적 없는 세삼한 내 마음을 표현 하나하나 내가 만족하게 AI가 쓸 수 있다는 건 배우자에게 표현하지 않아도 배우자가 내 마음을 다 알아주기 바라는 그런 것 같기도 합니다. AI가 사람의 지능을 지향하는데 사람이 근원적으로 할 수 없는 걸 AI가 한다는게 이상하기도 하네요. 생각해보면 배우자가 내 마음을 그렇게 세심하게 알아주길 바라지 않는 경우도 있는데, AI도 그런 관점으로 바라보면 쓸만한 글쓰기 도구가 될지도 모른다는 생각도 듭니다. 아무튼 저 같은 사람이 있다면 미술이나 작곡같은 창작물도 비슷할 것 같다는 생각이 드네요.

나그네의 겉 옷을 벗긴건 햇살

2026-05-04T08:47:59+09:00

몇 년 전에 한참 PT를 받을 때가 있었다.
PT만 하던 곳이라 그 시간에는 거의 나만 운동을 했다.

운동이 끝나면 샤워를 하고 나오는데, 어느 날은 PT 선생님이 칭찬을 하시는거다.

"동욱님이 샤워하고 나오면 항상 샤워실이 깨끗해요.
제가 청소하는 것보다 더 깨끗한 것 같아요" 라고.

샤워하고 나오면서 뒷정리를 굳이 신경쓰면서 하진 않았다.
근데 그런 얘기를 듣고나니 신경쓰이기 시작했다.

그 뒤로는 샤워가 끝나면 항상 한번 더 돌아보고 정리할 수 있는 건 정리하고 나왔다.

면도기 등 일회용품들이 널브러져 있으면 주워서 버렸다.
어쩔 때는 그 전 분이 사용하고 버리고 간 일회용 샤워타월을 주워서 버리기도 했다.

마지막에 나온 사람이 "나"이고, PT 선생님은 내가 그걸 버린 사람이라고 생각하실 수 있으니까.

그리고 이상한 느낌이긴 한데,
"이건 내가 한 게 아니니까, 내가 굳이 버릴 필요는 없지."
그렇게 한번 생각하기 시작하면, 어느 순간엔 "내가 쓴 건 맞지만, 다른 사람이 쓴 거라고 생각하실 수도 있잖아" 라고 핑계가 점점 자라날 것 같았다.

그래서 그냥 다 치우고 나왔다.

왜 그랬을까 곰곰이 생각해보니 결국 나를 좋은 사람이라고 생각해주는 사람을 실망시키고 싶지 않았던 것 같다.

PT 선생님은 나를 "머문 자리도 항상 깨끗하게 정리하는 좋은 사람" 이라고 생각해주신 거니까.

규칙을 빡빡하게 정하고, 지키지 않았을 때 패널티를 먹이고 하면 최소한의 무언가는 될 수 있다.
근데 그 이상으로 자발적으로 무언가를 하게 만들진 못하는 것 같다.
누군가를 바꿀 수 있는 건 그 사람을 좋은 사람으로 여기는 것일 수도 있겠다는 생각이 문득 들었다.

결국 나그네의 겉 옷을 벗긴건 차디찬 바람이 아니라 따뜻한 햇살이었으니까.

AI 해커톤

2026-04-30T09:06:49+09:00

오늘 전사 AI 해커톤을 진행했다.

주제는 "이게 되네? AI 인프톤",
목적은 "AI가 어렵거나 특별한 기술이 아닌, 누구나 쉽게 쓸 수 있는 업무 도구라는 것을 직접 경험"하는 것이었다.

AI를 활용하는 일반적인 해커톤과 비슷하지만, 이번엔 두 가지 제약을 뒀다.

운영/사업 1명 + 개발자 1명으로 조를 편성하되,
"개발자는 절대 코드를 작성하지 않고 페어인 운영/사업팀 분이 모든 구현을 한다 ",
"CLI는 절대 사용하지 않고 클로드 데스크탑 앱으로만 구현한다".

제품 직군(개발/디자인/PM)은 AI를 적극적으로 쓰지만,
운영/사업 쪽에 계신 분들께는 여전히 AI가 어렵다.
그리고 이건 집체교육으로 풀 수 있는 문제가 아니라고 생각했다.

AI가 어렵지 않다는 걸 느끼게 해주는 가장 좋은 방법은 "일상 업무에서 발생하는 답답함을 AI를 통해 본인의 손으로 직접 해결하는 경험"이라고 생각했다.
직접 해결하되, 막힐 때마다 옆자리 개발자 동료가 조언과 힌트를 준다.
단, 개발자가 직접 손대는 건 절대 안 된다.
앞으로도 이렇게 직접 AI와 함께 풀어 나가시길 바랐다.
CLI를 금지한 것도 같은 이유다.
CLI는 너무 어려운 도구니까.

점심시간, 발표시간, 시상식을 빼고 나니 실제 해커톤 시간은 4시간 30분(오전 1시간 30분, 오후 3시간)이 전부였다.

그래서 이번 해커톤도 'AI 찍먹', '개발팀과의 유대감 형성' 정도로 끝나지 않을까 싶었다.

근데 웬걸.
깜짝 놀랄 만한 결과물이 너무 많았다.
일부는 오늘부터 담당 팀에서 바로 쓰기 시작했고,
일부는 조금만 더 다듬으면 전체 팀원이 쓸 수 있었고,
일부는 개발을 전혀 모르는 사람이 4시간 만에 어디까지 할 수 있는지 한계를 돌파한 것 같은 결과물도 있었다.

물론 이 경험으로 "개발자가 다 대체된다", "모두가 개발자가 될 수 있다" 같은 호들갑/설레발을 치고 싶진 않다.
(그렇게 생각하지도 않고.)

다만, 놀라웠던 것은 해커톤의 주 타깃이었던 운영/사업팀보다 서포터에 가까웠던 개발자들이 훨씬 더 많은 인사이트를 얻었다는 점이다.

어떤 팀에선 마케터 분이 제안한 기능을 두고, 페어를 이룬 개발자가 "이 시간 안에는 어렵겠다"며 좀 더 낮은 스펙을 제안한 뒤 잠깐 화장실을 다녀왔다고 한다.
그 사이에 마케터 분이 AI와 뚝딱뚝딱 하더니, 안 될 거라던 그 기능을 만들어냈다.
돌아온 개발자가 너무 놀랐다며 그 경험을 공유해주셨다.

다른 분은 "개발자는 '이 시간 안에 어디까지가 현실적으로 가능한지' 계산할 수 있는 사람들이라, 그 제약을 먼저 고려할수록 오히려 AI를 제대로 못 쓰게 되는 것 같다." 는 이야기도 해주셨다.

호들갑 떠는 걸 선호하지 않음에도, 이번 해커톤 경험은 정말 좋았다.

사실 이번 해커톤은 대표님의 제안으로 시작되었고, 나는 처음엔 반대였다.

5월에 출시 예정인 제품들이 많았고, 그 제품들이 정말 기대됐다. 하루라도 더 빨리 내고 싶은데 해커톤을 하면 일정이 더 밀리고, 5월엔 연휴도 많아서 어영부영하다가 한 달이 끝날 것 같았다.

근데 대표님이 "정식 제품 출시가 더 지연되더라도 이번 해커톤은 그만큼의 가치가 있다"고 이야기해주셨다.
이 정도로 확신을 갖고 계신다면 해야겠다 싶어서 진행했다.

그동안 본 많은 해커톤들에서 실제 고객이 쓰거나 사내에서 계속 사용되는 제품을 만들기보다는 단기간의 무형 가치(서로 다른 조직간의 유대감 형성, 새로운 기술 찍먹, 일상에서 벗어난 몰입 경험 등)를 만드는 이벤트로 끝나는 걸 봐왔다.

근데 그것도 이젠 선입견이라는 걸 이번 해커톤으로 많이 깨달았다.
요즘 시대에 내가 가장 갇혀 있는 사람이었구나 싶었다.

형식에 대한 걱정도 많았다.
개발자는 서포터로만 참여해야 하니 답답할 것이고,
운영/사업팀은 같은 조인데도 본인이 하나부터 열까지 다 해야 하니 그것대로 답답할 것 같았다.
(물론 해커톤 참여 자체는 자율이었다.)

근데도 다들 너무 웃으면서, 즐겁게, 몰입감 있게 참여해주셨다.
끝나고 "또 하고 싶다"는 이야기들을 해주셨는데, 그게 정말 큰 힘이 됐다.

개인적으로 너무 좋은 경험이었기에, 이런 방식의 해커톤을 많은 분들께 추천드리고 싶다.

이번 해커톤의 제대로 된 후기와 결과물은 따로 정리해서 올릴 예정이다.

Claude Code for Developers 밋업 후기

2026-05-02T16:44:13+09:00

출처: https://luma.com/tzobcks8

Claude Code 커뮤니티가 주최하는 밋업을 다녀왔다.

일시: 2026-04-30 10:00 ~ 12:00
형식: 발표 4 세션 + 네트워킹 Q&A

발표 메모

이 글은 밋업에서 들은 내용을 정리한 글입니다. 발표를 듣고 메모한 내용을 재구성하였으며, 이 과정에서 발표자의 의도와 다른 정보가 적혀있을 수 있습니다. 이후에 발표자 분들의 링크드인을 통해 발표 자료를 공유주실 예정입니다.

1. Claude Code 최신 업데이트 / 최훈민

4월 중후반에 추가된 주요 업데이트와 품질 이슈 공유

/ultrareview: 클라우드에서 PR 리뷰 수행 (5/5까지 3회 무료)
/usage: 사용량의 출처(도구, 세션 등)를 상세하게 보여줌
session recap: 세션 이탈 후 복귀 시 컨텍스트 자동 요약
claude --teleport: 웹/모바일 세션을 CLI로 전환
/claude-api
- migrate: 모델, 프롬프트 자동 업데이트 및 마이그레이션
- managed-agents-onboard: 설정, 모니터링, 디버그 지원
https://claude.ai/code 사이트 UI 개선

Claude Code

A shared Claude Code session on claude.ai/code

claude.ai

prompt caching dashboard 추가
- 캐시 히트율 ↑ = 비용 절감으로 이어지기 때문에, 대시보드를 통해 캐시 히트율을 높이려는 시도 가능
- 대시보드에서 사용 현황 확인 가능
managed agents memory
- 기존: 세션 종료 시 기억 소실
- 변경: 사용자 선호도, 반복 작업, 연락처 등 영속화 지원

개인 메모
session recap를 보고 생각난 팁. 나는 현재 세션에서 갑자기 동작이 정지되거나 뭘 하고 있었는지 까먹어서 물어보고 싶을 때 /btw를 자주 쓴다. 현재 세션의 컨텍스트를 오염시키지 않으면서도 새로운 질문을 던질 수 있다.
- ex: /btw 지금 서브 에이전트 동작에 문제 있는지 확인해 줘

2. Claude와 함께라면 놀면서 온보딩 / 변규홍

클로드를 업무나 일상 등 다양한 방면으로 사례를 소개해주신 발표. 좋은 이야기를 많이 주셨는데 사례 위주다 보니 메모한 내용이 적다.

활용 사례

복잡한 로직 분석 — 레거시 코드 흐름 빠르게 파악 및 개발
일상 활용 — 비행기에서 읽을 전자책 제작, 일상에 필요한 간단한 도구 만들기
커뮤니케이션 개선
- 요구사항 전달 시 모호함 감소
- 프로토타입을 직접 만들어 전달 가능

3. Ouroboros 딥다이브 — MCP Mesh와 Disposable Memory를 활용한 자율형 AI 하네스 / 이재규

우로보로스(Ouroboros)라는 하네스 오픈소스를 개발 및 운영하는 과정에서 얻은 인사이트를 공유해 주신 발표. 보통 '하네스 엔지니어링'에 대한 추상적인 개념만 설명하는 경우가 많은데, 재규님은 실제 구현한 사례와 아키텍쳐 등을 공유 주셔서 더 와닿았다.

Bitter Lesson

Rich Sutton: "사람이 짜낸 도메인 지식보다, 연산량을 더 많이 투입한 일반적 학습 방법이 결국 이긴다"
참고: https://news.hada.io/topic?id=19154

AI 창업자의 씁쓸한 교훈 (Bitter Lesson) | GeekNews

AI Safety 스타트업 Andon Labs (YC w24) 창업자 Lukas Petersson 의 4부작 글을 하나로 정리역사적으로 AI 분야에서는 일반적인 접근 방식이 항상 승리했음현재 AI 애플리케이션 분야의 창업자들은 과거 AI 연

news.hada.io

LLM은 animal이 아니라 ghost다

LLM = 인간 텍스트로부터 압축된 결과물
강력하지만 인간의 편향에 의존적

컨텍스트 엔지니어링의 한계

문맥이 길어지면 앞 내용을 잘 기억하지 못함
추론도 비용이기 때문에 무한히 늘릴 수 없음
초반에 준 지시가 뒤로 갈수록 흐려짐
빈칸을 그럴듯하게 채움 (할루시네이션)

해결 접근 - 세션 쪼개기

하나의 긴 대화로 모든 작업을 처리하지 않고, 아주 긴 프롬프트를 격리된 세션으로 분리
현재 세션이 더럽혀지거나 바닥나면 계속 이어가지 말고 독립 세션에서 진행
이 과정에서 인간이 컨텍스트를 직접 관리하기는 어려워 MCP 서버를 통해 구축
- 메인 세션: 명령·결과 수집·오케스트레이션
- 서브 에이전트: 작업 수행
- 나뉜 작업 결과를 다시 모아서 최종 결과 생성
기존의 fat skill은 모델, 설정 등에 따라 결과가 계속 달라질 수 있다
수직적(vertical) fat skill이 아닌, 수평적(horizontal) 연결된 구조(shared coordination layer)로 확장

세션을 쪼개며 알게 된 점

도구가 LLM을 호출하는 구조로 바뀜
- 기존: 특정 시점에 실행되는 hook 기반 제어
- 변경: MCP가 실행 흐름 자체를 제어
오케스트레이션 과정 자동화
- rule과 skill은 "부탁"에 가까움
- 직접 독립 세션을 열고 다시 합치려면 spawn / schedule / collect 과정 필요
- 이 오케스트레이션이 MCP handler 안으로 들어감
작업 흐름(call structure) 고정
- 스킬은 멱등성이 없음 (모델이 바뀌면 처리 과정도 달라질 수 있다)
- 세션을 쪼개는 과정에서 호출 순서를 고정하게 됨

Agent OS는 Contract Layer다

이러한 오케스트레이션 구조를 추상화한 것이 Agent OS
Agent OS는 커널이 아니라 런타임과 에이전트 사이의 Contract Layer
Agent OS: 에이전트 실행을 위한 상위 레벨 오케스트레이션 환경
Contract Layer: 시스템 간 상호작용을 명확한 규칙(계약)으로 정의하는 계층

runtime 내부의 프롬프트가 아니라, agent를 가로로 묶는 OS contract primitive

4. K-FED — 수천 시간 삽질로 깨달은 AX의 진짜 의의 / 이선민

하네스 엔지니어링에 대한 개인적 견해와 다양한 시도를 공유한 발표. 암묵지라는 개념을 설명 주시면서 이를 어떻게 문서화하였는지에 대한 과정이 흥미로웠다.

엔지니어링의 진화

prompt engineering → context engineering → harness engineering → problem engineering
하네스 엔지니어링은 마케팅 용어라는 말이 있음
하네스는 새로운 학문이 아님. 유사한 용어들이 이미 다양하게 존재.
하네스는 코드가 아니라 문제에 씌워야 한다 — 코드는 결과물, 문제 정의가 본질

Dev-Harness Mapping Table

하네스 용어가 사실상 기존 인프라/데브옵스 개념과 1:1 매칭된다는 것을 보여주는 표

암묵지 끌어내기

암묵지: 학습과 경험을 통해 개인에게 체화되어 있지만, 말이나 글로 표현하기 어려운 노하우나 경험적 지식

사례 - 한의학: 기술이 구두로 전수되고 사람마다 다르게 관리되고 용어가 다른 경우가 많음
동일한 개념 다양한 용어를 어떻게 다 커버할 것인가가 핵심 과제
최대한 많은 데이터를 모아 md로 전환
패턴을 파악하는 것이 중요

Polysona (오픈소스) 개발

AI가 모를 수 있는 모든 컨텍스트(경쟁사 뉴스, 팀원과의 관계, 핸드폰 메모 등)를 모아 페르소나 생성
24시간 동작하는 AI - 온갖 곳에서 컨텍스트를 끊임없이 수집
심리학, 철학, 정신의학 기법 활용

5. 네트워킹 Q&A (11:30)

하네스 시작이 어려운 사람들을 위한 조언

잘 만들어진 하네스를 분석해 보기
- 여러 구조를 뜯어보면 다양한 영감을 받을 수 있음
- 어떤 것은 과하게 복잡하다, 어떤 추상화는 깔끔하다 등 비교 분석하는 것이 큰 도움
어렵게 생각하지 말 것 - "랄프 루프(Ralph Loop)에 종료 조건을 붙이는 것"만으로도 하네스
처음이라면 스킬을 깎아가며 다양한 시도해 보는 것을 추천

AI Slop Tossing 문제 & 코드 리뷰

AI가 만든 결과물을 검증 없이 던지는 문제

코드가 아닌 ADR(Architecture Decision Record) 작성 및 리뷰
코드 작성자가 스스로 생각하도록 유도하는 리뷰 — 이해 안 되는 부분은 리뷰로 남겨 답변하게 만들기
AI끼리 토론 (최대 횟수 제한두기) → 인간이 최종 리뷰

위 방법들과는 별개로 어떤 설계·결정이 있었는지 개발자가 반드시 알고 있어야 한다고 생각.

AI로 컨텐츠를 제작할 경우 잘못된 정보가 있지 않은가

plan 모드 적극 활용해 확률을 줄임
할루시네이션이 발생 가능하다는 것을 인지해야 함

클로드 코드로 팀원과 협업하는 방법

팀 공유용 규칙·코드와 개인용 규칙·코드를 분리해야 함
하네스를 팀/조직 기준으로 강제하면 개인의 커스텀이 어려울 수 있음

AI 트렌드 습득 방법

유사한 정보를 자주 보면 SNS 알고리즘이 자동으로 추천
트렌드 팔로업을 일부러 안 함
- 일주일 이상 지속되는 키워드만 인사이트가 있을 거라고 기대
- 의외로 많은 기술이 원래 존재했지만 하드웨어 한계로 적용되지 못함. 이런 것들 위주로 확인

하네스 결과물이 만족스럽지 않은 상태라, 개선 방식에 대한 고민

AI 생성 속도 > 인간의 인지 속도 → AI에 브레이크가 필요
AI에게 이데아·온톨로지를 주입하면서 방향성을 스스로 인지·조정하게 함
가장 중요한 것은 아키텍처 설계 단계, 그 위에서 결과물이 잘 동작하는지 검증

AI와 직무 경계가 흐릿해진다에 대한 의견

모든 직군의 컨텍스트를 한 번에 넣기는 어려워서 혼자서 모든 걸 처리하는 건 아직 이른 이야기 같다
도메인 지식 깊이가 중요할까?
- 도메인 지식을 넓게 익히고 도메인 간 링크하는 능력 중요
- 도메인 지식을 깊게 파는 건 AI에게 시키는 것이 ROI 측면에서 유리하다고 생각

개인 메모
고민 중에 현재 조직의 형태가 FE개발자만 BE개발자만 이런 식의 동일 직군에 대한 조직이어서, 특정 직군에 한정된 AI 활용이 이루어지는 것 같다(?)는 이야기가 있었다. 너무 단순하게 생각하는 것 같기도 하지만 나는 개인적으로 이는 내가 다른 직군의 업무에 계속 관심을 갖고, 원활한 커뮤니케이션을 할 수 있다면 큰 문제가 아닐 것 같았다. 이는 AI에 한정된 이야기가 아니라 어떤 업무를 개발로 자동화할 수 있을지 고민하는 등의 일도 마찬가지라고 생각했다.

밋업 후기

오랜만에 밋업에 참여했다. 최근 회사에서 Claude가 도입되어 관련 이야기를 듣고자 신청했는데, 특정 도구에 한정되지 않고 AI 전반에 대한 다양한 관점을 들을 수 있었다. 기존에 막연하게 생각하던 개념들이 조금 더 구체화된 느낌이었다.

특히 그동안 하네스 엔지니어링에 대한 추상적인 개념을 설명하는 자료는 많았지만, 실제로 어떻게 구현하고 적용하는지에 대한 사례는 접하기 어려웠다. 이번 밋업에서 공유된 사례는 절대적인 기준이라고 보기는 어렵지만, 실제 구현을 기반으로 한 이야기라는 점에서 참고할 만한 방향성을 제공해 주었다. 어떤 식으로 접근해야 할지에 대한 감이 조금 잡힌 만큼, 관련 오픈소스 사례들을 모아 비교해 보는 것부터 시작해보려고 한다.

트위터를 통해 다양한 AI 정보를 접하고 있지만, 새로운 정보가 빠르게 소비되다 보니 충분히 소화하기도 전에 다음 흐름으로 넘어가는 경우가 많았다. 반면 밋업 발표는 내용을 정리하고 구조화하는 과정을 거치기 때문에, 일시적인 유행보다는 비교적 오래 남는 이야기라는 인상을 받았다.

한편 컨텍스트 수집에 대한 고민도 남았다. 온오프라인 혼합 근무 환경에서 온라인 작업은 기록이 비교적 잘 남지만, 오프라인에서의 구두 논의는 쉽게 휘발된다. 회의록으로 일부 보완할 수는 있지만, 항상 기록을 남기기 어려운 상황도 많다. 과제를 병렬로 진행하다 보면 회의 간 간격이 촘촘해 바로 정리하기도 쉽지 않다. 이 문제를 어떻게 해결할 수 있을지 질문해보고 싶었지만, 시간 관계상 답변을 듣지는 못했다.

[SE-0521] Improved Syntax for Optionals of Opaque and Existential Types

2026-05-01T06:51:10+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0521 — Opaque 및 Existential 타입의 Optional 문법 개선에 대해 정리해보겠습니다

Intro

Proposal: SE-0521
Author: Tony Allevato
Review Manager: Frederick Kellison-Linn
Status: Accepted with modifications

Motivation

Swift에서 some P와 any P는 이미 익숙한 문법이죠.

개발자들은 자연스럽게 Int?, String?처럼 some P? 또는 any P?라고 쓰고 싶어 합니다.

그런데 현재 이 코드는 컴파일 에러가 발생합니다

func fetchUser() -> some Identifiable?  // ❌ error
var handler: (any EventHandler)?        // ✅ 이렇게 써야 함
var handler: any EventHandler?          // ❌ error

이유는 파싱 우선순위 때문입니다.

컴파일러는 some P?를 some (P?)로 해석하는데, Optional<P>는 프로토콜이 아니기 때문에 에러가 발생하게 됩니다.

결국 개발자들은 어쩔 수 없이 (some P)?, (any P)?처럼 괄호를 추가해서 써야 했어요.

커뮤니티에서도 "ExistentialAny를 적용하고 나서 괄호 때문에 가독성이 너무 떨어진다"는 불만이 꽤 많았던 주제였거든요!

Detailed Design

이번 제안의 핵심은 간단합니다.

some P?와 any P?를 각각 (some P)?, (any P)?와 동일한 의미로 허용하는 것입니다.

기본 동작

some P?  // == (some P)?  ✅
any P?   // == (any P)?   ✅
any P!   // == (any P)!   ✅

다중 Optional도 지원

var a: some P??  // == (some P)??
var b: any P???  // == (any P)???

파서는 변경 없음

some P?는 여전히 OpaqueResultTypeRepr(OptionalTypeRepr(P))의 형태로 파싱되며, TypeRepr(AST) 자체도 바뀌지 않습니다. 단지 타입 체커가 이 구조를 만났을 때 의미를 재해석하는 방식만 바뀌는 것입니다.

함수 파라미터에서도 동작

func process(_ item: some Identifiable?) { }
// == func process<T: Identifiable>(_ item: T?) { }

Fix-it도 개선

// Before fix-it
let x: P?
// warning: ... fix-it → (any P)

// After fix-it
let x: P?
// warning: ... fix-it → any P  (괄호 없음!)

주의: 프로토콜 컴포지션은 여전히 괄호 필요

// ❌ 여전히 에러: P & Q? 자체가 invalid
var x: some P & Q?

// ✅ 이렇게 써야 합니다
var x: (some P & Q)?

// ✅ typealias 활용도 가능
typealias PQ = P & Q
var x: some PQ?  // OK!

Accepted with modifications

Language Steering Group은 원 제안에 수정 사항을 추가해 승인했습니다.

바로 suppressed constraints(~)에도 동일한 개선을 적용하는 것입니다.

any ~Copyable?   // == (any ~Copyable)?  ✅
some ~Copyable?  // == (some ~Copyable)? ✅

var x: ~Copyable?  // ⚠️ warning: requires 'any'

단, .swiftinterface 파일에는 기존처럼 괄호를 포함한 형태((any P)?)가 유지됩니다.

해당 파일은 컴파일러가 소비하는 아티팩트이지, 개발자가 직접 읽는 용도가 아니기 때문이에요.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드와의 소스 호환성은 100% 유지됩니다.
기존의 (some P)? 형태는 여전히 유효합니다.
some/any P?와 (some/any P)?의 타입 맹글링은 동일하므로 ABI에도 영향이 없습니다.

Alternatives Considered

아무것도 하지 않기

괄호 방식을 그대로 유지하는 것도 방법이지만, ExistentialAny가 언젠가 필수가 된다면 코드베이스 전반에 걸쳐 괄호가 대량으로 생겨나는 문제가 있거든요.

제안자는 이를 미리 해결하는 것이 적절하다고 판단했습니다.

Conclusion

작은 변경이지만, any/some 타입을 자주 쓰는 코드베이스에서는 가독성이 꽤 많이 개선되는 실용적인 변경입니다

Int?를 쓰듯이 any Protocol?, some Protocol?을 자연스럽게 쓸 수 있게 되면서, Swift의 타입 시스템이 한층 일관적이고 직관적으로 느껴지게 될 것 같습니다!

특히 ExistentialAny를 이미 적용한 프로젝트에서는 산더미 같은 괄호들을 제거할 수 있겠네요

References

swift-evolution/proposals/0521-improved-optional-opaque-and-any.md at main · swiftlang/swift-evolution

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

github.com

KIST Claude Code 실습교육 - 1.Cloude Code 기초

2026-04-29T14:00:00+09:00

KIST AIX전략실에서는 자체 AI 역량을 향상시키고자 합니다.
일환으로 전사 100인을 대상으로 Cloude Code 교육을 실시하며,
첫 시간으로 카카오 황민호 수석의 Cloud Code 기초 교육이 진행되었습니다.

1. KIST AIX 교육

Fortune: MIT report: 95% of generative AI pilots at companies are failing
머니투데이: '실전형 AX’나선 KIST…정예팀 100인 선발
HelloDD: “AI 연구 100인 특공대 선발” KIST AIX 선언 연구 방식 근본적 전환···소수 정예로 ‘돌파’

KIST에서 2026년을 시작하며 가장 중요하게 보고 있는 요소 중 하나는 임직원 개인의 AI 역량 강화입니다.
AI 전환이 95% 실패한다는 보고가 있는 만큼 전과는 다른 방식으로 접근해야 성공 확률이 있다고 판단했으며
그 중심에 개인의 AX 없이 조직의 AX없다는 결론을 내리고 교육을 강화하기로 결정했습니다.
AI 서비스, 특히 챗봇을 개발하여 보급하지 않을 것이며
특히 수요를 받아 용역 개발을 해 주는 일을 하지 않을 것입니다.
조직은 물론 개인의 AI 전환까지 늦추어 공멸하는 길이라고 판단하고 있기 때문입니다.
다만 위 선언은 개발을 목표로 하지 않겠다는 것일 뿐,
더 큰 목적을 위해서는 AI 서비스 개발이나 수요 대응을 할 수 있습니다.
이런 배경으로 교육을 강화하기로 결정했으며
전 부서에서 보직자를 중심으로 100명의 인력을 선발해 우선적으로 시행하기로 했습니다.
보직자를 대상으로 하는 이유는 업무 경험이 많고 시야가 넓어 아이템 발굴에 유리하고,
거꾸로 보직자의 AI 이해도가 낮을 경우 실무자의 노력을 꺾어버릴 수 있기 때문입니다.
총 4개의 track으로, 각기 AI 활용, AI 개발, Special Session, 연구자 교류회을 중심으로 진행될 예정입니다.
교육의 시작은 이틀 전인 4월 27일, ‘젯슨맘’ 장성숙 앰버서더께서 열어주셨습니다.
57세에 코딩을 시작해 코딩파티로 환갑잔치를 대신하고 이후 엔비디아 앰버서더에 오른 인물입니다.
40도 되지 않은 젊은 박사들이 새로운 걸 배울 나이는 지났다고 말하는 경우를 종종 보았습니다.
이런 분들께 자극을 드리고자 하는 목적이 담긴 의도적인 배치였으며,
기대 이상으로 열정이 넘치는 강연을 선사해 주셨습니다.

2. Claude Code 교육

2.1. 강의

26.04.29. 황민호 강의자료 다운로드
26.04.29. 황민호 강연 다시보기: YouTube
KIST 물순환자원연구단 김후 박사 정리 강의록
github:hoohugokim, scribe-md

이 중 두 번째 track, vibe coding intensive course는 클로드 코드를 중심으로 구성했습니다.
교육을 계획한 2026년 3월 시점에서 vibe coding의 주류를 형성하고 있고,
Google Antigravity와 cursor 같은 좋은 도구들도 있지만 가장 강력한 기본 도구라고 판단했기 때문입니다.
교육을 위해 임직원 100명에게 Claude 유료 계정 가입을 지원했습니다.
첫 시간은 카카오 FDE 황민호 수석의 클로드 기초 강의로 진행됐습니다.
충실한 강의자료를 준비해 오셨음에도,
현장에서의 니즈를 반영하여 즉석에서 논문 분석을 중심으로 한 실습강의로 전환해 주신 연사의 관록이 돋보였습니다.
물자원순환연구단 김후 박사님께서는 강의 후 자작 프로그램을 이용해 실제 진행된 강의내용을 정리, AI Frenz에 배포해 주셨으며,
해당 자료를 KIST 게시판과 본 블로그 등을 통해 배포할 수 있도록 허락해주셨습니다. (다운로드
)

2.2. 현장지원

100명이 넘는 분들을 대상으로 한 강의는 KIST로서도 도전이었습니다.
강연장에 wifi가 설치되어 있지만 사이버보안팀에서 전날 강연장에 유선랜을 추가로 포설해주셨고,
교육을 담당하는 가치혁신팀에서는 USB-LAN 젠터를 긴급공수했습니다.
덕택에 안정적인 인터넷 연결을 바탕으로 강의가 진행될 수 있었습니다.

AIX전략실원들은 진행보조를 담당했습니다.
전날과 당일 강의장의 멀티탭 설치부터 2주 전 Claude Code 설치방법 게시판 공지 뿐 아니라,
숱한 경우의 설치 오류를 비롯해 터미널 창과 CLI가 낯선 분들께 강의 내내 기술 지원을 실시했습니다.

식별하기 좋도록 단체티를 입고 움직였는데,
클로드 마스코트가 인쇄된 이 티셔츠는 허예찬님이 협찬해 주셨습니다.

3. 후기

긍정적인 말씀을 전해주신 참석자 분들이 적지 않아서 다행이라는 생각이 들었습니다.
한편으로 앞으로 vibe coding 기준 한달 반,
전체 교육일정 기준 6개월을 이어가야 할 일정이라 긴장하게 됩니다.
실원들, 유관부서와 함께 잘 만들어 보겠습니다.
저희 움직임이 대한민국 출연연에 좋은 자극제가 되기를 바랍니다.

해커에서 연쇄 창업가로, 노정석 비팩토리 대표

2026-04-30T00:00:13+09:00

우리나라 이공계를 대표하는 대전 카이스트와 포항 포스텍. 2002년부터는 양교는 포카전/카포전을 개최합니다.(연고전/고연전과 비슷한 느낌) 종목은 축구, 농구 야구 같은 스포츠 뿐만 아닐 LOL, 해킹, AI, 과학퀴즈가 있습니다. 작년까지의 전적은 카이스트 13승 대 포스텍 10승으로 카이스트가 앞섭니다.

이런 공식적인 교류가 있기 전에 양교의 학생들은 자존심을 건(?) 기술 승부를 펼칩니다. 서로의 전산시스템의 결함을 찾아 해킹하고, 이를 보완하는 공수전. 물론 비공식적인 승부죠. 카이스트측 선수는 쿠스(KUS), 보안연구 동아리입니다. 1996년 4월 5일 새벽 KUS 대표였던 경영공학과 94학번 노정석 군은 포스텍 전자전기, 물리학과 등 7개 컴퓨터 시스템의 보안 헛점을 이용하여 연구원들의 연구 과제나 학생들의 과제물을 삭제하는 식으로 장난을 칩니다. 이는 앞선 3월에 있었던 카이스트 컴퓨터 시스템의 해킹 배후에 포스텍 보안동아리인 플러스(PLUS)가 있다고 의심했기 때문이었죠. 물론 이렇게 죄의식없이 타대학 전산망에 침입하면 안됩니다.(당시 쿠스 지도교수님인 박성주 교수님의 발언) 이 사건이 알려지면서 검찰의 추적을 받던 노정석씨는 전산시스템에 대한 파괴행위 및 전산망 불법침투 혐의로 구속되어, 구치소에서 40일간 수감됩니다. (불법이지만 진검승부같은 느낌)

노정석 님는 졸업후 기술력을 살려 1997년 보안업체인 인젠을 창업하여 2002년 코스닥에 상장됩니다. 첫번째 엑싯입니다. 이후 다시 2002년 데이터 기반 침입탐지시스템을 개발하는 젠터스를 창업하지만, 17개월만에 사업을 중단하고 2004년 8월 SK 텔레콤에 입사하여 개인화 서비스를 설계하고 개발합니다. 이후 2005년 8월에는 크래프톤으로 널리 알려진 장병규님이 당시 창업했던 첫눈 검색엔진의 개발팀에 합류했다가 3개월만에 나와서 태터앤컴퍼니를 설립니다. 태터툴즈로 알려진 설치형 블로그 솔루션을 만들었고, 이 회사는 우리나라 스타트업 최초로 구글에 인수됩니다. 이것이 두번째 엑싯입니다. 태터툴즈를 잘 모르시는 분들도 계실텐데, 태터를 기반으로 제공되는 서비스로 남아있는 것이 바로 티스토리입니다.

이후 2010년 9월 모바일 게임 데이터 분석 업체인 파이브락스를 설립했는데요. 2014년 탭조이에 인수합병됩니다. 세번째 엑싯이네요.

이후 2020년 8월 AI에 기반한 화장품 회사인 비팩토리를 설립하여 다시 네번째 창업에 도전하고 있습니다. 이정도면 연쇄 창업가라 불리울만 하죠. 요즘은 유튜브 방송을 통해 AI에 대한 인사이트를 공유하고 있습니다. 잘 보고 있습니다!

엘리트는 많은데 리더가 없어요. 자신만의 방향이 있고, 향기가 있는 사람이 없는 거죠. 여기저기 휩쓸리기만 하는 엘리트들은 리더가 될 수 없습니다.

인생은 판단의 연속인데 자신의 판단에 모든 것을 걸 수 있는 정신이 필요합니다.

모든 사람은 ’나’라는 회사의 리더에요.

"처음부터 특별한 목적을 가지고 미래의 일을 모두 예상하고 살아가는 사람은 없습니다. 한 순간 한 순간 최선을 다하고 인생의 경험에서 찍히는 수많은 점들을 연결해 나가세요."

지식과 소프트웨어 코드를 다루는 스킬이 있는 사람이 뭐든 할 수 있는 시대가 되고 있다

소프트웨어가 그냥 전산학의 영역에 있는 것이 아니라 모든 영역으로 가고 있다. 다 데이터로 만들어 버린 달음에 코드를 통해 그 데이터를 조직해서 기득권자가 갖고 있던 것보다 더 뛰어난 생산성을 더 큰 스케일로 보여주고 있다.

구글이 소프트웨어 회사를 사면 사람들이 “소프트웨어 코드는 깃허브에 다 나와 있는데 왜 사냐”라고들 한다. 하지만 사실 코드 덩어리 자체는 그냥 결과물이다. 그 코드 안에 녹아있는 수많은 시행착오를 알고, 그것이 왜 그렇게 구성되어 있는지 그 설계를 갖고 있는 사람이 핵심 자산이다.

시각화 #1. 어떻게 Local 에서 클라우드 RDS 로 query 를 날리나요?

2026-05-01T17:36:57+09:00

서문

안녕하세요. “시각화 한장으로 개념 이해하기” 시리즈를 써보려고 합니다. LLM 과 학습하는 시간이 늘어나면서, 뇌가 입력 받는 양이 늘어났습니다. 그러면서 Input 과 Output 의 비율이 깨지고 있습니다. 학습은 Output 을 통해 이루어집니다. 뱉어봐야 나의 것이 됩니다. 그 정수는 시각화라고 생각합니다. 시각화를 한다는건, 글보다 훨씬 어렵습니다. 어렵다는건, 더 많은 내용을, 더 깊이 이해하고 있어야 진정 제대로 그릴 수 있다는 것입니다. 바꿔 말하면, 시각화할 수 있다는건, 그 개념을 정확히 이해하고 있다는 것을 의미합니다. AI 시대에 거꾸로 가기 위해서, 시각화를 연습하고 글로 써봅니다.

오늘은 <어떻게 Local 에서 클라우드 RDS 로 query 를 날리나요?> 라는 질문에 답을 해봅니다.

문제 상황

서버 개발을 하면, 어플리케이션 서버를 띄우고, RDBMS 서버를 띄웁니다. AWS 로 치면, EC2와 RDS 를 통해 호스팅합니다. 이때 실제 Database 에 query 를 날려서 데이터를 얻어와야 하는데요. EC2 에 직접 접속해서, 쿼리를 날리는건 너무나 불편합니다. 접속도 불편하고, Terminal UI 는 시각화와 쿼리 관리가 어렵죠.

그래서 Local 에서 GUI 로 된 DB Client 를 사용합니다. DBeaver 나 MySQLWorkbench, DataGrip 등이 유명합니다.

이들은 대체 어떻게, Local 에서 RDS 로 바로 접속해서 query 를 날리는 것처럼 보일까요? 그 블랙박스를 시각화해서 그려봅니다.

시각화

시각화 전체 흐름 설명

Local 은 SSH Protocol 22 port 로 EC2 에 접속한다.
1. EC2 는 Local 에서 접속 가능하도록 Security Group(보안 그룹)을 설정해야 한다.
EC2 는 MySQL Protocol 3306 port 로 RDS 에 접속한다.
1. RDS 는 EC2 에서 접속 가능하도록 Security Group(보안 그룹)을 설정해야 한다.
Local 에서 query 요청을 날리면, EC2 를 거쳐서, RDS 로 가고, RDS 에서 응답을 하면, EC2 를 거쳐서 Local 로 응답이 온다.

이 그림을 잘 이해하기 위해서, SSH Protocol, MySQL Protocol, Security Group 을 이해해야 합니다.

SSH Protocol

SSH 의 풀네임은 Secure Shell 입니다. 클라이언트가 원격 서버에 안전하게 접속할 수 있도록 하는 프로토콜 입니다.

여기서 Shell은 터미널 명령을 실행하는 환경입니다. 즉 SSH는 “내 Local Terminal에서 EC2 Terminal에 안전하게 들어가는 방법”이라고 볼 수 있습니다.

MySQL Protocol

MySQL Protocol은 MySQL Client와 MySQL Server가 대화하는 규칙입니다.

우리가 DBeaver에서 아래 쿼리를 실행한다고 해봅시다.

"SELECT * FROM users;"

사람 눈에는 SQL이지만, 실제 네트워크에서는 MySQL Client가 MySQL Protocol에 맞춰 요청을 보냅니다.

DBeaver --> EC2 -- MySQL Protocol --> RDS MySQL

즉, SQL은 “무엇을 할지”를 표현하는 언어이고, MySQL Protocol은 “그 SQL을 DB 서버에 어떻게 보내고 응답을 어떻게 받을지”를 정한 통신 규칙입니다.

MySQL은 기본적으로 3306 포트를 사용합니다. 그래서 EC2에서 RDS로 갈 때는 보통 3306 포트가 열려 있어야 합니다.

Security Group

Security Group은 AWS 리소스 앞에 붙는 방화벽입니다.

Public Subnet에 있다고 해서 모든 요청이 열리는 것은 아닙니다. Public Subnet은 “인터넷으로 갈 수 있는 길이 있다”는 뜻이고, Security Group은 “그 길에서 어떤 문을 열지” 정합니다.

이번 구조에서는 두 가지 문이 필요합니다.

Local -> EC2
SSH 22번 허용
Source: 내 IP/32

EC2 -> RDS
MySQL 3306번 허용
Source: EC2 Security Group

중요한 점은 RDS의 Source입니다. RDS 입장에서는 접속자가 Local이 아니라 EC2입니다. 그래서 RDS Security Group에는 내 IP가 아니라 EC2 Security Group을 허용해야 합니다.

시니어 개발자는 무엇인가

2026-05-02T18:00:00+09:00

주니어 팀원이 어떤 개발자를 시니어 프론트엔드 개발자라고 불러도 되는지 물었다. 나 역시 정리해 둔 답이 없어서 곧바로 답해 주지 못했다. 이 질문은 생각보다 어렵다. 오래 일했다고 시니어라고 부르기에는 부족하고, 특정 프레임워크만 능숙하게 다룬다고 해서 시니어라고 부르기에도 좁다. React, TypeScript, 복잡한 상태 관리, 디자인 시스템—이런 말들은 시니어의 한 면을 짚을 수는 있지만, 그것만으로는 부족하다. 구현이 아니라 판단 한때는 실력을 "얼마나 잘 구현하느냐"로 말해 왔다. 복잡한 화면을 빠르게 만들 수 있는지, API와 상태를 연결할 수 있는지, 인터랙션이 자연스러운지. 물론 지금도 구현 능력은 중요하다. 그런데 AI가 코드를 빠르게 생성하는 시대에는 그 척도만으로 시니어를 설명하기 어렵다. 컴포넌트, 이벤트, API 호출, 에러 처리까지 초안은 짧은 시간에 나온다. 그렇다고 시니어의 역할이 줄어드는 것일까. 나는 반대라고 본다. 오히려 더 분명해진다. 중요한 것은 얼마나 많이 직접 쓰느냐가 아니라, 사람이 만들었든 AI가 만들었든 결과가 올바른 방향으로 가고 있는지 판단하는 능력이다. 시니어 프론트엔드 개발자는 단순히 기능을 잘 만드는 사람이 아니다. 제품의 의도, 사용자 경험, 시스템 구조가 실제 결과물 안에서 서로 어긋나지 않는지 보는 사람이다. "되게 만드는 것"을 넘어, 결과가 맞는 방향으로 수렴하도록 만드는 사람이다. "돌아간다"고 해서 맞는 것은 아니다 "맞다"는 단순히 돌아간다는 뜻이 아니다. 버튼이 반응하고 페이지가 넘어가고 데이터가 보인다고 해서 항상 맞는 것은 아니다. 사용자의 기대와 어긋날 수 있고, 웹이 원래 제공하는 동작과 어긋날 수 있으며, 접근성이 깨져 있을 수 있다. 지금은 괜찮아 보여도 나중에 확장할 때 구조가 버티지 못할 수도 있다. 페이지 이동을 구현한다고 해보자. 버튼 클릭으로 다른 화면으로 보내는 것은 어렵지 않다. 특별한 지시가 없으면 AI는 onClick에서 window.location을 호출하는 식의 초안을 내놓는다. 화면은 이동하고, 기능적으로도 문제없어 보인다. 시니어는 여기서 멈추지 않는다. 이게 단순한 클릭인지, "이동"이라는 의미를 갖는 동작인지 먼저 본다. 사용자를 다른 페이지로 보내는 일이라면 브라우저가 제공하는 링크의 의미를 따라야 한다고 판단한다. onClick만으로 때우지 않고 a 태그나 를 쓴다. 겉으론 사소해 보인다. 그러나 링크로 구현해야 뒤로 가기, 새 탭, 주소 복사, SEO, 접근성이 한꺼번에 맞춰진다. 화면만 넘어가는 것과, 웹의 의미 안에서 올바르게 넘어가는 것은 다르다. 당장 동작하는지만이 아니라, 그 기능이 어떤 의미를 갖는지, 그 의미에 맞게 만들어졌는지를 본다. 이런 어긋남은 페이지 이동처럼 눈에 띄는 기능에서만 드러나지 않는다. 훨씬 작은 UI에서도 드러난다. 버튼인데 텍스트에만 클릭이 걸려 있고 전체 영역은 눌리지 않는 경우. 기능은 동작한다. 텍스트를 누르면 이벤트는 발생한다. 그러나 사용자는 버튼 전체가 눌리기를 기대한다. 입력창도 같다. 겉으로 넓어 보이지만 안쪽의 작은 input만 포커스를 받는 경우가 있다. 에러도 없고 테스트도 통과할 수 있다. 그래도 경험은 어긋난다. 이런 문제는 치명적인 버그처럼 보이지 않는다. 그래서 지나치기 쉽다. 하지만 작은 어긋남이 쌓이면 사용자는 "뭔가 불편하다", "이 제품은 덜 다듬어졌다"고 느낀다. 정확히 무엇이 문제인지 설명하지 못하더라도. 프론트엔드는 화면만 만드는 일이 아니다. 사용자가 제품과 만나는 앞단이다. DB 구조나 서버 내부는 보이지 않는다. 버튼, 입력, 전환, 로딩, 에러 메시지, 피드백으로 제품을 경험한다. 프론트엔드 개발자가 만드는 것은 단순한 UI 조각이 아니다. 제품의 의도가 사용자에게 전달되는 방식 그 자체다. 기준을 남기는 사람 앞에서는 링크와 버튼처럼 프론트엔드에 가까운 세부를 많이 들었다. 그런데 조금 더 넓게 생각해 보면, 시니어 개발자라고 부를 만한 사람은 그런 요소만으로 잘리지 않고, 아래와 같은 면도 함께 갖추지 않을까 싶다. 팀·코드베이스·기준에 관한 이야기는 직군이 달라도 조직 안에서는 비슷한 형태로 반복된다. 시간이 지나면 시스템은 자연스럽게 흐트러진다. 급한 일정 때문에 예외가 생기고, 임시 처리가 추가되고, 비슷하지만 조금 다른 구현이 반복된다. 어느 순간 아무도 자신 있게 고치기 어려운 코드가 된다. 이때 AI는 편의라기보다 증폭기에 가깝다. AI는 코드베이스의 패턴을 강하게 따라간다. 좋은 패턴이 많으면 좋은 결과로 이어지고, 나쁜 패턴이 많으면 나쁜 결과를 더 빠르게 반복한다. 구조, 네이밍, 책임 분리는 이제 사람만을 위한 정리가 아니다. 사람이든 AI든 같은 방향으로 만들게 하는 기반이 된다. 기준이 없으면 팀은 제각각 구현한다. 한 사람은 링크를 의미에 맞게 구현하고, 다른 사람은 클릭 이벤트로 처리한다. 한 사람은 상태를 도메인 기준으로 정리하고, 다른 사람은 화면마다 흩어놓는다. 한 사람은 에러 상태를 사용자 경험의 일부로 보고, 다른 사람은 콘솔 에러만 없으면 된다고 생각한다. 각각의 선택은 작아 보인다. 그러나 이런 차이가 쌓이면 시스템은 일관성을 잃고, 이해하기 어렵고, 수정하기 어렵고, 결국 팀의 속도를 떨어뜨린다. 시니어는 이 흐름을 막는 사람이다. 코드 리뷰에서 스타일만 짚는 것이 아니라, 왜 이 방식이 더 나은지, 어떤 문제가 반복되고 있는지, 책임과 상태와 경계를 어디에 둬야 하는지 팀이 같은 언어로 판단하게 만드는 사람이다. 중요한 것은 문제를 많이 지적하는 것이 아니라, 같은 문제가 덜 생기게 만드는 것이다. 접근성 지적이 PR마다 반복된다면, 그때마다 수정하는 것으로는 부족하다. 공통 컴포넌트를 고치고, 사용 예시를 정리하고, 디자인 시스템의 기준을 업데이트해야 한다. 에러 처리 방식이 제각각이면 패턴을 정리하고 기본 흐름을 만들어야 한다. 상태 위치가 매번 흔들리면 나누는 기준을 팀 안에서 합의해야 한다. 그래서 시니어의 영향력은 작성한 코드의 양으로만 측정되지 않는다. 남긴 기준, 정리한 구조, 팀이 다시 같은 실수를 하지 않게 만든 정도가 더 크다. 팀에서 시니어에게 기대하는 것도 결국 이 지점이다. 자기 일만 잘 끝내는 사람이 아니라, 팀 전체가 더 나은 방향으로 일하게 만들고, 빠르게 만들면서도 나중에 속도를 깎아먹을 리스크를 줄이며, 반복해서 좋은 선택을 하도록 기준을 남기는 사람. 완성도의 기준이 다른 사람 앞에서는 화면과 동작의 예로 말했지만, 여기서 말하는 간극은 링크와 버튼에만 해당하지 않는다. "요청은 처리됐다"와 "의도한 대로 잘 처리됐다" 사이, "일단 배포됐다"와 "운영에서 버틴다" 사이에서 같은 종류의 판단이 필요하다. 앞에서 말한 것들을 실제로 하려면 시간이 더 걸린다. 더 고민해야 하고, 더 많은 것을 챙겨야 한다. 기능이 돌아가는 상황에서 굳이 하지 않아도 되는 일처럼 보이기도 한다. 더 빨리 끝낼 수 있는 선택지는 항상 있다. 시니어는 그 선택지를 고르지 않는 사람이다. 특별한 의지로 버티는 것이 아니라, 완성도의 기준 자체가 다르다. "돌아가면 됐다"가 아니라, "제대로 동작해야 한다"가 기본이다. 그 기준이 내면화되어 있어서, 한 단계 더 들어가는 것이 추가 작업이 아니라 당연한 과정으로 느껴진다. 이 기준은 특별한 상황에서만 작동하지 않는다. 기능이 완료되었다고 느끼는 순간에도, 어딘가 찜찜한 부분이 있으면 그냥 넘기지 않는 습관이다. 만족하기 쉬운 상황에서 기준을 낮추지 않는 것. 그 일관성이 시니어를 만든다. 앞에서 그랬듯이, 다른 계층에서도 같은 태도가 드러난다. 현실과의 균형 이 모든 일은 프로젝트의 현실 안에서 이루어져야 한다. 구조적으로 맞아도 일정과 팀 상황을 무시한 제안은 실행되지 않는다. 실행되지 않는 이상론은 팀을 설득하지 못한다. 좋은 시니어는 "이걸 제대로 하려면 시간이 필요하다"고 멈춰 서지 않는다. 기존 프로젝트의 흐름을 유지하면서, 기능을 만드는 와중에도 조금씩 구조를 바로잡는다. 지금 반드시 손봐야 할 것과 나중으로 미뤄도 되는 것을 구분하고, 큰 변경은 잘게 쪼개 한 번에 흔들지 않는다. 한 번 짚고 지나가면 그걸로 끝이 아니라, 팀이 다시 같은 방향으로 돌아가고 있지 않은지 계속 살핀다. 기술적 개선을 "별도 작업"으로 분리하면 항상 뒷순위로 밀린다. 일상적인 개발 흐름 안에서 조금씩, 그러나 꾸준히 바꿔 나가는 것이 결국 시스템을 지킨다. AI 덕분에 잘못된 방향도 빠르게 쌓일 수 있다. 속도를 무조건 늦추는 사람이 아니라, 빠른 속도가 엇나가지 않게 조정하는 사람. 그 책임을 지속적으로 지는 사람이 시니어다. 맺음 앞은 화면과 구현의 이야기로 썼다. 돌이켜 보면 직군을 가리지 않고 같은 질문에 닿는다. 의도와 결과가 맞는지, 팀에 기준이 남는지, 선이 어디인지, 현실과 어떻게 맞출 것인지. 시니어에 가깝다고 느끼는 사람은 대략 이런 쪽이다. 돌아가면 됐다고 끝내지 않고, 제대로인지를 묻는다. 쉬운 쪽이 있어도 나은 쪽을 고른다. 그 판단을 혼자만의 습관에 묶어 두지 않고 팀에 남기고, 일상적인 흐름 안에서 방향을 조정한다. 지금은 그렇게 본다.