@SoftyChoco Blog

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

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

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

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

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

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

첫번째, 개발을 하던 초기에는 프로젝트 마다의 고객의 요구사항을 따로 정리하지 않고 진행했던 적이 있다.다행히 동시에 진행되는 경우가 없고 대부분은 기억을 하고 있었어서 이로 인한 문제가 발생하지는 않았지만,지금 생각해보면 정말 돌이켜보면 위험했던 선택이다.하지만, 그러던 중 "요구사항 명세서" 라는 문서를 받고 하나하나 완료되었는지 체크하면서 일을 진행했더니 머리 속의 복잡한 것들이 모두 씻겨 내려가는 느낌을 받았다.이 때부터 나는 무언가를 하기 전, 프로젝트에서 어떻게 진행되면 좋을지, 계획을 정리하기 시작했다.두번째,어느정도 시간이 지나 나에게 작고 많은 일들이 주어지기 시작하면서, 계획을 정리하는 것을 소홀히 하기 시작했다.하나하나 작은 건이고, 계획을 정리하는 동안  완료하는게 더 빨랐으니까.그..

이번 사연자님은 이전 직장에서 소프트스킬이 부족한 것 같다. 소프트스킬을 기르면 좋을 것 같다. 라는 이야기를 들으신 분입니다. 우선 하드스킬과 소프트스킬의 차이점는 아래의 포스트를 읽어보시길 추천드립니다. https://asana.com/ko/resources/hard-skills-vs-soft-skills 예시로 살펴보는 직장에서의 하드 스킬 vs. 소프트 스킬 [2022] • Asana 하드 스킬과 소프트 스킬은 모두 우리가 직장에서 발휘하는 재능을 나타냅니다. 각각의 예시를 살펴보고 어떤 스킬을 개발해야 할지 생각해 보세요. asana.com 문제가 된다고 생각하는 부분은 아래와 같았습니다. 이력서에 쓸 때 잘 못쓰는 느낌을 받았다. 인성질문이나 일을 어떤식으로 하는지 물어봤을 때 답하기가 어렵다..

이번 사연자 분은 사이드 프로젝트를 진행하던 중에 포트폴리오로써 쓰기 위해서는 어떻게 하면 좋을지를 고민하시던 분이었습니다. 아마도 제가 이전에 어떤 이유에서 사이드 프로젝트를 하는지 근거를 명확하게 하라고 했던 것 같은데,,,(사실 기억이 잘 안납니다.) 뭐 어쨌든 근거를 명확하게 가져오신다고 가져오셨는데요. 사실 이 단계에서 이전에 대화했던 내용이 뭐였는지, 어떤 부분이 궁금한건지 이해가 잘 안되더라구요. 사연자님이 원하는 부분이 무엇인지에 대한 문맥을 찾고나니 뭔가 잘못된 부분이 발견되었습니다. 일반적으로 배우고 싶은 부분에 대해 정의를 하거나, 문제가 발생한 부분부터 개선이 시작되는데, 대화를 보면 아시겠지만 이미 배우고 싶은 부분에 대해 정의를 하고서는 해결방법까지 어느정도 제시가 되어있습니다...

요새들어 많이들 하시는 고민인 것 같습니다. 여기저기서 개발자 불황이다, 개발자 인력이 감축된다 하면서 대기업 마저도 구조조정을 진행하는 상황을 보며 많은 취준생들이 불안함을 겪고 있는데요. 사연자께서도 그런 이야기를 들으셨는지 걱정이 앞서셨던 것 같습니다. 서비스 회사로의 도전인데다가, 대전에서 서울로 올라갈 생각도 있으셨어서 아마 심적 부담감이 더욱 크셨던 것 같아요. 이런 경우 내가 생각하던게 실패했다고 생각해봅시다. 우선 직장을 다니고 있던 중 이직에 실패한다면? 그냥 다니시던 곳 다니면 됩니다. 그럼 퇴사를 먼저 해야할 것 같은데 이직에 실패한다면? 현재 수준의 회사에 다시 입사할 수 있을지를 생각해보세요. 만약 그것도 안된다면 이직을 준비하지 않는게 맞을 것 같습니다. 더 공부하셔야해요. 이직..