사회는 지식을 공유하는 형태로 보관하는 저장소입니다. 종종 더는 쓸모 없는 과거의 유물이 더 나은 단계로 나아가지 못하게 막는 일도 많습니다. 우리가 아직도 청산하지 못한 구태가 어떤 형태로 애플리케이션에 남아 있는지 정리해 보았습니다.

1. 불안의 원인들
애플리케이션 아키텍처 안티 패턴
‑ 박성철 ‑

2. 안녕하세요(‑.‑)

3. 生卽苦
(생 즉 고)

4. 아키텍처

5. 아키텍처
아키텍처 = 비전 + 구조

6. 애플리케이션 아키텍처 구조

10. 학습곡선
발단, 도약, 고원, 해구, 하향

11. 심판관
DRY & OCP
“모든 시스템은 그 시스템이 살아 있는 한 평생
변경이 된다. ”

12. DRY, 중복배제원칙
Donʹt Repeat Yourself
“모든 지식의 단편은 시스템 안에 단일의, 명백
한, 권위있는 표상을 가져야 한다.”
Once and Only Once
Abstraction Principle

13. OCP, 개방폐쇄원칙
Open‑Closed Principal
“소프트웨어의 구성요소(클래스, 모듈, 함수 등)
은 확장은 가능하지만 수정은 불가능해야 한다.”

14. 시스템 아키텍처와 로직
A long time ago in a galaxy far, far away...

15. 다중 계층 아키텍처
오늘날의 전형적인 애플리케이션
아키텍처,
추상화 수준에 따라 애플리케이션
을 여러 그룹으로 분해하여 애플리
케이션의 구조를 체계화
표현 계층
비지니스 계층
데이터 계층

16. 단일 티어
대형/중형 컴퓨터 + 천공카드 or 더미 터미털
중앙 집중 처리

17. 이중 티어
PC, 워크스테이션 + 미니 컴퓨터
클라이언트‑서버 모델
스마트 UI ‑ 안티패턴

18. N‑티어
Post PC & Internet
Application Server

19. 표현 계층 ‑ 비지니스 계층 ‑ 데이터 계층
다중 계층 아키텍처

20. 트랜잭션 스크립트
아키텍처 패턴
애플리케이션 = 트랜잭션의 묶음

21. 안티패턴 #1
연통 배관
(Stovepiping)

22. 연통 배관
애플리케이션의 각 모듈이 독립적으로 개발되어 다른 모듈과
로직이나 데이터를 공유하지도 않고 상호작용하지도 않는다.

23. 자동 연통 대량 생산
연통 배관에서 반복적으로 같은 구조가 나타나면 생산성을
높이고자 소스 코드 자동 생성기를 사용해서 중복된 코드를
대량으로 생산한다.
코드 중복 가속화
구조가 바뀌어야 할 경우 모든 코드를 변경해야 함
추상화로 해결해야 할 문제
수동 연통 대량 생산 (복봍 방법론)

24. 관심사에 따른 계층 설계
관심사 분리 원칙에 따라 계층도 각 계층의 관심사에 따라 설
계

25. 안티패턴 #2
스마트 DAO

26. 스마트 DAO
대부분의 비지니스 로직을 프로그래밍 언어가 아닌 SQL에 담
고 프로그래밍 언어는 이 SQL를 준비하고 실행하고 결과를
받는 작업만 수행하는 데 사용

27. 중복
재사용 할 수 없는 1회용(ad‑hoc) 쿼리 사용으로 로직의 중복
이 발생하고 유지보수성이 떨어짐
SELECT username, secword FROM users WHERE uid=1;
SELECT uid, username, secword, firstname, lastname, regidate, birth, gender, rate
FROM users WHERE UID=1;

28. 로직표현
SQL로 표현되는 비지니스 로직
애플리케이션은 SQL에 매개변수를 전달하고 쿼리 결과를
가공할 뿐
SELECT username, secword
FROM users
WHERE UID=1 AND birday > "20000101" AND gender='F' AND rate > 40
UPDATE users
SET rate = rate + 10
WHERE UID=112 AND gender='F' AND rate > 40 AND status='T';

29. SW의 복잡도를 다루는 기술
Abstraction
Encapsulation
Information Hiding
Modularization
Separation of Concerns
Coupling and Cohesion
Divide‑and‑Conquer

30. SQL 추상화 기술
ORM(Hibernate, JDO, JPA)
Active Record
Query Builder(JooQ, QueryDSL)
Table Data Gateway

31. 무거운 서비스
(Fat Service)

32. 안티패턴 #3
무거운 서비스
뒤범벅 아키텍처
(Jumble Architecture)

33. 뒤범벅 아키텍처
애플리케이션의 횡적인 설계 요소와 종적인 설계 요소가 혼
합되어서 변경에 취약한 아키텍처가 만들어짐
사용자의 기능 요청을 구현하는 종적인 관심
여러 기능에 공통적으로 적용되어야 하는 횡적인 관심
횡적 요소의 모듈화로 재사용성과 안정성 확보 필요

34. 뒤범벅 아키텍처 해법1
파이프 & 필터 패턴
여러 단위 처리 모듈(필터)을 순서대로 나열하고 한 필터에 데
이터를 입력해 얻은 출력을 그 다음 필터의 입력으로 삼도록
구성하는 아키텍처 패턴

35. 해법 1‑1
애플리케이션 계층 추가
추가 계층을 만들어서 횡적 요소와 종적 요소를 조립
애플리케이션 서비스 계층과 비지니스 서비스 계층 분리
횡적 관심사의 모듈화
Pipe & Filter Pattern

36. 해법 1‑2
위임
로직을 비니지스 객체로 분리하고 서비스는 비니지스 객체
로 위임
애플리케이션 서비스 계층 추가와 사실상 동일
아키텍처가 아닌 객체 설계로 해결
Pipe & Filter Pattern

37. 뒤범벅 아키텍처 해법2
관점 지향 프로그래밍(AOP)
기능에 직교적인 횡적 관심사를 분리해 모듈화 수준을 높이
는 기술

38. 안티패턴 #4
무거운 서비스
긴 공개 메서드
(Long Method)

39. 긴 공개 메서드
클래스에 공개 메서드 뿐, 각 메서드의 크기가 너무 길다.
미미한 기능 분화, 낮은 유지 보수성
중복 다량 발생
단일 책임 원칙 위반
기능 분화로 재사용 코드 발견, 추상화의 기회

40. 조합 메서드
public String renderPage(PageData data, boolean isSuite) {
ResultPage result = prepareResultPage(isSuite);
if(isTestPage(data)) {
result.includeSetup(data);
result.includeTeardown(data);
}
return result.getHtml();
}

41. 긴 공개 메서드
프로그래밍 = DSL 개발
(Domain Specific Langage)
ʺ프로그래밍 대가는 시스템을 작성할 프로그램이 아니
라 말하고 싶은 이야기로 생각한다. 그들은 프로그래밍
언어의 장치를 사용해서 더 표현력이 풍성하고 강한 언
어를 만들고 그 언어로 이야기를 말한다.ʺ
‑ 로버트 C 마틴 ‑

42. 긴 공개 메서드
함수 작성법
공개 메서드는 이야기(의도, 작업 흐름) 흐름을 나타내라
비공개 메서드는 이야기의 의미를 정의하라
작게 만들고 한가지만 하라(SRP)
함수내 동일한 추상화 수준 유지
서술적인 이름 사용
명령/조회의 분리
고차 함수를 사용함 함수 수준 추상화(람다식)

43. 안티패턴 #5
무거운 서비스
하는 놈 따로, 아는 놈 따로
(Doer & Knower)

44. 하는 놈 따로, 아는 놈 따로
OOP 언어를 사용하고 클래스를 만들지만 사실은 여전히 구
조적으로 프로그래밍을 하므로 로직과 데이터가 애플리케이
션 전체적으로 분리되어 있다.

45. DB 의존적 애플리케이션
모든 상태를 DB에만 보관
상태 조작은 SQL로 처리
애플리케이션 코드는 단순히 인자와 SQL 결과를 전달

46. 도메인 모델 도입
도메인 모델: 행위와 데이터를 포함하는 비지니스 영역의
객체 모델
객체와 객체의 관계망으로 비지니스 영역을 집합적으로 서
술
복잡한 비지니스 로직을 표현 가능
Active Record 또는 ORM

47. 상태의 영속화
도메인 모델이 도입되면 상태를 메모리에서 관리
데이터의 저장은 메모리상 상태의 영속화 개념으로 바뀜
많은 상태 조작이 메모리에서 수행됨
프로그래밍 언어의 복잡도를 관리하는 기능 활용

48. 빈약한 도메인 모델
(Anemic Domain Model)
단순 데이터 접근 메서드만 있는 도메인 모델
도메인 모델을 도입하는데 드는 비용만 들고 이점을 하나
도 못 누림
모든 로직은 서비스에 몰려 있음, 트랜잭션 스크립트

49. 무법천지
비지니스 규칙이 체계적으로 관리되지 않고 비지니스 로직
곳곳에 중복 분산
도메인 모델 객체 활용
Specification 모델링 패턴
BRE(비지니스 룰 엔진) 사용
if(user.age() > AGE_ADULT && user.isMale() && user.getLoyalty() > LOYALTY_VIP) {
giveGift(user);
}

50. 안티패턴 #6
무거운 서비스
단일 객체 서비스
(Single Class Service)

51. 단일 객체 서비스
서비스가 객체 하나로 구성되어 있고 적절하게 분화하지 않
음

52. 서비스 객체의 용도
경계 객체
컨트롤러
파싸드(Facade)

53. 낮은 응집도 높은 결합
코드의 중복이 많고 추상화 수준이 낮아서 코드를 수정함으
로서 발생하는 영향을 예측하기 어렵고 단일 요구사항으로
인한 변경 지점이 흩어져 있다.

54. 클래스 추가 공포증
클래스를 추가하면 클래스 설계가 복잡해진다는 믿음
OOD에 대한 경험 부족
영어...
지나치게 엄격한 아키텍처

55.
높은 응집도 낮은 결합
지역적 변경(SRP)
중복 최소화(DRY)
로직과 데이터 근거리 보관
변경 주기에 따른 응집
메시지 = 인터페이스

56. 빈약한 추상화
추상화: SW의 복잡도를 다루는 기술(OOP, FP, 메타 프로그래밍)
인터페이스(완전 추상 클래스) 없는 컴포넌트 경계(정적 바
인딩)
일반화와 특화의 구분 부재
과도한 중복으로 견고성, 신뢰성, 재사용성, 가독성에 문제
발생
서비스 객체는 비니지스 계층의 경계 객체 또는 Facade
비지니스 계층은 넓은 영역

57. 잘못된 의존 관계

58. 정적 바인딩
전역 변수
하드 코딩
싱글턴 남용
인터페이스 미사용

59. 무거운 서비스 정리
AOP를 사용해서 종적 관심사와 횡적 관심사 분리
조합 메서드를 활용하고 DSL을 개발하라
도메인 모델을 도입하라
큰 서비스를 작은 클래스로 분해하고 위임하라
높은 응집도와 낮은 결합도를 갖도록 설계하라

60. 기타

61. 과잉 일반화(Over Generalizing)
Object, 문자열, Map 같이 지나치게 일반적인 타입의 과용

62. 하나님 객체(God Object)
과도한 재사용 시도
Super~
여러 기능에 공통적으로 적용되어야 하는 횡적인 관심
가독성과 변경이 자주 일어나며 (횡적 요소의) 재사용성과
신뢰성이 떨어짐
황금 망치 증후군

63. 편의 객체 상속
편의 객체를 상속함으로써 소중한 상속의 기회를 낭비
기반 클래스가 하나님 객체가 될 위험이 큼
위임으로 해결 가능

64. 과잉 최신 기술 준수
(Over Buzzword Compliance)
온갖 최신 기술로 도배된 아키텍처
검증되지 않은 위험한 기술
교육비용 발생
고객의 잘못된 요구를 무비판적으로 수용
프로젝트 수행 여력이 부족해짐

65. 클라우드

66. 클라우드 적합성
매우 기민하고 가용성이 높은 서비스를 단명하고 망가질 것
으로 예상되는 컴포넌트로 구축

67. 클라우드 특성
전통적 인프라 클라우드
n‑tier SOA, MSA
수직확장성 수평확장성
장애 예방 장애 예상
트랜잭션내 정합성 결과적 정합성
경직성 기민/유연성
수동 운영 자동 운영
낮은 신뢰성 자가 복구
점검 운영 중단 무중단

68. 클라우드 성숙도

69. 결론
연통 배관
스마트 DAO
뒤범벅 아키텍처
긴 공개 메서드
하는 놈 따로, 아는 놈 따로
단일 객체 서비스
과잉 일반화
하나님 객체
편의 객체 상속
과잉 최신 기술 준수