인프런 커뮤니티 질문&답변

질문 감사합니다 :)

음 대용량 트래픽의 경우에 사이드 프로젝트로 해결했다라는 걸 어필하기가 어려울 수 있을것 같아요.
결국 사용자가 없는 상태에서 테스트를 하는 것이라 의도한 대로, 아무런 제약이 없는 임의 트래픽 이라서요.

제가 완전히 동일한 경험을 한 것이 아니라서 개인적인 면접관으로서의 경험을 기반으로 말씀드릴게요!

제가 배민에 있을때 SI/SM 경험만을 가진 7 ~ 10년차분을 1차 기술 면접에서 통과시킨적이 있는데요.

대용량 트래픽 경험이 없지만 통과시켰던 이유는

• 200~300라인의 한번에 실행되는 SQL을 리팩토링 하여 30~50줄의 여러 쿼리로 나누는 리팩토링 (SQL 재활용, 쿼리들 사이사이 로그 추가등을 목적으로)

• 2~3초씩 걸리던 쿼리 성능 개선

• 이펙티브 자바, 클린코드 책들을 보고 작업 완료된 코드들을 주말 내내 리팩토링

• 위 작업들을 모두 블로그에 정리 (실제 회사 코드는 사용하지 않고, 다시 예제코드를 만들어서)

요지는, "척박한 실전 환경에서 얼마나 개선해보려고 노력했느냐" 를 많이 봤었던것 같아요.

사이드 프로젝트로 새로운 기술을 배워보고 할 순 있는데, 실제 사용자가 없는 환경에서는 대용량 트래픽, 데이터처리 등을 경험치로 인정 받기는 쉽지 않더라구요.

왜냐면 아무런 제약 조건이 없는 가장 이상적인 환경, 가장 의도한 환경에서의 테스트였을거라서요.

그래서 사이드 프로젝트로 대용량 트래픽 경험을 쌓으려고 하시기 보다는

서비스 회사에서 사용하는 기술 스택 경험을 사이드 프로젝트로 쌓는게 좀 더 좋을것 같고,

지금 일하고 계신 회사에서 쿼리 튜닝, 테이블 설계, 코드 리팩토링, 개발환경 개선 등을 시도하고 이를 이력서로 쓰시는 것을 추천드립니다 :)

물론 어디까지나 개인 경험이라서 이게 정답이 아닐 수 있습니다.

그래서 가능한 많은 시니어 개발자분들께 여쭤보시고 가장 와닿는 방법을 선택하시면 될 것 같구요 ^^;

저도 같은 게 궁금했어요

질문 감사합니다 리건님! ㅎㅎ
처음 선택할때 몇가지 기준들이 있었는데요.

• 새로 만들지는 않더라도 어느정도 직접 수정할 수 있는 부분이 열려있으면 좋겠다. (GA, Adsense, 커스텀한 댓글, 커스텀 UI 등 가능하도록)

• 통계 등 대시보드가 잘 되었으면 좋겠다.

• SEO가 잘되었으면 좋겠다.

• 모바일앱이 있었으면 좋겠다.

등의 조건들의 교집합이 당시에는 티스토리밖에 없었어요.

계속 쓰면서 불편함이 일부 존재하긴했는데,

티스토리 오픈 API가 지원되어서 이를 통해 자동화나 사용성 개선이 가능했고,

통계 대시보드와 모바일앱이 계속 개선되기도 하더라고요 ㅎㅎ

제가 무언가 액션을 하지 않아도 글쓰기 플랫폼이 계속 되다보니

글쓰기에만 집중할 수 있는 환경을 만들어줘서, 지금까지 계속 쓰게 된 것 같아요 ㅋㅋ

물론 나중에 그동안 블로그 플랫폼 사용 경험들을 모아서 제가 원하는 블로그 플랫폼을 만들고 싶다는 생각은 계속 하고 있습니다 ㅎㅎ

향로님 자세한 답변 감사합니다! ^^

안녕하세요 JUNN님 :)
질문 남겨주셔서 감사합니다.

Q. 향로님 및 호돌맨님께서 생각하시는 그 방향에 대해 다른 시니어 개발자 분들, 그리고 신입을 채용할 계획이 있는 회사의 개발자들 분들이 얼마나 공감할 지 향로님의 생각이 궁금합니다.

A. 음 이건 확실하게 답변을 드리기는 어려운 부분 같아요 :)
모든 시니어들의 생각을 물어본적이 없기 때문이고요.
반대로 저나 호돌맨이 방송에서 하는 이야기들은 딱 저희들만의 생각이라기 보다는, 저희와 이야기하는 다른 시니어분들도 언급하신 부분들이 포함되어있어서 이게 딱 저희만의 생각이라고 하기도 어렵기 때문입니다.
아마도 이 부분은 누구도 확실한 답변을 할 수 없지 않을까 싶습니다 :)
신입분들이라면 각자가 경험한 면접 경험,
채용을 하실 시니어분들이라면 그간 뽑아본 신입 개발자들의 유형에 따라 각자가 생각하는바는 같을 수도 있고, 다를 수도 있을것 같습니다. :)

Q. 신입 개발자가 어필할 수 있는 역량(?)에 대해서도 향로님의 생각

A. 음 방송에서 여러번 이야기했지만, 저는 신입분들이 추상화된 기술에 대해 찍먹해봤냐에 대해서는 가산점을 크게 주지 않습니다.
그리고 가능하면 직접 서버에 배포를 하고, 서비스를 작게라도 운영해본 경험에 대해 많은 가산점을 줍니다.
localhost:8080 에서만 작동하는 프로젝트 보다는 실제로 도메인이 있고 접속 가능한 서비스를 운영 해봤느냐 안해봤느냐가 서버(백엔드) 혹은 프론트엔드 개발자로서 운영 서비스에 대한 이해도가 확 차이가 나던 걸 경험했어서요.
대표적인 사례로 아래 두분의 Github Repository를 참고해보시면 좋을것 같습니다.
- https://github.com/bmm522/quiz-studio
- https://github.com/hongjk7777/score-manager

안녕하세요 우진님 :)
질문 감사합니다.

정말 아쉽게도 인프콘 추가 티켓 계획은 없습니다 ㅠㅠ....

내년엔 더 큰 규모가 되기 위해 노력해보겠습니다...!

저는 우진님이 인공지능 개발자로 지원서를 내느냐 프론트엔드 개발자로 지원하느냐에 따라 다를 것 같다고 봐요.

인공지능 개발자로 지원하신다면 당연히 대학원만으로는 부족하고 더 많은 경험을 이력서에 쌓으셔야할 것 같고요.

여태 해오신 경험이 있는 프론트엔드 개발자로 지원하신다면 인공지능 대학원 재학중인 것은 전혀 패널티는 아니라고 봐요.

그게 패널티로 먹힌다면 그건 현재 우진님의 프론트엔드 역량이 그 연차에 비해 부족할때인것같아요.

3년차, 4년차에 이정도 경험 혹은 실력밖에 되지 않는다고? 라는 생각을 면접관이 하게 되면 그때서야 "대학원때문에 그러신가?" 라고 이유를 추측하실것 같아요.

백엔드가 데브옵스 혹은 프론트엔드를 공부하는 경우처럼 다른 분야의 공부를 하는 경우는 많습니다.

그렇지만 다른 분야를 공부한 것이 내 커리어에 방해가 되는 경우는 주 분야의 실력이 그 연차 대비해서 부족할때입니다.

주 분야의 실력이 뛰어나면, 다른 분야를 공부했다는 것은 오히려 "이 사람은 프론트엔드를 잘하는데 여가시간에 이렇게 다른 분야도 공부하는 사람이구나" 로 생각하게 되죠.

반대로 주 분야의 실력이 부족하면, "자기 분야도 못하는데, 왜 굳이 다른 분야까지 하시는거지?" 라고 생각할 수 밖에 없을것같아요.

그래서 저는 우진님이 오히려 인공지능 대학원을 다니면서 어떻게 하면 프론트엔드 개발 역량도 함께 향상 시킬 수 있을것인가를 더 고민해야하는 게 아닐까 싶어요 :)

정리하면, 인공지능 대학원을 다니는 것은 전혀 패널티가 아니며,

오히려 내 주력 분야인 프론트엔드 역량이 충분하다면 다른 분야로의 공부는 오히려 장점이 될 수 있다고 말씀드리고 싶습니다 :)

향로님 답변 감사드립니다. 많은 도움이 되었습니다!

정리해주신, 대학원을 다니면서 주 분야인 프론트엔드에서도 실력이 부족하지 않도록 조심해야겠어요! 감사합니다!

좋은 스타트업 취업을 목표로 한다는 것 너무 좋습니다 :) 응원합니다!

그 회사의 사업이나 규모등 객관적인 지표를 볼 때는 아래 2가지 서비스를 활용합니다.

• 혁신의 숲

• The VC

그 외에 다른 정보들은 다음과 같은 서비스들에서 제공합니다.

• Exit 경험이 있는 대표, 유명 VC가 투자한 초기 스타트업들의 채용공고 모음

• 초기 스타트업의 제품 커뮤니티 - 디스콰이엇

• 링크드인 (여기서는 해당 스타트업 대표님들의 프로필과 올리신 글들을 보러 갑니다)

   

물론, 저는 인프랩에 합류할때 위와 같은 서비스들을 활용하진 않았습니다 ㅎㅎ

제가 결국 인프랩이 운영하는 인프런 서비스의 지공자였으며, 학생이여서 고객이였거든요 ㅎㅎ

그리고 대표님과의 인연이 2018년도부터 있었기 때문에 어떤 회사이고 어떤 팀인지 알고 있었기 때문에 작은 스타트업이였지만 다른 회사들의 조건들을 두고 선택할 수 있었던것 같아요 :)

어떤 기술들의 변화나 새로운 분야로 뛰어들때 느끼는 학습양의 방대함에 압도되는 것은 커리어 내내 있는것 같아요.

저도 당연히 가지고 있는 부분이고요.

다만, 이게 처음 겪는 경험이냐 아니냐의 차이가 있는것 같아요.

저는 아무래도 그런 압도되는 상황에서 어떻게든 작게라도 한걸음씩 나아가면 결국 더 괜찮은 사람이 된다는걸 몇번 경험하다보니 이제는 그런 걸 조금 즐기는 상황인것 같아요.

익숙해지기 전까지는 다음과 같은 생각들을 했던것같아요.

지금은 잘 기억도 안나지만, 어떤 기자님이 공식 석상에서 많은 기자들이 모여있는 곳에서 유명하신분께 민감한 질문을 하는 것이 항상 부담스러웠다고 해요.

하지만, 기자라면 그런 경험이 꼭 필요하잖아요?

그래서 공식석상에서 질문하기전에 "긴장되어서 가슴이 뛸때가 기회다" (정확한 문장이 기억이 안나는데 대충 이런 느낌으로 기억하고있습니다) 라고 항상 생각했다고 합니다.

저 역시도 부정적인 감정이 들때마다 항상 이런 생각을 했었어요.

"이런 긴장,부담,걱정이 드는 것 보니 이게 기회인가보다" 라고요.

그리고 냉정하게 생각해봤을때도 압도되어서 아무것도 안하는 것보다는 그래도 하는 것이 훨씬 낫고, 소극적인 전진이라도 가만히 있는 것 보다는 그래도 앞으로 나아가는 것이라고 생각합니다.

시간이 지나면 부정적인 감정보다는

제가 수행했던 결과물들만 남아서, 꾸역꾸역 실행에 옮겼던것 같습니다 :)

재르재르쟁쟁님 안녕하세요 :)

질문 남겨주셔서 감사합니다.

2개 질문에 답해드리자면

Q) BE 직무 신입/주니어 개발자 포트폴리오에 말씀하신 1인 개발/운영 프로젝트에서 FE 관련 코드의 퀄리티가 부족해도 좋게 평가를 하시는 편인가요?

A) 지원자의 직무가 BE라면 FE 코드는 평가 대상에 포함시키지 않습니다.

반대로 FE 개발자로 지원했다면 BE 코드는 평가 대상에 포함시키지 않습니다.

그래서 전혀 다른 직무의 코드가 좋고, 나쁜 것이 평가 요소에 포함되지 않아, 해당 직무가 작업한 코드와 그 주변의 작업에 대해서 집중적으로 검증합니다.

Q) 수준이 비슷한 두 명의 지원자 포트폴리오에서 1인 개발/운영 경험을 가진 지원자와 일반적인 사이드 프로젝트만 경험한 지원자의 평가 차이를 많이 두시는 편인가요?

A) 실제 서비스를 운영해서,

• 사용자가 사용하다가 발생한 오류를 어떻게 본인이 인지하게 할 것인가

• 오류가 났을때 문제 원인을 정확하게 확인하기 위해 로그를 어떻게 남길 것인가

• SQL 인잭션등 해킹성 시도가 계속 들어오는 것을 막기 위해 어떻게 방어할 것인가

• 갑자기 서버가 죽었는데 그게 무엇때문인지 확인하기 위해 어떤 작업들이 필요한지

등등 서비스 운영하다 보면 필요한 정말 많은 지식들이 필요합니다.

이건 단순히 코드를 이쁘게 작성하는 것과는 완전히 격이 다른 역량이라고 저는 보고 있습니다.

localhost:8080 밖에 보여줄 것이 없는 지원자보다는

코드가 아무리 더러워도 직접 서비스를 운영해본 사람에 대해서 더 좋은 분이라고 저는 생각합니다 :)

안녕하세요 hyo11 님.

질문 남겨주셔서 감사합니다. :)

개인적으로는 그냥 무작정 공부만 하는 것은 의미가 없다고 생각합니다.

계속해서 이력서를 제출하면서 면접을 보러 다니고, 면접에서 받은 질문들을 기반으로 공부하는 것이 훨씬 더 좋다고 생각합니다.

이와 관련해서 과거에 쓴 글이 있어서 이 글을 한번쯤 읽어보시길 추천드립니다.

• 링 위에 올라가기

말씀하신 자료구조, 알고리즘 등의 CS와 코딩 테스트 준비, 프로젝트 준비 등등을 하시고 나서 이력서를 제출하시면 너무 늦습니다.

그리고 알고리즘 테스트를 입사 과제로 보는 회사와 실전과 같은 프로젝트 구현 과제를 주는 회사들은 서로 다릅니다.

가시고 싶으신 회사가 어느 형태의 과제를 내는지를 보고 선택하는 것도 좋다고 봅니다 :)

가능하면, 자격증시험이나 수능시험 보듯이 숙제하듯이 공부하시는 형태는 좋지 않다고 봅니다.

개발 그 자체에 재미를 느끼셨으면 좋겠습니다 :)

그래서 직접 서버에 만드신 프로젝트를 배포하고 사용해보는 경험을 꼭 해보셨으면 합니다.

다른 분들의 이력서를 보셔도 어떤걸 준비해야할지 도움이 되실것 같습니다 :)

• 개발바닥 이력서 이벤트 방송

괜찮은 회사인지 확인하는 방법은 예전에 유튜브 영상으로 공유한적이 있어서 함께 공유합니다 :)

• 주니어 개발자에게 추천하는 회사는 스타트업

• 개발자를 위한 좋은 회사 고르는 비법

안녕하세요 향로님!

답변 감사합니다.

실패한 경험을 실패에 그치지 않고 그 부분을 채워서 지금보다 더 나은 곳으로 갈 수 있도록 도전하겠습니다.
다시 생각할 수 있게 도와주셔서 감사합니다~!

음 저는 사실 경력이 몇년차인데 공백이 있으면 감점요소로 본다 이런것은 전혀 없습니다.

공백 여부와 관계 없이 실력이 3년차에 걸맞는 분이냐가 중요하고, 3년차에 맞게 과제를 제출했느냐, 면접의 답변이 그정도 수준이냐가 중요했습니다.

이건 제 주변 다른 시니어분들도 거의 비슷하세요 ㅎㅎ

그래서 제 생각엔 "내 3년의 경력을 사람들이 인정해주지 않을것 같다"는 걱정보다는

"어떻게 해야 복귀 후, 3년차에 걸맞는 실력을 갖출수 있을까" 가 좀 더 유의미한 고민이 될 것 같아요 :)

그 어떤 회사의 면접관도 경력기간과 공백기간으로 지원자를 평가하진 않을거에요.

"어떤 경력과 공백이 있는건 알겠는데, 그래서 현재 실력이 어떤데?" 가 최우선 고려사항일거라고 생각합니다 :)

특정 언어를 자꾸 올려치기 하는 것 같아서 조심스러운데요 ^^;;;

언어나 프레임워크의 완성도와 별개로 한국 + 경력 1년 + 취업이라는 관점에서 제 경험 기반으로 이야기 드릴게요!

파이썬을 쓰는 회사가 확실히 적어진것 같긴 합니다.

다만, 파이썬 경력이 1년이 있으신데 바로 다른 언어로 환승하는 것 보다는 진짜 좋은 파이썬 회사가 없는지 먼저 고민해볼 것 같은데요.

저는 특정 기술을 사용하는 좋은 회사를 찾을때 가장 먼저 해보는 것이 해당 기술의 가장 유명한 컨퍼런스의 후원사 목록을 확인하는 것인데요.

예를 들어 파이썬 진영에는 파이콘이라는 대형 컨퍼런스가 있습니다.

올해 컨퍼런스 후원사 목록을 보면 다음과 같이 좋은 기업들을 알 수 있습니다.

페이히어, 레블업, 요기요, 크림등 좋은 회사들이 있기 때문에 이들을 한번 시도해볼 것 같아요.

파이썬 외에 한국에서는 백엔드가 크게 JVM (자바, 코틀린) 과 Node 쪽으로 나눠져있는것 같아요.

시리즈 C 이상의 기업들은 JVM으로

시리즈 B 이하의 스타트업들은 Node로

물론 시리즈 A, B에서도 JVM을 쓰는 회사들이 존재하며

시리즈 C 이상에서도 Node를 쓰는 회사들도 존재 합니다.

다만, 그 수가 상대적으로 비교했을때 위와 같은 양상을 보이는것 같아요.

제 주변을 보면 각 진영마다의 어려움이 존재했던 것 같아요.

JVM 은 큰 회사들이 많지만 그만큼 지원자들도 너무 많아 경쟁률이 치열하며, JVM 기반의 작은 스타트업들은 숫자가 적어서 주니어때 경력을 쌓을만한 회사들이 적다는 고민을 많이들 하시구요.

Node 쪽은 스타트업들이 많으니 이직이나 처음 취업의 난이도가 상대적으로 JVM 보다는 조금 더 수월하게 하셨던것 같아요.
다만, 흔히 말하는 네카라쿠배등의 회사들에 지원하기가 어렵고 (JVM 경력 몇년이상 등의 조건이 있는 공고들이 많다보니) 이런 큰 회사들에 지원하면 상대적으로 서류 탈락율이 높았던 것 같아요.

이게 올바른 것이냐 아니냐와는 별개로 제 주변 지인들, 멘토링 해주던 분들만 봤을때입니다.

또, 커뮤니티와 자료들이 부족해서 Java 나 C#쪽 자료들을 레퍼런스 삼아 공부하고, 스프링 개발자분들의 스터디에 참여해서 어려움을 겪기도 하시더라구요.

그래서 어디를 가든 그만큼의 어려움이 있는것 같아요.

저는 개인적으로는 다시 신입이 되어서 리셋해서 새롭게 시작하기 보다는 2년차 백엔드 개발자로서 실무 경험을 쌓는게 더 좋다고 봐요.

파이썬 기반의 백엔드 개발을 더 잘하기 위해 노력하다보면 다른 백엔드 기술 스택과 마찬가지로 좋은 경험을 쌓을 수 있을거라고 봅니다.

저 역시도 JVM으로 경력 내내 사용해오다가, 인프랩을 오면서 Node로 전환을 진행했고,

이때 JVM에서 더 잘하기 위해 노력했던 것들이 Node로 전환하는 내내 도움이 많이 되더라구요 ㅎㅎ

다른 언어와 프레임워크에서 진행되는 컨퍼런스가 있으면 참석하시는 것을 추천드립니다.

해당 컨퍼런스에 가서 다른 생태계에서는 문제를 어떻게 해결하는지 등을 보시고, 이걸 파이썬에서는 어떻게 풀었지로 연결해보면 좋은 경험이 될 것 같아요 :)

파이썬, 장고와 같이 애플리케이션 코드만 작성하는게 백엔드의 역할이라고 보진 않습니다.

네트워크, 리눅스 서버, SQL 튜닝 & 데이터모델링, 시스템 아키텍처 등등 다양한 경험이 백엔드에겐 필요하다고 봅니다.

좋은 장고 개발자가 되기 위한 노력 보다는

좋은 백엔드 개발자, 더 나아가서는 좋은 프로그래머가 되기 위한 노력이 정답이지 않을까 싶습니다 :)

진심어린 답변 정말 감사드립니다. 많이 정리가 되네요.
말씀하신것처럼 좋은 '백엔드' 개발자가 되기 위해 노력하겠습니다!

저는 1~2년정도는 그렇게 다른 분야를 경험해보는 것도 좋다고 생각합니다 :)

물론 1~2년 혹은 그것보다 짧은 시간만에 너무 안맞으시면 다시 FE를 전문적으로 해보시면 되구요.

가능하면 데브옵스 영역까지도 해보시면 더 좋을것 같구요.

아시다시피 과거에는 프론트엔드 개발이라는게 없었는데요.

그러다보니 저는 신입 ~ 3년차까지는 프론트엔드 JS 코드 작업을 계속 해왔습니다.

웹 퍼블리셔분들이 작업해주신 마크업을 가지고 (지금은 다 잊혀진..) Backbone.js, Handlebar.js, Grunt (+Gulp) 를 활용해서 IE7 까지 적용 가능한 JS 코드를 작업해서 사용자 서비스에 배포하는 일을 주니어 경력 내내 해왔습니다.

그리고 이렇게 해왔던 프론트엔드 개발 경험이 이후 경력 내내 많은 도움을 주었습니다.

프론트엔드 개발자분들과 협업을 할때나

내부 도구를 만들어야할때 직접 프론트 영역까지 최신 프레임워크로 구현한다던가

CTO로 프론트엔드 개발자분들과 소통을 해야할때 등등

많은 부분에서 저에게 도움을 주었습니다.

그 당시에는 그게 문제라고 생각하지 않았고, 실제로 웹 개발자라면 당연히 해야한다고 생각했는데요.

요즘은 이 부분이 완전히 분리되다보니 오히려 FE <-> BE <-> Infra 영역에 대한 이해도가 너무 낮은 상태로 업무를 진행하게 되는 문제가 발생하지 않나 싶습니다 :)

최근에 트위터에서 본 문장 중에 딱 와닿는게 있었는데요.
"헤맨 만큼 내 땅이 된다"

이것저것 해보시는게 스페셜리스트가 되지 못하는게 아닐까 걱정하실 수 있겠지만,

나의 학습 방법, 학습 루틴을 테스트해볼 수 있는 좋은 기회로 생각하고, 여러 다양한 경험치를 쌓을 수 있는 시간으로 생각을 해보시면 어떨까요?

아참 그리고 CTO 분들중에 백엔드 베이스가 많은 부분은 저도 좀 궁금한 부분인데요.
전체 CTO분들을 모시고 통계를 뽑은게 아니라서, 실제로 그런것인지 아닌지 먼저 확인이 필요할것같아요.

다만, 실제로 말씀하신것처럼 백엔드 출신의 CTO가 더 많다고 가정하고 생각을 해보면 다음과 같은 이유 때문이지 않을까 싶어요.

FE <-> BE <-> DevOps 로 협업을 하는 것이 일반적인 IT 기업의 구조인데, 여기서 백엔드 분들이 서로 다른 영역에 계신분들 사이에서 일을 하다보니 상대적으로 다른 파트에 대한 이해도가 조금 더 높지 않을까 하는 것이 있구요.

회사의 핵심 비즈니스에 가까울수록 C레벨이 될 수 있다고 생각하는데요.
만약 우리 팀의 핵심 비즈니스가 메신저라고 하면 앱 개발 분들이 CTO가 될 확률이 높고,
Web UI Kit 혹은 사용자의 사용성에 관한 것이 메인 비즈니스라고 한다면 웹 프론트엔드 개발자분들이 CTO가 될 확률이 높을것 같아요.
백엔드는 아무래도 데이터에 대한 가장 가까운 조직이다보니, 데이터가 회사 비즈니스의 핵심이라면 (포털, 컨텐츠, 커머스 등이 다 데이터가 중요한 곳인것같구요) 백엔드 분들이 CTO가 될 확률이 높지 않을까 추측해봅니다.

어디까지나 제 추측이고요 ㅎㅎ
이건 너무 재밌는 주제라서 나중에 유튜브에서도 한번 호돌맨과 이야기 나눠보겠습니다 :) 

답변감사합니다. 스페셜 리스트에 대한 고민이 있었는데 바로 잡아주시는군요 도움이 되었습니다.

"헤맨 만큼 내 땅이 된다"라는 말이 엄청 공감 되는군요. ㅎㅎㅎ 한번 해봐야 겠네요

회사 주력에 따라 CTO 가 결정된다라. 어렵네요.. 추후 AI 개발을 대신 하게 되면 CTO 영역은 또 바뀔것 같다는 생각도 드네요.

CTO 관련된건 나중에 영상 만들어 주시면 챙겨 보겠습니다 ㅎㅎ

감사합니다.

지나가다... 마침 프론트엔드 개발자에서 CTO로 가는 커리어패스를 가상으로 만들어봤는데 혹시 참고가 되실까 해서 공유드려봅니다. https://www.wanted.co.kr/community/post/9913

저는 원래 클라이언트 사이드의 기술을 주로 해왔어서, 주변에 프론트엔드 개발하다가 CTO 하시는 분들도 조금 있는 편인데요. 백그라운드에 따라 장단점이 있는 것 같아요. 자신의 장점을 살리는 커리어를 만들어 가시면 좋겠고요.

프론트엔드 또는 앱 관련 경력이 많은 분들의 장점은 유저와 제품 중심으로 생각하는 역량이 뛰어나고 디자이너 협업에도 뛰어난 것 같아요. 제 개인적인 생각이지만 기술적 과제 해결보다도 사업적 성과를 내는데 더 유리한 것 같아요. 다만, 백엔드 경험이 없으면 종합적으로 판단하기가 어려운 한계도 있기 때문에 이 부분은 기회가 있을 때 경험을 쌓아두시면 좋구요.

지금 프론트엔드 개발을 하시는데 백엔드 개발자로 경험을 쌓을 기회가 있다면 향후 커리어에 분명 도움이 되실거라고 생각합니다. CTO가 되는 길이 한가지만 있는 것은 아니니 내가 잘 하는 역량을 살려나가시면 언제든 기회가 있을 거에요.

좋은 추가 답변 감사합니다 리건님 :)
답변해주신 리건님도, (전) 무신사의 CTO이신 조연님도 다 클라이언트 개발자분들이셨어서 백엔드 출신의 CTO가 많다 아니다보다는 어떤 사람이 우리 회사의 CTO가 되는 것이 사업적/제품적/기술적으로 좋을 것인가에 대해 많은 회사들이 고민 하고 결정하는 것 같아요 :)

안녕하세요 falsystack 님 ㅠ
정말 죄송하게도 아직 일정이 명확하게 나오진 않았습니다.
제가 참... 배치책을 계속 써야하는데 계속 집필 활동을 못하고 있었네요.
최대한 빠르게 작업하도록 하겠습니다 ㅠ

안녕하세요 코린코린님

질문 남겨주셔서 감사합니다. :)

이미 서비스 대기업에 다니시면서 "대규모 클러스터화된 서버에서 비동기 로직을 이용한 작업, 쿠버네티스 환경, 카프카, 레디스" 등에 익숙하시다면 그것만으로도 좋은 커리어라고 생각합니다.

물론 단순히 이직할 수 있는 회사의 범위로만 본다면 "스프링 + RDBMS" 조합에 대한 경험을 필요로 하는 곳이 많기 때문에 이러한 경험이 필요하다고 볼 수 있겠습니다.

다만, 그런 경험이 없다고 해서 코린코린님의 경험이 부족하다고 보긴 힘들 것 같습니다.

내가 접한 기술과 환경에 대해 내가 얼마나 깊게 이해하고 있고, 내 것으로 만든 것이 확실하다면 그것 자체가 새로운 회사로 이직할때의 강점이라고 생각합니다.

스프링 + RDBMS라는 코린코린님께 생소한 환경에 대한 것도 빠르게 본인 것으로 만들 수 있음을 알 수 있기 때문입니다.

저라면, 일단 현재 회사내 팀 이동을 통해 지금 원하시는 경험을 쌓을 것 같습니다 :)

그리고 회사내에서 경험을 쌓으면서 내가 부족한 것들이 무엇인지 좀 더 디테일하게 체크하면서 공부를 할것 같습니다 :)

예시로 드신 "JPA의 @GeneratedValue 생성 전략에 따른 Insert 성능 비교 및 해결 방법" 등은 생각보다 실제 RDBMS를 활용하는 회사에서 문제로 인식하기엔 어려움이 있습니다.

물론 저 지식이 필요없진 않습니다만,

이미 대부분의 테이블이 생성되어있고, 그 안에서 PK 선언 방법이 정리가 끝난 상태에서는 신규 테이블을 만들때 외에는 사용하기는 어렵습니다.

더군다나 대부분의 회사에서 데이터베이스의 성능 문제는 조회/인덱스 문제입니다.

RealMySQL 책의 실행계획, 인덱스 등의 챕터와 데이터 모델링 챕터등을 보시는게 훨씬 더 필요한 지식이 아닐까 싶습니다 :)

특히 RDBMS를 공부하실때 JPA, ORM에 의존한 공부를 하시면 안되며 SQL, 스키마, 실행계획, 인덱스 등 애플리케이션을 제외하고 공부하는 것도 필요합니다.

물론 이것도 제가 설명하신 것들을 기반으로 한 추측입니다 ^^;

그래서 가능하면 실제로 RDBMS를 사용하는 경험할 수 있는 팀으로 이동해서 실제 업무에 필요한 데이터베이스 지식이 무엇인지 체감하면서 공부하시는 것을 추천드립니다 :)

effx 님 안녕하세요.
질문 남겨주셔서 감사합니다 :)

저는 연차가 쌓이면서 딱 한분야만 하는 경우는 정말 큰 대기업에 있을때만 그랬던것 같아요.

스타트업에 있으면서는 확실히 여러 영역을 다 다루고 있게 되어서 T 형태의 지식이 쌓였던것 같습니다 :)

요즘의 프론트엔드 개발도 데브옵스 영역에 대해 점점더 공부가 많이 필요로 하고 있습니다.

그래서 프론트엔드 커리어를 쌓으면서도 다른 영역을 공부하는 것이 커리어에 방해가 된다고 생각하진 않습니다.

아래에서도 몇번 언급했던 배휘동님의 프론트엔드 커리어 로드맵을 살펴보면 다음과 같이 여러 트랙의 프론트엔드 개발자가 있습니다 :)

만약 제가 그런 상황이라면 저는 벨로퍼트님처럼 사이드 프로젝트로 하나의 서비스를 혼자서 다 만들어보는 경험을 쌓을것 같습니다.

벨로퍼트님이 라프텔, 리디등에서 근무하실때 FE 개발자로 일하셨지만,

사이드 프로젝트로 velog, veltrends 등을 만드실때는 풀스택으로 전체를 구현하셨던 것이 말씀하시는 커리어의 가장 이상적인 형태가 아닐까 싶습니다 :)

그리고 그렇게 하나의 서비스 전체를 만들어보면서 진짜 내가 백엔드, 데브옵스에 관심이 있는건지, 프론트엔드를 하다보니 잠깐 흥미가 있었던 것인지 구분 해보는 시간으로 가질 것 같아요 :)

인프런과 저를 응원해주셔서 감사합니다 :)
더욱 좋은 서비스로 보답하겠습니다 ^^;

안녕하세요 양지님 :)

질문 남겨주셔서 감사합니다.

데이터 엔지니어 직무에 대한 구인은 제가 봐도 거의 없다고 느껴집니다.

특히 제 주변을 보면 소규모 스타트업은 데이터 분석가와 엔지니어를 별도로 구분해서 채용하지 않습니다.

풀스택 개발자를 채용하듯이 (모든 분야를 다 잘하는 것을 바라는게 아니라, 소규모로도 하나의 완성된 서비스를 만들 수 있는 정도를 바라는 것)

데이터 직무에 대해서도 상세하게 나눠서 채용하지 않고, 데이터 파트로 채용을 해서 분석/엔지니어링을 다 하길 바라고 있습니다.

제가 데이터 영역에 대해서는 전문가가 아니라서 조심스럽지만,

주변의 사례를 본다면 지금 같이 경력직만 채용 하고, 신입 엔지니어 채용이 없다는 가정 하에서는 다음과 같은 고민을 할 것 같습니다.

• 현재 회사에서 하시는 "Airflow와 크롤링 일을 하고, 시계열 그래프를 그리고 데이터를 통한 인사이트" 를 계속 하면서 회사가 좀 더 커지면 데이터 엔지니어 파트 신설을 요청 할 것 같습니다.

   

저는 어떤 직무냐 아니냐는 크게 중요하다고 보지 않습니다.

(건강보험 서류에 백엔드개발자라고 출력되는 것도 아니니깐요)

사내에서 어떤 역할을 했느냐 가 중요하고, 그걸 했기 때문에 타 회사 이직시 충분히 경력으로 인정 받을 수 있다고 생각합니다.

특히나 회사를 다니고 있으니, 회사가 망하지 않는 이상은 계속해서 일을 하시면서 주니어 채용 공고가 나올때까지 연습할 시간을 벌 수 있다고 생각 되구요 :)

가능하면 회사를 나와서 준비하지는 마세요.

그리고 어떤 직무의 타이틀을 얻어야만 경력이 쌓인다고 생각하진 말아주세요.

본인이 어떤 역할을 했느냐가 중요하며, 그리고 이 업을 더 잘하기 위해 어떤 노력을 계속 해왔는지가 훨씬 더 중요하다고 생각합니다 :)

그렇게 시간을 보내시다보면 원하시는 회사들의 채용공고가 올때까지 계속해서 성장하면서 기다릴 수 있다고 봅니다.

안녕하세요 finedev님

질문 남겨주셔서 감사합니다 :)

제가 2~3년차 프론트엔드 개발자로 이직을 해본 적이 없기 때문에 정확한 답변은 아닐 수 있습니다.

이점 양해 부탁드리겠습니다 :)

Q) 파이썬, 노드를 공부하는 것 vs 프론트엔드 성장 집중

저는 전문분야에 대한 공부가 충분한 상태가 아니라면 전문 분야에 대한 공부를 먼저 할 것 같습니다 :)

이제 6개월차 밖에 되지 않으셨는데 백엔드를 공부하는 것은 2~3년차가 되었을때 전문성이 전혀 쌓여있지 않을것 같습니다.

가능하면 프론트엔드 분야에 대한 공부를 계속 하시는 것을 추천드립니다.

만약 내가 직접 하나의 서비스를 운영해보고 싶다는 생각이시라면

프론트엔드 외적인 부분은 최소화할 수 있도록 Node.js로 하시는 게 좋을것 같습니다.

Q) 프론트엔드 2~3년차에게 기대하는 수준

A) 이건 제가 존경하는 개발자이신 배휘동님께서 블로그에 이미 정리해둔 글이 있어서 해당 글로 대체하겠습니다 :)

• https://steady-study.super.site/frontend-engineer-career-roadmap

Q) 문제해결과정, 코드 수정 과정을 중점으로 내용을 늦게나마 정리해보려 하는데 이 방향성으로 가도 괜찮을까요?

A) 어떤 문제를 어떤 과정으로 수정했는지의 구체적인 예시가 없어서 제가 그런 방향으로 가도 되는지에 대해서는 확답을 하기가 어렵습니다 ^^;

사람마다 가진 경험이 다르기도 하고, 그걸 녹여내는 문장력도 큰 차이가 있기 때문입니다.

다만, 제가 다른 회사에서 탐낼만한 좋은 서비스를 개발하고 있는 상황이 아니라면,

저는 말씀하신 방법을 제가 가진 문장력으로 잘 녹여낼 것 같습니다.

ps)

finedev님의 현재 역량이나 가지신 경험등을 전혀 모르는 상태에서 답변을 하는 것이라 아무래도 제한이 있다고 봅니다 :)

위에서 언급한 존경하는 프론트엔드 엔지니어이신 배휘동님께서는 인프런 내에서 멘토링을 하고 계십니다.

배휘동님과의 멘토링을 통해 성장에 대한 여러가지 고민들을 나눠보시는 것을 강력 추천드립니다 :)

• 배휘동 - 인프런 코칭 시작: 개인과 조직을 더 효과적으로 만들기(개발자 취업, 이직, 역량향상, 팀 리딩)

안녕하세요 Sony Bae 님
질문 남겨주셔서 감사합니다 :)

음 저는 4년차가 대략 이정도는 해야한다라는 보편적인 기준을 갖고 있진 않습니다.

어떤 회사에 입사했냐에 따라 얻을 수 있는 경험이 다르기 때문에,

그 사람을 판단하는데 있어서 객관적인 기준을 가지기란 어렵고,

그 환경내에서 할 수 있는한 최선을 다 하신것인지를 좀 더 보려고 하는 편인데요

기술적 취향이 맞는 회사에 가셔서 아무런 노력을 하지 않은 분과

기술적 취향이 맞지 않는 회사에 갔지만 정말 노력을 많이 하신 분 사이에서

전자인 분이 어떤 특정 기술에 대해서는 좀 더 숙련도(전문성은 아닙니다) 가 높긴 하겠지만,

전자가 더 좋은 개발자 라고 저는 생각하지 않기 때문입니다.

다만, 질문 주신 요지에 대해서는 아마도 "남들이 좋다고 생각하는 IT 서비스 기업에서 원하는 4~5년차에게 필요한 역량" 이 무엇인지 궁금해하실것 같고,

그런 회사들의 기술 스택이나 아키텍처가 어느정도 보편화 되어있기 때문에 그것에 대해서는 이야기해줄 수 있지 않겠냐라고 저는 해석을 했습니다 :)

아니라면 편하게 말씀주세요! ㅎㅎ

예전에 제가 쓴 글 중에서 자바, C#으로 된 좋은 컨텐츠들을 한번 정리한 적이 있습니다.

• https://jojoldu.tistory.com/609

이 안에 있는 컨텐츠들을 보시면 좋습니다.

이중에서도 특히 추천드리고 싶은 것들을 남깁니다.

자바, 스프링, SQL 등으로 기능 구현은 어떻게든 해낼 수 있는 분이라는 가정하에

스프링 기본은

• 김영한님의 스프링 기본편

스프링 부트를 직접 만들어가는 과정을 담은

• 토비님의 스프링 부트 원리와 이해

이 외에 클린코드, OOP, SQL 등을 배우기 위해 아래 내용들을 추천합니다.

• 백명석님의 클린 코더스

• 조영호님의 오브젝트

• Real MySQL 혹은 SQL 레벨업

특히 백명석님의 클린 코더스는 저나, 제 주변 지인들도 모두 2회이상 전체영상을 시청할 정도로 강추 합니다.

물론 이외에도 JPA와 같은 ORM도 당연히 공부하셔야하고, 클라우드 환경에 대한 이해도 필요합니다.

테스트코드 역시 절대 빠질 수 없는 요소입니다.

다만, 만약 이걸 전체를 다 하기가 어렵다면, 그리고 같이 공부할 동료나 내가 제대로 공부한 것이 맞는지 확인이 필요하다면 코드리뷰가 지원되는 유료 강좌를 수강하시는 것을 추천합니다.

• https://edu.nextstep.camp/c/8fWRxNWU/

NextStep의 강의들은 모두 코드리뷰가 지원되고,

TDD, 클린코드, OOP 등을 배우는데 좋은 커리큘럼을 가지고 있으니 자금이 있으시다면 들어보시길 추천드립니다.

안녕하세요 :)
질문 남겨주셔서 감사합니다.

저는 보통 걱정이 많아질때면 가장 먼저 하는 것이 A 를 선택했을때와 B를 선택했을때를 각각 사실 기반으로 비교를 합니다.

지금 익명님의 걱정은 저도 충분히 공감되기 때문에 제가 그 상황이라고 생각하고 비교를 해보면 다음과 같겠습니다.

• 지금 회사에 계속 남아 있는 경우

  • 사실

    • 연차/경력이 쌓임

    • 시니어의 조언이나 리뷰를 받을 수 없음

    • B2C 서비스 개발 경험을 쌓을 수 없음

    • 사내 자체 유통 프로그램 개발 경험을 쌓을 수 있음

    • 안정적으로 매월 급여가 들어옴

  • 아직 발생하지 않은 일

    • 잘못된 학습으로 커리어가 꼬임

• 지금 회사를 퇴사하고 이직을 위한 공부하는 경우

  • 사실

    • 연차/경력이 쌓이지 않음

    • 시니어의 조언이나 리뷰를 받을 수 없음

    • B2C 서비스 개발 경험을 쌓을 수 없음

    • 개인적인 공부할 시간을 확보 할 수 있음

    • 급여가 더이상 들어오지 않음

  • 아직 발생하지 않은 일

    • 개인 시간의 공부로 올바른 성장을 할 수 있음

사실 말씀하신 걱정 중에서는 퇴사후 혼자 공부해도 쌓을 수 없는 것들이라고 생각합니다.

시니어의 좋은 조언을 받지 못하는 점이나, 대용량 트래픽 등 잘나가는 서비스 회사에서 얻을 수 있는 경험등이 이에 해당한다고 봅니다.

정확한 내부 사정과 개인 사정을 알 수 없기 때문에 남겨주신 질문만으로 비교를 하였습니다 :)

한번 객관적으로 회사를 계속 다니는 것과 퇴사 후 개인공부를 하는 것 사이의 사실, 장/단점 등을 나열해서 비교해보시고 적절한 선택을 해보시는 것을 추천드립니다 :)

안녕하세요 김재환님
질문 남겨주셔서 감사합니다. :)

사실 제 기준에서는 프로그래밍 경험이 전무한게 아니라면 C++, MFC, 자료구조, 네트워크 등에서 자료구조, 네트워크 등은 프로그래머라면 어느정도 알고 있어야할 기반지식중 하나라서 굳이 일정에 포함시키지 않을것 같고,
C++ 은 JS에 대한 공부를 충분히 하셨다면 배우시는 데 큰 문제가 없다고 봅니다.
그리고 MFC만이 아마 조금 다르게 느껴지실 수 있을것같은데요.
그럼 3개월이면 저는 충분하지 않을까 싶습니다 :)
단순한 예로 프로그래밍을 처음하는 입문자를 대상으로 한 부트캠프에서도 프로젝트 기간을 제외하고 교육 기간으로만 하면 3개월을 넘는 경우가 거의 없는 것을 생각해보면 비슷하지 않을까 싶습니다 :)

다만, 이 기간 내에 훈련이 되냐 안되냐는 중요한 문제는 아닌것 같습니다 :)
많은 회사들이 그런 온보딩 기간을 주지 않는 곳들이 더 많기 때문인데요.
3개월이라는 신입 온보딩 기간은 생각보다 회사에서 많은 시간을 투자하는 것으로 저는 판단됩니다 :)
그렇다면 3개월안에 어떻게든 이 과제를 달성하기 위해 집중하는 것만 고려할것 같습니다 :)

안녕하세요 재미있는 산호님 :)
지금 어떤 노력들을 하고 계신지 잘 모르겠어서 이대로 계속 해도 되는지에 대한 고민을 이야기하셔도 답변드리기가 어려운것 같습니다 ^^;;

다만, SI 계열의 대기업을 노리시는게 아니라면 자격증과 영어는 준비하지 않으셔도 될 것 같습니다 :)
스타트업이나 서비스 회사들은 그 둘을 전혀 보지 않아서요

안녕하세요 jeong-min yoon 님

질문 감사합니다. :)
전체적으로 내용이 길어서, 어떤 것이 고민인지 제가 찾기가 조금 어렵긴한데요.
제 생각에는 "이직을 하고는 싶지만 제가 3년차에 맞는 실력을 갖고 있는지 의문을 가져서 망설이게 되고, 노력에 대한 의지도 꺾이지 않을까" 하는 것으로 보이는데 맞으실까요?

(제 생각에는)이런 부분에 대한 고민이 있으신 것 같아서 한번 제 생각을 나눠볼게요 ㅎㅎ

노력해야할 것이 너무나 많으면 그 양에 압도되는 것은 사람인이상 누구나 그럴 수 있다고 생각합니다 :)

다만, 그렇게 압도 되고 나서 "그 이후에 어떤 행동을 취하느냐" 는 사람마다 다른 것 같아요.

누군가는 압도되어 아무것도 못할 것이고,

누군가는 그럼에도 불구하고 한발자국씩 전진하는 사람이 있을거에요.

결국 움직이지 않으면 그 어떤 것도 내 지식이 되진 않을테니깐요.

프로그래밍 세계에는 분할 정복 이라는 개념이 존재합니다.

아주 거대한 양도 작은 것 부터 시작하시면 결국 다 해결되실거라고 생각합니다 :)

그리고 혼자서 공부하시면서 코드리뷰나 좋은 코드에 대한 피드백에 대한 아쉬움은 저는 다음과 같이 해결했습니다.

(저도 SI나 시니어가 없는 회사등을 다니면서 코드리뷰 등에 대한 갈망이 높았던 시절이 있었어서요 ㅎㅎ)

• 인프런의 멘토링을 통해 포트폴리오, 학습방법, 이력서에 대한 피드백을 받으시거나

• 빅테크 회사의 개발자들이 코드 리뷰를 해주는 사설 교육 서비스를 이용하시거나

등등 신뢰할만한 사람들을 통해 피드백을 받아보시는 것을 추천드립니다. :)

좋은 개발 문화를 가진 회사로의 이직은 항상 어려움이 많고, 해야할 일이 많은 것을 저도 100% 공감합니다.

저 역시도 커리어 전환하기 위해 많은 시간을 쏟았었구요.

돌이켜보면 그런 시간으로 인해서 커리어 전환이 된 것도 좋았지만,

몰랐던 것들을 하나둘씩 알게되는 순간, 과거 보다 조금 더 성장하고 있음을 느끼는 그 과정 자체가 저에겐 가장 큰 보상이였던 것 같아요 :)

이 많은 노력과 시간을 쏟아야만 얻을 수 있는 보상에 집중하시기 보다는

그 과정 자체를 즐기시는 것을 더욱 추천드립니다 :)

경력직 이직을 원하시는지, 중고신입으로서의 이직을 원하시는지에 따라 다를것 같습니다 :)
보통은 만 2년이 되어야만 경력직으로 생각하는 경우가 많지만, 회사 별로 3년이상, 5년이상 등을 채용 공고 조건에 넣고 있는 경우도 있습니다.

그래서 어느정도 경력이 있어야 이직이 가능한지는 알 수 없으며,

채용공고를 낸 회사가 기대하는 역량을 쌓았느냐가 더 중요한것 같습니다.

경력이 있다고 해서 그게 실력을 나타내는 지표는 아니라는걸 요즘은 정말 많은 회사에서 인지하고 있어서요 :)

질문 글을 보니까 아랫분이랑 상황이 많이 비슷한 것 같네요..ㅎㅎ

안녕하세요 MJKim 님 :)
질문 남겨주셔서 감사합니다.

저는 요즘의 신입 소프트웨어 엔지니어 지망생분들이 어떤 공부가 필요한지를 여쭤보실때마다 항상 이야기드리는 것은, 하나의 서비스를 온전히 다 만들어서 실제 운영까지 해보는 것을 이야기 드립니다.

어느 카테고리의 회사 취업을 목표로 하느냐에 따라 다르겠지만,

일반 웹/앱서비스의 소프트웨어 엔지니어는 고객의 불편함을 해결하는 제품을 만들어내는 것이 제 1역할이라고 저는 생각합니다.

소프트웨어 엔지니어는 학술가 혹은 연구원이 아니라고 생각합니다.

"내가 원하는 무엇을 만들기 위해서는 어떤 기술이 필요하다. 그렇기 때문에 그 기술을 공부하겠다" 로 접근해야만 저는 올바른 공부가 된다고 생각합니다 :)

학교에서 시험 공부하듯이 어떤 기술을 공부하는 것은 결국 학문 그 이상이 되지는 못하는 것 같습니다.

특히나 백엔드 개발자는 사용자가 없는 환경에서 단순히 공부만으로는 본인의 역량이 되지 못하는 부분이 굉장히 많습니다.

아래 서비스들은 모두 다 개인 혹은 2인의 팀이 만들어낸 제품입니다.

• https://velog.io/

• https://iloa.gg/

저는 MJKim 님도 내가 느낀 어떤 불펴함 혹은 최소한 나 라도 쓸 서비스를 하나 만들어가면서 그때그때 필요한 것들을 공부해서 하나의 웹 서비스를 구축하고 실제 24시간 운영하기 위해서는 어떤 것들이 필요한지 몸으로 직접 느끼면서 채워나가시는 것이 가장 필요한 공부이고 좋은 학습방법이 아닐까 생각합니다 :)

안녕하세요 rlamw2000님
질문 남겨주셔서 감사합니다 :)

지향하시는 회사의 유형이 어디냐에 따라 다를것 같아요.

백엔드 개발팀의 규모가 20명 이하인 대부분의 스타트업에서 생각하는 기본기는 내가 사용하고 싶은 제품을 직접 만들어본 경험을 이야기하는 경우가 더 많은 것 같습니다.

알고리즘, 자료구조 등을 공부하는 이유가 취업때문인지,

내가 더 좋은 소프트웨어를 만들기 위해 필요한 지식이라 공부하는 것인지 구분하는 것은 굉장히 중요하다고 생각합니다.

그리고 스타트업의 소프트웨어 엔지니어는 학습, 연구만을 하는 연구원이 아니라, 결국 제품을 만들어낼 수 있는 사람이어야 한다고 생각합니다 :)

본인이 불편하다고 느낀 점을 해결하기 위해 소프트웨어 기술을 활용해보신 적이 있으실까요?

주변인들의 불편함을 해결하기 위해 소프트웨어를 만들어보신적이 있으실까요?

어떤 제품을 만들어서 본인의 불편함을 해결하셨나요?

저는 소프트웨어 엔지니어가 되겠다는 것은 이런 점에 대해서 먼저 고민하는게 필요하다고 생각합니다 :)

CS공부를 많이 하고, 그걸 증명만 할 수 있다면 스타트업에서 생각하는 좋은 소프트웨어 엔지니어가 된다고 생각하진 않습니다.

소프트웨어를 학문적으로만 접근하지는 않으셨으면 좋겠습니다 :)

그리고 이건 마지막에 언급하신 이펙티브 자바를 공부할까 말까에 대한 것도 같은 의미입니다.

물론 스타트업 등이 아닌 네이버, 카카오 등의 빅테크에서는 좀 더 장기간의 안목을 갖고 신입 개발자를 평가합니다 :)

저는 대학생 신분이라면 당장의 취업 준비 보다는 OS를 만들어 보는 것도 좋은 방법이라고 생각합니다.

다만, 그 경험이 취업에 유리하냐라고 한다면 그건 아닐 확률이 높을 것이며

개발자로서 길게 본다면 당연히 도움이 될 수 있다로 생각을 정리할 수 있을것 같습니다.

네이버에서 진행한 백엔드 개발자를 꿈꾸는 학생개발자에게 를 읽어보시면 도움이 많이 되실것 같습니다 :)

위 링크와 더불어서 글을 작성해주신 정상혁님께서 댓글로 남겨주신 내용도 함께 첨부하니 같이 읽어보시면 좋을것 같아요 :)

어떤 역량을 가져야 신입 개발자로 뽑힐수 있느냐는 질문을 받아서 여기에 댓글로 제 생각을 정리해봅니다.

신입기준으로는 당장 쓸 구체적인 응용기술을 아는 것도 당연히 선택을 받는데 도움이 됩니다.

실무자들이 면접을 볼때 같이 나눌수 있는 이야기가 많아지기 때문입니다.

특히 신입이라도 당장 와서 일할수 있는 사람을  찾는 조직에서는 실무기술을 가급적 많이 아는 사람을 선호할듯합니다.

그런데 실무 기술을 써본 경험이 있어도 그 기술에 대해 자세히 설명할수 없다면 오히려 경험 안했다고 이야기하는 것보다 더 부정적인 영향을 미칠수 있습니다.

예를 들면 Java로 DB를 쓰는 개발을 해봤다고했는데 그게 MyBatis를 썼는지 JPA를 썼는지도 모르는 경우입니다.

반면 잠깐 써보고 아직 깊이 모르는 기술이라도 구체적인 이야기를 체계적으로 할 수 있다면 더 긍적적인 요인이 됩니다.

예를 들어 MyBatis를 처음 썼는데 어떤 상황이 어려웠고, 알고보니 MyBatis의 어떤 특성 때문이였고, 이를 어떻게 해결했는지 등에 대한 구체적인 이야기를 하는 사람이면, '이 사람은 쓰는 기술에 대해서 제대로 파악을 하려고 했구나'를 느낄수 있습니다.

그런 사람이면 MyBatis를 당장 안 쓰고 JPA를 쓰는 프로젝트에라도 바로 적응할수 있겠구나  하는 느낌을 줍니다.

신입 개발자를 채용할때는 현재 할 수 있는 일이 얼마나 되는지를 넘어서 앞으로 얼마나 발전가능성이 있는지에 더 중점을 둬야된다고 생각합니다.

면접관 입장에서는 자신이 잘 아는 기술을 단편적으로 물어보는것에 그치지 않고 사람이 가진 학습 능력, 학습 의지 등을 파악해야하는데, 당연히 쉬운 일은 아닙니다.

지원자 입장에서는  성장가능성을 표현할수 있는 방법은 여러가지일 것 같습니다.

위와 같이 실무에서 쓰는 이미 잘 알고 있고, 그걸 학습해온 과정을 잘 설명하는 것도 하나의 방법입니다.

학교에서 한 팀 프로젝트라도 남 다르게 한 면이 있다면 실무기술을 잘 몰라도 충분히 앞으로 성장 가능성을 보여줄수 있다고 생각합니다.

코딩 테스트에서 문제를 센스있게 파악한다던지, 유창하고 거침없이 코딩을 할 수 있는것도 자신을 잘 드러낼수 있는 방법입니다.

글을 쓰다보니 '신입개발자로 지원할 때는 자신이 앞으로 빠른 속도로 발전할수 있다는 가능성을 보여주는 것이 중요한데 실무에서 쓰는 기술을 일부 아는 것은 그 방법 중의 하나이다. 그러나 유일한 방법은 아니다.'  정도로 제 생각은 정리가 되네요.

글을 쓰다보니 몇년전의 어느 인턴 지원자의 면접이 기억납니다.
Linux 커널에 관심이 많은 학생이였는데, 사실 제가 인턴의 업무로 염두에 두었던 분야는 그쪽은 아니였습니다.
코딩 테스트도 제가 계획한 둔 인턴 과제에서는 쓰지 않을 C++로 하기도했습니다.
당시에 엄격한 기준으로 채점을 하는 시스템을 이용해서 코딩 테스트를 했는데, 그 시스템의 판정으로는 그 학생은 문제를 통과하지 못했습니다.

그렇지만 거의 답에 근접한 방식으로 코딩을 했고, 무엇보다 유창하고 거침없이 코딩을 하는 모습이 인상적이였습니다.

하나의 방법이 잘 안되자 그 다음 생각나는 아이디어를  바로 빠르게 타이핑해나갔습니다.

저는 그 학생을 합격시키고, 연관된 업무가 있을만한 다른 프로젝트 쪽에 추천을 드렸습니다.
인턴을 거쳐서 그 학생은 최종 입사를 했습니다.

그런데 처음 그 신입사원이 했던 분야는 그 학생이 깊게 팠던 Linux 커널등과 관련된 분야는 아니였습니다.

Java웹개발과 JavaScript와 Angular.js로 FE개발까지 했던것으로 알고 있습니다.

그때의 인턴은 몇년이 지나서 Linux 커널에 코드 기여를하고 Deview 2018에 "대형 컨테이너 클러스터에서의 고가용성" 라는 발표를 하기도했습니다.

그  발표를 두고 어떤 분들은 DEVIEW 2018의 최고의 발표라고도 말씀을 하셨듯습니다.

신입 개발자가 당장 실무에서 쓰는 기술을 알아야하는 채용이 되는 것은 아니라는 예로 위의 사례를 봐주셨으면 합니다.

그리고 그 인재가 가진 역량이 당장은 아니더라도  장기적으로 발휘될 것이라는 믿음으로 신입사원을 바라보기도합니다.

안녕하세요 쫑긋님
질문 남겨주셔서 감사합니다 :)

저는 신입 팀원 (꼭 프로그래머가 아니더라도 모든 직군의 공통으로) 에게 가장 기대하는 점은

"팀의 상황을 읽고 내가 할 수 있는 일이 뭔지 고민하는 자세" 입니다.

신입 개발자로서 어떻게 성장해야할지 고민하는 것도 분명히 팀에서는 도움이 되겠지만, 더 중요한 것은 어떤 태도로 팀에서 활동할 것인가 를 고민해보는 것입니다.

신입 개발자가 당장에 팀에 전문성으로 기여하는 것은 어렵습니다.

기술적으로 성장하는 것도 당연히 필요하지만,

당장 전문성으로 팀에 기여하는 바가 없다면, 전문성이 쌓이기 전까지는 어떤 점으로 팀에 기여할까를 항상 팀의 입장에서 고민하는 자세가 있다면 그게 바로 팀에서 바라는 이상적인 신입 개발자의 모습이라고 생각합니다.

그리고 그렇게 팀에 기여하면서 점점 기술적인 면에서도 시니어의 조언을 받으며 성장한다면 가장 좋은 성장 사례가 되지 않을까 생각합니다 :)