회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
앞으로 30년 혹은 그 이상을 개발자로 살고 싶은 분들께 조금이나마 도움이 되었으면 하는 마음으로 제 경험을 3회차의 연재 글로 풀어볼 겁니다. 지난 1편에 이어 두 번째 글입니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
앞으로 30년 혹은 그 이상을 개발자로 살고 싶은 분들께 조금이나마 도움이 되었으면 하는 마음으로 제 경험을 3회차의 연재 글로 풀어볼 겁니다. 지난 1편에 이어 두 번째 글입니다.
80억 인구가 80억 가지 인생을 살게 되므로 제 이야기가 여러분께, 혹은 지금 시기에 딱 맞지 않을 수도 있습니다. 그럼에도 가능하면 시간이 지나도 살아있는 콘텐츠가 될 수 있도록 핵심에 집중했습니다. 개발자 여러분께 도움이 되길 희망합니다.
30년 커리어패스의 두 번째 10년에 필요한 매지니먼트 역량은 총 3가지입니다.
매니지먼트는 프로젝트 관리, 팀 관리, 프로세스 관리로 구분할 수 있습니다. 첫 번째 프로젝트 관리는 출시 시기와 중점을 둬야 하는 일을 관리하는 기술입니다. 두 번째는 팀 관리, 즉 사람 관리입니다. 세 번째로 프로세스 관리입니다. 진행하는 과정을 관리하는 기술입니다.
주니어 개발자로 입사하면 처음에는 주어진 일을 하며, 개발 방법과 개발 주기를 배웁니다. 연차가 높아질수록 프로젝트를 관리하는 방법, 직원을 관리하는 방법, 좋은 프로세스를 설정하는 방법을 고민하며 성장합니다. 이 단계를 거쳐야 좋은 시니어 개발자가 되거나 좋은 개발 팀장이 될 수 있습니다.
프로젝트 관리는 기본적으로 비용(리소스/인력), 시간(출시일), 제품 범위(기능) 세 가지를 관리하는 겁니다.
기업 입장에서는 기능을 모조리 넣으면서, 최대한 출시일을 앞당기고, 인력을 최소한으로 쓰고 싶어 합니다. 결론부터 말씀드리면 불가능한 이 야기입니다. 시간과 인력은 늘 부족합니다. 반대로 만들고 싶은 것은 무한합니다. 그래서 이 사이에서 균형을 잡아서 제품을 출시해야 합니다.
시간은 누구에게나 공평하게 하루 24시간이죠. 게다가 적절한 출시 시점도 무시할 수 없습니다. 돈이 있다고 원하는 사람을 무한정으로 뽑을 수 있는 것도 아니고, 사람은 기계랑 달라서 입사하자마자 본인 자리에 앉아 프로젝트에 기여할 수 있는 것도 아닙니다. 그래서 결국에는 제품의 범위를 줄여야 합니다. 기능을 100%가 아니라 80~90%만 넣어 출시하는 겁니다. 최소기능제품을 출시하고 지속적으로 기민하게 업데이트하는 개발 방법론이 애자일입니다. 이때 핵심 기능을 빠뜨리는 일이 없어야 합니다. 품질과 경쟁력에 영향을 미쳐 자칫 위험에 처할 수도 있습니다.
두 번째로 팀 관리를 살펴보겠습니다. ‘팀을 만든다 → 유지한다 → 제품을 출시한다’ 순서로 큰 그림을 그립니다. 다음 표는 팀이 어떤 방식으로 조직되어 돌아가는지 보여줍니다.
팀을 포밍(forming)하면 스토밍(storming), 즉 폭풍처럼 마구 싸웁니다. 그러고 나면 잔잔해지고(norming) 사람들이 친해집니다. 마지막은 퍼포밍(performing), 즉 일을 잘하게 되는 단계로 진입합니다. 대부분의 팀이 이런 순서로 돌아갑니다. 여기서 핵심은 신뢰와 지식입니다. 무슨 뜻이냐면, 새로 결성된 팀에서 처음 만난 사람들은 당연히 서로를 신뢰하지 않습니다. 그래서 지식도 공유하지 않습니다. 상대방을 믿지도 못하고 상대가 무엇을 하는지도 모릅니다. 이게 첫 단계입니다.
그러다 조금씩 자기가 하고 싶은 말을 합니다. 그러면서 본인의 지식을 전하게 됩니다. 아직은 서로를 신뢰하지는 못하기 때문에, 상대방 말이 기분 나쁘게 들립니다. 그래서 싸움이 생깁니다. 스토밍 단계에 접어드는 거죠. 사람은 참 이상합니다. 싸우다 보면 결국 친해집니다. 정이 드는 것이죠. 친해지면 신뢰가 생겨서 다른 사람의 지식을 믿고 잘 협력하게 됩니다. 비로소 팀이 잘 돌아가게 되는 거죠. 시너지가 발생합니다. 1+1이 2가 아니라 3이 되는 거죠. 프론트엔드 개발자와 백엔드 개발자가 원활히 협업해 일하다가, 그 과정에서 새로운 서비스나 아키텍처를 고안해 낼 수도 있습니다. 함께 일하기 노림수는 시너지에 있다고 해도 과언이 아닙니다. 혼자가 아니라 함께 일하면 더 큰 성과를 만듭니다. 이게 퍼포밍 단계입니다.
팀 관리자라면, 팀원에게 큰 그림을 보여줘야 합니다. 그래야 현재 팀 위치를 파악하고, 자신이 무엇을 어떻게 해야 하는지 생각할 수 있습니다. 저는 새 팀을 만들 때마다 워크숍을 합니다. 워크숍 때마다 남들이 써줬으면 하는 자신의 장점을 말하게 합니다. “나 C#을 정말 잘해. 나에게 물어봐줘” C# 고수가 동료라니 누가 반기지 않겠습니까?
약점도 말하게 합니다. 그런데 약점만 말하라고 하면 싫어합니다. 그래서 본인 약점을 말하되, 자신의 약점을 어떤 방식으로 도와줬으면 좋겠는지 말하게 합니다. “내 약점은 자리에 앉아서 혼자 일하는 걸 좋아하는 거야. 사람들이 말 거는 것을 싫어해. 하지만 중요한 일로 말을 걸고 싶으면 책상을 한두 번 톡톡 쳐줘. 그럼 하던 일을 멈추고 이야기할게.” “나는 일하다 보면 너무 집중해서 옆도 안 보고 앞만 보고 가. 그러니까 그럴 땐 꼭 옆에서 너무 빨리 가는 것 같으니 잠시 멈춰서 살펴보자고 알려줘.” 팀 존재 이유는 서로의 장점을 공유해서 극대화하고 약점을 보완해 주는 것이므로, 서로가 강점과 약점을 알아야 합니다. 특히 약점을 공격하는 데 사용하면 안 됩니다. 약점은 당사자를 보호하고 팀워크를 유지하는 데 사용해야 합니다. 팀 생성 초기에 이 워크숍을 진행하면 빠르게 신뢰 단계(규범기)로 진입해 원활히 지식을 나누게 됩니다.
프로세스란 결국 일을 하는 과정을 정리하는 겁니다. 한 번 했던 일을 다시 할 때 잘하기 위한 장치가 프로세스입니다. 프로세스를 만들면 규격화해 측정할 수 있게 됩니다. 두세 번 반복하면서 최적화할 수 있습니다.
예를 들어 저는 이사를 하거나 직장을 옮기면, 출퇴근 수단과 경로를 정리하고 시도해 봅니다. 그렇게 최적의 경로를 찾으면, 집에서 몇 시에 나서면 언제 도착하는지 예상할 수 있습니다. 프로세스 관리는 실패를 막고, 우연을 막고, 철저하게 품질을 관리하고, 최적화하는 과정을 만드는 겁니다. 개발 방법은 다양합니다. 그러니 프로세스를 만들어두는 것이 매우 중요합니다. 개발 주기, 코드 리뷰 등 개발과 관련된 모든 것이 프로세스에 해당합니다. 프로세스가 잘 정립된 회사는 문제없이 회사를 운영할 수 있을 뿐만 아니라 최적화까지 할 수 있습니다. 프로세스가 정립되어야지만 회사의 현 상태를 측정하고, 고도로 최적화할 수 있습니다.
훌륭한 개발자는 절대 엔지니어링 역량만 가지고는 될 수 없습니다. 매니지먼트 역량이 꼭 필요하고 이 매니지먼트 역량의 바탕은 바로 소프트 스킬(Soft Skill)입니다. 소프트 스킬 중에서도 제일 기본인 다섯 가지 기술을 알아보겠습니다. 첫째 소통(communication)입니다. 소통이 원활하지 않으면 일이 원활하게 돌아가지 못합니다. 둘째 협업 (teamwork)입니다. 혼자서 프로그램을 만들던 시대는 끝났습니다. 일을 주고받으며 함께 일해야 합니다. 소통과 협업은 비슷하면서도 다릅니다.
셋째 긍정적인 자세(positive attitude)입니다. 일을 할 때 사람마다 자세와 마음가짐이 다르게 마련입니다. 일이 될 거라고 믿는 긍정적인 자세와 안 될 거라고 보는 부정적인 자세가 큰 차이를 만듭니다. 넷째 프로 의식(work ethic)입니다. 자신의 일이라고 생각하고, 최선을 다하는 자세입니다. 마지막은 리더십(leadership)입니다. 프로젝트를 리딩하는 능력, 다른 사람을 관리하는 능력, 기술을 결정하는 능력이 여기에 해당합니다.
매니지먼트 역량은 관리자뿐만 아니라 직원에게도 필요합니다. ‘상사가 일을 어떻게 했으면 좋겠다’라는 생각이 있어야 합니다. 그래야 상사에게 요구할 수 있습니다. 예를 들어, 일주일에 한 번은 상사와 면담을 하고 싶어 하는 직원이 있다고 가정해 봅시다. 그런데 상사가 면담을 해주질 않습니다. 그러면 해달라고 요청할 수 있어야 합니다. 추후에 본인이 상사가 되면 직원과 일주일에 한 번씩 면담해야겠죠. 자신에게 주어진 일만 하는 것이 아니라 더 멀리 내다보고 자신이 바라는 관리자 모습을 그려 보고, 관리자가 그렇게 해줄 수 있도록 유도해야 합니다. 그래서 저는 채용 면접 때 “상사에게 무엇을 원하냐?”, “무엇을 원하지 않느냐?”라는 질문을 꼭 합니다. 대답에서 원하는 관리자 모습을 알게 됩니다. 입사 후 어떻게 일하게 될지도 유추할 수 있습니다.
리더라면 특히 소통과 리더십을 갖춰야 합니다. 소통에서는 투명성과 개방성, 리더십에서는 인사이트가 중요합니다. 저는 그동안 투명성, 개방성, 인사이트를 갖춘 리더가 본인과 조직원과 비즈니스와 회사를 성장시키는 일을 적지 않게 봐왔습니다. 그래서 더 자신 있게 꼭 갖춰야 한다고 말할 수 있습니다.
소통에서는 투명성(transparency)이 중요합니다. 투명성은 사람들이 알아야 할 정보를 충분히 공급해 주는 걸 말합니다. 투명성이 보장되려면 업무에 필요한 중요 정보에 모두가 쉽게 접근할 수 있어야 합니다. 서로가 항상 사실을 말해야 합니다. 예를 들어 리더가 투명하게 이야기하면 더 쉽게 의도가 전달됩니다. 그리고 부하 직원은 리더를 예측할 수 있게 됩니다. 리더에게 질문했을 때 답변을 예측할 수 있으면 사사건건 상사에게 물어볼 필요가 없습니다. 상사의 생각을 미리 알기 때문에 ‘아 이거는 이런 식으로 처리하면 되겠구나’라고 생각하는 거죠.
반대로 상사에게 허락을 받아야 할 사안은 확실하게 물어보게 됩니다. 이렇게 투명성과 예측 가능성 이 확보되면 직원에게 자율성이 생깁니다. 아직도 옥죄야 성과가 나온다고 생각하는 분이나 조직이 있는지 모르겠지만, 자율성이 보장될 때 창의성이 발현되고 직원은 행복해지고 결과적으로 더 나은 성과를 도출하게 됩니다. 따라서 상사라면 당연히 예측 가능한 상사가 되어야 합니다.
투명성은 개방성(openness)과 같이 있을 때 더 빛을 발합니다. 항상 모든 정보를 투명하게 공개하는 일은 소통에서 매우 중요합니다. 아울러 리더라면 개방성을 가지고 남의 말을 경청하는 사람이 되어야 합니다. 투명하고 예측 가능하지만 다른 사람의 말을 무시한다면 아무 의미가 없습니다. 즉 투명하게 모든 정보를 공유하고, 개방적인 자세로 다른 사람의 말을 잘 듣는 것. 이 두 가지를 잘하는 것이 소통의 핵심입니다. 투명성과 예측 가능성을 기반으로 한 자율성에 개방성을 더해봅시다. 적극적인 참여를 즐기는 동시에 성과도 내는 팀을 만나게 될 겁니다.
협업은 논쟁 테이블 위에서 벌어지는 관철과 양보의 줄다리기입니다. 좋은 리더라면 협업을 잘 이끌어야 하는데, 그러려면 8할을 양보해야 합니다. 예를 들어 비슷한 역량을 갖춘 A와 B가 한 프로젝트에서 개발을 한다고 가정합시다. 일을 하다 보면 둘 사이 이견이 생길 수 있습니다. 이견이 생길 때마다 항상 A 의견이 관철된다고 해봅시다. 그럼 제대로 된 협업이 아닙니다. 3대 7, 6대 4, 5대 5 정도로 아웅다웅하면서 일하는 게 협업입니다. 한 사람이 항상 이겼다면 그건 욕심에서 비롯된 결과일 겁니다. ‘작은 일에 목숨 걸지 마라’라는 말을 다들 아시죠? 이래도 되고 저래도 되는 일까지 자신의 의견을 관철할 필요는 없습니다. 정말 중요한 일을 관철하지 못하는 일이 발생하지 않도록 하는 게 더 중요합니다.
좋은 리더라면 작은 것을 버리고 큰 것을 얻어야 합니다. 중요하지 않은 일은 원하는 대로 하게 둡시다. 대신 중요한 일에서는 물러서서는 안 됩니다. 설득해야 합니다. 너무 중요하다면 우겨서라도 이겨야 합니다. 중요한 일까지 물러서면 호구입니다. 열에 여덟아홉 사소한 일에서 확실히 물러섭시다. 중요한 한두 건만 확실히 챙깁시다.
아마존 제프 베조스는 경영 회의에서 모두가 ‘좋아요’라는 합의를 보면 불이 나게 화를 냅니다. 충분히 고려하지 않았다고 생각하는 겁니다. 건강한 조직이라면 협업 테이블에서 치열한 논쟁이 오가야 합니다. 그래야 최고의 선택을 할 수 있습니다. 점잖은 샌님 놀이로는 전쟁 같은 개발 세계를 지탱할 수 없습니다. 중요한 일이라면 치열하게 논쟁하고 관철해 냅시다. 그렇지 않으면 양보합시다. 그러면 협업을 제대로 이끌어내는 리더가 될 수 있습니다. 아시겠지만 양보했다고 해서 나 몰라라 하면 안 됩니다. 무관심을 주는 게 아니라 자율 선택권을 주는 양보와 타협이라면 지지하고 지원해줘야 합니다.
리더의 조건으로 리더십을 흔히 말합니다. 리더십은 무얼까요? 리더십이라는 역량은 많은 것을 포괄합니다만 그중에서 하나만 꼽으라면 인사이트입니다. 현재 시장을 파악하고 향후 변화의 큰 물줄기를 분간하는 능력이죠. 탁월한 인사이트를 갖춘 리더라면 큰 물줄기를 발견해 흐름에 올라탑니다. 인사이트가 부족하면 지류로 조직을 내몰아 바다에 닿지 못하고 배를 땅에 처박을 겁니다. 인사이트가 있어야 기술 변화를 내다보고, 개발 방식과 방향을 결정할 수 있습니다. 코끼리 무리에서는 할머니 암컷이 리더를 맡습니다. 초목과 물로 무리를 이끌어야 하므로 경험과 노련함이 중요한 겁니다. 힘은 큰 의미가 없습니다. 리더가 없거나 리더가 초원과 물이 있는 곳으로 안내하지 못하면 코끼리 떼는 근방에 있는 목초를 금세 다 뜯어먹고 나서 아사하게 될 겁니다. 비즈니스에서도 마찬가지입니다. 리더에게 기술, 제품, 시장에 대한 인사이트가 없으면 개발만 하다가 도태될 겁니다.
그럼 인사이트를 어떻게 계발할 수 있을까요? 저는 책과 사람 그리고 크리티컬 싱킹을 제안해 봅니다. 좋은 책을 계속 읽고, 좋은 사람을 계속 만나야 합니다. 이렇게 해서 얻어진 것들을 실제 업무에 적용해 보고, 크리티컬 싱킹을 해서 계속 확장해야 합니다. 투명하게 지속적으로 본인의 인사이트를 전파하고 개방성을 발휘해 다시 좋은 피드백을 듣고 반영해야 합니다. 그래야 혼자만의 생각이 아닌 집단 지성을 이끌어내며 발전할 수 있습니다.
업무 위주의 책만 보는 것이 아니라 인문이나 리더십 서적 등 다양한 주제의 책을 읽어야 하며, 사내와 외부 사람들 모두를 많이 만나보아야 합니다. 일하면서 그리고 책을 읽고 느낀 점을 사람들과 대화를 나누면서 발전시켜야 합니다. 계속 만나던 사람들도 좋지만 매년 새로운 사람들을 만나는 노력을 해야 합니다. 세상은 빠르게 변합니다. 내가 세상보다 빠르게 변하지 않으면 세상이 나를 강제로 변화시킬 겁니다. 내가 세상보다 빠르게 변하려면 인사이트 계발에 많은 노력을 해야 합니다.
관리자는 최상위 관리자와 중간 관리자로 나뉩니다. 최상위 관리자는 회사의 미래, 파트너십, 투자를 책임지고, 중간 관리자는 실무선에서 제품을 개발하고 조직을 관리합니다. 10년 차 20년 차가 되어도 관리자 역할을 하지 않고, 본인의 역량과 능력을 활용해서 회사에 기여하는 일반 직원을 개인 기여자(individual contributor)라고 부릅니다. 100세 코딩을 꿈꾼다면 개인 기여자의 삶을 살면 됩니다. 개인 개발자로 남을지 관리자가 될지는 본인의 선택입니다. 하지만 관리자가 무슨 일을 하는지는 알아야 본인이 관리자로서 재능이 있는지 알 수 있고, 커리어도 결정할 수도 있습니다.
중간 관리자(개발 팀장)는 세 가지 일을 합니다. 첫 번째는 프로젝트 리딩입니다. 프로젝트 관리와 비슷합니다. 제품의 방향을 결정하고 잘 출시하도록 프로젝트를 진행하는 일입니다. 두 번째는 테크니컬 리딩, 기술에 집중합니다. 사용하는 기술이 올바른 기술인지, 해당 기술을 잘 쓰고 있는지, 현 상태로 개발하면 나중에 문제가 생기지는 않을지, 시스템은 확장 가능한지 등 기술과 관련된 문제에 집중합니다. 마지막은 피플 매니징입니다. 직원의 행복과 성장에 집중하는 겁니다. 결국 관리자는 제품, 기술, 사람과 관련된 일을 하는데, 이 세 가지는 성격이 많이 다르다는 것을 기억해주세요.
현실적으로 개발 팀장이 세 가지 영역을 다 잘하기는 쉽지 않습니다. 관리자는 본인이 잘하는 것에 집중하고, 부족한 부분은 도움을 받아 메워야 합니다. 예를 들어 기술이 좀 약하다면, 기술 역량이 높은 직원에게 “기술적인 부분은 당신이 많이 도움을 주면 좋겠어”라고 역할을 부여해 주는 겁니다. 사람 관리에 약한 편이라면, 팀원 중 시니어 한 명에게 부탁해 팀원을 관리하게 하면 됩니다. 개발 팀장이 혼자서 세 가지를 다 할 필요는 없습니다. 다만 각 역할을 명확히 이해하고는 있어야 합니다. 다시 이야기하지만 팀 리딩은 프로젝트 리딩, 테크니컬 리딩, 피플 매니징을 포괄합니다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
좋아요
댓글
공유
공유
29.6K
