Work

이 주제의 항목 · 26

• 개발 배우기의 네 단계와 넘는 법개발 입문은 자신감이 오르는 강의 단계, 빈 에디터 앞의 혼란, 범위가 넓어지는 절망의 사막, 실력이 붙는 상승기를 거친다. 단계마다 넘는 방법이 다르고, 비전공자는 CS 기초를 의식적으로 보완하며 학력 대신 공개된 결과물로 실력을 증명한다.
• 개발 자료 잘 찾는 법막혔을 때 자료를 찾는 순서: 영어 검색과 관용 키워드 → 검색 연산자로 좁히기 → 공식 문서에서 API의 입출력 확인 → 라이브러리 소스 직접 열기 → 오픈소스 저장소의 이슈·PR 검색.
• 개발자 기술 블로그: 왜 쓰고 어떻게 오래 쓰나남에게 설명하며 이해의 빈틈을 찾고, 기록이 포트폴리오와 기회가 된다. 메모가 아닌 완성된 글을 형식을 정해 쓰고, 오래 보존할 수 있는 도구와 검색·구독 채널로 꾸준히 운영한다.
• 개발자 생산성: 무엇이 10배 차이를 만드나프로그래밍은 선형 노동이 아니라 설계라서 개인 간 생산성 차이가 곱으로 벌어진다. 10배 프로그래머를 만드는 요소(설계 희생, 단순함, 지식, 저수준 이해, 디버깅, 집중), 연구로 밝혀진 스타 엔지니어의 아홉 가지 업무 전략, 팀의 속도를 스프린트·마라톤·인터벌로 나눠 보는 모델과 속도를 깎는 요인, 프로그래머에 맞춘 뽀모도로와 집중 원칙을 정리한다.
• 개발자 역량 지도: 주니어에서 시니어, 풀스택, 아키텍트까지주니어에서 시니어로 가며 넓혀야 할 열한 가지 역량(협업 도구, 언어, API, 서버·클라우드, 인증·테스트, DB, CI/CD, 자료구조·알고리즘, 시스템 설계, 디자인 패턴, AI 도구), 풀스택 개발자가 다루는 일곱 영역, 소프트웨어 아키텍트에게 필요한 지식 지도, 모든 개발자가 알아야 할 여덟 가지 표준을 한 장에 정리한다.
• 개발자에서 리더로: 테크 리드·팀장이 바꿔야 할 것리더의 성과는 내 산출물이 아니라 팀이 만든 가치다. 기술 실력만 믿고 직접 코딩·통제에 매달리는 다섯 가지 실수를 피하고, 1:1 면담·업무 배정·심리적 안전감·피드백·목표와 문서화로 팀을 키운다.
• 개발자의 마음 관리: 감정을 다시 해석하기자신감과 가면 증후군 사이를 오가는 개발자의 감정을 시스템 1·시스템 2 관점으로 보고, 같은 신체 감각을 다른 감정으로 해석하는 인지 재평가로 분노·스트레스·질투·두려움·피로·무력감을 다루는 법을 정리했다.
• 개발자의 지속 가능한 학습 루프개발 학습은 의지로 버티는 1년이 아니라 수십 년 이어지는 습관이어야 한다. 정보 습득 → 학습 → 정리 → 실습 → 적용의 다섯 단계, 기술 블로그를 고르고 읽는 법, 메타인지·설명해 보기·흐름 따라 공부하기 같은 공부법, 틈새 시간과 선택과 집중으로 루프를 유지하는 법을 정리했다. AI 도구를 다 따라가지 않고 흘러들어오게 하는 법, 생성형 지식과 고수에게 배우는 질문, 구현 의도로 실행하는 법도 정리했다.
• 디버깅 사고법: 가설을 세우고 반증한다버그는 머릿속 모델(멘탈 모델)이 실제 시스템과 어긋난 자리에서 생기므로, 디버깅은 그 어긋남을 배우는 문제 해결이다. 과학적 방법의 다섯 단계, 좋은 가설의 조건(원인과 실패 지점을 함께 설명하고 반증 가능), 주석을 규범이 아닌 참고로 읽기, 고정 마인드셋과 성장 마인드셋, 능동적 회상·나눠 공부하기·끈기 같은 습관을 정리한다.
• 비즈니스 이메일 쓰는 법업무 메일은 받는 사람, 단일 주제, 스타일, 구성 요소 네 가지로 정리된다. To·CC·BCC와 답장·전체 답장·전달을 고르는 기준, 한 메일 한 목적 규칙, 3~8단어 제목부터 서명·첨부·발송 전 점검까지의 체크리스트.
• 사이드 프로젝트를 시작하고 끝까지 가는 10가지 팁꾸준히 하나는 굴리기, 내 불편에서 아이디어 찾기, 틈새 겨냥, 작게 시작, 1~2주 단위 기한, 코딩 전 랜딩 페이지로 검증하기까지 사이드 프로젝트를 시작하고 유지하는 원칙. 내가 쓸 것을 내가 만드는 출발점과 불편 일기, MVP·MMP·MLP로 나눈 검증, 빌드 인 퍼블릭까지 다룬다.
• 사회 초년생을 위한 직장 생활 팁경력 관리와 자기 관리 습관, 업무량이 많을 때 실수를 줄이고 속도를 올리는 실무 습관, 집중 시간을 지키는 법, 업무 전화를 실수 없이 처리하는 법을 상황별로 정리했다.
• 소프트웨어 문서화: 네 가지 문서 유형과 코드에서 문서 만들기소프트웨어 문서는 목적에 따라 튜토리얼·하우투 가이드·레퍼런스·해설의 네 유형으로 나뉘고(Diátaxis), 한 문서는 한 유형만 따른다. 레퍼런스는 코드 구조를 따라 주석에서 자동 생성해 코드와 어긋나지 않게 한다. 무엇은 이름으로, 왜는 기록으로 남긴다. 프로젝트의 입구인 README에 담을 것과 README를 먼저 쓰는 README 주도 개발도 다룬다.
• 실력만으로는 부족하다: 명성 쌓기와 커뮤니티 기여일을 잘해도 알려지지 않으면 기회가 오지 않는다. 글쓰기·발표·공개 작업으로 명성을 쌓는 원칙, 흔한 핑계를 넘는 법, 커뮤니티에 기여할 때 지킬 태도를 정리했다.
• 엔지니어 레벨: 주니어에서 Distinguished까지의 커리어 사다리소프트웨어 엔지니어의 커리어 사다리는 주니어, 엔지니어, 시니어, 스태프, 시니어 스태프, 프린시플, Distinguished로 올라가며, 레벨을 가르는 것은 코드 실력보다 영향 범위(개인 → 팀 → 조직 → 회사 → 업계)와 일의 크기다. 레벨별 기대 역할, 빅테크의 레벨 명칭(Google L, Meta E), 승진 기대 기간, IC와 매니저 트랙, 더 읽을 자료를 정리한다.
• 오픈소스 기여 시작하기: 문서·답변에서 코어 기여까지기여는 코드만이 아니다. 문서 번역, Q&A 답변, 리뷰, 글쓰기도 기여다. 쓰고 있는 라이브러리에서 good first issue로 시작하고, 소스 추적·토론 채널 참여·프로토타입으로 깊은 기여로 넘어간다.
• 오픈소스 라이선스: 허용형과 카피레프트오픈소스 라이선스는 사용·수정·배포를 허락하는 조건이다. MIT·BSD·Apache 2.0 같은 허용형과 MPL·LGPL·GPL·AGPL 같은 카피레프트를 소스 공개 의무, 같은 라이선스 강제, 특허 조항으로 비교하고, 라이선스 호환성, 라이선스 없는 저장소의 의미, SPDX 표기, 오픈소스가 아닌 소스 공개 라이선스(BSL·SSPL)로의 전환 흐름을 정리한다.
• 오픈소스 프로젝트 운영: 도입, 포크, 문서, 확산, 유지오픈소스는 공개만으로 쓰이지 않는다. 쓸 라이브러리는 인기·문서·인터페이스로 고르고, 포크할 때는 당위와 계획으로 신뢰를 얻는다. 문서와 예제가 성패를 가르고, 공개 후에는 이슈 대응·로드맵·메인테이너의 지속 가능성이 프로젝트를 살린다.
• 웹 프로젝트 가격 책정프리랜서·에이전시가 웹 프로젝트 값을 정하는 원칙. 시간제·고정가·월 단위 계약을 고르는 기준, 가격을 올릴 신호, 예산을 묻는 법, 견적서 쓰기, 잊기 쉬운 사후 지원까지 정리했다.
• 의사결정 체크리스트결정을 내리기 전에 무엇을, 언제까지, 누가, 누구와 상의해, 누구의 승인으로, 누구에게 알릴지 정하는 6가지 항목. 수평적인 팀에서는 결정 자체가 아니라 결정권자를 합의로 위임하고, 치열한 결정일수록 빠르게 정한다.
• 친절한 엔지니어링: 정직, 심리적 안전감, 피드백친절은 예의 바름(nice)이 아니라 상대에게 관심을 쏟아 그가 있는 자리에서 돕는 것(kind)이다. 정직하되 개인적으로 신경 쓰기, 코드 리뷰 같은 비동기 소통에서 '왜'를 묻기, 비난 없는 문화와 실패에서 배우기로 심리적 안전감 만들기, 피드백을 받는 법과 주는 법(감정·신뢰·논리)을 정리했다.
• 컴퓨팅 사고와 개발 실력 늘리는 법컴퓨팅 사고는 문제를 분해·패턴 인식·추상화·알고리즘으로 다듬어 컴퓨터가 실행할 수 있는 절차로 바꾸는 사고다. 요구사항을 데이터의 관점으로 다시 정의하는 법, 알고리즘을 자연어·순서도·의사 코드로 적는 법과 순차·선택·반복의 세 제어 구조, 알고리즘 공부가 프론트엔드 개발자에게도 필요한 이유, 개발을 운동처럼 훈련하는 방법을 정리했다.
• 페어 프로그래밍두 사람이 드라이버와 내비게이터 역할을 번갈아 맡아 한 코드를 함께 짜는 애자일 실천법. 역할을 나누는 이유, 장단점, 핑퐁·포모도로·스트롱 스타일 같은 진행 방식, 짝을 존중하는 진행 규칙과 원격 도구를 정리한다.
• 협업을 잘하는 개발자: 프로그래머가 아니라 문제 해결사코드의 가치는 코드가 만드는 비즈니스 가치에서 나오고, 개발 직군만으로는 그 가치를 키우기 어렵기 때문에 개발자는 협업해야 한다. 문제의 본질 찾기·모순 해소·함께 풀기라는 문제 해결 원칙과 심리적 안전감, 의도와 맥락을 담은 말하기, 수평적 팀에서의 역할 감각을 정리했다.
• 회사에서 빠르게 성장하는 법짧은 피드백 사이클, 스스로 높이는 업무 난이도, 신중한 이직 판단으로 회사의 성장 속도를 따라잡고, 본캐에 수렴하는 부캐와 100일 프로젝트로 도구가 바뀌어도 나에게 쌓이는 역량을 만드는 방법.
• 회의 잘하는 법: 발산과 수렴회의가 산으로 가는 이유는 사람보다 방식에 있다. 발산 회의와 수렴 회의를 구분해 알리고, 결과물을 정의하고, 그라운드 룰과 짧은 마감을 두면 대부분의 회의가 나아진다. 참석자로서 쓸 수 있는 환기 질문과 침묵·반복을 깨는 장치까지 정리했다.