AX 플랫폼에서 AI 에이전트가 IM을 PPTX로 생성하면, 사용자는 다운로드 전에 웹에서 결과물을 먼저 확인한다. 이 미리보기 기능의 로딩 시간이 원본 파일을 내려받아 PowerPoint로 여는 것보다 오래 걸렸다. 미리보기가 다운로드보다 느리다면 미리보기는 존재할 이유가 없다.기존 구조는 브라우저에서 PPTX를 직접 해석했다. 10MB가 넘는 원본을 통째로 받아 ZIP을 풀고, 슬라이드마다 XML을 파싱하고, 좌표를 CSS px로 변환해 React 컴포넌트로 그렸다. 이 과정에 10초 가까이 걸렸다.느린 것보다 더 큰 문제는 결과가 실제 문서와 달랐다는 점이다. 요소브라우저 렌더실제 PowerPoint텍스트기본 서식만테마 색상과 폰트테이블문자열 그리드셀 병합과 서식차트데이터 테이블로 대체시각화그라디언..

AI 에이전트가 만든 재무모델, 미리보기에 28초가 걸렸습니다AI 에이전트가 재무모델 xlsx 파일을 생성하는 기능이 있습니다. 사용자가 결과물을 확인하려면 매번 파일을 내려받아 로컬 Excel로 열어야 했습니다. 그래서 브라우저에서 바로 여는 미리보기 패널을 만들기로 했습니다.전제는 하나였습니다. 로딩이 "다운로드 후 Excel로 열기"보다 빨라야 합니다. 그렇지 않으면 미리보기는 한 단계를 더 거치는 우회로일 뿐입니다.처음에는 브라우저용 스프레드시트 엔진인 Univer로 클라이언트에서 수식을 직접 계산해 렌더링했습니다. 그러자 시트 12개, 셀 18만 개 규모의 파일은 첫 셀이 뜨기까지 8~28초가 걸렸습니다. 로컬 Excel로 여는 것보다 느렸습니다. 병목을 단계별로 측정했습니다재무모델 파일은 수식..

내가 개발하고 있는 플랫폼에서는 채팅방마다 재무모델/PPT생성 등을 함께 편집할 수 있다. 여러 명이 동시에 수정하면 내용이 덮어써지므로, 채팅방 하나에는 편집 권한을 가진 사용자가 한 명만 있어야 한다.문제는 "지금 누가 갖고 있는가"만으로는 부족하다는 점이다. 탭을 닫거나 네트워크가 끊기거나 브라우저가 강제 종료되면 보유자는 사라지지만 락은 그대로 남는다. 편집 락 설계는 결국 "그 사람이 아직 살아있는가"를 어떻게 판정하느냐의 문제다.이 프로젝트는 Redis 없이 단일 PostgreSQL DB 안에서 상태를 공유해야 하는 제약이 있었다.설계: DB를 유일한 상태 출처로 두고 SSE로 전파구성요소역할소실 시 영향DB유일한 상태 출처. 획득·보유 확인·해제 모두 여기서 이루어진다.전체 장애SSE3분마다..

이번 프로젝트에서 브라우저에서 엑셀 파일을 원본 형태 그대로 미리 보여주는 기능을 맡게 되었다. 대상은 복잡한 수식과 서식, 여러 개의 시트로 구성된 재무모델(xlsx/xlsm)이었다. 다운로드 없이 화면에서 원본을 그대로 보여줘야 했지만 시트마다 구조와 양식이 달라 셀 값만 추출해 별도의 UI로 그리는 방식으로는 재현할 수 없었다.문제를 해결하려면 엑셀 파일이 실제로 어떤 구조로 저장되고, 브라우저에서는 그 구조를 어떤 과정을 거쳐 화면에 그리는지부터 이해해야 했다.이 글은 그 과정에서 엑셀 파일 포맷과 렌더링 파이프라인을 단계별로 살펴보며 정리한 기록이다.1. xlsx의 실체는 ZIP으로 묶인 XML이다xlsx는 하나의 바이너리 덩어리가 아니다. 확장자만 바꾸면 그대로 압축이 풀리는 ZIP 아카이브이..

배경새 프로젝트를 지난달 말에 시작했다. 최근 비개발 부서와 협업하게 되면서 플랫폼 기획까지 우리가 직접 맡게 됐다. 팀에 기획자나 PM은 따로 없다. 개발자들이 기획부터 개발, 진척 관리까지 다 같이 한다.작업 진척판은 Google Sheets로 관리한다. 구조는 단순하다. | 기능 구분 | 역할 구분 | 세부 업무 | 담당자 | 완료일 | 6월 1주차 | 6월 2주차 | ... | 완료한 작업은 해당 주차 칸을 초록색으로 칠하고 [완료] 라고 적는다.사실 일정 관리는 Jira나 Monday를 쓰면 된다. 하지만 그런 툴을 자유롭게 쓰는 IT 기업의 환경은 아니다. 게다가 이 시트는 타 부서와 부장님, 전무님께 공유하는 용도이기에 보던 양식을 바꾸는 것도 부담이었다. 그래서 툴을 바꾸는 대신 엑셀을 그..

2월부터 3월까지는 기존 레포지토리에서 프론트엔드 기능 개발에 집중했다. 이미 돌아가고 있는 서비스 위에 새 기능을 얹는 작업이 대부분이었다. 4월부터는 상황이 달라졌다. 우리 조직이 아닌 다른 부서 서버를 쓰게 되면서 형상관리부터 배포까지 전 과정을 GitLab에서 처음부터 새로 짜야 했다. CI/CD는 단순한 자동화가 아니다이번 프로젝트의 핵심은 GitLab 파이프라인으로 STG/PROD 배포 흐름을 잡고 트래픽 경로를 파악해 장애 대응 능력을 확보하는 것이었다. 전체 구조는 Next.js 앱을 GitLab으로 배포하고 Application Gateway → Nginx → WAS 순으로 트래픽이 흐르는 형태다.파이프라인을 직접 처음부터 구성해본 건 이번이 처음이었다. 작업하면서 느낀 건 CI/CD가 ..