셩잇님의 잡동사니

1. https://github.com/jojoldu/junior-recruit-scheduler GitHub - jojoldu/junior-recruit-scheduler: 주니어 개발자 채용 정보 주니어 개발자 채용 정보. Contribute to jojoldu/junior-recruit-scheduler development by creating an account on GitHub. github.com 향로님의 깃허브 리포지토리로써 주니어 개발자를 위한 취업 정보를 업데이트하여 자료를 제공해주는 리포지토리입니다. 프론트/백엔드 자료가 위주입니다. 2. https://github.com/JaeYeopHan/Interview_Question_for_Beginner GitHub - JaeYeopHan/..

이래저래 취업 준비하고 계신 분들과 이야기 나누고, 실제로 회사에서도 채용에 어느 정도는 관여를 (안할 수가 없어서) 하다보니 드는 생각이 있어서 글을 몇개 가져와봅니다. HP 에서 조사한 결과에 보면 남성은 채용 공고의 자격 요건을 60% 정도만 맞으면 지원해보는데, 여성은 100% 다 충족해야 지원하는 경향이 있다고 하는데요. 저 수치가 맞냐 틀리냐를 떠나, 어느 정도 저런 경향을 저도 직간접적으로 체험하긴 했던 거 같아요. https://www.thewomens.network/blog/the-resume-gap-is-real 근데 또 한편으로는 "이걸 남녀 자신감의 차이라고 단순히 후려칠 수 있지만, 다른 측면이 더 크다"는 주장도 봤는데요. 위 HP 연구 결과에 의문을 갖고 1000명을 대상으로 ..

(번역) 주니어가 되는 것을 그만두세요. 아마 개발자로 일을 한지 2~3년 차 시절 때였습니다. DEVIEW에 참관하러 나갔다가 저의 멘토님이시자 스승님이 발표하신다기에 응원을 하러 갔었죠. 아무렇지 않게 동기들과 맨 앞자리에 자리를 잡고 기다리다 인사할 기회가 생겼는데 그분은 저에게 이런 말씀을 하셨습니다. "이제 발표할 때 되지 않았니? 준비는 잘 하고 있지?" 이제 막 회사에 적응해서 코딩을 하는데 겨우 재미가 들던 시절 발표라니... 너무도 충격적인 기억이라 아직도 생생한데요. 지나고 보면 경험이나 연차가 많아야지만 그런 무대에 올라 발표를 해야 하는 룰은 없으니 스스로 제 자신의 울타리를 친 건 아닌가 생각을 해본 기억이 있습니다. 주니어 개발자의 정의는 무엇일까요? 그렇다면 시니어 개발자는요?..

코드 리뷰는 조직의 상황에 따라 실행하는 목적도 방식도 목표도 다르다. 그렇기에 정답이 없다. 그래서 내가 코드리뷰에 관한 글을 시작하기 앞서 내가 처한 상황을 설명하지 않는다면, 읽는 사람도 글을 이해하기 쉽지 않을 것이다. 나와 함께 일하는 조직은 아래와 같았다. * 열 명 이하로 구성된 개발 조직이었다. * 대부분의 개발자가 신입 사원이거나 경력이 2년이 채 되지 않는 주니어 개발자였다. * 간혹 10년~20년 경력의 시니어 개발자가 있었으나 코드 리뷰 경험이 없었다. * 실력 있는 개발자를 채용하기 어려웠다. * Git을 SVN(Subversion)처럼 쓰고 있었다. * 이슈 기반의 개발을 하고 있지 않았다. 코드 리뷰어로서 내 목표는 세 가지였다. * 최소한의 코드 품질 유지 * 개발 코칭을 통..

최근 이직을 위해 공부하면서 새로운 개발자들을 만났다. 서로 직장이 없는 상태에서 만났기 때문에 가장 관심 있는 대화 주제는 역시 이직(취직)이었다. 함께 면접 스터디를 진행하며 많은 도움을 주고받았고, 덕분에 원하던 회사에 합격하는 결과를 얻었다. 물론 면접에는 운이 작용한다. 하지만 이번 합격을 순전히 운으로 치부하기보다는, 준비 과정에서 어떤 요소들이 긍정적으로 작용했는지 원인을 분석해 보고 싶었다. 그리고 글로 남겨둔다면 취직이나 이직을 준비하는 사람들에게 작은 도움이라도 줄 수 있을 것이라 생각했다. 더 읽어보기 : 요즘 IT https://yozm.wishket.com/magazine/detail/2058/?utm_source=stibee&utm_medium=email&utm_campaign=..

유니티 블로그에 게임 개발할 때 사용하기 좋은 다양한 아키텍처 패턴과 이를 활용하는 방법의 글이 있어 공유한다. 글이 너무 길지도 않고 15분에서 20분 정도면 읽을 수 있으니 출, 퇴근길 대중교통에서 가볍게 읽으면 좋을 것 같다. 😎 https://blog.unity.com/kr/games/level-up-your-code-with-game-programming-patterns 게임 프로그래밍 패턴으로 코드 작성 스킬 업그레이드하기 | Unity Blog 객체 지향 프로그래밍 언어를 다룬 경험이 있다면 SOLID 원칙, MVP, 싱글턴, 팩토리, 관찰자 패턴 등에 대해 들어보셨을 것입니다. 유니티에서 발행한 최신 전자책에서는 이러한 원칙과 패턴을 활 blog.unity.com

필자는 스타크래프트에 한글 지원 기능을 제작한 박종천 개발자이며, 30년 개발 경력의 경험을 글로 풀어보았다 합니다. 본문이 개발자 여러분께 도움이 되길 희망합니다. “30년 혹은 그 이상을 개발자로 살고 싶은 분들께 조금이나마 도움이 되었으면 하는 마음으로 제 경험을 3회차의 연재 글로 풀어볼 겁니다. 80억 인구가 80억 가지 인생을 살게 되므로 제 이야기가 여러분께, 혹은 지금 시기에 딱 맞지 않을 수도 있습니다. 그럼에도 가능하면 시간이 지나도 살아있는 콘텐츠가 될 수 있도록 핵심에 집중했습니다.” -필자 더 읽어보기 : 요즘 IT https://yozm.wishket.com/magazine/detail/2025/?utm_source=stibee&utm_medium=email&utm_campaig..

+10배의 엔지니어는 신화적인 인물일지 몰라도 -10배의 엔지니어는 존재합니다. -10배의 엔지니어가 되려면 주당 400시간의 엔지니어링 시간을 신나게 낭비하면 됩니다. 본문을 통해 -10배 엔지니어가 되는 20가지 전략들을 공유합니다. 더 읽어보기 : 요즘 IT https://yozm.wishket.com/magazine/detail/2012/?utm_source=stibee&utm_medium=email&utm_campaign=newsletter_yozm&utm_content=contents -10배 엔지니어가 되는 방법 | 요즘IT 이 글은 10x 엔지니어가 아닌 -10배의 엔지니어가 되는 법에 대해 작가의 개인적인 견해를 담은 글입니다. +10배의 엔지니어는 신화적인 인물일지 몰라도 -10배의 엔..

이전 글 ‘주니어 개발자를 위한 엄청 쉬운 TCP/IP 4계층 이야기’에서, 컴퓨터와 컴퓨터의 통신이 올바르게 이루어지기 위해 데이터가 각각 어떤 계층에서 캡슐화되어야 하는지 알아보았습니다. 또한 데이터가 목적지에 정확히 전달되기 위해 계층별로 어떠한 프로토콜(약속)로 구성되어 있는지도 간단히 알아보았습니다. “응용, 전송, 인터넷, 네트워크 액세스 순으로 캡슐화”라는 큰 개념만 알아보았다면, 이번 시간에는 앞서 언급한 각 계층의 대표적인 프로토콜들에 대해 좀 더 알아보고, 각 프로토콜이 네트워크에서 어떻게 이용되는지 확인해 보겠습니다. 더 읽어보기 : https://yozm.wishket.com/magazine/detail/2005/?utm_source=stibee&utm_medium=email&utm..

소프트웨어 엔지니어로 2-3년 정도 경력이 쌓이면 이제 주니어 레벨에서 벗어날 준비가 필요하다. 회사에서도 한 단계 높은 미드레벨 개발자의 역량을 요구하기 때문이다. 평균적인 수치로 경력을 2-3년이라고 했지만 이는 사람마다 다를 수 있다. 빠르면 1년 이내 미드레벨에 도달할 수도 있고, 길면 4-5년 차 또는 그 이상이 될 수도 있다. 이번 글에서는 주니어 개발자가 미드레벨에 도달하기 위해, 어떤 역량이 필요한지 필자의 경험을 토대로 살펴보고자 한다. 더 읽어보기 : https://yozm.wishket.com/magazine/detail/1993/?utm_source=stibee&utm_medium=email&utm_campaign=newsletter_yozm&utm_content=contents 미..

요약 1. 로직을 이해하기 쉽도록 구현했는지를 위주로 코드리뷰합니다. 2. 코드 작성자는 확신이 없는 부분에 대해서 사전에 설명하는 코멘트를 남겨두면 좋습니다. 3. 코드 리뷰어는 자신의 코멘트가 필수적으로 반영되어야 하는지, 선택적으로 반영하면 좋은 것인지 명시하면 좋습니다. 4. 구글 등 다른 코드리뷰 문화도 참고하시면 좋습니다. 경험상 사람마다 코드리뷰에서 주로 보는 부분이 다르겠지만, 저는 로직을 주로 봅니다. 구현하고자 하는 것에 비해서 복잡하게 되어있지는 않은지, 맥락을 알아야지만 이해할 수 있도록 구현되어 있지는 않은지 점검하는 편이에요. 그래서 사실 코드를 읽다가 이해하기 어렵다 싶으면 그때부터 로직에 개선점이 있는지 주의 깊게 봅니다. 코드 스타일 등 린터나 포매터로 자동화할 수 있는 부..

1. 코드 내용을 그대로 반복하는 (추가 정보가 없는) 주석은 적지 말라. 2. 좋은 주석은 불명확한 코드를 변명하지 않는다. - 주석으로 코드를 설명하지 말고 코드를 다시 써라. 3. 명확한 주석을 적을 수 없다면 코드에 문제가 있을 수 있다. - 코드가 어렵다고 주석으로 경고하지 말고 코드를 다시 써라. 4. 주석은 혼란을 야기하는 것이 아니라 해소해야 한다. - 주석을 보고 더 헷갈린다면 그 주석은 지워라. 5. 관용적이지 않은(unidiomatic) 코드는 주석으로 설명하라. - 불필요하거나 중복된다고 생각할 수 있는 코드, 이로 인해 다른 누군가가 "단순화"할 수도 있다고 생각되는 코드에는 주석을 달아 설명하는 것이 좋다. 6. 복사한 코드라면 원본 출처 링크를 주석에 포함하라. - 향후 코드를..

거의 모든 개발자는 성장의 여정에서 필연적으로 많은 장애물을 넘게 됩니다. 기술과 사람의 문제로 넘어지기도 하지만 이 경우는 일반적인 장애물은 아닙니다. 가장 일반적인 유형이자 제가 유독 많이 느끼기도 했던 개발자의 성장을 방해하는 장애물과 장애물을 넘는 방법을 하나씩 정리해보려고 합니다. ⚠️ 완벽 추구 개발자로서 어떤 시도를 하려고 할 때 완벽하게 준비가 됐을 때 행동하려는 마음이 생기곤 합니다. “난 더 연습해야 해. 아직 시도할 준비가 되지 않았어.” “조금 더 배워야 해” “코드와 기능을 조금 더 개선 후에 출시해야 해” “조금 더 공부하고 더 나은 회사에 지원해야 해” 이렇게 완벽을 추구하려는 노력은 사실은 누구나 가진 실패에 대한 자연스러움 불안함, 두려움입니다. “완벽 추구”는 불안, 불편..

개발자의 성장에 있어서 ‘반복하는’ 것은 굉장히 중요합니다. 현재 서 있는 자리에 오기까지 반복해서 시도한 것들을 앞으로도 계속 반복하면 분명 가치가 있겠지만 다음 단계로 넘어가기는 쉽지 않습니다. 다음 단계로 넘어가려면 새로운 경로, 단계, 올바른 방향으로 움직일 수 있는 힘이 필요합니다. 이러한 열린 마음을 갖는 것은 성장에 큰 도움이 됩니다. 그러나 새로운 경로, 단계, 올바른 방향을 안 것만으로는 충분하지 않습니다. 새로운 것이 일상적인 개발 루틴의 일부가 되도록 ‘연습을 반복’하는 것이 가장 중요합니다. 저는 새로운 것이 나의 일상이 되어 한단계 더 성장한 모습 상상하기를 좋아합니다. 하지만 성장에 그다지 큰 도움이 되는 상상은 아닌 것 같습니다. 개발자로 치열하게 살면 살수록 “천 리 길도 한..

앞으로 30년 혹은 그 이상을 개발자로 살고 싶은 분들께 조금이나마 도움이 되었으면 하는 마음으로 제 경험을 3회차의 연재 글로 풀어볼 겁니다. 지난 1편에 이어 두 번째 글입니다. 성장하는 10년 리딩하면서 일하는 10년 ←여기 서포트하는 10년 (경영과 사업의 10년) 매니지먼트는 프로젝트 관리, 팀 관리, 프로세스 관리로 구분할 수 있습니다. 첫 번째 프로젝트 관리는 출시 시기와 중점을 둬야 하는 일을 관리하는 기술입니다. 두 번째는 팀 관리, 즉 사람 관리입니다. 세 번째로 프로세스 관리입니다. 진행하는 과정을 관리하는 기술입니다. 주니어 개발자로 입사하면 처음에는 주어진 일을 하며, 개발 방법과 개발 주기를 배웁니다. 연차가 높아질수록 프로젝트를 관리하는 방법, 직원을 관리하는 방법, 좋은 프로..

일 잘하는 개발자는 어떤 역량을 갖추고 있을까요? 오늘은 제가 생각하는 개발자의 역량이란 무엇인지 정리했습니다. 개발자에게 있어 역량이란 '요구 사항을 안정성과 확장성의 균형을 맞춰 제시간에 개발하는 능력'이다. 요구 사항을 받아 든 순간부터 역량이 드러난다. 기획자, 디자이너와 요구 사항에 대해 함께 논의하고 구체적인 요구 사항을 정리한다. 때론 제시간에 개발하기 위해 요구 사항을 줄이는 제안을 하기도 한다. 코드를 작성하는 순간에는 안정성과 확장성 사이에서 균형을 맞춘다. 상상하고 싶지 않은 에러 상황들을 하나씩 상상해 가며 세심하게 코드를 써 내려간다. 변수명 하나에도 분명한 이름을 붙여 동료와 미래의 내가 이해할 수 있는 환경을 갖추기 위해 노력한다. 약속한 시각을 지켰다면 제품을 내보낸다. 만약..

엔지니어, 개발자에게 인성과 태도, 소프트 스킬이 중요한 이유는 이렇다. 1. 개발자에게 개발 능력이 최우선이 맞다 2. 개발 능력이 매우 뛰어나면 인성이나 태도가 그리 중요하지 않은 것도 맞다 이걸 다시 말하자면, 1. 10년 이상 개발일을 계속 하려면 개발 능력이 일정 수준 이상 되는 것이 전제 조건이다 2. 태도가 중요하지 않을 정도의 개발 능력을 갖춘 사람은 상위 1% 정도, 즉 100명 중에 한 명이 그정도 수준이 될까 말까다. 네이버 직원수에 비교하면 네이버 전체에 많아야 한 30~40명 정도? 즉, 1. 개발자로 오래 일하려면 일정 수준 이상의 개발 능력은 기본으로 탑재 되어 있어야 하고 2. 대부분은 태도가 중요하지 않을 정도의 능력자가 아니기 때문에 개발일을 직업으로가진 대부분의 사람들에..

길지 않으니 꼭 들어가서 원문을 읽어보세요! ----요약---- 📍 커밋 메시지를 잘 작성해야 하는 이유는 무엇인가요? 1. 커뮤니케이션의 효율성 증대 2. 문제 해결 속도 향상 3. 문서화의 기능 📍 어떻게 좋은 커밋 메시지를 작성하나요? 1. 앞단에 어떤 내용을 담은 커밋인지 커밋 유형을 지정합니다. 2. 다른 사람을 배려하기 위해서 자세하게 커밋 메시지를 작성합니다. 이때 commit body를 사용하면 세부적인 내용을 적을 수 있습니다. 이는 동료 개발자가 변경 사항을 더 잘 이해하는데 도움됩니다. 3. 커밋 메세지는 명령하거나 요청하는 어조를 사용합니다. 4. 불필요한 구두점 제거합니다. 5. 팀에서 정의한 '커밋 컨벤션'을 따릅니다. 출처 : 커리어리 '이장근'님 https://careerly..

애자일의 정의와 한계를 극복하기 위해 소프트웨어 장인 정신 이야기를 다룬 발표 자료가 있어 공유드립니다. 합의의 영역이 불분명하거나 프로세스가 모호하면 오히려 좋지 않은 방향으로 흘러간다는 점과, 개발도 결국 사람이 하는 것이기에 서로를 이해하고 맞춰가는 과정이 꼭 필요하다는 점이 특히 인상적이더라고요. 취업, 이직, 개발, 배포 등등 정신없는 일상 속에서 이런 내용의 글들을 읽으면서 잠시 스스로를 돌아보는 것도 좋지 않나 생각해 봅니다. 출처 : 커리어리 '권태관'님 https://careerly.co.kr/comments/83742?utm_campaign=user-share 권태관 / Software Craftsmanship 실천 가이드 ... | 커리어리 애자일의 정의와 한계를 극복하기 위해 소프트..

f-lab의 포스트를 가져왔습니다. 요약하자면 본인이 학습하거나 경험한 내용을 글로 잘 풀어내는 것이 중요한데요, 좋은 기술블로그의 예제도 같이 제공하니 읽어보시면 도움이 될 것 같습니다! 출처 : 커리어리 '강병진'님 https://careerly.co.kr/comments/83254?utm_campaign=user-share 강병진 / 면접관이 선호하는 개발블로그 | 커리어리 f-lab의 포스트를 가져왔습니다. 요약하자면 본인이 학습하거나 경험한 내용을 글로 잘 풀어내는 것이 중요한... careerly.co.kr 원 출처 : https://f-lab.kr/blog/developer-blog-tips 면접관 관점에서 본 좋은 개발자 블로그 개발자 블로그는 취업스펙이 되어버린 듯하다. 도움이 되면서 이..