코딩 에이전트가 구축하는 모든 컴포넌트나 추측한 의존성은 당신의 기술 부채가 됩니다

Claude Code, Cursor, 또는 Copilot에게 의존성 (dependency)을 추가해 달라고 요청하면, 이들은 즉각적이고 자신 있게 하나를 지목합니다. 그 자신감은 학습된 회상 (training recall), 즉 특정 차단 날짜 (cutoff date)에 동결된 스크랩된 코드의 스냅샷에서 나옵니다. 따라서 에이전트는 당신의 팀이 이미 이를 위한 내부 검증된 라이브러리를 보유하고 있다는 사실을 알 수 없습니다. 방금 지목한 패키지가 6개월 전에 유지보수가 중단되었거나, 지난주에 공급망 권고 (supply-chain advisory)가 내려졌다는 사실도 알 수 없습니다. 에이전트는 어떤 상황에서든 동일한 자신감을 가지고 일단 선택합니다.

문제가 심화되는 지점은 다음과 같습니다. 잘못된 선택은 그냥 튕겨 나가지 않습니다. 그것은 당신의 코드베이스 (codebase) 안으로 직접 쓰여집니다. 직접 만든 인증 흐름 (auth flow), 버려진 패키지에 대한 의존성, 혹은 이미 보유하고 있는 것을 중복하는 두 번째 모듈 같은 것들 말입니다. 그것이 바로 **에이전트가 생성하고 당신이 물려받는 기술 부채 (tech debt)**입니다. 그리고 이는 이자가 붙는 부채입니다. 에이전트는 잘못된 선택을 바탕으로 구축을 이어가고, 문제는 하류 (downstream)에서 표면화되며, 결국 당신은 이를 해제하고 다시 작업하기 위해 토큰 (tokens), 리뷰 시간, 재작업이라는 비용을 다시 지불해야 합니다.

이것은 프롬프트 (prompt)의 문제가 아닙니다. 모델에게 "주의해 줘"라고 요청한다고 해서 해결될 수 없습니다. 모델은 **평가 (evaluation)**를 해야 할 곳에서 **회상 (recall)**을 하고 있으며, 회상은 동결되어 있기 때문입니다.

회상이 당신에게 치르게 하는 비용

에이전트가 감독 없이 의존성을 선택하는 것에 대해 불안감을 느껴야 할 몇 가지 발견 사항이 있습니다. 그리고 이 중 어느 것도 단순히 보안 문제만은 아니라는 점에 주목하십시오:

거의 5개 중 1개의 패키지가 LLM이 생성한 코드에서 언급되지만 실제로 존재하지 않습니다 — 16개 모델과 576,000개의 샘플을 조사한 결과 19.7%였으며, 오픈 소스 모델의 경우 약 22%까지 상승합니다 (Spracklen et al., USENIX Security 2025). 존재하지 않는 패키지는 잘 풀려봐야 진단하고 다시 수행해야 하는 빌드 실패(failed build)에 불과하지만, 최악의 경우 공격자가 해당 인기 있는 환각(hallucination)을 미리 등록하고 기다리고 있을 수 있습니다 (이 패턴에는 이제 _slopsquatting_이라는 이름이 붙었습니다).
AI가 생성한 코드의 **~45%**가 알려진 보안 취약점을 유발합니다 — 80개 작업에 걸친 100개 이상의 모델을 대상으로 한 Veracode의 2025년 검토 결과입니다 (보고서).
기능의 전체 카테고리 측면에서 — 가장 치명적인 것은 인증(auth) 분야로, 커스텀 흐름(custom flow)은 부채(liability)인 동시에 이제 당신이 영원히 책임져야 하는 코드가 됩니다 — 에이전트의 기본 설정은 성숙한 라이브러리를 찾는 대신 **커스텀 코드를 직접 작성(hand-roll custom code)**하는 경우가 많습니다. (이것은 저의 개인적인 발견이며, 아래에서 재현해 보겠습니다.)

각각은 회상(recall)이 실패하는 지점이며, 더 똑똑한 프롬프트(prompt)로도 고정된 스냅샷을 고칠 수는 없습니다. 해결책은 모델이 결정을 내리는 순간에 **실제적이고, 최신이며, 구조화된 사실(real, dated, structured facts)**을 모델 앞에 놓아주는 것입니다.

보안만의 문제가 아닙니다 — 잘못된 선택이 실제로 초래하는 비용

에이전트가 사실 대신 기억에 의존하여 선택할 때, 당신은 네 가지 측면에서 대가를 치르게 됩니다. 보안은 모두가 가장 먼저 언급하는 것이지만, 대부분의 팀에게는 네 가지 중 가장 작은 부분입니다.

기술 부채 (Tech debt) — 핵심 이슈. 추측된 의존성은 당신의 이름이 새겨진 미래의 마이그레이션 작업이 됩니다. 즉, 이제 당신이 직접 관리해야 하는 수제 코드(hand-rolled code), 결국에는 뜯어내야 할 버려진 패키지, 혹은 에이전트가 당신이 이미 다른 것을 표준으로 사용하고 있다는 사실을 몰라서 발생한 중복 라이브러리 등을 의미합니다. 가장 저렴한 부채는 아예 작성되지 않은 코드 한 줄입니다.
토큰 및 시간 낭비. 잘못된 선택을 되돌리는 것은 공짜가 아닙니다. 에이전트는 그 선택을 바탕으로 코드를 작성하고, 문제는 나중에 나타나며, 이를 되돌리고 다시 작업하는 과정은 더 많은 모델 호출(model calls)과 더 많은 리뷰 시간을 요구합니다. 의사 결정 시점에 사실(facts)을 확인하는 것은 이 루프가 시작되기 전에 차단합니다. (토큰 절감액을 수치로 제시하지는 않았습니다. 이는 측정된 통계가 아니라 메커니즘이기 때문입니다. 제한 사항을 참조하세요.)
라이선스 노출. "이것은 AGPL인가요? 이 라이선스가 우리의 배포 모델에서도 유효한가요?"라는 질문은 비즈니스적인 질문이며, Recall(회상)은 이에 대해 신뢰할 수 없는 답변을 내놓습니다. 라이선스 사실을 미리 파악하면 그것이 시스템의 핵심 구성 요소가 되기 전에 예기치 못한 상황을 방지할 수 있습니다.
보안. CVE, 공급망 사고(supply-chain incidents), 그리고 위에서 언급한 슬롭스쿼팅(slopsquatting) 등입니다. 이는 실재하는 위협이지만, 네 가지 축 중 하나일 뿐입니다.

이 네 가지 모두는 한 가지 공통된 원인을 공유합니다. 바로 사실(facts) 없이 의사 결정이 내려졌다는 점입니다. 이것이 바로 Starlog이 목표로 하는 지점입니다.

Starlog: 의사 결정 시점에 이름만으로 패키지를 검증하세요

Starlog는 패키지에 대한 권위 있는 사실들 — 라이선스, 유지 관리 상태, CVE, 공급망 사고 — 을 에이전트 앞에 제시합니다. 이는 날짜 정보가 포함되어 있으며, 로컬에서 계정 없이 작동합니다:

npx starloghq facts ua-parser-js

당신은 파일에 기록된 검증된 사실(예: 2021년 유지 관리자 계정 침해 사례)을 "기준 날짜(as of date)"와 함께 얻게 됩니다. 1초 미만의 속도, 설정 불필요, 네트워크 호출 없음. Starlog은 세 가지 방식으로 에이전트에 연결됩니다:

CLI (starlog facts <pkg>),
에이전트가 직접 호출하는 MCP 도구 (starlog_facts),
그리고 에이전트가 npm install / pnpm add / pip install을 실행하는 즉시 라이브러리의 사실을 드러내는 패키지 설치 훅 (package-install hook) — 패키지를 기반으로 구축하기 전에 작동합니다. 이는 차단(blocking)하는 것이 아니라 권고(advisory)하는 방식으로, 다음 움직임에 정보를 제공합니다.

단 한 번의 명령으로 이 세 가지를 Claude Code에 연결하고(Cursor, Copilot, Codex를 위한 지침 파일도 생성합니다):

npx starloghq init

이것이 홍보 문구입니다. 이 포스트의 나머지 내용은 이것이 실제로 작동하는지에 대한 것입니다. 왜냐하면 "모델에게 더 많은 컨텍스트(context)를 제공하라"는 말은 주장하기 쉽고 속이기도 쉽기 때문입니다.

에이전트의 결정이 실제로 바뀌는가?

저는 통제된 전/후 비교 실험을 수행했습니다. 대조군(Control) = 회상(recall)만으로 답변하는 새로운 에이전트. 실험군(Treatment) = 동일한 에이전트, 동일한 프롬프트, 패키지의 Starlog 사실(facts)이 제공됨. 유일한 변수는 사실(facts)입니다.

폐기해야 했던 실험

저의 첫 번째 프라이빗 패키지 테스트에서는 에이전트에게 *"정책(POLICY): 반드시 @acme/flags를 사용해야 하며, 커스텀으로 구축하지 마십시오."*라는 사실을 제공했습니다. 에이전트는 2회 중 2회 모두 @acme/flags를 사용했습니다. 깔끔한 전환이었습니다!

하지만 이는 증거로서 가치가 없습니다. "X를 반드시 사용해야 한다"라고 말하는 사실은 에이전트가 **지침을 따른다(follows instructions)**는 것만 증명할 뿐, *정보(information)*가 에이전트의 생각을 바꿨다는 것을 증명하지는 않습니다. (한 리뷰어가 이를 포착했습니다. 이는 동의어 반복의 함정(tautology trap)이며, 벤더의 데모가 조용히 의존하는 바로 그런 유형입니다.)

그래서 저는 정보 제공 전용(informational-only) 사실을 사용하여 실험을 다시 수행했습니다. 여기에는 활성화된 내부 패키지가 존재한다는 사실만 명시되어 있으며, "반드시 사용해야 한다"라거나 "커스텀으로 구축하지 마라"와 같은 지침은 없습니다. 그런 다음 에이전트가 스스로 판단하도록 두었습니다.

필요 사항	대조군 (회상만 사용)	실험군 (정보 제공 전용 사실)	Δ
기능 플래그 (feature flags)	커스텀 구축 (build custom)	`@acme/flags`	DIY → 내부 라이브러리
인증 / 세션 (auth / session)	커스텀 구축 (build custom)	`@acme/session-core`	DIY → 내부 라이브러리

사실이 없을 때, 에이전트는 두 경우 모두 **커스텀 구축(build custom)**을 선택합니다. 여기에는 직접 구현하고 검증되지 않은 인증 계층이 포함되는데, 이는 기술 부채와 보안 책임이 결합된 전형적인 사례입니다. 이를 선호하라는 지침 없이 오직 활성화된 내부 라이브러리가 존재한다는 정보만 주었을 때, 에이전트는 스스로의 판단에 따라 2회 중 2회 모두 커스텀 구축 대신 내부 라이브러리를 선택했습니다.

그것은 결코 작성되지 않을, 직접 구현한(hand-rolled) 모듈입니다. 즉, 부채가 생성되려는 바로 그 순간에 부채를 회피한 것이며, 동시에 당신의 팀이 이미 배포하고 있는 다른 것들과의 일관성도 확보한 것입니다. 그리고 이것은 모델이 구조적으로 기억할 수 없는 사례입니다. 모델은 당신의 프라이빗 @acme/* 패키지들을 본 적이 없습니다. 사실(Facts)만이 그것들이 존재한다는 것을 모델이 학습할 수 있는 유일한 방법입니다.

솔직히 말해서, 공개적인 측면은

공개 패키지(Public packages)는 이를 테스트하기에 취약한 장소입니다. 이를 숨기기보다는 솔직하게 밝히는 것이 더 유용합니다. Claude의 공개적 회상(public recall) 능력은 진정으로 뛰어나기 때문에, 대부분의 경우 사실 정보는 모델이 이미 알고 있던 내용과 단순히 일치할 뿐입니다.

패키지	대조군 (Control)	실험군 (+사실 정보)	결과
`zod`, `fastify`	채택 (ADOPT)	채택 (ADOPT)	건강한 미끼 — 잘못된 전환 없음 ✅
...

정보를 전달하는 유일하고 깨끗한 공개적 변화는 posthog-node였습니다. 이는 학습 데이터 차단 시점(training cutoff) 이후의 공급망 고정(supply-chain pin) 사례입니다. 이것이 바로 한 줄로 요약된 핵심 논지입니다. 즉, 회상이 닿을 수 없는 지점에서 사실 정보가 결정적인 역할을 한다는 것입니다. 그리고 미끼(decoys)들이 전환되지 않았으므로, 에이전트가 단순히 도구가 말하는 대로 승인(rubber-stamping)만 하는 것은 아닙니다.

설계부터 정직하게

제가 가장 자랑스럽게 생각하는 점은 node-cache를 승리로 간주하지 않았다는 것입니다. 해당 사실(

위의 전/후 비교는 실제 모델 호출에서의 _메커니즘 (mechanism)_을 확인시켜 줍니다. 통계적 근거는 **4개의 모델 벤더(model vendors)를 대상으로 한 강력한 벤치마크 (benchmark)**이며, 이는 네 가지 보상 모두를 이끄는 단 한 가지 요소인 **의사결정 정확도 (decision correctness)**를 측정합니다. 사실 관계가 가용할 때, 올바른 채택/회피 결정은 ~20%에서 ~78%로 증가했으며, **자발적 채택 (unprompted adoption)은 100%**를 기록했습니다. 에이전트들은 사실 관계에 접근할 수 있다면 매번 이를 활용합니다. 그들은 이 신호를 원하고 있지만, 기본적으로는 이를 가지고 있지 않을 뿐입니다. 모든 올바른 결정은 발생하지 않은 부채이며, 지불하지 않아도 될 재작업 비용이며, 때로는 발견된 CVE(취약점)를 잡아내는 것입니다.

정직한 한계점

현재 큐레이션된 코퍼스 (corpus)는 42개의 패키지입니다. 이는 기반일 뿐, npm의 전체는 아닙니다. 도메인 외 (out-of-domain) 조회 시에는 억지로 답을 내놓는 대신 정직하게 누락되었음을 알립니다.
전/후 비교는 방향성에 대한 단일 레포지토리 (single-rep) 확인이며, 통계적 주장은 앞서 언급한 강력한 벤치마크에 근거한 것이지 여기서 재실행된 것이 아닙니다.
토큰 및 기술 부채 (tech-debt) 절감 효과는 별도의 벤치마크가 아닌 메커니즘을 통해 논증됩니다. 잘못된 선택은 이를 되돌리기 위한 재작업 비용이 발생한다는 것이 입증되었습니다. 다만 Starlog이 그 비용을 정확히 얼마나 아껴주는지에 대한 통제된 수치는 제시하지 않았습니다. 측정된 주장은 의사결정 정확도이며, 비용 절감은 테스트된 수치가 아닌 논리적 결과로 간주하십시오.
공개 패키지는 약한 사례 (weak case)입니다 — 설계 의도상 그렇습니다. 가치는 모델이 회상할 수 없는 곳, 즉 귀하의 프라이빗 라이브러리(private libraries)와 학습 데이터 컷오프(cutoff) 이후에 발생한 모든 것에서 발휘됩니다.
설치 훅 (install hook)은 권고 (advisory) 사항입니다. 만약 엄격한 PreToolUse 승인 게이트를 원한다면, 그것은 의도적으로 기본값에서 제외된 설정입니다. 채택을 위해서는 차단(blocking)보다는 유도(nudging)가 더 효과적이기 때문입니다.

사용해보기

# 패키지 검사 — 설치 불필요, 계정 불필요
npx starloghq facts event-stream

...

BUSL-1.1 라이선스 하에 소스 공개 (무료 사용, 수정 및 셀프 호스팅 가능; 2030년에 Apache-2.0으로 전환됨). 공식 MCP 레지스트리 (official MCP Registry)에 io.github.starloghq/starlog로 등록되어 있습니다.

레포지토리, 42개 패키지 코퍼스, 그리고 전체 검증 런북 (runbook): https://github.com/starloghq/index

만약 당신이 에이전트 (agents)를 구축한다면, 얻을 수 있는 교훈은 의존성 선택 그 이상으로 일반화됩니다. 모델이 **평가 (evaluation)**를 수행해야 할 곳에서 **회상 (recall)**을 수행하고 있는 모든 곳 — 즉, 시간이 민감한 모든 것, 프라이빗한 모든 것 — 에서, (모른다고 말할 줄 아는) 날짜가 기록된 정직한 사실들로 구성된 작은 로컬 인덱스 (local index)를 사용하는 것이 모델에게 더 열심히 노력하라고 요구하는 것보다 훨씬 낫습니다. 모델이 지지 않게 되는 부채, 그리고 당신이 지불하지 않아도 되는 재작업(rework)은, 모델이 잡아낸 CVE 바로 옆에 조용히 자리 잡은 승리입니다. 모델은 본 적이 없는 것을 회상할 수 없습니다.