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


Archive»


 
 

2019년 샌프란시스코 구글 NEXT 2019에서 발표한 로깅 시스템에 대한 강의 입니다.

구글 스택 드라이버 로깅에 대한 소개와, 삼성전자가 어떻게 스택 드라이버 툴을 이용해서 Devops로 적응했는지에 대한 사례입니다.

영어 컨텐츠 입니다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

줄줄이 실패하는 차세대..

IT 이야기 | 2009.09.01 11:30 | Posted by 조대협
http://www.ciobiz.co.kr/news/articleView.html?idxno=975
재미있는 기사인데..
요즘 IT 시장 상황을 잘 보여주는 듯한 기사 (나름 분석도 잘했고.)

공감이 가는것이 우리나라의 고객 시스템의 요구 사항은 다른 나라에 비해서 상당히 높은 편이다. 그래서 왠만한 패키지를 들고 들어오더라도 그 요건에 부합을 할 수 없을뿐더러, 많은 Customization이 필요한데, 이에 대한 이해나 인식이 낮다. 제품을 지배하지 못하고 사용하면 제품에 끌려갈 수 밖에 없는데, 이런 사례는 솔직히 수도 없이 봤다. 공부하지 않는 갑과, 양아치 영업들이 만들어낸 결과물이 아닐련지.

 경험의 부재도 마찬가지인데, I사가 덤핑으로 프로젝트 말아먹는 걸 보면 제일 정확하지 않을까? 글로벌 네트웍과 많은 노하우를 가지고 있음에도 불구하고, 그것을 이해하고 써먹을 수 있는 Local 인력의 부족으로 중소 SI 보다 부족한 실력으로 회사 간판만으로 프로젝트를 수행하다 보니 당연히 산으로 가는게 아닐까? 차라리 LG CNS나 SDS가 훨씬 더 이런면은 나아 보인데.

 오히려 외국계 기업들의 delivery 조직 (흔히 이야기 하는 컨설팅)이 구멍이 더 많을 것 같다.
잘하는 인력을 돈을 많이 주고 데려오던가. 아니면 교육을 팍팍 시키던가... 우리나라에 있는 외국계는 매출 올리기에만 급급하면서 사람팔아먹기만 하니 저런일이 안생길래야 안생길 수 가 없다.

 그리고 개발자와의 협업문제는 하루이틀 나온 사항은 아니고. 밤새기 강요. 푸대접.. 모 프로젝트들에서는 임금이 체불되서 파업까지 했다는데.. 이건 모... 애들 장난도 아니고..

 이런 사례들이 되도록이면 많이 알려져서 전체적으로 SI 프로젝트에 대한 문화가 바뀌었으면 한다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 허니몬 2009.09.01 12:45 신고  댓글주소  수정/삭제  댓글쓰기

    저도 공감!! ㅡㅅ-)!! 공영DBM이라는 곳에서 입사지원제의를 한 때와 맞물려서
    비슷한 상황의 글이 올라오니... 안볼 수가 없군요. ㅡㅅ-)!!
    거기서 CRM 솔루션 개발 이라고 하는데... @_@) 아직 자세히는 모르겠음. ㅎㅎ

  2. nokarma 2009.09.02 02:03 신고  댓글주소  수정/삭제  댓글쓰기

    SI 프로젝트에서 저런 경우는 다반사입니다.

    님이 있는 O사 본사 컨설턴트들 데리고 O사 본사에서 20분 거리에 있는 미국 회사 CRM시스템 구축한다고 2년 이상 헤메다가 포기하고 다 걷어치우는걸 본 적이 있습니다.

    이 경우는 기술력이 부족한 로컬 인력의 문제도 아니고,
    공부안하는 갑의 문제도 아니고,
    비즈니스 환경이 전혀 다른 문제도 아니고,
    저급 개발자들 데리고 무리한 일정으로 진행한것도 아닌데 말이죠.

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다.
주로 하는 작업이 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 신고  댓글주소  수정/삭제

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