블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다.
주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다.

그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다.
결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요.

그런데, 만약에 Short Release를 통해서 매번 회귀 테스트를 진행했더라면 어땠을까 하는 생각이 문득 집에 도착한후에 들더군요. 그러한 문제는 아주 조기에 발견이 되었을 것이고, 초반에 아키텍쳐 수정이 가해졌을 것이며, 이렇게 비용을 들여서 Code Inspection을 하거나 추가 비용을 들여서 하드웨어를 증설할 일도 없겠지요...

그리고 여러개의 시스템이 연결된 시스템이기 때문에, 이제서야 통합 작업을 수행합니다. 마찬가지로 Interative and ieration 전략을 사용했더라면 초반부터 통합을 해왔기 때문에 통합때문에 드는 작업이 거의 없었겠지요.

특히 통합이 일정대로 원할하지 못한 경우, 이번에 튜닝을 위해서 거의 5명의 벤더 엔지니어를 불러다 놓고 하루종일 거래 개통도 되지 않아 엔지니어들이 대기하다가 돌아갔습니다. 보통 벤더 엔지니어의 하루 몸값은 Charging을 하는 경우에는 100~120만원선이 됩니다. 5명이니 대략 아무것도 안하고 600만원을 날린셈이 되는 것입니다.

회귀 테스트나 Iteration 방법론, Short Release 를 실제 프로젝트에서는 시간이 없다. 예산이 없다는 이유로 잘 사용하지 않습니다. 기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요.

결국은 위의 사례와 같이 오픈 연기, 하드웨어 추가 구매, 튜닝 컨설팅등의 추가 비용이 발생하고, 끊임없는 야근과 누더기 코드로 이어집니다.

반대로 지난번 프로젝트를 진행했던 S사의 경우 제가 진행했던 파트는 2주 주기의 Short Release를 사용했고, Short Release 마다 어떤 형태로든 비기능 테스트를 통해서 끊임없이 아키텍쳐를 검증했기 때문에, 지금 프로젝트에서는 통합에 대한 이슈나 아키텍쳐를 통째로 흔드는 일이 없습니다.

항상 자연계 열역학 제 1의 법칙을 이야기 하지만, "에너지 불변의 법칙"은 사람이 일할때도 통하나 봅니다. 개발과정에 생략한 테스트와 검증은 프로젝트 말에 그만한 부담으로 다시 돌아옵니다. 아니 에너지 불변의 법칙이 아니라, Defect 증폭의 법칙이라고 해야할까요?
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. zeous 2009.03.05 13:57  댓글주소  수정/삭제  댓글쓰기

    어디서 본 이야기인데
    요즘처럼 하드웨어의 가격이 엄청나게 싸지고 있는 상황에서는
    사람을 통한 소스, 아키텍처의 변경을 통한 튜닝보다는 CPU나 메모리 업그레이드를 통한
    튜닝이 훨씬 싸게 먹힌다고 하더라구요

    물론 이것이 절대적인 대안이 될수는 없지만
    점차 하드웨어의 성능향상이 소프트웨어의 질을 커버해주는 상황이 되어버리면
    소프트웨어의 질의 중요성이 점차 낮아지지 않을까 하는 걱정이 되네요..

    • 조대협 2009.03.05 16:11 신고  댓글주소  수정/삭제

      그것도 ROI 관점에서는 한번 생각해볼만 하겠군요.
      그러나 하드웨어 증설은 유지보수 관점에서, IDC 확보, BOX당 유지보수 비용 지불. BOX당 소프트웨어 LICENSE 추가등의 비용이 들지 않을까요? 오픈 소스 기반이 아니라면 하드웨어 증설은 증설만으로는 끝나는 문제가 아닌것 같습니다. :)

  2. 김민재 2009.03.10 01:17 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다.
    옥에 티라면,
    Itertive and iteration 방법론
    Interative and ieration 전략
    이 두가지 표현인데요.. 일단 오타가 있구요, 동일한 이야기의 핵심 표현인거 같은데 틀린 이유가 잘 짐작이 안되네요. 그리고 추가 내용을 찾고자 구글링을 했는데 이렇다할 내용이 안 나오네요. 관련 자료가 있다면 url 공유 부탁 드립니다. ^^

    • 조대협 2009.03.10 09:53 신고  댓글주소  수정/삭제

      오타 맞습니다. 맞구요.. ^^;
      Iterative and incremental 개발 방법론입니다.
      RUP도 그렇고, 실용주의나 Agile 방법론도 반복 및 점진적 개발방번론(Iterative and incremental) 을 기반으로 하고 있기 때문에 구글링해보시면 자료를 찾으실 수 있을것 같네요.
      감사합니다.

    • 김민재 2009.03.10 17:24 신고  댓글주소  수정/삭제

      http://alistair.cockburn.us/Incremental+versus+iterative+development
      Iterative and incremental 개발방법론은 이 둘을 다 취하는거네요..
      구별해서 생각하는 것도 또 다른 인사이트를 준다고 설명하고 있습니다.

  3. kenu 2009.03.10 08:36  댓글주소  수정/삭제  댓글쓰기

    "기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요."
    <-- 이게 너무 당연해서 나중에 힘든 거지요. 일반적인 개발자에게는 너무 익숙한 태도입니다. 등산을 하면서 나무에 리본을 달아주는 여유, 그 정도만 있어도 좋을텐데 말입니다.

  4. 안모대리 2009.03.10 15:47  댓글주소  수정/삭제  댓글쓰기

    사실 개발자들은 예전부터 그런 방법론을 써오고 있는 거 같습니다. 자기 중심의 Test-Driven 개발요. 전체적인 관점에서 작고 주기적인 Release식의 방법은 유용할 것 같습니다. 대형 프로젝트에서 어떻게 관리되냐가 관건이겠지만요. 조만간 몇가지 조언을 들을 일이 생길수도 있겠다는 생각이 드네요. 오랜만에 뵙고 싶기도 하고요.~~ 그럼 계속 좋은 글 기대하겠슴다.

    • 조대협 2009.03.11 11:55 신고  댓글주소  수정/삭제

      불러만 주신다면 저야 감사하지요...
      어떤 프로젝트 준비하고 계신지도 궁금하구요.
      한번 초대해주세요..
      이야기 같이 나누면 좋겠습니다.