원문 보기
ngmsoftware.com/bbs/board.php?bo_table=study&wr_id=299
엔지엠소프트웨어
엔지엠 매크로는 복잡한 반복작업을 자동화할 수 있습니다. PC 게임, 모바일 게임을 최적으로 지원하며 모든 PC 프로그램 및 업무에 적용할 수 있습니다.
www.ngmsoftware.com
안녕하세요. 엔지엠소프트웨어입니다. 오늘 이야기할 내용은 제가 일하는 S사 프로젝트와 EES 솔루션 회사 그리고, 엔지엠소프트웨어에서 사용하고 있는 기술 스택(Tech Stack)에 대해 설명하고, 왜 이 기술들을 선택했는지에 대해 이야기 하려고 합니다. 이글에서 언급하는 내용들은 엔터프라이즈급 프로젝트 또는 소프트웨어에 적용하는거라서 중소규모 프로젝트에는 도입하기 어려운 부분이 존재합니다. 신생 회사라면 모르겠지만, 이미 사용하고 있는 관리 도구를 버리고 새로운 환경에 적응해야 하는 부담도 존재합니다.
소프트웨어 형상 관리(SCM, Software Configuration Management)
개발 및 유지보수 과정에서 발생하는 이슈와 소스 코드, 문서, 아키텍쳐, 인터페이스, 테스트, 정적 분석등등 모든 행위에 대해 형상을 만들고 이 형상에 대한 변경을 체계적으로 관리 및 제어하기 위한 시스템을 말합니다. SCM은 소프트웨어 개발에서 가장 넓은 의미의 관리 방법으로 다양한 도구들이 존재합니다. 대표적으로 원조격인 Jenkins가 있고, 이후로 체계적인 발전을 이루어 현재는 Microsoft의 TFS(Team Foundtation Server)와 Atlassian의 JIRA, Confluence가 있습니다. 요즘도 쓰고 있는지는 모르겠으나 IBM의 CC(Clear Case) / CQ (Clear Quest)도 있습니다.
소스 코드 버전 관리(SCM, Source Code Management)
보통 소스 코드 관리 또는 버전 관리 도구를 말합니다. 다양한 도구들이 존재하는데요. 요즘은 Git으로 정리가 되었습니다. 대부분의 소프트웨어 관리 도구들이 Git을 기본 탑재하고 있습니다. 이외에도 SVN(Subversion), CSV, SourceSafe가 있는데요. 아직도 SVN이나 CSV를 사용하는 곳이 있는지 잘 모르겠네요. 아무튼, DevOps 생태계에 편입하고자 한다면 Git을 권장합니다. 초기에는 버전 관리 도구로 SVN이나 CSV를 많이 사용했습니다. Git 초창기에는 도입 비용 문제(시스템 구축, 개발자 교육)로 현상태를 유지하는 회사가 많았습니다. 사실 Git을 적용하지 않는것은 버전 관리를 포기한다는 의미보다 Git으로 대변되는 DevOps 생태계 전체를 포기하는 것과 마찬가지입니다. 오픈 소스 진영의 최대 생태계인 GitHub, npm, yarn, Docker Hub, CI, CD이 Git을 기반으로 하고 있습니다. Git을 사용하지 않는다는것은 이런 기술 기반 활동들을 포기한다는 것과 동일하기 때문입니다. 개발자로 성장하기 위해 이런 시스템에 빨리 편입되는게 좋습니다.
Git 클라우드 서비스
Git은 소스 코드 관리를 위한 간단한(?) 도구일뿐입니다. 실질적으로 Git을 사용하게 되면 Git을 호스팅해주는 서비스를 선택해야 합니다. 일반적으로 검증된 Atlassian의 BitBucket을 사용합니다. 그다음 많이 사용하는 서비스는 MS의 Azure입니다. 그외에 개인적인 용도로 GitHub을 사용하고, 오픈소스인 GitLab을 직접 구축할수도 있습니다. 협업이 아닌 경우라도 로컬 커밋으로 Git을 사용하기를 권장합니다. 대부분의 Git 클라우드 서비스들이 소규모팀은 무제한 공간을 무료로 이용할 수 있도록 해줍니다. 저같은 경우에는 회사에서 Atlassian의 DevOps도구들을 사용하고, 엔지엠소프트웨어는 MS의 Azure DevOps를 사용하고 있습니다. 이전에는 리눅스 서버에 젠킨스로 CI/CD를 구축하고, Documentation과 SonarQube를 이용한 정적 분석 도구를 활용 했습니다.
구분GitHubGitLabBitBucketAzure
| 특징 |
오픈 소스 최대 허브로 대부분의 타 서비스들과 연결 |
오픈 소스 | Atlassian의 서비스들과 연결 | Microsoft의 서비스들과 연결 |
|
Public Repository |
무료 | 무료 | 무료 | 무료 |
|
Private Repository |
Free Individuals Teams Enterprise |
Free Bronze Silver Gold |
Free Standard Premium |
Free $0/user/month Up to 5 users 5 Users Over %5/user/month Test Plan $72/user/month Individual Services Azure Pipelines: Includes the free offer from |
| Self Hosted | Enterprise Plan $21/user/month |
Free | $10/up to 10 users $2500/up to 25 users $4500/up to 50 users $8300/up to 100 users $16,500/up to 250 users |
Free |
프로젝트와 회사는 BitBucket을 사용하고 있고, 엔지엠소프트웨어는 Azure를 사용중입니다. Git을 기반으로 두고 있기 때문에 크게 다른점은 없습니다. 지금까지 사용해본 도구들을 보면 서비스 비용이나 사용 방법들이 대동소이하기 때문에 변경에 대해 크게 부담은 없었습니다. 다만, 이미 구축된 시스템을 변경하는건 다른 이야기입니다. 프로젝트 또는 소프트웨어 및 팀의 규모에 맞게 선택하는게 중요합니다. 실질적으로 어떤 Git 클라우드 서비스를 선택해야 하는지는 각자 다를 수 있습니다.
지속적인 통합(CI, Continuous Integration)과 지속적인 배포(CD, Continuous Delivery)
DevOps 개발 환경과 더불어 CI/CD는 필수 사항입니다. Continuous를 "지속적"으로 해석했지만 CI 도구에서 제공하는 기능은 자동화에 가깝습니다. 개발자가 소스를 커밋하고 머지하면 서버는 자동으로 빌드하고 결과를 통보합니다. 물론, 배포도 자동으로 이루어지고 테스트 URL도 자동 통보가 되죠. 하지만, S사 프로젝트나 MES 또는 EES 솔루션과 같은 경우 CI/CD를 적용하기 어려운 부분도 존재합니다. 대용량 데이터를 핸들링하는 양산 환경에서는 아주 작은 실수도 엄청난 비용 손실을 발생시키기 때문입니다. 현재까지도 국내 최대 기업에서도 CI/CD가 도입되지 않은걸 보면 아직도 넘어야할 문제들이 많은걸로 알고 있습니다. 무료로 제공되는 서비스와 시스템을 감시할 수 있는 환경에서도 주의가 필요합니다. 회사 또는 개인적으로 사용한 경우는 Jenkins와 TFS입니다. 개발자가 소스 코드를 커밋하고 머지하면 자동으로 배포되고 릴리즈 됩니다. 이 때 빌드 머신에서 문제가 발생하거나 정상적으로 태깅한 소스로 빌드되고, 배포되면 관련자들에게 자동으로 이메일 또는 슬랙으로 메시지가 도착하게 됩니다.
이전 IBM의 CC/CQ를 사용할때는 개발자가 직접 릴리즈룸에 들어가서 서버별로 하나씩 배포해야 하는 끔찍한 경험을 했었습니다. 웹서버, 데이타베이스등등 수십대의 서버에 스위치로 들어가서 하나씩 작업하는건 상당히 번거롭고 괴로운 일입니다. 지금 S사 프로젝트도 각각의 Application Server, Database Server, Web Server에 직접 배포 해야 합니다. 서버가 한두대도 아닌데 말이죠. 그래서 CI/CD를 도입해야 한다는 것입니다. 일반적으로 CI 서버가 소스를 받고 미리 설정된 스크립트를 실행하게 됩니다. 또는 특정 위치에 bash나 Shell, PowerShell등이 함께 배포됩니다. Java나 C#의 경우에는 Build 스크립트를 사용하게 됩니다. 또한, 빌드가 정상적으로 완료되면 특정 서버 또는 FTP에 자동으로 배포하게 되고 알람을 발생시킵니다. CI/CD는 TFS 또는 BitBucket의 Pipeline이나 Jenkins를 사용합니다. 당연한 이야기겠지만, 유료 서비스들은 빌드 스크립트에 소스가 포함됩니다. Jenkins는 직접 구성해야 합니다. BitBucket은 CI Bamboo를 사용하는데 유료임에도 Jenkins나 GitLab에 비해 딱히 장점이 없습니다.
개인적으로 Jenkins를 추천하지는 않습니다. 생각보다 시스템 구축 및 환경을 갖추기가 어렵기 때문입니다. 물론, 수차례 경험이 쌓인다면 쉽게 쉽게 풀어나갈 수 있을겁니다. 스타트업이나 소호의 경우 이런 환경을 갖추는데 너무 많은 비용(시간)을 소비하는건 좋지 않습니다. 서비스 또는 제품을 만들고 출시하는데 전력을 기울여야 하기 때문입니다. 큰 회사에서 큰 프로젝트를 성공시켰던 개발자가 스타트업을 할 때 자주하는 실수가 이런 시스템을 갖추고 진행하면 더 잘 될거라는 확신이라는 것입니다. 대부분의 개발자가 이런 환경을 겪어보지 않았기 때문에 프로젝트는 지연되고, 실수로 인해 파생되는 다른 이슈들을 해결하기 위해 시간을 낭비하게 됩니다. 물론, 투자를 받아서 제대로 시작할 수 있다면 좋겠지만 이런 경우는 상당히 드물기 때문에 일단 시작하고, 천천히 준비하는게 좋습니다. 지극히 개인적인 의견이라서 반론도 있을테지만, 지금까지 경험으로 미루어볼 때 일단 코딩 한줄을 시작하는게 더 중요한거 같습니다.
사내 인프라팀을 갖춘 규모가 있는 회사라면 Jenkins와 같은 Self Hosting은 사용하지 않습니다. 위에서도 언급했지만, 작은 팀에서 어느정도 준비가 된 상태라면 적극적으로 도입해볼만 합니다. 5명 이상 되는 팀이라면 DevOps와 SonarQube의 정적 분석을 통해 많은 도움을 받을 수 있기 때문입니다. 또한, QA팀이 없다면 더 좋은 선택이 될겁니다. 대부분의 회사에서 MS 또는 Atlassian의 서비스들을 이용하면서 Jenkins와 SonarQube를 병행하고 있습니다. 그만큼 CI/CD와 Documentation 그리고 정적 분석에 요구가 많습니다. 모든 언어를 지원하는건 아니지만, 충분히 가치가 있는 활동입니다.
젠킨스에 대해 좀 더 이야기하자면 개인적으로 사용하는 도구로 상당히 강력한 성능을 보여줍니다. Java 오픈 소스로써 CI/CD에 있어서 초창기에 엄청난 발전을 이끈 장본인입니다. 실제로 젠킨스와 SonarQube(소나큐브)로 레거시 솔루션을 많이 개선했으며, 문서화도 빠르게 정리가 되었습니다. Git 클라우드 서비스 초창기에는 CI 기능이 없었습니다. 하지만, 젠킨스는 다양한 환경과 언어를 통합하고 빌드, 문서화, 정적 분석, 배포를 자동화 할 수 있었습니다. 유료 서비스를 이용하고 있음에도 여전히 많은 회사들이 젠킨스를 사용하고 있습니다. 역사가 오래된 만큼 사용 가치가 높은 플러그인도 많고, 예상하지 못한 상황에 대응할 수 있도록 커스터마이징도 가능하기 때문입니다. 하지만, 처음 시작하는 단계라면 적극 추천하지는 않습니다. 작은 팀이라면 유료 제품을 무료로 이용할 수 있는 선택지가 많기 때문입니다. 한가지 명심해야 하는 부분은 기술은 환경에 따라서 선택하는것이지 편의를 위해 선택하는건 아니라는 겁니다. 클라우드 서비스에서 제공하는 CI들은 단위 프로젝트에 초점이 맞춰져 있습니다. 프로젝트를 빌드하고 배포하는 인프라팀은 Kubernetes(쿠버네티스)등을 통해 Orchestration 기반으로 프로젝트가 아닌 인프라 자체를 배포하고 관리합니다. 인프라 단위 컨트롤에서는 젠킨스가 더 좋은 선택일겁니다.
※ 쿠버네티스: 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
언어와 프레임워크(Language & Framework)
위에서도 잠깐 언급했듯이 기획 단계에서 어떤 언어를 사용할 것인가는 무엇을 만들지에 따라서 결정됩니다. 이 부분에서 경험적으로 수차례 실패를 목격했기 때문에 기존 인력의 러닝커브를 고려하더라도 제공하는 서비스에 따라서 결정해야 한다는겁니다. 웹서비스를 제공해야 하는데 기존에 C, C++ 개발자만 있다면 익숙하고 빠르게 개발할 수 있는 C언어를 사용해야 할까요? 또는 C#의 ASP.NET을 사용해야 할까요? 예전에는 러닝커브에 소요되는 비용보다 익숙한 언어로 빠르게 개발하고 서비스를 출시하는게 더 중요했습니다. 하지만, 지금에 와서는 웹 언어들의 눈부신(?) 발전으로 인해 많은 부분에 인식이 개선되어 왔습니다. C, C++, C#, Java 개발자도 쉽게 웹에 적응할 수 있는 환경이 되었기 때문입니다. 그리고 지금 개발자들은 새로운 언어에 대해 두려움이 없고, 빠르게 새로운 언어를 습득할 수 있는 능력을 기본 탑재하고 있습니다. 아무튼, 언어가 결정되면 서비스에 최적화된 프레임워크를 선택하게 되고, 이 프레임워크를 사용할 수 있는 언어로 자동 선택되어 집니다. 대부분 언어와 프레임워크를 선택할 때 크게 고려되는 사항은 생태계입니다. 아무리 좋은 프레임워크라도 학습과 예제를 쉽게 얻을 수 있는 커뮤니티와 플러그인, 모듈, 라이브러리등등... 공유 가능한 생태계입니다.
생태계가 갖춰지지 않은 프레임워크는 오래 유지될 수 없고 선택 받을 확률이 낮아집니다. 사용자가 적으면 커뮤니티가 형성되지 못하고 결국은 시장에서 도태되는 결과를 가져옵니다. 그렇기에 대부분은 생태계가 잘 만들어져 있고, 관련 커뮤니티가 활발한 프레임워크를 선택하기 마련입니다. 이런 경우 지속적으로 업그레이드되고 새로운 환경에 유연하게 적응할 수 있는 토대를 마련할 수 있습니다. 사실, 웹은 node, typescript, angular등등으로 정리가 되가고 있는듯합니다. 서버는 java spring 또는 STS를 사용합니다. 모바일 서비스가 아닌 경우에 그렇죠. 모바일쪽은 어떻게 진행되고 있는지 잘 모르기 때문에 저도 궁금하긴 합니다. 이외에도 PHP나 JSP, ASP, ASP.NET등등... 많은 언어들이 있었으나 더이상 미래가 없어서 언급조차 안되고 있습니다. 특히 PHP와 ASP는 러닝커브가 낮은 언어라서 인기가 많았지만, 생산성이 좋은 언어는 아닙니다. 이 홈페이지도 PHP로 되어 있습니다. 특정 서비스 하나만을 위해서 사용하기에는 괜찮지만 지속적으로 확장하고 서비스를 늘려가야 한다면 노드로 전환하는게 더 좋은 판단이라고 생각합니다. 몇몇 IT 공룡들이 PHP 또는 Java를 사용하고 있지만, 이는 일부이기도 하고 더 많은 기업들이 노드로 전환하고 있습니다. 이런 추세는 가속화할 것으로 생각됩니다.
서버쪽 프레임워크는 Node(JavaScript), Spring(Java, STS), Django(Python)등등... 몇가지 선택할 수 있습니다. 기술 스택을 결정하는데 도움을 주는 [ 스택쉐어 ]에서 서버 프레임워크를 비교해보면 노드가 압도적으로 많은걸 알 수 있습니다. 회사에서 스프링을 쓰고 있긴한데... 점점 외면 받는 기술이 되어 가고 있는듯해서 안타깝습니다.
※ 2021.05.05 기준
원문 보기
댓글