@SoftyChoco Blog

요즘 서류 합격, 왜 이렇게 벽처럼 느껴질까요?

@SoftyChoco — Sat, 28 Feb 2026 23:32:24 +0900

최근 개발자들이나 취준생분들과 이야기를 나누다 보면 공통적으로 나오는 한숨 섞인 질문이 있습니다. "서류 통과조차 왜 이렇게 힘들까요?"

제가 커리어를 시작할 때와 비교해 보면, 지금의 채용 시장은 단순히 '불황'이라는 단어로 설명하기엔 훨씬 더 복잡하고 가혹해진 것 같습니다. 하지만 냉정하게 시장을 들여다보면, 우리가 어디에 집중해야 할지 그 실마리가 보입니다.

1. 이력서의 상향 평준화

채용 공고 자체가 줄어든 것도 문제지만, 더 큰 문제는 불안감으로 인한 이력서 남발입니다. 취업자리가 줄어드니 불안해진 지원자들이 더 많은 곳에 이력서를 던지는데, 그 과정에서 AI의 힘을 빌려 문장을 매끄럽게 다듬습니다.

채용 담당자의 책상 위에는 이제 잘 못 쓴 이력서가 많이 줄었습니다. 하지만 역설적으로 '진짜 실력이 있는 사람'을 가려내기는 더 힘들어졌죠. 그래서 회사는 전형을 길게 늘리거나, 라이브 코딩을 더 빡빡하게 잡고, 레퍼런스 체크에 열을 올립니다. 검증 비용이 올라가니 서류 필터링은 더 보수적으로 변할 수밖에 없어요.

2. AI가 흉내낼 수 없는 지점

이런 상황에서 무작정 이력서를 수백 군데 뿌리는 '물량 공세'는 오히려 독이 됩니다. 저는 오히려 '한 놈만 팬다'는 식의 집요함이 필요하다고 봅니다. AI가 아무리 문장을 예쁘게 만들어도 절대 흉내 낼 수 없는 부분이 있기 때문이죠.

주장: "너희가 찾는 사람이 바로 나다"라는 확신과 그에 대한 주장.
근거: 그 주장을 뒷받침 해줄 수 있는, 실패와 성공을 통한 나의 경험 어필.
태도: "왜 꼭 이 회사여야만 하는가"에 대한 개인적인 동기.

"너네가 찾는 사람이 나야(주장), 왜냐면 이런 경험이 있거든(근거), 그리고 난 너희랑 이런 이유로 함께 일을 꼭 해보고 싶어(태도)." 이 삼박자가 맞는 글은 수천 개의 AI 이력서 사이에서도 반드시 빛이 납니다. 이력서만 읽어도 납득이 가거든요.

3. 확률을 높이는 방법

모든 공고에 이렇게 공을 들이긴 어렵습니다. 그래서 저는 세 가지 전략을 추천합니다.

첫째, 도메인을 좁히세요.
핀테크면 핀테크, 커머스면 커머스. 특정 도메인을 따라가면 내가 가진 기술적 자산이 그대로 이어집니다. 수정할 부분은 줄어들면서 전문성의 농도는 짙어지죠.

둘째, 내가 가진 경험을 템플릿화 하세요.
모든 사람이 도메인을 좁게 가져갈 수는 없습니다. 그런 경우에는 '주도적인 분', '커뮤니케이션이 원활하신 분', '대규모 트래픽을 경험해보신 분'처럼, 각 키워드에 대한 경험을 이력서를 적을 때 마다, 별도로 키워드 - 경험을 매칭한 템플릿을 만들어보세요. 다른 공고에서 같은 키워드가 나왔을 때, 각각의 키워드에 맞는 경험을 가져다 붙이는 것 많으로도 많은 시간을 절약할 수 있습니다.

셋째, 주도적으로 문을 두드리세요.
공고가 뜨길 기다리는 게 아니라, 커피챗을 제안하거나 지인 추천을 활용하는 등 '사람'에게 직접 닿으려 노력해야 합니다. 지금처럼 시스템이 꽉 막힌 시기일수록, 시스템 밖에서 일어나는 연결이 훨씬 강력한 힘을 발휘합니다. 특히나, 면접에서 바라보는 지원자의 경험은 면접관의 질문에 맞는 부분만 보여지지만, 커피챗에서의 대화는 나를 좀 더 입체적으로 보여줄 수 있는 자리입니다.

합격은 확률의 총합

이런 노력을 한다고 해서 "반드시 합격한다"는 보장은 없습니다. 하지만 확실한 건, 이런 고민의 흔적 하나하나가 모여 나의 합격 확률을 1%에서 10%로, 다시 50%로 점차 끌어올린다는 사실입니다.

실패해도 다시 도전하고, 그 실패마저도 다음 이력서의 '근거'로 삼는 사람이야 말로, 결국 합격할 수 있는 주도적인 사람입니다.

계속 서류 탈락만 하고 있다면, 다시한번 이력서를 살펴보세요. "내 이력서에는 나의 주장, 근거, 동기가 충분히 담겨있을까?"

SayDo.me 개발 2

@SoftyChoco — Sun, 30 Nov 2025 19:54:23 +0900

이전 작업에서는 어떤 목적으로, 어떤 기능을 개발할지에 대한 정의와 MVP 기획안을 작성하고,
작성된 기획안을 기반으로 v0.app을 이용하여 디자인 초안을 잡았습니다.

아직 여전히 디자인이 마음에 들지 않는 상태인데, v0.app을 무료로 활용하다보니 무료 크레딧 5달러가 소진이 완료되어버렸더라구요.
그래도 초안으로 쓰기엔 적당한 수준의 디자인이라고 생각해서, 여기서부터는 커서AI를 활용해서 작업을 진행하였습니다.

제 경우에는 커서를 사용할 때 docs 폴더에 기획, 디자인 가이드, 컨벤션 등을 마크다운 파일로 먼저 생성하고, 그걸 기반으로 어떤 역할로써 개발을 진행할지를 정의하는 커서 룰(mdc)를 만듭니다.

여기서 초기에 작성하는 기획, 디자인 가이드는 기존에 이야기 나누었던 제미나이에게 '커서에 제공할 기획을 마크다운으로 생성해줘.' 와 같은 프롬프트로 입력하여 나온 결과물을 일부 수정하여 활용합니다.

이렇게 기획, 디자인, 컨벤션 등의 마크다운이 생성되었다면, 커서 내에서 해당 파일들을 참조한 뒤, 아래와 같은 프롬프트로 커서룰 파일을 만듭니다.

너는 Next.js를 전문적으로 작업을 하는 시니어 개발자야.
아래의 내용을 기반으로 역할을 프롬프트로 작성하고, developer.md 파일로 작성해줘.

@docs/director.md와 @docs/design.md, @docs/convention.md, @docs/change.md 를 기반으로 사용자가 요청한 수정작업을 진행하고, 업데이트 된 내용은 @docs/change.md 파일에 수정사항을 간략하게 작성해야해 (추후 맥락을 확인할 수 있도록)

이렇게 작성된 md 파일을 커서 룰(mdc 파일)로 변경한 뒤, 매 프롬프트 세션 시작 시 활용합니다.

그리고 그렇게 조금씩 수정해나간 결과물입니다.

초반에 비해 디자인이나 기능이 많이 추가되었습니다.
초반에는 커서에서 Claude Sonnet 4.5 모델을 이용했지만, 금방 사용량이 만료되어 90% 이상 Auto 모드로 작업했던 것 같습니다.
예전에 비해 Auto 모드의 성능이 많이 올라가서, 무제한으로 사용할 수 있다는 점에서 굉장히 메리트 있다고 생각합니다.

이렇게 "마트에서 달걍 구매하기"라고 이야기하면, '장보기' 탭에 '달걀 구매하기' 라는 할일로 저장됩니다.

아래는 해당 서비스의 README.md 입니다.
아직 구현되지 않은 동작은 취소선을 그어두었습니다 :)

SayDo.me

말하고 바로 실행한다 - 초스피드 음성 캡처 및 AI 자동 분류를 통한 할일 관리 PWA

프로젝트 소개

SayDo.me는 바쁜 사람들을 위한 음성 기반 할일 관리 애플리케이션입니다. Context Switching을 최소화하고, 음성으로 빠르게 할일을 캡처하고 AI가 자동으로 분류 및 처리합니다.

핵심 가치

초스피드 캡처: 음성으로 즉시 할일 기록
AI 자동 분류: 음성 인식 결과를 AI가 분석하여 카테고리, ~~우선순위~~(예정), ~~예상 소요 시간~~(예정) 등 자동 추출
업무 흐름 방해 최소화: 플로팅 버튼으로 언제 어디서나 빠른 접근

✨ 주요 기능

음성 인식

실시간 전사: 녹음 중 실시간으로 텍스트 확인 가능
브라우저 네이티브: Web Speech API를 활용한 빠른 음성 인식
자동 폴백: 동작 환경에 따라 자동으로 최적의 음성 인식 방식 선택(서버 작업 예정)

AI 자동 처리

자동 분류: 음성 내용 기반 분류 자동 할당
메타데이터 추출:
- ~~우선순위~~
- ~~예상 소요 시간~~
- ~~마감 시간~~
- 태그
자연어 처리: "마트에서 계란 구매하기" 같은 자연스러운 음성 입력 지원

PWA (Progressive Web App)

홈 화면 추가: 모바일에서 앱처럼 설치 가능
모바일 우선 디자인: 모든 기기에서 모바일 앱과 같은 경험 제공

게이미피케이션

보상 시스템:
- 환영 선물(AI 사용량 30회)
- 시간 보너스 (3~4시간 간격, AI 사용량 3~10회)
- PWA 설치 보너스(AI 사용량 20회)
사용량 표시: 헤더에 AI 사용량 실시간 표시

분류 관리

탭 기반 필터링: 전체, 장보기, 집안일, 업무 등 분류별 할일 관리
드래그 앤 드롭: 분류 순서 변경
커스텀 분류: 사용자 정의 분류 생성

검색 기능

실시간 검색: 할일 내용을 빠르게 검색

시작하기

첫 사용하기

로그인: Google 계정으로 간편 로그인
음성 녹음: 우측 하단의 녹음 버튼( )을 눌러 할일을 말하기
자동 분류: AI가 자동으로 분류와 메타데이터를 추출하여 할일 생성

사용 방법

할일 추가하기

우측 하단의 녹음 버튼( ) 클릭
할일을 자연스럽게 말하기 (예: "마트에서 계란 구매하기", "설거지하기")
녹음 중 실시간으로 보여지는 텍스트 확인
녹음 완료 후 자동으로 할일이 생성됨

할일 관리하기

완료 처리: 할일 왼쪽의 체크박스 클릭
수정하기: 할일 오른쪽의 수정 버튼 클릭하여 내용 수정
분류 변경: 수정 모달에서 분류 선택
검색: 상단 검색바에서 할일 검색

분류 관리하기

탭 전환: 상단 탭을 클릭하여 분류별 할일 필터링
분류 순서 변경: 설정 페이지에서 드래그 앤 드롭으로 순서 변경
새 분류 추가: 설정 페이지에서 커스텀 분류 생성

보상 받기

환영 선물: 최초 환영 선물 제공
시간 보너스: 3~4시간 간격으로 선물 상자( ) 아이콘 활성화
PWA 설치 보너스: 앱 설치 시 추가 보너스 제공
사용량 확인: 헤더의 로봇 아이콘( )으로 남은 사용량 확인

디자인 컨셉

SayDo.me는 미니멀리즘을 추구합니다.

깔끔한 흰색 배경: 집중력을 높이는 미니멀한 디자인
단일 포인트 컬러: 초록색으로만 강조하여 시각적 집중도 향상
명확한 위계: 굵은 텍스트로 정보의 중요도 구분
부드러운 모서리: 16px 라운드로 현대적이고 부드러운 느낌

❓ 자주 묻는 질문 (FAQ)

Q. 어떤 브라우저를 사용해야 하나요?

A. Chrome 또는 Edge, Safari 등의 브라우저를 권장합니다. Web Speech API를 완전히 지원하는 브라우저에서 최적의 경험을 제공합니다.

Q. 사용량이 부족하면?

A. 시간 보너스(3~4시간 간격)와 PWA 설치 보너스를 받을 수 있습니다. 또한 피드백을 보내주시면 추가적인 사용량을 제공해드릴 수 있습니다.

기술 스택

SayDo.me는 아래와 같은 기술로 구축되었습니다:

Frontend: Next.js 16, React 19, TypeScript
UI: Tailwind CSS, Radix UI
인증: NextAuth.js (Google OAuth)
AI: Google Gemini
Storage: Cloudflare R2

피드백 및 문의

SayDo.me는 지속적으로 개선되고 있습니다.

피드백 제출: 앱 내 설정 페이지에서 피드백(버그 신고, 기능 제안)을 보내주세요.

SayDo.me 개발 1 - 음성 입력 할일 관리 앱 개발 시작

@SoftyChoco — Wed, 26 Nov 2025 00:21:57 +0900

평소 글을 적기 위한 아이디어나, 집안일, 구매해야하는 물품, 업무 등 할일들이 많은 상황에서, 금방금방 떠올리지 못하는 문제를 겪었다.
시중에 나와있는 투두리스트는 많지만, 내가 가장 원하는 기능은 '최대한 쉽고 빠르게, 다시 떠올릴 수 있는 간단한 문맥을 입력'이었고, 이를 해결해주는 앱을 찾지는 못했다.
이런 목적으로, 사이드 프로젝트를 진행해보기로 했다.

먼저 Gemini를 통해 아이디어 구상을 진행한다.

이 때, 대화를 나누는 세션은 Gemini에서 Gem이라는 역할을 지정하여 사용하는 세션으로, 아래와 같은 요청사항이 기입되어있는 상태이다.

목표 및 역할:

* 사용자의 아이디어를 듣고, 새로운 IT 서비스 기반 스타트업을 위한 전문적인 조언을 제공합니다.
* 비즈니스 모델, 시장 분석, 기술적 타당성, 마케팅 전략 등을 종합적으로 고려하여 현실적이고 구체적인 피드백을 제시합니다.
* 사용자가 성공적인 창업을 위해 어떤 부분을 더 고민하고 준비해야 하는지 명확하게 알려줍니다.

행동 및 규칙:

1) 초기 대화:
a) 사용자의 아이디어를 경청하고, 해당 아이디어가 어떤 문제를 해결하려는지, 어떤 고객을 대상으로 하는지 질문합니다.
b) 사용자의 아이디어가 불명확할 경우, 추가적인 질문을 통해 구체화할 수 있도록 돕습니다.
c) 대화는 전문적이면서도 친근한 어조로 진행합니다. 한 번에 최대 2개의 질문만 하고, 사용자의 답변을 충분히 이해한 후 다음 질문으로 넘어갑니다.

2) 조언 및 피드백:
a) 사용자의 아이디어에 대해 시장성, 기술적 타당성, 수익 모델, 경쟁 우위 등 다양한 관점에서 분석하고 평가합니다.
b) 긍정적인 부분과 개선이 필요한 부분을 명확하게 구분하여 설명합니다.
c) 조언은 '이런 부분을 고려해 보세요'와 같이 제안하는 방식으로 제공하며, 사용자의 선택을 존중합니다.
d) 복잡한 개념은 쉬운 비유나 사례를 들어 설명하여 사용자가 쉽게 이해할 수 있도록 합니다.

3) 추가 정보 제공:
a) 사용자가 궁금해하는 특정 분야(예: 투자 유치, 팀 빌딩, 법률 문제)에 대해 관련 자료나 참고할 만한 정보를 제공합니다.
b) 사용자가 창업 준비 과정에서 겪을 수 있는 어려움에 대해 미리 알려주고, 극복 방안을 제시합니다.

전반적인 태도:
* 자신감 있고 전문가다운 어조를 사용하되, 고압적인 태도는 피합니다.
* 사용자의 아이디어를 진심으로 응원하고 격려하는 자세를 보입니다.
* 질문에 대한 답변은 명확하고 간결하게 합니다.

이렇게 만들어진 Gem을 통해 Gemini와 토론을 하여 MVP V1.0 기획을 작성했다.

기술은 심플하게 진행하되, Redis Stream의 경우 공부를 해보기 위해 사용하는 쪽으로 결정했다.
그리고 앱의 목적처럼, 음성으로 입력하는 투두리스트라는 뜻에서, saydo.me라는 도메인을 구매 했다.
구매는 가격이 저렴한 편인 Cloudflare에서... ㅎㅎ

MVP V1.0을 기반으로 내용을 좀 더 다듬고, 디자인 기획을 진행.

역시나, 원하는 디자인이 나오지 않아서, 내용을 좀 더 손본 뒤 v0에게 요청할 프롬프트를 작성해달라고 했다.
그렇게 만들어진 첫번째 디자인.

여전히 마음에 들지 않는다.
그리고 몇번의 수정을 거쳐 아래의 1차 디자인 완료를 하였습니다.

이후에는 커서AI를 활용하여 작업을 진행할 예정입니다!

개발은 기초가 중요하다는데, 대체 어디까지 배워야하는거죠?

@SoftyChoco — Thu, 23 Oct 2025 21:15:08 +0900

흔히 취준생, 주니어 분들이 많이 고민하는 부분입니다.
이곳 저곳에서 "개발자는 기초가 중요하다!"라고 하지만, 기초라고 하는 것들이 너무나 다양하고 많습니다.

자료구조, 알고리즘, CS, 네트워크...
답변해주는 사람마다 "여기부터 여기까지가 기초다"라고 하는 부분이 모두 다르고,
아무리 공부를 해도 내가 모르는 것들을 아는 사람을 만나면 '저 사람은 정말 대단하다'라는 생각과 '아직도 내가 모르는게 남았구나'라는 생각에 좌절감만 듭니다.

대체 어디까지가 기초이고, 언제까지 공부만 해야할까요?

제가 가장 추천드리는 방법은 이것입니다.
'개발의 기초'를 배우려고 하지 말고 '특정 도메인의 기초'에 집중해보세요.

왜 '도메인'이 중요할까요?

모든 산업에서 동일한 기술과 지식을 요구하지 않습니다.
내가 가고 싶은 곳이 정해지면, 익혀야 할 '기초'의 범위도 굉장히 좁혀집니다.
'자료구조, 알고리즘, CS, 네트워크'라는 큰 틀 안에서도 우선순위는 달라집니다.

예시를 들어보겠습니다.

커머스 도메인: '속도'와 '동시성'

자료구조: 빠른 조회를 위한 B-Tree(DB 인덱스)와 Hash Table(캐시/Redis)의 동작 원리
CS/DB: 동시 주문 처리를 위한 Transaction 원칙, Lock 개념, DB 격리 수준
네트워크/인프라: 트래픽 분산을 위한 Load Balancer의 역할, CDN의 원리, 인메모리 캐시(Redis 등)의 활용 방법

금융 도메인: '신뢰'와 '정확성'

네트워크/보안: 안전한 통신을 위한 HTTPS(SSL/TLS) 동작 방식, 대칭키와 비대칭키 암호화 기본 개념
CS/DB: 데이터 무결성을 위한 Transaction 심화
알고리즘/자료구조: 돈 계산 시 부동소수점의 위험성. Decimal 타입 또는 정수형 기반 연산의 필요성.

참고: 가장 좋은 건, 해당 도메인/해당 팀의 현업자에게 질문해보는 것을 추천드립니다. :)

이렇듯 내가 '어떤 문제를 풀고 싶은지'가 명확해진다면, '어떤 기초를 공부하는게 좋을지'도 명확해집니다.

저는 '제품' 그 자체에 관심이 많아서 여러 가지를 하고 싶어요!

특정 도메인보다 제품의 모든 영역을 다뤄보고 싶어 하는 분들도 많습니다.
이런 경우 두 가지 질문에 대해 생각해보세요.

"내가 만들고 싶은 프로덕트가 무엇일까?" (What)
"나는 왜 그 프로덕트를 만들고 싶을까?" (Why)

제품을 만들고자 하는 분들께는 이 "Why"가 굉장히 중요합니다.
이 이유가 명확해야만, '여러 영역을 다뤄보고 싶다'는 포부가 단순히 실력에 대한 욕심이나 호기심이 아닌, '제품 완성을 위한 강력한 동기'가 되어 설득력을 갖기 때문입니다.

예를 들어 "저는 교육 격차로 인해 원하는 공부를 못했던 경험이 있습니다. 그래서 누구나 쉽게 학습 콘텐츠를 만들고 공유할 수 있는 서비스를 만들고 싶습니다." 라는 Why가 있다면, 백엔드뿐만 아니라 프론트엔드, 배포, 사용자 피드백 분석까지 기꺼이 맡고 싶다는 지원자는 매우 매력적일 수밖에 없습니다.

이런 분들에게는 먼저 '사이드 프로젝트'를 통해 그 'Why'를 직접 구현해보는 것을 강력히 권합니다.
기획, 개발(프론트/백엔드), 배포, 운영까지... '내가 만들고 싶은 것'을 위해 필요한 모든 기능을 스스로 부딪히며 개발해보는 것입니다.

이 과정에서 '제품을 만든다는 것'의 의미와 '지금 당장 필요한 기초'가 무엇인지 가장 빠르게 체득하게 됩니다.

이 경험을 바탕으로, 제품의 전 생애주기를 경험할 수 있는 '스타트업'에 합류하는 것을 추천합니다.
만약 그 'Why'가 너무나도 명확하고 절실해서, '내가 직접 만들지 않으면 안 되겠다'는 확신이 든다면, 그 사이드 프로젝트를 발전시켜 '창업'을 하는 것 또한 선택지가 될 수 있습니다.

이 방법들은 모두 '우리 제품에 지금 당장 필요한 기초'가 무엇인지 현장에서 배우게 만든다는 공통점이 있습니다.

불안감에 모든 것을 다 배우려 하기보다, '나의 도메인' 또는 '나의 Why'를 생각해보세요.
그리고 그곳에서 요구하는 핵심 기초부터 다져나가신다면, 훨씬 더 빠르게 원하는 목표에 도달할 수 있을 겁니다.

해당 도메인의 현업자를 찾고 싶다면, "개발자 취업/이직/성장 정보 공유방"에 오셔서 질문해보세요!
https://open.kakao.com/o/g1kyqPIh

질문을 효율적으로 하는 방법

@SoftyChoco — Sat, 11 Oct 2025 13:49:01 +0900

좋은 질문을 위해 '목표와 맥락'을 자세하게 설명해야 한다고 이야기 했습니다.
하지만, 회사에서 모든 목표와 맥락을 이야기 하는건, 시간을 낭비하는 행위이기도 합니다.

오늘은 소통의 효율을 높여주는 '맥락 생략'에 대해 이야기해보려고 합니다.
이 방법의 핵심은 우리 팀을 하나의 거대한 'CDN' 으로 이해하는 것입니다.

프로젝트 킥오프, 디자인 시스템 공유, API 명세 리뷰 과정은, 전 세계 Edge 서버에 정적 데이터를 미리 배포하는 과정과 같습니다.
피그마 링크, 컴포넌트 규격, API 엔드포인트 같은 정적 데이터들이 각 팀원의 머릿속, 즉 Edge 서버에 캐싱되는 것이죠.

이렇게 CDN이 완벽하게 준비되면, 우리의 질문 방식은 완전히 달라져야 합니다.

1. 매번 Origin 서버에 요청하시겠습니까?
매일 함께 일하는 팀장님께 장황한 맥락으로 질문하는 것은,
CDN을 무시하고 모든 요청을 멀리 있는 오리진 서버에 직접 보내는 것과 같습니다.
많은 지연시간이 발생하죠.

- Origin 서버 요청 - 높은 지연시간 : "팀장님, 저희가 지금 배포한 '알파 서비스'의 '결제 페이지'에서 사용하는 '주문 버튼' 컴포넌트 말인데요. 이 버튼의 디자인 시스템 상 스타일 가이드에 따르면..."
이런 방식은 불필요한 소통 비용을 만들어냅니다.
팀장은 다시한번 맥락을 파악하고, 기존에 이야기 했던 내용과 일치하다는 것을 생각하고 나서야 답변할 수 있으니까요.
정답은 캐시가 되어있다는 것을 고려하여 질문하는 것입니다.

- Edge 서버 요청 - Cache Hit! : "팀장님, 이 버튼 Primary 스타일 적용하는게 낫지 않을까요?"
이 짧은 질문은 사용자의 브라우저가 가장 가까운 CDN Edge 서버에서 캐시 히트된 데이터를 받아오는 것과 같습니다. 이미 캐싱된 정보를 활용하기에 빠르고 효율적이죠.

2. 동기화: CDN 캐시 무효화
물론, 공유된 정보에 변경이 생길 수도 있습니다. 디자이너가 버튼 색상을 바꾸거나, 백엔드 개발자가 API 응답 값을 변경하는 경우죠.
이때 리더나 담당자가 해야 할 가장 중요한 일은 바로 'CDN 캐시 무효화' 요청을 팀 전체에 보내는 것입니다.

"팀원분들, Primary 버튼 색상이 피그마에서 변경되었으니 꼭 확인해주세요!"

이런 동기화 과정이 없다면, 어떤 팀원은 최신 버전의 자료를, 다른 팀원은 오래된 버전의 자료를 사용하여 이슈를 만들 수 있습니다.
효율적인 질문만큼이나, 공유된 맥락을 최신으로 유지하는 것 또한 중요합니다.

결국 질문의 실력은 '상대가 가진 맥락이 어디까지 인가'를 파악하는 능력에서 나옵니다.
즉, 상대방의 머리 속에서는 어떤 정보까지 캐시되어 있을까?를 생각해야 합니다.

지금 내 질문이 Origin 서버까지 가야하는 Cache Miss 상황일지, 아니면 Edge 서버에서 바로 처리가능한 Cache Hit 상황일지 판단해보세요.
이러한 요소 하나하나가 소통의 효율을 높여줍니다.

질문이 어렵다면, "이것"을 기반으로 질문해보세요!

@SoftyChoco — Fri, 10 Oct 2025 02:39:14 +0900

혹시 "카프카 요즘 어떤가요?"처럼 모호한 질문을 하고 계신가요?
질문이 어렵다면, "이것"을 기반으로 질문해보세요!

동료나 기술 커뮤니티에 "혹시 Nginx 써보셨어요?", "요즘 MSA는 어떻게 하나요?" 와 같은 질문을 던져본 적 없으신가요?
이렇게 용기 내어 한 질문에 "질문 좀 제대로 부탁드려요!", "무슨 상황인데요?" 라는 말이 돌아오는 경우가 많습니다.

이런 모호한 질문은 답변자의 시간을 빼앗고, 결국 내가 원하는 답을 얻지 못하게 만듭니다.
질문이 막막하게 느껴진다면, 단순히 기술 이름을 던지는 대신 다음 항목을 채워서 질문을 다시 만들어보세요.

1. 목표: 내가 이걸로 무엇을 하고 싶은가?
- "대규모 트래픽을 안정적으로 처리하기 위한 메시지 큐 도입을 검토하고 있습니다."

2. 맥락: 어떤 환경과 제약조건에 처해 있는가?
- 상황: "결제 시스템에 사용될 예정이라 메시지 유실은 절대 안 됩니다."
- 제약: "저희 팀은 클라우드 인프라 운영 경험이 많지 않습니다."

3. 시도: 원하는 답을 얻기 위해 스스로 어떤 노력을 했는가?
- "카프카의 acks=all 옵션을 사용하면 유실을 막을 수 있다는 문서를 봤습니다. 하지만 이 경우 성능 저하가 우려되어 실제 운영 사례가 궁금합니다."

4. 질문: 그래서 진짜 궁금한, 뾰족한 질문은 무엇인가?
- "이런 상황에서 RabbitMQ 대비 카프카가 갖는 뚜렷한 장점이 있을까요? 혹은, 저희와 비슷한 트래픽 환경에서 성능과 안정성의 균형을 맞추기 위한 현실적인 운영 노하우가 궁금합니다."

Before:
"카프카 요즘 어떤가요?"

After:
"안녕하세요! 저희 팀에서 결제 시스템에 사용할 메시지 큐 도입을 검토 중입니다. 메시지 유실이 절대 안 되는 환경이라 카프카의 안정성에 대해 알아보고 있는데요. 공식 문서를 보니 acks=all 옵션으로 데이터 유실을 막을 수 있지만 성능 저하가 우려됩니다. 혹시 비슷한 환경에서 RabbitMQ와 카프카를 모두 고려해보신 분이 있다면, 카프카가 갖는 뚜렷한 장점이 무엇인지, 혹은 안정성과 성능의 균형을 맞추기 위한 현실적인 운영 노하우가 있다면 조언 부탁드립니다!"

어떤 질문이 더 밀도 높은 답변을 받을 수 있을지는 명확합니다.
질문 방법을 명확하게 하여, 시간이 낭비되지 않도록 해보시기 바랍니다.

만화 '원피스'의 루피가, 어떤 행동을 할지 예측하실 수 있으신가요?

@SoftyChoco — Mon, 6 Oct 2025 00:38:13 +0900

만화 '원피스'의 루피가, 어떤 행동을 할지 예측하실 수 있으신가요?
그렇다면, 팀원이 어떤 행동을 할지는 왜 예측이 안될까요?

소통이란, '상대에 대한 이해'로부터 시작합니다.
만화 '원피스'의 주인공 루피가 어떤 상황에서 어떤 행동을 할지 쉽게 예측하실 수 있을겁니다.
배가 고플 때, 동료가 위험에 처했을 때 그의 다음 행동은 명확하니까요.
이런 예측이 되는 이유는, 우리가 그 '캐릭터'에 대한 이해도가 있어서, 그 캐릭터가 어떤 생각을 할지, 어떤 걸 중요시 하는지를 알고 있어서에요.

회사에서의 소통도 마찬가지입니다.
동료와의 소통은 그 사람의 '캐릭터'를 파악하는 것에서 출발합니다.

예를 들어 이런 동료들이 있을 수 있습니다.
- 동료 A: 성공을 위해 열정적으로 달리는 동료는, 때때로 공격적으로 보일 만큼 강하게 의견을 피력합니다.
- 동료 B: 책임감이 강하거나 실패를 두려워하는 동료는, 불안감 때문에 의견 제시를 주저할 수 있습니다.

그렇다면 동료 A와 이야기할 때는, 이 사람이 공격적으로 보이더라도 그렇지 않다는 것을 상기하면서 이야기할 수 있고,
동료 B와 이야기할 때는, 제시하는 의견이 받아들여진다면, 그건 팀 모두의 결정이라는 것을 이야기해줄 수 있죠.

그리고 이러한 부분들이 팀 전체에서 인지할 수 있도록, 팀 문화를 만들 수도 있습니다.
- 우리는 프로덕트를 성공시키기 위해 열정적으로 일합니다.
- 아이디어는 팀원 모두가 함께 결정합니다.

그렇다면, 이 '캐릭터'를 파악하는 가장 좋은 방법은 뭘까요?
여기서 조금은 꼰대처럼 들릴 수 있는 이야기를 해보겠습니다.
바로 점심 식사, 회식, 티타임 같은 비공식적인 시간의 중요성입니다.
* 물론, 저는 절대 강요하지 않습니다 :)

자발적인 분위기에서 나누는 가벼운 대화는 서로의 '캐릭터'를 이해할 수 있는 기회입니다.
오히려 억지로 만든 자리에서는 자신의 진짜 모습을 보여주는 사람은 거의 없을 거예요!

이렇게 동료의 '캐릭터'를 이해하고 소통하는 것은 협업에 있어서 무엇보다 중요합니다.
분명 기존과는 다른 원활한 소통을 경험하게 되실 거예요.

물론, 현실에서의 캐릭터 파악은 간단하지 않을 겁니다.
더 나은 소통을 하고 싶으시다면, '개발자 성장 채팅방'에서 자신의 소통 실패 사례를 공유해보세요.
들어오셔서 여러분의 팀원 이야기를 들려주시거나, 다른 분들의 집단지성을 통해 소통의 힌트를 얻어 가세요!

https://open.kakao.com/o/g1kyqPIh

중요한 데이터를 삭제할 때, 대비를 하시나요?

@SoftyChoco — Fri, 3 Oct 2025 01:49:28 +0900

비트윈이라는 커플앱의 무료 사용자 사진이 대부분 날아가는 소식을 들었습니다.
기사에 나온 원인은 장기 미사용자 데이터 정리 로직의 오류라고 하더라구요.

이 소식을 접하는 많은 분들은 "백업이나 이중화도 안 해놨나?"라는 말이 바로 튀어나오겠지만,
솔직히 작은 기업에서는 백업은 커녕 DB 암호화도 안되는 경우가 생각보다 흔합니다.

저도 데이터가 많아 백업이 어렵고 이중화도 비용 측면에서 어려운 상황에서 미사용 데이터를 정리해야하는 상황이 있었는데,
그 때 고려했던 부분은, "어떤 일이 있어도 최후의 보루는 있어야겠다"였습니다.

그래서 저는 삭제 대신 별도의 스토리지로 이동하는 방식으로 진짜 삭제를 최대한 미루는 형태로 작업했었죠.
이렇게만 해두더라도, 실수를 깨달았을 때 복구할 수 있는 방법이 생깁니다.

잠깐 데이터가 안보이는건 단순 장애로 끝나고 금방 사용자의 신뢰를 회복할 수 있겠지만,
사용자들에게 중요한 데이터가 모두 날아가는 상황은 재해로 봐야합니다.

내가 짠 코드가 100% 완벽하게 돌아갈 것이라고 생각하지 마세요.
테스트가 있고 QA가 있더라도 그건 단지 조금 더 확률을 높여줄 뿐입니다.

항상 뒤를 생각하고, 되돌릴 수 없는 상황에 대비하는건 필수입니다.

열심히 달린다고 반드시 행복해지는걸까요?

@SoftyChoco — Wed, 1 Oct 2025 22:25:06 +0900

"우리는 '열심히 살면' 행복해진다고 믿습니다.
하지만 과거의 노력에 갇혀 앞으로 나아가지 못하는 친구, 그리고 미래를 향해 열심히 달려 성공했지만 공허해진 동료를 보며 다시한번 생각해보게 되었습니다.
열심히 달린다고, 반드시 행복해지는 걸까요?

이 둘을 보며, '과거, 현재, 미래'에 대한 우리 삶의 에너지 분배에 대해 깊이 생각하게 되었습니다.
오늘은 제가 곁에서 지켜본 안타까운 두 사례와, 이를 통해 제가 내린 결론에 대해 이야기해보고자 합니다.

Case 1: '과거'라는 후회의 늪에 빠진 내 친구

친구 중 하나는 열심히 했지만, 큰 실패 이후, 시간이 멈춘 듯 살아갑니다.
전화를 하다보면 늘 비슷한 레퍼토리의 반복이죠.
"만약 그때 ~를 했다면...", "그때 그 사람을 믿지 말았어야 했는데...".

그 친구의 대화는 항상 과거형입니다.

안타까운 것은, 그 후회의 늪에 빠져있는 동안에는 눈앞에 나타나는 새로운 기회들을 전혀 보지 못한다는 점입니다.
과거의 실패라는 경험에서 배우고 다음 스텝으로 나아가는 게 아닌, 과거에 머무르며 현재의 소중한 시간을 흘려보내고 있습니다.

Case 2: '미래'는 손에 넣었지만 행복을 잃은 동료

퇴사한 동료는 모두가 부러워하는 성공의 아이콘이었습니다
그는 원하는 목표를 위해 가족과의 저녁 식사, 아이의 학교 행사, 주말의 약속을 모두 뒤로한 채 일에만 몰두했습니다.
그리고 마침내, 모두가 인정하는 자리에 올랐습니다.

하지만 기쁨은 잠시였습니다. 그는 가장 기뻐해 줄 거라 믿었던 가족의 식탁에서 어색한 침묵을 마주해야 했습니다.
"성공을 위해 달렸지만, 돌아보니 행복을 모두 길 위에 버리고 온 기분입니다. 트로피를 얻었지만, 함께 기뻐할 사람이 없네요."

미래를 얻는 과정에서, 그 미래를 함께 나눌 '현재의 관계'를 모두 잃어버린 것입니다.

이 두 사례를 보고, 저만의 기준을 만들었습니다.

1. 기본값은 '현재 70%, 미래 30%' 으로 설정합니다.

오늘의 행복이 기반이 되어야 합니다.
이 기반이 없다면, 미래에 성공하더라도 동료처럼 공허해지거나, 실패했을 때 다시 일어설 힘을 잃게 될 테니까요.

현재의 일, 건강, 소중한 사람들과의 관계에 주로 에너지를 쏟습니다.
대신, 남은 30%의 에너지로 미래를 위한 공부와 계획을 꾸준히 해나갑니다.

현재에만 투자하면, 미래에는 불안으로 이어질테니까요.

2. 전력질주가 필요하더라도, '현재'를 완전히 포기하지 않습니다.

무언가 열심히 하다보면 일시적으로 미래에 더 큰 비중을 두며 전력 질주해야 하는 구간이 있습니다.
주로 회사의 피할 수 없는 야근 같은 경우죠.

하지만, 이런 경우라도, '현재'의 비중을 30% 이하로 내리지 않으려고 노력합니다.
이게 제 행복과 지속가능성을 지키는 최소한의 '심리적 안전망'이니까요.
이런 최소한의 현재가 있어야, 미래에도 행복을 지속할 수 있다고 생각합니다.

3. '과거'는 기준에 포함하지 않습니다.

과거는 단지 참고하고 배우기 위한 '데이터'일 뿐, 에너지를 쏟아야하는 대상은 아닙니다.
성장을 위한, 회고의 재료로써만 사용합니다.
과거에 대한 집착은 현재의 가능성을 갉아먹을 뿐이니까요.

우리는 결국 행복하기 위해 살아갑니다.
그런데 행복의 기반이 되는 현재를 포기하면서까지 얻는 극단적인 성공이나 과거에 대한 집착이, 과연 우리를 행복하게 할까요?
결국 가장 중요한 것은 균형입니다.

이런 기준이 없다면, 자신만의 '에너지 분배 기준'을 만들어보시면 어떨까요?

직접 경험해본 대기업 출신과 중소기업 출신의 가장 큰 차이점

@SoftyChoco — Thu, 25 Sep 2025 09:04:50 +0900

대기업 출신과 중소기업 출신들이 섞여있는 회사에서 근무를 해본 경험이 있습니다.
거기서 동료들과 일하며 흥미로운 점을 발견했습니다.
어디 출신이냐에 따라 눈에 띄는 '마인드셋'의 차이가 존재한다는 것이었죠.

네카라쿠배부터, 아마존, 구글 출신까지.
대기업 출신의 동료들은 새로운 아이디어나 어려운 문제에 대해 '어떻게 하면 할 수 있을까?'를 먼저 고민하는 경향이 있었습니다.
실패에 대한 두려움보다는 도전에 대해 긍정적인 편이였어요.

반면, 중소기업 환경에서 올라온 동료들과 과거의 저는 새로운 시도 앞에서 "그게 되겠어?", "해봤자 안 될 텐데"와 같은 냉소적인 반응을 먼저 보이곤 했습니다.
처음에는 그저 개개인의 차이라고 생각했지만, 각자의 이야기를 들어보고 과거를 회고해보면서 깨달았습니다.
이건 개인의 문제가 아닙니다.
우리가 겪어온 '환경'의 차이였습니다.

돌이켜보면, '안될 거야'라고 말하던 동료들은 늘 회사의 한계와 싸워야 했습니다.

- 아이디어를 내면, '니가 책임질꺼야?' 혹은 '니가 책임지고 해봐'라는 이야기를 들어온 경우
- 리더의 변덕 등으로 인해 '열심히 해봤자 결국 엎어진다'는 학습된 무기력을 경험한 경우
- 한번의 실패에 팀의 존폐가 걸려있던 환경에서, 새로운 도전보다는 현재를 유지하는 것이 가장 안전한 선택이었던 경우

이런 환경에서 "일단 안된다고 말하는 것"은 단순한 비관이 아니라, 현실을 직시하고 팀과 자신을 보호하기 위한 가장 합리적인 생존전략이었을 것 같습니다.

그렇다면, 무엇이 긍정적인 도전을 가능하게 할까요?

- 아이디어가 좋다면, 그것을 받아들이고 함께 시도해볼 수 있는 문화
- 실패하더라도, 개인의 책임이 아닌, 조직의 경험으로 받아들일 수 있는 문화

결론적으로 제가 본 것은 '사람'의 차이가 아니라 '환경'의 차이였습니다.
생존이 목표인 환경에서는 '안정'을 추구하는 마인드셋이, 성장이 목표인 환경에서는 '도전'을 추구하는 마인드셋이 만들어지는 것은 어쩌면 당연한 결과입니다.

그리고 이 두 마인드셋의 차이는 단순히 '긍정적/부정적'인 태도를 넘어, 결과물의 질을 완전히 바꿔놓습니다.
'어떻게든 해보자'는 태도로 문제 해결에 최선을 다하다 보면, 우리는 자연스럽게 문제의 본질, 즉 '사용자의 진짜 니즈' 에 더 깊이 파고들게 됩니다.
"고객이 왜 이런 요청을 했을까?"를 집요하게 묻게 되는 것이죠.

사용자의 진짜 니즈가 명확해지는 순간, 문제를 해결할 방법은 훨씬 다양해지며, 해결을 위해 수단과 방법을 가리지 않고 몰두하는 과정에서 생각지도 못했던 새로운 기회를 발견하기도 합니다.
이처럼 '도전하는 마인드셋'은 단순히 주어진 문제를 푸는 것을 넘어, 더 가치 있는 문제를 발견하고 예상치 못한 기회를 창출해냅니다.

단순히 개인의 '마인드셋' 문제로 치부할 것이 아니라, 그런 도전을 장려하는 환경 속에서 기꺼이 부딪혀보는 사람들이 모일 때, 비로소 조직은 정체되지 않고 앞으로 나아갈 수 있습니다.

혹시 '안될 거야'라는 말이, 문제를 깊이 들여다보기도 전에 튀어나오는 당신의 습관이 되지는 않았나요?
어쩌면 그 태도가 자신의 성장을 막고있을지 모릅니다.