[회고] 졸업 프로젝트를 성공리에 마무리하며(Feat. 인공지능 복지사 복실이)

[회고] 졸업프로젝트를 성공리에 끝내며

# 정보

• 2023학년도 1학기
• 캡스톤 디자인 프로젝트
• 인원 : 5명 ( FE(3) , BE(2) )
• 프로젝트 명 : 복실이
• 깃허브 링크 

GitHub - ho-jun99/capstone-2023-11: 나만의 작은 복지사 - 복실이

 

복실이 - 캡스톤 11팀

 

# 수상 내역

• 다학제간 캡스톤 디자인 : 1등상
• 캡스톤 디자인 아이디어톤 : 우수상
• SW 인재페스티벌 우수 작품 추천 출품

 

# 복실이 출범식

 우리학교에서는 소프트웨어를 전공하는 학생들은 졸업을 위해서 4학년 1학기가 되면 '다학제간 캡스톤 디자인'에 참여하여 그간 배운 모든 기술의 결정체를 담는다. 1학기 약 3개월동안 아이디어 기획 - 개발 - 배포까지 모든 단계가 이루어져야 하기 때문에 학기의 계획에 맞춰 기획을 하면 늦는다. 그렇기 때문에 우리팀은 겨울방학때 아이디어를 모으고 주제를 확정했다. 

 우리팀은 총 5명으로 이루어져 있었다. 3명의 프론트앤드 개발자와 2명의 백앤드 개발자였다. 우리팀은 정말 오합지졸의 끝판왕이었다. 프론트앤드에서 한명과 백엔드(나)에서 한명 5명중 총 2명만이 프로젝트와 협업경험이 있었다. 졸업프로젝트라는점과 짧은 기간인점을 감안할때는 사실은 조금 무모하다고 생각할 수 도있다. 하지만 우리팀은 시작부터 이유없는 자신감으로 가득차있었다. 그렇게 복실이들은 출범식을 올렸다.

 

# 트랜드를 잡아라

 정해진 주제나 범위가 없는 상황에서 기획을 진행해나가는 것만큼 힘든건 없던 것 같았다. 캡스톤프로젝트에서는 그 어떤것을 만들어도 문제 없다. 그렇기 때문에 우리팀은 기획을 하는데 상당부분 많은 시간을 할애해야만 했다. 이 기획단계에서는 하루 5시간 이상씩 회의를 했던 것 같다.

 이시기에는 유독 챗지피티가 붐을 일으켰다. 물론 지금도 엄청난 붐이 일고 있지만, 이 시기에는 챗지피티가 막 서비스를 시작할때였고 지구에있는 모든 사람들이 인공지능에 열광하던 때였다. 그렇기 때문에 우리 프로젝트에는 무조건적으로 인공지능을 넣기로했다. 그 다음은 사회취약계층을 저격하자였다. 이건 사실 어떤 공모전이든 대회이든 살짝 '가불기'로 적용되는 것 같았다. 이렇게 말하면 비판의 시선이 있을지 모르겠지만, 우리가 지금 스타트업으로 이 아이디어를 가지고 창업을 할게 아니다. 우리의 인생을 걸면서 돈을 쫒는 그런 프로젝트가 아니다. 단지 누군가에게 심사를 받아야하고 스토리텔링이 필요했다. 냉정하게 사회취약계층을 인공지능을 이용해서 문제를 풀어낸다면 이것만큼 좋은 스토리텔링거리는 없다. 우리팀은 조금 냉정해졌고 뭐하나라도 타오자라는 목표를 정했다.

# 초기 복실이 

 초기 복실이의 기획은 완성작과는 많이 달랐다. 복지사들이 피부양자들을 조금 더 쉽게 관리해주기 위해 중간의 매개체가 되는 수단이었다. 전에 진행했던 프로젝트에서는 꼭 위와 같은 페르소나를 만들었던 것이 인상 깊었고 딱히 아이디어를 도출하기 어려워서 가상의 페르소나와 상황들을 만들고 이어나갔다. 이를 통해 뭐가 필요해야할지 조금 보이는 느낌이었고, 한계점도 보였다.

초기 복실이에는 아래와같은 기능이 디벨롭 됐다.

• 여러명 관리하는 피부양자들을 복지사가 쉽게 관리할 수 있다. ( 서류를 뒤질 필요가 없다 )
• 휴가와 같은 이유로 피부양자를 다른 복지사가 방문했을때 해당일에 대한 복지기록이 제대로 인수인계 되지 않을 가능성이 있다.
• 식사시간에 방문하지 않는경우는 식사를 봐드릴 수 없다.
• 피부양자들이 어떤 음식을 좋아하고 어떤 음식을 싫어하고 어떤 음식을 추천해야하는지에 대한 도움을 손쉽게 받고 싶다.
• 복용 중인 약과 식단관리 등을 제공하고 싶다. 
• 어떤 운동이 필요한지에 대한 추천이 필요하다.
• 처방전을 사진을 찍어 등록하거나, 식사를 사진으로 찍어 등록하고 싶다.
• 나의 건강에 대한 분석리포트를 쉽게 제공하여, 복지사에게 좋은 가이드가 되고싶다.

 우리가 뽑아낸 위의 중요 아이디어들은 대부분은 이용자의 '데이터'가 쌓여야 한다. 인공지능이든 추천알고리즘을 사용하든 가장 중요한것은 해당 유저에 대한 데이터가 얼마나 쌓였는가이고 이에 따라서 정확도가 올라가는 것은 당연한 사실이다. 

 그러나 우리팀은 이 HOW에서 막혔다. 몸이 불편하고 비교적 연세가 있을 것인 피부양자들이 어떻게 스마트폰을 이용해서 데이터를 쌓을까? 이는 분명한 물리적인 한계점이다. 복지사가 데이터를 쌓게하는 좋은 대안이 있을 수 있지만 그들은 24시간 피부양자들의 곁에 상주하지 않는다. 복실이팀에게 1차 거대한 위기가 찾아왔다. 

 

# THE NEW 복실이

 복실이의 좋은 취지와 기획을 잇기 위해서 우리팀은 비상선언을 했고 이를 해결하기 위한 여러 방법을 강구했다. 결국 이용대상을 피벗팅하자는 의견이 채택됐다. 기존 복지사의 플로우는 부모님의 상태를 관제하는 자녀or보호자로 변경하고 앱의 여러 기능을 누리는 피부양자 플로우는 노인or부모님으로 변경했다. 

• 복지사 -> 자녀(보호자)
• 피부양자 -> 노인(부모님)

 우리가 선택한 방법은 사용대상을 조금 더 넓힌 것이다. 그리고 초점을 잡은 것은 "핵가족화", "중장년층의 스마트폰 사용 활성화", "의미 없는 건강 안부" 였다. 카톡으로 전화로 나누던 '데이터'가 없는 건강 안부가 아닌 복실이가 알려주는 건강정보를 언제 어디서든 연결된 보호자에게 모니터링을 제공한다는 취지이다. 

 이렇게 함으로써 데이터를 쌓는 주체를 거동이 불편했던 피부양자가 아닌 우리들의 부모님으로 전환시켰고 이로써 위에서의 HOW의 문제를 풀었다.

 ## 차별점

 중장년층이 스마트폰을 잘 사용한다고 하더라도 2030세대들보다 능숙치 않은 것은 사실이다. 그래서 우리팀은 복잡한 입력플로우를 모두 사진한장으로 대체 가능하도록 구현했다.

자세한 내용이 궁금하다면 깃허브 페이지의 시연영상들을 참고해라!

식단을 사진을 찍어서 이미지로 분석 받고, 처방전 사진을 찍어 약 정보를 공공데이터포탈에서 가져와 등록시킨다. 우리 앱에서 가장 복잡한 입력플로우는 운동 선택 -> 시간 입력플로우다. 터치 두번이면 끝나고 운동 종목도 많이 두지 않고 중장년층이 많이 이용하는 20개 종목으로만 추렸다.

 여튼 이렇게 차별점을 만들고 마지막 한방은 이러한 데이터들이 쌓인 것을 가지고 챗지피티를 이용해서 건강 피드백을 작성하도록 했다. 나름 마지막 한방의 펀치를 날린 것이다.

 그리고 자잘하게 등록되면 메일을 통해 알림을 보낸는 것으로 유저 편의 기능도 제공한다는 점을 강조했다. 사실 카카오톡을 통해서 유저에게 알림을 주고 싶었지만, 사업자 등록이 필요하고, 과금이 생긴다는 것을 알았고 그것에 대한 대체 수단으로 아래와 같이 메일을 통해서 알림을 보내도록 했다. 타임리프로 이쁘게 템플릿 만들고 안에다가 데이터 파싱하는데 꽤 많은 시간을 썼다는 것은 비밀이다. 그래도 나름 실제 서비스에서 보내지는 템플릿 메일의 완성도가 나왔다!

아무튼 이런식으로 대상을 피벗팅하고 문제들을 자연스럽게 이야기가 가능하도록 풀어나갔다. 기능에대해 궁금한점은 깃허브페이지스를 참고하면 동영상(맨 밑에도 첨부해놨다)도 있고 이해하기 편할 것이다!

 

# 무엇을 했는가?

복실이 프로젝트를 하면서 무엇을 얻을 수 있었는지 무엇을 느낄 수 있는지에 대해서 적어본다.

## 회의는 너무 많고 문서화할 것도 너무 많다.

회의록 명단의 극히 일부분

 왜 회의 방법에 대한 방법론이 존재하는지 애자일선언에서 문서화보다 행동(코드)가 먼저라고 강요했는지 몸소 느낄 수 있었다. 일단 초기 단계에서는 정말 결정해야할 것도 많고 5명의 의사가 명확히 반영되어야 하기 때문에 회의도 너무 많고 너무 길어졌다. 또 팀별로 작은 회의도 계속해서 생기다 보니까 팀모두의 지향점이 점점 벗어나는 느낌이 들기도 했다. 

 우리 배가 과연 산으로 가는 것은 아닐까하는 확인이 필요했고, 회의 방법에 대한 개선이 필요하다는 생각을 했다. 회의를 빨리 그리고 효율적으로 진행하기 위해서는 무엇이 필요할까 고민도 해봤고, 그때 학교 선배님을 따라서 스타트업에 방문해서 인터뷰를 할 수 있는 시간이 있었다. 거기서 어떻게 회의를 진행하는지 궁금했던것들을 여함없이 보고 배워왔다. 

노션에 안건을 등록하면 Owner가 정리했다

 우리는 매주 정기회의일마다 담당하는 Owner를 정했다. 그리고 주차별 회의 안건 페이지를 만들고 해당 페이지에 각자의 안건을 올렸다. Owner는 회의 2일(최소 1일전)에 이 안건을 종합 정리하여 우리들에게 공유하고 회의전에 안건들에 대한 의견을 생각해온다. 회의를 하면서 무엇인가를 생각하기 보다는 회의시간에는 5명의 의견을 교류할 수 있는 효율적인 시간으로 바꾸기 위해 노력했다. 또 Owner는 회의의 사회자 역할을 하는과 동시에 서기의 역할을 맡으며 모든 내용들을 기록하도록 했다.(Owner가 말하고 싶을때는 다른 사람이 눈치것 적어줬다) 이렇게 함으로써 회의가 끝나고 난후에도 문서화가 되어 나눈 의견들이 휘발되지 않도록 했다.

 결국 이런 문서화는 최종 발표회에 쓰이는 발표자료와 발표보고서를 작성하는데 더욱 체계적이고 조밀하게 완성도 높은 보고서를 작성하는데 도움이 됐으며 시간적으로 많은 시간을 아낄 수 있었다.

 

## 애자일 비스무리한 것

[클린소프트웨어#1] 애자일(Agile) 방법론과 4가지 가치와 12개의 원칙

 3학년 말미와 4학년이 되면서 소프트웨어 공학에 대한 관심이 많아졌었다. 그래서 소프트웨어 디자인패턴도 공부해보고 소프트웨어공학 교과목도 수강했었다. 애자일이 강조하는 가장 첫번째는 "고객의 요구사항은 항상 변한다"였다. 그렇기 때문에 변화에 유연해야하며, 분업화가 잘되어야한다. 또 WaterFall방식으로 모든 기획을 끝내는 것도 아니라 작은 단위로 나누어지면서 계속 디벨롭되어야 한다는 것이다. 그러기 위해서 SOLID원칙을 준수하면서 개발을 하고, 고객의 요구사항을 팀원 모두가 정확히 이해하고 도메인 모델링을 진행해야한다는 것이었다. 빠르게 견고한 소프트웨어을 제작 할 수 있는 하나의 방법론이라는 것을 알 수 있었다.

 우리팀이 개발을 계속 진행해 나가면서 여러 제약사항들이 부딪히면서 원래 기획과 변경되는 점들이 너무 많았다. 프로젝트 초기에는 이러한 것들에 모두 대응하기 위해서 큰 계획을 계속해서 잡았지만, 결국에는 미래에 생길 불확실함에 대응한다는 것이 더 많은 제약사항을 만들었다. 그래서 우리팀은 일단 부딪히고 개발하다가 제약사항이 나오면 팀원 전체가 회의를 하고 빠르게 수정하고 반영했다. 내가 구현했던 카카오톡을 통한 알림기능을 메일로 대체했던것도 많은 것들 중 한가지였다.

 이러한 점들때문에 개발단위가 어쩌다보니 애자일에서 흔히 말하는 '스크럼'단위가 됐다. 주마다 팀 전체회의를 가졌는데 이때마다 이슈내용을 공유했고 새로운 작은단위의 개발을 각자에게 부여했다. 데일리 스크럼미팅(Scrum Meeting)을 정해놓고 가지지는 않았지만 친한친구들이다 보니까 단톡방에서 하루에 한번씩은 개발 관련되서 자동적으로 이야기를 나누었다. 결국 우리팀만의 애자일 비스무리하고 스크럼 뭐시기가 형성됐다. 

  4학년 학부생따리 슈퍼 주니어 개발자 김호준은 이를 보고 한가지 느낀것은, 동물이 살아남기 위해 진화하고, 인간이 새로운 환경에 적응하듯이 애자일 방법론도 결국에 SW개발을 하면서 마주치는 문제점들을 더욱 효율적이게 처리하기 위해서 진화하고 적응된 형태가 아닌가라는 생각이 들었다. 우리팀도 "체계적으로 스크럼을 만들고 이렇게 하자!"가 아니라, 그냥 계속 바뀌는 요구사항과 제약사항 그리고 학기중 수업과 병행하면서 짧은 기간동안 빠르게 개발해야하는 현상황을 효율적으로 처리하기위해서 조금씩 규칙을 만들고 바꾼 것이다. 그리고 뒤돌아보니 이게 애자일 비스무리한것이었고, 스크럼 뭐시기였다. ( 물론 나는 애자일에 관심 많아서 꼭 프로젝트에 체계적으로 적용해보고 싶었던 소망이 있었다ㅠ)

## 팀원이 무엇을 하는지 아는 것(feat. GitHubFlow)

 팀원이 무엇을 하는지 아는 것은 작은 단위의 팀에서 더 중요한 것 같다. 팀원이 배정된 임무가 없거나, 개발이 길어지면 팀원 전체가 이점을 공유받고 빠르게 해결하기 위해서 노력해야하기 때문이다. 대체로 주간 회의에서 각자의 임무가 배정됐으나, 배정된 임무안에서도 여러 단위로 나뉘기도 하고 실제로 지금은 어떤 개발을 하고 있는지 알필요가 있었다.

 노션의 멋진 UI를 이용해서 내가 하는 일들을 계속해서 드래그 해놓는다면 이처럼 이상적인것은 없을 것이다. 실제로 초기에는 이렇게 해보자 했지만 막상 개발을 진행하니 여기서 드래그앤드롭하는 것도 너무 귀찮았다. 그러다보니 최신화가 됐는지 알수도 없고 결국 의미 없는 타임보드가 됐다. 조금 개발자스럽게 이것을 한번에 처리하면 좋을 방법이 없을까 고민했다.

 우린 깃허브의 이슈(ISSUE)와 PR(PullRequest)기능을 조금 더 적극적으로 활용해보기로 했다. 우린 GitHubFlow를 채택하여 개발하고 있었다. 여기에 우리팀의 컨벤션을 만든다면 팀원들이 지금 무슨 개발을 하고 있는지는 알 수 있을 것 같았다.

그래서 우리팀은 먼저 개발을 해야하는 일이 있다면 해당 건에 대한 이슈를 필수로 작성하게 했다.

 그리고 해당 이슈에는 위와 같이 구현내용들에 대한 ToDo를 만들고 설명을 적었다. 그리고 브런치명을 아래와 같이 작성하여 생성하도록 했다. back/#이슈번호와 같이 생성하고 개발이 끝나면 해당 브런치를 PR하고 머지 된다면 바로 삭제하도록 했다. 이렇게 함으로써 팀원들이 지금 무엇을 개발하고 있는지 알 수 있었다. 노션의 이쁜 UI도 좋지만 결국 편한게 장땡이다. 어차피 깃허브를 활용해서 협업해야했기 때문에 딱히 번거롭지는 않았다. 

 더군다나 백엔드 팀원과 협업하면서 develop브런치에 머지하면서 한번도 충돌이 난적이 없었다. 그만큼 분업화가 잘 이루어졌고 깃허브를 잘 활용할 수 있었던 것 같다.

 웃긴건 우리팀이 프로젝트를 끝냈을때 이슈가 101개 PR이 119개였다. 무슨 이슈제조기들도 아니고.. 컨벤션에 맞춰서 다들 열심히 분업한 결과라고 볼 수 있다.

 

## 배포자동화

 CI/CD를 구축하고 프로젝트에 적용하기 위해서 프로젝트 초기에 어떻게 해야할지 구상을 했었다. 왜냐면 사실 그냥 해보고 싶었던게 크다. 동아리 해커톤에서 이거 구현해서 파이프라인을 보여주는데 꽤 멋져보였기 때문이 크다. 그래서 해커톤 학기초 교수님께 가서 뭐로 구현하면 좋은지 여쭈어 봤었다. 이전에 젠킨슨할아버지로 구현하는걸 봐서 공부했는데 막히는 부분도 있고 아키텍처가 구상이 안갔었기 떄문이다. 그래서 도커로 환경 만들고 이전 프로세스 죽이고 새롭게 배포되는 시스템을 배포시키되 이전 버전을 남겨두라는 아키텍처적인 조언을 받았다. 근데 교수님께서 말씀해주시기를 지금 만들기보다는 필요하면 배포자동화를 구축하여 적용을하라고 하셨다. 굳이 안써도 되는데 쓰면 그거자체로 시간낭비라고 말씀해주시는데 너무 크게 와닿았다. 요즘 뜨는 MSA설계도 대용량 트래픽을 더 잘 감당하기 위해서 MSA로 시스템이 바뀌는거지 애초에 MSA를 고려해서 설계하는것도 낭비다라는 말을 들었는데 그말이 문득 스쳐지나갔었다.

 그래서 프로젝트 초기에는 DB모델링하고 요구사항을 분석하는데 시간을 많이썼고 API서버가 올라가지 않았기 떄문에 딱히 필요가 없었다. 그러나 중-후반부에 계속해서 API만들어주고 수정해줘야하는 필요성이 있었고 그럴때마다 로컬에서 빌드해서 scp로 .jar파일 쏴준다음에 이전 프로세스 죽이는것도 한두번이지 너무 귀찮았다. 

AWS는 신이다.

 그리고 무엇보다 빠르게 배포자동화 환경을 만들어야 했고 젠킨스를 내가 공부하기에는 부족한 시간이 분명했기에 Github Action, AWS S3, AWS CodeDeploy를 활용해서 자동화 환경을 구축했다. 타겟 브런치에 풀리퀘 검증이 끝나고 머지된다면 테케를 다 통과한다면 자동으로 배포가 이루어졌다. 

 처음 이러한 환경을 구축하고 이러한 환경속에서 개발을 해봤는데, 정말 말도 안되게 편리했다. 개발환경으로 신경쓸 필요 없이 브런치파서 개발하고 합치면 끝나기 때문이다. 그리고 수정사항에 대해서 프론트를 작업하는 팀원들도 빠르게 받아볼수 있기때문에 팀원 모두의 만족도가 높았던 것 같았다.

 아무튼 배포자동화를 구축하면서 '필요에 의해'서 무엇인가를 해야한다는 점을 절실히 느꼈다. 그래야지 그것에대한 만족감도 있고 시간도 아낄 수 있기 때문이다. 너무 감수성없는 실용주의자가 되는것만 같아서 조금은 내자신이 싫지만, 그래야지 내가편한것임을 느낄 수 있었다.

 

# 아무튼

 아무튼 최종발표도 성공적으로 끝내고 운좋게 본선까지 올랐다. 본선에서 또 운좋게 1등상을 받을 수 있었다. 물론 누구보다 열심히 했기 때문에 딱히 과분하다는 생각은 팀원 모두가 하지 않았다. 우리 학교에는 이렇게 캡스톤 프로젝트를 전시하고 교수님+학부생들이 돌아다니면서 궁금한것도 물어보고 대답해준다. 본선에서는 교수님 + 외부평가단이 합쳐져 대면발표를 하고 질의를 받았고 예상질문도 미리 대비했기에 잘 대답할 수 있었다.

 아무튼 프로젝트 시작할때 무조건 상타자라는 우스갯소리를 실제로 이룰 수 있었던 값진 순간이었다.

 

# 후기는?

•  먼저 협업을 위해 고민해보고 개발환경에 집중하기 위해 여러 노력을 기울였던 점에서 대단히 큰 경험을 한것 같다.
•  다만 건강점수를 분석하여 계산하는 비즈니스 로직의 경우의 도메인 지식도 너무 부족했기에 조금 아쉬웠다. 멘토링 요청해서 받으면서 답을 찾아보려 했지만 역시 쉬운게 아니었다. 이점은 아쉬웠다.
•  실제 서비스 사용자가 없었다는 점도 아쉽다. 캡스톤이 어떻게 보는 평가를 위한 자리이지, 실제 유저층을 겨냥하는 것이 아니었기 때문이다. 실사용자에 대한 갈망이 있다.( 이후 현대백화점에서 인턴하면서 실제 50명 유저가 사용하는 서브시를 만들 수 있었다.)
•  멘토링 받으면서 어드민 페이지를 꼭 만들어야한다고 멘토님이 조언해주셨는데, 너무 바쁘고 실 사용유저도 없기에 구현하지 않았다. 그러나 이번에 현대백화점에서 인턴하면서 느꼈다. 운영단계에서 제일 중요한건 어드민 페이지인거 같다.
•  해보고싶었던걸 해보고 적용해서 좋았다. 실제 JWT를 이용한 소셜로그인, OpenAI의 Chat-gpt를 활용해보기, 이미지 OCR, Kakao Vision을 이용한 이미지 인식 등등 특히 최신 기술로 하여금 유저가 와닿는 서비스를 기획하고 개발했다는 점에서 너무 재밌었다.
• 이후 프로젝트에서는 JWT개발했던 경험을 발전시켜, 스프링 시큐리티를 활용하고 Rfresh-token을 활용하게 하는 로그인 시스템을 구축하는데 큰 도움이 됐다. 
• 뭔가를 필요에 의해서 적용하고, 단계적으로 발전하고 성장하는 느낌을 받았던 재밌고 의미있었던 프로젝트였다.

 

# 발표영상