책정리

---

백세코딩

저자

신현묵 지음

출판사

프리렉(이한디지털리) | 2014-07-25 출간

카테고리

컴퓨터/IT

책소개

스스로의 삶을 프로그래밍 하라 행복한 흰머리 개발자로 살아가기 ...

---

- 오픈마루나 KTH에서의 실수. 실패의 1순위는 돈을 벌지 못해서임. 실패의 첫번째 원인을 냉정하게 이야기하자면, 똑똑한 사람들이 모인다고 해서, 돈은 저절로 벌리는 것은 아니라는 것. 하지만 그래도 KTH의 도전은 오픈마루의 도전과는 차이가 있었고, 푸딩이라는 서비스가 생각보다 수익성을 기대할만한 서비스였음. 하지만 왜 그들은 모기업에서 더 기다려주지 못하고 해체되었을까? 그것은 정말 심각한 실패의 두번째 원인이다. 바로 그것은 모기업에서 원했던 것을 하고 있지 않았기 때문. 최소한 KT에서 원하는 것을 제대로 이해하고 비즈니스를 진행하지 못했음. 통신사가 원하는 ICT라는 해괴한 단어로 통신이 지배하는 세계를 다시 꿈구고 있다는 것을 모르는 듯 행동했음. 단편적으로 LTE에서 킬러 서비스로 제공될 재미있고 독특한 서비스를 KTH에서 만들어 모기업의 영광을 부활시키기를 원했는데 모기업에서 바라는 서비스를 개발하기 보다는 자기들만의 꿈을 위하여 달려가고 있었으니 모기업이 입장에서는 기가 막혔을 것임. 그래서 마라톤을 기획하였지만, 100미터 단거리 경주를 한셈. 최소한 모기업에서 투자한 벤처형태의 기업은 대부분 모기업의 영역에 도움이 되는 서비스를 개발하지 못하면 바로 사장되어 버리는 냉정한 비즈니스 세계에 있었던 것을 망각한 것은 아닐까. 대한민국 대기업의 투자와 테두리 내에서 자본을 수혈받는 안이한 방법으로는 세계적 정보통신기업이 만들어지기 어려움. 소프트웨어의 새로운 도전은 결코 대기업의 DNA를 이받아서는 탄생하지 않음. 자본주가 대기업이거나 제조업의 돈을 수혈받는다는 것 자체가 이미 DNA는 전이된 것이기 때문에 그 IT기업의 운명은 정해진 것. 스타트업은 그런 기존의 DNA가 주입되는 순간 운명이 끝난다. 아주 새로운 DNA를 기반으로 해야만 혁신은 가능함. 대부분 잉여를 인정하지 못했기 때문에 실패한 것이라고 이야기하고 싶다. 그들의 문화인 잉여를 인정하는 문화를 좀더 지켜보았다면 다른 결과가 나오지 않았을까? 잉여는 그렇게 쉽게 축적되지 않음. 그리고 기업의 목표는 돈을 버는 것. 돈을 벌지 못하면서 이야기하는 잉여는 아무 의미없는 단어일 뿐
- 주변 개발자들이 가장 잘못 쓰는 말 중 하나가 머릿속에 다 있다는 말이고 글로 쓰기에 너무 어려운 이야기라는 말은 가장 잘못된 것. 머릿속에 다 있다는 이야기는 한번 생각해보았으나, 결론을 내리지 못했다는 이야기로 들리고, 글로 쓰기 어렵다는 이야기는 그만큼 정리가 안되고 그 일에 대해서 잘 모른다는 이야기와 같음. 10년 20년 특정 도메인에서 일한 베테랑이라고 하는 개발자와 일할 때 자신이 하는 일은 너무 복잡하여 설계도나 다이어그램, 순서도, 타이밍 차트 등을 그릴 수 없다는 사람들이 있음. 그들과 이야기하고 다이어그램과 설계도로 만들어주어도 그들은 그것말고 설명이 안되는 그 무언가가 있다고 이야기를 함. 만일 그런 것이 존재한다면 그것은 당신만이 생각하는 경험이나 당신이 소중히 생각하는 가치일지 모르나, 그것은 어떤 지식이 되기엔 매우 부족한 것임. 지식은 설명하기 쉽고, 이해하기 쉬운 것. 설명하기 어려운 경험은 정규화되거나 전달되기 매우 어려움. 더 쉽게 이야기하면 쉽게 설명하거나 글자로 남기지 못하면 당신은 그것에 대해 잘 알고 있지 못한 것이다.
- 소프트웨어 기업의 필충조건
* 오픈된 생태계를 구성할 수 있는 열린 개발자 문화. 폐쇄적인 자신들의 수익모델로 수익 대부분을 갖고 가지 않음
* 단일제품이나 단일 서비스로서 상용화된 제품군을 가짐. 이를 판매하여 수익을 올리는 비즈니스 모델을 가짐
* 사용자에게 가치를 증가시키는 모델을 갖고 있으며, 소비를 위한 서비스만을 제공하지 않음
- 성공한 대한민국 중소 소프트웨어 기업의 특징
* 자신들만의 전문적 영역에 맞는 솔루현 중심으로 개발된 제품군을 가짐
* 중소 소프트웨어 기업의 대표이사는 직접 개발에 참여하고 있으며, 아직도 중요한 기능과 개발에 대해서는 직접 참여하고 CTO역할을 겸함
* 최소 5년 이상 하나의 솔루션에 집중하였으며, 초기의 어렵고 힘든 시간 동안 기업에서 버티지 못한 직원들이 들어오고 나갔지만, 그 개발의 중심에는 CEO가 직접 관여
* 대한민국의 고질적인 연구개발 자금에 기생하는 자금을 사용하지 않고, 큰 투자 없이 자신만의 힘으로 밑바닥에서 일으킨 스타트업 벤처를 기반으로 함
- 개발업무 진행은 투명해야 한다. 내가 어떤 업무를 진행하고 있는지, 기업과 조직이 진행하는 업무와 형태들이 내부의 동료와 직원들에게는 대부분 공개되어 있어야 한다. 그리고 투명화된 환경을 제공할 수 있는 시스템과 서비스들이 매우 효과적으로 제시되어야 하며 회사의 자산인 소프트웨어의 형상이 관리되어야 함. 소프트웨어라는 중요한 생산물은 관리되어야 하고 보다 훌륭하게 작성된 소프트웨어를 참조할 수 있는 환경을 갖고 있어야 함. 블랙박스 테스트가 되는 소프트웨어가 늘어야 함. 블랙박스 테스트(소프트웨어 검사방법의 하나로서 어떤 소프트웨어를 내부구조나 작동원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법을 이르는 말)가 되는 서비스와 모듈은 그 자체가 하나의 지식화된 형태로서 회사와 조직이 관리할 수 있음. 신뢰할 수 있는 소프트웨어가 된 것이다. 이러한 신뢰할 수 있는 소프트웨어가 많은 회사가 튼튼한 회사임.
- 사용자수만 늘린다고 무슨 가치가 있느냐는 벤처캐피탈의 물음에 답변을 준비해야 한다.
하나. 사용자 수만 늘리다 보면 결론적으로 성공할 것이니 나를 믿어라.
둘. 사용자수 말고도 다른 수익모델이 있다.
어느 방향으로 답변할 것인가에 대해 사업가들은 언제나 고민함. 우습지만, 투자를 받는 입장에서 첫번째 답변이 정답. 결론적으로 그런 질문을 하는 이유는 해당 사업에 대해 내가 얼마나 확신을 갖고 있는가에 대해 계속 질문을 한다고 이해해야 함. 현재 대부분 성공한 기업은 사용자수를 늘린 것이고, 그 이후에 필요한 비즈니스를 만들면서 고민하는 것이 정답. 이런 식의 질문을 하는 VC들은 엉터리들이니 피하는 것이 좋음. 정말 수준급의 제대로 된 VC를 만나는 것 자체가 어려움. 그런 VC들을 만나려면 내가 찾아가는 것이 아니라 그 사람이 나를 찾아오게 해야 함. 물론 이런 사람들을 만나기 전에 대부분 엉터리 같은 투자자들도 많이 만난다.
- 소프트웨어 분야에서 특정시점을 잡고 달성됐다고 말할 수 있는 것은 거의 불가능. 소프트웨어 품질은 지속적으로 관리돼야 하는 활동이기 때문에 테스트와 개발활동이 언제나 평행선을 그리면서 움직여 특정시점을 잡기도 어려움. 소프트웨어 테스트 계획은 요구사항 단계부터 시작하고 개발생명주기 동안 논스톱으로 계속 수행되며 소프트웨어의 품질을 향상시키는 것이기 때문. 일반적으로 소프트웨어 개발을 준비한다고 하면 테스트부터 준비하라고 말한다. 국내는 on going activity를 바이블 삼아 활동에 들어가는 비용과 리소스, 시간을 최소화 혹은 무시하는 것이 관행처럼 굳어져 있음. 그런 식으로 우리는 프로젝트를 구성할 때 최악의 상황은 전혀 고려하지 않음. 언제 어떻게 닥쳐올지 모르는 최악의 상황에 대한 대비가 너무 소홀함
- 소프트웨어 개발방법론에서 실버블렛(어떤 문제해결을 위한 묘책, 특효약)은 존재하지 않음. 다만, 소프트웨어 개발에도 유행이 존재. 사람이 바뀌지 않으면 도구와 방법론은 언제나 무용지물임. 애자일 도입 초창기 경험없는 사람들이 큰 고려없이 문서 작성도 필요하지 않은 것이 애자일이라고까지 말하는 게 국내 소프트웨어 개발분야의 실상이다 보니 애자일을 프로세스의 일부라고 주장하는 사람까지도 등장할 정도로 왜곡됨
- DevOps는 소프트웨어 개발과 운영, 서비스의 효율적 환경을 만들고자 노력하는 개발문화로서 간단하게 줄여 설명하면, 소비자 및 사용자들의 서비스 요구사항을 가장 빠르고 단순화하여 대응할 수 있는 신속한 서비스 지원형태, 그리고 그것을 지원하고 유지해주는 소프트웨어 개발문화라고 할 수 있음. 그래서 Development/Operation을 합친 말임. 물론, 이렇게 만들어진 환경은 개발자를 행복하게 할 것이다. DevOps는 단순화, 신속함이라는 서비스 형태를 지향. 그리고 그것을 지원하고 유지해주는 소프트웨어 개발문화를 지향. 실제로 DevOps를 구현했다고 평가받는 넷플릭스와 플리크 등의 개발성과물은 놀라울 정도로 효과적임. 1만개 이상의 AWS 인스턴스를 불과 10여명의 DevOps팀이 운영하고, 초당 4만장 이상의 업로드 부하를 버티고 자동화된 상태에서 하루 10회 이상의 배포본이 반영되는 매우 효과적인 개발과 운영이 접목된 환경을 만들어낸다는 사실에 개발자 문화의 최신화 경향을 만들어 냈음. 이렇듯 엄청난 효율과 고속의 처리를 만들어낸 것은 어떤 이유 때문에 가능한 것이었을까? 그리고 이러한 DevOps의 성과물들은 일반적인 IT기업에서도 얻을 수 있는 환경일까? 가장 먼저 DevOps의 장점 몇가지를 정리하고 넘어가자.
* 최소인원으로 개발과 운영이 가능한 환경 지향
* 서비스의 배포와 운영이 자유롭고 서비스가 매우 신속하고 빠르게 운영됨
* 배포가 자동화되며 그에 따라 고품질 서비스를 지향
- DevOps가 가동되고 개발조직의 문화가 되기 위한 조건
* 소프트웨어를 잘 만들어내는 개발자
* 잘 작동하도록 운영하는 운영자
그리고 이러한 두가지 조건을 만족시키기 위한 기본적인 환경구성이 필요. 그것은 가장 먼저 소프트웨어 품질을 관리하는 제대로 된 품질관리 조직이 있어야 하며, 개발조직이 빠르게 소프트웨어를 개발, 빌드, 테스트, 배포, 운영하게 할 수 있는 사이클을 신속하게 진행할 수 있는 개발환경을 갖추고 있어야 하고 업무 프로세스를 정의하고, 각 조직간의 역할을 조율하는 프로세스들이 매우 자연스레 자동화되어지고 효율적으로 운영되어야 함.