Log Friends의 지원 범위를 넓게 생각하고 좁게 정한 이유

Об этом предложении

Log Friends의 SDK를 고민하면서 지원할 수 있는 환경은 더 많이 보였다. 하지만 고려한 환경을 지금 모두 지원해야 하는 것은 아니었다. 백엔드, 웹 프론트엔드, 모바일까지 구분해 생각하되, 실제 지원 범위는 웹과 백엔드로 정했다. 모바일이 중요하지 않아서가 아니라, 사용할 수 있는 시간과 인력으로 어디까지 구현하고 검증하며 유지할 수 있는지를 먼저 생각했기 때문이다. 이번 글에서 남기고 싶은 것은 테이블을 몇 개 나눴는지가 아니다. 설계에서 고려할 범위와 현재 개발에서 책임질 범위를 구분한 과정 이다. 처음에는 어떤 언어의 SDK를 만들지 생각했다 처음에는 Kotlin SDK, TypeScript SDK처럼 언어를 중심으로 바라봤다. 어떤 언어로 만든 서비스에서 Log Friends를 사용할 수 있게 할지가 먼저였다. 그런데 실행 환경까지 생각하니 언어만으로는 구분이 충분하지 않았다. Kotlin은 Spring Boot 서버와 Android에서 모두 쓰이고, TypeScript는 Node.js 서버와 브라우저에서 모두 쓰인다. 같은 언어라도 수집할 정보와 실행 중 신경 써야 할 일이 다르다. 환경 구분해서 생각한 내용 백엔드 요청·함수 실행·업무 이벤트와 서버 종료 시 전송 웹 프론트엔드 페이지·컴포넌트·사용자 행동과 페이지 종료 시 전송 모바일 앱 화면·앱 생명주기·네트워크 상태에 따른 전송 서버 이벤트에 웹의 page_path 나 component_name 이 필요한지 살펴본 것도 이 구분의 한 계기였다. 공통 이벤트 계약이 있다고 해서 환경별 정보까지 모두 공통으로 취급할 필요는 없었다. 지원 환경이 늘면 유지해야 할 일도 늘어난다 백엔드·웹·모바일을 모두 고려하는 것과 실제로 지원하는 것은 다른 일이었다. SDK 코드를 추가하는 것만으로 지원이 끝나지는 않는다. 각 환경에서 이벤트가 제대로 수집되는지, 전송이 실패했을 때 어떻게 동작하는지 확인해야 한다. 사용법을 문서화하고, 공통 계약을 바꿀 때 기존 동작이 깨지지 않는지도 계속 확인해야 한다. 모바일까지 포함하면 앱 생명주기와 네트워크 변화 같은 조건도 별도로 다뤄야 한다. 공통 전송 코드를 재사용할 수 있어도 환경별 검증과 유지보수까지 없어지는 것은 아니다. 제한된 시간과 인력으로 이 범위를 동시에 가져가면, 지원 목록은 늘어나지만 각 환경을 충분히 확인하는 데 쓸 시간은 줄어들 수 있다고 판단했다. 유지보수 비용을 수치로 측정한 것은 아니지만, 범위를 정할 때 빼놓을 수 없는 조건이었다. 그래서 모바일 지원까지 늘리기보다 웹과 백엔드에서 수집부터 저장·조회까지 이어지는 흐름을 먼저 검증하는 것 을 우선순위로 정했다. 지금 책임질 범위를 코드와 문서에 맞췄다 현재 지원 범위는 다음과 같다. 구분 SDK 업무 이벤트 저장 서버 백엔드 Kotlin/JVM, TypeScript Node backend_custom_events 웹 프론트엔드 TypeScript Browser frontend_custom_events 이벤트 형식과 배치 전송 계약은 공유하고, 웹 UI 전용 컬럼은 프론트엔드 테이블에만 둔다. 저장 위치는 SDK가 아니라 Console이 등록된 Agent의 출처를 보고 결정한다. 모바일도 문서에서만 제외하지 않았다. 현행 TypeScript 패키지의 모바일 공개 진입점을 제거하고 빌드·배포·지원 테스트 대상에서 제외했다. Console도 새 모바일 등록과 수집을 거절하도록 변경했다. 기존 모바일 코드와 과거 데이터는 삭제하지 않았다. 과거 레코드를 읽기 위한 MOBILE 값은 남겨뒀지만, 이를 현재 지원하는 기능으로 안내하지는 않는다. 모바일 앱을 제외하는 대신 당장 지원 환경을 늘릴 수 있는 선택지는 내려놓았다. 그 시간은 웹·백엔드의 동작 확인과 문서 정리에 쓰기로 했다. 모바일은 필요성과 유지 여력을 다시 확인할 때 검토할 수 있지만, 지금 지원을 약속한 상태는 아니다. 휴대전화의 웹 브라우저는 웹 지원 범위에 포함한다. 모바일 앱 SDK 제외와 반응형 웹 지원은 별개다. 어디까지 확인했는가 2026-10-08 로컬 변경 기준으로 다음을 확인했다. TypeScript SDK의 npm run prepublishOnly : lint, 지원 범위 테스트 67개, ESM·CommonJS 빌드, 패키지 검증 통과. npm pack --dry-run : 배포 대상 파일에 모바일 빌드 결과가 없는 것을 확인. Console: 별도 빌드 경로와 Kotlin incremental 비활성화 설정으로 전체 build 통과. 모바일 등록·수집 거절과 서버·브라우저 저장 분기 테스트 포함. 모바일 테스트는 지원 범위에서 제외했으므로 위 결과를 모바일 동작 검증으로 해석하면 안 된다. 저장 분기 테스트도 mock DB 기반이다. 실제 TimescaleDB에서 V15를 적용해 양쪽 SDK의 등록부터 저장까지 확인하는 작업은 남아 있다. npm 배포와 NAS 적용은 하지 않았다. 모바일 공개 API 제거는 하위 호환성이 깨지는 변경이므로, 실제 배포 전에 버전 정책과 제거 안내를 결정해야 한다. 배운 점 처음에는 SDK를 어떤 언어로 제공할지 생각했다. 그다음에는 백엔드·프론트엔드·모바일이라는 실행 환경의 차이가 보였고, 마지막에는 이를 유지할 시간과 인력까지 생각하게 됐다. 설계할 때 여러 환경을 고려하는 것은 필요했다. 하지만 현재 지원 범위까지 전부 넓혀야 하는 것은 아니었다. 고려는 넓게 하되, 지금 검증하고 유지할 수 있는 범위를 선택하는 것 도 개발의 일부였다. 다음은 웹과 서버 이벤트를 실제 테스트 DB에 보내 등록·수집·분리 저장까지 확인하는 것이다. 지금 선택한 두 환경부터 끝까지 확인하려고 한다.