[개발이야기] CD(Continuous Development)

지속적인(지속가능한) 개발 이런뜻인데, 이게 현재 개발자들이 말하는 CI(Continuos Integration)/CD(Continous Deployment/Delivery) 보다 조금더 넓은 개념이다. CI/CD는 개발->QA로 넘어가는 단계에서 구성원들이 조금 더 편하게 만들고자 등장한것인데 빌드자동화, 코드 인스펙션 자동화, 성능 분석자동화 툴, 테스트 자동화 등이 여기에 들어간다. 

 

일반적인 Continuous Itegration/Delivery/Deployment 출처:레드햇

 

CI/CD는 툴에 보통의존하는데 툴을 사용하여 구성원들의 신경을 분산시킬 여지를 막는데 목적이 있다. 본인의 Main Job에 더 집중하란 이야기. 집중하는 환경을 만들어줘야 한다는 대세에 의거 해서SDLC(Software Development Life Cycle)의 한 부분을 차지하고 있는것이라고 보면 된다.아래의 그림은 SI(System Integration) 에 적합한 그림이라 보면 되겠다.

 

Software Deveopment Life Cycle

 

일반적으로 솔루션/서비스 회사는 Requirement Analysis(요구사항 분석) -> Designing/Architecturing(설계) -> Development(실제 개발) -> Test(테스트) -> Deploy(릴리즈) 의 사이클을 가지게 되는데 CI/CD는 Development/Test에 부담을 덜어주기 위한 개념인 셈이다.위에서 말했듯이 부담을 덜어줬으니 코딩 더 열심히 하란 소린데... 그거 더 열심히 하면 어떤 결과물이 나올거라고 기대를 할까?

 

읽기좋은코드, 성능좋은 코드?... 개발자에게 집중해서 코딩만 할 시간을 주자라는 철학은 집중하면 좋은코드가 생성될거고 좋은코드가 생성되면 앞으로도 더 좋은 코드로 발전할 것이고 개발이 더 잘될것이라는 한없이 긍정적인 믿음에서 출발하는것인데 이건 이상일 뿐 이라고 본다(적어도 나는). 이건 사람이 하는일이고 사람은 실수하기 마련. 물론 정말 좋은 사람이라면 실수할 확률이 적겠지만(확률일뿐 실수 안한다는건 아니니까) - 이래서 나는 개발 Process와 채용론(사람들이 잘 이야기 안하는)을 좀 중시하는 편이다. 결국 이 이야기도 Software Development Process 이야기.

 

코드가 읽기좋아 => 모든사람이 어느때나 실수없이 잘 읽고 고칠 수 있을까?

코드가 성능이 좋아 => 모든사람이 어느때나 실수없이 잘 리펙토링 할 수 있을까?

그 외 기타등등 모든 사람이 어느때나 라는 말을 붙이면 그렇다고 말할 수 있는 사람 없을거다. 그래서 나는 지속가능한 개발 이라는게 중요하다고 생각하는 쪽이다.

 

No Money Cost. 이말 아무도 쓰지 않는말인데 나는 이렇게 지칭한다. 돈으로 지불하지 않는 비용. 이건 개발과정에서 생기는 것들인데 문서화, 개발자들의 자기 계발, tech con, 리뷰 등등이다. 일하는 과정에서 "공부 그런건 개발자 니네들이 알아서 해야지" 라고 하는 문화를 "잠재적으로 사용할 수 있는것들을 알아보고 공부하면서 개발하자"로 바꿔야 한다는 이야기. 이 과정이 개발하는 과정에서 오버헤드로 보이고 생산성이 떨어져보이는게 당연할거다(CEO 입장에선) 그런데 조직 전체로보면 "장기적으로 봤을때" 알아서 잘 굴러가는 조직이 되기 위해서는 이런 과정이 필수다.

 

개발 문화가 제대로 발전하지 못하는곳들은 이 No Money Cost를 쓰려고 하지 않는 조직이 많아보인다. 그럼 위와같이 잘 돌아가려면 어찌해야할까? Tutorial, How to, Manual. 등의 template이 있어야한다. 이슈 스펙작성 가이드, Test 작성 가이드, 브랜치 관리 요령, 기타 등등...이 잘 작성되어 있어야 디자인/개발 단계에서 개발/테스트로 넘어가는 단계를 스무스하게 사람의 실수 없이 넘어갈 수 있다. 그리고 사람이 바뀌더라도 그 단계를 거침으로서 코드만 읽고 범할 수 있는 실수를 넘길 수 있어야하고.. 그리고 리뷰 혹은 엔지니어들 끼리 하는 IT Talk(혹은 Conference)를 업무의 연장으로 생각할 수 있어야 된다. 왜냐면 엔지니어들은 사람이기때문에 사이클이 존재하는데(열중->나이브) 가능한한 이 사이클을 sin 그래프가 아니라 constant 그래프에 가깝게 바꿔야한다는 이야기다. 어떻게 사람이 본인 개발에만 계속 집중할까? 가끔 주변을 돌아보며 주의 환기도 해야하고 다른 기술들도 점진적으로 따라가야한다.

 

돈없는 스타트업 같은곳에서는 사실 말도 안되는일이긴 하다. 살아남는게 더 중요하니까. 살아남더라도 프로세스가 빈약한것과 무거운것의 사이, 그리고 업종, 회사의 스타일에 맞는 프로세스를 만드는게 CEO/CTO의 의지도 중요하고 의지만 갖는다고 해결되는 문제도 아니고.. 대기업은 이미 본인들의 프로세스를 갖춰놓고 바꿀생각도 잘없을테니 말이다. 결국 전부 생산성의 관점인데 장기적관점에서 다방면으로 생산성을 내기위해 달릴것이냐, 단기적인 관점에서 단편적인 생산성에 집중할 것이냐는 결국 선택의 영역. 흑백이 아닌이상 정도의 차이가 있겠지만 후자쪽에 치우칠수록 우리가 생각하는 사람 갈아넣어서 돌리는 회사에 가깝지 않을까 하는 생각이다.

 

사람은 여유가 없으면 가장 어리석은 행동을 한다. 미래를 생각하지 않는행동. 누구나 운동을 하면서 체력관리를 해야 지속 가능하게 일을 할 수 있고, 공부를 할수 있다는것을 알고 있다. 하지만 초조하고 조급하면 오늘 미래를 위해 써야할 시간을 현재 눈앞에 닥친것을 위해 쓴다. 조직도 마찬가지다. 혼자바뀌는것은 쉽지만 이미 굳어진 조직의 문화는 여러 구성원이 바뀌지 않는한 바뀌지 않는다. 물론 정말 여유가 없어서 선택지가 없을수도 있다. 하지만 조금이라도 선택할 수 있는 때가 왔을때에도 이전의 습관대로 행동하지 않게 경계를 해야하지 않을까.