개발 관련 글 보다보면 답은 docker 다라는 글을 많이 보는데
솔직히 저는 거의 써본적이 없네요 대략 개념은 알고
한때 공부도 했지만 도커로 시작해서 쿠버네틱스
fabric 아키텍쳐 막 끝이없더라구요
이제 무시하기에는 뭔가 트렌드에 뒤쳐지는것 같고
실무에서 많이 쓰는지 궁금하군요
잠시 운용해볼까 했는데 Docker 로 말아서
무슨 고래 아이콘 모양 프로그램 깔고
온라인으로 작동하는 느낌이라
그냥 거기까지 해본것 같습니다.
솔직히 그런 필요성이 없는 회사에서 혼자서 삽질하기에는 한계가 있었어요
업계마다 상황이 다르다고 봐야 할 것 같습니다. 일단 클라우드 컴퓨팅 사용빈도가 높은 곳에서는 기본기처럼 많이 사용될겁니다.
여러 확장된 개념들이 많이 언급되지만, 도커, 아니 컨테이너 기술에서 가장 핵심은 이겁니다.
소프트웨어 개발, 특히 클래스 설계에서 SOLID 원칙 이야기와 불변성 이야기를 많이 하는데, 컨테이너에서도 크게 다르지 않습니다. 한 컨테이너는 그 자체로 "한 가지 역할"만 수행하는 “불변하는” 분리된 OS 인스턴스로서 (컨테이너가 가상화 기술을 쓰건 쓰지 않건 이건 부차적인 문제입니다), 이런 OS 인스턴스를 한 컴퓨터 안에서 여러 개로, 더 나아가서는 이런 컨테이너들을 호스팅하는 서버들을 동시에 지휘 (오케스트레이션)한다는 개념을 쓰는 것이지요.
대조를 위해 VM을 이야기하면, VM도 격리라는 면에서는 비슷한 점이 있긴 하지만, VM은 상태 불변적이지 않으며, 당연히 기존의 서버 컴퓨터처럼 동시에 여러 역할을 수행할 것을 기대할 수 있어서 구성이 복잡하고 물리 서버에 준하는 복잡성을 가집니다.
이상적인 것처럼 보이지만, 관리 코스트가 많이 늘어난다는 문제도 동시에 공존합니다. 그래서 수많은 데브옵스 모니터링 툴들이 범람하는 것이기도 하고, 로그 수집을 많이 해서 이걸 가지고 AI 분석을 돌리겠다는 이야기가 나오는 것입니다.
만약 관리 코스트를 많이 들일 여력이 되지 않는다면, 굳이 컨테이너 기반 워크로드를 고집할 이유는 없습니다. 그러나 앞서 말씀드린 특성을 활용해서 "노가다"를 면할 수 있는 면도 있기 때문에, 적절한 규모의 컨테이너화는 개발 자동화에 어느 정도 도움이 되니 검토해보셔도 좋을 듯 합니다. ㅎㅎ
저도 실무에 도입할때 비슷한 경험과 좌절을 한것 같습니다.
이게 혼자서 해결할려니 만만치 않고
주변에서 괜한짓으로 일만 만든다는 시각도 힘들고
아무래도 대형화 전문화 안된 개발조직에서는 이런 체계 데브옵스
도입부터 팀원들의 이해부터 힘든것 같아요
결론은 그냥 독재 해야 한다는 생각이긴 한데
Java 진영이 부러운것이 이런 eco 시스템의 대한 공감과 필요성에 대해서
군말없이 한다는 점이긴 합니다.
대형 플랫폼 회사들이 등장하면서 하나의 솔루션, 하나의 서비스, 또는 결합된 서비스가 하나의 엔드포인트를 갖고 있거나… 이런 상황이 클라우드가 등장하면서 부터 폭발적으로 증가해서 문화가 그렇게 된 것이라고 생각합니다.
요컨대 개발인력이 충분하지 않을 때는 이런 자동화기술들은 필요가 없습니다. 커리어를 쌓고 싶고 공부 목적으로 할 수는 있지만 이런 파이프라인을 만들어갈때 장점은 분업과 전문화 영역이 가능해진다는 건데, 내가 혼자 전문화를 다하고 있으면 내가 짱짱맨이 되는것이지요. 개발자 자체가 스파게티 코드 객체가 되는 거라고 볼 수 있을 것 같습니다.
저는 개인적으로 전문 DBA와 일해본 경험을 가지게 되면서 ORM에 대한 고정관념을 상당히 깨게 되었는데요.
DBA를 만나기 전까지는 보통 영세한 기업에서 개발자가 그냥 코드를 칠줄알고 검색을 할줄 안다는 이유만으로 DB까지 몽땅시키기 때문인데, 그러다가 개발자가 DBMS도 만지고 IDE도 만지면서 관리포인트가 2개로 나뉘는 데다 Stored Processor는 버전관리도 안되어서 혼자하기엔 벅차다는 그런게 있어서 ORM을 무조건 써야한다는 주의였지만, DBA가 따로 있는 환경에 가서는 ORM은 생각도 할 필요가 없이 우수한 DBA 분께서 만들어주신 SP를 열심히 호출해서 업무를 빠르게 끝낼 수 있었습니다.
사실 이렇게하면 DB가 WAS서버가 된다고 경계하시는 분들도 많지만, DB도 우리가 개발자라서 잘 모를 수 있는데 DB도 JSON도 파싱이나 리턴이 가능하고 HTTP 호출도 할 수 있게끔 일반 서버처럼 많은 업데이트를 거쳐왔습니다.
따라서 뭐가 좋기만하고, 아키텍쳐상으로 어떻고 간에 저는 현재 상황에서 전문가가 제시하는 방향이 좋다고 생각하며, MSA나 Docker같은 걸 실무로 도입하기 위해서는 그만한 충분한 인력이 있어야한다고 생각합니다.
일반화 할 수는 당연히 없겠지만 제가 많이 봐온 부류로서, 매번 혼자는 일하는 개발자는 자신만의 고유한 소스코드 스타일로 OOP를 거의 지키지 않으며 코드 파일 하나에 자기만 알아보기 편하게 개발하는 것과 같은 이유입니다.
사실 OOP 적으로서, 일반적인 개발 지식으로서 대중화되지 않겠지만 적어도 일을 처리함에 있어서는 자신의 고유한 방식으로 빠르게 처리하는 유지보수가 좋을 수도 있습니다.
대신 우물 안에 갇히거나 그런건 다른 문제인 것 같습니다.
따라서 커리어때문에 Docker를 공부하신다면 해보시는 게 좋고 실무에 도입하신다고 하시면 경력자를 채용하셔서 좋은 가이드던, 좋지 않은 가이드던 함께 연구할 수 있는 머리(관리자)가 따로 있는게 좋다고 생각합니다.
AWS, Azure, GCP같은 Cloud를 사용하게 되면 EC2와 같은 컴퓨팅 비용이 비싸다는 것을 느끼게 됩니다.
같은 비용으로 리소스 낭비 없이 사용하려면 아무래도 컨테이너 기반으로 서비스할 수 밖에 없다는 결론이 나올겁니다.
관리 측면에서도 Kubernetes가 강조되서 그렇지, AWS의 ECS나 Azure의 App Service와 같은 관리형 서비스를 사용하면 큰 문제 없이 사용할 수 있습니다.