클로드코드로 만든 지도앱이 느려질 때 — 범인은 마커(DOM 렌더링)였다

한 참여자가 클로드코드(Claude Code, AI 코딩 어시스턴트)로 사내용 지도 애플리케이션을 만들다가 벽에 부딪혔다. "클로드코드로 지도앱 만들고 있는데 너무 무겁고 느린데, 어떻게 수정 프롬프트를 쓰면 좋을까요, 고수님들 도움 좀"이라며 도움을 청한 것이다. 그는 이어서 "열심히 지도앱 만들어서 여러 부서가 이용하게 하고 싶은데, 너무 느려지고 Supabase(백엔드 데이터베이스·인증 서비스) 과금될까 무섭다"며 성능과 비용 두 가지를 동시에 걱정했다.

다른 참여자는 곧바로 원인을 짚었다. 지도 위에 표시되는 마커(marker, 위치를 나타내는 핀 아이콘)가 "확실히 인식도 잘 안 되고 느리다"는 반응이었다. 지도에 데이터가 많아질수록 마커·핀 렌더링이 늘어나고, 이는 브라우저가 화면 요소를 구조화해 그리는 방식인 DOM(Document Object Model, 문서 객체 모델)에 부하를 준다는 지적으로 이어졌다. 마커 하나하나가 개별 DOM 요소로 쌓이면 지도를 움직이거나 확대·축소할 때마다 브라우저가 이를 다시 계산해야 해서, 데이터가 늘어날수록 체감 속도가 눈에 띄게 떨어지게 된다는 설명이었다.

대화 중 한 참여자는 실제 사례로 지진 정보를 실시간으로 보여주는 지도 사이트(opencrab.sh/pet/earthquake)의 링크를 공유했다. 많은 위치 데이터를 지도 위에 표시하면서도 무겁지 않게 동작하는 서비스로, 마커를 개별 DOM 요소로 하나씩 그리는 대신 다른 렌더링 방식으로 처리했을 가능성을 보여주는 참고 사례로 언급됐다. 질문자가 겪은 문제와 비슷한 상황을 이미 풀어낸 서비스가 실제로 있다는 점에서, 프롬프트 수정만으로는 한계가 있고 렌더링 구조 자체를 손봐야 할 수 있다는 방향 제시이기도 했다.

이 대화는 AI 코딩 도구로 프로토타입을 빠르게 만드는 것과, 그것을 실제 여러 부서가 쓰는 서비스로 확장하는 것 사이의 간극을 보여준다. 데이터 양이 늘어날수록 단순한 마커 렌더링 방식은 성능과 비용(서버·DB 과금) 양쪽에서 한계를 드러내기 마련이며, 이런 경우 수정 프롬프트를 다듬는 것보다 렌더링 아키텍처 자체를 점검하는 편이 더 근본적인 해법이 될 수 있다는 점을 시사한다. 지도 위 데이터가 몇 개인지, 어떤 방식으로 그려지는지를 먼저 살피는 것이 다음 수정의 출발점이 될 만하다.

특히 질문자처럼 여러 부서가 함께 쓰는 사내 서비스를 목표로 한다면, 마커 개수가 지금보다 훨씬 늘어날 가능성을 미리 염두에 두어야 한다. 초기 프로토타입 단계에서는 눈에 띄지 않던 렌더링 방식의 비효율이, 사용자와 데이터가 늘어나는 순간 병목으로 드러나는 경우가 많기 때문이다. 이번 대화에서 오간 조언들은 결국 "지금 당장 무엇을 고칠까"보다 "왜 무거워졌는가"를 먼저 짚어야 한다는 점을 일깨워준다.

이 문답이 흥미로운 지점은, 질문자가 "수정 프롬프트를 어떻게 쓰면 좋을까"라고 물었지만 돌아온 답은 프롬프트가 아니라 구조를 향했다는 데 있다. AI 코딩 도구는 요구를 말로 풀어 넣으면 그럴듯한 결과물을 빠르게 내주지만, 그 결과물이 왜 느린지·어디가 병목인지를 파악하는 일은 여전히 사람의 진단 몫으로 남는다는 점이 드러난 셈이다. 프롬프트를 아무리 정교하게 다듬어도, 문제의 뿌리가 렌더링 구조에 있다면 같은 자리를 맴돌 수밖에 없다. 도구가 코드를 대신 써주는 시대일수록, 오히려 "무엇이 왜 느린가"를 읽어내는 기본기가 결과물의 완성도를 가르는 분기점이 된다는 인상을 남긴 대화였다.