LIFECYCLE · 04 / 06
구현
컴포넌트를 조립해 시스템을 만든다. 재사용 자산·패턴·프레임워크의 이해가 생산성을 가른다.
CBD 방법론
검증된 컴포넌트를 조립해 개발하는 방법론. 재사용성과 유지보수성을 높인다.
CBD는 재사용을 전제하므로 설계(앞단)에 더 많은 역량을 투입해야 하는 선제 대응형 방법론이다. 역량이 준비되지 않은 채 도입하면 오히려 더디다. 재사용 자산은 직접 만들어 본 만큼만 쌓인다.
구현 · 방법론애자일
짧은 반복으로 빠르게 결과물을 내는 방법론. 현업의 적극적 참여가 전제.
애자일은 조직의 성숙도와 현업의 적극적 참여가 전제되어야 작동한다. 중간 프로세스를 생략하는 만큼 사람과 신뢰가 그 공백을 메워야 하며, 준비되지 않은 애자일은 워터폴보다 위험하다.
구현 · 방법론ooCBD
객체지향 기술과 컴포넌트 기반 개발을 결합한 방법론.
컴포넌트 분할의 적정선은 부품을 얼마나 많이 쪼갰느냐가 아니라, 인터페이스를 바꾸지 않고도 내부를 자유롭게 고칠 수 있느냐로 정해진다. 재사용은 거저 얻어지지 않으며, 인터페이스를 일반화하고 의존성을 정리한 선행 투자가 이익을 넘어서는 지점을 가늠하는 것이 방법론 적용의 핵심이다.
구현 · 아키텍처MSA
큰 애플리케이션을 독립 배포 가능한 작은 서비스로 분해하는 아키텍처.
MSA의 성패는 서비스를 몇 개로 쪼갰느냐가 아니라, 각 서비스가 자기 데이터를 온전히 소유해 다른 서비스의 배포를 강제하지 않느냐로 갈린다. 빌드·배포·모니터링 자동화 같은 DevOps 역량이 갖춰지지 않은 조직이 성급히 분리하면, 독립의 이점은 사라지고 분산된 모놀리식이라는 운영 부담만 남는다.
구현 · 아키텍처MDA
코드가 아닌 모델 중심으로 시스템을 구축하고 도구로 코드를 변환한다.
MDA의 성패는 코드 생성 도구의 성능이 아니라 모델을 단일 진실의 원천으로 유지할 수 있는 규율에 달려 있다. 생성된 코드를 직접 수정하기 시작하는 순간 모델과 구현이 어긋나며, 변경이 잦은 영역은 모델 주도에서 의도적으로 제외하는 선택이 오히려 자산을 지킨다.
구현 · 아키텍처디자인 패턴
Context–Problem–Solution 구조로 반복되는 설계 문제의 검증된 해법.
패턴의 진짜 정보는 해법이 아니라 그 해법이 유효한 맥락과 함께 따라오는 절충에 있다. 문제가 분명히 확인되기 전에 패턴부터 박아 넣으면 복잡성만 늘어나므로, 패턴은 리팩토링으로 필요가 드러난 뒤 도입하는 편이 안전하다.
구현 · 구현리팩토링
동작은 유지한 채 내부 구조를 개선해 유지보수성을 높이는 작업.
리팩토링과 기능 변경을 한 번의 작업에 섞지 않는 것이 가장 중요한 원칙이다. 동작 보존을 지키는 테스트가 받쳐줄 때만 구조 변경이 안전해지며, 별도 일정으로 미루기보다 그 코드를 어차피 손대는 순간에 조금씩 함께 정비하는 편이 부채를 가장 싸게 통제한다.
구현 · 방법론워터폴
분석→설계→구현→테스트→유지보수가 순차로 흐르는 전통적 개발 모델.
워터폴은 요구사항이 초기에 확정될 수 있을 때 가장 강하고, 변경이 후반에 몰릴수록 가장 약하다. 방법론의 우열을 따지기보다 요건의 안정성과 검수 구조에 맞춰 워터폴·애자일·혼합형을 선택하는 것이 실무의 정석이다.
구현 · 비교워터폴 vs 애자일
순차의 워터폴과 반복의 애자일. 조직 성숙도와 요구 변동성으로 가른다.
워터폴이냐 애자일이냐는 일정표 모양이 아니라 변경을 어느 시점·어떤 절차로 흡수하느냐의 문제다. 순수한 한쪽보다 단계는 순차로 묶고 내부는 반복으로 도는 혼합형이 현실적 기본값이며, 조직 성숙도와 권한 구조가 받쳐주지 않으면 애자일은 통제 잃은 워터폴로 변질된다.
구현 · 아키텍처계층형 아키텍처
표현·업무·데이터 등 책임을 계층으로 분리하는 전통적 구조.
계층형 아키텍처는 그리는 것보다 지키는 것이 어렵다. 표현 계층이 업무 계층을 건너뛰어 데이터에 직접 접근하는 우회 호출 한두 개가 누적되면 계층은 이름만 남으므로, 경계를 코드 차원에서 강제하지 않으면 구조는 빠르게 무너진다.
구현 · 아키텍처MVC 패턴
모델·뷰·컨트롤러로 관심사를 분리하는 대표 아키텍처 패턴.
MVC의 실패는 대개 패턴을 안 써서가 아니라, 컨트롤러나 뷰에 업무 로직이 새어 들어가 분리가 형식만 남을 때 발생한다. 핵심 규칙을 모델에 모으고 컨트롤러를 얇게 유지한다는 경계 합의가 코드 컨벤션으로 강제되어야 패턴이 유지보수성으로 이어진다.
구현 · 아키텍처SOA
재사용 가능한 서비스 단위로 시스템을 구성하는 아키텍처.
SOA의 성패는 통신 기술이나 버스의 선택이 아니라 업무 경계를 어디에 긋느냐에서 갈린다. 서로를 쉴 새 없이 호출해야 하는 서비스로 쪼개면 분리는 했으나 결합은 그대로인 분산 모놀리스가 되므로, 계약을 안정적으로 유지할 수 있는 경계인지부터 검증해야 한다.
구현 · 아키텍처REST API
자원을 URI로 표현하고 HTTP로 다루는 웹 API 설계 원칙.
REST API의 진짜 비용은 만들 때가 아니라 외부에 공개된 뒤 발생한다. 자원·메서드·상태 코드의 일관성과 버전 관리 전략을 초기에 합의해 두지 않으면, 사용하는 측이 늘어난 다음에는 계약을 바꾸기 어려워 기술 부채로 굳는다.
구현 · 아키텍처도메인 주도 설계
도메인 모델을 중심으로 복잡한 업무를 설계하는 접근.
DDD의 성패는 정교한 패턴 적용이 아니라 현업의 언어를 코드에 일치시키는 협업의 지속성에 달려 있다. 패턴부터 전면 도입하면 단순 도메인에서는 과설계로 끝나므로, 규칙이 복잡한 핵심 영역에만 모델링 역량을 집중하는 편이 비용 대비 효과가 크다.
구현 · 구현스프링 프레임워크
의존성 주입·AOP 기반의 자바 표준 엔터프라이즈 프레임워크.
스프링의 의존성 주입은 단순한 편의 기능이 아니라 결합도를 낮춰 변경과 테스트 비용을 줄이는 설계 장치다. 추상화가 두꺼운 만큼 컨테이너 동작과 빈 생명주기를 이해하지 못한 채 관례만 복사하면 장애 추적이 어려워지므로, 표준 설정과 팀 가이드의 정비가 도입 안정성을 결정한다.
구현 · 구현ORM
객체와 관계형 DB를 매핑해 SQL 없이 영속성을 다루는 기술.
ORM은 반복적인 데이터 접근 코드를 없애 생산성을 높이지만, 추상화 뒤에서 실제로 어떤 SQL이 실행되는지 모르면 N+1 같은 문제로 성능이 무너진다. 도구를 신뢰하되 실행 질의와 로딩 전략을 점검할 수 있어야 하며, 통계성·대량 처리 영역에서는 직접 질의를 혼용하는 절충이 정석이다.
구현 · 구현DAO·DTO 패턴
데이터 접근(DAO)과 전송 객체(DTO)로 계층을 분리하는 패턴.
DAO·DTO는 정답이 아니라 변경 비용을 어디에 배치할지에 대한 선택이다. 외부 API 계약과 저장소 접근처럼 변동이 잦은 경계에만 분리를 충실히 적용하고, 변하지 않는 내부 흐름에서는 변환 코드를 줄여야 패턴이 부담이 아닌 자산으로 남는다.
구현 · 아키텍처GoF 디자인 패턴
생성·구조·행위 23개로 정리된 객체지향 설계 패턴의 고전.
GoF 패턴은 외우는 카탈로그가 아니라 변경에 대비하는 어휘다. 실제로 일어날 변화가 무엇인지 먼저 판단하지 않고 패턴부터 적용하면 추상화만 늘고 가독성은 떨어진다. 단순한 문제에는 패턴 없는 단순한 구조가 더 나은 설계인 경우가 많다.
구현 · 방법론DevOps
개발과 운영을 통합해 빌드·배포·운영을 자동화·연속화.
DevOps의 병목은 대개 기술이 아니라 조직 구조와 책임 분배에 있다. 파이프라인을 깔아도 개발과 운영이 목표를 공유하지 않고 장애를 비난의 대상으로 삼으면 변경 속도는 다시 느려진다. 배포 빈도와 복구 시간 같은 지표로 개선을 측정해야 구호에 그치지 않는다.
구현 · 구현CI/CD
통합·테스트·배포를 자동화해 짧은 주기로 안전하게 출시.
파이프라인 자동화의 신뢰도는 테스트의 신뢰도를 넘지 못한다. 불안정한 테스트를 방치한 채 배포 속도만 높이면 빠르게 장애를 운영에 밀어 올리는 장치가 될 뿐이므로, 속도를 늘리기 전에 검증의 결함 탐지력부터 확보해야 한다.
구현 · 인프라컨테이너
애플리케이션을 환경째 격리·패키징해 일관 배포하는 기술.
컨테이너의 실질적 이점은 빠른 기동보다 동일한 산출물을 모든 환경에 흘려보내 환경 차이를 제거하는 데 있다. 한 번 만든 이미지를 다시 빌드하지 않고 그대로 승격하는 원칙을 지킬 때 배포의 재현성과 신뢰가 확보된다.
구현 · 방법론스크럼
스프린트 반복으로 제품을 점진 개발하는 대표 애자일 프레임워크.
스크럼은 회의와 역할을 갖췄다고 작동하지 않는다. 회고에서 합의한 개선이 다음 스프린트에 실제로 반영되고 완료의 정의가 매 주기 지켜질 때 비로소 점진 개발의 효과가 나며, 그 둘이 빠지면 외형만 애자일인 짧은 폭포수가 된다.
구현 · 방법론스프린트
2~4주의 고정 반복 주기. 끝마다 동작하는 증분을 산출.
스프린트의 진짜 가치는 빠른 결과물보다 안정된 속도에 있다. 길이를 고정하고 미완료를 정직하게 넘겨야 팀의 실제 처리량이 드러나며, 그 숫자가 쌓여야 다음 일정을 약속이 아닌 근거로 말할 수 있다.
구현 · 구현테스트 주도 개발
실패 테스트를 먼저 쓰고 통과시키며 설계를 끌어내는 개발 방식.
TDD의 본질은 테스트 커버리지 숫자가 아니라 설계 압력과 변경 안전망에 있다. 테스트를 먼저 쓰면 호출 관점에서 인터페이스가 다듬어지고, 그렇게 쌓인 테스트가 이후 리팩토링의 두려움을 줄여 코드를 오래 살린다.
구현 · 구현형상관리
소스·산출물의 변경 이력을 관리하는 형상관리. Git이 사실상 표준.
형상관리의 실익은 도구 도입 자체가 아니라 변경을 다루는 규율에서 나온다. 의미 단위로 작게 커밋하고, 자주 통합하며, 중요한 분기점마다 베이스라인을 고정해 두어야 이력이 추적 가능한 자산이 되고 CI/CD도 신뢰할 수 있는 출발점을 얻는다.
구현 · 방법론칸반
작업 흐름을 보드로 시각화하고 진행 중 작업(WIP)을 제한하는 방식.
칸반의 실효는 보드를 예쁘게 그리는 데 있지 않고 WIP 한도를 실제로 지키는 데 있다. 한도를 형식만 걸어 두고 새 작업을 계속 끌어오면 보드는 현황판으로 전락하며, 카드가 쌓이는 열을 병목으로 인식하고 그곳부터 개선하는 반복이 흐름을 빠르게 만든다.