"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
우리는 꿈에서 한국말을 사용합니다. 그리고 생각을 하더라도 한국말을 이용하여 생각합니다. 물론 영어권에 사는 사람들은 영어로 꿈을 꾸고 영어로 사고를 하겠지요. 문화의 특성 때문에 각 나라에서 사용하는 언어가 표현할 수 있는 정도는 매우 다양합니다. 예를 들면 에스키모가 표현하는 "눈(雪)"은 수십가지가 됩니다. 우리가 눈에 대해 상상할 수 있는 것과 에스키모인이 눈에 대해 상상할 수 있는 것은 그 차이가 크겠지요.
마찬가지로 우리가 사용하는 기술이 가능성을 제한합니다. 물론 자기가 잘 알고 있는 기술로 안되는 것 없습니다. 다만 시간이 좀 걸리고 비용이 올라가는 것일 뿐이죠.
간단한 아키텍처 vs 복잡한 아키텍처?
여기서 이야기하는 간단한 아키텍처는 최소한의 기술만 사용하는 간단한 구조의 설계방식을 이야기합니다. 이러한 아키텍처를 사용하면 초기 생산성이 높고 유지보수가 편해 보입니다. 그러나 결국 어려운 서비스 구현에서 한계를 갖고 편법이 동원되는 경향이 있습니다.
반면 복잡한 아키텍처는 좀 더 복잡하고 자동화되며 제약과 규칙이 많은 아키텍처를 이야기합니다. 많은 레이터나 티어 그리고 프레임워크들로 포진된 아키텍처들이죠.
이렇게 학습곡선이 높은 기술을 사용하면 초기 생산성이 낮아지고 유지보수 비용 높아지지만 구현의 난이도가 높은 기능도 쉽게 해결된다.
(초기 생산성 및 유지보수 비용은 논란거리입니다. 많은 프레임워크가 이 비용을 낮춘다고 이야기하지만 학습곡선, 인력수급, 프레임워크 유지비용 등 이야기할 거리가 많아 단정짓기는 어렵습니다. 확실한 건 복잡하고 거대한 아키텍처가 단순한 아키텍처보다 유지하는데 비용이 많이 드는 사실입니다.)
이렇게 학습곡선이 높은 기술을 사용하면 초기 생산성이 낮아지고 유지보수 비용 높아지지만 구현의 난이도가 높은 기능도 쉽게 해결된다.
(초기 생산성 및 유지보수 비용은 논란거리입니다. 많은 프레임워크가 이 비용을 낮춘다고 이야기하지만 학습곡선, 인력수급, 프레임워크 유지비용 등 이야기할 거리가 많아 단정짓기는 어렵습니다. 확실한 건 복잡하고 거대한 아키텍처가 단순한 아키텍처보다 유지하는데 비용이 많이 드는 사실입니다.)
어느 것을 선택해야하나?
서비스 초기에는 간단한 아키텍처가 당연히 유리합니다. 우선 초기에는 비즈니스 성공을 위한 time to market이 중요하고 비즈니스 향방에 따라 민첩하게 움직일 수 있는 간단한 아키텍처가 유리합니다.
비즈니스 규모가 성장하면 더 이상 시스템이 따라가기 어려운 때가 올 것입니다. 이 때가 아키텍처 개선이 필요한 때입니다. 어느 정도 성장하면 미래의 비즈니스 방향과 규모가 예측될 것이며 그 비즈니스 목표를 이루기에 무리없는 좀 더 복잡한 아키텍처로 이동합니다.
비즈니스 규모가 성장하면 더 이상 시스템이 따라가기 어려운 때가 올 것입니다. 이 때가 아키텍처 개선이 필요한 때입니다. 어느 정도 성장하면 미래의 비즈니스 방향과 규모가 예측될 것이며 그 비즈니스 목표를 이루기에 무리없는 좀 더 복잡한 아키텍처로 이동합니다.
초기부터 복잡한 아키텍처를 적용할 경우
그러면 애초부터 견고한 아키텍처를 가지고 가는 것이 맞지 않냐는 반문을 할 수 있습니다. 비용이 많이 들어 초기부터 투자하기 어렵다니 이런 것은 빼더라도 초기부터 복잡하고 견고한 아키텍처를 적용하기 어려운 이유는
첫째 미래는 예측하기 어렵습니다. 초기에 구축한 아키텍처가 미래에 필요한 기능에 적합한 아키텍처라고 장담할 수 없습니다. 비즈니스가 예측한 방향으로 가지 않을 경우 아키텍처를 고쳐야 할 수도 있습니다.
첫째 미래는 예측하기 어렵습니다. 초기에 구축한 아키텍처가 미래에 필요한 기능에 적합한 아키텍처라고 장담할 수 없습니다. 비즈니스가 예측한 방향으로 가지 않을 경우 아키텍처를 고쳐야 할 수도 있습니다.
둘째 비즈니스 향방에 따라 빨리 쫓아가기 어려울 수가 있습니다. 많은 경우 프레임워크나 아키텍처가 견고해 질수록 여러가지 제약과 규칙이 있어 다양한 방법의 기술적인 시도가 어렵습니다. 이는 대기업 조직이 그 규모를 지탱할 수 있는 모양으로 견고하지만 비즈니스 민첩성에 불리한 이유와 같습니다.
(이미지출처)
이런 전략을 피해야 할 경우
- 차세대 프로젝트
이런 프로젝트는 이미 비즈니스는 거의 확정되어 있고 그간의 문제를 해결하고 업그레이드 하는 경우입니다.
즉 위에서 말한 성장을 위한 거대한 구조개선인 경우입니다. 이런 경우 쉬운 기술로 접근할 것이 아니라 비즈니스의 목표를 이룰 수 있는 견고한 기술과 아키텍처가 필요합니다.
- 이미 전사 아키텍처가 결정된 경우
당연히 그냥 따르십시오. 다양한 기술구조를 가진 아키텍처는 비용이 많이 듭니다. 아키텍처의 변화가 필요하다면 POC(또는 스파이크)와 파일럿을 통해 해결하고 점차 비즈니스 요구가 있는 곳부터 바꿉니다.
비즈니스 규모에 맞는 아키텍처
무조건 어려운 기술과 멋진 아키텍처가 좋지도 않습니다. 그렇다고 쉽고 가벼운 아키텍처가 무조건 좋다는 이야기도 아닙니다.
회사가 처음에는 낮은 비용의 민첩성을 요구하는 구조가 필요하고 회사가 성장하면 규모를 지탱할 수 있는 견고한 구조가 필요합니다. 작은 회사가 대기업의 구조를 가지는 것도 불리하고 대기업이 적은 비용의 관리 구조를 가지는 것도 역시 불가능합니다.
목표 시스템의 비즈니스 규모에 따라 아키텍처도 변해야 합니다.
우연히... JavaService Net 에서 VO를 써야한다 말아야한다 논쟁하는 쓰레드를 보았습니다. 양쪽 다 일리가 있지만 어떤 상황과 가정없이는 끝나지 않는 논쟁같습니다.
아키텍처 논의나 결정에서는 Mission, Environment, Stakeholder과 같은 상황과 가정을 바탕으로 타당성(Rational)을 따져야 합니다. 기술로만 이야기하면 끝없는 논쟁에만 빠집니다.
우연히... JavaService Net 에서 VO를 써야한다 말아야한다 논쟁하는 쓰레드를 보았습니다. 양쪽 다 일리가 있지만 어떤 상황과 가정없이는 끝나지 않는 논쟁같습니다.
아키텍처 논의나 결정에서는 Mission, Environment, Stakeholder과 같은 상황과 가정을 바탕으로 타당성(Rational)을 따져야 합니다. 기술로만 이야기하면 끝없는 논쟁에만 빠집니다.
'아키텍처' 카테고리의 다른 글
| 언어가 사고를 제한한다. 기술이 가능성을 제한한다. (2) | 2011/07/18 |
|---|---|
| 정경유착 (政經癒着) (0) | 2010/04/06 |
| '을(乙)'을 위한 아키텍처 (2) | 2010/03/25 |
| 개발자 그룹을 장악하는 방법 (6) | 2010/03/24 |
| 사람을 위한 아키텍처 (2) | 2010/03/05 |
| 비즈니스에 관심이 없는 아키텍트 (0) | 2010/02/17 |
