시니어 개발자는 무엇인가

주니어 팀원이 어떤 개발자를 시니어 프론트엔드 개발자라고 불러도 되는지 물었다. 나 역시 정리해 둔 답이 없어서 곧바로 답해 주지 못했다. 이 질문은 생각보다 어렵다. 오래 일했다고 시니어라고 부르기에는 부족하고, 특정 프레임워크만 능숙하게 다룬다고 해서 시니어라고 부르기에도 좁다. React, TypeScript, 복잡한 상태 관리, 디자인 시스템—이런 말들은 시니어의 한 면을 짚을 수는 있지만, 그것만으로는 부족하다. ## 구현이 아니라 판단 한때는 실력을 "얼마나 잘 구현하느냐"로 말해 왔다. 복잡한 화면을 빠르게 만들 수 있는지, API와 상태를 연결할 수 있는지, 인터랙션이 자연스러운지. 물론 지금도 구현 능력은 중요하다. 그런데 AI가 코드를 빠르게 생성하는 시대에는 그 척도만으로 시니어를 설명하기 어렵다. 컴포넌트, 이벤트, API 호출, 에러 처리까지 초안은 짧은 시간에 나온다. 그렇다고 시니어의 역할이 줄어드는 것일까. 나는 반대라고 본다. 오히려 더 분명해진다. 중요한 것은 얼마나 많이 직접 쓰느냐가 아니라, 사람이 만들었든 AI가 만들었든 결과가 올바른 방향으로 가고 있는지 판단하는 능력이다. 시니어 프론트엔드 개발자는 단순히 기능을 잘 만드는 사람이 아니다. 제품의 의도, 사용자 경험, 시스템 구조가 실제 결과물 안에서 서로 어긋나지 않는지 보는 사람이다. "되게 만드는 것"을 넘어, 결과가 맞는 방향으로 수렴하도록 만드는 사람이다. ## "돌아간다"고 해서 맞는 것은 아니다 "맞다"는 단순히 돌아간다는 뜻이 아니다. 버튼이 반응하고 페이지가 넘어가고 데이터가 보인다고 해서 항상 맞는 것은 아니다. 사용자의 기대와 어긋날 수 있고, 웹이 원래 제공하는 동작과 어긋날 수 있으며, 접근성이 깨져 있을 수 있다. 지금은 괜찮아 보여도 나중에 확장할 때 구조가 버티지 못할 수도 있다. 페이지 이동을 구현한다고 해보자. 버튼 클릭으로 다른 화면으로 보내는 것은 어렵지 않다. 특별한 지시가 없으면 AI는 `onClick`에서 `window.location`을 호출하는 식의 초안을 내놓는다. 화면은 이동하고, 기능적으로도 문제없어 보인다. 시니어는 여기서 멈추지 않는다. 이게 단순한 클릭인지, "이동"이라는 의미를 갖는 동작인지 먼저 본다. 사용자를 다른 페이지로 보내는 일이라면 브라우저가 제공하는 링크의 의미를 따라야 한다고 판단한다. `onClick`만으로 때우지 않고 `a` 태그나 `<Link />`를 쓴다. 겉으론 사소해 보인다. 그러나 링크로 구현해야 뒤로 가기, 새 탭, 주소 복사, SEO, 접근성이 한꺼번에 맞춰진다. 화면만 넘어가는 것과, 웹의 의미 안에서 올바르게 넘어가는 것은 다르다. 당장 동작하는지만이 아니라, 그 기능이 어떤 의미를 갖는지, 그 의미에 맞게 만들어졌는지를 본다. 이런 어긋남은 페이지 이동처럼 눈에 띄는 기능에서만 드러나지 않는다. 훨씬 작은 UI에서도 드러난다. 버튼인데 텍스트에만 클릭이 걸려 있고 전체 영역은 눌리지 않는 경우. 기능은 동작한다. 텍스트를 누르면 이벤트는 발생한다. 그러나 사용자는 버튼 전체가 눌리기를 기대한다. 입력창도 같다. 겉으로 넓어 보이지만 안쪽의 작은 `input`만 포커스를 받는 경우가 있다. 에러도 없고 테스트도 통과할 수 있다. 그래도 경험은 어긋난다. 이런 문제는 치명적인 버그처럼 보이지 않는다. 그래서 지나치기 쉽다. 하지만 작은 어긋남이 쌓이면 사용자는 "뭔가 불편하다", "이 제품은 덜 다듬어졌다"고 느낀다. 정확히 무엇이 문제인지 설명하지 못하더라도. 프론트엔드는 화면만 만드는 일이 아니다. 사용자가 제품과 만나는 앞단이다. DB 구조나 서버 내부는 보이지 않는다. 버튼, 입력, 전환, 로딩, 에러 메시지, 피드백으로 제품을 경험한다. 프론트엔드 개발자가 만드는 것은 단순한 UI 조각이 아니다. 제품의 의도가 사용자에게 전달되는 방식 그 자체다. ## 기준을 남기는 사람 앞에서는 링크와 버튼처럼 프론트엔드에 가까운 세부를 많이 들었다. 그런데 조금 더 넓게 생각해 보면, 시니어 개발자라고 부를 만한 사람은 그런 요소만으로 잘리지 않고, 아래와 같은 면도 함께 갖추지 않을까 싶다. 팀·코드베이스·기준에 관한 이야기는 직군이 달라도 조직 안에서는 비슷한 형태로 반복된다. 시간이 지나면 시스템은 자연스럽게 흐트러진다. 급한 일정 때문에 예외가 생기고, 임시 처리가 추가되고, 비슷하지만 조금 다른 구현이 반복된다. 어느 순간 아무도 자신 있게 고치기 어려운 코드가 된다. 이때 AI는 편의라기보다 증폭기에 가깝다. AI는 코드베이스의 패턴을 강하게 따라간다. 좋은 패턴이 많으면 좋은 결과로 이어지고, 나쁜 패턴이 많으면 나쁜 결과를 더 빠르게 반복한다. 구조, 네이밍, 책임 분리는 이제 사람만을 위한 정리가 아니다. 사람이든 AI든 같은 방향으로 만들게 하는 기반이 된다. 기준이 없으면 팀은 제각각 구현한다. 한 사람은 링크를 의미에 맞게 구현하고, 다른 사람은 클릭 이벤트로 처리한다. 한 사람은 상태를 도메인 기준으로 정리하고, 다른 사람은 화면마다 흩어놓는다. 한 사람은 에러 상태를 사용자 경험의 일부로 보고, 다른 사람은 콘솔 에러만 없으면 된다고 생각한다. 각각의 선택은 작아 보인다. 그러나 이런 차이가 쌓이면 시스템은 일관성을 잃고, 이해하기 어렵고, 수정하기 어렵고, 결국 팀의 속도를 떨어뜨린다. 시니어는 이 흐름을 막는 사람이다. 코드 리뷰에서 스타일만 짚는 것이 아니라, 왜 이 방식이 더 나은지, 어떤 문제가 반복되고 있는지, 책임과 상태와 경계를 어디에 둬야 하는지 팀이 같은 언어로 판단하게 만드는 사람이다. 중요한 것은 문제를 많이 지적하는 것이 아니라, 같은 문제가 덜 생기게 만드는 것이다. 접근성 지적이 PR마다 반복된다면, 그때마다 수정하는 것으로는 부족하다. 공통 컴포넌트를 고치고, 사용 예시를 정리하고, 디자인 시스템의 기준을 업데이트해야 한다. 에러 처리 방식이 제각각이면 패턴을 정리하고 기본 흐름을 만들어야 한다. 상태 위치가 매번 흔들리면 나누는 기준을 팀 안에서 합의해야 한다. 그래서 시니어의 영향력은 작성한 코드의 양으로만 측정되지 않는다. 남긴 기준, 정리한 구조, 팀이 다시 같은 실수를 하지 않게 만든 정도가 더 크다. 팀에서 시니어에게 기대하는 것도 결국 이 지점이다. 자기 일만 잘 끝내는 사람이 아니라, 팀 전체가 더 나은 방향으로 일하게 만들고, 빠르게 만들면서도 나중에 속도를 깎아먹을 리스크를 줄이며, 반복해서 좋은 선택을 하도록 기준을 남기는 사람. ## 완성도의 기준이 다른 사람 앞에서는 화면과 동작의 예로 말했지만, 여기서 말하는 간극은 링크와 버튼에만 해당하지 않는다. "요청은 처리됐다"와 "의도한 대로 잘 처리됐다" 사이, "일단 배포됐다"와 "운영에서 버틴다" 사이에서 같은 종류의 판단이 필요하다. 앞에서 말한 것들을 실제로 하려면 시간이 더 걸린다. 더 고민해야 하고, 더 많은 것을 챙겨야 한다. 기능이 돌아가는 상황에서 굳이 하지 않아도 되는 일처럼 보이기도 한다. 더 빨리 끝낼 수 있는 선택지는 항상 있다. 시니어는 그 선택지를 고르지 않는 사람이다. 특별한 의지로 버티는 것이 아니라, 완성도의 기준 자체가 다르다. "돌아가면 됐다"가 아니라, "제대로 동작해야 한다"가 기본이다. 그 기준이 내면화되어 있어서, 한 단계 더 들어가는 것이 추가 작업이 아니라 당연한 과정으로 느껴진다. 이 기준은 특별한 상황에서만 작동하지 않는다. 기능이 완료되었다고 느끼는 순간에도, 어딘가 찜찜한 부분이 있으면 그냥 넘기지 않는 습관이다. 만족하기 쉬운 상황에서 기준을 낮추지 않는 것. 그 일관성이 시니어를 만든다. 앞에서 그랬듯이, 다른 계층에서도 같은 태도가 드러난다. ## 현실과의 균형 이 모든 일은 프로젝트의 현실 안에서 이루어져야 한다. 구조적으로 맞아도 일정과 팀 상황을 무시한 제안은 실행되지 않는다. 실행되지 않는 이상론은 팀을 설득하지 못한다. 좋은 시니어는 "이걸 제대로 하려면 시간이 필요하다"고 멈춰 서지 않는다. 기존 프로젝트의 흐름을 유지하면서, 기능을 만드는 와중에도 조금씩 구조를 바로잡는다. 지금 반드시 손봐야 할 것과 나중으로 미뤄도 되는 것을 구분하고, 큰 변경은 잘게 쪼개 한 번에 흔들지 않는다. 한 번 짚고 지나가면 그걸로 끝이 아니라, 팀이 다시 같은 방향으로 돌아가고 있지 않은지 계속 살핀다. 기술적 개선을 "별도 작업"으로 분리하면 항상 뒷순위로 밀린다. 일상적인 개발 흐름 안에서 조금씩, 그러나 꾸준히 바꿔 나가는 것이 결국 시스템을 지킨다. AI 덕분에 잘못된 방향도 빠르게 쌓일 수 있다. 속도를 무조건 늦추는 사람이 아니라, 빠른 속도가 엇나가지 않게 조정하는 사람. 그 책임을 지속적으로 지는 사람이 시니어다. ## 맺음 앞은 화면과 구현의 이야기로 썼다. 돌이켜 보면 직군을 가리지 않고 같은 질문에 닿는다. 의도와 결과가 맞는지, 팀에 기준이 남는지, 선이 어디인지, 현실과 어떻게 맞출 것인지. 시니어에 가깝다고 느끼는 사람은 대략 이런 쪽이다. 돌아가면 됐다고 끝내지 않고, 제대로인지를 묻는다. 쉬운 쪽이 있어도 나은 쪽을 고른다. 그 판단을 혼자만의 습관에 묶어 두지 않고 팀에 남기고, 일상적인 흐름 안에서 방향을 조정한다. 지금은 그렇게 본다.