게시글
테스트케이스를 기획 리뷰 시점에 먼저 뽑기로 했다
구현을 끝낸 뒤 테스트케이스를 적다 보니 기획서에 답이 없는 경우가 나와, 기획 확인부터 다시 하는 일이 세 번 반복됐다. 다음 작업에서는 기획서를 받은 날 케이스부터 뽑았고, 빈틈 14건을 구현 전에 기획 리뷰에서 메웠다. 테스트케이스는 코드보다 기획서를 먼저 검증하는 문서로도 쓸 수 있었다.
AI에게 구현을 맡기며 설계를 한 번에 끝내지 않기로 했다
설계만 완벽하면 AI가 한 번의 구현으로 원하는 결과물을 뽑아낼 거라 믿었다. 하지만 아무리 공들여도 코드로 옮기는 순간 어긋나는 지점이 생겼고, 어떤 정보는 구현해 봐야만 알 수 있었다. 지금은 전체 흐름만 먼저 정하고 세부 설계는 기능 하나를 시작할 때마다 이어 가고자 한다.
AI 시대에서 개발자가 시간을 써야 할 곳은 어디일까?
개발자가 시간을 써야 할 곳은 코드가 작성되기 전에 질문을 던지는 순간이다. AI로 토이 프로젝트를 하다가 필터 하나를 검토 없이 승인했더니 상태 관리 구조를 통째로 다시 설계해야 했다. 결정이 늦어질수록 그 위에 얹힌 코드까지 함께 고쳐야 해서 되돌리는 비용이 커진다.
반복을 줄이는 것보다 역할을 드러내는 코드
컴포넌트를 나눌지는 이름과 시그니처만으로 무엇을 그리는지 설명되는지로 정한다. 클론 코딩 리뷰 질문에 답하다 보니 Card에 옵셔널 prop이 쌓여 이름만으로 역할을 설명하기 어려워졌다. 코드가 조금 중복되더라도 역할이 드러나면 그 중복은 코드 안에 남긴 이정표다.
로컬 LLM과 n8n으로 구축하는 에러 분석 자동화
에러가 나면 n8n이 소스 코드와 스택 트레이스를 모으고 로컬 LLM이 원인과 수정 제안을 Notion에 남기는 파이프라인을 만들었다. 에러마다 5분 넘게 걸리던 초기 탐색이 20~25초로 줄었다. 코드를 밖으로 내보내지 않는 대가로 로컬 모델의 정확도는 아쉬웠지만, 자동화가 사람이 집중할 곳을 좁혀준다는 건 확인했다.
실시간 통신 로직을 계층으로 정리하기
내 머릿속에만 있는 맥락은 구조가 아니었다. 기능이 늘수록 mediasoup 로직이 여러 곳에 흩어져 하나를 고치면 어디까지 파급될지 가늠하기 어려웠다. 계층마다 이 정보를 정말 알아야 하는지 묻고 몰라도 되는 정보를 걷어내자 수정 범위가 계층 하나로 좁혀졌다.
비디오 Consumer 수 상수화로 서버 부하 최적화
±1 프리패치로 100명 기준 Consumer 수를 9,900개에서 210개로 줄였다. 그 전에는 모든 참여자의 비디오를 동시에 받는 구조라 Consumer가 N×(N-1)로 늘어나 20명만 넘어도 CPU가 급증했다. 대안을 비교할 때는 단점의 허용 범위를 먼저 정해야 했다.
Node.js WAS에서 일관된 에러 처리 구조 적용하기
계층마다 다르던 에러 처리를 BaseError 상속 구조로 모았다. 계기는 게시글 API가 응답은 정상인데 데이터만 비어 있던 장애였고, 원인은 에러를 return null로 삼킨 코드였다. 에러 처리는 뒤로 미뤄도 되는 일이라 여겼지만, 미룬 작업이 반영된 적은 한 번도 없었다.
OCR과 Open AI의 응답 속도 개선
계약서 OCR과 OpenAI 번역 페이지의 로딩 2분을 18초로 줄였다. 화면에 보이는 구역만 요청하고 페이지 단위로 쪼개 병렬로 실행하고 먼저 도착한 페이지부터 렌더링했다. 비동기 처리에서는 요청 수보다 처리 단위를 어디까지 쪼갤 수 있는지를 먼저 봐야 했다.
동적 폰트 로딩 전략
폰트 적용 시점은 브라우저에 묶여 있어 서버 렌더링으로 깜빡임을 없앨 수는 없었다. 대신 WOFF2 변환과 두 겹의 캐싱, 스켈레톤 UI로 로딩을 줄이고 남은 순간은 가렸다. WOFF2 변환만으로 폰트 파일은 6.3MB에서 3.0MB로 줄었다.