박상도 개발자의 해외직구 배송대행 스타트업 CI/CD 도입기

『지속적 통합배포 구축은 처음이라』는 ‘[Beyond the book] 『자바 프로젝트 필수 유틸리티』 편’ 참여자의 글을 모아 한 권의 책으로 엮은 무료 전자책입니다.

[Beyond the book]은 책, 그다음 이야기를 전하는 독자참여 프로젝트입니다. 책을 읽고 현업에 적용한 이야기, 책에 소개된 내용 이외의 더 나은 대안은 없는지 등 다양한 주제의 독자 여러분의 기고를 기다리고 있습니다.  



박상도
십자 드라이버 하나 들고 컴퓨터를 수리하다가 개발자로 전향했다. 게으른 개발자일수록 반복되는 무의미한 일을 자동화할 방안을 찾는다고 믿는 ‘호모사피엔스’ 다. 중력에 순응한 뱃살이 개발자란 내 직업을 말해준다고 믿고 있다. 해외 직구 배송대행 서비스 회사에서 일하다가 최근에는 삼성 Apps 관련 팀에서 프리랜서로 일하고 있다. Sangdo Park란 이름으로 유튜브에 개발 관련 영상을 올리고 있다.



어떤 문제가 생기면 그 문제를 가장 쉽게 해결할 방법을 찾는 일을 최우선으로 하는 게으른 개발자입니다. 게으르다는 수식어는 부정적인 단어지만, 주니어 개발자 시절에 겪었던 에피소드를 들어보면, 깨달음의 결과로 게으르게 된다는 것에 수긍이 될 것입니다.


처음 개발자의 길에 첫발을 내딛었을 때에는 프로그래밍에 대한 경험이 많이 부족했습니다. 당시 운영하던 콜센터 시스템에 연동된 기간계 시스템이 유지보수를 이유로 밤 9시에  잠시 중단된다는 얘기를 듣고, 콜센터 시스템이 중단될까 우려되, 퇴근 후 밤 9시에 다시 출근하여 사용자에게 일부 서비스가 중단되었다는 메시지를 보여주도록 파일을 교체했었습니다.
나중에서야 든 생각인데, 단순히 if 구문을 이용해 현재 시간 값을 체크하여 단순 분기하면 될 일이었습니다. 루키 시절의 얘기라 너무 바보 같다 여길지 모릅니다. 조금만 생각하면 쉽고 빠르게 처리할 수 있는 일임에도, 경험 부족과 기능 숙지 미달로 참 바보 같이 일을 처리했구나 하는 생각이 들었습니다.


정도의 차이는 있겠으나, 프로그래머 직업의 세계에서 비일비재하게 일어나는 이러한 일을 여러분도 한두 번쯤은 겪었을 것입니다. 컴퓨터는 가능하면 많은 일을 한 번에 처리해야 하고, 개발자는 개발을 하면 할수록 게으를 권리를 찾아야 한다고 믿습니다.

혼자 하던 일에서 벗어나, 어느덧 규모가 큰 다른 프로젝트를 경험하며 자연스럽게 프로그램을 작성하는 일과 더불어 많은 일이 함께 진행되는 것을 지켜보게 되었습니다. 예전에는 SE, SA, DA 등으로 호칭되는 각자 맡은 일을 함으로써 한 시스템이 설계, 구성, 작성, 운영되는 일이 많았습니다.

최근에는 각 개인의 역량과 능력도 중요하지만, 팀 혹은 회사 구성원의 유기적인 협력과 조화가 큰 힘을 발휘하고 더 중시할 수밖에 없습니다. 시스템은 나날이 대형화되고 복잡해지면서 종합적인 엔지니어링 기술자가 필요한 일이 많아졌습니다.

다수의 작은 서비스를 제공하는 시스템 혹은 인스턴스가 모여 하나의 거대한 서비스를 제공하는 MSAMicro Service Architecture 가 등장하여 각각의 영향도를 최소화하여 무중단 서비스를 제공하는 사례도 있습니다. 개발자가 원격지에서 개발한 후 스스로 소스 코드를 검증하는 정적 분석 툴을 아주 쉽게 사용하기도 하며, 온라인 상에서 상호 코드 리뷰를 진행하고, 테스트를 통과한 소스Sources를 리포지토리Repository에 반영 즉시 서비스가 제공되는 방법도 사용됩니다.

사실상 시간과 공간의 제약을 받지 않는 환경에서 일하게 되면서 얼마 전까지는 상상으로만 여겼던 이러한 자동화가 눈앞에 펼쳐지고 있습니다. 이러한 일을 어떤 툴이나 프로그램으로 가능하게 되었지를 소개하는 것이 이 글의 처음과 끝이 아닐까 싶습니다.


이 글을 읽게 될 개발자가 어느 정도 관심을 가지고 CI/CD 를 대하는지를 알 수는 없습니다. 하지만 중요한 점은 이를 언젠가 쳐다 볼 관심의 대상이 아닌 지식으로서 자신의 것으로 만들면, 수많은 선배 개발자가 만들어 놓은 훌륭한 연장Tools으로 작업 시간을 혁신적으로 줄일 수 있을 것입니다.


 "Hello, World !" 에서 "Hello, Universe !! " 로 업그레이드 될 것입니다.


우리는 이런 시스템을 개발하고 있다.

개발팀이 단 2명으로 구성된 한 해외직구 배송대행 서비스 스타트업(이하, 회사)에서 일을 했습니다. 자체 쇼핑몰 서비스와 해외직구족을 위한 배송대행 서비스를 함께 제공하는 회사입니다. 국내 이용자를 대상으로 신청, 접수 등의 서비스를 제공하는 메인 웹Web 사이트와, 배송 대행을 제공하는 각각의 해외 거점 물류창고에서 몇 명의 직원이 PC에 설치된 CSCustomer Service 프로그램을 운용하며 웹 서비스Web Service를 호출하는 시스템이었습니다.

처음 일에 합류하게 되면 당연한 수순이지만 서비스가 어떻게 제공되는지, 시스템과 시스템의 네트워크 구성은 어떻게 이루어졌는지, 개발/테스트/배포 환경은 어떻게 구성되어 있는지를 파악합니다.


그림1 기존 시스템 구성도



개발자 PC에서 컴파일과 빌드 후에, HTML, CSS, Images, Classes Files를 직접 FTP로 접속하여, 경로를 찾아 업로드하고 있었습니다. 운영 관점에서 치명적이라고 할 수 있는 서비스 중단 사태도 간혹 일어나고 있었습니다. 데이터베이스DataBase, DB 운영은 차치하더라도 개발 작업 후 빌드와 배포가 수동으로 이루어지고 있음에 놀라지 않을 수 없었습니다. 혹여 의도치 않게 실수라도 하는 날이면 어떤 사태가 벌어질지 눈앞이 깜깜했습니다.


기존 개발 환경

소스 코드의 버전 관리 VCS는 일부는 깃Git, 일부는 SVN으로 이루어져 있었습니다. 선임자가 Setup을 했다는 이유로 개발 환경을 통합하거나 개선하지 않고 유지하고 있었습니다. 수시로 바뀌는 이벤트 팝업, 이미지 데이터 변경, 파악이 어려운 퇴사자의 작업 내용 등을 이유로 정확한 버저닝조차 되지 않고 있었습니다.

그 때, 『자바 프로젝트 필수 유틸리티』 책이 출간되었다면, 이 책을 회사에 비치해두고 순서대로 개발 환경 개선 작업을 진행해야 한다고 설득하는 일이 쉬웠을 텐데 하는 아쉬움이 있습니다. 실타래를 하나씩 풀어가 듯 이 난국을 벗어나 보자는 생각으로 작업을 시작할 수밖에 없었습니다.

개발자로서 일을 할 때 소프트웨어를 만드는 일은 결국 사람이 힘들게 하는 일을 쉬운 조작만으로도 컴퓨터가 자동으로 아주 빠르고 정확하게 해결해주기를 바라는 방향으로 작업해야 한다고 생각합니다. 이는 컴퓨터 혹은 소프트웨어 전공자이든 비전공자이든 초보이든 고수이든 누구나 원하는 일일 것입니다.

하지만, 프로그램을 작성하는 일에만 초점이 맞춰진 나머지, 프로그램을 작성하고 그 프로그램이 효율성과 논리의 정확성이 담보되는가에 대한 테스트를 통과하는지, 그리고 휴먼 에러Human Error를 방지하도록 미리 작성된 스크립트에 따라 자동 배포되도록 신경 쓰는 개발자는 많지 않은 것이 현실입니다.

대부분의 소규모 개발 현장에서는 기존의 관습과 다르게 새롭게 도입되는 일에 대한 러닝 커브Learning Curve를 받아들이지 못하고 강하게 거부하는 개발자를 자주 볼 수 있었습니다. 아울러 책임론에서 자유롭지 않다는 점을 내세워 타인의 시도조차 막는 일을 많이 봤습니다.

이번만큼은 개발자가 몇 안 되는 스타트업이었기에 CI/CD 툴의 A to Z까지를 고민하고 바로 실천할 수 있는 환경에 던져진 것에 감사합니다.

개발자는 기본적으로 주어지는 하드웨어적인 환경도 중요하지만(이것부터 배려가 없는 환경이라면 이직을 진중하게 고민하고 권하는 바입니다.), 소프트웨어적인 환경의 개선 노력과 생산성 향상 툴의 습득 노력을 아끼지 말아야 합니다. 또한 개발자 커뮤니티나 스터디, 세미나 등을 통해 지식보다 더 중요한 다양한 간접 경험을 자신의 것으로 만드는 일을 게을리 하지 말아야 합니다.


급하고도 아주 급하도다. 우선순위 0 순위의 일이었다.

다행히 우리는 SASystem Analysis에 의해 이미 정해지거나 구성된 대규모 현장이 아닌 스타트업이기에 어느 것이든 쉽게 도입하고 적응하고 선택할 수 있는 상황이었습니다. 그러나 같은 상황을 맞이하는 개발자의 태도는 이 기회를 자기계발의 행운으로 바라보는가, 업무 증가의 불운으로 바라보는가에 따라서 극명히 달랐습니다. 물론, 마감 기한이 정해져 있는 프로젝트 상황에서 새로운 언어를 도입하자거나, 새로운 기술이나 패턴, 개발 트렌드가 있으니 적용하자 주장하는 일은 없어야 하겠습니다.

한 명 한 명에게 막중한 책임이 부여되는 스타트업이라는 이유로, 첫 날부터 들은 이야기는 "바로 개발 가능하도록 PC 세팅이 끝났습니까?" 라는 질문이었습니다. 개발 PC와는 별개로, 회사의 개발팀 전체의 환경에 대한 문서는 기대할 수 없더라도, 개발을 시작하기에 앞서 환경에 대한 여러 설정, 필요한 툴의 설치 라이선스와 VCS 계정 설정, 이슈 관리 툴, 그 외 경험이 없는 Tools에 대한 각자의 학습 러닝커브는 전혀 고려되지 않고 있구나는 생각이 들었습니다.

개인의 생산성은 학습과 경험을 기준으로 어느 정도 격차가 있겠지만, 단지 익숙하다는 이유로 변화를 시도하는 일을 거부하는 완고함은 그 어떤 긍정적인 발전도 이룰 수 없다고 생각합니다. 이미 수많은 전 세계 개발자들이 사용하고 있으며, 비영어권 국가인 우리나라에도 도입해 사용되고 있는 여러 생산성 향상 툴에 대한 무관심으로 무려 14년 전에 쓰이던 툴을 쓰면서 업그레이드조차 시도하지 않는 상황이었습니다.

그로 인해 최근의 라이브러리와 호환성 문제까지 발생하는 상황에서조차 무엇이 문제인지 모르는 상황을 인식시키고 설득하는 데 에너지를 사용하고, 문제 해결에 소중한 시간을 허비하는 일도 있었습니다. 이런 일련의 일은 우선순위 결정의 문제를 만났으나 아랫돌을 빼서 윗돌을 괴는 시간 배분의 아이러니라고도 할 수 있겠습니다.

누군가는 최소한의 관심을 가지고, 회사는 분명히 IT 분야 일을 하고 있음에도 왜 컴퓨터가 힘들지 않고 사람이 힘든가라는 질문을 끊임없이 던져야 하지 않았을까 하는 생각을 해봅니다.

『자바 프로젝트 필수 유틸리티』는 2009 년에 출간된 동명의 책이 있는데, 사용하는 프로그램이나 툴은 새로운 몇 가지가 변경되거나 버전이 업그레이드되었습니다. 하지만 전체적인 Flow에 따라 소개된 단계의 설명과 필요성은 프로젝트 진행의 생산성 향상 차원에서 두 말할 필요 없이 일맥상통하며 유지가 됩니다. 혹시 기존 책을 구할 수 있다면 개인적인 바람으로는 함께 읽어보길 바랍니다. 시간이 느리게 흐르는 국내 SI 현장에서는 기존 책에서 소개된 부분을 아직 사용하는 프로젝트를 만날 수 있습니다.

아울러 CI/CD 에 대한 저자 '박재성'님의 다양한 관점과 이야기가 담겨 있습니다. 번역서와는 달리, 처음부터 국내 환경에서 쓰인 점과 이해하기 쉽도록 풀어 쓴 내용도 담겨 있습니다.

『자바 프로젝트 필수유틸리티』는 앞에 나열한 여러 문제 혹은 해결 과정을 다양하게 경험해 볼 수 있는 종합 가이드 북 같은 책입니다. 물론 각각의 단계에서 현장에서 발생할 수 있는 모든 경우의 수를 대응하지 못하는 것은 사실입니다. 이는 각 파트별로 소개된 프로그램을 전문적으로 소개하는 이미 출간되어 있는 책을 살펴보거나, 공식 사이트의 문서, FAQ 를 살펴보면 많은 정보를 습득할 수 있을 것입니다.


새로 구축 환경 구성 및 설명

이곳에는 Dev 단계의 개발자 PC, 흔히 Test 혹은 Stage라고 불리는 테스트 서버, Live나 Prod로 칭하는 실제 서비스를 담당하는 운영 서버 단계가 있었습니다. 대부분의 시스템이 이렇게 구성되어 있을 것입니다.

최근 많이 도입하는 AWS 클라우드 서비스를 도입하거나 새로운 서버를 확장할 수 없는 상황에서 주어진 조건에서 최대한 효율적으로 구성하여, 개발자가 개발에만 전념하고 반복적이고 주기적인 일은 프로그램이 해결할 수 있도록 할 생각이었습니다.


이슈 관리

우선은 가장 먼저 대체 사무실에서 누가 무엇을 어떻게 언제까지 왜 하고 있는지에 대해서 알고, 상호간에 공유할 필요가 있었기에 한 PC에 우분투 서버Ubuntu Server를 설치한 후 레드마인Redmine을 설치하였습니다.

추후 이슈 관리와 일정 관리는 뜻과 달리 기존의 관습대로 엑셀로 대체됩니다. 딱히 새로운 이슈관리 툴을 배워야 하는 필요를 못 느끼는 개발자를 설득하기 위해서는 이슈 관리 툴이 진정한 힘을 발휘하기까지의 기다림이 필요한데, 아마도 엑셀 그림과 표를 만드는 시간이 더 빠르고 중요하다고 생각하는 것 같았습니다.

여러분은 비용을 지불하며 사용하는 Jira 까지는 권장하고 요청할 수 없는 상황이라도 trac이나 redmine을 꼭 도입해서 사용해 보시길 강력히 추천합니다. 보고서 작성이 필요할 경우, 보고에 필요한 내용을 실제 운영되고 있는 DB와 이슈 관리 툴의 DB에서 SQL로 추출하여 웹이나 엑셀 문서의 그래프, 차트 등으로 자동으로 작성되는 과정을 목격하면 감탄사가 저절로 튀어 나올 것입니다.


개발 환경 구축

다음으로 개발 팀을 총괄하는 SA 역할을 하는 개발자가 없는 상황에서 기존의 누군가 설정해 놓은 환경 값을 변경 없이 사용하고 있었으며, 각 단계별 환경에서 당연하게 다르게 적용되어야 설정 값을 .properties 파일로 적용하고는 있었습니다.

하지만 새로운 개발자가 투입이 되었을 때 각각의 환경 값을 자동적으로 혹은 직관적으로 적용하여야 함에도 불구하고 빌드 경로를 찾지 못하고 컴파일 에러가 나는 문제가 발생했습니다. 개발자가 사용하는 IDE도 각자 달라 개별로 외부 Library 경로를 매번 설정하는 일도 벌어졌습니다.

문제는 메이븐 리포지토리Maven Repository에 공식적으로 등록되어 있지 않은 PG사의 자바 라이브러리 적용 문제였습니다. 이는 개발자 PC, 테스트 스테이지Test Stage, 라이브 서버Live Server가 모두 각각 다르게 설정되어 있었습니다. 우선 개발자 PC에 각자 사용하는 IDE에 맞게 설정하면 될 일이었지만, 특정 경로에 라이브러리를 위치시키고 어떤 경로에서 실행이 되던 해당 Library를 참조 및 적용할 수 있도록 바꾸어 놓았습니다. 혹시 배포 시 Profiling 설정을 누락시킬 경우를 대비해서 default를 설정하는 것도 잊지 않았습니다. 사람은 누구나 실수를 하기 마련입니다.

추가적으로 개발 서버나 운영 서버와는 별개로 개발자의 PC에서 빠른 개발을 위한 다양한 임시적 상황 설정과 실제 동작을 테스트하는 환경 등에 대한 대응으로는 빌드 툴인 메이븐이나 그래들의 프로파일링이 아닌, 스프링Spring에서 제공하는 자체 프로파일링 기능을 이용해도 편리합니다. 대부분의 IDE는 이를 위한 간단한 실행 방법과 단축키를 제공하고 있습니다.


정적 분석 툴

다음 세 번째는 개발자 PC에서 개발 중에도 수시로 소스 품질과 최소한의 검증을 확인해 볼 수 있는 정적 분석 툴 PMD 중 하나인 Sonarqube 플러그인을 설치했습니다. 그러나 이는 회사에서 제공해 준 개발자들의 PC 성능과 메모리 용량의 한계를 곧 깨닫고 곧 바로 포기할 수 밖에 없었습니다. Findbug로 더 잘 알려져 있는 이러한 분석 툴은 초급부터 고급 개발자까지 반드시 개발자 로컬 개발환경에 설치하여 수시로 체크하며 코드를 개선해 나가는 노력이 필요합니다. 어느 날 갑자기 화려하고 완벽한 코드가 저절로 쓰일 수 없습니다. 물론 책에서 설명되어 있는 것처럼 배포 단계에서 검증 단계를 포함시킬 수도 있습니다.


그림 2 개선된 시스템 구성도


자동 배포

마지막으로 개발자가 빌드/배포를 요청하는 URL을 호출하면 그 즉시 젠킨스가 동작하면서 Git, SVN에 현재까지 작업되고 정상 커밋된 내용을 바탕으로 각각의 서버의 적합한 위치에 자동으로 배포가 되도록  작업하였습니다. 각 서버에 떠 있는 여러 WAS 인스턴스를 모두 조사하였으며, 젠킨스의 자동으로 배포기능을 활용함으로써 기존에 FTP로 일일이 경로를 찾아 들어가서 수작업으로 업로드하는 방식을 더 효율적으로 바꿔 작업 시간을 단축할 수 있었습니다.


테스트

아울러 기본적인 테스트 과정이 추가되고 전체 빌드 과정에서 오류가 발생되면 해당 부분을 즉각 대응하고 바로 빌드를 할 수 있게 되면서 기존에는 무시되던 작은 오류를 눈으로 확인할 수 있었습니다. 그리고 경고문을 살펴보면서 줄여 나가는 과정을 통해 점점 안정적인 서비스 유지가 가능하게 되었습니다.

젠킨스는 서버에 사용자의 프로그램을 즉각 배포하고 그 결과를 리포팅하는 기능도 강력하지만, 무엇보다 젠킨스를 젠킨스답게 만드는 일은 그 모든 과정에서 사용자가 아주 쉬운 방법으로 모든 설정을 할 수 있다는 것입니다. 파일을 복사한다거나, 외부 서버에 접속한다거나, 테스트/배포 결과 리포트를 보내거나 저장하거나, 외부 소스 저장소의 소스를 바로 빌드한 후 배포하는 등의 강력한 기능을 제공합니다.


소통

하지만 이러한 편리함을 누리기 위해서는 누구든 작업 후에 바로 빌드와 테스트, 배포가 가능하다고 믿을 수 있는 상호 신뢰가 밑바탕이 되어야 합니다. 그를 위해서 VCS 의 브랜치 정책과 개발자 간의 원활한 소통과 믿음이 보장되어야 합니다.

소통을 위한 다양한 방법으로는 칸반 보드를 통한 개인적 이슈관리를 겸 할 수 있는 트렐로, 팀원 간 소통을 위한 슬랙Slack 같은 메신저 서비스, 잔디나 라인웍스, 최근 무료로 공개된 MS 사의 Teams 등 협업을 돕는 다양한 소통 도구가 있습니다.

심지어 개인 혹은 여러 개발자가 웹 브라우저 하나만 있으면, 동시 접속 후 개발 화면을 보며 작업할 수 있는 클라우드 코딩 서비스도 속속 소개되며 협업이나 역량 테스트에 활용되고 있습니다.

더 자세한 내용은 이번 글의 범위를 벗어나니 관심이 있는 개발자는 검색을 통해 관련 정보를 얻기를 바랍니다. 두 번 바랍니다. 반드시 찾아보기를 바랍니다. 적어도, “그럼, 네이트온으로 해요?”라며 되묻는 말은 이제는 다시 듣고 싶지 않습니다.

 

새 개발 환경의 이점

그렇다면 이 모든 내용들이 대체 왜 해야 하는 것이며, 개발자는 왜 시간을 내어 배워야 하는가 궁금해집니다. 실제 발생한 상황을 바탕으로 풀어볼까 합니다. 회사의 시스템에서 우려되는 부분은 실제로 운영되는 모든 데이터가 담긴 DB 서버가 물리적으로 1개만 존재한다는 점이었습니다. 그러나 어느 날 사고는 정작 다른 부분에서 발생했습니다.

2018년 7월 초 개발자라면 결코 겪고 싶지 않은 일이 벌어지고 말았습니다. Github 서버 중 일부에서 장애가 발생했습니다. 이때, 회사의 서비스가 제대로 동작하지 않고 중단되고 말았습니다. 급하게 원인분석을 한 결과 특정 JS 라이브러리의 include URL 을 github에서 직접 가져다 쓴 것 입니다. 어느 부분에서 문제가 발생했는지에 대한 경험이 있다면, 두 번 실수를 방지하기 위해 분석 도구인 Sonarqube 툴에 해당 부분을 등록하여 배포 전에 찾아냄으로써 개발자가 미처 인지하지 못한 부분을 찾아 주는 것이 좋습니다.

아울러 문제를 찾은 즉시 수정하고 원 클릭으로 바로 배포할 수 있는 자동화 툴을 도입해 두고도, 미처 제때 반영하지 못한 누적된 임시 변경된 파일에 의해 버전 관리가 잘 되지 않아 즉각 대응을 하지 못한 상황이 벌어졌습니다. 의도 여부는 알 수 없으나 트래픽 절감을 위해 외부에 공개되어 있는 스크립트의 URL을 가져다 사용한 것이었다면, 향후 직접 서버에 배치하거나 더 안정적인 CDN을 이용하여 이러한 사고에 대비하고 바로 서비스를 제공할 수 있어야 합니다.

원인을 알아낸 순간 프로그램을 수정하고, Push하면 그와 동시에 젠킨스가 작동하여 직접 배포까지 자동으로 끝내는 것이 완벽하게 준비가 되어 있었다면 1시간 가까이 서비스가 중단되는 일은 없었을 텐데 하는 아쉬움이 있습니다.

 

모르면 두렵고, 알면 지겹다.

한 스타트업에서 일을 하며 겪었던 CI/CD 도입 경험을 글로 풀어보니, 생산성 향상을 위해 활용해야 하는 것들을 어떻게 사용해야 하는가에 대한 글보다는, 그것이 왜 필요한가? 라고 묻는 이들을 상대하며 어떻게 설득하는지 혹은 그냥 포기해야 하는지에 대한 글이 되고 말았습니다. 하지만 여기까지 읽은 독자라면 이제는 스스로에게 익숙하지 않은 것들에 대한 관심과 학습이 뒤따를 것이라고 믿고, 그것이 학습 과정에 의한 잠깐의 고통보다 더 큰 편익을 선물해 줄 것이라고 믿는 개발자가 되길 바랍니다.

이러한 내용을 학습함에 있어 당장은 큰 빛을 발할 수 없을지 모르지만, 지금 누가 평가를 하거나 관심을 가져주지 않더라도 필요하다고 느끼고 깨닫게 된 것은 시간을 잠깐씩 내서 자신의 것으로 익혀 놓아야 합니다. 그러면 언젠가 위기의 순간에 어제의 내가 오늘의 나를 돕는 기분 좋은 경험을 하게 되리라 믿어 의심치 않습니다.

생산성이 높은 개발 환경을 구축으로 개발자가 웨트WET, Write Everything Twice한 코드를 드라이DRY, Don't Repeat Yourself한 코드로 만들기 위한 코드 품질 향상에 집중할 수 있게 되기를 바랍니다.

프로그래밍은 컨베이어 벨트로 상징되는 산업화 시대의 공장처럼 한정된 생산성으로 누가 더 많은 시간을 혹은 더 빠른 속도로 일을 하는가의 영역이 아닙니다. 문제를 해결하기 위한 다양한 방법을 마련하고 무엇을 먼저 해야 하는가에 대한 고민과 정확한 판단력, 경험으로 얻는 지혜를 통해 생산성을 향상시키는 데 더 큰 기여를 하는 영역이지 않을까 하는 생각을 전합니다.

그런 노력들이 모여 함께 일하는 개발 팀원들의 삶의 질을 높이고 아울러 개인의 여가를 즐기는 시간이 늘어날 수 있기를 바라며 글을 마무리 합니다.

어렵고 복잡하고 힘들고 반복되는 일은 컴퓨터가 하게 합시다.


게으를수록 적게 일한다.
아니,


적게 일하면, 게으를 권리를 얻을 수 있습니다.


   


자바 프로젝트 필수 유틸리티
쇼다 츠야노 , 전민수