[세미나 기록] (우아한테크세미나) 4월 우아한 테크리더 4인의 "공감 토크쇼"

아래는 2023-04-27에 있었던 4월 우아한테크세미나를 (1) 온라인 라이브로 듣고, (2) 이를 다시 들으면서 개인적으로 적은 기록입니다. 요약하면서 원래의 세미나 영상의 내용과 정확히 일치하지 않는 부분이 있을 수 있으니 양해 부탁드립니다. 혹시나 정정해야 할 부분이 있거나 비공개로 해야 할 정보가 있다면 알려주시길 바랍니다.

[우아한테크세미나] 우아한 테크리더 4인의 "공감 토크쇼" - YouTube

 

📌 토크쇼 연사 분들 list

영상에서 진행자 분을 제외한 맨 오른쪽부터 연사분들의 성함을 차례대로 A, B, C, D로 줄여 표기했다.

A: 황준태님(채널연계플랫폼실/서버)

B: 권용근님(회원프로덕트팀/서버)

C: 최희준님(자율주행소프트웨어팀/로보틱스연구개발)

D: 이덕우님(셀러웹프론트개발팀/웹프론트엔드)

 

📌 Q1. 개발보다 어려운 피드백과 1on1

1~2 나만의 팀 리딩 노하우와 동기부여를 하는 방법? 나와 조직 내의 팀원이 성장(성과)과 문화가 올바른 방향으로 가고 있는지 지속적으로 체크 가능한 방법이 있을까요?

A: 한 달에 최소한 1on1 하려고 노력 중. 식사 자리, 티타임, 사무실에서 마주칠 때, 온라인 미팅 등 여러 시간을 활용하여 커뮤니케이션을 하려고 노력한다. 팀원끼리 허물없이 편히 이야기하려는 분위기를 만들려고 노력하고 있다. 1on1 시간에 어떠한 것을 말해야 할지 막막해질 때까지 있는데, 완벽한 리더는 없기에 부담없이 시도를 하면서 시행착오를 겪는게 어떨까.

B: 개인의 성장을 위해 위임을 많이 하려고 노력하고 있다. "큰 나무 밑에서는 (그 밑의) 큰 나무가 자랄 수 없다"는 말에 공감이 많이 된다. 무조건적인 위임은 부작용이 있을 수 있기 때문에 "전문적 권력"을 뒷받침하려고 한다. 전문적 권력이란, 지식이나 역량에 오는 권력을 말하는데 개발 조직에 더 영향력 있는 권한이라 생각한다. 이를 어떻게 사용하면은 업무 분배를 할 때 전문적인 지식을 내가 받쳐주되, 그 구성원은 보다 자유롭게 위임을 받아서 개발을 할 수 있도록 장려하고 있다. 위임을 잘하기 위해서는 1on1을 잘 활용하는 것 같다.

C: 현재 팀에는 다양한 백그라운드에서 오는 사람들이 있기에 여기에서 오는 다양한 애로/건의 사항이 있기 마련이다. 여기에 최대한 공감하려고 노력하고 있고, 애로/건의 사항이 누그러들고 최대한 좋은 영향력을 끼칠 수 있도록 노력하고 있다. 개발자들에게 심리적 안정감을 주려고 노력하고 있다. 저 또한 개발에 대한 위임을 하려고 노력하고 있고, 그럴 때마다 그 일이 얼마나 중요한지 그리고 어떻게 발전해 나가는지 동기부여를 주려고 하고 있다.

D: 리더십 관련 도서나 교육을 받고 있다. 회사가 리더십이나 관련 교육을 적극적으로 지원해서 도움을 많이 받고 있다. 1on1을 통해 팀 구성원과 자유롭게 이야기 하면서 성장에 대한 피드백으로 동기부여를 시키려고 노력하고 있다.

 

3. 팀원 중 팀 문화에 맞지 않고 시니컬하거나 부정적인 경우에는 어떻게 소통하시나요?

A. 어딜가나 시니컬하거나 부정적인 사람은 있는 법. 오히려 리더가 볼 때는 상대적인 개념도 될 수 있다. 팀이 너무 한 방향으로 흘러가면 좋지 않은 결과가 있는 경우가 있었다. 팀 리더가 비판적인 입장에서 서 봄으로써 좀 더 건전하고 발전적인 방향으로 이끄는 것도 좋다. 반면에 시니컬/부정적인 구성원을 방치하면 팀 분위기나 업무의 생산성에 영향을 끼치게 된다. 시니컬/부정적인 구성원이 어떠한 생각으로 행동하는지를 지켜봐야 한다. 또한 나머지 긍정적인 구성원에 대한 케어가 반드시 있어야 한다. 포기하지 말고 시니컬/부정적인 구성원도 이끌어가야 하는 게 리더이기에, 팀원도 하나의 구성원이 될 수 있도록 노력해야 한다.

 

📌 Q2. 내가 만들고 전파하는 개발 문화

1. 내가 만들고 전파하는 개발 문화가 있나요?

C: "파일럿 프로젝트"라는 문화를 잘 전파했다. 주로 새로운 팀원이 합류했을 때 해당 팀의 처음 개발과 배포와 컨벤션 등까지의 전 과정을 짧은 주기로 체험하는 시기이다. 이를 신규 입사자에게 많이 한다. 여기에는 키 포인트가 있는데 분량을 주어진 기간보다 더 타이트하게 함으로써 약간의 좌절을 느끼게끔 한다. 보통 신입이 엄청난 열정을 갖고 입사하는데 일부러 무리를 해서 좌절을 겪을 수 있도록 하고 있다. 일부 좌절은 오히려 더 큰 열정을 불러 일으킬 수 있다. 온보딩이나 기술 블로그에서도 파일럿 프로젝트를 잘 활용하는 것 같다.

A: 처음 입사하고 초기 때 한창 성장하는 시기여서 프로덕트의 불안정한 상황이 자주 있었다. 이 상황 속에서 우리가 가고자 하는 방향을 많이 이야기 했다. 현재 처리한 현황을 신속하게 대처하고, 팀원과 프로덕트가 어떻게 발전해야 하고 시장을 리드해야 하는지 공간을 가리지 않고 여러 번 논의했다. 이러한 과정을 통해 커다란 로드맵을 그릴 수 있었다. 이러한 것들은 팀장이 어떠한 것을 선택해서 이루어지는 게 아니라 "수평적인 커뮤니케이션"과 "팀에서 발생하는 문제는 다 같이 해결해야 한다 책임감" 등을 바탕으로 했다.

 

2. 새로운 기술 도입이 필요할 때 팀원을 어떻게 설득하고 있나요?

D: 가장 중요한 것은 현재 우리가 운영하는 서비스의 상황과 새로운 기술이 적합성이 있는지를 생각한다. 이를 일방적인 주장하지 않고 팀원과의 협의를 통해 새로운 기술을 도입한다. 팀장 뿐만 아니라도 팀원 누구라도 이러한 과정을 거치고 있다.

C: 새로운 문제를 어떻게 정의하고 이를 어떻게 풀어야 할지 reasarch & survey를 하여 좋은 방법을 찾거나 아이디어를 구체화 하려고 한다. 충분한 시간을 통해 토론과 논의를 한다. 이러한 토론 과정이 늘어지는 경우도 있지만 최대한 충분하게 시간을 가지려고 노력한다.

 

📌 Q3. 팀원들의 성장 욕구를 만족시키며 프로덕트 성장시키기

1. 팀원 간의 기술 격차가 큰 상황에서, 조직의 성장 방향과 팀원들의 성장 방향을 잘 맞추고 간극을 해소하는 법은?

C: 다양한 백그라운드에서 오는 기술 격차가 존재하지만, 그러한 상황에서도 경험이나 능력이 많은 사람이 그렇지 않은 사람에게 긍정적인 영향을 끼치고 이게 성장에 어떻게 도움이 되는지, 이것이 조직의 성장으로 이어가는지 최대한 설득하고 있다. 모든 팀원이 성장할 수 있도록 한다.

D: 팀에서 가장 중요한 역량이 "팀워크"라고 생각한다. 개발자는 기술이 전부가 아니라고 생각한다. 어느 팀원이 꼭 기술적으로 역량을 발휘하지 못한다 하더라도 다른 분야의 역량 끌어올릴 수 있도록 이끌고 있다.

 

2. 개발자의 성장 욕구를 만족시키면서 조직의 프로덕트 성장을 함께 이끌어 나가는 방법은?

B: 회사란 곳은 "프로덕트의 성장"을 지향하는 곳이다. 따라서 개발자의 성장과 일치하지 않는 경우도 있다. 회사에서 주어지는 좋은 과제로만 성장하는 개발자는 한계가 있다고 생각한다. 스스로 성장 포인트를 찾아내서 성장하려는 사람을 선호한다. 개개인이 스스로 발견해서 할 수 있어야 한다. "현재를 되돌아 보는 것"과 "성장 포인트를 찾아내는 것"의 자세를 갖도록 독려하고 있다. 속칭 게임의 "오토 모드"를 돌려도 잘 돌아가는 개발자가 되도록 장려한다.

A: 모든 팀원이 동일한 성장 욕구를 갖고 있는 것은 아니다. 팀원의 참여 의지, 성장 욕구 등에 따라 다르다. 여기에는 프로덕트의 성장도 있기에 리더는 성과 또한 내야 한다. 성장 욕구가 높은 사람에게는 보다 난이도 있는 과제를, 반면에 성장 욕구가 낮은 사람은 거기에 걸맞는 과제를 할당하기도 한다. 하지만 개인적으로 리더는 너무 편중하면 안된다고 생각하기에, 성장 욕구가 낮은 사람에게도 나중에는 적절한 자극을 주어야 한다. 결국 팀원이 모두 골고루 성장할 수 있도록 독려해야 한다.

 

📌 Q4. 개발자의 숙명. 끊임없이 학습해야 하는 시니어

1. 새로운 기술이 끊임없이 나오는 상황에서 어떤 걸 공부해야 할지, 얼마나 깊게 공부해야 할지 정하는 노하우가 있나요?

B: 개인적인 생각으로 학습의 첫 번째 중요한 요소는 내가 현재 잘하고 있는 능력을 보다 깊게 잘 할 수 있도록 학습하는 것이다. 두 번째는 미래에 대한 준비를 위한 학습이다. 예시로는 새로운 기술의 도입을 미리 연습하는 것이다. 세 번쨰는 모르는 키워드를 수집하는 것이다. 현업에서 개발을 하면 할수록 보다 큰 그림을 그리는 아키텍쳐를 그릴 수 있어야 하기에 그 큰 그림에 대한 키워드를 알고 있어야 한다. 여담으로 키워드에 대해서, 예전에는 커뮤니티를 통해 키워드를 들었다면, 지금은 오픈채팅방 등에서 얘기를 키워드를 듣고 있으면 "내가 모르는 게 많구나"를 많이 느끼게 된다.

(+) 어떠한 채팅방..?

B: 개xx닥…

2. 개인이 부족하다고 생각하는 부분을 개선하고 연구해 나가는 구체적인 방법이나 노하우가 있나요?

D: 제가 모르는 게 많기 때문에, 모른다고 편히 얘기하는 게 노하우인 것 같다. 주니어 때는 몰라도 아는 척을 하는 경우가 많았지만, 최근에는 모르면 "모른다"라고 말하고 동료에게 적극적으로 질문해서 지식을 학습하고 있다. 이를 통해 보다 빠르고 많이 학습할 수 있고, 팀원도 그 내용을 설명함으로써 서로 성장할 수 있다고 생각한다.

 

📌 Q5. 시니어에게도 이직하고 싶은 순간은 찾아온다!

1. 스트레스 관리 잘 받으시나요? 어떻게 스트레스를 관리하고 있나요?

D: 스트레스를 잘 받는 편은 아니다. 개인적으로 기억력이 안 좋기 때문에 스트레스를 쉽게 잊는 편이다. 이런 식으로 해결하고 있다.

B: 개인적으로는 스트레스를 많이 받지 않는다. 많이 무딘 편이다.

C: 스트레스를 재충전으로 풀려고 노력한다. 여가 시간에 일과에 관련된 일을 하려고 하지 않는다. 전혀 업무와 관련 없는 행동을 하며 충전을 하고 있다.

A: 스트레스를 초반에 많이 받았지만, 시간이 지남에 따라 시스템이 안정화 됨에 따라 스트레스를 덜 받고 있다.

 

2. 언제 이직이 필요하다고 생각하시나요? 이직할 때 어떤 점을 고려하셨나요?

A: (많은 이직은 하지 않았지만) 내 성과/성취를 더 이상 못 느낄 때, 성과를 냈어도 조직에서 나를 필요로하는 구성원이라고 생각하지 않을 때, 새로운 도전을 찾으려고 할 때 이직을 생각한다.

C: 업무적으로 성장할 수 없다고 생각이 들거나, 주변의 동료/매니저가 (나에게) 긍정적인 영향력을 끼치지 못한다고 느끼거나, (내가) 팀원에게 긍정적인 영향력을 끼치지 못한다고 느낄 때 , 개인의 영향력이나 성장이 정체되어 있다고 느낄 때.

 

(+) 실제로 이직을 하기 전에 미리 준비해야 할 것이 있다면?

B: 새로 이직을 한다 해도 (그곳에) 내가 배울 만한 사람이 있을까에 대해 중점을 둘 것 같다.

D: 업무에 따라 개인 차가 있겠지만, "업무를 하면서 이를 재밌어 하는가?"를 중요하게 생각한다. 이에 대한 포인트는 개인적으로 (1) 개발하면서 서비스가 성장하는지? (2) 개발한 서비스가 사용자에게 충분한 가치를 제공하는지? (3) 가치를 제공할 때 내가 주도적으로 일을 진행할 수 있는지?가 있다. 이에 대해 내가 재밌어 하지 않는다면 이직을 생각하는 것 같다.

 

📌 BONUS! 마지막으로 시니어를 준비하고 있는 분들께

1. 나의 주니어 시절은 어땠나요??

A: 욕심이 많은 개발자였다. 밤샘 작업도 많고 집에 갈 생각도 안 들면서 몰두하는 일이 많았다. 주니어 때 deep & special 하지는 못했으나, 그때로 돌아간다면 특정 분야에 대해서 special한 분야를 만들어 놓고 여러 업무 영역으로 나아갈 것 같다.

(+) 주니어와 시니어를 나누는 결정적인 차이? 기준?

A: 시니어가 되면 여러 걱정이 많아지고 이를 인지할 때가 시니어가 된다. 주니어의 성장, 프로덕트에 대한 기여, 안정적인 서비스에 대한 고민 등등…

C: 주니어 시절은 필요한 것을 배우려고 노력했고, 이를 적극적으로 활용하려 노력했고, 주변 사람에게 좋은 영향력을 끼치려고 노력했다. 이러한 여러 시행착오가 나에게 도움이 많이 됐던 것 같다.

 

2. 조직에 고연차 시니어가 없을 때, 어떻게 하면 시행착오를 줄이고 더 안정적이고 빠르게 성장할 수 있을까요?

B: 주니어 시절 고연차 개발자 없이 개발해야 했던 상황. 그때 시행착오를 굉장히 했는데 지금 되돌아 보면 굉장히 넓고 많이 알게 되었다. 지금 되돌아 보면 도움이 되었던 게 많았다. 시행착오가 꼭 안 좋은 것은 아니고, 적당히 있다면 좋다. 엘리트 코스에 비해 이러한 시행착오를 겪는 게 느려 보일 수 있지만, 탄탄히 성장할 수 있는 기회가 될 수 있다.

D: B와는 다르지만, 시니어가 있으면 더 도움이 되지 않을까 생각을 한다. 혼자 내가 가고 있는 방향이 맞는지 흔들릴 때가 많다. 이러한 고민도 상담 받고 조언을 얻으면 좋지 않을까. 회사에 없다면 회사 밖에서도 오픈 커뮤니티 등을 통해 충분히 찾을 수 있다고 생각한다. 저라도 개인적인 능력 선에서 개인적인 연락을 준다면 최대한 답변해 줄 수 있다.

 

📌 실시간 질문

1. 리드 분들이 이끄셨던 스터디가 있을까요? 어떤 방식으로 하나요?

B: 개인적인 노하우는 아니지만, 스터디원을 모집하여 스터디를 했는데 노하우 없이 제가 강의를 오래 하게 되는 강의형 스터디가 되었다. 그래도 그 스터디원이 우리 회사로 입사를 했는데 그때 도움을 많이 받았다는 말을 전했다.

 

2. 시니어로 성장하고 싶은데 회사에서는 팀원 관리 중심의 리더 역할만 맡기려고 한다. 개발자로서 성장하려면 어떻게 회사를 설득해야 할까?

A: 조직 장에게 이러한 고민을 진지하게 이야기 해야 한다고 생각한다. 만약 그렇지 않는 조직이라면 이직할 때가 되었다고 생각한다.

D: "내가 왜 개발자로 남아서 성장하고 싶은지" 고민하는 것이다. 제 경우에는 "내가 성장해서 맡은 서비스를 성장하겠다."라고 생각했는데 관점을 바뀌니 해결이 되었다. 내 성장에는 한계가 있지만 팀원을 성장시키면 더 많은 서비스의 성장을 이끌 수 있다고 생각이 들었다.

 

3. 권용근님이 작성한 기술 블로그가 많은 도움이 되었습니다. 업무를 진행하면서 습득한 정보를 정리한 노하우가 있나요?

B: 딱히 노하우가 없지만, 내가 납득이 가지 않는 아키텍쳐를 고치기 위해 많은 노력을 했다. 작성 기간이 1년 반 동안 다듬어졌기에 특별한 노하우가 없다. 하지만, 이러한 과정을 마지막에는 정리했다는 것에 의미가 있는 것 같다.

 

📌 개인적인 후기

• 다루는 내용이 주니어/시니어 개발자를 대상으로 한 내용이 대부분이었기에, 취직을 준비하고 있는 나의 입장에서는 취직 이후 개발자로서의 전체적인 방향에 대해 생각해 보게 되었다.
• 꼭 지금 현업이 아니더라도 내가 앞으로 팀/사이드 프로젝트를 하면서 팀원들과 문제가 발생하였을 때 팀원 혹은 팀 리더로서 내가 어떻게 주어진 상황을 적절히 대처할 수 있을지 고민해 볼 수 있는 좋은 시간이었다.