주니어 개발자 커리어 로드맵 QnA
헤이조이스 발표 당일 채팅으로 보내주신 질문 중 제가 답변할 수 있는 것들, 회사에 대한 직접적인 질문이 아닌 것들을 추려서 올려요. 검색하기 편하게 질문을 따로 타이핑할까 했는데 하루라도 빨리 올리는 것이 좋을 것 같아서 일단 이 상태로 발행합니다.
아래 QnA를 읽어주시기 전에 - 저는 아직 경력 10년도 채우지 않았고 주변 네트워크도 넓지 않은 변방�의 직업=개발자인 사람이랍니다. 꼭 염두에 두고 읽어주세요. 또 몇 개를 읽어보면 느끼시겠지만 저는 커리어는 스토리텔링이지 왕도가 없다고 생각하는 편이에요. 그러니까 아래 내용에 커리어 A-Z 방법론은 없습니다. 마지막으로 틀린 내용은 댓글이나 프로필 화면의 제안하기를 통해 알려주시면 정정하겠습니다.
영감이 되는 질문들 감사합니다❤️
정말 그 분야로 전환을 하고 싶다면 어떻게든 관련 경험을 쌓는 게 필요할 것 같아요. 그런 의미에서 가장 효과적인 방법은 지금 하고 있는 업무에 접목시키는 것 같고요.
‘뭘 해야 할지 몰라서'라는 의미가 어디에 써야 할지 모르겠다는 뜻이라면, 이건 원래 그래요! 좋은 아이디어는 원래 쉽게 안 와요. use case를 리서치해보고 관련 컨퍼런스 발표 등을 찾아보시는 것은 어떨까요?
완성한 사이드 프로젝트는 있는데 세상 밖으로 내놓지는 않았습니다. 그래도 많은 것을 배운 것 만으로 만족해요. 저는 철저하게 선택과 집중을 하는 편이라서 제 포커스는 항상 현업과 저의 건강이었어요 ㅠㅠ 하지만 발표에서 말씀드렸던 것처럼 저는 운이 많이 따라줬던 것 같고요, 사이드 프로젝트 필요성을 느끼게 되는 과정은 당연히 이해합니다.
그리고 저는 창의성이 좋은 개발자는 아니에요. 회사에서도 아이디어가 많아서 이것저것 해보길 좋아하는 사람들이 있는데, 저는 그런 스타일은 아니라서 지금 만들고 있는 것을 최상의 퀄리티로 올리고 제대로 마무리하는 생각을 더 많이 하는 것 같아요. 아이디어가 많은 사람들이 부럽기도 하지만 제가 타고나지 않은 것을 어떡하겠어요! 그냥 제가 잘할 수 있는 것을 열심히 해야죠. 블로그 쓰는 것도 사이드 프로젝트라고 볼 수 있을 것 같아요. 저의 속도가 무지막지하게 느릴 뿐….
사이드 프로젝트를 올려놓는 것과 코딩테스트/기술면접, … 은 서로 큰 관련이 없어 보입니다. 전자는 본인 포트폴리오를 얼마나 잘 꾸미느냐의 문제고, 후자는 진짜 인터뷰를 통과하는 것의 문제 같아요. 왜 이력서에 사이드 프로젝트를 올려놓고 싶으신가요? 그 이유는 질문 주신 분이 제일 정확히 아실 것 같아요!
질문 주신 분의 경우에는 사이드 프로젝트 접근이 쉬울 것 같은데요. 원래 하시는 분야니까 배우기도 쉬울 거고요. 그런데 회사에서 쓰는 기술이 시장 트렌드하고 많이 다르다면 그걸 업무로 한번 제안해보는 것도 (가능하다면) 또 다른 방법이라는 생각이 들어요.
EM이 직접적인 도움을 주는 경우는 별로 없고 제가 능동적으로 성장하는 사람이 되도록 도와주는 역할이 더 큰 것 같아요. 되게 애매하게 들리죠… 저도 그렇게 생각해요! ;; 그리고 업무 분담은 모든 팀 멤버들이 같이 참여하는 미팅에서 합니다. 예전에 썼던 EM에 대해서 언급했던 글들을 붙여요.
https://brunch.co.kr/@ggool/77
https://brunch.co.kr/@ggool/59
개발자니까 이전에 해보지 않은 일을 해보고 매일 조금씩 배우고 있다는 동기부여가 일단 중요하겠죠? 그리고 팀 리더가 없어서 한 명이 총대를 매지는 않지만 대신 팀 자체가 동력을 조금씩 나눠가져요. 팀이 다 같이 planning을 하고 매일 서로 진행사항을 공유하기 때문에, 서로서로 동기부여를 해주면서, 또 어떻게 보면 같이 일하는 사람들 전부를 제가 저를 증명해야 하는 사람들로 볼 수도 있고요. 물론 이 경우 제가 느끼는 압박감의 정도가 많이 다르지만요.
감정 부침은 저도 아직 뾰족한 수가 없는데요. 만약에 업무를 하면서 사람하고 문제가 있으면 EM과 상담하면서 현실적으로 해결하려고 해요. 그리고 운동하면서 멘탈관리에 도움을 많이 받았고 특히 거기서 느끼는 성취감이 중요했다고 생각합니다. 저는 일을 하면서 자아실현이나 성장하는 나를 계속 기대하다 보니까 감정적으로 상황을 힘들게 받아들이는 것 같은데, 일 밖에서 성취감이 약간이나마 채워지니까 일을 건조하게 ‘일'로만 볼 수 있게 되더라고요. 직업에 열정이나 애착을 갖지 말자는 이야기는 아니고, 필요할 때 on/off를 할 수 있게 되었다는 뜻이에요!
저랑 일하는 방식이 많이 다른 것 같아요. Data scientist라서 각자 PM처럼 일하시는 걸까요? 그런데 말씀하신 두 가지 방법은 연결되지 않나요? 지금 업무 프로세스를 개선하기 위해서 다른 회사가 어떻게 일하는지 리서치해서 적용해보고, 잘 되면 좋은 거고 잘 안되면 실패고… 목표로 하는 회사의 방식이 가장 와닿고 좋은 방법이라고 생각하면 그대로 한번 해보시는 거죠.
질문을 여러 번 읽어봤는데 저랑 상황이 많이 다르신 것 같아서 질문을 정확히 읽었는지 모르겠네요. 대답 방향이 좀 어긋났다면 죄송해요!
저도 아직 가보지 않은 길이라 저 역시 궁금합니다. 제가 여태껏 내린 결론은 타이틀을 빨리 달고 싶으면 스타트업이 낫고, 그게 아니면 취향 차이 같아요. 다른 방법으로는 한 회사를 오래 다니면서 계속 승진해서 staff engineer가 되는 분들도 계시잖아요. 저는 아직 다양한 케이스를 자동화하는 인프라 쪽이 좋아서 큰 회사에 다니고 있지만요.
많은 분들이 비슷한 고민을 할 것 같아요. 일에서 내 취향을 깊게 생각하는 시간이 필요하다고 생각해요. 그냥 돈 벌어야 하니까 하는 것 같아도 미묘하게 호불호가 있는데, 그런 것을 알아차리기 시작하다 보면 앞으로 무슨 일을 하고 싶은지 아이디어가 생기지 않을까요?
우리가 어릴 때부터 정해진 과목대로 공부를 해와서 그런 거지, 사실 공부밖에 삶을 전부 이런 방법으로 꾸려나가잖아요. 좋아하는 음식을 먹고 좋아하는 취미를 즐기고 좋아하는 옷을 입고. 커리어에는 모범답안이 없고, 세상에 자기가 좋아하는 일을 하는 사람을 막을 수 있는 것이 어디 있겠어요.
아직 지금 다니는 회사에서 배울 점이 있고 한국에 들어가야 하는 중요한 이유가 없기 때문이에요.
어느덧 시간이 그렇게 지났네요 @.@ 저는 계획을 자세히 세우는 타입은 아니지만, 이직을 하던 회사 안에서 움직이던 내년 초에는 무언가 해야겠다는 생각이 들어요. 지금 beta도 붙이지 못한 새로운 플랫폼을 만들고 있는데 사용자가 생길 때까지 있을 계획입니다. 처음에 프로토타입을 만들던 아주 아주 초창기부터 있던 팀이라서 매듭을 잘 짓고 싶어요.
저는 개인적으로 40대 여성 개발자를 만난 적이 없어요. 흠 예전에 저와 같이 일하셨던 분들이 이제 30대 후반 아니면 막 40대가 되셨을지도 모르겠어요. 선례가 없으면 우리가 만들면 되지 않을까요?
그리고 개발자 시장이 같이 나이를 들어가면서 자연스럽게 시니어들이 자리 잡을 것이라고 생각해요. 지금이야 연차가 차면 높은 한 자리하거나 매니저가 돼야 한다고 말하지만, 점점 연차가 많아도 계속 개발자로 남을 수 있게 커리어 스텝도 다양해지지 않을까요.
제가 말씀하신 업무를 전문적으로 해본 적은 없지만, SQL procedure는 요즘 쓰는 방식에 비해서 운영이 힘들어서 많이 쓰지 않는 것으로 알고 있어요. 데이터 엔지니어로 바꾸신다면 지금 쓰는 개념들이 여기저기 녹아있는 것을 보시게 될 것 같아요. 아주 큰 테이블에 쓰는 쿼리를 최적화해보신 적이 있다면 경험으로 어필하는데 도움이 될 것 같습니다.
여기는 사수라는 개념이 없지만 그냥 seneriority라고 생각했을 때, 저한테는 누군가가 같은 팀에 있으면 내가 일을 잘할 수 있다고 자신감을 주는 사람인 것 같아요. 다른 말로 하면 개발자로 성장할 공간과 실수를 해도 괜찮다는 안전함을 같이 주는 사람이요. 그런데 ‘성장할 공간'을 주는 것이 꼭 일방적으로 지식을 많이 가르쳐주는 것은 아니었던 것 같아요. 저는 내 생각대로 해보고 피드백을 받고 이야기하고 고치는 과정을 통해서 가장 많이 배운다고 생각하거든요.
도움/피드백을 주는 것은, 저 나름대로 만든 방법이 있어요.
싫다/좋다 로 단순하게 말하지 않는다.
왜 좋지 않은 방법인지 이유를 붙여서 논리적으로 말한다.
대안을 같이 제안한다.
질문을 읽었을 때 먼저 ‘대용량 처리' 분야를 따로 나누는 것이 가능한지?라는 생각이 들었어요. 왜냐하면 모든 데이터 인프라가 기본적으로 대용량 처리를 기반에 두고 구축되거든요.
혹시 이걸 데이터 파이프라인을 구현하는 업무를 말씀하시는 것이라면, 이건 취향 차이 같아요. 데이터 파이프라인도 비지니스에 따라서 여느 복잡한 백엔드 서비스처럼 코드가 굉장히 복잡해질 수 있거든요. 이런 빡세게 복잡한 일을 좋아하는 사람이 있는 반면, 인프라 같은 일을 좋아하는 사람이 있더라고요. 여기는 또 다른 스타일의 복잡함이 있으니까….
풀은 둘 다 주니어에게 기회도 있고 경쟁력도 있을 것 같아요. 그리고 결국엔 두 가지 다 어느 정도 할 줄 알아야 가장 경쟁력을 갖출 수 있다고 생각합니다. 그래서 한 가지를 하면서 나머지 한 가지가 어떻게 돌아가는지 대충이라도 이해하려고 계속 노력하는 것이 좋을 것 같아요.
지금 회사에서는 백엔드는 스프링 대신 사내 프레임워크를 더 많이 써요. 지금 그 일을 하고 계시면 저보다 트렌드는 더 밝으실지도… 그리고 질문 내용은 회사마다 다를 것 같아요.
정확히 클라우드 환경의 어느 쪽을 모르신다는 거죠? 데이터센터가 있고 인프라팀이 모든 것을 다 해준다면 aws나 gcp를 쓰지 않을 뿐이지 나름대로 구축된 클라우드를 사용하신다는 것처럼 들리거든요.
Streaming Systems by Tyler Akidau, Slava Chernyak, Reuven Lax
기술적인 접점은 별로 없죠. 그래도 이건 제 생각인데 프론트엔드면 a/b 테스트나 user journey를 데이터로 쌓아서 분석할 수 있지 않을까요?
둘 다요! 그리고 우리 직업이 원래 그러니까 현타 느낄 필요 없어요. 저도 지난 3~4년 동안 데이터하고 백엔드를 동시에 했는걸요. 막 일하기 시작했을 때는 자바스크립트를 더 많이 했던 것 같아요.
저는 이 질문을 읽으면서 우리가 흔히 말하는 ‘공부’가 진짜 무슨 의미인지 생각해봤어요. 그게 책을 한 두권 보거나 코스 하나를 듣는 거라면 그 정도는 올해 상반기에 쉽게 하실 것 같거든요. 그렇게 하나하나 도장깨기를 해도 되는데, 사람 마음이 신기하게 도장 하나를 깨는 동안 아직 깨지 못한 도장에 자꾸 눈이 가고 초조해지고 뭐 그렇더라고요. 이렇게 계속 왔다 갔다 하다 보면 어느샌가 전부에 익숙해진 상태가 되어있을 거예요.
둘 중에 어떤 것이 커리어에 도움이 되는지는 모르겠습니다. 한 가지에 집중된 커리어라면 나중에 방향을 틀기 어려워질 수도 있고, 너무 포괄적인 일만 해왔다면 깊이가 없다고 고민하겠죠. 공부는 깊이 있게 하고 경험은 넓게 가지자... 이 정도로 밖에 말씀을 못 드리겠어요 ㅠㅠ
