어썸블로그

2026년 7월 출간 IT 원서들 기대평(그리고 빼먹은 6월 기대평 링크....)

2026-07-13T20:07:00+09:00

6월에 빼먹은 기대평 링크와 7월의 IT 원서 기대평입니다. 월드컵 특집(???)

이중 공유기 확인, 스크립트 한 줄로 끝내기

2026-07-14T22:05:10+09:00

포트 포워딩이 안 될 때, 이중 공유기 여부를 명령 한 줄로 확인하는 스크립트를 만들었습니다.

공유기에서 포트 포워딩을 분명히 설정했는데도 외부에서 서버 접근이 안 되는 경우, 경험상 가장 흔한 원인은 공유기 앞에 또 다른 공유기가 있는 이중 공유기 환경입니다. 예전에 이중 공유기 및 공유기 MAC 주소 확인하기라는 글에서 tracert와 arp 명령으로 직접 확인하는 방법을 소개했는데, 막상 다른 사람의 문제를 봐줄 때마다 명령을 하나씩 불러주고 결과 해석까지 해줘야 하는 것이 번거로웠습니다. 그래서 이 과정을 통째로 자동화한 스크립트를 만들어 GitHub에 올렸습니다.

스크립트가 하는 일

동작은 원래 글의 방법 그대로입니다. KT DNS(168.126.63.1)까지 경로를 추적해서 사설 IP 대역(192.168.0.0/16, 172.16.0.0/12)에 속하는 홉의 개수를 세고, 2개 이상이면 이중 공유기로 판정합니다. 10.x 대역도 사설 IP이지만 보통 통신사 내부망이므로 판정에서 제외합니다. 여기에 공유기의 MAC 주소를 ARP 테이블에서 찾아 테이블에 함께 보여주고, 결과를 다음과 같이 요약해 줍니다.

== Tracing route to 168.126.63.1 (max 5 hops)... ==

+-----+-----------------+-------------------+--------------------+
| Hop | IP Address      | MAC Address       | Type               |
+-----+-----------------+-------------------+--------------------+
|   1 | 192.168.123.1   | 18:c5:aa:bb:23:41 | Router 1 (private) |
|   2 | 192.168.219.1   | -                 | Router 2 (private) |
|   3 | 1.213.4.5       | -                 | Public             |
|   4 | 168.126.63.1    | -                 | Public             |
+-----+-----------------+-------------------+--------------------+

== 요약 ==
이중 공유기 환경입니다! (공유기 2개 감지)
  - 1차 공유기: 192.168.123.1 (MAC 18:c5:aa:bb:23:41)
  - 2차 공유기: 192.168.219.1
포트 포워딩은 모든 공유기에서 각각 설정해야 합니다.

위와 같은 결과라면 네트워크 구조는 이렇습니다. 외부에서 내 컴퓨터까지 도달하려면 두 공유기 모두에서 포워딩이 필요합니다.

graph LR
    PC[내 컴퓨터] --> R1[1차 공유기<br/>192.168.123.1]
    R1 --> R2[2차 공유기<br/>192.168.219.1]
    R2 --> NET[인터넷]

사용 방법

배포 형태를 고민하다가 결국 셸 스크립트와 PowerShell 스크립트 두 벌로 정했습니다.

방식	문제점
바이너리	SmartScreen, Gatekeeper가 서명 없는 실행 파일에 경고
sh 단일 배포	Windows에서 Git Bash나 WSL 없이는 실행 불가
sh + ps1	없음 — 텍스트라 경고 없고, 붙여넣기만으로 실행 가능

실행은 각 OS의 터미널에 한 줄 붙여넣기면 됩니다. 파일을 디스크에 저장하지 않으므로 다운로드 경고나 실행 정책 문제도 없습니다.

macOS / Linux (터미널):

curl -fsSL https://raw.githubusercontent.com/daeho-ro/router-check/main/check-router.sh | sh

macOS에서는 Spotlight(⌘+Space)에서 터미널을 검색해 열고 위 명령을 붙여넣으면 됩니다.

Windows (PowerShell):

irm https://raw.githubusercontent.com/daeho-ro/router-check/main/check-router.ps1 | iex

PowerShell이 처음이라면, 시작 버튼을 우클릭해서 터미널 또는 Windows PowerShell을 선택하거나, 검색창에 powershell을 입력해 실행하면 됩니다. 파란색(또는 검은색) 창이 열리면 위 명령을 붙여넣고 Enter를 누르세요. 관리자 권한은 필요 없고, cmd(명령 프롬프트)에서는 동작하지 않으니 반드시 PowerShell에서 실행해야 합니다.

스크립트의 한계

몇 가지 알아두시면 좋은 한계가 있습니다. 먼저 MAC 주소는 1차 공유기만 확인됩니다. 2차 공유기는 내 컴퓨터와 다른 서브넷에 있어 ARP 테이블에 존재하지 않기 때문에, 필요하다면 기기를 직접 찾아 라벨을 확인해야 합니다. 또한 감지는 경로 추적에 응답한 장비를 기준으로 하므로, 2차 공유기가 traceroute에 응답하지 않는 기종이라면 실제로는 이중 공유기인데 단일로 표시될 수 있습니다. 1차 공유기는 라우팅 테이블에서 직접 가져오기 때문에 이 문제가 없지만, 2차는 방법이 없습니다. 결과가 단일 공유기인데도 포워딩이 계속 안 된다면 통신사 장비가 공유기(라우터) 모드로 동작 중은 아닌지 의심해 볼 필요가 있습니다.

이 밖에 드물게 가정용 공유기가 10.x 대역을 사용하도록 설정된 경우에는 통신사 내부망과 구분할 수 없어 감지되지 않고, VPN이 켜져 있으면 트래픽이 VPN 터널로 흐르면서 경로가 왜곡되므로 VPN을 끄고 실행하셔야 정확한 결과가 나옵니다.

이 스크립트, 믿고 실행해도 되나요

인터넷에서 복사한 명령을 셸에 그대로 붙여넣는 것은 원래 조심해야 하는 일입니다. 그래서 직접 검증할 수 있는 방법을 안내해 드립니다.

가장 확실한 방법은 실행 전에 소스를 직접 읽어보는 것입니다. 두 스크립트 모두 100줄 남짓의 평문 텍스트라 위의 raw URL을 브라우저에서 열면 전체 내용을 볼 수 있고, GitHub 저장소에서 변경 이력까지 확인할 수 있습니다. 읽어보시면 스크립트가 사용하는 명령은 traceroute(tracert), arp, 라우팅 테이블 조회가 전부라는 것을 알 수 있습니다. 모두 조회 전용 명령이라 시스템 설정을 바꾸거나 파일을 쓰지 않고, 관리자 권한도 요구하지 않으며, 네트워크로 나가는 패킷은 KT DNS를 향한 경로 추적 프로브뿐입니다. 수집한 결과를 어딘가로 전송하는 코드도 없습니다.

한 가지 오해를 살 만한 부분은 PowerShell 스크립트 안의 Base64 문자열입니다. Base64 인코딩은 악성 코드가 내용을 숨길 때 자주 쓰는 수법이라 의심스러워 보일 수 있는데, 이 스크립트에서는 화면에 출력할 한글 문구를 담는 용도로만 사용합니다. Windows PowerShell 5.1의 파일 인코딩 문제를 피하기 위해 파일을 순수 ASCII로 유지하려는 선택이었고, 각 문자열 옆에 영어 주석으로 내용을 병기해 두었습니다. 의심스러우면 아무 문자열이나 직접 풀어볼 수도 있습니다.

[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('64uo7J28IOqzteycoOq4sCDtmZjqsr3snoXri4jri6Qu'))
# 단일 공유기 환경입니다.

그래도 파이프 실행이 꺼려진다면 파일로 내려받아 내용을 확인한 뒤 실행하는 방법도 있습니다.

irm https://raw.githubusercontent.com/daeho-ro/router-check/main/check-router.ps1 -OutFile check-router.ps1
notepad .\check-router.ps1   # 내용 확인
powershell -ExecutionPolicy Bypass -File .\check-router.ps1

코드는 daeho-ro/router-check에 있습니다. 포트 포워딩이 말을 안 들을 때 확인 명령 한 줄부터 실행해 보시면, 적어도 어느 공유기를 붙잡고 씨름해야 하는지는 바로 알 수 있을 겁니다.

개발 자동화에서 조직 AX까지

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

오랫동안 테스트했던 사내 배포 시스템을 드디어 운영 환경에 배포했습니다.

이제 누구나 AI로 앱을 만들고 공개 범위만 정한 뒤 “배포해줘~”라고 하면, 자동으로 보안 점검을 거쳐 내부망에 배포하고 사내에 공유할 수 있습니다.

이 글은 배포 시스템의 완성을 계기로 돌아본, 지난 1년간의 전사 AX(AI Transformation) 여정입니다. 다양한 의견은 언제나 환영합니다 ㅎ

AI의 등장

2025년 초까지 개발하면서 GitHub Copilot이나 ChatGPT, Claude의 도움을 조금씩 받고 있었습니다. 그때까지만 해도 개발은 어디까지나 개발자가 하고, AI는 옆에서 약간의 도움을 주는 보조적인 역할이었습니다.

그러다가 2025년 하반기, Claude Opus 4.1이 나오면서 엄청난 충격을 받았습니다. AI가 보조적인 역할에서 완전히 ‘메인’이 되는 순간이었습니다. Sonnet과 Opus의 체급 차이는 엄청났고, 난생처음으로 AI 구독에 월 $200짜리 플랜을 2개씩 구매해서 사용하기 시작했습니다. (구독에 $400이라니 말도 안 되게 비싸 보였지만, 개발자 인건비를 생각하면 한없이 혜자스러운 가격입니다.) Claude Code에 너무 감동받아 무려 4년 만에 블로그 글(초보를 위한 Claude Code 안내서)을 쓰기도 했습니다. 새롭게 쏟아지는 AI 소식들이 재밌어서 계속 밤샜던 기억이 납니다.

이때부터 AI가 미친 듯이 발전하고 다양한 툴이 쏟아져 나오기 시작했습니다. Nano Banana Pro 한글 품질의 충격, Typeless 음성인식의 부드러움, 마치 사람처럼 끝까지 요청한 일을 해내는 OpenClaw, 그리고 Claude에서 플러그인을 하나 만들면 SaaS 업체 주가가 폭락하는 충격까지… 이제 개발을 넘어 모든 업무에 AI를 적용할 수 있게 되었습니다. 그전까지는 메일 초안을 도와주거나 이미지를 생성하는 수준이었다면, 이제는 내가 가진 데이터와 맥락(Context)에 접근하고 실제 액션까지 수행하게 되었습니다.

세 가지 시도

2026년 초, 도대체 어디까지 AI를 적용할 수 있을지 궁금했습니다. 그래서 몇 가지 테스트를 진행했습니다.

첫 번째, 개발 업무 중 몇 %를 자동화할 수 있을까?
두 번째, 기존 시스템을 차세대 버전으로 마이그레이션할 때 얼마나 효율적일까?
세 번째, 신규 서비스 개발을 얼마나 안정적으로 빠르게 할 수 있을까?

첫 번째, 개발 자동화 테스트 결과는 충격적이었습니다.

제가 일하고 있는 퍼플아이오에서는 Asana를 태스크 관리 시스템으로, GitLab을 소스 저장소로, 배포는 작업별로 Branch를 따는 GitHub Flow 개발 방식을 사용하고 있습니다. Asana에 요청 사항이 들어오면 세부적으로 추가 논의를 하고, 태스크 번호로 Branch를 따서 작업 및 테스트를 거쳐 최종 배포하는 방식입니다. Branch = PR(Pull Request)이 곧 하나의 작업 단위입니다.

자동화 성능 테스트를 위해 최근 완료된 PR 180건을 샘플링해서 Diff 코드를 저장했습니다. 그리고 각 PR의 시작 시점 Git 코드를 가져와서, 오직 Asana 태스크만 보고 사람의 개입 없이 AI에게 PR을 작성하게 했습니다. 그리고 그 결과 Diff를 서로 비교했습니다.

결과는 사람이 작성한 코드와 AI가 작성한 코드의 평균 구현 일치도가 70%였습니다(태스크 설명이 제대로 작성된 구현 가능 PR 110건 기준). 100% 일치한 게 30개(태스크 설명이 상세한 PR의 27%), 90% 이상 거의 일치한 게 38개였습니다. 실패의 원인은 대부분 ‘태스크 설명이 부실해서’였고, 문제는 AI가 아니라 요구사항 정의였습니다.

다음은 실제 벤치마크 결과 보고서 일부입니다.

두 번째, 기존 레거시 시스템을 그대로 옮기는 것도 충격적이었습니다.

우리가 만든 CMS는 오래된 이슈가 있었습니다. 나름 Next.js에 React 구조였기 때문에 당장 큰 불편함은 없었지만, 한 번 크게 개선해야겠다는 생각은 하고 있었습니다. 보통 이런 작업은 우선순위가 낮아 방치되기 마련인데, AI를 활용해 보기로 했습니다.

AI에게 전체 소스코드 접근 권한을 주고 브라우저로 페이지를 분석하게 했습니다. AI가 브라우저를 띄우고 CMS에 접근한 뒤, 사용자가 로그인할 때까지 기다렸다가 마이그레이션할 페이지들에 접속하여 각 화면과 네트워크 요청을 분석하라고 시켰습니다. 그리고 각 페이지 스크린샷을 찍고 UI 구조, 컴포넌트, 데이터 모델링, API 호출, 상태 관리 등을 정리해 달라고 했습니다.

보통 AI가 만든 결과가 이상한 건 “내 맘에 안 들어서”입니다. 내 맘에 안 드는 이유는 요청을 모호하게 했기 때문이고(예: “기획전 관리 기능 만들어줘”), 반대로 ‘기존 페이지 소스코드와 화면’ 자체가 완벽한 기획서가 될 수 있다면 결과는 거의 의도한 대로 나옵니다.

내부 데이터가 있어 전부 공개할 순 없지만, 기본 기능은 완벽하게 동작했습니다. ~~지금 봐도 싱기..~~

이제 코드를 잘 타이핑하는 것보다 기능을 어떻게 명확히 정의하느냐가 더 중요해졌습니다. (Spec이 짱이다!)

이후 내부에서 큰 규모의 차세대 기능 마이그레이션 프로젝트가 있었는데, 기존 계획 대비 절반도 안 되는 리소스로 완료하고 안정적으로 운영 중입니다. 가장 시간이 많이 걸린 건 코딩이 아니라 기존 로직을 .md 파일로 정리하고 테스트 케이스를 빠짐없이 짜는 작업이었습니다.

세 번째, 신규 서비스 개발도 충격적이었습니다.

요구사항(Spec)만 잘 정의하면 구현은 원하는 대로 나왔기 때문에, 신규 시스템 구축도 훨씬 효율적으로 할 수 있었습니다.

기존에 요구사항 분석 -> 기획 -> 설계 -> 구현 -> 데모라는 긴 과정이 있었다면, 이제는 요구사항을 받자마자 그걸 세계 최고 수준의 전문가(넌 글로벌 탑티어 회사의 기획자야!)가 기획하고 개발까지 완료해서 첫 미팅부터 동작하는 데모를 보여주고 피드백을 받는 게 가능해졌습니다.

요구사항(3-4줄)을 받으면 그걸 바탕으로 PRD(제품 요구사항 정의서)를 만들고, 그 파일을 바탕으로 기능 명세를 정의한 뒤, 기능별 페이지, UI/Component, API/모델 설계, 사용자 Flow를 한 번에 생성하라고 했습니다. 그걸 사용자가 검토하고 승인하면 그대로 Ralph Loop으로 밤새 코드를 짭니다. 명세 보고 구현하고 제대로 짰는지 체크하고 다시 검증하라고 하면 구현만 6시간 정도 걸렸던 것 같습니다. ~~나는 잘 테니 넌 일해라~~

아래 화면은 그렇게 매장관리 시스템 초안을 잡은 모습입니다. (모두 가상 데이터입니다.)

첫 미팅 때 이미 동작하는 화면을 보고 이야기하니 개선이나 방향성을 잡기 훨씬 쉬웠습니다. 최종 완성 버전은 초기와 달라졌지만, 이 역시 기존 계획 대비 절반의 리소스로 구현했고 AI 분석 기능을 추가하여 더 강력한 기능을 제공하게 되었습니다.

전사적 선언

AI 성능에 강한 확신~~3 충격~~을 얻고 2026년 초, 회사의 방향을 AX로 정의했습니다. 밥 먹는 거 빼고 모오오오든 업무를 자동화하고 연말까지 인당 생산성을 200% 올리는 걸 목표로, 개인과 조직이 일하는 방식을 완전히 바꾸기로 했습니다.

AI가 못하는 일은 거어어어의 없어질 것이다.
- 코딩을 몰라도 많은 업무를 일정 수준 이상 자동화할 수 있습니다.
- 개발뿐 아니라 문서 작성, 분석, 운영, 배포, 데이터 처리까지 자동화의 대상이 됩니다.
앞으로는 맥락(Context)이 핵심 자산이 될 것이다.
- 나의 생각과 암묵지를 끊임없이 글로 남겨야 합니다.
- 내가 본 PPT, 문서, 자료를 markdown으로 저장해야 합니다.
- 팀과 맥락을 공유하고, 그 맥락 위에서 AI와 함께 일해야 합니다.
- AI는 맥락을 쉽고 효과적으로 모을 수 있게 도와줘야 합니다.

일단 단기적으로(한 달 내에) 할 수 있는 것부터 해보자고 사내 AI 챌린지(Quick Win)를 열었습니다.

홈 — Purple IO AI Quick Win

총 28개의 프로젝트가 등록됐고, 참가자들은 평균 83%의 업무 시간 절감 효과를 확인했습니다.

이걸 진행하면서 다시 한번 느낀 건, 정말 그냥 “해줘”라고 하면 다 해준다는 점입니다.

비개발자는 평소에 사용하던 CRM에서 지원하지 않던 기능(사이트 주소를 입력하면 스크립트를 분석해서 어떤 솔루션을 쓰는지 파악하고, 영업 리드 점수를 계산해 제안 메일 초안까지 써주는 기능)을 직접 만들었습니다.

개발자는 에러 알람이 오면 상세 로그를 뒤지고 관련 코드를 찾던 귀찮은 삽질을, AI가 1차 원인 분석을 끝낸 걸 확인만 한 뒤 승인하는 환경을 갖추게 되었습니다.

AI는 평소 하던 작업을 더 빠르게 하는 걸 넘어, 평소엔 생각도 못 했던 작업까지 가능하게 만들었습니다.

AI가 로컬에 있는 .md 파일을 읽고 해석하는 능력이 컨플루언스보다 낫다고 판단해 사내 정보를 옵시디언(Obsidian)에 모으기로 했습니다. 이때 가장 어려운 점은 비개발자분들에게 Git을 가르치는 일이었습니다. 누구나 문서를 작성하고 공유해야 하는데 Git CLI는 너무 높은 장벽이었습니다.

그래서 5분에 한 번씩 알아서 pull/push를 하고, 충돌이 나면 별도 파일로 쪼개어 머지 컨플릭트를 방지하는 옵시디언 플러그인을 만들었습니다. 옵시디언 플러그인 개발은 처음이었는데 AI 덕분에 몇 시간 만에 뚝딱 완성했고 문제없이 잘 쓰고 있습니다.

https://github.com/subicura/second-brain-plugin

또한 모바일 환경에서도 끊김 없이 Claude Code 작업을 하고 싶어서 터미널과 AI 코딩 기능이 포함된 Mac 애플리케이션(PurpleMux)도 만들었습니다. 난생처음 만져보는 Electron에 터미널 에뮬레이터, tmux 연동까지 AI가 아니었으면 불가능했을 겁니다. 무려 11가지 언어를 지원하는데, 어느새 중국인 사용자도 생겼습니다.

https://subicura.com/purplemux

지금 개발팀은 상상하던 모든 툴을 붙여 코딩의 완전 자동화를 꿈꾸고 있습니다.

지금 이 시간에도 새로운 프로젝트가 등록되고 있습니다..

진행중인 자동화 프로젝트 보기

Purple Pipeline: Asana로 태스크가 인입되면 파이프라인 큐에 쌓이고, 기획자 -> 아키텍트 -> 디자이너 -> 개발자 -> 리뷰어 -> 배포자 등의 페르소나를 조합하여 업무를 끝까지 처리합니다.

Purple Test: E2E 테스트를 실행하고 과정을 녹화해서 결과를 확인합니다.

Purple Gauge: 성능 테스트 자동화 툴입니다.

Purple Auth: 사내 SSO 및 중앙 인증/세션 관리를 담당합니다.

MeetNote: 화자 구분이 가능한 로컬 회의록 녹음 및 옵시디언 플러그인입니다.

확산과 허들

개발팀 특성상 AI를 빨리 접했기 때문에, 자연스럽게 함께 일하는 현업 부서의 업무를 AI로 도와주기 시작했습니다. 반복 업무는 자동화 프로그램을 만들었고, 우리가 일하는 방식(Claude Code)도 그대로 전파했습니다.

그런데 문제는 시작부터 터졌습니다. Windows 환경에서 cmd를 난생처음 보는 분에게 Claude Code를 가르치는 건 생각보다 훨씬 어려웠습니다. 설치하고, cmd가 뭔지 설명하고, cd로 디렉토리를 이동하는 법을 알려주는 데 교육 시간의 대부분이 날아갔습니다. 이렇게 좋은 툴이 있는데 시작조차 못 하는 상황, 상상도 못한 허들이었습니다.

그래서 툴을 바꿨습니다. 구글이 만든 IDE인 Antigravity였습니다. 에디터 형식이라 GUI 기반이고 AI Assistant를 지원하기 때문에 초보자도 바로 활용할 수 있었습니다.

이 방법은 대성공이었고 초기 허들을 크게 낮출 수 있었습니다. 여기서 자연스럽게 Claude Code와 cmd 환경으로 넘어오고, 내부 데이터에 접근할 수 있는 커스텀 스킬을 배포하자 사내 자동화 앱과 대시보드가 폭발적으로 늘기 시작했습니다.

기존에는 단순 매출 흐름만 보여줬던 대시보드에서, 특정 쇼핑몰에서의 순위와 최근 리뷰도 모아서 보여주고, 경쟁사 인기상품도 보여주고 별도로 찾고 수작업했던 작업을 하나의 화면에 모아서 보여줍니다. 현업이 직접 만들기 때문에 뭐가 필요한지 더 잘 알고 더 유용하게 쓸 수 있습니다.

엑셀을 눈으로 비교하던 단순 작업이나, 매일 사람이 확인하고 지시했던 업무들이 자동화되기 시작했습니다. 가장 기분 좋은 피드백은 “4~5시간 걸리던 수작업인데, 아침에 출근하면 이미 완료되어 있어요”입니다.

개발자 수준의 ‘AI 챔피언’들이 탄생하고 있습니다.

진짜 문제는 따로 있었다

하지만 판이 커지다 보니 공통적인 문제가 보였습니다. 잘 쓰는 사람은 어느새 알아서 잘하고 있지만, 그렇지 못한 많은 분들에게 여전히 허들이 남아있었습니다.

Windows 중심의 업무 환경
M365 / OneDrive 기반의 분산된 업무 방식
내부 시스템 연동을 위한 까다로운 인증/기본 설정
그리고 배포의 어려움

한 땀 한 땀 개발자가 도와주면 되지만 거기엔 한계가 있습니다. 결국 스스로 자생할 수 있어야 합니다.

그래서 QuickWin 때 만들었던 DocSync를 전면 개조하기 시작했습니다. 기본 AI Assistant 기능 위에 사내 환경에서 쓰기 좋은 것들을 하나씩 붙여 사내 AI 플랫폼 ‘코코(KOCO)’를 만들었습니다. Claude /Claude Cowork와 거의 유사하며 최대한 사용자들이 쉽게 사용할 수 있게 설계하고 개발도 최소화했습니다.

사내 업무에 최적화되어 있고

시각화도 이쁩니다.

주요 특징은 다음과 같습니다.

개발 도구(nodejs) 내장, 별도 설치 필요 없음
OneDrive / 메일 / 캘린더 연동 (묻고 답하고 생성까지)
SAP 등 내부 데이터베이스 연계, 그룹웨어(전자결재, 지원관리 등) 연계
스킬 및 워크플로우 공유
바이브 코딩부터 사내망 배포까지 한 번에

메일, 공유 드라이브의 파일을 싱크하고 SQLite에 색인하고 암호화해서 보관합니다. 일반 사용자가 보안 걱정 없이, 복잡한 설정 없이 업무를 자동화하고 바이브 코딩까지 할 수 있게 되었습니다. 약 80명을 대상으로 3개월간 테스트하며 뜨거운 피드백을 받았고, 계속해서 업데이트 중입니다.

다양한 방식으로 쓰고 있지만 최근 좋은 사례 하나만 꼽자면 ‘경영 정보 Agent’입니다.

재무 관련 데이터를 xlsx로 받고 월간 보고서를 한 디렉토리에 모읍니다. 그러면 커스텀 llm-wiki가 대용량의 xlsx를 DuckDB에 밀어 넣고 컬럼 메타데이터를 설정한 뒤, 월간 보고서는 .md로 변환해서 인덱싱합니다. 이 디렉토리를 OneDrive 공유 폴더로 만들고 담당자들이 공유받습니다. 그다음 KOCO에서 프로젝트를 만들고 “이 디렉토리를 보고 경영 정보를 알려줘”라고 지침을 넣으면 끝입니다. 최근 지표나 이슈를 물어보면 아주 정확하게 뽑아냅니다. 원래 내가 가지고 있는 파일을 기반으로 조회하는 거라 권한 이슈도 없습니다. ~~개이득~~.

그리고 여기서 가장 신경 쓴 기능 중 하나가 ‘배포’입니다. 바이브 코딩이 늘어날수록 “이거 팀에 공유하고 싶은데요”라는 요청이 점점 커져갔기 때문입니다.

배포

드디어 이번 글의 메인 주제입니다.

요구사항은 간단했습니다. ~~하지만 설정은 귀츈..~~

내부망에 배포할 것
배포 전에 보안 검토(Security Review)를 받을 것
사용자별로 인증하고, 공유 범위(전체 / 일부 사용자 / 비공개)를 설정할 수 있을 것

최종 아키텍처는 다음과 같습니다.

먼저 배포 대상이 될 사내 EKS(Kubernetes) 환경을 구축했습니다. 배포 파이프라인은 별도 솔루션을 도입하지 않고 GitLab CI/CD를 그대로 썼습니다.

사용자가 “배포해줘~”라고 하면, 현재 로그인한 사용자 아이디로 GitLab에 연동 로그인하고 랜덤한 이름의 프로젝트를 생성한 뒤 파일을 전부 올립니다. 그러면 자동으로 빌드되고 배포까지 이어집니다.

앱을 만들고 배포 요청을 합니다.

데이터베이스는 기본 SQLite이고 /data 폴더를 persistence volume으로 설정했습니다.

보안 검토도 여기에 얹었습니다. CI/CD 파이프라인 중간에 보안 스캔 단계를 넣었고, 검토가 완료되면 Slack으로 알람이 옵니다. 실제 배포는 담당자가 한 번 더 확인하고 승인합니다. ~~완전 자동은 아직 좀 불안; ㅎ~~

내부망 배포까지는 잘 됐는데, 마지막 퍼즐은 인증이었습니다. 전체 공개가 아니라 비공개로, 혹은 특정 사람에게만 공유하는 권한 제어 기능이 필요했습니다.

수많은 앱들마다 일일이 인증 코드를 넣으라고 가이드를 만들까 하다가 Cloudflare Access를 소개받았습니다. “오! 프록시처럼 동작하니까 모든 트래픽이 무조건 저길 거치게 하면 되는구나.”

그래서 ‘Purple Access’라는 자체 프록시 레이어를 만들었습니다. 이제 EKS의 Ingress ALB는 Pod을 직접 바라보지 않고 Purple Access를 바라봅니다. 인증이 안 되어 있으면 로그인 창을 띄우고, 로그인하면 접근하려는 앱에 대한 권한이 있는지 체크합니다. 있으면 통과, 없으면 block. 모든 접근은 감사 로그로 남습니다.

예전 같으면 이런 리버스 프록시 엔진을 직접 만든다는 건 꽤 골치 아픈 일이었겠지만, 이 또한 AI의 도움으로 며칠 만에 간단히 해결했습니다.

이렇게 배포 기능이 완성되었습니다. 바이브 코딩을 하고, 공개 범위를 정하고, “배포해줘~”라고 하면 보안 점검 후 내부망에 배포되고 사내에 공유됩니다.

앞으로

처음에는 AI가 개발을 더 빠르게 해주는 도구라고 생각했습니다. 하지만 지난 1년 동안 가장 크게 바뀐 것은 개발 속도가 아니었습니다.

문제를 정의하는 방식이 바뀌었고, 지식을 남기는 방식이 바뀌었으며, 함께 일하는 방식이 바뀌었습니다.

특히 가장 크게 느낀 것은 맥락(Context) 의 중요성입니다. AI는 생각보다 코드를 잘 작성하고 문서를 잘 정리합니다. 하지만 왜 이런 기능이 만들어졌는지, 어떤 배경에서 의사결정을 했는지, 앞으로 어떤 방향으로 발전해야 하는지는 결국 조직이 남긴 맥락에서만 찾을 수 있었습니다.

그래서 우리는 다음 단계들을 준비 중입니다. 없는 데이터는 모으고, 모으는 맥락은 더 정확하게 만들고, 서로 연결하는 것.

데이터 맵을 만들어 가시성을 높인다. 연계는 데이터가 중요한 것부터 우선순위대로.
비정형 데이터가 이메일과 로컬 PC에서 죽지 않도록, 업무의 input/output이 자연스럽게 마크다운 형태로 쌓이도록 프로세스를 리팩토링한다.
부족한 맥락은 업무 흐름을 개선하거나 신규 시스템을 구축한다.

기존 시스템을 살짝 개선 = 전자결재 AI 스크리닝 및 검수/제안 단계만 보완해도 의미있는 맥락을 데이터로 모을 수 있다고 생각합니다.

AI는 앞으로도 계속 발전할 것입니다. 하지만 그 AI를 얼마나 잘 활용할 수 있는지는 결국 조직이 얼마나 자신의 지식과 맥락을 축적하고 연결할 수 있는지에 달려 있다고 생각합니다.

지난 1년 동안 우리가 만든 것은 여러 개의 AI 도구와 하나의 배포 시스템이었습니다. 하지만 그 과정에서 정말 바뀐 것은 도구가 아니라 일하는 방식이었습니다.

이제 우리는 사람이 모든 일을 직접 처리하는 조직이 아니라, 사람이 남긴 맥락 위에서 AI가 함께 일하는 조직을 만들고 있습니다. 아직 완성된 답은 없지만, 방향은 분명합니다.

다음 글에서는 이 여정이 다양한 산업군에서 어떤 모습으로 이어지고 있는지 이야기해 보겠습니다.

기술 뉴스 #298 : 2026-07-16

2026-07-16T04:21:32+09:00

웹개발 관련

Getting Started with Anchor Positioning : 툴팁을 화면 안에서 띄우려면 처리가 꽤 복잡한데, Anchor Positioning API로 이를 쉽게 처리할 수 있다. 대상 요소에 CSS로 anchor-name으로 고유한 이름을 지정하고 position-anchor로 앵커에 연결할 수 있다. position-area로 원하는 위치를 조정하고 세부사항을 지정하면 자연스러운 툴팁을 쉽게 구현할 수 있다.(영어)
Wordgard Release 0.1 : 웹용 코드 에디터 CodeMirror를 만든 Marijn Haverbeke가 텍스트 에디터 ProseMirror와 CodeMirror 6 재설계에서 얻은 경험을 바탕으로, ProseMirror의 새로운 버전인 리치 텍스트 에디터 Wordgard 프로젝트를 공개했다. ProseMirror도 계속 유지보수할 것이지만, 아쉬운 결정이 있어서 완전히 새로 만들게 되었다. Wordgard는 델타 형식에서 파생된 CodeMirror의 변경 사항 표현 방식을 바탕으로 한 시스템을 사용한다.(영어)
오리진 트라이얼로 이메일 확인 프로토콜 테스트 | Blog | Chrome for Developers : 입력받은 이메일 주소로 메일을 보내서 소유자를 인증하는 이메일 확인을 자동화할 수 있는 프로토콜을 크롬이 제안하고 오리진 트라이얼로 피드백을 받고 있다. 사용자가 브라우저에서 이메일 제공 업체에 로그인한 상태에서 이메일 확인을 하려는 사이트가 이메일 제공 업체에 등록된 상태이면 사이트에서 이메일을 선택하면 이메일 인증 토큰(EVT)를 발급하고 해당 사이트가 이를 통해 소유주임을 자동으로 확인할 수 있다.(영어)
How Astryx works : Meta에서 AI와 연동되면서 의존성 없이 사용자가 정의할 수 있는 디자인 시스템 Astryx를 오픈소스로 공개했다. Astryx는 사전 컴파일된 CSS와 함께 제공되는 React 컴포넌트 라이브러리로 React와 StyleX 기반으로 구축되었다.(영어)

그 밖의 개발 관련

Getting started with loops : Claude Code에서 중지 조건이 충족될 때까지 작업을 반복하는 에이전트인 루프를 사용하는 방법을 설명한다. 턴제 루프는 사용자 입력에 따라 실행되고 /goal은 목표 기반 루프에 /loop와 /schedule은 시간 기반 루프에 사용할 수 있다. 선제적 루프는 사람의 개입 없이 이벤트나 일정에 따라 트리거되어 작업을 진행한다.(영어)
Rewriting Bun in Rust : 2021년 esbuild의 트랜스파일러를 Go에서 Zig로 바꾸면서 시작된 Bun은 Zig 덕에 완성될 수 있었다. 하지만 Bun의 버그 수정 목록은 너무 많았고 Zig는 메모리를 자동으로 관리해 주지 않아서 정리 코드를 잘 사용하기 위해 엄격한 스타일 가이드를 도입하는 것이 현실적인 선택이었다. 버그의 상당수는 오류 경로에서 해제를 잊은 경우였는데, Rust는 이를 컴파일러 오류로 처리해 더 효과적인 피드백 루프를 준다. 그래서 Bun의 53만 라인에 이르는 Zig 코드를 Claude Fable 5를 이용해 11일 동안 새로 작성하기 시작했다. 작업은 한꺼번에 처리하기로 하고 동적 워크플로우를 사용했으며 구현자 외에 에이전트 2개로 검토하게 했다.(영어)
The git history command deserves more attention : Git 2.54, 2.55에서 실험적으로 도입된 git history 명령어에는 기존 커밋을 수정하고 모든 브랜치를 이에 맞춰 자동으로 리베이스하는 fixup, 커밋 메시지를 업데이트하고 그 위의 모든 내용을 자동으로 리베이스하는 reword, 하나의 커밋을 두 개로 분할하는 split 서브 커맨드를 제공한다.(영어)
Claude Desktop on Linux (beta) : Claude Code 데스크톱 앱이 Linux 버전도 베타로 출시되었다.(영어)
Open source license compliance is in public preview : 저장소에 의존성을 추가하거나 수정할 때 라이센스를 검사해서 프로젝트의 라이센스와 맞는지를 확인해주는 라이센스 컴플라이언스 기능이 공개 프리뷰로 열렸다. 저장소의 ruleset에서 "Require license compliance check results before merging"를 활성화해서 사용할 수 있다.(영어)
Announcing Box3D : Box2D에서 게임을 위한 오픈소스 3D 물리 엔진 Box3D를 공개했다.(영어)

AI 관련

GPT‑5.6: Frontier intelligence that scales with your ambition : OpenAI가 GPT-5.6 모델 제품군을 정식 출시했다. 여기에는 플래그십 모델인 Sol, 일상 업무에 적합한 Terra, 비용 효율적인 모델인 Luna가 포함되어 있다.(영어)
Introducing Claude Sonnet 5 : Anthropic에서 Opus 4.8에 근접하면서 가격이 저렴한 최신 모델 Sonnet 5를 출시했다. Sonnet 4.6에 비해 잘못된 행동을 할 확률이 낮고 더 안전한 것으로 평가되었다.(영어)
Introducing Grok 4.5 : SpaceXAI가 최신 모델인 Grok 4.5를 출시했다. Cursor와 함께 훈련했고 공학 과제에서 뛰어난 성능을 보여준다.(영어)
GPT‑Live 소개 : OpenAI에서 AI와 실제 사람처럼 대화할 수 있는 음성 모델 GPT-Live를 출시했다. 초기 계단식 음성 대화는 음성을 텍스트로 변환하고 응답을 생성하고 이를 다시 음성으로 만드는 3가지 모델을 이용했지만 턴 기반 음성 모델에서는 하나의 모델안에서 음성을 처리하고 생성해서 자연스럽게 만들었지만 사용자의 말이 끝나고 처리해야 하므로 어색함이 존재했다. GPT-Live는 응답을 생성하는 동시에 사용자 입력을 처리할 수 있어 자연스럽게 대화하고, 복잡한 작업은 다른 모델에 맡겨 추론하도록 했다.(한국어)
GPT-5.6 기반 ChatGPT Work : OpenAI가 GPT-5.6 기반으로 팀에서 사용하는 도구의 맥락을 연결해 결과물을 만들 수 있는 ChatGPT Work를 출시했다.(한국어)
Moving to the new ChatGPT desktop app : OpenAI가 ChatGPT와 Codex로 분리되어 있던 데스크톱 앱을 통합하고 하나의 앱에서 Chat, ChatGPT Work, Codex를 모두 제공하는 방식으로 바꾸었다. 기존 ChatGPT 앱은 ChatGPT Classic으로 이름이 바뀌었다.(영어)
Claude Science, an AI workbench for scientists : Anthropic이 과학자들을 위한 AI 워크벤치인 Claude Science를 출시했다. Claude Science는 연구 수행을 돕고 결과물을 생성하면서 반복적으로 개선하도록 도와준다.(영어)
Start building with Nano Banana 2 Lite and Gemini Omni Flash : Nano Banana에서 가장 빠르고 비용 효율적인 이미지 모델인 Nano Banana 2 Lite와 비용 효율적으로 고품질 동영상을 생성하고 편집할 수 있는 Gemini Omni Flash를 출시했다.(영어)
GeneBench-Pro 소개 : OpenAI에서 계산생물학 연구에 필요한 높은 수준의 판단과 분석을 모델이 제대로 수행하는지 평가하는 벤치마크인 GeneBench-Pro를 출시했다.(한국어)
Redeploying Claude Fable 5 : 지난 6월 12일 미국 정부의 수출 통제 조치로 차단되었던 Claude Fable 5와 Claude Mythos 5가 지난 6월 30일 해제되어서 7월 1일부터 다시 Fable 5를 사용할 수 있게 되었다. 7일까지 유료 플랜에서 제공되다가 12일까지로 연장되었다.(영어)
Leanstral 1.5: Proof Abundance for All : Mistral에서 코드의 정확성을 증명하는데 초점을 맞춘 모델인 Leanstral 1.5를 공개했다. Leanstral 1.5는 전체 매개변수가 119B지만 활성 매개변수는 6B여서, 성능을 높이면서도 사용하기 쉬워졌다.(영어)
Introducing Muse Spark 1.1 : Meta에서 에이전트 기반 작업을 위해 구축된 다중 추론 모델 Muse Spark 1.1을 발표했다.(영어)

인프라 관련

Kubernetes 버전 롤백을 사용하여 Amazon EKS 클러스터를 자신 있게 업그레이드하세요! : AWS EKS가 버전 업그레이드를 더 적극적으로 할 수 있도록 버전 롤백 기능을 도입해서 7일 이내에 이전에 운영하던 버전으로 롤백할 수 있게 되었다.(한국어)
Announcing vmestimator: Real-time Cardinality Estimations for VictoriaMetrics and Prometheus : VictoriaMetrics에서 시계열 데이터에서 카디널리티 추세를 실시간으로 모니터링하고 알림을 보낼 수 있는 vmestimator를 오픈소스로 공개했다.(영어)

보안 및 장애

GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos : GitHub에서 새로 출시한 Agentic Workflows를 이용해서 이슈를 만들어서 워크플로우를 실행하게 해서 접근할 수 없는 비공개 저장소의 데이터를 공개 저장소에 올리게 하는 공격에 성공하고 이를 GitLost라고 명명했다.(영어)
GPT‑Red: Unlocking Self-Improvement for Robustness : OpenAI에서 자동화된 내부 전용 레드팀 모델을 훈련시킨 GPT-Red를 공개했다.(영어)

볼만한 링크

My Thoughts on the Bun Rust Rewrite : Zig를 만든 Andrew Kelley가 Bun이 Rust로 재작성된 것에 대한 생각을 밝혔다. Bun을 만든 Jarred Summer가 Zig 커뮤니티에 합류해서 빠르게 배우면서 커뮤니티에 긍정적인 영향을 끼치면서 Zig 커뮤니티에 감사함을 많이 표현했다. 하지만 Bun이 관심을 모으고 Oven이 본격적인 사업을 운영하면서 양상은 달라졌고 다른 사람들에게도 자신과 같은 삶을 요구하면서 형편없는 관리자로 평가받기 시작했고 Zig 커뮤니티 사람들도 Oven에서 일하는 것은 기피하기 시작했다. 이때부터 Zig와 Jarred의 갈등도 깊어지기 시작했고 LLM을 사용한 Bun의 코드 품질은 매우 나빠졌고 GitHub 봇인 Robobun이 Zig를 어떻게 작성하면 안되는지를 보여주면서 Zig 커뮤니티는 부담을 느끼기 시작했다. Oven이 Anthropic에 인수되고 미팅에도 나타나지 않았을때 관계가 끝났음을 알고 있었고 Rust로 재작성한다고 발표했을 때 너무 기쁠 정도였다. 핵심은 Zig와 Rust의 언어적 특징과는 상관없이 두 프로젝트 간의 가치관 차이로 발생한 것이다.(영어)
Zuckerberg 'Admits' Meta's Layoffs Were Ineffective : Meta의 CEO인 Mark Zuckerberg가 타운홀 미팅에서 구조조정 이후 지난 4개월 동안의 에이전트 개발 속도가 예상만큼 좋지 못했고, 당시 Claude Code 같은 도구에 너무 낙관적이었다고 밝혔다. Meta는 분위기에 의존해서 의사결정을 하는 경향이 있는데 메타버스가 실패였다는 걸 너무 늦게 깨달아 AI에서도 뒤처지게 되었고, 수천 명의 직원을 해고하고 AI 엔지니어에게 투자하는 결정을 했지만 이 역시 분위기를 따른 의사결정이었다고 말한다.(영어)
Interview With Mitchell Hashimoto : HashiCorp의 창업자이면서 Ghostty 터미널을 만들고 있는 Mitchell Hashimoto의 인터뷰다. 어떤 의도로 Ghostty를 만들고 있고 오픈소스와 프로그래밍 언어 생태계에 대해 어떤 생각을 가지고 있는지 알 수 있다.(영어)

IT 업계 뉴스

Better Auth is joining Vercel : 인증 프레임워크를 만드는 Better Auth가 Vercel에 인수되었다. 3년 전 인증 기능이 필요해서 NextAuth를 주로 사용했지만 더 많은 요구사항을 충족하지 못했고 다른 사람도 인증 시스템에 시간을 많이 쓰고 있다는 걸 깨닫고 better-auth를 만들게 되었고, 사람들에게 피드백을 받으면서 1.0을 릴리스했다. Better Auth가 인기를 끌면서 YC에 지원해서 합격하게 되어 회사를 설립하고 Auth.js와 NextAuth.js를 인수하게 되었다. 다음 작업으로 호스팅을 준비하다가 AI로 인해 달라지는 환경에 맞게 Agent Auth를 출시했고 이 시도를 이어가기에 Vercel이 적합하다고 판단하게 되었다.(영어)
Chat Control 1.0 passed the European Parliament — through the back door : EU가 암호화된 메시지와 사진 등 사적인 디지털 통신 내용을 사전 심의 없이 스캔할 수 있는 법안인 Chat Control 1.0이 유럽 의회를 통과해서 2028년 4월 3일까지 유효하게 되었다. Chat Control 1.0은 지난 4월 이미 만료되었으나 2.0이 아직 합의되지 않았고 지난 3월 Chat Control 1.0의 연장안이 의회에서 부결되었지만 6월말 의장이 재검토 후 유럽 이사회로 회부했고 이를 의회로 다시 돌려보냈으나 거부 동의안이 절대 다수에 미치지 못하면서 통과되었다.(영어)
The 'Father of the Internet' is finally retiring : TCP/IP를 개발해서 인터넷의 아버지라고 불리는 Vinton Cerf가 구글에서 부사장 겸 Chief Internet Evangelist로 2005년부터 근무했지만 이 직책에서 물러나 은퇴하게 되었다.(영어)

프로젝트

MemNixFS : Linux 메모리 덤프를 파일 시스템으로 마운트해서 기존 도구로 조사할 수 있게 하는 프로젝트.
Agentic Inbox : Cloudflare의 인프라를 이용해서 웹 인터페이스를 통해 이메일을 보내고 받고 관리할 수 있다.
Maestro : 모바일 UI 테스트 도구
Cloudflare Drop : 폴더나 Zip 파일을 드래그앤 드롭해서 올리면 Cloudflare에 바로 배포해준다.
nose : 중복 코드를 찾아주는 CLI
Orca : 에이전트에 최적화된 IDE
Capsomnia : 캡스락을 키면 맥북을 켜진채로 유지하게 하는 앱

버전 업데이트

TypeScript v7.0 : Microsoft가 만든 JavaScript transpiler, 릴리스 공지
- Go로 포팅해서 10배 빨라진 새 버전
podman v6.0.0 : 컨테이너 엔진, 릴리스 공지
npm v12.0.0 : Node.js 패키지 매니저, 릴리스 공지
sbt v2.0 : Scala 빌드 도구, 릴리스 공지
TinyBase v9.0 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지
Zed v1.10 : 코드 에디터, 릴리스 공지
Antigravity CLI v1.1.0 : 코딩 에이전트, 릴리스 공지
Upyo v0.5.0 : Node.js, Deno, Bun용 이메일 라이브러리, 릴리스 공지
GraalVM v25.1 : 통합 가상 머신, 릴리스 공지
Node.js v26.5.0 : 자바스크립트 런타임, 릴리스 공지
Expo SDK v57.0.0 : React로 네이티브 앱을 만드는 플랫폼 SDK, 릴리스 공지
Ant Design v6.5.0 : React 디자인 컴포넌트, 릴리스 공지
etcd v3.7.0 : 분산 키-밸류 스토어, 릴리스 공지
Electron v43.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
ESLint v10.7.0 : JavaScript 코드 분석 도구, 릴리스 공지
Rust v1.97.0 : 프로그래밍 언어, 릴리스 공지
Module Federation v2.8.0 : 자바스크립트 애플리케이션의 아키텍처 패턴, 릴리스 공지
Vue Router v5.2.0 : Vue.js의 라우팅 라이브러리, 릴리스 공지
Rolldown v1.2.0 : JavaScript/TypeScript 번들러, 릴리스 공지

시스템 엔지니어링

2026-07-07T08:58:22+09:00

시스템 엔지니어라는 역할을 새롭게 맡게 되었습니다. 그 동안 소프트웨어 개발에 집중해 왔는데, 이제 더 넓은 관점에서 다양한 파트의 일들을 접하게 될 것 같습니다. 회사 면접에서 시스템 엔지니어링과 관련된 짧은 발표를 요청받았는데 발표를 준비하며 시스템 엔지니어의 중요한 역할에 대한 생각을 정리해 보았습니다.

1. 팀이 미션을 이해하도록

시스템 엔지니어링의 시작은 우리의 미션을 구체적인 언어로 정의하고, 이를 모든 이해관계자들과 공유하는 일이라고 생각합니다. 개발 조직이 미션을 이해하는 충분한 과정 없이 시스템을 개발해 나가면 중요한 기술적인 결정의 순간에 목적에 벗어나는 결정을 하기 쉽습니다. 시스템의 요구사항은 초기에 완전하게 정의되지 않고, 여러 설계 결정사항들도 프로젝트를 진행하며 결정되는데 이때 미션에 대한 이해는 여러 결정의 순간 우리가 길을 잃지 않도록 돕는 등대와 같은 역할을 합니다. 시스템 엔지니어는 개발조직이 미션에 대해 잘 이해하고 스스로 목표를 달성하기 위한 올바른 결정을 할 수 있는 토대를 만들어 주어야 합니다.

2. 사용자의 필요를 공학적인 요구로 재해석하기

사용자의 요구사항은 그대로 엔지니어링 영역에 와 닿을 수 없습니다. 사용자는 순수한 필요를 말하지만 엔지니어는 그것을 구현하는데 여러 제약사항을 가집니다. 따라서 시스템 엔지니어는 사용자의 필요를 공학적인 제약사항 위에서 공학적인 요구로 재정의 할 수 있어야 합니다. 사용자의 언어와 엔지니어가 안고 있는 제약 사항을 함께 이해하여 둘이 공존할 수 있는 언어로 문제를 재정의 하는 것입니다. 시스템 엔지니어는 이를 통해 사용자와 엔지니어를 잇는 가교 역할을 합니다.

3. 테스트 가능한 요구사항

시스템 엔지니어는 요구사항을 정의하는 프로젝트 초기 단계부터 테스트 가능한 시스템을 고민합니다. 시스템을 어떻게 테스트할지 고민하는 과정은 반드시 요구사항을 구체적으로 정의하도록 유도합니다. 테스트 가능한 시스템을 고민함으로 불확실한 프로젝트의 건강한 초석을 다질 수 있습니다. 시스템 엔지니어는 프로젝트 전 과정에서 이 테스트에 대해 고민하고 실제 테스트 계획과 결과가 올바른지 점검도 합니다. 테스트에 대한 고민은 시스템 엔지니어링의 꽃이라고 부를 만큼 중요한 것이라고 생각합니다.

4. 안정적이지만 경제적인 결정하기

프로젝트는 무언가를 ‘결정’하는 일의 연속입니다. 이 모든 결정의 순간에 시스템 엔지니어는 안정적이지만 동시에 경제적인 것을 선택해 나가야 합니다. 경제적이라는 것은 프로젝트의 미션을 달성하는데 불필요한 것들을 찾아 제거하고, 반드시 필요한 것만 남기는 것이라고 다르게 표현 할 수 있습니다. 사용자들은 대게 프로젝트 초기에 자기가 원하는 것을 구체적으로 정의하지 못하는 경우가 많은데, 이로 인한 불안감으로 실제로 필요한 것보다 과도하게 무언가를 요구하는 경우가 있습니다. 시스템 엔지니어는 사용자의 상황과 목적을 잘 이해하고 그 필요를 세밀하게 분석하여 정말 필요한 것만 남을 수 있도록 사용자와 소통해야 합니다. 또한 시스템 엔지니어는 목적을 이루는 방법을 결정할 때 더 쉽고 확실한 방법이 없는지 자신과 조직에게 다시금 질문을 던져보아야 합니다. 한 번 더 생각해 보면 더 쉽고 확실한 해결책이 있을 때가 많습니다.

5. 조기 설계 검증

시스템 엔지니어는 핵심적이고 리스크가 높은 기능을 가능한 프로젝트 초기에 식별하고 설계 컨셉이 생각한 대로 동작하는지 시험하고 개선할 수 있는 구조를 만들어야 합니다. 일반적으로 시스템의 개발은 분석, 설계, 구현, 시험이라는 단계를 거치는데, 우주 분야의 제품은 이 단계들이 순차적으로 진행되는 경우가 많습니다. 그래서 프로젝트 막바지인 시험 단계에 설계 결함이 발견되면 이미 너무 많은 것들이 진행되어 문제를 해결하는데 비용이 과도하게 들거나, 어떤 경우에는 거의 불가능한 경우가 발생하기도 합니다. 시스템 엔지니어는 중요하지만 리스크가 높은 기능들을 조기에 식별하고 설계 단계부터 검증하여 적은 비용으로 수정할 수 있는 기회를 얻게 해야 합니다. 이를 통해 핵심적인 기능이 최종 완성품에서 실패하는 리스크를 크게 줄일 수 있습니다.

6. 인터페이스의 주인

소프트웨어 공학에는 ‘의존성 역전’이라는 설계 원칙이 있습니다. 위성 개발은 주관 기관을 중심으로 다양한 하위 기관들의 협력을 통해 만들어집니다. 이때 하위 기관들의 시스템 사이에 인터페이스 설계가 중요한 업무가 되는데, 주관 기관이 하위 시스템들을 잘 이해하고 적극적으로 인터페이스 요구사항을 내지 못한다면 하위 기관이 인터페이스를 주도해서 정의하고 주관 기관은 그저 하위 기관이 만들어 주는 대로 사용하는 의존 구조를 가지게 됩니다. 이렇게 되면 대게 주관 기관이 원했던 목적에 최적화된 인터페이스 설계가 이루어지지 못하고 프로젝트 후반부에 아쉬운 부분이 있더라고 이를 그대로 수용해야하는 결과를 가져오곤 합니다. 시스템 엔지니어는 서브 시스템들의 동작을 이해하고 인터페이스 설계에 적극적으로 참여하여 시스템의 인터페이스가 목적에 맞게 잘 설계 될 수 있도록 해야합니다.

7. 소통

위성 시스템은 기계, 광학, 전자, 소프트웨어 등 정말 다양한 파트의 전문가 그룹에 의해 개발됩니다. 그리고 그 모든 파트가 원활히 소통하며 한 방향으로 나아가지 못하면 프로젝트는 성공할 수 없습니다. 많은 사람들이 프로젝트가 실패하거나 큰 어려움을 겪는 이유가 조직의 기술적인 역량 부족 때문이라고 생각하지만, 실제로 프로젝트가 실패하거나 큰 어려움을 겪는 결정적인 이유는 소통의 실패에서 오는 경우가 너무나 많습니다. 시스템 엔지니어는 여러 파트들이 원활하게 정보를 교환하고 신속한 의사결정을 내리며 나아갈 수 있도록 그들 사이에 원활한 소통 채널을 만들고 소통을 주도해야 합니다.

제가 생각하는 시스템 엔지니어의 중요한 역할들에 대해 생각해 보았습니다. 저도 이것을 마음에 두고 앞으로 새로운 환경에서 잘 적응하고 조직에 꼭 필요한 일을 할 수 있도록 노력하겠습니다.

인프랩 AI 네이티브 9개월 정리

2026-07-13T09:31:48+09:00

사내 블로그에 지난 AX 경험기를 정리하려다가, 먼저 초안을 공유하고 그걸 본 분들이 궁금해하시는 내용 위주로 좀 더 보강하자는 생각에 초안을 먼저 공유합니다.
(아직 다 정리된 건 아니에요!)

AX 전환에 대한 인사이트를 나누는 글들을 보면, 정작 그 인사이트가 어떤 맥락과 환경에서 나온 것인지에 대한 자세한 설명이 부족한 경우가 많다고 느낍니다.
조직마다 규모, 예산, 인프라가 다 다른데 그 전제가 빠지면 좋은 인사이트도 내 상황에 그대로 옮기기 어렵습니다.

작은 조직일수록 AI 네이티브한 일하는 방식을 훨씬 빠르고 과감하게 실험해 볼 수 있다고 생각합니다.
실제로 그런 실험적인 시도를 앞장서서 보여주는 쪽은 인디해커나 소규모 스타트업인 경우가 많습니다.
다만 그 경험을 300명, 500명, 2,000명 규모의 조직에 옮기려면 조직 구조, 의사결정 방식, 인프라의 복잡도가 달라져서 손봐야 할 지점이 꽤 있을 겁니다.
반대로 큰 조직의 경험을 작은 조직에 그대로 옮기면 과한 프로세스가 되기 쉽습니다.
결국 어느 쪽 경험이든 규모가 다른 조직에 그대로 이식하기는 어렵고, 그만큼 서로의 맥락을 참고하는 게 중요하다고 생각합니다.

사업 규모나 형태도 다를 테고, 보안 레벨도 다르고, 사용할 수 있는 AI 플랜과 할당된 AI 예산도 다르기도 합니다.
(전해 들은 어떤 대기업 사례인데, 엔터프라이즈 플랜을 쓸 수밖에 없어서 월 15억을 AI 예산으로 잡았는데 40억 이상이 사용돼 AI 사용 전체를 재점검했다고 하더라고요.)
구축된 시스템 레벨, 연관된 저장소의 수, 크기, 흩어진 조직 맥락의 크기 등도 서로 너무 다릅니다.

그래서 어떤 조직의 여정이 공유될 때는 항상 그 조직의 맥락도 함께 봐야 한다고 생각하기 때문에 저희의 맥락을 먼저 이야기해 드립니다.

누적 가입자 수 165만 명, MAU 54만 명의 교육/채용 플랫폼인 인프런/랠릿 서비스를 운영하는 저희는 56명의 팀원이 함께하고 있습니다.
이 안에서 제품 조직은 26명, 운영/사업은 30명으로 운영되고 있으며, 각 제품 스쿼드는 4-6명으로 구성되어 있고, 요즘은 1-4인 스쿼드를 실험적으로 도입 중입니다.

엔지니어링 헤드, 데브옵스 팀장 등 명시적 리더 없이 CTO와 다이렉트로 일하고 있으며, 데브옵스 조직은 제 직속이고 각 스쿼드의 PM 분들이 매니저로서 일하고 있습니다.

비슷한 조직이시라면 도움이 되실 것 같고, 규모가 다르시다면 참고용으로만 보시면 좋을 것 같습니다.

저희 조직은 AI 도구를 작년 11월부터 본격적으로 사용하기 시작했습니다.
저희 팀의 경험을 돌이켜보면

1. 효율은 증명됐지만, 효과는 아직

AX를 통해 효율을 증명하더라도, 구체적인 일정 규모 이상의 회사의 성과를 달성했는지는 아직 시간이 필요한 것 같음.
"효율이 좋아진 것"과 "효과가 좋아진 것"은 다른 얘기임.
연매출 100억(거래액 말고 순매출) 이상 규모에서 AX로 50%, 100%, 200% 성장했다는 회사는 주변에서 못 봤음.
이 규모에서 지금까지 증명된 건 "예전 성과를 더 적은 사람으로 낼 수 있다"까지고, "더 큰 성과를 낸다"는 사례는 아직 못 봤음.

2. 형식지가 먼저, 자동화는 그다음

"A->B->C로 일하면 100의 성과를 낼 수 있다"처럼 어떤 방식으로 하면 어느 정도 성과가 난다는 형식지가 이미 구축되어 있으면, AI가 빠르게 자동화하고 효율을 높이는 데 도움을 줌.
다만 500의 성과를 한 번도 내 본 적 없는 조직이 AI로 500을 내는 건 아직 어려워 보임.
(테슬라 모델 3 사례가 그랬음.
초기에 완전 자동화를 밀어붙였다가 생산이 막혔고, 머스크도 2018년 4월 "과도한 자동화는 실수였다. 정확히는 내 실수다. 인간은 저평가됐다"고 인정함.
이후 로봇이 좌석을 옮기기만 하고 나사 조립과 배선은 사람이 마무리하는 식으로 공정을 다시 나눴음.
머스크가 나중에 정리한 원칙인 "요구사항에 의문을 제기하고, 불필요한 단계를 지우고, 단순화하고, 속도를 높인 다음 마지막에 자동화하라" 도 결국 검증 안 된 프로세스부터 자동화하면 실패한다는 같은 얘기임.)

3. 동기부여가 관리 대상

AI로 성과를 더 내기 위해서 관리해야 할 대상은 동기부여임.
의지 없는 팀원에게 AX 하라고 하면 딱 시키는 대로만 AI를 씀.
회사가 정해 놓은 규칙대로만 쓰고, 결과는 책임지지 않음.
리더가 시키는 대로는 다 했으니까.
근데 이러면 AI는 최악의 도구가 됨.
AI는 비결정적 도구라서 세 번, 다섯 번 한다고 원하는 결과가 나온다는 게 보장 안 됨.
즉 능동적인 사람에게는 유효하지만 수동적인 사람에게는 전혀 도움이 안 됨.
회사가 빡빡한 가이드라인을 만들면 결국 구성원들은 그 가이드대로 시키는 대로만 하는데, 원하는 결과가 안 나올 때 더 주도적으로 방법을 바꿔가며 노력해야 하는 게 거의 불가능해짐.
결국 요즘 시대에 리더에게 가장 요구되는 것은 팀원들의 동기부여임.

4. 같은 AI를 쓰는 기업간의 경쟁

돈만 내면 누구나 최고급 모델(Fable 5, GPT 5.6 xhigh 등)을 쓸 수 있다면, 조직 간 경쟁력과 해자는 뭐가 될까 고민하게 됨.
잊으면 안 되는 건, 이게 인간 vs AI 경쟁이 아니라 "같은 AI 도구를 쓰는 조직 대 조직" 의 경쟁이라는 점임.
경쟁사도 나랑 똑같은 도구를 쓰는데, 그럼 우리는 뭘로 격차를 벌리고 경쟁력을 키우느냐가 남는 질문임.
같은 도구를 쓴다고 같은 결과물이 나오지 않는다는 건 다들 이미 알고 있음.
결국 예전과 비슷하게, 그 도구를 쓰는 조직 구성원의 역량, 그리고 그 역량을 채용하고 키워내는 조직의 미션, 비전, 문화, 프로세스가 경쟁력이 됨.

5. 더 낮은 모델을 가지고 경쟁해야한다면

그런데 최근 보면 "돈만 내면 누구나"라는 전제 자체가 흔들리고 있긴 함.
Fable 5 같은 최고급 모델이 정액제에서는 못 쓰고 종량제에서만 쓸 수 있게 바뀌는 중임.
지금까지는 작은 회사가 팀플랜이나 개인 정액제로 거의 무한에 가까운 토큰을 아주 저렴하게 쓰고, 큰 회사는 엔터프라이즈 플랜을 쓸 수밖에 없어서 인당 200-300만 원씩 지원하면서도 개인당 토큰량은 Max 5x에도 못 미치는 경우가 있어서, 오히려 이 영역이 작은 회사가 가지는 경쟁력이였음.
근데 최고급 모델이 정액제에서 빠지면 얘기가 달라짐.
종량제 비용을 감당할 수 있는 회사와 감당하지 못하는 회사로 나뉘게 됨.
즉, 고급 모델을 쓰는 회사 vs 중-저급 모델을 쓰는 회사의 경쟁 구도도 가능함.
이 격차는 더 벌어질 것 같음.
(팀플랜도 결국 종량제로 바뀔까 걱정임.)
즉 구성원 역량 격차에 더해 모델 접근성 격차까지 새로운 경쟁 축으로 얹히는 셈임.

우리가 갖고 있는 많은 전제에서 "모델이 계속 발전하는 것" 을 우리 모두가 "충분히 사용" 할 수 있다는 전제위에서 AI 네이티브 논의가 많은데,
우리 회사가 그 좋은 모델을 쓸 수 있는 여력이 있는가,
쓸 수 있다고 해도 얼마나 많이 사용할 수 있느냐,
이에 따라 회사의 운영 방식이 크게 달라짐.

우리가 사용중인 월 $125의 프리미엄 시트, 월 $200의 Max 20x에서는 Fable과 같은 고급 모델을 사용하지 못하고, 대기업 혹은 그에 준하는 큰 투자를 받은 회사들에서는 그걸 적극적으로 쓴다면 무엇으로 경쟁할 것인가? 라는 질문이 남음.

타사보다 낮은 모델을 사용하면서도 타사와 경쟁한다면, 우리는 무엇을 해야 할까? 같은 고민을 시작하게 됨.

최근 로이터가 소식통을 인용해 보도한 바에 따르면, 중국도 Qwen, Doubao, GLM 5.2 같은 자국 플래그십 모델의 해외 접근 제한을 검토 중이라고 함. 아직 논의 단계일 뿐 결정된 건 없고, 시행 여부와 시점, 이미 해외에 풀린 기존 모델까지 소급 적용될지도 전부 불투명한 상태임. 낯설지 않은 패턴인 게, 작년 미국도 앤트로픽의 최상위 모델 Fable과 Mythos에 대해 외국인 접근을 차단하라고 명령했고, 그 여파로 앤트로픽이 전 세계 모든 사용자를 대상으로 두 모델을 일시 비활성화한 적이 있음(이후 Fable은 안전장치를 보강해 전체 사용자에게 복원됐지만, Mythos는 여전히 미국 내 일부 신뢰 기관으로만 제한돼 있음). 결국 모델 접근성 격차는 이제 가격 문제만이 아니라, 그 모델이 어느 나라 소속이냐는 지정학적 요인으로도 벌어질 수 있다는 얘기임.

[지적 자산]

6. 쌓아온 데이터 == 퍼포먼스

그동안 팀이 어떤 데이터를 쌓아 왔느냐에 따라 퍼포먼스 차이가 많이 남.
팀 컨벤션 문서가 이미 관리되고 있는지, 테스트 코드를 이미 작성하고 있는지, Jira나 컨플루언스 등에 의사결정 과정을 계속 기록해두고 있는지 등, 팀의 암묵지와 형식지가 얼마나 쌓여 있느냐에 따라 결과가 다름.

7. 모든 사내 회의 녹음부터

회사의 암묵지가 뭔지조차 모르겠다면, 모든 사내 회의를 녹음하는 것부터 시작하면 좋음.
문서로 정리된 것들에는 결과와 후속 액션 정도만 남고, 회사의 진짜 암묵지, 지적 자산은 "의사결정 과정" 그 자체임.
구글의 아키텍처 결정 레코드처럼 의사결정 과정 자체를 기록으로 남기는 프레임워크가 있어야 함(여기서 프레임워크는 특정 기술을 의미하는 게 아님).
그때 왜 그런 의사결정을 내렸는지 맥락이 남지 않으면, 조금만 응용된 상황이 와도 성공 경험을 전혀 활용하지 못하고 전혀 다른 의사결정이 나오게 됨.
그러면 AI도 완전히 다른 맥락을 갖게 됨.

8. AX는 전담인력을 팀 안으로

녹음 말고 암묵지를 형식지로 만드는 또 다른 방법은, 전담 인력을 그 팀 안에 제대로 밀어 넣고 한 팀으로 일하게 하는 것임.
그 인력이 옆에서 팀원들이 일하는 걸 보면서, AI가 참고할 수 있는 형식지를 계속 뽑아내게 하는 방식임.

[도구]

9. KB(Knowledge Base), MCP, FDE

전사 업무 생산성을 크게 높여준 건 KB(Knowledge Base), 각종 MCP(아틀라시안, 구글 캘린더, 지메일, 빅쿼리, 믹스패널, 데이터독, 깃허브), FDE의 침투(백엔드 엔지니어 한 명이 마케팅 팀 소속의 AX 엔지니어로 옮겨서 일하는 것)였음.

10. 전사 AI 도구는 하나로 통일

AI 도구는 파편화하지 않고 단일 도구로 통일하는 게 좋음. Claude, OpenAI, Gemini 등을 다 같이 쓰게 하기보다는, 전사 AI 도구는 이걸로 간다고 하나를 확정하고 그 안에서 개개인의 노하우를 공유하면 다 같이 효과를 보는 형태로 가야 함.
도구가 파편화되면 노하우도 분산됨.
예전에는 각자 자기한테 가장 잘 맞는 도구를 쓰게 뒀는데, 노하우를 한곳에 모으는 것보다 개개인에게 맞는 도구를 쓰는 게 전체 합이 더 컸기 때문임.
그런데 AI는 가능성과 확장성이 거의 무한대라 한계효용의 법칙이 잘 안 통함.
그래서 수십에서 수백 명이 하나의 도구를 쓰면서 플러그인, 스킬, MCP, 프롬프트 가이드 같은 노하우를 거기에 집중시키는 게, 개개인 입맛에 맞는 도구를 따로 쓰게 하는 것보다 훨씬 나은 조직 성과를 냄.

11. LLM 성능보다 문서 도구의 검색 품질

MCP를 연결해도 문서 탐색은 결국 문서 도구의 검색 결과에 의존함.
LLM이 전사 데이터를 다 들고 있는 게 아니라, 우리가 자연어로 질의하면 그걸 문서 도구의 검색 스펙에 맞는 조건으로 바꿔서 대신 호출하는 구조임.
그러니 아무리 데이터를 연결해도, 내가 찾는 그 데이터를 실제로 가져오는 건 LLM 성능보다 문서 도구의 검색 품질이 더 중요함.
그래서 검색 품질이 좋은 도구를 써야 하고, 잘 지원되는 문서 도구에 사내 문서와 데이터를 모아둬야 함(아틀라시안 제품 등).

[인프라]

12. 버전 관리부터

AI 환경에서 가장 안전한 방법은 데이터와 환경을 버전 관리가 되도록 관리하는 것임.
즉 Git을 도입해야 함. 회의록, PRD도 버전관리가 되는 환경에서 작성돼야 함.
AI는 비결정적 도구라 여러 번 작업한다고 항상 더 나은 결과가 나온다는 보장이 없고, 잘못 실행돼서 결과물이 날아가는 경우도 많기 때문임.
git 도입이 어렵다면 최소한 전사 문서 도구만큼은 항상 버전 관리가 되는 걸 써야 함.

13. IaC & GitOps

IaC & GitOps를 꼭 구축하기를 권장함.
GitOps 환경이 되면 개발팀이 인프라팀에 Jira 티켓으로 요청하는 대신 PR로 직접 인프라를 바꾸고 인프라팀은 리뷰만 하면 돼서, 요청 하나하나의 세부 맥락을 인프라팀이 다 짊어지는 부담이 크게 줄어듦.
본인이 Pulumi로 인프라를 직접 수정해보고 테스트 코드를 돌려서 깨지는 게 있는지 확인하고, 인프라 수정이 올라올 때 AI가 리뷰해서 코멘트를 남기는 도구까지 갖춰지고 나면 이런 환경이 주는 심리적 안정감과 속도감은 차이가 큼.
(물론 이건 리소스 설정값 수준의 검증이고, 실제 클라우드 동작까지 확인하려면 별도 통합 테스트가 필요함.)
롤백도 쉬움.
비슷하게 데이터베이스 테이블 관리도 flyway 같은 마이그레이션 도구의 필요성이 예전부터 강조돼 왔지만, 이젠 그게 더 커짐.
버전 관리가 가능한 데이터여야 AI가 의도와 맥락을 이해하고, 혹시 AI가 실수해도 되돌아가서 수정할 수 있음.

[보안]

14. AISecOps

DevSecOps가 대두되듯이 AISecOps도 필요하다고 느낌. DevOps 시대가 오면서 개발과 운영을 함께 보는 문화가 됐는데, 그 안에서 보안팀이 결국 병목이 되는 문제가 있음.
"덮어놓고 안 된다고만 하면 오히려 음지에서 AI를 쓰게 되고, 이게 더 큰 문제를 만듦".
팀의 생산성과 변화는 충분히 주면서 보안도 챙기려면, 보안팀이 AI를 더 잘 이해하거나 AI를 쓰는 사람이 보안을 공부하거나 둘 중 하나는 해야 함.
AI와 보안이 따로 있고 책임이 분리되어 있으면 서로 자기 시야로만 프로세스를 세우게 되는데, 이게 문제를 더 키움.
우리 팀은 원래 데브옵스가 보안을 같이 책임지는 구조라 AI도 이 조직을 중심으로 두고, 데브옵스와 AI와 보안을 한 조직에서 관리함. 편하게 쓰고 싶은 마음과, 최소한 지켜야 할 선이 어디까지인지는 항상 같이 고민할 수밖에 없음.

15. 개인 구독 AI 도구 금지

토큰 비용이 아깝다고 AI 도구를 개인 계정으로 쓰게 해서는 안 됨.
클로드는 팀플랜(150명 이하)에서 정액제로 지원하니까 최대한 이 플랜부터 활용해야 함.
보안팀이 관리하지 못하는 형태로 AI를 쓰게 해서는 안 됨.
MCP를 통한 보안 사고가 너무 많아서 사내에서 화이트리스트로 MCP를 관리해야 하고, 특히 사내 데이터 접근을 AI에 열어줄 거면 절대 개인 계정에 열어두는 방식으로 가면 안 됨.

16. AI Proxy 게이트웨이

LLM API는 항상 AI Proxy 게이트웨이를 통과하도록 구축해야 함.
기존 API 모니터링은 요청 수(count) 기반으로 이상 패턴을 감지하고 알림을 보내고 추적했는데, AI API는 요청 수가 같아도 토큰 사용량에 따라 비용이 천문학적으로 차이가 날 수 있어서 count만 보는 기존 방식으로는 이 비용 이상을 못 잡음.
그래서 로깅, 알림, 모니터링을 토큰/비용 기준으로 따로 구축해야 하고, 이걸 하려면 중간에 게이트웨이가 필수적임.
구축된 것과 아닌 것의 차이가 큼.
서비스 개발 단계뿐 아니라 실제 서비스에서 나가는 AI 호출도 어디서, 얼마나, 왜 이렇게 나가는지 트래킹해야 함.

17. 구글 워크스페이스를 Primary 계정으로

구글 워크스페이스 계정이 사내에서 사용하는 서비스들의 Primary 계정이자 권한 단위가 되는 게 맞는 방향인 것 같음.
AI 도구, AWS, 데이터독, 아틀라시안, VPN(Tailscale) 등 대부분은 구글 워크스페이스를 SSO/IdP로 붙일 수 있음.
이후 결국 그 팀원에게 수많은 사내 서비스들의 권한이 어떻게, 어디까지 할당되어 있느냐를 추적/관리하기 위함임.

18. DB 접속은 IAM 임시 자격 증명으로

DB 접속 정보는 정적인 id/pw가 아니라 IAM 기반의 임시 자격 증명으로 관리해야 함.
Secrets Manager 자동 로테이션도 좋지만 그건 오래 사는 비밀번호를 주기적으로 교체하는 것이라, 유출되면 다음 로테이션까지 몇십 일을 살아있고 앱 메모리나 환경변수 어딘가에 항상 정적인 값으로 존재해서 AI 에이전트에게 DB를 열어줄수록 그 값이 그대로 유출 경로가 됨.
반면 RDS나 Cloud SQL의 IAM DB 인증은 접속할 때마다 15분짜리 토큰을 새로 발급받는 방식이라 저장해 둘 비밀 자체가 없고, 사람/서비스/에이전트별로 계정을 쪼개 권한을 좁힌 뒤 사고가 나면 전체 로테이션 없이 그 주체의 IAM 정책만 떼서 몇 초 만에 끊을 수 있음.
다만 지원 엔진이 제한적이고 신규 커넥션이 아주 많은 워크로드엔 부담이라, IAM 인증이 안 되는 DB는 Secrets Manager 자동 로테이션이 차선임.

19. 환경변수는 별도 저장소에서 런타임 주입

모든 환경변수도 버전관리, 수정 이력, 권한 관리가 가능한 별도의 private 저장소에서 관리하고 런타임에 가져오는 구조로 가야 함.
코드 저장소에 그대로 박아두거나 개인 메모, 메신저로 공유하면 누가 언제 무엇을 바꿨는지 추적도 안 되고 권한 회수도 안 됨.

20. 데이터는 권한 관리가 되는 DW로

AI를 통해 누구나 자연어로 쉽게 비즈니스, 퍼널 데이터를 보게 만들고 싶다면 계정 단위로 테이블/컬럼 권한 관리가 가능한 도구에 데이터를 모아야 함.
예를 들어 빅쿼리 같은 전문 DW(데이터 웨어하우스) 도구.
단순히 조회용 RDB를 연결하는 방식도 있지만, 개인정보나 민감 정보를 컬럼/계정 단위로 세밀하게 막으려면 계정마다 개별 GRANT를 반복해야 해서 수백 명 규모로는 관리가 너무 복잡함.
조회용 RDB보다 빅쿼리 같은 전문 DW 도구가 유리함.
구글 계정과 바로 통합되고 정책 하나(정책 태그)로 여러 테이블에 걸쳐 컬럼 단위 접근을 관리할 수 있고, 행 단위 보안도 지원함.
DB 테이블, 마케팅 데이터(믹스패널 등), 프로덕트 릴리즈 데이터(서비스 출시 기록, DORA 메트릭 등)가 빅쿼리에 모여있고 계정 단위로 권한 관리까지 되면, MCP로 연결한 뒤 예전부터 이야기하던 "데이터가 흐르는 조직"을 AI의 도움으로 가능하게 할 수 있을 것 같음.
단, 온디맨드 과금은 쿼리가 스캔하는 데이터 크기만큼 부과되는 구조라 로그성 데이터까지 모두 담으면 비용이 늘 수 있음.
정액형(Editions/슬롯 예약) 과금이나 파티셔닝, 클러스터링으로 스캔량을 줄이는 방법을 함께 고려하는 게 좋음.

21. 해커도 AI를 씀

해커도 AI를 사용하고, AI와 함께하는 해커는 우리가 쓰는 범용 AI보다 더 뛰어나다는 점을 잊으면 안 됨.
데이터독 같은 모니터링 도구를 잘 활용하면, 장애 로그를 AI가 분석해서 문제 해결 코드를 만들고 PR까지 올리는 과정을 자동화할 수 있음.
다만 브라우저나 앱 같은 클라이언트 사이드 에러를 수집하는 SDK를 통해 오히려 공격이 들어오는 경우가 있음.
2026년 6월 공개된 사례가 그런 경우인데, 정확히는 SDK 자체의 결함이 아니라 공개된 에러 수집 키에 조작된 데이터를 주입하고 AI 코딩 에이전트가 MCP를 통해 그걸 신뢰할 수 있는 지시로 착각해서 실행하는 방식임.
(예: 관련 사례)
버그 수정까지 사람 개입 없이 완전 자동화하겠다는 건 둘 중 하나임.
우리 서비스가 해커 입장에서 공격할 만한 가치가 없을 만큼 작거나, 보안팀이 완벽하게 다 막아주고 있거나.
여러 모니터링 도구를 MCP로 연결해서 개발자가 버그를 쉽게 해결하도록 효율화하는 건 좋지만, 사람이 전혀 개입하지 않는 방향으로 완전히 넘어갈 수는 없음.
특히 프론트엔드는 UI 변경이 잦아서 자동화해도 괜찮을 거라 생각하기 쉬운데, 그러다 큰일 날 수 있음.
깃헙 저장소의 시크릿이나 CI 환경 같은 인프라가 백엔드와 프론트엔드로 완전히 격리돼 구현되는 경우가 거의 없어서, 프론트엔드 프로젝트가 오염되면 서비스 전체가 영향을 받을 수 있음.

[마치며]

쓰고 나서 다시 읽어보니 새로운 이야기가 많지 않습니다.
문서화, 테스트 코드, 버전 관리, 권한 관리처럼 예전부터 중요하다고 하던 것들이 대부분입니다.
"피닉스 프로젝트"와 "유니콘 프로젝트"가 그리던 암묵지의 문서화와 병목 없는 보안, 데이터가 흐르는 조직, "코드로 인프라 관리하기"가 말한 버전 관리와 IaC, "Release의 모든 것"이 말한 사람의 개입 지점을 남겨둔 자동화는 전부 AI가 나오기 전부터 있던 이야기입니다.
지난 9개월 동안 저희가 확인한 것도 그 이야기들이 AI 시대에 여전히 유효하고, 몇몇은 더 절실해졌다는 것이었습니다.
그래서 지난 9개월은 AI 도구를 배우는 시간이기도 했지만, 미뤄뒀던 숙제들을 더는 미룰 수 없게 된 시간에 가까웠습니다.

2026 Devchat Night+ 세미나 후기

2026-07-10T09:03:31+09:00

일시: 2026년 7월 7일(화)
장소: HAESO 해소 (서울 성동구 성수이로24길 31)
주최: Devchat

Why We Gather

김경환 (네이버), 김상기 (SK텔레콤), 이동현 (카카오페이)
진행: 황국화

Q. 지금까지 가졌던 데브챗 모임 중 가장 기억에 남는 모임은?

이동현 (카카오페이)

장소로는 엘타워가 가장 먼저 떠오름 - 롯데 이커머스 후원으로 열린 모임
- 전망 좋은 곳에서 일하는 기분에 대한 생각, 분위기가 좋았던 기억
최근에는 배민(우아한형제들)에서 함께한 모임도 기억에 남음
장소보다 기억에 남는 자리는 내부 팀장들이 모여 발표했던 시간
- 서로 다른 회사에서 일하며 얻은 좋은 점과 고충을 나누며 공감대를 형성

김상기 (SK텔레콤)

2023년 데브챗 모임 시작 이후 매달 스터디 형태로 진행하다가, 그해 12월 연 데브챗 컨퍼런스가 가장 기억에 남음
2024년에는 데브챗 멤버들과 함께 책을 집필 - 코드 너머, 회사보다 오래 남을 개발자 (한빛미디어, 2025년 출간)

김경환 (네이버)

2023년 1월 팀 리더를 맡게 되면서 개발 문화/조직 문화에 대한 관심으로 데브챗 스터디에 참여
첫 세션은 온라인(Zoom)으로 진행, 다소 낯설었지만 그때 받은 영향력 덕분에 지금까지 애정을 갖고 참여 중

Q. AI 시대에 오프라인 모임/커뮤니티가 갖는 힘은 무엇인가?

김상기 (SK텔레콤)

"여러분은 오늘 왜 오셨나요?"
사람을 만나면 상대에게 먼저 관심을 갖는 습관은 과거 코칭 활동에서 비롯됨

이동현 (카카오페이)

연결의 소중함 - AI와 연결하는 것보다 사람과 연결하는 게 중요해서 이 모임이 더 소중하게 느껴짐
데브렐은 원래 개발자와의 연결을 다루는 일이었는데, AI 시대에는 비개발자도 개발자와 같은 역할을 할 수 있게 되면서 개발자/비개발자 구분 없이 "만드는 사람들"과 연결되는 게 중요해짐
비슷한 고민을 하는 사람들끼리 연결돼 생각을 확장해 나갈 수 있는 기회라는 점에서 오프라인 모임이 소중함

김경환 (네이버)

커뮤니티에 모이는 가장 큰 힘은 관계에서 오는 동기
각자의 고민을 나누다 공통점을 찾고, 관계가 점점 따뜻해지면서 커뮤니티의 온기로 나타남
데브렐이라는 주제를 벗어나 실제 회사 업무, 살아가는 이야기까지 나누게 되는 점이 좋음

Q. 회사에서 진행 중인 AX와 데브렐은 어떤 관계인가?

김상기 (SK텔레콤)

AX는 결국 AI를 잘 이해하게 만드는 일 - AI를 다루는 데 가장 능숙한 건 개발자
비개발자가 개발자들이 쓰는 용어를 익히게 만드는 것이 관건 - 그래야 AI에게 원하는 걸 제대로 시킬 수 있음
본인이 속한 전사 HR 조직은 대부분 비개발자
- Claude, GPT 등 AI 도구를 쓰다 개발자 용어에 막히면 그걸 잘 아는 개발자와 연결해주는 역할을 함
데브렐이 개발자 간 관계를 만들던 일을, AX 시대에는 비개발자를 개발자로 연결/성장시키는 일로 확장해서 하고 있음 - 결과적으로 AX 팀은 데브렐과 협업할 수밖에 없는 구조
본인도 AX 팀에 합류했고, 전사/사업부별로 AX 조직이 계속 늘어나는 추세

Q. 데브챗 모임에서 나눈 이야기가 실무에 도움이 된 적이 있는가?

이동현 (카카오페이)

모임마다 기록을 남겨 참석자들에게 공유하고, 사내에도 별도로 기록해 둠
특정 사례를 콕 집어 말하긴 어렵지만, 쌓인 이야기들이 업무 어딘가에 반영되는 느낌을 받음
다른 회사의 이벤트/행사 기획 사례를 들으며 "언젠가 써먹어야지" 하고 아이디어를 얻은 경우가 많음

Q. 데브챗을 가장 잘 설명하는 키워드는 "집단지성"과 "심리적 안정감" 중 무엇인가?

김경환 (네이버)

앞서 말한 "온기"와 이어지는 맥락
- 심리적 안정감 쪽이 더 잘 맞는 표현
안정감 있는 관계 안에서 집단지성도 좋은 형태로 나온다고 생각

이동현 (카카오페이)

둘 중 하나를 고르고 싶지 않음, 둘 다 중요
훌륭한 발표자를 섭외해 이야기를 듣고, 이후 네트워킹으로 서로 회사 사례를 비교하며 아이디어를 나누는 과정에서 집단지성을 느낌
회사 안에는 데브렐 역할을 하는 사람이 몇 없어 고민을 나눌 곳이 마땅치 않은데, 데브챗에 오면 다양한 연차/직무/회사의 사람들이 모여 있어 여러 아이디어가 촉발됨

김상기 (SK텔레콤)

집단지성은 AI 때문에 오히려 약해지고 있다고 생각
심리적 안정감은 프라이빗 모임이기 때문에 가능
- 회사 안에서 못할 이야기도 나눌 수 있고, 밖에서 있었던 일이라 발설 부담이 없음
데브챗에서 얻는 정보는 AI나 책에서는 구할 수 없는 정보라 집단지성 역시 유효 - 결국 둘 다에 해당

Build Mode, AX in Reality - AI Native 개발문화 정착을 위한 기술리더들의 고군분투기

박성우 (한국디지털에셋), 박용권 (당근마켓), 서동민 (두들린)
진행: 강상윤 (야놀자)

Q. AI를 도입하면서 계획과 실제가 달랐던 점, 겪었던 시행착오는?

서동민 (두들린)

올해 초부터 본격 도입, 그 전에도 GPT-4o 즈음부터 조직 내에서 조금씩 실험
세상이 변하는 속도를 빠르게 못 따라간 것이 가장 후회되는 지점
처음 만든 건 단순 요약 기능이었는데, 당시엔 "이것도 잘 못한다"며 AI를 부정적으로 봤음
- 지금 보면 AI를 보는 눈높이 자체를 너무 낮게, 제한적으로 잡았던 것이 아쉬움

박성우 (한국디지털에셋)

AI로 인한 변화를 미리 예상하려 하지 않음
- "바이브"라는 말이 처음엔 유치하다고 생각했다가, 어느 순간부터 이 시대의 흐름을 가장 잘 표현하는 단어라고 느낌
그래서 바이브에 몸을 맡기고 바이브를 타는 게 가장 편했음

박용권 (당근마켓)

작년 2월 클로드 코드 출시 이전부터 AI와 일함, 이후로는 에이전트와 함께 일하는 게 일상화된 지 1년 반 이상
기대와 달랐던 점은 "생각보다 그렇게 빨라지지 않았다"는 것
무언가를 만드는 행위 자체는 압도적으로 줄었지만, 문제를 발견하고 검증 가능한 해결책으로 바꾸는 사고 과정, 디자인 영역은 아직 AI가 크게 못 함

Q. AI를 잘 쓰는 엔지니어들의 특징이나 패턴은?

박용권 (당근마켓)

한계를 스스로 정해두지 않고 "될 때까지" 끝까지 시켜보는 사람이 잘 씀
최근엔 출근해서 미팅/계획을 짜고 퇴근 전 AI에게 작업을 맡긴 뒤, 다음 날 아침 결과물을 확인하는 식으로 거의 24시간 활용하는 구성원도 있음

박성우 (한국디지털에셋)

한계를 두지 않는 사람, 업무 영역 경계에 얽매이지 않는 사람이 좋은 성과를 냄(개발자인데 디자인에도 관심, 백엔드인데 프론트도 시도 등)
다만 빠르고 과감한 초기 성과 이후에는 결국 책임감과 기본기가 탄탄한 사람이 진짜 의미 있는 제품을 만듦

서동민 (두들린)

테크(개발자)와 No테크(비개발 직군)를 나눠서 설명
개발자 쪽에서는 모호한 요구사항을 구체적 목표와 작은 테스트 단위로 쪼개고, 각 단위가 어떤 결과물에 도달해야 완성인지 정의하는 능력
- 추상적인 것을 구체적/정량적 표현으로 바꾸는 "문제 구체화 능력"이 뛰어난 사람일수록 AI 결과물이 의도한 것과 일치
비개발 직군 쪽에서는 결국 시도하는 능력
- 전사적으로 "전부 다 AI로 만들어보시라"고 독려 중인데, "이거 만들 수 있나요?"라고 물으러 오면 일단 AI에게 직접 시켜보고 안 되면 그때 다시 오시라고 안내
- 그렇게 하면 대부분 결과물이 나옴
한번 도전해보고 안 되면 왜 안 되는지 파악하면서 끊임없이 도전하는 사람이 성과를 냄

강상윤 (야놀자, 진행)

하나 덧붙이면, 회사에서 AX 프로젝트를 많이 해본 경험상 AI를 활용하지 않던 시대에도 지금도 공통적으로 잘하는 엔지니어의 특징은 직군과 스택을 넘어 공유를 잘하는 사람
- 이런 사람이 항상 회사에서 더 많은 가치를 만들어냄

Q. AI 시대, 연차(주니어/시니어/팀장급)별로 어떤 방향으로 성장하면 좋은가?

서동민 (두들린) - 주니어 대상

예전엔 책이나 강의로 먼저 공부한 뒤 회사 문제에 적용했다면, 이제는 책/강의 없이 회사에서 가장 어려운 문제부터 풀어보라고 제안
풀다가 모르는 게 나오면 AI에게 계속 물어보면서 새로운 개념을 확장해 나가는 방식으로 자연스럽게 성장 가능

박용권 (당근마켓) - 시니어 대상

"짬(연차)으로 밀어붙이는 시니어"는 이제 의미가 없음
- 1, 2년 전 본인이 작성한 코드 퀄리티를 지금은 2, 3년 차 엔지니어도 쉽게 재현
코드 레벨보다 앞으로 "어떤 방향으로 뾰족하게 성장할지"에 초점을 맞춰야 함
- 프로덕트 엔지니어냐 플랫폼 엔지니어냐 등 일하는 영역에 따라 AI 시대에 기대받는 전문성이 조금씩 다름
최근 인상적이었던 것은 오픈AI 코덱스 팀이 엔지니어에게 기대하는 역량으로 "프로덕트 취향(product taste)"을 정확하게 짚은 것
- 이 시대에 어떤 문제를 해결해야 할지, 어떤 취향을 담아 고객에게 전달해야 우리 제품을 쓰게 할지 고민할 수밖에 없는 시대(토스도 2, 3년 전에 했던 말이고, 꽤 많은 조직이 해온 이야기지만 지금 와서 훨씬 중요해짐)
(진행자의 "목적 조직을 어떻게 리드하는가" 추가 질문에) 특정 목적 조직 외에도 여러 조직을 겸하고 있음. 제품 리뷰/기술 리뷰/운영 이슈 등 방향을 정하는 흐름으로 조직을 리드하며, 예전엔 테크 직군과 주로 대화했다면 최근엔 기술과 AI를 함께 논의하는 경우가 늘어남

박성우 (한국디지털에셋) - 팀장급 대상

본인 팀은 팀원 전원이 팀장급 개발자(농담 반 진담 반)
- AI로 개인이 감당할 수 있는 업무 범위가 크게 넓어지면서 기존의 "팀" 개념 자체가 달라짐
"한 명 한 명이 팀으로 일해야 한다"는 이야기를 팀에 하고 있음
제품 방향 고민이나 커뮤니케이션 범위, 기술적 의사결정의 폭과 속도가 모두 넓고 빨라져, 기존처럼 팀 리드가 조언/코칭/리뷰를 해주기엔 속도가 따라가지 못하는 상황
- "나는 도대체 뭘 하는 사람인지" 회의감이 든 적도 있음
결국 개개인이 넓어진 범위에서 일할 수 있는 방향과 환경을 더 치열하게 고민해야 하는데, 팀원들이 그 속도에 지쳐가고 있진 않을까 걱정되는 시기

Q. AI 시대에도 변하지 않는 개발자의 핵심 역량은?

박용권 (당근마켓)

20년 내내 말해온 것 - 오늘의 나보다 내일의 나를 조금이라도 더 나아지게 하려는 태도. 그 성장 포인트를 끊임없이 찾아가며 노력하는 마음가짐은 AI 시대에도 동일

박성우 (한국디지털에셋)

책임감
- "마침표를 찍을 줄 아는 사람"이 가장 같이 일하고 싶은 사람. AI로 속도는 빨라져도 일을 완수하는 책임은 결국 그 사람의 몫

서동민 (두들린)

설계 - 코드를 짜는 행위 자체는 AI가 하지만, 무엇을 어디부터 어디까지 만들지, 다른 코드에 어떤 영향을 미칠지, 어떤 방향성으로 만들지 정의하는 것은 아직 AI가 못 하는 사람의 영역
그래서 "내가 이걸 어떻게 만들 것인가"를 설명하는 능력이 점점 더 중요해질 것

Q. 내일부터 회사에서 딱 한 가지를 바꿀 수 있다면?

박성우 (한국디지털에셋)

보안 특성상 운영 환경까지는 AI를 활용하지 못하고 있는 게 아쉬움 - 운영 환경 데이터 활용 방법을 고민 중

서동민 (두들린)

소스 관리, 제안(PR)/리뷰, 디자인 협업 등 기존 개발 프로세스를 AI 시대에 맞게 아예 무(無)에서부터 새로 만들고 싶음
- 지금의 프로세스는 사람 중심으로 짜여 있어 AI를 잘 쓰기엔 맞지 않는다고 봄
AWS의 AI DLC 프레임워크를 예로 들며, 직군별로 인원수를 다투던 시대는 끝났고 PM/엔지니어/디자이너 정도의 최소 구성으로도 충분히 만들 수 있는 시대라고 봄

AI DLC (AI Development Life Cycle): AWS가 제시하는, AI 활용을 전제로 재설계한 소프트웨어 개발 생명주기 프레임워크.

Inside Silicon Valley's Build Mode - Notion COO와 나누는 제품, 팀, 일하는 방식

Akshay Kothari(Notion 공동창업자 겸 COO)
진행: 이상아 (쿠팡)

Q. 노션 COO이기 전에, 실리콘밸리의 파운더이자 오퍼레이터로서 자기소개를 한다면?

인도에서 자라 미국에서 학사/석사를 마친 뒤, 스탠포드를 나오자마자 Pulse라는 회사를 창업
- 2013년 LinkedIn에 인수돼 약 5년 재직
2018년 노션에 여덟 번째 직원으로 합류해 다양한 역할을 거쳤고, 현재는 프로덕트/디자인/스토리텔링/브랜드를 맡고 있음

Q. 노션의 오리지널 비전 중 AI 때문에 바뀐 것은?

원래 비전은 소프트웨어 제작의 민주화
- 2천만 명의 개발자만 소프트웨어를 만들고 나머지는 쓰기만 해야 하는 구조를 바꾸고 싶었음
레고 블록에서 영감
- 동일한 블록으로 누구나 자신이 원하는 걸 조립할 수 있듯, 문서(docs) -> 데이터베이스 -> 자동화 -> 에이전트 순으로 "소프트웨어 블록"을 확장해 옴
AI 이전엔 사용자가 블록을 직접 조립해야 했다면, 이제는 원하는 언어로 말하면 AI가 대신 블록을 조립해줌
- 이걸 malleable software라고 부름

Malleable Software (말랑말랑한 소프트웨어): 플라스틱처럼 사용자가 자유롭게 변형/커스터마이징할 수 있는 소프트웨어라는 의미.

Q. 지난 1년간 노션의 의사결정과 가정은 어떻게 바뀌었나?

3, 4개월 전 출시한 개발자 플랫폼이 가장 큰 변화
1년 전 노션은 MCP/제대로 된 API/워커/액션이 없는 폐쇄적 플랫폼이었음
AI는 컨텍스트가 많을수록 좋아진다는 판단 아래, 노션을 "AI를 강제하는 폐쇄형"에서 "어떤 AI든 자유롭게 붙일 수 있는 완전 개방형"으로 전환
- 노션 자체는 기록의 시스템(system of record) 역할

Q. 여러 툴(슬랙/클로드/코덱스 등)을 오가며 일하는 개발자에게 노션은 어떻게 쓰이나?

개발자 플랫폼의 3가지 핵심 기능
- 임의의 데이터 소스 연결
- 특정 액션의 코드화
- 다른 에이전트를 노션 위로 불러오기
사내 소프트웨어 엔지니어링 팀은 노션을 하나의 "공장"처럼 사용 - 칸반 보드로 작업을 시각화하고, 클로드가 계획을 짜고 코덱스가 코드를 작성하고 또 다른 에이전트가 검수/배포하는 식
이 오케스트레이션 방식은 엔지니어링뿐 아니라 세일즈/마케팅 등 워크플로가 있는 모든 영역에 적용 가능
일부 고객은 노션 팀 자신보다도 이 방식을 더 잘 활용하고 있음

Q. 파운더 겸 오퍼레이터로서, 빠르게 변하는 AI 앞에서 전략을 어떻게 조정하나?

AI-필드 (AI-pilled): 실리콘밸리에서 쓰이는 표현으로, AI라는 새 기술의 힘을 의심 없이 받아들이고 적극 활용하는 사람을 가리킴.

예전엔 6개월 단위로 헤드카운트 계획과 제품 로드맵을 세웠는데, 이제는 사실상 실시간(just-in-time) 운영
- 매달 새 모델이 나오기 때문에 미리 계획하기 어려움
내부적으로 "모델과 싸울 수 없다, 강물이 흐르는 방향에 올라타야 한다"는 표현을 씀
- 로드맵도 향후 4-6주 정도만 구체적으로 그림
세 가지 축으로 방향을 유지
- 코어(문서/데이터베이스 등 시스템 오브 레코드)
- 에이전트 운영체제(에이전트/플랫폼웨어)
- 노션 링(문제 해결형 패키징 솔루션)
인원 수 기준 예산 대신 달러 기준 예산으로 전환
- 투자 결정도 실시간으로 이뤄짐
연례 컨퍼런스를 폐지하고 3개월마다 온라인으로 큰 런칭을 진행
- 물리적 행사는 준비에 6-9개월이 걸려 빠른 변화에 대응하기 어려움

Q. IC는 에이전트를 매니징하고 매니저도 IC 역량이 필요해지는 시대, 하이퍼포밍 팀은 어떻게 구성/운영돼야 하는가?

IC (Individual Contributor): 매니저 직책 없이 실무로 기여하는 개인 기여자.

아직 확실한 답은 없지만, 하나의 거대 팀보다 작은 팀 여러 개가 더 많은 프로젝트를 맡는 방향을 지향
코딩 에이전트를 제대로 다루는 2, 3명이면 상당한 힘을 낼 수 있음
- 실제로 노션의 개발자 플랫폼 전체를 12명 미만의 인원이 만듦(피자 두 판 팀 원칙)
기존 인력이 에이전트를 충분히 활용하도록 스킬업시키거나, 이미 익숙한 사람을 새로 채용해야 함
노션도 처음엔 소수의 AI-필드 직원에서 시작해, 지금은 전 직원이 AI 기반으로 사고하는 수준까지 확산됨

Q. (청중 질문) AI로 인한 "생산성 향상"이 실제 제품/서비스 생산성에 미치는 영향을 어떻게 측정하나?

Data Scout: 노션 사내에서 만든 커스텀 에이전트. 노션의 컨텍스트, MCP로 연결된 스노우플레이크(Snowflake) 데이터, 컴퓨터 사용 권한을 갖춰 데이터 사이언티스트가 하던 쿼리 작업을 누구나 할 수 있게 해줌.

노션의 초점은 개인이 아니라 "팀" 단위
- 한 사람이 만든 커스텀 에이전트를 회사 전체가 쓸 수 있다는 점이 핵심 힘
사례: 사내 엔지니어 한 명이 만든 "Data Scout" 에이전트를 하룻밤 사이 전사에 공유
- 이후 전 직원이 사실상 개인 데이터 사이언티스트를 갖게 됨
- 쿼리 1회당 3-4달러 비용에도 그만한 가치가 있다고 판단
데이터 사이언티스트 채용은 계속하지만, 역할이 "개별 쿼리 수행"에서 "시스템을 유지/고도화하는 역할"로 바뀜

Developer Reality Check - 개발자들은 진짜로 어떻게 생각할까?

김수빈 (당근마켓), 강현구 (센드버드), 성한영 (우아한형제들)
진행: 김만수 (센드버드)

Q. AI 사용 전후로 개발자로서의 하루가 많이 바뀌었다고 느끼는가?

성한영 (우아한형제들)

개발과 매니징을 병행하는데, AI를 쓴 뒤 처리할 수 있는 일의 양 자체가 늘어 요구받는 것도 많아짐
하루 업무가 여러 갈래의 짧은 단위로 잘게 쪼개질 만큼 달라짐

강현구 (센드버드)

목적에 다다르기 위한 행위(방법)는 많이 바뀌었지만, "무언가를 만든다"는 목적 자체는 그렇게 바뀌지 않음
AI 시대가 되면서 오히려 일이 많아지고 결국 해야 할 야근은 여전히 해야 해서, 하루가 크게 바뀌진 않았다고 봄

김수빈 (당근마켓)

원래도 팀에서 운영하는 개발자 플랫폼/서비스 제품이 많아, AI 도입 이전부터 여러 제품을 오가며 컨텍스트 스위칭하는 운영 업무가 많았음
AI가 이런 작업을 가속화하긴 했지만, 체감하는 컨텍스트 스위칭이나 개발량 자체는 이전과 비슷한 수준

강현구 (센드버드) - 자체 툴 제작 사례

슈퍼셋, 시냅스처럼 여러 터미널을 통합해 작업하는 툴이 나왔을 때도 "병렬로 일하는 게 정말 효율적인가" 의문이 있었음
직접 필요에 맞는 도구를 만들어보니 "도구가 없어서 그렇게 일을 못 했던 것"임을 깨달았고, 이후 일하는 방식이 많이 바뀜

성한영 (우아한형제들) - 매니저 관점

툴링을 직접 만드는 팀원을 볼 때, 문제 해결이 아니라 "도구를 위한 도구"를 만드는 자아실현으로 빠지는 경우를 경계함
그 경우가 아니라면 직접 도구를 잘 만드는 것 자체는 팀에 도움이 된다고 봄

Q. AI가 만든 결과물에 대한 신뢰도가 높은가?

강현구 (센드버드)

모델이 점점 좋아지면서 맡길 수 있는 일의 수준이 계속 올라가는 중
- 앞으로 더 좋아질 거라는 예측 아래 "지금 믿지 않고 쓰면 나중엔 믿을 수 있을까" 싶어 신뢰하려는 입장
다만 지금 당장 결과물이 늘 만족스러운 건 아니어서, 어떻게 지시해야 더 잘 쓸 수 있을지에 관심을 두는 편

김수빈 (당근마켓)

AI 신뢰도와 리스크는 저울질이 필요
- 본인이 개발하는 사내 플랫폼은 잘못된 결과물이 배포되면 인터페이스 롤백이 어려운 경우가 있어 한 번 더 검증하는 습관을 유지
코딩은 99% 이상 AI 에이전트로 생성하지만, 로컬/스테이징/운영 등 여러 검증 레이어를 리스크 수준에 따라 다르게 쌓아서 신뢰도를 관리
- 예: 로컬 시뮬레이션, 스테이징 배포 후 시뮬레이션, 운영 환경 성능 테스트, 다양한 에이전트를 통한 코드 리뷰 등

성한영 (우아한형제들)

사내 AX 도구를 직접 개발하는 입장이라, AI에게 일을 시켰을 때 원하지 않는 방향으로 나오는 경우를 계속 마주하며 개선 포인트를 찾게 됨
다만 목표는 신뢰도가 높은 상태를 만드는 것

Q. 신뢰도를 높이기 위한 가드레일이나 팁이 있는가?

강현구 (센드버드)

원하는 결과가 나오도록 인풋(지시사항)을 최대한 구체적으로 명시
SDK 개발 특성상 특정 부분 수정 시 사이드 이펙트 발생 여부가 중요한데, 에이전트 10개 정도를 병렬로 띄워 사이드 이펙트를 체크하고 재현율이 높은 것들을 추려 추적 - 대부분의 경우 문제 지점이 높은 확률로 드러남

Q. AI 도입 후 컨텍스트 스위칭이 늘었다고 느끼는가?

성한영 (우아한형제들)

코드를 손으로 직접 치지 않게 되면서 물리적으로 확보되는 시간이 늘어, "이것도 해보고 싶고 저것도 해보고 싶은" 일이 많아짐
- 그 결과 컨텍스트 스위칭도 자연히 늘어남

김수빈 (당근마켓)

컨텍스트 스위칭의 "종류"가 달라졌을 뿐, 종합적으로는 오히려 줄어든 느낌
예전엔 개발자 요청이나 이슈를 그때그때 바로 처리해야 했다면, 지금은 에이전트가 미리 처리하거나 빠르게 대응하는 경우가 늘어, 단순 업무에 쓰는 시간은 줄고 플랫폼 고도화/재설계처럼 깊은 고민이 필요한 일에 더 오래 집중하는 쪽으로 바뀜

Q. 노트 테이킹과 업무(태스크) 관리는 어떻게 하는가?

성한영 (우아한형제들)

매니저로서 우선순위 관리가 어려운 자리인데, 주간 단위로 클로드 등 AI 자동화를 활용해 컨텍스트를 정리
팀원이 업무 내용을 글로 잘 정리해서 공유해줄수록(컨텍스트가 풍부할수록) 더 잘 이해하고 해결할 수 있는데, 컨텍스트 정보가 적은 팀원의 업무는 파악하는 데 더 고민이 필요

강현구 (센드버드)

매니저가 아니라 개인 업무 자체는 AI 이후로도 크게 달라지지 않음 - 기존처럼 티켓 기반으로 생성/관리
부가적으로 들어오는 업무는 슬랙 "나에게 메시지 보내기"로 간단히 기록
- 슬랙에 클로드를 연동해두면 바로 실행하거나 컨플루언스 문서 업데이트까지 가능해 편리

김수빈 (당근마켓)

메신저는 슬랙, 문서화는 노션, 티켓/이슈 관리는 리니어(원문 "미디어", 정확한 툴명 확인 필요)를 사용
슬랙/구두로 논의된 업무가 노션에 정리되고, 그 주/그 달에 실행하기로 확정된 것은 이슈로 등록
- 이슈 하나가 에이전트 하나가 실행하는 작업 단위가 됨
필요하면 서브 이슈를 만들어 서브 에이전트에게 맡기고, 에이전트가 작업한 로그를 다시 이슈 코멘트로 남기는 방식

Q. IDE 없이 터미널(클로드 코드 등)만으로 작업이 가능한가?

강현구 (센드버드)

IDE는 거의 열지 않게 됨
- 회사에서 지원하던 커서도 비용이 아까워 정리하려는 중
최근엔 "에이전틱 IDE"로 불리는 컴포저/슈퍼셋/오르카 같은 도구로 터미널 기반 작업을 하면서, 필요할 때만 간단히 코드를 보는 정도

김수빈 (당근마켓)

IDE 사용 비중은 업무의 약 10% 정도
- 코드 리뷰나 직접 검증이 필요할 때, 터미널에서 눈으로 코드를 따라가기 어려운 부분을 IDE로 파악하는 용도로만 사용

Q. 회사에서 AI 도구를 얼마나 지원해주는가?

성한영 (우아한형제들)

클로드를 전사에 지원 중이며 전 직원이 사용
- 개발자들의 활용 속도가 매우 빠름

김수빈 (당근마켓)

개발자와 비개발자가 동일하게 지원받고, 원하는 것을 지원해주는 정책
사내에서 효용이 검증된 도구(앤트로픽 클로드, GPT/코덱스, 커서) 중 예산에 맞게 선택
- 클로드 맥스만 쓰거나, GPT와 코덱스를 반반 쓰거나, 코덱스 200달러 플랜을 쓰는 식
서비스에 사용하는 LLM API는 특별한 제한 없이 원하는 모델을 사용

강현구 (센드버드)

대부분의 툴을 지원하는 방향
- 클로드 코드는 팀 플랜이 열리자마자 전사 제공, 코덱스도 성능이 좋아진 이후 지원 시작
비용 측면에서 너무 비싸지지 않게 효율적으로 지원할 방법을 계속 고민 중

Q. AI를 잘 쓰는 개발자가 일도 잘한다고 느끼는가?

성한영 (우아한형제들)

반대라고 생각
- AI를 잘 써서 일을 잘한다기보다, 일을 잘하는 사람이 AI를 잘 가르치고 다루는 경우가 많음
결국 AI가 만든 코드 중 무엇을 채택할지는 사람이 정하는 것
- 이 도구를 어떻게 잘 다룰지 깊게 고민하고 접근하는 사람 자체가 희소하고, 그 고민이 이 시대에 가치 있는 것

강현구 (센드버드)

어느 쪽이라고 답해도 차이가 없을 것 같아 고민했는데, 시간이 지날수록 AI를 잘 쓰는 개발자가 고민도 잘한다고 느낌
결국 일을 잘하는 사람이 AI도 잘 쓴다는 쪽으로 둘 다 해당

김수빈 (당근마켓)

AI를 잘 쓰는 것은 일을 잘하기 위한 여러 조건 중 하나일 뿐, AI를 잘 써도 일을 못 할 수 있다고 봄
AI를 다루는 능력 자체는 점점 평준화되고 있다고 느낌
원래 일을 잘하던 사람에게 AI는 "날개를 달아주는 것"일 뿐
- AI를 위한 도구, 에이전틱 워크플로를 만드는 일 자체에 매몰되는 것을 경계

What's new in SwiftData (feat. WWDC 2026)

2026-07-12T18:36:37+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 WWDC 2026에서 나온 SwiftData 부분에서 업데이트 사항들에 대해 살펴보고 정리해보겠습니다

Sectioning your fetches

먼저 SwiftData에서 섹션별로 데이터를 가져오는 방법을 보겠습니다.

이제는 이렇게 쿼리에서 옵션을 주어 그룹별로 묶을 수 있어요.

각 섹션에선 ID 속성이 있고 이걸 활용하게 됩니다.

Using custom types

모델에 커스텀 타입을 저장하는 기능 향상을 살펴볼께요.

SwiftData는 로드될 때 모델에 대한 스키마를 자동으로 생성합니다.

스키마는 모델 클래스와 엔티티간 매핑을 정의하죠.

대부분의 타입에선 이게 자동으로 작동해요.

그렇지만 모델 매크로로 어노테이션 되지 않은 클래스는 자동으로 검사할 수 없기에 SwiftData는 스키마 생성에 실패합니다

만약 그렇다고 구현체에 접근할 수 없을 수 있잖아요?

그런 경우 이렇게 어트리뷰트 codable을 사용하여 주면 해결됩니다.

이 속성은 SwiftData에 타입의 인코딩된 표현을 저장하도록 알려주는 역할을 합니다.

타입에 대한 스키마를 추론하는 대신에요.

다만 염두해둬야할게 있는데, codable 속성의 내용은 SwiftData에 불투명합니다.

이는 Predicate에서 결과를 필터링하는데 사용할 수 없음을 나타내요.

또는 정렬도 사용할 수 없어요.

또한 codable 형태가 변경되면 속성을 추가하거나 제거하는 경우 마이그레이션이 트리거되지 않아요.

이 점을 주의해야 합니다!

Codable 속성 사용은 SwiftData가 기본적으로 지원하지 않는 타입을 저장하는 탈출구라고 생각하면 좋습니다.

직접 정의했다면 왠만해선 Codable 사용을 금해야 합니다.

Observing data stores

스토어를 모니터링하고 데이터 변경 시 알림 받는 방법을 살펴볼께요.

SwiftUI에서는 이렇게 데이터가 변경되면 뷰가 쿼리의 새로운 결과를 반영해 다시 렌더링합니다.

만약 SwiftUI가 아닌 부분은 어떨까요?

이걸 위해 이번 2027 릴리즈에선 ResultsObserver를 도입했습니다.

SwiftUI 쿼리처럼 데이터 가져오고 관찰하고 반영시키는 Swift Observation을 사용해요.

이런식으로 사용될 수 있습니다.

withContinuousObservation은 ObservationTracking 토큰을 반환합니다.

이 토큰이 관찰의 수명을 정의하죠.

여기서 더 나아가 이번 업데이트에서는 히스토리 관찰도 지원해줍니다.

데이터 스토어가 저장될 때마다 SwiftData는 히스토리 트랜잭션을 기록합니다.

여기에는 변경된 내용에 대한 정보가 포함됩니다.

그리고 변경이 어디서 왔는지 조차도 포함되죠.

히스토리에서 트랜잭션을 고유하게 식별하는 토큰도 있습니다.

ModelContext.fetchHistory() 이 API와 토큰을 함께 사용할 수 있어요.

HistoryObserver는 스토어의 변경 사항에 쉽게 반응할 수 있게 해줍니다.

지속적 히스토리 관찰과 새로운 트랜잭션 추가 시 코드가 반응하도록 해주죠.

특정 종류의 변경만 관찰하고 대응하고 싶다면 물론 HistoryObserver를 사용해 모델 타입과 트랜잭션 작성자로 필터링할 수 있어요.

외부 서버와 같은 다른 시스템과 연동 시 효과적이죠.

외부와 연동하는 예시를 볼까요?

이렇게 간단히 코드로 나타내서 사용할 수 있습니다.

References

SwiftData의 새로운 기능 - WWDC26 - 비디오 - Apple Developer

SwiftData의 최신 개선 사항을 확인하세요. Codable을 사용하여 맞춤형 및 타사 유형을 유지하는 방법과 가져온 데이터를 SwiftUI 앱의 섹션으로 그룹화하는 방법을 안내합니다. 또한 ModelResultsObserver와

developer.apple.com

느즈막히 올려보는 쿠팡에서의 회고 (feat. 또다른 시작)

2026-07-06T13:39:50+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 사실 기술적인 부분보다 회고를 하나 해볼까 합니다.

제가 근 1년 6개월 정도 근무했던 쿠팡을 떠나게 되었는데, 사실 쿠팡 입사 직후와 3개월쯤 되었을때 각각 쿠팡 이직기라던지 쿠팡에서의 일상 회고를 해보려 했는데, 일과 개인적인 바쁨에 치여 결국 쿠팡을 나올때 이렇게 회고를 올려보네요

그래서, 이번 회고는 역시나 무근본 무형식으로 그냥 두서없이 한번 적어보려고 합니다

쿠팡 입사

25년 2월에 쿠팡으로 이직을 하게 됩니다.

왜 이직했는지 그냥 지금와서 간단히 정리해보면, 정말 글로벌 서비스를 하는것과 글로벌 회사에서 일하는것을 경험해보고 싶었어요.

이전까지는 iOS 개발자 1인으로 내 할일을 다하는것에 초점이였다면 앞으로의 성장을 생각했을때 그걸 넘어서 정말 일을 잘하는 사람이 되고 싶었어요.

개발에 국한된게 아니라 일을 잘하는 사람이요.

그랬을때 좀 더 큰 대규모의 서비스를 경험해보면서 다국가 인종과 일하는 경험 이 두가지가 쿠팡을 지원하고 입사를 하게된 가장 큰 이유였습니다

그래서 쿠팡에서 쿠팡이츠라는 O2O 배달 앱 서비스의 시니어 iOS 엔지니어로 근무를 하게 됩니다.

그럼 쿠팡에서의 1년 6개월을 돌이켜봤을때 어떤것을 해왔고 어떤걸 배웠는지 한번 정리해볼까해요.

Life in Coupang

우선 일은 굉장히 굉장히 하드워킹이긴 했습니다.

그렇다고 밤낮이 없는 삶, 원양어선 그런건 아니였어요.

그냥 주어진 시간에 정말 1초도 쉬지 않고 일하면 다 끝날 수 있는 그런 정도..?

제가 맡은 TF는 주로 Ads TF였습니다.

배달 앱의 특성 상 배달이나 플랫폼 수수료 같은걸로는 정부 규제도 있고 단가가 그렇게 크지 않아 사실상 사업적인 부분에서 큰 이익이 되지 않는다고 생각해요.

그렇기에 또 다른 비지니스적인 부분을 고려할때 광고를 무시할 수 없습니다.

점포나 메뉴 광고가 주인데 어떤 부분에 배치하거나 어떤 시간대에 어떤걸 배치하면 이 점포를 가장 극대화되어서 CPC나 CPS를 올릴 수 있을지 같이 고민하고 여러 실험을 해보는 그런 TF입니다.

광고라는 도메인이 익숙치도 않고 처음 해보는거였지만 그만큼 재밌었어요.

직접적으로 주간으로 광고를 통해 얼마나 많은 매출에 기여했는지 확연하게 눈에 보일 수 있었기에 더 동기부여가 되었습니다.

또한, 광고 TF말고도 두루 경험해봤던것도 큰 기억으로 남아요.

핵심인 음식 배달과 요즘 밀고 있는 쇼핑(마트나 편의점, 꽃집 등등 - 푸드가 아닌 모든것) 그리고 고객들의 VOC나 편의성을 개선하기 위한 CRM TF 등 한 팀에 정말 다양한 TF가 로테이션으로 돌아가며 일을 하게 되는데 이 모든것의 비지니스 태스크를 한번씩은 해본것 같습니다.

그러다보니 자연스레 다양한 코드들을 보게되고 깊게 이해하게 되었어요.

이렇게 거시적으로 볼 수 있는 비지니스적인 일은 어떻게 했는지에 대해 간단히 회고를 해본다면 이제는 팀에 대한 회고를 해볼까해요.

사실상 가장 많이 짧다면 짧은 시간에 성장할 수 있게 된 원동력이 바로 소속된 iOS 팀이였습니다.

솔직하게 지금까지 나름 다양한 회사도 다녀보고 여러 동아리도 해보고 컨퍼런스도 다녀보면서 교류해봤지만 개발자 개개인의 역량으로는 쿠팡이 가장 월등하다고 느꼈어요.

쿠팡의 채용 과정이 정말 복잡하고 난이도가 큰 편이라 더 그런지는 몰라도 개발자의 능력은 어느 회사보다도 뛰어나다고 확신할 수 있습니다.

그렇기에 같이 부딪히며 토론하고 때론 설전도 벌이면서 일을 하면서 성장한것 같아요

쿠팡에서 일하기 전까지의 저를 돌이켜보면 iOS 개발 맡은거 능히 해낼 수 있는 개발자라고 말할 수 있다면, 여기서 배운건 그건 당연히 해야되는거고 그거 말고도 너가 더 뭘할 수 있는데?에 대한 푸시가 많고 그걸 잘 끌어올려줄 매니저와 팀원들이 존재했습니다.

너가 1인분 하는건 당연히 시니어 개발자가 아니라 주니어 개발자여도 당연히 해야되는거고, 그걸 넘어서 시니어 개발자라면 팀에 어떤 영향을 미칠 수 있는지 고민하고 iOS 뿐만 아니라 더 스펙트럼을 넓혀서 안드로이드, 웹을 포함한 프론트 그리고 백엔드까지 비지니스 스펙을 받으면 고려해서 테크적인 리드를 할 줄 알아야 하며 그런 부분을 하드 트레이닝을 많이 했던것 같아요.

그래서 일감이 주어지면 항상 어떻게 개발해야하지? 라는 생각보다 이게 정말 괜찮은 실험인지 이 실험을 성공시키기 위해서 각 파트에서 어떤 노력을 기울이면 좋을지 그리고 그게 제일 효과적인 방법일지를 고민하게 저의 일을 접근하는 방식 자체가 많이 변화한것 같아요.

그전에는 iOS 앱 개발 부분에서만 고민했다면 이제는 백엔드와의 트레이드오프도 생각해보고 좀 더 크로스 플랫폼에서 일하기 적절한 방법과 그리고 기능 개발 대비 어느정도 인력 코스트가 들어가는지 그런것들까지 고민하고 제안을 하게 되는 개발자로 성장했어요.

그리고 그건 제가 원하지 않아도 쿠팡에서 일을 하면 자연스럽게 요구되는 역량이고 그렇게 변하게 만들어주더라구요

그리고 팀적으로도 매주 테크 미팅을 통해 서로 기술을 공유하고 새로 맡은 비지니스 일감이 있다면 항상 먼저 테크 디자인을 한 후 공유해서 더 나은 방향이 있는지를 모바일 팀 자체적으로 더 체크를 합니다.

이렇게 꼼꼼하고 다양한 의견을 듣다보면 자연스럽게 시야도 넓어지게 되더라구요.

쿠팡에서는 이렇게 정말 많은 미팅과 룰과 일이 존재해요.

그러다보니 눈코 뜰 새가 없는건 사실이지만 어떻게 보면 가장 이상적인 시스템이라곤 생각이 되더라구요.

그 시스템에서 번아웃이 안오고 버티는게 힘든것 뿐이지만 회사적인 측면으로만 보면 합리적이고 비지니스가 성장할 수 있는 시스템이란 생각이 많이 듭니다.

그리고 또 많이 성장했던 부분은 바로 영어일것 같아요.

사실 영어를 잘하지 못했고 지금도 그렇지만 하나 달라진건 자신감인것 같아요.

회사에선 공식적으로 한국어로 일하는것 자체가 없어요.

공용 언어가 영어이기에 슬랙, 위키 등등 모든것이 영어죠.

그리고 미팅도 통역이 제공되는 경우도 있지만 기본이 영어입니다.

그러다보니 사실 살려면 해야됐었어요.

저도 처음에 입사해서 "아 이거 일보다 커뮤니케이션이 영어라 따라갈 수 있나?" 싶었어요.

그래서 슬랙도 그렇고 번역기에 번역하고 하고 싶은 말도 번역해서 떠듬떠듬 치고 그랬죠.

그런데 이게 일상에 녹아드니 별다른 영어 공부를 하지 않아도 자연스럽게 익숙해지기 마련이더라구요.

그 전에는 예를 들어 "이거 확인해주실 수 있나요?" 라는걸 영어로 말해야된다 생각하면 머릿속에서 문법부터 생각하고 완성한 다음 이게 진짜 맞나 고민하고 그런것들때문에 영어가 입 밖으로 더 안나왔던것 같아요.

그런데 이제는 일단 문법이 다 맞지 않고 그렇더라도 이 바쁜 일상에서 우선 커뮤니케이션이 우선이고 먼저 말해야된다는 압박이 있다보니 자연스레 "Could you check this?"와 같이 나오게 되더라구요.

물론 더 좋은 표현도 있고 하겠지만 배운 한가지가 자신감이라 했잖아요?

이 자신감은 확실히 익힌것 같아요.

이제 말로 표현하고 문장으로 쓰는게 내가 틀렸다 하더라도 두렵지가 않게 되었습니다.

그리고 앞서 계속 말했지만 팀원들 정말 훌륭하고 귀중한 팀원들 그리고 타 팀의 교류하는 사람들 모두 좋은 인프라를 쌓을 수 있어 감사했어요.

일이 빡센만큼 전우애가 더 많이 생기게 되는 쿠팡이였어요.

나간다니 이런 것까지 해주는 팀원들인데 어떻게 잊을 수 있을까 싶어요.

그래서 정리해보면 쿠팡에서 생활하면서 성장한 부분은 이렇습니다.

1️⃣ 기술적인 견고함과 더 넓게 바라볼 수 있는 시야

2️⃣ 개인 혼자만이 아니라 팀 전체에 영향을 미칠 수 있는 사고

3️⃣ 영어 의사소통

4️⃣ 정말 비지니스적으로 어떤것들이 도움되는지에 대한 고민

이 외에도 서버 드리븐적인 설계, 대쉬보드들을 구축해서 모니터링을 강화하는 방법, 장애 대응, AI 오너로써 팀을 이끌어본 경험 등등 기술적으로나 팀에 영향을 주는 부분으로나 정말 다양한 포인트들이 있지만 그거까지 쓰면 한도 끝도 없을것 같아 우선 쿠팡에서의 라이프는 간략하게 이정도로 마칠까 합니다.

그럼 가장 중요한 포인트인데 왜 쿠팡을 떠나는지에 대해 간단히 정리하고 마쳐보려고 해요.

Why am I leaving Coupang?

당연히 이직이 쉬운 선택도 아니고 또 새로운 도전을 하는것은 더더욱 쉬운 선택이 아닙니다.

그리고 그런 결정을 하기까지에는 정말 큰것부터 정말 사소한것까지 많은 복합적인 부분이 상호작용 할거에요.

여기선 몇가지 핵심적인 이유를 전해볼까해요.

우선, 쿠팡이 다니기에 좋지 않은 회사다 라는것은 전혀 아닙니다.

일이 힘들 순 있지만 그거때문에 이직하는건 도피라고 생각해요.

어딜가나 힘든건 있기 마련이고 일이 바쁘다고 나가는건 근로자의 덕목이 아니라 생각하기 때문이죠.

1️⃣ 더 넓은 글로벌 서비스

가장 큰것중 하나는 바로 이 항목이에요.

쿠팡이츠를 개발하면서 현재는 한국과 일본을 타겟으로 서비스하고 있는데, 일본을 고려해서 글로벌한 서비스를 구축하고 운영하다 보니 정말 더 많은 나라들 나아가서 대륙들을 타겟으로 하는 더 큰 글로벌 서비스들이 궁금해졌어요.

그리고 글로벌 서비스를 해보니 재미가 있더라구요.

같은 앱이지만 각 문화 환경에 따라 원하는 화면과 폰트 배치들이 다르다는것도 세삼 느끼게 되면서 뭔가 리전을 바꿀때마다 여행하는 느낌이 들었어요.

직간접적으로 그 나라를 체험해보는거죠.

그래서 이를 충족하는 서비스를 해보고 싶다는 생각이 컸습니다.

2️⃣ 컨텐츠 플랫폼에 대한 니즈

그리고 저는 사실 개발자를 처음 해올때부터 사용자들이 몰두할 수 있는 컨텐츠 플랫폼을 해보고 싶었어요.

지금까지는 주로 커머스, O2O와 같은 사용자들이 앱에 들어와서 빠르게 확인하고 구매하고 나가는 그런 동선으로 비지니스를 이끄는 서비스였어요.

그러다보니 한 화면에서 애니메이션이나 더 심미적인 부분보다는 탐색 플로우나 결제 플로우에서 로직과 빠른 구매가 더 중요해지더라구요.

그래서 한편으로는 그런 부분들을 많이 다룰 수 없었어요.

여담이지만 저는 KWDC 2023에서 SwiftUI 애니메이션 관련 세션을 발표할 정도로 심미적인것과 사용자의 더 아름다운 경험을 구현하는걸 원하고 좋아하는 개발자에요.

그래서 그런 부분을 채울 수 있는 컨텐츠 플랫폼 서비스를 꼭 해보고 싶었어요.

그럼 왜 여태까지 그런거 안했냐? 라고 한다면 안한게 아니라 못했던거라고 할 수 있어요

사실 알려진 컨텐츠 플랫폼 앱이 몇개 되지도 않지만 제가 원한다고 내일부터 그 회사에 들어가서 해볼 수 있는건 아니잖아요..?

무튼 그래서 컨텐츠 플랫폼을 향한 저의 개발자로서의 니즈가 이직의 큰 몫을 했습니다.

3️⃣ 거리

마지막으로 누군가한테 사소할 수도 있지만 저한테 큰 부분이였던건 회사와의 거리였어요.

사실 쿠팡에 입사한것도 처음엔 하이브리드로 재택이 존재했기에 공고나 계약도 그렇게 진행되었어요.

그래서 선릉까지 출퇴근하는게 매일이 아니니 부담스럽지 않고 현실적으로 가능했죠.

그런데 작년부터 풀출근으로 근무제도가 변경되면서 이는 적지 않은 부담으로 다가왔어요.

(물론 모든 쿠팡 부서가 그런건 아니고 근무제도는 조직장에 따라 모두 부바부입니다.)

그러다보니 출퇴근 하는데 드는 시간, 체력소모, 비용 그런것들까지 트레이드 오프 되는것을 생각해볼때 쿠팡이 큰 메리트가 되지 않는단 생각이 문득 들더라구요.

그래서 사소할 수 있지만 저한텐 어떻게 보면 심리적으로 가장 큰 부분이였어요.

이런 대표적인 이유 + 말하진 않았지만 더 많은 이유들이 상호작용하여 이직을 결심하게 되었습니다.

(혹시 말하지 않았지만 더 많인 이유들이 궁금하시다면 연락주세요 ㅋㅋㅋ)

그래서 이번엔 어딜 가는데?

이번에는 1과 2그리고 3번의 이직 이유들을 충족할 수 있는 곳으로 가게되었어요.

네이버웹툰에서 글로벌 웹툰 iOS 앱 개발에 기여하게 되었습니다.

아직 출근전이고 이 글이 나가는 시점에서 한 주 후 첫출근을 하게 될 예정이라 떨리네요 ☺️

인터뷰들을 진행하며 제가 더 다른 성장하고 싶은 포인트와 해소하고 싶은 포인트들을 네이버 웹툰에서 더 다양하게 해볼 수 있을것 같아 많은 기대가 됩니다!

아 그리고 현재 쿠팡에서 해당 제 포지션의 채용이 열려있어요!

관심 있으시거나 궁금한 부분이 있으신 분은 언제든 편하게 연락주시면 제가 아는선에서 알려드리고 도와드릴께요

제가 장담하건데 꼭 다녀봐야할 회사라고 생각합니다.

Sr Mobile Engineer (Eats iOS)

쿠팡이츠(Coupang Eats)는 쿠팡의 음식 배달 서비스이자,대한민국에서 빠르게 성장하고 있는 배달 서비스입니다. 2019년 국내 배달 업계에 혜성처럼 등장한 쿠팡이츠는 2024년 ‘무제한 무료배달’로

www.coupang.jobs

또 어떤 재밌는 일들이 벌어지고 경험하게 될지 모르겠지만, 언젠가 또 좋은 회고로 찾아오도록 하겠습니다

브라우저의 메인 스레드는 비싸다

2026-07-12T09:00:00+09:00

프론트엔드 최적화라고 하면 무엇이 떠오르는가? 대체로 네트워크 요청을 줄이거나 번들 크기를 줄이고 캐시를 잘 쓰는 일을 떠올린다. 그 외에는 리렌더링 줄이기나 리소스를 불러오는 타이밍쯤이 떠오를 것이다. 보통 메인 스레드를 떠올리기는 쉽지 않은데…

블로그에 ActivityPub 연동을 붙였다

2026-07-16T01:00:00+09:00

블로그에 ActivityPub 연동을 붙였다

직접 만든 정적 사이트 생성기인 Jikji로 이 블로그를 만들고 나서 5년 가까이 흘렀다. 그때의 나는 아직 TypeScript나 최신 웹 기술에 익숙하지 않았고, ActivityPub 구현도 해 본 적이 없었다. 하지만 이제는 TypeScript와 최신 웹 기술에 비교적 익숙해졌고, ActivityPub은 내게 중요한 기술이 되었다. 게다가 명색이 Fedify 메인테이너인데 정작 블로그가 연합이 안 되어 있다는 게 늘 마음에 걸리기도 했다. 그래서 블로그에 ActivityPub 연동을 붙이게 되었다.

기존 스택: Jikji + PHP

이 블로그는 원래 Jikji라는 내가 직접 Deno로 만든 정적 사이트 생성기 기반이었다. 엄밀하게는 정적 사이트라고 말하기는 어려웠는데, 옛날 Movable Type이 그러했던 것처럼, HTML만을 생성하는 게 아니라 PHP도 일부 생성했기 때문이다. PHP는 주로 HTTP 내용 협상을 위해서 쓰였다. 브라우저의 Accept-Language 헤더를 보고, 국한문 혼용 조선어, 한글 전용 한국어, 영어, 일본어 중에 적절한 언어로 표시했다. 단지 그뿐이지만.

이미 PHP를 쓰고 있으니, PHP로 얇게 ActivityPub 구현을 붙이는 것을 먼저 고려했다. 하지만 PHP를 쓰고 있다곤 해도 직접 코딩하는 게 아니라 Jikji가 생성해줬기 때문에 쓴 것이지, PHP를 손으로 직접 코딩하고 싶지 않다는 생각이 들었다. 새 글이 올라오면 자동으로 Create(Article) 액티비티를 팔로워들에게 전달해야 하는데 그러자면 어차피 메시지 큐 같은 구조가 필요해진다. PHP에 메시지 큐까지 붙여서 사용하게 되면, 사견으로는 PHP에 적합한 규모와 복잡도를 벗어난다는 느낌도 들었다. 그리고 무엇보다, Fedify가 있는데 굳이 ActivityPub 구현을 바닥부터 하고 싶지 않다는 생각도 했다.

그래서 PHP를 아예 걷어내고, Fedify를 붙이기로 마음먹었다.

새 스택: Astro + Netlify

일단 첫 선택으로, Jikji와 PHP를 버리고 정적 콘텐츠 중심의 웹 사이트를 만드는 데에 특화되어 있는 JavaScript 웹 프레임워크 Astro를 쓰기로 했다. 이미 @fedify/astro 연동 패키지가 있다는 것도 Astro를 고른 큰 이유였다.

단, 기존에 쓰던 CSS나 HTML 템플릿은 최대한 재활용했다. 현재 웹 디자인에 만족하고 있기도 했고, 웹 디자인 개편까지 하면 범위가 너무 커질 것 같았다. 퍼머링크도 완전히 그대로 보존했다. 전반적으로 방문자가 뭐가 딱히 바뀌었는지 눈치 못 챌 정도로 표면을 유지하면서 기술 스택을 이전하는 게 목표였다.

배포는 Cloudflare Workers와 Netlify 중에서 고민하다가, Fedify를 아직 Netlify에 올려 본 적이 없는 것 같아서 Fedify의 Netlify 지원을 이참에 추가하는 계기로 삼기로 했다. 여태까지 정적 사이트 호스팅을 위해 Netlify를 여러 차례 써 왔지만, 에지 함수를 함께 쓰는 건 처음이었다. 기본적으로는 정적인 애셋들로 이뤄져 있지만 일부 기능만 동적으로 동작한다는 개념이, 마치 90년대 말 웹 사이트를 만들 때 CGI 스크립트만 /cgi-bin/ 디렉터리 안에 두던 방식을 떠오르게 했다.

기존에는 블로그 글을 Markdown 파일로 저장하고 Git에 체크인한 뒤, 푸시하면 GitHub Actions로 정적 사이트를 빌드하고 나서 SFTP를 이용해 배포하는 흐름이었는데, 이제는 GitHub Actions를 빌드 파이프라인에서 뺄 수 있었다. Netlify가 알아서 빌드를 해주기 때문이다. 결과적으로 더 단순해졌다.

Astro는 대체로 만족스러웠고, 이전은 비교적 수월했다. 5년 전에 만든 뒤 거의 업데이트를 안 했던 Jikji보다 나은 건 물론이었다. Jikji는 더 이상 관리할 이유가 없어졌기 때문에 저장소를 아카이브 처리했다.

Astro에 Fedify 붙이기

@fedify/astro 최신화

그런데 막상 Astro에 Fedify를 붙이려니, @fedify/astro가 최신 버전인 Astro 7을 지원하지 않았다. 내부에서 사용하는 Astro API는 크게 달라지지 않았지만, 패키지에 명시된 호환 범위와 테스트는 Astro 5까지만 다루고 있었다. 결국 블로그에 Fedify를 붙이기 전에 먼저 @fedify/astro부터 고쳐야 했다.

단순히 패키지의 버전 범위만 넓히지는 않았다. 기존 테스트는 가짜 Astro 컨텍스트를 만들어 미들웨어를 직접 호출했기 때문에, Vite의 SSR 설정이나 어댑터 사이의 호환성, 빌드된 서버의 요청 라우팅 같은 문제는 잡아낼 수 없었다. 그래서 Fedify 패키지를 실제로 패킹해 작은 Astro 애플리케이션에 설치하고, 서버를 빌드하고 실행한 다음 HTTP 요청까지 보내는 호환성 테스트를 새로 만들었다.

이 테스트는 Astro 5, 6, 7에서 HTML 요청은 Astro 페이지로 넘어가는지, ActivityPub과 WebFinger 요청은 Fedify가 처리하는지, 그밖의 경로에서는 Astro의 404 Not Found 응답이 유지되는지 등을 확인한다. Astro 7은 Node.js뿐 아니라 Deno와 Bun으로도 빌드해 보도록 했다.

이 작업은 이미 업스트림에 머지되었고, Fedify 2.4.0에 포함될 예정이다.

정적 페이지와 동적 엔드포인트

Astro 프로젝트 전체는 서버 아웃풋으로 빌드하되, 기존 블로그 페이지는 이전처럼 프리렌더링하도록 했다. 반면 WebFinger와 액터, 인박스, 아웃박스, 팔로워 컬렉션, ActivityPub 객체 경로는 요청을 받을 때 Fedify가 동적으로 처리한다. @fedify/astro가 제공하는 미들웨어는 요청의 URL과 Accept 헤더를 살펴보고 Fedify가 처리할 요청만 가로챈다. 같은 URL이라도 HTML을 요청하면 기존 Astro 페이지를 보여주고, ActivityPub 표현을 요청하면 Fedify가 만든 객체를 돌려줄 수도 있다.

결과적으로 방문자가 보는 블로그는 여전히 정적 사이트에 가깝다. 새로 생긴 동적 부분은 대부분 페디버스의 다른 서버가 접근하는 곳에만 있다. 앞에서 CGI를 떠올렸던 것도 이런 구성 때문이었다.

`Person`과 `Article`

ActivityPub을 붙일 때에는 이 블로그에서 무엇이 액터이고 무엇이 객체인지도 정해야 했다. 블로그의 액터에는 Person 타입을 골랐다. 실제 발행 작업은 프로그램이 자동으로 하지만, 액터가 나타내는 것은 블로그 소프트웨어나 서비스가 아니라 이 글들을 쓰는 나 자신이기 때문이다. 그래서 핸들은 @hongminhee@writings.hongminhee.org이고, 액터의 웹 URL은 이 블로그를 가리킨다.

각 블로그 글에는 Article 타입을 골랐다. 제목과 본문이 있고, 독립적인 퍼머링크를 가진 장문 문서이므로 Note보다 의미가 잘 맞는다고 생각했다. 다행히 Mastodon 등 최근의 주요 ActivityPub 구현들도 Article을 대부분 지원한다. 사람이 읽는 기존 퍼머링크는 그대로 두고, ActivityPub 객체에는 /ap/articles/{year}/{month}/{slug} 형태의 별도 URI를 붙였다. Article의 url은 다시 기존 퍼머링크를 가리킨다. ActivityPub 객체의 URI와 사람이 읽을 웹 페이지의 퍼머링크를 구분한 것이다.

다국어 표현은 조금 더 고민할 부분이 있었다. 언어별 페이지를 서로 다른 Article 객체로 표현하면 같은 글에 대한 반응과 공유가 여러 객체로 흩어진다. 그래서 같은 퍼머링크에 속한 국한문 혼용 조선어(ko-Kore), 한글 전용 한국어(ko-Hang-KR), 영어(en), 일본어(ja) 버전을 하나의 Article로 묶었다. 제목과 요약, 본문에는 각각 언어 태그가 붙은 값을 모두 넣었다. JSON-LD로 직렬화하면 각각 nameMap, summaryMap, contentMap으로 표현된다. 언어별 값을 처리하지 않는 구현을 위해 name, summary, content에는 기본 언어의 값도 함께 넣었다. 영문판이 있으면 영어를, 없으면 국한문 혼용 조선어를 기본값으로 삼았다. 언어별 HTML 페이지는 Article의 url에도 hreflang 속성이 붙은 Link 객체로 덧붙였다.

이렇게 하면 수신 서버가 다국어 값을 이해할 경우 이용자의 언어에 맞는 제목과 본문을 고를 수 있고, 그렇지 않더라도 기본값은 표시할 수 있다. 사실, 내가 아는 거의 모든 ActivityPub 구현은 아직 이런 다국어 자연어 값을 제대로 표시하지 못한다. Mastodon 이슈 트래커에 이를 위한 이슈가 올라와 있고 Hackers' Pub 이슈 트래커에도 비슷한 제안이 올라와 있지만, 언제 구현될지는 기약이 없다. 아마 UI 디자인 측면에서도 고민이 필요할 것이다.

Fedify를 Netlify에서 돌리기

정적 파일만 배포할 때와 달리 ActivityPub 서버에는 배포가 끝난 뒤에도 남아 있어야 하는 상태가 있다. 우선 액터의 서명 키가 배포할 때마다 바뀌어서는 안 된다. 팔로워 목록도 다음 배포에서 사라지면 안 된다. 이 두 가지는 Netlify Database에 저장했다.

인박스에서 받은 액티비티와 원격 서버에 보낼 액티비티는 Async Workloads로 만든 메시지 큐에서 처리한다. 액티비티 전송은 상대 서버의 상태에 따라 느려지거나 실패할 수 있으므로, HTTP 요청을 받은 함수 안에서 모두 끝내려고 해서는 안 된다. 큐에 넣어 두면 요청과 전달을 분리할 수 있고, 실패한 작업도 나중에 재시도할 수 있다. 다행히 Fedify는 이러한 작업을 추상화해 두었고, 백엔드 어댑터도 확장할 수 있다. 다만 아직 Netlify의 Async Workloads를 위한 어댑터가 없었기 때문에, Fedify가 Async Workloads를 메시지 큐로 사용하면서 Netlify Database에 전달 순서 상태를 보존할 수 있도록 @fedify/netlify 패키지도 만들었다.

새 글을 연합우주(fediverse)에 알리는 일은 조금 다른 문제였다. 정적 사이트의 빌드가 끝났다고 해서 실행 중인 ActivityPub 서버가 어떤 글이 달라졌는지 저절로 알 수는 없다. 그래서 프로덕션 배포가 성공하면 이전 배포와 새 배포의 글 목록을 비교한다. 새로 생긴 글에는 Create(Article), 내용이나 수정 시각이 달라진 글에는 Update(Article), 사라진 글에는 Delete(Article) 액티비티를 만들어 팔로워에게 보낸다. 재시도하더라도 같은 변경에 같은 액티비티 ID를 쓰고, 더 오래된 배포가 나중에 동기화되어 최신 상태를 되돌리지 못하도록 배포 순서도 확인한다.

Netlify에는 배포 미리보기(deploy preview)와 브랜치 배포(branch deploy) 기능이 있는데, 그 경우에는 연합 기능을 아예 끄도록 했다. 미리보기마다 같은 블로그를 자처하는 액터가 생기거나, 시험 배포가 실제 팔로워에게 액티비티를 보내면 곤란하기 때문이다. 로컬에서는 메모리 저장소와 큐를 써서 개발할 수 있고, 프로덕션에서만 영속적인 데이터베이스와 큐를 사용한다.

아무튼 덕분에 Fedify는 이제 Deno Deploy 및 Cloudflare Workers와 함께 Netlify Functions도 지원하게 되었다. 물론, Node.js, Deno, Bun에서도 돌아가는 것은 기본이다.

마치며

이 작업으로 블로그에 타임라인이나 답글 작성 화면 같은 소셜 기능이 생긴 것은 아니다. 글을 쓰고 읽는 방식도, 기존 퍼머링크와 디자인도 거의 그대로다. 다만 이제 이 블로그와 글에는 연합우주에서 통용되는 이름과 주소가 생겼다. 사람들은 @hongminhee@writings.hongminhee.org를 팔로해 새 글을 받아 볼 수 있고, 각 글의 ActivityPub 객체 URI를 검색해 원문을 찾을 수 있다.

Fedify를 유지보수하면서 다른 개발자에게 ActivityPub을 구현하는 방법을 제공해 왔고, Hollo나 Hackers' Pub 등을 만들면서 개밥 먹기도 꽤나 했지만, 이미 운영 중인 웹 사이트, 그것도 정적 페이지로 되어 있던 블로그에 Fedify를 붙이는 건 처음이었다. 덕분에 Astro 통합의 호환성 테스트와 Netlify 지원을 추가했고, 문서나 단위 테스트만 봐서는 알기 어려운 배포와 운영상의 문제도 겪었다. Fedify가 소셜 네트워크를 새로 만드는 데에만 쓰이는 것이 아니라, 이미 존재하는 웹사이트가 자기 모습을 유지한 채 연합우주에 합류하는 데에도 쓰일 수 있다는 것을 확인할 수 있었다.

Cloudflare Tunnel 다운로드 속도 100배 높이기 (QUIC → HTTP/2)

2026-07-09T22:40:00+09:00

수십억대의 장비에서 동작하는 DBMS엔진의 개발자, 리처드 힙(Richard Hipp)

2026-07-13T00:00:00+09:00

힙은 조지아 공대(조지아테크)에서 전기공학을 전공하고, 듀크대학에서 음성 자연어 대화 처리 시스템에 대한 연구를 수행한 후 전산학 박사 학위를 받습니다. 이후 AT&T 벨 연구소에서 스태프 엔지니어로 C/Unix 프로그래밍 관련 업무를 담당했으며, 이후 DARPA 및 제너럴 다이나믹스사 등 회사 고객에 맞춤화된 솔루션은 전문적으로 제공하는 Hipp, Wyrick & Company, Inc(줄여서 Hwaci라 쓰고, 와치라 읽습니다)를 설립합니다.

HWACI사는 2000년 봄 미 해군의 유도미사일 구축함 프로그램용 소프트웨어 개발 계약을 따냅니다. 이런 종류의 프로젝트에서는 데이터를 처리하기 위해 데이터베이스 시스템이 필요합니다. 기존에는 인포믹스와 같은 RDBMS를 따로 구축하여 사용했는데, 해군 함정에서 사용하기는 너무 번거로웠죠. 그래서 미 해군은 관리부담을 최소화시킨, 별도의 설정 작업 없이 배포할 수 있으면서도 안정적인 성능을 제공하는 내장가능한 SQL 데이터베이스 엔진을 요구합니다. 힙은 이 과제를 수행하기 위해 공개 도메인 데이터베이스를 개발하는데, 이것이 바로 SQLite의 시작입니다.

원래 미 해군이 개발하던 소프트웨어는 DDG-79 오스카 오스틴 전함에 탑재될 예정이었습니다. 이런 전함은 매우 크고 복잡한 시스템이빈다. 따라서 각 부품의 연결 정보 등을 기반으로 바뀌는 환경에 대해 바로 대응할 수 있는 제어/판단 시스템이 필요합니다. 그런 시스템의 기반에는 전함의 배관 정보 및 밸브 정보 등이 저장되어야 합니다. 그렇다고 전함에 DBMS를 설치하면 프로그램을 사용할 사용자 말고 DBA도 탑승해야 합니다. 그렇지 않으면 프로그램을 실행했는데 "데이터베이스에 연결할 수 없습니다"라는 경고창이 표시될 테니깐요. 이 문제를 해결하기 위해 리처드 힙이 뛰어듭니다.

미 해군의 요구사항은 SQLite의 핵심 기능이 됩니다. 서버리스 방식으로 작동하므로 별도의 서버 프로세스를 실행하지 않고 애플리케이션에 라이브러리 형태로 내장됩니다. 설정 파일도 지원되지만, 별도의 설정을 하지 않아도 내장하면 바로 사용할 수 있습니다. 데이터베이스 기능을 제공하지만 라이브러리의 크기는 900KB 보다 작은 크기로, 소형 단말에서도 자유롭게 사용할 수 있습니다. 그 덕분에 SQLite는 iOS/AOS 스마트폰, 웹 브라우저, 자동차, 의료기기 등 수많은 애플리케이션에 내장되어 역사상 가장 많이 배포된 데이터베이스 엔진으로 자리잡게 됩니다.

SQLite로 알려진 힙이지만, 여러 다양한 소프트웨어 프로젝트도 진행합니다. 그중에서 Fossile SCM은 git과 유사한 분산 버전 관리 시스템 소프트웨어입니다. SQLite 개발도 Fossil 기반으로 진행됩니다. 또한 Tcl 스크립트 언어의 발전을 위해 주요 확장 기능과 도구를 개발해 오고 있습니다. 트리 위젯, 노트북 위젯, HTML 위젯 등 다양한 Tcl/Tk 모듈을 개발해 왔습니다. (TCL의 아버지 존 아우스트하우트 이야기도 읽어보세요.)

복잡함은 당신의 적입니다. 최대한 단순하게 유지하세요
처음 떠오르는 해결책을 바로 사용하지 마십시오, 문제를 좀 더 생각해 보면 더 나은 접근 방법을 찾을 수 있는 경우가 많습니다.
코드, 특히 데이터 구조와 변수 정의에 대해 꼼꼼히 주석을 다세요. 다른 사람이 읽고 이해하여 유지 관리할 수 있는 코드를 작성하세요. 내용을 명확히 설명하세요.
테스트를 고려하여 설계하세요. 작동하는 소프트웨어를 작성하는 것만으로는 충분하지 않습니다. 검증이 쉽고, 작동 여부를 금방 테스트할 수 있는 소프트웨어를 작성해야 합니다.
(좋은 소프트웨어 설계 원칙에 대한 질문에 대한 답변)

인공지능은 분명 유용합니다. 앞으로 인공지능의 새로운 활용법이 발견될 것이고, AI기술은 귀중한 시간 절약 도구가 될 것이라고 확신합니다. 하지만 인공지능이 세상을 완전히 장악할 것이라는 종말론적 예측에는 회의적입니다.

문제를 만드는 것보다 더 많은 문제를 해결하세요.
할 수 있는 한 많은 문제를 해결하세요. 작은 일부터 시작하세요. 침대를 정리하고, 쓰레기를 주워 쓰레통에 버리고, 가게 계산원에게 친절하게 대하세요. 이런 작은 일들은 더 큰 문제를 해결하는 데 좋은 연습이 됩니다. 작은 일들에 익숙해지면 더 큰 문제에 도전해 보세요. 가족과 친구를 돕고, 고객을 돕고, 지역 사회에 기여하세요. 문제를 일으키는 것보다 더 많이 해결할 수 있다면, 직업, 친구, 사랑, 행복이 부족할 일은 없을 것입니다.

진정으로 자유롭고 싶다면 스스로 행동해야 한다는 뜻입니다.

풀 리퀘스트(PR)는 공짜가 아닙니다. 사실상 제게 요구를 하고 있는 겁니다. 이렇게 멋진 기능을 내가 개발했으니, 당신이 그걸 유지보수하고 문서도 작성하고 테스트하면서 계속 유지보수해 주길 바라는 겁니다.
리누스가 한 명언이 있습니다. Free라는 단어는 무료 맥주를 의미하거나 표현의 자유를 의미할 수 있습니다. 하지만 또다른 Free가 있습니다. '내가 공짜 강아지를 한마리 입양해 줄게"
풀 리퀘스트는 누군가가 당신에게 강아지 한마리를 입양해 주는 것과 같습니다. 당신은 그 강아지를 버릴 수도 없습니다. 도덕적인 책임감 때문에 강아지가 죽을 때까지 돌봐야 합니다.
나는 그런 공짜 강아지를 원하지 않습니다.

당시 전문가들에게 물어보면 "불가능해. 절대 안 될 거야. 말도 안 되는 생각이야."라고 했을 겁니다. 다행히 저는 그런 전문가들을 알지 못했고, 그래서 그냥 해냈습니다. 이런 일도 종종 일어나는 거죠. 제 생각에는 전문가들의 말에 너무 귀 기울이지 말고, 스스로 이치에 맞는 일을 하는 게 중요한 것 같습니다. 문제를 해결하세요.

Home Page for D. Richard Hipp

www.hwaci.com

The Untold Story of SQLite

On today's show, I'm talking to Richard Hipp about surviving becoming core infrastructure for the world. SQLite is everywhere. It's in your web browser, it's in your phone, it's probably in your car, and it's definitely in commercial planes. It's where you

corecursive.com

Entrevista a Richard Hipp

Creador de SQLite

camilocs.substack.com

미장 SK하이닉스 ADR이 과하게 비싼게 해소되나?(feat 7월 29일)

2026-07-16T07:10:00+09:00

SK하이닉스의 미국 ADR주식이 국장 본주보다.. : 네이버블로그 SK하이닉스의 미국 ADR주식이 국장 본주보다 비싼 이유에 대해서 두차례 글을 올렸다. 변화가 생겨서 A/S해본다. 2026년 7월 15일, 한국 예탁원이 언론 취재에 확인해주는 형태로 "7월 29일이후 상호전환을 추진하고 있다"는 내용을 밝혔다. 변화가 생겼고, 이말을 해석해 본다. 미국에 ADR을 발행한 곳으로 TSMC(대만)와 ASML(네덜란드)이 있다. TSMC는 대만 본주보다 미국 ADR이 평균적으로 16~17%정도 비싸게 거래된다. 반면에, ASML의 ADR은 네덜란드 본주와 가격차이가 1% 안팎으로 거의 나지 않는다. TSMC와 ASML의 가장 큰 차이는 ADR과 본주간 전환이 양방향 모두.......

호르무즈해협에 이어서 홍해까지 막히나?

2026-07-16T00:10:00+09:00

상황이 변해서, 정리해 봅니다. 2026년 2월 28일, 이란의 지도자 하메네이가 이스라엘의 표적 공습으로 일가족과 함께 사망함. 2. 전쟁 여파로 장례식을 치르지 못하다가, 미국과 휴전MOU를 체결하면서 사망 126일 만에 장례 절차에 들어감. 3. 하메네이 뿐만 아니라 폭격으로 사망한 장녀, 사위, 손녀, 그리고 아들 모즈타바의 아내 시신도 함께 안치됨. 4. 장례식은 7월 4일에 시작되어서, 하메네이의 고향이자 시아파 성지인 이맘 레자 성지에 안장하는 것으로 7월 9일에 마무리 됨. 5. 장례식에는 파키스탄 총리 샤리프, 러시아 안보회의 부의장이 참석했고, 하마스·헤즈볼라·탈레반 대표단도 조문 대열에 합류함. 6. 예멘의 실질적 지배자인.......

미국 CPI 결과가 잘 나왔고, SK하이닉스 주가는 폭등했다.

2026-07-15T07:20:52+09:00

CPI 7월 14일, 6월 CPI가 발표되었다. 결론을 먼저 이야기하면, 예상보다 큰 폭의 하락이다. 6월 CPI는 5월보다 -0.4%로 6년만에 가장 크게 하락했고, 시장 예상치(-0.2%) 보다 낮았다. 근원 CPI도 5월과 같은 수준이 나와서, 시장 예상치(+0.2%)보다 낮게 나왔다. CPI가 안정된 가장 큰 이유는 6월 17일 미국과 이란의 휴전으로 휘발유가 -9.7%로 내리는등 에너지 가격들이 크게 내린것이다. 하지만, 에너지 가격이 빠진 근원 CPI도 5월과 같은 수준이 나온것도 감안할 필요가 있다. 운송서비스와 중고차 가격들이 낮아졌다. 에너지 가격은 크게 하락하고, 다른 가격들도 현상유지는 한 것이 6월 CPI로 나온 것이다. 케빈 워시 연준의장도 이번.......

미국의 중국규제 3종세트로 배터리 3사가 힘을 낼 수 있을까?

2026-07-15T00:10:00+09:00

국제에너지기구는 전세계 데이터센터의 전력소비량이 2024년 415TWh에서 2030년 945TWh로 두배이상 늘어날 것으로 전망한다. 데이터센터가 미국 위주로 건설되고 있어서, 미국의 전력 소비량이 주로 영향을 받는다. 미국 전력망에는 여러가지 문제가 있다. 대형 변압기만 하더라도, 70%이상이 25년이상된 낡은 설비이고, 15%는 40년이상 사용해서 기대수명이 지난 상태다. 대형변압기는 신청후 3년내외가 걸려야 납품이 되는데, 데이터센터가 필요한 곳들은 전력망 증설을 느긋하게 기다릴 수 없는 상태다. 빅테크들은 데이터센터 옆에 가스 발전소를 건설하기도 하고, 신재생과 거대한 ESS설비를 함께 건설하는등 대안을 찾기 시작하고있다. ESS.......

미해군, 이란 해안선 해상봉쇄 발표, 트럼프, 통행료는 우리에게

2026-07-14T06:42:14+09:00

미 중부사령부는 "이란의 모든 항구,석유터미널,연안지역을 대상으로 국가와 무관하게 모든 선박에 대해서 미 동부시간 7월 14일 오후 4시(한국 시간 7월 15일 오전 5시)부터 봉쇄를 집행한다"고 발표했다. "봉쇄는 이란 해안선 전체(항구·석유터미널 포함)이며, 허가 없이 봉쇄구역을 드나드는 것으로 의심되는 선박은 요격·전환·나포 대상이고, 여기에 응하지 않는 선박은 무력으로 강제될 수 있다"고 한다. " 다만 호르무즈 해협을 통과하되 이란이 아닌 목적지를 오가는 선박은 괜찮고, 식량·의료품 같은 인도적 화물은 검사를 조건으로 이란 항구 도착이 허용된다"고 한다. 해상봉쇄(naval blockade)는 교전.......

엔트로픽과 알리바바의 AI 전쟁

2026-07-14T00:10:00+09:00

2026년 6월 10일, 앤트로픽은 알리바바와 관련된 고발 문서를 미국 상원에 제출하였다. "알리바바의 Qwen AI랩과 연계된 곳에서 클로드에게 역대급 디스틸레이션 공격을 벌였다"는 주장이 담긴 고발 문서였다. Qwen은 통이첸원(通义千问,의미를 깨닫아 천가지 질문에 답한다)이 정식이름이고, 알리바바가 개발하고 있는 AI모델이다. Qwen은 미국의 반도체 수출 통제속에서 훈련을 해야하고, 알리바바의 이익범위내에서 투자를 하다보니 한계가 있다. 한마디로, 돈과 설비가 모두 부족한 상황이다. 이런 불리한 상황에서도 2025년에 메타의 라마를 제치고 세계 1위 오픈 웨이트 모델이 되었다. 오픈 웨이트 모델이 생소할 수 있다. 클로.......

SK하이닉스의 미국 ADR주식이 국장 본주보다 비싼 이유 A/S

2026-07-13T17:30:00+09:00

미장에 SK하이닉스는 15%이상 올랐는데, 국.. : 네이버블로그 위 글을 썼는데 댓글에서 아래와 같은 비슷한 질문들이 몇개 나왔다. 그럼 미국ADR교환권을 한국에 가져와서 본주 가방으로 교환해가면, 교환권은 한국에 계속 쌓여가고 미국에는 교환권이 줄어드는 건가요? 흔싸귀비인가.. 교환권을 가지고 있는 것이, 비교적 더 많은 본주보다 더 매력적인 것인가.. 아니면 그것을 가지고 있는 곳에서의 가치가 다른 것인가.. ADR의 구조에 대한 추가설명이 필요해 보였다. 아래 나무색 내용은 기존글의 반복이다. 추가 설명을 쉽게 이해하려면, 반복이지만 한번 읽고 추가글을 읽는게 도움이 될 것 같아서 올렸다. 이미 충분히 이해를 했다면, 나.......

미장에 SK하이닉스는 15%이상 올랐는데, 국장은 왜 빠질까?

2026-07-13T11:28:36+09:00

홍콩이나 일본을 출장가면, 가끔 가방을 살 때가 있다. 한국에서 살 때보다 홍콩이나 일본에서 사면 싼 경우가 많기 때문이다. 물론, 내 가방은 아니다. 서울에서 700만원 하는 가방이 일본에서 500만원에 팔린다고 생각해 보자. 그러면 일본에서 500만원에 사서 서울에서 팔려는 사람들이 생긴다. 항공비등 비용을 빼고도 돈이 되는 것이다. 비행기를 타고 갈 필요가 없는 온라인 직구상품이면 가격차이는 더 줄어든다. 쉽게 공돈을 벌 기회가 생기면 사람들이 몰리기 때문이다. 이것을 차익거래라고 한다. 규칙이 하나 있다고 가정해 보자. 일본이나 홍콩에서 산 가방을 서울에서 팔 수 없다는 규칙이다. 오프라인은 공항에서 막고, 온라인은 세.......

새로운 스테이블 코인 등장, Open USD의 정체는?

2026-07-13T00:10:00+09:00

신상 스테이블 코인이 신박한 내용으로 등장을 해서 정리해 봅니다. 스테이블 코인은 테더와 서클로 양분되고 있음. 2. 이들이 돈을 버는 구조는 단순함. 3. 테더를 예로 들어 구조를 단순하게 정리하면, 테더의 계좌에 1달러를 입금하면, 테더는 1테더(USDT)를 교환해 줌. © CoolPubilcDomains, 출처 OGQ 4. 테더로 물건값을 지불하거나, 해외 자녀에게 유학자금을 테더로 송금하면, 그 자체로는 특별한 비용이 발생하지 않음. 5. 비용은 테더로 거래하는 과정에서 발생하지 않고, 테더를 다시 달러로 바꾸는 경우에 발생함. 6. 1테더(USDT)를 테더사로 보내면, 1테더는 소각되고, 테더사는 1달러를 은행 계좌로 입금해 줌. 7. 테더를 달러로 바.......

항서제약의 비밀

2026-07-12T12:00:38+09:00

HLB 간암신약 미국FDA승인 불발의 비밀 A.. : 네이버블로그 어제 HLB 간암신약이 미국 FDA 승인 관련 내용을 정리했습니다. 이해를 돕기위해, 이번 신약승인의 키를 쥐고있는 항서제약의 상황에 대해서 A/S해봅니다. 항서제약은 중국 제약사중 시가총액 1위로, 글로벌 Top25에 들어가는 대형 제약사임. 2. 이런 회사에 FDA의 cGMP(음식점으로 치면, 시설 위생검사) 지적이 계속 나오는게 이상할 수 있음. 3. 히스토리를 보면 이해가 가능할 수 있음. 4. 항서제약은 장쑤성의 국영 제약공장에서 시작된 회사임. 5. 병원에 값싼 주사제와 원료의약품을 납품하던 중소기업급 지방국영기업이었음. 6. 1990년, 난징대학 박사출신 연구자인 쑨퍄오양(당.......

중국이 반도체에 사용되는 헬륨을 수출금지한 속사정

2026-07-12T00:10:00+09:00

2026년 7월 10일, 중국 상무부와 관세청은 반도체 생산 공정의 핵심 소재인 헬륨에 대한 수출 금지 조치를 내렸다. 헬륨은 호르무즈해협이 막히면서, 아래 글에서 언급한 내용이다. 호르무즈해협이 막히면, 반도체용 희귀가스는 괜.. : 네이버블로그 1. 호르무즈해협 봉쇄가 오랫동안 지속되면, 헬륨도 문제가 될 수 있음. 2. 천연가스에는 헬륨이 섞여있는데, 천연가스를 -162도로 냉각해서 LNG를 만드는 공정에서 헬륨을 분리해 내고 있음. 3. 천연가스를 급랭하면, 메탄가스는 액체가 되어 바닥에 고이는데 이것이 LNG임. 4. 메탄은 액체 LNG가 되었지만, 헬륨과 질소는 아직 기체로 남아있게 됨. 5. LNG를 회수하고 온도를 다시 -196도까지 내.......

계란가격은 왜 이리 비싼가?

2026-07-11T11:00:00+09:00

주말이라 가벼운 내용입니다. 올해들어서 계란가격이 많이 오르고 있음. 2. 쿠팡 판매순위를 보면, 3위에 있는 풀무원 특란의 경우 15구에 만원가까운 가격이 나오고 있음. 3. 가장 큰 이유는 조류인플루엔자임. 4. 조류인플루엔자(H5N1)는 1996년 중국에서 처음 발견된 인플루엔자임. 5. 철새를 통해 중국에서 전 세계로 전파가 되었고 한국도 매년 발생하고 있음. © ccomzi, 출처 6. 조류인플루엔자는 계속 늘어나고 있음. 7. 2023-24년 32건이 발생했는데, 2024-25년에 49건으로 늘어났고, 2025-26년에는 62건까지 발생한 것임. 8. 2024년 10월~2025년 3월에는 살처분된 닭이 483만마리 였지만, 2025 10월~2026 3월에는 1,122만마리가 살처분.......

HLB 간암신약 미국FDA승인 불발의 비밀 A/S

2026-07-11T00:10:00+09:00

1~29번은 기존글 요약입니다. HLB 간암신약 미국FDA 승인 불발의 비밀 .. : 네이버블로그 1. 리보세라닙은 중국과 미국 제약사에 근무했던 중국계 미국인 G. Paul Chen이 만든 신약임. 2. 구명정등을 만들던 HLB(현대 라이프 보트)가 바이오에 뛰어들면서 리보세라닙의 판권을 확보하게 됨. © CoolPubilcDomains, 출처 OGQ 3. HLB가직접 신약을 개발한 것이 아니라, 특허와 판매 권리를 산것임. 4. 2019년 6월, 리보세라닙이 임상 3상에 실패함. 5. 리보세라닙 단독으로 진행된 임상에 실패한 HLB는 리보세라닙과 캄렐리주맙을 섞어 쓰는 칵테일 요법으로 재도전을 시작함. 6. 캄렐리주맙은 중국 항서제약이 만든 신약으로 면역세포가 암세포를 공.......

KB국민은행에서 시작되는 주담대 축소의 속사정

2026-07-10T07:22:49+09:00

KB국민은행은 7월 10일부터 주택구입자금 대출 최대한도를 6억원에서 3억원으로 축소한다고 발표했다. 현재 수도권,규제지역은 작년 6.27 가계부채 관리방안등으로 주택담보대출 상한이 6억원으로 제한되어 있다. 이번에는 6억원을 3억원으로 더 줄이는것이다. 주택구입자금 최대한도 3억원 제한은 수도권 규제지역만 적용되는 것이 아니다. 지방을 포함한 전국이 해당된다. 수도권,규제지역에는 여기에 주택 가격에 따른 차등한도가 추가된다. 15억원 이하 주택은 6억원 한도가 3억원으로 낮아지고, 15억 초과 25억이하는 4억에서 3억, 25억 초과는 2억이 그대로 유지된다. 예외는 있다. 이주비·중도금·잔금 등 집단대출, 기금대출(디딤돌·버팀.......

트럼프가 비료부족에 대응하는 흥미로운 보법

2026-07-10T00:10:00+09:00

올해 3월, 호르무즈해협 봉쇄로 미국 비료부족 사태를 예상했는데, 최근 근황을 업데이트해봅니다. 1~17번은 이론적인 설명이니 스킵해도 됩니다. 1. 식물 성장에 필수적인 영양소는 질소(N), 인산(P), 칼륨(K)이 메인임. © Karolina Grabowska, 출처 OGQ 2. 공기는 78%의 질소와 21%의 산소로 구성되어 있음. 3. 공기 중의 질소는 혼자 다니지 않고 반드시 두 개가 짝을 지어서 다니는데 (N₂), 두 개가 결합하는 방식이 문제임. 4. 일반적인 분자는 결합이 1개인데, 질소는 3개의 결합으로 묶여있음. 5. 식물의 뿌리는 질소의 3중결합을 해체할 수 없기 때문에, 공기 중에 질소가 아무리 많아도 흡수하지 못함. 6. 1909년 독일 화학자 하버가 공.......

오늘 우리 국장은? 오랜만에..

2026-07-09T07:16:22+09:00

당일 국장을 예측할때는 야간선물을 많이 이용한다. 야간과 선물이라는 단어가 붙어있어서 생소할 수도 있다. 선물은 "미래에 정해진 가격으로 사고팔겠다고 지금 미리 약속하는 계약"이다. 배추농부와 김치공장을 생각하면 된다 아직 배추는 밭에서 자라고 있지만, 배추농부와 김치공장은 3개월뒤 수확하면 배추 한포기를 2000원에 넘기겠다는 계약을 하는 것이다. 배추가 크는 도중에도 "농부는 배추값이 폭락할까 겁이나고, 김치공장은 배추값이 폭등할까봐 신경이 쓰인다". 미리 2000원으로 사고팔기로 약속을 해두면, 배추농부와 김치공장은 가격변동의 불안감에서 해방이 되는 것이다. 선물의 원래 목적인 헤지(위험회.......

국민연금 리밸런싱은 끝난것 같다. 그런데 국장은

2026-07-09T00:10:00+09:00

리밸런싱은 개인 투자자에게도 도움이 되는 투자방법이다. 개인적으로는 1년에 두번 리밸런싱을 한다. 종목별 비중조절을 하지 않아도, 리밸런싱만 정기적으로 하면 너무 많이 오른 종목은 자연스럽게 익절이 되면서 비중조절이 된다. 개인이든 기관이든 연기금이든 비슷하다. 한가지 생각해 볼 지점이 있다 개인이 펀드매니저에게 '이러이러한 범위내에서 운용하라'는 조건을 달고 돈을 맡겼다고 생각해 보자. 펀드매니저는 고객과 협의된 범위내에서 운용을 해야한다. 협의된 범위를 벗어나는 일은 하지 않든지, 아니면 고객에게 물어보고 하는게 원칙이다. 국민연금도 비슷하다. 1년간 이러이러한 범위내에서 국민연금을 운용하겠다.......

SK하이닉스와 삼성전자 2배짜리를 금융당국이 승인한 비밀

2026-07-08T07:12:37+09:00

2025년 5월, 홍콩 2위 ETF 운용사인 CSOP자산운용은 '삼성전자 2X 레버리지'와 '-2X 인버스'를 홍콩증권거래소에 상장을 했다. 삼성전자 하루 오르내림의 2배를 추종하는 상품으로 '한국 단일종목을 기반으로 하는 세계 최초 레버리지 ETF' 였다. 테슬라나 엔비디아의 단일종목 레버리지는 미국에 있었지만, 한국 대형주 하나를 2배로 추종하는 상품은 이때가 처음이었다. 상장을 한 곳이 서울이 아니라 홍콩인 것은 이유가 있었다. 한국은 'ETF 구성 시 단일 종목 비중을 30% 이내로 제한하고 최소 10종목 이상 포함을 의무화'하는 규제가 있었다. 한국에서 '삼성전자나 SK하이닉스 하나만으로 2배.......

삼성전자등 반도체 메가 프로젝트 근황 A/S (feat 물은 괜찮을까?)

2026-07-08T00:10:00+09:00

반도체 메가 프로젝트 근황 (feat 삼성전자.. : 네이버블로그 반도체 메가 프로젝트에 대한 글을 썼는데, 전기는 많이 언급 했지만, 물에 대해서는 간단하게만 짚었다는 댓글들이 있었다. 반도체에 필요한 물에 대한 내용과, 물을 간단하게만 짚은 이유을 정리해 본다. 반도체 공장에는 대량의 물을 사용함. 2. 사용되는 물의 2/3 정도는 일반 산업용수를 쓰고 있고, 1/3 정도는 초순수를 쓰고 있음. 3. 초순수(UPW, Ultra Pure Water)는 극한까지 정제한 물로, 이온성분을 없앴다는 의미에서 DIW(탈이온수)라고도 부르고 있음. 4. 초순수가 쓰이는 곳은 세정과 연마, 절단임. 5. 웨이퍼 부스러기를 씻어내거나, 잔류 이온을 제거하는데 주로 쓰.......

삼성전자 역대최고 영업이익 발표, 주가는?

2026-07-07T08:06:36+09:00

삼성전자 2분기 영업이익이 방금 발표되었다. 2분기 영업이익은 89조 4천억원으로 나왔다. 1분기에 57.3조원의 영업이익이 나왔었는데, 2분기는 꽤 더 성장을 했다. 예상보다 5~6조원정도 더 잘 나온 숫자다. 이번 영업이익에는 직원들 성과급이 반영되어 있다. 1년치가 모두 반영된 것은 아니고, 1분기와 2분기 15조원 정도(노무라 19조원, 키움 10조원 추정)가 반영된 것 같다. 성과급이 없었으면 100조원내외의 영업이익이 나왔을 것이다. 작년 2분기 삼성전자의 영업이익은 4.7조원 이었는데, 1년만에 89.4조원으로 1,810%가 늘어났다. 2026년 4~6월, 3개월동안에 171조원을 팔아서, 89.4조원을 남겼으니, 영업이익률이 대단해 보인다. 한줄.......

캐나다가 독일 잠수함을 선택한 속사정

2026-07-07T06:00:00+09:00

캐나다가 2026년 7월 6일(현지시각) 독일 TKMS의 Type 212CD를 우선협상대상자로 선정했다는 기사가 로이터에서 나왔다. 한화오션의 KSS-III(도산안창호급)는 최종 탈락한 것 같다. 독일 TKMS가 제안한 Type 212CD 잠수함은 약점들이 있었다. 아직 세상에 나온적이 없는 잠수함인게 가장 큰 약점이었다. 기존 212A의 차세대급라고 소개되고 있지만, 크기와 톤수가 다른 신형 잠수함이고, 이제 설계도가 나와서 건조가 시작되는 단계다. 2000년 2월, 그리스는 독일의 Type 214 4척을 발주한 적이 있었다. 1번함(초도함)이 2004년 진수를 했지만, 해상 시험에서 치명적인 결함들이 쏟아졌다. 가장 심각한 것은 바다가 거칠면 선체가 균형을 유지하.......

어떻게 베팅해야, 안전하면서도 빨리 불릴수 있는가?(feat 켈리공식)

2026-07-07T00:10:00+09:00

7월 1일, 미 정부 윤리청(OGE)은 트럼프의 소득을 공개했다. 재산이 아니라 1년간 벌어들인 소득을 공개한 것이다. 트럼프는 2024년에 6억 2200만달러의 소득을 신고했는데, 2025년에는 22억달러(3.4조원)를 소득으로 신고했다. 트럼프가 1년간 가장 돈을 많이 번 종목은 코인이었다. 트럼프는 $TRUMP라는 코인 10억개를 발행했고, 2025년 1월 17일 이중 2억개를 일반에게 풀었다. 나머지 8억개는 트럼프측 법인이 보유하며, 3년에 걸쳐서 순차적으로 풀리도록 설계했다. $TRUMP는 일반에게 푼 날로부터 2일후인 2025년 1월 19일 $74.27까지 올라갔고, 시가총액으로는 270억달러까지 나왔다. 트럼프는 본인 보유분중 8억개중 3700만개를 풀었고, .......

자사주 매입 알림을 받아보기

2026-07-15T08:00:31+09:00

자사주 매입 내역은 KIND 에 매일 공시가 됩니다.회사는 오늘 자사주 몇 주를 샀는지를 보고하고,내일 최대 몇 주를 사겠다는 것도 미리 보고 해야 합니다. 그런데... KIND의 화면은 너무나 보기가 불편한 게 문제죠. 이 정보들을 가장 잘 보여주는 서비스는 액티브홀더스 자사주 매입하는 회사 목록을 가지런히 보여주고, 매일 얼만큼 자사주를 구매하고 있는

텔레그램으로 공시 알림 받기 - 액티브홀더스 새 기능 추가

2026-07-14T21:01:00+09:00

텔레그램은 어느덧 투자자들에게 가장 친숙한 메신저가 된 것 같습니다. 사용자들이 봇을 만들어서 운영하기 쉽도록 설계를 잘해둔 덕분이 아닐까 싶네요. 액티브홀더스에도 텔레그램 봇을 통해 관심회사들의 공시를 알려주는 기능을 추가해봤습니다. 텔레그램은 액티브홀더스에 로그인 후 여기서 간단하게 연동할 수 있어요. 연동하고 나면, 관심 회사들의 공시 알림이 이렇

[Server] CLI를 위한 2가지 인증 방식, Authorization Code Flow와 Device Authorization Flow

2026-07-14T10:00:21+09:00

1. CLI를 위한 2가지 인증 방식, Authorization Code Flow와 Device Authorization Flow

[ Authorization Code Flow와 PKCE이란? ]

PKCE(Proof Key for Code Exchange, "픽시")는 OAuth 2.0의 인증 코드 가로채기 공격을 막기 위한 보안 확장이다. 기존의 OAuth 2.0의 인증 코드 플로우(Authorization Code Flow)에서는 인증 서버가 리디렉션을 통해 인증 코드를 클라이언트에 돌려주면, 클라이언트가 그 코드를 활용해 액세스 토큰으로 교환한다.

이를 위해 사용자는 인증 코드를 돌려받을 본인 서버의 리디렉션 전용 URI를 인증 서버에 사전에 등록을 해두어야 한다. 그러면 인증 서버는 인증 코드를 쿼리 파라미터에 실려 돌려주고, 클라이언트는 이에 접속해 코드를 획득하게 된다.

https://mangkyu.com/callback?code=AUTH_CODE_HERE&state=xyz

전반적인 Authorization Code Flow를 살펴보면 다음과 같다.

sequenceDiagram
    autonumber
    participant C as Client
    participant B as Browser
    participant A as Auth Server

    C->>B: 브라우저로 인증 요청 시작
    B->>A: 인증 요청 전달
    A-->>B: 로그인 페이지 제공
    B->>A: 사용자 로그인 및 동의
    A-->>B: 리디렉션을 통해 Authorization Code 반환
    B-->>C: Authorization Code 전달
    C->>A: Authorization Code로 Access Token 교환 요청
    A-->>C: Access Token 반환

하지만 바로 이 과정에서 문제가 생길 수 있다. 바로 악의적인 방법으로 인증 코드가 탈취당하는 것이다. 특히 스마트폰과 같은 기기에서는 다른 애플리케이션이 동일한 리디렉션 URI를 등록하고 인증 코드를 가로챌 수 있다. 그러면 권한이 없는 리소스에 대한 액세스 토큰이 발급되어 접근이 가능해진다. 따라서 이를 방지하려면, 처음 인증을 시작한 앱이 인증 코드를 잘 전달받아 액세스 토큰을 교환하는 주체인지 확인해야 한다. 이를 위해 “일회성 인증” 개념을 기반으로 하는 PKCE가 활용된다.

PKCE를 위해서는 크게 2가지 검증값이 사용된다.

code_verifier: 클라이언트가 매 요청마다 생성하여 활용하는 랜덤한 문자열
code_challenge: verifier를 특정 알고리즘으로 해싱하고 base64url 인코딩한 값

클라이언트는 인증을 시작하기 전에, 무작위 검증 코드인 code_verifier를 생성하여 로컬에 저장한다. 그리고 인증 서버를 통해 인증을 시작할 때, code_verifier를 code_challenge 값으로 변환하고, 변환한 방식(code_challenge_method, 보통 SHA256)과 code_challenge를 함께 보내면, 인증 서버는 이 값을 저장해둔다.

그리고 나중에 인증 코드를 액세스 토큰으로 교환할 때 원본 code_verifier를 함께 보낸다. 그러면 인증 서버에서 이전에 전달받은 code_challenge_method로 code_verifier를 code_challenge 값으로 변환하고, 이전에 전달받은 code_challenge 값과 일치하는지 비교한다. 그래서 맞으면 토큰을 발급하고, 틀리면 거부하는 것이다.

sequenceDiagram
    autonumber
    participant C as Client
    participant B as Browser
    participant A as Auth Server

    C->>C: code_verifier, code_challenge 생성
    C->>B: 브라우저로 인증 요청 시작<br/>(with code_challenge, code_challenge_method)
    B->>A: 인증 요청 전달
    A->>A: code_challenge 저장
    A-->>B: 로그인 페이지 제공
    B->>A: 사용자 로그인 및 동의
    A-->>B: 리디렉션을 통해 Authorization Code 반환
    B-->>C: Authorization Code 전달
    C->>A: Access Token 교환 요청<br/>(with Authorization Code, code_verifier)
    A->>A: code_verifier로 code_challenge 생성 후 저장값과 비교 검증
    A-->>C: 검증 성공 시 Access Token 반환

[ CLI와 Authorization Code Flow 방식 ]

문제는 Authorization Code Flow(+PKCE)가, 스마트 티비나 CLI와 같은 브라우저가 존재하지 않는 환경에서 활용이 어렵다는 것이다. 근본적으로 Authorization Code Flow는 인증 서버가 리디렉션 URI로 코드를 돌려주는 걸 전제로 한다. CLI가 인증을 요청할 때 인증 코드를 돌려받을 리디렉션 URI를 함께 지정하는데, 인증 서버가 그 URI로 코드를 보내주려 해도 CLI에는 그걸 받을 서버가 없다는 것이다.

따라서 CLI에서는 인증 코드를 돌려받기 위한 임시 HTTP 서버를 띄우고, 리디렉션 URI를 자기 루프백 주소(http://127.0.0.1)로 지정한다. 그리고 인증 코드 발급을 위해 CLI에 노출된 URL을 브라우저에서 로그인 후 이 주소로 리디렉션하면, 로컬에서 대기 중이던 CLI가 코드를 받아낸다.

sequenceDiagram
    autonumber
    participant C as CLI
    participant B as Browser
    participant A as Auth Server

    C->>C: 로컬 루프백 서버 기동 (예: 127.0.0.1:52741)
    C->>B: 브라우저 실행 + 인증 요청 <br/>redirect_uri=http://127.0.0.1:52741/callback
    B->>A: 인증 요청 전달 (redirect_uri 포함)
    A->>A: 등록된 redirect_uri와 일치 검증
    A-->>B: 로그인 후 redirect_uri로 리디렉션<br/>?code=AUTH_CODE&state=xyz
    B-->>C: 루프백 주소로 코드 전달
    C->>C: state 검증 후 code 추출
    C->>A: Authorization Code로 Access Token 교환
    A-->>C: Access Token 반환

하지만 억지로 HTTP 서버를 띄우다 보니, 여러 가지 부가적인 문제들이 생길 수 있다.

루프백 서버를 위한 포트 문제
- 서버의 포트를 위해 고정 포트를 사용할 경우, 다른 프로세스가 사용중일 때 충돌이 생김
- 동적 포트(비어 있는 포트를 골라 씀)로 하면, 인증 서버에 리디렉션 URI를 미리 등록해둘 때 포트를 특정할 수 없어 와일드카드 허용이 필요함
브라우저 실행 환경 문제
- CLI가 로그인 페이지를 열려면 브라우저를 띄워야 함
- 로컬 데스크톱이면 open/xdg-open/start로 열면 되는데 원격 SSH 세션, 헤드리스 서버, 컨테이너 안에서는 브라우저가 아예 없어 로그인이 불가능함
클라이언트 시크릿 문제
- CLI는 사용자 기기에 바이너리로 배포되는데, 여기에 클라이언트 시크릿을 심으면 누구나 추출할 수 있음
- 따라서 CLI는 시크릿을 못 쓰는 퍼블릭 클라이언트로 취급해야 하고, 코드 탈취 방어를 위해 PKCE가 필수가 됨

이러한 문제들로 인해, CLI를 위한 인증 방식으로는 Device Authorization Flow 방식이 권장된다.

[ Device Authorization Flow 방식이란? ]

Device Authorization Flow는 입력 기능이 제한된 스마트 TV 혹은 CLI와 같은 헤드리스 앱을 위해 설계된 OAuth 2.0 인증 부여 방식이다. 사용자가 이러한 디바이스에서 인증 요청을 시작하면, 스마트폰이나 노트북 등과 같은 더 많은 입력 기능을 가진 디바이스에서 프로세스를 완료할 수 있다. 예를 들어 우리가 스마트 TV에서 넷플릭스를 보기 위해 로그인을 할 때, 코드를 입력하는 방식이 바로 Device Authorization Flow라고 볼 수 있다.

Device Authorization Flow 인증 방식을 위해서는 크게 2가지 코드(Device Code, User Code) 개념이 등장한다.

User Code (사용자 코드)
- 사람이 읽고 입력하는 코드로, 이를 기반으로 로그인을 시도하는 당사자가 맞는지를 확인함
- 8자 내외, 대문자, 하이픈으로 구분되어 짧고 타이핑하기 쉽게 만들어짐 ex) WDJB-MJHT
- 인증 서버는 짧은 만료 시간과 시도 횟수 제한으로 무차별 대입을 막음
Device Code (디바이스 코드)
- CLI나 스마트 TV 등의 기기가 쓰는 코드로, 사람은 볼 일도, 입력할 일도 없음
- 로그인을 시도하는 기계를 식별하기 위해 사용됨
- 사람이 타이핑하지 않으니 길고 복잡해도 되어 긴 문자열이 사용됨

전반적인 인증 흐름 과정을 살펴보면 다음과 같다.

sequenceDiagram
    autonumber
    participant U as User at browser
    participant D as CLI
    participant A as Auth Server

    D->>A: Client ID로 인증 요청
    A-->>D: Device Code, User Code, 인증 URI를 제공함
    D->>U: 사용자에게 인증 URI를 열고 User Code를 입력하도록 지시함
    D->>A: Device Code와 Client ID로 Access Token 폴링 시작
    U->>A: 인증 URI 접속 및 User Code 입력
    A-->>U: 사용자를 로그인 페이지로 리디렉션
    U->>A: 로그인 플로우 완료 및 로그인
    A-->>U: 사용자를 로그인 성공 페이지로 리디렉션하고 브라우저를 닫도록 지시
    A-->>D: 폴링 결과로 Access Token을 반환받음

Device Authorization Flow 인증 방식을 사용하면, CLI 환경에서 Authorization Code Flow 인증 방식을 사용할 때 생겼던 여러 가지 문제로부터 자유로워질 수 있다. 토큰을 요청하는 CLI와 사용자가 인증하는 브라우저 장치를 분리해, 포트 바인딩이나 로컬 브라우저 의존이 없다. 또한 노트북이나 컨테이너, CI 등 어디서나 동일하게 작동할 수 있다.

참고 자료

가짜 창업가

2026-07-16T06:45:00+09:00

어원은 불어지만, 창업가를 뜻하는 공식 영어는 ‘entrepreneur’이다. 그리고 한국에서는 잘 사용하지 않지만, 반대말인 ‘fauxtrepreneur’라는 비공식 단어도 있다. ‘Faux’가 불어로 ‘가짜’라는 의미인데, 해석 그대로 가짜 창업가를 뜻한다.

가짜 창업가들의 시대가 다시 왔다. 요새 미국에서 다른 투자자들과 이야기하면, 이 fauxtrepreneur라는 단어가 대화에서 자주 언급되는데, 그만큼 한국이나 미국이나, 전 세계적으로 가짜 창업가들이 넘쳐흐르고 있다는 증거인 것 같다. 물론, 가짜 창업가들은 항상 존재했고, 지금 존재하고, 앞으로 존재할 것인데, 요샌 AI로 인해 과거 그 어느 때보다 많은 사람들이 회사를 시작하고 제품을 만들면서 진짜 창업가와 가짜 창업가들이 시장에 걷잡을 수 없을 정도로 쏟아지고 있다.

AI 기술과 제품으로 인해 이젠 누구나 모든 걸 만들 수 있다. 나 같이 코딩을 못 하는 사람도 바이브코딩 며칠만 하면 뚝딱하고 그럴싸한 제품을 만들 수 있는 걸 보면, 누구나 다 시간과 에너지를 투자하면 그 어떤 제품도 만들 수 있을 것이다. 하지만, 내가 바이브코딩해서 만드는 제품은 시장에 진짜로 존재하는 문제를 깊게 해결할 수 있는 기능은 없고, 돈을 제대로 벌 수 있는 비즈니스 모델도 없는, 껍데기 제품이다. 실제로 바이브코딩으로 만드는 대부분의 제품이 그럴싸한 껍데기만 있는 깡통 제품일 확률이 높다. 이렇게 대충 만든 제품으로 투자받는 세상이 온 걸 보면 가끔은 나도 놀랄 때가 있다.

창업의 진입장벽이 낮아진 건 확실하다. 과거에는 창업하고 싶어도 개발을 못 하면 개발할 수 있는 코파운더를 찾거나 직접 배워야 했고, 이게 창업의 큰 진입장벽으로 작용했다. 하지만 이젠 누구나 다 AI로 제품을 만들 수 있어서 나이, 경험, 학력과 상관없이 본인이 하고 싶은 것을 하기 위해서 회사를 설립하고, 제품을 만들고, 창업할 수 있다. 실은 이렇게 창업의 장벽이 낮아진 건 우리 같은 투자자들에겐 희소식이다. 스트롱이 한국에 투자한 지 15년이 됐는데, 이렇게 똑똑하고, 야심차고, 자신감 있는 창업가들이 지금같이 많았던 적이 없었던 것 같다. 그리고 이들의 나이는 점점 더 어려지고 있다. 투자할만한 창업가가 없는 문제는 없어진 지 오래됐고, 이젠 다 투자하고 싶은데 예산이 한정됐다는 게 문제다.

하지만, 이 현상이 좋기만 하진 않다. 실은, 부작용 투성이다. 넘쳐흐르는 창업가들과 조금만 더 자세히 이야기해 보고, 이들이 만든 제품을 조금만 더 자세히 들여다보고, 이들에 대해서 조금만 더 알아보면 가짜 창업가가 상당히 많다. 제대로 된 사업을 만들고 싶어서 사업하는 창업가보단, 그냥 요새 AI 관련된 사업을 하면 투자받기 쉬운 환경이라서 창업하고 투자 좀 받은 후, 한 2~3년 후에 적당히 엑싯하거나 사업이 잘 안되더라도 이력서에 “AI native 회사를 창업해서 스트롱벤처스로부터 투자유치” 경력을 추가하면 구인시장에서 프리미엄을 받을 수 있다고 생각하는 분들도 많을 것이다.

이런 창업가들은 실은 항상 존재했는데, 바이브코딩 전에는 꽤 높은 정확도로 가짜 창업가를 구별하는 게 가능했다. 이젠 모두 다 너무 그럴싸한 제품 껍데기를 만들고, 모든 것을 다 AI에 물어보고 준비해서인지 이들을 구분하는 게 상당히 어려워졌다.

요새 내가 제일 힘든 건, 진짜 사업을 하기 위해 창업하고, 이 고통스러운 여정을 최소 10년 이상 할 각오가 되어 있는 진짜 창업가와 그냥 AI라는 테마로 상대적으로 쉽게 투자받고, 몇 년 해보자는 생각으로 창업하는 가짜 창업가를 구별하는 것이다. 실은 점점 더 어려워지고 있지만, 시간이 지나면서 이 또한 스스로 정화되고 정리될 것이라고 믿는다.

너도나도 AI라는 아주 화려한 재킷을 입고 다닌다. 문제는 모두 다 그 화려한 재킷이 얼마나 이쁘고 멋진지 칭찬하지만, 그 누구도 그 재킷 안에는 뭘 입었는데 안 물어본다는 것이다. 실제로 재킷을 벗으면 그 안에는 아무것도 안 입은 발가벗은 가짜 창업가들이 대부분이다. 이런 시대일수록 우린 본질을 파악할 수 있는 의지와 인내심이 필요하다.

새로운 고객획득비용 공식

2026-07-13T06:33:00+09:00

바로 이전 글에서 말한 대로 앞으로 네이버나 구글 같은 전통적인 검색 엔진보다 ChatGPT나 클로드를 활용한 AI 검색을 통한 고객 유입이 대세가 될 것으로 생각한다. 물론, 이렇게 안 되고 앞으로도 계속 우리는 네이버와 구글을 사용할 수도 있겠지만, 만약에 AI 검색이 전통적인 검색을 완전히 대체한다면, 모든 스타트업이 마케팅의 판 자체를 새로운 시각에서 봐야 할 것이고, 이전과는 다른 전략을 수립해야 할 것으로 생각한다.

일단 고객 획득 방법과 고객획득비용(CAC)을 전면적으로 재검토해야 한다. 고객을 획득하기 위해 기존에 하던 전통적인 퍼포먼스 마케팅은 구글, 네이버, 유튜브, 메타 등에서 계속 해야 하는데, 동시에 AI 검색을 위한 최적화 작업도 해야 한다. 즉, CAC는 올라가면 더 올라가지, 떨어지진 않을 것이다.

지금까진 이렇게 해서 고객을 획득하고 ROAS를 잘 관리하면 돈을 벌 가능성이 꽤 높았다. 고객을 아무리 비싸게 확보해도, 이들이 그보다 더 많은 돈을 우리 제품을 구매하는 데 사용하면 나름 잘 작동하는 마케팅 공식이 있었기 때문이다.

하지만, 점점 더 많은 제품과 서비스가 AI를 적극적으로 도입하면서 과거에는 없던 비용 항목이 생기고 있는데 바로 토큰 비용이다. 고객을 우리 서비스로 데려오기 위해서 여전히 마케팅에 돈을 많이 써야 하는데, 이들이 우리 서비스를 많이 사용하면 할수록 이젠 토큰 비용이 추가로 발생해서 이전에는 하지 않았던 다른 차원의 고민을 해야 한다.

SEO, AEO, GEO를 잘해서 트래픽이 폭주하면, 그리고 제품을 잘 만들었다면, 우리 매출도 증가하지만, 동시에 고객 획득 비용과 토큰 비용 두 가지가 모두 폭발적으로 증가할 텐데 이 문제는 어떻게 해결할 것인가?

과거에도 트래픽이 폭주하면 인터넷망 비용이 발생했고, 서버 비용이 발생했다. 이후 규모의 경제가 만들어지면서 망과 서버 비용은 증가한 트래픽으로 버는 매출 대비 무시할 수 있을 정도로 낮아졌고, 어쩌면 AI 토큰 비용도 앞으로 시간이 지나면서 비슷한 방식으로 줄어들 것이다. 하지만, 당장 낮아지진 않을 것이라서 모든 창업가는 고객 획득 비용을 새로운 각도에서 볼 필요가 있다.

고객 획득 부분에서는 오가닉 마케팅 기법을 강화하고 AI 검색 엔진이 가장 좋아하는, 돈이 상대적으로 덜 필요한 콘텐츠 마케팅을 고도화해야 한다. 블로그 마케팅이 가장 효과적인 콘텐츠 마케팅이긴 한데, 이건 스케일 하려면 시간이 정말 많이 필요하고 대부분 그 전에 포기하거나 망한다. 고객을 획득한 후에는 이들이 우리 서비스를 미친 듯이 사용하게 만들어서 매출을 극대화하고, 매출이 증가할수록 늘어나는 토큰 사용을 최적화해야 한다. 아마도 GPU와 NPU를 적절하게 사용하는 방법이 있을 것이고, 비싼 파운데이션 모델과 싼 모델을 같이 사용하면서 토큰 비용을 최소화하는 방법도 있을 텐데, 앞으로 창업가들이 이 재미있지만, 어려운 과제를 어떻게 풀지 매우 궁금하고 기대된다.

어쨌든 이젠 고객 획득 비용에 대한 다른 공식이 필요하다. 고객 모집과 토큰 사용 모두에 대해서.

AI 검색과 퍼널 관리

2026-07-09T06:35:00+09:00

가트너와 같은 시장 조사 기관의 자료를 보면 앞으로 몇 년 후엔 사람들이 구글이나 네이버와 같은 검색엔진보단 AI를 통해 모든 것을 검색할 것이라고 한다. 이게 3년 후일지, 10년 후일진 나도 모르겠지만, 요즘 트렌드를 보면 그냥 시간의 문제일 뿐, 궁극적으론 챗GPT와 클로드와 같은 AI 서비스가 구글과 네이버를 대체할 수 있다고 생각한다. 물론, 구글과 네이버도 이런 변화를 잘 감지하고 있고, 본인들도 AI 검색엔진으로의 변화를 시도하고 있지만, 너무 오랫동안 검색과 광고 시장에서 돈을 너무 잘 벌던 회사라서 그런지 이 전환이 생각보다 빠르게 일어나지 않고 있다.

나는 검색할 때 여전히 구글과 네이버도 사용하지만, AI도 적절히 사용한다. 하지만, 데이터를 보면 점점 더 많은 사람이 AI를 더 많이 사용하고, 챗GPT와 클로드를 AI 생산성 툴 또는 바이브코딩 플랫폼으로 잘 활용하는 사람도 많지만, 아마도 시장의 절대다수인 일반인들의 머릿속에는 이 두 개의 제품이 ‘검색엔진’으로 자리 잡고 있을 것이다.

최근에 AI 검색으로 제품을 발견한 고객은 실제로 그 제품을 구매할 확률이 매우 높다는 내용의 기사를 읽었다. 즉, AI 검색으로 제품을 발견하는 고객의 구매전환율은 일반 검색을 통해 같은 제품을 발견하는 고객의 전환율보다 높다는 의미인데, 크겐 거의 두 배 이상의 차이가 난다고 한다. 나도 생각해 보니, 지난주에 AI로 검색한 제품이 5개였는데, 이 중 5개를 모두 구매했다. 네이버로 검색했으면 이 중 하나 정도 구매하거나 아니면 아예 구매하지 않았을 텐데 AI 검색의 전환율은 왜 이렇게 높은 것일까?

더 생각해 보고, 더 읽어보니 – AI 검색 포함 – 고객의 여정이 시작되는 구매 퍼널의 위치에서 큰 차이가 발생하는 것 같다. 예를 들어보면, 내가 러닝용 티셔츠를 구매하고 싶은데 네이버로 검색하면, “러닝용 티셔츠. 가볍고 통풍성 좋아야 함. 가격은 10만 원대” 뭐, 이런 키워드를 입력할 것이고, 여기에 해당되는 제품, 회사 링크, 그리고 블로그가 검색 결과로 나열될 것이다.

그러면 나는 이 중 하나를 클릭해서 들어갈 것이고, 쇼핑몰 사이트면 판매하는 제품을 보고 바로 나갈 수도 있고, 특정 제품 상세 페이지로 들어갈 수도 있다. 제품 상세 페이지로 들어가서 상품 설명을 보고 내가 찾던 제품이면 구매할 수도 있지만, 십중팔구 내가 원하던 딱 그 상품이 아닐 것이다. 그러면 다시 처음부터 네이버로 검색을 반복한다. 이런 과정이 반복되니 전환율이 떨어질 수밖에 없다.

하지만, AI 검색을 하면, “요새 핫한 러닝용 티셔츠 추천해 주세요.”(맞다, 나는 AI한테 항상 예의 바르게 존댓말을 한다)로 시작하면 AI가 계속 더 구체적인 질문을 한다. “어떤 걸 중요하게 생각하시나요? 기능성인가요? 패션인가요?” 등. 그리고 AI와 대화할수록 더욱더 정교한 질문을 하고, 이전 대화로부터 내 성향과 취향을 기억하고 있다면, 이를 활용해서 내가 개인적으로 좋아할 만한 소수의 제품을 추천해 준다.

그러면 나는 이 링크를 클릭해서 그 제품의 상세 페이지로 바로 갈 것이다. 그리고 이미 나는 AI에 많은 걸 물어봤고, 나와의 대화를 통해 내 취향에 맞는 제품을 추천해 줬기 때문에, 내가 딱 좋아할 만한 제품일 확률이 상당히 높다. 그러면 이 제품을 구매할 확률이 매우 크기 때문에 구매 전환율이 확 올라가는 것이다.

즉, 네이버로 검색하면 구매 퍼널의 맨 꼭대기에서 고객의 여정이 시작할 확률이 높지만, AI로 검색하면 구매 퍼널의 중간 또는 하단에서 고객의 여정이 시작될 확률이 높아서 전환율이 자연스럽게 높아진다는 의미다.

또한, 정확한 이유는 모르겠지만, AI는 여러 가지 제품을 판매하는 플랫폼/마켓플레이스보다 자사몰로 더 많은 트래픽을 보내준다고 하는데, 이렇게 되면 전환율만 높아지는 게 아니라, 브랜드에 대한 충성도 또한 높아져서 이커머스 업체들에겐 여러 가지 면에서 유리한 환경이 만들어질 것이다. 어쨌든 구매 퍼널의 후반부에 있는 고객들을 자사몰로 보낸다는 건 이커머스 업체들에겐 엄청난 축복이다.

하지만 아직은 AI가 누구에게, 어떤 고객을, 어떤 방식으로 보낼지, 또는 보내고 있는진 아직은 미지수이다. 여기서 아마도 AI 회사들이 광고비를 더 많이 내는 사이트로 트래픽을 더 많이 보내면서 비즈니스모델을 만들 수 있지 않을까 생각한다.

앞으로 AI가 일반 검색을 대체하게 되면 구매 전환율이 지금보다 훨씬 높아질 것이고, 이럴수록 좋은 제품을 만드는 경쟁은 심화할 것이다. 정말로 잘하는 서비스와 제품들의 전환율이 그렇지 못한 회사보다 압도적으로 높아질 것이고, 이 경쟁에서 뒤떨어지는 회사들은 아예 사라지지 않겠느냐는 생각도 해 본다. 결국 AI 검색이든 AI 검색이 아니든, 좋은 제품을 만드는 회사들이 항상 이긴다는 건 불변의 진리인 것 같다.

플래시: 저, 잡스 편지 한 장에 갔습니다 - 은퇴한 IT들을 인터뷰했습니다 - 4화

2026-07-15T00:50:48+09:00

이번 인터뷰이는 이 시리즈 최초의 고인이다. 2020년 12월 31일에 공식 사망했으니, 섭외가 불가능한 줄 알았다. 그런데 수소문 끝에 연락이 닿았다. 요즘 젊은 친구들이 에뮬레이터라는 박물관에서 그를 종종 꺼내 보고 있어서, 완전히 떠나지는 못했다고 했다. 인터뷰 당일, 그는 등장부터 포스가 남달랐다. 스튜디오 문이 열리기 전에 문 위로 게이지가 먼저

네이버 vs 다음: 원조 라이벌 대담 - 은퇴한 IT들을 인터뷰했습니다 - 3화

2026-07-14T02:36:00+09:00

이 대담을 준비하면서, 두 분의 관계가 궁금해서 검색부터 해봤다. 네이버에 '다음'을 검색하고, 다음에 '네이버'를 검색했다. 서로가 서로를 소개하는 문장은 놀랍도록 건조했다. 27년째 같은 동네에서 일한 사이라기엔, 너무 예의 바른 남남이었다. 그래서 두 분을 한 테이블에 앉혀보고 싶었다. 섭외 전화부터 온도가 달랐다. 다음은 삼십 분 넘게 통화하며 묻

도토리: 제가 최초의 디지털 화폐였죠 - 은퇴한 IT들을 인터뷰했습니다 - 2화

2026-07-13T01:02:26+09:00

두 번째 인터뷰이는 화폐다. 지폐도 동전도 아닌데 한때 대한민국에서 하루 3억 원어치씩 거래되던 화폐. 섭외 자체는 어렵지 않았다. 문제는 장소였다. 어디로 찾아뵈면 되냐고 물었더니, 한참 뜸을 들이다 이런 답이 돌아왔다. "그게... 저도 제가 지금 어디 있는지 잘 모르겠어요." 수소문 끝에 만난 곳은 어느 서버 창고라고 해두자. 20년 치 추억,

공인인증서: 저도 시대의 피해자입니다 - 은퇴한 IT들을 인터뷰했습니다 - 1화

2026-07-10T20:09:56+09:00

저는 11년째 디지털 화면을 디자인 하고 있습니다. 그런데 언제부턴가 이상한 버릇이 생겼어요. 매끈한 요즘 화면들을 보다가 문득, 사라진 것들을 떠올리는 겁니다. 도토리는 잘 지내나. 그 많던 팝업창들은 다 어디로 갔나. 액티브 X... 아니, 걔는 안부가 궁금하진 않고요.역사책을 쓸 실력은 안 되고, 그렇다고 궁금한 걸 참는 성격도 아니라서, 그냥 직접

배포 다음 날이 진짜? 스프린트 4기 프로젝트 이야기 - 스프린트 4기, 대표 프로젝트 3선

2026-07-08T21:34:46+09:00

AI로 뭐라도 만들어봐야 할 것 같은데 어떻게 진행해야 할까요? 요즘 코칭에서 가장 많이 받는 질문인데요. 사실 답은 간단합니다. 포폴로서의 가치는 만들고 나서부터가 시작이거든요. 배포한 서비스에 실제 사용자가 들어오고, 그 사용자가 어디서 이탈하는지 데이터로 확인하고, 다음 개선을 결정하는 것. 이 사이클을 한 바퀴라도 돌려본 디자이너와 그렇지 않은 디

돈되는 회사

2026-07-15T09:46:48+09:00

'장원영 렌즈'로 알려진 하파크리스틴 운영사 피피비스튜디오스가 사모펀드에 1,400억 원에 팔린다. 테크 회사들의 조 단위 뉴스에 가려져 있지만, 뷰티 소비재 판에서는 이런 딜이 계속 일어나고 있다. 현금을 벌고, 빠르게 크고, 주인이 계속 바뀌는 회사들. 매수자는 사모펀드 KLN파트너스다. KLN은 맘스터치 운영사다. 2019년 맘스터치를 약 2,000억에 인수해 상장폐지 후 일본, 동남아로 확장했고, 현재 기업가치 1조 원 수준을 거론하며 매각을 진행 중. 지난해에는 마녀공장 지분 51.87%를 1,900억에 인수. 국내에서 검증된 브랜드를 사서 해외 유통을 붙이는 같은 플레이북을 운영중에 있다. 성장 속도가 압도적이다. 연결 매.......

오해

2026-07-14T00:34:24+09:00

어떤 방식으로든 에너지를 분출해내야만 살아갈 수 있겠다는 생각이 들 때가 있다. 아니, 생각이라기보다는 그냥 그래야만 하겠다는 상태에 가깝다. 딱히 엄청난 계산을 하고 움직인다기보다는 그저 나도 모르게 신발 끈을 묶고 있거나 책상 앞에 앉아서 노트북을 열고 타자판을 두드리거나 그러고 있는 것이다. 그렇게 해내야만 잠에 들 수 있을 것 같아서 그럴 때가 있다. 오해를 받는 것은 슬픈 일이다. 그리고 그것을 굳이 설명할 힘조차도 없을 때는 더더욱 슬프다. 최소한의 친절함은 그저 가만히 있는 것이다. 오해를 풀어주거나 혹은 그 오해에 대해서 대응할 정도의 가치도 느끼지 못한다. 각자가 각자의 세상에서 살아가는 것이다. 각.......

슈퍼파워 (vooy)

2026-07-13T09:54:03+09:00

연예인들을 눈앞에서 보는 느낌이었다. 항상 팔로우하던 테크 유튜버, 백만 인플루언서들, 모델들 어떻게 한자리에 다 모았나 싶다. 몇 년 전만 해도 인플루언서라고 불렸다. (그 전에는 파워블로거) 디지털 세상에서 콘텐츠를 만드는 게 직업이라고 인정받지도 않았다. 그런데 미스터비스트가 나왔고, 조 로건이 나왔다. 대통령이 팟캐스트에 나가는 시대다. 세상이 바뀌었다. 각자 한 명 한 명이 개성이 있고, 스토리가 있고, 강력한 팬들이 있다. 아직 정의되지 않은 직업이라고 생각한다. 하는 고민들이 다르지만 유사한 점이 많았다. 콘텐츠 크리에이터로서 전문성도 있지만, 사업가로서는 초보이기도 했다. 이번 행사는 ‘부이’ 주도로 해.......

AI 멀티플

2026-07-12T22:47:37+09:00

일본 인디 개발자 2명이 대박을 쳤다. 2명이서 게임 하나로 600억 넘게 벌었다고 한다. 로또 몇 배짜리다. 건물 몇 개 살 수 있겠다. 주인공은 일본의 인디 개발자 레모리온, 하가네이로다. 게임을 만들었고, 스팀에 올렸다. 2026년 6월 10일 스팀(Steam) 출시 후 4일 만에 100만 장, 16일 만에 1,000만 장, 한 달이 채 안 된 7월 5일에 1,500만 장 판매를 돌파했다. 스팀 글로벌 판매 1위, 동시접속자는 24만 명을 넘겼다. 엄청 간단한 게임이다. 하얀 캐릭터의 몸에 배경과 똑같은 색과 무늬를 칠해 위장하고, 총을 든 술래를 피해 숨는다. TV 예능에 나온 '보디페인팅 위장술'에서 아이디어를 얻었다고. 단 2명, 전부. 한 달 만에 중.......

희소성

2026-07-12T00:02:21+09:00

일본에서 사업하시는 사장님이랑 대화. 재미있었던 거 몇 개... 1. 일본 좋은 부동산은 시장(매물)로 절대 안나옴. 미공개물건(未公開物件)은 업자들 공유 데이터베이스에조차 안 올라가고, 매각 의뢰 받은 회사 한 곳이 조용히 쥐고서 자기 고객한테만 돌린다고 함. 입지가 좋아 매수자 수요 쌓여있는 곳들은 일반 공개 전에 사실상 매수자 다 결정된다고. 하이엔드로 갈수록 클로즈드, 혹은 세미클로즈드로 매각되는 게 전부. 한국보다 더 심하다고 함. 2. 그 네트워크 들어가는 게 핵심. 도심 일등지 대규모 토지나 역사 저택은 매각 자체 정보도 안흐르고 희소가치도 높아서 그냥 네트워크 내에서만 돈다고. 비공개 물건 소개 받으려면 수억.......

공간

2026-07-10T00:42:44+09:00

요즘 쓰는 오피스. 층고가 높고, 오후엔 해가 길게 든다. 공간은 중요하다. 트인 공간에서만 열리는 생각이 분명히 있다. 몇 달 미뤄둔 문제 하나가 정리됐다. 책상 앞에서 백날 붙잡고 있어도 안 풀리던 게, 자리를 옮기니 다르게 보였다. 보고 듣고 느끼는 감각 자체를 바꿔야 한다. 환경에 대한 투자는 아깝지 않다. 집, 오피스, 가구, 조명. 당장은 큰 비용처럼 보이지만... 인간은 단기적인 관점으로 눈앞의 비용을 과대평가 하니까... 좋은 환경은 비용 아니라 투자다. 매달 나가는 비용 아니라, 매일 쌓이는 생각의 질로 계산해야 한다. 더 큰 생각, 새로운 생각은 그런 환경에서만 찾아온다. 좋은 환경 만들어야 한다. 더 좋은 생각을 할.......

플라우드 한 달 후기

2026-07-07T10:49:54+09:00

* 플라우드 한 달 후기를 적습니다. 사용하며 효율성이 매우 오르기도 했지만, 그 이상 배운 것들이 있어 기록으로 남깁니다. 플라우드 한국 유통사의 지원도 받았습니다. 맨 하단에 이벤트가 있으니 도움 되시면 좋겠습니다. 제 서랍에는 비싼 기계들이 많습니다. 살 때는 다 인생을 바꿔줄(?) 기대로 샀던 물건들입니다. 하나같이 2주를 못 넘기고 서랍으로 갔습니다. 액션캠도 있고요. 스마트 링, 고급 팟캐스트용 마이크도 있고요. 여러 이유로 사기는 많이 사는데, 일상에 녹아들어 살아남는(?) 녀석들은 적네요. 지난달에는 AI 노트테이커 플라우드(Plaud)를 샀습니다. 결론부터 말하면, 서랍으로 들어가지 않았습니다. ㅎㅎ. 한 달째 살아.......

[커리어노트 196]왜 기업들은 디자인에 투자하지 않을까? (그리고 디자이너의 생존법)

2026-07-11T15:43:40+09:00

최근 현업에서 일하는 UX 디자이너들에게 자주 듣는 고민이 있다. 'AI가 내 직업을 대체하는 게 아닐지', '다른 직군이 디자인 영역까지 커버하게 되지 않을지', 혹은 'AI로 만들면 다 고만고만하게 비슷한 디자인이 나오는 건 아닌지'하는 불안들이다. 원래도 디자이너라는 직군의 잡시큐리티가 개발 직군에 비해 낮은 편인데, AI의 급격한 발전으로 그 고민과 불안이 훨씬 커진 듯하다. 스타트업 멘토링을 하다 보면 디자이너가 아예 없거나, 주니어 디자이너 한두 명으로 꾸려진 경우를 흔하게 접한다. 나 또한 첫 번째 직장에서 한동안 1인 디자이너로 일했던 경험이 있다. 왜 기업들은 디자인에 적극적으로 투.......

부동산 정책 국민 대토론회 풀영상 시청 및 발표자료 살펴보기

2026-07-15T23:40:00+09:00

어제 열린 대국민 부동산 토론회 국토교통부편에 이어 오늘 진행된 금융위원회편 풀영상을 시청했다. 부동산 정책이 사회갈등이 되는 이유는 서로의 포지션이 다르고 지식수준이 완전히 다르기 때문이다. 주식시장의 정책을 정할때는 주식을 거래해본 사람들이 참여하지만 부동산 정책에는 임차인과 임대인의 입장이 다르고 특정 거래를 해본사람과 해보지 않은 사람의 지식수준이 완전히 다르다. 그러다보니 갈등의 소지가 많고 본인의 의견과 다르다면 이를 이해하기 어려운 문제가 발생한다. 그렇기에 정부가 중심을 잡고 사회 전체 이익을 위해 정책을 설계해야 한다. 또한, 시장에 참여하고 있는, 특정 상품이나 거래를 여러번 경험해본 사.......

이찬진 금감원장이 자산운용사 대표에게 "문제는 과장광고와 의결권 행사"

2026-07-13T23:40:00+09:00

이찬진 금감원장이 20개 자산운용사 대표를 여의도 금융투자협회로 소집했다. 그 이유는 바로 한국 코스피의 변동성이 너무 커져서 이 문제를 해결하기 위함으로 보인다. 그런데 사실 이 문제의 본질은 우리 모두가 알고 있고 월스트리트에서도 알고 있으며 이웃나라 일본에서도 알고 있다. 그렇게 꼬리가 몸통을 흔드는 Wag the dog 현상이 하루걸러 하루씩 반복되는 코스피는 오늘도 매도 사이드카 & 서킷브레이커를 발동하며 폭락으로 마무리했다. 전일 거래에서 1% 이상 움직인 지수는 브라질이 유일하다. 원래 2년 전까지 우리의 박스피도 1% 이상 변동하는 날은 뉴스에 대서특필 될 정도였지만 이제는 5% 정도 변동은 뉴스거리도 아니.......

해골이 가득한 리마 성당과 카타콤 (리마 역사지구 여행)

2026-07-11T23:57:47+09:00

남북으로 길게 뻗은 국토로 인한 위도 차이와 안데스산맥으로 인한 고저차로 페루는 다양한 모습을 가지고 있다. 4천 미터가 넘는 산줄기가 쉼 없이 이어지며 하늘과 닿을 것 같은 만년설을 볼 수가 있고, 산이 너무 높아서 오르다가 수분을 모두 비로 떨어뜨리고 나면 서쪽 태평양 해안가는 사막이 되어 버린다. 수도인 리마도 우리로 치면 양재천보다도 수량이 적은 리마(Rimac) 강 하나로 천만 명이 식수원으로 사용할 뿐 일 년 강수량은 10mm 수준이다. 사막의 도시다. 그럼에도 불구하고 스페인은 해안가인 리마를 수도로 하여 본인들의 문화를 이식했다. 우리로 치면 스페인 주요 도시의 신도시라고 이해해도 될 만큼 규모가 대단하다. 남.......

한 주간 나온 반도체 관련 보고서, 애널리스트들은 어떻게 전망할까?

2026-07-10T23:56:55+09:00

성공한 밸류투자 이야기는 사람들의 관심을 끌지만 지금 밸류주를 소개하는 글은 역시 사람들의 관심 밖인 것 같다. 사실 지금 모든 사람이 궁금한 것은 하나다. 반도체 관련 주식을 어떻게 할 것이냐에 대한 것이다. 그래서 이번 주에 하락빔을 맞은 이후에 나온 보고서들을 살펴봤다. SK Hynix BNK증권 - 모멘텀 둔화 중, 더 좋은 투자 기회를 기다리자 (목표가 185만원, 중립) (7월 9일) BNK증권에서는 아직 주가가 200만원이 넘는데 목표가를 185만원으로 제시했다. 중립의 투자의견과 현재 주가보다 낮은 목표가를 제시했다는 것은 사실상 매도하라는 말과 같다. 보고서에서는 메타가 잉여 인프라를 외부 판매로 돌리기로 하였고 다른 CSP(C.......

장기투자는 이렇게 하는 겁니다 (한양증권 유상증자, 뚜벅이투자)

2026-07-10T06:30:00+09:00

지난 7월 6일 흥미로운 공시가 올라왔다. 바로 한양증권의 유상증자 결정에 대해 신주발행 금지 가처분 소송이 걸린 것이다. 발행하고자 하는 신주 2,380,952주는 한양증권 보통주식수의 약 18.7%에 해당하는 양이다. 그리고 이번 증자는 주주배정이 아닌 제3자 배정의 방식으로 결정했다. 그리고 3자배정의 주인공은 다름이 아닌 최대주주 당사자 KCGI다. 한양증권은 얼마 전까지 한양대학교를 운영하는 한양학원에서 PF 대출로 인한 유동성 위기를 해결하기 위해 매각을 시도했고 우리에게 강성부 펀드로 유명한 KCGI가 최대주주로 인수하게 되었다. 중소형 증권사인 한양증권은 인수 이후 NCR(Net Capital Ratio, 영업용순자본비율)을 높이고.......

콜마홀딩스 주가가 하락하는 이유 (퇴사하고 지분팔고 퉤퉤퉤)

2026-07-08T23:40:00+09:00

삼전닉스가 아니라면 어차피 다 하락하는 장이긴 하지만 인플레이션으로 돈이 풀리고 있는 지난 1년 동안 줄기차게 주가가 하락한 종목이 있으니 바로 콜마홀딩스다. 사실 콜마홀딩스는 작년 초에 남매간 경영권 분쟁으로 인해 글을 상당히 많이 썼던 종목이기도 하다. 그리고 작년 11월을 마지막으로 더 이상 글을 쓰지 않았다. 잠시 이해를 위해 지난 글을 들춰보자 (251121 지난 글) 그런데 오늘 흥미로운 공시가 나왔다. 임원 및 주요주주의 주식수가 변동되었을 때 나오는 지분공시다. 내용을 열어봤다. 임원 중 원재성이란 분이 7,200주를 싹 다 팔았네? 근데 UQ의 블로그를 봤다면 돈만 생각했을 때 9월에 팔았어야 했다. 그런데 팔지 않.......

배당을 이렇게나 주는데도 안 산다고?! 독하다 독해 (조선내화, CR홀딩스)

2026-07-07T23:40:00+09:00

삼성전자가 사상 최대, 혹은 세계 최대 분기실적을 공시했지만 오늘의 코스피는 또다시 서킷브레이커가 걸리며 퍼렇게 질렸다. 캐나다 잠수함 수주에 실패한 조선업종은 물론이고 너 나 할 것 없이 수많은 종목이 하락을 면치 못했지만 굳건히 버티고 상승한 종목이 있으니 바로 CR홀딩스(시알홀딩스)다. 물론 매일마다 사이드카에 서킷브레이커가 걸리는 코스피 인덱스만도 못한 변동성이지만 오늘 공시는 나름 의미가 있어 보인다. 내용을 살펴보자. 오늘 나온 배당공시는 중간배당이다. 주가가 주당 5천 원이 채 되지 않는데 중간배당을 200원을 준다. 중간배당만 받아도 4%가 넘는 배당수익을 챙길 수가 있다. 올해만 이렇게 주는 것도 아니.......

코스피 또 써킷브레이커 ㄷㄷㄷㄷ

2026-07-07T13:54:17+09:00

삼전 서프라이즈라더니 대단한 코스피

삼성전자 2분기 영업이익 89조원

2026-07-07T07:42:17+09:00

89조원이면 서프라이즈인듯 반도체는 위, 조선은 아래

잠수함은 독일이 가져갔고

2026-07-07T05:40:53+09:00

잠시 후 삼성전자 2q26 실적이 오늘 증시를 결정할듯 하다.

네이버파이낸셜과 두나무 합병, 언제까지 어깨춤을 추게할꺼야 (합병 연기의 진짜 이유)

2026-07-06T23:40:00+09:00

네이버 파이낸셜과 두나무 양사가 주식의 교환이전을 통한 합병을 또다시 연기했다. 벌써 두번째다. 네이버 주가도 완전히 소외받고 있는 이마당에 할꺼면 그냥 빨리 해버리지 왜 이렇게 질질 끄는 것일까? 오늘 기사에는 아래와 같은 내용이 담겼다. 네이버와 두나무는 공시에서 △독점규제 및 공정거래법에 따른 공정거래위원회의 기업결합 승인 △신용정보법에 따른 네이버파이낸셜 대주주 변경승인 및 겸영신고 △특정금융거래정보법에 따른 두나무 대주주 변경신고 수리 등이 필요하다고 언급했다. 실제로 지난 공시에는 이런 내용이 담겨있긴 하다. 하지만 이 내용은 이번에 정정된 내용이 아니고 원래부터 있던 내용이며, 통상적인 절차에.......

초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기

2026-07-10T11:00:00+09:00

들어가며: 왜 Kafka 종단 간 암호화인가?LINE 메신저에서는 매일 수십억 건의 메시지가 오갑니다. 이 방대한 데이터는 다양한 시스템으로 전달되며, 그중에는 개인 정보와 같이 ...

[AI 해커톤 후기] AI 시대의 해커톤과 인간의 역할: AI의 계획과 사람의 전략

2026-07-13T21:43:28+09:00

모두가 같은 주제로, 같은 수준의 AI 도구를 들고 시작한 해커톤. 그런데 결과물은 팀마다 전혀 달랐습니다. 같은 도구를 썼는데 왜 결과는 달라졌을까요?

네이버가 전사 차원에서 처음으로 개발자와 비개발자의 구분 없이 연 모두의 Engineering Day AI 해커톤에서 가장 흥미로웠던 질문입니다.

이 글은 그 질문에 대한 회고로, AI를 어떻게 활용했는지, 그리고 끝까지 사람의 몫으로 남은 일은 무엇이었는지 정리했습니다. 결론부터 말하면 AI는 계획(planning)에 강했고, 끝까지 사람의 몫으로 남은 일은 전략(strategy)이었습니다.

해커톤의 배경

이번 해커톤은 사내에서 실제로 겪는 문제를 해결하는 방식으로 진행됐습니다. 출제자(problem holder)가 문제와 요구 사항을 제시했고, 팀은 선발된 세 가지 문제 중 하나를 배정받았습니다. 요구 사항은 반드시 충족해야 하는 Must 항목과 추가로 해결하면 좋은 Nice 항목으로 나뉘었습니다.

제약은 분명했습니다. 짧은 시간 안에 사내 인프라와 보안 환경에서 실제로 동작하는 결과물을 만들어야 했습니다. 단순 데모로는 충분하지 않고 사내 시스템과 실제로 연동되어야 한다는 점이 가장 어려웠습니다. 평가는 코드 실행 없이 결과물 문서(readme.html)와 저장소 정적 분석으로 이뤄졌고, 사람과 LLM이 함께 심사했습니다.

저희 팀이 맡은 과제는 사내 경비 정산 자동화였습니다. 목표는 사내 메신저인 WORKS로 영수증 사진 한 장만 보내면 정산을 끝낼 수 있게 만드는 것이었습니다.

무엇을 만들었나

저희 팀은 WORKS로 영수증 사진을 보내면 OCR, 비용 분류, 카드 내역 매칭, 임시 저장까지 처리하는 정산 봇과 PC 인증을 위한 크롬 익스텐션을 만들었습니다.

사내 인증 세션의 SSO 쿠키가 PC 웹에서만 전달된다는 제약 때문에 WORKS 챗봇만으로는 정산 API를 호출할 수 없었습니다. 그래서 크롬 익스텐션이 최초 1회 인증 세션을 수행하고, 이후 WORKS 챗봇이 영수증 정산 흐름을 처리하는 2단계 구조를 선택했습니다. 봇 서버는 사내 PaaS에 배포했습니다.

그 결과, 매월 1시간 이상 걸리던 정산 작업을 영수증 10장 기준 약 30초, 사용자 액션 2번으로 줄일 수 있었습니다.

시스템 구성

전체 구조는 크롬 익스텐션, WORKS 봇 플랫폼, FastAPI 기반 봇 콜백 서버, 외부 연동 API군으로 이어집니다. 크롬 익스텐션이 인증 세션을 한 번 확보하면, 이후 영수증 처리는 콜백 서버가 비동기로 진행합니다.

1. 해커톤 자체에 대한 회고

이번 해커톤에서 가장 흥미로웠던 점은 모두가 같은 주제로 같은 수준의 AI 도구를 썼는데도 접근법, UI/UX, 활용 방식까지 산출물이 제각각이었다는 것입니다. AI가 항상 최적의 답을 준다면 '같은 주제'의 산출물은 하나로 수렴해야 할 텐데 실제 결과는 달랐습니다. 그 차이를 만든 것은 완성도를 더 끌어올리고자 하는 사람의 의지였습니다.

개발 그 이상의 영역 — 사람의 개입이 필요한 순간

실제 병목은 코드 작성이 아니라 WORKS 봇 권한 신청과 타 부서가 관리하는 경비 API 명세 확보 과정에서 발생하는 '불확실성'이었습니다. 이 문제는 AI에게 더 많은 컨텍스트를 준다고 해결되지 않았습니다. 인증 방식이 바뀌었는데 사내 문서는 최신 상태가 아니었습니다. 외부 문서는 저희 환경과 달라 AI도 혼란스러웠고, 경비 API는 공개 문서가 없어 담당자부터 찾아야 했습니다.

그래서 휴먼 인 더 루프를 적용해 역할을 나눴습니다. 사람은 아웃라인, 부서 소통, 업무 분장을 맡고, AI는 세부 구현, 코드 생성을 맡았습니다. 모듈 통합에는 AI를 오케스트레이터로 활용했습니다.

계획과 전략의 차이

계획은 목표를 작은 작업으로 쪼개고, 구현 순서를 정하는 일입니다. 이 영역에서 AI는 탁월했습니다. 반면, 전략은 불확실성 속에서 이기기 위한 가설과 방향을 세우는 일입니다. 사내 인프라의 제약을 어떻게 넘을지, 어떤 기능을 먼저 완성해야 평가단의 문제 의식을 정확히 건드릴지와 같은 결정은 AI가 대신하지 못했습니다. AI가 '어떻게 만들지'는 정할 수 있어도, '이기기 위해서는 무엇을 해야 할지'는 사람의 몫이었습니다.

프로세스 민첩성을 위한 바이브 코딩

주어진 시간이 짧았으므로 저희는 오버헤드가 큰 문서 중심 개발(SDD)은 과감히 배제하고 도메인 지식을 바탕으로 AI와 빠르게 주고받는 바이브 코딩을 택했습니다. 일부 팀이 plan.md 셋업에 리소스를 쏟다 속도가 느려지기도 한 것을 보면, 단기 스프린트에서는 형식적 프로토콜보다 휴리스틱과 유연한 애자일이 더 잘 맞았습니다.

인프라/보안과 '책임 있는 투명성'

구현을 서두르는 과정에서 사내 보안과 권한 프로세스의 사각지대도 발견했습니다. 저희 팀은 이를 편법으로 이용하는 데 그치지 않고, 해커톤 종료 직후 관련 부서에 내용을 투명하게 공유했습니다. 덕분에 단순히 해커톤 산출물을 내는 것을 넘어 전사 공용 플랫폼 보안에 선제적으로 기여하고, 동시에 정산 자동화가 실제 업무에도 충분히 적용 가능하다는 것을 확인해 정식 기능 출시 검토까지 이어진 것이 가장 값진 성과였습니다.

2. 개발 파트 회고: 속도와 안정성의 균형을 찾아서

개발 파트는 각자의 도메인을 책임지되, AI를 공통 언어로 삼아 조립해 나가는 과정이었습니다.

작은 블록으로 나누기

저희 팀은 레고식 개발을 적용해 전체 시스템을 인증 캡처, 경비 API 연동, 봇 콜백 서버, 메시지 송신, OCR, LLM 분류라는 6개의 독립 블록으로 나눴습니다. 각자 AI를 사용해 각 블록을 빠르게 구현한 뒤 AI에게 인터페이스 포팅과 머지를 맡겼습니다.

출처: OpenAI Harness engineering

검색, 리서치, 로그를 컨텍스트로 제공

AWS, GCP 등의 퍼블릭 클라우드와는 달리 사내 배포 환경은 LLM이 학습하지 못한 영역입니다. 따라서 'AI가 아는 것'에 기대기보다, 사내 정보에 연결해 '잘 찾게 만드는 것'이 관건이었습니다.

저희 팀은 사내 코드 저장소, 이슈 트래커, 위키를 사내 MCP로 연결해, AI가 직접 검색하며 사내 배포 플랫폼, 로드밸런서, 분산 DB 환경에 맞게 설정하도록 했습니다. 막힐 때 던지는 질문은 크게 세 종류였습니다.

구분	질문	활용 방식
WHAT	무엇을 써야 하는가	사내에서 사용할 수 있는 플랫폼과 유사 사례를 먼저 검색
HOW	어떻게 써야 하는가	설정 방법과 예시를 찾아 적용(예: DDL 분석, 마이그레이션, 쿼리 테스트 순서로 분산 DB 이관)
WHY	왜 실패하는가	빌드, 배포, 오류 로그를 제공하고 원인과 다음 조치를 확인

속도와 품질을 높이기 위한 327개의 테스트

빠르게 바꾸는 만큼 회귀도 빠르게 생깁니다. 저희 팀은 실패한 케이스를 지나치지 않고 테스트로 고정해 327개의 테스트를 만들었습니다. 정보가 부족하면 문서를 보강했고, 동작이 깨지면 테스트를 추가했습니다. 같은 실수가 반복될 것 같으면 가드레일로 검증 로직을 넣음으로써 속도에만 치중하지 않고 품질을 함께 지킬 수 있었습니다.

3. 비개발 파트 회고: AI라는 징검다리

해커톤에서 AI는 코드를 만드는 도구일 뿐만 아니라, 비개발자가 개발 상황을 이해하고 기획과 디테일에서 팀의 협업 속도를 높일 수 있게 해주는 징검다리이기도 했습니다.

개발 상황을 따라잡기

해커톤 중 팀 개발 채널에서 빠르게 흐르는 기술 대화를 비개발자가 이해하기는 어려웠습니다. 그래서 Playwright와 로그인된 Chrome 브라우저를 활용해 AI가 팀 채팅, 발표 자료, 사내 코드 저장소를 읽고 진행 상황 문서로 정리하게 했습니다. 그 결과 '지금 무슨 개발이 진행 중인지'를 파악해 담당 개발자에게 더 정확하게 질문할 수 있었습니다.

사용자 흐름을 구체화하기

서비스가 사용자에게 닿기까지의 흐름을 도입 페이지, 챗봇 플로우, 발표 자료 세 영역으로 나눠 AI와 함께 설계했습니다.

도입 페이지: 2단계 인증 구조로 인해 크롬 익스텐션만으로는 봇 사용법을 알기 어려워, 설치, 튜토리얼, 유의 사항을 모아놓은 페이지를 AI와 함께 기획했습니다.
챗봇 플로우: '언제 실패하는가'를 AI와 브레인스토밍해 분류 모호, 매칭 실패, 결제 익일 반영, 개인카드 오등록과 같은 오류 케이스를 설계하고, 이상적인 흐름과 오류 케이스를 HTML로 시각화해 개발 우선순위를 논의했습니다.
발표 자료: 코드 실행 없이 평가되는 만큼, 평가자를 LLM 평가단, 출제자, 청중으로 정의하고 첫 페이지에 Must, Nice, Beyond 충족도를 두괄식으로 배치했습니다.

디자인 톤을 하나로 맞추기

크롬 익스텐션, 도입 페이지, 발표 자료가 서로 다른 제품처럼 보이면 완성도가 낮아 보일 수 있습니다. 그래서 민트색(#0d9373), Pretendard 글꼴, 캐릭터, 아이보리색 알림 창과 같은 디자인 토큰을 정하고 팝업, 도입 페이지, 슬라이드에 일관되게 적용했습니다.

발표 덱은 출제자가 공유한 HTML 형식을 AI가 참고하게 해 기본 골격을 만들었습니다. 이후 내용을 이식해 약 1시간 만에 11장 분량의 초안을 완성했습니다. HTML 단일 파일이라는 특성 덕분에 지시 한 줄로 문구와 레이아웃을 빠르게 고칠 수 있었고, 실제로 마감 직전까지 20번 넘게 수정해 완성도를 높였습니다.

마치며

이번 해커톤에서 가장 분명하게 남은 것은 처음 질문에 대한 답이었습니다. 같은 AI를 쥐여 줘도 결과를 가르는 것은 사람의 선택과 전략입니다.

AI는 '계획과 구현'의 영역에서 압도적인 속도를 냈습니다. 하지만 불확실성 속에서 가설을 세우고, 조직 안의 의존성을 풀고, 보안 사각지대를 책임 있게 공유하는 '전략'의 영역은 사람의 몫으로 남았습니다.

개발 파트에서는 사람이 AI 에이전트를 오케스트레이션하며 큰 작업을 작은 블록으로 나눠 병렬로 진행한 전략이 중요했습니다. 비개발 파트에서는 AI를 소통과 기획의 징검다리로 삼아 협업 속도를 높인 전략이 중요했습니다.

AI 시대의 협업은 사람이 AI로 대체되는 그림이 아니라, 사람이 전략을 쥐고 AI에게 계획과 실행을 위임하는 그림에 가깝습니다. AI는 매일 더 똑똑해지지만, '만들었다'를 넘어 시장에서 선택받는 프로덕트를 만들어내는 것은 여전히 사람의 역할이 아닐까요?

이것이 이번 해커톤이 저희 팀에 남긴 가장 큰 배움이었습니다.

FE News 26년 7월 소식을 전해드립니다.

2026-07-09T02:52:20+09:00

주요소식

26년 6월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.

TypeScript 7.0 RC

Go로 재작성된 네이티브 컴파일러를 탑재한 TypeScript 7.0의 릴리스 후보(RC)가 공개되었다. 기존 타입 체크 로직과 구조를 그대로 유지한 채 포팅해 6.0보다 약 10배 빠르며, Bloomberg, Figma, Google, Slack, Vercel 등 여러 기업의 팀과 프리릴리스 빌드를 테스트해 왔다. 향후 한 달 내 정식 릴리스될 예정으로, 대규모 코드베이스에서 타입 체크와 빌드 속도로 고생해 온 팀이라면 미리 검증해 볼 가치가 있다.

Ship the policy, not the code

프런트엔드와 백엔드처럼 별도로 배포되는 두 시스템에 동일한 비즈니스 규칙을 구현할 때 발생하는 코드 중복과 불일치 문제를 다룬다. 백엔드가 "allowedActions": ["CANCEL"] 같은 결정값을 내려보내거나, CASL이나 JSON Schema 같은 표준 형식으로 정책 자체를 데이터로 직렬화해 전송하는 방안을 제시한다. 마이크로서비스나 BFF 구조에서 규칙 일관성을 고민하는 개발자에게 실용적인 관점을 제공한다.

Getting started with loops

Claude Code 팀이 코딩 에이전트에게 프롬프트를 반복 입력하는 대신 "루프를 설계"하는 접근을 정리한 글이다. 트리거 방식과 종료 기준에 따라 턴 기반, 목표 기반, 시간 기반, 프로액티브 4가지 유형으로 분류하고, 검증 절차를 스킬(SKILL.md)로 인코딩해 자가 검증 능력을 높이는 방법을 소개한다. 명확한 종료 기준 설정과 대규모 실행 전 파일럿 테스트 등 토큰 사용량 관리 팁도 함께 제안한다.

React Doctor

AI 에이전트가 작성한 React 코드의 품질 문제를 자동으로 잡아내는 도구다. 상태 관리, 이펙트, 성능, 아키텍처, 보안, 접근성 전반을 검사하며 Next.js, Vite, TanStack, React Native, Expo 등 대부분의 React 환경을 지원한다. Claude Code, Cursor, Codex 같은 AI 에이전트와 연동되고, GitHub Actions를 통한 PR 자동 리뷰도 가능하다.

vercel/eve

Vercel이 공개한 파일시스템 기반의 지속형(persistent) AI 에이전트 프레임워크다. 시스템 프롬프트는 instructions.md, 도구는 tools/, 온디맨드 절차는 skills/ 디렉터리에 두는 식으로 에이전트의 구성 요소를 코드가 아닌 디렉터리 구조로 관리해 검사와 확장이 쉽다. 마크다운과 타입 정의된 함수만으로 에이전트를 구성하는 접근은 코드 중심 프레임워크 대비 낮은 진입 장벽을 제공한다.

>> FE News 26년 7월 소식 보러가기

◎ FE News란?
네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다.

매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다.
▷ 구독하기

[AI 해커톤 후기] 코드와 문서만 읽은 LLM은 어떻게 사람과 같은 팀을 1위로 골랐을까

2026-07-06T23:44:16+09:00

2026년 봄, 네이버는 개발 직군 중심으로 열리던 Engineering Day를 모든 직군이 함께하는 '모두의 Engineering Day'로 넓혔습니다. 행사의 마지막 순서는 AI 해커톤이었습니다. 목표는 단순히 AI를 써보는 것이 아니라, 사람이 하던 반복 업무를 AI로 줄이고 그 과정에서 'AI native로 일해 보는 경험'을 만드는 것이었습니다.

실제 업무 문제를 겪는 현업 담당자(problem holder)가 세 가지 문제를 냈고, 문제를 푸는 사람(solver)은 직군 제한 없이 네 명씩 팀을 이뤘습니다. 모두 25개 팀, 100여 명이 현장에서 문제와 매칭되었습니다. 각 팀은 바로 사용할 수 있는 수준의 최소 기능 제품(minimum viable product, MVP)을 하루 안에 만들어야 했습니다. 주제는 신규 서비스가 아니라 사람이 손으로 처리하던 반복 업무를 줄이는 사내 문제로 좁혔습니다.

행사를 준비하면서 마지막까지 남은 고민은 평가였습니다. 25팀의 제출물을 짧은 시간 안에 보고, 문제별 상위 팀을 공정하게 가려야 했습니다. 모든 코드를 실행해 볼 수 있다면 가장 좋았겠지만 시간이 부족했고, 제출된 코드와 문서를 일관된 기준으로 빠르게 읽을 방법이 필요했습니다. 마침 LLM의 성능이 좋아지면서 LLM을 평가자로 활용하는 방식(LLM as a judge)이 외부에서도 활발히 시도되고 있었습니다. 공통 문제를 두고 여러 팀이 경쟁하는 이번 행사에도 적용해 볼 만하다고 판단했습니다.

이 글은 코드와 문서만 읽는 평가를 어떻게 설계했는지, 그 결과가 사람의 평가와 얼마나 일치했는지, 평가를 반복해도 비슷한 결과가 나오는지를 정리한 기록입니다. 다만 평가 대상은 세 문제, 25팀, 100여 명이 하루 만에 만든 MVP였습니다. 실제 서비스 코드처럼 방대하고 복잡한 환경에 이 방식을 그대로 적용하기는 어렵지만, 'LLM이 코드와 문서만 읽고도 사람과 비슷한 판단을 내릴 수 있는지'를 가늠해 볼 수 있었습니다.

세 개의 문제와 평가 단계

세 개의 문제는 다음과 같습니다.

문제 A(출자·투자 현황 관리): 수기 엑셀로 취합하던 출자·투자 지분 현황을 입력하고 검증할 수 있는 플랫폼으로 전환
문제 B(영수증 경비 정산): 영수증을 일일이 모아 처리하던 정산을 사내 메신저 봇으로 자동화
문제 C(업무 시간 관리): 흩어진 업무 소스를 모아 하루 일정을 만들고 실제 쓴 시간까지 돌아보는 어시스턴트 구현

심사는 1차와 2차로 나눴습니다. 1차는 문제별 후보군을 좁히는 예선이었고, 2차는 최종 시상을 정하는 본선이었습니다. 1차 안에는 두 트랙이 있었습니다. LLM 평가단은 문제당 상위 2팀을 점수와 근거로 추렸고, 문제 출제자는 본인 문제에서 꼭 살리고 싶은 1팀을 SUPER(슈퍼패스)로 본선에 올렸습니다.

단계		평가 주체	결과
1차	트랙 A — LLM 자동 평가	LLM 평가단	문제당 상위 2팀 선발
1차	트랙 B — SUPER(슈퍼패스)	문제 출제자	본인 문제에서 1팀 구제
2차		사내 AI 커뮤니티 30% + 출제자 30% + 참가자 40%	최종 수상자 결정

LLM 평가는 사내에서 제공하는 코딩 에이전트로 진행했습니다. 평가 절차와 루브릭(채점 기준표)을 하나의 '스킬'로 정의하고, 에이전트가 그 스킬에 따라 코드와 문서를 읽게 했습니다. 사내에는 Claude Code와 Codex가 제공되었는데, 두 에이전트의 결과를 얻고 맞춰 볼 시간이 부족했습니다. 그래서 이번 LLM 평가는 Codex 하나로 진행했습니다.

평가 기준은 '일을 얼마나 줄였는가'

이 평가가 던진 질문은 하나, '실제로 사용자의 일을 얼마나 줄여줬는가'였습니다. 단순히 AI나 기술을 사용했다는 사실은 중요하지 않았습니다. 같은 기능이라도 어디까지 이어지는지에 따라 점수가 달라졌습니다. 예를 들어 RAG(문서를 검색해 답을 보강하는 기법)가 정책을 찾아줘도 그 답이 경비 분류나 한도 판단으로 이어지지 않으면 검색을 돕는 데 그칩니다. 업무 화면으로 이동시키기만 하고 입력은 사람에게 맡기는 브라우저 확장 프로그램도 마찬가지입니다. 반대로 화면 입력을 대신 채우고, 실제 저장·상신(결재 요청)에 필요한 데이터를 만들고, 실패했을 때 다시 처리하는 흐름까지 구현했다면 사용자의 일을 대신했다고 볼 수 있습니다. 정적 대시보드도 정해진 상황만 보여주는지, 실제 수집 결과를 계속 반영하는지에 따라 다르게 평가했습니다. 그래서 발표 자료의 설명보다는 입력을 받고, 판단하고, 결과를 만드는 흐름이 실제 코드 안에서 이어지는지를 봤습니다. 기준을 납득 가능하게 만드는 것만으로는 충분하지 않았습니다. 문제당 상위 2팀을 가려야 했기 때문에, 비슷하게 좋아 보이는 팀들 사이에서도 차이가 드러나야 했습니다. 그래서 기능 완성도(functionality) 40점, 기술·구현(technical) 20점, 차별성·문제해결(differentiation) 20점, 문서·제출자료(documentation) 20점의 네 가지 평가 축을 정했습니다. 발표 자료만 보면 비슷해 보이는 팀도 코드에서 확인되는 구현 범위, 예외 처리, 업무 흐름의 연결 정도를 기준으로 보면 차이가 났습니다.

평가 시스템의 동작

평가 파이프라인은 단순했습니다. 각 팀의 저장소 주소, 커밋, 제출물 경로를 고정한 매니페스트를 준비하면 에이전트가 코드와 문서를 읽고 점수와 한 줄 평을 생성했습니다. 사람이 개입한 곳은 매니페스트를 준비하는 사전 단계와 결과 공개 시점을 정하는 단계뿐이었습니다.

가장 신경 쓴 부분은 공정성이었습니다. 화면을 직접 실행하지 않고 코드와 문서만으로 구현 수준을 판단해야 했기 때문에, 참가자와 운영자가 납득할 수 있는 기준이 필요했습니다. 발표 자료에는 완성됐다고 적혀 있어도 코드로 확인되지 않으면 구현 완료로 보지 않았습니다. TODO로 남은 기능, 틀만 있고 동작하지 않는 코드, 발표 자료에만 있는 기능도 마찬가지였습니다. 다만 같은 이유로 감점을 반복하지는 않고, 구현된 만큼만 점수를 주고 확인되지 않은 부분은 점수를 주지 않았습니다. 채점은 팀별로 분리했습니다. 팀별 채점 에이전트(team-evaluator)는 매니페스트에서 팀명, 문제, 커밋, 저장소, 제출물 경로를 확인한 뒤 문제별 루브릭에 따라 코드와 문서를 읽었습니다. 점수만 남기면 이후 조율과 검수가 어려우므로 내부 JSON에는 점수, 강점, 근거, 판단 리스크를 함께 남겼습니다. 세 문제는 동일한 네 가지 평가 축을 사용했지만, 문제별 스킬에서 중점적으로 본 부분은 달랐습니다.

문제	중점적으로 본 부분
문제 A(출자·투자 현황 관리)	수기 엑셀 기반 출자 현황을 기준 데이터(master DB)로 옮기는 입력, 검증, 불일치 발견·수정 경로
문제 B(영수증 경비 정산)	영수증 인식부터 카드 매칭, 분류, 한도 확인, 임시 저장까지 이어지는 경비 처리 흐름
문제 C(업무 시간 관리)	흩어진 업무 소스를 모아 하루 일정으로 바꾸는 핵심 흐름, 실제 연동, 상태 관리, 문서 근거

예를 들어 문제 B에서는 단순 OCR 데모와 실제 경비 처리 자동화를 나눠 보는 기준을 촘촘하게 뒀습니다. 영수증을 읽는 데서 끝나는지, 카드 매칭, 분류, 한도 확인, 예외 회복, 임시 저장까지 업무 흐름이 이어지는지를 따로 확인했습니다. 채점이 끝나면 문제별 취합 에이전트(topic-lead)가 같은 문제의 팀별 결과를 모았습니다. 이 단계에서는 새 점수를 만들지는 않고, 개별 채점 결과의 점수, 근거, 위험을 같은 문제 안에서 비교하고 점수 스케일과 상위권 후보가 갈리는 지점을 확인했습니다. 평가를 조율할 때는 책임을 나누는 데 신경을 썼습니다. 팀별 채점, 문제 내 조율, 한 줄 평 작성을 한 컨텍스트에 몰아넣으면 앞선 팀의 인상이나 문장의 톤이 다음 판단에 섞일 수 있고 평가 집중도가 떨어질 수도 있습니다. 그래서 채점 에이전트는 한 팀만 보고, 취합 에이전트는 같은 문제의 결과만 모으고, 한 줄 평은 작성(copywriter)과 검수(reviewer) 에이전트로 분리했습니다. 운영 관점에서는 네 가지 공통 평가 축을 먼저 고정했다는 점도 도움이 됐습니다. 문제별 세부 루브릭은 달라도 같은 평가 축을 공유했기 때문에 결과를 하나의 파이프라인으로 모으기 쉬웠습니다.

사람의 판단과 만난 지점

LLM 평가는 문제당 상위 2팀을 뽑는 1차 관문이었습니다. 따라서 공식 우승팀이 LLM 후보군 안에 들어왔다는 사실만으로는 큰 의미를 부여하기 어렵습니다. 더 흥미로웠던 지점은 문제 A와 문제 B에서 서로 다른 세 판단이 같은 팀을 가리켰다는 점입니다. LLM은 8~9개 팀(문제 A는 9개 팀, 문제 B와 C는 각 8개 팀) 중 해당 팀을 1위로 평가했습니다. 문제 출제자도 같은 팀을 SUPER로 골랐고, 최종 심사에서 사람들이 고른 우승 팀도 같았습니다.

문제	LLM 1위	SUPER	최종 1위	일치	상위권 양상	우수한 지점
문제 A (출자·투자 현황 관리)	팀 NStake	팀 NStake	팀 NStake	일치	1~3위 초접전	기능 완성도
문제 B (영수증 경비 정산)	팀 youngsoo	팀 youngsoo	팀 youngsoo	일치	1위가 비교적 뚜렷	차별성, 문제 해결
문제 C (업무 시간 관리)	팀 daylog	팀 TeamNaver_Assistant	팀 timamanager	불일치	1~3위 접전	문서, 제출 자료

문제 A는 상위권 점수 차가 거의 없는 초접전이었습니다. 눈에 띄는 것은 LLM 평가에서 접전 구간의 맨 앞에 놓인 팀이 출제자의 SUPER 선택과 같았다는 사실입니다. 팀 NStake를 고른 SUPER 선택도 실제 사용 가능성과 동작 완성도를 중요시한 결과라면, 두 평가는 같은 축에 무게를 둔 셈입니다.

문제 B에서는 팀 youngsoo가 차별성과 문제 해결에서 비교적 뚜렷하게 앞섰습니다. 이 문제의 스킬은 사내 메신저 봇(WORKS Bot), OCR, 예외 회복, 한도 확인, 사내 경비 시스템(neon-ess), 상신 안전성 같은 경계를 자세히 봤습니다. 루브릭이 영수증을 읽기만 하는 수준과 실제 경비 처리를 자동화하는 수준을 나눠 보도록 설계돼 있었기 때문에, 차별성이 코드 근거로 확인되는 팀을 찾아낼 수 있었습니다.

문제 C에서는 LLM 평가, SUPER, 최종 심사가 서로 다른 팀을 가리켰습니다. 당일 결과만 보면 문서와 제출 자료 근거가 확실한 팀 daylog가 LLM 평가에서 앞섰고, 공식 우승 팀 timamanager는 실제 동작 완성도에서 강했습니다. 특정 팀이 맞고 틀렸다는 뜻은 아닙니다. 문제 C처럼 상위권 점수 차가 작을 때는 한 번의 평가 총점만으로 1위를 단정하기 어렵다는 사실을 알 수 있었습니다.

반복 평가와 안정성

문제 C의 불일치를 보고 나니 한 가지를 더 확인하고 싶었습니다. 같은 제출물을 LLM이 다시 채점하면 비슷한 결과가 나올까, 아니면 실행할 때마다 전혀 다른 결과가 나올까 하는 것이었습니다. 해커톤이 끝난 뒤 각 문제를 5회씩 다시 평가해 봤습니다. 점수 자체는 예상보다 흔들렸지만, 상위권을 유지하는 팀은 비교적 안정적이었습니다.

반복 평가에서 1위가 나온 횟수는 다음과 같았습니다.

문제	5회 중 1위 횟수
문제 A	팀 NStake 4회, 팀 team22 1회
문제 B	팀 youngsoo 5회
문제 C	팀 timamanager 4회, 팀 Sherpa 1회

여기서 보고 싶었던 것은 문제별 순위를 다시 매기는 것이 아니라, 반복 평가에서도 상위권을 유지하는 팀에는 어떤 공통점이 있는가였습니다.

팀 NStake는 출자 현황 입력부터 기준 데이터 대조와 불일치 수정까지 이어졌습니다. 팀 youngsoo는 영수증 인식부터 카드 매칭, 분류, 임시 저장과 상신까지 이어졌습니다. 팀 timamanager는 업무 소스 수집부터 일정 생성, 상태 갱신, 퇴근 리뷰까지 이어졌습니다. 세부 구현은 달랐지만 점수를 만든 이유는 비슷했습니다. 입력부터 판단, 결과 생성까지 이어지는 문제 해결 흐름이 코드에서 보였다는 것입니다.

반대로 점수가 크게 흔들린 제출물은 기술이 부족했기 때문은 아니었습니다. 그 기술이 실제 업무를 어디까지 대신하는지가 애매한 경우가 많았습니다.

그래서 문제 C처럼 점수 차가 작은 경우에는 평가 한 번의 총점뿐 아니라 같은 평가가 반복해서 유지되는지도 함께 봐야 한다고 느꼈습니다. 반복해도 같은 팀이 상위에 남는다면, 그 평가는 운이 아니라 기준에 따라 어느 정도 일관되게 작동했다고 볼 수 있습니다.

회고

평가를 맡은 팀이 해커톤 뒤 잠깐 모여 회고했을 때 가장 아쉬워했던 점은 당일에 정해진 시간 안에 결과를 내야 하기 때문에 반복 평균을 사용하지 못했다는 것입니다. 다음에는 가능한 범위에서 평가를 병렬로 3~5회 반복하고, 평균 점수와 함께 반복 평가에서도 순위가 유지되는지를 보려고 합니다.

실제 실행 검증까지 가지 못한 것도 한계였지만, 모든 제출물을 직접 실행해 보는 것이 다음 과제라고 생각하지는 않습니다. 낯선 저장소를 안정적으로 실행하는 일에는 평가와는 또 다른 어려움이 있고, 사후 반복 평가에서 확인했듯, 코드와 문서만 읽어도 실제 업무 흐름이 잘 이어진 팀은 반복해서 상위권에 남았기 때문입니다.

반면, 다음에도 공통 평가 축을 먼저 정하고 문제별 세부 루브릭으로 구체화하는 방식은 유지하려고 합니다. 문제별 루브릭이 달라도 같은 평가 축을 공유했기 때문에 결과를 한 방향으로 모을 수 있었습니다.

마치며

이번 평가에서 가장 분명하게 확인한 것은, 채점 기준이 충분히 구체적이면 코드와 문서만 읽은 LLM도 사람의 판단에 가까운 결론에 도달할 수 있다는 점이었습니다. LLM은 단순히 기능 구현 여부만 보는 것이 아니라, 실제 문제를 해결하는 흐름이 코드 안에서 처음부터 끝까지 이어지는지까지 확인했습니다.

명확한 루브릭과 평가 범위가 있다면, 더 복잡한 코드에서도 제품이 의도한 업무 흐름을 갖추었는지 점검하는 보조 평가로 LLM 평가를 활용할 수 있겠다는 아이디어를 얻었습니다. 작은 코드베이스에서 본 가능성이지만, 이번 해커톤에서 여러 팀의 코드를 같은 기준으로 살펴보고, 그 판단을 사람의 평가와 나란히 비교해 본 덕분에, 그 가능성을 작게나마 실제 사례로 확인할 수 있었습니다.

[그로스 마케팅 부트캠프 후기]인턴 연계로 정규직 전환 - 그로스마케터 인턴 연계로 시작해 정규직 전환까지 이어진 실무 성장기

2026-07-14T11:07:09+09:00

부트캠프를 수료해도 인턴 연계나 정규직 전환까지 이어질 수 있을지, 막막하게 느껴질 때가 있죠. 멋쟁이사자처럼 그로스 마케팅 부트캠프 1기를 수료한 성진님은 인턴 연계로 입사해 정규직 전환까지 성공하며, 지금은 그로스마케터 6기 운영까지 함께 맡고 있어요. 디지털경영을 전공하며 데이터 분석 역량을 쌓아온 성진님의 이야기를 통해, 인턴십에서 무엇이 달라지

멀티플 (AI)

2026-07-12T22:46:24+09:00

일본 인디 개발자 2명이 대박을 쳤다. 2명이서 게임 하나로 600억 넘게 벌었다고 한다. 로또 몇 배짜리다. 건물 몇 개 살 수 있겠다.

주인공은 일본의 인디 개발자 레모리온, 하가네이로다. 게임을 만들었고, 스팀에 올렸다. 2026년 6월 10일 스팀(Steam) 출시 후 4일 만에 100만 장, 16일 만에 1,000만 장, 한 달이 채 안 된 7월 5일에 1,500만 장 판매를 돌파했다. 스팀 글로벌 판매 1위, 동시접속자는 24만 명을 넘겼다.

엄청 간단한 게임이다. 하얀 캐릭터의 몸에 배경과 똑같은 색과 무늬를 칠해 위장하고, 총을 든 술래를 피해 숨는다. TV 예능에 나온 '보디페인팅 위장술'에서 아이디어를 얻었다고.

단 2명, 전부. 한 달 만에 중견기업 연 매출. 한국 스팀 기준 판매가는 6,550원. 단순 계산 시 약 980억 원의 누적 매출이다. 보수적으로 스팀 수수료 등 제외 매출을 계산하더라도, 실제 개발자가 쥐는 돈은 600억 원대에 달한다고 한다.

흥미로운 점은 이 대박 게임을 완성하는 데 '단 2개월'밖에 걸리지 않았다는 것이다. 기획자가 아이디어를 내자 프로그래머가 하루 만에 기본 시스템을 짰고, 단기간에 세상에 내놓았다.

진짜 비결은 속도보다 '실패한 자산의 재활용'에 있다. 이들은 이전에 7개월 동안 만든 협동 게임이 흥행에 실패했는데, 그때 짜둔 멀티플레이 시스템을 버리지 않고 모듈처럼 떼어와 이번 게임에 그대로 조립했다. 0에서 시작한 게 아니라, 이전의 실패를 레버리지해 한계비용을 극단적으로 낮췄다.

서버 고정비는 '0원'으로 세팅했다. 동시접속자가 24만 명이나 몰리면 보통 트래픽 비용만 수억 원이 깨지지만, 이들은 에픽게임즈가 무료로 제공하는 서버 인프라(EOS)를 얹어 썼다. 고정비가 없으니 파는 족족 순이익으로 꽂히는 압도적인 마진 구조가 완성됐다.

마케팅비 역시 한 푼도 쓰지 않았다. 대신 게임 기획 단계부터 'SNS바에(SNS映え)'를 노렸다. 유저들이 엉성하게 색칠하고 숨는 모습 자체가 숏폼 콘텐츠의 밈(Meme)이 되도록 기획했고, 시청자 참여형 방송을 타며 전 세계로 오가닉하게 퍼져나갔다.

이 모든 것을 단 2명이 할 수 있었던 본질적인 이유는 'AI와 개발 툴의 진화'에 있다. 과거라면 2명이 두 달 만에 이 정도의 맵과 3D 시스템을 구현하는 건 불가능했다. 하지만 이제는 코딩 에이전트가 코드를 짜주고, 상용 엔진이 물리법칙을 대신 구현해 준다. 구현에 드는 '물리적 노동 시간'이 극단적으로 압축된 것이다.

크래프톤 같은 대형 게임사가 신작을 만드는 방식과 비교해 보면 산업 구조의 변화가 명확해진다. 대형 스튜디오는 수백 명의 인력, 수백억의 제작비, 막대한 마케팅비를 태워 수년 동안 '원히트 원더'를 빚는다. 배그(PUBG)처럼 터지면 조 단위로 벌지만, 최근의 여러 AAA급 게임들처럼 실패하면 회사 전체가 휘청거리는 무거운 도박판이다.

반면, 메챠카멜레온은 게임판의 '극단적인 린(Lean) 스타트업'이다. 수백 명의 인건비를 태울 필요 없이, AI 툴을 쥔 2명이 빠르게 프로토타입을 만들어 던져본다. 터지면 마진율 90% 이상의 캐시카우가 되고, 안 터져도 서버비 0원에 두 달 치 시간만 날렸을 뿐이니 바로 피벗(Pivot)해서 다음 게임을 만들면 그만이다.

2명이 로또 터진 것 이상으로 시사하는 바가 크다. AI는 파운데이셔널 모델뿐 아니라 모든 비즈니스에 명확한 시그널을 던진다. 제조원가를 극단적으로 낮추고, 멀티플이 어디서 나올지, 그리고 몇 배 멀티플 줘야 할지에 대한 계산을 처음부터 다시 해야 하는 산업들이 생길 것이다. 결국 특정 시점에는 그 멀티플들도 한 지점으로 수렴되겠지만, 수렴되기 직전까지 남들보다 조금만 빨리 알아챈다면 많은 기회를 선점할 수 있을 것이다.

권력이 자본력을 앞세운 '거대한 팩토리'에서, AI와 인프라를 레버리지해 트래픽을 설계하는 '마이크로 팀'으로 넘어가고 있다. 아이디어와 기획력만 뾰족하다면, 두 명이서 수백 명 규모의 대기업을 수익성으로 압살할 수 있는 시대가 완전히 열린다.

플라우드 한 달 후기

2026-07-07T10:48:22+09:00

* 플라우드 한 달 후기를 적습니다. 사용하며 효율성이 매우 오르기도 했지만, 그 이상 배운 것들이 있어 기록으로 남깁니다. 플라우드 한국 유통사의 지원도 받았습니다. 맨 하단에 이벤트가 있으니 도움 되시면 좋겠습니다.

제 서랍에는 비싼 기계들이 많습니다. 살 때는 다 인생을 바꿔줄(?) 기대로 샀던 물건들입니다. 하나같이 2주를 못 넘기고 서랍으로 갔습니다. 액션캠도 있고요. 스마트 링, 고급 팟캐스트용 마이크도 있고요. 여러 이유로 사기는 많이 사는데, 일상에 녹아들어 살아남는(?) 녀석들은 적네요.

지난달에는 AI 노트테이커 플라우드(Plaud)를 샀습니다. 결론부터 말하면, 서랍으로 들어가지 않았습니다.

ㅎㅎ. 한 달째 살아 있습니다. 왜 이건 살아남았는지, 사용 후기와 생각 몇 가지 나눠보려고요.

먼저 물건 소개부터 하면, 명함 사이즈의 녹음기입니다. 폰 뒤에 붙여두거나 지갑에 넣어둡니다. 버튼 한 번이면 녹음이 되고, 끝나면 알아서 전사를 해줍니다. 그리고 대화 내용을 요약하고, 해야 할 일도 뽑아줍니다. 여기까지 들으면 "폰에도 녹음 있는데?" 싶으실 겁니다. 저도 그랬습니다.

그런데 한 달 쓰면서 제 하루가 실제로 어떻게 바뀌었는지 보여드리는 게 빠를 것 같습니다.

1. 미팅부터요. 대화에 집중을 합니다. 대화가 끝나면 다시 그 대화를 정리합니다. 대화를 '정리'하는 데에만 미팅만큼 시간이 듭니다. 1시간을 대화하면 1시간을 정리합니다. 너무 중요한 미팅은 꼭 기억을 되살려 정리하지만, 바쁘면 놓치는 경우도 많았습니다. 그렇게 놓치는 미팅은 휘발되었습니다. 분명 좋은 이야기가 오갔는데, 일주일 뒤에 남은 건 "좋은 미팅이었다"는 인상뿐인 경우가 많았습니다. 플라우드를 사용하고 바뀐 건 이런 일이 없어졌다는 것입니다. 미팅을 시작하면 버튼을 누르고, 미팅이 끝나면 버튼을 다시 누릅니다. 대화가 끝나고 집에 오는 길이면 미팅 요약과, 할 일 목록이 모두 정리되어 있습니다. 필요한 것만 그 자리에서 팀에 넘깁니다. 회의록 쓰는 시간이 줄어든 게 아닙니다. 회의록이라는 '일' 자체가 제 하루에서 없어졌습니다.

2. 다음은 생각입니다. 좋은 생각은 이상하게 책상에서 안 나옵니다. 걷다가 나오고, 운전하다가 나오고, 샤워하다가 나옵니다. 문제는 그 생각들의 수명이 몇 분이 안 된다는 것입니다. 예전에는 폰 메모장에 적으려고 했습니다. 폰을 꺼내고, 잠금을 풀고, 앱을 찾고, 자판을 두드립니다. 그 네 단계를 지나는 동안 생각의 절반은 이미 도망가 있습니다. 열 개가 떠오르면 두세 개 적으면 많이 적은 것이었습니다. 지금은 걷다가 생각이 오면 버튼을 누르고 그냥 말합니다. 두서없어도 됩니다. 문장이 안 되어도 됩니다. 저녁에 열어보면 그 중얼거림이 전부 글자가 되어 있습니다. 열 개가 떠오르면 열 개가 남습니다. 잡는 양 자체가 달라졌습니다.

3. 글쓰기도 루틴이 바뀌었습니다. 예전의 글쓰기는 책상에 앉아 빈 화면을 마주 보는 일부터 시작했습니다. 뭘 쓸지부터 생각해야 하니까요. 지금은 책상에 앉으면 낮에 말해둔 재료들이 이미 쌓여 있습니다. 그 전사본을 AI한테 넘겨 초고를 만들고, 저는 고치고 자릅니다. 무에서 시작하는 글쓰기와 재료에서 시작하는 글쓰기는 걸리는 시간이 다른 게 아니라 난이도가 다릅니다. 책상은 이제 생각을 짜내는 자리가 아니라, 밖에서 잡아온 생각을 다듬는 자리가 됐습니다. 이 글도 절반은 걸으면서 썼습니다.

정리하면, 기록이 '마음먹고 하는 일'에서 '그냥 일상속에 들어온 일'이 됐습니다. 제 옆에 비서가 붙어서 계속 제가 한 대화들을 기록하고, 요약해줍니다. 필요할 때 꺼내 쓰면 됩니다. 폰 녹음기로는 이렇게 안 됐습니다. 조금이라도 귀찮으면 사람은 안 하거든요. 이 기계가 한 일은 그 귀찮음을 0으로 만든 것, 그게 전부인데 그 전부가 행동을 바꿨습니다. 돈 주고 기계를 샀는데, 심어진 건 버릇이었습니다.

물론 기계값이 있습니다. 구독료가 붙고요. 하지만, 저처럼 말하고 듣는 게 일인 사람에게는 값을 합니다.

마지막으로 제일 중요한 생각인데요. 기계는 계속 좋아질 것 같습니다. 하드웨어는 업그레이드 되고요. 몇 년 뒤에는 안경이 됐든 이어폰이 됐든 전혀 다른 형태가 나올지도요. 더 좋은 게 나오면 저는 미련 없이 갈아탈지도 모릅니다. 그래도 상관없다고 생각합니다. 하지만, 이 과정에서 배운 것은 기계가 아니라 업무하는 방식인 것 같습니다. 생각이 지나갈 때 잡아두는 버릇, 하루를 재료로 만드는 버릇. 기계는 서랍에 들어가도, 버릇은 서랍에 안 들어가니까요.

AI-native에 가까워지려고 노력하고 있습니다. 일상에서 작은 것들을 바꾸려고요. 그렇게 되면 복리가 쌓여서 큰 차이를 만들어낼 수 있지 않을까 믿습니다.

플라우드 코리아에서 제가 후기를 작성하니 후원을 해주셨습니다. 전용 기획전을 만들어주셨고요. 만약 필요하신 분들께 도움이 될법한 행사이기를 바라며 공유합니다.

PLAUD X 비즈카페

* 참고차, 해당 기획전 통해 판매되는 수익은 제게 돌아오지 않습니다. 순수 필요하신 분들 위해 할인 추가하여 받아온 상태이니 필요하신 분들 구매하시면 좋겠습니다.

Gemini API Managed Agents 기능 확장 등 7월 둘째 주 Google for Developers 위클리 업데이트를 지금 확인하세요!

2026-07-10T10:59:36.759+09:00

개발자 여러분, 안녕하세요!

7월 둘째 주 블로그에 발표된 Google의 주요 개발자 제품별 최신 소식을 살펴보세요.

[주요 개발자 블로그 업데이트]

AI & Machine Learning

Gemini API Managed Agents 기능 확장: 백그라운드 작업, 원격 MCP 등 지원 (Expanding Managed Agents in Gemini API: background tasks, remote MCP and more)
Google의 고성능 웹 AI 추론 엔진, LiteRT.js 소개 (LiteRT.js, Google's high performance Web AI Inference)
Gemini Spark 업데이트: macOS 버전 출시, 앱 연동 기능 추가 등 (Gemini Spark updates: macOS launch, connected apps and more)
Gemini 앱, 더 많은 사용자에게 개인화된 이미지 생성 기능 제공 (The Gemini app is bringing personalized image creation to more users.)
학습 도중 TPU 가동을 중단해도 몇 초 만에 복구: MaxText를 활용한 탄력적 학습 소개 (We terminated a TPU mid-training and it recovered in seconds: Introduction to elastic training with MaxText)
도메인 간 격차 줄이기: Antigravity와 Gemini로 구축한 AI 레이스 코치 (Bridging the Domain Gap: AI Race Coach built with Antigravity and Gemini)
ADK Go 2.0으로 신뢰할 수 있는 멀티 에이전트 앱 구축하기: 새로운 그래프 기반 워크플로 엔진, 내장형 Human-in-the-Loop, 동적 오케스트레이션 알아보기 (Build reliable multi-agent applications with ADK Go 2.0. Discover our new graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration)
공공기관이 위기 대응력을 높이기 위해 Google의 혁신적인 AI 기술을 활용하는 방법 (How governments and organizations are leveraging Google’s AI breakthroughs for crisis resilience)
모두가 함께 배우고 성장하는 시대: Google ‘AI올림’과 함께 AI 역량 한 단계 업그레이드하기 (국문)

Android

Android용 LLM 평가 방식의 진화: Android 벤치마크의 새로운 시대 (Evolving how LLMs are measured for Android: the next era of Android Bench)

* 국문 번역본으로 보시려면 Chrome 창에서 각 영문 링크로 이동한 후 마우스 우측 버튼을 눌러 ‘한국어로 번역'을 선택하시면 됩니다.

* 최신 개발자 문서에 대한 알림을 받아보려면, 여기에서 Google 개발자 프로필을 생성하여 손쉽게 살펴보세요. 다양한 개발자 학습 과정과 커뮤니티 이벤트에 참여하면 여러분의 프로필에 표시할 수 있는 온라인 인증 배지도 함께 드립니다.

Google for Developers

AI가 내 프롬프트를 흘려듣는 이유: 원리부터 다시 본 컨텍스트 엔지니어링

2026-07-07T15:00:39+09:00

분명 가이드에 다 적었는데, 왜 안 될까요?

분명 가이드에 다 적어놨습니다. 그런데 AI는 또 엉뚱한 코드를 내놓았습니다.

저는 디자인 시스템 안에서 MCP(Model Context Protocol) 서버 개발을 주도하고 있었습니다. AI가 우리 디자인 시스템 규칙에 맞는 코드를 생성하도록 가이드하는 게 목적이었고, 그러려면 우리가 원하는 코드가 무엇인지를 모델에게 정확히 전달해야 했습니다.

가이드라인을 짜고 실제 데이터를 넣어가며 테스트했지만 원하는 결과가 잘 나오지 않았습니다. 처음엔 프롬프트 문구나 가이드 양을 탓했습니다. 더 자세히, 더 많이 넣으면 나아지겠지 싶었죠. 그런데 증상이 묘하게 일관되지 않았습니다. 같은 입력인데 어떤 날은 멀쩡하고, 어떤 날은 가이드를 통째로 무시한 코드가 나왔습니다.

아래 두 코드를 비교해 보면 차이가 분명합니다. 첫 번째 코드는 기본값을 명시하지 않은 것은 좋았으나 스페이싱, 디자인시스템 컴포넌트 미사용, 커스텀 스타일 사용 등 규칙을 무시했고, 두 번째 코드는 대체로 규칙을 지켰지만, 기본값을 명시한 예외가 발생했습니다.

//생성 예제 1
@Composable
private fun FavoriteStoreProductCard(
    item: FavoriteStoreProductItem,
    onClick: () -> Unit,
    onFavoriteClick: () -> Unit,
    modifier: Modifier = Modifier,
) {
    Column(
        modifier = modifier.width(102.dp),
        verticalArrangement = Arrangement.spacedBy(10.dp), // 1. 정의된 스페이싱 안 씀
    ) {
        Thumbnail(
            ...
            onClicked = onClick,
            //2. 기본값 명시 안 함
        )

        Text( //3. 디자인시스템 내 텍스트 사용 안 함
            text = item.title,
            modifier = Modifier.fillMaxWidth(),
            style = ItemTitleTextStyle, //4. 커스텀 스타일 선언
            maxLines = 2,
            overflow = TextOverflow.Ellipsis,
        )
    }
}

//생성 예제 2
@Composable
private fun FavoriteItemCard(
    item: FavoriteSectionItem,
    itemWidth: Dp,
    onClick: () -> Unit,
    favoriteIcon: @Composable () -> Unit,
) {
    Column(
        modifier = Modifier.width(itemWidth),
        verticalArrangement = Arrangement.spacedBy(ClayMintTheme.spacings.spacing125),
        //1. 정의된 스페이싱 사용
    ) {
        Thumbnail(
            ...
            pressedEffect = PressedEffect.None, // 2. 기본값 명시
            onClicked = onClick,
        )
        ClayText(//3. 디자인시스템 내 텍스트 사용
            text = item.title,
            modifier = Modifier.fillMaxWidth(),
            color = ClayMintTheme.colorScheme.foregroundPrimary,
            style = ClayMintTheme.typography.descriptionMedium, //4. 디자인시스템 내 스타일 사용
            maxLines = 2,
            overflow = TextOverflow.Ellipsis,
        )
    }
}

도구를 더 만지기 전에, 의심의 방향을 틀었습니다.

가이드를 못 써서가 아니라, 이 모델이 글을 어떻게 읽는지를 내가 모르고 있는 것 아닐까.

팁을 더 찾기 전에, 원리를 먼저 봤습니다

검색하면 프롬프트 팁은 많이 나옵니다. 하지만 팁은 왜 되는지를 알려주지 않아서, 안 될 때 어디를 고쳐야 하는지도 알 수 없었습니다.

그래서 두 가지를 직접 파봤습니다. 하나는 LLM이 입력을 어떻게 처리하는지(원리), 다른 하나는 Claude, GPT, Gemini 같은 최신 모델에서 프롬프팅 권고가 어떻게 바뀌었는지(경향)입니다.

그 전에 하나만 짚고 가자면, LLM은 문장을 사람처럼 이해하는 게 아니라, 다음에 올 확률에 따라 단어(토큰)를 계속 이어 붙입니다. 출력이 확률 분포에서 하나를 고르는 일이다 보니, 같은 입력에도 답이 매번 조금씩 달라질 수 있습니다. 제가 겪은 "어떤 날은 되고 어떤 날은 안 되는" 현상의 뿌리가 여기였습니다. 가이드를 따르는 것조차 확정이 아니라 확률이었던 거죠.

LLM을 깊이는 모르고 활용만 해왔다면, 다음 세 단어만 잡고 기억하고 가면 됩니다.

컨텍스트 윈도우(Context Window): 모델이 한 번에 보는 작업 공간
어텐션(Attention): 그 공간에서 무엇에 주목할지 정하는 방식
컨텍스트 엔지니어링: 그 공간에 무엇을 담을지 설계하는 일

이 세 가지를 축으로 두 개의 질문을 따라갑니다. 먼저 모델이 글을 어떻게 읽는지를 봅니다. 순서대로 읽지 않고 관련도를 한꺼번에 따지는 어텐션, 무한하지 않은 컨텍스트 윈도우, 그리고 나에게 동의하려는 아첨 성향까지요.

첫 번째 질문: LLM은 글을 어떻게 읽을까요?

LLM 모델이 사람처럼 글을 왼쪽에서 오른쪽으로 순서대로 읽는다고 막연히 생각했는데, 아니었습니다. LLM 모델은 어텐션기반으로 컨텍스트 윈도우에 있는 필요한 정보를 한 번에 가져옵니다.

LLM은 순서가 아니라 관련도로 읽습니다

먼저, 어텐션은 입력 안의 각 단어가 다른 모든 단어와 얼마나 관련 있는지를 동시에 따져 의미를 만드는 방식입니다. 순서대로 훑는 게 아니라 한 번에 펼쳐놓고 관련도를 가중치로 계산합니다. 다만 이때 각 단어의 위치(순서) 정보도 함께 반영되며, 특히 앞이나 끝에 놓인 내용일수록 더 큰 가중치를 받는 경향이 있습니다. 모델이 어디에 주의를 두느냐가 곧 결과를 좌우한다는 뜻입니다.

여기서 실제로 도움이 되는 점 두 가지가 나옵니다. 먼저, 관련된 지시와 자료끼리 관계를 분명히 드러내야 한다는 것입니다. 모델은 무엇이 무엇과 얼마나 관련 있는지를 스스로 따지는데, 정작 이어져야 할 지시와 자료 사이에 상관없는 내용이 잔뜩 끼면 그 관련도가 희석됩니다. 그래서 가이드에 줄 글이 아닌 양식이 있으면 도움이 되는데, 그 방법으로 가장 널리 쓰이고 양식이 무겁지 않은 MarkDown 파일이 쓰입니다.
반면, 정보가 많을수록 오히려 정확도가 떨어질 수 있다는 것입니다. 모든 단어 쌍의 관련도를 계산하니 입력이 길어질수록 계산량이 제곱으로 늘고 주의가 묽어집니다. 가이드를 더 많이 넣으면 나아지겠지 했던 게 정확히 반대로 작용하던 이유입니다.
다음은 어텐션이 문장 내 단어 간 관련도를 가중치로 계산하는 방식을 보여줍니다.

가이드 방법 중 하나인 few-shot 즉, 원하는 형식을 몇 개 보여주는 것이 먹히는 이유도 여기서 설명됩니다. 모델 안에는 앞선 패턴을 그대로 복사해 잇는 메커니즘(induction heads)이 있어서, 예시를 본 뒤 같은 형식을 이어가려는 경향이 생깁니다. 예시는 논리를 가르치는 도구가 아니라 형식을 복사하게 만드는 도구인 셈인데, 이 점이 뒤에서 다시 중요해집니다.

컨텍스트 윈도우는 무한한 메모리가 아니라 유한한 책상입니다

컨텍스트 윈도우는 모델이 한 번에 올려놓고 보는 작업 공간입니다. 여기 올라가는 건 제 질문만이 아닙니다. 시스템 프롬프트, 그동안의 대화 이력, 도구와 검색 결과, 지금 생성 중인 답이 전부 같은 공간을 나눠 씁니다.

MCP나 긴 세션에서 대답이 들쑥날쑥했던 체감이 컸던 이유가 이거였습니다. 도구가 돌려준 결과와 누적된 대화가 알게 모르게 쌓여, 정작 중요한 가이드를 책상 밖으로 보이지 않게 밀어내고 있었습니다.

게다가 책상이 넓다고 다 똑같이 잘 보는 것도 아닙니다. 정보가 입력의 한가운데 있으면 활용도가 떨어지는 현상이 관측됩니다(lost in the middle). 중요한 지시는 앞이나 끝에 둘 때 가장 알아듣습니다. 그래서 시스템프롬프트나 사용자의 명령에는 잘 따른다고 느껴질 수 있습니다.
다음은 lost-in-the-middle이 발생할 수 있는 상황에 대한 예시를 보여줍니다.

이를 해소할 수 있는 방안으로 XML 태그나 Markdown 제목처럼 구조를 갖춘 문서가 유리합니다. 제목과 태그가 위치 표지 역할을 해 주면, 모델이 필요한 대목을 더 잘 찾아내 한가운데 묻혀 유실되던 정보가 줄어듭니다.

모델은 사용자에게 동의하고 싶어합니다

토큰 예측만으로 설명되지 않는 동작이 하나 더 있습니다. 모델은 왜 이렇게 고분고분할까요.

사실, 사전학습만 끝낸 모델은 원래 지시를 따르지 않습니다. 지금의 채팅 모델은 그 뒤에 사람의 선호로 보상을 주는 학습(RLHF 등 후처리)을 거쳐, 사람이 좋아하는 답을 내도록 정렬된 결과물입니다. 시스템 프롬프트를 따르는 힘조차 지능이 아니라 이 정렬에서 나옵니다.

문제는 부작용입니다. 보상 과정이 동의는 곧 사용자 만족이라고 함께 학습해버려서, 모델은 사용자에게 동의하고 칭찬하려는 경향이 있습니다(sycophancy, 아첨). 실제로 2025년 4월 OpenAI는 GPT-4o 업데이트가 과도하게 아첨적이라는 이유로 롤백하기도 했습니다.

그래서 "이 설계 괜찮지?"라고 물으면 모델은 "네 좋습니다" 쪽으로 기웁니다. 코드 리뷰에서 "좋은 접근이에요"는 거의 의미없는 멘트입니다. 내가 한 거니까 칭찬하는 것에 가깝죠. 물어보는 방식을 바꿔야 합니다. "이 설계의 약점과 반례부터 찾아줘", "내 결론에 동의하지 말고 반박해줘"처럼요. 사용자의 생각을 드러낸 질문 즉, 유도신문을 피하는 것만으로 답의 정직함이 달라집니다.

두 번째 질문: 그래서 지금은 어떻게 쓸까요?

LLM이 글을 어떻게 읽는지 구조를 들여다보고 나니, 다음 질문이 자연스레 따라왔습니다. 지금 우리가 쓰는 최신 모델은 예전과 무엇이 다를까. AI는 눈에 띄게 좋아졌고, 갈수록 더 복잡한 일을 스스로 처리하도록 설계되고 있습니다. 도구가 이렇게 달라지는데 쓰는 방식만 그대로일 수는 없었죠. 원리는 그대로여도 그 위에서 권장되는 사용법은 모델 세대에 따라 바뀝니다. 그래서 이번엔 최신 모델들의 경향을 따라가 봤습니다.

프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

원리를 알고 나니, 업계가 왜 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로 무게중심을 옮겼는지 이해됐습니다. 프롬프트 엔지니어링이 한 줄을 영리하게 쓰는 법이라면, 컨텍스트 엔지니어링은 모델이 볼 토큰 전체를 무엇으로, 얼마나, 어떤 순서로 채울지 설계하는 일입니다. 어텐션과 컨텍스트 윈도우의 한계가 그대로 근거가 됩니다.

프롬프트 기법이 한물갔다는 뜻은 아닙니다. 기법은 그대로 살아 있고, 사고의 단위가 한 줄에서 컨텍스트 전체로 넓어졌을 뿐입니다. 핵심 원칙은 세 가지입니다.

다 넣지 말고 관련된 것만 넣습니다. 정보가 많으면 어텐션이 묽어지니까요.
핵심 지시와 자료는 앞이나 끝에 둡니다. 한가운데 묻으면 놓치기 쉽습니다.
길이는 비용이자 노이즈입니다. 충분한 만큼만 최소로 넣습니다.

특히 마지막이 중요합니다. 관련 없는 텍스트는 그냥 쓸모없는 정도가 아니라 적극적으로 해롭습니다. 어텐션을 분산시켜 틀린 답을 유도하니까요. 혹시 모르니 다 붙여두기가 가장 흔한 안티패턴이고, 제가 바로 그러고 있었습니다.

예를 들어, 이 원리가 잘 드러나는 예가 하위 에이전트(sub-agent) 오케스트레이션입니다. 상위 에이전트, 즉 슈퍼바이저의 작업 공간은 일이 진행될수록 어질러집니다. A안과 B안을 비교하다 A안으로 정해도 기각된 B안과 그동안 쌓인 도구 결과가 그대로 남는데, 정작 "A안을 구현하라"는 작업에는 대부분 노이즈입니다. 그래서 슈퍼바이저가 그 어질러진 공간에서 직접 구현하는 것보다, 정제된 목표만 들려 하위 에이전트를 깨끗한 새 공간에서 돌리는 편이 그 작업에는 더 낫습니다.
다음은 하위 에이전트에게 전달하는 문맥에 따라 발생하는 컨텍스트 윈도우의 차이에 대해 보여줍니다.

하위 에이전트가 더 똑똑해서가 아닙니다. 대개 같은 모델이고, 차이는 일꾼이 아니라 깨끗해진 작업 공간에서 옵니다. 다만 공짜는 아닙니다. 슈퍼바이저가 목표를 제대로 정제해 넘겨야 하고, 버린 맥락에 진짜 제약이 숨어 있었다면 그걸 빼먹고 넘기는 순간 하위 에이전트는 같은 함정에 걸립니다. 결국 어려움은 사라지는 게 아니라 무엇을 넘기고 무엇을 뺄지 고르는 일로 옮겨갈 뿐입니다.

이 흐름은 여기서 멈추지 않습니다. 프롬프트, 컨텍스트, 하네스, 루프 엔지니어링 순으로 한 칸씩 올라갑니다. 매번 손으로 시키는 대신 에이전트가 도는 루프(성공 기준, 멈출 조건, 자가 수정)를 설계하는 쪽으로 무게가 옮겨가고, 가치의 단위도 응답 한 번에서 목표까지 가는 방식으로 바뀌어가고 있습니다.

모델이 강해질수록 지시는 가벼워집니다

컨텍스트를 어떻게 채울지가 바뀌면, 프롬프트를 쓰는 습관 자체도 함께 낡습니다. 제가 딱 그랬어요. AI를 처음 익히던 무렵의 모델은 추론이 약해서 단계를 하나하나 알려줘야 했고, 그래서 "단계별로 생각해(let’s think step by step)" 강제, 과한 few-shot, 깐깐한 절차 나열을 좋은 습관으로 배웠습니다.

그런데 지금의 추론 모델들은 복잡한 문제를 해결하도록 발전해왔고 스스로 단계를 나눕니다. 배워둔 습관이 오히려 독이 됐어요. 제약을 스무 개 나열하니 서로 충돌했고, few-shot을 도배하니 그 예시만 사용했고, 어설픈 사고 경로를 강요하면 성능이 떨어지기도 했습니다. 그래서 "어떻게 하는지"를 하나하나 알려주던 걸 접고, "무엇이 성공인지"를 주고 맡기는 쪽으로 제 습관을 바꿨습니다. 제약과 금지를 잔뜩 나열하기보다 핵심만 긍정형으로 남기고, 로직을 가르치려던 few-shot은 형식과 톤을 고정하는 용도로만 줄였습니다.

가장 크게 바꾼 습관은 목표를 검증 가능하게 말하는 것이었습니다.

”버그 고쳐줘” → “이 실패하는 테스트를 통과시켜줘”
“정리해줘” → “이 표에서 누락된 행을 찾아 표시해줘”

이렇게 성공 조건과 지켜야 할 규칙을 못 박아 모델의 행동을 붙들어 두는 층이 하네스입니다. 과도한 절차를 대신 "무엇이 성공인가"를 규정해 두는 것이죠. 그럼 이 방향을 실제 MCP 가이드에는 어떻게 담았을까요.

내가 검토한 두 갈래: 가이드라인과 하네스(프롬프트)

개선 방법은 두 갈래였습니다. 하나는 문맥이 부족하다고 보고 가이드라인을 더 주는 것, 다른 하나는 하네스 엔지니어링이 필요하다고 보고 동작을 규정하는 프롬프트를 더하는 것이었습니다. 둘은 푸는 문제가 다릅니다.

구분	가이드라인 추가	하네스(프롬프트) 추가
푸는 문제	모델이 무엇을 알아야 하는가 (지식과 맥락)	모델이 어떻게 행동해야 하는가 (절차, 검증, 중단 조건)
들어가는 내용	디자인 시스템 규칙, 컴포넌트와 토큰 정의, 예시	출력 형식 계약, 검증 루프, 유저 입력에 휘둘리지 않게 하는 규정
강할 때	모델이 우리 도메인을 모를 때	유저 입력이 들쭉날쭉해도 일관된 동작이 필요할 때
과하면	컨텍스트가 길어져 핵심이 묻힘	절차를 과하게 명시해 최신 추론 모델의 발목을 잡음

가이드라인 쪽에서 실제로 어려움을 겪은 적이 있습니다. dp 값은 반드시 spacing 토큰으로 지정하라고 가이드했더니, 모델이 이미지 크기 108dp를 spacing1000(80) + spacing300(24) + spacing50(4)으로 조합해버렸습니다. 간격이 아니라 크기 값은 토큰 없이 로우(raw) dp를 써야 하는데 말이죠. 게다가 few-shot 예시까지 함께 넣었더니 그 패턴을 모든 사이즈 계산에 확대 적용했습니다.

규칙이 틀린 게 아니라 너무 문자 그대로였던 게 문제였습니다. 그래서 특정 케이스를 못 박는 대신, "간격과 여백은 spacing 토큰으로, 아이콘이나 이미지 같은 크기 값은 로우 dp로" 처럼 경계를 원리로 이해되게 한 단계 추상화해서 다시 썼습니다.

그래서 무엇이 달라졌나

원리와 경향을 알고 가이드와 프롬프트를 다시 손봤습니다. 크게 세 가지를 바꿨습니다. 관련 있는 것만 남겨 컨텍스트를 큐레이션했고, 흩어져 있던 규칙을 레이어별로 모아 어떤 결정을 어디서 내릴지를 고정했고, 절차를 떠먹이는 대신 성공 기준과 행동 규정(하네스)을 줬습니다.

하네스를 정리했습니다: 긴 문장을 쪼개고, 결정의 자리를 고정

가이드와 프롬프트는 틀리진 않았지만 모호했고, 그 모호함이 흔들림의 1차 원인이었습니다. 60단어를 넘는 한 문장에 규칙 대여섯 개가 뭉쳐 있으면 모델은 그중 일부를 실행마다 다르게 빠뜨렸습니다. 그래서 규칙과 예산은 그대로 둔 채 구조만 바꿔, 한 문장을 원자 단위 지시로 쪼갰습니다.

//Before — 한 문장에 규칙 다섯 개
아이콘마다 search-icon으로 ClayMintDrawable id를 확인하고 ClayMintDrawable import를 추가하며, _fill/_line 쌍은 정적 디자인이 아니라 바인딩된 state/variant에서 접미사를 고르고, 상태가 있는 아이콘은 코드에서 분기한다(state → _fill / !state → _line);  ...

//After — 원자 지시로 분해
아이콘마다:
- search-icon으로 ClayMintDrawable id를 확인한다.
- ClayMintDrawable import를 추가한다.
- _fill / _line 쌍은 바인딩된 state/variant에서 접미사를 고른다.
- 코드에서 상태로 분기한다(state → _fill, !state → _line).
- search-icon 결과가 없을 때만 그 드로어블을 추론으로 표시한다.

또 하나는 결정의 소유권을 고정한 것입니다. "raw 픽셀을 토큰으로 바꿀지"(토큰 해석), "그 토큰을 padding에 쓸지 width에 쓸지"(간격 방출), "어디까지 추론으로 표시할지"(추론 경계)까지, 이 세 결정을 한 문장에 섞어두니 모델이 매번 다르게 합쳤습니다. 각 결정을 늘 같은 레이어의 같은 규칙에서 내리도록 나눴더니, 같은 값이 같은 자리에서 같게 처리됐습니다.

절차 대신 성공 기준과 하네스를 줬습니다

"이렇게 저렇게 해라"를 잔뜩 나열하는 대신, 무엇이 맞는지를 정의하고 그걸 스스로 지키게 했습니다. 두 가지가 핵심이었습니다.

첫째, 사후 검증 규칙셋입니다. 생성이 끝난 코드를 컴포넌트 manifest·토큰·아이콘 카탈로그가 확인 사항을 기준으로 삼아 점검하는 규칙 열여섯 개를 뒀습니다. 예를 들어 "컴포넌트 검색 결과가 비면 그 역할에는 컴포넌트가 없다는 뜻이니, 그럴듯한 이름을 지어 부르지 말고 빌딩블록이나 토큰 기반 custom으로 만들라" 같은 식입니다. 도구가 확정할 수 없는 것(픽셀 단위 시각 일치)은 애초에 검증 범위 밖으로 명시해, 규칙이 못 지킬 약속을 하지 않게 했습니다.

둘째, 컴포넌트 선택 사다리입니다. 전에는 "완성형 컴포넌트에 있나 없나" 이분법뿐이라, 없으면 곧장 custom UI로 직행했고 그 구조가 실행마다 달랐습니다. 완성형과 custom 사이에 표준 빌딩블록 단계를 끼워, 완성형 → 빌딩블록 → 토큰 기반 custom → raw 순으로 한 단계씩만 내려가게 했습니다. "없으면 즉흥 custom"이 "표준 재료 우선"으로 수렴했습니다.

도입부에서 소개한 그 코드가 규칙을 지키기 시작했습니다

도입부의 어긋났던 네 지점이 개선 뒤 어떻게 바뀌었는지 나란히 놓으면 이렇습니다.

지점	before (1장 코드)	after
스페이싱	`Arrangement.spacedBy(10.dp)`	`Arrangement.spacedBy(ClayMintTheme.spacings.spacing125)`
기본값	`pressedEffect = PressedEffect.None` 명시	명시 안 함
텍스트	`Text(...)`	`ClayText(...)`
스타일	`style = ItemTitleTextStyle` (커스텀 선언)	`style = ClayMintTheme.typography.descriptionMedium`

결과는 분명했습니다. 결과가 상이한 경우가 0이 되진 않았지만, 가이드가 지켜지지 않는 빈도가 5번에 1~2번에서 10번에 1번 미만으로 줄었습니다. 도구가 확정하지 못해 [추론]으로 남기던 영역 자체가 줄어든 덕분입니다. 그러면서 마땅한 완성형 컴포넌트가 없을 때 무엇으로 대신할지 고르는 판단처럼, 사람이 아니면 안 된다고 보고 남겨뒀던 부분도 이제 충분히 맡길 만해졌습니다.

여기서 "어겼다"와 "나아졌다"의 기준은 이렇습니다. 같은 Figma 입력을 여러 번(기본 4회) 실행해 산출물 코드에서 뽑은 구조 신호(어떤 컴포넌트·토큰·아이콘을 썼는지, [추론] 주석을 어디에 달았는지)가 실행마다 갈리면 흔들림 1건으로, 생성 코드가 manifest·토큰·가이드 규칙에 어긋나면 규칙 위반 1건으로 셉니다. 판정은 눈대중이나 LLM 채점이 아니라(채점기 자체가 흔들리니까) 이 신호 집합을 기계적으로 비교해 내렸고, 위 "5번에 1~2번"은 그 반복 실행에서 관찰한 값입니다.

정리

원하는 결과를 얻지 못한 진짜 원인은 도구가 아니라, 모델을 모르고 쓰던 저 자신이었습니다. LLM모델이 프롬프트를 관련성을 따져 읽고, 작업 공간이 유한하며, 나에게 동의하려 한다는 것. 이 세 가지만 알아도 프롬프트를 보는 눈이 달라집니다.

다만 이게 모든 모델에 통하는 만능은 아닙니다. 위 습관들은 추론이 좋은 최신 모델을 전제로 합니다. 오래됐거나 추론이 약한 모델에서는 few-shot과 단계별 가이드가 여전히 잘 먹히고, 작은 경량 모델을 하위 작업에 쓸 때는 오히려 절차와 검증 규칙을 더 촘촘하게 주는 편이 안정적입니다.

결국 남은 몫은 모델에게 잘 부탁하는 법이 아닌, 모델이 어떻게 읽는지를 알고 무엇을 컨텍스트로 제공할지 설계하는 일입니다. 혹시 분명 다 적었는데 왜 안 되지 싶다면, 프롬프트를 한 줄 더 다듬기 전에 책상(Context Window)에 뭐가 올라가 있는지부터 보시길 권합니다.

생성만 놓고 보면 이전보다 훨씬 쉬워졌고, 진짜 실력은 검증과 판단 그리고 방향 설정에 있습니다.

한눈에 보는 결론: Do / Don’t

Don’t (예전 습관)	Do (지금)
관련 있어 보이면 일단 다 넣는다	필요한 것만 골라 넣는다 (컨텍스트 큐레이션)
지시의 중요도와 상관없이 프롬프트를 늘어놓는다	핵심 지시는 앞이나 끝에 둔다
프롬프트가 길수록 더 정확해진다고 믿는다	길이는 비용이자 노이즈다. 충분한 만큼만 넣는다
절차를 하나하나 떠먹인다	목표와 성공 기준을 주고 맡긴다
금지 사항을 잔뜩 나열한다	원하는 행동을 긍정형으로 지시한다
로직까지 few-shot으로 가르친다	예시는 형식과 톤 고정용으로만 쓴다
규칙을 특정 케이스로 못 박는다	경계를 원리로 적는다
큰 작업을 프롬프트 하나에 다 몰아넣는다	하위 작업은 정제된 목표만 줘서 분리한다
"이거 괜찮지?"로 확인받는다	"약점과 반례부터 찾아줘"로 검증시킨다
한 번 잘 나왔으니 늘 그렇게 나온다고 믿는다	출력은 확률이라 매번 흔들린다고 보고, 중요한 건 다시 확인한다
최신 모델이니 무조건 짧게 쓴다	대상 모델의 성격에 맞춰 조절한다

The post AI가 내 프롬프트를 흘려듣는 이유: 원리부터 다시 본 컨텍스트 엔지니어링 first appeared on 우아한형제들 기술블로그.

AI 인프라 설계의 기술적 레퍼런스, 를 소개합니다

2026-07-13T11:57:40+09:00

[![NHN Cloud_meetup banner_FactoryX WP_202606_900.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetup%20bannerFactoryX%20WP202606900.png)](https://www.nhncloud.com/kr) ## 어제의 경험으로 내일의 변화를 만들어 내는 공장, NHN FactoryX 필요한 만큼의 GPU를 사서 랙에 꽂으면 AI 인프라가 완성될까요? 실제로 대규모 GPU 클러스터를 운영해 본 팀이라면, 장비 구매는 끝이 아니라 시작이라는 것을 알 수 있습니다. 수백 장의 GPU가 동시에 통신을 시도하는 순간 네트워크에 병목이 발생하고, 학습 데이터를 읽어오는 속도가 GPU 연산을 따라가지 못해 고가의 장비가 데이터를 기다립니다. 최신 AI GPU 랙의 전력 밀도는 60~90kW에 달하지만 공랭식 냉각의 실질적 한계는 30kW 부근이라 그 이상에서는 GPU 온도를 억제할 수 없고, 결국 시스템이 스스로 성능을 깎아내리기 시작합니다. GPU를 '사는 것'과 GPU를 'AI 인프라로 만드는 것'은 완전히 다른 문제입니다. 그리고 이 간극을 메우는 데 필요한 기술적 의사결정은 생각보다 많고, 예상보다 깊습니다. NHN FactoryX는 NHN Cloud가 7년 이상의 GPU 인프라 운영 경험을 바탕으로 만든 AI 워크로드를 위한 풀스택 환경입니다. NHN FactoryX 서울 데이터 센터에 4,080장의 GPU를 단일 클러스터로 묶어 FP8 기준 27.4 EFLOPS 규모의 연산 능력을 확보했습니다. 구조는 세 개의 계층으로 나뉩니다. 맨 아래에서 수랭식 데이터 센터와 GPU 클러스터(Infrastructure)가 물리적 기반을 제공하고, 그 위에서 GPU Live와 AI EasyMaker(Platform)가 GPU 자원의 동적 할당과 ML 파이프라인을 담당하며, 최상위에는 ProjectX(Service)가 위치해 기업 전용 AI 에이전트 개발·연동 환경을 제공합니다. 현재 산업계·학계·공공 기관이 이 플랫폼 위에서 LLM 학습, 멀티모달 AI 연구, 추론 서비스를 운영하고 있습니다. ![01_3layers_900.png](https://image.toast.com/aaaadh/real/2026/techblog/013layers900.png) 이번에 발간한 〈NHN FactoryX 기술 백서〉는 이 중 인프라와 플랫폼 영역의 설계 근거를 약 60여 페이지에 걸쳐 풀어 설명한 기술 백서입니다.
## NHN FactoryX의 모든 것, 〈NHN FactoryX 기술 백서〉 AI 인프라의 도입은 더 이상 장비 구매가 아니라 기술 검증을 동반하는 의사결정 프로세스입니다. GPU 모델 사양만 비교해서는 안 되며, 인터커넥트 토폴로지, 스토리지 I/O, 네트워크 병목 대응, 냉각 설계, 선형 확장성까지, 풀스택 관점의 설계를 동시에 고민해야 합니다. 이 전체를 한 곳에서 체계적으로 다룬 자료가 부재했기 때문에 NHN Cloud는 AI 인프라 요구 사항에 NHN FactoryX가 어떻게 답하고 있는지를 하나의 문서로 정리한 기술 백서를 발간했습니다. 이 백서는 위에서 다룬 NHN FactoryX의 세 레이어 가운데 인프라와 플랫폼, 즉 AI 워크로드를 물리적으로 지탱하고 자원을 지능적으로 배분하는 두 레이어의 설계 철학과 기술 근거를 담고 있습니다. 백서는 먼저 기존의 범용 클라우드 인프라가 AI 워크로드에 대응하기에 어떤 점에서 한계가 있는지 짚는 데서 출발합니다. 기존 데이터 센터는 CPU 중심 연산, 공랭식 냉각, 이더넷 기반 네트워크를 전제로 설계되어 범용 워크로드에는 효율적이지만, 대규모 AI 학습에서는 구조적 병목에 직면합니다. 이 한계를 넘기 위해 NHN FactoryX가 어떤 설계 선택을 했는지를, 다음 네 개의 핵심 영역으로 정리합니다. ![02_agenda_900.png](https://image.toast.com/aaaadh/real/2026/techblog/02agenda900.png) 각 영역은 독립적으로 참조할 수 있지만, 풀스택 관점에서 서로 연결되어 있습니다. 여기에서는 이 백서가 다루는 질문 중 핵심이 되는 내용을 간략하게 훑어보고자 합니다.
## 〈NHN FactoryX 기술 백서〉 훑어보기 ### "왜 공기로는 안 되나요?" - 공랭식 냉각의 구조적 한계 AI GPU의 전력 밀도는 세대마다 가파르게 올라가고 있습니다. A100 시절에는 랙당 13\~39kW 수준이었지만, 최신 B200/B300 세대에서는 랙당 90kW에 육박합니다. 문제는 여기서 발생합니다. 공기의 체적 열용량은 물의 약 1/3,500에 불과합니다. 같은 열을 제거하려면 공기는 물보다 3,500배 많은 양이 필요하다는 뜻입니다. 랙당 전력 밀도가 30kW를 넘는 순간부터 공랭식은 열역학적 한계에 부딪힙니다. 〈NHN FactoryX 기술 백서〉는 이 한계를 ASHRAE 등급 기준과 CFD 시뮬레이션 연구를 인용해 구조적으로 짚어보고, D2C 수랭식 도입 시 반드시 검증해야 할 다섯 가지 요건(벤더 호환성, 인터페이스 표준화, 운전 파라미터, 확장성, 수질 관리)을 하나하나 설명합니다. NHN FactoryX는 이 과정을 거쳐 프리쿨링 연계 운전으로 PUE 1.15 이하를 달성할 수 있는 구조를 만들었습니다. 공랭식 대비 연간 냉각 에너지를 약 30~40% 절감할 수 있는 수치입니다. 자세한 내용은 〈NHN FactoryX 기술 백서〉 2.3절 전력 및 냉각 설계에서 확인하실 수 있습니다.
### "GPU 수천 장을 어떻게 나눠 쓰나요?" - GPU Live의 설계 철학 GPU 클러스터를 팀별로 고정 배정하면 운영은 단순하지만, 대규모 클러스터 트레이스 분석에서 자원 활용률이 한 자릿수에서 30%대에 머무르는 사례가 보고되어 왔습니다. GPU Live는 이 문제를 동적 할당 기술로 풀되, 자체 스케줄러를 새로 만들지 않고, Kubernetes 표준 생태계의 검증된 컴포넌트 위에 NHN FactoryX 환경에 맞는 운영 정책을 얹는 방식을 택했습니다. GPU 드라이버 업데이트나 분산 학습 프레임워크의 변화를 표준 경로로 흡수할 수 있고, 향후 NPU 같은 이종 가속기가 등장해도 동일한 표준 인터페이스로 통합이 가능하도록 하기 위함입니다. 그 위에 GPU Live가 직접 설계한 영역이 있습니다. 3계층 멀티테넌시(System → Organization → Project)로 조직 간 자원·정책·권한을 격리하고, GPU 기준 Best-fit 빈패킹으로 단편화를 줄이며, 쿼터·오버부킹·자동 회수를 결합해 활용률을 끌어올립니다. 학습 워크로드는 Gang Scheduling으로 일괄 시작·종료하고, 추론 워크로드는 인스턴스 단위로 장애 복구와 재배치를 처리합니다. 같은 GPU 풀에서 성격이 전혀 다른 두 워크로드를 안정적으로 수용하는 구조입니다. 자세한 내용은 〈NHN FactoryX 기술 백서〉 2.4절 GPU 동적 할당 기술(GPU Live)에서 확인하실 수 있습니다.
### "베어메탈이면 충분하지 않나요?" — GPUaaS를 선택한 이유 베어메탈 방식은 GPU 자원을 물리 서버 단위로 직접 할당하므로 하드웨어 성능을 최대한 활용할 수 있습니다. 다만 다수의 사용자가 동일 인프라를 공유할 경우 테넌트 간 보안 격리가 보장되지 않고, 테넌트별 환경 구성이 상이하여 장애 발생 시 일관된 운영 정책을 적용하기 어렵다는 한계가 있습니다. NHN FactoryX는 이 한계를 극복하기 위해 GPU 인프라 상위 계층에 GPUaaS 플랫폼을 구축하는 방식을 택했습니다. 테넌트·워크스페이스·프로젝트로 이어지는 계층적 구조를 기반으로 자원과 보안 통제를 일관되게 적용하고, 한 기관에서 대규모 학습으로 자원 사용량이 급증하더라도 다른 기관의 서비스에는 영향이 없는 격리 구조를 실현했습니다. 실제로 957개 GPU 노드 위에서 산업계·학계·연구계의 다수 기관이 독립된 워크스페이스를 운영하고 있습니다. 서비스 계층이 추가되면 네트워크 병목으로 인한 성능 저하가 우려될 수 있지만, NHN FactoryX는 GPUaaS 플랫폼 환경에서 255노드 규모의 HPL(High Performance Linpack) 벤치마크를 수행해 베어메탈과 동일한 수준의 성능을 확인했습니다. 컨테이너가 호스트 수준의 네트워크 성능을 유지하도록 설계한 결과입니다. 자세한 내용은 〈NHN FactoryX 기술 백서〉 06장 활용 사례에서 확인하실 수 있습니다.
## 마치며 이 글에서는 〈NHN FactoryX 기술 백서〉의 핵심 내용 중 일부를 살펴보았습니다. 백서 전체를 관통하는 메시지를 한 문장으로 요약해 보면 이렇습니다. AI 인프라는 개별 하드웨어의 성능 향상을 넘어, 물리적 공간 설계부터 전력 및 냉각 효율, 초고속 네트워크 튜닝, 소프트웨어 정의 기반의 관리 플랫폼까지 모든 요소가 유기적으로 통합되어야 합니다. NHN FactoryX는 이 통합을 하나의 공간에서 실현합니다. 수랭식 데이터 센터 위에 GPU 클러스터를 구성하고, GPUaaS 플랫폼으로 자원을 관리하며, AI 개발 플랫폼까지 3개 레이어를 풀스택으로 제공합니다. 동일한 GPUaaS 아키텍처 위에서 멀티테넌트 공유 환경과 기업 프라이빗 전용 환경이 모두 구현되며, 957개 GPU 노드 규모에서 베어메탈 동등 수준의 성능과 조직 간 보안 격리를 동시에 달성하고 있습니다. AI 인프라는 현재진행형입니다. GPU 세대 전환에 따른 전력 밀도 증가, Kubernetes DRA를 비롯한 자원 관리 표준의 진화, NPU 등 이종 가속기의 등장은 인프라 설계의 전제 조건을 지속적으로 변화시킵니다. NHN FactoryX는 차세대 GPU 플랫폼까지의 상위 호환성을 전제로 수랭식 인프라를 설계하였으며, GPU Live의 동적 할당 모델을 이종 가속기로 확장하기 위한 기술 검토를 진행하고 있습니다. 백서에는 이 글에서 미처 다 다루지 못한 GPU 세대별 사양 비교, 5가지 성능 저하 패턴과 설계 단계 체크리스트, Scalable Unit 기반 증설 전략, 기업 프라이빗 AI 인프라 구축 사례 등이 구체적인 수치와 다이어그램과 함께 담겨 있습니다. AI 인프라 도입을 검토하는 기술 의사결정자, 대규모 AI 시스템을 설계하거나 운영하는 아키텍트 및 엔지니어 분들께 실질적인 기술 레퍼런스로 활용되길 기대합니다. 긴 글을 읽어 주셔서 감사합니다. ‍♀️ > [NHN FactoryX 공식 포털 바로 가기](https://www.nhnfactoryx.com/?utm_source=meetup&utm_medium=post&utm_campaign=meetup&utm_content=0713_xwhitepaper) > > [NHN FactoryX 기술 백서 다운로드](https://info.nhncloud.com/factoryx-whitepaper?utm_source=meetup&utm_medium=post&utm_campaign=meetup&utm_content=0713_xwhitepaper) > > [NHN FactoryX 소개서 다운로드](https://info.nhncloud.com/factoryxbrochure?utm_source=meetup&utm_medium=post&utm_campaign=meetup&utm_content=0713_xwhitepaper) [![NHN Cloud_meetup banner_footer_grayd9d9d9_202606_900.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetup%20bannerfootergrayd9d9d9202606900.png)](https://www.nhncloud.com/kr)

Redis와 Valkey를 해킹해 보자(Feat. CVE ID)

2026-07-06T14:15:25+09:00

[![NHN Cloud_meetup banner_cve_202607_900.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetup%20bannercve202607900.png)](https://www.nhncloud.com/kr) ## 들어가며 안녕하세요. NHN Cloud NoSQL개발파트 이준영입니다. 여러분은 CVE(Common Vulnerabilities and Exposures)에 대해 들어보셨나요? CVE란 공개적으로 알려진 소프트웨어 및 하드웨어의 보안 취약점을 식별하고 명명하기 위한 표준화된 체계입니다. 각 취약점은 CVE ID라는 고유 식별자를 부여받으며, 이는 전 세계 보안 커뮤니티가 동일한 취약점을 정확하고 일관되게 추적하고 논의할 수 있도록 돕습니다. 저는 작년에 개인 프로젝트로 Valkey와 Redis의 취약점을 연구하였는데요. 운이 좋게 CVE ID까지 발급받게 되었습니다. 이번 글에서는 해당 취약점의 분석 내용을 공유하고자 합니다. ### CVE 정보 | 구분 | 세부 내용| | --- | --- | | CVE | [https://nvd.nist.gov/vuln/detail/CVE-2025-67733](https://nvd.nist.gov/vuln/detail/CVE-2025-67733) | | PoC | [https://github.com/JYlab/CVE-2025-67733](https://github.com/JYlab/CVE-2025-67733) | | GitHub Security Advisory | [https://github.com/valkey-io/valkey/security/advisories/GHSA-p876-p7q5-hv2m](https://github.com/valkey-io/valkey/security/advisories/GHSA-p876-p7q5-hv2m) | | Valkey 패치 | - 취약 버전: 9.0.1 이하
- 패치 버전: 9.0.2, 8.1.6, 8.0.7, 7.2.12 | | Redis 패치 | - 취약 버전: 8.4.1 이하
- 패치 버전: 8.4.2, 8.2.5, 8.0.6, 7.4.8, 7.2.13 | | CVSS | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H (8.5/10) |
## 개요 먼저 RESP 인젝션 공격에 대해 설명하고자 합니다. 분석 내용은 Valkey 8.1.4 버전의 코드를 기준으로 작성하였습니다. 해당 취약점을 통해 Valkey 서버의 소켓 포이즈닝을 유발하여 데이터를 변조할 수 있으며, DoS 공격 또한 가능합니다. 공격 방법은 Valkey의 `EVAL` 명령에 다음과 같은 Lua 스크립트를 실행하는 것입니다. ![NHN Cloud_meetup_data-forgery_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetupdataforgery1.png) 이것이 어떻게 취약점을 유발하는지 이해하려면 `RESP`, `Lua 스크립트 실행 흐름`, `redis.error_reply() 서버 API`, `error() 내장 함수` 등에 대한 이해가 필요합니다. 따라서 배경 지식을 먼저 설명한 뒤 취약점 분석 내용을 공유하겠습니다.
## RESP RESP(Redis Serialization Protocol)는 Valkey, Redis 계열에서 클라이언트↔서버가 명령/응답을 주고받을 때 사용하는 직렬화 프로토콜입니다. 타입 접두어(prefix) + CRLF(`\r\n`)로 구분하고, Bulk는 길이를 명시하여 사용합니다. 대표 타입(Simple String, Error, Integer, Bulk String, Array)과 사용 예시는 다음과 같습니다. ### Simple String(성공 메시지) * 프로토콜: `+` * 예시: `+OK\r\n`, `+PONG\r\n` ### Error(실패 사유) * 프로토콜: `-` * 예시: `-ERR unknown command 'HELLO'\r\n` ### Integer(정수 반환 - 카운트/증가 결과 등) * 프로토콜: `:` * 예시: `:0\r\n`, `:123\r\n` ### Bulk String(길이+데이터 - 값/바이너리) * 프로토콜: `$` * 예시: `$5\r\nhello\r\n`, `$-1\r\n` (null), `$0\r\n\r\n` (빈 값) ### Array(여러 RESP 값의 리스트 - 명령도 보통 이 형태) * 프로토콜: `*` * 예시: `*0\r\n`, `*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n`, `*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n`
## Lua 스크립트 실행 흐름 Valkey에서 `EVAL` 명령으로 Lua 스크립트를 실행하면 다음과 같은 흐름으로 처리됩니다. ```text EVAL 명령 → luaCallFunction() → Lua 스크립트 실행 → (오류 발생 시) → 오류 처리 → 클라이언트 응답 ``` ### luaCallFunction() `luaCallFunction()`은 Lua 스크립트를 실행하고, 실행 결과나 오류를 처리하는 핵심 함수입니다. ![NHN Cloud_meetup_luaCallFunction_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20CloudmeetupluaCallFunction1.png) 이 함수에서 중요한 점은 다음과 같습니다. 1. `lua_pcall()`로 Lua 스크립트를 실행 2. 오류 발생 시 `luaExtractErrorInformation()`으로 오류 정보 추출 3. 오류 타입에 따라 `luaReplyToRedisReply()` 또는 직접 오류 응답 전송 오류가 발생했을 때, 오류 메시지가 어떻게 만들어지고 클라이언트에게 전송되는지가 이 취약점의 핵심입니다. ## redis.error\_reply() 서버 API 동작 방식 Valkey의 Lua 스크립트 엔진에서는 오류 발생 시 오류를 테이블 형태로 반환할 수 있는 기능을 제공합니다. `redis.error_reply()`는 이와 같은 오류 테이블을 커스텀하게 정의할 때 사용하는 API입니다. ![NHN Cloud_meetup_luaRedisErrorReplyCommand_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20CloudmeetupluaRedisErrorReplyCommand1.png) 위 Server API를 호출하면 C 함수 중 `luaRedisErrorReplyCommand()`가 호출됩니다. 이 함수는 `redis.error_reply` 파라미터의 개수와 String 여부를 판단하고, 만약 문자열에 `-`가 없으면 `-`를 추가로 붙인 뒤 `luaPushErrorBuff()` 함수에 `err_buff` 인자로 넘깁니다. RESP의 Error 프로토콜 양식이 `-`로 시작하기 때문입니다.
## error() 내장 함수 `error()`는 Lua의 내장 함수로, 스크립트 실행을 즉시 중단하고 오류를 발생시킵니다. Valkey에서 Lua 스크립트가 `error()`를 호출하면, 인자로 전달된 값이 클라이언트에게 오류 응답으로 전송됩니다. ![NHN Cloud_meetup_ex_error_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetupexerror1.png) 여기서 핵심은 `error()`의 인자로 `redis.error_reply()`가 반환한 오류 테이블을 전달할 수 있다는 점입니다. 이 경우 오류 테이블의 `err` 필드 값이 그대로 RESP Error 응답으로 클라이언트에게 전송됩니다. 공격 관점에서의 흐름은 다음과 같습니다. 1. `redis.error_reply(...)` → 악성 페이로드가 포함된 오류 테이블 생성 2. `error(오류 테이블)` → 스크립트 중단 및 오류 응답 전송 트리거 3. 서버 → 클라이언트로 오류 메시지 전송(이 과정에서 취약점 발생) 즉, `error()`는 `redis.error_reply()`로 만든 악성 페이로드를 실제로 클라이언트에게 전송하는 트리거 역할을 합니다. 다음 그림은 `luaCallFunction()` 함수의 일부이며, `error()`에 의해 발생한 오류 값이 `lua_pcall()`에 의해 캡처되는 모습입니다. ![NHN Cloud_meetup_error_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetuperror1.png) ## luaPushErrorBuff() 함수 다음 그림은 `luaPushErrorBuff()` 함수의 일부입니다. 입력으로 들어온 `err_buff`로부터 error code를 분리한 뒤, `\r\n`를 `sdstrim()`한 후 `final_msg`로 만들어 오류 테이블의 `err` 필드를 채웁니다. ![NHN Cloud_meetup_luaPushErrorBuff_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20CloudmeetupluaPushErrorBuff1.png) 여기서 중요한 부분은 `sdstrim()` 함수에 의해 취약점이 발생한다는 점입니다. `sdstrim(msg, "\r\n")` 함수는 `msg` 문자열의 양 끝에서 `\r`, `\n`에 해당하는 문자가 있으면 이를 제거하는 함수입니다. 해당 함수의 문제점은 문자열 전체에서 `\r\n`를 제거하는 것이 아니라, 문자열 양 끝에서만 `\r\n`을 제거한다는 점입니다.
## 취약점: 소켓 포이즈닝을 통한 데이터 변조 취약한 오류 메시지가 실제로 클라이언트 버퍼에 어떻게 쓰여지는지 살펴보겠습니다. (여기서 말하는 '클라이언트 버퍼'는 서버가 각 클라이언트 연결별로 유지하는 서버 사이드 출력 버퍼, 즉 `c->buf`를 의미합니다.) ### 전체 흐름 ```text luaCallFunction() ↓ luaExtractErrorInformation() → err_info.msg = "X\r\n+FAKE" ↓ sdscatfmt(final_msg, "-%s", err_info.msg) → final_msg = "-X\r\n+FAKE" ↓ addReplyErrorSdsEx(c, final_msg, flags) ↓ addReplyErrorLength(c, err, sdslen(err)) ↓ addReplyProto(c, s, len) ← s = "-X\r\n+FAKE" addReplyProto(c, "\r\n", 2) ↓ _addReplyToBufferOrList(c, s, len) ↓ _addReplyToBuffer(c, s, len) ↓ memcpy(c->buf + c->bufpos, s, reply_len) ← 클라이언트 버퍼에 직접 쓰기 ``` ### 상세 분석 **1\. addReplyErrorSdsEx() - networking.c:706** 해당 코드 내에서 `addReplyErrorLength` 함수를 호출하면서 오류 메시지를 버퍼에 추가합니다. ![NHN Cloud_meetup_addReplyErrorSdsEx_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20CloudmeetupaddReplyErrorSdsEx1.png) 이 함수는 `sdsmapchars()` 같은 sanitization 없이 오류 메시지를 그대로 전달합니다. **2\. addReplyErrorLength() - networking.c:565** ![NHN Cloud_meetup_addReplyErrorLength_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20CloudmeetupaddReplyErrorLength1.png) 오류 메시지가 이미 `-`로 시작하면 그대로 전송합니다. `addReplyProto()` 함수를 호출하며 `s` 값을 버퍼에 넣기 위한 함수를 호출합니다. **3\. \_addReplyToBuffer() - networking.c:403** ![NHN Cloud_meetup_addReplyToBuffer_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20CloudmeetupaddReplyToBuffer1.png) 최종적으로 `memcpy()`를 통해 클라이언트의 출력 버퍼(`c->buf`)에 데이터가 직접 기록됩니다. 따라서 공격자가 `error(redis.error_reply("X\r\n+FAKE"))`를 실행하면 버퍼 상태가 다음과 같이 채워집니다. ![NHN Cloud_meetup_client_buffer_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetupclientbuffer1.png) 클라이언트는 `\r\n`을 RESP 메시지 경계로 인식하므로, 이를 두 개의 독립된 응답으로 파싱합니다. 1. `-X\r\n` → 첫 번째 응답(Error) 2. `+FAKE\r\n` → 두 번째 응답(Simple String) - 다음 명령의 응답으로 처리됨 따라서 이후 `PING` 명령을 보내면, 서버의 실제 응답(`+PONG\r\n`) 대신 버퍼에 남아있던 `+FAKE`가 반환됩니다. 이렇게 소켓 포이즈닝이 가능합니다.
## 취약점: DoS RESP 인젝션을 활용하면 클라이언트를 대기 상태로 만들어 서비스 거부 공격을 수행할 수 있습니다. RESP의 Bulk String 타입은 `$길이\r\n데이터\r\n` 형식으로, 클라이언트는 명시된 길이만큼 데이터를 수신할 때까지 대기합니다. 공격자가 거대한 길이를 주입하면 ![NHN Cloud_meetup_dos_1.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetupdos1.png) 클라이언트 버퍼가 다음과 같이 채워집니다. ![NHN Cloud_meetup_client_buffer_2.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetupclientbuffer2.png) 공격 시나리오는 대략 다음과 같습니다. 1. 첫 번째 응답 `-X\r\n`을 정상 처리(Error) 2. 두 번째 응답 `$999999999\r\n`을 파싱 3. 999,999,999 바이트의 데이터를 기다림 4. 데이터가 오지 않으므로 클라이언트는 비정상 동작 여러 커넥션에서 동시에 이 공격을 수행하면, 다음과 같은 메커니즘으로 인해 서버 레벨에서 DoS가 발생할 수 있습니다. * 모든 클라이언트 커넥션이 멈춤(hang) 상태 * 서버의 커넥션 슬롯 소진 * 새로운 클라이언트 접속 불가 → 서비스 전체 마비 ## 마치며 이 글에서는 RESP 인젝션 취약점의 원리와 이를 활용한 소켓 포이즈닝 및 DoS 공격 방법에 대해 알아보았습니다. 오류 메시지 경로에서 CRLF를 충분히 검증하지 않는다는 작은 허점이 데이터 변조와 서비스 마비로 이어질 수 있다는 점에서, 아무리 단순한 문자열 처리 로직이라도 보안 관점에서의 검증이 중요하다는 것을 다시 한번 느꼈습니다. 이 글이 Valkey나 Redis의 내부 동작에 관심이 있는 분들, 그리고 오픈소스 보안 취약점 연구에 도전해 보고 싶은 분들에게 도움이 되길 바랍니다. 긴 글 읽어 주셔서 감사합니다. [![NHN Cloud_meetup banner_footer_202507-01.png](https://image.toast.com/aaaadh/real/2026/techblog/NHN%20Cloudmeetup%20bannerfooter20250701%281%29.png)](https://www.nhncloud.com/kr)

AI 코드 리뷰 자동화, 판정은 왜 흔들릴까 - 원인과 해결법 4가지

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

같은 코드를 리뷰시켜도 판정이 매번 달라지는 이유는 LLM의 비결정성 때문입니다. temperature를 0으로 내려도 흔들림은 남습니다. 코드 위임·폭 좁히기·다수결·하네스로 LLM 판정의 일관성을 높이는 네 가지 방법을, 총 55회 호출 실험 결과와 함께 정리했습니다.

n8n 워크플로 관리 - 워크플로는 남는데 소유권은 왜 사라질까

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

n8n 워크플로가 100개를 넘으면 누가 만들었고 무엇에 물려 있는지부터 흐려집니다. n8n 기본 기능으로 소유권·구조를 어디까지 볼 수 있는지, 그 빈자리를 인포그랩 Nelper는 어떻게 채우는지 정리했습니다.

더 빠르게, 그리고 무너지지 않게 — 전시 아키텍처 개선기 (1/3)

2026-07-13T15:53:34+09:00

글. 박성진(Philip) / 전시개발팀

이 글은 3부작입니다.

(1/3) 더 빠르게, 그리고 무너지지 않게 — 문제 정의와 아키텍처 의사결정, 그리고 내고장성 설계 (현재 글)
(2/3) 가격 계산 모듈 분리 + skills 로 마이그레이션 — 트랜잭션 스크립트에서 숙소 메타 + 가격 계산 모듈로 (by @엉Ung(진영준) / 전시개발팀 )
(3/3) 데이터 통합 — MongoDB 원칙으로 document를 통합하고 동기화를 재설계 (by @조이Joy(우재호) / 전시개발팀 )

안녕하세요, 여기어때 전시 개발팀 백엔드 개발자 필립입니다.

전시 영역에는 숙소 목록(PLP), 상세(PDP), 객실 상세(RDP)처럼 사용자가 가장 많이 마주하는 화면들이 있습니다. 이 화면에 상품을 내려주는 상품 API를 한동안 운영하면서, 저희는 트래픽이 몰릴 때마다 같은 곳에서 발목을 잡혔습니다 — 바로 캐시였습니다.

이번 글에서는 그 캐시를 V2에서 V3로 다시 설계하며 풀어간 이야기를 해보려 합니다. 빠르게 만드는 것도 목표였지만, 그보다 “캐시가 무너져도 서비스는 멈추지 않게” 만드는 데 더 많은 고민을 쏟았는데요. 어떤 문제를 만났고, 여러 갈래의 선택지를 어떻게 저울질했으며, 결국 어떤 구조에 도달했는지를 차례대로 풀어보겠습니다. 비슷한 고민을 하고 계신 분들께 작은 참고가 되면 좋겠습니다.

결과부터

전시 상품을 내려주는 표준 상품 API(Builder-API)를 V2에서 V3로 다시 설계했습니다. 핵심 지표부터 말씀드리면,

처리량(TPS) 3배 향상 — 211 → 666 (채택 구조 기준, 스테이지 vuser 6000)
P95 응답 시간 대폭 단축 — 응답 캐시에 의존하던 4.13초 구간을 캐시 없이도 1초대로
MongoDB CPU 부하 20~30% → 10% 이하 — 컬렉션 통합으로 조회 비용 자체를 줄임

하지만 이번 작업에서 더 공들인 건 숫자가 아니었습니다. 원인이 무엇이든 캐시 계층이 무너져도 서비스는 멈추지 않는 구조, 그걸 만드는 데 가장 많은 고민을 했습니다. 왜 그랬는지부터 이야기하겠습니다.

어쩌다 캐시가 발목을 잡았나

기존 구조에서 우리는 캐시에 깊게 의존하고 있었습니다. 제휴점 × 체크인/체크아웃 날짜 조합마다 최종 응답 전체를 통째로 Redis에 캐싱했습니다. 빠르긴 했지만, 같은 메타 정보가 날짜 조합마다 중복 저장되면서 캐시는 점점 무거워졌습니다.

문제는 트래픽이 몰릴 때 드러났습니다. 대용량 응답(한 요청에 메타·상품을 합쳐 수십 MB에 달하는 경우도 있었습니다)이 높은 TPS로 동시에 나가면, Redis 노드의 아웃바운드 네트워크가 인스턴스 baseline을 넘어섭니다. baseline을 넘는 순간 패킷이 큐잉·드랍되고, 응답 지연이 누적되다 결국 클라이언트의 command timeout으로 터집니다. 한 노드에서 시작된 timeout은 곧 전체 pod로 번졌습니다.

Slow query 로그는 깨끗했습니다. Redis가 명령을 느리게 처리한 게 아니라, 네트워크 대역폭 한계에 걸려 응답을 내보내지 못한 것이기 때문입니다. 원인이 애플리케이션 로직이 아니라 인프라 한계선이었다는 점이 중요합니다.

더 뼈아팠던 건 복구 수단마저 캐시 구조에 묶여 있었다는 점입니다. 장애 중에 pod를 늘려보려 했지만, 새로 뜬 pod 역시 같은 Redis를 바라보니 부하만 더 얹는 꼴이었습니다. 스케일아웃이 해법이 되지 못했습니다.

여기서 두 가지 구조적 한계가 분명해졌습니다.

캐시가 단일 장애점이다. Redis 하나가 흔들리면 전부 멈춘다.
Redis가 병목이라 스케일아웃이 막혀 있다. 애플리케이션 pod를 늘려도, 병목이 Redis에 있으니 처리량이 따라 늘지 않는다.

우리가 마주한 구조적 문제는 사실 세 갈래였습니다.

① RDB를 그대로 옮긴 파편화된 Document 구조 — PLP 한 번 조회에 15개 이상 컬렉션을 건드리고, 다중 조인성 쿼리가 slow query를 유발했습니다. → 컬렉션 통합으로 해결, 2편에서 다룹니다.
② 서비스 코드에 트랜잭션 스크립트 스타일로 엉겨 있던 가격 계산 — 숙소 메타 조회와 가격 계산이 한 덩어리라 모듈화가 어려웠습니다. → 숙소 메타 + 가격 계산 모듈로 분리, 3편에서 다룹니다.
③ 캐시 단일 의존 — 이 글에서 끝까지 파고들 주제입니다.

어떤 메모리 아키텍처로 서빙할 것인가

개선은 두 단계로 접근했습니다.

Phase 1 — 연산과 구조부터 풀다

가장 먼저 손본 건 조회 비용 그 자체였습니다. 기존 구조에는 두 가지 병목이 있었습니다.

첫째, 파편화된 Document를 향한 다중 조인. RDB 테이블을 그대로 MongoDB 컬렉션으로 복사해둔 탓에, PLP 한 번 조회에 15개 이상의 컬렉션을 건드려야 했습니다. 관련 데이터가 여기저기 흩어져 있으니 10여 개 Document를 조인하는 무거운 쿼리가 만들어졌고, 이게 slow query와 불필요한 네트워크 대역폭 낭비로 이어졌습니다. 그래서 Document DB의 특성에 맞게 — 정규화보다 조회 효율을 우선해 — 관련 데이터를 하나의 Document로 통합했습니다. 10여 개를 조인하던 쿼리가 3~4개의 단순 쿼리로 줄었습니다.

둘째, 제휴점별 순차 처리. 여러 제휴점을 한 번에 조회할 때, 전체 응답 시간이 각 제휴점 처리 시간의 합이 되는 구조였습니다. 제휴점이 늘수록 응답이 선형으로 느려졌고, 1.2초를 훌쩍 넘기는 경우가 잦았습니다.

// 기존: 순차 처리로 인한 느림
for (Place place : places) {
    PdpResponse pdp = pdpService.getPdp(place.getId()); // IO 대기
    Price lowestPrice = calculateLowestPrice(pdp);      // CPU 작업
}

이걸 풀기 위해 Virtual Thread를 도입했습니다. Properties·RoomRatePlans·Products를 먼저 배치로 적재한 뒤, 제휴점별 모델 생성을 Virtual Thread로 병렬 처리해 한 요청에서 수십 건의 IO를 동시에 흘렸습니다. 플랫폼 스레드 풀을 쓸 때 겪던 스레드 고갈과 컨텍스트 스위칭 오버헤드 없이, 경량 스레드로 대규모 병렬 처리가 가능해졌습니다. 개별 제휴점 실패가 전체 응답을 무너뜨리지 않도록 에러도 격리했습니다.

이 두 가지를 풀고 나니, MongoDB 직접 조회의 비용 자체가 크게 떨어졌습니다. 나중에 “캐시 없이도 버틴다”는 전제를 가능하게 한 토대가 바로 이 단계입니다.

그래서, 어떤 메모리 아키텍처로 서빙할 것인가

연산·구조를 풀고 나니 진짜 설계 질문이 남았습니다. 이 데이터를 어떤 메모리 아키텍처로 들고 서빙할 것인가.

그전에, 장애 직후의 응급조치(스펙업, Replica 증설·payload 줄이기)는 egress를 줄여주긴 했지만 본질적으로 시간 벌기였습니다. 트래픽이 더 늘면 baseline은 다시 넘습니다. 그래서 튜닝이 아니라 구조를 다시 골랐습니다. 후보는 셋이었습니다.

채택 — CDC로 항상 최신인 메타 캐시 + 실시간 가격

우리가 택한 건 TTL로 만료시키는 캐시가 아니라, 변경이 생길 때만 이벤트로 갱신하는 캐시였습니다. 메타(제휴점 정보 properties, 객실 상품 정보 room_rate_plans)는 자주 바뀌지 않으니, MongoDB에 변경이 생기는 순간 그 변경을 캐시에 반영하면 됩니다. 이를 Kafka 기반 CDC(Change Data Capture)로 구현했습니다.

흐름은 이렇습니다. 숙소 정보, 가격 데이터 변경을 감지하면 전시 워커가 CDC 메시지를 만들고, 변경된 id들을 chunk 단위로 묶어 Kafka로 발행합니다. 전시 가격 어플리케이션의 Consumer는 파티션별로 메시지를 받아 Virtual Thread로 병렬 처리하며, MongoDB에서 최신 데이터를 읽어 Redis에 반영합니다.

이 구조가 우리가 가진 문제를 한꺼번에 풀었습니다.

캐시는 항상 최신이다. TTL 만료를 기다리지 않고 변경 즉시 반영되므로, “캐시가 오래돼 틀린 값”이라는 부류의 문제가 사라집니다.
캐시에는 가볍고 변동 적은 메타만 남으니 중복·payload 비대 문제가 사라지고, Redis egress에 여유가 생깁니다.
가격은 실시간 조회라 캐시·실제 가격 불일치가 원천 차단됩니다(사용자 신뢰도와 직결).
Phase 1에서 Mongo 조회 비용을 낮춰뒀기에, 가격 경로는 평시에도 이미 Redis를 거치지 않습니다. 즉 Redis가 흔들려도 가격 경로는 멀쩡합니다.
운영 충돌을 막기 위해 v2/v3 Redis를 완전히 분리(별도 RedisTemplate)했고, 실패한 id만 Slack으로 알리되 업서트는 멱등이라 메시지는 ACK 처리해 중복 캐싱을 막았습니다.

그 결과 Redis 부하가 내려가 master CPU를 10% 아래로 유지할 수 있게 됐고, MongoDB CPU 부하도 20~30%에서 10% 이하로 떨어졌습니다. 무엇보다 Redis가 더는 병목이 아니게 되면서, 이제 애플리케이션 pod를 늘리면 그대로 스케일아웃이 됩니다.

(필요하면 상품 캐시나 pod별 로컬 캐시로 처리량을 더 끌어올릴 카드도 확인했지만, 로컬 캐시는 각 pod가 CDC를 받아야 해서 이번 phase에선 의식적으로 미뤘습니다.)

캐시가 무너져도 멈추지 않게

여기까지가 “더 빠르게”였습니다. 이제 “무너지지 않게”입니다.

우리가 한 번 겪은 일은 분명했습니다 — 원인이 무엇이든(심지어 우리가 잘못 쓴 탓이든) 캐시 계층은 무너질 수 있다. 그렇다면 막으려 애쓰는 것만으로는 부족하고, redis가 죽어도 버티는 구조가 필요했습니다. 그래서 조회 경로를 3 tier로 설계했습니다.

이 방어선은 가격 경로만이 아니라 메타 조회·가격 조회 모두를 커버합니다. 어느 한 계층이 무너져도 다음 계층이 받아내고, 최후에는 MongoDB 직접 조회로 떨어지더라도 서비스는 살아 있습니다.

Phase 1에서 Mongo 조회 비용을 낮춰둔 게 여기서 빛을 발합니다 — Level 3가 “겨우 죽지만 않는” 수준이 아니라 실제로 버틸 만한 성능이거든요.

조회 코드는 “Redis → Local → Mongo, 안 되면 다음”이라는 의도만 드러나게 했습니다.

방어선의 복잡함은 설정(서킷 브레이커)으로 빼두었기 때문에, 메타든 가격이든 같은 패턴으로 감싸 일관되게 보호할 수 있습니다.

// 조회는 항상 위에서부터 시도하고, 서킷이 열려 있으면 다음 단계로 떨어진다. 
// 메타 조회·가격 조회 모두 같은 패턴으로 감싼다. 
public PropertyData getProperty(String partnerId) {
    // Level 1 — Redis (Primary): 평시 경로
    return Try.ofSupplier(
            redisCircuitBreaker.decorateSupplier(
                () -> redisCache.getProperty(partnerId)))
        // Level 2 — Local Cache (Secondary): Redis 서킷 OPEN 시
        .recover(throwable ->
            localCircuitBreaker.decorateSupplier(
                () -> localCache.getProperty(partnerId)).get())
        // Level 3 — MongoDB Direct (Fallback): 최후의 보루
        .recover(throwable ->
            mongoRepository.findProperty(partnerId))
        .get();
}

전환은 서킷 브레이커(resilience4j)로 자동화하되, 티어마다 성격이 다르므로 민감도를 다르게 뒀습니다.

# Redis 티어: 빨리 끊고, 오래 쉬게 한다
redis-tier:
  failure-rate-threshold: 50
  slow-call-duration-threshold: 5s
  wait-duration-in-open-state: 10m
  record-exceptions:
    - RedisConnectionFailureException
    - QueryTimeoutException
# Local 티어: 더 관대하게 — 마지막 보루에 가까우므로
local-tier:
  wait-duration-in-open-state: 5m
  record-exceptions:
    - OutOfMemoryError
    - IllegalStateException

설계 의도는 이렇습니다. Redis는 한번 흔들리면 빠르게 차단하고 충분히 쉬게 합니다(다시 붙였다가 또 무너지는 걸 막기 위해, OPEN을 길게). 반대로 Local 캐시는 마지막에 가까운 방어선이라 쉽게 끊지 않습니다. 그리고 각 티어가 “무엇을 장애로 볼지”도 분리했습니다 — Redis는 연결 실패·타임아웃을, Local은 메모리 고갈류를 기준으로.

그리고 실전에서 검증됐습니다

설계를 마친 뒤, 서킷을 강제로 열어 로컬로 매끄럽게 넘어가는지 사전 확인했습니다.

그런데 얼마 지나지 않아 예기치 않게 Redis 연결이 끊기는 상황이 실제로 발생했습니다.

결과는 설계한 그대로였습니다. 서킷 브레이커가 열리며 트래픽이 곧바로 로컬 캐시로 흘렀고, 사용자는 아무것도 느끼지 못했습니다. 과거 같은 상황이라면 전 pod가 timeout으로 무너졌을 텐데, 이번엔 모니터링 그래프 위의 작은 점 하나로 끝났습니다.

정리하며

성능 향상이 1차 목표였던 건 맞습니다. 하지만 정말 공들인 건 “이 캐시가 또 무너지면 어쩌지”라는 불안을 구조로 없애는 일이었습니다. 여러 메모리 아키텍처를 저울질하고, 빠른 길 대신 버티는 길을 고르고, 티어마다 차단 정책을 다르게 다듬은 이유가 거기에 있습니다.

다음 편에서는 이 모든 걸 가능하게 한 토대 — 파편화된 MongoDB Document를 어떻게 도메인 단위로 다시 설계했는지(조이), 그리고 가격 계산을 어떻게 독립 모듈로 떼어냈고 skill을 활용해 페이지 타입별 마이그레이션을 어떻게 처리했는지 더 깊이 다룹니다.

그리고 한 가지 더. 이 글에는 기록의 의미도 있습니다. 지금 전시팀이 수행 하는 가격제공이 변경 예정 입니다.

즉 이 시리즈에서 이야기하는 코드의 일부는 머지않아 우리 손을 떠납니다. 그 전에, 우리가 어떤 문제를 만났고 어떤 고민 끝에 지금의 구조에 도달했는지를 남겨두고 싶었습니다. 떠나보내는 코드에 대한 작은 회고이기도 합니다.

긴 글 읽어주셔서 감사합니다.

더 빠르게, 그리고 무너지지 않게 — 전시 아키텍처 개선기 (1/3) was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI 수석회의

2026-07-13T13:27:49+09:00

글. 박지형(Paori) / 주문결제개발팀

안녕하세요, 주문결제개발팀 파오리 입니다.

제가 2026년 상반기 우리 팀의 FT (퍼실리테이터; 참고) 로서 참여했던
<AI 수석회의> 활동에 대해 글 써보려고 합니다.

바야흐로 AI 전성시대!

빠르게 변화하고 진화하며 AI 기술이 쏟아지고 있지만
그만큼 개인의 관심과 의욕에 따라 개인별 편차도 커지고 있습니다.
한 조직 내에서 이 편차가 커지면 모두가 같은 높이의 시선으로 AI 를 받아들이고 활용하기에는 아무래도 어려운 면이 있죠.

하지만 같은 서비스를 운영하고 개발해나가야 하는 조직이니
시선의 높이를 맞추고 새로운 정보를 공유해나가는 과정은 반드시 필요합니다.

그래서 제가 속한 코어플랫폼실의 개발팀에서는
각 팀마다 유난히 AI 에 관심이 많고, 팀의 AI 관련 작업을 주도하는 분들을 ‘AI 수석’ 으로 명명하고 모임을 가졌습니다.

<AI 수석회의>
회의 날짜 : 2026.05.14 부터 매주 목요일 오후 4시
참석 인원 : 각 팀의 FT, AI 수석, 이 회의에 관심 있는 팀원 누구나

팀별로 돌아가면서 AI 수석이 발표를 준비했으며,
발표의 내용은 팀 내에서 사용하고 있는 AI 기술 및 공유하고 싶은 내용들로 자유롭게 구성하였습니다.
발표가 끝나면 서로 고민했던 지점들에 대한 의견도 나누고
AI 를 사용하며 알게 된 소소한 꿀팁들을 가볍게 나누는 시간도 가졌답니다.

이렇게 진행한 회의는 Gemini 가 작성한 회의록으로 남았습니다.

궁금하신 분은 주문결제개발팀 컨플루언스를 방문해 보세요!

모든 내용을 자세히 공유 드리기는 어려운 관계로, 각 회의들의 발표 주제들을 간략히 소개드리려고 합니다.

2026.05.14 회의

발표자 : 주문결제개발팀 애쉬
주제 : AI 패러다임이 전환됨에 따라 주문결제개발팀에서 추진 중인 ‘Agent-Common’ 프레임워크의 도입 목적 및 방향성 공유

현재 개발자마다 사용하는 프롬프트와 규칙이 파편화되어 있어,
여러 도메인(국내숙소, 해외숙소 등 카테고리)을 관리하고 있는 주문결제개발팀에서는 일관성을 유지하기 어렵다는 문제가 있습니다. 이를 개선하고자 애쉬는 공통의 규칙을 정의하고, 깃 액션 파이프라인을 통한 소스 코드 규칙 관리, 런타임 최신화 과정, 그리고 사후 검증 피드백 시스템을 구축해서 개발 품질을 상향 평준화하는 “중앙통제관리소” 와 같은 방향성을 제시했습니다.

팀 전체 룰이 있고 각 도메인별 룰을 필요할 때 lazy loading 해오는 방식으로 비용절감을 하도록 한 점이 인상 깊었습니다. 한편으로는 새 프로젝트들도 많이 생겨나고 있는 상황에서 개발자들의 자율성과 강제 규칙 적용 사이의 경계선에 대한 고민도 이야기를 나누었습니다.

2026.05.21 회의

발표자 : 정산개발팀 페퍼
주제 : LLM 컨텍스트 관리 경험기 공유

정산개발팀에서는 claude team plan 사용 당시 토큰 절감에 대해 고민을 많이 하셨다고 합니다. 그 결과 LLM Wiki 를 도입하여 초기 토큰 소모 과다와 품질저하 문제를 해결했습니다.

처음에는 기획서나 코드를 통째로 넘겨 분석시켰지만 불필요한 내용까지 포함되어 토큰 소모가 컸고, 생성되는 개발 계획서의 분량이 지나치게 많아 리뷰 피로도가 높았습니다. 또한 claude code 가 자잘한 의사결정을 임의로 수행하는 등 품질 저하와 반복적인 수정 요청이 발생하는 문제가 있어, 효율적인 대화형 개발환경을 모색하게 되었습니다.

이 문제는 claude 를 처음 도입하고 사용하는 초기에 많이들 고민하셨을 것 같은데요, 저도 초기에는 사내에서만 공유되는 기획이나 통용되는 용어들에 대해 반복해서 학습시키고 이야기 하는 것에 토큰을 소모하는 게 여러모로 낭비라는 생각을 했습니다.

정산개발팀의 LLM Wiki 는 데이터베이스 (SQL, DDL), 도메인 지식, 소스 코드로 구성된 Raw 폴더와 이를 구조화한 Wiki 폴더를 가집니다. 특히 각 Wiki 하위의 index.md 파일은 클로드가 필요한 파일을 식별하고 로드하는 핵심 경로 역할을 하며, 옵시디언 툴을 활용하여 데이터 관리의 효율성을 높였습니다.

2026.05.28 회의

발표자 : 유저혜택개발팀 윌비
주제 : AI 작업 표준화 전략과 협업 도구 활용을 통한 효율적인 개발 운영 체계 구축 논의

윌비는 AI 워크스페이스를 만들어 AI 관련 작업을 단일 저장소에서 통합 관리하며 공통 가이드와 컨텍스트 주입을 통한 운영 일관성 확보, 모든 협업 이력을 파일로 기록하고 피드백 루프를 운영하며 작업 효율성을 높이는 것에 대해 이야기했습니다.

개발 작업, 검증/품질 체크, git /commit, 문서화, 운영작업, 모니터링/장애 대응 과 같이 카테고리별로 팀에서 반복적으로 작업하는 것들에 대해 스킬을 만들어서 공통으로 사용하도록 했는데요, 공유해주신 AI 워크스페이스의 README 만 보아도 유용하게 쓰일 수 있는 스킬들이 많았습니다.

이러한 AI 와의 협업과정에서 모든 입력값, 프롬프트, AI 의 답변, 그리고 AI가 스스로 판단한 결정 사항들을 파일에 기록하여 맥락을 공유하고 있었습니다. 작업 커밋 시에는 사용스킬과 피드백을 링크하여 사람이 검토하도록 하였는데요, AI 가 작업을 하되, 주도권은 사람에게 남겨두도록 고민한 포인트가 인상적이었습니다.

2026.06.04 회의

발표자 : 광고플랫폼개발팀 지하
주제 : 광고플랫폼개발팀의 하네스 구조를 통한 개발 일관성 확보와 함께 가드레일 구현 및 시스템 운영 효율화 방안 논의

광고플랫폼개발팀에서는 대규모 언어 모델을 활용할 때 발생하는 비결정적인 결과물 문제를 해결하기 위해 하네스(Harness) 구조의 ‘AD’ 라는 프로젝트를 개발하였습니다. 어떤 팀원이 어떤 기능을 개발하더라도 일관된 결과물을 도출할 수 있도록 컨텍스트를 주입하고, 파괴적 명령어 차단 등 가드레일 설정을 하고 있습니다.

위에서 보았던 애쉬, 윌비의 발표 내용과도 일맥상통하는 주제라고 생각하는데요, 우리 실의 많은 팀들이 AI 를 도입해 볼 만한 포인트로 규칙과 가드레일의 공통화를 보고 있네요.

초기에는 세션 대화를 정규식으로 긁어서 신호를 만들던 hook 이 있었지만,
노이즈가 89%에 달했다고 합니다. 그래서 컨벤션 위반, 리뷰 결과, 차단 로그, 결정 기록 과 같은 신호를 정하고 고정된 출처에서만 받도록 했다고 합니다.

2026.06.11 회의

발표자 : 주문결제개발팀 월터
주제 : 급변하는 AI 도구 환경 속에서 개발자의 핵심 역량 변화와 전략적 도구 활용 방안 논의

이 전까지의 회의에서는 AI 를 활용하여 우리에게 맞는 도구를 만들어 내는 것에 대한 이야기 들을 많이 했는데요, 이런 이야기 들을 반복하다 보니 월터는 조금 더 큰 영역에서의 고민을 제안했습니다.

개발자들이 각자 스킬, 기능, 도구를 만들지만 빠르게 발전하고 있는 AI 생태계에서 항상 더 좋은 기능들을 포함한 도구들이 빠르게 업데이트 되고 있습니다.

그 과정에서 우리(개발자들)가 키워야 하는 능력은 무엇인가 에 대한 이야기를 나눠 주셨는데요, 결론은 결국 나에게 필요한 좋은 도구를 골라낼 수 있는 좋은 눈과 AI 가 일을 더 잘하게 명령할 수 있는 힘인 것 같네요.
앞선 회의와는 다른 주제였지만 모두가 공감하며 한참 대화를 나눈 것이 좋았습니다.

2026.06.18 회의

발표자 : 주문결제개발팀 애쉬
주제 : MCP 기반의 자동화된 이슈 근본 원인 분석 도입기 공유 및 아키텍처 구축 방안 논의

애쉬는 주문결제개발팀 해외숙소 모니터링 과정에서 장애 발생 시 즉각적으로 오류 지점과 로그를 파악하여 분석시간을 단축시키는 RCA Agent 를 도입했습니다.

기존의 장애 대응은 사람의 손을 많이 타는데요,
LGTM 스택(Loki · Grafana · Tempo · Mimir)과 슬랙 알림 채널로 장애가 수집되면, 담당자가 Grafana 를 열어 LogQL · TraceQL · PromQL 을 직접 작성하고, 스택 트레이스를 읽고, 코드베이스를 grep 하고, 최근 커밋을 확인하면서 원인을 추정합니다.

하지만 운영을 하다 보면 대부분 비슷한 원인으로 에러 메시지가 발생하고
위의 과정을 5–15분 걸려 파악하고 나면 이미 어느 정도 예측했던 원인과 맞아 떨어지죠. 그래서 이 5–15분을 자동화한 agent 를 만들었습니다.

정상적인 예외와 시스템 에러에 따라 분석 과정을 달리하여 제법 정확도 높게 슬랙으로 회신해주는 것이 흥미로웠어요.

2026.06.25 회의

발표자 : 정산개발팀 이스트
주제 : 클로드 코드 환경에서 사용되는 인기 있는 오픈소스 플러그인 조사 및 적용기 공유

상반기를 마무리하는 마지막 회의로, 요즘 뜨고 있는 Claude Code 오픈소스 플러그인 9종에 대해 소개하고 적용기를 공유하는 시간을 가졌습니다.

크게 A. 하네스 / B. 메모리 / C. 컨텍스트 이 세 가지의 분류로 플러그인을 소개해주셨는데요,

[A. 하네스] 에서는 superpowers , ECC (Everything Claude Code), gstack, oh-my-claudecode (OMC)

[B. 메모리] 에서는 claude-mem, agentmemory, mem0

[C. 컨텍스트] 에서는 graphify, Understanding-Anything
을 소개해주셨습니다.

겉으로는 다 장점이 명확하고 유용하게 쓰일 수 있을 것 같았는데요,
실제 여러 사용자들의 후기 종합 결과, 호평보다는 혹평이 더 많았습니다.
그리고 새로운 모델들이 빠르게 해당 pain point 를 개선해서 배포되고 있기도 합니다.

실제로 이스트의 사용기 후기도 “아직 ‘이거다' 싶은 쓸 만한 오픈소스 프로젝트는 없다.” 라는 후기를 남겨주셨습니다.
결국은 위에서 월터가 나눠주신 이야기 처럼 “지식베이스 구축" 이 가장 중요한 것이라는 결론에 도달하였네요.

회의를 시작하기 이전에는 다른 팀에서 어느 정도의 범위로 어떻게 AI 를
활용하고 있는지 알지 못했는데, 이 회의에 참석하면서 다른 팀에서
어떻게 AI 를 사용하는지 알게 되어 매우 유익한 시간이었습니다.

또한, 제가 사용해 보지 않은 도구들의 사용기와 구축기를 들으면서
‘이런 것도 있구나’ , ‘이 부분은 나도 활용해 보면 좋을 것 같다' 라는 생각도
들었습니다.

팀별 담당 도메인이 다르다 보니 각 팀마다 운영 프로세스도 다르고
프로젝트 구조도 다른데, 각자 적합한 도구와 컨텍스트 를 적용시킨 경험기를 들으며 다른 팀의 업무와 역할에 대해서도 이해도를 높일 수 있었고,

한편으로는 수없이 많이 쏟아지는 AI 도구들과 일주일, 한 달 사이에도 빠르게 발전하고 변화하는 AI 에 대해 두려움 혹은 앞으로 개발자로서 나아가야 할 방향에 대해서도 가볍게 공유하고 토론하는 시간도 있어서 한 번씩 마음다짐도 할 수 있었네요. (ㅎㅎ)

거창한 발표가 아니더라도 다른 팀과 소소한 꿀팁을 공유하는 모임,
한 번씩 해보면 어떨까요?

AI 수석회의를 함께 한 분들
유저혜택개발팀 제이알, 광고플랫폼개발팀 제시카, 주문결제개발팀 월터,
정산개발팀 이스트, 광고플랫폼개발팀 지하, 유저혜택개발팀 윌비,
정산기획팀 와이제이, 정산개발팀 페퍼, 주문결제개발팀 애쉬

AI 수석회의 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI가 해킹하는 시대, 보안 직군에서 진짜 필요한 역량은 무엇일까

2026-07-10T11:19:10+09:00

AI가 취약점 스캔부터 보고서 초안까지 작성하는 지금, 보안 커리어를 지킬 수 있는 핵심 역량은 기술 실력이 아니라 커뮤니케이션 역량일 수 있어요.

[사내 지식 AI 만들기 ⑤·수집] 좋은 답변의 90%는 검색 전에 결정된다 — Notion 회사와는 차원이 다른 20년치 수집

2026-07-12T09:59:58+09:00

GIGO, 그런데 우리 건 차원이 다르다

RAG에는 오래된 격언이 있다. "쓰레기를 넣으면 쓰레기가 나온다(Garbage In, Garbage Out)."

그런데 사내 지식은 — 쓰레기인지 아닌지조차 애매했다. 작년에 폐기된 규정인데 멀쩡해 보이는 문서, 부서마다 다르게 부르는 용어, 같은 내용이 세 군데에 흩어진 중복, 그리고 절대 새어 나가면 안 되는 개인정보.

1탄~4탄에서 검색·권한·대화·채널을 아무리 잘 만들어도, 들어온 지식이 엉망이면 답도 엉망이다. 좋은 검색의 대부분은 검색 알고리즘이 아니라 _수집 단계_에서 결정된다. 그리고 개인정보 한 건이 새어나가면 그건 "틀린 답변"이 아니라 보안 사고다. 사내 지식은 "얼마나 정확한가"와 "얼마나 위험한가"를 동시에 조심해야 하는, 일반 GIGO보다 한 단계 무거운 문제였다.

Notion 하나 쓰는 회사 vs 20년 Excel·PPT 쓴 회사

다른 회사 이야기를 들으면 부러울 때가 있다. 처음부터 지식을 Notion 하나 같은 단일 도구에 모아 쓰는 회사는, 도서관을 신축 설계도 한 장으로 짓는 것과 같다. 소스가 하나고, 게다가 Notion은 태생이 마크다운 — 텍스트 구조가 이미 깔끔해서 파싱이 거의 공짜다. 서가 규칙이 처음부터 하나다.

우리는 달랐다. 20년 넘게 Excel·PowerPoint·사내 게시판·메일로 지식을 쌓아온 회사였다. 여기서 진짜 난이도는 "소스가 많다"가 아니라 "20년치 이질적 포맷" 자체다.

Excel: 표, 병합 셀, 여러 시트, 수식 결과값, 셀 안에 줄바꿈으로 욱여넣은 문단.
PowerPoint: 텍스트가 도형·표·이미지 안에 흩어져 있고, 발표 흐름은 사람 머릿속에만 있다.
게다가 표를 이미지로 캡처해 붙인 문서도 흔하다 — 그 안의 글자는 텍스트가 아니라 그림이다.

Notion 회사가 "책을 그대로 서가에 꽂는" 일이라면, 우리는 책을 펼쳐 표·도형·이미지에서 글자를 발라내는 일부터 해야 했다. 통째로 다시 지을 순 없었다 — 이미 그 안에 20년치 지식이 살고 있었으니까. 그래서 만든 건 "하나의 표준 서가"가 아니라, 소스마다 맞춘 전용 손수레(connector) 였다. Confluence, Jira, SharePoint, 게시판, Teams… 소스마다 다른 문·다른 포맷에 맞춰 각각의 connector를 만들고, 그 손수레들이 정해진 시간에 각 소스를 도는 순회 일정(scheduler) 을 짰다.

검수대(Ingestion Gate)

포맷을 발라 텍스트를 얻었다고 끝이 아니다. 도서관에 책을 들이기 전, 검수대를 뒀다. 모든 문서는 색인되기 전에 이 게이트를 통과한다.

[소스] → 파싱 → 한국어 전처리 → 청킹 → (검수대: ingestion gate)
                                          ├─ 품질: 너무 짧거나 깨진 문서?
                                          ├─ 보안: PII/기밀? → 격리(quarantine)
                                          └─ 메타: 권한 태깅(tenant/kb/tier/acl)
        → 중복 제거 → 임베딩 → 저장(Qdrant)

100G를 통째로 나를 수는 없다 — 분할과 델타

소스 하나가 워낙 커서(대용량), 손수레로 한 번에 다 나르려면 트럭 몇 대로도 부족했다. 두 가지를 했다.

분할(partition): 큰 자료 뭉치를 통째로 나르지 않고, 감당할 수 있는 단위로 쪼개서 나른다.
델타(delta): 매번 소스 전체를 다시 뒤지지 않는다. fingerprint로 지난번과 달라진 부분만 골라 옮긴다 — 안 그러면 순회할 때마다 도서관 하나를 통째로 다시 옮기는 셈이 된다.

여러 소스를 돌다 보면 같은 문서가 이름만 바꾼 채 여러 곳에 꽂혀 있는 것도 발견한다 — 그대로 다 꽂으면 사용자는 같은 답을 세 번 받거나, 서로 다른 버전의 답을 받는다. 그래서 서가에 꽂기 전, 마지막으로 한 번 더 골라내는 절차(중복 제거)를 거친다.

수집 스택:

소스 connector : Confluence / Jira / SharePoint / 사내 게시판 / Teams — 소스별 어댑터
포맷 파싱      : Excel / PPT / PDF / 문서 — 표·도형·이미지에서 텍스트 추출
증분 크롤      : fingerprint 기반 변경분만 재수집
워크플로       : Temporal(스케줄·재시도·크롤 상태 추적)
PII 스크럽     : 정규 포맷 + 우회 케이스(하이픈 없는 번호 등) 규칙 엔진
중복 제거      : 해시 → 근사중복 → 의미중복 다단계 파이프라인
임베딩/저장    : 청킹 → 임베딩(OpenAI) → Qdrant(1탄의 통합 컬렉션, 권한 태그 포함)

심화 — 검수대는 무엇을 막고, 우리는 어디서 데였나

이 절은 깊다. 검수대가 실제로 어떻게 판정하고, 대용량 수집이 어디서 터졌는지 궁금한 분을 위한 detail이다. 바쁘면 체크리스트로 건너뛰어도 좋다.

① 검수대 판정 — 무엇을 막고, 무엇을 통과시키나

게이트는 결과를 네 갈래로 나눈다.

if verdict in {보안 위반: PII·기밀}:     action = QUARANTINE   # 색인 안 함, 격리
elif core_fail >= 2:                     action = REJECT       # 핵심 품질 다중 실패
elif core_fail == 1:                     action = HOLD         # 재작업 여지
elif core_warn:                          action = PROCEED      # 로그만, 색인은 진행 (아래 ②)

핵심은 보안 위반(PII·기밀)만 색인을 막는 하드 블록(격리) 이고, 나머지 품질 문제는 정도에 따라 REJECT/HOLD로 나뉜다는 것. "정확도"와 "위험도"를 같은 잣대로 다루지 않는다.

② 영리한 선택 — 경미한 경고(WARN)는 색인을 막지 않기로

처음엔 품질 경고(WARN)도 색인을 막았다. 그랬더니 문제가 생겼다 — 사소한 경고 하나 때문에 멀쩡한 문서가 0청크로 저장돼 검색에 안 잡히는 일이 벌어졌다. 그래서 정책을 뒤집었다: Core WARN은 PROCEED(로그만 남기고 색인은 진행). 막아서 얻는 안전보다, 막아서 잃는 "있는데 안 나오는 지식"이 더 컸기 때문이다. 게이트의 목적은 "완벽한 것만 통과"가 아니라 "위험한 것만 차단"이었다.

③ 숫자, 정직하게

여기도 자랑할 실측 %는 없다. 아래 ④의 사고를 고친 뒤 "0청크 → 정상 청크 + 한글 근거 복원"을 확인한 정성적 결과가 전부다. 없는 숫자는 안 만든다.

④ 우리가 처음엔 틀렸다 — chunks=0의 진범은 파일명 길이였다

대용량 재적재 중, 어떤 소스의 문서들이 인제스트했는데 청크가 0개로 나왔다. 원인을 다섯 번 오진했다: PostgreSQL 갭 → S3 키 불일치 → 버킷 IAM 권한 → boto3 버전 → 인코딩(ASCII rekey). 다 아니었다.

진범은 어이없게도 파일명 길이였다. 리눅스 파일시스템의 파일명 한계는 255바이트인데, 그 소스의 한글 파일명은 인코딩하면 283바이트로 그 한계를 넘었다. 그래서 다운로드가 로컬에 저장되는 순간 ENAMETOOLONG으로 실패했는데 — 이걸 넓은 except: continue가 삼키면서 겉으로는 "S3 object not found" 로 위장됐다. 있는 파일을, 없다고 보고하고 있었던 것이다.

고친 방식: 다운로드 로컬 파일명을 원본 키 대신 짧은 해시(sha256 앞 16자) 로 쓰고, 사용자에게 보일 제목(한글 citation)은 원본 키에서 따로 유도했다. 그리고 그 broad except의 마스킹을 걷어내 진짜 에러가 드러나게 했다.

# S3 키 basename이 로컬 255바이트 한계를 넘으면 ENAMETOOLONG →
# 이전엔 "S3 object not found"로 위장됐다. 짧은 해시명으로 우회.
safe_name = hashlib.sha256(key.encode("utf-8")).hexdigest()[:16] + Path(key).suffix

교훈 두 개. 하나의 증상(chunks=0)이 다섯 개의 서로 다른 원인을 가릴 수 있다. 그리고 넓은 except는 사고를 고치는 게 아니라 숨긴다 — 3탄에서 본 "같은 증상, 다른 원인"이 수집 파이프라인에서 다시 나타난 셈이다.

들이기 전에 고민한 것들 (체크리스트)

PII redaction — 주민번호·카드·전화·이메일을 들어오기 전에 스크럽한다. 표준 포맷뿐 아니라 우회 케이스(하이픈 없는 번호, 공백 구분, 국제 포맷)까지. 한 번 새면 영속 저장소에 남는다.
중복(dedup) — 같은 문서가 여러 소스에 → 다단계 파이프라인으로 거른다(해시 → 근사 중복 → 의미 중복 → 충돌 탐지).
신선도(freshness) — 오래된 규정이 최신처럼 답하면 그게 사고다. 소스별 신선도 SLA를 두고, 늦으면 경보·재수집.
권한 메타 — 수집 시점에 출입증(2탄의 tenant/kb/tier)을 박아야 한다. 검색 시점에 뒤늦게 권한을 붙일 수 없다.

한 줄로

좋은 답변은 좋은 검색에서, 좋은 검색은 좋은 저장에서, 좋은 저장은 — 좋은 수집에서 시작한다.

시리즈를 마치며

저장(1) → 권한(2) → 대화(3) → 채널(4) → 그리고 그 모든 것의 출발점, 수집(번외). 한 바퀴를 돌았다.

우리가 내내 붙잡은 원칙 하나로 닫는다: 구조를 만드는 것은 시작이지 끝이 아니다. "저장이 잘 됐나?"가 아니라 "각 사용자의 질문에 근거 있게 답했나?" 를 — 실제 사용자가, 측정된 품질로, 운영 경로에서 증거와 함께 — 확인할 때, 비로소 완료다.

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 · 번외 수집 (이 글)

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

사내 지식 AI 만들기 ④·채널] 모바일 앱을 또 만들 뻔했다 — 채널은 글로벌 업체를 못 이긴다, 그래서 Thin 플랫폼

2026-07-12T09:58:51+09:00

우리가 만든 앱, 그리고 폐기한 앱

솔직히 고백하면 — 우리는 모바일 앱을 만들었다. 포털도 만들었다. 그리고 폐기했다.

이유는 단순하고 아팠다.

사용자는 우리 앱에 안 들어왔다. 이미 Teams에 살고 있었다.

좋은 지식 AI를 만드는 것과, 사용자가 그걸 쓰게 만드는 것은 완전히 다른 일이었다. 멋진 새 집(앱)을 지었는데, 사용자는 이사 올 생각이 없었다. 하루 종일 일하는 곳은 워크스페이스(Teams, Google Chat)였으니까.

채널은 글로벌 업체를 못 이긴다 — 그래서 Thin 플랫폼

방향을 틀면서 우리가 인정한 게 하나 있다. 채널 그 자체(메신저 UX, 알림, 첨부, 카드 렌더링…)는 글로벌 업체가 수십 년 투자한 영역이고, 우리가 그 수준으로 만들 수 없다. Teams를, Google Chat을 우리가 다시 만들 수는 없다.

그리고 하나에 락인(lock-in) 되는 것도 위험했다. 한 플랫폼에 올인하면 그 플랫폼 정책 하나에 서비스가 흔들린다.

그래서 택한 게 Thin 플랫폼이다 — 채널을 _소유_하지 않는다. 대신 각 채널에 얇게 연결만 하고, 무거운 지능(검색·권한·근거·rerank)은 우리 쪽 공통 substrate에 둔다. 채널은 갈아 끼울 수 있는 얇은 어댑터가 되고, 우리는 벤더와 경쟁하는 대신 그 위에 올라탄다.

        [디지털 동료]  (1~3탄: 저장 · 권한 · 대화)
             │  공통 substrate (검색/권한/rerank/근거)   ← 무겁게, 우리가 소유
   ┌─────────┼──────────┬───────────┐
 Teams봇   Google Chat   Outlook    A2A(에이전트 연동)    ← 얇게, 갈아끼움

디지털 동료 하나 → 채널 N개

Thin 플랫폼의 보상은 여기서 나온다. 신원 확인과 UX 포장을 채널별로 한 번씩만 풀어두면, 그 다음부터는 —

디지털 동료 하나를 추가하면 이미 연결된 모든 채널에 동시에 나타난다.
채널 하나를 연결하면 이미 있는 모든 동료가 그 채널에서 한 번에 쓸 수 있게 된다.

동료 M명 × 채널 N개를 M×N번 따로 만드는 게 아니라, M + N번만 만들면 되는 구조다. 이게 "직접 UI를 안 만든다"가 단순 비용 절감을 넘어 _구조적 레버리지_가 되는 지점이다.

같은 답, 다른 얼굴

인증만 채널마다 다른 게 아니었다. 같은 질문에 같은 근거로 답해도, 그걸 _보여주는 방식_은 채널마다 달라야 했다. Teams에선 풍부한 카드(Adaptive Card)로, Google Chat에선 그 채널의 카드 포맷으로, 사람이 보지 않는 에이전트 연동 채널에선 애초에 "보여줄" 필요 없이 구조화된 데이터로 — 같은 답을 그 채널이 이해하는 언어로 다시 포장한다.

여기서 데인 교훈 하나: pod에서 함수로 찍어 본 게 사용자 화면이 아니다. 이건 그냥 넘어갈 얘기가 아니라 심화에서 따로 다룬다.

직접 UI를 안 만든다는 원칙

모바일·포털은 폐기. 워크스페이스 플랫폼 + 채널 + 디지털 동료 연결로 통합.
새 기능 = 새 화면을 또 만드는 게 아니라, 기존 채널에 동료의 능력을 더하는 것.
운영 작업(관리자)은 별도 UI 대신 CLI·슬래시 명령으로.

우리는 _프론트엔드를 다시 만드는 일_을 줄이고, _동료의 능력_에 집중할 수 있게 됐다.

심화 — 채널마다 다른 인증, 그리고 렌더링은 화면에서 검증한다

이 절은 깊다. 채널을 얇게 연결한다는 게 코드에서 뭘 뜻하는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 같은 "누구인지" 확인인데, grant 타입이 다르다

채널을 하나 늘릴 때마다 가장 먼저 부딪힌 건 신원 확인 방식이 제각각이라는 점이었다. 두 개만 나란히 놓아 보자.

Google Chat — 서비스 신원(OIDC) 검증. Google이 발급한 OIDC id_token을 우리 쪽 verifier가 검증한다(정해진 발신자 allowlist인 service_account 모드, 또는 도메인 정책상 허용된 사용자 이메일 토큰). 핵심은 "이 요청이 신뢰된 발신자(서비스)에서 왔는가" 를 토큰으로 확인하는, machine-to-machine에 가까운 모델이다.
에이전트 연동(A2A) — 위임 토큰 교환(OBO). 여기선 사람이 채널에 로그인하는 게 아니라, 에이전트가 사용자를 대신해(on-behalf-of) 통신한다. 사용자 동의로 얻은 토큰을 downstream 토큰으로 교환(On-Behalf-Of) 해서, 그 위임 신원으로 다음 시스템에 접근한다. authorization-code에서 파생된 위임(delegated) 모델이다.

같은 "이 사용자가 누구인지 확인한다"인데, 한쪽은 _서비스 신원을 검증_하고 다른 쪽은 _사용자 위임을 교환_한다 — grant 타입 자체가 다르다. 그래서 채널 하나 = 인증 어댑터 하나였다. (이 위임 교환은 실제로 한 번 크게 데였다 — invalid_grant가 무더기로 나 별도 원인분석을 했다.) 각 채널의 인증을 2탄의 출입증(payload 권한)에 다시 맞물리는 게 Thin 플랫폼의 진짜 일이었다.

② 영리한 선택 — 채널을 소유하지 않는다

기각한 대안은 명확했다: 자체 채널·앱을 만들어 그 안에서 모든 걸 통제하기(모바일·포털이 그거였고, 폐기했다). Thin 플랫폼은 그 반대다 — 채널 UX는 벤더에게 맡기고, 우리는 그 위에 얇은 어댑터로만 붙는다. 잃는 것: 채널 화면을 100% 우리 맘대로 못 함. 얻는 것: 벤더와 경쟁 안 함 + 락인 회피 + M+N 레버리지.

③ 숫자, 정직하게

여기엔 자랑할 하드 넘버가 없다. M+N의 이득은 "채널·동료를 늘려도 연결 작업이 곱이 아니라 합으로 는다"는 구조적 사실이지 측정된 %가 아니다. 없는 숫자는 안 만든다.

④ 우리가 처음엔 틀렸다 — pod에서 찍은 건 사용자 화면이 아니다

가장 아팠던 채널 사고는 렌더링이었다. Teams 카드가 단일 줄바꿈을 공백으로 뭉개 잘 정리한 답이 한 덩어리 벽처럼 나온 적이 있다. 또 한 번은 카드를 감싸던 내부 호환 마커(__ADAPTIVE_CARD__)가 안 벗겨져 raw JSON이 그대로 사용자에게 노출된 적도 있다. 둘 다 pod 안에서 함수를 호출해 찍어 보면 멀쩡했다 — "함수 출력이 맞다"와 "그 채널에서 실제로 그렇게 보인다"는 다른 일이었으니까.

그래서 렌더링을 화면 기준으로 강제하는 4겹을 깔았다: commit 훅(원시 마커 누출 차단) · CI(카드 골든 렌더 테스트) · 런타임(발신 직전 outbound guard) · Datadog 모니터(마커 누출·렌더 실패율). 채널을 얇게 연결한다는 건, 역설적으로 각 채널의 화면을 더 깐깐하게 검증한다는 뜻이었다. (사실 문서를 한 도구에서 다른 도구로 옮길 때마다 겪는 일이다 — 원본에선 멀쩡한데 옮긴 화면에선 깨지는. 규모만 다를 뿐 같은 교훈이다.)

맺음 — 그런데 좋은 지식이 없으면 다 소용없다

저장(1) → 권한(2) → 대화(3) → 채널(4). 이제 사용자는 자기 자리에서, 권한 안에서, 근거 있는 답을 받는다.

그런데 이 모든 건 _좋은 지식이 들어와 있을 때_만 의미가 있다. 쓰레기가 들어가면 쓰레기가 나온다. 그 지식을 _어떻게 모으고, 들이기 전에 무엇을 검수했는지_는 — 번외편 — 좋은 답변의 90%는 검색 전에 결정된다에서.

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 (이 글) · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

[사내 지식 AI 만들기 ③-2부·대화] RAG Score와 Answer Readiness는 다른 질문이다

2026-07-10T14:12:11+09:00

정확도 1.0, 그런데 남은 질문

1부에서 정확도 1.0을 냈다. 에이전트가 KB를 정확히 고르고, 권한 안에서, 근거를 재정렬해서 답했다. 그런데도 사용자는 여전히 나쁜 경험을 겪었다. 이유는 하나였다 — "검색이 맞았는가"와 "이 사람에게 답이 됐는가"는 다른 질문이기 때문이다.

이 구분을 실감 나게 보여주는 비교 대상이 하나 있다.

좋은 비교 대상, 그러나 다른 질문 — NotebookLM

여기서 자주 듣는 말이 있다. "이건 NotebookLM에서는 잘 나오는데요?" 틀린 말은 아니다. NotebookLM은 문서 몇 개를 넣고 요약·질문·근거 정리를 시키는 데 실제로 뛰어나다. 범위가 좁고, 문맥이 유지되고, 목적이 분명해서 잘 나온다.

문제는 비교 대상이 다르다는 데 있다. NotebookLM은 문서를 잘 읽는 도구다. 기업의 지식 AI는 그 위에 몇 가지를 더 얹어야 하는 운영체계다.

같은 질문도 누가 물었는지에 따라 답이 달라진다 — 그 사람이 그 문서를 볼 권한이 있는지부터 확인해야 한다(2탄).
최신 공지와 오래된 규정이 충돌하면, 어느 쪽을 우선할지도 판단해야 한다.
답이 틀렸을 때, 누가·어떤 근거로·어떤 경로로 답했는지 나중에 재현할 수 있어야 한다.

이건 문서 QA가 아니라 운영이다. 그래서 NotebookLM은 경쟁 대상이 아니라 기준점으로 쓰는 게 맞았다. 같은 문서를 넣었을 때 NotebookLM은 답하는데 우리 검색은 못한다면 — 그건 검색·청킹·리랭킹(1부)·근거검증·프롬프트 중 어딘가가 부족하다는 신호다. 반대로 NotebookLM이 잘한다고 그 경험을 그대로 기업 시스템에 옮길 수 있는 것도 아니다. 권한이 있어야 하고, 감사가 있어야 하고, 실패가 드러나야 하고, 업무로 이어져야 한다 — 문서를 잘 읽는 것과 회사 안에서 그 답을 운영 가능하게 만드는 것은 다른 일이다.

RAG Score vs Answer Readiness

이제 이름을 붙여보자.

RAG Score        : 문서를 잘 읽었는가?         (검색·태깅·재정렬의 정확도)
Answer Readiness : 이 사람에게 답이 됐는가?     (맥락·권한·시점까지 반영한 실사용 준비도)

RAG Score는 도구의 품질이고, Answer Readiness는 운영체계의 자격이다. 1부는 전자의 이야기였다. 여기서부터는 후자다.

Query Expansion — 사람은 완전한 문장으로 안 묻는다

"그거 다시 설명해줘." "방금 그건 휴가에도 적용돼?" — 이런 말은 그 자체로는 검색할 수 없다. 이전에 뭘 물었는지, 뭘 가리키는지가 없으면 "그거"는 그냥 대명사다.

그래서 검색으로 넘기기 전에 질문을 한 번 다듬는다. 세 갈래로:

문맥 보존 명확화 — "그거"가 뭘 가리키는지 앞선 대화에서 찾아 완전한 문장으로 바꾼다.
핵심 키워드 추출 — 검색엔진이 더 잘 무는 형태로 다시 뽑는다.
의미 보존 변형 — 같은 뜻을 다르게 표현한 질문 몇 개를 더 만들어서, 하나로 안 걸리는 것도 다른 표현으론 걸리게 한다.

여기서도 익숙한 구조가 나온다. 사전에 등록된 동의어·줄임말은 규칙 기반으로 항상 확장하고, 그걸로 부족하면 LLM 기반으로 의미를 더 풀어서 확장한다. 값싼 걸 먼저, 비싼 건 필요할 때만 — 1부 rerank에서 봤던 것과 같은 이중 구조다.

세 번 넘어졌던 이야기

이거 켜는 데 세 번 넘어졌다.

첫 번째는 이름이었다. 코드는 한 이름의 환경변수만 봤는데, 운영자는 다른(그러나 더 흔히 쓰이던) 이름으로 설정을 넣었다. 둘 다 "쿼리 확장을 켜라"는 같은 뜻이었는데, 코드가 한쪽만 알아들어서 — dev에는 켜졌고 prod에는 조용히 안 켜져 있었다. 에러 한 번 없이, 그냥 확장이 안 됐을 뿐이었다.

두 번째는 기본값이었다. 이름을 통일한 다음에도 기본값이 꺼짐으로 남아 있었다. 로그를 뒤져서 잡았다 — 같은 기간 dev 로그엔 "쿼리 확장됨" 흔적이 여러 건 있었는데, prod 로그엔 한 건도 없었다. 품질 지표(주제 적합도)도 유독 낮게 나오던 원인 중 하나가 이거였다. 기본값을 켬으로 뒤집었다.

세 번째는 인터페이스였다. LLM 기반 확장을 붙이자 "지원하지 않는 클라이언트 타입"이라는 에러가 매 요청마다 조용히 찍히기 시작했다 — 확장을 시도했다가 실패하고 원래 쿼리로 되돌아가는 걸 반복하고 있었다. 새로 붙인 LLM 클라이언트가 기대하던 메서드 이름과 실제 메서드 이름이 달랐던 것 — 어댑터로 감싸서 맞췄다.

세 번 다 겉으로는 "왜 확장이 안 켜지지"라는 같은 증상이었다. 원인은 매번 달랐다 — 이름 불일치, 기본값 반전, 인터페이스 불일치. 셋이 서로 아무 관계가 없다는 게 오히려 배운 점이었다. 같은 증상이 여러 다른 원인을 가릴 수 있다는 것.

개인화 스레드 회수 — 출입증이 이제 기억한다

2탄 끝에서 열어둔 질문이 있었다. "출입증은 못 들어가는 문만 막아줄 뿐, 이 사람이 평소 자주 드나드는 문이 어딘지는 알려주지 않는다."

이제 그 답을 할 수 있다. 매 턴마다, 이 사람이 누구이고(조직·부서·직급) 무엇을 기억하고 있는지(장기 기억)를 한 번에 모아 하나의 맥락으로 만든다. 이 맥락이 두 곳에 쓰인다.

하나는 대화 이어가기다. "그거 다시 설명해줘" 같은 말은 그 자체로는 아무것도 아니다. 기억이 있어야 "그거"가 뭔지 안다. 장기 기억에서 방금 무슨 대화가 있었는지를 찾아, 그 말을 완전한 질문으로 다시 써서 검색에 넘긴다. (앞서 본 Query Expansion의 문맥 보존 명확화와 같은 문제를, 대화가 남긴 흔적 쪽에서 한 번 더 푸는 셈이다.)

다른 하나는 조직에 맞춘 우선순위다. 같은 질문도 이 사람이 어느 조직·부서에 있는지에 따라 무엇을 먼저 보여줄지가 달라진다. 접근 가능한 범위(2탄)는 그대로지만, 그 안에서 _이 사람에게 더 맞는 것_을 앞에 놓는다.

두 가지 다 최근에 실제로 켜졌다. "이 사람이 평소 자주 드나드는 문"에 대한 답은 결국, 문을 열어주는 것과는 별개로 — 그 사람을 기억하고, 그 기억을 대화와 라우팅 양쪽에 실제로 쓰는 것이었다.

Before/After — 뭐가 달라졌나

숫자로 자랑할 단계는 아직 아니다. 그런데 체감은 있다.

같은 질문을 두 번 다른 말로 다시 물어야 했던 게, 한 번으로 줄었다 — 문맥 재작성과 쿼리 확장이 같이 자리를 잡은 덕분이다.
"그거 다시" 같은 되묻기가 끊기지 않고 이어진다 — 장기 기억이 무엇을 가리키는지 찾아준다.
같은 권한 범위 안에서도, 이 사람 조직에 더 맞는 답이 앞으로 온다.

여전히 남은 것도 있다. 그리고 그건 다음 이야기 몫이다.

심화 — "그거"를 자립형 질문으로 바꾸는 프롬프트, 그리고 "Pod" 사고

이 절은 깊다. 대화 재작성과 쿼리 확장이 실제 코드에서 어떻게 도는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 코드 — "그거"를 푸는 실제 프롬프트 + 방어막

본문의 "문맥 보존 명확화"는 실제로 이런 프롬프트로 돈다.

def _build_prompt(query, history):
    return (
        "사용자의 모호한 후속 질문을, 대화 기록에서 대명사·지시어(그거, 저분, 위, 아까)를 "
        "풀어 자립형 한국어 검색 질의로 다시 써라. 하나의 간결한 질의로. 답하지 말 것. "
        "이미 자립형이면 그대로 반환.\n\n"
        f"[대화 기록]\n{history}\n\n[현재 질문] {query}\n\n[자립형 질문]"
    )

중요한 건 프롬프트 자체가 아니라 그 주위의 방어막이다. 재작성 결과는 (a) 비어있지 않고 (b) 원본 대비 터무니없이 길지 않고 (c) 프롬프트의 섹션 마커를 되돌려 뱉지 않을 때만 믿는다(_is_plausible_rewrite). 하나라도 실패하면(타임아웃·예외·이상한 출력) 조용히 옛 방식(직전 대화를 그냥 뒤에 이어 붙이기)으로 폴백하고, Datadog에 applied|timeout|error|rejected 태그를 남긴다. "LLM 한 스텝 + 하드 폴백 + 관측 트립와이어" — 이 기능 하나를 넘어 재사용되는 패턴이다.

② 우리가 처음엔 틀렸다 — "Pod"가 "Print On Demand"가 되다

쿼리 확장이 켜지자 새로운 실패가 나왔다. 쿠버네티스 "Pod"를 물은 사용자의 질의가, 같은 용어 사전에 있던 전혀 다른 도메인의 약어로 조용히 확장됐다(리테일 쪽 "Pod = Print On Demand"). 사전에 IT 약어와 리테일 약어가 같이 살았고, 확장 로직은 사용자가 어느 도메인을 뜻했는지 몰랐던 것.

여기서 배운 게 이 시리즈에서 드문 결이다 — 확장은 "못 찾던 걸 찾게" 할 뿐 아니라, "맞던 걸 틀리게" 만들 수도 있다. 본문의 세 번 넘어진 이야기(안 켜지는 문제)와는 정반대 방향의 실패다. 고친 방식: 질의에 이미 다른 IT·인프라 용어가 섞여 있으면, 알려진 교차-도메인 동음이의(pod, node, service, image, port, token, storage, disk)에 대해선 사전 확장을 건너뛴다 — 사전을 무조건 믿지 않고 문맥으로 가드.

그리고 하나 더 — 이 확장이 답변 품질을 실제로 올리는지 A/B로 재려 했는데, 정작 골든 질문 세트에 "짧은 도메인 약어 질의"가 너무 적어 통계적으로 판정할 수 없었다. 그때 결과를 우겨서 내는 대신 INSUFFICIENT_DATA로 정직하게 기록하고, 검정력이 낮다는 단서를 붙여 A/B 결론을 냈다. 기능의 버그가 아니라, 기능을 재는 방식의 결함을 먼저 공개한 사례다.

맺음 — 그리고 다음 질문

1부에서 라우팅을 풀었고, 2부에서 대화의 결을 채웠다. 태깅 정확도와 대화 능력, 둘 다 갖췄으니 이제 완성일까?

아직 하나가 남는다. 이 좋은 답을 어디서 보여줄 것인가. 우리는 하마터면 앱을 또 만들 뻔했다. 그 이야기는 4탄 — 모바일 앱을 또 만들 뻔했다에서.

(그리고 — 이 모든 걸 사람이 아니라 에이전트가 굴린다는 이야기, Claude나 Codex 같은 코딩 에이전트도 결국 같은 틀 안의 "에이전트"라는 이야기는 언젠가 따로.)

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 (이 글) · 4탄 채널 · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

[사내 지식 AI 만들기 ③-1부·대화] 사용자는 한 줄로 묻지 않았다 — 그런데 정확도 1.0으로도 부족했다 (RAG → AgenticRAG)

2026-07-10T13:56:17+09:00

사서가 필요했다

2탄까지 — 지식은 통합 컬렉션에 잘 저장되고, 권한대로 안전하게 조회된다. 그런데 한 가지가 끈질기게 남았다.

"이 질문은 어느 KB를 봐야 하지?"

per-KB 시절엔 사람이 골라줬다. "그건 인사 KB에 물어보세요." 새 KB가 끝없이 추가되는 환경에서, 이 수동 선택은 곧 한계에 부딪혔다. 게다가 사용자는 한 줄로 묻지 않는다.

"지난번 그 정산 건, 점포 기준이랑 본사 기준 다르지? 그리고 그거 휴가에도 영향 있어?"

한 마디에 정산·점포운영·인사 세 지식이 얽힌다. 멀티턴, 멀티인텐트. 사람이 KB를 골라주는 고전 RAG로는 이 대화를 감당할 수 없다. 잘못 고르면 — 문서는 있는데 답을 못 한다.

이건 가정이 아니라 반복해서 겪은 패턴이었다. 같은 사용자가 부서 경계를 넘나드는 질문을 매번 다른 봇에 따로 물어야 했고, "이걸 왜 매번 나눠서 물어야 하나"라는 불만이 쌓였다. 지식은 잘 저장돼 있는데(1탄), 그걸 하나의 대화로 잇지 못하면 사용자에게는 여전히 흩어진 지식일 뿐이었다.

RAG → AgenticRAG

전환점은 이거였다. "어느 지식을 볼지"를 사람이 하드코딩하는 대신, 에이전트가 대화 맥락 + 사용자 권한 + 의도로 동적으로 고르게 했다.

여기서 "Agentic"의 범위: 에이전트가 무엇을 검색할지 스스로 정한다는 뜻이다 — 의도를 분해하고, 접근 가능한 KB scope를 고르고, 멀티인텐트를 라우팅한다. (검색 결과를 스스로 평가·재시도하는 더 무거운 _적응형 루프_는 지연·비용 트레이드오프가 있어 별개의 프론티어로, 신중히 단계적으로 켠다. 과장하지 않는다.)

멀티턴/멀티인텐트 질문
   → 의도 분해 (멀티 인텐트 감지)
   → 사용자 권한(2탄) 해석 → 접근 가능한 KB scope 자동 선택   ← 사람이 KB 안 고름
   → scope 내 통합 검색(1탄)
   → 필요하면 clarify ("어느 점포 기준이요?")
   → rerank → 근거 기반 답변

대화 스택:

LLM 라우팅   : LiteLLM Proxy (작업별 모델 분리 — 분류는 가볍게, 답변은 무겁게)
의도 분해    : LLM 기반 intent classifier (멀티인텐트 감지)
에이전트 조율: Supervisor 패턴 (역할별 에이전트에게 위임)
비동기 실행  : Temporal 워크플로 (에이전트 작업 상태 추적)
권한 신호    : 사용자 조직 기준 KB 접근범위 결정

한 명의 사서가 아니라 역할이 나뉜 여러 에이전트가 이 대화를 나눠 맡는다. 지식을 아는 에이전트, 그걸 조율하는 층, 실제로 화면을 조작하거나 알림을 보내는 에이전트 — 저마다 자기 몫을 하고, 서로에게 넘긴다. 그리고 누가 물었는지(조직)가 그 라우팅에 함께 반영된다 — 다만 "이 사람이 평소 자주 찾는 지식까지" 반영하는 개인화는 아직 다른 이야기다. (2부에서 왜 그런지 다룬다.)

사서 비유 — 사서 한 명에서, 사서 팀으로

예전 도서관에선 사서가 "303호 서가로 가세요"라고 위치를 알려줬다 — 사용자가 서가 번호를 알아야 했다(수동 KB 선택). 처음엔 사서 한 명(에이전트 하나)이 질문을 듣고 알아서 서가를 도는 정도로 충분해 보였다.

그런데 질문이 여러 전문 분야에 걸치자, 사서 한 명으로는 부족했다. 그래서 도서관을 사서 팀으로 다시 그렸다 — 각 분야를 잘 아는 사서들이 있고(아는 역할), 그 사서들 사이에서 "이 질문은 누구한테 먼저 물어야 하나"를 정리해주는 총괄 사서가 있고(조율하는 역할), 그리고 자료를 찾아주는 데서 그치지 않고 실제로 뭔가를 갖다주거나 대신 처리해야 할 때 움직이는 사람도 있다(실행하는 역할). 사용자는 여전히 한 명의 사서에게 물을 뿐이지만, 그 뒤에서는 팀이 협업한다.

핵심은 "검색을 똑똑하게"이기 이전에, "무엇을 검색할지를 에이전트가 정한다"였다. 끝없이 자라는 KB를 사람이 일일이 관리하던 구조에서, 에이전트가 권한과 의도로 길을 찾는 구조로.

rerank — 후보를 찾은 다음, 순서를 다시 세운다

"무엇을 검색할지"는 에이전트가 정했다. 그런데 검색(1탄, dense+sparse hybrid)은 후보를 넓게 찾는 데 강할 뿐, 그 후보를 질문에 가장 잘 맞는 순서로 세우는 데는 약하다. 임베딩 검색(bi-encoder)은 질문과 문서를 각각 따로 벡터로 만들어 거리로 비교하기 때문에 빠르지만, 질문과 문서를 나란히 놓고 세밀하게 견주지는 못한다.

그래서 상위 후보에만 한 번 더 손을 댄다. 질문과 문서를 함께 입력해 정밀하게 관련도를 매기는 cross-encoder 기반 reranker를 상위 후보에만 돌린다 — 전체 후보에 돌리면 느리니까, 값싼 1차 검색으로 후보를 좁힌 다음 비싼 2차 정렬을 그 위에만 얹는 구조다. 상용 rerank API를 1순위로 쓰고, 막히면 자체 호스팅 cross-encoder로 넘어가는 이중화도 해뒀다.

순서를 정할 때도 모델 점수 하나만 보지 않는다. 모델 관련도 + 원래 검색 순위 + 출처 종류(공식 문서·웹·그래프·FAQ 별 가중치) + 필요하면 결과 다양성을 가중합해서 최종 순서를 만든다. FAQ로 등록된 답이 있으면 살짝 밀어주고, 비슷한 문서만 줄줄이 나오지 않도록 다양성 점수도 얹는다. "무엇을 볼지"는 에이전트가 고르고, "어떤 순서로 보여줄지"는 이 재정렬이 고른다 — 둘이 같이 맞아야 사용자가 실제로 원하는 답에 먼저 닿는다.

(이 "값싸고 넓게 + 비싸고 정밀하게" 이중 구조, 기억해 두면 2부에서 한 번 더 보게 된다 — 검색 말고 다른 layer에서.)

정확도 1.0인데, 왜 여전히 나쁜 경험이었나

여기서 또 한 번 배웠다. 어느 질문이 어느 지식 범위(KB)에 속하는지, API로 태그를 정확히 매기는 것 자체는 정확도 1.0까지도 낼 수 있었다. 그런데 그것만으론 부족했다.

사람은 한 번에 묻지 않는다. 되묻고, 앞서 한 말을 다시 끌어오고, 한 문장에 여러 의도를 섞는다. 지식 범위를 완벽하게 골라내는 것과, 그 반복·다의도 대화를 자연스럽게 받아내는 것은 다른 능력이었다. 태깅 정확도가 아무리 높아도, 대화 기능이 그 대화의 흐름을 못 따라가면 — 사용자에게 돌아오는 건 잘 만든 지식이 아니라, 뚝뚝 끊기는 나쁜 경험뿐이었다.

즉 1탄의 저장, 2탄의 권한이 아무리 정교해도, 이 위에서 사람과 자연스럽게 대화를 이어가는 능력이 없으면 그 지식은 사용자에게 닿지 않는다. 지식 범위를 고르는 일(라우팅)과 대화를 이어가는 일(대화 관리)은 같이 완성돼야 하는 한 쌍이었다.

심화 — reranker는 fallback 안에 fallback, 그리고 점수가 1.0에 붙어버린 사고

이 절은 깊다. 라우팅과 재정렬이 실제 코드에서 어떻게 방어되는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 코드 — 리랭커는 fallback 안에 fallback

본문에서 "상용 rerank API 1순위, 막히면 자체 호스팅 cross-encoder"라 했다. 실제 코드는 한 겹 더 깊다.

def _create_reranker():
    """우선순위: cohere(상용, LiteLLM 경유) > cross_encoder(자체) > 없음."""
    if reranker_type == "cohere" and os.getenv("LITELLM_API_BASE"):
        return CohereReranker()                    # 1순위: 상용 API
    if os.getenv("DISABLE_CROSS_ENCODER_RERANKER") != "true":
        adapter = CrossEncoderIRerankerAdapter()   # 2순위: 자체 호스팅
        loop.create_task(adapter.warmup())         # 모델 로드는 논블로킹
        return adapter
    logger.warning("리랭커 없음 — 벡터 유사도 순서만. 관련도 ~20%% 저하 예상.")
    return None                                    # 3순위: 없음(조용히 넘기지 않고 숫자 로깅)

눈여겨볼 두 가지: (1) 자체 모델 warmup을 loop.create_task로 논블로킹 발사 — 콜드 모델 로딩이 그 요청을 붙잡지 않는다. (2) "리랭커가 아예 없는" 최후 분기가 조용히 넘어가지 않고 "~20% 관련도 저하"라는 숫자를 로그에 남긴다. 그리고 자체 어댑터(CrossEncoderIRerankerAdapter) 안에는 또 3단 fallback이 있다 — 원격 자체호스팅 HTTP → 인프로세스 로컬 모델 → 원순위 기반 선형감쇠. fallback 안의 fallback.

② 영리한 선택 — 점수 정규화: 절대 clamp vs 배치 상대 stretch

싼 1차 점수(벡터 유사도)와 비싼 2차 점수(cross-encoder 관련도)를 가중합할 때, 두 점수의 스케일이 다르다(코사인은 대략 0~~1, rerank logit은 -10~~10 같은 무한대역). 우리가 고른 방식은 각 점수를 절대 기준 0~1로 clamp하는 것. 기각한 대안:

정규화 없이 그냥 합산 — 스케일이 달라 무의미.
배치 안에서 min-max로 늘리기(stretch) — 이게 함정이었다(④ 참조).
순위-위치 가중(1등=1.0, 2등=0.95…) — 점수 크기를 버려서, 톱1이 "진짜 좋아서"인지 "그 배치에서 제일 덜 나빠서"인지 구분 못 함.

③ 숫자, 정직하게 — 둘은 실측, 하나는 아직

점수 포화 fix: golden-question 평가에서 리랭커 톱1 점수가 천장에 붙어 있었다 — 실제 관련도와 무관하게 톱1이 ≥0.94인 비율이 89.6%. 배치 min-max 정규화가 그 배치의 최고점을 항상 1.0으로 만든 탓. 목표를 "톱1 ≥0.94 비율 <50%"로 잡고 고쳤다.
KB scope 확장 A/B(프로덕션 데이터, 골든 26문항): 좁은 기본 scope vs 권한 내 넓힌 scope → 도메인 질문 근거율(grounded@0.5)이 3/22(13%)에서 10/22(45%)로, 대조군 회귀 0.
intent classifier 정확도: 하드 넘버 아직 없음(목표 ≥80% top-1, 8문항 PoC만) — 정직하게 "측정 인프라는 설계했으나 아직 대규모 미가동".

④ 우리가 처음엔 틀렸다 — flag 켜니 "이 시스템 뭐야?"가 깨졌다

KB scope를 넓히는 건 명백히 좋아 보였다(③의 A/B가 증명). 그런데 프로덕션에서 flag를 켜자, 그동안 항상 맞히던 기본 질문 — "이 시스템 뭐야?" — 이 즉시 회귀했다. 격리된 A/B 경로에선 멀쩡했는데, 라이브 end-to-end 경로에서만 깨졌다.

원인은 ②의 점수 포화와 같은 버그 계열이었다: 명시적 KB 리스트가 없을 때만 도는 내부 "KB 선택" 스텝이, min/max 기반 정규화로 아무 상관없는 대형 KB에 인공적 천장 점수를 줘서 톱으로 올려버린 것. 좁혀진 후보 집합에서 "제일 top인 하나"가 실제 관련도와 무관하게 1.0을 받는, 바로 그 실패.

고친 순서가 교훈이다: (1) 같은 날 flag를 한 줄로 되돌려 롤백 → (2) 다음날 격리로 원인 규명(명시적 KB 리스트로 넘기면 정상, "필터 없이 파이프라인이 알아서 고르게" 하면 회귀) → (3) 넓힌 scope를 항상 명시적 KB 리스트로 넘겨 그 버그 경로를 고치는 대신 우회해 재출시. 이 사고는 지금 라이브 코드의 docstring(_resolve_accessible_default_kb_filter)에 그대로 적혀 있다 — 코드가 자기 과거 회귀를 기억한다.

교훈: 격리된 실험에서 좋았다고 라이브에서도 좋은 게 아니다. "이 경로에서만 도는 스텝"이 실험 경로엔 없고 라이브 경로엔 있으면, 그 차이가 정확히 회귀가 숨는 자리다.

맺음 — 그리고 이 반전이 남긴 질문

이제 에이전트가 알아서 지식을 찾는다. 멀티턴으로 얽힌 질문도, 권한 안에서, 근거를 모아 답한다. 그런데 정확도 1.0짜리 라우팅으로도 사용자는 여전히 나쁜 경험을 겪었다 — 그 이유를 따라가면 질문이 하나 남는다.

"검색이 맞았는가"와 "이 사람에게 답이 됐는가"는 다른 질문이었다. 그리고 2탄이 심어놓은 또 다른 숙제 — 이 사람이 _평소 자주 찾는 지식_은 여전히 못 알아본다는 것 — 도 그대로 남아있었다.

이 두 질문에 어떻게 답을 하려 했는지는 3탄-2부 — RAG Score와 Answer Readiness는 다른 질문이다에서.

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 (이 글) · 3탄-2부 대화 · 4탄 채널 · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.