"도움이 되는 수준"과 "너무 많은 정보" 사이의 경계

AI 코딩 도구는 의도치 않게 선을 넘는 것을 매우 쉽게 만듭니다. 버그 때문에 막혀서 파일을 복사해 채팅창에 붙여넣고 나서야, 그 안에 무엇이 들어있었는지 깨닫게 됩니다. 명명 규칙 (naming conventions), 비즈니스 규칙 (business rules), 출시 계획 (launch plans) 같은 것들 말이죠.

저는 보안 정책을 쓰려는 것이 아닙니다. 변호사도 아니고, 국가 차원의 위협 모델링 (threat-modelling)을 하는 것도 아닙니다. 제가 가진 것은 제 업무를 위한 실질적인 경계입니다. 즉, 개인정보 보호나 데이터 보관에 대한 일반적인 안심 문구들이 있더라도, AI 도구에 절대로 붙여넣지 않을 코드에 대한 경계입니다.

패턴은 간단합니다. 코드가 _클라이언트가 어떻게 운영되는지_에 대해 더 많이 말해줄수록, 저는 그 코드가 제 에디터를 벗어나는 것을 원치 않습니다.

법적 소유권보다 운영상의 소유권이 더 중요하다

어떤 코드는 명백히 민감합니다. API 키, 비밀번호, 토큰 같은 것들이죠. 이는 기본 중의 기본입니다. 더 흥미로운 카테고리는 법적으로 소유권이 있는 것은 아니지만, 운영적인 관점에서 소유권이 있는 코드입니다.

저희의 내부 NAS 마운트된 에셋 파이프라인 (asset pipeline)에서 임포트 (import)하는 모든 것은 AI 도구에 넣지 않습니다. 경로, 명명 규칙 (naming conventions), 그리고 누락된 InDesign 패키지에 대한 폴백 로직 (fallback logic)은 모두 Ideebv에서 클라이언트 작업을 어떻게 구조화하는지를 드러냅니다. 심지어 다음과 같은 단 한 줄의 코드만으로도:

import { processClientPackage } from '@ideebv/nas-utils'

경쟁사에게 우리의 워크플로 (workflow)에 대해 제가 공유하고 싶은 것보다 더 많은 정보를 알려주게 됩니다. 그들이 구현 방식을 알 수는 없겠지만, 우리가 패키징을 어떻게 생각하는지, 어떤 부분을 자동화했는지, 그리고 내부적으로 이름을 어떻게 짓는지에 대해서는 알게 됩니다.

이 코드는 어떤 특별한 법령에 의해 보호되는 것이 아닙니다. 그저 다른 사람이 알 필요가 없는 일일 뿐입니다.

비즈니스를 노출하는 비즈니스 로직

제가 AI 도구에 멀리하는 또 다른 카테고리는 메인 리포지토리 (repository) 외부에 존재하는 클라이언트 특화 비즈니스 로직 (business logic)입니다.

한 가지 예로, 그들의 ERP와 연결된 커스텀 할인 매트릭스 (discount matrix)를 사용하는 클라이언트를 위한 가격 책정 모듈이 있습니다. 매트릭스 자체는 암호학적으로 비밀인 것은 아니지만, 상업적으로 민감합니다. 그것은 다음과 같은 것들을 인코딩합니다:

• 지역별로 얼마나 공격적으로 할인을 제공하는지
• 어떤 고객 유형이 가장 높은 마진 (Margin)을 얻는지
• 마진을 포기하면서까지 판매량을 늘리려는 지점은 어디인지

"정제된 (sanitized)" 버전을 AI 어시스턴트에 붙여넣는 것조차 그들의 가격 계층 (pricing tiers) 구조, 마진 구조, 그리고 지역별 할인 전략을 노출하게 됩니다. 일반적인 calculateTotal 함수를 리팩터링 (refactor)하는 데 모델은 그 정보가 전혀 필요하지 않습니다.

만약 알고리즘에 대한 도움이 필요하다면, 다음과 같이 내용을 덜어낼 수 있습니다:

function calculateTotal({ items, discounts }) {
  // ...여기에 순수 수학 로직
}

고객 이름도, 제품 코드도, 내장된 비즈니스 규칙 (business rules)도 없습니다. AI는 상업적 전략이 아닌 루프 (loops)와 조건문 (conditionals)을 보게 됩니다.

인증 코드는 "단순한 버그"가 아닙니다

인증 (Authentication) 및 세션 처리 (session handling)는 또 다른 함정입니다. 공격자의 관점에서 읽어보기 전까지는 일반적인 배관 작업 (plumbing)처럼 보입니다.

저는 리다이렉트 루프 (redirect loop)를 디버깅하기 위해 Next.js 미들웨어 (middleware) 스니펫을 AI 도구에 붙여넣고 싶은 유혹을 느꼈습니다. 그러다 그 파일에 하드코딩된 폴백 (fallback) 쿠키 이름, 세션 비밀값 회전 (session secret rotation) 패턴, 그리고 우리가 전환 중인 레거시 (legacy) SSO 제공업체에 대한 주석이 포함되어 있다는 사실을 알아차렸습니다.

그것은 코딩 문제가 아니라, 보안 감사 (security audit)가 발생하기를 기다리고 있는 상태입니다. 설령 그 스니펫이 절대 유출되지 않더라도, 우리의 세션이 어떻게 작동하는지, 무엇을 폐기 (deprecating)하고 있는지, 그리고 취약점이 어디에 있을 수 있는지를 깔끔하게 나열한 기록이 어딘가에 남는 것을 원치 않습니다.

저의 해결책은 지루하지만 효과적입니다. AI 디버깅을 위해 로직을 익명화한 버전이 담긴 "안전한 샌드박스 (safe sandbox)" 파일을 유지하는 것입니다. 패턴은 동일하지만 세부 사항은 다릅니다. 쿠키 이름은 SESSION_COOKIE가 되고, 제공업체는 PRIMARY_SSO가 되며, 비밀값은 완전히 제거됩니다. 저는 프로덕션 (production) 코드에서가 아니라, 이 안전한 파일에서 AI 도구로 복사합니다.

라우트 파일에 숨겨진 로드맵

미발표 제품과 관련된 코드는 또 다른 절대 금지 사항입니다.

우리는 새로운 복합 소재 라인을 공개적으로 발표하지 않은 한 소재 기업을 위한 포털을 구축하고 있습니다. 구성 요소의 이름, 라우트 구조(route structure), 그리고 피처 플래그(feature flags)는 그들의 제품 로드맵과 직접적으로 연결됩니다.

featureFlags 객체처럼 무해해 보이는 것조차 다음과 같은 정보를 노출할 수 있습니다:

• 어떤 기능이 베타(beta), 알파(alpha), 또는 내부 전용(internal-only)인지
• 어떤 시장이나 고객 세그먼트를 우선적으로 고려하고 있는지
• 출시(rollout)를 어떤 단계로 진행할 계획인지

저는 타입(type) 관련 문제를 물어보려고 그 객체를 AI 채팅창에 거의 붙여넣을 뻔한 제 자신을 발견했습니다. 모델이 이를 오용하지는 않겠지만, 대화 내용은 저장될 것이고, 제 클라이언트의 출시 일정은 생성된 코드를 읽는 누구에게나 읽힐 수 있는 상태가 될 것입니다.

다시 말하지만, 모델이 저를 돕기 위해 이 모든 것을 알 필요는 없습니다. 만약 타이핑(typing) 문제가 있다면, 실제 플래그를 flagA, flagB, flagC로 대체할 수 있습니다. 라우팅(routing)을 디버깅 중이라면, 이를 /page-a와 /page-b로 축소할 수 있습니다. 로직은 유지하되, 로드맵은 제거하는 것입니다.

정책 문서 대신 간단한 냄새 테스트 (Smell Test)

이 모든 것이 정책처럼 들리겠지만, 저는 공식적인 문서를 관리하지 않습니다. 저에게 경계선은 '냄새 테스트(smell test)'입니다.

만약 제가 멈춰 서서 "이걸 붙여넣어도 될까?"라고 자문해야 한다면, 답은 '아니오'입니다.

저는 스스로에게 정직하기 위해 간단한 규칙을 사용합니다: 일반적인 알고리즘은 괜찮지만, 도메인 로직(domain logic)은 안 됩니다.

실제로 이는 다음과 같은 의미입니다:

• 커스텀 useDebounce 훅(hook)은 기꺼이 붙여넣을 것입니다.
• 특정 클라이언트의 인벤토리 API 업데이트를 디바운스(debounce)하는 훅은 붙여넣지 않을 것입니다.

첫 번째는 도구입니다. 두 번째는 지문(fingerprint)입니다. 하나는 블로그 포스트나 라이브러리에 존재할 수 있지만, 다른 하나는 실제 비즈니스가 데이터를 어떻게 이동시키는지 설명합니다.

이것이 제가 파일 전체를 붙여넣는 것을 피하는 이유이기도 합니다. 컨텍스트(context)를 더 많이 포함할수록, 운영상 기밀인 것들—경로, 주석, 아직 출시되지 않은 기능 이름 등—을 실수로 끌어들이기가 더 쉬워지기 때문입니다.

판단력을 외주 주지 않고 AI 사용하기

AI 도구는 리팩터링(refactoring), 설명, 그리고 변형 생성에 능숙합니다. 하지만 무엇을 보여주는 것이 안전한지 결정하는 데는 능숙하지 않습니다. 그 부분은 여전히 당신의 몫입니다.

제가 사용하는 경계선은 의도적으로 매우 단순합니다(low-tech). 다이어그램도, 프레임워크(frameworks)도, 신호등도 필요 없습니다. 그저 몇 가지 질문만 던집니다:

• 이 코드가 클라이언트가 업무를 구조화하는 방식, 가격 책정 방식, 인증(auth), 또는 로드맵(roadmap)을 드러내는가?
• 경쟁자가 이 코드 조각을 통해 우리의 프로세스나 클라이언트의 비즈니스에 대해 유용한 정보를 얻을 수 있는가?

만약 대답이 '예'라면, 저는 해당 내용을 프롬프트(prompt)에서 제외하고 대신 정보를 삭제한(scrubbed) 일반적인 버전을 만듭니다. 몇 분의 시간이 더 걸리겠지만, 클라이언트의 내부 로직이 왜 타인의 학습 데이터(training data)나 로그(logs)에 들어가게 되었는지 클라이언트에게 설명하는 것보다는 훨씬 저렴한 비용이 듭니다.

AI는 코드를 작성하는 데 도움을 줄 수 있습니다. 하지만 그 이면에 있는 비즈니스까지 볼 필요는 없습니다.