개발자 레이첼에게 무엇이든 물어보세요 E.005
저는 평소에 개발, 프로덕트, 여성 3가지 키워드로 대화를 자주해요. 대화를 통해서 많은 깨달음도 얻고 지인들의 이야기를 공유하면서 또 깨달음을 얻고 그랬어요. 문득, 누구에게 고민을 털어놓거나 질문해야할지 모르는 사람들도 많지 않을까? 다른 분들에게도 이야기를 들으면 또 몰랐던 깨달음을 얻게 되지 않을까? 라는 생각을 했어요. 화려하고 거창하지는 않지만 어떤 고민이든 어떤 질문이든 편하게 남겨주시면 진지하게 고민하고 좋은 형태로 답을 드릴게요. 제 이야기가 답이 아닐 수 있지만 답을 찾아가는 과정도 의미있을 것 같아요. 공유는 환영입니다!
수많은 고민과 질문이 저에게 도착했습니다. 뉴스레터 형태로 고민에 대한 저의 생각을 공유하고 있고요. 그렇게 공유한 저의 생각을 이곳에도 기록으로 남겨둘까 합니다.
✏️ 오늘의 질문: 개발/공부
저는 주니어 백엔드 개발자입니다. 시니어 개발자가 되기 위해서는 어떤 능력을 갖춰야 할까요? 조언 부탁드립니다.
⭐️ 레이첼의 생각
요즘 여러 채널에서 논의가 많이 이루어지고 있는 ‘시니어 개발자란 무엇인가’에 대해 질문을 남겨주셨네요. 주니어, 미드 주니어 혹은 중니어, 시니어 등 개발자가 보유한 역량 수준을 칭하는 다양한 용어들이 존재하는 요즘이죠. 유사 주제에 대한 글과 토론 쓰레드를 접했을 때 저의 결론은 ‘그런 시니어가 있어?’, ‘그래서 결국 시니어가 뭔데?’ 라는 모호한 감정과 혼재하는 생각이었습니다. 개인적으로는 회사에서 동료들을 대할 때 혹은 채용을 진행할 때 시니어 혹은 주니어라는 용어 사용을 지양하는 편입니다. 편의상 이 용어들을 사용해야 할 때가 있지만 ‘상대적으로 경험이 많은’ 혹은 ‘상대적으로 경험이 적은’ 이라는 수식어를 주로 사용합니다. 이유는, 저도 명확하게 정의를 내리지 못한 상태이고 또 그럼 나는 어디에 속하는 사람인가에 대한 답도 뚜렷하지 않기 때문이죠.
그래서 오늘의 질문은 저의 재량으로 ‘개발자가 경험을 쌓아가면서 어떤 역량을 갖춰야 하는가’로 살짝 바꾸어 보겠습니다.
개발자가 경험을 쌓아가면서 어떤 역량을 갖춰야 하는가?
우리는 개발자라는 직업을 선택한 후 선망의 대상 한두 명쯤은 갖기 마련이죠. 마틴 파울러, 켄트 벡과 같이 소프트웨어 엔지니어링 분야에 꾸준히 기여하신 분들 혹은 마크 저커버그처럼 프로그래머 출신 기업가를 마음속에 두고 생각합니다. 나도 뛰어난 개발자가 되어야지. 뛰어난 개발자는 무엇일까요? 특정 기술에 대해 조예가 깊은 사람? 혹은 어떤 기술이든 매우 빠른 속도로 평균 이상을 습득하는 사람? 저는 많은 회사들이 적용하고 있는 기술 역량 레벨에서 그 정의를 내릴 수 있지 않을까 생각합니다. 여러 회사들의 그것을 듣고 접한 결과 다음과 같이 요약할 수 있을 것 같아요.
- 특정 도메인에서 문제가 명확히 주어졌을 때 적절한 기술을 적용하여 이를 해결하는 것
- 특정 도메인에서 문제를 스스로 정의하고 적절한 기술을 적용하여 이를 해결하는 것
- 하나 이상의 도메인에서 문제를 스스로 정의하고 적절한 기술을 적용하여 이를 해결하는 것
결국 우리가 빈번히 이야기하는 문제 해결 능력과 도메인 다양성의 조합으로 이야기할 수 있을 것 같은데요. 여기서 이야기하는 문제 해결 능력은 단순히 ‘문제를 어떻게 해결하냐’에 그치는 것이 아니라고 생각합니다. ‘문제 자체를 정확하게 정의할 수 있는 것’부터 시작이겠죠. ‘기술이 최고야’ 함정에 빠진 많은 분들이 간과하는 것이 바로 이 부분이라고 생각합니다. 실제로 문제를 분명하게 정의하다 보면 그 해결책이 상당한 기술이 아닐 때가 잦기도 하니까요. 그래서 저는 ‘최고의 기술’이 아닌 ‘적절한 기술’로 문제를 해결하는 동료들을 존경합니다. ‘적절한’을 고민하는 사람에게는 기술만이 아닌 사람, 시간, 도메인, 회사의 방향 등 복합적인 요소를 치열하게 고민한 흔적이 남아있거든요.
그래서 제가 하고 싶은 말은, 본인이 작성하고 있는 코드가 혹은 본인이 사용하고 있는 기술이 어떤 문제를 해결하기 위함인지 꾸준히 생각하세요. 그리고 그 꾸준함의 시간이 흐르면, 해결책이라고 적용하고 있는 그것이 정말 ‘적절한가’에 대해 고민하세요. 그다음은 내가 속한 팀, 프로젝트 혹은 프로덕트에서 문제를 찾고 정의하려는 시도를 해가시길 바랍니다.
함께 일했던 동료들의 이야기를 잠시 해볼까 합니다. 두 명의 친구가 생각나는데요. 두 친구 모두 기술적 논의에서는 우열을 가리기 힘들 정도로 예리하게 핵심을 파악하고 결론을 도출하는데 많은 기여를 했습니다. 하지만 팀장인 저와 더 상위 조직장들은 유사한 이유로 두 친구를 다르게 바라봤습니다. 그 차이점은 이렇게 이야기할 수 있겠네요.
적절한 기술에 대한 고민: 앞서 언급한 것처럼 두 친구 모두 기술적인 주제가 주어지면 심도 있는 토론으로 좋은 결과를 도출해내고, 다른 동료들에게도 좋은 영향을 주고는 했습니다. 다만, 친구1은 ‘적절한가’에 대한 고민을 항상 동반했고 친구2는 이 고민에 대한 부분이 살짝 아쉬웠죠. 복합적인 요소들을 고려한 후 지금이 적절한 시기가 아니라는 판단하에 때로는 무언가를 포기하는 쪽은 친구1 뿐이었습니다. 물론 친구1의 역량을 더 높게 생각했고요.
시니어 개발자가 무엇인지 잘 모르겠다로 시작해서 질문을 마음대로 바꾼 뒤 주저리주저리 생각을 작성했지만, 제가 늘 지니고 다니는 제 자기소개 한 줄이 답이 아닐까 감히 생각해봅니다.
‘개발을 도구 삼아 문제를 해결하는 사람’
여기서 핵심은 개발이 아닌, 문제를 (찾고) 해결하는 사람이라고 단언하고 싶습니다.
마무리 하며 (´▽｀)
2021년 3월 8일에 작성
김하나 작가님의 ‘말하기를 말하기’ 책에 다음과 같은 구절이 있습니다.
『본인의 성장과 체력, 루틴에 맞게 집중력을 유지하려면 노하우가 필요하다. 무엇보다도 자신을 잘 아는게 중요한 것 같다. 무조건 할 수 있다고 하기보다는 내가 잘할 수 있는 선을 알아야 한다. 그러기 위해서는 자신을 면밀히 관찰하는 것이 우선이다.』
우리가 지금 하고있는 고민도 마찬가지란 생각이 드네요. 내가 잘할 수 있는 선을 알기 위해 스스로를 면밀히 관찰하는 일이 필요한 것처럼, 내가 무엇을 하고 있고 어떤 길로 성장하고 있는지 알기 위해서는 내가 지금 선택하고 행하고 있는 것들의 이유를 선명히 가져가셔야 합니다.
덧) 마틴 파울러, 켄트 벡을 언급하면서 클린 코드로 유명한 그분은 언급하지 않았습니다. 차별과 배제를 이야기하는 사람 안에서는 그 어떤 것도 빛날 수 없습니다.
