안녕하세요. 자율주행로봇 서버는 어떻게 구성되어있나, 주니어 개발자들의 우당탕탕 서버 개발기를 발표하게 된 안재영입니다.
저는 자율주행로봇 회사 트위니의 로봇플랫폼개발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명까지, 성장하는 팀에서 살아남기 에서 해당 내용이 나올텐데 많은 관심과 질문 부탁드립니다!
앞으로의 트위니가 기대되시나요? 기대되신다면 오늘 부스에 찾아주셔서 많은 질문과 응원 부탁드립니다!
트위니는 좋은 개발자를 상시 채용하고 있으니 많은 지원 부탁드립니다!
감사합니다!
![자율주행로봇 서버는
어떻게 구성되어 있나
안재영, 트위니
wnaldj1589@gmail.com
[GDG Daejeon]
재영님 사진 넣어주세요~
주니어 개발자들의 우당탕탕 서버 개발기](https://image.slidesharecdn.com/gdg1-220619121426-d3aca118/85/GDG-1-320.jpg)
