#process
노트 28개
Computer Science › Engineer Information Processing
소프트웨어 프로젝트 관리: 비용 산정·일정·위험프로젝트의 정의와 착수·계획·실행·통제·종료 단계, 참고 틀(PMBOK, ISO/IEC/IEEE 12207)과 CMMI 성숙도 5단계, WBS와 롤링 웨이브 계획, 비용 산정 기법(전문가 감정·델파이·LOC·COCOMO 모드별 계수·Putnam·기능 점수 가중치와 보정 공식), PERT 네트워크의 ES/EF·LS/LF 계산과 주 경로, EVM 지표(SV·CV·SPI·CPI·EAC·VAC), 위험의 식별·분석·대응(회피·완화·전가·수용)을 정리한다.
Computer Science
운영체제하드웨어와 프로그램 사이에서 자원을 관리하고 실행 환경을 제공하는 시스템 소프트웨어에 대한 노트 모음. 프로세스·메모리·파일의 이론과 함께 UNIX 시스템 프로그래밍(파일 디스크립터, 시그널, 셸, pthread, 타이머)과 리눅스 운영(systemd, 접근 제어, 배포판, 가상화)을 다룬다.
Computer Science › Operating System
교착 상태프로세스들이 서로의 자원을 기다리며 멈추는 교착 상태의 4가지 발생 조건, 자원 할당 그래프, 예방·회피(은행원 알고리즘)·탐지와 복구·무시.
Computer Science › Operating System
데몬과 systemd터미널과 분리되어 백그라운드에서 도는 데몬의 개념, SysV 방식의 이중 fork 데몬화가 필요했던 이유, 그 일을 대신 해 주는 systemd의 유닛·서비스·타이머, cron을 대체하는 systemd 타이머와 journalctl 로그를 정리한다.
Computer Science › Operating System
동시성·병렬·비동기·논블로킹과 동시성 모델동시성(논리적으로 함께 진행)과 병렬(물리적으로 동시에 실행), 동기·비동기(완료를 누가 확인하나)와 블로킹·논블로킹(제어권을 바로 돌려받나)을 구분하고, 스레드보다 가벼운 실행 단위(파이버·코루틴·그린 스레드·가상 스레드), async/await와 CPS, Reactor·Proactor, 공유 메모리 대신 메시지를 쓰는 CSP·액터, Go·Tokio·BEAM 런타임의 스케줄링, GIL과 그 대안을 한 지도로 정리한다.
Computer Science › Operating System
셸이 명령을 실행하는 방식셸이 한 줄의 명령을 토큰화·파싱·확장한 뒤 fork·exec·wait와 pipe·dup2로 실행하는 과정. 파이프라인이 동시에 실행되는 이유, 쓰지 않는 파이프 끝을 닫아야 하는 이유, heredoc·서브셸·종료 상태까지 정리한다.
Computer Science › Operating System
운영체제의 시간과 타이머운영체제가 다루는 세 가지 시간(벽시계·단조·프로세스 CPU 시간), 이를 재는 하드웨어(RTC·HPET·TSC), POSIX 시계 API, sleep 계열 함수, alarm과 인터벌 타이머를 정리한다. 경과 시간은 단조 시계로 재야 하는 이유가 핵심이다.
Computer Science › Operating System
프로세스 동기화공유 데이터에 동시에 접근할 때 생기는 경쟁 상태, 운영체제 안의 경쟁 상태, 임계 구역 문제와 해결 조건, 피터슨 알고리즘과 Test-and-Set, 뮤텍스 락과 세마포어(상호 배제·실행 순서 제어), 고전적인 동기화 문제, 모니터의 진입 큐와 조건 변수.
Computer Science › Operating System
프로세스 상태와 CPU 스케줄링프로세스 상태 전이, CPU burst와 성능 척도, 선점·비선점 스케줄링 알고리즘(FCFS·SJF·HRN·RR·MLFQ), 다중 프로세서·실시간·스레드 스케줄링, 문맥 교환 비용 정리.
Computer Science › Operating System
프로세스와 스레드프로세스의 문맥과 메모리 영역(코드·데이터·힙·스택), PCB, 문맥 교환, 스레드의 구조와 장점, 사용자 수준·커널 수준 스레드 모델(N:1·1:1·M:N), 멀티프로세스와 멀티스레드 비교, fork·exec·wait·exit, IPC 수단과 파이프·FIFO·공유 메모리·메시지 큐 사용법.
Computer Science › Operating System
POSIX 스레드와 동기화 APIC에서 스레드를 다루는 POSIX pthread API와 동기화 도구. 스레드 생성·join·detach, 뮤텍스와 조건 변수, POSIX 세마포어, 원자성을 하드웨어가 보장하는 방법, 커널 내부의 스핀락, Java 모니터와의 대응을 정리한다.
Computer Science › Operating System
UNIX 시그널커널이나 다른 프로세스가 프로세스에 보내는 비동기 알림인 시그널. 주요 시그널과 기본 동작, sigaction과 핸들러 작성 규칙, 보류·병합 특성, SIGCHLD와 좀비 프로세스, 시그널을 통신에 쓸 때의 한계를 정리한다.
DevOps
장애 대응과 포스트모템장애는 탐지 → 전파 → 해결 → 보고 → 회고의 다섯 단계로 다룬다. 해결은 확산을 막는 임시 조치(롤백·재기동·증설·기능 스위치)가 먼저고, 보고서와 비난 없는 포스트모템으로 재발 방지·탐지·처리 개선 과제를 검증 가능한 액션 아이템으로 남긴다.
AI & Data
시각화 설계 과정: 과업 분석, 상호작용, 평가시각화 도구는 사용자가 데이터로 무엇을 하려는지(과업)를 먼저 끌어내고, 스케치와 프로토타입을 반복해 형태를 정하고, 개관 → 확대·필터 → 세부 순서의 상호작용을 붙인 뒤, 사용자가 얻은 통찰(정성)과 통제 실험의 정확도·속도(정량)로 평가한다.
Tools › Git
GitHub 이슈·프로젝트로 진행 상황 관리하기GitHub Issues를 작업 목록으로, Projects를 우선순위·상태 보드로 쓰고, 이슈를 브랜치·커밋·PR과 연결하면 저장소 하나에서 팀의 진행 상황이 투명하게 보인다. 이슈 크기 기준, 마일스톤·하위 이슈·프로젝트 보드(Status 칸과 기본 워크플로)로 묶어 보는 법, 스크럼 대응, 팀 개발 흐름과 리뷰 제출 종류, 문서화 원칙을 정리했다.
Career › Product
기술 부채기술 부채는 지금 빠른 길을 택한 대가로 나중에 치르는 추가 작업이다. 원금(고치는 비용)과 이자(고치지 않아 매번 더 드는 비용)로 생각하고, 파울러의 사분면으로 원인을 나누며, 백로그 항목으로 보이게 만든 뒤 이자가 큰 곳부터 갚는다.
Career › Product
백로그와 추정: 에픽·사용자 스토리·스토리 포인트큰 목표를 에픽과 사용자 스토리로 쪼개고(3C, INVEST, 인수 기준), 스토리 포인트와 플래닝 포커로 상대 크기를 추정하고, 속도와 번다운·번업 차트로 진척을 본다. 각 도구는 계획을 돕는 설명 지표이지 성과 지표가 아니라는 점이 핵심이다.
Career › Product
사용자 리서치: 방법 고르기, 페르소나·시나리오, 사용성 평가더블 다이아몬드의 단계마다 맞는 리서치 방법이 다르다. 사용자를 직접 못 만나면 리뷰·상담 기록·포럼을 쓰고, 조사 결과는 근거 있는 페르소나와 사용 전·중·후 UX 시나리오로 정리해 UX 전략으로 잇는다. 화면은 닐슨의 10가지 휴리스틱 평가와 5명 단위 사용성 테스트로 검증하고, 큰 조직에서는 정기 세션으로 학습 문화를 만든다. 급할수록 맥락·분석 시간·자기 디자인에 대한 애착을 경계하고, 참가자 보호를 위한 윤리 절차를 갖춘다.
Career › Product
새 서비스 개발 프로젝트 진행 순서기획 → 개발 기반 구축 → 개발 진행 → 서비스 진화의 기승전결로 정리한 서비스 개발 절차.
Career › Product
스크럼: 책임·이벤트·산출물스크럼은 한 달 이하의 스프린트 안에서 투명성·검토·적응을 반복하는 가벼운 프레임워크다. 세 가지 책임(PO·스크럼 마스터·개발자), 다섯 가지 이벤트, 세 가지 산출물과 각각의 약속(제품 목표·스프린트 목표·완료의 정의)으로 구성된다. 2020년판 스크럼 가이드 기준으로 정리하고, 흔히 잘못 알려진 운영 방식을 함께 짚었다.
Career › Product
스포티파이 모델: 스쿼드·트라이브·챕터·길드와 그 한계자율적인 교차 기능 팀(스쿼드)을 트라이브로 묶고 직군별 챕터·길드로 가로지르는 매트릭스 조직 모델. 자율이 정렬보다 앞서고, 엔지니어링 책임자가 팀 밖에 있고, 협업 기술을 가정만 한 탓에 잘 작동하지 않았다. 모델을 통째로 들여오지 말고 책임 구조와 정렬 장치부터 설계한다.
Career › Product
애자일과 스프린트애자일의 핵심은 만들고-보여주고-피드백 받고-방향을 맞추는 주기를 모두가 함께 짧게 만드는 것이다. 스프린트는 목표를 쳐내는 마감 장치가 아니라 정해진 주기마다 속도와 방향을 점검하는 장치이며, 일정은 미리 예측하지 말고 만들어 보며 측정한다. 구글 스프린트 5일 구성과 장치들, 폭포수와 애자일을 고르는 기준도 함께 정리했다.
Career › Product
유스케이스 다이어그램UML 유스케이스 다이어그램으로 시스템이 누구에게 어떤 기능을 제공하는지 한 장에 그려 범위를 합의하는 법. 액터·유스케이스·시스템 경계, 연관·일반화·include·extend 관계, 작성 4단계, 정상·대안·예외 흐름과 시나리오를 담는 유스케이스 명세, 흔한 실수를 정리한다.
Career › Product
조직의 디지털 전환과 웹 거버넌스디지털 전환은 기술 도입이 아니라 고객 행동 변화에 조직을 맞추는 일이다. 디지털 성숙도 5단계, 웹 거버넌스의 네 영역(전략·관리·실행·측정), 권한 없는 실무자가 변화를 이끄는 방법을 정리했다.
Career › Product
칸반과 린: 흐름과 낭비린은 고객 가치를 기준으로 낭비를 없애고 흐름을 만드는 사고방식이고, 칸반은 그것을 일에 적용해 보드로 시각화하고 진행 중인 일(WIP)을 제한해 당기는 흐름을 만드는 방법이다. 칸반·스크럼·스크럼반 비교, 흐름 지표와 리틀의 법칙, 낭비 유형, 가치 흐름 매핑, 병목과 제약 이론, 카이젠·PDCA를 정리했다.
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주 동안 팀에 맡긴다. 백로그를 두지 않고, 시간이 다 되면 범위를 줄여서라도 끝낸다.