개발자의 성장에 관하여
좋은 개발자는 어려워.
이번 금요일에 회사의 시니어 개발자가 멘토님을 한분 섭외해서 성장 세미나를 열어주셨는데 그때 들었던 말들을 곱씹어봅니다. 당연히 모든 게 정답이라고는 생각하지 않고 몇몇 이야기들은 알고 있었지만, 한번 다시 정리할 수 있었고 좋은 말들을 많이 들어서 감사한 시간이었어요.
세미나의 연사로 오신 분은 꽤나 유명하신 분이었는데, 개발 커리어도 탄탄하고 주니어 개발자나 대학생 멘토로서도 오래 활동하셔서 그런지 참석했던 주니어 개발자들의 고민을 잘 알고 있었고 질문에도 막힘없이 대답해 주셨던 것 같았습니다.
개발자를 보는 기준
결론부터 말하면 성장 가능성과 커뮤니케이션. 두 가지만 보신다고 했습니다. 이게 이렇게 명쾌하게 나온다는 게 조금 의심스럽긴 했어요. 천편일률적으로 적용할 수 있을만한, 답지가 있는 문제는 아니니까요.
공감되었던 내용은 일 잘하는 사람에 대한 기준이었습니다. 그건 바로 어떻게든 일이 되게 하는 사람이다. 저 사람하고 같이 일하면 일이 술술 풀려요라는 말이 나온다면 그게 일 잘하고, 같이 일하고 싶은 사람이라고요. 커뮤니케이션 능력이라는 게 말만 이쁘게 잘하는 게 아니에요. 핵심을 잘 파악해서 빠르게 문제를 해결할 수 있고, 교착에 빠진 대화를 효율적으로 해소해 내고, 의사결정에서 개발자로서 줄 수 있는 최대의 정보를 줘서 최적의 선택을 할 수 있도록 돕는 사람이죠.
계속 성장할 수 있는 사람에 대해서는 안타깝게도 잘 기억나지 않아요. 정체하지 않을 것 같은 사람, 계속 기여할 수 있는 사람 정도였던 것 같아요. 면접에서 기술 질문 해서 떨어뜨려봤자 사실 빠르게 성장할 수 있는 사람일 수도 있고, 뽑을 땐 실력 좋아 보였는데 들어와서는 회사 코드도 잘 모르고, 기술도 써본 것만 다루는 사람일 지도 모르니까요. 그런 관점이었던 것 같습니다.
기술블로그 써라.
정확히 말하면 회사의 기술블로그입니다. 개인 기술블로그는 파급효과가 크지 않지만, 회사의 기술블로그는 그것보다는 큽니다. 또한 회사의 기술블로그는 내가 관리하지 않아도 회사가 관리해 주고 내가 퇴사해도 남아있습니다. 그리고 회사에 남기는 내 업적처럼 가지고 갈 수도 있어요.
또한 기술 블로그는 내가 회사에서 해결했던 문제에 관해 쓰는 게 좋다고 하셨습니다. 이 부분도 공감되었던 내용이에요. 많은 이력서들에서 봤던 기술블로그들에서는 공부한 내용을 정리하거나 새로 알게 된 사실 등을 적는데, 실제로 기술 블로그는 겪었던 문제를 되짚으며 기록하는 회고의 성격에 가깝다고 생각하기 때문이에요.
공감능력
개발자의 필수 역량 중 하나로 공감능력을 꼽으셨어요. 처음엔 당연히 같이 일하는 사람들의 말을 잘 들어주고 상대방 기분을 잘 살피는 등의 능력을 말하는 줄 알았는데 전혀 달랐습니다.
우리는 고객에 공감해야 합니다. 예시로 배민에 근무하던 시절 이야기를 해주셨는데요, 배민에서의 우리의 고객은 배고픈 사람들이고 이 배고픈 사람들이 어떤 상황에서 우리 서비스를 떠나는지에 대해 공감하지 않으면 좋은 서비스를 만들 수 없다고 했습니다. 또한 사장님들의 상황도 공감해야 했습니다. 리뷰에 얼마나 일희일비하는지, 주문부터 배달까지 하나하나 체크하는데 얼마나 바쁜지 등등이요.
저희같이 B2C 스타트업에서 일하는 개발자들에게는 더더욱 좋을 것이라고 말하셨어요. 만약 SI나 설루션 업체였다면 이런 생각을 할 기회조차도 없었을 테니까요.
내 성과를 알아내라
내가 한 개발이 회사에 어떤 이득을 가져왔는지 명확히 알아내라. PO를 괴롭히든 DA를 괴롭히든, 매출로 이어졌든 사용자를 불러 모았든, 불만접수 건수를 줄였든 어떤 걸 자동화해서 일을 편하게 했든 개발자가 알 수 없는 정보면 직접 찾아가서 내 성과를 두 눈으로, 두 귀로 확인해야 합니다.
연사님이 실제 일할 때 클라이언트를 찾아가서도 말해보고 데이터를 다루시는 분을 찾아가서도 여쭤봤다고 했어요. 개발자가 궁극적으로는 엔지니어다 보니까 자신이 다룬 기술로 만들어낸 결과를 사업의 측면이나 고객 관리의 측면에서는 어떤 효과를 가져오는지 잘 모를 수 있으니까요.
내 기술스택이 의심될 때
가고 싶은 회사의 채용공고를 10장만 모아놓고 그중 기술스택, 우대사항을 조사해 보는 것입니다. 기술스택이 겹칠수록 시장의 트렌드라는 뜻이며, 우대사항에 있는 내용은 그 회사에 가서 기술적으로 리드할 수 있음을 의미합니다.
사실 기술스택은 큰 의미 없다고들 하는데, 이건 취준생이나 주니어 개발자들에게는 적용하기 힘들다고 생각해요. 가뜩이나 바다 같은 기본기는 다 공부할 수도 없는데, 특정 기술마저도 추구하지 말라고 하면 불안해서 이직 못할 거예요. 저도 이제야 기본기를 좀 다지고 있는 상태라 어떤 기술이든 가서 배우면 금방 한다는 마인드가 생겼는데, 1~2년 전의 저라면 아마 절대 못했을 거예요.
회고를 해라
이건 연사님 개인 습관인데, 매일 회고를 하신다고 하셨어요. 스스로를 돌아봐야 한다고요. 저는 올해부터 주간 회고를 하고 있는데 회고는 확실히 좋은 습관인 것 같아요. 마일스톤은 자주 체크하지 않으면 가까이 가기 힘들거든요.
회고의 중요성을 말씀해 주시면서 오랜 이야기 하나 이야기해 주셨는데, 어떤 사람이 어떤 목적지까지 가야 해서 택시를 타고 그곳까지 시간이 걸리냐고 물어봤다고 해요. 2시간이 걸린다길래 2시간 동안 자고 일어나니까 반대 방향으로 2시간을 간 상태였다는 거예요. 결과적으로 그 사람은 중간중간 체크하지 않아서 반대방향으로 2시간을 더 가버렸고, 목적지에서는 2배나 더 멀어지게 된 것이죠.
고민의 주체
이건 제가 따로 드린 질문이에요. 내가 개발자로서는 성장한다고 느껴지는데, 주변 환경이 너무 힘들다면 어떻게 해야 하냐고요. 제가 고민했던 문제는 정말 다양했어요. 넓은 범주에서의 의사결정, 인재밀도 관리, 팀의 방향성, 업무방식 같은 부분을 정하고 싶었거든요. 원래 하던 대로 리더들과 이야기를 나눠봤지만 별로 달라지는 게 없었어요. 조금 느긋하게 대처하셨다고나 할까요. 결과적으로 해결되지 않았고, 저는 답답한 채로 다니고 있는 상황이었습니다.
이에 대해 답변해 주신 건 회사가 고민해야 할 일과 개인이 고민해야 할 일을 구분해라였습니다. 회사나 C레벨이 고민해야 할 사안을 조직원으로서 개인이 고민하고 있거나, 그 반대의 경우는 잘못돼도 단단히 잘못된 상태라고요. 얼른 바꿔야 한다고 하셨습니다.
저도 은연중에 이걸 내가 왜 고민하고 있지 하면서 자괴감에 든 적이 하루이틀이 아닌데, 뭔가 정리해 준 느낌이었습니다.
강의를 하나 찍어봐라.
이유는 기억이 안 나는데, 인프런에 유료 강의 하나 올려보라고 하셨어요. 들었던 내용 중에 이건 실천해야겠다 생각했던 내용이라 2월이 끝나기 전에 강의를 준비하고, 늦어도 3월 안에 동영상으로 만들어서 올릴 거예요.
강의 찍어보라는 말씀이 실력향상을 목적으로 말씀하신 건 아니었던 걸로 기억하는데, 실력 향상을 위해서라도 하나 찍어보면 좋겠다 싶어요. 학생 때 선생님한테 들었던 내용 중에 기억에 남는 게, 학습에 가장 효과적인 방법 중 하나가 티칭이라는 것이었거든요. 가르치려면 그 내용을 빠삭하게 다 알고 있어야 한다고요. 조금이라도 모르면 물 흐르듯 강의를 진행할 수 없다고 하셨습니다. 실제로 해보니까 그렇더라고요. 과외를 할 때나 스키강사로 일할 때, 뭔가를 알려주려면 정말 잘 알아야 한다는 사실을 배웠거든요.
마치며
서두에서 말했듯이 이 분 말이 전부 정답이라고는 생각 안 합니다. 하지만 많은 부분이 명쾌하게 답변으로 나오는 것을 보고 나 스스로도 정리되는 기분도 들고 동기부여도 있었기 때문에 어느 정도는 한번 바뀌어보려고 합니다.
Copyright HOJUN IN. All rights reserved.
