#software-engineering
노트 33개
Frontend › Architecture
결합도를 낮추는 전략결합도는 코드를 고쳤을 때 영향이 미치는 범위다. 모듈 결합도의 고전적 6단계 분류(자료~내용)와 높은 결합의 신호를 정리하고, 페이지 전체 쿼리 파라미터를 한 훅에 몰지 않고 책임별로 쪼개고, 앞으로 갈라질 수 있는 코드는 중복을 허용하고, Props Drilling은 조합(children) 패턴으로 먼저 풀고 마지막에 Context를 쓴다. 앱 규모에서는 기능 모듈이 서로를 부르지 않고 퍼사드(샌드박스)와 중재자(앱 코어)를 거치게 한다.
Frontend › Architecture
응집도를 높이는 전략응집도는 함께 수정돼야 할 코드가 항상 함께 수정되는지다. 모듈 응집도의 고전적 7단계 분류(기능적~우연적)와 낮은 응집의 신호를 정리하고, 함께 바뀌는 파일을 도메인 디렉토리에 모으고, 매직 넘버를 상수로 묶어 한쪽만 바뀌는 일을 막고, 폼은 변경 단위에 따라 필드 단위 검증과 스키마 기반 폼 전체 검증 중 하나를 고른다.
Frontend › Architecture
추상화 계층과 데이터 흐름요구사항을 데이터로 표현하면 구현이 되고, 구현에 알맞은 수준의 이름을 붙이면 추상화가 된다. 잘 변하지 않는 추상화가 쌓여 계층이 되고, 계층 사이를 사용자 중심으로 순환하는 데이터 흐름이 코드의 자리를 정한다. 요구사항을 이 계층과 흐름의 구간으로 쪼개 채우는 사고법(그라데이션 사고)을 정리한다.
Frontend › Architecture
프론트엔드에서 관심사의 분리관심사의 분리는 한 단위가 하나의 선명한 기준으로 구분되게 해 인지 부하를 줄이는 일이다. 프론트엔드는 역할(HTML·CSS·JS) → 기능(컴포넌트) → 컴포넌트 안의 다시 계층으로 분리 축을 바꿔 왔고, 관심사는 모듈·레이어·데이터 흐름 여러 방향이 있어 프로젝트 시기마다 우선순위가 달라진다.
Backend › Architecture
도메인 주도 설계(DDD)비즈니스 도메인을 모델로 표현하고 그 모델이 코드·DB·API 설계를 이끌게 하는 방법론이다. 유비쿼터스 언어와 바운디드 컨텍스트로 모델의 경계를 잡고, 엔티티·값 객체·애그리거트로 모델을 짜며, 리포지토리·팩토리·도메인 서비스·도메인 이벤트로 다룬다.
Backend › Architecture
소프트웨어 아키텍처 패턴계층형, 클라이언트-서버, 이벤트 기반, 마이크로서비스, 플러그인(마이크로커널), 헥사고날(포트와 어댑터) 아키텍처를 구조·장점·약점으로 비교하고, 구성 요소·커넥터와 제어·데이터 흐름으로 스타일을 가르는 다섯 계열(데이터 흐름, 호출-반환, 독립 구성 요소, 데이터 중심, 가상 머신)과 문제 모양별 선택 경험칙을 정리한다. 패턴마다 얻는 것과 치르는 것이 다르므로 시스템의 변경 방향과 팀 규모를 보고 고른다.
Backend › Architecture
시스템 설계의 품질 속성과 트레이드오프확장성·가용성·신뢰성·성능이라는 네 가지 품질 속성의 뜻과 달성 수단, 설계에서 늘 부딪치는 다섯 가지 트레이드오프, 시스템 설계를 이루는 빌딩 블록, 목표·범위·규모에서 상위 설계·병목까지의 설계 진행 순서와 지연 시간 숫자로 하는 어림셈, 요구 사항에서 이전 계획까지 설계 논의의 체크리스트, 그리고 CAP·BASE·KISS 같은 약어를 한 곳에 정리했다.
Backend
백엔드 테스트: 범위, 대역, 구조, 자동화도메인 로직은 프레임워크 없는 단위 테스트로, 경계는 실제 자원이나 에뮬레이터(Testcontainers·LocalStack)로 검증한다. 목은 통제할 수 없는 의존성에만 쓰고, 테스트는 공개 인터페이스만 보며 수를 줄인다. Describe-Context-It으로 구조화하고, CI는 결과를 PR 단계에 보여 준다.
Computer Science
정보처리기사정보처리기사 실기에서 여러 회차에 반복해서 나오는 개념을 주제별로 묶은 요약 노트 모음.
Computer Science › Engineer Information Processing
소프트웨어 설계와 공학개발 생명주기 모델(폭포수·원형·나선형·V·UP·애자일), 요구공학(추출·분석·명세·검증, EARS, 추적 매트릭스), 구조적 분석·설계(문맥도·DFD·구조 차트)와 UML 객체지향 분석·설계(경계·제어·실체 클래스, 시퀀스·활동·상태 머신), 모듈 결합도·응집도와 복잡도 척도(McCabe 순환 복잡도, Halstead), 사용자 인터페이스 황금률, 디자인 패턴, 유지보수 유형과 Lehman 법칙·재공학, 형상 관리, CASE 도구 정리. 프로젝트 관리(비용 산정·일정·EVM·위험)는 별도 노트로 분리했다.
Computer Science › Engineer Information Processing
소프트웨어 테스트ISO/IEC 25010 품질 특성과 McCall 모델, 품질 보증·품질 관리·감사와 테스트의 차이, 테스트 원리와 에러·결함·고장, V-모델의 테스트 레벨과 검증·확인, 명세 기반 기법(동등 분할·경곗값·결정 테이블·상태 전이·페어와이즈)과 구조 기반 커버리지(문장~MC/DC)의 실제 케이스 도출, 테스트 오라클, 통합 테스트, ISO/IEC/IEEE 29119 테스트 프로세스와 위험 기반 테스트, 결함 관리, AI 소프트웨어 테스트(변성 테스팅, 뉴런 커버리지) 정리.
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 › Programming Languages
좋은 코드를 위한 열 가지 원칙코드 규약 준수, 이유를 남기는 주석, 견고함, SOLID, 테스트하기 쉬운 구조, 적당한 추상화, 과설계 없는 패턴 사용, 전역 의존 줄이기, 지속적인 리팩터링, 보안 우선이라는 열 가지 코딩 원칙을 각각 왜 필요한지와 함께 정리하고, 원칙끼리 부딪칠 때의 판단 기준을 덧붙인다.
Computer Science › Programming Languages
책임 주도 설계: 협력·책임·메시지객체지향 설계는 좋은 객체가 아니라 좋은 협력을 설계하는 일이다. 메시지를 먼저 정하고 그 메시지를 처리할 책임을 가진 객체를 고른다. 객체가 받는 메시지의 집합이 인터페이스가 되고, 속성은 책임을 정한 뒤에 따라온다.
Computer Science › Programming Languages
추상 클래스와 인터페이스인스턴스를 만들 수 없는 추상 클래스와, 구현할 행동의 계약만 정하는 인터페이스를 Java 기준으로 비교한다. 추상 클래스는 상태와 공통 구현을 물려주는 'is-a' 관계, 인터페이스는 여러 개를 붙일 수 있는 'can-do' 역할이며, Java 8 이후 디폴트 메서드로 경계가 흐려졌어도 상태를 가질 수 있느냐가 결정적 차이다.
Computer Science › Programming Languages
클린 코드: 함수와 이름『클린 코드』의 함수와 이름 규칙을 정리한다. 나쁜 코드가 비싼 이유와 보이스카우트 규칙, 피해야 할 습관도 다룬다. 함수는 작게, 한 가지만, 한 추상화 수준으로 쓰고 위에서 아래로 이야기처럼 읽히게 배치한다. 값을 돌려주는 질의와 상태를 바꾸는 명령은 나눈다(명령-질의 분리). 타입 분기는 팩터리 한 곳에 가두고 나머지는 다형성에 맡기며, 이름은 의도를 드러내고 한 개념에 한 단어만 쓴다.
Computer Science › Programming Languages
GoF 디자인 패턴객체 지향 설계에서 반복되는 문제의 검증된 해법인 GoF 디자인 패턴을 생성·구조·행위 세 갈래로 나눠, 패턴마다 푸는 문제와 한 줄 비유로 정리한다. 패턴은 어휘이자 도구이며, 필요 없는 곳에 쓰면 오히려 복잡도를 늘린다.
Computer Science
달력과 시간에 대한 개발자의 착각하루는 24시간, 1년은 12개월, 시간대는 정시 단위, 날짜는 빠짐없이 이어진다는 가정이 모두 틀리는 사례를 날·주, 달력 체계, 윤년·연도, 시간대, 서머타임으로 묶고, 윤초와 여러 시간 표현(UTC·TAI·GPS 시간·Unix 시간·TrueTime), 리프 스미어를 덧붙였다. 결론은 직접 계산하지 말고 검증된 날짜 라이브러리와 IANA tz 데이터에 맡기라는 것이다.
Computer Science
소프트웨어 복잡성: 본질적 복잡성과 우발적 복잡성큰 소프트웨어를 만들기 어려운 근본 원인은 이해하기 어렵다는 것, 곧 복잡성이다. 문제 자체에 있는 본질적 복잡성과 도구·설계가 덧붙인 우발적 복잡성을 나누고, 복잡성의 주원인인 상태·제어 흐름·코드 양, 「단순함(simple)」과 「쉬움(easy)」의 차이와 얽힘(complect), 피하고(avoid) 분리하라(separate)는 처방을 정리한다.
Computer Science
소프트웨어 비대화하드웨어가 빨라진 만큼 소프트웨어가 느려지고 커져서 사용자가 체감하는 속도는 그대로인 현상. 「개발자 시간이 더 비싸다」는 논리로 쌓인 의존성·계층·임시방편이 원인이다. 효율을 기본값으로 두고, 의존성을 아끼고, 증상이 아니라 원인을 고치고, 재현 가능하게 만든다.
Computer Science
소프트웨어 안전: 위험원 분석과 결함 허용 설계허용 가능한 위험만 남은 상태를 안전으로 정의하고, 소프트웨어 결함이 사고로 이어진 사례, 결함 예방·검출·제거·허용의 네 전략, 중복성과 다양성, IEC 61508을 뿌리로 한 분야별 안전 표준과 SIL, FMEA·FTA·HAZOP 안전 분석을 정리한다.
DevOps
12요소 앱클라우드에서 확장·배포·운영하기 쉬운 애플리케이션을 만드는 열두 가지 원칙(코드베이스, 의존성, 설정, 백엔드 서비스, 빌드·릴리스·실행, 프로세스, 포트 바인딩, 동시성, 폐기 가능성, 개발·운영 일치, 로그, 관리 프로세스)을 각 원칙이 막는 문제와 지금의 구현 방식으로 정리했다.
DevOps
플랫폼 엔지니어링: 내부 개발자 플랫폼과 골든 패스플랫폼 엔지니어링은 개발팀마다 반복되는 인프라·배포·보안 작업을 내부 개발자 플랫폼(IDP)이라는 내부 제품으로 묶어 셀프서비스로 제공하는 일이다. 개발자를 고객으로 보는 제품 관점, IDP의 다섯 구성 요소와 플랫폼 오케스트레이터, 포털과 플랫폼의 차이, 골든 패스(포장된 길)의 네 가지 성질과 설계법, 최소 실행 가능 플랫폼에서 시작해 키우는 방식을 정리한다.
DevOps
DevOps, SRE, 플랫폼 엔지니어링, NoOps와 클라우드 거버넌스개발과 운영을 잇는 방식의 갈래를 비교한다. DevOps는 협업 문화와 자동화, SRE는 SLO·에러 버짓으로 신뢰성을 공학 문제로 다루는 실천, 플랫폼 엔지니어링은 개발자가 스스로 쓰는 내부 플랫폼을 제품으로 만드는 일, NoOps는 서버리스로 운영 작업을 클라우드에 넘기는 지향이다. 클라우드를 들인 조직의 운영 모델(중앙 집중·분산·공유 서비스·CCoE), 통제가 아니라 가드레일로서의 거버넌스와 문화 전환, 테스트가 개발자 몫으로 옮겨 간 흐름과 회사 규모별 배포·품질 도구의 변화도 함께 다룬다.
Tools › Code Review
리팩터링 원칙마틴 파울러 『리팩터링』(2판) 1·2장에서 뽑은 원칙. 리팩터링의 정의, 기능 추가와 리팩터링을 나누는 두 개의 모자, 테스트 먼저, 3의 법칙, 성능은 다듬은 뒤에 챙긴다는 태도를 정리한다.
Tools › Code Review
삭제하기 쉬운 코드코드는 쓰는 순간부터 유지 비용을 낳는다. 확장성과 재사용을 미리 설계하기보다, 바뀔 가능성을 기준으로 경계를 나눠 나중에 쉽게 버리고 바꿀 수 있게 쓴다. 쓰지 않기 → 복사 → 함수 추출 → 보일러플레이트 허용 → 래퍼 → 덩어리 → 변경 경계 분리의 단계로 정리한다.
Tools › Code Review
Simple Design코드 품질을 '가독성'·'깔끔함' 같은 느낌 대신 객관적 기준으로 다루기 위해 켄트 벡의 Simple Design을 '중복이 없으면서 최소한의 문법 요소로 구성된 코드'로 줄여 쓰는 방법. 중복 제거 시점, 비용과의 타협, 본질적 복잡성 다루기, DRY·KISS·YAGNI와의 관계까지 정리한다.
Tools › Git
모노레포와 폴리레포여러 서비스의 코드를 저장소 하나에 두는 모노레포와 서비스마다 저장소를 나누는 폴리레포(마이크로레포)를 구조·권한·의존성 버전·코드 품질 기준·도구 면에서 비교하고, 폴리레포에서 의존성 버전을 맞추는 방법으로 버전 세트 기반 빌드 시스템(Amazon Brazil)의 구조를 정리했다.
Career › Product
기능 공장: 출시량이 아니라 결과를 보는 팀기능을 많이 내보내는 것을 성과로 착각하는 팀을 기능 공장이라 부른다. 측정·회고·사후 점검이 없고 로드맵이 기능 목록인 12가지 신호로 진단하고, 출력(output) 대신 결과(outcome)와 학습을 기준으로 일하도록 바꾼다.
Career › Product
기술 부채기술 부채는 지금 빠른 길을 택한 대가로 나중에 치르는 추가 작업이다. 원금(고치는 비용)과 이자(고치지 않아 매번 더 드는 비용)로 생각하고, 파울러의 사분면으로 원인을 나누며, 백로그 항목으로 보이게 만든 뒤 이자가 큰 곳부터 갚는다.
Career › Work
개발자 생산성: 무엇이 10배 차이를 만드나프로그래밍은 선형 노동이 아니라 설계라서 개인 간 생산성 차이가 곱으로 벌어진다. 10배 프로그래머를 만드는 요소(설계 희생, 단순함, 지식, 저수준 이해, 디버깅, 집중), 연구로 밝혀진 스타 엔지니어의 아홉 가지 업무 전략, 팀의 속도를 스프린트·마라톤·인터벌로 나눠 보는 모델과 속도를 깎는 요인, 프로그래머에 맞춘 뽀모도로와 집중 원칙을 정리한다.
Career › Work
소프트웨어 문서화: 네 가지 문서 유형과 코드에서 문서 만들기소프트웨어 문서는 목적에 따라 튜토리얼·하우투 가이드·레퍼런스·해설의 네 유형으로 나뉘고(Diátaxis), 한 문서는 한 유형만 따른다. 레퍼런스는 코드 구조를 따라 주석에서 자동 생성해 코드와 어긋나지 않게 한다. 무엇은 이름으로, 왜는 기록으로 남긴다. 프로젝트의 입구인 README에 담을 것과 README를 먼저 쓰는 README 주도 개발도 다룬다.
Career
개발 분야별 추천 도서CS 기초, 알고리즘, 설계·코드 품질, DevOps·SRE, 프론트엔드·UX, 언어·도구, 일하는 방식·커리어까지 분야별 개발 서적과 각 분야의 입문 경로, 그리고 분산 시스템을 바꾼 고전 논문.