디자인패턴 쓴 자바"의 맛 (반 패턴으로 프로그래밍을 향상시키는 방법)

반 패턴으로 프로그래밍을 향상시키는 방법

문서 옵션 이 페이지를 이메일로 보내기

난이도 : 초급

Bruce A. TateJ2Life, LLC

2002 년 3 월 01 일
2003 년 1 월 14 일 수정

전문 기술 잡지등에서 다루어지는 양에서도 알 수 있듯이 설계 패턴은 소프트웨어 개발에서 중요하다. 그러나 설계 패턴은 개발 프로세스에서 유용하지만 그 퍼즐의 반쪽만을 해결한다. "명확하게 부정적인 결과를 가져오는 문제에 대해 일반적으로 등장하는 솔루션'으로 설명되는 반패턴 (Antipattern)은 자바 프로그래머들에게 일반적인 자바의 함점을 피할수 있는 방법을 보여줌으로서 나머지 반쪽을 해결하고자 한다. 이 글에서 반 패턴 전문가이자 "Bitter Java"의 저명한 저자인 Bruce Tate는 왜 반패턴이 설계 패턴에 필요하고 그것과 보완적인 짝이 되는지, 그리고 어떻게 작동하는지를 보여준다. 그는 반패턴의 구체적인 예들(Round-Tripping 반패턴과 Magic Servlet 반패턴)을 제공하며, 여러분의 프로그램과 개발 프로세스를 향상시키기 위해 지식을 어떻게 적용하는지를 설명한다.

동부 테네시의 어느 추운 날 내 카약은 "State Line 폭포"라는 6 피트 높이의 폭포 위에 불안정하게 놓여 있었다. 이만한 속도는 보트와 사람을 박살내는 위험성으로 악명이 높다. 꼭대기에서는 강의 굴곡부에 숨어 있는 위험에 대한 아무런 단서도 없었지만 나는 알고 있었다. 안내책자의 설명이 며칠 동안 깨어 있는 내내 내 머리 속에 있었다. 5개 트럭 크기의 큰 돌이 네 개의 수로를 지키고 있다. 내가 전체 폭포를 보게되는 건 그것을 건너기 불과 몇 초전이 될 것이다. 네 개의 수로중 3개가 억척스런 여러분의 계모에게조차 너무도 폭력적이고 위험한 것으로 알려져 있다. 강물이 네번?의 "우호적인" 수로를 거세게 빠져나가며 속도를 높이고 이어 뾰족한 바위위로 부딛친다. 나는 직업 프로그래머이며, 두 아이의 아버지이고, 중급 정도의 기술을 가진 카약인이다. 나는 안내책자에 따르면 V 등급인 이 폭포를 지나가야 할 '최소한의' 용무도 없다. 도대체 나는 여기서 무엇을 하고 있단 말인가 ?

내 안의 프로그래머는 수도 없이 같은 질문을 되뇌인다. 늘어가는 스케쥴의 압력과 실패시의 끔찍한 결과의 중압감에 처해 있는 상황에서 생소한 문제를 공격할 준비를 할 때, 위에서 말한 것과 같은 절벽 꼭대기에 난 서 있다. 이 글에서 나는 프로그래머의 반란인 '반패턴'을 여러분이 항해할 수 있도록 도와줄 도구에 대해 설명할 것이다. 또한 반패턴이 여러분의 설계 패턴 연구를 도와줄 수 있도록 하는 몇 가지 방법을 지적할 것이다. DeveloperWorks에 자주 들르는 사람이라면, 여러분은 소개된 여러 설계 패턴들을 보아왔을 것이며 그 가치에 대한 논쟁들을 목격했을 것이다. 하지만 Eric Allen의 버그 패턴에 관한 글들(참고 자료)이 이들을 활용하는 힌트를 제공했겠지만, 여러분은 아마 반패턴에 대해서 동일한 평가를 하고 있지는 않을 것이다. 여러분 뿐만이 아니다. 개발자들은 여러 해동안 설계 패턴에 대한 통찰력있는 책들과 글들을 발표해 왔으나, 분명히 반패턴에 대해서는 그리 적극적이지 못했다. 이 글에서의 나의 목표는 여러분에게 반패턴이 설계 패턴에 꼭 필요하며 보완적인 짝이라는 것을 보여주는 것이다.

설계 패턴으로 성공적인 전략 반복하기

State Line 폭포위에서 흐르는 강물을 내려다보고 있을 때 나는 내가 알고 있는 것을 재고해 보았다. 다른 사람들과의 대화에서 나는 성공적으로 내려가려면 세번째 수로의 오른쪽으로 가야 하고 폭포 밑 얕은 물 아래의 바위들을 피하기 위해서는 속도를 내어 나아가야 한다는 것을 알고 있었다. 나의 확신을 견고하게 하는 이 지식으로 나는 소용돌이의 보호된 안전 지대를 떠나 강물의 주 흐름으로 들어갔다.

당시 내가 염두에 둔 건 아니지만, 나는 설계 패턴을 사용하고 있었다. 난 내 전략을 나보다 앞서 항해를 한 사람들이 성공적으로 강물을 탄 방법에 기반을 두었다. 설계 패턴은 그렇지 않았다면 내 기량을 넘어섰을 속도로 항해할 확신을 심어주었다. 난 종종 같은 원칙을 프로그래밍과 아키텍처에 적용하곤 한다; 여러분은 주어진 문제를 해결하기 위해 한 전략이 계속 성공적인 결과를 가져오는 것을 보고 배울 수 있다. 설계 패턴으로 그 결과들은 긍적적이다. 여러분은 여러분 자신의 경험을 두드려 보거나, 조언자를 만나거나 혹은 전문가들이 수행한 것을 읽을 수 있다.

우리의 프로그래밍 기술의 대부분의 중요한 발전은 설계 패턴에서 나왔다. Model-View-Controller 패턴은 우리에게 사용자 인터페이스와 모델사이에 잘 정의된 경계선을 따라 코드를 효과적으로 분할하도록 해 주었다. Publish-Subscribe 설계 패턴은 이벤트들을 동시에 뿌리지 않고도 관리하는 법을 가르켜주었다. 다른 설계 패턴들은 다양한 자바 프레임워크에 지대한 영향을 미쳤다: 원격 통신을 위한 프록시 EJB 인터페이스, collection 클래스, Swing 프레임워크, 그리고 기타 많은 것들이 이에 해당된다.

나는 반복적인 프로세스를 만들어가는 것에 열광적인 팬이다. 이러한 관점에서 설계 패턴은 많은 것을 제공한다. 설계 패턴은 여러분의 문제를 작은 별개의 문제들로 나누는 것을 고려하도록 하는데, 이 중 몇몇은 반복되는 솔루션을 응용할 수도 있다. 설계 패턴은 또한 여러분의 설계 지식을 공식적으로 표현하고 전달하는 방법에대해 생각하도록 하여, 다른 사람들도 여러분의 작업을 활용할 수 있도록 한다.

그러나 디자인 패턴만으로 충분한 것은 아니다. 프로그래밍 문제를 건너가야 하는 지형으로 볼 때 설계 패턴은 기껏해야 부분적인 지도에 해당될 뿐이다. 결국 여러분의 필요에 맞는 완벽한 솔루션이 존재한다면 여러분은 아마도 개발하기보다는 구매할 것이다. 나아가 지원 소프트웨어가 발전함에 따라 인프라가 빨리 변한다. 부분 지도는 몇 몇 위험을 피하도록 할 수는 있지만 전부를 피하게 할 수는 없다. 여러분은 여러분의 목적지에 이르기 위해 지도에 모험을 걸어야 할 것이다. 그런데 길을 잃으면 어떻게 할 것인가 ?

위로

반패턴으로 고통스런 함정 피하기

내가 항해를 하고 있을 때, 물살은 나를 왼쪽으로 밀어넣고 있었다. 카약인들은 빠른 흐름속에서 위험한 지점을 본능적으로 알아 차려야 하고, 난 내 숙제를 완수했다. 난 내 앞의 몇 몇 항해자가 왼쪽으로 흘러가 박살이 난 것을 알고 있었으며, 이 문제를 해결하는 방법에 대해 토의하고 마음 속으로 연습하였다. 준비를 하였으므로 나는 나를 일직선으로 뒤쪽으로 보내는 강하게 내리치는 공격적인 방법을 구사했다. 난 이제 무사히 통과하도록 싸울 기회를 얻게 되었다.

여기에서 이것을 어떻게 반패턴으로 보는지에 대해 설명한다: 나는 어려운 문제를 가지고 시작하였다. 나는 다른 성공적인 솔루션들에 기초하여 계획을 선택했다: 즉 설계 패턴을 사용하였다. 나의 계획은 잘못되었지만 급류속에서 다른 어려운 항해들을 분석함으로써 대응하고자 준비했다: 즉 반패턴을 사용하였다. 내가 준비하였기 때문에 나는 문제를 인식하고 제대로 된 흐름으로 돌아가기 위해 내 방식을 조정하였다: 즉 나는 갱신한 것이다. 고급 카약 타기과 프로그래밍에 있어 여러분 자신의 실수를 통해 배우는 것도 가치있지만 뼈아픈 일이다. 나는 다른 사람들의 실수로부터 배우겠다. 이러한 방식으로 나는 제대로라면 내 기량을 앞서는 문제들을 공격할 수 있는 것이다.

"반패턴 : 소프트웨어, 아키텍처 및 위기의 프로젝트를 갱신하다 (참고자료)"의 저자는 반패턴을 다음과 같이 정의한다.

반패턴은 명확하게 부정적인 결과를 가져오는 문제에 대해 일반적으로 등장하는 솔루션을 설명하는 것으로, 저술 형태로 되어 있다.

여기서 핵심 구문은 :

• 저술 형태: 반패턴은 문제를 기술한 것이지 코드가 아니다. 이것은 메시지를 빠르고 효과적으로 전달할 수 있고 고객이 빨리 이해할 수 있기 때문에 중요하다.
• 일반적으로 등장하는 : 패턴이 아니라면 반패턴도 아니다. 여러분은 반패턴의 수준으로 발생하는 버그에 대해 잘못 수행되는 몇가지 다른 예를 확립해야 하며, 이 때 다른 문맥으로 하는 것이 좋다.
• 부정적 결과: 설계는 주목할만한 부정적인 영향을 가지고 있어야 한다.

가장 유명한 반패턴은 우리에게 공포와 흥미로운 새 영역에 대한 약속을 보여준 Y2K이다. 수 십만의 개발자들이 4자리 대신 2자리로 날짜를 코딩하고 수 백만의 버그를 야기하는 이 자릿수를 틀리게 비교했던 것을 회고해보라. 많은 저명한 연구자들이 재앙의 확산을 예고했으나, 문제에 대한 집중적인 연구를 통해 새로운 검증과 갱신 기술들로 코드를 효과적으로 수정했기 때문에 예상된 규모로 문제를 경험한 곳은 거의 없었다. 반패턴은 설계 패턴과 마찬가지로 반복적인 솔루션이다. 차이는 부정적인 결과들을 가지고 있다는데 있다. 반패턴을 문서화할때, 여러분은 최소한 다음의 요소들을 확보하기를 바랄 것이다.

• 이름: 때때로 반패턴은 개발 단체가 명명한 하나 혹은 여러개의 비공식적인 이름을 이미 가지고 있을 것이다. 여러분은 하나를 선택할 수 있다. 의미를 잘 설명하고 있고 간단한 것이 좋다.
• 문제점: 문제점은 반패턴의 결함있는 솔루션과 개발자들을 결함있는 솔루션으로 이끄는 동기화 요소들을 설명한다. 이 설명은 다른 사람들에게 문제를 어떻게 발견하는지를 가르쳐준다.
• 갱신된 솔루션: 반패턴은 우리가 함정에서 빠져나가도록 혹은 완전히 피하도록 도와줄 정도로 유용하다. 갱신된 해결책은 다른 사람들이 문제를 어떻게 고쳤는지를 알려주는 길잡이가 된다.

위로

다른 업계도 반패턴을 성공적으로 사용

다른 많은 업계 --특히 제조업 --에서도 보통 설계 패턴과 조합하여 일정 형태의 반패턴을 사용한다. 현재의 제조업체들은 다른 업체의 성공적인 공정 개선을 모방한다. Just-In-Time "설계 패턴"의 예를 들어보자. Just-In-Time 제조 방식은 재고를 줄여주는 공정이고 품질 문제를 신속하게 수정하여 품질을 향상시킨다. 한 공정에서 연속되는 각각의 단계는 전 단계로부터 적시에 전달되는 부품들을 사용한다. 현재 모든 주요 자동차 제조업체는 이 기법을 사용하고 있다. 제조업체들은 또한 부품 조립과 테스트 및 데이터 수집을 위해 여타의 다른 설계 패턴들도 적용한다. 최고의 제조업체들은 여기에서 멈추지 않는다. 그들은 또한 체계적인 공정상의 결함을 발견해야 하는 필요성을 인식하고 있다. Zero Defects와 Quality Cycle과 같은 프로그램들은 공장 노동자들이 정기적으로 체계적인 공정상의 문제에 대해, 그리고 이들을 어떻게 방지하는 것이 최선인지에 대해 토의하는 시간을 갖도록 하고있다. 평균적인 프로그램은 종업원들에게 유지보수에 필요한 시간보다 훨씬 많은 시간을 ?축시켜 주고 있다. 업계에서 사용되는 반패턴의 예에는 다음과 같은 것이 있다.

• 의료 산업 : 연구자들이 나쁜 식습관에 대해 발견하고 발표하며, 훌륭한 의사들은 증상 뿐 아니라 환자의 건강 문제의 근본 원인을 고치기 위해 그 정보를 이용한다.
• 법 집행 조직 : 경관들이 문제 지역 내 범죄의 근원을 찾아내고 방지하기 위해 여러 단체들과 협력한다. 이 프로그램들은 마약과 폭력 범죄를 현저히 줄일 수 있다.
• 출판 업계 : 가장 성공적인 출판업체들은 십여년의 무시후에 작가와 다시 한번 가까운 협력관계를 가지고 일한다. 이 협력 관계는 저자들로 하여금 나쁜 저술 습관을 찾아내고 고쳐서 더 좋은 책들을 만들어내도록 도와준다. 가장 성공적인 전문 출판업체가 이 방식을 사용하였고, 다른 업체들도 이를 모방하기 시작하고 있다.

위로

자바 언어에서의 반패턴의 예들

다른 업계에서 반패턴이 성공적이라면, 프로그래머들도 반패턴으로푸터 혜택을 얻을 수 있지 않을까 ? 나는 프로그래머들이 얻을 게 더 많다고 믿는다. 프로그래머로 성공하려면 여러분은 단순히 흔한 함정을 신속하게 알아채기만 하면 된다. 소프트웨어 개발은 터무니없이 다양한 세트의 도구, 언어, 기법 및 전략을 이용한다. 우리의 지도 비유로 돌아가 생각해 보자. 문제점들은 한 상황과 그 다음 상황에서 약간씩 달라진다. 여러분이 성공하기 위해서는 지식을 일반화하고 이를 환경에 맞추어 변환할 수 있어야 할 것이다. 설계 패턴이 매우 특수한 문제 영역을 타겟으로 하는 반면에 반패턴은 보다 일반적일 수 있다. 사실 여러분이 저지를 수 있는 많은 실수들은 이전에 행했졌던 것들이다. 반패턴은 여러분이 개발 단계의 보다 초기에서 이들의 더 많이 알 수 있도록 도와 준다. 만일 여러분이 대부분의 프로그래머들과 유사하다면, 현재의 상황에서 함정들을 이해하기 위한 약간의 시간을 할애하는 것으로 엄청난 양의 시간과 노력을 줄일 수 있다. 자바 언어의 진화는 다른 프로그래밍 세대들로부터 빌려온 수많은 실수의 예를 우리에게 보여준다.

• EJB 엔터티 빈의 초기 구현은 지독히 느렸는데, 통신 비용이 높은 것도 한 이유였다. 시간이 흐른 뒤 사람들은 중요한 문제가 왕복 통신(round-tripping)에 있었음을 알게 되었다. 우리는 결국 facades와 같은 해결책으로 이러한 문제를 풀어가는 방법을 알게 되었다 (상세 사항은 보조 자료 Round-Tripping 반패턴 참조). 다른 개발자들은 EJB 컴포넌트가 존재하기 훨씬 이전에 이 지뢰를 거쳤었다. 개인용 컴퓨터의 초기 데이터베이스들은 관리자들이 많은 데이터베이스 통신을 하나로 통합시키기 위해 저장 프로시져를 사용하는 방법을 배울 때까지 성능 문제로 골머리를 앓았다. 초기의 분산 시스템 개발자들도 같은 문제를 발견했으며, Facade 솔루션을 공개하였다.
• 일반적인 자바 반패턴의 또 다른 예는 Magic Servlet이다. 이것은 매우 기본적인 반패턴으로 비교적 진보적인 내 고객들을 함정에 빠뜨렸다. 자세한 것은 보조 자료 Magic Servlet 반패턴에 설명되어 있다. Magic Servlet에서는 하나의 서블릿 프로세스가 View, Model, 그리고 Controller 로직을 처리한다.그러한 설계는 유지보수를 거의 불가능하게 만들어 버리는데, View가 바뀔 때마다 Model 로직을 바꾸어야 하며 그 역의 경우도 마찬가지이기 때문이다. Magic Servlet은 또한 자바 언어를 앞서는 근원을 가지고 있다. 이 문제의 가장 보편적인 예가 실제로 Visual Basic에서 일어나는데, Visual Basic에서 프로그래머는 흔히 pushbutton과 같은 하나의 컨트롤에 10k 크기의 스크립트를 붙여넣곤 한다.

이러한 문제들은 빙산의 일각에 불과하다. 새로운 영역에서 자바 개발자들은 일정한 규칙을 가지고 기존의 실수들을 재발견한다. 만일 우리가 피하기 위한 의도로 함정을 연구한다면 분명히 고통을 줄일 수 있다.

위로

반패턴 프로세스 사용하기

반패턴이 주의를 기울일만한 가치가 있음을 여러분에게 확신시켜 주었기를 바란다. 어떻게 하면 여러분이 매일 수행하는 작업 속에 이들을 통합시킬 수 있을 것인가 ? 그림 1은 반패턴을 확인하고 해결할 수 있도록 도와주는 한 프로세스의 간략한 단계를 보여준다. Bitter Java (참고자료) 에서 이를 보다 자세히 설명하였다.

1. 문제 확인 자바 프고그래밍에서는 문제가 버그가 될 수도 있고 혹은 성능상의 문제, 유지보수가 어려운 클래스, 또는 메모리 요구량 증대등이 될 수도 있다.
2. 패턴 확립소프트웨어 엔지니어링을 공부하는 학생이라면 버그를 고치는데 드는 비용이 개발 단계가 진행될 수록 더 많이 증가한다는 것을 알고 있을 것이다. 문제의 패턴을 확립할 때 개발 단계의 보다 초기에 더 많은 문제를 확인하고 수정한다면 여러분의 이익이 증대될 것이다. 이 가치 체인을 상승시키는 핵심은 패턴을 확립하고 가능한한 광범위하게 반 패턴에 대해 작업하는 것이다.
3. 코드 갱신 이 단계에서 여러분은 문제를 야기시키는 코드를 수정한다. 이 단계는 간단하게 버그를 수정하는 것으로서, 여러분이 지금까지 확인했던 모든 문제들에 대해 적용된다. 신속한 패치를 사용하는 것보다는 완전하게 수정해야 하며, 같은 곳에 버그가 나타날 법하면 문서화를 해두어야 한다. 또한 솔루션을 다른 사람에게 배포하기 위해 여러분이 밟은 단계들을 문서화하고자 할 수도 있을 것이다.
4. 솔루션 전파 여기에서 여러분은 버그를 만난 다른 사람이 이를 고치는 방법을 알고 함정을 만난 사람들이 이를 피하는 방법을 알도록 해야 한다. 반패턴을 공개하는 것은 혜택을 보다 넓게 확산시킬 수 있다.
5. 프로세스 확립 여기에서 여러분은 반 패턴에 대해 보호 장벽을 구축한다. 프로세스를 확립 시키는 것은 여러 많은 형태를 취할 수 있다. 테스트 케이스를 향샹시키면 회귀를 신속하게 확인할 수 있따. 매일 수행되는 프로세스나 통신 채널을 확립시키면 문제가 발생되기 전에 이를 방지할 수있다. 코딩 표준을 확충하면 중괄호나 코멘트의 위치와 관련된 버그 같은 일정 유형의 코딩 에러를 거의 없앨 수 있다.

이 단계들은 특수한 것에서부터 일반적인 것으로 가는 방식을 취한다. 여러분은 버그를 발견하고 패턴을 확립하고 버그를 수정하고 프로세스를 확립한다. 이 단계들 중 일부를 여러분의 매일의 작업에 포함시키면 여러분은 보다 훌륭한 프로그래머가 될 수 있다. 그러나 여기에서 멈추지 말라. 반 패턴에 대한 여러분의 지식을 프로세스를 확립하고 회사내의 프로그래머들을 향상시키는데 사용하여 가치 체인을 높여라. 여러분의 반 퍄턴을 공개하여 여러분이 모르는 프로그래머들에게도 도움이 되게 하라. 여러분이 프로그래머이고 설계 패턴의 팬이라면 여러분은 반 패턴이 많은 것을 제공한다는 점을 발견하리라고 확신한다.

나의 나머지 항해는 용두사미격이었다. 나는 휩쓸리고 마음대로 떨어지고 거품 속에서 여자애같은 남자처럼 뛰어내렸다. 그리고 아래에서 기다리고 있던 안전한 차량에 닿을 ?가지 도저히 바보같은 웃음음 멈출 수 없이 아니 멈출 생각도 하지 않고 나머지 시간을 노를 저었다.

위로

참고자료

• developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
  
  
• Bitter Java (웹 사이트)
  
  
  
  
• Bitter Java (책)
  
  
• Session Facades의 규칙 및 패턴
  
  
• WebSphere에서 서블릿, EJB 및 JSP 설계 및 구현하기
  
  
• "Struts, 오픈 소스의 MVC 구현".
  
  
• 반패턴: 소프트웨어, 아키텍처 및 위기의 프로젝트를 갱신하다 W.J. Brown, Malveau, W.H. Brown, McCormick과 Mowbray (John Wiley & Sons, 1998), 반 패턴 논의를 출발시킨 책. 반 패턴을 포착하는데 사용할 수 있는 템플릿들에 대한 훌륭한 정보가 들어 있다.
  
  
• Diagnosing Java Code , Eric Allen, developerWorks, 반 패턴의 원리를 보다 하위 수준의 버그 패턴의 형태로 설명
  
  
• IBM Patterns for e-business: 사용중인 설계 패턴들이 나와있다.
  
  
• developerWorks Java zone: 자바 관련 글 모음.
  

위로

필자소개

	Bruce Tate는 독립 컨설턴트 겸 작가이다. IBM에서 12년간 일하면서 자바 개념 입증팀을 이끄는등 다양한 업무를 수애하였다. Bruce는 Austin 출범을 위한 솔루션 개발 조직을 운영하기 위해 IBM에 채용되었으나 자신의 사업체인 J2Life, LLC를 만들기 위해 그만두었다. 자바 반패턴에 관한 책인 Bitter Java 의 저자이다.