▲ 69 · 51 comments on source · Hacker News · shailendraht · 2 months ago
Launch HN: HyperProbe (YC S26) – 프로덕션에서 읽기 전용 디버깅을 수행하는 에이전트
안녕하세요 HN, Shailendra와 Karan입니다. 저희는 코딩 에이전트가 프로덕션에서 실시간으로 이슈를 디버깅할 수 있는 빠르고 안전한 방법을 만들고 있습니다. 프로덕션이 터졌을 때, Cursor, Claude 등이 실행 중인 코드에 안전하게 가상 브레이크포인트나 프로브를 배치하고, 로그에는 없는 정확한 변수 값을 추출할 수 있게 해줍니다. 이 모든 것은 근본 원인을 찾을 때까지 로그와 트레이스를 뒤지거나 console.log나 print 문을 넣어 재배포해야 했던 엔지니어들의 시간과 노력을 절약해줍니다. 이를 설명하는 영상 링크입니다: https://www.youtube.com/watch?v=ivV7I--ta5c 이제 대부분의 코드를 에이전트가 작성합니다. 이는 엔지니어가 AI가 작성한 코드를 디버깅하는 데 필요한 유용한 컨텍스트를 줄여주는데, AI가 같은 코드에 추가한 제한적인 텔레메트리로는 도움이 되지 않는 문제입니다. 그래서 프로덕션에서 뭔가 터지면 엔지니어의 첫 본능은 로그를 열거나 에이전트에게 로그를 던져주는 것입니다. 하지만 찾고 있는 라인이 거기에 없다면, 에이전트는 존재하지 않는 데이터를 기반으로 근본 원인을 추측하기 시작하고, 결국 로그를 추가하고 재배포해야 합니다. 기존 데이터로 에이전트가 분석-추론 루프를 도는 것은 결코 저렴하지 않으며, 많은 토큰을 소모합니다. 그리고 로그 추가, 재배포 사이클은 너무 느리고 고통스러워서 엔지니어들이 온콜을 싫어하게 만듭니다. 저희 접근 방식은 에이전트가 실패의 정확한 순간과 지점에서 온디맨드로 텔레메트리를 캡처하게 하여, 로그-재배포 사이클을 없애고 더 적은 토큰을 소모하면서 가장 정확한 RCA를 얻을 수 있게 합니다. 명백한 문제는 실행 중인 서비스에서 이를 작동시키는 것입니다. 노트북에서 디버거를 일시정지하듯이 라이브 서비스를 일시정지할 수는 없습니다. 스레드를 멈추거나 호스트를 느리게 하지 않으면서 실행 중인 프로세스에서 값을 안전하게 꺼내는 것이 과제입니다. 저희는 이를 실현하고 있습니다. 이전에 저는 100명 규모 팀에서 엔지니어링을 이끌었습니다. 그 후 Karan과 저는 3년 동안 테스팅 도구인 HyperTest에 매진했습니다. HyperTest에서 저희는 OpenTelemetry를 사용해 프로덕션 트래픽을 통합 테스트로 전환했습니다. 그것 역시 프로덕션 계측이었습니다. 서비스를 망가뜨리지 않으면서 실행 중인 서비스에서 실제 런타임 상태를 끌어내는 어려운 부분들은 저희가 함께 익힌 어려운 부분들이었습니다. 다른 교훈들도 힘겹게 배웠습니다. HyperTest는 더 나은 테스트로 버그를 예방하려 했고, 도입은 매번 싸움이었습니다. 팀들이 프로덕션 불을 끄느라 바쁘다는 이유로 계약이 계속 취소되었습니다. 테스팅은 위생이었습니다. 프로덕션이 망가진 것은 불이 난 것이었습니다. 이로 인해 저희는 우선순위가 어디에 있는지 알게 되었습니다. 이것이 진정으로 자율적인 온콜 에이전트, 즉 알림을 받고 몇 분 안에 프로브하고 진단하고 수정하는 에이전트를 만들겠다는 아이디어의 씨앗이 되었습니다. 하지만 현재 작동 방식은 이렇습니다: 이미 하던 방식대로 코딩 에이전트와 대화합니다. 무엇이 잘못됐는지 알려주세요: "checkout은 200을 반환하는데 일부 사용자가 주문 실패를 겪고 있습니다. 이유를 찾아주세요." 그러면 에이전트가 로컬 코드에서 해당 라인을 찾고, MCP를 통해 저희에게 연결하고, 실행 중인 서비스의 그 라인에 프로브를 배치합니다. 프로브는 읽기 전용이며 실제 트래픽이 닿을 때까지 휴면 상태로 있습니다. 트래픽이 닿으면 그 정확한 순간에 호출 스택의 모든 프레임에서 로컬 변수를 캡처합니다. 이를 에이전트에게 전달하면, 에이전트는 실제 데이터로 진단합니다. 두 가지 구성 요소가 있습니다. 서비스 내부에서 실행되는 SDK와, 코딩 에이전트가 대화하는 MCP 서버입니다. SDK는 재배포 없이 프로브(가상 브레이크포인트, 로그 또는 메트릭) 설정을 가능하게 하는 것입니다. Node와 Python에서는 인프로세스로 연결됩니다. Java에서는 JVM 에이전트로 붙어 바이트코드 수준에서 계측합니다. 어느 쪽이든 서비스는 계속 실행되며 트래픽을 처리합니다. 아무것도 일시정지되지 않습니다. 에이전트가 어떤 라인을 보고 싶어 하면 MCP 서버를 호출하고, MCP 서버는 SDK에 그곳에 프로브를 배치하라고 지시합니다. 요청이 그 라인에 닿으면 SDK는 프로브가 요청한 것을 캡처하고, 인프로세스에서 정제한 뒤 MCP를 통해 에이전트로 스트리밍합니다. 이것은 프로덕션 내부에서 실행될 수 있으므로, 프로브는 그 변수에 들어 있는 어떤 값이든 읽을 수 있습니다. 저희는 리댁션이 인프로세스 내부에서, y
원문 게시글에서 발췌한 번역본입니다. 전문과 원문 댓글은 아래 링크에서 확인하세요.
Discussion on runchr
Loading comments…
to comment.