2018.02.12

IT 재난이 임박했다··· 조기 경보 신호 8가지

Dan Tynan | CIO

지금은 괜찮아 보일지 모른다. 하지만 경보 신호가 이미 울렸음에도 불구하고 이를 아직 알아채지 못했을 가능성이 있다. 네트워크 상태가 갑자기 나빠지고 간단한 문제 해결에 시간이 더 오래 걸리며 계속 고장 나는 것이 생긴다. 모든 대규모 코드 릴리즈(Release) 후에는 버그가 출현한다. 셰도우 IT(Shadow IT)가 일상이 되었다. 그리고 비즈니스 전략에서 바뀐 부분을 당신이 가장 나중에 알게 된다.

직원들이 작업을 중단하고 웹사이트가 오프라인 상태가 되며 현업 사용자는 클라우드에 자신의 데이터센터를 마련하고 해커가 다크넷(Darknet)에서 당신의 고객의 기록을 판매할 즈음에는 이미 너무 늦었다.

오늘은 잠재적인 파멸에 대한 조기 경보 신호와 이를 모면하는 방법에 대해 알아보도록 하자. 무시한다면 그 대가를 치를 것이다.



현업 사용자가 더 이상 불평하지 않는다
불평이 줄어들면 좋은 것이라고 생각할 수도 있다. 그런 생각이 잘못되었을 수 있다고 IT서비스 제공사 알바카 네트웍스(Alvaka Networks)의 CEO 올리 토르다슨이 말했다.

그에 따르면 사용자가 문제 해결에 대한 희망을 포기한 경우 불평이 줄어드는 경우가 많으며 이는 모든 나쁜 결과로 이어질 수 있다.

토르다슨은 “도움 요청의 감소가 관리자가 잘 하고 있다는 뜻으로 늘 이어지는 것은 아니다. 사용자 커뮤니티가 IT 그룹에 대한 신뢰를 잃었다는 뜻일 수 있다. 그리고 나면 셰도우 IT, 교차 사용자 지원 메커니즘, 해고와 직원 회피가 증가하게 된다”라고 말했다.

토르다슨은 사용자가 불평할 때는 IT부서가 그들의 필요에 대응할 것이라는 기대가 있다고 말했다. 그는 언제든지 일정 수량의 오픈 티켓(Open Ticket)이 있기 마련이라며, 불평의 기준을 수립하고 그 수가 크게 변화하는 경우 각별히 주의하라고 조언했다.

물론 대규모 업그레이드 또는 다른 주요 변경사항으로 인해 불평이 증가할 수 있으며, 지원 티켓의 수량 감소는 상당한 프로세스 개선 또는 일부 장기적인 문제의 해결 때문일 수 있다. 토르다슨은 “하지만 증가 또는 감소의 문제에 대한 해답을 찾지 못한다면 큰 문제가 된다”라고 말했다.

구내 식당이 갑자기 외부인으로 가득 찼다
직장에서 점심을 먹는데 모르는 사람들이 가득하다면 조직이 다른 기업을 인수하고도 알려주지 않았을 가능성이 있다.

이런 인수가 조직에 좋을 수도 있고 그렇지 않을 수도 있다. 어쨌든 당신의 팀은 전략적인 프로젝트를 제쳐두고 새로 인수한 기업의 시스템과 데이터를 통합하는데 시간을 보내야 할 가능성이 높다. 이로 인해 혁신 능력이 저하될 수 있다.

부동산 사이트 트룰리아(Trulia)의 엔지니어링 부사장 딥 바르마는 2000년대 중반에 야후(Yahoo)에서 근무하면서 이를 직접 목격했다. 당시 해당 검색 포털은 광고 기술 기업 오버추어(Overture)와 여러 소기업들을 인수했다.

그는 “당시 야후가 많은 중소기업을 인수했기 때문에 대부분의 시간을 검색 키워드와 품질의 관련성 증가 방법을 찾는 것보다는 통합에 썼다. IT 직원 직원들은 '이런, 통합에 너무 많은 시간을 보내고 있어’라고 말하곤 했다. 이로 인해 혁신이 많이 느려졌다”라고 회고했다.

물론, CEO에게 기업 인수를 그만두라고 말하기는 어렵다. 하지만 비즈니스 리더들이 정말로 필요로 하는 분석 등의 부분을 통합하면서 제품, 로드맵, 사업부를 따로 유지하는 방안을 마련할 수는 있다.

바르마에 따르면 야후는 각 인수 건이 전반적인 비즈니스에 얼마나 적합한지에 관해 전략적으로 생각하지 않았기 때문에 혁신이 멈췄으며, 이로 인해 결국 종말로 치달았다.

계속 같은 문제를 해결하고 있다
조직의 IT팀이 하나의 극적인 문제 때문에 무릎을 꿇는 경우는 거의 없다. 오히려 미묘하고 멈출 수 없는 기술적인 부채의 축적이 문제를 일으키는 빈도가 잦다.

고지 및 협업 플랫폼 x매터스(xMatters)의 운영 이사 아담 세레디욱은 “늦은 밤 작업, 사소하지만 설명할 수 없는 고장 정지, 놀랍도록 오랜 시간이 소요되는 간단한 작업 등에 유의해야 한다. 종이에 수 천 번 베인 끝에 사망에 이르는 사망이 자주 발생한다”라고 말했다.

어느 조직에나 일정량의 비효율성이 내재되어 있으며, 대부분의 프로세스는 효과(effectiveness)과 효율성(efficiency)을 맞바꾼다고 세레디욱이 말했다. 하지만 같은 시스템이 계속 고장 나고 아무도 이를 방지하기 위해 선제적인 조치를 취하지 않을 경우 빠져 나오기 어려운 구멍이 출현하며 이로 인해 직원이 과로하게 되는 경우가 많다고 그는 강조했다.

세레디욱은 “누군가 조직을 떠나기로 결정하는 순간이 있게 마련이다. 그들이 일주일 내내 같은 문제를 10번이나 처리하고 미침내 링크드인(LinkedIn)에서 메시지를 보낸다. ‘저기요? 이제 정말 지겨워요.’ 그리고 그들은 떠난다”라고 말했다.

최고의 해결책은 가능하다면 오래되고 문제가 많은 시스템을 버리고 새로운 것으로 새롭게 시작하는 것이다.

“자칫 매몰 비용 오류의 함정에 빠지기 쉽다. 그런 경험에서 배운 지식으로 더욱 잘 하면 된다는 착각이다. 그러나 기술은 과거의 실수를 되새기기에는 너무 빠르게 변화한다는 사실도 감안해야 한다”라고 그는 말했다.

너무 많은 코드를 내보내고 있다
하나의 거대한 코드 덩어리를 내보낼 때는 상황이 잘못될 확률이 크게 높아지며 시스템 전체를 다운시킬 수 있는 캐스케이드(Cascade) 효과가 발생할 위험이 있다고 링크드인의 사이트 신뢰성팀 엔지니어링 부사장 브루노 코넬리가 말했다.

그는 “모든 것을 한 번에 해결하고 싶은 유혹이 있지만 여러 사소한 변화가 적용된 거대한 코드 덩어리는 작업이 훨씬 복잡하다. 그리고 무엇인가가 잘못되면 다른 시스템 문제를 더 많이 발생시킬 수 있다”라고 지적했다.

문제를 예방하기 위해서는 상대적으로 변화가 적은 소량의 코드를 더욱 자주 내보내는 것이 훨씬 좋다는 설명이다.

코넬리는 “우리 역시 코드를 가능한 자주 내보내기 위해 시스템을 최적화했다. 우리는 코드를 지속적으로 조금씩 내보내려고 노력한다. 이는 모든 것의 성능 특성과 다운스트림 의존성이 여전히 동일한지 확인하는 측면에서 유리하다”라고 말했다.

그에 따르면 링크드인은 또 고장을 의도적으로 시뮬레이션함으로써 예상치 못한 상황에 대비하고 있는지 확인하고 있다. 지난 11월, 해당 사이트는 신뢰성 엔지니어들이 애플리케이션에서 인공적인 문제를 발생시켜 서비스가 이를 얼마나 잘 처리하는지 살펴볼 수 있는 링크드아웃(LinkedOut) 프레임워크를 출시한 바 있다.

또한 링크드인은 하루 한 번씩 주요 데이터 센터 중 한 곳을 강제로 시스템 대체 작동시켜 실제 데이터센터 재난을 견딜 수 있는 충분한 용량과 자동화가 확보되어 있는지 확인한다고 코넬리는 전했다.

그는 “시스템 대체 작동 시나리오에서 살아남을 수 있는 능력에 대한 확신이 없다면 또 다른 경보 신호라 할 수 있다. 이를 지속적으로 실천함으로써 고장을 편안하게 받아들일 수 있어야 한다”라고 말했다.

직원들이 더 이상 아이디어를 제시하지 않는다
팀이 어려운 문제를 해결하거나 새로운 전략을 수립하도록 촉구할 때 귀뚜라미 소리만 들린다면 심각한 의욕 문제가 발생한 상황일 수 있다.


2018.02.12

IT 재난이 임박했다··· 조기 경보 신호 8가지

Dan Tynan | CIO

지금은 괜찮아 보일지 모른다. 하지만 경보 신호가 이미 울렸음에도 불구하고 이를 아직 알아채지 못했을 가능성이 있다. 네트워크 상태가 갑자기 나빠지고 간단한 문제 해결에 시간이 더 오래 걸리며 계속 고장 나는 것이 생긴다. 모든 대규모 코드 릴리즈(Release) 후에는 버그가 출현한다. 셰도우 IT(Shadow IT)가 일상이 되었다. 그리고 비즈니스 전략에서 바뀐 부분을 당신이 가장 나중에 알게 된다.

직원들이 작업을 중단하고 웹사이트가 오프라인 상태가 되며 현업 사용자는 클라우드에 자신의 데이터센터를 마련하고 해커가 다크넷(Darknet)에서 당신의 고객의 기록을 판매할 즈음에는 이미 너무 늦었다.

오늘은 잠재적인 파멸에 대한 조기 경보 신호와 이를 모면하는 방법에 대해 알아보도록 하자. 무시한다면 그 대가를 치를 것이다.



현업 사용자가 더 이상 불평하지 않는다
불평이 줄어들면 좋은 것이라고 생각할 수도 있다. 그런 생각이 잘못되었을 수 있다고 IT서비스 제공사 알바카 네트웍스(Alvaka Networks)의 CEO 올리 토르다슨이 말했다.

그에 따르면 사용자가 문제 해결에 대한 희망을 포기한 경우 불평이 줄어드는 경우가 많으며 이는 모든 나쁜 결과로 이어질 수 있다.

토르다슨은 “도움 요청의 감소가 관리자가 잘 하고 있다는 뜻으로 늘 이어지는 것은 아니다. 사용자 커뮤니티가 IT 그룹에 대한 신뢰를 잃었다는 뜻일 수 있다. 그리고 나면 셰도우 IT, 교차 사용자 지원 메커니즘, 해고와 직원 회피가 증가하게 된다”라고 말했다.

토르다슨은 사용자가 불평할 때는 IT부서가 그들의 필요에 대응할 것이라는 기대가 있다고 말했다. 그는 언제든지 일정 수량의 오픈 티켓(Open Ticket)이 있기 마련이라며, 불평의 기준을 수립하고 그 수가 크게 변화하는 경우 각별히 주의하라고 조언했다.

물론 대규모 업그레이드 또는 다른 주요 변경사항으로 인해 불평이 증가할 수 있으며, 지원 티켓의 수량 감소는 상당한 프로세스 개선 또는 일부 장기적인 문제의 해결 때문일 수 있다. 토르다슨은 “하지만 증가 또는 감소의 문제에 대한 해답을 찾지 못한다면 큰 문제가 된다”라고 말했다.

구내 식당이 갑자기 외부인으로 가득 찼다
직장에서 점심을 먹는데 모르는 사람들이 가득하다면 조직이 다른 기업을 인수하고도 알려주지 않았을 가능성이 있다.

이런 인수가 조직에 좋을 수도 있고 그렇지 않을 수도 있다. 어쨌든 당신의 팀은 전략적인 프로젝트를 제쳐두고 새로 인수한 기업의 시스템과 데이터를 통합하는데 시간을 보내야 할 가능성이 높다. 이로 인해 혁신 능력이 저하될 수 있다.

부동산 사이트 트룰리아(Trulia)의 엔지니어링 부사장 딥 바르마는 2000년대 중반에 야후(Yahoo)에서 근무하면서 이를 직접 목격했다. 당시 해당 검색 포털은 광고 기술 기업 오버추어(Overture)와 여러 소기업들을 인수했다.

그는 “당시 야후가 많은 중소기업을 인수했기 때문에 대부분의 시간을 검색 키워드와 품질의 관련성 증가 방법을 찾는 것보다는 통합에 썼다. IT 직원 직원들은 '이런, 통합에 너무 많은 시간을 보내고 있어’라고 말하곤 했다. 이로 인해 혁신이 많이 느려졌다”라고 회고했다.

물론, CEO에게 기업 인수를 그만두라고 말하기는 어렵다. 하지만 비즈니스 리더들이 정말로 필요로 하는 분석 등의 부분을 통합하면서 제품, 로드맵, 사업부를 따로 유지하는 방안을 마련할 수는 있다.

바르마에 따르면 야후는 각 인수 건이 전반적인 비즈니스에 얼마나 적합한지에 관해 전략적으로 생각하지 않았기 때문에 혁신이 멈췄으며, 이로 인해 결국 종말로 치달았다.

계속 같은 문제를 해결하고 있다
조직의 IT팀이 하나의 극적인 문제 때문에 무릎을 꿇는 경우는 거의 없다. 오히려 미묘하고 멈출 수 없는 기술적인 부채의 축적이 문제를 일으키는 빈도가 잦다.

고지 및 협업 플랫폼 x매터스(xMatters)의 운영 이사 아담 세레디욱은 “늦은 밤 작업, 사소하지만 설명할 수 없는 고장 정지, 놀랍도록 오랜 시간이 소요되는 간단한 작업 등에 유의해야 한다. 종이에 수 천 번 베인 끝에 사망에 이르는 사망이 자주 발생한다”라고 말했다.

어느 조직에나 일정량의 비효율성이 내재되어 있으며, 대부분의 프로세스는 효과(effectiveness)과 효율성(efficiency)을 맞바꾼다고 세레디욱이 말했다. 하지만 같은 시스템이 계속 고장 나고 아무도 이를 방지하기 위해 선제적인 조치를 취하지 않을 경우 빠져 나오기 어려운 구멍이 출현하며 이로 인해 직원이 과로하게 되는 경우가 많다고 그는 강조했다.

세레디욱은 “누군가 조직을 떠나기로 결정하는 순간이 있게 마련이다. 그들이 일주일 내내 같은 문제를 10번이나 처리하고 미침내 링크드인(LinkedIn)에서 메시지를 보낸다. ‘저기요? 이제 정말 지겨워요.’ 그리고 그들은 떠난다”라고 말했다.

최고의 해결책은 가능하다면 오래되고 문제가 많은 시스템을 버리고 새로운 것으로 새롭게 시작하는 것이다.

“자칫 매몰 비용 오류의 함정에 빠지기 쉽다. 그런 경험에서 배운 지식으로 더욱 잘 하면 된다는 착각이다. 그러나 기술은 과거의 실수를 되새기기에는 너무 빠르게 변화한다는 사실도 감안해야 한다”라고 그는 말했다.

너무 많은 코드를 내보내고 있다
하나의 거대한 코드 덩어리를 내보낼 때는 상황이 잘못될 확률이 크게 높아지며 시스템 전체를 다운시킬 수 있는 캐스케이드(Cascade) 효과가 발생할 위험이 있다고 링크드인의 사이트 신뢰성팀 엔지니어링 부사장 브루노 코넬리가 말했다.

그는 “모든 것을 한 번에 해결하고 싶은 유혹이 있지만 여러 사소한 변화가 적용된 거대한 코드 덩어리는 작업이 훨씬 복잡하다. 그리고 무엇인가가 잘못되면 다른 시스템 문제를 더 많이 발생시킬 수 있다”라고 지적했다.

문제를 예방하기 위해서는 상대적으로 변화가 적은 소량의 코드를 더욱 자주 내보내는 것이 훨씬 좋다는 설명이다.

코넬리는 “우리 역시 코드를 가능한 자주 내보내기 위해 시스템을 최적화했다. 우리는 코드를 지속적으로 조금씩 내보내려고 노력한다. 이는 모든 것의 성능 특성과 다운스트림 의존성이 여전히 동일한지 확인하는 측면에서 유리하다”라고 말했다.

그에 따르면 링크드인은 또 고장을 의도적으로 시뮬레이션함으로써 예상치 못한 상황에 대비하고 있는지 확인하고 있다. 지난 11월, 해당 사이트는 신뢰성 엔지니어들이 애플리케이션에서 인공적인 문제를 발생시켜 서비스가 이를 얼마나 잘 처리하는지 살펴볼 수 있는 링크드아웃(LinkedOut) 프레임워크를 출시한 바 있다.

또한 링크드인은 하루 한 번씩 주요 데이터 센터 중 한 곳을 강제로 시스템 대체 작동시켜 실제 데이터센터 재난을 견딜 수 있는 충분한 용량과 자동화가 확보되어 있는지 확인한다고 코넬리는 전했다.

그는 “시스템 대체 작동 시나리오에서 살아남을 수 있는 능력에 대한 확신이 없다면 또 다른 경보 신호라 할 수 있다. 이를 지속적으로 실천함으로써 고장을 편안하게 받아들일 수 있어야 한다”라고 말했다.

직원들이 더 이상 아이디어를 제시하지 않는다
팀이 어려운 문제를 해결하거나 새로운 전략을 수립하도록 촉구할 때 귀뚜라미 소리만 들린다면 심각한 의욕 문제가 발생한 상황일 수 있다.


X