Topic
커리어와 학습
현실적인 경험에서 배우는 개발자 성장, 커리어 선택, 제품과 학습을 다룹니다.
AI 개발 작업을 맥락과 기기, 위험도에 따라 나누기
IDE 검토, 데스크톱 에이전트, 원격 모바일 흐름을 연결하되 맥락의 크기와 검토 필요성, 운영 위험에 따라 작업을 나눕니다.
실제로 검증한 AI 작업 흐름으로 개발 템플릿 바꾸기
반복해서 검증한 AI 작업 흐름에 맞춰 개발 템플릿을 바꾸되, 검증은 명시적으로 남기고 프로젝트별 지침은 공통 기본값과 분리합니다.
AI 생산력과 엔지니어링 생산성은 같지 않다
AI 에이전트가 생산량을 높여도 복잡한 실무에는 맥락, 메모리, 판단, 좋은 동료의 자발적인 사고 확장이 왜 필요한지 살펴봅니다.
AI 버즈워드보다 실제 업무 효용으로 판단하기
유행하는 AI 용어를 좇기보다 실제 업무와 프로젝트에 적용해 보고, 직접 만든 경험으로 효용과 불안을 구분하는 법을 다룹니다.
공부 시간보다 경력 경험의 밀도를 높여라
업무와 무관한 공부 시간을 늘리기보다 실제 회사 일에서 설명할 수 있는 경험의 밀도를 높이는 커리어 원칙을 다룹니다.
부트캠프 간판보다 목적과 멘토를 검증하는 법
구체적인 학습 목표, 멘토 역량, 실제 성과와 한계, 비용의 타당성을 기준으로 부트캠프를 판단하는 방법을 다룹니다.
AI와 만드는 새 프로젝트의 모듈과 계층 단순화
AI와 새 프로젝트를 만들 때 모듈·인터페이스·계층을 줄이는 가설을 검토하되, 명확성과 품질 및 레거시의 점진적 개선을 지킵니다.
애매한 개발 경력을 정직한 면접 강점으로 바꾸는 법
전체 경력은 정직하게 유지하되 지원 역할마다 프로젝트 강조점을 바꿔, 인접 경험을 채용할 만한 근거로 만듭니다.
신뢰와 작은 성공으로 개발 문화를 바꾸는 법
새 조직을 먼저 이해하고 일로 신뢰를 얻은 뒤, 테스트와 정책 공유의 작은 성과를 보여 개발 문화를 확산합니다.
암묵지를 살아 있는 팀 컨벤션으로 만드는 법
팀원의 머릿속에만 있는 개발 규칙을 이유와 함께 기록하고, 팀별 재정의와 리뷰·온보딩으로 살아 있게 관리합니다.
회사 규모를 넘나들며 개발자 경험의 폭을 넓히는 법
장기 목표에 맞춰 작은 조직의 넓은 책임과 큰 조직의 깊은 전문성 중 필요한 경험의 폭을 의도적으로 선택합니다.
개발자 이직은 연봉만이 아니라 다음 경험으로 고른다
현실적인 금전 제약을 존중하면서도 도메인, 운영 문제, 책임을 장기 역량으로 바꿀 수 있는지를 이직 기준에 넣습니다.
개발 리더십은 직함을 받기 전에 시작된다
리뷰, 장애, 넓은 문제와 동료의 신뢰를 먼저 책임지며 직함이 붙기 전부터 개발 리더십을 준비하는 기준입니다.
강점과 실험으로 개발자 커리어를 설계하는 법
자신의 강점을 구조화하고 여러 개발 경험을 직접 시험하며, 막연한 포부 대신 근거로 미래 방향을 계속 고치는 방법입니다.
코드 리뷰 품질은 댓글 수보다 줄어드는 추이로 본다
자동화와 드래프트 PR로 초기에 합을 맞추고, 공통 규칙이 자리 잡으며 반복 피드백이 줄어드는지를 확인합니다.
도메인 지식을 실무 문제 해결로 증명하는 법
운영, 정책과 부서 간 문제에서 도메인 지식을 쌓고 용어가 아니라 실제 판단과 해결 과정으로 역량을 증명하는 방법을 다룹니다.
바이브 코딩 시대에도 개발자 판단력이 필요한 이유
AI 코딩을 활용하면서도 문제 정의, 코드 검토, 품질 기준과 결과를 검증할 기술 지식을 지키는 방법을 다룹니다.
애자일은 문서화를 하지 말라는 뜻이 아니다
애자일을 문서화 거부의 핑계로 삼지 않고 팀의 연속성, 보안, 규제와 운영에 필요한 문서를 판단하는 기준을 다룹니다.
회사가 아닌 개발자가 자신의 성장을 책임지는 법
회사, 책, 프로젝트와 커뮤니티의 경험을 자기 판단으로 바꾸며 개발자 성장을 스스로 책임지는 관점을 다룹니다.
시니어 개발자가 다음 개발자에게 남겨야 할 유산
연차가 아니라 유지보수 가능한 코드, 테스트, 가이드와 팀의 지속가능성으로 시니어의 책임을 살펴봅니다.
경력 있는 신입 개발자는 업무 경험으로 차별화하라
이전에 한 일과 문제, 접근 방식, 시도한 해법과 실제 행동을 면접에서 구체적으로 설명하는 법을 다룹니다.
작은 문제를 적은 자원으로 푸는 엔지니어링
현재 시스템의 한계를 측정하고 작은 문제를 비례 있게 해결하며, 근거가 생길 때 캐시와 분산 인프라를 추가합니다.
도메인 학습과 기술 실험을 분리하는 두 가지 트랙
도메인 프로젝트는 익숙한 기술로 출시하고, 낯선 인프라는 최소 프로젝트와 성능 테스트로 따로 검증합니다.
개발자 성장은 맡은 일을 끝내는 데서 시작한다
최소 품질선을 지키며 가치 있는 일을 완수하고, 이후 리팩터링과 학습으로 다음 성장을 준비하는 태도를 다룹니다.
바꾸기 전에 먼저 팀의 사람이 되어라
제때 묻고 진행 상황을 공유하며 빠르게 리뷰받고, 신뢰를 쌓은 뒤 근거 있는 작은 변화로 새 개발팀에 적응하는 방법을 다룬다.
관리비 고지서에서 연체 도메인을 발견한 순간
평범한 고지서에서 상환 모델의 빠진 개념을 발견하고, 현실의 단서를 검증 가능한 소프트웨어 경계로 바꾸는 과정을 살펴본다.
설계 자원을 쓰기 전에 핵심 개념의 우선순위를 정하라
1급 도메인 개념을 찾고 보조 흐름을 분리해, 제한된 설계 시간을 변화의 중심에 쓰는 실용적인 방법을 설명한다.
경험과 반복이 지속 성장하는 개발자를 만든다
다양한 실전 경험과 실패의 반복, 비즈니스 제약에 대한 관심이 낯선 운영 문제를 푸는 개발자를 만드는 과정을 살펴본다.
CS 지식은 실무 문제를 해결할 때 역량이 된다
실제 엔지니어링 문제를 통해 CS를 배우고, 그 지식으로 업무를 어떻게 판단하고 개선했는지 보여 주는 방법을 다룬다.
거듭된 실패가 가르쳐 준 개발자 커리어의 기준
실패를 다음 기회의 검증 기준으로 바꾸고, 신뢰할 수 있는 추천을 활용하며, 과거의 규칙도 새 경험 앞에서 다시 고치는 법을 다룬다.
얼어붙은 신입 개발자 시장을 통과하는 현실적인 전략
채용이 좁아진 2024년에는 첫 회사의 범위를 넓히고, 실제 업무를 문제 해결 근거로 바꾸며, 기술 목록보다 사고 과정을 보여줘야 합니다.
SI에서 서비스 개발로: 채용 요건을 학습 계획으로 바꾸기
SI에서 서비스 팀으로 옮긴 데에는 도움과 운이 컸습니다. 반복 가능한 전략은 목표 채용 요건을 읽고 관련 역량과 경험을 만드는 것입니다.
실제 트래픽이 없어도 대용량 시스템 대응은 연습할 수 있습니다
작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.
Git 이력은 개인 작업일지가 아니라 팀의 자산입니다
커밋을 다듬기 전에 작업부터 나누고, 동료가 검토하기 좋은 PR과 다음 사람이 변경 이유를 추적하고 릴리스를 복구할 수 있는 이력을 남깁니다.
토이 프로젝트를 서비스라고 부르기 전에 운영해보기
토이 프로젝트에서 서비스 경험을 얻으려면 하나의 목표를 정하고, 출시하고, 실제 사용자를 만나며, 리텐션과 종료 시점을 봐야 합니다.
사용자 관점에서 문제를 정의하는 법
기술 부하와 제품 가치를 구분하고, 만든 것을 실제로 출시하며, 사용자가 왜 선택할지 계속 물어야 문제 해결 능력이 자랍니다.
개발 용어보다 자기 생각과 운영 경험을 선택하기
이론과 패턴은 유용한 참고 자료지만, 개발자는 코드와 트레이드오프, 운영 결과를 자기 언어로 설명할 수 있어야 합니다.