2021 공개SW 개발자대회 회고
개요
7월 초부터 11월 초까지 4개월 동안 진행한 공개SW 개발자대회가 드디어 마무리되었다.
생각보다 프로젝트가 길기도 했고, 없는 시간들을 쪼개가며 열심히 달려왔던 것 같아서 돌아보며 회고를 해보려고 한다.
(너무 값진 경험이었고 다른 분들께 공유해 보고 싶은 글이라 편하게 읽어주셨으면 합니다 ^^)
대회 참여
공개SW에 관심있는 국민 누구나?? 나 말하는 건가?
2021, 6월이 마무리되던 때, 과학기술정보통신부에서 주최하는 공개SW 개발자대회의 참가 신청을 받는다는 것을 학교 동기를 통해 알게 되었다. 이때는 여름방학 기간이라서 시간도 많았고 다음 학기가 시작하기 전에 출품을 할 수 있을 것 같았다. 그리고 무엇보다 새로운 프로젝트를 너무 개발하고 싶었다..ㅎㅎ (넘쳐흐르는 개발 욕구)
따라서 평소 프로젝트를 함께 진행해 보고 싶었던 두 사람과 함께 팀을 이루게 되었고 자유 주제를 목표로 프로젝트를 시작하게 되었다.
대회 진행
7월 초 대회 준비를 시작하게 되었고 출품 마감까지 두 달 가량의 시간이 있었다.
프로젝트 주제
공개 SW.. 근데 뭘 만들지?
먼저, 3인으로 구성된 우리 팀은 각자 공부하는 분야가 완전히 달랐다. (각각 백엔드, 안드로이드, 인공지능)
따라서 프로젝트의 주제를 정하기 전에 아래와 같은 필요 요건들을 추려보았다.
- 안드로이드, 백엔드, 인공지능으로 파트를 나누어 각각 개발 -> 하나의 서비스로 통합
- 공개SW 대회 목적에 맞는 오픈 소스 프로젝트를 개발
- 창의적인, 혁신적인 프로젝트이지만 반드시 구현이 가능해야 함
팀원 모두의 역량을 최대로 이끌어내기 위해 각자 자신 있는 분야를 하는 것이 중요하다고 생각했고 이들을 연결하는 것은 하나의 도전일 뿐 절대 불가능하다고 생각하지 않았다. 그다음에는 팀원들과 머리를 맞대고 주제를 생각해 보았다. 힘든 고민을 한 결과 미디어 파이프를 이용해 손 제스처를 인식한 뒤 동일한 제스처를 매칭 시키는 알고리즘을 개발하고 그 알고리즘을 이용하는 채팅 애플리케이션을 제작하는 것으로 결정을 내리게 되었다.
- 대략적인 애플리케이션 흐름
- 안드로이드 애플리케이션을 통해 손 제스처를 캡처 후 서버로 전송
- 제스처 매칭 알고리즘을 통해 동일한 손 제스처들을 군집화하여 매칭을 수행
- 매칭에 성공한 클라이언트들에게 채팅방을 생성(웹소켓으로 구현)
백엔드 개발
- 백엔드 개발은 생각보다 쉽지 않았다!
구현에 대한 고민이 정말 많았다. 채팅 서버는 어떻게 구현할 것인지, 채팅 데이터는 어떻게 관리할 것인지, 동시성에 대한 고민, 디비에 대한 고민, 매칭 알고리즘을 어떻게 연계할 것인지, 어떤 인프라를 사용하고 장애 처리는 어떻게 할지, HA 구현 방법, 협업이 용이하도록 서버를 구성하는 방법 등등.. 평소 이론 및 실습을 통한 공부에서는 절대로 경험해 볼 수 없는 부분이었고 지금 와서 돌이켜보면 내 스스로 성장할 수 있는 정말 좋은 기회였던 것 같다.
채팅 서버
기본적으로 애플리케이션과는 REST API로 호출할 생각을 가지고 있었고 큰 어려움이 없었다.
하지만 가장 먼저 고민한 것은 백엔드의 채팅 서버를 구현하는 것이었는데 롱 폴링을 사용할지, 웹소켓을 사용할지 이었다. 롱 폴링의 경우 HTTP Request/Response 만 생각하면 되겠다고 생각했지만 비교적 무겁고 효율성을 놓고 보았을 때 공개SW 대회의 성격과 맞지 않다고 판단했다. 웹소켓의 경우 매우 가벼웠고 관련 기술에 관심이 있었기 때문에 웹소켓을 통해 구현하기로 결정하게 되었다.
MSA
이번 대회를 진행하기 전에 나는 Spring Cloud에 대해 공부하고 있었다. MSA에 대해 알게 된 지도 얼마 안 되었고 간단한 토이 프로젝트 정도의 경험밖에 없었기 때문에 이번에 MSA를 통해 프로젝트를 구현해 보고자 하는 욕심이 있었다.
하지만 프로젝트에서는 AWS EC2 프리 티어 인스턴스를 사용하고 있었고 컴퓨팅 파워가 부족하기 때문에 리소스에 대한 걱정이 항상 있었다. 때문에 모놀리식 구조로도 충분히 구현할 수 있지 않을까? 라고 고민했었지만 매칭 알고리즘이 Mediapipe, Tensorflow와 같은 인공지능 라이브러리들을 필요로 했기 때문에 모든 서버를 자바 스프링으로 구현할 수 없었다. 따라서 Spring eureka server를 토대로 하여 파이썬에서 유레카 클라이언트로 접속할 수 있도록 MSA 아키텍처를 선택하게 되었다. 하지만 이로 인해서 프로젝트를 개발하는 동안 여러 번의 리소스 문제를 겪게 된다..ㅠㅠㅠ
이와 연계하여 메시지 브로커는 RabbitMQ를 사용했다. 먼저 각각의 서비스들의 분리된 configuration을 외부에서 한 번에 모아서 관리할 필요가 있었고 여기서 RabbitMQ, Kafka, AWS SQS와 같은 서드파티 및 클라우드 서비스들을 이용할 수 있었다. 하지만 Kafka의 경우 초당 10만 건의 데이터를 다루는 대용량 이벤트에 적합한 솔루션이었고 SQS의 경우 프리 티어로 이용할 수 있었지만 클라우드 서비스에 종속적이고 싶지 않았다. 마찬가지로 RabbitMQ는 비교적 적은 양의 서비스 내부 통신에 적합했고 메시지 브로커이지만 pub/sub 또한 지원하고 있었기 때문에 선택하게 되었다.
Trouble-Shooting
그 외에도 개발 중에 여러 가지 문제들을 겪고, 해결하면서 짧은 글들을 작성했었다.
두 달동안 팀을 이끌어 가면서 체계적으로 개발하는 것에 큰 초점을 두었고, 계획한 출품 일정에 맞추어 프로젝트를 완성할 수 있었다.
- 백엔드 서버 구성
본선 진출
1차 평가에 통과하여 본선에 진출하게 되었다!
1차 평가 이후 대회 프로세스는 멘토링, 기능 테스트, 라이선스 검증, 최종 발표로 진행되며 대회가 마무리된다.
멘토링
본선에 진출한 이후 각 팀마다 실무자가 직접 맞춤형 멘토링을 진행하면서 출품작을 보완하는 시간이 주어졌다. 대회의 특성상 프로젝트의 분야가 매우 다양하기 때문에 각 팀마다 맞춤형 멘토링을 위해 설문을 받았었다. 우리 팀의 경우 상의를 해본 결과 인공지능과 모바일 관련 멘토링을 신청하게 되었는데 실제로는 백엔드 실무자분께서 멘토로 매칭이 되어서 조금 놀랐었다.
하지만 내 입장에서는 백엔드 개발자분께서 직접 멘토링을 받을 수 있는 정말 좋은 기회가 생기게 된 것이라 너무 기쁘기도 했고 코드에 부족한 점들이 많을 것 같아 걱정이 되기도 했었다.
멘토님과는 주 1~2회 정도 비대면으로 멘토링을 진행했으며 멘토님께서 모바일, 인공지능 분야에 대해서는 많은 도움을 주지 못할 것 같다고 하셨지만 모바일, 인공지능 관련 멘토링에서도 엄청난 도움이 되었었다.(전문 분야가 아닌 지식에도 실무자분들은 이 정도로 알고 계시구나.. 라는 것에 또 놀랐다)
백엔드 멘토링은 멘토님께서 제가 구현한 백엔드 서버에 대해 들어보신 후에 함께 인프라에 대해 고민해 보는 시간을 가지기도 했고 실제 백엔드 및 채팅 서버가 실무에서 어떻게 구현되고, 어떻게 서비스되고 있는지 실무자의 경험들을 들을 수 있어 너무 값진 경험이었다. 추가적으로 백엔드에만 치중하지 않고 개발자의 측면에서도 여러 조언들을 주셔서 너무 고마웠다. 멘토님 덕분에 고민해 보지 못했던 부분에 대해 생각해 볼 수 있었고 문제에 대해 함께 고민해 보는 시간이 너무너무 좋았던 것 같다.(만약 이런 기회를 얻고 싶다면 공개SW 개발자대회에 꼭 참가해 보라고 말해주고 싶다!)
라이선스 검증 및 기능 테스트
멘토링이 종료된 후 출품작에 라이선스 문제는 없는지, 프로젝트의 기능은 모두 정상적으로 동작하는지 검사를 하게 된다.
- 라이선스 검증
라이선스 검증의 경우 오픈소스의 특성상 사용한 모든 라이브러리에 대해 라이선스 충돌이 있지는 않은지, 내가 정상적인 라이선스를 명시하였는지 등등 라이선스 규정을 위반하지 않았는지를 검증했다. 먼저 라이선스에 대해 간단하게만 알고 있었지만 이번에 교육을 듣게 되면서 오픈소스 라이브러리가 생각보다는 복잡한 것을 알게 되었고 내가 프로젝트에서 사용한 라이브러리의 라이선스를 하나하나 찾아보게 되었다. 큰 문제가 있지는 않아서 프로젝트에 영향을 주지는 않았지만 오픈소스가 말 그대로 오픈소스이지는 않으니 조심해야 겠다고 생각했다 ㅎㅎ; (MariaDB 커넥터의 경우 LGPL 2.1이다 ..!)
- 기능 테스트
기능 테스트를 진행하기로 한 날 당일에 백엔드 서버에서 에러가 난 것을 확인하였고 이를 해결하기 위해 실례를 무릅쓰고 테스트 일정을 연기하게 되었다.. 문제점을 테스트 당일에 알게 되어 너무 당황했고 빠르게 해결할 것이라 예상했지만 그렇게 하지 못했었다. 내가 부족해서 발생한 문제였기 때문에 팀원들에게 너무 미안했고 여기서 페널티를 받게 될까 봐 정말 걱정이 많았다. 그리고 평소 백엔드 개발을 할 때 worst case에 대해 항상 고민한다고 생각했는데, 정말 사소한 실수를 키우게 된 것 같아서 나를 다시 돌아보게 되었다.. 다행히도 기능 테스트를 마무리할 수 있었지만 절대 잊지 못할 것 같다.
최종 발표
최종 발표는 15분 동안 진행했으며 비대면으로 진행되었다. 심사위원분들이 여러 질문을 주셨는데 우리 팀의 프로젝트가 오픈소스로 어떻게 발전할 수 있을지? 어떤 곳에 기여할 수 있을지 와 같은 것에 초점을 둔 것 같았다. 7월부터 시작해서 4개월 동안의 대장정이 드디어 막을 내리게 되었다.
결과
이번 대회를 참여할 때도 수상 여부와 관계없이 경험을 해보자는 취지로 참가한 대회였었는데, 은상을 받게 되어서 팀원들 모두 놀랐다!
좋은 결과를 얻어서 4개월 동안 시간을 투자한 보람을 느낄수 있었다. 팀원들 모두 고생했다~
마치며
역시 이론과 실습은 다르다. 나는 나 자신이 야생형 개발자라고 생각하는데 이번 기회로 부딪혀보면서 정말 많이 성장한 것 같다. 하지만 지금 생각해 보면 아쉬웠던 점들이 있기도 하다.
가장 먼저, 백엔드 서버에 부하 테스트를 적용하지 못했다. 출품작을 보완할 때 서버의 고가용성을 위해 HA 까지 구현을 했지만 이에 연관하여 부하 테스트를 해보고 테스트 결과를 토대로 더욱더 개선할 필요가 있었지만 그렇게 하지 못한 것이 너무 아쉬웠다. 이번 프로젝트에서 무엇보다 기능에 대해 중점을 두다 보니, 서비스의 안전성에 대해 놓친 게 아닌가 하는 생각이 든다.
두 번째로, 어떤 기술, 인프라, 라이브러리 및 모듈을 붙이는 경우 납득할 수 있는 이유가 있어야 한다. 프로젝트 개발 시간에 많은 부분을 차지한 것이 리소스 최적화 부분이었다. AWS EC2 프리 티어를 사용하다 보니 MSA 에서 대부분 리소스가 부족했다. 실제 CI/CD는 각각의 도커 이미지를 docker-compose를 통해 배포하게 되는데 한 번에 모든 서비스를 연속으로 배포하는 경우 EC2 인스턴스가 100% 다운되었다. 따라서 사용하는 라이브러리가 꼭 필요한지? 필요 이상의 리소스를 낭비하지는 않는지? 대안은 없는지? 등 고민이 필수라는 것을 느꼈다. MSA 를 위해 유레카 서버를 붙였지만 이를 완벽하게 사용하지 못했다고 생각한다. 라이브러리를 적용하기 전에 야생형처럼 부딪히는 것도 좋지만 때로는 기술에 대해 선행되는 지식이 필요한 경우가 많다는 것을 느꼈다.
마지막으로, 아직 많이 부족한 개발자라는 것을 느꼈다. 프로젝트의 팀장으로서, 백엔드 파트 담당으로서, 대회가 잘 마무리되었지만 내 스스로 만족하지 못하는 부분들이 많았다. 더욱더 성장하려면 더욱더 시간을 투자해야 한다고 생각한다. 아직 관련 인프라에도 관심이 많고 백엔드 공부도 하고 있는 상황이기 때문에 앞으로도 열심히 달려볼 예정이다.
댓글남기기