Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 05. 16:21

회사가 Claude Code 사용을 허가하지 않아서, 코드를 로컬에서 비식별화하는 프록시를 만들었습니다

요약

기업의 보안 정책으로 인해 AI 코딩 도구 사용이 제한되는 문제를 해결하기 위해, 로컬에서 코드를 비식별화하는 오픈 소스 프록시 'Kiri'를 개발했습니다. Kiri는 민감한 정보를 플레이스홀더로 교체하여 보안을 유지하면서도 AI의 도움을 받을 수 있게 합니다.

핵심 포인트

  • 기업의 지적 재산 보호와 개발 생산성 사이의 딜레마 해결
  • Kiri: AI 도구와 LLM 사이의 오픈 소스 온프레미스 프록시
  • 민감한 코드(알고리즘, API, 스키마 등)를 로컬에서 비식별화
  • 정화된 요청을 통해 보안 리스크 없이 AI 어시스턴트 활용 가능

AI 코딩 어시스턴트(AI coding assistants)들은 믿기 힘들 정도로 발전하고 있습니다. Claude Code, Cursor, Windsurf와 같은 도구들은 생소한 코드를 설명하고, 거대한 코드베이스(codebases)를 탐색하며, 보일러플레이트(boilerplate)를 생성하고, 종종 전통적인 웹 검색보다 더 빠르게 문제를 해결할 수 있습니다.

하지만 많은 엔지니어링 팀들이 남몰래 겪고 있는 문제가 하나 있습니다: 어떻게 하면 독점적인 소스 코드(proprietary source code)를 노출하지 않고 클라우드 기반 AI 도구를 사용할 수 있을까?

중요한 모듈의 리팩터링(refactor)을 돕기 위해 AI 어시스턴트에게 질문하는 상황을 상상해 보십시오. 유용한 답변을 얻으려면 컨텍스트(context)를 제공해야 합니다. 그 컨텍스트에는 다음과 같은 내용이 포함될 수 있습니다:

  • 독점 알고리즘 (Proprietary algorithms)
  • 고객 특화 워크플로우 (Customer-specific workflows)
  • 내부 API (Internal APIs)
  • 데이터베이스 스키마 (Database schemas)
  • 수년간 축적된 비즈니스 규칙 (Business rules)
  • 시스템 작동 방식을 드러내는 명명 규칙 (Naming conventions)

많은 조직에게 이러한 리스크는 논의가 시작되기도 전에 중단될 만큼 충분한 이유가 됩니다. 많은 경우, AI 제공업체가 엔터프라이즈급 보장(enterprise-grade guarantees), 프라이빗 배포(private deployments) 또는 강력한 개인정보 보호 약속을 제공하더라도 이러한 우려는 여전히 존재합니다.

대규모 독점 코드베이스를 다루는 소프트웨어 매니저로서, 저는 계속해서 같은 딜레마에 직면했습니다:

  • 개발자들은 AI 지원 개발을 통한 생산성 향상을 원했습니다.
  • 회사는 지적 재산(intellectual property)을 보호하기를 원했습니다.

두 입장 모두 완벽하게 타당했습니다. 과제는 절충안을 찾는 것이었습니다.

민감한 코드가 네트워크를 떠나지 않는다면 어떨까?

AI 코딩 어시스턴트의 허용 여부를 묻는 대신, 저는 다른 질문을 던지기 시작했습니다: «코드의 민감한 부분이 애초에 네트워크를 떠나지 않는다면 어떨까?» 만약 모델이 코드의 정제된(sanitized) 버전만 본다면, 개발자들이 여전히 AI의 도움을 받을 수 있지 않을까?

그 아이디어가 결국 Kiri가 되었습니다.

핵심 아이디어

Kiri는 AI 코딩 도구와 클라우드 LLM (Large Language Model) 제공업체 사이에 위치하는 오픈 소스 온프레미스 (on-premises) 프록시입니다.

요청이 모델에 도달하기 전, Kiri는 이를 로컬에서 가로채어 독점적인 구현 세부 사항을 식별하고 민감한 정보를 플레이스홀더 (placeholder)로 교체합니다. 이렇게 정화된 요청이 AI 제공업체로 전달되면, 그 응답이 개발자에게 반환됩니다.

예를 들어, 가공되지 않은 비즈니스 로직을 보내는 대신:

// Kiri 사용 전
 public static decimal CalculateDiscount(Order order) {
      var tier = _tiers[order.Customer.Tier];
...

외부 모델은 다음과 같이 받게 됩니다:

// Kiri 사용 후
  public static decimal CalculateDiscount(Order order) {
      // [PROTECTED: implementation is confidential]
...

문제의 전체적인 구조는 이해 가능한 상태로 유지되지만, 구현 세부 사항은 노출되지 않습니다. 목표는 완벽한 비밀 유지가 아닙니다. 목표는 AI 어시스턴트가 유용하게 작동할 수 있을 만큼의 충분한 컨텍스트 (context)를 보존하면서, 조직 외부로 유출되는 민감한 정보의 양을 줄이는 것입니다.

어려운 부분은 프록시를 구축하는 것이 아니었습니다

가장 흥미로운 도전 과제는 완전히 다른 것이었습니다: AI가 유용성을 잃기 전까지 얼마나 많은 정보를 제거할 수 있는가?

너무 적게 제거하면 보호해야 할 정보가 노출될 위험이 있습니다. 너무 많이 제거하면 모델이 더 이상 문제를 이해할 수 없게 됩니다. 이 균형을 찾는 과정은 일련의 실험 과정이 되었습니다.

어떤 시나리오에서는 공격적인 편집 (redaction) 후에도 모델이 놀라울 정도로 유용하게 유지되었습니다. 반면 어떤 경우에는 핵심 정보를 제거하자마자 답변의 품질이 빠르게 저하되었습니다. 제가 배운 것은 프라이버시가 "모두 보내기"와 "아무것도 보내지 않기" 사이의 이분법적인 선택이 아니라는 점입니다. 그 사이에는 아직 탐구되지 않은 넓은 설계 공간 (design space)이 존재합니다.

왜 그냥 엔터프라이즈 AI를 사용하지 않나요?

이는 합리적인 질문입니다. 많은 AI 제공업체가 이미 엔터프라이즈 계약, 프라이빗 배포 (private deployments), 그리고 데이터 보존 보장 (data-retention guarantees)을 제공하고 있습니다. 어떤 조직들에게는 아마 그것만으로도 충분할 것입니다.

다른 조직들에게는 법적 요구 사항, 내부 정책, 고객 계약, 규제 관련 우려 또는 단순한 위험 회피 성향으로 인해 여전히 외부로 코드를 공유하는 것이 어려울 수 있습니다. Kiri는 기업용 솔루션 (enterprise offerings)을 대체하기 위해 만들어진 것이 아닙니다. 이는 또 다른 선택지를 탐색하려는 시도입니다.

추측 대신 측정하기

이 프로젝트의 예상치 못한 결과 중 하나는 벤치마크 (benchmark) 그 자체였습니다. 저는 AI 개인정보 보호 (privacy)에 관한 논의가 종종 이론적으로만 흐른다는 사실을 빠르게 깨달았습니다. 모두가 의견을 가지고 있지만, 그 트레이드오프 (trade-off)를 정량화할 수 있는 방법을 가진 팀은 매우 드뭅니다.

제가 처음부터 원했던 것 중 하나는 끝없는 논쟁 대신 그 영향을 측정할 수 있는 방법이었습니다. 대부분의 개인정보 보호 도구들은 주장 (claims)을 하지만, Kiri는 측정할 수 있게 해줍니다.

이 프로젝트에는 사용자의 자체 저장소 (repository)에서 직접 실행할 수 있는 벤치마크 도구가 포함되어 있습니다. 저의 가정을 신뢰하는 대신, 여러분의 코드베이스 (codebase)에서 이 방식을 테스트하고 어떤 결과가 발생하는지 직접 확인할 수 있습니다.

벤치마크는 다음과 같은 질문에 답하는 데 도움을 줍니다:

  • 얼마나 많은 코드가 비식별화 (redacted)되고 있는가?
  • 어떤 식별자 (identifiers)가 여전히 노출되어 있는가?
  • 비식별화 전략을 얼마나 공격적으로 가져가야 하는가?
  • 구조적 문맥 (structural context)이 얼마나 여전히 보존되는가?

저는 이것이 AI 개인정보 보호에 관한 이론적인 논의보다 훨씬 더 유용하다는 것을 알게 되었습니다. 왜냐하면 모든 코드베이스는 서로 다르기 때문입니다. 한 프로젝트에서 잘 작동하는 전략이 다른 프로젝트에는 완전히 부적절할 수도 있습니다.

왜 오픈 소스인가?

저는 많은 팀이 동일한 딜레마에 직면해 있을 것이라고 생각하여 Kiri를 오픈 소스 (open-source) 프로젝트로 공개했습니다. 개발자들은 AI 지원 개발 (AI-assisted development)의 이점을 원하지만, 보안, 법무 및 엔지니어링 리더십은 지적 재산권 (intellectual property)에 대한 더 강력한 보장을 원합니다.

이러한 목표들은 종종 상호 배타적인 것으로 제시되지만, 저는 반드시 그렇다고 생각하지 않습니다.

커뮤니티를 위한 질문

다른 조직들은 오늘날 이 문제에 어떻게 접근하고 있는지 진심으로 궁금합니다:

  • AI 코딩 어시스턴트 (AI coding assistants) 사용이 완전히 금지 (banned) 되어 있나요?
  • 엔터프라이즈 계약 (enterprise agreements) 에 의존하고 계신가요?
  • 로컬 모델 (local models) 을 실행하고 계신가요?
  • 내부 게이트웨이 (internal gateways) 를 구축하고 계신가요?
  • 완전히 다른 접근 방식 (completely different approach) 을 취하고 계신가요?

여러분의 사례 중 무엇이 효과적이었는지, 그리고 무엇이 효과적이지 않았는지 꼭 듣고 싶습니다.

직접 시도해 보세요

궁금하시다면 제 말만 믿지 마시고 직접 확인해 보세요. 여러분의 리포지토리 (repository)를 대상으로 벤치마크 (benchmark)를 실행하여, AI가 문맥 (context)을 놓치기 시작하기 전에 얼마나 많은 정보를 제거할 수 있는지 확인해 보시기 바랍니다. 결과는 저를 여러 번 놀라게 했습니다.

Kiri는 MIT 라이선스 하에 완전한 오픈 소스 (open source)이며, 문서, 예제 및 리포지토리 벤치마크 도구를 포함하고 있습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0