"거대 용량 시스템에서의 설계 이슈 from kaistizen" 에 대한 저의 대답입니다.
좀더 최적화 할 수 있겠지만, 그 프로젝트는 성공적이었다. 엔지니어가 할 수 있는 것은 "이렇게 하면 좀더 좋았지 않았을까요?"라고 말해보는 것이 전부일 것이다.
DBMS를 파일 시스템 수준으로 사용하는 것은 어떻게 보면 거대한 낭비일 수 있습니다. 하지만 해당 프로젝트를 수행한 집단의 목적성에 비추어 볼 때 실패는 아니겠죠. 아니 성공입니다. 기한내에 해내었고 어쨌든 잘 돌고 있으니까요. 비용적인 측면이야 예산내로 했을테니 (다른 요소 다 가리고) 일단 프로젝트는 성공이 아닐까요?
문제의 관점을 어떻게 놓고 보느냐에 따라 많은 답들이 나올 수 있습니다. 엔지니어링 적 측면에서 최적의 해와는 너무나 거리가 먼 솔루션은 나쁠 수 있습니다. 좀더 고민해 보면 "아름다운 아키텍처"가 있을 것인데 그건 고려치도 않고 대충 얼버무린 것은 끔찍한 코드를 집단적으로 작성한 것으로 여길 수도 있습니다.
순수한 엔지니어는 돈 못버는게 이런 이유가 아닐까요? 만약 이베이와 선이 새로운 DBMS를 만들려고 했다면 아마 아직도 하고 있을지 모릅니다.
반대로, 구글이나 몇 회사들 처럼 직접 구현한 회사들은 아름다운가에 대해 고민해 보면, 물론 최적의 성능을 끌어 낼 수는 있었겠지만 지금의 상황이 아닌 초창기의 상황을 보자면 시중에 좋은 구현들 많은데 돈도 많으면서 그런거좀 사지 왜 구지 만들었냐라고도 할 수 있습니다. 자신이 최적이 코드를 만들 수 있을지 몰라도 프로젝트 전체에서 보면 직접 구현이 항상 최적은 아닐 수 있죠.
항상 프로젝트 단위로 혹은 회사 단위로 생각해 볼때 엔지니어적 아름다움이 전부여서는 안될 것입니다. 반대로 단위 프로젝트의 경제성만이 전부는 아닙니다. 그렇게 놓고 보면 지금의 구글은 없었죠. stakeholder들이 무엇을 얻는가만이 중요할 것입니다.
대형 서비스업체가 SI기업에게 발주를 하였습니다. 그 프로젝트에서 "OO할아버지DBMS"를 직접 구현하여 초당 1조개의 데이터를 처리하게 만들었다~~라고 선전할 수도 있겠지만 두 기업은 무엇을 얻을까요. 그저 초당 1억개 정도만 처리하면 충분했었는데 말이죠.
상용DBMS를 사는 이유는 단순히 그 제품의 Full Functionality를 보고 사는 것은 아닐 것입니다. Feature List중 과연 몇%가 해당 프로젝트에 도움이 될까요. 제품을 구입한 곳은 가격을 지불합니다만 그 가치비교 대상은 Full List가 아니라 Sub List일 것입니다. Stored Procedure로 구현하면 물론 빠르겠지만 비베로 대충 짠 코드로도 충분한 성능이 나오면 구지 SP로 작성할 필요가 없을 것입니다. 오히려 다른 이슈들이 고려되겠죠. 마이그레이션이 예가 될 수도 있습니다. 비싼 상용툴을 산 이유는 업체 관계자랑 술을 마셨을 수도 있겠지만 AS나 기술지원을 봤을 수도 있습니다. 뭐 개인적으로는 순전히 브랜드에 대한 느낌 만으로, 돈과 관련된 내용은 Oracle이 아닌 곳에는 저장하지 않겠다라고 한적도 있습니다. 의사 결정자의 가격대비 효용가치를 판단할때 기존의 구현이 나쁘다고 보이지는 않습니다.
구글 케이스는, 그들은 자신의 시스템을 직접 구축함으로써 기업의 벨류를 쌓았습니다. 그것이 중요하였기 때문이겠죠.
검증되지 않은 기술을 실전에 사용하는 것은 이른바 "SI 프로젝트"에서는 자살행위입니다. 프로젝트의 성공가능성을 매우 낮추는 행위기 때문입니다. 벤처야 프로젝트 몇개 날려도 잃을 것이 없겠지만 대형 발주 하나 펑크 내고 패널티 몇달 들어가면 끝장입니다. 안전빵으로 가는게 최고입니다. 반대로 벤처의 경우 투자대비 아웃풋을 극대화 시켜야 하기 때문에 모험을 해야 할 것이고 그래서 벤처겠죠.
PS1.
어느날 갑자기 NHN이 자사의 모든 서비스를 Ruby로 재작성 하겠다고 발표했다고 칩시다. 이유는 "신규기능 확장이 너무 편해요"라고 하죠. 그렇다면 두가지 추측을 해볼만 합니다. 현재 시스템에 대한 미련을 버리고 과감한 변신을(심지어 회사의 사운을 건) 시도하는 것이거나, 대장이 지독한 변비에 걸렸나 보다 정도.
PS2.
개혁은 소규모 프론티어들에 의해 서서히 진행되는 거겠죠. 혁명을 해 버리면 누군가 피를 봐야 하고 후유증이 남고 결론적으로 좋아진건지 판단하기 더 어려워 질 것입니다. 개혁이 사회에 반영되어 기존의 구성원들도 따라 움직이게 만들어야 겠죠.
좀더 최적화 할 수 있겠지만, 그 프로젝트는 성공적이었다. 엔지니어가 할 수 있는 것은 "이렇게 하면 좀더 좋았지 않았을까요?"라고 말해보는 것이 전부일 것이다.
DBMS를 파일 시스템 수준으로 사용하는 것은 어떻게 보면 거대한 낭비일 수 있습니다. 하지만 해당 프로젝트를 수행한 집단의 목적성에 비추어 볼 때 실패는 아니겠죠. 아니 성공입니다. 기한내에 해내었고 어쨌든 잘 돌고 있으니까요. 비용적인 측면이야 예산내로 했을테니 (다른 요소 다 가리고) 일단 프로젝트는 성공이 아닐까요?
문제의 관점을 어떻게 놓고 보느냐에 따라 많은 답들이 나올 수 있습니다. 엔지니어링 적 측면에서 최적의 해와는 너무나 거리가 먼 솔루션은 나쁠 수 있습니다. 좀더 고민해 보면 "아름다운 아키텍처"가 있을 것인데 그건 고려치도 않고 대충 얼버무린 것은 끔찍한 코드를 집단적으로 작성한 것으로 여길 수도 있습니다.
순수한 엔지니어는 돈 못버는게 이런 이유가 아닐까요? 만약 이베이와 선이 새로운 DBMS를 만들려고 했다면 아마 아직도 하고 있을지 모릅니다.
반대로, 구글이나 몇 회사들 처럼 직접 구현한 회사들은 아름다운가에 대해 고민해 보면, 물론 최적의 성능을 끌어 낼 수는 있었겠지만 지금의 상황이 아닌 초창기의 상황을 보자면 시중에 좋은 구현들 많은데 돈도 많으면서 그런거좀 사지 왜 구지 만들었냐라고도 할 수 있습니다. 자신이 최적이 코드를 만들 수 있을지 몰라도 프로젝트 전체에서 보면 직접 구현이 항상 최적은 아닐 수 있죠.
항상 프로젝트 단위로 혹은 회사 단위로 생각해 볼때 엔지니어적 아름다움이 전부여서는 안될 것입니다. 반대로 단위 프로젝트의 경제성만이 전부는 아닙니다. 그렇게 놓고 보면 지금의 구글은 없었죠. stakeholder들이 무엇을 얻는가만이 중요할 것입니다.
대형 서비스업체가 SI기업에게 발주를 하였습니다. 그 프로젝트에서 "OO할아버지DBMS"를 직접 구현하여 초당 1조개의 데이터를 처리하게 만들었다~~라고 선전할 수도 있겠지만 두 기업은 무엇을 얻을까요. 그저 초당 1억개 정도만 처리하면 충분했었는데 말이죠.
상용DBMS를 사는 이유는 단순히 그 제품의 Full Functionality를 보고 사는 것은 아닐 것입니다. Feature List중 과연 몇%가 해당 프로젝트에 도움이 될까요. 제품을 구입한 곳은 가격을 지불합니다만 그 가치비교 대상은 Full List가 아니라 Sub List일 것입니다. Stored Procedure로 구현하면 물론 빠르겠지만 비베로 대충 짠 코드로도 충분한 성능이 나오면 구지 SP로 작성할 필요가 없을 것입니다. 오히려 다른 이슈들이 고려되겠죠. 마이그레이션이 예가 될 수도 있습니다. 비싼 상용툴을 산 이유는 업체 관계자랑 술을 마셨을 수도 있겠지만 AS나 기술지원을 봤을 수도 있습니다. 뭐 개인적으로는 순전히 브랜드에 대한 느낌 만으로, 돈과 관련된 내용은 Oracle이 아닌 곳에는 저장하지 않겠다라고 한적도 있습니다. 의사 결정자의 가격대비 효용가치를 판단할때 기존의 구현이 나쁘다고 보이지는 않습니다.
구글 케이스는, 그들은 자신의 시스템을 직접 구축함으로써 기업의 벨류를 쌓았습니다. 그것이 중요하였기 때문이겠죠.
검증되지 않은 기술을 실전에 사용하는 것은 이른바 "SI 프로젝트"에서는 자살행위입니다. 프로젝트의 성공가능성을 매우 낮추는 행위기 때문입니다. 벤처야 프로젝트 몇개 날려도 잃을 것이 없겠지만 대형 발주 하나 펑크 내고 패널티 몇달 들어가면 끝장입니다. 안전빵으로 가는게 최고입니다. 반대로 벤처의 경우 투자대비 아웃풋을 극대화 시켜야 하기 때문에 모험을 해야 할 것이고 그래서 벤처겠죠.
PS1.
어느날 갑자기 NHN이 자사의 모든 서비스를 Ruby로 재작성 하겠다고 발표했다고 칩시다. 이유는 "신규기능 확장이 너무 편해요"라고 하죠. 그렇다면 두가지 추측을 해볼만 합니다. 현재 시스템에 대한 미련을 버리고 과감한 변신을(심지어 회사의 사운을 건) 시도하는 것이거나, 대장이 지독한 변비에 걸렸나 보다 정도.
PS2.
개혁은 소규모 프론티어들에 의해 서서히 진행되는 거겠죠. 혁명을 해 버리면 누군가 피를 봐야 하고 후유증이 남고 결론적으로 좋아진건지 판단하기 더 어려워 질 것입니다. 개혁이 사회에 반영되어 기존의 구성원들도 따라 움직이게 만들어야 겠죠.
'개발&Development > 개발방법론' 카테고리의 다른 글
| 웹기획 (5) | 2008.01.31 |
|---|---|
| Tistory Project review 조금 (1) | 2007.10.22 |
| Software Estimation (1) | 2007.04.20 |
| 구성원들의 오해 (4) | 2007.03.20 |
| 인간 시뮬레이터 (0) | 2007.03.19 |