셩잇님의 잡동사니

"목표를 이루기 위해 고민했다." 나의 목표는 기술적으로 뛰어난 개발자가 되어 억대 연봉을 받는 것이다. 어떻게 해야 뛰어난 개발자가 될 수 있고 이것을 인정받아 억대 연봉을 받을 수 있을까? 많은 고민 끝에 내린 결론은 매우 단순했다. 내가 내린 결론은 내가 다니는 기업에 '받은 것보다 더 많은 것을 주는 것'이다. 하지만 이 단순한 결론에 도달하기까지에는 많은 고민이 있었다. 고민을 하게 된 이유는 주변 사람들이 받은 만큼 일해야 한다고 말했기 때문이다. 내가 어떻게 이 단순한 결론에 도달하게되었는지 고민의 과정을 정리하는 포스팅이 될 것이다. 더 읽어보기 및 출처 : 티스토리 '초급에서 고급까지'님 https://jfbta.tistory.com/279 나의 가치를 향상 시키는 방법(부제: 내가 야근..

영상 내용을 요약해서 본문 게시글로 작성하려고 했는데, 이미 댓글로 정리되어 있어 이를 참조한다. 1. 지금 할 수 있는 일에 집중하기 (시간 낭비하지 않고 본질에 집중하기) 2. 꾸준히 질문하며 커뮤니케이션하기 (맥락을 파악하며 거시적으로 보기) + 만들 대상이 있다면 공부 범위가 확 줄어든다. 3. 알고 있다고 착각하지 말기 (메타인지 : 내가 무엇을 알고 무엇을 모르는지 아는 것) 설명할 수 있거나 아웃풋 할 수 있어야 아는 것이다. 4. 성장 마인드셋 탑재하기 능력과 한계는 고정적이지 않고 노력으로 향상시킬 수 있다. 절대로 모든 것을 다 알 수 없다. 그렇기에 모르는 것이 나올 때 좌절하기보다 성장할 수 있는 기회로 삼자. 모든 문제는 성장의 밑거름이다. 5. 일을 시간별로 쪼개고 우선 순위 리..

재미있는 영상이다. 영상을 요약하자면 '취업하기 위해선 기술적인 능력이 필요하다.'로 보면 될 것 같다. 출처 : 유튜브 스칼라의 IT직업충전소님 https://www.youtube.com/watch?v=v1kxbDq1zT4&t=18s&ab_channel=%EC%8A%A4%EC%B9%BC%EB%9D%BC%EC%9D%98IT%EC%A7%81%EC%97%85%EC%B6%A9%EC%A0%84%EC%86%8C

본문은 요즘IT와 번역가 Chase가 함께 조쉬 코모(Josh Comeau)의 글 을 번역한 글입니다. 필자인 조쉬 코모는 언스플래쉬, 칸 아카데미 등에서 일했고 현재는 웹사이트 Joshwcomeau.com를 운영하며 리액트, CSS, 애니메이션 등에 대한 다양한 아티클과 강의를 제공하고 있습니다. 이 글은 개발자로서 새로운 기술을 빠르게 습득하는 방법을 다루고 있습니다. 필자에게 허락을 받고 번역했으며, 글에 포함된 각주(*표시)는 ‘번역자주’입니다. 글에 포함된 링크는 원문에 따라 표시했습니다. 더 읽어보기 및 출처 : 요즘 IT의 번역글 https://yozm.wishket.com/magazine/detail/2334/?utm_source=stibee&utm_medium=email&utm_campa..

들어가며 이번 글에서는 지난 3년간 개인 기여자(Individual Contributor, IC)가 아닌 한 명의 리더로서 좋은 리더란 무엇인지, 또 좋은 리더가 되려면 어떤 역량이 필요한지에 스스로 고민해 봤던 내용에 관해 적어보려고 한다. 아무리 기여자로서 일을 잘했던 사람이라고 해도 이 경험이 좋은 리더로서의 역량으로 이어지리란 법은 없기 때문에 자연스럽게 이런 고민을 시작하게 되었다. 많은 개발자들이 리더나 매니저 역할을 맡게 되면, 어렵다고 느끼는 부분이 컴퓨터와 다르게 인간은 생각보다 논리적으로 행동하지 않는다는 점에서 기인한다. A라는 명령을 내리면 그대로 A라고 알아듣고 수행하는 컴퓨터와 다르게 인간은 A라고 이야기했을 때 곧이곧대로 A라고 이해하는 경우가 거의 없다. 인간은 각자 자라온 ..

주니어 시절 가장 어려웠던 건 ‘어떻게 자기 계발해야 하는지’ 방법을 몰랐다는 것이었다. 주변에 물어볼 만한 선배나 동료가 많지 않았고, 요즘처럼 다양한 플랫폼에서 직무 관련 많은 정보를 얻기도 쉽지 않았기 때문이다. 그래서 무작정 검색도 해보고, 주변에 참고할 만한 기획안을 요청해 보기도 하고, 서점에 가서 책도 읽었다. 관련 온/오프라인 세미나도 꾸준히 다니며 다양한 노력을 했다. 그렇게 성장에 목말라하던 나도 이제는 IT업계에서 일한 지 벌써 10년이 넘었다. 지금은 주변에 선배, 동료, 후배들도 많고, 자연스럽게 알게 되는 업계 소식도 많아졌다. 그래서 주니어 때만큼 성장에 목말라하지 않지만, 배움엔 끝이 없으니 멈추지 않고 정진하고 있다. 하지만 주니어 시절, 누군가 나에게 성장하는 방법을 알려..

나는 지난 몇 년간 개발자를 코칭하며 ‘프론트냐 백엔드냐’를 고민하는 당신에게, 개발자를 코칭하며 배운 7가지, 장애는 우리의 문제다 등의 글을 썼다. 코칭 과정에서 개발자들이 성장에 대해 관심이 많다는 것을 알 수 있었다. 관심이 많은 만큼이나 스스로 성장이 정체된다고 느꼈을 때 고민이 크다. 하지만 안타까운 점은 자신이 왜 정체되는지 원인을 잘 찾지 못한다는 것이다. 나는 연차가 많아도 실력은 3~4년 차 정도에 머무는 사람들을 자주 본다. 이런 사람들의 공통적인 특징은 학습하려 하지 않고 변화를 좋아하지 않는다는 것이다. 왜 그렇게 되었을까? 내 나름대로 추정해 보면 성장이 정체되었다고 느꼈을 때 원인을 찾지 못하고(않고), 성장이 멈춘 채 시간이 흘렀을 것이다. 성장하지 못했다는 불안감은 점점 익..

좋은 동료가 되기 위한 10가지 방법 제가 수구를 처음 배울 때에, 코치가 해줬던 말이 잊혀지지 않습니다. 그는 “뛰어난 선수는 주변 선수들을 뛰어난 선수처럼 보이게 한다.” 라고 했습니다. 뛰어난 선수는 잘못된 던지기를 예상하고 미리 움직여 어떤 패스라도 잡을 수 있습니다. 뛰어난 선수가 공을 다시 패스할 때는 다른 사람이 쉽게 잡을 수 있도록 공을 던집니다. 오늘날의 소프트웨어 개발은 팀 스포츠와 같습니다. 수구에서와 같이 뛰어난 소프트웨어 시스템은 혼자서 만들 수 없습니다. 그래서 처음 10배 뛰어난 엔지니어에 대한 컨셉을 들었을 때는 혼란스러웠습니다. 어떻게 한 명의 뛰어난 사람이 팀웍을 이길 수 있을까? 제 경험상 성공을 위해 각 개인의 뛰어남은 필수 요소지만, 충분 요소는 아니었습니다. 개개인..

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

필자는 스타크래프트에 한글 지원 기능을 제작한 박종천 개발자이며, 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배의 엔..

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

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

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

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

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

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

조금 과장하여, 기술 면접용 바이블이라 불릴 만한 콘텐츠를 소개합니다. 어느날 전직 메타 스태프 엔지니어인 양 순 개발자는 이직을 준비하는 바쁜 동료 엔지니어를 도와주고 싶어 리트코드에서 문제들을 추리기 시작합니다. 그리고 블라인드에 페이스북 개발자 기출문제 75선 (수능 같은 표현이긴 합니다) 선별해 블라인드에 공유합니다. 해당 게시글은 한동안 인터넷 개발자 커뮤니티를 뜨겁게 달궜습니다. 자신감을 가진 그는 십여 년 넘는 경험과 지식이 농축된 온라인 책을 무료로 출판하게 됩니다. 그 책이 바로 "기술 인터뷰의 모든 것: 기술 인터뷰 핸드북"입니다. 은밀한 업계 고급 정보를 이렇게 무료로 만들어주시다니, 코딩으로 밥먹고 살아가는 저와 같은 개발자는 한 줄기의 빛을 본 기분입니다. 이제 면접 '카더라' 통..

개발자, 디자이너, 사업가, 기획자, 예술가 그 영역과 직업을 떠나서 특정 레벨 이상의 성취를 만든 사람들이 중요하게 생각하는 것이 무엇인가를 듣다보면 결국 '가치'라는 개념으로 수렴하게 된다고 느낍니다. 기술 자체가 중요한 것이 아니라, 돈 자체가 중요한 것이 아니라, 자원 자체가 중요한 것이 아니라 정말로 사람들에게 필요한 것이 무엇인가에 대한 질문을 던지고 있다는 느낌을 받습니다. 그런데, 여기서 가치라는 개념을 제가 오래 전에 이해하기로는 유저의 수, 서비스라면 서비스를 접속하는 유저의 리텐션, 유료화 고객의 수, 이런 것들이라고 생각을 했는데요. 요즘 들어서는, (계속 비슷한 이야기만 듣다보니) 가치라는 개념이 단순 보이는 데이터들 이상의 것으로 드러나지 않나 싶습니다. 어찌보면 철학의 개념으로..

회사 입장에서 어려움 점을 이해해 보고 주니어 개발자가 꼭 알아야 할 점을 파악해 봅니다. 1️⃣ 주니어 개발자는 1, 2년의 투자 기간이 필요하다 최소 1, 2년 정도 한 사람에게 투자할 수 있는 팀이 아니라면 주니어 개발자를 고용하지 않는 것이 좋다. 특히 투자자들에게 결과물을 빨리 내야 하는 스타트업에는 적합하지 않은 고용 방법일 수 있다. 2️⃣ 그들에게는 경력이 많은 관리자가 필요하다 경력이 없거나 자질이 없는 관리자는 주니어 개발자를 고용하거나 멘토 할 수 없다. 주니어 개발자를 고용하려면 경력이 풍부한 관리자가 필요하다. 3️⃣ 잘 정의된 업무만 줄 수 있다 주니어에게 몇 주 만에 결과물을 내야 하는 업무를 줄 수 없다. 따라서 팀은 최소 6개월에서 12개월 안에 결과물을 낼 수 있는 프로젝..