백엔드 개발자들은 어떤 고민을 하고 있나 ? - 백엔드 개발자 모임에서 나온 개발자들의 고민들

---

목차

 

 

💭 백엔드 개발자 모임에서 나눈 대화 정리하기

지난번 포스팅(백엔드 개발자 놀이터 모임 준비 및 후기)에 이어서, 모임에서 나누었던 이야기를 정리해보려고 한다. 벌써 한 달이나 지난 일이라 가물가물한데... ㅋㅋ

 

생각보다 많은 얘기를 나누었던 것 같아서 주제별로 나열해 보면서 기억하면 기억나지 않을까...? ㅋㅋ

 

일단 백엔드 개발자 모임에서 나눌 고민 주제는 아래와 같이 요약할 수 있다.

 

1. 커리어 설계
2. 이직 준비
3. 일의 방식과 조직에서의 역할
4. 기술 스택과 성장 방향

 

추가적으로 이때 모인 멤버는 나까지 총 6명으로 대부분 1~5년 차 백엔드 개발자였다.

1번부터 너무 큰 주제여서 2번 이직준비부터 대화를 진행했다.

 

 

*(참고) 이번 모임은 서로의 고민을 공유하고 공감하는 목적이었기 때문에 특정 고민에 대한 답을 구하는 자리는 아니었다. 

 

*영상이 편하신 분들을 위한 유튜브 링크

https://youtu.be/IKgFvcOTsYE

 

 

🚙 이직 준비

참여자분들중에 3년 차이신 분들이 꽤 많았는데, 이 연차 때 슬슬 이직 생각을 하는 것 같다. 나도 첫회사에서 3년 차쯤~ 이직 준비를 부랴부랴 했던 것 같아서 잠깐 옛날 생각이 났었다 ㅎㅎ

 

왜 3년차일까 생각해 보면, 3년이면 어느 정도 회사에 적응하고, 지금 하는 일에 적응하고 주어진 업무를 쉽게 처리할 능력이 되는 시기다. 그리고 3년 차면 자기가 뭔가 기술적으로나 업무적으로 성과를 내고 싶은 시기인데, 만약 회사에서 주어지는 일이 너무 쉽게 여겨지거나 도전적인 업무가 아닐 경우 (단순한 반복 업무일 경우) 매너리즘에 빠질 수 있는 때다.

 

게다가 3년동안 개발자로 일하면 어느 정도 좋은 회사와 안 좋은 회사 필터링이 가능해지는데, IT 대기업을 가고 싶은 욕망이 뿜뿜 하는 시기다. 보통 첫회사가 IT 대기업(흔히 네카라쿠배 뭐시기..)이라면 이 시기에 이직을 덜 하는 것 같긴 하다.

 

이 주제에 대해서 얘기를 나누면서 나온 고민들을 정리해 보면 다음과 같다.

 

참여자 A님 (5년 차 백엔드 개발자) - 어떻게 하면 이직을 쉽게 할 수 있을까? 

이건 이직을 준비하는 개발자라면 누구나 하게 되는 고민이긴 한데, 고민을 공유해 주신 A님은 자기의 사례를 아주 구체적으로 말씀해 주셨다. 참여했을 당시는 이미 이직할 회사에 합격하고, 이전 회사를 그만두신 상태였는데, 이직을 하기 위해 이력서를 몇 십 군데 지원했다고 얘기하셨다. 그리고 서류 합격율이 생각보다 높으셔서 면접을 많이 봤다고 하셨다 ㅋㅋ 몇 %였는지 기억이 잘 안 나는데 25%~30% 정도였던 것 같다. 그래서 다른 참여자분들도 "오 그 정도면 높은데요?!"라고 부러워하셨는데... 이 바닥은 서류 합격이 힘든 게 사실인 것 같다.

 

A님도 역시 IT 대기업을 가고 싶어 하셨는데, 합격하기 정말 힘들다고 하셨다. 면접까지는 갔는데 면접에서 자꾸 떨어진다고 ㅠㅠ

하지만 A님은 면접을 하면서 자기 자신의 부족한 점을 객관적으로 느끼셨다고 한다. "세상에 너무 잘하는 사람이 많다"라고 말하시는 겸손한 태도를 보고 언젠가 꼭 좋은 회사를 가실 수 있을 거라는 생각이 개인적으로 들었다.

 

이직은 3번 정도 해보고, 면접관으로 참여를 해보면서 이직은 쉽게 하는 방법에 대해서 생각해 본다면, 역시 제일 쉬운 것은 인맥이다.

나 역시 지금 회사에 추천으로 들어왔기 때문에 추천의 힘이 강하다는 것을 알 수 있다. 

 

회사 입장에서 전혀 모르는 사람을 검증하여 뽑는 것보다는 아는 사람을 뽑는 게 더 이득이다. 이미 누군가에게 검증된 사람이기 때문이다. 이래서 레퍼체크가 중요함 ㅇㅇ

 

그럼 인맥은 어디서 구하는데?라고 질문할 수 있는데, 가장 쉬운 건 좋은 대학을 나오는 것. 스카이정도 나오면 학교 인맥으로 좋은 회사에 들어가기 쉬운 것 같다. 물론 학교 생활을 잘해서 동기나 친구들을 잘 사귀었다면 말이다. 

 

하지만 대학은 이미 과거이기 때문에, 현재에 인맥을 쌓을 수 있는 방법은 무엇일까? 네트워킹 모임을 나가면 된다. 인터넷에 개발자 모임이나 네트워킹이라고 검색하면 많은 모임이 존재한다. 개인이 주최하는 것보다 회사나 단체에서 주최하는 걸 참여하면 많은 개발자와 교류할 수 있다. 아니면 IT관련 컨퍼런스에 참여하는 것도 방법이다.

 

또 다른 방법은 회사 인맥이다. 이직을 하다 보면 전회사, 전전회사 동료를 통해 또 다른 회사로 이직할 수 있는 경우가 많다. 물론, 평소에 회사에서 좋은 인간관계를 형성해 놓아야지만 가능한 일이다 ^^

 

인맥 말고 이직을 잘하는 방법은 뭐가 있을까..? 하면, 역시나 그냥 개발을 잘하는 수밖에 없다. 개발을 잘하면 딱 봐도 티가 나고 주변에서 데려가려고 아우성이다. 회사일을 잘하는 건 기본이고 오픈소스에 기여하거나 개인적인 프로젝트를 만들어서 공유하거나 하는 방식으로 잘해야 한다. 회사일만 잘해서는 눈에 띄지 않는다는 점이 중요하다. 따라서 남에 눈에 띄게 개발을 잘하려면 업무 외 시간에 개발을 많이 해야 하는데, 이렇게 되면 거~~~ 의 개인 시간이 없게 된다. 나 같은 경우 취미/특기가 개발이기 때문에 아주 운이 좋은 케이스이긴 한데, 이런 경우가 아니라면 개인의 모든 시간을 개발에 쏟아야 하기 때문에 삶이 힘들게 느껴질 수 있다. 하지만 그 정도 노력은 해야 좋은 데 가지.. 노력하지 않고 좋은 데 가려고 하는 건 너무 욕심인 것 같다. (극 T 발언..)

 

이직/면접에 대한 마음가짐

이건 그냥 이직 관련 얘기를 하다 나온 주제인데, 서류나 면접을 탈락하게 되면 심리적으로 타격이 꽤 크다. 나도 첫 이직하던 시기에는 스스로 일도 잘하고 능력이 빵빵하다고 자만할 때가 있었다. 정말 어디든 갈 수 있을 거라 생각했었는데, 맘처럼 쉽게 되지 않았다. 이곳저곳에서 탈락소식을 듣게 되면 "내가 정말 잘하는 게 맞나?", "나는 그냥 감자인가?", "지금 회사에 익숙해진 거지 내가 잘하는 게 아니었나?" 등등의 많은 생각을 하게 된다. 

 

나는 개인적으로 면접은 운 적인 요소가 많다고 생각하는데, 면접관으로 어떤 사람이 들어가냐, 그 사람의 기분은 어떠냐, 제한된 시간에 나오는 질문의 종류가 무엇이냐 등등 여러 가지 랜덤성이 있는 요소가 면접에 포함되어 있다. 따라서 면접에 떨어진다고 해서 면접자가 부족한 사람이라는 생각은 잘 안 하는 편이다.

 

내가 항상 말하는 것은 면접이란 면접관과 면접자가 서로 평가하는 자리로, 면접관은 면접자에 대해서 같이 일하기 좋은 사람인지 판단하고, 면접자는 면접관을 보면서 일하기 좋은 회사(or 팀)인가를 확인하는 자리다. 절대로 일방적인 평가자리가 아니라고 생각한다. 면접관을 통해 이 회사가 정말로 내가 일하기 좋은 회사인지 판단하는 것도 면접자의 일이라고 생각한다. 면접에서 좋은 결과가 있더라도, 면접관이나 면접태도 등이 마음에 들지 않는다면 가지 않는 게 좋다고 생각한다. 연차가 많을수록 이런 생각을 많이 하는지, 최종 면접까지 합격해도 회사에 오지 않는 사람이 많은 것 같다. 역시 이런 게 경험에서 나오는 지혜인가..?

 

 

 

내 고민 - 면접자에 대한 배려의 선은 어디인가

이건 내 고민 ㅋㅋ 이직이라기보다는 면접에 대한 내용이다. 4~6년 차 개발자를 뽑기 위해 면접관으로 들어갔을 때 얘기인데, 지원자는 카카오에서 핵심 도메인을 담당하는 팀의 개발자였다. 기술적으로 특출 난 분은 아니었지만 열정이 넘치고, 대외 활동을 열심히 하시면서 개발에 대한 욕심이 많은 분이었다. 면접 진행 후 참여한 면접관끼리 면접자에 대한 판단을 내리는 시간을 가졌는데, 나는 연차대비 괜찮은 사람이라고 생각해서 'YES'로 판단했다. 같이 면접관으로 참여했단 다른 팀원은 "NO"로 판단했는데, 그 이유를 들어보니 "우리 회사처럼 보수적인(금융회사) 회사에서는 저런 열정이 오히려 독이 될 수 있다. 하고 싶은 게 많은데 할 수 없다면 지원자분 입장에서도 장기적으로 보면 손해다"였다.

 

나는 여기서 머리 위에??? 가 떴는데, 면접관으로 판단해야 하는 것은 면접자의 자질이지 그 사람이 회사에 들어와서 어떤 생활을 할지 미래를 평가하는 것은 아니라고 생각했기 때문이다. 그래서 지원자가 어떤 생각을 가지고 있는지도 모르고, 그런 상황에서 어떻게 대처할지도 모르고, 어떤 사람인지도 모르는데 거기까지 걱정하는 건 배려가 아니고 기만 아닌가라는 생각을 했다.

 

이 사례를 얘기하면서 참여자 분들에게 (마침 참여자 분들이 비슷한 연차였기 때문에) 물어보았는데, 나와 동일한 생각을 가진 분들도 있고 다른 생각을 가진 분도 있었다. 참여자 중 B님은(3년 차 백엔드 개발자) "합격하게 되면 같이 일하게 될 팀원인데 그렇게 고민해 준 것에 감사하다"라고 얘기해 주셔서, 그렇게 생각될 수도 있겠구나라고 고개를 끄덕였다. 그래도 만약 내가 그 지원자였으면 나에 대해서 잘 모르면서 그렇게 판단하는 건 오만이라고 화났을 것 같다. 사람의 생각이란 게 다양하는 것을 한번 더 깨닫는 중.. ㅋㅋ 

 

 

🤝 일의 방식과 조직에서의 역할

참여자 B님 (3년 차 백엔드 개발자) - 회의를 너무 많이 해서 제가 개발을 하는 사람인지 회의를 하는 사람인지 모르겠어요

 

이 고민을 들었을 때, "와.. 옛날에 나도 저 고민했었는데"라는 생각이 제일 먼저 들었다. 근데 옛날이라고 말한 거 보면 지금은 고민을 안 한다는 건데- ㅋㅋ 

 

B님 공유해 주신 고민에 구체적인 내용은 의사 결정이 잘 안 돼서 똑같은 회의를 반복하느라 시간을 허비한다는 것이었다. 회의가 문제라기보다는 회사 문화가 문제인 것 같아 보였다. 일단 B님은 의사 결정에 권한이 없는데, 계속해서 회의를 끌려다니느라 고생하는 것 같았다. 그렇다고 안 갈 수도 없는 회의인 것 같아 무조건 가긴 가야 하는데, 회의의 결론이 잘 안 난다는 것이 문제.

이런 건 답도 없는 회의라고요~!

 

이런 고민에서 어떤 회의인지 구분하는 것이 중요한데, 위처럼 답도 없는 회의면 개인이 어떻게 해결할 수 있는 문제는 아닌 것 같다 ㅋㅋ 그럼에도 불구하고 그 상황에서 내가 어떤 것을 해야 더 나은 방향으로 갈지 고민하는 것이 최선인 것 같다. 뭐 다른 의사결정자를 찾는다던지, 의사 결정자가 잘할 수 있도록 회의 시간 말고도 딱 달라붙어서 이것저것 물어보면서 준비할 사항이 있다면 준비하던지 등등.. 

 

반대로 그냥 개발자가 참여하는 회의가 많은 거라면 약간 다른 시선으로 바라보아야 한다. 나도 옛날에는 개발자는 회의보다는 개발을 더 많이 하는 게 좋다고 생각했다. 그런데 최근에는 개발자도 회의를 많이 해야 한다는 것을 조금씩 느끼는 중인데, 그중 하나는 영향력이다. IT회사에서는 개발자가 프로젝트에 중심에 서는 경우가 많다. 물론 리딩은 PM이 하겠지만, 특정 기능에 대한 개발 가능여부나 일정은 개발자에 더 포커싱 되어있다. 따라서 개발자가 회의에 참여하여 기능에 대한 리뷰나 일정관리등에 적극적으로 참여해야 일이 쉽게 진행된다. 전통적인 대기업 같은 경우는 수직으로 일이 할당되기 때문에 이런 일이 별로 없는데, IT기업들은 회의를 참여하는 개발자가 필요하다. 심지어 개발자들끼리 회의할 때도 많다 ㅋㅋ 

 

이렇게 개발자가 회의를 많이 참여하여 개발적인 생각 등을 공유하게 되고, 그 효과로 프로젝트가 잘 진행된다면 개발자로서 영향력이 쌓이게 된다. 여기서 영향력이란 쉽게 설명해서 내 말을 다른 사람들이 기꺼이 들어주게 되는 힘 같은 건데 신뢰라고 생각하면 편할 듯하다. 영향력이 높은 개발자라면 문제가 발생하거나 중요 이슈사항이 생겼을 때 사람들이 도움을 청하러 오는 경우가 많아지고, 프로젝트에 더더욱 중심에 서게 된다. 최근에 시니어 개발자의 요건 중에 이런 영향력 항목이 있는 것을 봤던 것 같은데, 회의를 많이 다니면서 자신의 개발적인 능력을 다른 동료들에게 어필하게 된다면 자연스럽게 영향력이 상승하게 되는 것 같다. 물론 개발 실력이 느는 건 아니긴 한데, 요즘은 개발 실력만 가지고 개발자를 판단하지 않으니 ㅋㅋ 

 

영향력 외에 또 다른 이유는 개발의 방향성을 정하기 위해서다. 회의에 참여하여 어떤 의도로 어떻게 일이 진행되고 있는지 파악해야 개발할 때 요건에 맞게 개발할 수 있게 된다. 'XX 만들어주세요'보다는 '이번에 법이 바뀌어서 새로 만들어야 하는 게 생겼는데, 기존 거에 보완해서 XX를 만들어주세요"로 좀 더 구체적으로 알고 있다면, 개발하기 전에 좀 더 알맞은 설계 및 구조로 개발을 할 수 있다. 혹은 내가 개발하기 편한 방법으로 프로젝트를 드리블할 수도 있다. ^^

 

아무튼 연차가 쌓일수록 개발자도 비개발적인 업무를 잘해야 편하다는 경험이 쌓이게 되면서, 회의가 많다고 불평하는 건 없어진 듯하다. 물-론!! 답 없는 회의는 너무 싫다. ㅋㅋ

 

 

개발자에게 조직 내 영향력이란 무엇인가?

 

위에 주제와 연관되어서 나온 질문이었는데, 개발자의 영향력이 중요한가라는 내용이었던 것 같다. (구체적으로 어떻게 이 주제가 시작되었는지 기억 안 남.. ㅋㅋ)

 

나는 일단 '영향력'이라는 단어가 나온 것에 조금 놀랐다. 

 

놀란 이유는 최근에 회사에서 '시니어 개발자의 조건'을 한번 얘기한 적이 있는데, 시니어 개발자라면 이런 스킬이 있어야 한다!라는 느낌의 내용이었다. 시니어 개발자가 가지고 있어야 하는 역량 중에 '영향력'이 포함되어 있었다. 영향력이란 무엇인고 하니, 업무를 진행하는 데 있어서 다른 직무의 사람들이 얼마나 개발자를 의존하는가? 의사결정에 얼마나 영향을 주는가? 정도로 생각하면 되겠다. 

 

평소에 '영향력'이라는 것을 몸소 체험하고 있긴 하지만, 이것이 '영향력'이다!라고 정의해서 의식하고 있지는 않았는데, 시니어의 필요 요건 중에 하나라는 얘기를 들었을 때, '음 그럴 수도 있겠다~'라고 생각했다. 영향력이 없으면 개발자가 의도한 대로 개발하게 되는 경우가 적어지며 일도 힘들어지고, 구조도 복잡해질 수 있다. 물론 개발을 잘한다는 베이스가 깔려있어야 하지만 ^^ 시니어면 잘하겠지~

 

암튼, 이렇게 시니어 레벨에서 고려하는 것을 이번에 모인 1~5년 차 개발자 분들이 벌써 생각하고 있는 것에 놀랐다!!

 

대체적으로, 주니어 레벨에서는 영향력을 챙기기보다는 개발 자체에 집중하는 개발자들이 많은 것 같다. 나 역시 개발만을 추구하던 때가 있었는데, 회사생활 하다 보니 개발보다 도메인이나 회의, 대인관계 등 전체적인 것이 중요하다고 느껴서 다방면으로 열심히 하려고 노력하고 있다. 

 

사실 주니어가 영향력을 갖는다는 것은 특별한 상황인 것 같다. 영향력을 갖기 위해서는 진행하는 개발업무에 대해 의사결정권이 있어야 하는데, 일반적인 회사에서는 주니어에게 그런 권한을 주지 않는다. 하지만 IT회사처럼 직급체계가 없는 개발자 중심의 회사라면 얘기가 달라진다. 이런 회사에서는 주니어라도 특정 업무를 리딩할 수 있는 기회가 주어지며, 혼자서 업무에 대한 의사결정을 할 수 있는 권한도 제한적으로 주어진다. 

 

이런 상황이 주어지면 어떤 개발자들은 스트레스를 받을 수도 있을 것 같다. 아직 많은 경험이 없기 때문에 의사결정 하나하나가 힘들 것이다. 차라리 개발만 하고 싶다!라는 생각이 들기도 한다. 하지만 나는 이런 상황이야 말로 개발자로서 성장할 수 있는 기회라고 생각한다. 부족한 경험을 어떻게 해서든 메꾸려는 노력을 하면서 얻는 게 많아지게 되는 시기인데, 사수나 멘토를 붙잡고 늘어지면서 자기 생각을 말하며 조언을 구하며 돌아다니는 것이다. 이때 중요한 것은 판단은 자신이 해야 한다는 것.

 

물. 론. 본인의 역량을 본인이 판단해서 아 이 정도는 내가 할 수 있겠구나~, 이건 못하겠구나~ 객관적인 판단을 하는 게 제일 중요하다. 시니어도 어려운 의사결정을 끙끙 앓고 있으면 역효과이기 때문이다. 

 

얘기하다 보니 이도 저도 아닌 이상한 의견(?)이 되어버렸는데 그래서 어떡하라는거냣!! ㅋㅋㅋ 

그냥 ^^ 이런 고민을 한다는 것 자체가 개발자로서 성장하고 있다는 증거니까,, 잘하고 있다고 얘기해주고 싶은 거다. 답은 스스로 구해야지~ ㅋㅋㅋ

 

 

회사에서 요구하는 개발자, 내가 바라는 개발자

 

이것도 겸사겸사 나온 주제인데, 회사에서 요구하는 것과 내가 하고 싶은 것의 차이를 느낄 때 어떻게 해야 하는지에 관한 주제였다.

 

이건 정말 어떤 회사냐, 어떤 팀이냐, 내가 어떤 생각을 가지고 있느냐에 따라 수많은 케이스가 생기는 경우라서 아마 모든 사람이 다르게 느끼는 문제가 아닐까라고 생각한다. 

 

예를 들어 참여자 중에 어떤 분은 회사에 조직구조가 계속해서 변하고 있어서 자신의 Role이 계속 바뀌는 것에 대해 고민이라고 말씀해 주셨다. 아직 조직이 어떤 방향으로 나아가야 할지 확실하게 정해져 있지 않아 이것저것 시도해보고 있는 것 같은데, 그 변화에 중심에 있는 것 같았다. 보통 이렇게 회사 차원에서 움직이는 거는 개인이 어떻게 해볼 도리가 없다고 생각되는데, 그렇다고 그냥 회사가 하라는 대로 따라가는 게 좋은 것인지.. 딜레마이긴 하다.

 

나는 일단 개인적으로는, 내가 하고 싶은 것을 할 수 있는 곳은 내가 만든 회사밖에 없다고 생각한다 ㅋㅋ 아무리 개발 문화가 좋고 일하기 좋은 회사라고 해도, 이건 불변인 것 같다. 내 회사가 아닌 이상 내 맘대로 할 수 있는 건 없다. 어떤 사람은 회사에서 일할 때는 생각을 하지 말라고도 한다 ㅋㅋ 

 

근데 두 가지 사이에서 고민하는 개발자들을 보면 책임감이 매우 강한 사람들이 대부분이었다. 자신이 진행하는 업무에 대한 책임감이 강하여 잘해보려고 하는데, 회사에서 반대로 요구하거나, 전혀 다른 방향을 요구하기 때문이다. 이런 상황에서 스트레스를 받으면서 현타가 오는 분들을 많이 봤다. 

 

나는 일단 객관화를 매우 잘하기 때문에 회사일은 회사일이라고 생각하면서 회사에 요구사항에 최대한 맞추려는 태도를 가지고 있다. 물론 내가 원하는 방향도 있지만, 실제 책임자는 회사이고 임원이고 내 상사이기 때문에, 내가 공식적으로 책임지는 것이 아니면 웬만해서는 회사의 의견에 따르려고 한다. 이게 좋은 것은 아니지만 적어도 스트레스는 안 받는다. 

 

근데 그렇다고 아예 순응해 버리면 안 된다. 그냥 회사와 나의 의견이 다르구나~ 정도로 다름을 인식하는 정도지, '회사가 옳다!' 이거는 아니다. 요즘 개발자는 한 곳에 오래 머무는 것도 아니고, 언제까지 회사에서 근무하는 것도 아니다. 언젠가 이직을 하고, 또 창업을 할지도 모른다. 즉, 언제까지 내가 시키는 대로만 해서 돈을 벌 수 있는 환경이 아니기 때문에 스스로 판단해 보고 의사결정 해보는 것이 중요하다. 그러므로 회사의 요구사항은 일단 그 회사에서 일하니까 받아들이고, 만약 내가 이렇게 한다면 어떨까? 상상의 나래를 펼쳐보거나 좀 더 딥하게 파고들어서 결과를 예측해 보거나, 실제 일이 끝나고 결과도 내가 원했던 방향의 결과와 비교해 보면서 최대한 얻을 수 있는 것을 얻는 게 중요하다. 

 

물론, 제일 좋은 건 내가 바라는 방식으로 일할 수 있는 회사를 가는 것인데, 그건 현실적으로 매우 힘들다 ^^. 하지만 언젠가 이루어질 수도 있으니 유연한 개발자가 될 수 있도록 준비하는 게 좋을 것 같다.

 

 

 

📚 기술 스택과 성장 방향

백엔드, 프론트, 풀스택

이 주제는 진짜 어느 개발자를 만나도 항상 핫한 주제가 아닐까 싶다 ㅋㅋ 

 

일단 주제의 시작은, 참가자 분들 중 본의 아니가 프론트까지 개발하고 있어서 너무 고민이라는 질문이다. 백엔드 개발자로 취업했지만, 어쩔 수 없이 프론트까지 하는 경우가 많긴 한데, 이런 경우는 어떻게 해야 하나.

 

이런 질문을 만나면 나는 일단 '회사에 얘기는 해 보았는가?'라는 질문을 가장 먼저 한다. 사실 이 질문은 어디까지 노력해 보았는가? 를 확인하기 위한 질문인데, 생각보다 많은 개발자들이 회사나 팀장, 상사에게 얘기해보지 않고 이런 불만을 갖고 있다. 즉, 본인이 어떻게 상황을 바꿔보려는 노력도 하지 않고, 그냥 불평만 하고 있는 것이다. 이런 분들을 만나면 일단 노력하고 얘기한다. 노력하지 않는데 좋은 상황을 기대하는 건 조금 욕심 아님?

 

근데 또 그렇다고, 말해서 그렇게 쉽게 바뀌는 문제는 아니다. 사람이 적은 중소기업이나 스타트업의 경우 개발자 뽑기가 힘들어서 한 사람이 두 가지 모두 하는 경우가 많은데, 회사입장에서는 아주 귀한 인재다. 이렇게 사정상 어쩔 수 없이 해야 한다면, 적어도 그 대접은 받아야 한다 라는 게 내 논리이긴 한데, 예를 들어 월급을 더 올려 받는다던지, 업무 시간을 좀 더 자유롭게 한다든지 자신이 챙길 수 있는 게 있는지 확인해서 받아내야 한다. 

 

또 하나의 방법은 그냥 즐기는 거다. 내가 이런 부류긴 한데, 나는 프론트도 잘하고 싶다 ㅋㅋㅋㅋ ㅋㅋ 프론트 잘하면 혼자 뚝딱뚝딱해서 서비스 만들 수 있자네?!

 

근데 나는 어느 정도 연차가 쌓여서 그렇게 생각하는 걸 수도? 한쪽만 해도 배울 게 많은데 두 개를 동시에 하긴 힘들 수 있다.

 

그래서 일단 회사에 얘기한다 -> 긍정적으로 생각해 본다 -> 이직 이 순서로 해결해야 하지 않을까? 싶음 ㅋㅋ 

 

 

깊이와 넓이 중 어디에 집중할 것인가? 

 

이 주제도 당골이긴 한데, 깊이 vs 넓이의 싸움이다. 물 ~ 론 ~ 깊고 넓은 게 최고이긴 한데 ㅋㅋㅋ 그게 되면 그렇게 하고, 하나만 집중했을 때 어떤 걸 선택하냐~ 의 질문이다. 

 

음.. 나는 깊이가 더 좋다고 생각이 들긴 하는데, 일단 특정 기술에 대해 깊이 파고드는 노력치와 넓게 알려고 하는 능력치가 조금 다른 것 같다고 생각된다. 한 기술에 대해 깊게 파고들려면 집중력이나 이해력이 필요하다고 생각되는데, 넓게 아는 건 포용력(?) 적용력(?)이 필요하다고 생각된다. 여러 가지를 넓게 알기 위해서 제일 쉬운 방법은 원래 아는 지식과 비교해서 배우는 것. 즉 귀납법적인 사고방식이 필요하기 때문에 한 가지에 대한 전문지식을 배우는 것과는 다른 노력이다.

 

그래서 나는 우선순위를 둘 때, '깊이'를 더 높게 두고 싶다. 한 가지 기술에 깊이 파고들 때, 그 기술에 대한 이해도만 올라가는 것이 아니라 개발 전체적으로 이해도가 올라가게 된다. 이 상태에서 다른 기술들을 접하게 되면, 내가 알던 기술에 대한 이해도 덕분에 비교하면서 더 쉽게 다가갈 수 있다. 

 

간단하게 예를 들면, C언에서의 기본 입출력은 printf, scanf인데, 이 메서드를 안다면 다른 언어-자바나 파이썬-을 공부할 때 system.out.println이나 print 등을 쉽게 이해할 수 있다. 이건 개발 도메인 한정이 아니라 모든 것이 다 그런 것 같다. 영어를 공부할 때 우리가 일일이 한국어 뜻으로 생각하면서 공부하는 이유도 이거다. 일단 한 가지 언어를 하면 그 언어와 매핑시켜서 배우면 된다. 

 

물론 이건 내생각인 거고, 반대로 넓게를 먼저 알고 깊게 가는 방법도 있을 것 같다. 여러 가지를 알고 그것으로 더 깊은 지식을 찾을 수도 있으니까. 이건 그냥 사바사인 듯? 자기가 편한 대로 고르면 될 것 같다.

 

무튼, 두 개중에 선택하는 게 아니라, 하나만 하면 다른 하나는 따라오게 되는데, 본인이 쉬운 길을 선택하면 될 것 같다는 게 내 의견~!

 

기술 전환기에 겪는 어려움

 

개발자로 살다 보면 본인이 원하지 않게 사용 중인 기술 스택이 변경되는 경우도 있고, 본인이 바꾸길 원해서 바꾸고 싶은데 그렇게 안 되는 경우가 있다.

 

첫 번째 경우는 그나마 나은데, 두 번째 경우가 좀 힘들 수 있다. 나도 처음에 C언어를 사용하는 회사에서 5년 있다가 다른 거 하고 싶어서 결국 이직으로 스택을 바꾸는 데 성공했다. 

 

바꾸기 힘들었던 이유는 일단 C로만 개발되어 있는 회사에서 일하기 때문에 언어 바꾸기 힘듦. 그렇다고 이직을 하자니 C만 5년 했는데 C를 안 쓰는 회사에서 나를 뽑을 이유가 없음 ㅎㅎ 

 

다행히 나는 간간히 다른 언어로 된 프로젝트를 개인적으로 진행한 것이 있고 공부를 꾸준히 해와서 이직에 성공할 수 있었다. 물론 메이저 회사로는 이직하지 못하고 도메인이 맞는 스타트업으로 이직했고, 그 후에는 이직이 조금 수월해졌다. 

 

반대로 어떤 경우는, 본인은 계속하고 싶은데, 외부에 의해 바뀌는 경우다. java를 열심히 공부하면서 배우고 있었는데, 어느 날 갑자기 회사에서 '저희는 이제 go를 씁니다'라고 한다면..? java 공부 때려치우고 go를 해야 하나? 아니면 java를 쓰는 다른 회사를 가야 하나?

 

만약 내가 같은 경우라면 내 상황을 한번 생각해봐야 할 것 같다. 만약 내가 아직 주니어고 연차가 높지 않다면, 나는 java를 쓰는 다른 팀이나 다른 회사로 옮기는 선택을 할 것 같다. 왜냐하면 한 가지 기술에 대해 어느 정도 수준에 도달하지 않았는데, 다른 것을 하는 것은 그냥 리셋되는 것과 똑같다고 생각하기 때문이다. 

 

반대로 내가 연차가 좀 된다? 그럼 오 땡큐~ 하고 새로운 것을 받을 것 같다. 그리고 연차가 좀 돼서 개발 경력이 높다면, 금방 금방 다른 것을 할 수 있다고 생각된다. (이미 이것에 대해 깊이 vs 넓이 주제에서 얘기했다)

 

그렇다고 기술을 전환하는 것이 쉽다는 것은 아니다. 새로운 것을 배우는 것은 항상 어렵다. 하지만 내 상황에 따라 그것을 어떻게 받아들이는지가 차이가 있을 뿐이다. 머리 뜯어가며 이 악물고 이해해야 하는지, 아니면 조금 더 여유롭게 배우던지 차이 ㅋㅋㅋ 

 

일단 본인이 어느 정도 노력할 수 있는지 판단하고, 최선의 선택을 하는 수밖에 없을 듯? 

일단 제일 좋은 건 초기에 대중적인 기술을 고르고 그 기술로 어느 정도 경력을 쌓기까지 계속하는 것이다. 운이 좋아야겠지만 ^^...

 

 

 

 

👨‍💻 커리어 설계

 

자 커리어 설계.. ㅋㅋ 여태까지 나누었던 얘기를 총 정리하는 시간이라고 보면 된다.

 

'나는 어떤 개발자가 되고 싶은가?'

 

일단 대부분의 개발자가 이 고민에서는 개발을 계속할 것인지, 아니면 매니저로 빠지는 게 좋은지 선택지를 고민한다. 나도 평소에 많이 고민하는 부분인데, 사실 이건 개인의 선택보다는 외부에 의해 결정되는 경우가 많다. 개인이 할 수 있는 것은 그것을 감당할 수 있는지 정도?

 

즉 주제를 바꾸면, 매니저 하라고 하면 할래?로 바꿀 수 있을 것 같다 ㅋㅋ  

 

나는 옛날에는 개발만 계속하고 싶었는데, 일을 하면서 내가 소프트 스킬이 좋다는 것을 알았고, 잘한다는 것을 알고 나서는 매니저도 할만하겠는데?라는 생각이 든다. 누군가가 개발만 계속하기 위해서는 누군가는 매니징을 해야 하기 때문에 그럴 거면 잘하는 내가 하는 게 낫지~ 이런 생각? 

 

그렇다고 손들고 하고 싶지는 않고 언제가 기회가 되면 하겠다는 생각정도만 하고 있다. 아직 개발이 재밌긴 해서... ㅋㅋ 

 

참여자분들도 대부분 이런 고민을 하고 있었지만, 아직은 그런 선택을 받게 되는 연차는 아니었다. 대부분 어떻게 하면 더 개발을 잘할까의 고민을 하고 있는 것 같았다. 스스로 생각하기에 내 성장을 막고 있는 문제점을 말하셨는데, 대부분 조직이나 팀 얘기가 많았다. 

 

나는 이렇게 하고 싶은데 이 팀에서는 이게 안 돼요. 그래서 이직을 준비하고 있어요.

 

이런 느낌? 

 

개발자로 성장하기 제일 쉬운 방법은 멘토를 찾는 것 같다. 그 멘토가 같은 회사, 같은 팀에 있다면 최고다. 멘토라고 해서 뭐 대단한 사람을 말하는 게 아니다. 배울 게 있는 사람. 하나라도 그 사람에게 배울 게 있다면 멘토로 삼으면 된다. 

 

내가 생각했을 때 이직 타이밍은 배울 게 없는 회사다.

첫 회사를 이직한 이유도 이거였는데, 하루 종일 부동산 보고 있는 과장 보고 현타 와서 이직 ㅎㅎ 

 

훌륭한 스승을 옆에 두는 것만큼 좋은 게 없다고 생각하고, 그런 이유의 이직은 바람직하다고 생각한다. 다양한 회사와 다양한 사람을 경험해 보면 본인이 스스로 어떤 개발자가 되고 싶은지 선택의 폭이 넓어지기 때문이다. 

 

그래서 참여자 분들에게 이직은 많이 해보라고 얘기했던 것 같고, 대신 그 회사에서 얻을 수 있는 건 다 얻고 하라고 말했던 것 같다 ㅎㅎ 

 

 

이렇게 정리하다 보니 '운'이라는 게 새삼 중요하다고 느꼈다. 참여자 분들 중 어떤 분은 원하지 않는데 devops영역까지 해야 하는 분이 있는가 하면, 어떤 분은 devops영역도 하고 싶은데 권한이 없어서 못한다는 분도 있었다. 코틀린을 하고 싶지만 회사에서 안 쓰는 경우도 있고, 코틀린 모르는데 코틀린을 써야 하는 경우도 있다. 

 

그렇다고 운이 전부라고 생각하진 말자. 운 좋게 우리에게 기회가 왔을지 몰라도, 그 기회를 잡을 수 있는 건 우리의 노력이다. 

급 명언으로 마무리.. 🤣

 

 

 

 

 🎬 마무리

 

와.. 그때 어떤 얘기했는지 남긴 게 없어서 가물가물하면서 쓰느라 너무 힘들었다.

이렇게 또 기록의 중요성을 느끼고... 다음부턴 무조건 적어야지. (녹음이라도)

 

아무튼 오랜만에 다른 개발자분들과 소통할 수 있어서 너무 재밌었고, 다음에 또 만나서 얘기를 나누고 싶다는 생각이 들었다. 

 

4분기쯤에 다시 만나서 그날 이후 어떻게 지냈는지 얘기 나누는 모임을 해볼까 한다. 

 

그때는 꼭! 영상, 사진, 기록 남겨야지. 😄

 

 

 

 

 

 

썸네일용 사진 ㅋㅋ