Home Goodbye, 2023! Welcome, 2024! - [2023년 개발 회고]
Post
Cancel

Goodbye, 2023! Welcome, 2024! - [2023년 개발 회고]

2024년을 맞이하며

눈 깜짝할 사이에 2023년이 끝났다. 2023년은 여러 이벤트가 겹치면서 다양한 경험을 할 수 있었다. 사용하는 기술 스택에 대한 이해가 이전보다 나아졌고 무엇보다도 확실한 협업 경험을 통해 협업 능력이 높아진 부분에 대해서 상당히 만족하는 한 해였던 것 같다.

이런 소중한 경험들을 머릿속에 두었다간 금방 잊힐 게 눈에 보여서 블로그 글로 23년의 경험들을 정리하고자 한다. 그리고 이왕 회고 글 작성을 시작한 김에 2023년을 시작으로 계속해서 1년 단위 회고를 작성하고자 한다. 해마다 계속해서 쌓이는 회고들을 보면서 내 성장 과정을 확인한다면 뭐라도 느끼는 게 있지 않을까 싶어서다.

이 글이 나중에 뭐 어떤 식으로든 도움이 되길 바라며 이야기를 시작하겠다.

1
2
3
4
5
6
목차
1. 팀 리더로서 첫 프로젝트
2. GDSC, 2년의 마침표
3. 해커톤 최우수상
4. 2023 총정리
5. 2024 목표

첫 번째 이야기 - 팀 리더로서 첫 프로젝트

첫 프로젝트 리더

2023년 3월부터 6월까지는 대학교에 다닌 시기다. 4학년 1학기였고 졸업 필수조건인 캡스톤 강의를 수강해야 했다. 캡스톤은 학교에 협력하는 여러 기업에서 필요로 하는 기능이나 서비스를 강의를 수강하는 학생들이 팀을 이루어 개발하는 졸업 프로젝트다. 그래서 캡스톤을 수강한 학생이라면 최소한 한 번의 프로젝트 경험을 얻게 된다.

나는 대학교 개강 전에 미리 연락을 돌려 캡스톤 팀원을 모으고자 했는데 당시에 활동하고 있던 개발 커뮤니티에서 합을 맞춰본 지인을 섭외하는 데 성공했다. 그리고 나머지 두 자리는 내가 섭외했던 지인이 두 명을 데리고 왔다. 팀원은 총 4명이고 나는 모바일 개발, 한 명은 웹 개발, 나머지 두 명은 서버 개발을 맡았다.

팀 구성이 끝나고 여러 기업이 요구하는 과제를 둘러봤는데 우리 팀 구성에 맞는 프로젝트가 딱 한 개 있었다. 반려동물 케어 서비스를 요구하는 프로젝트였다. 모바일, 웹, 서버 개발이 모두 가능했기에 주저 없이 해당 프로젝트를 선택했다.

팀도 구성했고 프로젝트 선택도 끝났으니 마지막으로 팀장을 뽑는 시간을 가졌다. 팀원 모집할 때 내가 섭외했던 지인을 포함해서 나머지 팀원들에게 혹시 팀장을 맡을 의향이 있는지 물어봤는데 원하지 않는 눈치였다. 그래서 마침 팀장으로서의 포지션도 경험하고 싶었던 내가 맡기로 했다.

기획

모든 준비가 끝났고 본격적으로 기획 회의에 들어갔다. 기획부터 쉽지 않았다. 시중에 서비스하는 반려동물 케어 관련 서비스들을 확인했는데 웬만한 것들은 다 있어서 어떻게 차별성을 만들지 아주 많은 고민을 했다. 그래서 2~3번의 기획 회의를 진행했고 결론은 다음과 같다.

반려인과 동반으로 여행하는 반려동물의 안전을 위해서 반려동물에 맞춘 여행지 정보 제공 및 리뷰 제공 서비스를 하기로 했다. AI 기술을 이용한 서비스 개발은 팀 구성을 봤을 때 불가능하고 짧은 시간 내에 프로젝트를 마무리해야 해서 충분히 시도해볼만한 주제를 탐색했다. 이를 고려하여 위와 같은 주제를 선택했고 유사 서비스를 벤치마킹하여 좀 더 세밀하게 정보를 제공한다는 목표로 기획을 마무리했다.

KakaoTalk_Photo_2024-01-24-23-50-00 1

KakaoTalk_Photo_2024-01-24-23-50-09 1

UI 디자인

두 번째 난관에 봉착했다. 어려웠던 기획을 끝내고 모바일 UI/UX 디자인을 시작했는데 이 부분도 굉장히 어려웠다. 시각적인 요소들을 다루는 걸 좋아해서 평소에 UI/UX 디자이너 영상을 챙겨보는 편인데 막상 영상에서 배웠던 걸 적용하려 하니까 쉽지 않았다.

그래서 강의 영상과 구글링해서 배우는 것 이외에도 야놀자, 여기어때, 토스 앱의 UI/UX를 참고했다. 카테고리 배치와 리스트와 배치 등을 참고하여 내 나름대로 디자인을 해봤다.

잘 만들어진 디자인 시스템을 이용해서 제작하는 게 좋을 것 같다고 판단하여 Material Design을 사용하기로 결정했다. 구글 디자인 시스템인 Material Design에서 제공하는 UI 컴포넌트에 최대한 맞춰서 설계하고자 했고 가능한 단순하게 구성하려고 노력을 많이 했다. 근데 막상 다 만들고 보니까 단순한데 복잡(?)한 느낌이 좀 들었다.

App Design Mockup 1

Group 175

프로그래밍

모바일 UI/UX 디자인을 마치고 본격적으로 개발을 진행했다. 이때는 서버 담당 인원들과 회의를 진행하면서 API 설계 방식에 대한 회의를 최대한 많이 진행해서 API를 연결하는 데 지장이 가지 않도록 했다. 그리고 서버 담당 인원들의 진행속도에 맞춰서 개발을 진행했다.

Android 설계 방식에 관해 얘기를 해보자면 22년 여름으로 거슬러 올라간다. 당시 여름에 처음 나갔던 해커톤에서 팀원이 설정한 프로젝트 구조를 통해 아키텍처 컴포넌트를 처음으로 경험해봤다. 당시에 ViewModel , LiveData , Coroutine 등을 몰라서 코딩하는 시간보다 해당 개념들을 이해하는 데 시간을 많이 소비했다.

또한 프로젝트를 Ui , Data 층으로 분류해서 관리하는 법도 처음 경험했다. 이전까지는 액티비티나 프래그먼트에 모든 코드를 때려박았으니 ViewViewModel 이 무엇인지, Data 층에서 Repository , DataSource 가 무엇인지 몰랐다. 이것도 최대한 이해하려고 발버둥을 쳐봤는데 결국 한 10%만 조금 이해하고 팀원이 먼저 작성한 코드를 보면서 그대로 따라 하는 식으로 어떻게든 코딩을 했다. 결국, 미완성으로 제출하고 마무리했다.


새로운 목표 - 해커톤 대회에서 사용했던 설계 방식을 스스로 1부터 100까지 해보자

해커톤 대회를 마치고 대회에서 처음 써봤던 개념들을 차근차근 학습하면서 각 개념의 역할을 이해하고자 했고 이때 새로운 목표를 세웠다. 해당 목표를 완수하기 위해서 마침 혼자서 앱 개발을 진행해야 했던 캡스톤 프로젝트로 도전했다.

결과는 성공적이었다. 해커톤 때는 팀원이 작성한 예시코드를 단순히 따라서 만드는 식으로 진행했기 때문에 코딩해도 내가 사용하는 라이브러리나 구조에 대한 이해가 전혀 안 됐다. 하지만 캡스톤 프로젝트에서는 내가 직접 프로젝트를 생성하고 세팅부터 마무리까지 하니까 이전에는 보이지 않던 이유들이 보이기 시작했던 것 같다.

덕분에 DI Retrofit ViewModel LiveData 등등.. 이런 여러 라이브러리의 역할을 이해할 수 있었다. 물론 해당 라이브러리들을 완벽하게 이해한 것은 절대 아니다. 역할과 다른 라이브러리와 연결되는 흐름 정도만 조금 이해했다고 할 수 있는 정도가 되겠다.

퀄리티를 높이기 위한 생성형 AI 적용

캡스톤 프로젝트의 가장 중요한 부분이고 가장 잘한 선택이었다고 말할 수 있다. 기존에 기획했던 목표치 개발을 무사히 완료하고 오류를 검토하는 단계로 넘어갔는데 한 가지 고민이 생겼다. “여기서 좀 더 보완하거나 강화할만한 요소가 있을까?”

그런데 서버 담당이었던 팀원이 챗 GPT API 얘기를 꺼냈다. 나는 그걸 듣고 AI 챗봇 기능을 생각했고 바로 해당 인원과 얘기를 해서 GPT API 적용이 가능한 조건의 상황인지 파악했다. 이게 적용하기만 하면 여행지 정보를 찾는 과정 자체가 굉장히 단순해져서 AI API 연결이 가능하다면 하면 무조건 추가하고 싶은 마음이 컸다.

그래서 로직 흐름 작성 및 간단한 테스트를 진행해본 결과, 충분히 적용 가능하다는 결론이 나왔다. 나는 바로 AI 챗봇 느낌으로 구현하는 계획을 진행했다. 적용 방법은 다음과 같다.

1
2
3
4
0. 서버에서 관리하는 장소 데이터들을 GPT에 제공하여 학습시키기.
1. 사용자가 질문을 입력하면 해당 질문에 대한 문자열을 서버로 전송해서 서버에서 GPT API를 호출한다. 
2. 해당 호출의 결과는 서버로 다시 전송될 것이고 서버는 이 결과를 클라이언트에 최종 전달한다. 
3. 클라이언트(Android)는 서버로부터 받은 결과물을 화면에 출력한다.


UI는 흔히 볼 수 있는 챗봇 UI 느낌으로 제작했다. 사용자가 질문을 입력하면 답변을 띄우기 전까지 프로그래스 바를 이용해서 사용자 요청이 정상적으로 처리되고 있음을 나타냈다. 프로그래스 바에 사용된 이미지 파일은 로티(Lottie)에서 가져왔다.

리사이클러 뷰를 기반으로 아이템을 동적 추가하는 방식으로 설계를 했다. 그래서 사용자가 처음에 챗봇 페이지에 들어가면 빈 공간이 나오고 질문에 대한 답변이 추가되면 위에서 아래로 쌓인다. 질문이 많아지면 스크롤을 해서 볼 수 있도록 스크롤 뷰도 추가했다.

사진에 나오는 강릉 경포해변, 라마다 호텔앤스위트, 서울남대문은 실제로 해당 앱에서 제공하는 여러 장소 중 하나다. 이런 식으로 사용자가 여러 과정 필요없이 챗봇을 이용해서 바로 요약된 답변을 받아 볼 수 있다.

Screen 3

결과

결과는 최고학점인 A+ 을 받았다. 다 팀원들이 모두 열심히 참여해준 덕이다 :)

기업 멘토님의 평가

여태 맡았던 팀 중에서 가장 잘한 팀이라는 칭찬을 받았다. 뭔가 기획한 서비스가 대단한 것도 아니고 유사 서비스를 이길 수 있는 강력한 무기가 있는 것도 아니어서 이 정도 칭찬을 들을 정돈가 싶었다. 그래도 기획한 부분을 깔끔하게 완료했고 오히려 기존 기획에서 AI챗봇을 추가한 부분에 대해서 좋게 봐주신 것 같다.

교수님들 평가

기획 관련해서 여러 질문을 해주셨다. 엄청나게 깊은 질문은 아니고 그냥 이 서비스를 기획한 이유라던가 다른 서비스와의 차이점 같은 간단한 질문이었다.

개발 관련 질문도 나왔는데 AI에 관한 내용이었다. 챗봇 기능을 위해 사용한 챗 GPT의 버전이 무엇이며 해당 기술의 정보 신뢰성에 대한 질문을 받았다. 교수님들이 봤을 때는 GPT API가 항상 우리가 원하는 답을 주는 것도 아니고 거짓된 정보도 제공할 수 있기 때문에 이에 대해서 기술적인 해결시도가 있었는지를 알고 싶어서 물어보신 것 같다.

우리 팀도 이 부분을 몰랐던 것은 아니다. 이를 어느 정도 해결하기 위해서는 1차로 좀 더 비싸고 성능 좋은 GPT API를 사용해야 한다. 그리고 2차는 우리가 기술적으로 설계를 탄탄하게 해서 사용자에게 신뢰성 있는 정보를 제공하는 것이다. 하지만 우리에겐 돈도 많이 없었고 챗봇 기능을 거의 캡스톤 막바지에 추가했기 때문에 기능을 리뷰할 시간도 많이 없었다. 그래서 교수님들의 질문에 대해선 이 부분을 솔직하게 말씀드렸다.

프로젝트를 마무리하며 좋았던 점

우선 팀장으로서 팀원들을 이끌고 프로젝트를 하는 경험은 처음이었는데 팀원으로서 프로젝트에 참여했을 때와는 다르게 신경써야 하는 범위가 매우 컸다. 팀장이라 직접 노션에 협업 페이지를 만들고 회의, 팀원 케어, 보고서 작성, 일정 조율을 주도적으로 했는데 협업 능력치가 이전보다 성장한 것 같아서 이 부분에 대해선 굉장히 만족한다.

그리고 서비스 기획부터 완성 발표까지 처음과 끝을 다 경험해서 나중에 기획자와 디자이너의 협업 기회가 생기면 잘할 수 있겠다는 자신감이 생겼다. 기획과 디자인의 고충을 이번 프로젝트로 뼈저리게 느꼈다…

마지막으로 팀 분위기가 처음부터 끝까지 열정적이어서 매우 좋았다. 같이 으쌰으쌰하는 분위기라 나도 열심히 참여했고 다른 팀원들도 열심히 참여했다. 팀장으로서 팀 분위기를 좋게 하려고 연예인 매니저 빙의해서 케어를 했는데 팀원들이 잘 받아주고 잘 참여해줘서 너무나도 고마웠다.

프로젝트를 마무리하며 아쉬웠던 점

챗봇 AI 기능을 개선할 시간이 부족했던 게 너무 아쉬웠다. 프로젝트 막바지에 챗봇 기능을 추가해서 뭔가 개선할 수 있는 시간이 좀 부족했던 것 같다. AI 기술을 처음 다뤄서 굉장히 재밌게 개발했는데 나중에 AI 기술을 다뤄볼 기회가 또 생기면 그때는 제대로 만들어보고 싶다.

또 다른 아쉬운 점은 기업이랑 협력해서 과제를 수행하는 방식인데 우리 팀은 기업으로부터 도움을 받은 게 별로 없었다는 것이다. 초반 기획에는 화상회의를 통해서 기획에 대한 여러 피드백을 받을 수 있어서 좋았다. 하지만 멘토로 참여했던 기업 대표이사님이 기획자 위치라 기획이 완료된 이후의 과정에서는 우리끼리 모든 걸 정하고 진행할 수밖에 없었다.

UI/UX, 기술적인 설계에 대한 도움이 가장 필요했는데 해당 피드백은 어려울 것 같다는 답변을 받아서 우리가 직접 검토하면서 진행을 했다. 만드는 건 문제가 되지 않았지만, 문제점 없이 만들었는지에 대한 점검은 우리 수준에서 어려웠던 것 같다.

두 번째 이야기 - GDSC, 2년의 마침표

21-22 GDSC 수료 1

22-23 GDSC 수료 1

21년에 합격해서 시작했던 구글 학생 개발자 클럽인 GDSC 활동을 드디어 23년 6월 중순에 마무리했다. 약 2년의 기간 동안 다양한 활동들을 했었는데 나에게 정말 좋은 추억으로 남았다. 이 활동을 통해서 개발자라는 목표를 더욱 돈독히 다지게 됐으니 말이다.

시작은 군대에서 우연히 보게 된 영상으로부터

나는 원래 군대에 가기 전까지는 개발자가 되는 것을 원하지 않았다. 과는 컴퓨터공학부였지만 단순히 고등학교 성적에 맞춰서 선택해서 들어온 학과고 이 때문에 목표의식이 없는 채로 1학년을 마무리했다. 그리고는 그 상태 그대로 입대를 했다. 훈련소에서 새벽 불침번을 하면서 혼자 미래에 대한 생각을 해봤는데 뭔가 스스로 변화가 필요하다는 것을 느꼈다.

그래서 훈련소를 수료하고 자대에 가자마자 평생 해보지도 않았던 헬스를 시작했다. 제대로 해보고 싶어서 유튜브로 운동 영상을 찾아봤고 벌크업을 위해서 식사량을 엄청나게 늘렸다. 그 결과, 말랐던 몸이 건강한 근육질로 바뀌었고 특급전사까지 달성하는 쾌거를 이루었다. 아마 이때를 기점으로 새로운 것에 도전하고 성취하고자 하는 가치관이 만들어진 것 같다.

이때 이후로 군대에서 할 수 있는 여러 큰 도전을 해본 것 같다. 평생 남들 밑에서 조용히 지내던 내가 팀의 리더인 분대장을 자원해서 팀을 이끄는 일도 하고 공도 제대로 차본 적 없는 내가 족구에 도전해서 대대 족구 대회를 우승하는 경험도 했다. 내가 뭔가를 시작하면 끝을 봐야 하는 성격이라 덕분에 결과가 모두 좋게 나온 것 같다.

손을 대는 것마다 성과가 엄청나니까 진로에 대한 자신감도 생기게 되었다. 그래서 이왕 컴퓨터공학부로 입학했으니 전공을 살리기로 마음을 먹고 유튜브에 개발자 관련 영상을 찾아보기 시작했다.

그렇게 영상을 보던 중에 눈에 띄는 제목의 한 영상을 발견했다. Interactive Developer 라는 멋있는 이름이 달린 채널이었다. 디자이너와 개발자를 동시에 수행하는 구글 직원이었는데 궁금해서 그 사람이 올린 본인 포트폴리오 영상을 봤다. 미적인 영감을 프로그래밍으로 구현하는 모습을 보고 감탄을 했다. 코딩의 대단함을 이때 많이 느꼈던 것 같다.

image 1

출처 - jongmin kim blog

그리고 군대에 있던 20년도에 '하트시그널3'이라는 프로그램이 유행했다. 딱히 개인 시간에 할 게 없어서 한 번 봤는데 남자 출연자 중에서 금융 관련 스타트업에서 일하는(현재 퇴사) 개발자가 있었다. 개발자로서 어떤 사람인지 호기심에 유튜브 검색을 해봤는데 엄청난 인물이었다. 실력은 당연하고 직업 가치관이 굉장히 멋있었다. 이런 멋있는 가치관과 직업에 대한 애정에 반해서 개발자라는 직업에 좀 더 흥미를 붙이게 된 것 같다.

image 2

출처 - 아무튼 출근

image 1

출처 - eo 천인우

이를 통해 전역 후에 개발 역량을 높이는 방법을 생각해봤다. 혼자서 개발 공부를 하는 것보다는 동아리나 학회에 들어가서 잘하고 열심히 하는 사람들 밑에서 공부하는 게 성장하는 데 유리할 것 같다는 생각을 했다. 그래서 대학생 커뮤니티인 에브리타임에서 동아리나 학회 모집 공고를 챙겨보기 시작했고 거기서 GDSC 모집 글을 발견했다. 커리큘럼도 괜찮았고 구글 후원의 행사도 다양해서 여기 아니면 안 된다는 마음으로 지원을 넣었고 운 좋게 합격해서 활동을 시작하게 되었다.

IMG_4AB7BAB37D32-1 1

21-22 개발 새내기의 도전

GDSC에 합격한 후, 다양한 사람들과 다양한 활동들을 경험했다. 들어가자마자 안드로이드 개발 공부를 팀 스터디 형식으로 진행했다. 팀 스터디 자체를 처음 해보고 안드로이드 개발도 처음 해보는 거여서 같이 하는 사람들한테 민폐 안 끼치려고 정말 열심히 했다.

안드로이드에 어느 정도 익숙해졌을 때 구글에서 전 세계 대학생들을 상대로 여는 솔루션 챌린지 대회에 참가했다. 이 대회가 내 첫 프로젝트였다. 이때 세 명이 함께 한팀을 이루고 채식주의자를 위한 레시피 정보 제공 애플리케이션을 개발했다. 프로젝트가 처음이었던 나는 깃허브 사용도 어색해서 이것저것 팀장한테 물어보면서 겨우겨우 내 코드를 메인 브랜치에 merge 했던 기억이 난다.

그리고 안드로이드 스튜디오로 뷰를 제작할 때 코드타이핑을 하지 않고 레이아웃 도구를 이용해서 뷰를 마우스로 배치하는 짓을 저질렀다. 또한, 이것도 모자라.. 액티비티에 네트워킹, 데이터, 뷰와 관련된 모든 코드를 때려 박는 짓을 저질렀다. 덕분에 내가 작성한 액티비티 코드는 담당자인 내가 봐도 파악을 못 하는 경지에 도달했다.

유지보수는 1도 안 되고 어딘가 오류가 발생하면 액티비티 전역이 빨간불 걸리고… 확장하려니 기존코드를 또 수정해야 하고… 정말 답도 없었다. 심사하려고 이 코드를 봤던 구글 개발자분들에게 죄송할 따름이다. 그래도 이런 경험을 통해 소프트웨어 아키텍처가 필요한 이유를 알게 되었다.

완전 초보인 상태로 프로젝트를 끝낸 이후에는 다양한 사람들과 스터디도 하고 해커톤도 나가고 MT도 갔다. 프로젝트 이외에도 다양한 활동을 한 덕분에 소통, 협업, 개발 능력치를 올릴 수 있었다. 여기서 인연이 되어 지금도 연락하고 지내는 사람들도 꽤 있다. 그만큼 구성원들도 활동 내용도 매우 만족스러운 활동이었다.

Group 2

장고 스터디 정모 단체샷

22 - 23 새로운 도전

구성원으로서 약 1년의 활동을 끝내고 혼자 머릿속으로 회고를 진행해봤다. 개발과 협업을 모두 경험해봤는데 뭔가 개발보다는 협업이 더 어려운 것 같다는 생각을 했다. 그래서 협업 능력을 키우기 위한 고민을 하고 있었는데 때마침 GDSC에서 구성원으로 같이 활동한 친구가 다음 기수 리드로 활동하게 돼서 코어 멤버를 뽑아야 하는데 해볼 생각 있느냐고 제안이 왔다.

코어 멤버로 활동하게 되면 일반 멤버로 활동할 때와 다르게 조직 운영 및 기획과 소통을 할 일이 많으므로 내가 원하는 부분을 얻을 수 있을 것 같아 면접을 보고 코어 멤버로 2회차 활동을 시작했다. 코어 멤버로서 리드와 회의를 진행하면서 여러 중요한 것들을 결정하고 진행했다. 이 과정에서 회의를 정말 많이 한 것 같다.

대회 기획 및 운영

가장 기억에 남는 활동은 대회를 기획하고 운영하는 일이었다. 22년에 교내에서 알고리즘 경진 대회를 기획했는데 내가 맡은 역할은 다음과 같다.

1
2
3
4
5
1. 굿즈 디자인 및 주문 관리
2. 홍보 포스터 제작
3. 홍보 현수막 제작
4. 문제 제작 및 검토
5. 대회 현장 감독 및 운영
  • 굿즈 디자인 및 주문 관리

    회의 결과로 에코백, 렌즈 클리너, 스티커를 대회 굿즈로 결정했다. 에코백 안에 렌즈 클리너와 스티커를 넣어서 대회 참가자들에게 제공하면 깔끔할 거 같아서 구성을 위와 같이 했다. 생각보다 스티커 디자인이 어려워서 여기에 시간을 많이 썼다. 나머지는 이전부터 생각한 게 있어서 빨리 끝낼 수 있었다.

    IMG_0958 1

  • 홍보 포스터와 현수막 제작

    홍보 포스터와 현수막을 제작하는 과정은 즐거웠다. 평소 디자인에 관심이 많아서 직접 포스터와 현수막을 제작하고 싶다는 마음이 컸다. 그래서 기획 회의에서 이를 말했고 내가 제작을 담당하게 되었다. 구글에서 다양한 포스터 디자인을 참고하여 디자인 콘셉트를 잡았고 해당 틀 안에서 여러 가지를 제작하고 비교하여 가독성이 좋은 쪽으로 수정을 진행했다.

    Group 1

    Component 8

  • 문제 제작 및 검토

    문제 출제는 백준을 참고했는데 DP 문제 하나를 참고해서 살짝 틀었다. 이게 우리 학교 학우들의 수준을 잘 몰라서 난이도 조정에서 많은 고민을 했다. 고민한 끝에, DP 를 이용하여 팰린드롬인 수열을 카운트하는 방식으로 제작했다. 난이도는 백준 기준으로 골드3이었다.

    내가 만든 문제 이외에도 다른 문제들도 평균적으로 골드 중간급 이상이어서 충분히 해볼 만한 수준이었다. 실제로 대회 참가자 중에서 꽤 많은 인원이 절반 이상 문제를 해결했다. 이래서 문제 검토 때 교수님이 높지 않은 난이도에 대한 우려를 보이신 것 같다. 내 생각에는 다음 대회부터는 난이도를 조금 더 높이면 딱 알맞을 것 같다.

  • 대회 현장 감독 및 운영

    대회 당일에 현장 스태프로 참여하여 감독관 역할을 수행했다. 비기너 트랙은 챌린저 트랙보다 문제 난이도가 쉬워서 문제를 다 푼 사람이 두 세 명 정도 나왔다. 챌린저 트랙에서 올 클리어는 나오지 않았지만 반 이상 해결한 사람들은 꽤 있었다. 현장 운영을 하면서 갑작스러운 오류와 질문이 발생했지만, 운영진들이 최대한 빠르게 해결하여 무사히 대회를 끝낼 수 있었다.

    코페 수강실 뒤에서 샷

    그런데 대회가 끝나고 지인을 통한 문제 오류를 제보받았는데 실제로 확인해보니 오류가 존재했다. 지인이 해당 문제의 오류 때문에 시간을 많이 할애해서 단순히 넘어갈 문제가 아니라고 판단을 했다. 그래서 급하게 운영진들에게 이를 알렸고 해당 문제로 피해를 받았을 가능성이 높은 인원들을 추려서 사죄의 메시지와 적절한 보상안을 준비했다. 정말 다행이었던 것은 해당 문제 오류로 참가자 순위를 업데이트했을 때 당일 순위와 같아서 등수 변동에 대한 문제는 없었다는 거다. 정말 대참사가 날 뻔해서 당시에 문제가 해결될 때까지 엄청나게 긴장을 했던 기억이 난다.

    운영진들끼리 대회 관련 이슈가 완전히 끝나고 회고하는 시간을 가질 때 다들 이 부분을 문제점으로 뽑았다. 운영진들이 아무래도 대회 준비 이외에도 하는 일이 많다 보니 각자가 맡은 문제만 검수하는 방식으로 진행했었는데 이게 잘못된 선택이었던 것 같다. 아무리 바빠도 시간을 내서라도 운영진 모두가 전체 문제에 대한 검토를 세세하게 해야 했는데 너무 안일했다. 그래서 나중에 대회를 준비하게 될 다음 기수들이 우리와 같은 실수를 반복하지 않도록 문제점, 보완해야 할 점, 추가해야 할 점 등을 정리해서 참고할 수 있도록 따로 드라이브에 정리하는 것으로 마무리했다. 다음에 대회를 기획하고 운영할 기회가 또 생긴다면 이런 부분에서 실수가 나오지 않도록 신경을 써야겠다.

    코페 기념샷

일반 멤버였을 때는 배울 수 없던 소중한 경험들

일반 멤버로 GDSC 를 활동했을 때는 주변 일반 멤버들을 보고 배운 게 많았다면 코어 멤버는 코어와 리드와의 소통이 많다 보니 그 사람들의 리더쉽과 다양한 협업 가치관을 배울 수 있었다. 다들 책임감을 가지고 맡은 일을 열심히 해내는 모습을 보고 나도 덩달아 열심히 하게 된 것 같다.

그리고 코어로 활동하는 이상, 일반 멤버들이 잘 따라올 수 있도록 신경 쓰는 건 필수라고 생각해서 고민이 있는 멤버가 있으면 최대한 도움을 주려고 했다. 실제로 23년 초에 프로젝트를 하던 시기에 한 멤버가 실력 문제로 프로젝트 이탈에 대한 고민을 나에게 꺼냈었다. 나도 일반 멤버로 활동했을 때 비슷한 고민을 겪어봤고 극복한 경험이 있어서 그 친구에게 걱정하지 말고 믿고 따라와 주면 좋겠다는 식으로 얘기했다. 다행히 해당 멤버는 포기하지 않고 끝까지 잘 마무리를 했고 지금은 코어 멤버로 제2의 활동을 하고 있다.

코어 멤버로 약 1년 동안 활동하면서 프로젝트도 그렇고 조직을 운영하는 것도 그렇고 결국엔 서로가 서로를 잘 이끌어주는 게 가장 중요하다고 느꼈다. 나는 아직 이런 부분에서 부족한 점이 여전히 많지만 2년간의 GDSC 활동을 통해 이전보다는 훨씬 성장했다고 생각한다.

첫 개발 커뮤니티 활동을 GDSC로 시작한 것은 나에게 있어 최고의 선택이었고 이것은 내 대학 생활에서 가장 큰 변환점이었던 것 같다. 23년 이후에 우리 학교의 GDSC 챕터에서 활동하는 사람들 모두 좋은 기억을 얻고 갔으면 좋겠다.

Frame 11

코어 분좋카 후기 단체샷

Group 3

Group 2

세 번째 이야기 - 해커톤 최우수상

23년 최고의 순간을 뽑으라면 여름에 열린 교내 해커톤 대회에서 최우수상을 받은 이 스토리를 주저 없이 고를 것이다. 나에게 있어서 단순히 운이 좋아서 얻은 결과가 아닌 22년의 실패를 극복하기 위해서 오랫동안 준비해온 노력의 결실이다. 이 스토리를 제대로 이해하기 위해서는 22년 교내 해커톤 대회 때 이야기부터 풀어야 한다.

첫 해커톤의 시작은 GDSC 졸업 회식에서

22년 GDSC 마지막 날, 수료를 기념하기 위해 학교 근처에서 단체로 회식하고 있었다. 밥을 먹다가 GDSC로 친해진 형이 나한테 해커톤 대회에 참가하자는 제안을 했다. 대충 상황을 물어봤는데 형을 포함해서 세 명은 확정이고 나만 들어오면 팀 빌딩이 완성되는 상황이었다. 형을 제외한 나머지 두 명도 GDSC 멤버였으며 나보다 선배인 형들이었다.

제안을 받고 나서 고민을 했다. 이미 확정된 세 명의 형들은 나보다 경험도 많고 잘하는 사람들이지만, 나는 이때 프로젝트 경험이 한 번뿐이고 깃허브도 제대로 다룰 줄 모르는 상태였다. 그래서 하루 동안 빠르게 개발을 해야 하는 해커톤에서 내가 과연 잘할 수 있을지 의문이었다. 그래도 이렇게 우연히 찾아온 기회를 무섭다고 거절하면 다음은 없을 것 같아서 큰마음을 먹고 제안을 승낙했다.

처음 경험해본 합숙

해커톤 팀이 결성됐던 GDSC 수료 기념 회식 이후, 우리는 해커톤 공지에서 코로나 키워드가 대회 주제와 관련이 있다는 힌트를 보고 세부 주제를 유추해봤다. 다같이 고민을 해본 결과, 코로나로 인해서 바뀐 삶에 최적화된 서비스를 만드는 게 대회에서 제시할 주제인 것 같다는 결론을 냈다. 코로나 라는 키워드에서 낼 수 있는 주제가 한정적이라 우리가 유추한 주제가 완전히는 아니더라도 어느정도는 맞을 것 같다는 확신을 했다.

그 다음에는 우리가 생각한 세부 주제를 가지고 각자가 생각하는 서비스 기획안을 얘기하는 시간을 가졌다. 처음에는 뭔가 그럴듯한 아이디어가 나오지 않아서 골머리를 앓았다. 계속된 기획 회의에 서로 지쳐가던 마당에 한 명이 출장이 잦고 출장과 동시에 여행을 즐기는 직장인들 대상으로 근무지 및 여행지 추천 애플리케이션을 만들어보는 게 어떻겠냐는 제안을 했다. 나 포함해서 다른 팀원들도 괜찮은 반응이어서 해당 아이디어를 구체화하기로 결정했다.

기획의 가닥이 잡혔을 시기에 GDSC 수료 기념 MT 일정이 있었는데 팀원 한 명이 MT 일정 전날에 다 같이 모여서 기획 구체화를 어느 정도 진행하고 다음날에 MT 일정에 참여하는 것은 어떠냐는 제안을 했다. 팀원 전원이 동의했고 바로 MT 전날에 1박으로 유스호스텔에 모여서 팀원들끼리 서비스 이름과 와이어 프레임, DB 등에 대해 논의하는 시간을 가졌다.

이때 나는 프로젝트를 체계적으로 진행해본 경험이 없어서 서버와 프론트 사이의 얘기를 이해하지 못했다. 나와 같이 안드로이드를 담당한 팀원 한 명과 서버를 담당한 팀원 한 명은 고학년에 경험도 있어서 둘이 DB에 관한 이야기와 API 명세서와 같은 이야기를 술술 나눴다. 당연히 나는 이때 당시에 DB 개념은 아예 모르고 API 명세서라는 것도 처음 들어봐서 둘의 대화를 옆에서 멀뚱히 보기만 했다.

나도 뭔가 도움이 되고 싶은데 지켜보기만 하는 게 미안해서 충분히 할 수 있는 서비스 이름이랑 UI/UX, 아이콘 제작이라도 열심히 참여했다. 나는 이때 대부분 시간을 모바일 UI/UX 제작에 투자했던 것 같다. UI/UX 회의를 할 때 비로소 팀에 이바지를 한다는 마음이 들어서 조금 안심이 됐다. 모바일 파트는 UI/UX 회의를 진행하고 서버 파트는 따로 서버와 관련된 회의를 진행했다. 새벽까지 각자 여러 작업을 진행하고 합숙을 마무리했다.

합숙을 하면서 내가 도움될 수 있는 부분은 적었지만, 확실히 같이 모여서 작업을 하니까 효율이 엄청나게 좋았다. 그리고 개발 이외에도 산책하거나 같이 밥 먹으면서 노닥거리기도 했는데 이게 팀 분위기를 좋게 만든 것 같다. 여러모로 프로젝트 진행에 많은 도움이 되는 것 같다.

처음보는 라이브러리와 구조

합숙을 끝내고 대회가 시작되기 전에 팀원 형이 대회에 사용할 기술스택들을 설명해줬는데 AAC, Coroutine, Retrofit2 등 모두 다 처음 보는 라이브러리였다. 심지어 프로젝트 구조도 단순히 액티비티에 코드를 작성하는 것이 아닌 ui 층과 data 층으로 나누어서 ui 층에는 ViewModel을, data 층에는 Repository, DataSource 을 사용하는 방식이었다. 라이브러리도 그렇고 처음 보는 구조에 뇌정지가 왔지만, 대회가 곧 열리기 때문에 팀원이 제공해준 강의를 빠르게 들으면서 대회 전까지 최대한 프로젝트에 사용될 라이브러리와 구조에 관한 공부를 했다.

대망의 대회 당일

대회 당일, 대망의 대회 세부 주제가 발표됐는데 우리가 예상했던 주제와 어느 정도 일치했다. 그래서 우리는 어느 정도 주제를 예측해서 준비했던 기획을 그대로 사용하기로 했고 바로 구체화를 시작했다. 내가 맡은 파트는 게시글 작성 기능이었는데 여러 Fragment 를 이용해서 사진 첨부, 텍스트 작성, 장소 태그 추가 등 다양한 작업을 구현해야 했다.

Group 247

하지만 시작부터 쉽지 않았다. 기본적인 안드로이드 컴포넌트에 대한 개념도 제대로 알지 못한 상태에서 아키텍처 컴포넌트와 RetrofitCoroutine 에 맞춰서 설계하려 하니까 작은 것조차 구현하는 데 많은 시간을 썼다. 여기서 1차로 집중력이 흐트러졌다.

시간은 계속 흘러가는데 코딩도 못하고 계속 라이브러리와 구조에 대한 이해와 파악만 계속하고 있으니 자괴감이 엄청났다. 이런 일이 있을까 봐 대회 전까지 열심히 강의 들으면서 공부했는데 단기간에 이해하기에는 복잡하고 큰 범위의 내용이었던 것 같다. 솔직히 지금 생각해도 이제 걸음마를 뗀 안드로이드 초보가 한 달도 안되는 기간에 아키텍처와 AAC 라이브러리들을 전부 이해한다는 게 말이 안 됐다.

그래도 어떻게든 내가 맡은 파트는 끝내야 한다는 생각에 같은 팀원이 먼저 올린 코드를 보면서 단순히 따라 하는 식으로 급하게 코드를 작성했다. 물론 스스로 고민하고 코드를 작성하는 것이 맞지만 하루 만에 끝내야 하는 해커톤이기 때문에 어쩔 수 없던 선택이었다.

결국 단순 따라 하는 방식으로 댓글 기능과 검색 기능을 구현하는 데 성공했다. 그러고 나서 게시글 작성 기능 구현을 바로 시작하여 뷰에서 사용자의 데이터를 받아서 저장하는 것까지 완료했는데 그다음에서 문제가 발생했다. 사용자가 등록한 사진, 게시글 문구, 장소를 서버에 전송해서 게시글 등록에 대한 요청을 처리해야 하는데 통신 에러가 났다.

status 코드가 500번대로 계속 떠서 로그로 확인했는데 멀티파트 형태로 서버에 전송되어야 하는 게 null 로 전송이 되는 것을 확인했다. 처음에는 Retrofit2Request 의 양식이 잘못된 줄 알고 둘의 코드를 여러 방식으로 수정을 해봤다. 내가 맞춰서 설계하려 라이브러리에 대한 경험이 없어서 구글링으로 여러 코드를 합치다 보니 분명히 요청 방식에 대한 맞춰서 설계하려 관련 코드가 잘못된 것이라 생각을 해서 해당 판단을 한 것이다.

그런데 아무리 코드를 수정해도 오류가 해결되지 않아서 계속 몇 시간 동안 해당 오류와 승강이를 벌였다. 앞서 댓글 기능과 검색 기능을 구현하는 데 체력과 정신을 쏟아서 판단이 흐린 상태로 어떻게든 통신 오류를 해결하고자 했는데 결국 아침까지 해결하지 못했다.

다른 안드로이드 것조차 맡은 팀원은 마감 전까지 급하게 구현하지 못한 기능들을 최대한 구현하려고 나머지 힘을 쥐어짜 내고 있는데 정작 나는 오류 하나 해결하지 못해서 아무것도 못 하는 상황이 매우 비참했고 다른 팀원들에게 너무 미안했다.

결국 마감 시간이 다가와서 해결하지 못한 오류는 포기하고 구현한 것만 제출하기로 했다. 나는 깃허브에 지금까지 작업물을 제출하고 나머지 팀원들은 발표자료를 만들기로 하고 마지막 업무를 진행했는데 여기서 또 내가 대참사를 냈다. 대회 깃허브 페이지에 작업물을 잘못된 방법으로 push 하는 바람에 혼자서 10분 동안 삽질을 했다. 결국, 옆에서 발표 자료 만들던 팀원이 도와줘서 마감 직전에 겨우 제출할 수 있었다.

정말 참담했다. 게시글 작성 기능 오류를 해결하지 못해서 깃허브라도 제대로 하고 싶었는데 이것조차 제대로 하지 못한 내 모습이 너무 부끄러웠다. 그래도 팀원들은 괜찮으니까 발표까지 잘 마무리하자며 격려해줘서 혼란스러웠던 감정을 잘 추스르고 무사히 발표를 마무리했다.

다사다난했던 22년 첫 해커톤 종료

65_윤승민 (1)

대회를 마무리하고 집에 오는 길에 수많은 감정을 느꼈다. 여태까지 새로운 것에 도전하면 목표보다 높은 결과를 내서 나름의 자신감 있는 태도로 해커톤에 임했는데 처음부터 끝까지 제대로 해낸 게 없어서 내가 해온 것들에 대한 희의감을 느꼈다.

그래도 얻은 것도 많았다. 이때 스스로에 대한 객관화를 제대로 할 수 있었고 프로젝트 설정부터 열심히 도와준 안드로이드 팀원 덕분에 안드로이드의 중요 라이브러리와 아키텍처라는 것을 알게 되어 좀 더 넓은 시선을 가지게 되었다.

대회 결과는 일주일 뒤에 발표됐는데 우수상으로 생각보다 굉장히 만족스러운 결과를 얻었다. 우수상을 받아서 다행이란 마음이 들었지만, 한편으론 내가 게시글 기능 구현을 잘 마무리하고 다른 기능까지 더 개발해서 완성도를 높였으면 결과가 더 좋았을 거라는 아쉬움이 들었다. 지금도 이때의 우수상은 기획부터 개발까지 내가 크게 이바지한 부분이 많이 없다고 생각해서 내가 아닌 다른 팀원들이 이끌어낸 성과라고 생각한다.

Group 249

Group 248

실패를 극복하기 위한 노력

해커톤을 끝내고 팀원 중 한 명이 대회 때 못다 한 개발을 마무리하는 것이 어떠냐는 제안에 팀원들이 동의해서 바로 재개발에 착수했다. 나는 이번에야말로 저번에 끝내 해결하지 못했던 오류를 해결하겠다는 의욕으로 다시 오류를 찾기 시작했다. 그래도 대회 때와 달라진 점이 있다면 대회가 끝나고 내가 많이 부족했음을 인정하고 부족한 부분들을 공부했기 때문에 프로젝트 구조와 라이브러리가 익숙해졌다는 것이다.

이 덕분에 대회 때 능숙하게 해내지 못한 로직의 흐름 이해가 잘 되어 내 발목을 붙잡았던 오류의 원인을 찾을 수 있었다. 원인은 생각보다 단순했다. 대회에서 레트로핏 라이브러리와 관련한 오류라고 생각을 해서 오류를 쉽게 찾지 못했는데 이 때문이 아니라 프래그먼트의 생명주기와 관련된 문제였다. 프래그먼트의 생명주기에 따라 유저 데이터가 초기화될 수 있다는 점을 간과하고 단순히 통신 관련 코드를 잘못 작성한 거라고 생각을 했던 것이다.

그래서 테스트를 위해서 임시로 여러 프래그먼트 전역에서 사용할 수 있는 싱글톤 객체를 만들어서 해당 객체에 유저 데이터를 저장하고 서버 통신을 해봤는데 정상적으로 응답을 받는 것에 성공했다. status 코드가 200 이 나온 로그를 보고 참으로 허무함을 느꼈다. 가장 근본적인 것부터 시작해서 오류의 원인을 찾았어야 했는데 숲을 보지 않고 나무만 본 결과가 이런 건가 싶었다.

결국 막혔던 오류를 무사히 해결하고 게시글 작성 기능 구현을 완성해서 그동안 쌓였던 앙금이 조금은 풀린 느낌을 받았다. 이후에도 계속 개발을 진행하면서 회의도 했는데 팀원 두 명의 일정 문제로 아쉽게 추가 개발은 마무리되었다. 그래도 이때를 기점으로 안드로이드 공부의 방향성을 잡아서 안드로이드로 홀로서기를 시작한 계기가 되었다. 오히려 큰 실패가 더욱더 열심히 하게 되는 원동력이 된 것 같다.

해당 원동력으로 해커톤이 끝나고 9월부터는 좀 더 폭넓은 시선을 가지고 싶어서 GDSC 코어 멤버로서의 활동을 시작했고 23년부터는 해커톤 때의 프로젝트 경험을 살려서 본격적으로 홀로 프로젝트 개발을 진행하는 경험을 쌓았다.

운명처럼 다시 찾아온 그 해커톤 대회

운명인 건지 우연인 건지, 23년 6월에 GDSC 코어 멤버로서의 활동이 끝나가던 시점에 첫 교내 해커톤 대회를 같이 했던 팀원 한 명이 이번에도 같이 해커톤 대회를 할 생각이 있는지 나에게 물어봤다. 처음 제안을 받았을 때 이전 해커톤 대회의 아픈 기억이 떠올라서 다시 경험하고 싶지 않은 마음에 거절하려고 했다.

게다가 첫 해커톤 시절과는 다르게 이때는 GDSC 코어 멤버라서 할 수 있는 해커톤 운영진 경험을 하고 싶어서 해당 대회의 기획 및 운영을 하는 쪽으로 리드와 얘기가 어느 정도 됐던 상황이다. 그래서 굳이 하고 싶었던 운영진 자리를 포기하고 대회에 참가할 필요가 없던 상황이기도 했다.

그런데 문득 이번 대회를 운영진으로 마무리하게 되면 이전 대회 때의 실패를 만회하지 못한 채로 졸업하게 되는데 그렇게 되면 나중에 가서 두고두고 후회할 것 같았다. 그때를 기점으로 개인적인 기술 스택 공부와 프로젝트 리드 및 협업 경험을 쌓았기 때문에 23년의 대회는 단순히 허황한 도전이 아닌 충분히 준비된 도전이라 판단이 되어 과감히 운영진을 포기하고 참가자로 노선을 틀었다.

IMG_0959 1

다시 시작된 해커톤, 시작부터 변수 발생?

이번에도 6월에 대회가 열렸다. 종강하고 바로 대회가 바로 열려서 사실상 대회 힌트에 맞춰서 미리 기획을 조금이라도 짜낼 시간이 거의 없었다. 그래서 우리 팀은 대회 공지에 나온 힌트에 맞춰서 주제를 유추하는 회의를 진행했고 가장 괜찮은 하나를 대회에 들고갔다.

그런데 대회가 시작되고 주제를 발표했는데 우리가 준비했던 주제와 전혀 연관성이 없는 변수가 발생했다. 그래서 우리는 대회 오프닝이 끝나고 작업 공간에 모여서 재빨리 대회 주제에 맞는 아이디어를 구상했다. 대회 주제가 2023 트렌드 코리아에서 선정한 올해의 키워드를 기반으로 대학생들에게 도움이 되는 서비스를 만드는 것이었는데 쉽게 아이디어가 나오지 않았다.

위기를 기회로 바꾸다

팀원들이 여러 아이디어를 얘기하고 있던 그때 문득 대학생들끼리 자주 하는 밥약 이 떠올랐다. 대학생 커뮤니티인 에브리타임에서 심심치 않게 같이 밥 먹을 사람을 구하는 글이 올라오는 걸 볼 수 있는데 나는 이 부분을 서비스로 구체화하면 괜찮지 않느냐는 생각을 했다.

해당 생각에 대해 여러 가지 이유가 있었는데 먼저 우리 학교의 위치상 교통이 좋지 않고 폐쇄적이어서 기숙사나 근방에 자취하는 학생들은 공휴일이 낀 휴일이나 명절이 아닌 이상 다른 지역으로 이동하지 않는 성향이 있다. 그러다 보니 우리 학교 근처를 한정으로 한 로컬 서비스가 있으면 신선한 맛이 있을 거라 생각했다.

두 번째 이유는 다른 팀과 기획이 겹치고 싶지 않은 마음이 있었다. 대학생들을 위한 서비스가 주요 주제였기 때문에 분명히 대부분 팀이 문서나 일정과 관련된 카테고리를 다룰 거로 생각해서 우리 팀도 그런 주제를 기획한다면 압도적으로 잘 만들어야 입상 가능성이 생긴다. 따라서 우리 팀은 주제에서 벗어나지 않으면서 최대한 다른 팀과 겹치지 않은 주제로 기획하는 것이 유리하다고 판단을 했다.

세 번째 이유는 우리 팀 구성원들의 실력에 대한 믿음이 있어서다. 밥약 매칭 서비스의 모든 기능을 고작 하루에 전부 구현하는 것은 절대 불가능하다. 그렇다면 주요 기능들에 대한 완성도 있는 UI/UX에 초점을 맞추고 이를 빠르게 개발할 수 있어야 한다. 내 기준에서는 우리 팀원들이 이를 충분히 해낼 수 있는 경험과 실력이라고 생각이 들었다. 나를 포함해서 안드로이드 파트를 맡은 또 다른 팀원 둘 다 UI/UX 디자인 경험이 있고 레퍼런스도 많아서 다른 팀들과 비교했을 때 충분히 경쟁력 있는 모바일 화면을 만들 자신이 있었다.

나의 아이디어로 대회 입상에 도전하다

나는 밥약 매칭 서비스가 충분히 경쟁력 있다고 판단이 돼서 팀원들에게 곧바로 해당 기획에 대해 설명을 했다. 이를 듣고 팀원들이 처음에는 장난 섞인 웃음을 보였다가 이내 생각에 잠기더니 생각보다 괜찮을 것 같다는 반응을 보였다. 그래서 나는 여러 케이스를 설명하면서 내 기획에 대한 어필을 했다. 뭔가 그때를 돌아보면 내 기획이 충분히 통할 거라는 자신이 있었던 것 같다. 진지하게 고민을 하던 팀원들은 내 기획을 받아들였고 우리는 해당 기획으로 본격적인 구체화를 시작하게 되었다.

개발 과정

기획 확정을 하고 휴게실에서 팀원들끼리 밥을 먹으며 구체적인 설계 방법을 얘기했다. 거기서 어느 정도 틀을 잡은 뒤에 작업 공간으로 돌아와서 서버팀은 데이터베이스와 API 구현을 하고 안드로이드 파트는 UI/UX 디자인을 했다. 참고할만한 UI/UX 레퍼런스를 여러 개 모아서 직관적이고 단순한 콘셉트로 디자인을 진행했다. 안드로이드 파트가 두 명이다 보니 서로 절반씩 나눠서 작업했다.

디자인 작업이 거의 다 끝나갈 무렵에 서버팀에서 일부 API가 완성되어서 디자인 마무리를 하고 바로 코딩을 시작했다. 제한된 시간 내에 빨리 개발을 해야 하므로 나에게 익숙한 구조와 코드를 사용했다. 그래도 이전 해커톤 때와는 다르게 안드로이드 개발에 대한 경험이 쌓인 상태라 작업에 속도를 붙일 수 있었다.

아침이 지나고 개발 막바지를 향해 달려가고 있을 때 매칭된 화면의 개발을 담당한 안드로이드 팀원이 특정 오류를 잡지 못해서 개발이 잠시 멈추는 상황이 발생했다. 아무래도 매칭 화면이 가장 핵심인 부분인지라 굉장히 긴장되는 상황이었다. 어떤 오류인지 파악하기 위해서 같이 오류를 살펴봤는데 쉽게 원인을 찾지 못했다. 그래도 팀원이 꼭 해결하겠다는 의지가 눈에 보여서 나는 팀원을 믿고 내가 하던 개발을 마저 진행했다.

하지만 끝내 해당 팀원이 대회 마감 전까지 오류를 해결하지 못하여 우리는 매칭 화면은 단순히 제작한 UI를 보여주는 것으로 방향을 틀고 작업물을 제출했다. 해당 팀원은 죄책감에 나를 포함한 팀원들에게 계속 미안하다는 말을 계속했던 것 같다. 이때 뭔가 이전 데이터베이스와 때의 내 모습이 떠올랐는데 그때의 나도 내가 맡은 파트는 스스로 해결해야 한다는 마음으로 끝까지 오류와 싸웠지만 결국 해결하지 못하고 팀원들에게 미안하다는 말만 했다. 아마 이 친구도 나와 비슷한 심정이지 않았을까 하는 생각이 들었다. 그래서 다른 감정보다는 오히려 내가 맡은 파트 때문에 팀원을 더 도와주지 못한 것에 대한 미안함이 컸다.

결과물 발표 시간

그래도 매칭 화면을 빼고는 나머지 주요 기능들은 구현을 해서 시연 영상과 발표 자료를 잘 준비하여 발표 강의실에 들어갔다. 첫 번째 팀의 발표를 시작으로 다른 팀들의 발표를 보면서 우리 팀의 결과물을 비교해봤는데 생각보다 할만하다는 생각이 들었고 우리 팀의 발표를 맡은 서버 인원들도 똑같은 반응을 보였다. 이 덕분에 우리 팀이 발표를 좀 더 자신감 있게 할 수 있었던 것 같다.

우리팀의 발표가 끝나고 심사위원들의 반응을 살폈는데 예상보다 반응이 좋아서 조금 놀랐다. 기획의 허점을 찌르는 질문이 심사평의 주가 될 줄 알았는데 그것보다는 흥미와 호기심에 기반을 둔 여러 긍정적인 질문들이 더 많았다. 안 그래도 이전 팀들의 대부분 심사평이 좋지 않아서 우리 팀도 긴장하면서 심사평을 기다렸는데 정말 다행이었다. 이게 반응이 생각보다 좋아서 오히려 너무 기획이 터무니없어서 부정적인 재미를 느낀 게 아니겠느냐는 생각도 들었다. 그래도 우리는 최대한 긍정적인 방향으로 생각하기로 하고 대회를 마무리했다.

가장 예쁜 꽃은 우여곡절 끝에 피는 꽃

대회가 끝나고 약 일주일 뒤에 그렇게 기다리던 슬랙 공지가 떴다. 우리 팀 명이었던 초록깡통 이 시상 대상팀에 속한 걸 보고 속으로 얼마나 소리를 지른 지 모르겠다. 내가 낸 기획안이 대회에서 통했다는 생각에 기쁨이 배가 된 것 같다. 팀원들끼리도 자축하면서 고생했다는 말을 나눴다.

다음날 시상식에 팀원들이 모두 일정이 있어서 일정이 너른 내가 참여했다. 수상팀 발표는 우수상부터 대상 순으로 진행이 됐는데 나는 우수상이 세 팀이나 있어서 우리 팀이 초반에 우수상으로 호명될 줄 알았다. 대상과 최우수상은 각각 한 팀만 해당이 돼서 이걸 우리 팀이 수상하는 건 어렵다고 생각했다.

그런데 예상치 못한 반전이 일어났다. 수상팀을 차례대로 발표하는데 초반 우수상 세 팀에 우리 팀이 없어서 엄청나게 당황했다. 우수상을 받을 줄 알았는데 우수상을 넘어서 최소한 최우수상은 확정이고, 크게는 대상까지 기대할 수 있는 상황이 됐다. 하지만 아쉽게도 우리 팀은 대상까진 닿지 못했고 최우수상을 받았다. 그래도 우리 팀은 최고의 결과로 받아들였다. 대상 팀의 작업물은 다른 팀들과 비교했을 때 급이 너무 높아서 이 팀이 시상 대상팀에 속한 걸 보는 순간 대상을 받을 거라고 팀원 모두 예상을 했었다. 그래서 우리는 아웃라이어 느낌의 대상팀을 제외하면 비슷비슷한데 그중에서 우리가 최고인 거 아니냐며 장난스럽게 긍정적인 합리화를 했다.

IMG_0720

Group 248

최우수상 판넬을 들고 집으로 복귀하는 버스에 탔는데 감회가 새로웠다. 1년 전만 해도 혼자서 제대로 해낸 것 없이 대회를 마무리하고 비참한 심정으로 집에 가는 버스를 탔었는데 1년 후에 같은 대회에 다시 나가서 이번에는 내가 직접 아이디어를 내고 그 아이디어로 최우수상이라는 결과를 냈으니 도파민이라는 게 이런 건가 싶었다.

00BD5503-E156-4E22-80C6-4B7731B8D20C_1_105_c 1

누군가에게는 교내 공모전 수상이 특별하게 느껴지지 않을 수도 있다. 오히려 그걸로 이렇게까지 기뻐할 정도인지 의문을 품을 수도 있다. 하지만 나에게 있어서 교내 해커톤 대회는 내가 한 번 제대로 실패를 겪은 기억하기 싫은 트라우마였고 나는 이를 극복하기 위해서 스스로 같은 대회에 다시 나가 직접 트라우마를 부쉈다. 그래서 큰 대외 공모전도 아닌 단순하고도 단순한 교내 공모전 수상에 행복을 느끼는 거다.

2023년 말에 화제가 되었던 롤드컵 우승팀인 T1의 정글러 오너(Oner)선수가 이런 말을 했다.

image 1

출처 - 이포커스 유튜브 채널 썸네일 캡처

나는 이 말을 굉장히 좋아한다. 내 해커톤 경험처럼, 그리고 오너 선수가 22년에 준우승을 하고 23년엔 결국 우승을 한 것처럼 끝까지 가면 결국엔 해낸다는 게 이런 게 아닐까 싶다. 평생은 모르겠는데 그래도 오랫동안 이 경험을 잊지 못할 것 같다.

마지막으로 이런 경험을 할 수 있게 이끌어준 팀원들에게도 매우 고맙다는 말을 또 한 번 이 글을 통해 전하고 싶다. 수상 기념 팀 회식 사진을 끝으로 이 에피소드에 대한 이야기를 마치겠다.

IMG_0793

2023 총정리

이렇게 2023년에 있었던 큼직한 여러 일화를 다뤘는데 23년은 특히 협업 능력치가 이전보다 크게 성장한 해였다. 다양한 사람들과 프로젝트를 하면서 가장 크게 깨달은 게 있다면 성공적인 프로젝트를 위해서는 많은 소통과 좋은 분위기가 필요하다는 것이다. 여태까지 협업하면서 항상 좋은 결과를 낸 사람들을 보면 뛰어난 개발 실력은 물론이고 팀 자체의 분위기를 좋게 만드는 긍정적인 에너지가 있었는데 나도 아직은 많이 부족하지만 그런 사람으로 발전하는 것이 내년 목표라고 할 수 있겠다.

반대로 아쉬운 점도 있었다. 협업 관련 경험은 기회가 많았고 실제로 커뮤니티도 하고 대회도 나가고 프로젝트도 했는데 그에 반해서 기술적 성장은 많이 이뤄내지 못했다. 23년 초반에는 혼자서 안드로이드 아키텍처 컴포넌트와 관련된 라이브러리와 소프트웨어 아키텍처를 연습해보는 시간을 가졌고 여름에 있었던 해커톤에서는 기획과 협업 위주로 수행하다 보니 좀 더 나은 코드를 위해 고민을 하는 시간이 없었다.

그래서 하반기에 기술적 발전을 도모하기 위해 UMC라는 대학생 연합동아리를 통해 다른 학교 학생들과 프로젝트를 할 기회를 잡았는데 아쉽게도 안드로이드 파트는 나를 포함해서 전원이 초보자라 단순히 동작 구현에만 초점을 맞춘 개발을 했다. 실제로 이때 Koin 대신에 좀 더 제대로 된 DIHilt 와 안드로이드에 종속된 LiveData 대신에 코틀린에서 제공하는 Flow 와 같은 써보지 않았던 기술을 경험해보고 싶었는데 다른 팀원들이 나보다 훨씬 경험이 적어서 내가 기존에 사용했던 방식을 팀원들에게 알려주고 실제로 적용하는 걸 옆에서 코치하는 구실을 했다. 팀원들이 최대한 빠르게 이해할 수 있게 아이패드 드로잉 앱으로 동작 흐름에 따른 라이브러리 작용을 그려가면서 알려주기도 했다.

2024년 목표

23년에는 많은 협업 경험을 해봤기 때문에 24년에는 나의 기술적 공백기를 깨고 싶은 마음이 크다. 그래서 쉽지는 않지만 가능하다면 좀 더 규모가 있는 대외활동에 참여해서 안드로이드에 대한 이해를 높이는 것이 첫 번째 목표다. 마음에 두고 있는 대외 개발 동아리가 두 곳이 있는데 둘 다 들어가기 쉽지 않은 곳이라 열심히 준비해야 할 것 같다.

두 번째 목표는 본격적인 이력서 작성을 통해 서류와 면접을 대비하는 것이다. 아직 인턴 경험이 없어서 실제 회사에 면접을 본 경험이 없다. 이제 졸업을 앞두고 있고 본격적으로 취업 시장에 뛰어들 타이밍이기 때문에 일단 도전해본다는 마음가짐으로 임할 생각이다. 여기서 운 좋게 인턴 기회가 생긴다면 네 발로 길 자신 있다. (제발요)

세 번째 목표는 앱스토어에 등록할 개인 프로젝트를 해보는 것이다. 여태까지 프로젝트는 여러 번 해봤지만, 앱스토어 출시까지 간 적은 없어서 이번에는 꼭 해보고 싶다. 현재 생각해놓은 간단한 기획이 있긴 한데 좀 더 안드로이드에 관한 공부를 진행하고 늦어도 하반기 전에는 완성하는 것이 목표다.

마지막으로는 대학교의 마지막 학기를 잘 마무리하는 것이다. 개인적으로 대학에 입학하면서 대학생으로서 이루고 싶은 버킷리스트가 있었는데 작년을 끝으로 모두 이뤄냈다. 그래서 이제는 학교생활에 대한 미련 없이 행복하게 졸업할 수 있을 것 같다. 그러므로 남은 한 학기를 잘 마무리하고 싶다.

1
2
이로써 23년의 회고는 모두 끝이 났다. 
2024년에 목표한 것들을 꼭 이루고 뿌듯한 마음으로 24년 회고를 작성할 날을 기대하며 여기서 글을 마치겠다.

(프로그래머스 | Kotlin) - 무인도 여행

Kotlin - ArrayList와 MutableList, 무엇을 써야 할까?