저는 GPTers 커뮤니티에서 마케팅을 담당하고 있으며, 커뮤니티 유저의 활성도를 판단하고 검색 유입 성과를 분석하기 위해 Mixpanel에서 게시글 조회수를 모니터링하고, Google Search Console(GSC)을 활용해 검색 노출 및 키워드 데이터를 확인하고 있습니다.
그리고 이러한 데이터를 기반으로 콘텐츠 마케팅 전반에 대한 가이드를 제시할 수 있다고 생각했습니다.
대시보드를 통해 해결하고 싶은 문제는 아래와 같습니다.
1. 두 사이트를 왔다 갔다 — Mixpanel에서 조회수 보고, GSC에서 검색 데이터 보고... 번거로움
게시글 바로 열기 불가 — Mixpanel에서 조회수 높은 글을 발견해도, 해당 글을 바로 열어볼 수 있는 링크가 없음
트렌드 파악 어려움 — 일별/월별 추이를 한눈에 보기 힘듦
전에는 이 방식을 게시글마다 점수를 부여해볼까 하고 접근한 적이 있었는데요.
평가지표를 만드는 것이 어렵기도 하고 크게 의미가 있을까 싶은 생각 에 일단 두 서드파티의 데이터 수치를 시각적으로 보기 좋게 만드는 대시보드를 먼저 구현해봐야겠다 생각했습니다.
지난 번 이렇게 1차적인 틀을 만들었었고
이번 주는 본격적으로 데이터를 밀어 넣고 세부적인 것들을 완성했는데요.
많은 정보가 포함된 대시보드
대시보드를 만들고 나니, 예상치 못한 문제가 생겼습니다.
데이터가 10만 건이 넘으니 로딩이 2~3초씩 걸리며 생각이상으로 사용성이 안 좋았습니다.
그래서 클로드 코드와 이 문제를 해결한 방법, 과정을 소개드립니다.
속도 개선 1: 병렬 쿼리 (Promise.all)
뭔가요?
원래 데이터베이스에서 정보를 가져올 때, 하나씩 순서대로 가져옵니다.
1번 쿼리 실행 (0.5초) → 기다림 →
2번 쿼리 실행 (0.5초) → 기다림 →
3번 쿼리 실행 (0.5초) → 기다림 →
4번 쿼리 실행 (0.5초) → 기다림 →
5번 쿼리 실행 (0.5초) → 완료!
총 2.5초
병렬 쿼리는 이걸 동시에 실행하는 겁니다.
1번 쿼리 ─┐
2번 쿼리 ─┼─ 동시 실행 (0.5초) → 완료!
3번 쿼리 ─┤
4번 쿼리 ─┤
5번 쿼리 ─┘
총 0.5초
어떻게 적용했나요?
Claude Code에게 이렇게 말했습니다:
"이 5개 쿼리가 서로 의존성이 없으면 동시에 실행해서 속도 올릴 수 있어?"
그랬더니 Promise.all이라는 방법으로 5개 쿼리를 동시에 실행하도록 코드를 바꿔줬습니다.
결과: 2.5초 → 0.5초 (5배 빨라짐)
속도 개선 2: 디바운스 검색
뭔가요?
검색창에 "gpters"를 입력한다고 해봅시다.
원래는 이렇게 동작합니다:
g 입력 → 서버 요청
gp 입력 → 서버 요청
gpt 입력 → 서버 요청
gpte 입력 → 서버 요청
gpter 입력 → 서버 요청
gpters 입력 → 서버 요청
총 6번 서버 요청!
디바운스는 "입력이 멈추면 그때 요청"하는 방식입니다:
g 입력 → (대기)
gp 입력 → (대기)
gpt 입력 → (대기)
gpte 입력 → (대기)
gpter 입력 → (대기)
gpters 입력 → 0.5초 대기 → 서버 요청
총 1번 서버 요청!
게시글을 제목과 작성자로 검색하는 기능을 추가했는데, 검색어가 완성되기 전에 계속 호출을 하는 구조로 초기 설계가 되었었습니다. 예를 들어 '바이브코딩' 을 검색하고자 할 때, '바' 까지 쳤을 때도 검색이 돌아가고 있고 '바이' 까지 쳤을 때도 검색이 돌아가고 해서 이 부분을 고치고자 했습니다.
"검색할 때 타이핑할 때마다 API 호출되는 것 같은데, 입력 끝나고 잠깐 있다가 호출되게 해줘"
그랬더니 500ms(0.5초) 디바운스를 적용해줬습니다.
결과: 서버 요청 6회 → 1회 (서버 부하 83% 감소)
속도 개선 3: 차트 지연 로딩
뭔가요?
대시보드에 테이블 1개 + 차트 4개가 있었습니다. 원래는 이 5개를 다 불러올 때까지 화면이 안 뜹니다.
테이블 로딩 중... (1초)
차트 1 로딩 중... (0.5초)
차트 2 로딩 중... (0.5초)
차트 3 로딩 중... (0.5초)
차트 4 로딩 중... (0.5초)
→ 3초 후 화면 표시
지연 로딩은 중요한 것(테이블)부터 먼저 보여주는 방식입니다:
테이블 로딩 (1초) → 화면 표시! (차트는 로딩 중 표시)
차트들 로딩 (백그라운드에서 진행)
→ 1초 후 테이블 표시, 차트는 나중에 채워짐
어떻게 적용했나요?
Claude Code에게 이렇게 말했습니다:
"테이블이 먼저 뜨고, 차트는 나중에 로딩되게 해줘. 차트 자리엔 로딩 중 표시해주고."
결과: 체감 로딩 시간 3초 → 1초
실제 전체 로딩 시간은 같지만, 사용자가 기다리는 느낌이 훨씬 줄었습니다.
속도 개선 4: 데이터 필터링
뭔가요?
GSC 데이터 중 검색 노출(impressions)이 10 미만인 데이터는 분석에 의미가 없었습니다. 노출이 3번, 5번인 건 우연일 수 있으니까요.
그래서 "10번 이상 노출된 데이터만 보여줘"라고 필터를 걸었습니다.
결과
원본 데이터: 96,806건
필터 후: 23,867건
75% 데이터 감소 → 로딩 속도 비례 개선
속도 개선 5: 페이지네이션
10만 건 데이터를 한 번에 다 불러오면 당연히 느립니다. 페이지네이션은 30개씩 끊어서 보여주는 방식입니다.
원래는 한 페이지에 게시글을 100개 까지 보이게 했다가 이 수를 줄이면서 한 페이지에 로딩되는 속도를 줄였습니다.
1페이지: 1~30번 데이터 (빠름)
2페이지: 31~60번 데이터 (빠름)
...
어차피 사용자는 한 번에 30개 이상 안 봅니다.
결과: 10만 건 로딩 → 30건 로딩 (3000배 데이터 감소)
바이브코딩 팁: 개발 용어 몰라도 됩니다
이 과정에서 제가 실제로 Claude Code에게 했던 코멘트입니다.
바이브코더로써 자세한 개발 언어를 몰라도 수정 가능할 것 같은 아이디어를 잘 던지기만 해도 서비스의 사용성이 크게 올라가는 것을 확인 했습니ㅏ.
내가 한 말
Claude가 이해한 것
"로딩 느린데 빠르게 해줘"
성능 최적화 필요
"이거 동시에 실행하면 안 돼?"
Promise.all 적용
"타이핑 끝나고 검색되게 해줘"
디바운스 적용
"테이블 먼저 보여줘"
지연 로딩 적용
"30개씩 끊어서 보여줘"
페이지네이션 적용
핵심: 원하는 결과를 설명하면 됩니다. 방법은 Claude가 알아서 찾아줍니다.
"Promise.all이 뭐야?"라고 물어보면 설명도 해줍니다. 그 설명 듣고 "아 그러면 적용해줘"라고 하면 됩니다.
마무리
개발자 없이, 개발 용어 모르고도 대시보드를 만들고 성능 최적화까지 했습니다.
중요한 건 "뭘 원하는지 명확히 설명하는 것"입니다.
"빨라졌으면 좋겠어" → "로딩이 3초인데 1초 안에 뜨게 해줘" "예쁘게 해줘" → "차트가 로딩될 때 빈 화면 말고 로딩 표시 보여줘"
구체적으로 말할수록 Claude Code가 정확하게 해줍니다.
바이브코딩, 운동 많이 됩니다.
