조사 결과에 관심이 가는 이유는 선호하는 제품과 꺼리는 제품 사이의 큰 차이다.



그래프가 아니라 수치로 보면 또 다른 느낌이 든다.

Tool	Best	OK	Problematic	Dangerous	No Opinion	Active Responses	Approval %
Subversion	20	72	6	1	0	99	93%
git	65	19	1	0	14	85	99%
Mercurial	33	27	2	0	36	62	97%
ClearCase	0	3	14	41	41	58	5%
TFS	0	0	32	22	44	54	0%
CVS	0	14	59	11	15	84	17%
Bazaar	1	13	3	0	80	17	82%
Perforce	1	26	16	1	54	44	61%
VSS	1	1	11	64	22	77	3%

이 수치를 보면 몇 가지 화두를 꺼낼 수 있다. 상투적이지만 오픈소스의 위력을 떠올려볼 수도 있다. 하지만, 거의 꼴찌에 놓인 ClearCase에 관심이 간다. 국내 현장에서 널리 쓰이는 상용 제품이기에 그렇다. ClearCase를 쓰는 고객과 무슨 이야기를 할 수 있을까 생각해봤지만, 안타깝게도 공감대가 형성되기 어려울 듯하다. 고객이 소스 코드 버전 관리에 대해 실제적인 경험이 적어 이해하는 부분이 적다고 치부할 수도 있지만, 반대로 아직 내가 버전 관리 도구(와 프로세스)의 개선이 줄 수 있는 파급력을 설명할 능력이 없다고 하는 편이 좋겠다.

물론, 개발자 메일링 조사이니 공신력에 의문을 품을 수도 있고, 외국 현실(I conducted the survey from February 23 2010 until March 3 2010 on the ThoughtWorks software development mailing list)이니 국내 현실과 차이는 있다.

출처: VcsSurvey

학부 때 소프트웨어 공학 과목 시험에서 Scalability에 대해 논하라는 문제가 나왔다. '확장성'으로 풀어야 하나 '규모 신장성'으로 풀어야 하나 고민했던 기억이 난다. 결국, 답으로 무얼 적었는지는 모르겠다.

지금 생각해보면 결국 투자 대비 수익(Return on Investment)이라 정리할 수 있다. 하드웨어든 가상화나 그리드 솔루션이든 돈을 들이는 만큼 더 많은 고객을 포용할 수 있어야 한다. 그러나 소프트웨어 산업 초창기인 터라 실제 구현해내는 일은 그리 만만치가 않다. InfoQ 등을 보면 선형적 규모 가변성(Linear Scalability)을 이야기하지만, 국내 현장에선 남의 나라 이야기다. 민감한 시스템 구축 프로젝트에서 이를 언급했다가는 5년 전 일이 데자뷔로 다가오지 않을까. 2005년 대규모 프로젝트에서 스프링(Spring Framework) 도입할 때, '멋 모르는 신출내기' 취급을 받았던 때가 떠오를 듯하다.

바쁜 와중에 갑자기 Scalability에 대해 이야기하는 이유는 얼마 전 스프링로드가 자랑스레 트윗했던 뉴스를 읽었기 때문이다. 영국 최대의 언론사에서 하드웨어 추가에 따른 웹 로직 도입 비용에 부담을 느껴 오픈소스로 눈을 돌린 모양이다. 그러다가 긴급 지원이 가능한 tc 서버로 눈을 돌렸고, 스프링로드의 레퍼런스가 만들어졌다. 구글이 형광등처럼 하드디스크를 소모품으로 여기듯이 하드웨어는 단순 소모품으로 전락할 가능성이 크다. U(Ubi~)라는 키워드가 곳곳에서 쓰이는 현실을 고려하면 점점 하드웨어를 묶어 사용하는 가상화 환경은 기본으로 자리 잡을 가능성이 크다. 이미 포탈에서는 관계형 데이터베이스의 한계를 이야기하고 있고, 서비스를 수행하는 기업은 하드웨어 가용성에 대한 고민을 위탁할 가능성이 매우 크다.

결국은 클라우드가 순식간에 피부에 와 닿을 날이 떡국 몇 그릇 먹기 전에 올 듯하다. 최근에 IDC를 완공한 SI 업체가 측은하게 느껴지는 것은 지나친 걱정일까?

  * 기업 경영에 대한 필자의 조언

k16wire님 추천에 의해 읽은 책이다. 인상에 남는 구절을 짧은 감상과 함께 메모.

좋아하는 오렌지색을 넣은 편집도 그렇지만, 시종일관 신선한 내용과 흥미로운 전개가 돋보이는 책이다. 300쪽을 넘어가 슬슬 지루할 즈음에 이어지는 마지막은 정말이지 임팩트 있는 만점 마무리다.


읽으면서 온통 밑줄을 그었고, 곁에 두고 가끔 참고해야 할만한 책이란 생각이 드는 책이다. ^[각주:1]


 

창조적 괴짜가 세상을 움직인다 - 요나스 리더스트럴러.첼 노오스트롬 지음, 조성숙 옮김/황금가지

가능성이 높다 → 가능성이 크다
(의지를) 가지고 → (의지를) 갖추고
감싸인 → 둘러싸인
★ 감안해 → 고려해, 참작해, 살펴, 생각해
★ 갖고 있는 → 가진
(~을/를) 갖고 있지만 → (~가) 있지만
갖아보면 → 가져 보면
갖지 → 느끼지
검색을 할 → 검색할
결국 → 결국,
고민을 했다 → 고민했다
관심을 갖는 → 관심을 두는
구비한 → 갖춘
★★★★★ 그러나, → 그러나
★★★★★ 그리고, → 그리고
근자에는 → 요즘에는
금새 → 금세
(능력이) 급성장하다 → 급향상하다
기반한 → 기반을 둔
기여할 → 이바지할
꺼림직한 → 꺼림칙한
꺽인다 → 꺾인다
꽤나 → 꽤
나눠지고 → 나뉘고
나올라나 → 나오려나
★ 난데 없이 → 난데없이
난이도도 높고 → 어렵고
남탓에 → 남 탓에
내역 → 내용
너무 좋아서 → 아주/매우 좋아서
노하우 → 비결, 비법
누구말대로 → 누구 말대로
다달을수록 → 다다를수록
단초 → 실마리
담고 있는 → 담은
대개의 경우 → 대개
대기한다 → 기다린다
대부분의 (작업을) → (작업) 대부분을
더 이상 → 다시는, 더는
데드락 → 교착상태
데자뷰 → 데자뷔
도식화 한다 → 도식화한다
도처에서 → 곳곳에서
되더라구요 → 되더라고요
동일하게 → 같이
뒤 이어는 → 뒤이어는
뒷풀이 → 뒤풀이
들여다 보면 → 들여다보면
띄며 → 띠며
맞냐 → 맞느냐
머지 않아 → 머지않아
몇 일 → 며칠
모양을 띈다 → 모양을 띤다
못지 않게 → 못지않게
무리배 → 무뢰배
무엇이었냐 → 무엇이었느냐
바꾼 후 → 바꾸고, 빼앗긴 후 → 빼앗기고
반감을 가진 → 반감을 품은
박발을 하다 → 반박하다
방치했다 → 버려뒀다
별 생각 → 별생각
병기하기 → 함께 적기
보내다보니 → 보내다 보니
보여질 → 보일
부르짓던 → 부르짖던
부합하는 → 맞는
★ 분명 → 분명히
불러지는 → 불리는
블로그스피어 → 블로고스피어
빽빽히 → 빽빽이
뿐만 아니라 → 그뿐만 아니라
사랑스런 → 사랑스러운
사용할 수 있는 방법은 → 사용하는 방법은
새 집으로 → 새집으로
수 밖에 → 수밖에
쉽상인 → 십상인
스스로도 → 자신도
아니기 때문에 → 아니므로
악세사리 → 악세서리
안좋은 → 안 좋은
않는가 → 않은가
얼마전 → 얼마 전
얼핏보면 → 언뜻 보면
옥의 티 → 옥에 티
와닿는다 → 와 닿는다
왠만한 → 웬만한
★ ~의 경우 → ~는
의례 → 으레
의지 박약 → 의지박약
이런 저런 → 이런저런
이로 인해 → 이 때문에, 이로 말미암아, 이 탓에, 이 덕분에
이를 테면 → 이를테면
이야기 하고 → 이야기하고
이와 같이 → 이처럼
있냐 → 있느냐
익숙치 → 익숙지
~인 반면 → ~이지만
일괄로 → 한꺼번에
일체 없다 → 일절 없다
입각해서 → 따라서
제3자 → 제삼자
족하다 → 충분하다
주눅들어하는 → 주눅이 들어하는
주제 넘게 → 주제넘게
중생으로써 → 중생으로서
중에 하나 → 중의 하나
증가 뿐 → 증가뿐
지나고 있는 → 지나는
지는거다 → 지는거다
지불한 → 지급한, 낸
지져분하게 → 지저분하게
짐작컨대 → 짐작건대
짖굳게도 → 짓궂게도
짜투리 → 자투리
짧막하게 → 짤막하게
쪽팔리게시리 → 쪽팔리게끔
차용한 → 빌린
촉진시켜 → 촉진해
최선을 다하지 → 온 힘을 다하지/기울이지
추스리고 → 추스르고
컨퍼런스 → 콘퍼런스
컬럼 → 칼럼
큰 경우에 → 크면
타고 나는 → 타고나는
트랜젝션 → 트랜잭션
폄하하여 →  깎아내려
프록시 → 프락시 (외래어 표기법 at NARAINFOTECH 2009.06.11(v4.01))
피같은 → 피 같은
필요로 하는 → 요구하는
필요로 할 → 필요할
하고 있는 → 하는, 한
하길래 → 하기에
~하기 위해서는 → ~하려면, ~하려고
(발행)하는데 → 하는 데
하다보니 → 하다 보니
★★★★★★ 하지만 → 하지만,
한 가운데 → 한가운데
한가지 → 한 가지
한김에 → 한 김에
한 두 → 한두
해외여행 → 외국/재외/국외여행
향후 → (순화용어) 앞으로
현자들이 → 현자가
현혹시킬 → 현혹할
혼돈스럽게 → 혼란스럽게
휴대폰 → 휴대전화
휴우 → 후유
흥망성쇄 → 흥망성쇠
흥미로와서 → 흥미로워서
★★★★★ 힘든 → 어려운
100 여 → 100여

수집 동기: 한국어 맞춤법/문법 검사기 쓰기에 따른 개선 활동

InfoQ 기사 Java EE6: EJB3.1 Is a Compelling Evolution 를 읽고 인상에 남는 내용 메모

EJB 3.1은 JSR 318로 최근 발표한 Java EE 6 에 포함되어 있다. Josh Long 은 EJB의 새로운 특징(features)으로 Singletons와 The EJB Timer, No-Interface Views, Asynchronous Services, Simplified Deployment 등을 들었다. EJB 2.x 사용자라면 생소하겠고, EJB 3.0 사용자라면 편하게 느낄 테지만, 사실 스프링(Spring Framework) 사용자에겐 전혀 새로운 내용이 아니다. 그럼에도 불구하고 No-Interface Views와 Asynchronous Services 등은 눈에 띈다.

No-Interface Views는 일종의 암묵적 인터페이스 지원이다. 스프링은 애초부터 인터페이스를 강제하지는 않았기 때문에 예전부터 지원하던 기능이다. 파일 숫자를 줄일 수 있어서 복잡도를 낮출 수는 있지만, 인터페이스 기반 프로그래밍(Programming to Interfaces)의 이점과 더불어 일관성 저하를 낳아 큰 매력은 없다.

스프링에서도 3.0부터 지원하는 Asynchronous Services는 쓰임새를 잘 찾아내면 매우 요긴할 듯하다. 내부 메커니즘이야 구현 제품에 따라 다르겠지만, 스프링과 차이는 애노테이션이다. 스프링은 @Async 이고, EJB 3.1은 @Asynchronous이다. 스프링에서도 @Asynchronous 사용이 가능하다.

스프링의 발전이 "J2EE development without EJB" 였다면 프로그래밍 모델로서의 EJB 발전 방향은 "POJO-driven Java EE development without Spring and Hibernate"에 맞추는 듯하여 격세지감을 느낄 수 있다. EJB 3.1에 대한 보다 상세한 기사는 이미 TSS에서 다섯 편으로 연재한 바 있다.

Will it play in App Engine에서 확인 가능. 스프링뿐 아니라 Java Enterprise Edition (Java EE) Technologies와JVM-based Languages, Miscellaneous Java™ Libraries and Frameworks의 세 개 분류로 자바 기술 스택의 주요 구성 요소와의 호환성을 확인할 수 있다.


Spring MVC
Version: 2.5.6
Status: COMPATIBLE

• To see Spring's MVC framework running on App Engine, check out the autoshoppe sample application.
• If you're using Spring forms (e.g. using the spring-form.tld tag library and subclassing SimpleFormController), you will need to register custom editors for your properties. This is covered in http://groups.google.com/group/google-appengine-java/browse_thread/thread/d93fd7385bf85bf7.
  

Spring ORM
Version: 2.5.6
Status: COMPATIBLE

• To get Spring working with the App Engine-provided JPA interface, follow the instructions at http://objectuser.wordpress.com/2009/05/19/spring-jpa-in-google-app-engine/, which discusses a workaround to the dependency on javax.naming needed for @PersistenceContext. A more complex workaround is available at http://groups.google.com/group/google-appengine-java/browse_thread/thread/187d41712ec1d394.

Spring Security
Version(s): ?
Status: SEMI-COMPATIBLE

• To work around a ClassNotFoundException, you can use a re-compiled version of the library which adds a StringInsensitiveComparator class -- the download is provided at http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx.
  
• See http://www.dotnetguru2.org/bmarchesson/index.php?p=1100 for tips on how to get Spring Security running with App Engine and GWT (in French).
• See http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c for discussion on the integration.

Grails
Version: 1.1.1
Status: SEMI-COMPATIBLE

• A plugin has been made available which integrates the App Engine SDK with Grails, adding features to upload Grails application automatically and run the local dev server. To download this plugin or see a screencast and tutorial, see http://grails.org/plugin/app-engine.
• As of now, you have to use the "grails app-engine run" command rather than "grails run-app", which blocks other plugins that extend run-app including the GWT plugin. More incompatibilities noted in this thread.

GUI 기반 프로그래밍 전형이다. SDK가 제공하는 인터페이스 구현(implements)를 통해 이벤트 핸들러를 정의한다.


실제 비즈니스 로직은 모아 두었다.(sendNameToServer() 메소드)


GAE/J 가 원격 통신을 추상화시켜주겠지. 직관적인 콜백 메소드 이름(onFailure, on Success)탓에 쉽게 코드를 이해할 수 있다.

다른 GUI 프로그래밍과 다른 부분은 아래 코드다.


RootPanel 클래스의 add() 메소드로 HTML의 특정 영역을 지정하고, GWT 컴포넌트를 삽입한다. HTML 영역지정 코드는 다음과 같다.



이번에는 GAE/J Eclipse 개발환경의 특징이다. SDK로 서버가 배포되는 점에서 GAE/J의 포지션을 알 수 있는 부분이지만, 편리해서 마음에 든다.


얏호! 수 초의 작업 후에 배포에 성공했다.

http://ahnyounghoe.appspot.com/

마이플랫폼 스크립트도 자바스크립트와 거의 같은 문법을 사용하므로 JsDoc 적용 가능.


문제가 있는 파일을 고르기 위해 개별 실행한다.


로그만으로 알기 어려워 Perl 문법도 모르지만 일단 jsdoc.pl 파일을 열어 봤으나 코드만 보아선 알 수 없다. printf 명령을 넣어서 해시의 키라도 출력해보려고 했으나 암호(?)가 나온다. 구글 검색에 무언가 있는 듯하더니 페이지로 가보면 사라졌다. JsDoc 메일링 리스트 검색해도 답이 없다.

로그 문장을 보고 return 관련해서 의심스러운 코드를 bad.js로 저장해서 테스트해보니 같은 오류가 난다.


@return 뒤에 공백 문자 이외의 문자가 있거나 @return 구문을 아예 없애버리면 오류가 나지 않는다.




한참 삽질을 했기에 기록을 남겨둠
  

InfoQ 글(Are You a Software Architect?)에 메모를 추가함

이젠 앞서 정의한 아키텍처를 제대로 구현해내는 일(Delivery of the software architecture)이다.

Ownership of the bigger picture
아키텍트의 책임감을 요구하는 부분이다. 임무 완수(through to a successful conclusion)를 위해선 영업사원 마냥 개발팀 여러 구성원에게 아키텍처를 이해시키고 동조를 얻어야 한다.(sells the vision throughout the entirety of the software development lifecycle) 단기 프로젝트가 아니라면 개발 과정에서 얻어진 새로운 정보(혹은 요구사항)에 의해 변경도 필요하다.(evolving it throughout the project if necessary)


위 글은 두 가지 관점에서 볼 수 있다. 하나는 아키텍트의 책임감 측면이다. '아키텍트'라는 사람이 구현기술에 대한 상세한 내용은 내 일이 아니라며 미루는 모습을 자주 볼 수 있다. 물론, 본인 스스로 모든 것을 해결할 수도 없고, 그럴 필요도 없다. 하지만, 적어도 '아키텍트'가 아키텍처 이슈(시스템 전반에 영향을 미치는 사항)를 개발팀에 떠넘기는 것은 문제가 있다. 또 다른 측면은 '아키텍트'의 높은 몸값 때문에 프로젝트 초반에만 고용하는 점이다. 만일 아키텍트가 철수한다면 어떻게 아키텍처를 지켜나갈지 방책을 마련해둬야 한다.

Leadership
아키텍처는 역할에 의해 권위를 갖지만 기술적 결정과 가이드(providing technical guidance, making technical decisions) 책임 역시 갖는다. 아키텍트의 권위는 당연한 이야기처럼 들리지만 실제로 충부한 권위를 갖지 못하는 경우가 많다.(The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need ...)


Coaching and mentoring
국내 현실에서는 아키텍처 구현을 위한 가이드를 하다 보면 자바 문법이나 디버깅 방법까지 묻는 경우가 발생하고, 새로운 기술에 대한 거부감/저항/두려움을 갖은 인력을 만나는 일이 잦다. 게다가 설계 결정까지 개발자에게 넘겨서 난감한 구현을 만들어내는 일이 흔하다. 개발인력을 일시적인 노동력으로만 보는 현상과 지나치게 개발 절차 자체를 강조하는 경우, 코드가 아닌 문서 형태의 중간 산출물로 진척을 확인하는 현상과 관계가 있는 듯하다.

Quality assurance
품질보증(QA)을 위해서 보통 '표준화'라는 추상적인 이름으로 코딩 표준이나 설계 원칙(coding standards, design principles)에 대한 리뷰가 필요히다. 리뷰는 시간과 노력이 많이 필요한 작업으로 CI 도구나 테스트 지원 도구(continuous integration, automated unit testing and code coverage tools)의 지원이 필요하다. 개발자 테스트 없는 CI 도구를 이용한 자동화 빌드만으로도 아주 기본적인 통합은 보장할 수 있다. 최근에도 형상 불일치 문제로 오픈을 못한 사이트 소문을 듣곤 하는데 일부 개발자의 변화에 대한 초기 저항감만 누르면 쉽게 적용할 수 있다. 하지만, 자동화 테스트는 조금 다르다. 현실적인 기준선(baseline)으로 DAO에 대한 테스트에 초점을 맞추는데, 테스트 품질을 높이려면 다양한 현실적 사례(가령, 조회 요청에 대한 테스트라면 복잡한 조회 조건의 현실적인 경우의 수를 뽑아내 모두 테스트케이스로 수렴해야 함)를 테스트에 담아야 하는데 능동적으로 이를 이행하기란 아웃소싱이 기본인 SI 현실에서 불가능이라고 할 수 있다. 현실적 제약을 인정하면, '모 아니면 도'식 접근 대신 중요한 코드(architecturally significant, business critical, complex or highly visible) 테스트로 범위를 좁히는 것도 실용적인 접근이다.

국내 SI 프로젝트에서 자동화 테스트는 높은 ROI(투자 대비 수익)를 뽑을 수 있다고 생각한다. 일각에서는 이를 인지하고 실천하는 움직임이 보인다. 하지만, 여전히 대다수의 프로젝트에서 QA하면 절차(프로세스)에 대해서만 고민하고, 지나치게 문서에 매달리며 시간을 낭비한다. 소프트웨어도 제조물과 마찬가지로 제품에 대한 품질이 최우선이다.


Design, development and testing
Simon Brown와 내 생각은 거의 비슷하다. 그가 아키텍트의 몸값 탓("too valuable to undertake that commodity work")에 조직에서 코딩을 못하게 하는 점을 지적했는데, 외국이나 우리나 현실이 비슷한 모양이다. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines. 라는 말에 동의하지만, 게다가(In addition)로 부연한 내용이 더 중요하게 생각된다.

아키텍트가 꼭 코딩을 할 필요는 없다고 생각하지만, 만일 코딩을 하지 않으면 실제로 개발자 입장(the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective.)을 이해하지 못할 수도 있다. 최근에 고객 업무에 깊이 관여하면서 일치감을 느껴 신규 업무 설계와 화면을 만든 짜릿한 경험을 했는데, 개발자에 대해서도 마찬가지다. 유명한 국내 아키텍트 중에도 실제 구현 과정에서 겪는 어려움을 무시해서 모두를 어렵게 만드는 이에 대해 듣곤 한다.

 
개발자에게 아키텍트 역할에 대한 강연을 준비하던 글인 듯한데.. 마무리가 인상 깊다.


사이먼 말처럼 개발자이지만 이미 아키텍트의 역할을 (일부라도) 수행하는 이도 있다. 반대로 지겨운 개발(?)을 그만두기 위해 아키텍트를 꿈꾼다는 이해하기 어려운 사람도 어렵지 않게 만날 수 있다.

관련 글:

• 소프트웨어 아키텍트의 일에 대한 메모 (상)
• Architects architect architecture!

InfoQ 에서 흥미로운 글을 올렸다. 

Are You a Software Architect?


아키텍처는 시스템이 전체적으로 어찌 구동하는가를 이해하는 큰 그림에 대한 것이라는 일반적인 이야기를 해놓고, 이것만으로는 부족하다며 말을 잇는다.

그리고 바로 중요한 두 가지 사실을 꺼내 놓는다.


하나는 아키텍트는 경험이 필요하며 하루아침에 만들어지는 것이 아니라 서서히 키워지는 것이란 점(It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role.)

두 번째는 아키텍트는 역할이지 등급이 아니란 점. 사실 이 말이 피부에 와 닿으려면 아키텍트보다 높은 대가를 받는 고급 개발자가 있어야 하지 않을까?

점차 심도 있는 이야기를 꺼내는데 아키텍트가 행해야 하는 다양한 행위(involvement, influence, leadership and responsibility)를 설명하기 위해 아키텍처를 정의하는 측면과 구현하는 측면으로 나눠(Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it's delivered.) 부연을 시도한다.

Definition of the software architecture

떡 하니 다섯 개 영역으로 나눈 그림을 제시한다. 그림을 보고 문득 이런 생각이 든다. 만일 암기에 의해서가 아니라 경험에 의해서 아키텍트로 프로젝트에 참여했을 때 해야 할 일이 아래 그림처럼 자명하게 떠오르고, 프로젝트 규모와 기간, 해당 시스템의 업무적 특성, 그리고 사용 조직의 특성 등을 고려해 각각 방법을 만들어낼 수 있다면 스스로 전문적인 아키텍트라 칭해도 좋겠다는 생각을 한다. (반대로 그렇지 못하다면?)

Management of non-functional requirements
기능 요구사항과 달리 고객이 요구사항을 매우 모호하게('빠르게', '불편하지 않게') 주거나 아니면 아예 주지 않는다. 온라인 애플리케이션은 예상 사용자 규모에 따라 성능을 산정해야 하는 기술적 어려움이 따르고, 업무 프로세스와 관계된 배치(batch) 업무는 실제 업무 방식을 모르면 성능 기준을 수립조차 하기 어렵다. '잘하는 법'을 교육하기는 어렵지만, 잘 다듬어진 템플릿과 예제가 도움을 주긴 한다. 종종 몇몇 조직에서 EA나 프로세스 관련 프로젝트를 수행하고 나서 (다른 산출물은 유명무실하게 버려두지만) 비 기능 요구사항에 대한 체크리스트를 널리 재사용하는 경우를 본다.

Architecture definition
적절한 수준으로 비 기능 요구사항의 설정하면(captured) 아키텍처를 정의한다. 아키텍처 정의를 이루는 활동을 간략히 언급(Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project.)하고 설명하는 글에서 두 가지 사항이 눈에 띈다.

모든 시스템이 (정의을 하든 아니든) 아키텍처를 갖기는 하겠지만 항상 아키텍처를 정의하는 것은 아니란 점
It's fair to say that every software system has an architecture, but not every software system has a defined architecture.

그리고 신규 시스템이냐 기존 시스템 수정이냐에 따라 크게 다르다는 점

there's a big difference between designing a software system from scratch and extending an existing one.


Technology selection
기술 선택을 할 때 고려할 다양한 사항을 열거한다. cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments. 또, 기술 선택에는 위험이 따르기 때문에 검토와 평가가 필요하다. (need to be reviewed and evaluated)

위에 열거한 항목 외에도 흔한 일은 아니지만, 법적 문제나 기술 제공 업체(vendor)의 경제력이 문제가 되는 일도 있다. 국내 솔루션이 외산 솔루션 복제 소송에 휘말린 경우가 있고, 직원 월급을 지급하지 못해 솔루션 커스터마이징 인력이 안정적으로 일하지 못하는 경우가 발생한 바 있다.

역시 신규 시스템이냐 기존 시스템 수정이냐에 따라 기술 선택도 달라진다.

Again there's a big difference between evaluating technology for a new system versus adding technology into an existing system.


Architecture evaluation
소프트웨어가 갖는 복잡함과 추상적 성격 탓에 이해관계자에게 '구현할 소프트웨어가 어떤 것'인지 보여주기 어렵다. 시스템뿐 아니라 아키텍처도 테스트해야 한다. 요즘은 많은 프로젝트에서 파일럿을 통해 아키텍처를 검증한다. 주어진 제약(기간, 자원, 예산)하에서 무엇을 검증하느냐가 결국 관건이다. 막연히 잘 되기를 바라지 말고, 위험요소에 대해 적극적으로 대처해야 한다.(And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best)


Architecture collaboration
아키텍처는 개발자 관점뿐 아니라 다양한 측면(a security, database, operations, maintenance, support)에서 긴밀한 협업을 이끌어야 한다. 규모가 커질수록 서로 다른 많은 회사나 팀이 참여하게 되니 실천이 쉽지 않다.
 

관련 글: Architects architect architecture!

IBM DW의 A Conceptual Model for Event Processing Systems 에서 그림만 발췌

기업하기 좋은 나라?

생각의 좌표 -
홍세화 지음/한겨레출판

시민의 기본 자세

InfoQ에 기사가 올라왔다. 메이븐 2까지는 Plexus DI container 라는 넘을 쓴 모양이다. 글을 올린 InfoQ의 Josh Long의 요약에 따르면 메이블 플러그인 개발이 Plexus에 종속적인 면(Plugin authors need to understand Plexus)과 부족한 문서(the poor documentation)를 들었다. 다른 이유로 메이블 프로젝트와 소나타입(Sonatype) 창립자인 Jason Van Zyl의 말을 인용했다. 


얼핏 읽어보면 기반 솔루션(IoC 컨테이너)보다는 핵심 역량(개발 지원 및 빌드 도구)에 집중한다는 듯하다. 하지만, Jason Van Zyl 이 JSR 330: Dependency Injection for Java Expert Group 구성원란 점을 안다면 다르게 해석할 수 있다. 그가 작성한 글을 보면 Guice의 기능 때문에 오랜 친구(?)를 버린 듯하다.

제이슨이 직접 스프링(Spring)이 아닌 이유를 언급하진 않았는데, 메이븐 개발자인 Stuart  McCulloch이 나와 같은 궁금증이 있던 방문자의 글에 답을 달았다.


OSGi In Action의 저자이기도 한 Stuart  McCulloch가 Felix에 참여한다는 점을 고려하면 Spring을 선호할 가능성은 매우 낮아 보이기도 한다.^[각주:1] 현재 메이븐3 버전은 알파 6에 머물러 있다. 메이븐3은 메이븐을 시도하면서 겪었던 거부감을 완화하고 편리함을 느끼게 해줄 수 있을까?

• 현재 클래스 구조로는 통과시키기 어려운 구조 개선을 하려는 경우에 테스트 코드를 주석 처리(comment out)하고 구조를 변경한다. 이렇게 하면 구조 개선 과정에서 지금까지 되던 기능(기존 테스트)은 보장(회귀 테스트)할 수 있다. 이후에 주석 처리를 풀고 테스트를 다시 시작한다.
• for 등 반복문 괄호 범위 안에 넣어야 하는 로직을 밖에 넣었을 때 나타나는 오류도 빨리 포착할 수 있다. 다른 로직과 엉켜 원인을 알기 힘들게 되기 전에
• Ctrl+C, Ctrl+V 가 타이핑보다 유리할 수 있다. 복사 + 붙여넣기 하는 과정에서 자연스럽게 중복을 인지할 수 있으니 테스트 성공 후에는 기억/메모해두었다가 리팩토링한다.
  

초반부는 줄긋기에 열을 올렸다.
그리고 사람을 배려하는 마음에서 좋은 아키텍처가 나온다는 내 일에 대한 깨달음도 얻었다.
스무 페이지 남짓 읽을 때까지는 그랬다.

그러나 이내 교육 현실에 대한 강한 비판과
이를 낳은 어두운 과거사의 굴레와 현재의 그림자에 대한 암울한 인식은 편안하게 수용하기 어려웠다.
일단 1/3 정도 읽고 잠시 멈췄다. 나머지는 조금 휴지기를 두고서 읽으려고 한다.

얼마나 읽을지 모르지만, 조만간 한겨레 신문을 구독하기로 마음먹었다.
망설이고 있었는데 생각의 좌표에서 논한 한계레신문에 대한 부정적인 인식때문에 마음을 정했다.
구독하는 이유는 두 가지다.

하나는 아침에 여유를 갖는 삶을 살고 싶어서다. ^[각주:1]
두 번째는 좋은 신문을 표방한 한겨레 인터넷 신문에서 저질 광고를 빼줬으면 하는 바램 때문이다.


어머니가 통장이라 구청에서 구입하는지 접힌 채로 버리는 문화일보를 넣어준다.
한겨레신문으로 바꿔 줄 수 있는지 확인 후에 구독부터 끊고 한겨레로 바꿔야겠다.

'컨설팅에 유감 많습니다'라는 글에서 인상적인 내용만 발췌해봅니다.




IT에서도 비슷하게 적용할 수 있는 듯...

IBM DeveloperWorks가 소개한 자바 스크립트 프레임워크 비교(Framework comparison)는 풍성한 내용을 담고 있다. 최근에는 자바 스크립트 쓸 일이 없어 내용 자체에는 관심이 없었는데 기능 분류가 마음에 들어 발췌해둔다.

• Selectors
• DOM traversal
• DOM manipulation
• Utility functions
• Event handling
• Ajax

비교를 할 때 대상을 선정하는 일도 쉽지는 않지만, 조사를 통해 수집할 수 있지만, 비교 기준을 뽑는 일은 해당 분야에 대한 경험과 통찰력 없이는 불가능하다.