- 발행일
1920px 고정 폭에서 100vw로 — "1980 결정 전"이라는 커밋 제목
1920px 고정 폭에서 100vw로
이 글은 2026년 9월에 당시 커밋 이력을 다시 보며 정리한 것입니다. 날짜는 작업한 날 기준입니다.
TripTune의 디자인 시안은 1920px 폭 기준이었습니다. 시안을 그대로 옮기면서 레이아웃의 큰 상자들에 max-width: 1920px을 걸어 뒀어요. .main, .content, .footer, 그리고 온보딩 이미지. 첫 커밋부터 그랬습니다.
8월 17일에 이런 제목의 커밋을 남겼습니다.
fc4e827 [24-08-17] 1980 결정 전
1980은 어디서 왔나
그 커밋의 onBoard.module.css diff입니다.
.onBoardingImg {
- width: 98vw;
- max-width: 1920px;
- height: auto;
+ width: 1980px;
+ height: 610px;
display: inline-block;
margin:0;
- max-height: 610px;
}
98vw에 max-width: 1920px이던 온보딩 이미지를 width: 1980px 고정으로 바꿨습니다. 같은 커밋의 Layout.module.css에서는 .footer의 max-width: 1920px이 위치만 바뀌고 값은 그대로예요. 그러니까 저장소 안에 1920과 1980이 동시에 있었습니다.
1980이라는 값은 어디에도 근거가 없습니다. 시안은 1920이었고 다른 상자들도 1920이었어요. 커밋 제목 "1980 결정 전"은 "1980으로 갈지 아직 정하기 전"이라는 뜻으로 읽히는데, 그 결정을 내린 커밋은 없습니다. 오타를 결정 사항으로 착각한 채 두 달을 보낸 것으로 보입니다. 확실하지는 않습니다. 커밋에 그 이상은 없어요.
같은 커밋에서 width: 100%이던 폼 상자들을 480px·500px 고정 폭으로 바꾼 것도 보입니다. 시안 수치를 그대로 박는 쪽으로 가던 시기였습니다.
두 달 뒤, 전부 100vw로
10월 19일 e8726e1("해상도 이슈 수정")에서 고정 폭을 한꺼번에 걷어냈습니다.
.main {
color:#000000;
- width: 100%;
- max-width: 1920px;
+ width: 100vw;
.content {
- width: 100%;
- max-width: 1920px;
+ width: 100vw;
.footer {
- width: 100%;
+ width: 100vw;
height: 324px;
- max-width: 1920px;
.onBoardingImg {
- width: 1980px;
+ width: 100vw;
height: 610px;
1920 셋과 1980 하나가 같은 날 전부 100vw가 됐습니다. 이 커밋 뒤로 저장소에서 1980은 사라졌어요.
"해상도 이슈"가 구체적으로 무엇이었는지는 커밋에 없습니다. 같은 커밋에서 left: 61.8%이던 배경 장식을 66%로 옮기고 스케줄 모달 폭을 240px에서 360px로 키운 걸 보면, 1920보다 좁거나 넓은 화면에서 배치가 어긋난 걸 고친 것으로 보입니다.
100vw가 가져온 것
100vw는 세로 스크롤바 폭을 포함한 뷰포트 폭입니다. 스크롤바가 있는 화면에서 width: 100vw인 상자는 스크롤바 폭만큼 화면보다 넓어지고 가로 스크롤이 생겨요. 8월 9일 "가로 스크롤 삭제"(7900500)에서 온보딩 이미지 태그의 width={"1920"}을 지우고 헤더 폭을 auto에서 100%로 바꾼 적이 있었는데, 두 달 뒤에 같은 종류의 값을 다시 넣은 셈입니다.
그 뒤 100vw를 건드린 커밋이 2025년 7월까지 열 개가 넘습니다. 현재 저장소(master)의 src/styles에는 100vw가 두 곳(하나는 max-width), 1920px이 두 곳(하나는 width, 하나는 max-width) 남아 있고, 404·500 페이지도 100vw를 씁니다. 어느 한쪽으로 정리되지 않은 채입니다.
검증
fc4e827의 diff에서width: 1980px한 곳과max-width: 1920px유지 한 곳을 확인했습니다.e8726e1의 diff에서100vw로 바뀐 네 곳(.main·.content·.footer·.onBoardingImg)을 확인했고, 그 커밋 시점에git grep '1920\|1980' -- src가 비어 있는 것을 확인했습니다.git log -S'100vw' -- src/styles로 이후 커밋 수를 셌습니다.- 당시 어느 해상도에서 어떻게 깨졌는지 캡처는 없습니다.
남은 것 · 한계
- 1980의 출처는 끝내 모릅니다. 오타라는 것이 가장 그럴듯하지만 커밋에는 "결정 전"이라고 적혀 있습니다.
100vw는 해결이 아니라 다음 문제의 시작이었습니다. 스크롤바 폭 문제를 그때는 몰랐고 이후 열 번 넘게 같은 속성을 만지게 됐습니다. 지금도100vw와1920px이 섞여 있습니다.- 8월 19일
be64281("반응형 처리")에서@media구간을 1600·1280·1024·768·480·320으로 여섯 단 만들었는데, 그 안에서도max-width: 100vw를 쓰고 있습니다. 반응형과 고정 폭이 같은 파일에 공존하던 시기였어요. - 시안 수치를 그대로 박는 습관은 이 프로젝트 내내 남았습니다. 시안과 코드를 체계적으로 대조한 건 2026년 5월 Figma 44프레임을 코드와 대조하기2026-05-10Figma 44프레임을 코드와 대조하기 — "다르다"와 "틀렸다"를 나누는 일디자인과 화면이 조금씩 다른데 뭐가 틀린 건지 모르겠다는 상태를 정리하려고, Figma 44프레임을 코드와 전수 대조해 리포트를 만들었습니다. 핵심은 차이를 찾는 게 아니라 "의도적 조정"과 "결함"을 가르는 규칙이었어요. 그리고 2.5개월 뒤에 확인해보니 HIGH 4건 중 2건이 아직 미반영입니다.에서였습니다.
관련 글: Figma 44프레임을 코드와 대조하기2026-05-10Figma 44프레임을 코드와 대조하기 — "다르다"와 "틀렸다"를 나누는 일디자인과 화면이 조금씩 다른데 뭐가 틀린 건지 모르겠다는 상태를 정리하려고, Figma 44프레임을 코드와 전수 대조해 리포트를 만들었습니다. 핵심은 차이를 찾는 게 아니라 "의도적 조정"과 "결함"을 가르는 규칙이었어요. 그리고 2.5개월 뒤에 확인해보니 HIGH 4건 중 2건이 아직 미반영입니다. · 루트 레이아웃에 'use client'가 붙어 있었다2026-03-14루트 레이아웃에 'use client'가 붙어 있었다 — 라이트하우스 점수를 보러 갔다가App Router로 만들었다고 믿었던 프로젝트의 루트 레이아웃에 use client가 붙어 있었습니다. 그 한 줄 때문에 트리 전체가 클라이언트 컴포넌트였고, next/head는 무동작이었으며, QueryClient는 모듈 최상단에서 만들어지고 있었어요. 점수를 올리러 갔다가 경계를 다시 그은 기록입니다. · 55개 파일의 회색을 처음 통일했다2025-09-1955개 파일의 회색을 처음 통일했다 — 그때는 대비를 재지 않았다입사 다섯 달째, 화면마다 제각각이던 표 정렬과 보조 제목과 회색을 55개 파일에서 한 번에 손봤습니다. 회색은 400을 500으로 올렸는데, 그때는 대비 수치를 재지 않고 눈으로 골랐어요. 1년 뒤 대비 감사를 하면서 같은 회색이 다시 도마에 올랐고, 그날 고른 값이 우연히 기준선과 같았다는 걸 알았습니다.