How Snyk Turned an Internal Support Agent into a Customer Feature

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Snyk는 사용자 권한 통제와 LangSmith 평가를 바탕으로 내부 지원 도구였던 Snyk Assist를 고객용 제품 기능으로 확장했으며, 2026년 4월 고객 공개 이후 60,000건 이상의 질의를 처리하고 세션의 85% 이상을 지원 티켓 없이 해결했다고 보고했다.

📌 핵심 요약

• Snyk Assist는 문서, 지원 콘텐츠, 계정 데이터에 흩어진 정보를 자연어로 찾고 고객 대신 작업을 수행하는 에이전트다. 열린 이슈 조회, 패키지의 알려진 취약점 확인, 지원 케이스 생성, 기능 요청 등록을 지원한다.
• 약 1년간 내부 지원팀 도구로 운영한 뒤 2026년 4월 지원 포털에 공개했고, 2026년 9월 1일 핵심 Snyk 제품의 모든 페이지 상단에 배치해 모든 유료 고객이 이용할 수 있게 했다.
• 단일 LangGraph 런타임이 Slack 앱, 웹 앱, 직접 API 접근을 지원한다. 요청 시 로그인 사용자의 실제 권한에 맞춰 도구를 연결하며, 에이전트가 사용자가 이미 볼 수 있는 데이터에만 접근하도록 설계했다.
• LangSmith로 모든 모델 호출, 도구 호출, 의사결정 지점을 추적한다. 오프라인 평가와 레드팀 테스트를 모든 풀 리퀘스트에서 실행하고 합의된 기준 미달 시 출시를 차단하며, 운영 환경에서는 모든 실행을 평가해 지원 티켓 없이 해결되는 비율과 질문 유형을 측정한다.
• 2026년 4월 고객 공개 이후 500개 이상의 고객 계정에서 60,000건 이상의 질의를 처리했다. 세션의 85% 이상을 지원 티켓 없이 해결해 지원팀의 수백 시간을 절약했으며, 250건 이상의 케이스를 자동 감지해 적절한 팀으로 에스컬레이션했다고 밝혔다.

🧩 주요 포인트

1. 내부 지원팀에서 지원 포털, 핵심 Snyk 제품으로 단계적으로 공개 범위를 넓힘 → 초기 오류와 위험한 기능을 내부에서 검증하고 실제 사용 기록을 평가 데이터로 축적했다.
2. 단일 LangGraph 런타임, 사용자별 도구 등록, 미들웨어, PostgreSQL 체크포인터를 결합함 → 여러 접점에서 권한 통제와 대화 상태를 유지하면서 수정·확장 작업을 한곳에 집중했다.
3. LangSmith 추적을 출시 전 평가와 운영 중 평가에 연결함 → 응답 품질 퇴행을 차단하고, 실패 기록을 새 평가 데이터로 전환하며, 고객의 혼란 지점을 문서 개선에 활용했다.

🧠 상세 정리

1. 흩어진 정보와 늘어나는 지원 수요

Snyk는 코드, 오픈소스 의존성, 컨테이너, 클라우드 구성의 취약점을 찾아 수정하는 AI 보안 플랫폼으로, 개발자가 사용하는 IDE, 풀 리퀘스트, 파이프라인 안에서 작동한다. 고객은 실제 작업 도중 취약점, 계정 맥락, 지원 문제, 제품 동작에 관한 구체적인 답변을 필요로 했지만, 관련 정보는 제품 문서와 지원 문서, 릴리스 노트, 학습 콘텐츠, 계정 데이터에 분산돼 있었다. 적절한 답을 찾으려면 여러 페이지를 읽거나 티켓을 제출하고 기다려야 했고, 지원팀은 몇 주마다 수천 건의 케이스를 읽어 제품·심각도·담당자별로 분류하고 전달해야 했다. Snyk Assist는 이러한 탐색과 지원 부담을 줄이기 위해 LangChain과 LangGraph로 구축한 대화형 에이전트이며, 관측에는 LangSmith를 사용한다. 단순한 정보 검색을 넘어 열린 이슈 조회, 패키지의 알려진 취약점 확인, 대화 중 지원 케이스 생성, 아직 지원하지 않는 작업에 대한 기능 요청 등록까지 수행할 수 있다.

2. 신뢰 검증을 거친 단계적 고객 공개

보안 소프트웨어를 만드는 Snyk는 에이전트에도 기존 제품과 같은 수준의 기준을 적용해야 한다고 봤으며, 정확한 답변, 필요한 요청의 거부, 사용자에게 허용되지 않은 정보의 비노출을 입증해야 했다. 이를 위해 제품에 곧바로 공개하지 않고 약 1년간 Snyk 직원만 사용하는 지원 케이스 분류 도구와 가상 에이전트로 운영해, 초기 오류의 영향을 내부에 한정하고 위험도가 높은 기능도 시험했다. 내부 사용은 오프라인 테스트에서 드러나지 않은 예외 상황을 발견하게 했고, 피드백을 릴리스 주기가 아닌 시간 단위로 반영할 수 있게 했으며, 초기 세션의 추적 기록은 평가 데이터에 포함됐다. 2026년 4월 지원 포털에 공개했을 때는 사용자 이름과 계정 맥락을 이해하고, 로그인 시 상태 점검을 수행하며, 사람이 개입할 때까지 기다리지 않고 언제든 티켓을 생성할 수 있었다. 2026년 9월 1일에는 새 내비게이션과 함께 핵심 Snyk 제품의 모든 페이지 상단 패널로 들어가 모든 유료 고객에게 제공됐으며, 각 단계에서 에이전트 런타임은 유지하고 사용자가 접하는 화면만 바꿨다.

3. 여러 접점을 지원하는 하나의 런타임

Snyk Assist는 하나의 LangGraph 에이전트를 Slack 앱, 웹 앱, 직접 API 접근이라는 여러 접점 뒤에 두고, 모든 접근을 동일한 보안 프레임워크로 연결한다. 소규모 팀이었던 Snyk는 버그 수정, 기능 출시, 사고 대응을 한곳에서 수행하기 위해 단일 런타임을 선택했고, 이 단순성이 아키텍처를 분산시키지 않으면서 빠르게 확장하는 데 도움이 됐다고 설명한다. LangChain을 선택한 이유로는 큰 커뮤니티, 풍부한 생태계, 에이전트 구축의 사실상 표준으로 자리 잡고 있다는 팀의 판단을 제시한다. 또한 에이전트 추상화가 오케스트레이션, 도구 호출, 스트리밍, 상태 처리를 제공해 팀이 직접 기반 구조를 다시 만드는 대신 기능과 효과에 집중할 수 있었다고 밝혔다. 이러한 구성의 핵심은 고객이 접근하는 경로가 늘어나더라도 각각 별도의 에이전트를 만드는 대신 공통 실행 기반에서 기능과 운영을 관리하는 데 있다.

4. 사용자별 도구 권한과 미들웨어

운영 환경에서 실용성을 확보한 첫 번째 설계는 도구를 타입이 지정된 함수로 만들고, 로그인한 사용자의 실제 권한에 따라 요청 시점에 등록하는 방식이다. 이 구조에서는 에이전트가 연결받는 도구 자체가 사용자 권한에 의해 제한되므로, 사용자가 원래 볼 수 있었던 데이터에만 접근하도록 설계된다. 대부분의 도구는 별도 마이크로서비스로 구성돼 있어 독립적으로 확장할 수 있고, 에이전트 루프를 변경하지 않고도 기능을 추가할 수 있다. 두 번째 설계는 맥락 관리, 가드레일, 모델 폴백을 루프 안에 직접 엮는 대신 LangChain 미들웨어가 제공하는 정해진 생명주기 지점에 연결하는 것이다. 팀은 이 방식 덕분에 동작을 추가하거나 순서를 바꿀 때 전체 코드를 다시 작성하지 않고 목록을 한 줄 수정하면 된다고 설명하며, 권한 경계와 기능 확장을 공통 런타임 안에서 함께 관리했다.

5. 대화 상태와 내부 플랫폼으로서의 에이전트

세 번째 설계는 대화 상태를 체크포인터에 맡기는 것으로, 대화 이력을 PostgreSQL에 저장하고 세션을 기준으로 구분한다. 원문은 이 구성이 여러 차례 이어지는 대화의 기억, 여러 파드에 걸친 확장, 중단된 대화의 재개를 별도의 추가 연결 작업 없이 지원한다고 설명한다. 네 번째 설계는 에이전트 루프 자체를 내부 플랫폼으로 취급하는 것으로, 모델·도구·프롬프트·미들웨어·체크포인터를 조합하는 공통 팩토리가 컴파일된 그래프를 반환한다. 각 팀은 이 공통 구조에 자신에게 필요한 설정을 제공하며, 대부분의 새 워크플로는 새로운 아키텍처를 구축하는 대신 설정을 바꾸는 방식으로 구현한다. 이 두 결정은 대화가 지속되는 데 필요한 상태 처리와 여러 팀의 기능 확장을 공통 기반에 모으는 역할을 하며, 단일 런타임을 유지하면서도 서로 다른 사용 사례를 수용하려는 운영 방향과 연결된다.

6. 오프라인 평가와 출시 차단 기준

Snyk는 개발 첫날부터 모든 모델 호출, 도구 호출, 의사결정 지점을 LangSmith로 추적했고, 이 기록을 변경 사항의 출시 여부를 판단하는 기반으로 삼았다. 오프라인 평가의 첫 축은 알려진 좋은 답변이 있는 실제 질문 집합을 실행하고 별도의 모델로 채점해, 프롬프트나 모델 변경 때문에 응답 품질이 나빠졌는지 빠르게 확인하는 것이다. 두 번째 축은 에이전트가 지시를 무시하거나 비밀 정보를 넘기도록 속이려는 시도를 포함하는 자동화된 레드팀 평가다. 모든 풀 리퀘스트의 CI는 실제 에이전트를 이러한 평가 묶음에 실행하고, 저장소에 기록한 합의된 임계값을 충족하지 못하면 통과를 차단한다. AI 엔지니어 Bailey Millns는 어려운 일이 모델의 능력을 확인하는 데 그치지 않고 에이전트가 실제로 작동함을 입증하는 데 있다고 강조하며, 모든 변경이 LangSmith 평가 기준을 넘어야 출시된다고 설명했다.

7. 운영 평가에서 개선 데이터로 이어지는 순환

온라인 평가에서는 예약된 작업이 운영 환경의 모든 실행을 채점하며, 질문이 Snyk에 관한 것이었는지와 응답이 그 질문에 답했는지를 확인한다. Snyk는 이 점수를 통해 지원 티켓 없이 해결되는 비율을 추정치가 아닌 측정값으로 파악한다고 설명한다. 각 질문은 제품 영역, 주제, 언어 생태계, 오류 유형별로도 분류돼, 제품 관리자가 고객이 어떤 부분에서 어려움을 겪는지 현재 상황을 볼 수 있게 한다. 문제가 있는 추적 기록을 발견하면 코딩 에이전트에서 LangSmith MCP 서버를 사용해 IDE를 벗어나지 않고 조사하고 평가 데이터셋으로 전환할 수 있다. 이 과정은 실제 질문으로 변경 사항을 검증하고, 출시 전에 품질 퇴행을 잡으며, 실패 사례를 다음 평가에 반영하는 피드백 순환을 만든다. 대화의 채점과 분류는 응답 개선뿐 아니라 제품에서 혼란을 일으키는 부분을 찾아 문서를 개선하는 데도 사용된다.

8. 보고된 성과와 제품 안으로의 확장

Snyk가 제시한 성과는 2026년 4월 고객 공개 이후의 수치로, 500개 이상의 고객 계정에서 60,000건 이상의 질의를 처리했다는 것이다. 또한 세션의 85% 이상을 지원 티켓 없이 해결해 지원팀의 수백 시간을 절약했고, 250건 이상의 케이스를 에이전트가 자동 감지해 적절한 팀으로 곧바로 에스컬레이션했다고 보고했다. 따라서 이 사례에서 에이전트의 역할은 답변을 제공해 티켓 생성을 줄이는 것과, 사람의 처리가 필요한 케이스를 찾아 전달하는 것을 모두 포함한다. 원문은 모든 대화를 평가하고 분류하는 방식이 고객의 혼란 지점을 드러내 문서 개선에도 도움이 된다고 설명하지만, 절약 시간의 상세 산식이나 성과 수치의 세부 분모는 제시하지 않는다. 9월부터는 고객이 이미 작업하고 있는 제품의 모든 페이지에서 Snyk Assist를 사용할 수 있게 됐으며, Snyk는 이를 고객 경험의 유용한 일부로 만들고자 한다고 밝혔다.

🧾 핵심 주장 / 시사점

• 내부 사용을 먼저 거친 과정은 공개 범위를 제한하는 동시에 실제 예외 상황을 평가 데이터로 축적하는 수단이었다. 단계적 공개와 평가 체계 구축이 서로 연결돼 있었다.
• 단일 런타임의 운영상 이점은 여러 화면을 지원하는 데 그치지 않는다. 사용자별 권한, 대화 상태, 기능 확장을 공통 구조에서 관리해 소규모 팀의 수정과 대응을 한곳에 집중했다.
• Snyk Assist는 지원 티켓 없이 해결하는 흐름과 적절한 팀으로 에스컬레이션하는 흐름을 함께 제공한다. 대화 평가와 분류는 지원 성과 측정뿐 아니라 문서 개선에도 활용됐다.

✅ 액션 아이템

• Snyk Assist의 단계적 공개 방식을 참고해 내부 지원팀 검증 결과와 고객 공개 범위의 연계를 검토한다.
• 단일 LangGraph 런타임에서 사용자별 도구 등록이 실제 권한 범위에 맞게 적용되는지 확인한다.
• LangSmith 평가에서 발견한 실패 기록을 새 평가 데이터로 전환하고, 고객의 혼란 지점을 문서 개선에 반영한다.

❓ 열린 질문

• Snyk Assist의 내부 지원팀 검증에서 지원 포털과 핵심 Snyk 제품 공개로 넘어갈 때 적용한 구체적인 통과 기준은 무엇이었나?
• LangSmith 오프라인 평가와 레드팀 테스트에서 출시를 차단하는 합의된 임계값은 어떻게 설정했나?
• 세션의 85% 이상을 지원 티켓 없이 해결했다는 수치는 어떤 세션 범위와 판정 기준으로 산출했나?