"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
아키텍트는 흔히 고객(甲)의 비즈니스 목표를 이루어주기 위한 최적의 아키텍처를 만든다고 착각하는 경우가 있습니다. 나도 역시 내 역할에 충실하게 일한다고 생각하고 이런 착각에 빠진 경우가 많습니다.
몇 일전 실력있는 고객과 이런 저런 이야기를 나누고 느낀 점이 있어 글을 올려봅니다. 고객(甲)과 수행업체(乙)의 대화입니다.
괄호는 혼자말입니다. ^^
乙: 우리 프레임워크를 사용하면 생산력 끝내줍니다.
甲: 다른 업체가 그 프레임워크를 사용하게 되어도 동일한가요?
乙: 우리 프레임워크를 사용하면 생산력 끝내줍니다.
乙: 음 얼마간의 교육이 필요하겠죠.
甲: 우리가 인수인계받아서 사용해도 생산력 좋겠죠?
乙: 마찬가지입니다. 정기적인 교육이 필요합니다. 게다가 무료입니다. 얼마나 좋아요.
甲: 우리는 다른 것도 써야 하고 업무도 해야 하니 학습곡선도 고려해 주세요. 그런데 프레임워크 소스는 주는 건가요?
乙: 아뇨 우리회사가 땅파먹고 사는 회사는 아니지 않습니까? 사용권만 줍니다.
甲: 허~ 왜 우리 시스템에 시한폭탄을 심어놓는다는 기분이 들죠?
乙: 우리는 여러분에게 필요한 프레임워크 구성을 풀세트로 제공합니다.
甲: 뭐 이리 복잡하나요? 이중 이번에 쓸게 몇 개나 되죠?
乙: 이번에는 20개중 3개정도 사용합니다. 그러나 내년에는 꼭 필요할 겁니다. 제 예측은 빗나가지 않아요.
甲: 음. 그럼 이 프레임워크를 올리려면 서버 스펙은 어떻게 되야 하나요?
乙: 네 이 정도면 현재의 4배정도 용량은 필요합니다.
乙: Hibernate나 JPA를 사용하면 Database 계층과 분리됩니다.
乙: 이런 방식으로 하면 DBMS 바뀌어도 끄떡없습니다. 더 이상 DB 벤더에 휘둘릴 염려없습니다. 환상적이죠?
甲: 우리는 애플리케이션 뒤집는 비용보다 DBMS 바꾸는 비용이 몇 배 더 듭니다.
甲: 우리는 다른 것도 써야 하고 업무도 해야 하니 학습곡선도 고려해 주세요. 그런데 프레임워크 소스는 주는 건가요?
乙: 아뇨 우리회사가 땅파먹고 사는 회사는 아니지 않습니까? 사용권만 줍니다.
甲: 허~ 왜 우리 시스템에 시한폭탄을 심어놓는다는 기분이 들죠?
乙: 우리는 여러분에게 필요한 프레임워크 구성을 풀세트로 제공합니다.
乙: 이번에는 20개중 3개정도 사용합니다. 그러나 내년에는 꼭 필요할 겁니다. 제 예측은 빗나가지 않아요.
甲: 음. 그럼 이 프레임워크를 올리려면 서버 스펙은 어떻게 되야 하나요?
乙: 네 이 정도면 현재의 4배정도 용량은 필요합니다.
乙: Hibernate나 JPA를 사용하면 Database 계층과 분리됩니다.
甲: 우리는 애플리케이션 뒤집는 비용보다 DBMS 바꾸는 비용이 몇 배 더 듭니다.
데이터베이스 전환 비용은 위험하기도 하지만 끔찍한 일입니다. 우리가 DBMS 바꿀 가능성이 얼마나 될까요?
아마 DB 벤더 바꿀정도의 상황이 오면 아마 애플리케이션도 다시 만들걸요?
아마 DB 벤더 바꿀정도의 상황이 오면 아마 애플리케이션도 다시 만들걸요?
乙: ...
그래도 벤더에 휘둘릴텐데요.
甲: (그 벤더가 너인것 같다.)
乙: 이 도구를 사용하면 몇 분만에 프로그램 하나가 나옵니다.
甲: 우리는 유지보수하는데 시간과 돈을 더 많이 씁니다.
乙: 이 도구를 사용하면 몇 분만에 프로그램 하나가 나옵니다.
빨리 만드는 것도 중요하지만 우리가 고치고 새기능을 붙이기 쉬운 방법으로 만들어주세요.
乙: 시간내에 프로젝트를 마칠 수 있다니까요? (우리는 빨리 만들고 떠나고 싶어요...)
乙: 이제는 SOA를 하지 않으면 도태됩니다.
甲: 우리는 단지 내부에서 사용할 간단한 회계업무 프로그램을 만들건데 그런게 필요한가요?
乙: 시간내에 프로젝트를 마칠 수 있다니까요? (우리는 빨리 만들고 떠나고 싶어요...)
乙: 이제는 SOA를 하지 않으면 도태됩니다.
그런데 서비스 그 기술 쓰면 서비스가 좋아지기는 하나요? (시스템이 친절해지기라도 하나요?)
乙: SOA 하면 기술적으로 이래 좋고 저래 좋다니까요? (아 이렇게 후진 아키텍처를 어디에 내밀어. 내 경력의 오점이야)문제는
근본적인 문제는 아키텍트가 비즈니스 목표를 제대로 이해하지 않고 있다는 겁니다. 아키텍트는 시스템이 죽지 않고 씽씽 돌아가는 것보다는 이걸 만들어 고객이 원하는 게 이루어질까를 더 고민해야 합니다.
나를 위한 아키텍처가 아니라 고객(甲)을 위한 아키텍처를 만듭시다.
'아키텍처' 카테고리의 다른 글
| 언어가 사고를 제한한다. 기술이 가능성을 제한한다. (2) | 2011/07/18 |
|---|---|
| 정경유착 (政經癒着) (0) | 2010/04/06 |
| '을(乙)'을 위한 아키텍처 (2) | 2010/03/25 |
| 개발자 그룹을 장악하는 방법 (6) | 2010/03/24 |
| 사람을 위한 아키텍처 (2) | 2010/03/05 |
| 비즈니스에 관심이 없는 아키텍트 (0) | 2010/02/17 |
