SW bootcamp PART.팀 Project 중간 점검

서론

프로젝트 2주차에 다다르면서 AI 파트는 어느 정도 알고리즘 틀도 잡혔고 학습도 안정감을 갖췄습니다. 이제 제 꿈은 Aiaas를 위해서 개발에 협조할 생각입니다. 협업 기술, 개발 노하우 등을 선배들에게 여쭤보고 모두 제 것으로 만들 것입니다. 

 

그 전에 지금까지 진행된 상황을 정리하고자 합니다.

 

본론

이 프로젝트에서 제가 맡은 파트는 딥러닝 개발자이지만 전체 목적은 서비스를 개발하는 것이기 때문에 Aiaas라고 할 수 있습니다. 그렇다면 Aiaas가 프로젝트를 진행할 때 어떤 것들을 생각해야 하는지 경험한 것을 정리해보겠습니다.

 

- 프로젝트 기획 단계

※ 요구사항이 없는 일반 팀 프로젝트의 경우 이 단계에서 리서치가 매우 중요하고 시간을 많이 투자해야 합니다.  (주제를 구체화 할 때 데이터가 없거나 구현이 불가능하여 다시 아이디어 thinking 단계로 갈 수도 있습니다.)

1. 프로젝트 주제

=> 아이디어 thinking

=> 아이디어 선정

 

브레인 스토밍을 통해 아이디어를 생각하고 선정합니다. 타당성 분석, 방법론 검증 등으로 인해 이 과정이 시간이 매우 많이 소요됩니다.

 

2. 협업 방식

협업은 류태선 강사님께서 전수해 주신 방법과 선배님들께서 캡스톤 때 하셨던 방식으로 진행합니다. 

 

1) 데일리 미팅 : 매일 오전 10시, 오후 1시 반
2) PR : 오후 4시 반 -> 백엔, 프엔, DB, ML 각자 지라 작성하고 스프린트 데일리 미팅 때 종합 및 일일 보고서를 한 명이 서기를 담당하여 작성

3) 주간 목표 정하기 : 매주 금요일
4) 보고서 작성 방식 : 쓰기로 한 날 모두 모여서 부여된 파트 작성 등

※ 필요한 보고서
ⓛ 프로젝트 계획서, ② 요구사항 명세서, ③ 프로젝트 설계도(구성도), ④ 다이어그램(시퀀스, 클래스)

5) 역할 : 팀장, 데일리 회의록 작성(개개인의 오늘 한 일, 추후에 할일을 적고 팀의 목표, 일정 변동 사항 등을 적음) 등

6) 협업 툴 : 형상관리 = 깃, 레드마인/ 스케쥴 = 지라(프로젝트 페이지에 자료 공유 공간 준비), 노션 등
7) 타임라인 작성

 

3. 깃허브 규칙

1) pr 규칙 : 몇 명 이상이 허락해야 merge 가능하도록 등

2) branch 규칙 :

① 기능 개발 브랜치의 경우 feature, 기능 개발인데 로그인이면 feature/로그인 등

② merge는 브랜치에서 더 이상 버그가 일어날 일이 없다고 생각되면 하고 그 전에는 커밋, 푸시만 하는 것이고 버그 추적도 끝나고 pr도 하면 브랜치를 삭제해야한다.

 

+ 이런 규칙들을 원래는 노션에 적겠지만 지라만 활용할 경우 지라에 저장할 공간을 만들고 전부 다 지라에 기록할 수 있도록 하면 좋겠다. 또한 jira에도 노션 같은 달력 템플릿이 있어서 타임라인도 작성할 수 있습니다.

 

4. 주제 구체화

먼저 주제가 정해졌으면 데이터부터 있나 확인해보고, 관련 논문이 있는지를 영어로 조사합니다. 그리고 모든 팀원이 동일한 주제를 생각하도록 구체적으로 동기화 해야합니다. 

 

+ 주제를 정할 때는 관심과 서비스 가치가 있는지 BM도 생각합니다.

 

※ BOAZ에서는 GAN 스터디, visual search API 조사 등 조사와 리서치만 4주를 잡았다!

 

=> 요구사항 분석 :

고객이 요청한 경우에는 요구사항 분석, 요구사항 명세서 작성이 이 단계에서 필요합니다. 회원, 판매자, 주문처럼 카테고리를 나누고 카테고리별로 기능 리스트(참고 4)를 작성합니다. 또한 스프링이라면 카테고리 별로 컨트롤러를 구분할 것입니다.

 

※ 필요한 경우 요구사항 리서치 수반(AI면 논문 조사, 개발이면 관련 어플리케이션 조사한 것 워드에 작성 참고 3)

 

 

=> 서비스 기능, 설계 정리

1. AI 필요한 기술 정리 : 얼굴 표정 감정 인식, 추천 알고리즘 등

2. 설계 : 도메인 설계(도메인 별 협력관계 설계, 클래스 다이어그램 설계), 서비스에 따른 구조도 설계, 시퀀스 다이어그램, UI 디자인 설계, DB 다이어그램 설계, 서비스 흐름 설계(참고 2), AI를 프론트에 넣을지 서버에 넣을지, 앱 로고+이름+디자인 색깔 등

3. 기능 : 로그인, 웹 캠 띄우기 등

 

=> 기획서 작성 및 발표

1) 기획서

2) 발표자료

 

- 프로토타입 작성

이건 지금까지 한 번도 한적이 없긴한데 포켓몬 프로젝트를 생각했을 때 기획과 설계를 기반으로 간단하게 그림을 그려보면 좋을 것 같다고 생각되어 포기할 수 없다고 판단했습니다. 그리고 정말 간단하게 그림 한장으로 끝내도 됩니다. 세세한 것은 페이지 별 기능 명세서에 나타나기 때문입니다.

 

- 프로젝트 설계 단계

이 부분을 팀원들이 모두 모여서 설명하고 회의하고 피드백하는 것이 좋습니다, 또한 이 부분에서 백엔드도 여러개(참고 1)로 나뉠 수 있고 프론트, 앱 설계도 여러 개로(참고 1) 나뉠 수 있습니다. 경우에 따라 스무스하게 진행하면 됩니다. 또한 시나리오 설계, 시퀀스 다이어그램이 여기서 필요합니다.

 

1. AI 논문 조사, 코드 실행 

AI는 논문을 찾아보고 논문에 함께 있는 코드를 실행해 보는 것이 가장 빠르고 효과적인 방법입니다. AI 파트는 계속해서 주제에 적합한 논문을 찾아보고 소스를 실행해야합니다.

 

2. DB 설계

3. 백엔드 api 설계(기능 명세서)

 

4. 프론트엔드 UI, 기능 설계(기능 명세서)

 

5. 앱 UI, 기능 설계(기능 명세서)

 

 

+ 페이지별 기능 명세서

프론트에서는 위에서 기능 명세서로 큰 틀을 잡았지만 추가로 페이지별로 더욱 세세하게 하나하나 꼼꼼하게 기능을 명세합니다. 어쨌든 프론트는 페이지의 이동이기 때문에 정말 꼭 필요한 중요한 과정입니다.

 

 

=> 설계 마무리, 개발 시작

이렇게 설계를 하고 jira와 노션을 통해서 타임라인대로 개발을 하면 됩니다.

 

 

 

- AI 모델 파트 진행 상황

-> 시행착오

1. FER : 너무 흔하고 일반 분류 모델이므로 신뢰성이 떨어짐
2. posenet : 관절을 tracking하는 모델을 눈과 입을 추적하도록 어노테이션도 직접해서 학습하고자 했지만 face align이 이반적이라 배제
3. face alignment : 눈, 입을 찾을 수 있게 되어 각도 모델로 활용 예정

4. 랜드마크 잇고 분류 : '이미지에 임의로 선을 긋고 분류 모델을 돌리면 모델이 이해하기 쉽지 않을까?'라는 생각에서 시작된 시도였지만 정확도가 낮아서 배제
5. facial-expression-recognition-using-cnn : 분류 모델에 얼굴을 넣기 전에 랜드마크로 feature를 뽑는 과정을 거치는 모델로 활용 예정
6. official model : 지금까지 다른 모델들은 제가 직접 처음부터 끝까지 학습을 시켜야하는 경우라 이미 만들어진 모델도 하나 있으면 좋겠다 하여 선택하였고 Attention 기법을 활용한 감정인식 모델입니다.

이렇게 6가지 경우를 고려했고 3, 5, 6을 사용할 것입니다.

 

 

 

결론

개발 프로세스 정리와 지금까지 진행된 상황을 나타내보았습니다. 이제 본격적으로 개발을 진행하면 됩니다. 개발80, ML20으로 가겠습니다.

 

- 지금까지 받은 AI 프로세스 관련 피드백

1. 실시간 처리에서는 모델을 서버에 넣으면 트래픽이 너무 심하니 프론트에서 넣어라
2. AI 프로젝트를 할 때 유명 학회의 논문의 코드부터 실행해보고 되면 논문을 읽으면서 데이터 전처리에 신경써라
3. 딥러닝은 최후의 수단으로 쓰고 안 쓸 수 있으면 안쓰는 것이 좋다
4. 속도가 느리더라도 완전 정확도에 초점을 맞춘다면 사용해도 된다. 논문 요약을 하더라도 논문을 직접 읽는 것보다 AI에게 요약을 맡기고 다른 일을 하는 것이 더 좋으니 사람들이 감안할 것이다

 

참고

설계 여러개

서비스 흐름 설계

요구사항 리서치

카테고리 별 기능 리스트