eXemble

온프레미스로 여러 고객사에 설치하는 AI 통합 플랫폼. 사용자는 기능 단위인 노드를 캔버스에 이어 붙여 AI 업무 흐름(워크플로우)을 만들고, 채팅으로 바로 실행합니다. 워크플로우와 AI 채팅의 FE 설계/개발을 담당하고, 2026년 1분기부터 FE 파트(3명)를 리딩하고 있습니다. 2025.12 v1.0 출시.

🔗 eXemble 서비스 소개 →

스택 React 19 TypeScript React Flow Zustand Zod TanStack Query SSE Vitest

---

[워크플로우] 노드 확장 구조 설계

2025.09 ~ 현재

배경

워크플로우는 기능 단위인 노드를 이어 붙여 만들고, 고객사 요구가 들어올 때마다 노드 종류가 늘었습니다. 그런데 노드 하나를 추가하거나 수정하려면 여러 공통 파일을 함께 고쳐야 했고, 한 곳을 빠뜨려도 빌드 에러가 나지 않았습니다. 누락은 메뉴에 노드가 보이지 않거나 설정이 사라지는 식으로, 실행해 봐야 드러났습니다.

어떻게 풀었나

• 노드가 불필요하게 늘지 않도록, 요구가 들어오면 FDE(고객사 현장 엔지니어)와 요구가 나온 배경을 먼저 확인하고 새 노드를 만들지, 기존 노드의 기능으로 넣을지 판단했습니다. 예를 들어 재시도 노드를 만들어 달라는 요구는 모든 노드가 가지는 공통 설정으로 설계했습니다.
• 노드 하나의 설정·검증·서버 변환이 공통 파일 여러 곳에 흩어져 있던 구조를, 노드 폴더 하나에 모으고 공통 파일에는 짧은 선언만 남기는 Registry 구조로 재설계했습니다. 이제 기존 노드를 고칠 때는 해당 노드 폴더만 수정하면 됩니다.
• 새 노드를 추가 메뉴에 등록하지 않아도 빌드가 통과하던 문제는, 등록을 TypeScript 타입으로 강제해 빠뜨리면 실행 전에 컴파일 에러가 나는 구조로 바꿨습니다.
• 누가 추가하든 같은 절차와 규칙을 따르도록, 새 노드에 필요한 결정을 차례로 묻고 코드 골격과 테스트까지 만들어 주는 노드 추가용 Agent Skill을 만들었습니다.

결과

• 지원 노드 종류 2배 이상, 2026년 1분기 워크플로우 기능 개선 20건 이상 출시
• 팀원들도 같은 방식으로 새 노드(이메일·차트 등)를 추가
• 노드 등록 누락이 실행 전 컴파일 단계에서 드러나는 구조

📝 노드 구조 설계 과정 자세히 보기 →

[편집기 사용성] 워크플로우 편집기 사용성 개선

2026.01 ~ 현재

워크플로우를 처음 만드는 사용자와 매일 쓰는 사용자 모두 편집기에서 막히지 않도록, 불편한 지점을 짚어 개선안을 제안하고 구현했습니다.

• 처음 쓰는 사용자도 노드를 바로 추가할 수 있도록, 참고 제품(n8n)의 노드 추가 방식을 분석해 빈 캔버스 안내와 + 버튼으로 노드를 추가하는 흐름을 제안 문서로 정리하고 작업 단위로 나눠 구현했습니다.
• 편집하던 워크플로우에 다시 들어오면 복원 여부를 묻는 창이 먼저 떠 작업 흐름이 끊겼습니다. 묻지 않고 자동으로 복구한 뒤 알려주는 방식으로 바꾸고, 여러 탭에서 서로 섞이던 초안도 워크플로우별로 분리했습니다.
• 실행 중 잘못된 값을 발견해도 실행 화면이 읽기 전용이라 그 자리에서 고칠 수 없었습니다. 편집 화면 하단에 채팅·실행 로그·노드 값 패널을 추가하고 노드마다 실제로 받은 입력과 낸 출력을 보여줘, 실행 결과를 보면서 바로 값을 고칠 수 있는 화면으로 개선했습니다.

[AI 채팅] 스트리밍 규약 설계와 연결 안정화

2025.10 ~ 2026.08

배경

질문 하나에 워크플로우가 10~30초 실행되는 동안 실행 계획, 노드 진행, 답변, 참고 문서를 함께 보여줘야 했습니다. 이후 근거 자료, 중단, 테스트 채팅 같은 요구가 계속 더해졌습니다.

어떻게 풀었나

• 주요 AI 서비스의 스트리밍 방식을 비교한 뒤, 서버가 답변을 보내기만 하면 되는 흐름이라 WebSocket 대신 SSE를 택했습니다. 답변 텍스트·참고 문서·노드 실행 상태를 메시지 종류로 구분하고, 새 기능이 생기면 기존 코드를 고치지 않고 메시지 종류만 추가하면 되는 규약을 설계해 발표하고 백엔드와 합의했습니다. 이후 분기 노드가 추가됐을 때도 기존 코드 수정 없이 대응했습니다.
• 실시간으로 받는 답변과 다시 불러온 대화 기록의 형식이 달라, 같은 AI 메시지를 화면마다 따로 처리하고 있었습니다. 형식을 백엔드와 통일해 AI 메시지를 하나의 모델로 정의하고, 통합 테스트로 사용자 흐름을 먼저 고정한 뒤 세 화면에 흩어진 대화 기록 관리를 하나로 모았습니다. 이 과정에서 중단한 답변이 다음 질문을 보내면 사라지던 문제도 해결했습니다.
• 탭 이동이나 서버 무응답으로 채팅이 끊겨도 사용자는 응답이 멈춘 이유를 알 수 없었습니다. 원인을 찾는 디버깅 작업과 해결 방식을 설계하는 작업을 나눠 백엔드와 합의했고, 하트비트 이벤트를 맞춰 끊김 감지와 자동 재연결을 구현했습니다. 재연결 대기 시간을 조정해 불필요한 재연결로 인한 서버 부담을 줄였고, 최종적으로 이 동작을 회귀 테스트로 고정해 재발을 막았습니다.

결과

• 실행에 10~30초가 걸려도 TTFT(첫 토큰까지 걸리는 시간) 0.5초 미만, 운영 서버 반영
• 연결 끊김 감지·자동 재연결, 불필요한 재연결로 인한 서버 부담 방지, 회귀 테스트로 재발 방지

📝 SSE 이벤트 프로토콜로 AI 채팅 스트리밍 설계하기 →

[고객사별 제품 구성] 빌드 없이 서버 설정으로 바꾸는 메뉴 구성

2026.06 ~ 2026.08

배경

eXemble은 같은 제품을 여러 고객사 서버에 설치하지만, 고객사마다 계약한 기능이 달라 보여줄 메뉴도 달라야 했습니다. 처음에는 고객사마다 레포나 브랜치를 따로 두고 대응해 같은 수정을 여러 번 반영해야 했고, 어느 고객사에 무엇이 들어갔는지 추적하기 어려웠습니다. 한 레포로 합친 뒤에도 고객사별 차이를 코드와 환경 변수에 적어두는 방식이라, 고객사가 늘거나 메뉴 구성이 바뀔 때마다 코드를 고치고 다시 빌드해야 했습니다.

어떻게 풀었나

• 고객사 설치를 맡는 FDE가 빌드 없이 서버에서 메뉴를 켜고 끌 수 있도록, 고객사별 메뉴 구성을 코드에서 빼내 서버 설정 기반 메뉴 구조를 제안하고 백엔드와 설계했습니다. 제안한 구조는 그대로 스펙에 채택됐습니다.
• 고객사 서버는 각 고객사 일정에 맞춰 업데이트되기 때문에, 새 프론트가 아직 메뉴 설정을 내려주지 않는 구버전 서버와 만날 수 있었습니다. 설정이 없는 것을 "켜진 메뉴 없음"으로 처리하면 배포하는 순간 잘 쓰던 고객사의 메뉴가 전부 사라지므로, 설정이 없는 경우와 빈 목록을 구분해 구버전 서버에서는 기존처럼 모든 메뉴가 보이는 구조로 설계했습니다.
• 로그인 후 첫 화면이 대시보드로 고정돼 있어, 대시보드를 끈 고객사에서는 메뉴에 없는 화면이 먼저 열렸습니다. 첫 화면을 보이는 메뉴 중 첫 번째로 정하는 규칙으로 바꿔, 고객사마다 메뉴 구성이 달라도 첫 화면이 함께 바뀌는 구조로 만들었습니다.
• 메뉴에서 숨겨도 주소를 직접 입력하면 화면이 열려, 사용자에게는 고장 난 화면으로 보일 수 있었습니다. 이 점을 먼저 공유한 뒤 구축 일정에 맞춰 화면마다 어떤 메뉴에 속하는지 표시해, 메뉴 노출과 화면 접근을 같은 설정으로 판정하는 구조로 바꿨습니다. 이 표시를 빠뜨려도 에러가 나지 않아 알아채기 어렵기 때문에, 새 화면을 추가할 때 생기는 누락을 검사하는 테스트도 작성했습니다.

결과

• 고객사별로 나뉘던 코드 분기 제거, 고객사가 늘어도 프론트 코드 수정·재빌드 없음
• FDE가 서버 설정만으로 고객사별 메뉴 구성

📝 고객사마다 다른 화면, 코드는 하나 →

[팀 AI 활용] 공용 AI 스킬 구성과 테스트 자동화

2025.09 ~ 현재

AI 코딩 도구를 각자 쓰는 데서 멈추지 않고, 팀이 같은 규칙으로 쓰는 환경을 만드는 데 집중했습니다.

• 레포마다 스킬 사본을 두면 사람마다 버전이 달라져서, 두 제품 레포가 같은 저장소를 참조해 쓰는 팀 공용 Agent Skill 저장소를 만들었습니다. PR 리뷰, 구조 리뷰, PR 자동화 등을 담았고 팀원들이 실제로 사용하고 있습니다.
• 워크플로우 노드 구조와 연결한 노드 추가 스킬은 새 노드에 필요한 결정을 차례로 묻고 구현 계획·코드 골격·테스트까지 만들어 줘, 사람이 바뀌어도 같은 규칙으로 노드를 추가할 수 있습니다.
• QA 조직 없이 짧은 기간에 기능을 내야 해서 테스트 작성이 늘 뒤로 밀렸습니다. 동료와 함께 무엇을 어디까지 검증할지 테스트 기준을 먼저 정하고, Claude Code 서브에이전트가 그 기준에 맞춰 테스트를 작성·실행하는 흐름을 만들었습니다. E2E는 Playwright MCP로 자연어 요청만으로 작성·실행하고, 실패하면 GitHub Issue가 자동 등록되는 구조로 구성했습니다.

결과

• 테스트 작성·실행부터 실패 시 이슈 등록까지 에이전트가 맡는 흐름을 팀에 정착

📝 QA도, 시간도 없던 팀이 AI Agent로 테스트 자동화를 정착시킨 방법 →

그 밖의 성과

FE 파트 리딩, 사내 땡큐 어워즈 수상

스프린트마다 PO와 범위를 조율하고 팀원의 경험을 고려해 업무를 나눴습니다. 주간 기술 공유 세션에서 각자 만든 기능의 배경과 기술 결정을 나눴고, 코드 리뷰와 기술 공유로 동료 추천을 받아 사내 땡큐 어워즈를 받았습니다.

exem-ui 디자인 시스템 코어 전환 주도

사내 여러 제품이 쓰는 디자인 시스템의 유지보수와 컴포넌트 개발에 기여하고 있습니다. 한 화면의 요구를 그 화면 안에서 우회하지 않고 다른 제품도 쓸 수 있는 공용 컴포넌트로 만드는 것을 기준으로 삼았고, 지금은 코어를 Radix UI에서 Base UI로 전환하는 작업을 주도하고 있습니다.

프론트엔드 선행 API 설계

출시 일정이 급박한 상황에서 담당 페이지들이 개발 흐름 후반부에 있어, 그대로 두면 일정 안에 출시하기 어려웠습니다. 각 화면에 필요한 정보를 정리해 API 인터페이스를 먼저 설계하고 백엔드에 전달했고, 덕분에 프론트엔드와 백엔드가 병렬로 개발할 수 있었습니다.

Sticpay 서비스

상대방이 어디에 있든 실시간으로 송금·수취할 수 있는 글로벌 e-wallet 서비스.

Next.js TypeScript Emotion.js Recoil

Money In & Out 리뉴얼

입출금 페이지 구조 개선

새 결제 수단이 추가될 때마다 전용 페이지와 컴포넌트를 새로 만들어야 해서, 협력사가 늘수록 관리할 페이지도 계속 늘었습니다. 결제 수단을 신용카드·계좌이체·대체 결제 수단(APM) 카테고리로 묶어 카테고리별 표준 흐름을 설계하고, 서버 데이터에 따라 화면이 구성되는 구조로 재설계했습니다.

결과

전체 페이지 수 70% 축소, 새 결제 수단은 프론트엔드 코드 수정 없이 추가 가능

📝 입출금 구조 개선 과정 자세히 보기 →

여러 단계로 나뉜 결제 흐름을 위한 퍼널 도입

결제 수단마다 입력받을 정보가 많아, 카드 선택 → 금액 입력 → 결제 진행처럼 여러 단계로 나뉜 화면이 많았습니다. 단계 사이의 입력값 유지와 단계 이동을 한곳에서 관리하는 useFunnel 커스텀 훅을 만들었고, URL로 중간 단계에 바로 진입하는 것도 막았습니다.

다이어그램으로 복잡한 계정 연동 기능 재구현

외부 서비스와 계정을 연동하는 기능을 새 API 스펙에 맞춰 다시 만들어야 했는데, 성공·실패 케이스가 많은 데 비해 문서와 히스토리가 없어 코드만으로 동작을 파악해야 했습니다. 기존 기능을 단계별로 실행하고 코드를 분석해, 외부 서비스 창이 닫혀 서류 제출이 누락되는 경우 같은 실패 케이스까지 상태 다이어그램으로 그려 팀 위키에 공유했습니다.

결과

팀원들이 다이어그램을 기준으로 구현·리뷰하면서 예외 처리 코드를 실수로 지우는 일을 막을 수 있게 되어, 이후 복잡한 기능 개발의 팀 표준 절차로 채택

📝 상태 다이어그램 활용 과정 자세히 보기 →

인증과 성능

메인/마이페이지로 나뉜 서브도메인 간 SSO 로그인

메인 페이지와 마이페이지가 서로 다른 서브도메인에 있는데 인증 정보를 브라우저 스토리지에 저장하고 있어, 두 서비스가 로그인 상태를 공유할 수 없었습니다. 쿠키 기반 인증으로 전환하고 저장 값을 암호화해, 서브도메인 간 로그인을 공유하면서 보안도 강화했습니다. 또 페이지를 이동할 때마다 호출하던 2단계 인증 확인 API는 토큰이 바뀔 때만 갱신하는 전역 상태로 바꿔 없앴습니다.

SSO 계정 연동 중 API 요청 취소 문제 해결

사용자가 SSO 계정 연동을 요청한 직후 페이지를 벗어나면, 진행 중이던 API 요청이 함께 취소돼 연동이 실패했습니다. fetch의 keepalive 옵션을 적용해, 페이지를 떠나도 요청이 끝까지 전송되어 연동이 완료되는 구조로 바꿨습니다.

SVG 스프라이트 도입으로 성능 개선

국가 선택 화면에서 국기 이미지 260개를 하나씩 요청해 페이지 로딩이 느렸습니다. 국기를 한 파일로 합치는 SVG 스프라이트 기법을 도입하고, 로컬과 S3 환경에서 모두 쓸 수 있는 스프라이트 이미지 생성 스크립트를 만들어 적용했습니다.

결과

이미지 요청 횟수 260회 → 1회

📝 SVG 스프라이트 도입 과정 자세히 보기 →

이미지 최적화를 통한 성능 개선

메인 페이지 이미지를 WebP 형식으로 변환하고, 화면 밖 이미지에는 지연 로딩을 적용했습니다. WebP를 지원하지 않는 브라우저에는 picture 태그로 PNG를 대신 보여줘 호환성도 유지했습니다.

결과

모바일 Lighthouse 점수 26 → 72

React 18 마이그레이션

React 17 · Node 16 환경의 기능 제약을 해소하기 위해 React 18로 업그레이드했습니다. Docker로 Node 20 환경을 먼저 구성한 뒤 버전을 올렸고, React Router · React Query 등 주요 라이브러리의 호환성 문제를 해결했습니다.

---

Sticplay 캐시백 서비스

파트너사 이용 중 발생한 손실 금액 일부를 환급해 주는 캐시백 서비스.

Node 16 Zustand next-i18next

로그인 · 2FA 연동 및 페이지 접근 제어

기존에는 페이지에 들어간 뒤 클라이언트에서 권한을 확인해, 권한이 없는 화면이 잠깐 보였다가 다른 페이지로 이동하는 문제가 있었습니다. Next.js middleware를 도입해 페이지 진입 전에 서버에서 권한을 확인하는 구조로 바꿔, 화면 깜빡임과 동시성 문제를 함께 해결했습니다.

다국어 i18n 세팅

빌드할 때마다 번역 API가 호출되어 서버에 부하를 주고 있었습니다. 번역 데이터 수집 스크립트를 만들어 CI/CD 파이프라인에서만 실행되는 구조로 바꿔, 불필요한 번역 API 호출을 없앴습니다.

---

그 밖의 성과

Sticpay API Docs

PDF로 관리하던 API 문서를 MDX 기반 웹 페이지로 전환했습니다. 정확한 검색어를 몰라도 원하는 문서를 찾을 수 있도록 퍼지 검색을 넣고, 검색 결과 키보드 이동과 전역 단축키(cmd+k), ARIA 속성을 더해 키보드만으로도 쓸 수 있는 문서 검색을 구현했습니다.

TypeScript Next.js App Router fuse.js

이메일 템플릿 노코드 빌더

마케팅팀이 eDM HTML이 필요할 때마다 개발자가 직접 작성해야 했고, 요청 빈도가 높아 개발 일정에 영향을 주고 있었습니다. 요청을 그때그때 처리하는 대신 비개발자가 콘텐츠를 직접 만들 수 있는 빌더를 제안·개발했습니다. 다단 레이아웃과 이미지·텍스트 블록을 드래그 앤 드롭으로 배치하고, HTML 미리보기와 직접 편집을 함께 지원했습니다.

결과

마케팅팀이 eDM을 자체적으로 제작할 수 있게 되어, 반복 요청에 쓰던 프론트엔드 리소스를 다른 작업에 투입