코드 땜장이

단위 테스트와 통합 테스트, 무엇을 어디까지 검증해야 할까 빠른 답 단위 테스트는 한 함수, 클래스, 정책 객체처럼 작은 책임을 빠르게 검증하고 외부 의존성은 보통 테스트 대역으로 분리한다. 통합 테스트는 DB, HTTP API, 파일 시스템, 메시지 브로커처럼 실제 연결 지점이 함께 동작하는지 확인한다. 슬라이스 테스트는 웹 계층이나 저장소 계층처럼 일부 구성만 로드해 단위 테스트보다 현실적이고 전체 통합 테스트보다 가볍게 검증한다. CI에서는 빠른 테스트를 먼저 실행하고, 통합·E2E·스모크 테스트는 변경 위험과 배포 단계에 맞춰 품질 게이트로 나누는 편이 관리하기 쉽다. 목차 한눈에 비교 왜 경계가 헷갈리기 쉬운가 선택 기준 매트릭스 테스트 범위 정하는 흐름 스택 중립 예시로 보는 테스트 경계 슬라이스 테스트를 둘 위치 CI 품질 게이트 나누기 실패 출력으로 원인 좁히기 테스트 대역과 실제 환경의 균형 운영 검증까지 이어지는 테스트 전략 한눈에 비교 검증 범위 단위 테스트는 작은 책임 단위, 슬라이스 테스트는 특정 계층, 통합 테스트는 여러 구성 요소의 연결을 본다. 실행 비용 단위 테스트는 빠르고 자주 돌리기 좋으며, 통합 테스트는 환경 준비와 I/O 때문에 상대적으로 느리다. 실패 원인 단위 테스트는 실패 지점이 좁고, 통합 테스트는 설정, 데이터, 네트워크, 트랜잭션까지 원인 후보가 넓어진다. 의존성 처리 단위 테스트는 대역 객체를 자주 쓰고, 통합 테스트는 실제 DB나 컨테이너, 테스트용 외부 API 서버를 사용한다. 신뢰도 성격 단위 테스트는 로직 회귀를 빠르게 잡고, 통합 테스트는 배포 후 연결 문제를 줄이는 데 도움이 된다. 왜 경계가 헷갈리기 쉬운가 테스트 이름은 단순하지만 실제 코드에서는 경계가 자주 흐려진다. 예를 들어 OrderService 하나만 테스트한다고 해도 그 안에서 재고 조회, 결제 요청, 주문 저장이 모두 일어나면 클래스 하나를 테스트한다는 사실만으로 단위 테스트라고 부르기 어렵다. 테스트가 묻는 질문...

시맨틱 마크업은 왜 접근성과 SEO의 출발점이 되는가 빠른 답 시맨틱 마크업은 화면 모양보다 콘텐츠의 역할과 관계를 HTML 구조에 남기는 작성 방식이다. 접근성에서는 제목, 랜드마크, 버튼과 링크의 역할이 스크린 리더와 키보드 탐색의 기준이 된다. SEO에서는 주요 콘텐츠, 제목 계층, 링크 구조가 검색 엔진이 문서를 이해하는 단서가 된다. CSR에서도 최종 DOM의 의미 구조는 중요하지만, 공개 콘텐츠라면 초기 HTML에 무엇이 들어 있는지도 함께 봐야 한다. 목차 점검 매트릭스 시맨틱 마크업은 태그 이름보다 의미 구조에 가깝다 브라우저와 보조 기술은 구조를 기준으로 해석한다 점검 순서는 제목, 랜드마크, 상호작용부터 잡는다 문서 구조를 먼저 모델링해 본다 버튼처럼 보이는 것과 버튼으로 동작하는 것은 다르다 자동 점검과 CI 품질 게이트를 둔다 CSR 환경에서는 초기 HTML과 최종 DOM을 나누어 본다 운영 중 자주 깨지는 지점을 미리 본다 점검 매트릭스 점검 매트릭스 문서 구조 머리말, 탐색, 본문, 보조 영역, 바닥글의 역할이 구분되는지 확인해 페이지의 큰 지도를 만든다. 제목 계층 글자 크기가 아니라 문서의 포함 관계에 맞게 제목 수준이 이어지는지 확인한다. 상호작용 요소 클릭 가능한 요소가 키보드와 보조 기술에서 버튼, 링크, 입력 필드로 인식되는지 확인한다. 주요 콘텐츠 반복되는 메뉴를 지나 본문으로 바로 이동할 수 있는지 확인해 탐색 비용을 줄인다. 렌더링 시점 CSR 페이지에서 초기 HTML과 최종 DOM이 각각 어떤 정보를 제공하는지 확인한다. 자동 검증 린트, 접근성 검사, E2E 스모크 테스트가 배포 전 최소 기준을 막는지 확인한다. 시맨틱 마크업은 태그 이름보다 의미 구조에 가깝다 시맨틱 마크업은 특정 요소 이름을 많이 쓰는 기법이 아니다. 페이지 안의 콘텐츠가 어떤 역할을 하는지 브라우저, 보조 기술, 검색 엔진이 해석할 수 있도록 구조를 남기는 방식이다. 같은 박스처럼 보이는 영역도 문서 안에서는 서로 다른 의...

프론트엔드 E2E 테스트란 무엇이고, 어떤 사용자 흐름부터 검증해야 할까 빠른 답 E2E 테스트는 브라우저에서 사용자의 주요 흐름이 끝까지 완료되는지 확인하는 마지막 품질 기준선이다. 모든 화면을 자동화하기보다 로그인, 결제, 신청, 권한 확인처럼 실패 비용이 큰 여정부터 잡는 편이 유지 비용이 낮다. 도구 선택보다 더 자주 발목을 잡는 것은 불안정한 셀렉터, 고정 대기, 재현되지 않는 테스트 데이터다. 실패를 빨리 좁히려면 스크린샷만 남기지 말고 trace , 콘솔 로그, 네트워크 기록, 요청 ID를 함께 남겨야 한다. E2E 테스트는 브라우저를 얼마나 많이 조작했는가를 보는 작업이 아니라, 배포 전후에 사용자가 중요한 일을 실제로 끝낼 수 있는지를 확인하는 작업에 가깝다. 단위 테스트와 통합 테스트가 코드 단위의 정확도를 높여 준다면, E2E 테스트는 라우팅, 인증, 렌더링, 네트워크, 권한이 연결된 최종 경로를 확인한다. 목차 시간 흐름으로 이해하기 흐름으로 보기 왜 이 기준을 기본 품질로 볼까 핵심 흐름 선정 실제로 막히는 지점 테스트 환경 준비 브라우저 시나리오 실행 실패 증거 수집 CI 품질 게이트 무엇을 E2E로 두고 무엇은 단위·통합 테스트에 맡길까 시간 흐름으로 이해하기 설계 시점 실패 비용이 큰 사용자 여정 2~5개를 먼저 고른다. → 준비 시점 계정, 시드 데이터, 외부 의존성을 반복 가능한 상태로 맞춘다. → 실행 시점 입력과 클릭보다 최종 화면, 세션 유지, 응답 결과를 기준으로 본다. → 실패 시점 스크린샷, 콘솔, 네트워크, trace 를 함께 저장해 원인을 좁힌다. → 배포 시점 PR 스모크, 배포 전 회귀, 스테이징 검증을 분리해 운영 흐름에 붙인다. 시간축으로 보면 E2E는 테스트 코드 한 파일의 문제가 아니라, 설계와 운영을 잇는 품질 장치에 가깝다. 앞단에서 범위를 잘 고르고, 중간에서 증거를 잘 남기고, 뒷단에서 품질 게이트를 분리해야 유지가 쉬워진다. 흐름으로 보기 흐름 다이어그램 이 순서를 거꾸...

웹 접근성은 왜 기능이 아니라 기본 품질일까: 구조부터 점검까지 실무적으로 이해하기 빠른 답 웹 접근성은 일부 사용자를 위한 부가 기능이 아니라, 더 많은 사용자가 같은 기능을 실제로 사용할 수 있게 만드는 기본 품질입니다. 출발점은 복잡한 위젯이나 ARIA 가 아니라 HTML 구조, 제목 체계, 버튼과 링크의 의미 같은 기본 마크업입니다. ARIA 는 시맨틱 요소를 대체하지 못하고, 이름·역할·상태를 보강해야 할 때만 의미가 있습니다. 자동 검사 점수보다 중요한 것은 키보드와 스크린 리더로 핵심 사용자 흐름을 끝까지 수행할 수 있는지입니다. 목차 점검 순서 흐름으로 보기 웹 접근성을 기본 품질로 보는 이유 사용자는 어디에서 막히는가 시맨틱 구조가 접근성의 출발점인 이유 폼, 버튼, 모달에서 바로 적용하는 코드 예시 ARIA는 언제 필요하고 언제 멈추는 편이 나은가 키보드 포커스, 대비, 오류 메시지는 함께 봐야 한다 개발 과정에 녹이는 설정과 자동 점검 개선 우선순위를 잡을 때 놓치기 쉬운 점 점검 순서 제목 구조, 랜드마크, 버튼·링크의 의미를 먼저 확인합니다. 마우스를 치우고 Tab , Shift+Tab , Enter , 방향키만으로 이동해 봅니다. 폼 입력, 오류 메시지, 제출 실패 흐름이 읽히는지 점검합니다. 모달·탭·드롭다운 같은 복합 UI에 필요한 ARIA 만 보강합니다. 자동 진단 도구로 누락을 찾고, 마지막에 실제 보조기기 탐색으로 우선순위를 다시 조정합니다. 이 순서가 유용한 이유는 접근성 문제가 대개 화려한 인터랙션보다 기본 구조에서 먼저 드러나기 때문입니다. 처음부터 속성을 많이 덧붙이기보다, 문서 구조와 상호작용 흐름을 바로잡는 편이 실제 사용성 개선으로 이어지는 경우가 많습니다. 흐름으로 보기 1 구조 작성: 제목, 랜드마크, 입력 요소, 버튼의 의미를 마크업에 담습니다. ↓ 2 브라우저 해석: DOM 과 기본 시맨틱을 바탕으로 접근성 트리가 만들어집니다. ↓ 3 보조기기 전달: 스크린 리더는 요소의 ...