JavaScript SDK란?StepBy는 고객사에서 생성한 가이드를 코드로 직접 실행할 수 있는 기능을 제공합니다. 이를 통해 안정적으로 인앱 가이드를 테스트하고 배포할 수 있습니다.이를 위해 JavaScript SDK 파일을 제공하고 있으며, 고객사는 태그를 통해 손쉽게 자신의 애플리케이션에 삽입해 사용할 수 있었습니다. 이 SDK 파일(index.min.js)은 StepBy 서비스와 고객사의 애플리케이션 간 연결을 담당하는 핵심적인 구성 요소였습니다. 하지만 SDK 파일을 어떻게 서빙할지 결정하는 과정에서 여러 고민과 시행착오를 겪었고, 최종적으로 AWS S3와 CloudFront를 조합한 방식으로 문제를 해결했습니다. 이번 글에서는 AWS S3와 CloudFront를 도입하며 겪었던 기술적 고민..

웹 성능 최적화는 사용자 경험(UX)과 서비스 품질을 좌우하는 중요한 요소입니다. 저는 StepBy SDK를 사용하는 고객사들의 페이지 로딩 속도 개선을 위해, Dynamic Import를 활용한 코드 스플리팅을 적용했습니다.그 결과 JavaScript 파일 크기를 87KB → 11KB로 줄이고, 로딩 속도를 38ms → 18ms로 절반 가까이 단축할 수 있었습니다. 이번 글에서는 이 과정을 어떻게 진행했는지, 어떤 최적화 전략이 효과적이었는지 다뤄보도록 하겠습니다. 🚀 배경StepBy는 고객사에서 온보딩 구축에 필요한 다양한 기능들을 직접 제어할 수 있도록 JavaScript SDK를 제공합니다. 서비스 초기에는 기능 자체가 적었고, SDK 파일도 그리 크지 않았습니다.하지만 기능이 점점 추가되면서 ..

Backgrounds싱글톤 패턴(Singleton Pattern)이란?싱글톤 패턴은 애플리케이션 내에서 특정 클래스의 인스턴스가 단 하나만 생성되도록 보장하는 디자인 패턴입니다. 데이터베이스 연결, 설정값 관리, 공통 서비스 제공 등 애플리케이션 전역에서 공유되어야 하는 리소스를 관리할 때 자주 사용됩니다.class Singleton { private static instance: Singleton | null = null; private constructor() {} static getInstance(): Singleton { if (!this.instance) { this.instance = new Singleton(); } return this.instance; }}..

2부. 기준기준은 기본적인 '기대 수준'이다. 이는 우리가 지켜야 한다고 정한 기준선이다. (...) 기준을 능가하는 건 상관없지만 절대 그에 못 미쳐서는 안 된다. 9장. 생산성여러분의 CTO로서 나는 생산성에 있어 몇 가지를 기대한다.- 나는 절대 똥덩어리를 출시하지 않기를 기대한다- 나는 낮은 수정 비용을 기대한다- 나는 우리가 언제나 준비되어 있기를 기대한다- 나는 안정적인 생산성을 기대한다 10장. 품질여러분의 CTO로서 나는 품질에 있어 몇 가지를 기대한다.- 나는 지속적인 개선을 기대한다- 나는 두려움을 이기는 능력을 기대한다- 나는 극한의 품질을 기대한다- 나는 우리가 QA에게 떠넘기지 않기를 기대한다- 나는 현실적으로 자동화 가능한 모든 테스트가 '자동화되기를' 기대한다 자동화 테스트와 ..

5장. 리팩터링더보기리팩터링은 동작을 바꾸지 않으면서 코드를 연속적으로 조금씩 바꿔서 소프트웨어의 구조를 개선하는 것인데, 각 변경을 마무리할 때마다 포괄적인 테스트 묶음을 통과시킴으로써 동작이 바뀌지 않았음을 증명한다.여기서 핵심은→ 1) 리팩터링은 동작을 보존한다 2) 개별 리팩터링은 작다. 디버깅이 필요하지 않을 만큼! 기본 도구이름 바꾸기무언가의 정확한 이름을 찾는 일은 연속적이고 반복적인 개선 과정인 경우가 많다. 정확한 이름을 추구하는 일을 두려워하지 말라. 프로젝트가 아직 초기일 때 가능한 자주 이름을 개선하라. 좋은 이름 짓기는 정말 어렵다!!이때 기억하면 좋을 교훈은 → 연속적이고, 반복적인 개선을 통해 최선의 이름을 찾을 수 있다는 것.따라서 변경을 두려워하지 말아야 한다. 지속적으로 ..

4장. 테스트 설계데이터베이스 테스트하기데이터베이스를 테스트할 때 첫 번째 규칙은 다음과 같다. 데이터베이스를 테스트하지 말라.(...) 두 번째 규칙은 다음과 같다. 데이터베이스를 비즈니스 규칙과 분리하라. 결국 핵심은, 비즈니스 규칙과 그 이외의 요소들을 명확히 분리 하는 것! 이를 위해 인터페이스(예제에서는 Gateway)를 만들어해당 인터페이스를 구현하는 클래스가 실제 데이터베이스에서 필요한 기능을 수행하도록 작성해야 한다. 이를 통해 인터페이스 경계 너머(비즈니스 로직)에서는SQL도, ORL 프레임워크도, 데이터베이스 API도, 데이터베이스 스키마도 알 필요가 없으며,오직 의존 중인 인터페이스가 정의한 결괏값(비즈니스 객체)에만 신경 쓸 수 있게 된다.→ 비즈니스 로직을 테스트할 때는, 스텁이나..