공공데이터 청년인턴 후기(2) 최우수상을 수상하다.

공공데이터 청년인턴 후기(2) 최우수상을 수상하다.

1)해커톤에 지원하다.

java를 시작한지 한달밖에 안됐을 때여서 대회에 출전해도 되는건지에 대한 불안감이 있었습니다. 고민했지만 '도전은 그 자체만으로도 의미있다"는 생각으로 해커톤에 지원하기로 결심하였습니다. 해커톤 개최 전 온라인으로 팀원들을 모집하는 시기가 있었는데, 초반부터 모집하는 팀이 열정적이고 준비성도 있을 것이라 생각해 최대한 빨리 팀에 들어가려 하였고, 이것이 좋은  팀원들을 만나게 된 이유 중의 하나라고 생각합니다. 그렇게 팀에 들어가게되었습니다.

 

 

2) 최우수상을 수상하다.

코로나로 우울증 환자가 증가한다는 사회적인 문제에서 출발하여 마음을 주기적으로 캐어할 수 있는 프로그램을 만들기로 하였습니다.

 

맡은 파트: 사용자가 날짜를 선택하면 그 날짜를 기준으로 한 "주"의 실천률을 그래프에 구현하는 부분을 담당하였습니다. 백엔드 개발자가 없어, Room Library를 사용하여 내부 DB에 데이터를 저장해주었습니다. 내부 DB의 데이터를 쿼리해 추출한 데이터를 그래프에 월요일부터 일요일까지 각각 입력해 표시하였습니다. 하단엔  알약 모양으로 일주일 전체의  실천률을 표시하였습니다.

사용자의 날짜 선택

 

Mpchart Library를 활용해 실천률 구현

 

시연영상

https://drive.google.com/file/d/1jPeuGjGBCFE3KqlyuLKkHbVPvZRfzf42/view?usp=sharing 

해커톤제출용.mov

 

github

https://github.com/slew61/MindCareApp

GitHub - slew61/MindCareApp: ProjectStart

 

배운점

 

1. 모르는 부분이 있으면 혼자 파고드는 것도 좋지만, 팀원들과 이슈를 공유하면 더 효율적인 방법으로 문제를 해결할 수 있다는 것을 깨닫게 되었습니다. 물론 혼자 파고드는 과정에서 배우는 점도 있지만, 간단한 실수의 경우 타인의 눈에 더 잘보이기 때문에 시간을 절약할 수 있었습니다. 또한 팀원이 이미 아는 부분일 경우, 도움을 받고 빠르게 문제를 해결할 수 있습니다.

 

2. 프로젝트가 진행되면서 개발은 개발만 기획은 기획만 하다보니 점차 기획팀과 개발팀의 소통이 부족하게 되었습니다. 개발팀에서는 현재 기술적으로 구현 가능한 부분을 중심으로 핵심 기능을 구현하는 것을 중심으로 하였으나, 기획팀은 아무래도 기획이다 보니 개발자 수준을 고려하지 못해 AI 기능 등을 추가하거나, 기획 내용을 여러 차례 수정하였습니다. 그래서 중간에 개발에 있어 많은 혼란이 있었고 예상보다 시간이 더 걸리게 되었습니다. 이는 개발팀, 기획팀의 문제가 아닌 소통의 부재때문이었다고 생각합니다. 무엇이 문제였는지 고민해본 결과, 개발자들끼리만 회의를 해서 그랬던 것같습니다. 따라서 개발 과정에서 개발자끼리만 회의를 하는 것이아니라, 기획팀과도 같이 주기적으로 해야한다는 배움을 얻게 되었습니다.  

 

3.  Git을 통해 협업을 하면서 merge rebase pull push fork master branch remote 등에 대해 더 명확히 알게 되었습니다.

-본선 진출 전에는 하나의 master브랜치에서 각자 맡은 파트를 작업해 push하는 식으로 협업을 하였습니다. 하지만 본선 진출이 확정되고 단순한 프로토타입이 아닌 하나의 유기적인 어플리케이션을 개발하기 위해 브랜치를 파서 협업을 진행하였습니다. 브랜치를 파 협업을 하는 과정은 큰 문제가 되지 않았으나, 개발자 회의 이후 약속한 날에 머지를 할 때에 문제가 발생하였습니다.

처음으로 머지하는 과정에서 당연히 컨플릭트가 날 수밖에 없었는데  ‘Accept yours’를 다 해버려서 완전 코드가 꼬여버렸었습니다.  이 과정에서 팀원들의 도움을 받아 rebase해 pull을 초기화하는 방법을 배우고 추천해준 유투브영상을 보며 차근차근 머지를 성공시켰습니다. 특히 가장 뿌듯했던 점은 복습을 통해 똑 같은 실수를 반복하지 않았다는 점입니다. 팀원들의 도움 이후 다음에 똑 같은 실수를 하지 않기 위해 관련 부분들을 복습하여 다음 머지때는 컨플릭트를 쉽게 해결할 수 있게 되었습니다.

 

 

어려웠던 점

 

자바를 공부한 지 한달 반정도 되었을쯤 인턴 내부적으로 해커톤을 개최한다는 소식을 들었습니다. 부족한 실력에도 운이 좋게 좋은 팀에 들어가게 되었고, 개발자 회의를 하였는데 정말 아는 단어가 한 두 개밖에 없어 큰일났다는 생각이 들었습니다. ‘백쓰레드’,’내부DB’, ‘리사이클러뷰’ 등 무슨 말인지도 모르고 고개만 끄덕였습니다. 제가 맡은 부분은 그래프 탭이었습니다. 사용자가 기록에 날짜별로 할일을 입력하고 실천한 일을 체크하면, 그것을 그래프 상에서 일주일 단위 별로 달성률을 나타내주는 것이 었습니다. 하지만 예상하시다시피 전 어떻게 접근해야할 지 몰랐습니다.

어려웠던 점 2가지 

1.     DateRangePicker를 통해 월요일이든 목요일이든 사용자가 클릭하면 그 주가 월요일부터 일요일까지 선택되게 고정하게 구현하고 싶었습니다. 처음엔 material로 구현을 해보았지만 첫번째 클릭과 두번째  클릭을 고정할 수 있는 메소드가 없었습니다. 이미 눌러진 날짜를 (Selection) 가져오는 메소드는 있었지만, 다이얼로그 안에서 사용자의 선택을 일주일 단위로 고정할 수 있는 메소드는 찾지 못했습니다. 그래서 라이브러리를 찾아보려고 하였으나, 찾지 못했습니다. DatePicker를 사용하여 월요일만 선택하게 하고 월요일을 선택하면 내부적으로 날짜를 계산해서 일요일까지 계산하는 방식을 생각해냈습니다. 그런데  이 부분을 material로 구현하려 하였는데, CalendarConstraint를 사용하여, 미래 날짜를 제한한다거나 등은 할 수 있었지만 요일을 제한하는 방법을 도무지 찾을 수가 없었습니다. 따라서 요일을 제한할 수 있는 라이브러리를 찾아 월요일만 선택할 수 있도록 하여 문제를 해결하였습니다.

 

2.   datePicker 등 다양한 이슈를 겨우 해결하고 나니 팀원들은 DB작업을 진행하자고 하였습니다. 저희 팀은 백엔드 개발자가 없어 내부DB를 사용하였습니다. 내부DB를 사용하기 위해 SQLlite가 아닌 Room을 사용하기로 결정하였는데, 회의에서 정말 아는 단어가 나오지 않아 염치불구하고 사실은 잘 모른다고 팀원들께 이야기했던 기억이 납니다. 창피하기도 했지만 친절하게 설명해주셨고 관련된 구글자료나 유투브 영상을 추천해주셔서 그걸 보고 공부할 수 있었습니다. 그럼에도 불구하고 처음 접하는 DB여서 어려운점이 무척이나 많았습니다.

먼저 Dao는 무엇인지.. item 모델은 무엇인지를 알아야했고 쿼리문을 짜야했습니다. 아예 모르는 상태로 시작하니 어떤 것을 구글링해야할지도 감이 안잡혀 무척이나 어려웠습니다. 하지만 공부해보다 도저히 모르겠는 부분들은 팀원들과 소통하며 해결하였고, 덕분에 시간 내에 Room 을 활용할 수 있게 되었습니다.  

공부 이후 실제로 적용하려 했더니 DB는 백쓰레드에서 작업을 해야한다는 사실을 알게 되었습니다. 그래서 백쓰레드를 공부하다 보니, UI 메인  쓰레드라는 것도 알게 되었습니다. 이런 과정이 순조로운 듯 싶었으나 갑자기 DB값이 그래프 상에 제대로 반영되지 않는 등의 문제도 발생하였습니다. 찾아보니 쓰레드는 랜덤하게 동시에 작동하기 때문에, 백쓰레드를 통해 DB값이 전달되기 전 메인쓰레드가 작동하면 DB값이 그래프 상에 재대로 반영되지 않는 것이었습니다. 이를 해결하기 위해 열심히 구글링을 하던 중 join을 통해 백쓰레드가 끝난 후 메인쓰레드를 실행시키는 방법을 알게 되어 문제를 해결할 수 있었습니다.

 

한 숨 돌렸지만, 더 큰 어려움에 봉착하게 되었습니다. DB의 entity의 구조때문이었는데요 저희는 Record 안에 Task라는 entity를 List형태로 저장하는 아이템 모텔 형태를 구현했기 때문입니다. 아이템 모델 안에 들어가있는 또다른 아이템의 list형식을 쿼리해야하는 문제에 직면하게 되었습니다. 여러 구글문서, 유투브 등을 보았지만 아이템 형식의 list를 어떻게 쿼리해야할지 찾기 어려워 굉장히 힘들었습니다. 그러다 결국 List형식을 가져올 수 있으려면 converter를 통해 json형식을 list로 전환하는 방식이 필요하다는 사실과 아이템 안의 아이템은 getter 메소드를 통해 가져오면 된다는 것을 알게 되어 문제를 해결할 수 있었습니다. 전에 있던 이슈들을 해결하는 과정에서 팀원들에게 많은 도움을 얻어 이번에는 혼자 해결해보고 싶다는 욕심이 들었었습니다. 오랜 시간을 들였지만 해결에 어려움이 있어 팀원들과의 소통을 통해 해결하게 되었습니다. 자바 개발 한달 차에 이런 이슈들은 저의 수준을 넘어선 것일 수도 있었음에도 혼자해보겠다는 욕심에 많은 시간을 낭비했다는 생각이 들었습니다. 팀원들과의 소통을 통해 충분히 빠르게 해결할 수 있는 부분이 었기 때문입니다. 그렇다고 팀원에만 의존하는 것도 정답이 아니라고 생각합니다. 이번 프로젝트를 계기로 이슈가 생기면 일정한 시간을 정해놓고 스스로 이슈를 해결해보고, 그래도 해결되지 않으면 혼자 전전긍긍하지말고 팀원들과 이슈를 공유하여 최대한 빠르게 이슈를 해결하는 것이 좋다는 것을 알게 되었습니다. 

 

 

새벽 6시부터 밤 12시까지 공부했습니다. 하나의 이슈를 해결하면 더 큰 이슈가 생겨 정말 힘들었습니다. 그런데 그 과정이 너무 재밌었던 것같습니다. 입시기간 이후로 모처럼 몰입할 수 있어 굉장히 좋았습니다.