소프트웨어학과

애자일 방법론

Agile Methodology

1~4주짜리 짧은 반복 주기(스프린트)마다 실제로 동작하는 결과물을 내놓고 피드백을 반영하는 개발 방법론. 스크럼에서는 스프린트 시작 때 할 일을 정하는 스프린트 플래닝, 매일 진행상황을 공유하는 데일리 스탠드업, 끝나고 개선점을 논의하는 회고(retrospective)를 정해진 리듬으로 반복함.

ex) 카카오·네이버 같은 IT기업 개발팀이 2주 단위로 기능을 배포하는 방식.

디자인 패턴

Design Patterns

생성자를 private으로 막고 클래스 안에 정적 인스턴스 하나만 두어 어디서든 같은 객체를 참조하게 만드는 싱글턴, 어떤 객체(주체)의 상태가 바뀌면 등록된 관찰자들에게 자동으로 알림을 보내는 옵저버 패턴처럼, 반복되는 설계 문제에 대한 검증된 해결책을 정리해둔 것.

ex) 설정값을 앱 전체에서 하나만 유지하는 Config 객체가 싱글턴 패턴의 전형적인 예.

단위테스트와 TDD

Unit Testing & Test-Driven Development

실패하는 테스트를 먼저 작성(Red)하고, 그 테스트를 통과할 최소한의 코드를 작성(Green)한 뒤, 동작은 그대로 두고 코드 구조만 개선(Refactor)하는 사이클을 반복하는 개발 방법론.

ex) "이 함수는 짝수만 걸러야 한다"는 테스트를 먼저 쓰고 나서 실제 필터링 로직을 짜는 순서.

SOLID 원칙

SOLID Principles

클래스는 오직 하나의 책임만 져야 한다(단일책임), 기능 확장엔 열려있되 기존 코드 수정엔 닫혀있어야 한다(개방-폐쇄), 하위 타입은 상위 타입을 대체할 수 있어야 한다(리스코프 치환), 인터페이스는 필요한 기능만 작게 나눠야 한다(인터페이스 분리), 구체적인 구현이 아니라 추상화에 의존해야 한다(의존성 역전)는 5가지 객체지향 설계 원칙. 이 원칙을 지킬수록 코드 한 곳을 고쳐도 다른 곳이 덜 깨지는 유연한 구조가 됨.

ex) 결제 방식을 추가할 때 기존 결제 로직 코드를 건드리지 않고 새 클래스만 추가해서 확장하는 설계.

Git과 버전관리

Git & Version Control

각 커밋을 이전 커밋을 가리키는 SHA-1 해시값으로 식별해 방향성 비순환 그래프(DAG)로 이력을 관리하는 분산 버전관리 시스템. 두 브랜치를 합칠 때는 공통 조상, 브랜치A, 브랜치B 세 지점을 비교해 변경사항을 자동으로 합치는 3-way merge 알고리즘을 사용함.

ex) 코드의 변경 이력을 기록하고 여러 사람이 동시에 작업한 내용을 병합할 수 있게 해주는 시스템.

코드 리뷰 문화

Code Review Culture

변경된 부분(diff)만 비교해 보여주는 화면에서 동료가 로직 오류, 네이밍, 잠재적 버그를 지적하고 승인해야 병합(merge)되도록 하는 협업 관행. 리뷰가 병목이 되지 않도록 변경량을 작게(스몰 커밋) 유지하는 게 실무의 핵심 요령.

ex) GitHub Pull Request에서 코드 옆에 코멘트를 남기고 승인 버튼을 눌러야 배포되는 절차.

브랜칭 전략

Branching Strategies (Git Flow/Trunk-Based)

기능마다 별도 브랜치를 만들어 개발-리뷰-병합하는 Git Flow는 여러 기능을 안전하게 병렬 개발할 수 있지만 병합 충돌 위험이 크고, 모두가 하나의 메인 브랜치에 자주(하루에도 여러 번) 작은 변경을 바로 병합하는 트렁크 기반 개발은 충돌을 최소화하고 배포 속도를 높이지만 팀의 테스트 자동화 수준이 높아야 안전함. 팀 규모와 배포 빈도에 따라 다른 전략을 선택함.

ex) 빠른 배포를 지향하는 스타트업이 트렁크 기반 개발을, 안정성이 중요한 대기업 프로젝트가 Git Flow를 선호하는 경향.

MVC 패턴

Model-View-Controller Pattern

사용자 입력을 받은 컨트롤러가 모델(데이터·비즈니스 로직)을 갱신하고, 모델이 바뀌면 이를 구독하는 뷰(화면)가 자동으로 갱신되는 단방향에 가까운 데이터 흐름을 갖는 설계 패턴. 화면·로직·데이터를 분리해 한쪽을 바꿔도 다른 쪽에 영향이 적게 만듦.

마이크로서비스 아키텍처

Microservices Architecture

하나의 거대한 애플리케이션(모놀리스)을 기능 단위로 쪼개 각자 독립적으로 배포·확장 가능한 서비스로 만들고, 서비스끼리는 REST API나 gRPC로 통신하는 구조. 서비스마다 별도 DB를 두는 경우가 많아 여러 서비스에 걸친 데이터 일관성을 즉시 보장하기보다 지연을 허용하는 최종 일관성(eventual consistency)으로 타협하는 경우가 많음.

RESTful API 설계

RESTful API Design

자원을 URI로 표현하고, GET(조회)·PUT(전체수정)·DELETE(삭제)는 여러 번 호출해도 결과가 같은 멱등(idempotent) 연산으로, POST(생성)는 멱등하지 않게 설계하는 게 원칙인 API 설계 방식. 응답에는 성공(2xx), 클라이언트 오류(4xx), 서버 오류(5xx)를 구분하는 HTTP 상태 코드를 붙임.

이벤트소싱과 CQRS

Event Sourcing & CQRS

현재 상태 값만 덮어써 저장하는 대신, "무엇이 일어났는지"를 나타내는 이벤트를 순서대로 전부 기록해두고 현재 상태는 그 이벤트들을 처음부터 재생(replay)해 계산하는 이벤트소싱과, 데이터를 바꾸는 쓰기 모델과 조회하는 읽기 모델을 아예 분리해 각각을 독립적으로 최적화하는 CQRS(Command Query Responsibility Segregation)를 함께 쓰면, 상태 변화의 전체 이력을 보존하면서도 조회 성능을 따로 극대화할 수 있음.

ex) 은행 계좌의 현재 잔액뿐 아니라 모든 입출금 내역을 영구히 재구성할 수 있어야 하는 회계 시스템 설계.

레이어드 아키텍처와 헥사고날 아키텍처

Layered & Hexagonal Architecture

표현-비즈니스로직-데이터 접근을 수직으로 쌓아 각 층이 바로 아래 층만 호출하게 만드는 레이어드 아키텍처와, 핵심 비즈니스 로직을 중심에 두고 DB·외부API·UI 같은 세부 구현은 모두 포트-어댑터를 통해서만 연결되게 만들어 핵심 로직이 특정 기술에 종속되지 않게 하는 헥사고날 아키텍처. 후자는 DB를 MySQL에서 MongoDB로 바꿔도 핵심 비즈니스 로직 코드는 건드리지 않아도 되는 게 장점.

ex) 핵심 주문 처리 로직을 그대로 두고 결제 연동사만 토스에서 카카오페이로 갈아끼울 수 있게 설계하는 것.

클라이언트-서버 모델

Client-Server Model

클라이언트(브라우저)가 HTTP 요청을 보내면 서버가 이를 처리해 HTML·JSON 등을 응답으로 돌려주는 요청-응답 구조. HTTP는 상태를 저장하지 않는(stateless) 프로토콜이라, 로그인 상태 같은 걸 유지하려면 세션이나 토큰 같은 별도 장치가 필요함.

프론트엔드 프레임워크

Frontend Frameworks & Virtual DOM

실제 DOM을 매번 직접 조작하면 느리기 때문에, 메모리 상의 가상 DOM 트리를 먼저 갱신하고 이전 트리와 비교(diffing)해 실제로 바뀐 부분만 골라 진짜 DOM에 반영(reconciliation)하는 방식으로 렌더링 성능을 높이는 React 등의 프레임워크.

ex) React, Vue 등 UI를 컴포넌트 단위로 구성하는 프레임워크.

세션, 쿠키, JWT 인증

Sessions, Cookies & JWT Authentication

세션은 서버가 사용자 상태를 저장하고 클라이언트에는 세션ID만 쿠키로 주는 방식이고, JWT는 `헤더.페이로드.서명` 세 부분을 base64url로 인코딩한 토큰 자체에 사용자 정보를 담아 서버가 상태를 안 갖고도(stateless) 서명만 검증해 인증하는 방식.

ex) 로그인 후 서버 상태 없이 토큰만으로 API 호출을 인증하는 최신 웹서비스 방식.

CORS와 웹 보안 기초

CORS & Web Security Basics

브라우저는 기본적으로 한 웹사이트의 스크립트가 다른 도메인의 서버에 함부로 요청을 보내지 못하게 막는데(동일 출처 정책), 서버가 특정 다른 도메인의 요청은 허용한다고 명시적으로 응답 헤더에 표시하면 그 예외를 허용하는 게 CORS(교차 출처 리소스 공유). 이 정책과 이를 우회하려는 CSRF 공격 방어(토큰 검증)가 웹 API 보안 설계의 기본기.

ex) API 서버가 자사 프론트엔드 도메인의 요청만 허용하고 낯선 사이트의 요청은 브라우저 단에서 차단당하는 것.

네이티브 앱과 크로스플랫폼

Native vs Cross-Platform (React Native/Flutter)

iOS는 Swift, 안드로이드는 Kotlin으로 각각 개발하는 네이티브 방식은 성능과 플랫폼 기능 접근이 유리하고, React Native나 Flutter로 한 코드베이스를 양쪽에 컴파일하는 크로스플랫폼 방식은 개발 속도와 유지보수 비용에서 유리한 트레이드오프가 있음.

반응형 UI 설계

Responsive UI Design

화면 너비에 따라 다른 스타일을 적용하는 미디어쿼리와, 요소를 한 줄/여러 줄로 유연하게 배치하는 flexbox·grid 레이아웃을 조합해 같은 코드가 휴대폰·태블릿·PC 어디서든 자연스럽게 보이도록 만드는 설계 원칙.

앱 생명주기와 상태관리

App Lifecycle & State Management

모바일 앱은 사용자가 다른 앱으로 전환하거나 전화를 받으면 백그라운드로 밀려나고, 메모리가 부족하면 OS가 강제로 종료시킬 수도 있어, 화면이 꺼졌다 켜져도 입력하던 데이터가 사라지지 않도록 각 생명주기 단계(생성-시작-재개-일시정지-정지-소멸)마다 상태를 저장·복원하는 로직을 설계해야 함.

ex) 메시지 앱에서 답장을 쓰다가 전화를 받고 돌아와도 쓰던 내용이 그대로 남아있는 것.

ACID

ACID Properties

트랜잭션은 전부 실행되거나 전혀 안 되거나 둘 중 하나인 원자성(Atomicity), 제약조건을 항상 만족하는 상태로만 전이하는 일관성(Consistency), 동시 실행 트랜잭션이 서로 간섭하지 않는 것처럼 보이는 고립성(Isolation), 커밋된 결과는 장애 후에도 유지되는 지속성(Durability)을 보장해야 한다는 원칙.

정규화

Normalization

한 속성 값이 다른 속성 값을 결정하는 함수적 종속성을 분석해, 기본키 일부에만 종속되는 부분종속(2NF 위반)이나 비키 속성을 거쳐서만 종속되는 이행종속(3NF 위반)을 제거하도록 테이블을 쪼개는 과정. 중복은 줄지만 조인이 늘어 조회 성능이 떨어질 수 있는 트레이드오프가 있음.

트랜잭션 격리 수준

Transaction Isolation Levels

커밋 안 된 데이터를 읽는 더티 리드, 같은 행을 두 번 읽었는데 값이 바뀌는 반복불가능 읽기, 조건은 같은데 행 개수가 달라지는 팬텀 읽기를 어디까지 허용하느냐에 따라 Read Uncommitted < Read Committed < Repeatable Read < Serializable 순으로 격리 수준이 강해짐.

B+ 트리 인덱스

B+ Tree Index

한 노드가 여러 키를 갖도록 만들어 트리 높이를 낮춘 균형 탐색 트리. 데이터는 리프에만 두고 리프끼리 연결리스트로 이어, 탐색은 이고 범위 탐색도 리프를 순서대로 따라가면 되어 효율적임.

샤딩과 리플리케이션

Sharding & Replication

데이터를 키 값에 따라 여러 DB 서버에 나눠 저장해 쓰기 처리량을 늘리는 샤딩과, 같은 데이터를 여러 서버에 복제해두어 한 서버가 죽어도 서비스가 유지되고 읽기 처리량도 늘리는 리플리케이션. 원본(master)에 쓰고 복제본(replica)에서 읽게 하는 구조가 흔한데, 복제 지연 때문에 방금 쓴 데이터가 복제본에서는 잠깐 안 보일 수 있다는 점을 고려해 설계해야 함.

ex) 대형 쇼핑몰이 주문 데이터를 여러 DB 서버에 샤딩해 저장하고, 조회 전용 복제본을 따로 둬 조회 트래픽을 분산하는 것.

캐싱 전략

Caching Strategies

조회 시 캐시를 먼저 보고 없으면 DB에서 가져와 캐시에 채우는 cache-aside 방식과, 쓰기 시점에 캐시와 DB를 동시에 갱신하는 write-through 방식이 대표적. 어떤 데이터를 캐시에서 내릴지는 가장 오래 안 쓴 항목부터 지우는 LRU가 흔히 쓰임.

메시지 큐

Message Queue

생산자(producer)가 큐에 작업을 쌓아두면 소비자(consumer)가 자기 속도에 맞춰 꺼내 처리하는 비동기 구조. 특정 소비자 하나만 받는 점대점 방식과, 여러 구독자에게 같은 메시지를 뿌리는 발행-구독(pub-sub) 방식이 있어 서비스 간 결합도를 낮추고 트래픽 급증을 완충함.

확장성

Scalability (Vertical/Horizontal Scaling)

서버 한 대의 CPU·메모리를 늘리는 수직 확장은 한계가 명확한 반면, 같은 서버를 여러 대 두고 로드밸런서로 요청을 분산하는 수평 확장은 이론상 대수를 늘릴수록 처리량이 거의 선형으로 늘어나지만, 여러 대 사이의 데이터 동기화·일관성 문제가 새로 생기는 트레이드오프가 있음.

분산 트랜잭션과 사가 패턴

Distributed Transactions & Saga Pattern

마이크로서비스처럼 서비스마다 DB가 따로 있으면 여러 서비스에 걸친 작업을 하나의 ACID 트랜잭션으로 묶을 수 없는데, 모든 참여자가 준비됐는지 먼저 확인하고 나서 한 번에 커밋하는 2단계 커밋(2PC)은 한 참여자가 멈추면 전체가 잠기는 위험이 있어, 대신 각 단계를 로컬 트랜잭션으로 순차 실행하고 중간에 실패하면 이미 끝낸 단계들을 역순으로 취소(보상 트랜잭션)하는 사가 패턴을 널리 사용함.

ex) 주문·결제·배송이 각각 다른 마이크로서비스일 때, 배송 준비가 실패하면 이미 처리된 결제를 자동으로 환불 처리하는 것.

CDN과 엣지컴퓨팅

CDN & Edge Computing

이미지·동영상 같은 정적 콘텐츠를 원본 서버 한 곳에서만 서비스하면 물리적으로 먼 사용자일수록 응답이 느려지는데, 전 세계 여러 지역에 콘텐츠 사본을 미리 캐싱해두고 사용자와 가장 가까운 서버에서 응답하게 하는 CDN(콘텐츠 전송 네트워크)과, 아예 일부 연산 로직까지 사용자와 가까운 엣지 서버에서 처리해 지연시간을 최소화하는 엣지컴퓨팅.

ex) 해외 스트리밍 서비스가 한국 사용자에게도 버퍼링 없이 빠르게 재생되는 이유(국내 CDN 서버에서 콘텐츠를 받는 것).

사용성 휴리스틱

Usability Heuristics

시스템이 지금 뭘 하고 있는지 사용자가 알 수 있게 하는 "시스템 상태의 가시성", 실수해도 쉽게 되돌릴 수 있게 하는 "실행 취소 지원" 등 닐슨이 정리한 10가지 경험적 원칙으로 인터페이스를 평가하는 방법.

사용자 중심 설계

User-Centered Design

설계-프로토타입 제작-사용자 테스트-피드백 반영을 짧은 주기로 반복하며, 매 단계에서 실제 사용자의 행동을 관찰·검증해 인터페이스를 다듬는 방법론.

웹 접근성

Web Accessibility (WCAG)

시각·청각·운동 장애가 있는 사용자도 웹사이트를 문제없이 이용할 수 있도록, 이미지에는 대체 텍스트를 달고 키보드만으로도 모든 기능을 조작할 수 있게 하며 색상 대비를 충분히 확보하는 등의 국제 표준 지침(WCAG). 장애인만을 위한 게 아니라 밝은 야외에서 화면을 보는 사용자, 마우스 없이 작업하는 사용자 등 폭넓은 상황에서 실제로 사용성을 높여줌.

ex) 시각장애인이 스크린리더로 웹사이트를 이용할 때 이미지의 대체텍스트를 음성으로 들을 수 있는 것.

통합테스트와 E2E테스트

Integration & End-to-End Testing

개별 모듈은 정상이어도 모듈 간 인터페이스가 안 맞으면 문제가 생기므로, 여러 모듈을 결합한 상태로 검증하는 통합테스트와, 실제 사용자처럼 브라우저를 자동 조작해 로그인부터 결제까지 전체 흐름을 검증하는 E2E테스트.

회귀테스트

Regression Testing

기존에 통과했던 테스트 케이스들을 코드 수정 후 다시 실행해, 새로운 변경이 이전에 잘 되던 기능을 망가뜨리지 않았는지 확인하는 테스트. CI 파이프라인에 자동화해 커밋마다 돌리는 것이 일반적.

코드 커버리지와 뮤테이션 테스팅

Code Coverage & Mutation Testing

전체 코드 중 테스트가 실행해본 비율을 나타내는 코드 커버리지는 높다고 해서 테스트가 실제로 버그를 잘 잡아낸다는 보장은 없는데(코드를 지나치기만 해도 커버리지는 올라감), 뮤테이션 테스팅은 소스코드에 일부러 작은 결함(예: `>`를 `>=`로 변경)을 심어 넣고 기존 테스트가 그 결함을 잡아내는지 확인해 테스트 자체의 실질적인 품질을 검증하는 기법.

ex) 커버리지가 90%인데도 실제로는 버그를 못 잡는 형식적인 테스트를 골라내는 것.

워터폴과 애자일 방법론 비교

Waterfall vs Agile

요구분석-설계-구현-테스트를 순서대로 한 번씩 거치는 워터폴은 요구사항이 명확한 프로젝트에 적합하고, 짧은 주기로 반복하며 요구사항 변화에 대응하는 애자일은 불확실성이 큰 프로젝트에 적합하다는 게 일반적 구분.

사용자 스토리와 백로그 관리

User Stories & Backlog Management

"~로서 나는 ~하고 싶다, 왜냐하면 ~이기 때문이다" 형식으로 요구사항을 사용자 관점에서 짧게 적은 사용자 스토리를 우선순위에 따라 쌓아둔 목록(백로그)으로 관리하며 스프린트마다 상위 항목부터 꺼내 작업함.

칸반보드와 WIP 제한

Kanban Board & WIP Limits

작업을 "할일-진행중-완료" 같은 열로 나눠 카드로 시각화하는 칸반보드에서, 각 "진행중" 열에 동시에 놓일 수 있는 작업 개수(WIP: Work In Progress)를 의도적으로 제한하는 기법. 사람이 동시에 여러 작업을 벌이면 하나도 제대로 못 끝내는 경우가 많은데, WIP를 제한하면 팀이 하나씩 확실히 끝내고 넘어가도록 강제해 실제 완료 속도(처리량)가 오히려 빨라짐.

ex) 개발팀이 "진행중" 칸에 3개 이상 카드가 못 들어가게 제한해 작업이 쌓이지 않고 계속 흘러가게 만드는 것.