면접에서 "좋은 개발자가 뭐라고 생각하세요?"라는 질문을 받았다. 준비한 답변을 했다. 뭐라고 했는지 정확히는 기억 안 나는데, "비즈니스 임팩트를 만드는 사람"이라는 취지의 말을 꽤 그럴듯하게 포장해서 했던 것 같다. 면접관이 고개를 끄덕였고, 나도 꽤 잘 답한 것 같아서 기분이 나쁘지 않았다. 그런데 면접이 끝나고 건물 밖으로 나와서 걸어가는데, 갑자기 이런 생각이 스쳤다.

"나 진짜 그렇게 생각하나?"

그 질문이 이상하게 계속 머릿속에서 맴돌았다. 집에 가는 지하철에서도, 샤워하면서도. 면접 결과가 궁금한 게 아니라 내 대답이 진심이었는지가 궁금한 거였다. 그래서 그날 밤에 노트 앱을 열고 적어봤다. 1년 차 때 나는 좋은 개발자를 어떻게 정의했는지, 지금은 뭐가 달라졌는지.

적다 보니까 꽤 많이 바뀌어 있었다.

1년 차: 코드를 잘 짜는 사람#

처음 개발을 시작했을 때, 좋은 개발자의 이미지는 명확했다. 코드를 잘 짜는 사람. 클린 코드를 읽고, 함수는 하나의 역할만 하도록 쪼개고, 네이밍에 30분씩 고민하고, 디자인 패턴을 자유자재로 쓰는 사람. GitHub에 초록 잔디가 빼곡하고, LeetCode medium을 30분 안에 풀고, 새로운 기술 스택이 나오면 주말에 바로 사이드 프로젝트를 만들어보는 사람.

솔직히 말하면 그때는 코드 자체에 대한 집착이 있었다. PR 리뷰에서 "이 부분 좀 더 깔끔하게 할 수 있을 것 같아요"라는 코멘트를 받으면 자존심이 상했다. 리팩토링을 하면서 변수명을 바꾸고 추상화 레이어를 하나 더 넣을 때의 그 만족감. 코드가 예뻐지는 걸 보면서 "나 좀 잘하는 것 같은데"라고 느꼈다.

그때 나한테 "좋은 개발자"란 결국 기술적으로 뛰어난 사람이었다. 알고리즘, 자료구조, TypeScript 타입 체조, CSS 애니메이션, 번들 사이즈 최적화 — 이런 걸 잘하면 좋은 개발자. 단순했다.

그리고 그 기준으로 보면 나는 항상 부족했다. 주변에 나보다 잘하는 사람은 무한했고, 새로운 기술은 끊임없이 나왔고, 배워야 할 건 줄어들 줄 몰랐다. 좋은 개발자가 되려면 끝없이 기술을 갈고닦아야 한다고 생각했다. 그 자체가 틀린 말은 아닌데, 뭔가 빠져 있었다.

2년 차: 문제를 잘 푸는 사람#

전환점이 있었다. 우리 팀에서 상품 상세 페이지 로딩 속도를 개선하는 프로젝트를 맡았을 때의 일이다.

나는 당연히 코드 레벨에서 접근했다. React 렌더링 최적화, 이미지 lazy loading, 번들 스플리팅. 일주일 동안 열심히 작업했고, Lighthouse 점수가 20점 정도 올랐다. 꽤 뿌듯했다.

그런데 같은 팀의 시니어 한 분이 접근한 방식은 완전히 달랐다. 먼저 GA 데이터를 뒤져서 실제 이탈률이 높은 구간을 찾았다. 알고 보니 페이지 로딩 자체보다 상품 옵션을 선택하는 UI에서 이탈이 심하게 일어나고 있었다. 옵션 조합이 복잡한 상품에서 유저가 뭘 골라야 할지 모르겠다는 반응이 많았던 거다. 이 분은 기술적인 최적화 대신 옵션 UI를 재설계하는 방향을 제안했고, 결과적으로 전환율이 15% 올랐다.

나는 "페이지가 느리다"는 문제를 받고 코드를 최적화했다. 이 분은 "왜 유저가 떠나는가"라는 진짜 문제를 찾았다.

그때 처음으로 깨달았다. 기술은 도구다. 아무리 정교한 코드를 짜도, 풀고 있는 문제 자체가 잘못되면 의미가 없다. 좋은 개발자는 코드를 잘 짜는 사람이 아니라 올바른 문제를 찾고, 그 문제를 기술로 해결하는 사람이라는 생각이 그때부터 자리잡기 시작했다.

이때부터 나의 관심사가 조금씩 바뀌었다. "이 기능을 어떻게 만들지"보다 "이 기능을 왜 만들어야 하지"를 먼저 생각하게 됐다. PM이 기획서를 가져오면 기술적 구현 방법보다 "이게 유저한테 실제로 도움이 되나?"를 먼저 따졌다. 가끔은 "이거 안 만들어도 될 것 같은데요"라고 말할 때도 있었다. 1년 차의 나였으면 상상도 못 했을 일이다.

그리고 지금#

요즘 나한테 "좋은 개발자가 뭐야?"라고 물으면, 아마 이렇게 답할 것 같다.

같이 일하고 싶은 사람.

좀 뜬금없게 들릴 수 있다. 코드 실력은? 문제 해결 능력은? 당연히 중요하다. 근데 그건 일정 수준 이상이면 기본값이 된다. 2~3년 차 이상이면 대부분 코드를 "어느 정도"는 짠다. React 컴포넌트를 설계하고, API를 연동하고, 버그를 추적하는 건 경력이 쌓이면 어느 정도 되는 영역이다. 물론 깊이의 차이는 있지만, 실무에서 발을 못 붙일 정도로 코드를 못 짜는 사람은 생각보다 드물다.

차이가 나는 건 다른 곳이다.

코드 리뷰를 할 때 "이거 왜 이렇게 짰어요?"가 아니라 "이 방향도 좋은데, 이런 관점도 한번 생각해보면 어떨까요?"라고 말하는 사람. 장애가 터졌을 때 범인 찾기가 아니라 "일단 복구하고, 나중에 원인 분석하자"를 먼저 말하는 사람. 자기가 모르는 걸 모른다고 솔직하게 말할 수 있는 사람. 문서를 귀찮아하지 않는 사람. 새로 들어온 팀원한테 "이건 이래서 이렇게 된 거야"를 기꺼이 설명해주는 사람.

한마디로 말하면 팀의 전체 아웃풋을 올리는 사람이다.

혼자서 10의 성과를 내는 것도 대단하다. 하지만 내가 팀에 있음으로써 다른 사람들도 각자 2씩 더 낼 수 있게 만든다면, 팀이 5명일 때 총 아웃풋은 10이 아니라 20이 된다. 그런 사람이 실제로 있었다. 우리 팀에서 같이 일했던 시니어 한 분인데, 이 분이 들어오고 나서 팀 전체의 분위기가 바뀌었다. 코드 리뷰가 배움의 시간이 됐고, 스탠드업이 형식적인 보고가 아니라 실질적인 소통이 됐다. 기술적으로 엄청 뛰어난 것도 맞지만, 그것만으로는 설명이 안 되는 영향력이 있었다.

그래서 지금의 나는 "좋은 개발자 = 같이 일하고 싶은 사람"이라고 생각한다.

근데 이것도 정답인지 모르겠다#

여기까지 쓰고 나니까 뭔가 깔끔하게 정리된 것 같은데, 솔직하게 말하면 이것도 확신은 없다.

왜냐면 내가 아는 또 다른 개발자가 있다. 커뮤니케이션? 잘 안 한다. 슬랙 메시지도 잘 안 읽고, 미팅에서 말도 거의 안 하고, 문서화 같은 건 관심이 없다. 팀 이벤트에도 잘 안 나온다. 내가 방금 쓴 "같이 일하고 싶은 사람"의 기준으로 보면 솔직히 좀 부족한 사람이다.

그런데 이 사람이 짜는 코드는 정말 미쳤다.

복잡한 상태 관리 로직을 이 사람이 설계하면 버그가 거의 안 나온다. 남들이 일주일 걸릴 작업을 이틀 만에 끝내는데, 코드 퀄리티가 떨어지는 것도 아니다. 오히려 그 사람 코드가 팀에서 제일 읽기 쉽다. 말은 안 하는데 코드로 다 설명이 된다. 가끔 이 사람 PR을 읽으면서 "아 이런 방법이 있었구나" 하고 배울 때가 있다.

이 사람은 좋은 개발자가 아닌가? 당연히 좋은 개발자다. 엄청나게 좋은 개발자다.

그래서 결국 "좋은 개발자"의 정의가 하나일 수 없다는 결론에 도달하게 된다. 팀을 움직이는 사람도 좋은 개발자고, 혼자 조용히 미친 퀄리티의 결과물을 내는 사람도 좋은 개발자다. 커뮤니케이션의 달인도 좋은 개발자이고, 코드로만 말하는 장인도 좋은 개발자다. 주니어의 눈높이에서 친절하게 설명해주는 사람도, 기술적 난제를 홀로 뚫어내는 사람도.

결국 맥락에 따라 다른 거다. 팀 구성에 따라, 프로젝트 성격에 따라, 회사 문화에 따라 필요한 "좋은 개발자"의 모습이 다르다.

더 유용한 질문#

이런 생각을 한동안 하다 보니까 어느 순간 깨달은 게 있다. "좋은 개발자란 무엇인가"는 사실 좀 함정 같은 질문이라는 것. 답이 계속 바뀌기 때문이다. 경험이 쌓이면 기준이 바뀌고, 환경이 바뀌면 또 기준이 바뀐다. 정의를 내려봤자 6개월 뒤에 또 바뀔 거다.

차라리 "나는 어떤 개발자가 되고 싶은가"가 더 유용한 질문인 것 같다.

이건 정답이 없어도 괜찮은 질문이다. "좋은 개발자"는 객관적인 기준이 있을 것 같은 뉘앙스가 있어서, 그 기준에 내가 못 미치면 불안해진다. 근데 "되고 싶은 개발자"는 순전히 나의 방향에 대한 질문이다. 남이 뭐라 하든 내가 가고 싶은 쪽으로 가면 되는 거다.

나는 뭘까. 아직 잘 모르겠다. 비즈니스 임팩트를 중시하는 건 확실하다. 기술 그 자체보다 기술이 만들어내는 결과에 관심이 많은 것도 맞다. 팀에 좋은 영향을 주고 싶다는 것도 진심이다. 그런데 동시에 혼자 깊이 파고드는 시간도 좋아한다. 새벽에 조용한 방에서 복잡한 문제를 한 줄 한 줄 풀어나갈 때의 그 몰입감. 그것도 내가 개발을 하는 이유 중 하나다.

깔끔하게 한 문장으로 정리가 안 된다. 1년 차 때는 됐었는데, 지금은 안 된다. 근데 그게 나쁜 건지도 모르겠다. 오히려 명확하게 정리되는 순간이 더 위험한 게 아닌가 싶기도 하다. 정의가 확정된다는 건 더 이상 고민을 안 한다는 뜻일 수도 있으니까.

면접에서 그 질문을 다시 받으면 뭐라고 답할까. 아마 또 그럴듯한 답변을 할 것이다. 면접이니까. 그런데 건물 밖을 나와서는 또 같은 생각을 하겠지. "나 진짜 그렇게 생각하나?" 하고. 어쩌면 그 의문 자체가 답을 찾아가는 과정인지도 모른다. 아직은 잘 모르겠다.