Younghoe.Info v3

제2회 한국 SW 아키텍트 대회에 발표자 자격으로 참석했다. 행사에 관심 있는 분에게 공유 차원에서 후기를 남긴다. 먼저 리셉션 후기다. 마침 업무상 방문했던 분당에서 올라오는 길에 시간이 맞아 리셉션에 참석했다. 우연히 모 SI 업체에서 아키텍트 팀을 총괄하는 분이 옆에 앉았다. 인사를 청하자, 고객이 '아키텍트가 도대체 뭘 하는 사람이냐?'라고 물으면 한 마디로 뭐라 대답하느냐고 물었다. 난감한 질문이다. 대개는 프로젝트 종료 후에 인정하지, 말로는 설명이 어려웠다. 한 수 배우려고 오히려 반문했지만, 묘안은 없었다. 대화를 나누다 보니 자연스레 대회 필요성을 공감할 수 있었다. 아직, 직무로 통용하기 어려운 '아키텍트'란 역할에 대해 공감대나 저변 확대를명확한 정의, 범용성 확보 혹은 홍보 등의 활동이 필요한 듯하다.

축사 과정에서 두 가지 인상 깊은 발언이 있었다. '통신 분야에서 일하다가 SI에 왔더니 상황이 이 정도로 열악한 줄 몰랐다'라는 모 SI 업체 대표님 발언이 하나고, 다른 하나는 모 교수님의 '상식수준의 내용을 대단한 노하우인양 숨기던 관행을 벗어나자!'라는 취지의 발언이었다.

10일 세션 발표 시간은 아쉬웠다. 오후 발표는 시간이 늦어졌고, 가뜩이나 짧은 25분 발표도 5분이 줄었다. 핵심적인 메시지 위주로만 전달했는데 그래도 1분을 초과했다. 질문사항 응답 및 토론시간의 열기가 놀라웠다. 내 발표에 대해서도 질문이 있어 답변했다. 오픈소스 라이선스 관련 질문이 두 개나 있었는데, 발표자가 참석하지 않아 대신 대답했다. 이를 포함하여 몇 가지 인상적인 질문과 대답을 메모한다.

1. 아키텍처 평가 모델을 실제 프로젝트에 적용한 사례가 있는가?
없다. (좌장 추가 의견) 현실적으로 아키텍처 평가 모델에 입각한 절대적 검증은 불가능하다. 감리는 절차만 다룬다. 내용에 있어서 감리할 수 있는 조직이 국내에는 없다. 따라서, 다른 아키텍트가  경험에 따른 직관으로 조언을 제시할 수 있을 뿐이다.

2. 테스트 자동화를 위해 아키텍처 측면에서 고려해야 할 요인이 있나요?
없다. 테스트 자동화는 오히려 다양한 아키텍처를 포용할 수 있어야 한다. (다른 발표자 추가 의견) 테스트 자동화를 위해 아키텍처를 고칠 수 없다. 그러나 일관성 있는 아키텍처를 갖춘 시스템은 테스트 자동화가 쉽다. 가령, 각 레이어별로 전달인자가 분명한 경우를 떠올려보라.

3. Spring, Struts 등으로 비즈니스 로직을 구현한 경우 공개 의무는?
아파치 라이선스를 채택한 경우이므로, 사용 고지에 대한 의무는 있지만, 소스 코드 공개에 대한 의무는 없다. 자세한 사항은 오픈소스란 어떤 것인가? 내용 참조.

4. Hibernate와 iBatis 성능 비교?
단순 성능 비교는 의미 없다. 개발/운영 시 DBA가 SQL을 짜주는 경우라거나 SQL을 직접 노출하여 관리하기 위해 iBatis를 선택했다거나 장기적으로 객체 모델을 유지해가기 위해서 혹은 솔루션 코어를 만들기 위해서 Hibernate를 선택한다는 식이 바람직하다.