code를 헤엄치는 인어공쭈

“오늘 나 뭐 했지?”에 데이터로 대답하는 법 (Haneui-Tracker 개발기)

인어공쭈 — Wed, 21 Jan 2026 14:46:58 +0900

들어가며

재택근무시엔 개발자로서 한 가지 질문을 자주 받게 됐다.

“오늘 뭐 하셨어요?”

문제는,
분명 하루 종일 코딩했는데 말로 설명하려니 늘 추상적이라는 점이다.

“버그 좀 잡았고요…”
“리팩토링이랑 구조 정리 좀…”
“코드는 많이 안 늘었는데요…”

이쯤 되면 스스로도 의심이 든다.
“나 오늘 진짜 일한 거 맞나?”

그래서 생각했다.

느낌 말고, 데이터로 말해보자.

이렇게 시작된 프로젝트가
VS Code Extension Haneui-Tracker다.
내 개발 활동을 감정이 아닌 숫자로 보여주는 도구다.

왜 만들었나: 문제 정의 (aka 개발자의 자아성찰)

1. 정량적 성과 측정의 어려움

개발자의 성과는 숫자로 표현하기 참 애매하다.

커밋 수 → 리팩토링은 늘 억울하다
코드 라인 수 → 좋은 코드는 오히려 줄어든다
PR 개수 → 하루 종일 한 PR이 세상을 구할 수도 있다

그럼에도 불구하고,
나의 성장 추이와 실제 활동량은 보고 싶었다.

2. 재택근무의 애매함

재택근무를 하다 보면 이런 순간이 온다.

하루 종일 바빴는데 결과물이 잘 안 보일 때
스탠드업에서 “오늘 뭐 했어요?”가 가장 어려운 질문일 때
스스로 생산성을 관리하고 싶은데 기준이 없을 때

그래서 필요했던 건:

실제 코딩 시간
어떤 언어를 얼마나 썼는지
오늘 손이 얼마나 움직였는지

해결 방향: 그래서 직접 만들었습니다

기존 솔루션도 찾아봤다.
하지만 대부분은 다음 중 하나였다.

서버 기반 → 프라이버시 부담
기능 과다 → 설정하다 하루 종료
VS Code와 미묘한 거리감 → 결국 안 씀

그래서 결론은 하나였다.

로컬에서만 동작하고
VS Code에 완전히 녹아들며
켜두면 알아서 기록되는 도구

없으면?
직접 만든다.

기술적 아키텍처 설계

전체 구조

Extension Entry
   ├─ ActivityTracker   // 내가 뭘 했는지
   ├─ StatsCalculator   // 그래서 얼마나 했는지
   ├─ StorageManager    // 기억력 담당
   └─ UI
       ├─ StatusBar
       ├─ Sidebar
       └─ Dashboard(Webview)

한 줄 요약하면
이벤트는 모으고, 계산은 분리하고, UI는 조용하게.

핵심 컴포넌트

ActivityTracker – 개발자의 모든 움직임 추적

VS Code는 생각보다 많은 이벤트를 제공한다.

onDidChangeTextDocument
onDidSaveTextDocument
onDidChangeActiveTextEditor
onDidChangeWindowState

이걸 잘 엮으면 알 수 있다.

키보드를 치고 있는지
파일을 옮겨 다니는지
아니면 그냥 화면만 보고 있는지

비활성 시간 감지

const IDLE_THRESHOLD = 10 * 60 * 1000; // 10분

커피 마시러 간 시간은 코딩이 아니다
멍 때린 시간도 코딩이 아니다
10분 이상 조용하면 코딩 타이머는 멈춘다

타이머는 정직해야 한다.

라인 수 계산: 생각보다 까다로운 문제

처음엔 이렇게 생각했다.

“라인 수? 그냥 늘어난 줄 세면 되겠지”

완전히 틀렸다.

여러 파일 동시 수정
대량 붙여넣기
삭제 + 추가가 한 이벤트에 섞여 들어옴

그래서 해결책은 다음과 같다.

파일별 마지막 라인 수를 Map으로 관리
변경 전/후를 역산
추가 / 삭제 / 수정 구분 집계

이제야
진짜로 손이 움직인 만큼만 기록된다.

날짜 변경 감지 – VS Code는 잠들지 않는다

VS Code는 며칠이고 켜져 있다.
문제는 날짜는 바뀌는데 앱은 그대로라는 점이다.

마지막 체크 날짜 저장
모든 이벤트에서 날짜 변경 여부 확인
날짜가 바뀌면:
- 어제 데이터 저장
- 오늘 세션 초기화

개발자는 자고 일어나도
데이터는 정확해야 한다.

StorageManager – 기억은 가볍게, 오래

일별 데이터만 저장
주간 / 월간 통계는 실시간 계산
Map / Set → 직렬화 가능한 구조로 변환

오래 써도 무거워지지 않게 설계했다.

Dashboard – 숫자는 시각화되어야 한다

Chart.js + VS Code Webview
언어별 분포 도넛 차트
코딩 시간 추이 라인 차트

VS Code 테마와 자연스럽게 어울리도록 구성했다.

데이터는 많아도
보는 사람은 편해야 한다.

개발하면서 배운 것들

정확함은 늘 대가가 따른다
이벤트 하나 놓치면 통계가 틀어진다
UX는 눈에 안 띄어야 잘 만든 것이다

그리고 무엇보다,

이 Extension을 만들고 나서
“오늘 뭐 했어요?”에
대시보드 스크린샷으로 답하게 됐다.

한계와 개선 계획

현재 Haneui-Tracker는 여전히 발전 중인 도구다.

실사용 과정에서 발견되는 버그와
개선이 필요한 부분들이 분명히 존재하며,
이를 하나씩 해결해 나가며 디벨롭을 이어가고 있다.

이 프로젝트는
“완성된 결과물”이라기보다
지속적으로 다듬어 가는 개발 기록에 가깝다.

성과와 회고

기술적으로

VS Code Extension 구조 이해
이벤트 기반 아키텍처 설계
Webview UI 구현 경험
가벼운 도구를 만드는 감각

개인적으로

내 개발 패턴을 데이터로 인식
재택근무 생산성 관리
“필요한 도구는 직접 만든다”는 경험

마무리

이 프로젝트는 단순한 사이드 프로젝트가 아니다.

문제를 정의하고
도구를 선택하고
실제로 쓰는 제품으로 만든 경험

개발자는 결국
문제를 보고, 귀찮아하고, 결국 직접 만드는 사람이라고 생각한다.

Haneui-Tracker는
그 귀찮음에서 시작된, 꽤 정직한 결과물이다.

GitHub: https://open-vsx.org/extension/haneui-tracker/Haneui-Tracker
Version: 0.0.6
License: MIT

Cursor / VS Code 개발 활동을 기록하는 나만의 익스텐션 만들기 – Haneui-Tracker

인어공쭈 — Mon, 22 Dec 2025 09:51:47 +0900

개발을 하다 보면 가끔 이런 생각이 들 때가 있다.

“오늘 나… 열심히 했나?”

커밋은 없고, 기능은 조금 진전됐고, 시간은 분명 흘렀는데
내가 실제로 얼마나 열심히 했는지는 아무도 알수 없다.

그래서 만들었다.
Cursor / VS Code에서 내 개발 활동을 그대로 기록해주는 익스텐션,
=> Haneui-Tracker

왜 만들었을까?

“오늘 얼마나 했지?”
“내 성과가 궁금해”

이런 궁금증을 Git 커밋 말고, 실제 개발 행위 기준으로 보고 싶었다.

Haneui-Tracker는 커밋 여부와 상관없이 에디터 안에서 실제로 일어난 행동을 그대로 수집하고 시각화한다.

재택근무할 때 특히 좋은 이유

재택근무를 하다 보면 이런 순간이 은근히 많다.

“오늘 뭐 했는지 말로 설명해야 할 때”
“나 스스로도 오늘 제대로 일했는지 애매할 때”
“열심히 했는데, 결과물은 아직 정리 안 됐을 때”

Haneui-Tracker는 이런 상황에서 아주 간단한 증거가 되어준다.

‘활동 증거’로 쓰기 좋다

하루 코딩 시간
실제 타이핑한 키스트로크 수
수정한 코드 라인
어떤 언어를 얼마나 사용했는지

이 모든 게 자동으로 기록된다.

“오늘은 3시간 정도 코딩했고
React 위주로 작업하면서
실제로 이만큼 수정했어요”

같은 설명을 숫자와 그래프로 바로 보여줄 수 있다.

보고용 문서를 만들 필요도 없고,
“열심히 했습니다” 같은 추상적인 말도 필요 없다.

스스로를 점검하기에도 딱 좋다

이 익스텐션이 진짜 좋은 지점은
남을 설득하기보다, 나 자신을 속이지 않게 해준다는 것이다.

“오늘 생각보다 집중 못 했네?”
“오히려 짧게 했는데 밀도는 높았네”
“이번 주는 확실히 JS 비중이 높네”

이런 걸 하루 단위로 가볍게 확인할 수 있다.

KPI용 도구가 아니라
자기 객관화용 대시보드에 가깝다.

부담 없는 기록이라 더 자주 보게 된다

타이머 켤 필요 없음
버튼 누를 필요 없음
설정도 없음

그냥 코딩하면, 기록된다.

그래서
재택근무 중에도 부담 없이 켜두고,
하루 끝나고 “오늘은 이 정도 했구나” 하고 확인하기 좋다.

어떤 걸 추적하나?

1. 개발 활동 추적

에디터에서 일어나는 거의 모든 “손 움직임”을 기록한다.

⏱ 코딩 시간
- 실제 활동 기준
- 10분 이상 비활성 시 자동 중단 → 물 마시러 간 시간은 빼준다
⌨️ 키스트로크 수
- 의미 없는 키 입력이 아니라 라인 단위 기준
편집한 파일 수
➕➖ 코드 라인
- 추가 / 삭제 / 수정 라인 수
언어 분포
- 어떤 언어를 얼마나 썼는지 한눈에

“오늘 React만 했네?”
“아니네, JSON을 제일 많이 썼네…?”

이런 현실 자각도 가능하다

보는 맛이 있어야 기록이지

상태바

코딩하면서 계속 보이는 최소한의 정보

현재 코딩 시간
키스트로크 수

“아… 그래도 2시간은 했구나”
이게 은근히 멘탈에 좋다.

사이드바 (활동 패널)

왼쪽 활동바에 ‘개발 활동’ 패널이 생긴다.

오늘 / 이번 주 / 이번 달 / 전체
트리뷰 형태로 깔끔하게 정리된 통계
우클릭으로 통계 초기화도 가능

웹뷰 대시보드

이 익스텐션의 핵심.

명령 팔레트에서
“개발 활동 통계 보기” 실행하면 대시보드가 열린다.

언어별 키스트로크 분포 (도넛 차트)
일별 코딩 시간 추이 (라인 차트)

숫자로만 보던 걸
“아, 나 진짜 일주일 내내 코딩했네”
라고 느끼게 해준다.

날짜 바뀌는 거… 신경 안 써도 된다

하루 지나서 통계 꼬이는 거 싫어서
날짜 변경 자동 감지를 넣었다.

날짜가 바뀌면
- 이전 날짜 데이터 자동 저장
- 새 날짜로 초기화
단,
- 코딩 시간
- 수정한 라인 수
=> 이 둘은 유지

“오늘 얼마나 쌓였는지” 흐름이 끊기지 않게 설계했다.

개발하면서 신경 쓴 포인트

Cursor / VS Code 둘 다 지원
설정 없이 설치하면 바로 동작
데이터는 로컬 기준 → 개인정보 걱정 없음
차트는 WebView + Chart.js

아직 Git 커밋 통계는 없지만
그건 “의도적으로” 뺐다.

이 익스텐션은
성과를 재는 도구가 아니라, 과정에 집중하는 도구니까.

마무리하며

Haneui-Tracker는
“열심히 했다”는 말을
숫자와 그래프로 증명해주는 작은 도구다.

누군가에게 보여주기 위한 통계가 아니라,
스스로를 속이지 않기 위한 기록에 가깝다.

오늘 커밋이 없어도
오늘의 코딩은 사라지지 않도록.

개발자라면 한 번쯤 써볼 만하다
아직 부족하지만 앞으로도 조금씩 다듬어갈 예정!

Enjoy tracking your coding activity!

React Native CodePush(Hot Updater) 적용기

인어공쭈 — Sat, 20 Dec 2025 20:07:22 +0900

두려워서 시작했는데, 결국 적용해버린 이야기

프론트엔드 개발자로서 가장 무서운 순간이 언제일까.

배포 버튼을 누를 때
금요일 오후에 긴급 이슈가 터졌을 때
그리고 스토어 심사를 다시 기다려야 한다는 걸 깨달았을 때

영끌 앱을 운영하면서 이 모든 순간을 다 겪었다.
특히 모바일 앱은 웹과 달리 “한 번 나가면 바로 고치기 어렵다”는 점에서
항상 묘한 긴장감을 안고 있었다.

그러다 자연스럽게 이런 생각이 들었다.

“웹처럼, 조금 고치고 바로 반영할 수는 없을까?”

처음엔 Hot Updater가 아니었다

사실 처음부터 Hot Updater를 쓰려던 건 아니다. 비교적 단순한 revopush라는 서비스를 사용했다.

하지만 현실은 예상보다 빠르게 나를 때렸다.

iOS 수정 → Android에서 문제 발생
Android 수정 → iOS에서 다시 문제 발생

하루는 iOS가 멀쩡했고,
다음 날은 Android가 멀쩡했다.
둘 다 멀쩡한 날은 없었다.

그때 깨달았다.
문제를 해결하는 게 아니라 확률 게임에 가까웠다.

그래서 다시 마주한 Hot Updater

이전부터 알고는 있었지만 미뤄왔던 이녀석을
다시 꺼내 들었다.

솔직히 말하면 여전히 무서웠다.

잘못 배포하면 모든 유저에게 동시에 영향
플랫폼별 미묘한 차이

하지만 한 가지는 분명해졌다.

지금 방식이 더 위험하다.

핫 업데이트가 무서운 게 아니라,
통제할 수 없는 배포가 무서운 거였다.

그래서 CodePush를 “편의 기능”이 아니라
통제 가능한 배포 수단으로 설계하기로 했다.

적용하면서 가장 신경 쓴 것들

1. 핫 업데이트의 범위를 명확히 정하기

모든 걸 CodePush로 해결하려는 순간 사고가 난다.

UI 수정
텍스트 변경
경미한 비즈니스 로직 수정

이 정도까지만 허용했다.
네이티브 영역이나 구조 변경은 절대 금지.

웹처럼 쓰되, 웹처럼 믿지는 말자.

2. 플랫폼별 분리와 롤백 전략

이전의 가장 큰 문제는
iOS와 Android를 한 번에 묶어버린 것이었다.

플랫폼별 배포 분리
항상 이전 안정 버전 유지
문제 발생 시 즉시 롤백 가능하도록 설계

이때 처음으로
프론트엔드도 배포 전략을 설계해야 한다는 걸 실감했다.

3. 운영 관점에서의 안정화

CodePush를 “적용했다”로 끝내지 않았다.

플랫폼별 동작 차이 체크
업데이트 타이밍에 따른 UX 검증

적용하고 나서 달라진 것들

가장 큰 변화는 이거였다.

긴급 이슈 대응 속도
CS 대응 시간
그리고 배포에 대한 두려움

스토어 재배포 없이
그날 안에 문제를 해결할 수 있다는 것은
운영하는 입장에서 엄청난 안정감을 줬다.

무엇보다 좋았던 건,

“프론트엔드가 단순 구현자가 아니라
서비스 운영의 한 축이 되었다”

라는 감각이었다.

마무리하며

CodePush는 여전히 조심스럽다.
지금도 배포할 때마다 한 번 더 확인한다.

하지만 분명한 건,

레포 푸시로 겪은 시행착오 덕분에
배포를 더 진지하게 고민하게 되었고
그 결과 CodePush를 제대로 설계할 수 있었다

두려웠지만,
그래서 더 공부했고
그래서 더 안전해졌다.

프론트엔드 개발자로서
“화면을 만드는 사람”을 넘어
“서비스를 안전하게 운영하는 사람”이 되게 만든 경험

그게 내 핫 업데이트 적용기다.

HOxy, 프론트 개발자가 경험한 혹시 주도 개발(Feat: Server-Driven UI)

인어공쭈 — Mon, 17 Nov 2025 14:54:25 +0900

빠르게 변하는 서비스에서 Server-Driven UI가 왜 핵심이었나

HOxy(혹시) 개발을 진행하면서 가장 크게 필요했던 것은
UI 구조를 서버 정책 변화에 의존하게 만들지 않는 것,
즉 server-driven UI 기반의 확장 가능 구조였습니다.

기획 변경이 하루에도 몇 번씩 들어오는 환경에서
“앱을 다시 빌드해야만 반영되는 구조”는 더 이상 유지가 불가능했습니다.

그래서 프론트의 모든 UI 흐름을
정책 플래그, 서버 응답, 동적 레이아웃 정보로 제어할 수 있도록 만들었습니다.

아래는 실제로 활용했던 server-driven UI의 핵심 개념과 구현 방식 입니다. 간략하게 설명하고자 ~이다 체로 변경할께요 : )

Server-Driven UI가 필요한 이유

일반적인 모바일 앱에서 UI는 코드에 강하게 묶여 있다.

버튼 노출 조건
화면 이동 플로우
특정 상태의 예외 처리
CTA 기능의 정책 변경
문구/레이아웃 변경

이 모든 것이 “코드 → 빌드 → 배포” 과정을 거쳐야 한다.

하지만 HOxy처럼 정책이 자주 바뀌는 서비스는 이 방식으로는 절대 따라갈 수 없다.
그래서 방향을 바꿨다:

‘UI는 서버가 결정하고, 앱은 렌더링만 한다’
이게 HOxy에서 적용한 server-driven UI 근간이다.

Server-Driven UI 구조 설계

1) Policy Layer: 정책을 하나로 묶는 중앙집중 모듈

가장 먼저 한 일은 정책·조건문·분기 로직을 모두 UI 컴포넌트에서 제거하는 것이었다.

대신 모든 정책은 아래 형태의 중앙 모듈에서 처리한다.

UI는 정책을 “실행”만 한다.

이렇게 되면:

정책이 바뀌면 정책 레이어만 수정
화면 코드 변경 없음
테스트 범위 명확해짐
서버 정책 변경 시 즉시 반영 가능

= 빌드 없는 정책 변경이 가능해진다.

2) Server Response 기반 UI 전략 자동화

정책 레이어가 방향을 잡아준다면,
실제 흐름은 서버 응답이 결정하게 만들었다.

예를 들어 서버 응답이 아래처럼 온다고 하자.

{
  "status": "BLOCKED",
  "nextAction": "OPEN_MODAL",
  "modalType": "VERIFICATION_REQUIRED"
}

앱에서는 아래처럼 자동으로 전략을 조립한다.

switch (response.status) {
  case 'BLOCKED':
    if (response.nextAction === 'OPEN_MODAL') {
      openModal(response.modalType);
    }
    break;
  case 'OK':
    navigate('Home');
}

즉,

어떤 모달을 띄울지
어떤 화면으로 이동할지
CTA 버튼이 어떤 기능을 수행해야 하는지

전부 서버가 준 instruction대로 렌더링만 한다.

이 방식은 기획 변경이 심할수록 진가를 발휘한다.

이 구조가 결국 “주도 개발”을 만들어냈다

Server-Driven UI는 단순히 UI 기술이 아니라
서비스 전체 흐름을 설계하는 방식이다.

이 구조를 프론트에서 설계하면서 자연스럽게 이런 질문이 나에게 모이기 시작했다.

어떤 정책이 우선순위를 가져야 하는지
API가 어느 범위까지 UI 정책을 책임져야 하는지
특정 사용자 상태에서 어떤 흐름이 맞는지
플래그 조합이 충돌할 때 어떤 전략을 띄워야 하는지

즉,
프론트에서 server-driven 구조를 설계하는 순간,
정책·기획·흐름·데이터 구조까지 책임지는
주도 개발의 중심에 서게 된다.

HOxy에서의 server-driven UI 도입은 단순히 “유연한 UI” 문제가 아니었다.

빠른 기획 변경 대응
재배포 없는 정책 수정
UI 전략 자동화
예외 케이스 통일
모듈 단위 재사용성 증가
유지보수 비용 절감

그리고 무엇보다,

프론트엔드인 내가 서비스의 흐름을 정의하는 주체가 될 수 있게 만든 방식이었다.

“React는 게임엔 안 맞다.” 그래서 만들어봤습니다.

인어공쭈 — Wed, 12 Nov 2025 18:06:16 +0900

React로 만든 “하리니 오락실” 제작 썰

“아니, 프론트 개발자가 오락실을 만든다고?”
네, React로요. 그리고 또 1등했습니다.

하리니 오락실의 정체

하리니 오락실은 영끌 앱 안의 미니게임 센터예요.
“앱 안에 오락실이 있다고요?”
네, 광고도 노출하고, 포인트도 쓰고,
유저도 붙잡는 일석삼조 프로젝트입니다.

목표 요약하면 이렇습니다

리텐션 확보 — “하리니 보러 매일 출근각”
광고 구좌 확보 — “죽었을 때 광고 보면 부활 (상술의 미학)”
포인트 소진 — “이왕이면 즐겁게 소비하게 하자”
체류시간 확보 — “유저가 앱에서 못 나가게 하자 ”

PM님이 한 줄로 정리했습니다.
“유저의 시간을 뺏자. 착하게.”

게임 두 개, 미친듯이 단순하게

React로 FPS 떨어지는 순간, 그건 게임이 아니라 슬라이드쇼입니다.
그래서 단순함 + 몰입감 + 중독성 이 세 가지를 목표로 했어요.

1) 바구니 캐치 (Basket Catch)

하늘에서 과일이 떨어집니다.
유저는 바구니를 좌우로 흔듭니다.
그리고… 폭탄도 떨어집니다.

사과 : +100점
오렌지 : +80점
폭탄 : -1 생명
불 : 속도 미쳤음 (벌받음)

게임이 단순하다고요?
근데 3판만 하면 알 거예요.
이게 왜 멈출 수 없는지.

2) 하리니 쌓기 (Harini Stack)

블록이 좌우로 왔다갔다,
클릭하면 “착”하고 쌓입니다.
살짝만 삐끗하면 “짤림”

Perfect Stack을 성공하면
하리니가 “헤헤~ 잘했어” 하는데,
그 순간 도파민이 쏟아집니다.

“이거 React로 만들었다는 게 말이 되냐고요”
→ 됩니다. 커서와 함께라면..ㅋㅋ

Canvas와 React, 그 위험한 동거

React는 화면 리렌더링을 사랑하고,
Canvas는 그걸 극도로 싫어합니다.

결국 이렇게 결론 내렸죠:

“React야, 넌 UI만 해. Canvas는 내가 그릴게.”

export class GameEngine {
  update(dt) {
    this.updatePlayer(dt);
    this.updateItems(dt);
  }

  render() {
    this.ctx.clearRect(0, 0, this.canvas.width, this.canvas.height);
    this.renderPlayer();
    this.renderItems();
  }
}

하루 10판 제한 시스템

유저들이 미친 듯이 플레이하면
서버비도, 정신도 타들어가요.

그래서 하루 10판만 가능하게 했습니다.

Zustand + localStorage로 간단하게 구현했는데,
이게 또 은근히 UX에 영향을 줘요.

10판 끝나면 하리니가 나와서 말하죠.

“이봐요, 쉬었다 하죠 ☕ (친구 초대하면 한 판 더!)”

→ 사람들은 안 쉽습니다.

랭킹 시스템: 사람의 경쟁심은 무료가 아닙니다

하루 종일 게임하다가 랭킹창 눌러보면
“내 점수 2등이네?”
→ 5분 후 1등 빼앗김
→ 10분 후 다시 접속

Retention 확보 성공

Prisma ORM으로 groupBy 쿼리 날리며,
“이게 진짜 DB에서 되는구나” 감탄했습니다.

const rankings = await prisma.score.groupBy({
  by: ["userId"],
  _max: { score: true },
  orderBy: { _max: { score: "desc" } },
  take: 50,
});

랭킹이 실시간으로 오를 때,
그게 진짜 하리니 오락실의 dopamine trigger입니다.

버그는 게임의 일부였다

아이템이 너무 많이 떨어져서 FPS 20 → Object Pooling 도입
모바일 터치가 300ms 느림 → passive: false

반응형 & 터치 대응

Canvas 크기 조정은 지옥이었습니다.
기기마다 픽셀 비율이 달라서
“하리니 머리가 길어졌다 짧아졌다” 반복

결국 devicePixelRatio 기반으로 정규화.
지금은 모든 기기에서
하리니가 일정합니다. (감격)

결과: 또 1등 했다

“부틀리 게임센터 1등 발표합니다.”

프로젝트: 하리니 오락실

부틀리 시간 몇 시간으로 AI 챗봇을 엔드투엔드 구현한 이야기

인어공쭈 — Mon, 10 Nov 2025 15:38:39 +0900

React로 시작해 인턴을 만들었습니다

AI 챗봇 ‘하리니’ 개발 회고

이미 몇달이나 지나서 앱에 올라갔지만 그냥 넘어가긴 아쉬워서 쓰는 글

부틀리(Bootly): 하고 싶은 걸 해보는 시간

저희 회사에는 부틀리(Bootly)라는 문화가 있습니다.
한 달에 한 번, 정해진 토픽 아래 일주일에 몇 시간 정도를 본업 외의 무언가에 도전해보는 시간이죠.
누군가는 새로운 기능을 실험하고, 누군가는 데이터를 분석하거나 디자인을 다시 뜯어봅니다.

저는 이번에, 조금 다른 걸 해보기로 했습니다.

“CX팀을 도와줄 챗봇을 직접 만들어보자.”

CX의 한숨에서 시작된 프로젝트

시작은 단순했습니다.
옆자리 CX 담당자분이 “오늘도 문의가 너무 많아요…”라고 말하던 그날.
유저 수는 빠르게 늘고 있었고, 매일 쏟아지는 문의는 하루를 꽉 채우고 있었습니다.

그 말을 듣고 문득 생각했습니다.

“이건 진짜 자동화가 필요하겠다.”

그래서 CX 담당자분과 함께 ‘우리만의 CX 챗봇’을 만들어보기로 했습니다.
기획은 CX팀이, 개발은 제가 맡았습니다.

“인턴 하리니”의 탄생

이름은 ‘인턴 하리니’.
처음엔 정말 인턴처럼, 어설프지만 성실했습니다.

목표는 단 하나.
반복되는 FAQ 문의를 대신 응대해, CX팀이 더 중요한 일에 집중할 수 있도록 하는 것.

한 달 동안 다음을 진행했습니다:

CX 데이터 분석 및 FAQ JSON 구축
사용자 문의 패턴 정리
Gemini 기반 LLM 연동
프론트(React) + 백엔드(Express) 구현

기술적인 구성

Frontend

React + TypeScript
간단한 채팅 UI, 입력/응답 인터랙션
상태 관리 및 로딩 처리

Backend

Express + Node.js
/classify: 문의 내용 분류
/response: 카테고리 기반 답변 반환
LLM: Google Gemini 2.0 Flash

Data Layer

CX팀이 직접 정제한 FAQ JSON
각 항목별 카테고리, 키워드, 응답 텍스트 구조화

const classifyInquiry = async (text) => {
  const keywords = await gemini.extractKeywords(text);
  const matched = faq.find((item) =>
    item.keywords.some((k) => keywords.includes(k))
  );
  return matched?.response || "이건 조금 더 공부 중이에요  ";
};

Google ADK로 cs_ai_agent 구현

챗봇을 한 단계 업그레이드하기 위해 **Google ADK(Agent Development Kit)**를 사용했습니다.
FAQ와 VOCS 데이터를 instruction에 넣어, 반복되는 문의를 자동으로 처리하도록 설계했죠.

구현 방식: instruction embedding → RAG/벡터 검색 없이 단순 구현
모델: Gemini 2.0 Flash
데이터: FAQ 40개+, VOCS 1800개+
실행: InMemoryRunner를 사용, 비동기 스트리밍으로 실시간 응답

장점: 단순, 빠른 프로토타입 가능
한계: 데이터가 늘어나면 토큰 사용량 증가, RAG 전환 필요

결과: 부틀리 1등, 그리고 상용화

한 달 뒤, 이 프로젝트는 부틀리 1등으로 선정되었습니다.
그리고 다른 기획자, 백엔드, AI 담당자분들이 합류해
‘인턴 하리니’는 정식 앱 기능으로 상용화되었죠.

지금은 유저의 문의를 자동으로 처리하고,
CX팀의 하루를 조금 더 여유롭게 만들어주고 있습니다.

회고: 중요한 건 ‘관찰’

이 프로젝트를 하면서 가장 크게 느낀 건,
좋은 아이디어는 꼭 회의실에서 나오지 않는다는 점이었습니다.

옆자리의 한숨, “이거 좀 불편해요” 같은 말 한마디가
가장 강력한 문제 정의가 될 수 있습니다.

그걸 기술로 해결해보는 시도
그게 결국 개발자의 재미 아닐까요?

마무리하며

React로 시작해 인턴을 만들 줄은 몰랐습니다.
하지만 덕분에, 기술이 사람을 돕는 방식에 대해 다시 생각하게 됐습니다.

“코드는 결국, 옆자리 사람을 도와주는 도구다.”

다음 부틀리에서는 또 어떤 실험이 탄생할지, 기대가 됩니다 :)

혼자서 상위 1% 앱을 살려냈다? 프론트엔드 개발자의 피 땀 눈물 마이그레이션 생존 보고서!

인어공쭈 — Thu, 17 Jul 2025 12:03:20 +0900

웹 개발자가 앱 마이그레이션을 맡으면 생기는 일 .zip

“안녕하세요, 5년차 웹 프론트엔드 개발자입니다.”

“아, 그럼 앱도 할 줄 아시겠네요?”

”(??!?!!)”

그 말을 들은 날, 제 React Native 설치 창에는 npm install과 함께 신호 없이 찾아온 여정이 열렸습니다.

React Native 처음 써봤습니다. 말 그대로 처음

처음엔 그냥 웹처럼 div, className, px 단위 쓰면 되겠지~ 싶었습니다.

네, 바로 뚝배기 맞았습니다. React Native에는 div도 없고, className도 없고, px도 그냥 무시당합니다.

대신 View, Text, StyleSheet.create() 같은 낯선 친구들과 친해져야 했고, 어느샌가 저는 “Metro 번들러가 터졌을 때는 캐시부터 지워보자”는 신념을 가진 개발자가 되어 있었습니다.

구조 파악부터 컴포넌트 분해까지

기존 앱은 Flutter 기반이라 구조가 전혀 달랐고,

이를 RN으로 옮기기 위해선 먼저 전체 플로우와 UI 구조를 세세하게 분석해야 했습니다.

라우팅 방식 다름 → React Navigation으로 재구성
스크롤/페이지 전환 UX → Flutter처럼 구현하려면 커스텀 작업 필요
컴포넌트 분리 기준 → 재사용성 vs platform specific 분기 처리
WebView ..ㅠㅠ

이걸 혼자 하려니, 하루에 폴더 구조만 3번 뒤엎은 날도 있었습니다.

“내가 만든 코드인데 내가 이해 못하는 느낌...”

크로스 플랫폼 = 같은 코드, 다른 버그 (참 쉽죠?)

RN은 하나의 코드베이스로 Android와 iOS를 모두 지원합니다.

…라는 말은 이론이고요. 실제로는:

iOS에선 잘 되는데 Android에선 깜빡임
Android에선 터지는데 iOS에선 멀쩡
시뮬레이터에선 되는데 실기기에선 죽음
됐다가 갑자기 안됌

“어디서 분명 된다는데, 왜 나는 안 되지?”라는 자문을 하루 3번씩 하게 됐고, 결국 Platform.OS 조건문을 코드 곳곳에 심으며 종교처럼 외웠습니다:

“이건 Android 때문이야. 분명히 그래. (iOS일 수도 있지만…, 도 아닐 수도 있지만...)”

디바이스 반응형 이슈: 내 앱이 왜 씹히죠...?

웹에서는 media query 한 줄이면 끝나던 반응형.

앱에서는 아이폰 미니, 삼성 폴드, 플립 등 다 따로 놀며 SafeArea가 아니라 Danger Zone이었습니다.

iPhone 13 mini: 버튼이 잘려서 못 누름
폴드, 플립: 텍스트가 뭉개짐

그제서야 깨달았습니다. 앱 개발자들이 테스트폰을 5대씩 쌓아두는 이유는 그냥 멋이 아니었다는 걸.

useWindowDimensions, percentage-based layout, SafeAreaView, StatusBar, FlatList 등 온갖 키워드를 던지며, 결국은 화면 비율별 조건 분기라는 폭풍 속으로 빠져들었습니다.

디버깅은 고행이었고, 캐시는 배신자였다 (feat. 삽질의 연속)

웹에서는 새로고침이면 되던 걸, 앱에서는 npm start --reset-cache, npx pod-install, gradlew clean 등 주술급 명령어를 외워야만 했습니다.

iOS는 Xcode가 삐지면 30분 날아가고, Android는 에뮬레이터 하나 띄우는 데도 메모리와 싸워야 했습니다.

하루에 앱을 10번은 지웠다 깔고, “도대체 뭐가 문제야…”라는 말을 매일 중얼거렸습니다.

그러다 보니깐 주술급 명령어들을 어느순간 다 외워지는... SUPER MAGIC

그럼에도 앱스토어에 올라갔습니다. 나름(?) 당당하게.

이 모든 던전 클리어 끝에 앱스토어에 배포 완료.

그때 깨달았죠.

‘개발자란, 코드를 잘 짜는 사람이 아니라 끝까지 버티는 사람이다.’

‍ 웹 개발자의 앱 도전, 그 이후

이번 경험 덕분에 React Native라는 새로운 영역에서 한 뼘 더 성장할 수 있었고, 무엇보다 “나도 앱 만든 사람이다”라는 자신감이 생겼습니다. 아직도 앱을 열 때마다 감회가 새롭습니다. “와 이걸 내가 만들었어?” 하면서요.

끝으로 한 마디만…

웹 개발자라고 앱 못 만드는 거 아니잖아요. 다만, 약간의 멘탈 관리 능력은 필수입니다.

고군분투 했던 저의 앱이 궁금하신 분들은 아래를 보고 다양한 피드백 부탁드립니다~!

https://play.google.com/store/apps/details?id=com.FhTArrLMPEaw.natively&hl=ko

영끌 - 영수증 끌어모아 포인트 적립 - Google Play 앱

영끌, 영수증 끌어오면 돈이 된다!

play.google.com

RN - 프론트엔드 개발자를 위한 모바일 앱 개발 가이드

인어공쭈 — Wed, 26 Feb 2025 16:31:09 +0900

1. React Native란?

React Native(RN)는 React 기반의 크로스플랫폼 모바일 앱 개발 프레임워크이다. JavaScript 및 TypeScript를 사용하여 iOS와 Android 앱을 동시에 개발할 수 있도록 해준다.

주요 특징

크로스플랫폼 개발: 하나의 코드베이스로 iOS, Android 동시 개발 가능
네이티브 성능: React와 네이티브 코드를 결합하여 최적화된 성능 제공
핫 리로드(Hot Reload): 코드 변경 시 앱을 새로 실행하지 않고 바로 반영
풍부한 라이브러리 지원: Expo, React Navigation, Redux 등과 호환
광범위한 커뮤니티: Meta 및 오픈소스 커뮤니티에서 활발히 유지보수됨

2. React Native의 기본 구조

React Native 앱의 주요 구조는 다음과 같다:

  MyReactNativeApp
 ┣ android  // 안드로이드 네이티브 코드
 ┣ ios       // iOS 네이티브 코드
 ┣ src       // 앱의 주요 React Native 코드
 ┣ assets    // 이미지, 폰트 등의 정적 파일
 ┣ components // 재사용 가능한 UI 컴포넌트
 ┣ screens   // 각 페이지별 화면 구성
 ┣ navigation // 앱 내비게이션 설정
 ┣ App.js    // 앱의 진입점
 ┗ package.json  // 프로젝트 설정 파일

3. React Native 설치 및 환경 설정

React Native는 Expo와 React Native CLI 두 가지 방식으로 설치할 수 있다.

3.1 Expo를 사용한 설치 (쉬운 방법)

Expo는 빠르게 React Native 프로젝트를 시작할 수 있는 도구로, 네이티브 빌드를 직접 하지 않아도 된다.

npx create-expo-app MyApp
cd MyApp
npm start

3.2 React Native CLI를 사용한 설치 (커스텀 가능)

네이티브 코드를 직접 다룰 필요가 있다면 React Native CLI를 사용한다.

npx react-native init MyApp
cd MyApp
npx react-native run-android # 안드로이드 실행
npx react-native run-ios # iOS 실행

4. React Native의 주요 개념

4.1 JSX 및 컴포넌트 기반 개발

React Native는 JSX 문법을 사용하며, 컴포넌트 기반 개발을 한다.

import React from 'react';
import { View, Text, StyleSheet } from 'react-native';

const App = () => {
  return (
    <View style={styles.container}>
      <Text style={styles.text}>Hello, React Native!  </Text>
    </View>
  );
};

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center', backgroundColor: '#f0f0f0' },
  text: { fontSize: 20, color: '#333' }
});

export default App;

4.2 React Navigation (내비게이션)

React Native에서 화면 이동을 관리하려면 react-navigation을 사용한다.

import { NavigationContainer } from '@react-navigation/native';
import { createStackNavigator } from '@react-navigation/stack';

const Stack = createStackNavigator();

const App = () => {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen name="Home" component={HomeScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
};

JavaScript - 리스트 매핑시 여러가지 방법

인어공쭈 — Wed, 11 Dec 2024 14:31:33 +0900

<주요 이슈 요약>

⇒ 금액이 0보다 큰 금액이 있는 결제 SEQ 를 취소를 해야 하는 데, 0인 SEQ 는 제외해서 매핑

⇒ TASF 빼고 RV의 합산금액을 초과할수 없다. 취소가능금액 해당 payment 에 가능금액으로 RV 합산금액과 비교해서 사용

따라서 리스트를 매핑하는 과정에서 다양한 방법이 존재하길래 한번 정리해보았다.

onClickSave() {
    if (this.putForm.invalid || this._checkCancelAmountExceeds()) {
      this._checkValid = true;
      return;
    }

    const cancelItems = this.payments.value.flatMap((item) =>
      item.transactions
        .filter((transaction) => transaction.cancelAmount > 0 && transaction.cancelAmount != null) // 값이 없거나 0인 경우 제외
        .map((transaction) => ({
          test: transaction.test,
        })),
    );
    this.submitEvent.emit({ cancelItems });
  }

  private _checkCancelAmountExceeds() {
    const exceededPayments = this.payments.value.filter((payment) => {
      const airrvTransactions = payment.transactions.filter(
        (transaction) => transaction.typeCode === 'OK',
      );
      const totalCancelAmount = airrvTransactions.reduce(
        (sum, transaction) => sum + (transaction.cancelAmount || 0),
        0,
      );
      return totalCancelAmount > payment.cancelableAmount;
    });
    return exceededPayments.length > 0;
  }

대안 1: reduce를 사용한 방식

const cancelItems = this.payments.value.reduce((acc, item) => {
  const transactions = item.transactions.map((transaction) => ({
    test: transaction.test,
  }));
  return acc.concat(transactions);
}, []);

대안 2: for...of 반복문을 사용한 방식

const cancelItems = [];
for (const item of this.payments.value) {
  for (const transaction of item.transactions) {
    cancelItems.push({
          test: transaction.test,
    });
  }
}

대안 3: map과 concat 조합 방식

const cancelItems = [].concat(
  ...this.payments.value.map((item) =>
    item.transactions.map((transaction) => ({
        test: transaction.test,
    }))
  )
);

간단하게 테스트 코드를 작성해보았는데 여러가지 방법이 있지만 가독성 및 효율을 따져서 나의 픽은 flatMap 이었다.

flatMap 과 reduce 는 잘 안쓰는 메서드 였는데 이번기회에 잘알게 되어서 좋은 경험이었다. 굳굳

JavaScript - About 비동기, AJAX란?

인어공쭈 — Tue, 10 Dec 2024 13:53:49 +0900

AJAX란 무엇인가?

AJAX는 "Asynchronous JavaScript And XML"의 약자로, JavaScript를 사용하여 서버와 비동기적으로 데이터를 주고받는 기술이다. 비동기 처리를 통해 웹페이지 전체를 새로고침하지 않고도 필요한 데이터를 서버로부터 받아올 수 있다. 이로 인해 사용자 경험(UX)이 크게 향상된다.

AJAX의 동작 원리

AJAX는 클라이언트(브라우저)와 서버 간의 비동기 데이터 통신을 관리하는 메커니즘으로 다음의 단계로 동작한다.

클라이언트 요청:
- JavaScript가 서버로 요청을 보냅니다.
- 요청은 비동기적으로 수행되며, 웹페이지가 새로고침되지 않는다.
서버 처리:
- 서버는 클라이언트 요청을 처리하고, 데이터(예: JSON, XML)를 생성.
클라이언트 응답:
- 서버로부터 응답 데이터를 받아 웹페이지의 특정 부분을 동적으로 업데이트.

이 과정에서 전체 페이지가 다시 로드되지 않기 때문에 사용자는 더 빠르고 유연한 경험을 할 수 있다.

AJAX 구현을 위한 주요 도구

AJAX는 특정 기술이 아니라 여러 도구와 개념의 조합이다. 다음은 AJAX를 구현하는 데 사용되는 주요 도구들이다.

1. XMLHttpRequest

AJAX 구현을 위한 초기 기술이다. 비동기적으로 서버와 통신할 수 있도록 설계되었다. 하지만 사용법이 복잡하고, 코드가 길어질수록 "콜백 지옥" 문제를 초래할 수 있다.

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.example.com/data', true);

xhr.onload = function () {
  if (xhr.status === 200) {
    console.log('Response:', xhr.responseText);
  }
};

xhr.send();

2. Fetch API

Fetch API는 XMLHttpRequest의 현대적인 대안으로, Promise 기반으로 설계되어 비동기 작업을 더 간결하게 처리할 수 있다.

fetch('https://api.example.com/data')
  .then((response) => response.json())
  .then((data) => console.log('Data:', data))
  .catch((error) => console.error('Error:', error));

3. Promise

Promise는 비동기 작업의 결과를 나타내는 객체이다. AJAX 요청 후 서버 응답을 처리하거나 에러를 처리하는 등의 작업을 체계적으로 관리할 수 있다.

const getData = () =>
  new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve('Data received');
    }, 1000);
  });

getData()
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

4. Async/Await

Async/Await은 Promise를 기반으로 하여 비동기 작업을 동기 코드처럼 읽기 쉽게 작성할 수 있도록 도와준다. Fetch API와 함께 사용하면 더욱 간결하게 AJAX 요청을 처리할 수 있다.

const fetchData = async () => {
  try {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    console.log('Data:', data);
  } catch (error) {
    console.error('Error:', error);
  }
};

fetchData();

AJAX의 장점과 단점

장점

새로고침 없는 데이터 업데이트: 필요한 부분만 업데이트하므로 빠르고 유연한 사용자 경험을 제공한다.
효율적인 데이터 전송: 전체 페이지를 다시 로드하지 않으므로 데이터 전송량이 줄어든다.
다양한 데이터 형식 지원: JSON, XML, HTML, 텍스트 등 다양한 데이터 형식을 주고받을 수 있다.

단점

Cross-Origin 제한: 기본적으로 동일 출처(Same-Origin) 정책을 따르므로, 다른 도메인과 통신하려면 CORS 설정이 필요하다.
SEO 문제: 클라이언트에서 동적으로 데이터를 로드하므로, 검색 엔진이 콘텐츠를 인덱싱하지 못할 수 있다.
구형 브라우저 호환성: Fetch API와 같은 최신 기술은 구형 브라우저에서 지원되지 않는다.

AJAX와 함께 사용되는 데이터 형식: JSON

AJAX에서 가장 많이 사용되는 데이터 형식은 **JSON(JavaScript Object Notation)**이다. 가볍고 구조화된 데이터를 처리하기에 적합하다.

{
  "name": "John Doe",
  "age": 30,
  "email": "john.doe@example.com"
}

JSON 데이터를 처리하는 JavaScript 코드 예제:

fetch('https://api.example.com/user')
  .then((response) => response.json())
  .then((data) => {
    console.log(data.name); // John Doe
  });

비유로 이해하기

AJAX를 비동기 통신의 철학이라고 생각하고, 그 위에 쌓인 도구들을 기술 스택으로 이해해보자

AJAX는 비동기 데이터 통신의 기본 철학.
XMLHttpRequest는 AJAX를 구현하기 위해 처음 만들어진 기술.
이후 등장한 Fetch API는 AJAX 구현을 더 간단하게 만든 현대적 도구.
Promise는 AJAX 요청을 관리하고 비동기 작업을 체계적으로 처리하기 위한 메커니즘.
Async/Await은 Promise를 쉽게 사용하기 위한 더 간단한 문법.