코딩 실력이 아니라 설계 관점이 연봉을 바꾼다
Article
왜 실력이 비슷한데 연봉이 다른가
같은 회사, 비슷한 연차의 퍼블리셔 두 명이 있다고 해봅시다.
A는 새로운 CSS 속성이 나오면 바로 공부하고, 코딩 속도도 빠르고, 다양한 레이아웃을 구현할 수 있습니다.
B는 코딩 속도는 A보다 느리지만, 시안을 받으면 항상 "이건 이렇게 구조를 잡아야 나중에 수정이 편합니다"라고 먼저 말합니다.
6개월 뒤, 연봉 협상에서 B가 더 높은 인상을 받았습니다.
왜? PM 입장에서 B는 지시 없이도 판단하는 사람이기 때문입니다. A는 훌륭한 "실행자"지만, B는 "실행 + 판단"을 같이 합니다. 그 판단이 프로젝트의 리스크를 줄여줍니다.
"더 많이 아는 것"의 함정
퍼블리셔, 신입 개발자들이 빠지기 쉬운 함정이 있습니다.
"더 많이 알면 실력이 올라간다."
그래서 새로운 CSS 속성을 공부하고, 새 프레임워크를 배우고, 새 AI 툴을 익힙니다. 양적으로 넓어집니다.
그런데 면접에서, 또는 실무에서 이런 질문을 받으면 멈춥니다.
- "이 레이아웃을 왜 Flexbox로 잡으셨어요? Grid가 더 적합하지 않아요?"
- "이 컴포넌트를 왜 이 단위로 분리하셨어요?"
- "이 페이지의 마크업 구조를 왜 이렇게 잡았는지 설명해주세요."
"왜?"에 답하지 못하면, 아는 게 많아도 설계할 줄 모르는 겁니다.
Flexbox와 Grid를 둘 다 쓸 줄 아는 건 스킬입니다. 이 상황에서 왜 Flexbox를 선택했는지 설명할 수 있는 건 관점입니다. 연봉을 바꾸는 건 스킬이 아니라 관점입니다.
설계 관점이란 구체적으로 뭔가
거창한 게 아닙니다. 코딩하기 전에 "왜?"를 묻는 습관입니다.
레벨 1: 시안대로 코딩한다
시안 받음 → 바로 코딩 시작 → 완성 → 제출
대부분의 신입 퍼블리셔가 여기에 있습니다. 문제없이 동작하면 끝이라고 생각합니다.
레벨 2: 구조를 생각하고 코딩한다
시안 받음 → 구조 분석 → "이건 공통 컴포넌트로 빼야겠다" → 코딩 → 완성
여기부터 차이가 나기 시작합니다. 단순히 "보이는 대로"가 아니라, 나중에 수정될 걸 고려한 구조를 잡습니다.
레벨 3: 판단 근거를 설명할 수 있다
시안 받음 → 구조 분석 → 판단 근거 정리 →
"이 부분은 재사용 가능성이 높아서 컴포넌트로 분리했고,
이 부분은 이 페이지에서만 쓰이니까 인라인으로 처리했습니다" → 코딩
이 레벨에 있는 사람은 대체가 어렵습니다. 왜냐하면 이 판단은 프로젝트의 맥락, 클라이언트의 요구사항, 기술적 제약을 동시에 고려한 결과이기 때문입니다. AI가 못 하는 영역입니다.
신입도 레벨 2는 내일부터 가능하다
"나는 아직 레벨 1인데, 어떻게 올라가지?"
레벨 2로 가는 건 사실 간단합니다. 코딩 시작 전에 5분만 투자하면 됩니다.
시안을 받으면 바로 에디터를 열지 말고, 이 3가지를 먼저 생각해보세요.
1. 반복되는 패턴이 있는가? 헤더, 카드, 버튼 — 여러 페이지에서 같은 모양이 반복되면 공통으로 뺄 수 있습니다.
2. 나중에 바뀔 가능성이 높은 부분은 어디인가? 클라이언트가 "이거 나중에 바꿀 수도 있어요"라고 한 부분. 또는 경험상 자주 수정 요청이 오는 부분. 이런 곳은 구조를 유연하게 잡아야 합니다.
3. 이 구조를 다른 팀원이 보면 이해할 수 있는가? 내가 짠 코드를 내일 다른 사람이 이어 작업한다면? 클래스명만 보고도 구조를 파악할 수 있는가?
이 3가지를 생각하는 데 5분이면 충분합니다. 하지만 이 5분이 "시킨 대로 하는 사람"과 "구조를 보는 사람"의 차이를 만듭니다.
관점이 바뀌면 보이는 것이 달라진다
설계 관점을 가지기 시작하면, 같은 시안을 봐도 다른 게 보입니다.
관점 없을 때: "헤더, 메인, 사이드바, 푸터. 4개 영역이네. 바로 짜야지."
관점 있을 때: "헤더는 모든 페이지에서 공통이니까 컴포넌트로 빼고, 사이드바는 대시보드에서만 쓰이니까 레이아웃 단위로 분리해야겠다. 메인 콘텐츠 영역은 페이지마다 다르니까 슬롯 구조로 가는 게 맞겠다."
코드를 한 줄도 안 쳤는데, 이미 구조가 결정됐습니다. 이게 설계입니다.
이 블로그에서 관점을 넓히는 법
이 블로그의 tech 카테고리 글들은 대부분 "왜 이렇게 해야 하는가"에 초점을 맞추고 있습니다.
- HTML vs TSX 비교 — 같은 UI를 왜 다른 방식으로 짜야 하는가
- Server vs Client Component 경계 — 컴포넌트 분리의 판단 기준
- 컴포넌트 설계: 납품용 vs 서비스용 — 맥락에 따라 "좋은 코드"가 달라지는 이유
- layout.tsx로 보는 프로젝트 구조 — 폴더 하나가 왜 아키텍처 결정인가
코드를 배우는 게 아니라, 판단의 기준을 배우는 것입니다. 틈틈이 읽어보면서 "나라면 어떻게 했을까?"를 생각해보세요.
결론
CSS 속성을 100개 아는 것보다, 이 상황에서 왜 이 속성을 써야 하는지 설명할 수 있는 게 더 가치 있습니다.
새 프레임워크를 배우는 것보다, 지금 쓰는 기술을 왜 이렇게 쓰는지 깊이 이해하는 게 더 가치 있습니다.
AI 시대에 코딩 속도는 점점 덜 중요해집니다. 대신 "왜 이렇게 해야 하는가"를 판단하는 능력이 점점 더 중요해집니다.
설계 관점은 타고나는 게 아닙니다. 내일 작업에서 "왜?"를 묻는 것으로 시작할 수 있습니다.
그 "왜?"가 쌓이면, 코딩 실력이 아니라 관점의 깊이로 평가받는 사람이 됩니다. 그리고 그런 사람의 자리는 AI가 대체할 수 없습니다.