코르카 AX Day 3회차: 슬기로운 보안생활
4월 2일 목요일, 2주만에 코르카의 3번째 AX Day가 열렸습니다.

AX Day는 격주 목요일, 더 큰 도약을 위해 잠시 무릎을 꿇고 손발에 흙을 묻혀가며 여러가지 재미있고 급진적인 시도를 해보는 날입니다. 업무시간이 10% 줄게 되겠지만, 이를 통해 장기적으로는 생산성 및 업무에서 오는 재미가 10배 늘어나길 기대합니다.
이번 AX Day 는 지난 2회와 다르게 테마를 넣었습니다. 바로 '보안' 테마였는데요. 이젠 정말 경각심을 가져야 할 시기라고 판단했기 때문입니다.
보안 분야에서 최악이었던 한 주
AI 코딩이 대세가 된 이후로 부쩍 보안 사고가 많아졌고, 이번주에도 큰 사건이 여러 개 터졌죠. 최근의 보안 사고들에 대해 Conviction의 창업자이자 X에서 활발히 활동하고 있는 Sarah Guo가 쓴 '다크 코드'라는 글이 상당히 인상적이었습니다. 최승준님이 번역하신 글이 있어서 일부 인용합니다.
보안 분야에서 정말 최악이었던 한 주 요약:
* TeamPCP 공격: 해커들이 Trivy라는 인기 오픈소스 보안 스캐닝 도구의 빌드 시스템에 침입했다. 이것은 공급망 공격(널리 쓰이는 소프트웨어 도구나 라이브러리에 악성 코드를 몰래 끼워 넣어서, 이를 다운로드하거나 사용하는 사람들에게 자동으로 퍼지게 만드는 공격)이다. 해커들은 탈취한 접근 권한을 이용해 LiteLLM(월간 약 1억 건 다운로드되는 인기 Python 게이트웨이 라이브러리로, 개발자들이 하나의 단순한 인터페이스를 통해 여러 AI 모델을 쉽게 호출할 수 있게 해준다)과 Telnyx(통신 플랫폼으로, 예를 들어 개발자들이 전화 통화를 만들고 문자 메시지를 보낼 수 있게 해준다) 같은 다른 도구들까지 오염시켰다. 이 악성 코드는 개발자들의 컴퓨터에서 비밀번호와 각종 비밀 정보를 훔쳤고, 이를 통해 해커들은 Mercor에 침입해 매우 민감한 데이터를 대량으로 탈취했고, Cisco에도 침입해 자사의 AI 제품 관련 소스 코드를 훔쳤다.
* Axios npm 공격: 누군가가 axios(브라우저나 앱에서 인터넷을 통해 데이터를 쉽게 주고받을 수 있게 해주는 인기 JavaScript 라이브러리)의 핵심 기여자 계정을 탈취했다. 이것 역시 또 하나의 공급망 공격이었다. 해커들은 두 개의 가짜 버전을 배포했고, 이 버전들은 이를 다운로드한 사람들의 컴퓨터에 몰래 악성 소프트웨어를 설치했다. 그 결과 해커들은 해당 컴퓨터들을 원격으로 완전히 제어할 수 있게 되었다.
* Claude 유출: Anthropic은 자사의 AI 코딩 도구를 배포하면서, 내부 코드 전체와 비밀 지시문, 그리고 향후 출시 예정 기능들이 들어 있는 큰 숨김 파일을 실수로 함께 공개했다. 모델 가중치가 유출된 것은 아니었다. 하지만 차기 미출시 AI 모델인 “mythos”에 관한 문서들이 온라인에 노출되었다. 이는 해킹이 아니라 실수로 발생한 사고였다.
* Railway 이슈: Railway(개발자용 클라우드 플랫폼)는 설정 실수를 잠깐 하는 바람에, 1시간 미만 동안 무작위 사용자들이 다른 이용자들의 비공개 정보를 볼 수 있게 만들었다. 이와는 별개로, 악의적인 행위자들은 Railway의 플랫폼을 Microsoft 계정 대상 피싱 공격을 운영하는 도구로 활용하기도 했다.
남의 이야기가 아니다
위에서 LiteLLM 이슈는 실제로 회사 동료 한 분이 (Ouroboros라는 하네스를 새로 시도하다가) 공격당해서 맥북이 한동안 먹통이 되기도 했습니다. Axios 와 Claude Code는 우리가 매일같이 쓰는 라이브러리와 도구들이었고요. 장기 미사용 상태였던 코르카의 AWS 서비스에 대한 정보 탈취 시도가 있었다는 경고 메일이 날아와서 깜짝 놀라기도 했었습니다.
이러한 보안 문제가 이젠 정말 남의 이야기가 아니라는 생각에, 회사 C레벨 전원이 모여 정말 진지하게 대응할 순간이라는 합의에 도달했습니다. 물론 기본적인 보안은 회사 차원에서, 그리고 각자 잘 지키고 있다고 생각했지만 그 이상의 무언가가 필요하다는 느낌이 강하게 들었던 것이죠.
그래서 이번 AX Day의 테마가 '보안'이 되었어요. 보안 TF를 꾸려 할 수 있는 모든 보안 조치를 취하고, 다른 분들도 보안과 관련된 아이디어를 짜내서 뭔가 해보자는 것.
산출물들
보안이라는 게 그리 쉬운 주제는 아니었던 만큼, 어려워하시는 분들도 많고 여러가지 공부를 하신 분들도 많았어요. 그래서 잘 생각이 안나면 지난 AX Day 들처럼 해보시라는 얘기도 드렸습니다. 결과적으로는 이런 것들이 나왔습니다.
- 슬기로운 보안 생활 가이드 + 도구들 (공급망 공격 취약점 분석 스킬 등)
- OWASP Top 10을 공부하며 회사 제품을 모의 해킹하여 취약점 발견
- 회사 및 제품 문의에 대응하는 AI 콜센터 (민감한 얘기는 유출하지 않게 프롬프팅)

- OpenClaw 토큰 만료를 기념하여 토큰 인증 패턴 가이드를 만들어 공부

- '코르카 보안왕'을 뽑는, Slido를 이용한 보안 퀴즈 대결 (1등과 꼴등은 슬랙에 뱃지가 달림)

- 소셜 엔지니어링에 대해 공부하면서, 서로 블러핑/가스라이팅/시스템 공격 등을 통해 상대방의 키/몸무게를 탈취하는 에이전트를 개발해봄

몇 가지는 조금 더 자세히 소개합니다.
슬기로운 보안 생활 가이드
코르카의 CEO, CTO, Head of Products, 인프라 전문가 네 분으로 구성된 보안 TF에서는 이번 AX Day 에 아래와 같은 노션 가이드를 만드셨습니다.

얼핏 보면 당연해 보이는 항목들이지만, 스타트업으로서 속도를 유지하면서도 안전을 지킬 수 있게 문장 하나하나를 구성하는 데 TF에서 심혈을 기울였습니다. 그리고 '가이드 문서'의 존재만으로 보안 수준이 실제로 올라가는 게 아니듯, 여러가지 실질적인 실행을 하고 장치와 도구도 마련했어요. 몇 가지 예를 들면:
- 모든 시크릿 키는 Vault에서 관리
- 구글, 깃헙, 슬랙, 노션, AWS 등 모든 서비스에 전 직원 2FA 설정
- 모니터 안 꺼져있는 동료 컴퓨터 발견하면 슬랙에 '나는 바보입니다' 보내기 (단, 처벌이나 수치심에 기반한 보안 정책은 역효과를 준다는 점은 잘 알고 있습니다. 가이드에서는 '드러내기'의 중요성을 가장 크게 강조합니다)
- AWS에서 안 쓰이는 자원과 Security 그룹 정리, 보안 감사 로그 켜기
- 깃헙 저장소의 공급망 공격 취약점을 찾아주는 보안 감사 스킬 개발 및 적용
공급망 공격 취약점 분석 스킬
저는 특히 CTO님이 만드신 보안 감사 스킬이 아주 신통방통하게 느껴지더군요. Anthropic의 공식 /security-review 는 전혀 문제없다고 한(좌측 이미지) 저장소에 대해 여러가지 잠재적 공급망 공격 취약점을 찾아줬기(우측 이미지) 때문입니다.


좌측: 공식 /security-review 결과 우측: 코르카 /security-audit 결과
두 스킬은 목적이 좀 다릅니다. 공식 /security-review 는 아직 푸시되지 않은 커밋들에 대해(검사한 저장소는 한참동안 작업 중이었어서 커밋 179개가 쌓여있었네요) 공급망 공격 취약점을 포함한 여러가지 검토를 해줍니다. pre-push 훅이나 CI에서 쓰라고 만든 것입니다.
반면 코르카 보안 감사 스킬은 git diff 대신 저장소의 모든 패키지 매니저 패턴을 감지하고, 공급망 공격 취약점을 집중적으로 분석하여 대응법을 알려줍니다. 전체 검사이다 보니 매번 돌리는 건 과해요. 예를 들어 분기별로, 또는 메이저 업그레이드를 할 때마다 쓰면 됩니다. 이 스킬은 내부에서 많이 써보고 좀 더 안정화되면 퍼블릭 공개 예정입니다.
OWASP Top 10에 기반한 보안 스터디 + 모의 해킹
이건 제가 소속된 조에서 해본 건데요. 저 또한 보안에 대해 아는 바가 많지 않았기 때문에 조악하나마 레드팀 역할을 해보면서 보안 공부를 하면 좋겠다고 생각했어요.
어떻게 시작할까 하다가 AX팀 동료인 최정혁님이 만드신 study 스킬이 떠올랐어요. 주제 또는 URL을 쥐어주면 소크라테스식으로 질문을 던지며 이해를 돕고 진행 과정을 기록해주는 스킬입니다. 클로드 코드를 켜고 두서없이 시작했어요. (길어서 접어뒀지만, 가치있는 내용이 많으니 궁금하시면 펴보세요 😄)
첫 몇 턴 대화 재구성
<첫 질문>
보안에 대한 공부를 좀 하려고 합니다. 보안에 문외한이라 보안 철학, 기법, 공격방법(레드팀) 등등 아는 게 하나도 없습니다.
일단 생각하는 건 유명한 오픈소스 패스워드 관리자 (또는 오픈소스로 열려있는 임의의 이런 공부하기 좋은 리포지토리) 하나를 골라서, study 스킬로 공부해보는 겁니다. 그런데 '보안'을 더 깊이 이해하게 되었다는 것을 어떻게 평가할 것인가가 중요합니다. 이 평가하는 질문들, 또는 평가 방법, 또는 어떤 행위를 할 수 있게 됐다, 어떤 자신감(자기효능감)이 생겼다 같은 기준을 잘 세우고 시작하는 게 가장 중요할 것 같습니다.
제 목적을 달성하는데 도움이 되는 얘기를 같이 해봅시다.
<클로드 응답 (일부)>
좋은 접근입니다. 도구부터 실행하기 전에 목표와 평가 기준을 먼저 정리하는 게 맞습니다.
학습용 리포지토리 추천
보안 학습용으로 몇 가지 후보를 비교하면:
- age: Go, ~3000줄, 암호화 도구, 설계 문서 명확. 단점은 범위가 좁음 (암호화에 집중)
- Bitwarden: 패스워드 관리자, 인증/암호화/네트워크 모두 포함. 단점은 거대한 분산 아키텍처임
- KeePassXC: 로컬 패스워드 관리자, 중간 규모. 단점은 C++이며 복잡도가 높음
- OWASP Juice Shop: 의도적 취약점 포함, 공격 학습용. 단점은 "나쁜 코드"를 보는 것이라 설계 철학 학습엔 약함
제 추천: age로 시작 → 이후 Juice Shop으로 확장
- age는 "보안을 잘 하는 코드가 어떻게 생겼는가"를 배우기에 최적이고
- Juice Shop은 "공격자 관점"을 배우기에 좋습니다.
평가 기준 제안
보안 이해도를 측정하는 3가지 축을 제안합니다:
1. 설명 능력 (개념 이해)
- "이 코드에서 왜 이 알고리즘을 선택했는지" 설명할 수 있는가
- 암호화 기본 원칙(CIA triad, Kerckhoffs' principle 등)을 자기 말로 설명할 수 있는가
- "이 설계가 어떤 위협 모델을 가정하는지" 말할 수 있는가
2. 식별 능력 (코드 리뷰)
- 임의의 코드를 보고 "이건 보안상 문제가 있다"를 짚어낼 수 있는가
- PR 리뷰에서 보안 관련 코멘트를 달 수 있는가
- CVE를 읽고 "무엇이 잘못됐고 어떻게 고쳤는지" 이해할 수 있는가
3. 적용 능력 (실전)
- 간단한 기능을 구현할 때 보안 고려사항을 스스로 떠올릴 수 있는가
- 위협 모델링을 스케치할 수 있는가
- "이 시스템을 공격한다면 어디를 노릴까"라는 질문에 답할 수 있는가
<내 응답>
전반적으로는 괜찮고, 제안해준 age 리포지토리도 괜찮아 보이는데, 이걸 생각해봅시다.
솔직히 실질적으로 지금은 대부분의 '코딩'을 코딩 에이전트가 합니다. 그래서 특정 코드 스니펫을 보고 보안 위협이 있는지 식별하는 능력도 중요하지만, 그것보다는 에이전트에게 어떤 특정한 키워드를 담아 프롬프팅했을 때 보안 위협을 에이전트가 잘 찾는가? 도 중요하다고 생각합니다. 그래서 이것도 같이 테스트를 해보고 싶습니다. (서브에이전트 활용하면 될 것 같기도 하고..)
근데 한편으로는, 그냥 '보안 위협이 될만한 거 찾아줘'라는 간단한 프롬프트만으로 되는 거 이상을 하고 싶습니다. 그리고 보안 위협은 대부분 정적 분석으로 찾아내는 게 가능할 것도 같은데, snyk? 이런 도구가 뭘 어떻게 하는지도 궁금합니다. 두서없이 얘기했는데 이해하셨나요?
그리고 이걸 통해서 결국 우리가 하고 싶은 건, 우리 소스코드/앱에 대한모의 공격? 을 하고 싶어요. 그래서 이 행위를 할 수 있게 되는 게 최종 골 일 것같기도 합니다.
셋이서 한 조였는데, 이런 식으로 함께 토론하다 보니 점차 방향성이 잡혔습니다. 클로드에게 OWASP(Open Worldwide Application Security Project) Top 10 이라는, 다수의 웹 서비스에 흔히 존재하는 보안 취약점을 하나씩 배우면서 이 취약점들이 실제로 우리 회사 서비스에 존재하는지 찾아보고 함께 모의 공격을 해보는 것이었어요. 참고로 2025년의 Top 10 목록은 다음과 같습니다.
- A01:2025 - Broken Access Control
- A02:2025 - Security Misconfiguration
- A03:2025 - Software Supply Chain Failures
- A04:2025 - Cryptographic Failures
- A05:2025 - Injection
- A06:2025 - Insecure Design
- A07:2025 - Authentication Failures
- A08:2025 - Software or Data Integrity Failures
- A09:2025 - Security Logging and Alerting Failures
- A10:2025 - Mishandling of Exceptional Conditions
항목이 많다 보니 모든 키워드와 개념을 완벽히 이해한 건 아니었지만 공부하는 게 아주 즐거웠습니다. 그냥 공부만 하는 게 아니라 이 문제가 우리 서비스에서 왜 중요한지, 현실적인 시나리오로 어떤 일이 생길 수 있는지 클로드에게 만들어달라고 해서 검토해보니 와닿는 게 많았어요. 클로드의 이런 제안을 받고 각자 프롬프트를 작성해보기도 했습니다.
클로드: 지금까지 배운 IDOR 개념을 가지고, 문라이트 코드베이스에서 이 취약점을 찾기 위해 에이전트에게 시킬 프롬프트를 직접 작성해보시겠어요? 세 분이 각자 한 줄씩 써봐도 좋습니다.
클로드가 평가도 해주고, 실제로 코드베이스에 던져본 결과를 분석도 해보고요. 자세한 결과는 (보안상 😄) 공개하기 어렵지만, 이러한 과정에서 크고작은 취약점(예: 인증 없이 접근 가능한 API 엔드포인트)을 정말로 찾아냈어요. 코드베이스 접근 권한이 있었기 때문에 비교적 쉽게 찾아낸 것들이지만, 정확한 키워드를 알고 탐색하니 이렇게 짧은 시간에 많은 이슈를 찾을 수 있다는 것에 기분이 묘했습니다. 깃헙에 이슈를 올리면서 뿌듯하기도 하고 경각심도 들더군요.

맺으며
AX Day 전날, CTO인 강규영님이 슬랙에 이런 내용의 글을 올리셨습니다.
- 보안 사고는 누구나 겪을 수 있는 감기 같은 것이다. 밖에 안 돌아다니면 감기에 안 걸리듯, 아무것도 안 하면 오히려 안전할 수 있다. 이것저것 열심히 하는 사람들이 사고를 겪을 가능성이 높아진다. 그러니 사고 당한 사람들은 위축되지 말자.
- 한편, 감기는 누구나 걸릴 수 있지만 공중보건 정책을 정하고 시행하는 건 국가의 책임이듯, 보안 사고는 누구나 겪을 수 있지만 보안 정책을 정하고 시행하는 건 회사의 책임이다. 그래서 작은 보안 TF를 만들어 정책을 잘 정해보려 한다. 앞으로 조금 귀찮은 일들을 종종 부탁드릴텐데, 지나치게 귀찮지 않으면서 적절하게 안전할 수 있는 방안을 잘 고민해보겠다.
서두에 언급한 Sarah Guo는 이렇게 말하기도 했습니다.
AI 소프트웨어의 폭발적 증가와 개발 속도, 에이전트형 라이브러리 선택, 그리고 AI 자동화 빌드 / AI가 관리하는 시크릿 체계가, 기존부터 존재하던 공급망 문제와 인간의 실수를 분명히 더 증폭시키고 있다.
코딩 에이전트의 도움으로 전 국민의 개발자화가 진행되고 있습니다. 이 말은 전 국민이 보안 사고라는 감기에 걸릴 수 있는 상황이라는 뜻이기도 합니다. 사실 보안 사고는 감기보다 훨씬 더 심각한 영향을 불러오기도 하고요. 전례없는 속도로 소프트웨어가 만들어지고 있는데, 그 모든 소프트웨어(를 만드는 전 국민의 컴퓨터)가 취약해지고 있는 셈이죠.
실제로 GitGuardian에서 최근 발표한 연구에 따르면 이게 단순한 '느낌'이 아니라는 게 분명해집니다. (Disclaimer: GitGuardian은 시크릿 탐지 도구를 파는 회사이므로 조금은 걸러 들어야 합니다)
- 2025년 GitHub 퍼블릭 커밋이 약 19.4억 건에 달했으며, 전년 대비 43% 증가 — 이전보다 최소 2배 빠른 성장 속도
- 활성 개발자 수는 33% 증가
- AI 보조 코드의 시크릿(비밀 키) 유출률이 GitHub 전체 기준의 약 2배
- 유출된 시크릿은 총 약 2,865만 건, 전년 대비 34% 증가 — 역대 최대 단일 연도 증가폭
보안을 지키는 데 꼭 빡센 SoC나 네트워크 모니터링 장치 같은 조직 레벨의 무언가가 필수적인 건 아닙니다. 오히려 이런 장치가 있으면 불편해도 안전하겠지, 같은 착각을 불러일으킬 수 있습니다.
"AI 시대에 가장 취약한 건 개발자들의 컴퓨터이며, 비교적 짧은 프롬프트/스킬/스크립트 실행만으로도 아주 많은 문제를 방지할 수 있다." 이게 이번 AX Day에서 얻은 가장 큰 교훈입니다. 코드 취약점 해소를 비롯한 실질적인 조치도 열심히 취하고 있고요. (물론 '짧은' 프롬프트와 스킬을 만들기 위한 공부는 필요했습니다)
여러분의 조직에서도 '감기'에 걸리지 않도록 예방주사와 마스크를 준비해보는 건 어떠실까요?
참고자료
클로드에게 이 글을 검토시키면서 얻은 참고자료도 몇 개 첨부합니다.
- "Secure by Design" (2019, Dan Bergh Johnsson et al.) — 보안을 코드 설계에 내장하는 접근. 글에서 말하는 "단순한 프롬프트로 방지"를 넘어서는 체계적 접근에 대한 좋은 참고서.
- "The Security Culture Framework" by Kai Roer — 수치심 기반 보안 문화의 문제점과 대안. "나는 바보입니다" 슬랙 메시지 같은 관행의 양면을 이해하는 데 유용.
- Google's "SLSA" (Supply-chain Levels for Software Artifacts) — 공급망 보안을 체계적으로 등급화하는 프레임워크. 글에서 다룬 공급망 공격 주제를 더 구조적으로 이해하는 데 도움.
- "Lessons from the Codecov Breach" (various, 2021) — 공급망 공격의 실제 사례 연구. Sarah Guo의 인용보다 더 깊이 있는 기술적 분석.
- "Threat Modeling: Designing for Security" by Adam Shostack — OWASP를 넘어서 위협 모델링을 체계적으로 배우고 싶다면.
Member discussion