@SoftyChoco Blog

흔히 취준생, 주니어 분들이 많이 고민하는 부분입니다. 이곳 저곳에서 "개발자는 기초가 중요하다!"라고 하지만, 기초라고 하는 것들이 너무나 다양하고 많습니다.자료구조, 알고리즘, CS, 네트워크... 답변해주는 사람마다 "여기부터 여기까지가 기초다"라고 하는 부분이 모두 다르고, 아무리 공부를 해도 내가 모르는 것들을 아는 사람을 만나면 '저 사람은 정말 대단하다'라는 생각과 '아직도 내가 모르는게 남았구나'라는 생각에 좌절감만 듭니다.대체 어디까지가 기초이고, 언제까지 공부만 해야할까요?제가 가장 추천드리는 방법은 이것입니다. '개발의 기초'를 배우려고 하지 말고 '특정 도메인의 기초'에 집중해보세요.왜 '도메인'이 중요할까요?모든 산업에서 동일한 기술과 지식을 요구하지 않습니다. 내가 가고 싶은 곳..

혹시 불안해서, 다른 역할을 하고싶은 생각이 든적 있나요?간혹 자신의 업무가 맞지 않다고 생각해서, 다른 역할이나, 다른 업종으로 바꾸는게 답이라고 생각하는 분들을 만나곤 합니다.흔히 이야기하는 상황은 이렇습니다.다른 사람들과 협업하는게 너무 어려워, 그냥 나 혼자 일할 수 있는 직무로 바꿔야하나?내가 다른사람들에 비해 기술적으로 너무 부족한 것 같은데, 누구나 다 아는 건데 나만 모르는 것 같아...이쯤 되면 그냥 개발자가 나랑 안맞는걸까? IT 업계를 떠나야하나...사실 이런 고민은 생각보다 많은 분들이 하고 있습니다.새로운 도전을 위해 직무를 바꿔보려는 것 이라면 좋은 일이지만, 단순히 불안감을 회피하기 위해서라면 조금 더 생각해볼 필요가 있습니다.사실 이런 고민들이 드는 이유는 단지 불안감으로 인..

혹시, '걸어 다니는 자기계발서' 같은 리더와 일하고 계신가요? 마치 자신의 상황이나 운은 생각하지 않고, 그저 자신처럼 하면 무조건 성공한다고 이야기하는 그런 자기계발서 같은 리더 말이에요. "나는 이렇게 성공했으니, XX님도 할 수 있습니다." "제가 예전에 겪은 압박에 비하면 이건 아무것도 아니에요. ㅎㅎ" 이런 말들, 혹시 익숙하지 않으신가요? 선의로 포장되어 있지만, 어쩐지 나를 작아지게 만드는 말들이죠. 많은 리더들이 자신의 성공 경험을 바탕으로 팀을 이끌어가지만, 그 중 일부는 자신만의 성공 방정식을 '유일한 정답'으로 여기는 경우가 있습니다. 그들의 세상에서는 자신의 성공에 기여했던 수많은 맥락들은 지워지고, 오직 '개인의 의지와 노력'만이 남는 경우가 있습니다. 그리고 큰 실패 경험이 없..

이전 작업에서는 어떤 목적으로, 어떤 기능을 개발할지에 대한 정의와 MVP 기획안을 작성하고,작성된 기획안을 기반으로 v0.app을 이용하여 디자인 초안을 잡았습니다.아직 여전히 디자인이 마음에 들지 않는 상태인데, v0.app을 무료로 활용하다보니 무료 크레딧 5달러가 소진이 완료되어버렸더라구요.그래도 초안으로 쓰기엔 적당한 수준의 디자인이라고 생각해서, 여기서부터는 커서AI를 활용해서 작업을 진행하였습니다.제 경우에는 커서를 사용할 때 docs 폴더에 기획, 디자인 가이드, 컨벤션 등을 마크다운 파일로 먼저 생성하고, 그걸 기반으로 어떤 역할로써 개발을 진행할지를 정의하는 커서 룰(mdc)를 만듭니다.여기서 초기에 작성하는 기획, 디자인 가이드는 기존에 이야기 나누었던 제미나이에게 '커서에 제공할 기..

평소 글을 적기 위한 아이디어나, 집안일, 구매해야하는 물품, 업무 등 할일들이 많은 상황에서, 금방금방 떠올리지 못하는 문제를 겪었다.시중에 나와있는 투두리스트는 많지만, 내가 가장 원하는 기능은 '최대한 쉽고 빠르게, 다시 떠올릴 수 있는 간단한 문맥을 입력'이었고, 이를 해결해주는 앱을 찾지는 못했다.이런 목적으로, 사이드 프로젝트를 진행해보기로 했다.먼저 Gemini를 통해 아이디어 구상을 진행한다.이 때, 대화를 나누는 세션은 Gemini에서 Gem이라는 역할을 지정하여 사용하는 세션으로, 아래와 같은 요청사항이 기입되어있는 상태이다.목표 및 역할:* 사용자의 아이디어를 듣고, 새로운 IT 서비스 기반 스타트업을 위한 전문적인 조언을 제공합니다.* 비즈니스 모델, 시장 분석, 기술적 타당성, 마..

좋은 질문을 위해 '목표와 맥락'을 자세하게 설명해야 한다고 이야기 했습니다. 하지만, 회사에서 모든 목표와 맥락을 이야기 하는건, 시간을 낭비하는 행위이기도 합니다. 오늘은 소통의 효율을 높여주는 '맥락 생략'에 대해 이야기해보려고 합니다. 이 방법의 핵심은 우리 팀을 하나의 거대한 'CDN' 으로 이해하는 것입니다. 프로젝트 킥오프, 디자인 시스템 공유, API 명세 리뷰 과정은, 전 세계 Edge 서버에 정적 데이터를 미리 배포하는 과정과 같습니다. 피그마 링크, 컴포넌트 규격, API 엔드포인트 같은 정적 데이터들이 각 팀원의 머릿속, 즉 Edge 서버에 캐싱되는 것이죠. 이렇게 CDN이 완벽하게 준비되면, 우리의 질문 방식은 완전히 달라져야 합니다. 1. 매번 Origin 서버에 요청하시겠습니까..

혹시 "카프카 요즘 어떤가요?"처럼 모호한 질문을 하고 계신가요? 질문이 어렵다면, "이것"을 기반으로 질문해보세요! 동료나 기술 커뮤니티에 "혹시 Nginx 써보셨어요?", "요즘 MSA는 어떻게 하나요?" 와 같은 질문을 던져본 적 없으신가요? 이렇게 용기 내어 한 질문에 "질문 좀 제대로 부탁드려요!", "무슨 상황인데요?" 라는 말이 돌아오는 경우가 많습니다. 이런 모호한 질문은 답변자의 시간을 빼앗고, 결국 내가 원하는 답을 얻지 못하게 만듭니다. 질문이 막막하게 느껴진다면, 단순히 기술 이름을 던지는 대신 다음 항목을 채워서 질문을 다시 만들어보세요. 1. 목표: 내가 이걸로 무엇을 하고 싶은가? - "대규모 트래픽을 안정적으로 처리하기 위한 메시지 큐 도입을 검토하고 있습니다." 2. 맥락..