Loading glossary...
A/B 테스트는 두 가지 이상의 서로 다른 UI/UX 시안(A안, B안)을 실 사용자에게 무작위로 보여준 후, 클릭률이나 전환율(Conversion Rate) 등 실제 데이터를 비교 분석하여 최적의 버전을 결정하는 데이터 기반 의사결정 기법입니다.
"버튼을 파란색으로 할까, 빨간색으로 할까?"와 같이 감이나 직관에 의존하는 것이 아니라, 실제 사용자의 행동 데이터를 바탕으로 더 나은 비즈니스 결과를 가져오는 디자인을 채택하기 위함입니다.
| 단계 | 과정 | 설명 |
|---|---|---|
| 1 | 가설 수립 | "버튼 색상을 빨간색으로 바꾸면 클릭률이 올라갈 것이다"와 같이 검증 가능한 가설을 세웁니다. |
| 2 | 변수 설정 및 제작 | 기존 화면(대조군, Control)과 변경된 화면(실험군, Variant)을 준비합니다. 이때 변수는 1개만 설정하는 것이 좋습니다. |
| 3 | 트래픽 분배 (테스트) | 웹사이트 방문자를 50:50 등의 비율로 무작위 배정하여 각각 다른 화면을 보여줍니다. |
| 4 | 데이터 분석 및 결정 | 수집된 데이터를 바탕으로 통계적 유의성을 검증하고, 더 성과가 좋은 버전을 최종 반영합니다. |
테스트 기간이 너무 짧거나 표본(트래픽)이 충분하지 않은 상태에서 결론을 내리면, 우연에 의한 결과일 확률이 높습니다. A/B 테스트 결과를 신뢰하기 위해서는 충분한 모수 확보와 '통계적 유의성' 검증이 필수적입니다.
'기민한, 날렵한'이라는 뜻으로, 소프트웨어 개발 시 처음부터 끝까지의 모든 계획을 완벽하게 세우고 시작하는 대신, 일정한 주기(Sprint)를 두고 끊임없이 시제품을 만들어 사용자 피드백을 반영하며 유연하게 수정/보완해 나가는 개발 방법론입니다.
| 구분 | 폭포수 (Waterfall) | 애자일 (Agile) |
|---|---|---|
| 유연성 (수정) | 수정이 매우 어려움 (비용 큼) | 수정이 용이함 (변화 환영) |
| 출시 주기 | 모든 개발이 끝나야 1번 출시 (수개월~년 단위) | 빠른 반복 출시 (1~4주 단위 Sprint) |
| 위험 관리 | 출시 후 실패하면 리스크가 큼 | 작은 단위로 피드백을 받아 리스크 최소화 |
API는 두 개의 소프트웨어가 서로 대화할 수 있도록 이어주는 '연결 고리' 또는 '심부름꾼'입니다. 프론트엔드(클라이언트)가 백엔드(서버)에 데이터를 요청할 때, 정해진 규칙에 따라 요청을 전달하고 결과를 받아오는 창구 역할을 합니다.
우리가 식당에 가면 주방장(서버)에게 직접 요리를 달라고 하지 않습니다. 손님(클라이언트)은 메뉴판(API 문서)을 보고 웨이터(API)에게 주문(요청)을 합니다. 웨이터는 주방에 주문을 전달하고, 요리가 완성되면 다시 손님에게 가져다 줍니다(응답).
| 종류 | 특징 |
|---|---|
| REST API | 가장 흔하게 쓰이는 방식. 명사(URL)와 동사(HTTP 메서드: GET, POST 등)의 조합으로 자원을 조작합니다. (예: GET /users) |
| GraphQL | 페이스북이 만든 방식. 클라이언트가 "나 이름과 이메일만 필요해!" 하고 원하는 데이터만 콕 집어서 요청할 수 있습니다. |
| Open API | 구글 지도, 카카오 로그인, 날씨 정보 등 누구나 가져다 쓸 수 있도록 외부 개발자에게 공개된 API입니다. |
고객 획득 비용입니다. 1명의 신규 결제 고객(또는 가입자)을 데려오기 위해 마케팅이나 영업에 얼마의 비용을 썼는지를 나타냅니다. 이 비용이 너무 높으면 아무리 물건을 많이 팔아도 회사는 적자를 보게 됩니다.
| 전략 | 설명 |
|---|---|
| 오가닉 트래픽 강화 | 돈을 쓰는 유료 광고 대신 SEO(검색엔진 최적화), 블로그, 유튜브 등 콘텐츠 마케팅을 통해 자연 유입을 늘립니다. |
| 추천 프로그램 (Referral) | 기존 유저가 친구를 초대하면 양쪽 모두에게 혜택을 주는 방식(예: 토스, 에어비앤비)으로 바이럴(입소문)을 유도합니다. |
| 타겟팅 최적화 | 광고 집행 시 우리 제품에 관심 없는 사람들에게 노출되는 것을 줄이고, 진성 타겟에게만 예산을 집중합니다. |
개발자들이 작성한 코드를 중앙 저장소에 통합하고(CI), 실제 서비스 서버에 반영하기까지의(CD) 전 과정을 사람의 손을 거치지 않게 '자동화'하는 파이프라인 관행입니다. GitHub Actions, Jenkins, CircleCI 등의 도구가 널리 쓰입니다.
| 개념 | 주요 목적 | 파이프라인 단계 (Workflow) |
|---|---|---|
| CI (Continuous Integration) | 코드 충돌 방지 및 품질 유지 | 1. 코드 Commit/Push 2. 자동 빌드 (Build) 3. 자동 단위 테스트 (Unit Tests) 4. 정적 코드 분석 (Lint) |
| CD (Continuous Deployment) | 신속하고 안전한 기능 출시 | 5. 컨테이너(Docker) 이미지 생성 6. 스테이징 환경 배포 및 E2E 테스트 7. 프로덕션 환경 무중단 자동 배포 |
컴포넌트(Component)는 UI를 독립적이고 재사용 가능한 조각으로 나눈 것입니다. 마치 레고 블록을 조립해 거대한 성을 만들 듯, 리액트에서는 작은 컴포넌트들을 조립하여 복잡한 웹 애플리케이션을 완성합니다.
재사용성(Reusability)과 유지보수성(Maintainability)이 극대화됩니다. 한 번 만들어둔 <Button /> 컴포넌트는 프로젝트 어디서든 다시 가져다 쓸 수 있습니다.
CORS는 서로 다른 출처(Origin, 예: 도메인, 포트)를 가진 웹 앱들끼리 자원을 안전하게 주고받을 수 있도록 허용해주는 브라우저의 보안 정책입니다. 기본적으로 브라우저는 해킹 방지를 위해 출처가 다르면 통신을 차단(SOP 정책)하는데, 이를 예외적으로 허락해 주는 것이 CORS입니다.
A마을(클라이언트) 주민이 B마을(서버) 창고에 물건을 가지러 갑니다. B마을 입구에는 경비원(웹 브라우저)이 서 있습니다. 경비원은 무조건 외부인을 막지만, B마을 촌장(서버 설정)이 "A마을 사람은 들여보내라(Access-Control-Allow-Origin)"고 허락증을 써두면 무사히 통과시켜 줍니다.
프론트엔드 개발자가 가장 자주 만나는 붉은 글씨의 CORS Error는 십중팔구 백엔드(서버)에서 허락을 안 해줘서 브라우저가 막은 것입니다.
Proxy 기능을 사용하여, 마치 같은 도메인에서 요청하는 것처럼 브라우저를 속입니다.