@SoftyChoco Blog

최근 개발자들이나 취준생분들과 이야기를 나누다 보면 공통적으로 나오는 한숨 섞인 질문이 있습니다. "서류 통과조차 왜 이렇게 힘들까요?"제가 커리어를 시작할 때와 비교해 보면, 지금의 채용 시장은 단순히 '불황'이라는 단어로 설명하기엔 훨씬 더 복잡하고 가혹해진 것 같습니다. 하지만 냉정하게 시장을 들여다보면, 우리가 어디에 집중해야 할지 그 실마리가 보입니다.1. 이력서의 상향 평준화채용 공고 자체가 줄어든 것도 문제지만, 더 큰 문제는 불안감으로 인한 이력서 남발입니다. 취업자리가 줄어드니 불안해진 지원자들이 더 많은 곳에 이력서를 던지는데, 그 과정에서 AI의 힘을 빌려 문장을 매끄럽게 다듬습니다.채용 담당자의 책상 위에는 이제 잘 못 쓴 이력서가 많이 줄었습니다. 하지만 역설적으로 '진짜 실력이 ..

해당 이력서의 경우에는 취업 준비생의 이력서입니다. 기술스택은 모두 부트캠프에서 3달간 배운 것 밖에 없어서 다른 사람들의 이력서에 비해 부족한 부분이 너무 많았어요. 대신 노가다나 승선을 1년씩 진행했던 경험을 살려 이력서로 녹여내었습니다. 해당 이력서로 변경 전 500개의 기업에서 불합격 통보를 받았지만, 변경 후 일주일도 안되어 "서류 - 과제 - 면접"에서 과제 전형을 패스하고 바로 면접으로 진행되었습니다. 자신만의 경험이 없는 잘못된 이력서: https://softychoco.tistory.com/14

개요소프트웨어 개발 생명주기 모델 중 하나로 가장 고전적인 모델.각 단계가 순차적으로 진행되며, 다시 이전단계로 되돌아가기가 어렵기 때문에 "폭포수 모델"이라고 이야기 함.모델 구조가 간단하며 각 단계별로 산출물이 나오기 때문에 요구사항이 명확하고, 변경될 일이 없는 작은 프로젝트에 적합함.구성도타당성 검토 > 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수작업 방식타당성 검토기술적, 법적으로 문제가 없는지 검토하는 단계산출물: 타당성 검토 확인서계획프로젝트의 범위, 일정, 자원 등을 수립하는 단계산출물: 프로젝트 계획서요구사항 분석고객 요구사항을 분석하고, 명세하는 단계산출물: 요구사항 명세서설계요구사항 명세서를 기반으로 DB 구조, 시스템 구조 등을 설계를 진행하는 단계산출물: 시스템..

저는 면접관으로서 지원자를 만날 땐, 약점을 물어봅니다.이 질문에 지원자들의 흔한 답은, "생각을 못 해봤네요."나 "제 약점은 이러이러합니다." 라는 대답입니다.그나마 그중의 일부 지원자는, "제 약점은 이러이러 하지만, 이런 부분을 통해 개선하고 있습니다."와 같은 답변을 해서 자기 객관화와 성장 가능성을 어필하지만, 이 또한 반쪽짜리 답변입니다.왜 이런 답변이 '반쪽짜리'일까요?자기 객관화와 개선 의지는 분명 훌륭한 덕목입니다.하지만, 채용이라고 하는 것은 '지원자'만의 이야기가 아니라, '회사와 지원자가 어떻게 어우러지는지'를 알아보는 자리입니다.결국 위 답변들에서는 '우리 회사와의 연결고리'가 빠져있습니다.개인의 노력만으로 성장하겠다는 다짐은 어디에서나 할 수 있는 이야기입니다.그리고 그 답변은..

아직은 '바이브 코딩은 완성되지 않았다'라는 말들을 하지만, 저는 이미 충분한 역할을 하고 있다고 생각합니다. 직접 활용해본 결과, 앞으로의 프로덕트 팀의 구조는 이렇게 변하지 않을까? 라는 생각에 글을 한번 적어봅니다.현재의 바이브 코딩의 장점은 "빠른 생산성"이지만, 그에 대한 문제점으로는 "믿을 수 없는 안정성"에 있습니다. AI가 생성하는 결과물이 우리의 기대를 벗어나거나, 눈에 보이지 않는 오류를 포함하기 때문인데요. 이러한 문제는 단순히 더 좋은 AI를 기다릴 것이 아니라, 이에 맞춰 조직의 구조를 새롭게 변화시켜야 할 때라고 생각합니다.생산성과 안정성의 딜레마AI는 우리에게 명확한 기회와 위기를 동시에 제시했습니다.기회는 바로 '압도적인 생산성'입니다.아이디어 구상부터 실제 코드 생성까지의 ..

2025.01.09 - [생각 정리/개발] - 개발은 완벽하지 않아도 된다. 개발은 완벽하지 않아도 된다.예전의 나는 프로그램을 개발하면서 "완벽한 코드"를 작성해야 한다는 압박을 느껴왔다.하지만 과거의 경험을 돌아보면, 생각과는 다르게 복잡하거나 문제를 일으키는 코드가 되어있던 적이 있softycho.co영상에서는 특히 이런 질문들을 중심으로 이야기를 나눕니다.개발자에게 '완벽한 코드'란 무엇일까요?제품을 만드는 관점에서 '완벽함'보다 중요한 가치는 없을까요?우리가 완벽주의에 빠지는 이유는 뭘까요? 그리고 그게 때론 왜 위험할 수 있을까요?핵심은 "상황에 맞는 최적의 균형점을 찾는 것"이라는 점이에요.글로 전했던 메시지를, 좀 더 편하게 이해하기 쉽게 하기 위해서 팟캐스트로 제작했습니다.기존 글을 재미..

개발자라면 많은 트래픽을 받아보고 싶은 분들이 많을텐데요,정작 신입 이력서에서 요구하는 대규모 트래픽 경험을 도대체 어디서 얻을 수 있는지는 알기가 어렵습니다.기업에서 신입에게 어느정도의 선을 요구할지, 좀 더 명확하게 차근차근 알려드리겠습니다.당연하게도, 가장 이상적인건 직접 경험하는 것당연히 대규모 트래픽을 직접 경험해보았다면 가장 이상적이겠지만,이 글을 보시는 분들은 이런 대답을 원한게 아닐 것이라는 것쯤은 알고있습니다.그렇다면, 왜 이게 가장 이상적일지 생각해보신적이 있을까요?깊게 생각해보지는 않고 "단순히 동일한 경험이니까." 정도로 치부할게 아니라,대규모 트래픽을 경험해봤다는 것의 실제 의미는 시스템 운영 중에 트래픽으로 인한 부하가 될만한 지점(병목지점)을 인지하고 개선하는 것입니다.당연히 ..

목표를 세우려고 할 때 유튜브나 주변에서 이런 말을 들어본 적이 있을 겁니다."작은 성공부터 쌓아라."그런데, '작은 성공을 쌓는다고 변화가 있었으면, 왜 다른 사람들이 안 했겠어?' 라는 생각이나,"그렇게 작은 성공만 쌓는 게 정말 큰 변화를 가져올까?"라는 의문이 들 수 있습니다.또, 시작했더라도 작은 성공을 쫓다 보면 목표가 지루해지고 스트레스가 쌓이는 경우도 종종 있습니다. 작은 성공보다는 작은 재미를 추구하자저는 작은 성공을 쫒으려고 하지 않습니다.대신 "작은 재미"를 쫒아보려고 합니다."작은 성공"이란 우리가 달성해야 할 목표를 의미하지만, "작은 재미"는 그 목표를 향한 여정에서 즐거운 요소를 찾는 것입니다.어릴 때의 저를 회상해보았을 때, 어떤 것을 하든지 재밌다는 생각을 했던 것 같았습니..

해당 이력서는 펌웨어 관련 개발을 하셨던 분의 개선 전 이력서입니다. 자기소개를 보면 좋은 내용들이 있긴 하지만, 이력서 내에 좋은 내용들에 대한 사실을 뒷받침해줄 근거가 부족합니다. 기술스택은 무난하지만, 펌웨어 개발자에서 갑자기 백엔드 개발자로 전향하게 된 이유나, 프로젝트에 적힌 내용이 기술스택밖에 없다는 점. 또한 이력서 자체에 본인의 색깔이 확연하게 드러나지 않아서 낮은 점수를 받을법한 이력서라고 생각됩니다. 펌웨어 개발자를 하다가 백엔드 개발자를 하게 된 이유가 공부할 수 있는 범위와 자료의 한계, 즉 본인이 더 많이 배울 수 있는 환경을 찾기 위함을 충분히 어필하고, 펌웨어 개발자로써 지냈던 경력들을 활용하여 본인의 경험을 살려내면, 많은 장점이 나올 것이라고 생각됩니다. 그런 장점들을 자기..