[원문 번역]기술 리더로서의 첫 경험: 번역과 개인적 소회

기술 리더로서의 첫 경험: 번역과 개인적 소회

안녕하세요, 여러분. 오늘은 제가 최근에 읽은 매우 흥미로운 블로그 포스트를 소개하고 싶습니다. 이 글은 한 개발자의 기술 리더로서의 첫 경험을 상세히 다루고 있는데, 저와 비슷한 연차의 개발자로서 언젠가 마주하게 될 도전에 대해 많은 통찰을 얻을 수 있었습니다. 이 글의 주요 내용을 번역하고 제 생각을 덧붙여 여러분과 공유하고자 합니다.

소프트 스킬의 중요성

원문 저자는 자신의 초기 개발자 시절을 회상하며 이렇게 말합니다:

"첫 선발 과정에 참여했을 때, HR 면접, 실무 테스트, 기술 리더와의 면접, 그리고 마지막으로 매니저와의 면접 등 지루할 정도로 많은 단계를 거쳤습니다. 그 당시에는 HR 사람들과의 면접이 불편했습니다. '기술 테스트에서 요구사항을 충족할 수 있다면, 그것만으로도 충분한 능력을 보여주는 것 아닌가?'라고 생각했죠."

 

그러나 기술 리더가 되어 채용 과정에 참여하면서, 코딩 능력 외에도 의사소통 능력, 직무에 대한 관심, 개인의 배경 등이 얼마나 중요한지 깨달았다고 합니다. 특히 이런 부분이 인상적이었습니다:

"후보자들의 기술적 능력에 대해 얼마나 적게 논의했는지 놀랐습니다. 신입 개발자 채용이어서 기술 능력이 덜 발달한 것이 당연했고, 이는 논의의 주요 초점이 아니었습니다."

 

저 역시 이 부분에 크게 공감했습니다. 개발자로 일하면서 점점 더 팀 협업의 중요성을 실감하고 있거든요. 아무리 뛰어난 코드를 작성해도 팀원들과 소통이 원활하지 않으면 프로젝트 성공이 어렵다는 걸 여러 번 경험했습니다.

주니어와 시니어의 경계

원문에서는 '시니어'의 정의에 대해 다양한 의견이 있음을 언급합니다. 저자는 이에 대해 자신의 견해를 이렇게 밝힙니다:

"시니어가 된다는 것은 단순히 기술적 지식만을 의미하지 않습니다. 진정한 시니어, 또는 적어도 훌륭한 시니어는 코드와 시스템 아키텍처 모두에서 복잡한 문제를 해결할 수 있는 사람입니다. 코드 품질 유지, 좋은 개발 관행 준수, 프로젝트 관리 지식은 모두 중요한 측면입니다."

"핵심적인 차이는 시니어가 이 모든 것을 자율적으로 실행할 수 있어야 하며, 더 중요하게는 다양한 수준과 부서의 팀과 협력하여 최상의 프로젝트를 제공할 수 있어야 한다는 것입니다."

 

이 부분을 읽으며 제 자신을 돌아보게 되었습니다. 기술적으로 성장하는 것도 중요하지만, 앞으로는 팀 내에서 어떻게 더 효과적으로 협업하고 문제를 해결할 수 있을지에 대해서도 고민해야겠다는 생각이 들었습니다.

프로젝트 리딩 경험

저자는 첫 프로젝트 리딩 경험을 상세히 설명합니다:

"첫 프로젝트를 맡았을 때, 상사는 제가 이전에 프로젝트를 이끈 경험이 없다는 것을 알고 있었습니다. 그가 첫 번째로 물어본 질문은 '프로젝트 완성에 필요한 인원과 어떤 종류의 인력이 필요할 것인가?'였습니다."

 

이어서 저자는 프로젝트 관리 방법론 연구, 개발 플랫폼 선택, 스택 결정, 시스템 아키텍처 설계, 시장의 다른 솔루션 연구, 각 개발자의 수준 모니터링, 그리고 끊임없는 관리 회의 등 다양한 책임에 대해 이야기합니다.

아직 저는 이런 큰 책임을 맡아본 적이 없지만, 언젠가 이런 역할을 맡게 될 것을 생각하면 설렘과 동시에 부담감도 느껴집니다. 지금부터 조금씩 리더십 스킬을 개발해 나가야겠다는 생각이 듭니다.

코드에서 멀어지는 과정

저자는 리더 역할을 맡으면서 변화를 경험했다고 합니다:

"어느새 저는 코드에서 점점 더 멀어지고 있었습니다. 제 역할은 개선사항을 제안하고 프로젝트가 작동하거나 적어도 개발자들이 시작할 수 있는 견고한 기반을 제공하기 위해 중요한 버그를 수정하는 것이 되었습니다."

"나머지 작업은 개발자들과 소통하고, 작업을 분배하고, 지표를 모니터링하는 것이었습니다. 기본적으로 한쪽 눈은 Asana-협업툴(프로젝트 납품 시간을 추정하기 위해)에, 다른 쪽 눈은 Meet에 두고 마이크가 켜져 있지 않은지, 원치 않는 것이 '우연히' 새어나가지 않는지 확인하는 것이었습니다."

 

이 부분은 제게 새로운 관점을 제시해 주었습니다. 지금까지는 '더 뛰어난 개발자가 되는 것'에만 초점을 맞추었는데, 앞으로의 커리어에서는 기술적 역량과 함께 관리 능력도 균형있게 발전시켜야 할 것 같습니다.

원문 전체 번역

결론을 내리기 전에, 제가 읽고 감명받은 원문 블로그의 전체 내용을 한국어로 번역하여 공유하고자 합니다. 이를 통해 여러분도 원문의 풍부한 내용을 더 자세히 살펴볼 수 있을 것입니다.

---

안녕하세요, 여러분! 한동안 글쓰기를 쉬었다가 다시 돌아왔습니다. 이제 다시 글쓰기의 흐름을 타보려고 합니다. 이 공간에서 공유되는 경험들은 제 학문적, 직업적 경험을 바탕으로 한다는 점을 강조하고 싶습니다. 따라서 여기서 설명되는 내용은 현실의 일부만을 반영할 수 있으며, 특정 프로세스나 절차, 서비스에 대한 결정적인 공식으로 해석되어서는 안 됩니다.

저는 현재 제 경력의 새로운 단계에 대해 매우 흥분되어 있습니다. 많은 것을 배웠고, 이 여정의 일부를 커뮤니티와 공유하고 싶습니다. 여기서 제시되는 정보가 독자 여러분께 큰 가치가 있기를 바랍니다.

사람이 먼저 - 소프트 스킬의 중요성

몇 년 전 첫 선발 과정에 참여했을 때를 선명히 기억합니다. 지루할 정도로 많은 단계를 거쳤죠: HR 면접, 실무 테스트, 기술 리더와의 면접, 그리고 마지막으로 매니저와의 면접. 개발자로서의 경력 동안 다양한 모델의 여러 면접에 참여했습니다. 그 당시에는 HR 사람들과의 면접이 불편했습니다. 왜 그런지 정확히 이해하지 못했고, "기술 테스트에서 요구사항을 충족할 수 있다면, 그것만으로도 충분한 능력을 보여주는 것 아닌가?"라고 생각했습니다.

기술 개발 리더로서의 역할을 맡았을 때, 제 책임 중 하나는 HR과 협력하여 기술 테스트를 준비하고 백엔드 분야에서 시작하는 두 후보자의 면접 형식을 정의하는 것이었습니다. 백엔드 분야의 초보 개발자가 무엇을 제공해야 하는지, 그리고 테스트에서 무엇이 차별화 요소로 간주될지 이미 알고 있다고 생각했습니다. 그러나 예상하지 못했던 것은, 코드의 중요성에도 불구하고, 프로젝트 제출 외에도 다른 요구사항들이 생겼다는 것입니다: 후보자들의 의사소통 능력을 어떻게 평가할 것인가? 그들의 직무에 대한 관심은 어떠한가? 그리고 그들이 제시하는 맥락이 제안된 직무에 대한 적합성에 어떤 영향을 미칠 수 있는가? 이런 질문들과 다른 질문들이 두 후보자가 제출한 코드만큼이나 중요한 것으로 드러났습니다. 이는 제가 개발자로서의 초기 시절에는 고려하지 않았던 것입니다.

최종 결정을 위해 회의 테이블에 앉았을 때, 각 후보자의 기술적 능력에 대해 얼마나 적게 논의했는지 놀랐던 기억이 납니다. 이는 부분적으로 신입 후보자들이었기 때문에, 그들의 기술적 능력이 덜 발달한 것이 당연했고 이는 논의의 주요 초점이 아니었습니다.

그러나 더 고급 직위, 특히 시니어 레벨 직위의 경우에도, 의사소통, 문서화, 적응성, 주도성 등 자주 언급되는 다른 기술들을 고려하는 것이 매우 중요합니다. 이러한 소프트 스킬은 기술적 능력 외에도 역할에서의 성공을 위해 근본적이며 결정적일 수 있습니다. 사실, 이것이 제가 다음으로 언급하고 싶은 점입니다.

주니어와 시니어 사이의 경계 (아니, 중급이 아닙니다)

경험 수준과 관련된 용어의 의미와 분류에 대해 많은 논의가 있다는 것을 알고 있습니다. 특히 "시니어"라는 용어에 대해서요. 어떤 이들은 "시니어는 경험 연수로 정의된다"고 말하고, 다른 이들은 "어떤 회사에서는 1년 후에 시니어 경험을 얻는다"고 주장합니다. "주니어와 시니어 사이에 명확한 구분이 없다"거나 "시니어는 단지 코드 리뷰만 하고 PR을 승인한다"고 말하는 사람들도 있습니다. 이 진술들 중 일부는 우스꽝스럽고, 다른 것들은 일말의 진실을 담고 있습니다. 사실, "시니어"의 개념은 매우 다양하며, 저는 보편적인 기준을 정의할 위치에 있지 않습니다. 하지만 이 분류를 더 개별적으로 이해하는 데 도움이 될 수 있는 몇 가지 지침을 제시할 수 있습니다.

시니어가 된다는 것은 단순히 기술적 지식만을 의미하지 않습니다. 물론 이는 의심할 여지 없이 매우 중요합니다. 진정한 시니어, 또는 적어도 훌륭한 시니어는 코드와 시스템 아키텍처 모두에서 복잡한 문제를 해결할 수 있는 사람입니다. 코드 품질 유지, 좋은 개발 관행 준수, 프로젝트 관리 지식은 모두 중요한 측면입니다.

핵심적인 차이는 시니어가 이 모든 것을 자율적으로 실행할 수 있어야 하며, 더 중요하게는 다양한 수준과 부서의 팀과 협력하여 최상의 프로젝트를 제공할 수 있어야 한다는 것입니다. 게다가, 진정한 시니어(또는 적어도 최고의 시니어들)는 팀을 이끌고 안내할 뿐만 아니라, 다른 개발자들이 새로운 직위와 책임을 맡을 수 있도록 개발하고 준비시킵니다.

프로젝트 리딩에 대한 나의 첫 경험

첫 프로젝트를 맡았을 때, 상사는 제가 이전에 프로젝트를 이끈 경험이 없다는 것을 알고 있었습니다. 그가 첫 번째로 물어본 질문은 "프로젝트 완성에 필요한 인원과 어떤 종류의 인력이 필요할 것인가?"였습니다. 저는 즉시 답을 알지 못했습니다. 매우 복잡한 질문이었죠. 프로젝트는 아직 개요 단계에 있었고, 우리는 스택, 각 작업을 완료하는 데 걸리는 시간, 그리고 경영진이 관심을 가질 만한 다른 지표에 대해 전혀 알지 못했습니다. 다음날 제출하기 위해 여러 프로젝트 관리 방법론에 대한 완전한 연구를 수행했습니다: PERT, Planning Poker 등. 우리는 협력하여 가장 적합한 것을 선택했고, 도전이 시작되었습니다.

팀의 각 구성원을 위한 최상의 개발 플랫폼, 사용할 최상의 스택, 시스템 아키텍처의 작동 방식, 시장의 다른 솔루션 연구, 각 개발자의 수준 모니터링, 그리고 경영진과의 끊임없는 회의, 회의, 또 회의가 이어졌습니다.

어느새 저는 코드에서 점점 더 멀어지고 있었습니다. 제 역할은 개선사항을 제안하고 프로젝트가 작동하거나 적어도 개발자들이 시작할 수 있는 견고한 기반을 제공하기 위해 중요한 버그를 수정하는 것이 되었습니다. 나머지 작업은 개발자들과 소통하고, 작업을 분배하고, 지표를 모니터링하는 것이었습니다. 기본적으로 한쪽 눈은 Asana(프로젝트 납품 시간을 추정하기 위해)에, 다른 쪽 눈은 Meet에 두고 마이크가 켜져 있지 않은지, 원치 않는 것이 '우연히' 새어나가지 않는지 확인하는 것이었습니다.

결론과 과거에 대한 회고 - 스승에 대한 애정을 담아

저는 개발 인턴으로 경력을 시작했고, 흥미롭게도 - 여러분은 조금 모순적이라고 생각할 수도 있겠지만 - 저를 주니어, 풀 또는 시니어 개발자로 분류할 수 있는 구체적인 경험(적어도 공식적으로 제 고용 기록에 기록된)이 없었습니다. 제가 얻은 경험의 대부분은 개인 프로젝트와 대학에서의 연구에서 왔습니다. 그 초기 시절 이후로 제 기술이 발전했다는 것을 깨달을 때까지 점진적인 과정이었습니다.

하지만 네, 저는 다양한 수준에서 개발자로 집중적으로 일했고 경력 전반에 걸쳐 다양한 유형의 시니어 전문가들을 만날 기회가 있었습니다:

1. 매우 유능하고 효율적이지만 의사소통이 부족한 시니어로, 자신의 접근 방식에 대한 설명 없이 문제를 해결했습니다.
2. 의사소통과 교육에 뛰어난 시니어지만, 종종 긴급한 업무로 인해 가르칠 시간이 부족했습니다.
3. 과도한 엔지니어링과 기술 중앙화에 열정적이었지만, 마감일을 지키고 약속을 이행한 시니어.

가장 중요한 것은, 그들의 정당화할 수 있는 결점에도 불구하고(완벽한 균형을 이루는 것은 가능하지만 매우 어렵습니다), 이 모든 전문가들이 가치 있는 것을 가르쳐줄 수 있었다는 것입니다. 이러한 경험들은 제 경력을 형성하는 데 도움이 되었고 시스템 개발에서 무엇이 효과가 있고 무엇이 없는지에 대한 명확한 시각을 제공했습니다.

---

결론

저자는 자신의 경력을 돌아보며 다양한 유형의 시니어 개발자들을 만났다고 합니다. 저자는 이 모든 경험이 자신의 경력을 형성하는 데 도움이 되었다고 말합니다.

이 글을 통해 기술 리더의 역할과 책임에 대해 새롭게 이해하게 되었습니다. 앞으로의 커리어에서 이러한 인사이트를 어떻게 적용할 수 있을지 더 깊이 고민해 보려고 합니다.

---

원문 링크: https://dev.to/sampseiol1/my-first-experience-as-a-tech-lead-5g28

My first experience as a Tech Lead