당근마켓ㅣ개발자 커뮤니티, 진짜 도움 되나요?
당근마켓ㅣ개발자 커뮤니티, 진짜 도움 되나요?
일자
상시
유형
아티클태그
이 아티클은 <꿈의 직장 '네카라쿠배당토'> 시리즈의 6화입니다.
*해당 아티클은 wanted+ 영상 성장하는 서버 개발자 되기 를 바탕으로 작성되었습니다.
기획 의도
서버 개발자는 어떻게 성장할 수 있을까요? 서버 개발자가 성장할 수 있는 방법에 대해 현실적이면서 다양한 방향의 조언을 들려줍니다.
이런 분이 읽으면 좋아요
- 개발 커뮤니티, 각종 채널 활용방법이 궁금한 개발자
- 다양한 경험을 쌓고 싶거나 이직을 고민 중인 서버 개발자
아티클로 얻을 수 있는 인사이트
- 개발 커뮤니티 200% 활용 방법
- 이력서에 개발 역량 작성하는 방법
- 성장을 위해 해야 할 다양한 활동들
*해당 아티클은 wanted+ 영상 성장하는 서버 개발자 되기 를 바탕으로 작성되었습니다.
기획 의도
서버 개발자는 어떻게 성장할 수 있을까요? 서버 개발자가 성장할 수 있는 방법에 대해 현실적이면서 다양한 방향의 조언을 들려줍니다.
이런 분이 읽으면 좋아요
- 개발 커뮤니티, 각종 채널 활용방법이 궁금한 개발자
- 다양한 경험을 쌓고 싶거나 이직을 고민 중인 서버 개발자
아티클로 얻을 수 있는 인사이트
- 개발 커뮤니티 200% 활용 방법
- 이력서에 개발 역량 작성하는 방법
- 성장을 위해 해야 할 다양한 활동들
안녕하세요, 저는 당근마켓 개발자 변규현입니다. 현재 AWS Serverless Hero로도 활동하고 있어요. 사내에서는 주로 GO 언어를 사용하고 있고, 개발을 잘하고 싶어서 무엇을 못하는지 찾고, 매일 공부하고 있어요. 오늘은 제가 세 번째 스타트업에 오기까지의 여정에 대해 말씀드리려고 해요.
변규현 님 ⓒ 변규현
당근마켓에 올 수 있었던 계기
당근마켓에 오기 전에 저는 작은 스타트업들을 다니고 있었습니다. 그때 작은 커뮤니티 중 하나인 AWS Korea User Group을 접했어요. 이 곳에서 처음 당근마켓 CTO를 만나게 됐습니다. 당근마켓이 커지기 전에 처음 뵀는데, 2019년에 제가 이직한다는 소식을 듣고 저한테 전화를 주셨어요. 실제로 만나 조인 과정에 대해 이야기를 나누다 면접을 보게 됐고, 당근마켓에 입사하게 됐습니다.
개발 커뮤니티가 취업에 도움이 될까?
한 가지 의문이 드실 것 같아요. ‘과연 커뮤니티 활동이 이직에 도움이 될까?’라는 점이요. 답변은 ‘도움 된다’입니다. 그렇다면 왜 도움이 될까요? 그리고 저는 어떤 과정으로 도움받았을까요? 먼저 커뮤니티 활동을 하면 기술 능력이 향상됩니다. 예를들어 AWS 커뮤니티는 AWS에 관심이 많은 사람들로 구성돼 있는데요. AWS에 대해 궁금한 점을 공유하고, 아는 것과 궁금한 점을 계속해서 공유해요. 이처럼 커뮤니티는 지식을 공유하는 공간이에요. 가르침을 받기도 하지만 아는 것을 공유하기도 하거든요.
그렇다면 커뮤니티에서 어떻게 개발 지식을 쌓을까요? 어렵지 않습니다. 커뮤니티에 가입하고, 구독만 하면 돼요. 페이스북 커뮤니티도 괜찮고, 이메일 구독도 괜찮아요. 많은 유즈 케이스(use case)와 글이 매주 공유되는데, 이것만 읽어봐도 좋아요. 페이스북의 경우 글이 매일 올라와요. 사실 처음에는 글을 읽고 발표를 들어도 기억에 잘 남지 않아요. 익숙한 기술이 아니기 때문에 까먹기 십상이죠. 그런데 커뮤니티에서 공유되는 내용은 계속 반복이 돼요. 비슷한 기술을 사용한 경험들이 지속적으로 공유되는데, 이 반복 학습이 기적을 만듭니다. 처음에는 어렵다고 느끼고, 이해하는 데까지 시간이 걸렸는데 커뮤니티에서 관련 아티클을 계속해서 읽다 보면 어느새 그 기술과 친숙해지는 거예요. 그리고 계속 보다 보면 “이거 한번 해보고 싶은데?”하면서 따라하게 되고, “개선해보고 싶은데?”하면서 계속 성장하게 되는 상황에 자연스레 휩싸이게 되죠.
그런데 반복되다 보면 ‘지루하지 않을까?’하는 의문이 생기겠죠. 이미 알고 있는 것들도 있으니까요. 그런데 90% 정도의 내용이 반복되더라도 10%는 누구나 특별한 경험을 갖고 있어요. 우리가 일하는 공간이 다르고, 경험하는 방식이 다르기 때문이에요. 그래서 다른 사람들의 특별한 경험 10%로 부족한 경험들이 채워지는 거죠. 그리고 이 지식을 당장 사용하지 않더라도 1년 후에 사용할 일이 생길 수도 있어요. 개인적으로는 그럴 때 굉장히 도움 된다는 걸 경험할 수 있었어요. 그래서 이 공부는 나중을 위해 하는 거니까 계속 배우는 것에 대해 적응해야 하는 거죠. 물론 커뮤니티 활동을 하면 시간을 낭비한다는 생각이 들 수 있어요. 그런데 커뮤니티에 참여해도 놀 시간은 충분해요. 커뮤니티 행사가 하루 종일 있지도 않고, 몇 시간을 투자해야 되는 수준도 아니거든요. 보통 5분, 길면 15분이기 때문에 부담 없이 활동하면 돼요.
이렇게 두 번의 스타트업을 다니는 동안 커뮤니티에서 많은 것을 배웠어요. 저의 부족한 점을 알고 있었고, 부족한 점을 채우기 위해 커뮤니티에서 잘하는 분들을 찾아 계속 배웠던 것 같아요. 그래서 커뮤니티를 보면 영화 <어벤져스>가 생각나요. 수많은 사람들이 잘하는 분야가 다 다르거든요. 그리고 무엇보다 위계질서가 없어요. 회사에선 팀장님한테 물어보기 무섭잖아요. 그런데 여기서는 60대 교수님들과도 친구처럼 지내요. 심지어 제가 더 잘 아는 부분이 있으면 알려드리고, 내가 모르는 게 있다면 그분이 알려주세요. 그럼 모르는 부분의 키워드도 듣고, 그 부분을 따로 공부하는 압축 성장을 할 수 있는 공간인 거죠.
또, 커뮤니티의 중요 포인트는 자주 참여하다 보면 발표 제안이 온다는 거예요. 커뮤니티는 발표자에 목마르거든요. 저는 발표 제안이야말로 저를 알릴 수 있는 좋은 기회라고 생각해요. 커뮤니티는 규모가 크든 작든 발표 연습을 할 수 있는 공간이에요. 그리고 작은 발표 경험은 큰 발표에 도움이 되죠. 예를 들어 10명 내외를 위한 발표자료를 만들고 공유했는데, 이분이 카카오 컨퍼런스를 진행하는 사람이라면 그 경험을 “우리 컨퍼런스에서 공유해주시는 게 어때요?”하고 제안이 와요. 그럼 이 자료를 바탕으로 딥다이브해서 다시 공유하는 거죠. 그렇게 계속 발표하다 보면 오늘처럼 원티드에서도 발표할 수 있는 거죠. 이건 이력서를 직접 넣는 것과 또 달라요. 쉽게 저를 알릴 수 있어 이력서를 넣지 않더라도 제안을 받게 되는 거예요.
당근마켓에 올 수 있었던 계기
당근마켓에 오기 전에 저는 작은 스타트업들을 다니고 있었습니다. 그때 작은 커뮤니티 중 하나인 AWS Korea User Group을 접했어요. 이 곳에서 처음 당근마켓 CTO를 만나게 됐습니다. 당근마켓이 커지기 전에 처음 뵀는데, 2019년에 제가 이직한다는 소식을 듣고 저한테 전화를 주셨어요. 실제로 만나 조인 과정에 대해 이야기를 나누다 면접을 보게 됐고, 당근마켓에 입사하게 됐습니다.개발 커뮤니티가 취업에 도움이 될까?
한 가지 의문이 드실 것 같아요. ‘과연 커뮤니티 활동이 이직에 도움이 될까?’라는 점이요. 답변은 ‘도움 된다’입니다. 그렇다면 왜 도움이 될까요? 그리고 저는 어떤 과정으로 도움받았을까요? 먼저 커뮤니티 활동을 하면 기술 능력이 향상됩니다. 예를들어 AWS 커뮤니티는 AWS에 관심이 많은 사람들로 구성돼 있는데요. AWS에 대해 궁금한 점을 공유하고, 아는 것과 궁금한 점을 계속해서 공유해요. 이처럼 커뮤니티는 지식을 공유하는 공간이에요. 가르침을 받기도 하지만 아는 것을 공유하기도 하거든요.그렇다면 커뮤니티에서 어떻게 개발 지식을 쌓을까요? 어렵지 않습니다. 커뮤니티에 가입하고, 구독만 하면 돼요. 페이스북 커뮤니티도 괜찮고, 이메일 구독도 괜찮아요. 많은 유즈 케이스(use case)와 글이 매주 공유되는데, 이것만 읽어봐도 좋아요. 페이스북의 경우 글이 매일 올라와요. 사실 처음에는 글을 읽고 발표를 들어도 기억에 잘 남지 않아요. 익숙한 기술이 아니기 때문에 까먹기 십상이죠. 그런데 커뮤니티에서 공유되는 내용은 계속 반복이 돼요. 비슷한 기술을 사용한 경험들이 지속적으로 공유되는데, 이 반복 학습이 기적을 만듭니다. 처음에는 어렵다고 느끼고, 이해하는 데까지 시간이 걸렸는데 커뮤니티에서 관련 아티클을 계속해서 읽다 보면 어느새 그 기술과 친숙해지는 거예요. 그리고 계속 보다 보면 “이거 한번 해보고 싶은데?”하면서 따라하게 되고, “개선해보고 싶은데?”하면서 계속 성장하게 되는 상황에 자연스레 휩싸이게 되죠.
그런데 반복되다 보면 ‘지루하지 않을까?’하는 의문이 생기겠죠. 이미 알고 있는 것들도 있으니까요. 그런데 90% 정도의 내용이 반복되더라도 10%는 누구나 특별한 경험을 갖고 있어요. 우리가 일하는 공간이 다르고, 경험하는 방식이 다르기 때문이에요. 그래서 다른 사람들의 특별한 경험 10%로 부족한 경험들이 채워지는 거죠. 그리고 이 지식을 당장 사용하지 않더라도 1년 후에 사용할 일이 생길 수도 있어요. 개인적으로는 그럴 때 굉장히 도움 된다는 걸 경험할 수 있었어요. 그래서 이 공부는 나중을 위해 하는 거니까 계속 배우는 것에 대해 적응해야 하는 거죠. 물론 커뮤니티 활동을 하면 시간을 낭비한다는 생각이 들 수 있어요. 그런데 커뮤니티에 참여해도 놀 시간은 충분해요. 커뮤니티 행사가 하루 종일 있지도 않고, 몇 시간을 투자해야 되는 수준도 아니거든요. 보통 5분, 길면 15분이기 때문에 부담 없이 활동하면 돼요.
이렇게 두 번의 스타트업을 다니는 동안 커뮤니티에서 많은 것을 배웠어요. 저의 부족한 점을 알고 있었고, 부족한 점을 채우기 위해 커뮤니티에서 잘하는 분들을 찾아 계속 배웠던 것 같아요. 그래서 커뮤니티를 보면 영화 <어벤져스>가 생각나요. 수많은 사람들이 잘하는 분야가 다 다르거든요. 그리고 무엇보다 위계질서가 없어요. 회사에선 팀장님한테 물어보기 무섭잖아요. 그런데 여기서는 60대 교수님들과도 친구처럼 지내요. 심지어 제가 더 잘 아는 부분이 있으면 알려드리고, 내가 모르는 게 있다면 그분이 알려주세요. 그럼 모르는 부분의 키워드도 듣고, 그 부분을 따로 공부하는 압축 성장을 할 수 있는 공간인 거죠.
또, 커뮤니티의 중요 포인트는 자주 참여하다 보면 발표 제안이 온다는 거예요. 커뮤니티는 발표자에 목마르거든요. 저는 발표 제안이야말로 저를 알릴 수 있는 좋은 기회라고 생각해요. 커뮤니티는 규모가 크든 작든 발표 연습을 할 수 있는 공간이에요. 그리고 작은 발표 경험은 큰 발표에 도움이 되죠. 예를 들어 10명 내외를 위한 발표자료를 만들고 공유했는데, 이분이 카카오 컨퍼런스를 진행하는 사람이라면 그 경험을 “우리 컨퍼런스에서 공유해주시는 게 어때요?”하고 제안이 와요. 그럼 이 자료를 바탕으로 딥다이브해서 다시 공유하는 거죠. 그렇게 계속 발표하다 보면 오늘처럼 원티드에서도 발표할 수 있는 거죠. 이건 이력서를 직접 넣는 것과 또 달라요. 쉽게 저를 알릴 수 있어 이력서를 넣지 않더라도 제안을 받게 되는 거예요.
ⓒ 변규현
그렇다면 발표는 어떤 주제로 해야 할까요? 저는 두 가지 카테고리로 나눠요. 모두가 관심 갖지만 대부분 모르는 것, 그리고 내가 잘 알고 경험이 있는 것으로요. 전자의 예시는 3-4년 전만 해도 클라우드 경험이 없었거든요. 그럼 클라우드를 도입할 때 어떤 것을 고려해야 하는지 이제 막 시작하는 사람들을 대상으로 저만의 방식을 알려줘요. 예를들면 제가 잘 알고 있고 경험이 많은 것은 GO 언어와 채팅 플랫폼, AWS, 데이터 파이프라인 등이 에요. 이미 잘 알고 있기 때문에 이 경험을 잘 정리해서 사람들에게 공유할 수 있겠죠. 이렇게 두 가지 방식이 있는 것 같아요.
모두가 관심 갖지만 대부분 모르는 것에 대해 발표했을 때, 이것을 새로운 공부를 하는 기회라고 생각하는 것이 중요해요. 내가 공부한 내용을 레퍼런스로 남길 수 있는 기회인 거죠. 아무리 공부를 열심히 해도 면접관들은 내가 이걸 아는지 몰라요. 그런데, ‘나는 이걸 공부했다’는 걸 알려야만 해요. 왜냐하면 나는 이 회사를 가고 싶거든요. 그래서 나의 발표자료를 이직하고 싶은 회사의 담당자가 보고 “이 사람 이런 것도 공부했었네?”하고 알 수 있도록 준비하는 거죠. 그러면 발표하는 것이 곧 기회가 되는 거예요.
그렇다면 발표는 어떤 주제로 해야 할까요? 저는 두 가지 카테고리로 나눠요. 모두가 관심 갖지만 대부분 모르는 것, 그리고 내가 잘 알고 경험이 있는 것으로요. 전자의 예시는 3-4년 전만 해도 클라우드 경험이 없었거든요. 그럼 클라우드를 도입할 때 어떤 것을 고려해야 하는지 이제 막 시작하는 사람들을 대상으로 저만의 방식을 알려줘요. 예를들면 제가 잘 알고 있고 경험이 많은 것은 GO 언어와 채팅 플랫폼, AWS, 데이터 파이프라인 등이 에요. 이미 잘 알고 있기 때문에 이 경험을 잘 정리해서 사람들에게 공유할 수 있겠죠. 이렇게 두 가지 방식이 있는 것 같아요.
모두가 관심 갖지만 대부분 모르는 것에 대해 발표했을 때, 이것을 새로운 공부를 하는 기회라고 생각하는 것이 중요해요. 내가 공부한 내용을 레퍼런스로 남길 수 있는 기회인 거죠. 아무리 공부를 열심히 해도 면접관들은 내가 이걸 아는지 몰라요. 그런데, ‘나는 이걸 공부했다’는 걸 알려야만 해요. 왜냐하면 나는 이 회사를 가고 싶거든요. 그래서 나의 발표자료를 이직하고 싶은 회사의 담당자가 보고 “이 사람 이런 것도 공부했었네?”하고 알 수 있도록 준비하는 거죠. 그러면 발표하는 것이 곧 기회가 되는 거예요.
ⓒ 변규현
서버 개발자에게 필요한 역량
그렇다면 일을 잘하기 위해서는 어떤 역량이 필요할까요? AWS에서는 원하는 역량이 있습니다. 다이브 딥, 띵크 딥, 원 트러스트 등이 있는데요. 이런 것들을 제외하고 비즈니스 도메인에 대한 이해가 필요하다고 생각해요. 가고 싶은 회사의 비즈니스 도메인에 대한 이해가 없으면 안 된다고 생각하거든요. 만약 원티드에 가고 싶다면, 채용 플랫폼에 대한 이해 없이 지원할 수는 없겠죠. 광고 회사에 가고 싶다면 어떤 광고로 이뤄져 있고, 이 회사에서 광고 비즈니스 모델은 어떤 게 있는지 공부해서 지원해야 된다고 생각해요. 개발자도 마찬가지예요. 비즈니스 모델을 모르면 실제 업무를 진행할 수가 없어요.
그리고 개발자 측면에서는 피처 개발, 아키텍처 개선, 튜닝, 로직 개선에 대한 고찰 등이 필요해요. 피처 개발을 할 때 기획자가 생각하는 것을 시키는 대로 개발하는 게 아니라 함께 고민하며 개발하는 거죠. 그리고 아키텍처 자체를 개선할 수 있어요. 점점 서비스가 커져가면 아키텍처가 바뀌거든요. 그래서 아키텍처를 어떻게 개선할까, 튜닝을 어떻게 할까, 로직을 어떻게 개선할까에 대한 고민을 하는 것 같아요. 이 서비스가 커지면 기존 방식으로는 내가 해결하지 못하기 때문에 새로운 방법을 찾게 되고, 현재 ‘As-is(현재 업무 프로세스 분석)’에서 보이는 문제를 분석하고 ‘To be(미래에 개선될 업무 프로세스)’ 모델을 생각하는 거죠.
또, 커뮤니케이션 역량이 중요해요. 개인적으로 개발자가 개발만 하는 것은 아쉽다고 생각하는데요. 개발자 혼자 프로덕트를 개발할 수 없고, 1인 개발로 성장할 수 있는 벽은 정해져 있거든요. 결국 디자이너와 PM, 대표, 마케터 등 다양한 직군과 소통할 수 있어야 해요. 다른 직군도 알아들을 수 있도록 단어를 선택해 대화해야 해요. 예를 들어, 메신저로 일하는 경우 대화를 간결하게 하기보다는 한 가지 질문에 상황 설명을 하면서 질문하는 것을 추천해요. 커뮤니케이션 코스트(cost)를 줄이는 것을 생각하는 거죠. 저는 개발자가 다양한 방면에 있어 효율적인 업무를 진행하기 위해 고민해야 하는 것 같아요. 같은 말을 하더라도 상처주지 않고 상대방의 의욕을 북돋도록 대화하는 역량도 중요하죠.
성장하는 개발자가 되기 위해서는 사이드 프로젝트가 중요하다고 생각해요. 회사에서 경험할 수 있는 것은 회사에 한정되기도 해서 더 공부하고 싶은 영역은 사이드 프로젝트로 증명할 수 있다고 생각해요. 제가 공부한 것을 깃헙에 올려놓는 거죠. 그런데 단순히 공부한 부분을 써놓는 것이 아니라 사이드 프로젝트를 실제 업로드하고, 디플로이해서 실제 사용자들이 작업물을 볼 수 있도록 제공하는 것이 중요한 점인 것 같아요. 또, 유튜브에 내가 공부하고 싶은 것을 검색해 보세요. 주의해야 하는 것은 ‘For beginner’, ‘시작하기’ 말고 딥 다이브, 아키텍처, 인터널 같은 키워드로 검색하는 게 좋아요. 내부적으로 어떻게 동작하는 지 알면 사용처를 더 분명하게 알 수 있거든요. 결국 겉핥기식 지식이 아니라 좀 더 깊이 이해하는 자세한 지식을 알 수 있게 돼요.
마지막으로 공식 문서를 먼저 보는 습관을 말씀드리고 싶어요. 한글로 된 블로그는 누군가의 생각이 들어간 내용인 경우가 많은데, 공식 문서는 이 프로덕트를 만든 사람, 누구보다 이것을 이해하는 사람이 직접 적은 글이거든요. 더욱 정확한 지식을 얻을 수 있고, 깊이 있는 개발자가 되기 위해 이 기술에 한 걸음 더 다가갈 수 있는 거죠. 이 말은 Stack Overflow를 최대한 멀리하라는 말이에요. Stack Overflow는 실제로 이해하고 쓰는 지식이 아니라 문제 해결만을 위한 인스턴트형 지식이 많거든요. 제대로 된 이해를 하고 싶으면 레퍼런스 문서를 먼저 읽는 게 좋아요. 그래서 성장하고 싶다면 Stack Overflow는 최대한 멀리하라고 말씀드리고 싶어요.
당근 개발자의 취업 꿀팁
이 부분은 모두에게 통용되는 것은 아니니까 자신만의 방식을 찾는 의미로 들어주셨으면 해요. 앞서 말했듯, 저는 관심 분야에 대한 발표를 하고 정리하는 것을 추천해요. 발표 제안이 오면 여유가 되는 한 대부분 진행했어요. 회사 업무에 영향이 가지 않아야 하기 때문에 심야나 주말을 활용해 준비했죠. 오늘 이 발표 자료를 준비하고 공유한 것도 새벽 3시쯤이었을 거예요. 발표자료는 항상 제 개인 시간을 들여 준비했었고요.
그럼 발표하고 공개하는 것이 왜 좋다고 할까요? 오늘 계속해서 말씀드리지만, 면접관은 이력서 한 장을 보고 판단해요. 그런데 내가 아는 지식이 많더라도 이 한 장에 설명이 들어가야 해요. 발표를 했다고 하면 링크를 첨부하세요. 논문을 쓰셨으면 논문을 첨부하세요. 사이드 프로젝트를 했으면 사이드 프로젝트 링크를 첨부하고, 예제에 사이트를 올려주세요. 아니면 앱 링크를 올리거나 깃헙이면 깃헙 Repository를 첨부하세요. 그럼 채용 담당자는 한 번은 반드시 들어가 보거든요. 한 번은 후킹할 수 있는 요소들을 남겨놓는 거죠. 그래서 어디 출신인지가 중요한 것이 아니에요. 이 사람이 서류를 통과하려면 합격시키려는 근거가 있어야 해요. 어떤 프로젝트에서 어떤 경험을 했는데, 그게 만족스러워야 통과가 되는 거잖아요. 이런 증거를 보여주는 건 깃헙이고 그걸 증명하는 과정은 면접이 되겠죠.
제가 말하고 싶은 건 이런 거예요.
서버 개발자에게 필요한 역량
그렇다면 일을 잘하기 위해서는 어떤 역량이 필요할까요? AWS에서는 원하는 역량이 있습니다. 다이브 딥, 띵크 딥, 원 트러스트 등이 있는데요. 이런 것들을 제외하고 비즈니스 도메인에 대한 이해가 필요하다고 생각해요. 가고 싶은 회사의 비즈니스 도메인에 대한 이해가 없으면 안 된다고 생각하거든요. 만약 원티드에 가고 싶다면, 채용 플랫폼에 대한 이해 없이 지원할 수는 없겠죠. 광고 회사에 가고 싶다면 어떤 광고로 이뤄져 있고, 이 회사에서 광고 비즈니스 모델은 어떤 게 있는지 공부해서 지원해야 된다고 생각해요. 개발자도 마찬가지예요. 비즈니스 모델을 모르면 실제 업무를 진행할 수가 없어요.그리고 개발자 측면에서는 피처 개발, 아키텍처 개선, 튜닝, 로직 개선에 대한 고찰 등이 필요해요. 피처 개발을 할 때 기획자가 생각하는 것을 시키는 대로 개발하는 게 아니라 함께 고민하며 개발하는 거죠. 그리고 아키텍처 자체를 개선할 수 있어요. 점점 서비스가 커져가면 아키텍처가 바뀌거든요. 그래서 아키텍처를 어떻게 개선할까, 튜닝을 어떻게 할까, 로직을 어떻게 개선할까에 대한 고민을 하는 것 같아요. 이 서비스가 커지면 기존 방식으로는 내가 해결하지 못하기 때문에 새로운 방법을 찾게 되고, 현재 ‘As-is(현재 업무 프로세스 분석)’에서 보이는 문제를 분석하고 ‘To be(미래에 개선될 업무 프로세스)’ 모델을 생각하는 거죠.
또, 커뮤니케이션 역량이 중요해요. 개인적으로 개발자가 개발만 하는 것은 아쉽다고 생각하는데요. 개발자 혼자 프로덕트를 개발할 수 없고, 1인 개발로 성장할 수 있는 벽은 정해져 있거든요. 결국 디자이너와 PM, 대표, 마케터 등 다양한 직군과 소통할 수 있어야 해요. 다른 직군도 알아들을 수 있도록 단어를 선택해 대화해야 해요. 예를 들어, 메신저로 일하는 경우 대화를 간결하게 하기보다는 한 가지 질문에 상황 설명을 하면서 질문하는 것을 추천해요. 커뮤니케이션 코스트(cost)를 줄이는 것을 생각하는 거죠. 저는 개발자가 다양한 방면에 있어 효율적인 업무를 진행하기 위해 고민해야 하는 것 같아요. 같은 말을 하더라도 상처주지 않고 상대방의 의욕을 북돋도록 대화하는 역량도 중요하죠.
성장하는 개발자가 되기 위해서는 사이드 프로젝트가 중요하다고 생각해요. 회사에서 경험할 수 있는 것은 회사에 한정되기도 해서 더 공부하고 싶은 영역은 사이드 프로젝트로 증명할 수 있다고 생각해요. 제가 공부한 것을 깃헙에 올려놓는 거죠. 그런데 단순히 공부한 부분을 써놓는 것이 아니라 사이드 프로젝트를 실제 업로드하고, 디플로이해서 실제 사용자들이 작업물을 볼 수 있도록 제공하는 것이 중요한 점인 것 같아요. 또, 유튜브에 내가 공부하고 싶은 것을 검색해 보세요. 주의해야 하는 것은 ‘For beginner’, ‘시작하기’ 말고 딥 다이브, 아키텍처, 인터널 같은 키워드로 검색하는 게 좋아요. 내부적으로 어떻게 동작하는 지 알면 사용처를 더 분명하게 알 수 있거든요. 결국 겉핥기식 지식이 아니라 좀 더 깊이 이해하는 자세한 지식을 알 수 있게 돼요.
마지막으로 공식 문서를 먼저 보는 습관을 말씀드리고 싶어요. 한글로 된 블로그는 누군가의 생각이 들어간 내용인 경우가 많은데, 공식 문서는 이 프로덕트를 만든 사람, 누구보다 이것을 이해하는 사람이 직접 적은 글이거든요. 더욱 정확한 지식을 얻을 수 있고, 깊이 있는 개발자가 되기 위해 이 기술에 한 걸음 더 다가갈 수 있는 거죠. 이 말은 Stack Overflow를 최대한 멀리하라는 말이에요. Stack Overflow는 실제로 이해하고 쓰는 지식이 아니라 문제 해결만을 위한 인스턴트형 지식이 많거든요. 제대로 된 이해를 하고 싶으면 레퍼런스 문서를 먼저 읽는 게 좋아요. 그래서 성장하고 싶다면 Stack Overflow는 최대한 멀리하라고 말씀드리고 싶어요.
당근 개발자의 취업 꿀팁
이 부분은 모두에게 통용되는 것은 아니니까 자신만의 방식을 찾는 의미로 들어주셨으면 해요. 앞서 말했듯, 저는 관심 분야에 대한 발표를 하고 정리하는 것을 추천해요. 발표 제안이 오면 여유가 되는 한 대부분 진행했어요. 회사 업무에 영향이 가지 않아야 하기 때문에 심야나 주말을 활용해 준비했죠. 오늘 이 발표 자료를 준비하고 공유한 것도 새벽 3시쯤이었을 거예요. 발표자료는 항상 제 개인 시간을 들여 준비했었고요.그럼 발표하고 공개하는 것이 왜 좋다고 할까요? 오늘 계속해서 말씀드리지만, 면접관은 이력서 한 장을 보고 판단해요. 그런데 내가 아는 지식이 많더라도 이 한 장에 설명이 들어가야 해요. 발표를 했다고 하면 링크를 첨부하세요. 논문을 쓰셨으면 논문을 첨부하세요. 사이드 프로젝트를 했으면 사이드 프로젝트 링크를 첨부하고, 예제에 사이트를 올려주세요. 아니면 앱 링크를 올리거나 깃헙이면 깃헙 Repository를 첨부하세요. 그럼 채용 담당자는 한 번은 반드시 들어가 보거든요. 한 번은 후킹할 수 있는 요소들을 남겨놓는 거죠. 그래서 어디 출신인지가 중요한 것이 아니에요. 이 사람이 서류를 통과하려면 합격시키려는 근거가 있어야 해요. 어떤 프로젝트에서 어떤 경험을 했는데, 그게 만족스러워야 통과가 되는 거잖아요. 이런 증거를 보여주는 건 깃헙이고 그걸 증명하는 과정은 면접이 되겠죠.
제가 말하고 싶은 건 이런 거예요.
화려한 스킬은 없어요. 모든 것은 차근차근 쌓아서 눈에 띄는 사람이 되도록 하는 거예요. 개발자는 자기소개를 백날 써봤자 증명할 수 없거든요.
그런데 소스코드, 발표, PPT가 증거 자료가 되는 거죠.
ⓒ 변규현
Q&A
1. 작은 회사라서 인프라를 경험할 수 있는 기회가 없을 경우 이직밖에 답이 없을까요?
작은 회사라도 충분히 성장할 수 있습니다. 회사 자체에서 배우는 것이 한정적이라면 개인 시간을 들여야 하거든요. 이 경험을 시뮬레이션하는 방법은 간단해요. 라인 엔지니어링, 당근마켓 블로그 등 여러 회사의 기술 블로그에 과정과 방향을 정리한 문서를 참고하는 거예요. 거기에는 아키텍처가 있고, 키워드가 있어요. 그럼 키워드를 찾아 케이스 스터디를 하면 돼요. 직접 정리하고 공부할 수 있는 거죠. 유튜브 같은 곳에서 키워드와 함께 ‘딥 다이브’라고 검색하면 좋은 내용들이 많이 나오거든요. 그런 것을 보면서 공부하면 좋아요. 중요한 것은 찾아서 공부해야 한다는 점이에요.
2. 3년 차 서버 개발자인데 앞으로의 개발 공부 방향에 대해 궁금해요.
제가 이 질문의 케이스를 두 가지로 나눠봤어요. 먼저 회사에서 성장하고 싶은지, 그리고 이직하고 싶어서 성장하고 싶은지 생각해야 할 것 같아요. 만약 회사에서 더 좋은 자리를 잡고 싶다고 하면 회사에 존재하는 것에 대해 더 공부해야 해요. 회사 시스템을 더 정확하게 이해하는 게 우선인 거죠. 그런데 내가 이직하고자 하는 회사에서 사용하는 것이 다른 분야라면 그 분야에 대해 공부하고, 준비하는 거죠.
3. 대용량 트래픽 분산처리의 해결 과정이 궁금해요.
명확하게 대용량 트래픽 분산처리가 필요한 상황에 대해 정의해야 해요. 필요한 요소가 어떤 건지, 특정 서비스에서 발생하는 건지, 전반적으로 모든 서비스에서 발생하는 건지 알아야 해요. 만약 특정 서비스에서 발생한다면 서비스를 분리할 수 있어요. 결국에는 대용량 트래픽 분산처리의 꽃은 캐싱이라고 생각하거든요. 만약 자세히 공부하고 싶으면 유튜브에 ‘AWS cache me if you can’이라고 검색하면, 캐싱이 어떻게 이뤄지는지, 캐싱 레이어들이 어떻게 이뤄져 있는지 공부할 수 있을 거예요.
4. 회사마다 요구하는 기술 스킬이 제각각이라 준비하기 힘들어요.
한두 개만 집중해서 준비해야 하냐 말아야 하냐에 대한 이야기는 정답이 아니라고 생각해요. 참고하실 수 있도록, 제가 준비했던 과정을 공유드릴게요. 먼저 제일 가고 싶은 회사 하나를 정하고 이 회사를 준비해요. 그런데 이 회사와 비슷한 스택의 회사들이 있어요. 그럼 그 회사들을 연습게임으로 두는 것 같아요. 수능을 보기 전에 모의고사를 보잖아요. 그런데 모의고사가 없으면 수능을 잘 보기 힘들잖아요. 그래서 이 회사를 깊게 준비하기 위해 비슷한 회사를 찾아 면접을 보는 거죠. 그래서 하나를 깊게 준비하는 것을 추천드려요.
5. 사이드 프로젝트를 진행하고 깃헙에 올리고 있는데 예전 코드를 보면 부끄럽기만 합니다. 깃헙에 올린 코드를 지금이라도 시간을 들여 리팩토링하는 것이 신입 개발자로서 어필이 될까요? 그리고 리팩토링에 참고할 만한 대표적인 소스는 어떤 게 있을까요?
저도 부끄러운 코드가 있죠. 그런데 그렇다고 해서 옛날에 짜둔 코드를 수정하지 않아요. 왜냐면 그것도 제 역사거든요. ‘옛날에 이렇게 했는데 지금은 더 잘 짜고 있어요’라는 걸 보여줄 수 있는 과정이거든요. 새로운 프로젝트를 하시면서 개선된 코드를 보여주는 게 낫다고 생각합니다.
6. 현재 주니어에서 시니어로 넘어가는 시점입니다. 시니어 개발자로 성장하기 위해 어떤 것들이 필요한지 궁금합니다.
‘프로젝트를 처음부터 끝까지 정확하게 설계하고 이 일정에 차질 없게 진행할 수 있는가?’가 시니어 개발자의 기준인 것 같아요. 시니어는 이 사람을 적재적소에 투입하고, 머릿속에 릴리즈 데이트 이전까지의 여정이 처음부터 끝까지 저절로 그려져야 되거든요. 저도 그 과정에 있다고 생각하고, 그 목표를 향해 나아가고 있습니다.
7. 취업, 이직 준비생으로 책이나 페이퍼로 공부하고 있는데 이런 것들은 어떻게 어필하면 좋을까요?
뭐든지 사용자 입장에서 생각해야 되거든요? 이력서를 보는 사람이 편하게 볼 수 있도록 하는 것이 중요한 것 같아요. 개인 블로그에 정확한 제목과 목표, 상세한 내용을 적고 트러블슈팅까지 정확하게 정리하는 것이 좋은 습관인 것 같아요. 개인 블로그를 준비하고 있다면 면접 전에 그 블로그를 보고 이 사람을 판단할 수 있는 거죠. 면접관에게 쉽게 접근할 수 있는 길을 열어주는 것이 중요하다고 생각합니다.
8. 현재 직무와 스킬셋이 다른 짧은 경력도 이력서에 기술하는 게 좋을까요? 혹은 너무 짧아서 마이너스 요인이 될 수 있으니 적지 않는 것이 좋을까요?
짧은 경력이 기준이 되는 것은 아니고, 내가 정확하게, 깊게 아는 것이 아니라면 이력서에서 빼는 것을 추천합니다. 오히려 바닥이 드러나는 과정일 수도 있거든요 “어디까지 해봤어요?”라는 질문을 받았을 때 “써봤어요”라고 대답하면 면접관은 더 이상 질문할 것이 없거든요. 그래서 정확하게 알고, 고민해보고 할 말이 있는 것을 이력서에 적는 게 맞다고 생각해요.
9. 번아웃이 왔을 때 어떻게 극복하셨나요?
저는 번아웃이 온 적이 없어요. 그런데 번아웃이 아니라 ‘힘든 시간’, 그리고 일하기 싫을 때는 당연히 찾아오는 것 같아요. 번아웃이라는 말에 집중하면 더 번아웃에 빠지는 것 같거든요. 개인적으로 번아웃은 ‘안 하기 위한 핑계’라는 생각이 들어요. 하기 싫을 때는 진짜 안 하고, 하고 싶을 때 다시 돌아와 보고, 누군가와 충돌이 있어서 잘 안 된다 싶을 때는 그때 멈추고 느슨한 상태에서 다시 이야기하고, 그렇게 하는 것 같아요. 번아웃은 누적돼서 해결이 안 됐을 때를 말하는 것 같은데 일이 어차피 진행되지 않고 있는데 번아웃이라는 단어에 집중하지 않는 게 정답이라고 생각해요. 번아웃을 피하기 위해 놀러 나가는 자유로운 해결 방법을 추천합니다. 힘든 시간은 있지만 번아웃은 오지 않았다고 생각해요.
10. 서버 개발자를 꿈꾸는 사람인데, 중고 신입에게 필요한 게 자격증 같은 지식적인 부분인지, 토이 프로젝트 같은 경험일지요. 우선순위를 정해야 한다면 어떤 것에 집중해야 할까요?
지식이라고 하면 너무 광범위하고, 토이 프로젝트라고 하면 하나의 카테고리화된 영역에 대해 토이 프로젝트를 진행하잖아요. 그럼 그 카테고리의 영역에 대해 토이 프로젝트를 진행하면서 지식을 쌓아올린 다음에 면접에서 잘 이끌어내는 것이 중요한 것 같아요. 면접에서 잘하는 영역을 질문받으면 강점이 드러나는 것이고, 못하는 것을 적어두고 질문받으면 단점이 드러나는 거잖아요. 장점을 드러낼 수 있게 작전을 짜는 거죠. 지식을 쌓아뒀다고 해도 면접관들은 이 사람이 지식을 얼마나 가졌는지 몰라요. 그것을 증명할 만한 단서를 주는 거죠. 저는 그걸 토이 프로젝트라고 생각해요.
11. 서버 코드 작성을 주로 하다 보면 인프라 모니터링에 대한 경험이 적습니다. 여기에 대한 경험을 간접적으로 쌓을 수 있는 방법이 있을까요?
모니터링은 선택이 아니라 필수고요. 모니터링에 대해 더 딥하게 설명하면 모니터링이 인프라 레벨에서의 모니터링이 있고, API에서의 모니터링이 있고, 어플리케이션 로직 내에서의 모니터링이 있어요. 그것들을 하나하나 할 줄 알아야 해요. 컴퓨팅 리소스 자원에 대해서 어떻게 모니터링하는지, 클러스터에서 인스턴스 전체 흐름에 대한 모니터링을 해야 하고, APM 모니터링도 봐야 하고 이것들을 전부 해야만 저희가 서비스에서 문제 지점을 빠르게 파악하고 개선할 수 있어요. 그래서 선택이 아니라 필수라는 점을 염두에 두고 성장하셨으면 좋겠습니다.
▶ <꿈의 직장 ‘네카라쿠배당토’> 시리즈 보러 가기
CREDIT
김수진ㅣ객원 에디터
발행일 2022.02.10
Q&A
1. 작은 회사라서 인프라를 경험할 수 있는 기회가 없을 경우 이직밖에 답이 없을까요?
작은 회사라도 충분히 성장할 수 있습니다. 회사 자체에서 배우는 것이 한정적이라면 개인 시간을 들여야 하거든요. 이 경험을 시뮬레이션하는 방법은 간단해요. 라인 엔지니어링, 당근마켓 블로그 등 여러 회사의 기술 블로그에 과정과 방향을 정리한 문서를 참고하는 거예요. 거기에는 아키텍처가 있고, 키워드가 있어요. 그럼 키워드를 찾아 케이스 스터디를 하면 돼요. 직접 정리하고 공부할 수 있는 거죠. 유튜브 같은 곳에서 키워드와 함께 ‘딥 다이브’라고 검색하면 좋은 내용들이 많이 나오거든요. 그런 것을 보면서 공부하면 좋아요. 중요한 것은 찾아서 공부해야 한다는 점이에요.
2. 3년 차 서버 개발자인데 앞으로의 개발 공부 방향에 대해 궁금해요.
제가 이 질문의 케이스를 두 가지로 나눠봤어요. 먼저 회사에서 성장하고 싶은지, 그리고 이직하고 싶어서 성장하고 싶은지 생각해야 할 것 같아요. 만약 회사에서 더 좋은 자리를 잡고 싶다고 하면 회사에 존재하는 것에 대해 더 공부해야 해요. 회사 시스템을 더 정확하게 이해하는 게 우선인 거죠. 그런데 내가 이직하고자 하는 회사에서 사용하는 것이 다른 분야라면 그 분야에 대해 공부하고, 준비하는 거죠.
3. 대용량 트래픽 분산처리의 해결 과정이 궁금해요.
명확하게 대용량 트래픽 분산처리가 필요한 상황에 대해 정의해야 해요. 필요한 요소가 어떤 건지, 특정 서비스에서 발생하는 건지, 전반적으로 모든 서비스에서 발생하는 건지 알아야 해요. 만약 특정 서비스에서 발생한다면 서비스를 분리할 수 있어요. 결국에는 대용량 트래픽 분산처리의 꽃은 캐싱이라고 생각하거든요. 만약 자세히 공부하고 싶으면 유튜브에 ‘AWS cache me if you can’이라고 검색하면, 캐싱이 어떻게 이뤄지는지, 캐싱 레이어들이 어떻게 이뤄져 있는지 공부할 수 있을 거예요.
4. 회사마다 요구하는 기술 스킬이 제각각이라 준비하기 힘들어요.
한두 개만 집중해서 준비해야 하냐 말아야 하냐에 대한 이야기는 정답이 아니라고 생각해요. 참고하실 수 있도록, 제가 준비했던 과정을 공유드릴게요. 먼저 제일 가고 싶은 회사 하나를 정하고 이 회사를 준비해요. 그런데 이 회사와 비슷한 스택의 회사들이 있어요. 그럼 그 회사들을 연습게임으로 두는 것 같아요. 수능을 보기 전에 모의고사를 보잖아요. 그런데 모의고사가 없으면 수능을 잘 보기 힘들잖아요. 그래서 이 회사를 깊게 준비하기 위해 비슷한 회사를 찾아 면접을 보는 거죠. 그래서 하나를 깊게 준비하는 것을 추천드려요.
5. 사이드 프로젝트를 진행하고 깃헙에 올리고 있는데 예전 코드를 보면 부끄럽기만 합니다. 깃헙에 올린 코드를 지금이라도 시간을 들여 리팩토링하는 것이 신입 개발자로서 어필이 될까요? 그리고 리팩토링에 참고할 만한 대표적인 소스는 어떤 게 있을까요?
저도 부끄러운 코드가 있죠. 그런데 그렇다고 해서 옛날에 짜둔 코드를 수정하지 않아요. 왜냐면 그것도 제 역사거든요. ‘옛날에 이렇게 했는데 지금은 더 잘 짜고 있어요’라는 걸 보여줄 수 있는 과정이거든요. 새로운 프로젝트를 하시면서 개선된 코드를 보여주는 게 낫다고 생각합니다.
6. 현재 주니어에서 시니어로 넘어가는 시점입니다. 시니어 개발자로 성장하기 위해 어떤 것들이 필요한지 궁금합니다.
‘프로젝트를 처음부터 끝까지 정확하게 설계하고 이 일정에 차질 없게 진행할 수 있는가?’가 시니어 개발자의 기준인 것 같아요. 시니어는 이 사람을 적재적소에 투입하고, 머릿속에 릴리즈 데이트 이전까지의 여정이 처음부터 끝까지 저절로 그려져야 되거든요. 저도 그 과정에 있다고 생각하고, 그 목표를 향해 나아가고 있습니다.
7. 취업, 이직 준비생으로 책이나 페이퍼로 공부하고 있는데 이런 것들은 어떻게 어필하면 좋을까요?
뭐든지 사용자 입장에서 생각해야 되거든요? 이력서를 보는 사람이 편하게 볼 수 있도록 하는 것이 중요한 것 같아요. 개인 블로그에 정확한 제목과 목표, 상세한 내용을 적고 트러블슈팅까지 정확하게 정리하는 것이 좋은 습관인 것 같아요. 개인 블로그를 준비하고 있다면 면접 전에 그 블로그를 보고 이 사람을 판단할 수 있는 거죠. 면접관에게 쉽게 접근할 수 있는 길을 열어주는 것이 중요하다고 생각합니다.
8. 현재 직무와 스킬셋이 다른 짧은 경력도 이력서에 기술하는 게 좋을까요? 혹은 너무 짧아서 마이너스 요인이 될 수 있으니 적지 않는 것이 좋을까요?
짧은 경력이 기준이 되는 것은 아니고, 내가 정확하게, 깊게 아는 것이 아니라면 이력서에서 빼는 것을 추천합니다. 오히려 바닥이 드러나는 과정일 수도 있거든요 “어디까지 해봤어요?”라는 질문을 받았을 때 “써봤어요”라고 대답하면 면접관은 더 이상 질문할 것이 없거든요. 그래서 정확하게 알고, 고민해보고 할 말이 있는 것을 이력서에 적는 게 맞다고 생각해요.
9. 번아웃이 왔을 때 어떻게 극복하셨나요?
저는 번아웃이 온 적이 없어요. 그런데 번아웃이 아니라 ‘힘든 시간’, 그리고 일하기 싫을 때는 당연히 찾아오는 것 같아요. 번아웃이라는 말에 집중하면 더 번아웃에 빠지는 것 같거든요. 개인적으로 번아웃은 ‘안 하기 위한 핑계’라는 생각이 들어요. 하기 싫을 때는 진짜 안 하고, 하고 싶을 때 다시 돌아와 보고, 누군가와 충돌이 있어서 잘 안 된다 싶을 때는 그때 멈추고 느슨한 상태에서 다시 이야기하고, 그렇게 하는 것 같아요. 번아웃은 누적돼서 해결이 안 됐을 때를 말하는 것 같은데 일이 어차피 진행되지 않고 있는데 번아웃이라는 단어에 집중하지 않는 게 정답이라고 생각해요. 번아웃을 피하기 위해 놀러 나가는 자유로운 해결 방법을 추천합니다. 힘든 시간은 있지만 번아웃은 오지 않았다고 생각해요.
10. 서버 개발자를 꿈꾸는 사람인데, 중고 신입에게 필요한 게 자격증 같은 지식적인 부분인지, 토이 프로젝트 같은 경험일지요. 우선순위를 정해야 한다면 어떤 것에 집중해야 할까요?
지식이라고 하면 너무 광범위하고, 토이 프로젝트라고 하면 하나의 카테고리화된 영역에 대해 토이 프로젝트를 진행하잖아요. 그럼 그 카테고리의 영역에 대해 토이 프로젝트를 진행하면서 지식을 쌓아올린 다음에 면접에서 잘 이끌어내는 것이 중요한 것 같아요. 면접에서 잘하는 영역을 질문받으면 강점이 드러나는 것이고, 못하는 것을 적어두고 질문받으면 단점이 드러나는 거잖아요. 장점을 드러낼 수 있게 작전을 짜는 거죠. 지식을 쌓아뒀다고 해도 면접관들은 이 사람이 지식을 얼마나 가졌는지 몰라요. 그것을 증명할 만한 단서를 주는 거죠. 저는 그걸 토이 프로젝트라고 생각해요.
11. 서버 코드 작성을 주로 하다 보면 인프라 모니터링에 대한 경험이 적습니다. 여기에 대한 경험을 간접적으로 쌓을 수 있는 방법이 있을까요?
모니터링은 선택이 아니라 필수고요. 모니터링에 대해 더 딥하게 설명하면 모니터링이 인프라 레벨에서의 모니터링이 있고, API에서의 모니터링이 있고, 어플리케이션 로직 내에서의 모니터링이 있어요. 그것들을 하나하나 할 줄 알아야 해요. 컴퓨팅 리소스 자원에 대해서 어떻게 모니터링하는지, 클러스터에서 인스턴스 전체 흐름에 대한 모니터링을 해야 하고, APM 모니터링도 봐야 하고 이것들을 전부 해야만 저희가 서비스에서 문제 지점을 빠르게 파악하고 개선할 수 있어요. 그래서 선택이 아니라 필수라는 점을 염두에 두고 성장하셨으면 좋겠습니다.
▶ <꿈의 직장 ‘네카라쿠배당토’> 시리즈 보러 가기
CREDIT
김수진ㅣ객원 에디터
발행일 2022.02.10