“다른 모델들은 우리가 문제를 해결한 후에도 계속해서 같은 부분을 반복해서 지적했습니다. 반면 Enter Pro를 사용해 보았을 때, 이 모델은 실제 원인이 무엇인지 정확히 파악해 냈습니다.”

WhyVenv는 엔지니어가 프로덕션 오류에서 근본 원인 분석까지 더 빠르게 도달할 수 있도록 돕기 위해 Quackathon을 위한 자율 장애 대응 에이전트인 Kronos를 구축했습니다.

호출기는 시작에 불과합니다

프로덕션 환경이 중단될 때, 알림을 받는 것 자체는 그리 어려운 일이 아닙니다.

Grafana는 무언가 다운되었다는 것을 알려줄 수 있습니다. 로그는 무언가 실패했다는 것을 보여줄 수 있습니다. 대시보드는 새벽 2시에 누군가를 깨울 만큼 충분히 요란하게 빨간색으로 깜빡일 수 있습니다.

하지만 그 이후부터 진짜 작업이 시작됩니다.

엔지니어는 여전히 로그를 열고, 오류를 이해하고, 코드베이스를 검색하고, 어떤 함수가 중요한지 추측하고, 문제가 시급한지 결정하고, 다음 단계로 적절한 조치가 GitHub 이슈 생성인지, 패치인지, 아니면 전체 에스컬레이션인지 파악해야 합니다.

무언가 고장 났다는 사실을 아는 것과 무엇이 고장 났는지 이해하는 것 사이의 격차야말로 장애 대응이 고통스러워지는 지점입니다.

이 지점은 Dawood Khan이 Kronos에 대한 아이디어를 얻은 곳이기도 합니다.

Dawood는 AI를 공부했지만, 대학 졸업 후 시스템 엔지니어링 분야로 자리를 옮겼습니다. 그의 관심은 추상적이지 않았습니다. 그는 프로덕션 시스템이 어떻게 실패하는지, 팀이 어떻게 대응하는지, 그리고 알림과 해결책 사이에 여전히 얼마나 많은 수동 조사 작업이 존재하는지 직접 목격했습니다.

하이드라바드에서 열린 Grafana 이벤트에서 이 문제는 더욱 명확해졌습니다. 엔지니어들은 동일한 패턴을 설명하고 있었습니다. 시스템이 다운되고, 누군가 전화를 받고, 팀이 수동으로 실패를 추적하는 익숙한 작업을 시작하는 패턴이었습니다.

Quackathon은 무언가 다른 것을 만들 수 있는 순간이 되었습니다. WhyVenv가 구축한 Kronos는 프로덕션 장애 대응을 에이전트 기반 워크플로우로 전환하여 Track 01: Software - The Sentient Workspace 챌린지에서 두각을 나타내며 Quackathon 2위를 차지했습니다.

WhyVenv가 구축한 것

WhyVenv의 프로젝트는 Quackathon의 Sentient Workspace 트랙을 위해 구축된 자율 장애 대응 에이전트인 Kronos였습니다.

아이디어는 단순하지만 야심 찼습니다.

Kronos는 프로덕션 오류를 수신하고, 로그를 읽고, 관련 코드를 검색하고, AI 모델에 가능성 있는 근본 원인을 진단하도록 요청한 다음, 다음에 수행할 작업을 결정합니다.

때로는 그것이 GitHub 이슈를 여는 것을 의미합니다.

때로는 문제의 심각성에 따라 수정을 시도하는 것을 의미합니다.

핵심은 단순히 프로덕션이 중단되었다고 엔지니어에게 알리는 것이 아닙니다. 핵심은 일반적으로 알림 이후에 수반되는 작업에서 엔지니어가 한발 앞서 나갈 수 있도록 돕는 것입니다.

인터뷰 중 Dawood의 말에 따르면, Grafana 알림 덕분에 무언가 다운된 시점을 아는 것은 쉬워졌습니다. 문제는 그 이후의 모든 과정이었습니다. 무엇이 문제를 일으켰는지, 버그가 어디에 있는지, 그리고 팀이 어떤 조치를 취해야 하는지 찾아내는 것이었습니다.

Kronos는 바로 그 중간 레이어를 자동화하기 위해 구축되었습니다.

Kronos 뒤에 숨겨진 엔지니어링 통찰력

“제가 가장 자랑스럽게 생각한 부분은 검색 단계였습니다. AST나 임베딩만 사용하는 대신 추적 로그를 기반으로 작업했습니다. 엔지니어들이 보통 문제를 찾는 방식이 바로 그렇기 때문입니다.”

Dawood가 가장 자랑스러워한 부분은 대시보드나 GitHub 연동, 혹은 AI 진단조차 아니었습니다.

그것은 바로 검색 단계였습니다.

많은 AI 코딩 시스템은 임베딩, AST 파싱 또는 광범위한 컨텍스트 로딩을 통해 코드베이스를 이해하려고 시도합니다. Kronos는 더 엔지니어 친화적인 경로를 택했습니다. 추적 로그에서 시작하여 이를 통해 검색 범위를 좁히는 방식입니다.

이 선택은 중요합니다.

엔지니어가 프로덕션 장애를 디버깅할 때, AI 모델에 전체 리포지토리를 읽어달라고 요청하는 것으로 시작하는 경우는 거의 없습니다. 그들은 오류를 확인합니다. 스택 추적을 따릅니다. 코드를 grep으로 검색합니다. 증상에서 시작하여 원인으로 이동합니다.

Kronos는 바로 그와 동일한 직관을 바탕으로 설계되었습니다.

이 시스템은 로그를 진입점으로 사용하고, 가장 관련성이 높아 보이는 코드를 검색한 다음, 비로소 AI 모델을 워크플로우에 도입합니다. 이로 인해 모델은 모든 것을 꿰뚫어 보는 예언자라기보다는, 집중된 증거 패킷을 바탕으로 작업하는 검토자에 가까워집니다.

Dawood는 대규모 환경에서 신뢰를 얻기 전에 이 접근 방식을 여전히 개선해야 한다고 분명히 밝혔습니다. 하지만 데모에서는 잘 작동했습니다. 더 중요한 것은, 이것이 진지한 제품적 직관을 반영했다는 점입니다. 최고의 AI 시스템은 엔지니어링 워크플로우를 맹목적으로 대체하지 않습니다. 엔지니어가 이미 문제를 해결하는 방식으로부터 배웁니다.

Enter Pro를 활용한 관측 가능성 스택 구축

Kronos는 팀이 이전에 깊이 사용해 보지 않은 도구들을 가로질러 작동해야 했습니다.

Grafana. Prometheus. Loki. 대시보드. 로그. 메트릭. 알림.

해커톤 팀에게 이는 실제 제품이 작동하기 시작하기도 전에 이해해야 할 인프라가 너무 많음을 의미합니다.

이 지점에서 Enter Pro가 WhyVenv에게 유용하게 활용되었습니다.

팀은 프로젝트 전반에 걸쳐 연구, 아이디어 구체화, 디버깅을 위해 Enter Pro를 사용했습니다. Dawood와 그의 팀원들은 이를 사용해 관측 가능성 스택을 이해하고, 구성 요소들이 어떻게 결합되는지 파악하며, 시스템이 예상대로 작동하지 않을 때 통합 문제를 해결해 나갔습니다.

한 가지 순간이 기억에 남습니다.

팀은 데이터 알림이 왜 올바르게 들어오지 않는지 파악하지 못해 막혀 있었습니다. 다른 AI 모델들을 시도해 보았지만, Dawood는 일부 모델들이 팀이 이미 문제를 해결한 후에도 계속해서 같은 지점만 맴돌고 있다고 느꼈습니다.

그들이 Enter Pro를 사용해 보았을 때, 이 모델은 실제 원인을 더 직접적으로 식별할 수 있도록 도와주었습니다.

이것이 바로 빌드 스프린트에서 중요한 순간입니다. 다듬어진 데모 답변이나 일반적인 제안이 아닙니다. 실제 장애물을 돌파할 수 있는 구체적인 추진력입니다.

WhyVenv에게 Enter Pro는 단순히 코드를 생성하는 공간이 아니었습니다. 계속해서 빌드를 진행할 수 있을 만큼 빠르게 낯선 시스템을 논리적으로 분석하는 방법이었습니다.

이틀간의 집중

Dawood는 팀이 본격적인 개발을 시작하기 전에 프로젝트를 계획해 두었습니다.

그는 그들이 무엇을 만들고 싶어 하는지 알고 있었습니다. 기본 아키텍처를 철저히 고민해 두었습니다. 작업이 어떻게 분담되어야 하는지 대략적인 감을 잡고 있었습니다.

그 후 실제 해커톤의 리듬이 시작되었습니다.

첫날이 온통 코드로만 채워진 것은 아니었습니다. 팀은 함께 시간을 보내고, 대화하고, 농담을 나누며 발맞추어 나갔습니다. 진짜 빌드는 그 이후에 찾아왔습니다. 작업을 나누고, 생소한 부분을 연구하고, 핵심 흐름을 구현하고, 제품이 형태를 갖출 때까지 다듬는 집중적인 스프린트였습니다.

아키텍처는 단순하게 시작되었습니다:

크래시 리포트 -> 관련 코드 -> LLM 진단 -> 이슈 생성 또는 수정.

그 후 팀이 빌드해 나가면서 각 부분이 더욱 정교해졌습니다.

그 단순함이 Kronos가 매력적인 이유 중 일부입니다. 에이전트 기반 소프트웨어에 대한 복잡한 이론에서 시작하지 않습니다. 대기 중인 모든 엔지니어가 이해하는 워크플로우에서 시작합니다. 무언가 고장 났고, 원인을 찾고, 다음에 무엇을 할지 결정하는 것입니다.

Kronos가 AI 에이전트에 대해 시사하는 바

Kronos는 코드베이스 옆에 앉아 있는 챗봇이 아닙니다.

그것은 워크플로우 에이전트에 가깝습니다. 실제 세계로부터 신호를 수신하고, 올바른 증거를 수집하고, 추론이 유용한 지점에서만 추론을 요청한 다음, 엔지니어들이 이미 사용하는 도구로 결과를 라우팅하는 시스템입니다.

그 차이는 중요합니다.

Dawood는 AI 시스템을 둘러싼 비용 및 제어 문제에 민감합니다. 인터뷰에서 그는 토큰 사용량, 비용이 많이 드는 모델 호출, 그리고 결정론적인 백엔드 로직이 작업의 일부를 더 효율적으로 처리할 수 있을 때 에이전트가 모든 것을 처리하도록 두지 않는 것의 중요성에 대해 이야기했습니다.

이는 2026년에 AI를 활용해 무언가를 구축하는 사람으로서 성숙한 직관입니다.

AI 에이전트의 미래는 단순히 더 강력한 모델을 사용하는 것에만 국한되지 않을 것입니다. 모델을 사용하지 않아야 할 때를 아는 것도 포함될 것입니다. 어떤 부분이 코드가 되어야 할까요? 어떤 부분이 검색이 되어야 할까요? 어떤 부분이 모델 추론이 되어야 할까요? 어떤 부분이 인간의 검토 하에 남아 있어야 할까요?

Kronos는 해커톤 프로젝트임에도 불구하고 바로 그 질문을 향하고 있습니다.

다음에 올 것

이 프로젝트가 프로덕션 환경에 적용될 준비를 마치기 전에 여전히 답해야 할 질문들이 있습니다:

검색 접근 방식이 더 큰 코드베이스에서 얼마나 잘 확장되는가?
심각도와 자율성을 어떻게 조정해야 하는가?
에이전트가 수정을 시도하는 대신 이슈를 열어야 하는 때는 언제인가?
모델이 실제 장애를 진단하기에 충분한 컨텍스트는 어느 정도인가?
무언가 프로덕션에 도달하기 전에 인간이 승인해야 하는 것은 무엇인가?

이것들은 사소한 질문이 아닙니다. 바로 Kronos에 주목할 가치를 부여하는 질문들입니다.

프로덕션 장애는 사라지지 않을 것이기 때문입니다. 유일한 질문은 모든 대응이 수동적인 패닉으로 시작되어야 하는가입니다.

Kronos는 다른 첫 단계를 상상합니다. 실패를 감지하는 시스템이 그 실패를 이해하기 시작할 수도 있는 단계입니다.

그것이 바로 Enter가 지원하기 위해 존재하는 목적입니다.

단지 더 빠른 코드만이 아닙니다. 실제 페인 포인트에서 작동하는 제품으로 더 빠르게 이동하는 것입니다.

그리고 WhyVenv에게 그 움직임은 고통스러운 엔지니어링 패턴을 Quackathon의 우승 프로젝트 중 하나로 바꾸기에 충분했습니다.

자세히 알아보기: Kronos.

이 이야기는 빌더들이 Enter Pro를 통해 무엇을 만들었는지, 왜 만들었는지, 그리고 그들의 작업이 AI 기반 소프트웨어 제작의 미래에 대해 무엇을 말해주는지 이해하기 위해 한 번에 하나의 프로젝트를 다루는 Quackathon Builder Series의 일부입니다. 계속 지켜봐 주시기 바랍니다.