@SoftyChoco Blog

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

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

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

개인적인 이유나, 이력을 위해 사이드 프로젝트를 시작해보셨던 적이 있나요?"이건 정말 잘 만들어봐야지!"라는 생각에 의욕이 넘치게 시작했지만, 어느 순간 흥미가 떨어지고 진행이 멈춰버린 경험이 있는 분들이 많으실겁니다.왜 이런 일이 생기는지 생각해보셨나요?오늘은 그 이유를 이야기해드리려고 합니다.마감 기한이 없어서학교의 과제나, 회사의 프로젝트는 마감 기한이 존재합니다.그 기한 안에 결과물을 내야하니, 어떻게든 시간에 맞춰 "현재 내가 아는 만큼의 지식"으로 해결하려고 노력합니다.하지만 사이드 프로젝트는 중요도가 상대적으로 떨어지다보니, 마감 기한이 없거나 너무 느슨한 경우가 많습니다.이런 경우에는 우선순위에 대한 고민을 하지 않고, 우선순위가 낮은 것에도 오랜 시간을 쏟는 경우가 많습니다.마감 기한을 ..

개발을 하다 보면 유난히 예상치 못한 오류가 자주 발생하는 사람들이 있다.특히 자신이 알고 있는 것이 항상 맞다고 믿는 사람일수록 그런 경향이 강했다.반대로 나는 내가 확신할 수 없는 부분에 대해서는 쉽게 믿지 않으려고 노력한다.이 글에서는 왜 개발할 때 "아무것도 믿지 않는 태도"가 중요한지에 대해 이야기해 보려고 한다.사람은 망각한다코드를 작성한 후 시간이 지나면 대부분의 개발자는 그 내용을 점점 잊어버린다.물론 기억력이 뛰어난 사람도 있지만, 보통 6개월 정도 지나면 자신의 코드라도 남의 코드처럼 느껴질 수 있다.그럼에도 불구하고 많은 개발자가 예전에 작성했던 코드를 완전히 이해하고 있다고 착각한다.특히 기존 코드와 연관된 기능을 추가할 때 이런 실수가 자주 발생한다.하지만 기억에 의존하면 실수가 ..

개발을 잘하고 싶어하는 분들이 자주 묻는 질문이 있습니다."설계는 어떻게 해야하나요?", "이런 설계가 정답인가요?"그리고 이런 질문에 대한 답변은 다양합니다.모놀리식 VS MSA로도 갈리기도 하고, kafka VS rabbitmq 로도 갈릴 수 있구요.케바케(case by case), 서비스에 따라 다르다 라는 말을 하는 사람도 있습니다.회사에서 서비스 개발을 하면서 수많은 선택을 하는데 있어서 설계에 대한 정답이 뭘까요?요리로 빗대어 생각해보자.직접 요리를 해드시거나, 하지 않더라도 음식은 누구나 먹겠죠?요리를 하지 않더라도 계란프라이 정도는 해보거나 드셔보셨을꺼에요.그럼 계란프라이를 만드는데 필요한 것은 무엇이 있을까요?대표적인 재료로는 계란, 식용유, 소금 등이 있습니다.자, 그럼 계란프라이를 만..

개발자들은 보통 하드 스킬에는 많은 신경을 쓰지만, 정작 업무 효율에 대해서는 깊이 고민하지 않는 경우가 많습니다.특히 신입 개발자일수록 이런 경향이 강하게 나타나죠.하지만 개발과 업무는 생각보다 비슷한 패턴을 보입니다.시스템에 부하가 생기는 경우?아무런 최적화가 없을 때 시스템에 부하가 생기는 원인은 다음과 같습니다.단순한 조회가 많을 때네트워크 요청이 많을 때CPU, 메모리, Disk I/O, 네트워크 등 시스템 자원을 많이 사용할 때그 외 기타...위에서 이야기한 내용들은 대부분 쉽게 개선이 가능한 영역입니다.캐시를 사용하거나, 요청 여러개를 묶어서(bulk) 요청하거나, 스케일 업 또는 스케일 아웃 하는 방법 처럼요. 이런 케이스는 간단하게 해결할 수 있는 부분을 업무적으로 봤을 때는 어떤 상황일..

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

내가 지금까지 거쳐온 회사는 지방의 작은 소기업부터 중소기업, 정부기관 파견, 그리고 판교의 서비스 기업까지 정말 다양하다.일반적인 관점에서는 판교의 서비스 기업이 성장의 기회와 배울 것이 가장 많을 것이라 생각하기 쉽지만, 내 경험은 조금 달랐다.어디서 가장 중요한 것을 배웠냐고 묻는다면 한 마디로 대답하기는 어렵지만, 가장 큰 교훈은 성장을 위해 '생각'이 필수적이라는 점이다.소기업에서의 성장: 시행착오신입 개발자로서 첫 발을 내딛었던 소기업.처음에는 단순히 "개발자가 되었다"는 사실만으로도 벅찼고, 내가 만든 코드를 통해 가치를 창출하고 돈을 번다는 것이 큰 자부심이었다.하지만 첫 번째 큰 프로젝트에서 현실의 벽을 마주쳤다.팀장이 제시한 요구사항을 맞추기 위해 매일 야근을 했지만 끝이 보이지 않았다..

예전의 나는 프로그램을 개발하면서 "완벽한 코드"를 작성해야 한다는 압박을 느껴왔다.하지만 과거의 경험을 돌아보면, 생각과는 다르게 복잡하거나 문제를 일으키는 코드가 되어있던 적이 있다.당연히 완벽한 코드가 좋은게 아닐까? 완벽하지 않아도 된다는건 무슨 뜻일까?개발자가 아닌, 프로덕트를 판매하는 입장에서 생각해보자개발자의 관점에서는 코드의 완벽함이 중요한 요소일 수 있다.그러나 프로덕트를 판매하는 입장에서 보면, 고객이 느끼는 가치는 코드의 완벽함이 아니라 그 프로덕트가 제공하는 혜택과 경험에 달려 있다.예를 들어, 출시가 늦어져 고객이 원하는 기능을 제때 사용할 수 없다면, 코드가 아무리 완벽하더라도 고객에게는 큰 의미가 없다.반면, 약간의 버그가 있더라도 고객이 필요한 문제를 해결하고 가치를 제공할 ..