[2022 회고록] 2. 커리어에 대하여

올해도 폭풍성장했습니다.

내가 가는 길이 맞는지에 대한 고민은 누구나 하고 있을 것이라 생각합니다. 적어도 현재 어떤 길을 가고 있다면 맞는 방향인지 정도는 알아야겠죠. 하지만 누구나 한 번에 그 사실을 알아차릴 순 없습니다. 계속 평가하고, 수정해서 수렴하는 방법 밖에요.

이번 글에서는 2022년 제 커리어를 위해 했던 활동을 회고합니다.

좋은 개발자

나는 좋은 개발자가 되기 위해서 어떤 노력을 했을까요. 일단 좋은 개발자 는 뭐죠. 나름의 기준은 개개인마다 다르겠지만 저도 저 나름의 기준이 있어요. 이 글에 정리해뒀으니 여기선 짧게 설명할게요. 저는 비즈니스 , 사용자 경험(UX), 개발자 경험(DX)을 언급한 우선순위대로 지키는 개발자를 좋은 개발자라고 평가해요. 일단 비즈니스가 돌아가도록 요구사항을 빠르게 해결할 줄 알아야 하고, 그 와중에 사용자 경험을 해치는 의사결정이나 개발은 지양해야 하며 서비스의 꾸준한 유지보수를 위해 개발자 경험을 한껏 드높일 필요가 있음을 뜻해요.

이게 개인적인 기준이다 보니 저는 스스로 위의 3가지 원칙을 되뇌며 의사결정하고 개발하기 때문에 스스로는 좋은 개발자라고 이야기할 수 있다고 생각해요. 저걸 다 지킬 수 있는 사람을 보는 게 아니라 당장은 그런 생각을 보는 것이니까요. 어차피 우주최강 개발자가 와도 위 세 가지를 완벽하게 지킬 순 없는 노릇 아니겠어요?

사실 위의 기준은 올해 정했어요. 회사에서 아예 좋은 개발자란 무엇인가에 대해 생각할 수 있게 질문을 항상 던져주셨거든요. 물론 목적은 채용 기준 확립이었지만 CTO님이 모두에게 던지고 싶은 이야기였다고 받아들이고 저는 제 기준을 내재화시켰어요. 아주 훌륭한 경험이 되었다고 생각합니다. 올해의 소득 중 손에 꼽을 수 있지 않을까 싶네요.

좋은 동료

좋은 동료 는 좋은 개발자와는 별개입니다. 궁극적으로 우리는 개발자, 디자이너, 기획자 등의 직책과 일하는 게 아니라 동료 1, 동료 2랑 일하는 것이니까요. 그러기 위해선 모두가 좋은 동료가 될 필요가 있습니다. 위의 질문과 마찬가지로, 좋은 동료의 기준도 개인마다 천차만별이에요.

저는 아주아주 식상한, 저도 올해에 와서야 조금씩 의미를 알아가고 있는 두 가지 키워드를 꼽아볼게요. 하나는 존중 , 두 번째는 소통 이에요. 다만 여기서 기본으로 생각하는 점은 각자의 직무에 있어서의 프로다움(전문성) 입니다. 직장에서 돈을 받고 일하는데 해당 직무를 잘 수행하지 못하는 사람은 뭔가 문제가 있다는 뜻으로 받아들여도 무방하다고 생각하기 때문에 당연한 겁니다.

먼저 존중 입니다. 내가 누구와 일을 하든 그는 그의 입장이 있고, 사정이 있습니다. 우리가 앞뒤 가리지 않고 본인의 기술이나 비즈니스에 매몰되어 상대의 상태를 바꾸려고 하면 안돼요. 저는 합리적인 의사결정을 선호하는데요, 우리가 AI와 일하는 게 아닌 이상 항상 합리적인 의사결정은 불가능하고 어느 정도 사람다움과 느슨함이 필요했어요. 상대의 의사결정이나 권한, 권리를 존중 하지만 올바른 의사결정을 할 수 있도록 보조하는 역할, 그게 좋은 동료가 할 수 있는 것 중 하나라고 봤습니다.

두 번째는 소통 이에요. 우리는 비즈니스 문제를 해결하는 사람들입니다. 근데 혼자서 그 많은 걸 해결할 순 없어요. 여러 직군의 사람들과 소통하며 문제를 공유하고 해결할 방법을 찾습니다. 소통을 잘하는 방법은 정말 수도 없이 많겠지만 올해 제가 느낀 건 두 가지예요.

하나는 빠른 피드백 입니다. 우리가 소통을 시작했을 때, 그 한마디가 공허한 외침이 되도록 놔두면 안 됩니다. 그 이슈를 알던 모르던 누군가 피드백을 최대한 빠른 시간 안에 해야 할 수 있는 그다음의 노력을 최단시간 내에 착수할 수 있어요. 그리고 결과적으로 이런 피드백들이 모여서 소통량을 늘려줄 것이고, 소통으로 모든 문제를 해결할 수 있다는 믿음을 조직에 심어줄 수 있다고 생각해요.

두 번째는 말투 입니다. 저는 장교 후보생부터 군생활을 하는 내내 귀에 못이 박히도록 들은 말이 군더더기 없이 표현해라 입니다. 미사여구나 부연설명 없이 신속정확한 정보전달이 중요하다고요. 그리고 이건 꽤 합리적이었기 때문에 저 또한 그렇게 말하는 게 좋을 줄 알았습니다. 하지만 실제 대화를 할 때 앞뒤 맥락 없이 이런 대화를 하다 보니 명령조로 들리거나 누군가의 위에 군림하는 듯한 대화를 하게 되었습니다. 이는 조직문화와도 맞지 않고 제 스스로의 가치관 하고도 다른 결이라서 과감하게 없애보려 해요. 이렇게 되면 다시 조금은 군더더기가 있는 말을 하게 되겠지만 소통에 있어 상대방의 거부감을 없앨 수 있을 것 같아요.

개발 블로그

작년 목표 중 하나가 개발 블로그를 직접 만들고 운영하는 것이었는데 이번달 말에 와서야 만들고 있습니다. 완벽한 실패네요. 맨날 해야지 해야지 말만 하고 안 하다가 결국 내년도 똑같아지겠다 싶어서 부리나케 만들었는데, 그나마 이제 운영은 할 수 있는 모양은 나왔기 때문에 규칙을 정하고 글을 채워나가야겠어요.

기존에 아카이빙 된 글은 많지만 혼자 보려고 적어놓은 글이 대다수라서 당장 게시할 수 없는 상태예요. 세이브 원고가 있지만 없다고 볼 수 있죠. 다만 다행인 점은 회사 개발 블로그에 써놓은 글이 많다는 점이에요. 제가 쓴 글이기 대문에 조금 각색해서 다시 올리거나 백링크를 걸어둘 생각입니다.

스터디

솔직히 작년 여름부터 시작된 스터디가 지금까지 진행될 줄은 몰랐어요. 벌써 1년 반이 지났습니다. 중간에 휴식도 있었고 스터디 종목 변경도 있었고 다들 나름의 권태기도 있었던 같은데 잘 이어져서 지금은 쉴 사람 쉬고 새로 시작할 사람 포함해서 2기로 진행하고 있어요.

성과로는 팀 sundayTen의 첫 번째 프로젝트인 유기동물 찾기 서비스 어게인은 성공적으로 마무리되어 론칭되었고, 지금은 OKR을 개인의 영역에서 활용할 수 있는 Personal OKR 두 번째 프로젝트를 준비 중이에요.

사실 제가 생각했던 속도보다 느린 건 사실입니다. 모두가 처음 시작했을 때보다 바빠진 것 같기도 하고 저 조차도 많은 시간을 할애하기 어려웠으니까요. 하지만 중간중간 재정비하는 시간을 가졌기 때문에 그나마 이어져왔다고 생각해요. 이번에 새로 하는 프로젝트는 사이즈가 꽤 커서 다가오는 일 년을 꽉 채울 것 같네요.

독서모임

구독형 독서모임 인 트레바리는 모임 주최자 직책인 파트너 로 2회 진행했어요. 결론적으로 반은 성공이고 반은 실패 같습니다. 첫 번째로 한 모임은 사람들 지금도 잘 만나고 친하게 지내는데 두 번째 모임은 와해되어버려서 자존감이 많이 상했거든요.

첫 번째 모임은 잘 되었으니까 차치하고 두 번째 모임만 보면, 체험독서라는 콘셉트에 반해 사람들이 원했던 여러 번의 재밌는 모임을 하지 못했던 제 자신을 반성을 하게 되더라고요. 사람들이 기대하고 온 저와 저희 클럽의 모습이 있었을 텐데 제가 그 모습에 부합하지 못했다고 생각해요. 아무래도 더 활동적이고 자주 사람들을 모아서 여러 액티비티를 진행했어야 했는데 그게 저도 아쉬워요. 다음에 또 파트너를 하게 된다면 더 많이 소통하고 만나서 모두가 목적을 이룰 수 있도록 이끌어볼 거예요.

글쓰기

올해 글 꽤 많이 썼습니다. 목표는 주 1회였는데 오늘까지 거의 주 0.7개 정도 쓴 것 같아요. 올해 목표도 동일하게 잡을 건데, 이제 정말 주 1회 정기 발행을 해보려고요.

사실 모든 글이 사랑받진 못했지만 그래도 어제 최초로 하루 조회수 100건을 넘어봤어요. 항상 3 자릿수는 불가능했는데 이제 적당히 몇십 명은 제 글을 보고 있나 봐요. 운 좋아서 어제는 136건이나 달성했고요.

http://t1.daumcdn.net/brunch/service/user/aVyy/image/DJHSLswrcnkA1jKzqt6_I6LwhIc.png이게 불과 어제 일이랍니다~

내년엔 조금 더 박차를 가해볼 거예요. 꾸준하게 내 생각을 전달하고, 당장은 봐주는 이 없지만 언젠가 제 브런치가 디지털 빌딩이 되면 제 의견이 영향력을 가지는 날이 오겠죠?

내가 올해 배운 거

이번 년에 새롭게 배운 잡기술이 몇 개 있습니다. 그냥 같이 일하는 사람들한테 지나가는 대화에서 듣거나 배운 건데 생각해보면 이런 게 정말 디테일하게 일 잘하는 법이라고 생각했어요.

첫 번째로, 질문하는 법 을 배웠습니다. "이런 맥락이 궁금합니다. 그중 제가 진짜 궁금한 건 A입니다"라고요. 질문이라는 게 그냥 순수하게 궁금해서 묻는 게 다는 아니었습니다. 우리가 주니어(근데 저도 주니어네요..?) 부사수 키우면서 듣는 질문들은 그럴 수 있어요. 순수하게 코드를 왜 이렇게 작성한 걸까 궁금할 수 있잖아요. 하지만 질문과 대답 그 자체는 서로의 에너지 소모가 수반 되기 때문에 꽤 효율적으로 활용해야 합니다.

저는 종종 면접 때, 대표님한테 CDN에 대해 설명해보라는 질문 을 하는데요. 이건 상대방 괴롭히기가 아니라 커뮤니케이션 과정에서 자주 나오는 상황이기 때문입니다. 가령 디자이너 A가 프런트엔드 개발자 B와 소통하며 이미지 사이즈에 대한 이야기를 나눴고, 이 사이즈에 대한 의사결정을 그 대화에 참여하지 않은 기획자 C가 내려야 한다면, 우리는 맥락도 모르고 개발 및 디자인 이슈를 모르는 기획자 C에게 휴가 간 디자이너 A를 대신해 내용을 전달해야 합니다. 이런 맥락에서 상대방이 가진 맥락의 수준 을 고려해서 나의 언어를 조절 하고 포함될 내용을 적절히 추상화할 필요 가 있기 때문입니다.

두 번째로는 질문을 받아 답변을 할 때, 상대방이 원하는 답변을 먼저 꺼내는 방법입니다. 상대방이 진짜 궁금한 건 뭔지 서두에 말해주면서 질문해주면 베스트인데, 그렇지 않은 사람이 대부분이에요. 왜냐면 진짜 궁금한 점을 말하는 방법을 모를 수도 있고, 그냥 떠보는 것일 수도 있으니까요. 그럴 땐 진짜 궁금한 게 뭔지 역으로 물어보거나 본질을 파악해서 상대방이 진짜 풀고 싶은 문제에 대한 해답을 주는 것입니다.

세 번째로는 문제를 재정의 하는 것입니다. 제가 사람들에게 재질문을 할 때 가장 많이 하는 말이 그래서 풀고 싶은 문제는 이건가요?라고 물어보는 거예요. 대화를 하다 보면 상대방은 A라는 문제를 풀고 싶은데 자꾸 다른 콘텍스트에 손이 가는 경우가 많거든요. 분명 개발자로서 해당 분야의 전문가라면 그런 맥락을 바로잡고 풀고 싶은 문제가 A면 A를 푸는 가장 효율적인 방법은 이렇게 하는 겁니다 하고 해답을 제시할 줄 알아야 합니다.

진짜 풀고 싶은 문제가 뭔지 문제를 재정의하는 프로세스는 개인 업무를 진행할 때, 어떤 비즈니스 문제를 해결할 때에도 동일하게 적용됩니다. 내가 당장 해결해야 할 문제 는 이건대, 자꾸 어떤 기술에 매몰되던가 조금 더 잘해보려고 이것저것 건드려보는 일이 있거든요. 진짜 본질까지 스스로 질문하고 문제를 해결하는 가장 빠르고 정확한 방법을 찾았다면 그 이외의 처리들은 나중에 해도 무방합니다.

저는 문제를 재정의해서 재치있게 풀어낸 사례가 적벽대전 직전에 주유가 제갈량에게 사흘안에 화살 10만개를 구해오라 고 명령했을 때라고 생각해요. 진짜 풀어야 할 문제는 10만개의 화살을 주유에게 제공하는 것이니, 한시라도 빨리 화살 공장을 가동하는 것 처럼 매몰된 해답에 매몰되어 주위 사람을 힘들게 하는 것 보다 정말 해결해야 할 문제에 집중했던 거니까요. 만약 요구사항에 깃털의 크기, 나뭇대 2/3지점에 위나라 마크가 찍혀야 하고 화살촉은 강철로 만들어져야 한다는 조건이 있었다면 제갈량도 이 방법을 쓰진 않았겠죠?


커리어에 있어서는 29년 인생 중 최고로 만족하는 1년이었다고 자부할 수 있어요. 다시 말하면 그만큼 제가 여러모로 바닥이었다 는 것이지만, 뭐 아무렴 어떻습니까 중간중간 평가해본 제 커리어 상태는 아직 정상 입니다. 내년에는 얼마나 더 성장할지 기대되네요.

Copyright © HOJUN IN. All rights reserved