@SoftyChoco Blog

"모르는 거 있으면 편하게 물어보세요."팀장님은 편하게 질문하라는 듯이 이야기 해주시지만, 뭘 물어봐야할지, 어디까지 물어봐도 될지를 모르겠는 상황.나는 그저 막막하고, 질문의 수준이 너무 낮은건 아닌지 질문 하나하나가 걱정만 하는 중인데, 옆자리 동기 놈은 벌써 일을 마무리해가는 듯 합니다. 불안감과 조급함으로 인해 자신감도 바닥을 치게 되었구요.이런 경험, 한번 쯤은 있지 않으신가요?마치 안개 속을 걷는 것처럼 막막하고, 나만 뒤처질까 불안하신가요?괜찮습니다. 이건 내가 무능해서가 아닌 팀장의 잘못이고, 이 글을 읽고 난 뒤에는 뭘 물어봐야할지 아시게 될테니까요!당신은 지금 '시야 10%'로 슈퍼 마리오를 플레이하고 있습니다이 막막함은 마치 아래 슈퍼 마리오 게임을 하는데, 마리오 캐릭터 주변 10%..

종종 이력서에서 가독성을 챙겨야하기 때문에 1장으로 적어라, 2~3장으로 적는게 좋다라며 이야기하는 경우가 있다. 하지만, 나는 오히려 이력서를 길게 적기를 바라고, 이야기한다.물론, 내 역량을 충분히 보여주면서 가독성까지도 챙길 수 있는 2~3장짜리 이력서라면 누구라도 좋아한다.하지만 연차가 있는 사람들조차도 이력서에 자신을 제대로 어필하지 못한다.그런데 신입한테 짧은 이력서까지 바라는 건 말이 안된다고 생각한다.오히려 가독성을 챙긴다고 자신의 성과나 어필포인트를 잘못 생각하고, 경험을 너무 추상화를 해서 '이 사람이 그래서 뭘 한거지?'라는 생각이 들게 하는 경우가 훨씬 많다.차라리 자세히 적고, 길게 쓴 다음, 중요하게 생각하는 부분들을 진하게 처리라도 하자.색상 같은걸 넣어도 좋다. 자신이 회사에..

실패보다 최악인 것.나도 그랬지만, 실패를 두려워 하는 분들을 많이 본다.이걸 했다가 실패하면 흠이 생긴다고 생각하고,누군가가 욕할까봐 두려워서 그럴 수 있다.하지만 최악의 경우는 실패가 두려워서 아무것도 안하는 것이다.예를 들어 취업을 하는데, '저 곳은 내 실력으로는 가기 어려울꺼야'이직을 하고 싶지만, '내가 이 회사를 벗어날 수 있을까? 나보다 잘하는 사람이 훨씬 많겠지?'새로운 도전 기회가 있을 때도 '내 수준으로는 이런 일을 하기 어려울꺼야'이런 생각들은 우리를 아무것도 못하는, 그저 하던 것만 하도록 만드는 역할을 한다.도전하더라도 실패를 하면, 왜 실패를 했는지 회고하거나 그 상황을 다른 사람에게 물어봄으로써 성장하는 계기를 만들 수 있다.도전했는데 실력이 조금 부족했더라도, 운이 좋게 성..

팀장이 되기 위한 가장 빠른 방법은 개발 역량이 아닙니다.흔히 개발자의 성장 방식은 두가지로 나뉩니다.엔지니어링 역량을 높여 전문가가 되는 것과, 팀장으로써의 역량을 높여 팀을 이끄는 것이죠.엔지니어링 역량이야 시니어들을 보면서, 엔지니어링에 대한 컨퍼런스 등을 참고하면서,늘상 해오던대로 개발에 대한 역량을 높이고, 더 큰 문제를 해결하다보면 자연스럽게 이루어집니다.하지만 팀장의 경우, 어떤 역량을 키워야하는지 잘 모르는 경우가 많더라구요.하지만, 가장 빠르게 팀장을 달 수 있는 방법이 있습니다.바로 '팀장의 일을 모두 빼앗아가는 것'이에요.물론 자기 몫의 일은 해내는게 기본 값이겠죠?제가 이야기를 나눠봤던 분들 중에는, 자신의 팀장님이 어떤 일을 하는지도 잘 모르는 경우가 많았습니다.이건 대기업에 계신..

이력서의 상세 내용을 적을 때 개발처럼 생각하면 좋다.개발자가 흔히 반복되는 문제를 해결하기 위해 디자인 패턴을 사용하는 것처럼, 이력서에도 패턴이 존재한다.흔히 이야기하는 STAR 기법은 "어려웠던 일을 있는 그대로 전달하기 위한" 목적으로써 사용하는데, 해당 기법은 "문제 수준이 높은 과제"에서만 잘 먹힌다는 점이다.특히나 주니어 같은 경우에는 문제의 수준이 높은 경우가 많이 발생하지 않고, 실패가 많을 수도 있다. 그럼 어떻게 고민해보면 좋을까?디자인 패턴에 대해서도 많은 개발자들이 하는 말이 "디자인 패턴에 코드를 맞추지 말고, 코드를 효율적으로 짜다보면 자연스럽게 디자인 패턴과 맞춰진다" 라고들 한다. 마찬가지로 이력서도 "효율적"으로 작성하면 된다.어떤 이력서가 효율적일까? 이력서의 목적은 "..

실패한 경험을 숨기지 말자. 흔히 이력서에 "자신의 성과"만을 입력하고자 하는 사람들이 있다. 물론 충분히 연차가 있고, 그만한 실력이 있다면 그래도 괜찮다. 이미 여러 문제해결을 통해 실패를 했을 것이고, 그게 쌓였을 것이라고 보기 때문이다. 하지만, 저연차일수록 실패한 경험을 숨기는게 마냥 좋은게 아니다. 주로 저연차에게 원하는 것은 "성장속도"인데, 여기서 말하는 성장은 하드스킬의 영역만이 아니다. 실패에서도 배울 수 있는 사람인지, 실패해도 다시 일어날 수 있는 사람인지도 중요하다. 그렇다면 이런 실패한 사례를 어떻게 어필할 수 있을까? 과거로 돌아가 과거를 바꿀 수 없기 때문에, "만약 내가 다시 그 상황을 겪는다면"으로 생각하면 된다. 그리고 우리는 그것을 회고라고 부른다. 블로그에 회고를 해..

여러군데에 이력서를 넣고, 합격률을 확인하는건 대부분 의미가 없습니다. 흔히 개발자적인 생각에서 이력서를 고쳐가며, 이전 이력서는 합격률이 8%, 변경 이후 이력서는 합격률이 15%...와 같은 형태로 체크를 하시는 분이 있습니다. 하지만, 이게 너무나도 의미가 없다는 것을 알고 계신가요? 가장 큰 오류는 '회사의 성격', '채용 담당자'가 모두 다르다는데 있습니다. 어느 회사는 내 이력서에서 내 성실한 태도를 마음에 들어할 수도 있고, 어느 회사는 내 이력서에서 협업 능력을 마음에 들어할 수 있으며, 또 다른 회사는 내 이력서를 마음에 들어하지 않을 수 있다는 것이죠. 말하자면, 이력서와 회사 간의 합격률은 매번 다른 변수에서 실행되는 테스트 케이스입니다. 이런 테스트 케이스가 유효할리 없겠죠? 그렇다..

저는 멘토링도 익명으로 진행합니다. 흔히 멘토의 배경만 보고 '저 사람 말이 맞을꺼야' 라는 생각을 하는 분들이 꽤나 많기 때문에, 그런 '편한 사고'를 막기 위해, 제가 적는 내용을 의심하고, 직접 생각하게끔 하기 위해 그렇게 진행합니다.그러다보니, 제 멘토링은 일반적인 멘토링보다 시간이 오래걸릴 수 밖에 없습니다. 멘티의 경험담을 듣고, 어떤 부분이 좋은지/나쁜지를 고민하고, 왜 제가 그렇게 생각하는지를 논리적으로 설명하는데, 이 과정에서 '멘티가 이해할 때까지' 설명해야하기 때문이죠.그런데 이 과정에서, 간혹 유난히 시간이 많이 걸리는 케이스들이 있습니다. 이미 마음에 철벽을 많이 쳐버리신 분들이에요.'하지만 다른 사람은 이렇게 생각할꺼야' 라는 자기 비판을 가지고 있어서, 제가 이야기하는 내용이 ..

"경력이 없어 취업이 안 되고, 취업을 못 하니 경력이 없다."IT 업계에 뛰어든 신입과 주니어 개발자라면 이 말이 얼마나 뼈아프게 다가오는지 공감하실 겁니다. 과거 신입의 몫이었던 단순 반복 업무를 AI가 대체하기 시작하면서, 이제 막 커리어를 쌓으려는 이들의 입지는 점점 좁아지고 있습니다. 기업은 그 어느 때보다 'AI를 활용해 즉시 실무에 투입 가능한 인력'을 원하고 있죠.이처럼 암울해 보이는 상황 속에서, 우리는 어떻게 돌파구를 찾아야 할까요?저는 그 해답이 바로 '바이브 코딩(Vibe Coding)'에 있다고 생각합니다. 최근 IT 업계에서 주목받고 있는 이 개념은 단순히 AI가 코드를 대신 짜주는 것을 넘어, 아이디어 구상부터 완성까지 AI를 파트너 삼아 제품 개발의 모든 과정을 주도적으로 이..

이런 생각을 해보자. 어제까지는 막노동을 하던 사람이, 오늘 갑자기 기막힌 사업을 구상해서 성공할 가능성은 얼마나 될까? 아마 대부분은 불가능에 가깝다고 여길 것이다.왜 그럴까?단지 그 사람이 막노동을 하는 사람이라서가 아니다. 우리는 생략된 배경까지도 생각하여 판단한다. 막노동을 하는 사람은 먹고살기 힘들 것이고, 하루하루 일하는게 삶일테니까.물론, 100% 모든 사람이 그런 것은 아니다. 그럼 그들간의 차이는 어디에서 발생하는걸까? 우물 안 개구리이러한 상황은 분명 막노동을 하는 사람만의 이야기가 아니다.대부분의 사람들은 자신이 맡은 '역할'의 관점을 잘 벗어나지 못한다. 마치 우물 안 개구리처럼, 자신이 보고있는 하늘이 전부라 믿는 것처럼. 그 역할이 주는 안정감과 익숙함에 안주하면서, 다른 세상이..