개발자로 후회없는 삶 살기
SW bootcamp PART.팀 Project 1주차(팀 빌딩, 주제 브레인스토밍) 본문
서론
팀 프로젝트 1주차 내용입니다.
본론
1일차(1.30)
- 정할 것
1) 데일리 미팅 : 매일 온라인 오전 10시, 오후 3시
2) 대면 미팅 요일 : 일주일에 2번 화, 금요일 픽스
3) 보고서 작성 방식 : 쓰기로 한 날 모두 온라인으로 모여서 부여된 파트 작성
-> 보고서는 어떤게 필요할까?
① 프로젝트 계획서
② 요구사항 명세서
③ 프로젝트 설계도(구성도)
④ 다이어그램(시퀀스, 클래스)
4) 협업 툴 : 형상관리 = 깃, 레드마인 / 스케쥴 = 지라, 노션
5) 역할 : 김지훈(팀장) / 한상범(데일리 미팅 기록)
6) 주제
-> 문제점 : 주제를 정하는데 팀원 모두 너무 모르는 분야다 보니 확실히 감이 오는 주제가 없었습니다. 거의 오전 9시 반부터 오후 4시 반까지 이렇다할 주제 없이 토의를 했습니다.
-> 후보
① AI 의료 진단 플랫폼 : nlp, cv 기술을 전부 활용하여 통화 의료 진단, X-ray 진단, 자세 진단 등 할 수 있는 진단은 전부 넣은 플랫폼 개발
② 약제 분석, 혼용금지 약물 알림 AI : 보유한 알약을 이미지 업로드하면 같이 먹으면 안되는 약을 알려줍니다.
③ 비건 식단 추천
④ 의학용어 번역 : 의사들만 이해하는 어려운 의학용어를 일반인도 이해할 수 있도록 번역합니다. 영어에서 한국어가 아니라 의학용어에서 쉬운 용어로 번역입니다.
⑤ 새로운 질병 대비 AI 모델 개발 : 10년에 한 번씩 터질지도 모르는 팬데믹을 미리 예방하기 위한 AI를 개발합니다.
⑥ 삶의 질을 올려주는 힐링 음악 추천
-> 시행착오
이번 프로젝트에서 처음으로 느낀 감정이 있습니다. 각자 역할은 나눠서 진행을 하였는데 AI 프로젝트이다보니 모든 주제 선정에 딥러닝 개발자의 능력과 취향이 들어가야 한다는 것입니다. 정말 신기한 경험이었습니다. 주제를 정하는데 모두 저만 바라보고 제가 말할 때마다 엄청 이목이 집중되었습니다. 현업에서도 각자 맡은 파트만 수행한다고 하는데 만약 이렇다면 제 능력을 더 키워야 함을 강력하게 느끼는 하루였습니다.
-> 확정 : 그러다가 검색 도중 맞춤형 헬스케어 서비스를 알게 되었고 요즘은 온라인으로 맞춤 서비스를 제공하는 것이 좋은 성과를 내고 있는 것 같아서 선택하고자 하였습니다. 저희 팀이 컴공이 많아서 개발은 문제없이 할 수 있을 거란 자신감이 있었습니다.
> 하지만 검색해서 찾은 서비스를 그대로 만들 수는 없었기에 후보중에 투표 1위를 했던 약제 맞춤형 서비스를 만드는 방향으로 갔습니다. 이 또한 잠시 후 팀원 모두 약에 대한 지식이 없기에 스택업보다는 노가다의 향기가 난다고 말하기 시작했고 최종적으로 거북목 감지 시스템을 알게 되어 거북목 맞춤형 헬스케어 서비스를 주제로 선정하였습니다.
2일차(1.31)
- 주제 정하기 2차
1일차에서 정한 주제를 대상으로 구체화하기 위해 데이터를 찾아보았습니다. 하지만 거북목 데이터는 일체 존재하지 않았습니다. 크롤링을 해볼 생각을 했지만 저작권 문제로 좋은 방법으로 보이지 않았습니다. 그러다 관련 논문(참고 1)을 알게되어 읽어보니 총 500장의 사진을 실제 저자들의 사진으로 찍어서 구축하였고 데이터 증강을 하여 2500장으로 늘렸다고 했습니다. 저희 총 인원이 7명으로 70장 씩 준비하면 500장을 충족할 것이라고 생각해서 그렇게 진행하려고 했지만 논문에서 모델 정확도가 낮게 나온 것이 부족한 데이터와 5배로 증강하여 발생한 과적합이라고 생각했습니다.
> 따라서 데이터가 존재하는 다른 감지 서비스를 생각해보기로 했고 팀원분 중 한 분이 AIHUB의 얼굴 감지 데이터를 말씀해주셨습니다. 그때 제 아이디어가 번뜩했습니다.
-> 웹캠으로 실시간으로 표정변화를 받고 감정을 평가해서 실시간으로 노래를 선곡해주자는 것입니다!
거기에 맞춤형 서비스를 제공하기 위해 하루의 기분을 종합하여 감정 지수를 만들고 '오늘은 이런 노래로 하루를 마무리하는 건 어때요?'라던가 한 주의 노래를 추천해 주는 것 입니다. (추가로 맞춤형 서비스에 맞게 상담사를 연결해 준다 거나 기분 좋아지는 레시피를 보여줄 수도 있습니다.)
-> 추상적인 부분
하지만 팀원 한 분이 좀 추상적인 느낌이 든다고 하셨습니다. 따라서 확실히 해야할 부분이 2가지 생겼습니다.
1) 표정을 정확하게 평가해야 함 : 기분 좋은 사람에게 화났다고 하면 X
2) 물리적인 헬스케어가 아닌데 좋은 평가를 받을 수 있을지 확실하지 않음 : 멘탈케어로 강하게 말하면 됨
위 두가지 문제를 팀원들의 의견을 통일하여 해결한 후 주제를 확정, 선정하게 되었습니다!(이제 정말 할 일만 남았습니다!)
- 타임라인
이제는 프로젝트 기획서를 작성할 시간입니다. 동아리에서 프로젝트를 진행할 때도 그렇고 이번에도 그렇고 저는 타임라인에 대한 감각이 너무 없었습니다. 텍스트로 (1주차 : 개발 > 2주차 : 개발) 이렇게 쓰려고 했는데 선배님들께 혼났습니다. 최초 기획서에 들어갈만큼 타임라인의 중요성을 알게 되었고 타임라인은 노션 달력 템플릿처럼 캘린더 형식이 제일 좋다고 생각합니다.
- 깃허브 형상관리 규칙
이 부분은 처음 안 사실이 많습니다. 개발자에게는 필수인 매우 중요한 부분이니 강조하겠습니다!!
1) pr 규칙
깃허브에 Branches에 branch를 관리할 rule을 정할 수 있습니다. people을 2로 하면 pr을 했을 때 두 명 이상 허락해야 merge가 가능하도록 할 수 있습니다. 데일리 미팅인 매일 오후 3시에 다 같이 merge하기로 했습니다.
2) branch 규칙
팀원 분께서 기능 개발 브랜치의 경우 feat, 기능 개발인데 로그인이면 feat/로그인 이런 식으로 브랜치 명을 잡아왔다고 하셨습니다. 모든 규칙과 설계, 기능, 규칙은 내일(3일차) 세세하게 기능을 잡을 때 jira에 적어두기로 했습니다. 이제 모든 것을 jira에 적을 것 입니다. jira를 노션처럼 생각하고 잘 관리해 보면 매우 좋은 경험이 될 것이라고 생각합니다.
- ML 필요한 기술 정리
=> 얼굴 표정 감정 인식
-> 이미 있는 모델 사용하기(참고 1)
참고 1을 보면 코드와 모델이 주어지기 때문에 그냥 가져다 사용하면 되지만 프로젝트 의의가 떨어집니다.
-> FER fine tuning(참고 2)
FER 알고리즘대로 모델을 제 데이터에 맞게 학습시킬 수 있으므로 좋습니다. 하지만 FER 모델은 너무 흔하게 사용됩니다.
-> 강사님이 원하시는 방식
강시님께서는 FER은 너무 흔하다고 웃는 얼굴이면 미소를 지었기 때문에 웃는 얼굴이다. 화난 얼굴이면 눈쌀을 찌푸렸기 때문에 화난 얼굴이다 등을 제시해 줬으면 좋은 평가를 받을 수 있을 거라고 하셨습니다.
이것은 제가 구상한 모델로 얼굴에서 눈과 입만 탐지하여 눈과 입의 바운딩 박스 크기로 웃고 있음을 알아차리거나 pose를 추가하여 눈이 구부러니는 각도를 알 수 있게되면 눈웃음이나 찡그린 것을 알아차릴 수 있을 거라고 기대합니다. 모델도 수정해보고 공부도 많이 할 수 있을 것이기에 시간이 되는 한 이대로 진행하고자 합니다.
3일차(2.1)
- jira
jira에 대하여 팀원들에게 설명하는 시간을 가졌습니다. 스크럼 방식의 보드를 jira를 통해 수행하는 방법을 보여드리니 모두 만족하셨고 jira로 협업을 하기로 최종 결정하였습니다.
스커럼 방식은 프로젝트를 기획할 때 전체 일정을 다 짜야합니다. 따라서 기능(ex. 로그인)을 모두 구상하고 모든 세부 이슈를 다 짜놓자고 하셨습니다. 아직 기능회의를 끝내지 못한 상황이라서 설계, 기능, 다이어그램 등을 완료하고 스프린트 전체 일정을 다 짜겠습니다.
- 발표 피드백
오후에 프로젝트 기획 내용을 발표하고 피드백을 받았습니다. 피드백 내용을 정리해 보겠습니다.
1. 강사님의 경우 업무를 할 때 무표정으로 하신다. 기분이 좋아도 무표정이고 나빠도 무표정이다. 따라서 표정 변화로 기분을 측정 못 할 것을 대비하여 웨어러블 아이템을 활용한 심박수 등을 고려해보면 좋을 것이다.
2. 플라스크 서버와 스프링 서버의 데이터 흐름 구조를 잘 표현해줬으면 좋겠다.
-> 피드백에 대한 답변
1. 저희도 동의 하였습니다. 어느 정도 개인적인 생각일 수 있지만 맞는 부분도 분명 있다고 생각합니다. 따라서 여러가지 방법을 생각하였습니다.
1) 앱을 시작하고 중간중간에 기분에 대한 질문을 하자 : 이건 너무 과한 설정인 것 같다고 판단하였습니다.
2) 처음 가입하면 취향을 설문 받고 표정변화가 없을 땐 취향에 맞는 노래를 틀어주다가 표정 변화가 있을 때만 노래 추천을 해준다. : 팀원분께서 스마트워치를 예로 들었습니다. 스마트워치도 심박수가 올라갈 때만 알림을 줍니다. 하지만 그 기능만 있었으면 사용하지 않았을 것이고 다른 여러 기능도 제공하니 사용하는 것입니다. 만약 저희 서비스가 표정 변화가 있을 때만을 위해 계속 접속해야하는 것이라면 사용할 이유가 없을 것이라고 합니다.
3) 제가 생각한 방법으로 미묘한 감정 차이도 체크하는 것입니다. POSENET을 활용한 방법으로 2일차에 구상한 방법인데 반드시 이쪽으로 진행해야만 해 졌습니다.
-> 느낀점
요즘 프로젝트를 하면서 굉장히 고객 마인드로 많은 생각을 해보는 것 같습니다. 특히 이번 프로젝트는 졸업하신 선배님들과 함께해서 더욱 그렇습니다. 매우 좋은 경험이기에 기분이 좋습니다!
2. 구조도 설명
1) 깃, 깃 액션 : 무중단 배포
2) 네모 : 모두 다 따로 컨테이너로 구동됩니다.
3) 게이트웨이 : 리엑트와 안드로이드에 얼굴 인식 모델을 둘 다 올려야하고 그 결과를 플라스크 AI 서버로 보내서 플라스크에 있는 노래 추천 알고리즘을 돌려 다시 안드로이드와 웹에 보내줍니다. 스프링은 추가 기능(감정 지수, 로그인)을 위해 필요합니다. 스프링과 플라스크에서 안드로이드랑 웹으로 Get-Post 방식으로 데이터를 줍니다.
-> 느낀점
1) 질문 : "왜 노래 추천 알고리즘이랑 얼굴 모델이 다른 곳에 위차합니까?" 라는 질문을 했습니다. 원래 다 플라스크에 두는 것이 맞다고 하십니다. 하지만 실시간 처리를 위해서 서버에 부담을 주는 것이 별로이고 모두의 기술을 활용해 보고자 일부로 나누어 위치하였다고 합니다.
2) 진짜 개발자들과 대화하고 프로젝트하는 기분으로 모르는 용어도 너무 많고 배우는 사실도 너무 많습니다. 기분이 너무 좋습니다!! 화이팅해서 정말로 열심히 해야겠습니다~
4일차(2.2)
- AI의 정체성
1. 추천 시스템과 SQL 필터링의 차이
1) SQL : 행복한 기분을 입력으로 넣으면 조건문으로 "happy"라면 SQL SELETE로 happy한 노래 리스트를 보여주는 것
2) 추천 시스템 : 결론을 다른 사용자 기록이 필요합니다. 현재 추천을 받을 사용자가 있을 때 그 사용자의 기록과 유사한 다른 사용자가 본 contents를 추천합니다. happy한 노래를 많이 듣는다면 happy한 다른 사용자가 들은 유사한 content를 추천하게됩니다.
2. 회귀와 SQL의 차이
1) SQL : 예측을 하는 것이 아닌 DB에 있는 값만 출력
2) 회귀 : 이미 존재하는 데이터가 아닌 없는 데이터에 대한 값을 출력
> 추천 시스템에 대해 팀원 분들께 정리하는 시간을 가졌습니다.
- 기능, 설계, 규칙 정한 것
1. 설계
1) 서비스에 따른 구조도 설계
2) 서비스에 따른 요구사항 명세서
3) 시퀀스 다이어그램
4) ui 디자인과 설계
5) 설계를 기반으로 한 관계형 데이터베이스 설계
2. 기능
1) 로그인 : 스포티 api를 하기 위해서 필요하며 로그인 DB를 두어 사용자의 감정 데이터를 관리하기 위함
2) 웹 캠 띄우기 : 영상 데이터는 바로 얼굴 인식 모델에 입력됨
3) 노래 추천 : 백엔드에서 노래 추천 결과를 사용자에게 보여줌
4) 노래 추천 안할 시 : 사용자의 플레이 리스트를 보여줌
-> 이때 필요한 고민 : 사용자의 플레이 리스트를 틀어주다가 노래 추천을 해서 추천 노래를 틀거나 추천 노래가 끝나서 다시 돌아가야 할 때 어떻게 할까?
① 추천 노래가 끝나면 플레이 리스트 중 랜덤으로 다시 틀어준다.
② 노래를 추천할 때는 추천한 노래를 최우선으로 듣고 있던 노래를 끊고 틀어준다. or 사용자 플레이리스트 맨 위에 끼워넣는다.
5) 사용자 감정 분석 : 사용자의 감정 변화, 감정 지수 등을 보고서로 보여주는 페이지(추가 서비스 : "오늘 하루는 기분 좋은 하루였네요^^ 차분한 노래로 하루를 마무리 해보세요. or 기분이 나쁜 한 달이 유지되면 상담사를 안내해준다.)
- 일정
1) 서버, 프엔, DB, ML 각자 지라 작성하고 스프린트 데일리 미팅 때 종합
2) 프엔 분들이 UI 짜주시면 그에 맞춰서 구성
> 이제 기틀이 잡혔습니다. 3주 중에서 4일을 프로젝트 기회, 발표에 사용했습니다. 이제 진짜로 구현을 하는 시간을 가지겠습니다.
-> 딥러닝 개발자로서의 오늘 할 일
1) ML 수행
2) ML 부분 jira 작성
3) 멜론 크롤링 견적 보기
5일차(2.3)
오늘은 1주 동안 구상한 아이디어를 기업 멘토링 시간에 피드백을 받았습니다. 또한 저희 팀은 추가로 맞춤형 서비스에 제공할 아이디어 회의를 진행하였습니다.
- 피드백
1. 찰나의 순간 표정을 읽어 낼 수 있을까?
2. 인풋 프레임 간격 고려할 것
3. 기능 구현이 우선이다. 마지막에 성능 신경쓰는 걸 추천
4. 신뢰성 있고, 가용성 있는 백엔드를 탄탄하게 할 것
5. 경량화 성능은 많이 안 떨어질 것으로 예상된다. (오히려 모델 input이 더 중요할 것 같다.)
6. input이 과했거나, 모바일 성능이 더 좌지우지 할 것으로 예상
-> 느낀점
멘토님들은 정말 대단하신 것 같습니다. 저희는 한가지 주제를 정해서 엄청 많은 고민을 하고 질문한 것인데 멘토님들은 7팀의 주제를 모두 케어해 주시고 모든 질문마다 도움이 되는 답을 해주십니다. 질문을 하는 과정에서 많은 것을 생각할 수 있어서 노하우를 쌓을 수 있고 답변을 받음으로써 새로운 지식과 노하우를 전수받을 수 있습니다. SW 부트캠프를 멘토링 때문에 신청한 것인데 정말로 잘 선택한 것 같습니다.
- AI 부분 피드백
강사님께서 옛날에 진행하신 경험이 있으셔서 표정을 인식하는 방법을 말씀해 주셨습니다. 일반적으로 posenet을 재학습하는 것보다 표정인식은 face alignment로 한다고 하십니다. 관련 링크를 전달받아 조사해 보았습니다.
face alignment로 표정을 인식하는 방법이 무엇인지 궁금하였습니다. 좌표 align을 봤을 때 행복한 align이 있고 화난 align이 있는지 의문이었습니다.
> 정답은 제가 오해한 사실에서 시작됩니다. 사람 얼굴 면적에 따라서 랜드마크의 개수가 달라질 것이라고 생각했는데 랜드마크의 개수는 정해져있고 위치 또한 정해진 것이었습니다. 강사님께서 주신 링크와 조사한 바에 따르면 랜드마크의 위치가 정해진 것이니 이 좌표를 활용하여 표정을 인식하는 알고리즘이 있습니다.
> 이렇게 되면 posenet을 하지 않아도 눈과 입의 모양을 캐치할 수 있고 눈과 입만 있지 않아도 랜드마크 거리 계산으로 표정을 분류할 수 있습니다.
-> 최종 AI 방법론
1) 분류 모델 사용
2) face alignment 수행
3) posenet은 나중에 생각하기
최종적으로 정한 모델은 위와 같습니다. 1)은 성공하였으니 2)를 빨리 수행하겠습니다.
- 아이디어 회의 안건
1. TTS를 넣자
2. 타임랩스 형식으로 기록하여 일기처럼 저장하자
3. 슬플 때, 기분좋을 때, 헤어졌을 때, 봄일 때 등등 기분에 따라 다른 list를 제공 할 수 있게 하자
4. 노래만 추천하지 말고 영화나 소설도 가능하다.
5. 음성인식으로 틀어드릴까요? 물어보고 예/아니오 대답으로 자동 재생해주기
6. 영상 재생 중에 자신의 기분을 이모티콘으로 알려주기
결론
AI 부분에 점점 더 많은 기능이 주어질 것 같습니다. 처음에는 얼굴 인식과 추천 시스템이었지만 TTS가 추가될 것 같습니다. 이번 멘토링과 프로젝트로 AI 측면에서도 배우는게 많고 개발과 협업에도 많이 배웠습니다. 빨리 AI 파트를 끝내고 개발에 참여하고 싶습니다!
참고
'[대외활동] > [네트워크형 캠퍼스 아카데미]' 카테고리의 다른 글
SW bootcamp PART.팀 Project 중간 점검 (0) | 2023.02.09 |
---|---|
SW bootcamp PART.팀 project 2주차(모델 조사, 선정) (0) | 2023.02.05 |
SW bootcamp PART.팀 Project 1일차(프로젝트 시작) (0) | 2023.01.30 |
SW bootcamp PART.도커 AI 활용 (0) | 2023.01.26 |
SW bootcamp PART.개인 Project 3주차(flask 서버 구축, streamlit) (0) | 2023.01.25 |