몇 주 동안 공들여 만든 SSE(Server-Sent Events)를 걷어냈습니다. 처음 SSE를 제안하고 구현을 시작한 것은 저였고, 논의 끝에 걷어내자고 최종 결정한 것도 저 자신이었습니다.
SSE를 도입하고 polling으로 바꾸기까지의 기술적 판단은 함께 작업한 팀 동료가 앞선 글에 정리했습니다.
이 글은 그 판단에 이르게 된 과정을 따라가며, AI와 함께 빠르게 답을 완성하는 동안 루프 바깥에서 무엇이 더 필요했는지를 다룹니다.
AI는 주어진 문제를 빠르게 해결한다
Qra는 Vizend에서 애플리케이션 배포를 수행하고 그 상태를 보여주는 서비스입니다. 배포는 수십 초에서 길게는 수 분이 걸립니다. 그때 제게 주어진 문제는 사용자가 단계별 배포 진행 상황을 확인할 수 있는 기능을 제공하는 것이었습니다. 저는 이전에 다른 프로젝트에서 오래 걸리는 비동기 작업의 진행 상황을 SSE로 시각화한 경험을 떠올려, 이번에도 자연스럽게 SSE로 문제를 풀 수 있으리라 생각하고 방향을 잡아갔습니다.
당시 저희 팀은 AI 에이전트와 함께 워크플로를 다듬어가며 SSE를 구현하고 검증하고 수정했습니다. 리소스 문제부터 프론트엔드 라이브러리 선택 등 해결할 일이 잇따랐지만 SSE 구현은 큰 어려움 없이 스테이징까지 올라갔습니다. 그렇게 SSE는 잘 자리 잡는 듯했습니다.

구현과 검증을 반복하면서 SSE는 점차 안정됐습니다.
문제의 해결이 처음의 판단까지 증명하지는 않는다
그러던 중 Vizend 플랫폼의 정기 리뷰를 앞두고 프로덕션 기준을 다시 확인하면서 이전부터 염두에 두고 있던 무상태 구조와 수평 확장이라는 조건에 다시 무게를 두었습니다. Qra에서 배포 상태 변화를 감지한 인스턴스와 사용자의 SSE 연결이 맺어진 인스턴스가 달라질 수 있어 즉시 전달하려면 별도 중계 경로가 필요했습니다. 그런데 Qra는 특정 인프라가 고정된 프로젝트가 아니라 여러 환경을 지원하는 플랫폼 서비스였습니다.
애초에 Qra의 요구사항은 ‘사용자가 배포 진행 상황을 확인할 수 있게 한다’였지, ‘SSE로 실시간 전달한다’가 아니었습니다. 하지만 SSE로 방향을 잡은 뒤로는 그 방식을 어떻게 더 안정적으로 구현할지에 집중했지, 그 선택 자체를 다시 검토할 생각은 하지 못했습니다.
그 요구사항에 다시 비추어 보면 polling에는 화면 갱신 지연과 요청량 증가라는 대가가 있습니다. 하지만 이 화면의 핵심은 사용자가 배포가 어디까지 진행됐는지, 실패했다면 언제 왜 실패했는지를 확인하는 데 있었습니다. 화면 갱신이 몇 초 늦어져도 배포 자체나 사용자의 다음 행동에는 큰 영향을 주지 않았기 때문에 그 대가는 Qra에서 감당할 수 있는 수준이라고 판단했습니다.
또한, 화면 하나의 즉시성을 위해 중계 경로와 연결 관리, 백엔드·프론트엔드의 공통 규칙까지 새로 정의하는 것은 과하다고 생각했습니다. 그 후 팀 동료와 인프라팀, Vizend 플랫폼팀과 논의를 거쳐 플랫폼 차원의 SSE 기준은 백로그로 남기고 Qra에서 SSE를 걷어냈습니다.
이 결정에 이르기까지 서로 다른 층위의 두 질문이 있었습니다. ‘SSE가 잘 동작하는가?’ 라는 질문은 AI 실행 루프를 거치며 충분히 확인할 수 있었습니다. 하지만 ‘Qra가 이 운영 책임을 맡을 만큼 즉시성이 중요한가?’라는 질문에는 구현 결과가 아무리 좋아도 그 루프 안에서는 답할 수 없었습니다.
회고 중 조직 학습 이론에서 Single Loop와 Double Loop 개념을 접했을 때 그 구분이 더 명확해졌습니다. Single Loop가 정해진 목표 안에서 오류를 바로잡는다면 Double Loop는 그 목표와 가정부터 다시 점검합니다. 제가 몇 주간 붙들고 있던 건 SSE의 완성도를 높이는 루프였습니다. 하지만 한 걸음 밖에서 바라보니 SSE 자체가 Qra에 필요한지 묻는 두 번째 질문이 남아 있었습니다.
무엇에 무게를 둘지 판단하는 감각
새 문제를 마주하면 과거의 경험과 지식을 추상화하여 지금의 문제와 유사한 부분을 찾게 됩니다. 다만 그다음엔 다시 해상도를 높여 과거와 지금 상황의 차이를 봐야 합니다.
이전 프로젝트에서는 제가 리드로서 정해진 환경에 적합한 기준을 정하고 추진할 수 있었습니다. 하지만 여러 환경과 팀을 고려해야 하는 플랫폼의 일부인 Qra에서는 그 기준을 제 판단만으로 정할 수 없었습니다. 저는 이 차이를 기준으로 충분히 앞세우지 못했습니다.
한 번 잘 작동한 방식이라면 이번에도 맞을 것이라는 확신을 가질 수 있습니다. 그 확신이 클수록 지금 상황의 차이를 고해상도로 다시 보는 일을 놓치기 쉽습니다.
추상화로 닮은 점을 찾고, 고해상도로 차이를 살핀 뒤에는 무엇을 앞세울지 정해야 합니다. 저는 이때 여러 요소 사이의 무게를 가늠하는 감각을 일종의 Taste라고 봅니다. 여기서 Taste는 단순히 취향이나 안목만으로는 다 설명하기 어렵습니다.
이 감각을 두고 Andrew Ng은 사람들이 Taste라고 부르는 인간의 기여를 맥락상의 우위(context advantage)로 표현했습니다. 제품과 사용자 가까이에서 쌓인 정보와 경험이 새로운 판단의 재료가 된다는 뜻입니다.
판단에 필요한 재료를 사전에 문서와 피드백만으로 모두 담아 두기는 어렵습니다. 일이 진행되면서 새롭게 드러나는 맥락이 있을 수 있고, 같은 사실을 두고도 그 상황에서의 목적과 역할, 책임에 따라 무엇을 더 중요하게 볼지는 달라질 수 있습니다.
Qra에서 달라진 것은 판단의 재료가 아니라 그 재료에 둔 무게였습니다.
판단을 선택으로 옮기는 힘
AI가 제가 고른 답을 빠르게 완성할수록 처음의 질문은 검토 대상에서 멀어져갔습니다. SSE가 잘 동작하는지는 실행 루프를 거치며 빠르게 확인할 수 있었지만, 그 방식을 계속 써야 하는지는 루프 밖에서 물어야 할 몫으로 남아 있었습니다.

기준을 충족하는지는 루프 안에서 확인할 수 있지만, 그 기준을 계속 적용할지는 루프 밖에서 다시 검토해야 합니다.
일이 진행되는 동안에도 사람은 처음의 판단이 지금의 목적과 역할에 맞는지를 계속 따져야 합니다. 그에 따라 지금의 방식을 이어갈지, 손볼지, 바꿀지를 정해야 합니다.
Human Agency는 실행의 속도를 높이는 데서가 아니라, 이미 선택한 답을 다시 검토하고 책임지는 데서 드러납니다.
참고 자료
- HKK, 실시간성 확보 SSE 도입부터 Polling으로의 회귀까지 (Nextree, 2026-05-07)
- Andrew Ng, The Batch Issue 359 (2026-06-26)
- Chris Argyris, Double Loop Learning in Organizations (Harvard Business Review, 1977-09)
TaeZ