SE(Software Engineering) is dead 는 틀린 말이 아니다.
딱히 변화와 혁신이 없었기 때문이다.
짧게는 최근 몇개월동안, 길게는 1년 정도를
다른 회사, 사람들은 어떻게 일하는지, 기술 트렌드는 어떤지를 파악해보고
우리 회사에 도입할 수 있는 부분은 무엇일지, 내 커리어는 어떻게 가지고 나가야할지 고민해보았다.
DevOps라는 방법론이 인기를 끌고 있고 그 속에 반드시 알아야 되는, 도입해야 되는 기술들이 있었다.
이에 대해 몇 개의 part로 나눠 글을 써본다.
Agile 방식이 trend라고 했지만 결국 우리는 적용할 수 없었고,
CI(Continuous Integration)이 기본이고 시작점이라고 했지만 그 역시도 제대로 할 수가 없었다.
최근엔 CI/CD(Continuous Delivery)를 지나 DevOps가 대세가 되었으며,
DevOps가 가능할 수 있도록 그 속엔 기술의 발전이 있었다.
바로 docker로 흔히 통하는 container기술이다.
기존에 우리는 서버를 효율적으로 사용하지 못했다.
100대 이상의 서버가 있었지만
A제품 버전1용 5대,
A제품 버전2용 5대,
A제품 버전3용 5대,
B제품 버전1용 5대,
...
식의 서로 다른 환경설정과 툴체인을 가진 환경이 필요했고 서버는 항상 모자라 보였다.
물론 가상화(VM) 기술을 활용했으나, 이 문제를 해결할 수는 없었다.
개발자에게 PC를 한대 더 주고 개발환경을 구성해 쓰라고 해도
다양한 환경을 모두 설정할 수는 없었다.
그러나, docker는 이 문제를 해결할 수 있다.
모든 개발환경을 각각의 dockerfile로 작성한 후
build하여 docker registry에 등록해두면 된다.
이 방법은 두 가지 관점에서 장점이 있는데,
운영자는 많은 서버를 일일이 설정해야 했는데 앞으로는 dockerfile을 작성하여 관리하면 된다는 것이다.
코드로 관리되다보니 실수할 일도 사라진다.
이것을 Infrastructure as Code 라 한다.
개발자는 여러 개발환경을 필요할 때마다 끌어다 쓸 수 있어 유연성이 증가된다.
Host OS가 어떤 것이든 상관 없이 다양한 환경을 사용할 수 있다.
예를 들어 Ubuntu가 설치된 PC가 있을 때(Don't care임),
RHEL이든 Ubuntu든 Windows든 어떤 개발환경을 바로 실행할 수 있으며 여러 개를 동시에 사용할 수도 있다.
이로써 개발, 시험, 배포(운영) 환경이 자동화, 표준화되며, 이를 활용하면 운영과 개발 모두 개선되고 속도가 빨라질 수 있다.
개발환경이 이렇게 자동화되면 다음은 빌드 자동화다.
Part 2에서 이를 다루기로 한다.
