프론트엔드 설계
설계·호환성·테스트와 협업 절차
객체 지향 추상화, 브랜치 전략, 크로스 브라우징, 자동화 테스트는 변경 비용과 배포 위험을 낮추기 위해 팀 맥락에 맞춰 선택합니다.
이럴 때 필요해요
설계 원칙과 개발 프로세스를 유행어나 형식적인 규칙이 아니라 안전한 변경과 검증을 위한 실용적인 도구로 활용합니다.
어떻게 동작하나요?
코드가 커질수록 한 곳을 고쳤을 때 예상치 못한 다른 화면이 깨지기 쉽습니다. 객체 지향 설계는 관련된 상태와 행동을 책임 단위로 묶고 캡슐화·추상화·다형성을 통해 변경의 파급 범위를 줄이는 접근입니다. 이때 깊은 클래스 상속 계층은 오히려 부모와 자식을 강하게 묶어 수정을 어렵게 할 수 있으므로, 프론트엔드에서는 작은 역할들을 조립하는 구성(Composition)과 인터페이스 기반 의존성 주입을 활용하면 UI와 분리된 깔끔한 설계를 얻기 쉽습니다.
협업 프로세스 역시 팀의 배포 주기와 제품 성격에 맞춰 선택합니다. main·develop·feature·release·hotfix 브랜치를 엄격히 나누는 Git Flow는 정해진 버전 릴리스 주기가 있는 팀에 어울리지만, 매일 수시로 배포하는 팀이라면 짧은 기능 브랜치와 빠른 통합(GitHub Flow, Trunk-Based)이 병합 충돌 비용을 줄여 줍니다. 애자일 또한 회의 형식만 따르는 것이 아니라 짧은 주기로 작동하는 결과물을 검증하고 피드백에 맞춰 방향을 조정하는 원칙입니다.
마찬가지로 크로스 브라우징은 모든 환경에서 픽셀 하나까지 똑같이 그리는 일이 아니라, 합의된 지원 환경에서 핵심 사용자 과제가 안전하게 작동하도록 기능 탐지(Feature Detection)와 점진적 향상, 실제 브라우저 테스트를 조합하는 과정입니다. 테스트 코드도 내부 구현 세부사항이나 단순 정적 마크업을 그대로 베껴 확인하기보다, 순수 도메인 로직·컴포넌트 상호작용·핵심 사용자 흐름의 계약이 깨졌을 때 정확히 신호를 주는 테스트로 구성해야 유지보수 가치를 발휘합니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
function createCart(storage) {
return { save(items) { storage.write(items); } };
}
// 테스트에서는 기록 가능한 가짜 storage를 주입한다.저장소(storage) 의존성을 외부에서 주입받도록 설계한 예제입니다. 이렇게 경계를 나누면 실제 브라우저의 localStorage나 복잡한 UI를 띄우지 않고도 가짜(Fake) 저장소 객체를 넣어 저장 로직을 빠르게 단위 테스트할 수 있습니다.
자주 헷갈리는 포인트
- 단순한 기능에도 무조건 복잡한 클래스 상속과 추상화 계층을 많이 쌓는 것이 좋은 설계라고 생각하지 않습니다.
- 기능 지원 여부를 직접 확인(Feature Detection)하지 않고 브라우저 이름(User-Agent) 문자열만 비교해 동작을 단정하지 않습니다.
내 말로 설명해 보기
하루에도 여러 번 프로덕션에 배포하는 소규모 팀에서 긴 수명의 release 브랜치를 계속 유지한다면 어떤 비용과 장단점이 생길까요?
함께 읽으면 좋은 개념
관련 면접 질문 4개
크로스 브라우징은 어떤 기준으로 접근하고 검증하나요?
크로스 브라우징은 모든 브라우저에서 1픽셀까지 똑같이 보이게 만드는 작업이 아니라, 서비스가 목표로 하는 브라우저·OS·기기 범위에서 사용자가 핵심 기능을 문제없이 이용할 수 있도록 호환성을 확보하는 과정입니다. 먼저 사용자 통계와 비즈니스 요구를 바탕으로 지원 대상(browserslist)을 정의하고, User-Agent 문자열 추측 대신 기능 탐지(Feature Detection, @supports, 'in' 연산자 등)와 점진적 향상(Progressive Enhancement) 전략을 적용합니다. 아울러 Babel·Autoprefixer·polyfill로 기본 호환성을 맞추고, Safari·모바일 브라우저 등 실제 렌더링 엔진 환경에서 레이아웃·폼 입력·스크롤 동작을 자동화 테스트(Playwright 등)와 수동 점검으로 검증합니다.
꼬리질문과 참고자료 →객체 지향 프로그래밍(OOP)의 특징과 설계상 트레이드오프는 무엇인가요?
객체 지향 프로그래밍은 관련된 상태(데이터)와 행동(메서드)을 객체라는 책임 단위로 묶고, 추상화·캡슐화·상속·다형성을 통해 복잡한 시스템의 변경 영향을 관리하는 설계 패러다임입니다. 내부 구현을 숨기고 공개 인터페이스만 노출하는 캡슐화와, 조건문 분기 대신 동일한 인터페이스로 서로 다른 구현체를 교체할 수 있는 다형성은 프론트엔드 도메인 모델링과 테스트 대역(Mock/Fake) 주입에서도 매우 유용합니다. 다만 깊은 클래스 상속 계층은 부모·자식 간 결합도를 높여 변경을 어렵게 만들 수 있으므로, 상속보다 객체 조합(Composition)과 인터페이스 기반 설계를 우선 검토하는 것이 좋습니다.
꼬리질문과 참고자료 →Git Flow는 어떤 브랜치 운영 전략이며 언제 적합한가요?
Git Flow는 main(배포)·develop(통합) 두 개의 중심 브랜치를 두고, 역할에 따라 feature(기능 개발)·release(출시 준비 및 QA)·hotfix(운영 긴급 수정) 보조 브랜치를 나누어 운영하는 브랜치 전략입니다. 정기적인 버전 릴리스 주기가 있거나 여러 배포 버전을 동시에 검증·관리해야 하는 프로젝트에서는 작업 격리와 출시 안정화에 도움이 됩니다. 반면 하루에도 여러 번 배포하는 지속적 배포(CD) 환경에서는 브랜치 수명이 길어지면서 병합 충돌과 절차 비용이 커질 수 있으므로, 팀 규모와 배포 주기에 맞춰 GitHub Flow나 Trunk-Based Development와 비교해 선택합니다.
꼬리질문과 참고자료 →