#collaboration
노트 46개
Frontend › JavaScript
TypeScript 코딩 컨벤션TypeScript 팀 컨벤션 문서의 규칙을 주제별로 묶었다. 이름 짓기, 타입, 선언, 클래스, 표현식, 제어문, 함수, 에러 처리, 내장 객체, 모듈 규칙을 필수·권장과 이유까지 함께 정리하고, 중괄호·줄 길이·빈 줄·중첩 줄이기·헬퍼 함수 위치 같은 코드 모양과 유지보수를 괴롭히는 패턴(닌자 코드) 목록을 더했다. Airbnb JavaScript 스타일 가이드의 객체·함수·형 변환 규칙과, 공개 스타일 가이드끼리 갈리는 지점(export default, for...of, ++, getter, 약어 표기)도 비교했다.
Frontend › UI Design
디자인 도구와 개발자 핸드오프디자인 핸드오프는 이미지와 문서를 메일로 넘기던 방식에서 브라우저 기반 공유 파일(Figma)로 옮겨 왔다. 개발자는 스타일·변수 확인, 치수 측정, 애셋 추출, 프로토타입 흐름 읽기, 댓글로 협업한다. Inspect 코드는 그대로 쓰지 않고, absolute 좌표는 흐름으로, Auto Layout은 Flexbox로 옮긴다. 디자인은 실제 데이터와 여러 화면 크기로 검증하고, 도구 이전은 비용을 계산해 한 번에 끝낸다.
Frontend › UI Design
디자인 시스템: 구성, 도입, 구축과 배포디자인 시스템은 팀이 같은 UI를 같은 규칙으로 만들게 하는 원칙·스타일·컴포넌트·문서의 묶음이다. 무엇으로 이루어지는지, 작은 팀도 필요한 이유와 도입 시점, 감사→기준 합의→파운데이션·컴포넌트 정리→개발 합의→QA로 이어지는 구축 절차, 토큰과 컴포넌트를 중앙 모노레포에서 패키지로 배포하는 구조까지 정리했다. 감사는 인터페이스 인벤토리로, 시각 방향은 스타일 타일·요소 콜라주로 가볍게 합의한다.
Frontend
프론트엔드 개발자의 업무 범위와 역량프론트엔드의 일을 데이터 흐름 기준 여섯 영역(보여 주기·조작·보내기·받기·환경 관리·도구 만들기)으로 나누고, 퍼블리셔·백엔드·풀스택과의 경계, 회사와 동료가 보는 잘하는 프론트엔드 개발자의 조건을 정리했다.
Computer Science › Programming Languages
C++ 코딩 표준과 clang-formatC++ 프로젝트의 코딩 표준이 무엇을 정하는지(사전·사후 조건, 유지보수, 서식, 이름, 클래스 배치, 문서화, 최적화 힌트)를 한 프로젝트 표준을 예로 정리하고, 서식은 사람이 지키지 말고 clang-format으로 자동화하는 방법을 다룬다.
DevOps
장애 대응과 포스트모템장애는 탐지 → 전파 → 해결 → 보고 → 회고의 다섯 단계로 다룬다. 해결은 확산을 막는 임시 조치(롤백·재기동·증설·기능 스위치)가 먼저고, 보고서와 비난 없는 포스트모템으로 재발 방지·탐지·처리 개선 과제를 검증 가능한 액션 아이템으로 남긴다.
DevOps
ChatOps: 채팅에서 운영하기ChatOps는 배포·조회·알림·장애 대응 같은 운영 작업을 팀 채팅방에서 봇 명령으로 실행하는 협업 방식이다. 누가 무엇을 했는지 모두에게 보이고(투명성), 보면서 배우고(온보딩), 손으로 치던 위험한 명령이 검증된 스크립트가 된다. 구성 요소, 도입 단계, 권한·비밀·알림 피로 같은 위험을 정리한다.
DevOps
DevOps, SRE, 플랫폼 엔지니어링, NoOps와 클라우드 거버넌스개발과 운영을 잇는 방식의 갈래를 비교한다. DevOps는 협업 문화와 자동화, SRE는 SLO·에러 버짓으로 신뢰성을 공학 문제로 다루는 실천, 플랫폼 엔지니어링은 개발자가 스스로 쓰는 내부 플랫폼을 제품으로 만드는 일, NoOps는 서버리스로 운영 작업을 클라우드에 넘기는 지향이다. 클라우드를 들인 조직의 운영 모델(중앙 집중·분산·공유 서비스·CCoE), 통제가 아니라 가드레일로서의 거버넌스와 문화 전환, 테스트가 개발자 몫으로 옮겨 간 흐름과 회사 규모별 배포·품질 도구의 변화도 함께 다룬다.
AI & Data
조직 AX: 개발 자동화에서 전사 AI 전환까지AI 전환(AX)을 개발팀 도구에서 조직의 일하는 방식으로 넓히는 과정. 과거 PR 재현·레거시 마이그레이션·신규 서비스 실험으로 자동화 가능성을 재면 실패 원인이 AI가 아니라 요구사항과 맥락 부족임이 드러난다. 맥락을 핵심 자산으로 삼는 원칙, 한 달짜리 Quick Win, 비개발자 온보딩 허들과 GUI 우회, 설치·인증·배포를 감춘 사내 AI 플랫폼, 보안 스캔·승인·인증 프록시를 갖춘 바이브 코딩 앱 배포 파이프라인을 정리한다.
AI & Data
AI 네이티브 프론트엔드 개발코드를 AI만으로 쓰는 팀에서 프론트엔드가 일하는 방식. 금지 규칙 대신 대화로 뽑은 스킬, 구조를 직접 바꾸며 이해하기, 의도 정렬 순서, 이슈·PR로 맥락 관리, 병렬 작업과 이탈 감지, 디자인 픽셀 비교와 상태 재현 환경, BE·디자인을 정본으로 삼아 FE를 얇게 만들기, AI에게 관측 통로 달아 주기, 통합과 완성도로 옮겨 가는 역할을 정리한다.
Tools
개발과 협업, 분석, 3D 작업에 쓰는 도구들의 사용법 모음.
Tools › Code Review
리뷰 코멘트와 PR 소통의도가 정확히 전달되는 리뷰 코멘트 쓰는 법, PR에서 자주 쓰는 약어(LGTM·IMO·NIT·PTAL), 리뷰를 받는 쪽의 태도와 PR 템플릿.
Tools › Code Review
코드 리뷰 원칙과 체크리스트코드 리뷰를 왜 하는지(품질이 비용을 낮추는 이유, 리뷰의 다섯 가지 효과), 작성자와 리뷰어가 할 일, 자동화할 것과 사람이 볼 것을 나누는 원칙, 리뷰를 빠르게 돌리고 교착을 푸는 운영법, 가독성·부작용·경계 조건·보안·성능·테스트 체크리스트.
Tools
Git코드의 변경 이력을 기록하고 여러 사람이 동시에 작업할 수 있게 해 주는 분산 버전 관리 시스템.
Tools › Git
모노레포와 폴리레포여러 서비스의 코드를 저장소 하나에 두는 모노레포와 서비스마다 저장소를 나누는 폴리레포(마이크로레포)를 구조·권한·의존성 버전·코드 품질 기준·도구 면에서 비교하고, 폴리레포에서 의존성 버전을 맞추는 방법으로 버전 세트 기반 빌드 시스템(Amazon Brazil)의 구조를 정리했다.
Tools › Git
브랜치 전략: Git Flow, GitHub Flow, 트렁크 기반 개발팀이 브랜치를 어떻게 나누고 언제 합치는지 정한 규칙. 릴리스 주기가 긴 제품에 맞는 Git Flow(main·develop·feature·release·hotfix), 지속 배포에 맞는 GitHub Flow(main + 짧은 기능 브랜치 + PR), 하루 단위로 trunk에 합치는 트렁크 기반 개발을 비교하고 고르는 기준과 git-flow 도구의 현재 상태, 중앙 집중·기능 브랜치·포크 워크플로의 차이를 정리했다.
Tools › Git
영어 커밋 메시지 동사 사전영어 커밋 메시지는 작문이 아니라 패턴이다. Fix·Add·Remove·Use·Update·Improve·Make·Ensure·Prevent·Avoid 같은 동사 20여 개와 in·to·for·when·where 같은 전치사 패턴만으로 대부분의 커밋을 쓸 수 있다. 동사별 쓰임과 서로 헷갈리는 동사의 구분, 간결하게 쓰는 규칙을 정리한다.
Tools › Git
원격 저장소와 GitHubGit(버전 관리 도구)과 GitHub(호스팅·협업 서비스)의 차이, remote·push·pull·fetch·clone으로 로컬 저장소를 GitHub 같은 원격 저장소와 동기화하는 방법과, 이력을 유지한 채 다른 서비스로 옮기는 미러링.
Tools › Git
커밋 컨벤션과 자동 검사좋은 커밋 메시지의 7가지 규칙(빈 줄, 50/72자, 명령문 제목, 무엇·왜 본문)과 type(scope): subject 형식의 컨벤션, 커밋 템플릿 설정, husky와 commitlint로 규칙을 자동 검사하는 방법.
Tools › Git
Git 되돌리기와 이력 다루기reflog로 지나온 상태를 찾아 되돌리는 법과 상황별 복구 레시피(마지막 커밋 고치기, 다른 브랜치에 잘못한 커밋 옮기기, 파일 하나 되돌리기, 원격 상태로 초기화), reset·revert로 커밋을 되돌리고, cherry-pick으로 커밋 하나를 옮기며, 진행 중인 merge·rebase를 --abort로 취소하고, 푸시한 민감 정보·작성자를 filter-repo로 정리하는 방법. 공유된 이력이면 revert, 내 로컬 이력이면 reset이 기본이다.
Tools › Git
GitHub 이슈·프로젝트로 진행 상황 관리하기GitHub Issues를 작업 목록으로, Projects를 우선순위·상태 보드로 쓰고, 이슈를 브랜치·커밋·PR과 연결하면 저장소 하나에서 팀의 진행 상황이 투명하게 보인다. 이슈 크기 기준, 마일스톤·하위 이슈·프로젝트 보드(Status 칸과 기본 워크플로)로 묶어 보는 법, 스크럼 대응, 팀 개발 흐름과 리뷰 제출 종류, 문서화 원칙을 정리했다.
Tools › Git
GitHub 협업 저장소 설정팀 저장소를 처음 세팅할 때 할 일: 협업자·브랜치 보호 규칙·CODEOWNERS·이슈/PR 템플릿(마크다운 템플릿과 YAML 이슈 폼, config.yml)·라벨, 그리고 PR 알림 도구와 기능별 브랜치 습관.
Tools
Jira: 이슈 구성, JQL, 워크플로Jira 이슈의 주요 필드와 Epic·Component·Label을 구분해 쓰는 기준, JQL로 이슈를 구조적으로 검색하는 방법, 워크플로·Board·Sprint·스토리 포인트로 팀 업무를 운영할 때의 원칙과 실무 팁.
Career › Product
디자이너와 함께 일하기: 역할·채용·협업그래픽·인터랙션·UX 디자인의 차이, 디자이너를 뽑기 전에 정할 권한과 성공 기준, 서로 다른 관점을 섞는 팀 구성(경쟁가치모형), 디자이너·개발자·고객·브랜드 에이전시가 함께 일하는 원칙을 정리했다.
Career › Product
사용자 리서치: 방법 고르기, 페르소나·시나리오, 사용성 평가더블 다이아몬드의 단계마다 맞는 리서치 방법이 다르다. 사용자를 직접 못 만나면 리뷰·상담 기록·포럼을 쓰고, 조사 결과는 근거 있는 페르소나와 사용 전·중·후 UX 시나리오로 정리해 UX 전략으로 잇는다. 화면은 닐슨의 10가지 휴리스틱 평가와 5명 단위 사용성 테스트로 검증하고, 큰 조직에서는 정기 세션으로 학습 문화를 만든다. 급할수록 맥락·분석 시간·자기 디자인에 대한 애착을 경계하고, 참가자 보호를 위한 윤리 절차를 갖춘다.
Career › Product
스크럼: 책임·이벤트·산출물스크럼은 한 달 이하의 스프린트 안에서 투명성·검토·적응을 반복하는 가벼운 프레임워크다. 세 가지 책임(PO·스크럼 마스터·개발자), 다섯 가지 이벤트, 세 가지 산출물과 각각의 약속(제품 목표·스프린트 목표·완료의 정의)으로 구성된다. 2020년판 스크럼 가이드 기준으로 정리하고, 흔히 잘못 알려진 운영 방식을 함께 짚었다.
Career › Product
스포티파이 모델: 스쿼드·트라이브·챕터·길드와 그 한계자율적인 교차 기능 팀(스쿼드)을 트라이브로 묶고 직군별 챕터·길드로 가로지르는 매트릭스 조직 모델. 자율이 정렬보다 앞서고, 엔지니어링 책임자가 팀 밖에 있고, 협업 기술을 가정만 한 탓에 잘 작동하지 않았다. 모델을 통째로 들여오지 말고 책임 구조와 정렬 장치부터 설계한다.
Career › Product
애자일과 스프린트애자일의 핵심은 만들고-보여주고-피드백 받고-방향을 맞추는 주기를 모두가 함께 짧게 만드는 것이다. 스프린트는 목표를 쳐내는 마감 장치가 아니라 정해진 주기마다 속도와 방향을 점검하는 장치이며, 일정은 미리 예측하지 말고 만들어 보며 측정한다. 구글 스프린트 5일 구성과 장치들, 폭포수와 애자일을 고르는 기준도 함께 정리했다.
Career › Product
유스케이스 다이어그램UML 유스케이스 다이어그램으로 시스템이 누구에게 어떤 기능을 제공하는지 한 장에 그려 범위를 합의하는 법. 액터·유스케이스·시스템 경계, 연관·일반화·include·extend 관계, 작성 4단계, 정상·대안·예외 흐름과 시나리오를 담는 유스케이스 명세, 흔한 실수를 정리한다.
Career › Product
제품 중심 개발자 (Product-Minded Engineer)기획을 구현만 하지 않고 제품의 이유를 묻고, 제품·엔지니어링 트레이드오프를 함께 제안하며, 출시 후 데이터까지 책임지는 개발자의 9가지 특징과 성장 방법. 목적 조직에서 개발자가 맡는 역할과 OKR·애자일의 관계까지.
Career › Product
칸반과 린: 흐름과 낭비린은 고객 가치를 기준으로 낭비를 없애고 흐름을 만드는 사고방식이고, 칸반은 그것을 일에 적용해 보드로 시각화하고 진행 중인 일(WIP)을 제한해 당기는 흐름을 만드는 방법이다. 칸반·스크럼·스크럼반 비교, 흐름 지표와 리틀의 법칙, 낭비 유형, 가치 흐름 매핑, 병목과 제약 이론, 카이젠·PDCA를 정리했다.
Career › Product
콘텐츠 전략과 핵심 모델콘텐츠는 목적·핵심 메시지·다음 궁금증·운영 계획을 갖춰야 전략이 된다. 메인 페이지가 아니라 사업 목표와 사용자 작업이 겹치는 핵심 페이지부터 설계하는 핵심 모델(core model)과 워크숍 진행법을 정리했다.
Career › Product
BDD·SDD로 기획서를 태스크로 나누기기획·디자인·개발·QA가 같은 문서를 보도록 기획을 사용자 행동(BDD의 given-when-then)과 데이터 구조(SDD)로 정리해 태스크를 만드는 방법. then 하나가 태스크 하나가 되어 진척도·일정·테스트 범위가 함께 보이고, Figma에 디자인과 기획을 합쳐 두면 최신 화면까지 한곳에서 관리된다.
Career › Product
EoA: 불확실성을 다루는 애자일 메커니즘EoA(Essence of Agility, 기민함의 맥)는 정해진 실천법을 따라 하는 대신, 불확실할 때 효과적인 메커니즘을 이해하고 맥락에 맞는 실천법을 스스로 설계하게 하는 프레임워크다. 네 가지 상위 목표, 결과 관찰 질문(OOQ), 병목 정의, 팀 템플릿과 세션 운영법을 정리했다.
Career › Product
Shape Up: 6주 사이클 제품 개발 방식Basecamp가 만든 제품 개발 방식. 견적 대신 투입할 시간의 상한(appetite)을 먼저 정하고, 거칠지만 위험을 제거한 형태(shape)로 다듬은 피치를 베팅 테이블에서 골라 6주 동안 팀에 맡긴다. 백로그를 두지 않고, 시간이 다 되면 범위를 줄여서라도 끝낸다.
Career › Work
개발자 생산성: 무엇이 10배 차이를 만드나프로그래밍은 선형 노동이 아니라 설계라서 개인 간 생산성 차이가 곱으로 벌어진다. 10배 프로그래머를 만드는 요소(설계 희생, 단순함, 지식, 저수준 이해, 디버깅, 집중), 연구로 밝혀진 스타 엔지니어의 아홉 가지 업무 전략, 팀의 속도를 스프린트·마라톤·인터벌로 나눠 보는 모델과 속도를 깎는 요인, 프로그래머에 맞춘 뽀모도로와 집중 원칙을 정리한다.
Career › Work
개발자에서 리더로: 테크 리드·팀장이 바꿔야 할 것리더의 성과는 내 산출물이 아니라 팀이 만든 가치다. 기술 실력만 믿고 직접 코딩·통제에 매달리는 다섯 가지 실수를 피하고, 1:1 면담·업무 배정·심리적 안전감·피드백·목표와 문서화로 팀을 키운다.
Career › Work
소프트웨어 문서화: 네 가지 문서 유형과 코드에서 문서 만들기소프트웨어 문서는 목적에 따라 튜토리얼·하우투 가이드·레퍼런스·해설의 네 유형으로 나뉘고(Diátaxis), 한 문서는 한 유형만 따른다. 레퍼런스는 코드 구조를 따라 주석에서 자동 생성해 코드와 어긋나지 않게 한다. 무엇은 이름으로, 왜는 기록으로 남긴다. 프로젝트의 입구인 README에 담을 것과 README를 먼저 쓰는 README 주도 개발도 다룬다.
Career › Work
오픈소스 기여 시작하기: 문서·답변에서 코어 기여까지기여는 코드만이 아니다. 문서 번역, Q&A 답변, 리뷰, 글쓰기도 기여다. 쓰고 있는 라이브러리에서 good first issue로 시작하고, 소스 추적·토론 채널 참여·프로토타입으로 깊은 기여로 넘어간다.
Career › Work
오픈소스 라이선스: 허용형과 카피레프트오픈소스 라이선스는 사용·수정·배포를 허락하는 조건이다. MIT·BSD·Apache 2.0 같은 허용형과 MPL·LGPL·GPL·AGPL 같은 카피레프트를 소스 공개 의무, 같은 라이선스 강제, 특허 조항으로 비교하고, 라이선스 호환성, 라이선스 없는 저장소의 의미, SPDX 표기, 오픈소스가 아닌 소스 공개 라이선스(BSL·SSPL)로의 전환 흐름을 정리한다.
Career › Work
오픈소스 프로젝트 운영: 도입, 포크, 문서, 확산, 유지오픈소스는 공개만으로 쓰이지 않는다. 쓸 라이브러리는 인기·문서·인터페이스로 고르고, 포크할 때는 당위와 계획으로 신뢰를 얻는다. 문서와 예제가 성패를 가르고, 공개 후에는 이슈 대응·로드맵·메인테이너의 지속 가능성이 프로젝트를 살린다.
Career › Work
의사결정 체크리스트결정을 내리기 전에 무엇을, 언제까지, 누가, 누구와 상의해, 누구의 승인으로, 누구에게 알릴지 정하는 6가지 항목. 수평적인 팀에서는 결정 자체가 아니라 결정권자를 합의로 위임하고, 치열한 결정일수록 빠르게 정한다.
Career › Work
친절한 엔지니어링: 정직, 심리적 안전감, 피드백친절은 예의 바름(nice)이 아니라 상대에게 관심을 쏟아 그가 있는 자리에서 돕는 것(kind)이다. 정직하되 개인적으로 신경 쓰기, 코드 리뷰 같은 비동기 소통에서 '왜'를 묻기, 비난 없는 문화와 실패에서 배우기로 심리적 안전감 만들기, 피드백을 받는 법과 주는 법(감정·신뢰·논리)을 정리했다.
Career › Work
페어 프로그래밍두 사람이 드라이버와 내비게이터 역할을 번갈아 맡아 한 코드를 함께 짜는 애자일 실천법. 역할을 나누는 이유, 장단점, 핑퐁·포모도로·스트롱 스타일 같은 진행 방식, 짝을 존중하는 진행 규칙과 원격 도구를 정리한다.
Career › Work
협업을 잘하는 개발자: 프로그래머가 아니라 문제 해결사코드의 가치는 코드가 만드는 비즈니스 가치에서 나오고, 개발 직군만으로는 그 가치를 키우기 어렵기 때문에 개발자는 협업해야 한다. 문제의 본질 찾기·모순 해소·함께 풀기라는 문제 해결 원칙과 심리적 안전감, 의도와 맥락을 담은 말하기, 수평적 팀에서의 역할 감각을 정리했다.
Career › Work
회의 잘하는 법: 발산과 수렴회의가 산으로 가는 이유는 사람보다 방식에 있다. 발산 회의와 수렴 회의를 구분해 알리고, 결과물을 정의하고, 그라운드 룰과 짧은 마감을 두면 대부분의 회의가 나아진다. 참석자로서 쓸 수 있는 환기 질문과 침묵·반복을 깨는 장치까지 정리했다.