네이버 클라우드 플랫폼에서 제공하는 120여개의 서비스들 중에 스타트업에서 사용하기에 적합한 서비스들에 대한 소개와 네이버 클라우드 플랫폼에서 참고할만한 다양한 기술 콘텐츠들을 소개 합니다 | Among the 120 services provided by Naver Cloud platform, we introduce the services suitable for use by a startup and introduce various technical contents that can be found in Naver Cloud platform.
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSAVMware Tanzu Korea
최근 IT 시장은 ‘클라우드 네이티브’ 라는 컨셉을 적극적으로 받아들이면서 혁신의 속도를 높이기 위해 여러가지 노력을 기울이고 있습니다. 본 세션에서는 ‘클라우드 네이티브’ 를 이루는 4가지 요소인 DevOps, CICD, Container, MSA 를 간략하게 살펴보고 MSA 가 나머지 클라우드 네이티브 3 요소와 어떻게 상호작용하여 고객 여러분의 비즈니스에 도움이 되는지 알아봅니다. 그리고 MSA 로 이행하기 위한 조직면에서의 요건과 기술 면에서의 요건을 살펴봅니다.
한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
네이버 클라우드 플랫폼에서 제공하는 120여개의 서비스들 중에 스타트업에서 사용하기에 적합한 서비스들에 대한 소개와 네이버 클라우드 플랫폼에서 참고할만한 다양한 기술 콘텐츠들을 소개 합니다 | Among the 120 services provided by Naver Cloud platform, we introduce the services suitable for use by a startup and introduce various technical contents that can be found in Naver Cloud platform.
클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 - DevOps, CI/CD, Container, 그리고 MSAVMware Tanzu Korea
최근 IT 시장은 ‘클라우드 네이티브’ 라는 컨셉을 적극적으로 받아들이면서 혁신의 속도를 높이기 위해 여러가지 노력을 기울이고 있습니다. 본 세션에서는 ‘클라우드 네이티브’ 를 이루는 4가지 요소인 DevOps, CICD, Container, MSA 를 간략하게 살펴보고 MSA 가 나머지 클라우드 네이티브 3 요소와 어떻게 상호작용하여 고객 여러분의 비즈니스에 도움이 되는지 알아봅니다. 그리고 MSA 로 이행하기 위한 조직면에서의 요건과 기술 면에서의 요건을 살펴봅니다.
한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
저번 시간에 CI/CD에 대해서 간단하게 공부해봤으니 이번에는 툴 하나를 정해서 사용해보려고 합니다.
Jenkins, AWS Codepipeline 등 유명한 CI/CD 툴이 많지만 이번에는 github action을 사용해보려고 해요!
전세계적으로 많이 사용되는 github에서 지원하는 CI/CD 기능으로 진행 중인 프로젝트에 아주 간단하게 적용할 수 있는데 같이 공부해봐요!
안녕하세요. 자율주행로봇 서버는 어떻게 구성되어있나, 주니어 개발자들의 우당탕탕 서버 개발기를 발표하게 된 안재영입니다.
저는 자율주행로봇 회사 트위니의 로봇플랫폼개발1팀에서 서버 개발을 맡고 있습니다.
자율주행로봇회사인 트위니에서는 나르고 60부터 나르고 1000, 따르고 등 다양한 형태의 자율주행로봇을 개발하고 있습니다.
그리고 자율주행로봇들을 이용하기 위한 로봇 플랫폼 TARP, 사용자에게 편리성을 제공해주는 TARAS도 개발하고 있습니다.
TARP는 Twinny Autonomous Robot Platform의 줄임말로 다양한 형태의 자율주행로봇 서비스 개발을 지원하는 자율주행 S/W 플랫폼입니다.
주요 기능으로는 로봇 자율주행, 다중 로봇 관제, 자동 업무 배정, 자동 충전 제어가 있습니다.
그리고 TARAS는 Twinny Autonomous Robot Automation Service의 줄임말로 TARP의 기능을 베이스로 다수의 로봇을 최적으로 운영하여 업무 생산성을 높이는 트위니의 자율주행로봇 기반 운송 자동화 서비스 입니다.
주요 기능으로는 모바일 앱을 통한 로봇 제어, 고객 업무에 최적화 된 UI를 제공하여 편리한 로봇 제어, 생산관리시스템 MES, 창고관리시스템 WMS 등의 타 플랫폼과의 연동을 해줍니다.
이러한 TARP, TARAS를 로봇플랫폼개발 1팀이 맡아서 개발하고 있습니다.
그러면 저희 로봇플랫폼개발 1팀의 개발기를 시작하겠습니다.
발표는 다음 순서로 준비했습니다!
첫번째로는 TARP 개발기입니다!
TARP, 팀의 프로덕트를 개발하면서 가장 중요한 것이 뭐였을까요?
프로그래밍 언어? 백킹 서비스의 종류? 플랫폼?
저는 “팀"이 가장 중요하다고 생각합니다.
“팀”에서 개발하는 제품은 팀의 구조, 성격, 역량을 따라갈 수 밖에 없습니다.
TARP도 저희 로봇플랫폼개발1팀의 변화와 성장에 맞춰가면서 새로운 모습으로 탈바꿈해나갔습니다.
정말 다양한 시도, 프로젝트 관리 툴 적용, 내부 세미나, 가 있었고, 여전히 진행 중이지만 모든 시도에는 한가지 공통점이 있습니다.
우리 스스로 답을 찾아간다는 것, 더 나은 모습을 위해서 항상 노력한다는 것입니다.
이런 트위니 로봇플랫폼개발1팀과 함께한 TARP의 성장 과정을 설명드리겠습니다.
제가 3줄 요약을 좋아해서 TARP의 개발과정을 짧게 정리해봤습니다.
TARP의 성장과정은 다음과 같습니다.
저희들의 호기심과 요구사항을 충족하는 Monolithic Server 형태의 TARP를 개발하였습니다.GraphQL, Cache Aside 패턴, WebSocket 등 처음 사용해보는 기술들이 많습니다.두려움 반, 설레임 반으로 시작한 작업이었고 로봇이 처음 움직이는 순간은 크으...
그렇게 기본적인 요구사항을 만족하게 된 TARP는 여러 PoC에 나가게 되었습니다.
이제 각 PoC마다 추가 요구사항이 들어옵니다.새롭게 추가된 기능들은 어쩔 수 없이 버그를 가지고 있었습니다.남이 짠 코드에서 발생하는 버그를 대응하는 것이 얼마나 스트레스 받는지는 다들 아실겁니다.하지만 저희들은 이 분노와 짜증을 성장의 트리거로 삼았습니다.새롭게 추가되는 기능들은 의무적으로 테스트 케이스를 작성해야 했고, CI를 도입하여 최소한의 동작을 확인한 뒤에야 서버를 배포하는 절차를 도입했습니다.그리고 배포과정에 필요한 비용도 최소화 시키기 위해서 terraform으로 aws 스택들을 관리하기 시작했습니다.우리 팀에 맞는 CI/CD 파이프라인이 완성되어가면서 눈에 보일 정도로 업무 효율이 증가하여 정말 뿌듯했습니다.
다른 한편으로는 각 기능간 독립적인 scale out을 위해서 MSA 구조를 도입했습니다.굴지의 기업들이 MSA를 적용하고 있는 이유를 몸소 체험하고 싶었고, MSA의 장단점을 분석하고 도입 시기, 적절한 도입 방법을 다 같이 논의해볼 수 있는 좋은 기회였습니다.
예를 들어서
TARP의 기능 개발에 익숙해지고 나니 “운영”이라는 아주 큰 짐이 눈에 들어오게 되었습니다.로봇이 연결이 되지 않거나, 기기 오류가 있을 때에도 가장 먼저 문의가 들어오는 곳이 서버팀입니다.우리가 작성한 코드에서 에러가 발생한 것도 아닌데 로그를 살펴보고, 문제점을 파악한 뒤 담당 부서에 라우팅해주는 것은 정말… 너무 귀찮은 작업입니다.이를 해결하기 위해서, AWS의 fully managed service들을 사용하여 backing 서비스들의 안전성과 로그 등의 유틸성을 확보했습니다.그리고 다른 팀들이 사용할 수 있는 관제툴을 배포하여 저희 팀의 부담을 덜 수 있었습니다.
TARP의 구조가 어느 정도 잡혀나가면서 TARP의 구조를 추상적인 레벨까지 확장시킬 수 있었고,
각 모듈, 컴퍼넌트들을 추상화해나가면서 필연적으로 소프트웨어 개발 원칙과 디자인 패턴을 적용시키게 되었습니다.
가장 눈에 띈 변경은 DIP의 적용이었습니다. Dependency Injection을 이용해서 비즈니스 로직과 실제 구현을 분리해나가면서
테스트 케이스 관리도 용이해지고, 서버 구조에 관한 논의도 훨씬 활발해지는 것을 경험했습니다.
코드 레벨에서 의존성과 확장성을 얻으니 플랫폼 레벨에서도 이를 추구하게 되었습니다. 기존 AWS 스택의 의존성을 해소하기 위해서 Kubernetes를 도입하게 되었습니다.
지금까지의 TARP는 배포와 운영단계가 “완벽하게” AWS 의존적이었습니다.
맨 처음 aws의 ecs 사용을 결정할 때에도 K8s가 거론되긴 했습니다. 하지만 팀의 규모와 제품의 크기에 비해 K8s의 높은 러닝 커브 때문에 실효성이 떨어질 것이라고 판단하여 보류했었습니다. 이제 K8s의 도입이 필요해졌다는 사실에 우리가 많이 성장했다는 것을 피부로 느낄 수 있었습니다.
다음은 TARAS 개발기 입니다.
TARAS 개발기도 발표에 포함될 것이라고 팀원분들께 말씀드렸을 때는
아마 다들 마음 속으로 이 질문이 떠올랐을 것 같습니다.
“TARAS 개발을 맡게 된지 얼마 되지도 않았는데 할 얘기가 있나요?”
정확히는 기존 TARAS가 erlang으로 개발되고 있어서 python으로 재개발하는 프로젝트를 진행하고 있습니다.
순탄할 줄만 알았던 재개발 프로젝트도 여러 난관에 부딪히고 있는데 팀원 분들과 같이 문제점을 파악하고 개선해나가는 과정은 정말 다른 곳에서는 겪어볼 수 없는 값진 경험인 것 같습니다.
지금 겪고 있는 문제들과 시도하려는 해결책들을 간단하게 설명해드리겠습니다.
- python 비동기 이슈 -> 컴퍼넌트의 분리
- stateful한 서버 -> 이벤트 소싱
- Web Framework와의 강한 의존성 -> 서버 레이어의 분리
지금은 아시겠지만 트위니 로봇플랫폼개발 1팀은 현재에 안주하지 않고 자기주도적이고 항상 발전하는 모습을 지향합니다.
클린 코더를 향한 목표
- 소프트웨어 디자인 패턴에 능숙해지기
- 끊임없이 새로운 기술을 공부하기
- 틀에 갇히지 말고 유연한 사고력 키우기
- 실패를 두려워하지 않기
클린 코드를 향한 목표
- 지속 가능한 개발
- 확장성
- 유지보수성
시작할 때
질문 있으실까요?
저희 팀은 TARP를 개발하면서 단순히 소프트웨어적인 문제 뿐만 아니라
팀이 커져가면서 겪는 성장통도 저희의 큰 고민거리였습니다.
다음으로 문형철님이 발표하는 2명에서 13명까지, 성장하는 팀에서 살아남기 에서 해당 내용이 나올텐데 많은 관심과 질문 부탁드립니다!
앞으로의 트위니가 기대되시나요? 기대되신다면 오늘 부스에 찾아주셔서 많은 질문과 응원 부탁드립니다!
트위니는 좋은 개발자를 상시 채용하고 있으니 많은 지원 부탁드립니다!
감사합니다!