화면의 시대에서 코드의 시대로

8월 30일 일요일, 어제 도곡동에서 열린 그라파나 밋업에 다녀왔습니다. 발표가 다섯 개였는데 스펙트럼이 되게 넓었죠. 셀프스토리지 스타트업부터 삼성전자 반도체, AI 스타트업까지. 저도 고객사 관측 스택을 LGTM으로 운영하는 입장이라 도구 팁이나 몇 개 주워오자는 마음으로 갔는데, 다녀와보니 이게 도구 얘기가 아니더라고요. 다섯 팀이 전부 다른 문제를 들고 나왔는데 결이 같았습니다. 결국에는 두 가지 질문으로 모이더라고요.

그라파나의 경계를 어디에 그을 것인가, 그리고 이 화면들을 누가 읽게 할 것인가.

 

다섯 개의 발표, 짧은 스케치

세컨신드롬의 미니창고 다락 발표는 제목부터 그라파나 그렇게 쓰는 거 아닌데?였습니다. 프론트엔드 리소스가 없어서 그라파나를 읽기 전용 어드민처럼 쓰다가, 쓰기 기능까지 붙였다가, 선을 그은 이야기죠.

 

AB180은 10년 동안 난립한 얼럿을 갈아엎은 이야기를 했습니다. 그라파나 콘솔에서 손으로 만들고, 뉴렐릭에서 만들고, AWS 콘솔에서 만들고, 테라폼으로도 만들다 보니 뭐가 어디 있는지 아무도 모르는 상태가 됐다는 거죠. 개편의 기준이 흥미로웠는데, 에이전틱 코딩이 잘 먹히는 구조를 최우선으로 잡았습니다.

 

세 번째 발표는 넛지 헬스케어의 Tempo 2를 RF1로 운영하다 겪은 장애 분석이었습니다. 인제스터 아홉 대 중 한 대가 OOM 났는데 메트릭 수신량이 90퍼센트 무너졌죠. 직관적으로는 11퍼센트만 죽어야 하는데요. 원인은 배치로 묶인 리퀘스트의 병렬 쓰기 중 하나만 실패해도 전체가 실패 처리되는 코드 경로였고, 배치에 트레이스가 N개 들어 있으면 성공 확률이 (8/9)의 N승으로 지수적으로 떨어지는 구조였습니다. 실측 배치 평균이 26개였으니 답이 나오죠.

 

삼성전자 반도체 쪽에서 플랫폼을 운영하시는 분은 사고 세 개를 풀어놓으셨습니다. 10년 방치된 형상관리 서버의 디스크 폴트로 데이터를 하루치 날린 이야기, 5년 묵은 국제망 지연의 범인이 스위치 한 대의 버퍼 오버플로우 버그였다는 이야기, 그리고 지금 GPU 100장으로 임직원 9천 명에게 LLM을 서빙하면서 테스트를 줄이고 모니터링으로 버티는 이야기까지요.

 

마지막으로 사이오닉 AI는 시켜만 놓으면 되는 그라파나라는 제목으로, 에이전트가 대시보드를 만들고 읽게 하는 구조를 보여줬습니다. 이제 인간이 개입하는 게 오히려 속도를 늦춘다는 도발적인 전제로 시작했는데, 발표 주제를 당일 새벽에 바꿨다고 하시더라고요. 그 속도감 자체가 발표 내용과 묘하게 어울렸습니다.

다들 선을 긋고 있더라

첫 번째 공통점부터 얘기하면, 다섯 팀이 전부 경계 이야기를 하고 있었습니다.

다락이 제일 노골적이었죠. 읽기 전용 어드민까지는 되게 잘 먹혔답니다. 요청이 오면 그라파나로 하루 만에 화면을 만들어서 2주에서 4주 지켜보고, 아무도 안 보면 드랍하고, 의미가 있으면 그때 어드민으로 본격 개발하는 방식이요. MVP 탐색 도구로는 최고였다는 겁니다. 그런데 Business Forms 플러그인[1]으로 POST API를 붙여서 운영 처리까지 시키는 순간 얘기가 달라졌다고 하더라고요. 리드 권한과 리드라이트 권한을 나눠 관리하던 체계에 그라파나가 쓰기 주체로 끼어들면서 관리 포인트가 늘고, 화면 하나 고칠 때마다 프론트도 보고 그라파나도 봐야 하는 상태가 된 거죠. 그래서 변화가 적은 간단한 기능까지만 하기로 선을 그었습니다.

 

 

AB180의 얼럿 프록시도 같은 구조의 결정입니다. 그라파나 얼럿은 판정 엔진으로만 쓰고, 판정 이후의 모든 것들은 자체 프록시 API 서버가 받아서 팬아웃합니다. 슬랙 포매팅, ack와 리졸브 버튼, 담당자 멘션, 그룹핑, 재알림 같은 것들을 전부 프록시 뒤로 모았죠. 그라파나가 잘하는 것과 조직이 직접 쥐어야 하는 것 사이에 명확한 금을 그은 겁니다.

 

Tempo 3.0은 이 경계 이야기의 아키텍처 버전이었습니다. 쓰기 내구성의 경계를 인제스터 쿼럼에서 카프카 같은 듀러블 스트림으로 옮겼죠[2]. 스트림에 적재되는 순간 쓰기가 완료되고, 블록 빌더와 메트릭스 제너레이터는 독립 컨슈머로 각자 소비합니다. 한 컴포넌트의 실패가 다른 경로를 무너뜨리던 결합이 경계 이동으로 사라진 겁니다. 물론 발표자분도 짚었지만 공짜는 아니에요. 카프카 운영과 컨슈머 랙 관리라는 새 숙제가 생기죠.

 

경계 안쪽을 파고든 사례도 있었습니다. 다락은 전사가 그라파나를 쓰기 시작하면서 DB 세션이 계속 늘었는데, 5퍼센트 단위로 계약 증감을 보는 장표가 사실상 같은 쿼리를 12번 날리는 구조였다고 해요. 파티셔닝과 인덱싱으로는 별로 안 잡히더랍니다. 답은 그라파나의 대시보드 데이터 소스였죠. 데이터를 한 번만 가져오고 트랜스포메이션으로 12개 패널을 나눠 그리니 세션이 뚝 떨어졌다는 겁니다. 경계를 긋는 것과 별개로, 그은 경계 안에서는 도구가 주는 것들을 끝까지 써먹는 모습이었어요.

 

결국에는 도구를 잘 쓴다는 게 기능을 많이 쓴다는 뜻이 아니라 어디서 멈출지를 안다는 뜻이더라고요.

에이전트한테는 화면이 아니라 코드를 주더라

두 번째 공통점이 제가 이 밋업에서 진짜 가져온 것들입니다.

 

에이전트 시대의 관측성은 화면이 아니라 코드다.

사이오닉의 여정이 이걸 압축해서 보여줍니다. 처음에는 클로드 코드에 브라우저를 띄워서 그라파나를 직접 조작하게 했답니다. 되긴 되는데 너무 오래 걸리고, 언제 끝날지 모르고, 제대로 못 하더라는 거죠. 그래서 그라파나 Git Sync[3]로 방향을 틀었습니다. 대시보드가 Git의 코드가 되니까 에이전트는 기존 YAML과 팀의 패턴을 읽고, 대시보드를 직접 만드는 게 아니라 PR을 올립니다. 여기서 되게 영리한 부분이, Git Sync가 PR에 달아주는 비포와 애프터 프리뷰 렌더[4]를 에이전트의 눈으로 쓴다는 점이에요. 커밋을 올리고, 렌더된 패널을 읽고, 노 데이터가 떴으면 스스로 고치고. 사람이 하던 리뷰 루프를 그대로 에이전트한테 학습시킨 거죠.

 

AB180은 반대편에서 같은 결론에 도착했습니다. 얼럿 개편의 목표 자체가 코드화, 중앙화, 자동화였는데, 이 세 가지가 사실 에이전틱 코딩이 잘 돌아가기 위한 조건이거든요. 대표님이 수신자로 남아 있던 오래된 얼럿들을 정리할 때, 예외 조건까지 자연어로 지시하면 에이전트가 코드를 고치고 푸시하면 자동 배포까지 흘러갑니다. 발표자분은 MCP도 써봤는데 너무 느려서 안 쓴다고 하셨어요. 코드를 직접 고치는 게 빠르고, 눈에 보이니까 마음도 편하다는 거죠.

 

서로 모르는 두 회사가 각자 부딪혀보고 같은 자리에 도착했다는 게 포인트입니다. 에이전트한테 사람 쓰라고 만든 인터페이스를 쥐여주면, 아니죠, 쥐여줄 수는 있는데 느리고 불안합니다. 에이전트가 잘하는 형태로 세계 쪽을 바꿔주는 게 답이더라는 겁니다. 대시보드가 코드가 되고, 변경이 PR이 되고, 검증이 CI와 프리뷰가 되면 에이전트는 원래 잘하던 일을 하면 되니까요.

 

읽는 쪽도 마찬가지였습니다. 사이오닉은 옵저버라는 별도 에이전트를 뒀는데, 얼럿매니저가 알람을 던지면 옵저버가 미리 학습해둔 서비스 매핑을 따라 트레이스와 로그와 소스코드를 분석해서 초기 진단을 스레드로 남깁니다. 에러 영향도와 신뢰도까지 붙여서요. 재미있는 건 그 다음이에요. 그 회사 개발자들은 이제 거의 에디터를 안 쓰고 각자 에이전트로 개발한다는데, 그래서 진단 결과를 사람만 읽는 게 아니라 개발자의 에이전트가 MCP로 받아다 쓰는 플로우를 그리고 있답니다. 에이전트가 에이전트를 읽는 A2A 구조를 만들려고 노력 중이라는 표현을 쓰셨어요.

 

삼성 쪽 발표는 이 흐름의 전제 조건을 보여줬다고 생각합니다. 모델이 일주일에 두 개씩 나오는 상황에서 정식 카나리 절차로는 속도를 못 따라가니까, 테스트를 줄이는 대신 배포 전에 대시보드부터 전부 띄워놓고 문제가 보이면 즉시 원상복구하는 쪽으로 전략을 뒤집었다고 하셨죠. 리스크를 제로로 만드는 게 아니라 최소 리스크에서 빠르게 되돌리는 구성. 이게 가능하려면 관측이 배포보다 먼저 준비되어 있어야 합니다. 사이클을 빨리 돌리는 쪽이 이기는 시대에, 관측은 사이클의 결과물이 아니라 선행 조건이 되는 것들이죠.

 

관측을 운영하는 입장에서

말이 좀 돌아갔는데, 저희처럼 고객 인프라를 관측하고 운영하는 쪽에서 이 밋업을 어떻게 소화해야 하나를 좀 붙여보겠습니다.

 

먼저 순서에 대한 확신입니다. 장애 분석을 에이전트한테 시키는 시도는 지금 다들 하고 있죠. 그런데 이번에 확인한 건, 에이전트를 붙이기 전에 관측 자산부터 에이전트가 읽을 수 있는 형태로 바꾸는 게 먼저라는 겁니다. 사이오닉의 옵저버 에이전트가 초기 진단을 낼 수 있는 건 서비스 매핑과 배포 형상이 미리 정리되어 있기 때문이고, AB180의 에이전트가 얼럿을 일괄 수정할 수 있는 건 얼럿이 전부 한 레포의 YAML이기 때문이거든요. 에이전트의 성능을 올리는 것보다 에이전트가 밟고 설 땅을 고르는 게 먼저더라고요.

 

그리고 삼성 발표의 명제, 옵저버빌리티는 사고 후의 도구가 아니라 사고 전의 습관이라는 말은 에이전트 시대에 오히려 더 무거워집니다. 그분 표현으로는 원인이 사실 되게 작대요. 디스크 한 장, 장비 한 대. 그걸 건초더미에서 바늘 찾듯 찾아야 하는데, 데이터가 미리 쌓여 있지 않으면 사람이든 에이전트든 찾을 방법 자체가 없죠. 에이전트가 읽는 주체가 되어도 읽을거리는 사고 전에 사람이 습관으로 쌓아둬야 합니다.

MCP 얘기도 잠깐 하면, 이번 밋업에서 MCP에 대한 태도가 두 갈래로 갈렸다는 게 흥미로웠습니다. AB180은 느려서 버렸고, 사이오닉은 개발자의 에이전트가 옵저버를 MCP로 읽어가는 플로우를 그리고 있습니다. 모순처럼 보이는데 뜯어보면 용도가 달라요. 상태를 바꾸는 조작은 코드와 PR로, 분석 결과를 가져오는 조회는 MCP로. 쓰기는 리뷰와 형상이 남아야 하니 Git을 타는 게 맞고, 읽기는 왕복 한 번이면 되니 MCP가 맞는 거죠. 도구 자체의 우열이 아니라 어느 자리에 두느냐의 문제였습니다.

 

하나 더, AB180 Q&A에서 나온 답변이 계속 남습니다. 서서히 잠식되는 비용 같은 미지의 문제를 미리 감지할 수 있느냐는 질문에, 10년 해보니 쉽지 않더라, 분기 점검 때 하나씩 진짜 걸리더라, 그래서 주기 점검이 답인 것 같다고 하셨거든요. 이벤트 기반으로 다 잡겠다는 꿈은 저도 있지만, 미지의 문제는 정의상 얼럿 룰이 없습니다. 주기적으로 사람이 눈으로 훑는 시간은 에이전트가 아무리 좋아져도 당분간 빼기 어려운 것 같아요. 굳이 연결하면 이 훑는 일이야말로 나중에 에이전트한테 넘기기 좋은 후보겠지만, 그것도 훑을 데이터가 쌓여 있어야 가능한 얘기죠.

 

이 기준을 저한테 되돌려보면 좀 뜨끔한 것들이 있습니다. 저도 그동안 대시보드를 만들 때 보는 사람이 이해할까만 따졌지, 읽는 쪽이 맥락 없이 와도 판단할 수 있게 되어 있나는 잘 안 따졌거든요. 삼성 발표에 좋은 예가 있었는데, GPU 지표를 평균의 평균으로 뭉쳐 보여주면서 대신 이 수치는 정확하지 않다, 일정 수준을 넘으면 지연이 생긴다는 설명을 대시보드에 같이 적어놨다고 합니다. 그랬더니 사용자들이 지금 느린 게 내 문제가 아니라 GPU 문제구나를 스스로 판단하고, 심지어 여유 있는 모델로 알아서 옮겨가더라는 거죠. 수치의 한계까지 화면에 적어두는 것. 읽는 주체가 사람이든 에이전트든, 판단에 필요한 맥락을 데이터 옆에 붙여두는 습관부터가 시작인 것 같습니다.

마치며

다섯 발표를 한 문장씩으로 접으면 이렇게 됩니다. 다락은 그라파나로 어디까지 버틸 수 있는지를, AB180은 어디부터 직접 쥐어야 하는지를, Tempo 발표는 경계를 옮기면 구조가 어떻게 풀리는지를, 삼성은 그 모든 것 이전에 쌓는 습관을, 사이오닉은 쌓인 것을 읽는 주체가 바뀌고 있음을 보여줬습니다.

 

결국에는 관측성이라는 게 대시보드를 예쁘게 만드는 일이 아니라, 시스템이 스스로를 설명할 수 있는 형태로 세계를 정리해두는 일이더라고요. 그 설명을 읽는 쪽이 사람에서 에이전트로 넓어지고 있을 뿐입니다. 그리고 읽는 쪽이 누구든, 쌓는 쪽의 습관과 경계 감각은 여전히 사람의 몫이었습니다.

주석

[1] Business Forms 패널 플러그인. VolkovLabs 제작, 그라파나 대시보드에서 데이터 입력과 API 호출을 지원한다. https://grafana.com/grafana/plugins/volkovlabs-form-panel/

 

[2] Tempo 3.0 릴리즈. 카프카 호환 메시지 큐를 쓰기 경로의 듀러블 WAL로 두면서 RF3 요구사항을 제거했다. https://grafana.com/blog/tempo-3-0-release-all-the-latest-features/

 

[3] Grafana Git Sync. 대시보드와 폴더를 Git 저장소와 양방향 동기화하는 기능으로 2026년 4월 GA. https://grafana.com/whats-new/2026-04-20-git-sync-for-grafana-dashboards-and-folders-now-generally-available/

 

[4] Git Sync의 PR 프리뷰. PR이 열리면 원본과 수정본 대시보드의 스크린샷과 프리뷰 링크가 코멘트로 달린다. https://grafana.com/docs/grafana/latest/as-code/observability-as-code/git-sync/git-sync-setup/set-up-extend/