대기업 실전 애자일 1장 #1-1 지속적인 딜리버리
#1-1 지속적인 딜리버리(Continuous delivery)
이 책의 첫 번째 챕터에서는 필자가 과거 애자일을 처음으로 시작했던 이유와 경험에 대해 적었다. SW를 만드는 바쁜 개발 현장에서 새롭게 무언가를 시도하려는 독자가 있다면 이 이야기를 듣고 용기를 얻기 바란다. 이 챕터는 여러분의 시도가 얼마나 가치 있는지를 이야기하기 위해 쓴 글이다.
첫 번째 장은 3개의 경험담과 1개의 정리 글로 이루어져 있다. #1-1은 대형 SI 구축형 사업 후 운영 유지보수에서 지속적인 딜리버리 체계를 담당하고 이를 개선한 사례를 담았다. 어떤 엔지니어들은 현재 환경에서 혼자서는 아무것도 할 수 없다고 느낀다. #1-1은 그런 생각을 하고 좌절하고 있는 분들에게 도움이 될 수 있는 글이다.
#1-2는 입사 후 2년 후 혼자서 일하는 것에서 벗어나 당신이 첫 번째 후배와 일하게 된다면, 어떠한 시도를 할 수 있는지에 대한 사례를 담은 글이다. 필자는 과거 신입사원 3명의 멘토가 되는 행운을 얻었다. SI개발 및 운영 환경에서도 그들과 함께 페어 프로그래밍을 해보고 이를 성과로 만든 적이 있다.
#1-3은 혼자서 할 수 있는 애자일 기법에 흠뻑 취해, 큰 실수를 저지르고 이를 통해 무엇을 배웠는지 적었다. 가끔 자신의 실력을 맹신하는 분들은 이를 읽고 자신의 업무에 조금 더 철저하길 바란다.
마지막으로 #1-4는 위의 경험을 통해 무엇을 배웠는지 독자들과 이야기해 볼 수 있는 정리 글이다.
#1-1 지속적인 딜리버리(Continuous delivery)
* 개발자로의 커리어 시작
필자는 대학을 졸업하고 국내 최대 SI 전문 회사인 S사에 들어갔다.
이에 대해 주변 사람들의 두 가지 다른 반응이 있었는데, S사에 들어갔다고 축하해주는 대부분의 사람들과 다른 회사를 선택하는 게 더 좋지 않을까 조언하는 일부의 사람들이 있었다. 흥미로운 것은 다른 선택을 조언하는 사람들은 대부분 IT 업계에 근무하는 지인들이었다. 뭐 주변이야 어쨌든 필자는 S사에 입사하게 된 것이 정말 행복했고, 가진 능력에 비해 좋은 회사에 들어간 것이라 생각하고 만족해했다.
하지만, 6개월 정도 흘렀을까, 그때부터 필자에게는 조금씩 걱정거리가 생기기 시작했다. 주변의 지인들이 “IT를 계속하려면 다른 선택을 하는 게 더 좋지 않을까”라고 이야기했던 이유에 대해 진심으로 이해하기 시작했다. 당시 필자가 몸담았던 SI사업 현장은 다양한 문제들이 있었다. 이 문제들을 경험하면서, 자연스레 IT 엔지니어로 일하는 곳에서의 문화/환경/인식에 대한 불만이 점점 쌓여갔다.
가장 심각하게 느낀 가장 큰 문제는 “성장한다는 느낌이 없다” 는 것이었다.
필자는 가장 먼저 70명 정도의 개발자가 일하는 대형 공공 SI 프로젝트를 수행했는데, 스스로가 회사의 부속품 같다는 생각을 했던 것 같다. 개발을 잘하고 싶은 개발자로서 해야 하는 일의 패턴은 너무 단순했다. 대형 시스템을 위해 만들어진 견고한 개발 프레임웍은 마치 미 항공우주국 NASA의 프로그래밍 코딩 표준처럼 최소한의 시도와 실수만 용납하는 것이었다. (NASA는 최소한의 결함을 만들기 위해 매우 상세한 코딩 표준을 요구한다)
심지어 만드는 기능 자체도 경영정보시스템(MIS) 형태의 단순한 생성/조회/삭제/수정 패턴이었다. 기술은 화면의 HTML을 JSP로 고치는 일과 일부 쿼리 작업이 있었다.
처음에는 모든 것을 배워야 했던 입장이므로 그 개발 프레임웍들의 존재가 매우 감사했다. 개발 경험이 별로 없었음에도 프로젝트가 요구하는 기술들을 엮어 쉽게 기능을 개발하도록 도와주었다. 굳이 주변에 질문을 많이 할 필요도 없었다. 한 기능을 개발하고, 이전 작성한 코드에서 70% 정도를 그대로 복사해서 사용할 수 있었다. 그때는 정말 복사 후 붙이기 기능을 많이 썼던 것 같다. (SI개발 환경에서 소프트웨어 아키텍트라는 역할자들은, 개발자들의 고민을 줄이고 프로젝트 성공확률을 최대한 높이고자, 모든 기술을 그들이 먼저 생각한 뒤, 개발 표준이라는 것을 만들고 대규모 개발자들이 그 안에서 일하도록 도왔다. 이는 최고의 효율을 낼 수 있는 SI 프로젝트 수행 방법이었다.)
하지만, 두 달 정도 지나고, 이 일에 점점 익숙해지면서, 비슷한 패턴의 단순한 작업을 반복하고 있는 스스로를 발견하게 되었다.
"나는 깊게 고민할 필요가 없는 일을 하고 있었다."
옆에 앉아 개발하는 경력이 많은 직원들을 보면서, 나는 더 답답함을 느꼈다. 수년의 경력 차이에도 불구하고 그들과 필자의 능력은 크게 차이가 없어 보였다.
그들은 분명히 특정 도메인에 대한 지식이 가득 찬 풍부한 경험을 가지고 있었으나, 최근 각광받는 새로운 기술에 대한 고민이나 적응력은 그다지 훌륭해 보이지 않았다. 혹시나 내가 10년 뒤에도 이 자리에 앉아 똑같은 고민을 하고 있는 것은 아닐까라는 상상이 되면서 필자는 미래에 대한 두려움이 생기기 시작했다. 그리고 스스로에게 다음과 같은 질문을 하기 시작했다.
“내가 지금 여기서 무엇을 다르게 할 수 있을까?”
필자는 이 상황을 조금이나마 극복하고 앎에 대한 욕구를 해소하고자, 주변 사람들의 코드를 읽어보기 시작했다. 당시에 쓰던 공동 소스코드 저장소에서 다른 개발자들이 작성한 다른 패키지의 코드들을 보았다. 하지만, 안타깝게도 특별히 흥미를 느낄 수 없었다. 일부 자바스크립트를 현란하게 쓰는 개발자들의 코드를 제외하고는 필자의 코드와 크게 차이가 없는 느낌이었다.
필자는 기술 서적을 보고, 가장 센스가 있어 보이는 회사 내에서 선배들을 찾아 질문하고 공부하면서 앎에 대한 욕구를 채워나갔다. 이를 위해 프로젝트 외 스터디를 시작했다.
하지만, 프로젝트의 납기일이 점점 다가오면서, 필자도 프로젝트 내 다른 사람들처럼 크런치 모드에 들어갔다. 지식에 대한 욕구를 충족시키는 것보다, 어떻게든 먼저 만드는 것이 늘 우선시되었다. 비슷한 패턴의 일로 계속해서 야근을 했다. 이와 병행하여 공부하는 것은 쉽지 않았다. 우여곡절이 많았지만 13개월간의 야근과 주말근무가 반복된 프로젝트가 드디어 끝났다. 나는 마음속으로 쾌재를 불렀다. 그리고 반복되는 일상에서 벗어나 좀 더 새로운 일을 하고 싶다는 생각이 들었다. 스터디에서 공부했던 것들을 실제로 현장에서 써보고 싶었다.
* 새로운 역할 - 지속적인 딜리버리
인생의 첫 번째 프로젝트가 마무리되었다. SI 개발 프로젝트가 끝나면, 보통 1년간 무상 유지보수 기간이 시작되는데, 운영/유지보수 프로젝트를 총괄하게 될 관리자가 필자에게 다가와 말을 걸었다.
그는 내가 원하는 바에 대해 듣더니 '네가 원하는 것을 가장 잘할 수 있는 방법은 다른 프로젝트를 하는 것보다, 운영/유지보수 프로젝트를 하면서 여러 가지 일을 한 번에 할 수 있는 기회를 얻는 것'이라 이야기했다. 왜냐하면, 다른 프로젝트에 투입되는 순간 똑같이 작은 한 가지의 모듈을 맡게 될 가능성이 크기 때문에, 운영 프로젝트에서 개발에서의 여러 사람의 일을 경험하며 실력을 키워나갈 수 있다는 것이었다. 그리고 나에게 프로젝트를 함께 하지 않겠냐고 제안했고, 나는 고민 끝에 운영/유지보수 프로젝트에 남기로 했다.
필자는 그가 말했던 대로 다양한 일을 할 수 있는 기회를 갖게 되었다. 대형 SI 구축 형사 업이 유지보수 체제로 전환되면서 프로젝트를 떠나는 사람들이 대부분이었고 필자는 남들이 하던 일을 맡게 되었다. 하지만, 정말 힘든 시간을 겪게 된다. 현실적으로 볼 때 2년 차 엔지니어에게 맡겨진 일 치고는 많아도 너무 많았다.
필자는 시스템 관리 업무 개발, 로그인/보안 등의 공통기능을 개발하는 일, 서버를 운영하는 일, 배포를 담당하는 일 등을 해야 했다. 게다가 신규 및 변경 요구사항에 대해 고객과 협상하는 최접점 역할을 수행했다.
내가 맡은 일은, 불과 6개월 전만 해도 8명이 하던 일이었다. 유지보수 프로젝트가 시작된 후, 세 달 가까이 야근과 주말 출근이 반복되었다. 정말 힘든 시간이었지만, 필자는 여전히 긍정적이었다. 진심으로 이 ‘다름'과 ‘배움'을 즐겼다.
가장 마음에 들었던 일은 배포에 관련된 일이었다. 나는 평소에 존경하던 선배가 만들어놓은 ‘지속적인 딜리버리 시스템’을 운영하게 되었다.
당시 지속적인 딜리버리 시스템은 ‘크루즈 컨트롤’이라는 오픈소스에 ‘앤트’라는 애플리케이션 빌드 툴을 엮어두었고, 당시에 프로젝트에서 자체 구축한 프로젝트 관리 시스템이라는 SR(서비스 요청: Service Request) 처리 시스템과 맞물려 돌아가고 있었다. 당시 서비스 요청 흐름은 다음과 같았다.
이를 쉽게 설명하면 다음과 같다.
우선 서버는 크게 개발서버와 테스트 서버 그리고 운영 서버로 구성되어 있다. 개발서버의 빌드는 지속적인 통합을 통해 매 1시간마다 빌드가 되었다. 테스트 서버는 위에서 말한 시스템과 함께 엮여 빌드가 되었고, 운영 서버는 컴파일된 파일을 전달받고 재부팅이 메커니즘을 갖고 있었다.
이 서버들이 프로젝트 관리 시스템과 엮이는 것을 간단히 설명하면, 고객이 SR을 등록하면, 개발팀의 리더가 SR을 접수한다. 그리고 개발 리더가 특정 개발자에게 SR을 할당하고, 이 개발자는 이 SR의 내용을 확인하고 소스를 수정한 뒤 “SR처리” 상태로 변경하면서 수정한 소스를 패키지 구조로 리스트업 한다.
그리고 이를 “빌드 요청” 상태로 변경하면, 빌드가 일어나고 완료가 되면 이 SR이 “빌드 완료” 상태가 되고 웹 애플리케이션 시스템이 재부팅된다. 이후 고객이 테스트를 한 뒤 완료하면 이 내용이 “배포 요청”으로 옮겨지고, 다음 배포 시기에 배포되고 “배포 완료”가 된다.
이때 앤트는 SR 처리 시 리스트업 된 소스를 소스 코드 저장소에서 다운로드하여 폴더를 만들고 기존 소스와 함께 컴파일하고 완료되면 완료 폴더를 만들어 옮기고, 이 중 리스트업 된 파일만 파일 전송 기술로 테스트 서버에 보내는 역할을 수행했다.
당시 크루즈 컨트롤이라는 툴은 소스코드 저장소에서 특정 버전의 소스들을 태깅을 할 수 있는 기능이 있었다. 이 태깅 기능을 통해 어떤 파일이 어느 SR과 연관이 있는지를 마킹하여 빌드를 수행했다. 배포 대상은 표시를 해야 하는데, 심지어 소스코드 저장소의 마킹 기능도 엉망이었어서, 1500개 정도의 자바 소스가 있는 레파지터리에 필요한 소스를 마킹하는데만 20분 이상의 시간이 소요되었다.
결과적으로 저장소 내 4개의 소스코드 프로젝트의 빌드를 수행하려면 마킹이 매우 느려 1시간의 넘는 시간이 필요했다. 지금 생각하면 형편없이 느린 툴이었고, 그저 인수인계를 받아 운영했던 툴이지만, 나는 이 새로움과 복잡함 자체를 굉장히 즐겼던 것 같다. 그도 그럴 것이 ‘06년 당시 지속적인 딜리버리라는 개념은 등장하기 전이었고, 이 내용에 대해 아는 사람은 S사에 그리 많지 않았다. 필자는 이를 통해 주변 사람들에게 다름을 보여줄 수 있었다. (이후 2010년에 제즈 험블이 “지속적인 딜리버리”라는 책을 통해 이 개념을 세상에 알렸다.)
프로젝트 관리 시스템과 연계한 시스템은 “지속적인 딜리버리" 책의 내용으로 생각해 본다면 배포 파이프라인과 비슷한 개념이다. 지속적인 딜리버리에서 가장 중요시하는 테스트 코드는 없었지만, 그래도, 일부는 자동, 일부는 수동 프로세스를 통해 개발, 스테이지, 프로덕션 서버에 계속적으로 딜리버리가 가능한 파이프라인을 가지고 있었다.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
