[회고록] 복수전공, 융합캡스톤 팀플 후기
코드들은 아래에서 확인 가능!
https://github.com/CSID-DGU/2022-1-CSC4031-Atk-origin
GitHub - CSID-DGU/2022-1-CSC4031-Atk-origin
Contribute to CSID-DGU/2022-1-CSC4031-Atk-origin development by creating an account on GitHub.
github.com
시작
2022년 4-1학기에 융합소프트웨어 복수전공으로 부터 시작한 프로그램이다. 해당 과목은 복수전공의 대체 논문 과목이기 때문에, 필수로 들어야 하는 수업이다. 사실... 제공된 커리큘럼에 비해서는 난이도가 급상승하는 느낌은 적지 않게 받았었다. 그래도 개발자의 소양 중 하나인 자기 개발(?)을 따로 해왔기에, 내 희망 직무인 스프링 백엔드 부분을 맡게 되었다. 이 과목은 학교에서 제공해주는 주제를 선정해서 한 학기동안 결과물을 만들면 된다. 우리 팀이 선택한 주제는 STT를 통한 "청각 장애인을 위한 강의 도우미 서비스"였고, 주제의 범용성을 높여서 대상을 모두가 사용할 수 있는것을 목표로 하였다.
구조
시스템 구조도
프론트엔드
크롬의 확장프로그램을 활용하였으며, 사진과 같이 서버에 요청을 하면 알맞은 응답을 받고, 처리하도록 하였다. 프론트를 담당한 친구의 제일 중요 임무는 오디오를 캡쳐해서 서버로 보내주는 것이다. 이미 누가 오디오 캡쳐 기능을 만들어 두었지만, 저장 후 서버로 보내지기까지 많은 시간이 할애되었다. 결국은 성공한 친구가 대견스러웠다 ㅎㅎ
백엔드
내가 맡은 파트다. 나는 스프링을 활용하였고, 이 과정을 통해 다음과 같은 경험을 할 수 있었다.
- Spring Security를 활용한 JWT 로그인: 프론트와 백엔드를 분리하였으니 로그인을 어떻게 해볼까 고민하던 중 JWT 토큰을 활용하는 로그인 방식이 있었고, 이를 사용해보았다. 이 과정을 통해 Spring Security의 필터가 대략 어떤 흐름을 이용하여 인증/인가를 해주는지 배울 수 있었다.
- PAPAGO, Oxford 등 외부 API를 이용하여 서비스 로직에 활용: 우리는 STT를 통해 추출된 텍스트를 사용자들에게 번역과 영단어를 제공해주어야 한다. 번역도 요새 모델을 잘 구하면 된다곤 하지만.. 이미 잘 마련된 API를 쓰기로 마음 먹었다. 그래서 위의 API들을 갖고온 뒤 JSON으로 잘 파싱하고 클라이언트에게 잘 제공해 주었다.
- Fast API를 구축하여, 스프링과 파이썬 서버간끼리 연동: 키워드 추출과, STT 처리는 파이썬 모델을 활용하기에 파이썬 서버도 필요하게 되었다. 처음엔 Java ProcessBuilder를 활용하여 python.exe python.py 처럼 파이썬을 컴퓨터에 실행시켜 결과값을 받아오도록 했는데, 계속 모델을 학습하는 과정이 일어나니 성능 저하가 생겼다. 그래서 차라리 파이썬 서버 실행시키면서 import하면 좀 빠르지 않을까? 내 뇌피셜을 활용하여 가볍다는 FastAPI를 구축하여, 서버간 통신을 이뤄냈다. 근데 이렇게 만들고 보니 생각보다 스프링에서 해주는 일이 별로 없어져서 주객 전도된 기분이었지만, 이런 연동도 언젠가 해봐야 하는 일이니 기분 좋게(?) 넘어갔다.
- Github Actions를 활용하여 AWS S3에 .jar 업로드: 제일 삽질을 많이 한 부분이다. AWS 프리티어를 사용해서 EC2까지는 쉽게 만들었다. 코드가 완료되면 배포를 해야할턴데.. 이것을 매번 내가 빌드하고 올리는 것은 많은 수고가 생기기에 CI/CD 툴인 Github Actions를 도입해보았다. 문제는 gradle로 빌드시 테스트도 이뤄지는데, 나는 비밀번호 같은 주요 정보들은 gitignore 해두었기에 찾지를 못하는 것이다..! 물론 로컬에서 다 테스트 해본것이라 gradle에서 test task는 빼도 되겠다만, 내 자존심이 용납하지 못하여 갖은 뻘짓을 하여, 빌드 시 인자값들을 넣어주는 방법을 찾아 해결했다! 그렇게 성공한 .jar파일은 S3에 업로드하였고, 최종적으로 EC2에서는 다운 받아 갈아 끼워주면 되는 것이다. 시간 관계상 CodeDeploy까지는 사용 못해봤는데, 앞으로 있을 프로젝트에서 도입해보려고 한다.
아래의 사진은 우리의 화면을 figma라는 툴로 그렸고, 화면대로 모든 페이지를 완성시켰다!
소감
팀워크의 소중함과 함께 팀 분위기에 있어서 어떤 사람을 만나는지도 얼마나 중요함을 배웠다. 해당 프로젝트는 4인 인원으로 구성되는데, 우리팀만 늦게 들어온 학생이 합류하여 5인으로 구성되었다. 5인이 된만큼 더 좋은 퀄리티를 제공하는 것을 목표로 하였는데, 새 멤버는 많은 변명과 함께 일을 계속 미루더니 급기야 학기 도중에 말도 없이 잠적을 해버린 것이다. 맡은 일도 거의 안 하고, 사라지니 많이 당황스러웠지만 남은 멤버끼리 역할 분배를 다시 하였고, 빠르게 정상 궤도로 돌아와 최종 발표까지 잘 마무리하였고, A+를 받는 쾌거를 얻을 수 있었다. 어느 분야를 막론하고 일을 잘하는 것이 제일 중요하겠지만, 타인간 소통을 하며 좋은 팀 분위기로 프로젝트가 유지되는 것이 끝나서도 서로에게 좋은 추억으로 마무리 되겠구나 느꼈다. 끝까지 함께 한 나머지 3명이 정말 소중하고, 감사하다.
기획이라던가 구현 계획은 처음에 확실히 해야함을 배웠다. 지금까지 스프링으로 토이 프로젝트를 한다면, 내가 SSR(서버 사이드 렌더링)을 통해서 내가 화면도 그리고 스프링과 작업하는 식으로 했는데, 이번 프로젝트에서 철저하게 프론트와 백엔드를 구분하여 개발을 하였다. 전체적인 틀은 내가 그린 다음에 프론트 친구한테 이런식으로 보내주면 내가 응답값을 이렇게 보내줄게, 하고 구두로 API를 그린 다음에 간단한 텍스트로만 정리했다. 그러면서 내가 스프링을 공부하면서 "이렇게 주는게 좀 더 좋을거 같네?" 생각이 들어 response값을 프로젝트하면서 계속 변경하게 되었고, 이는 결국 프론트엔드의 개발 속도가 늦춰지는 악영향을 끼치게 되는 것이다. 우리는 API가 그렇게 많지는 않아서, 친구도 괜찮다곤 했지만 계속 번거롭게 했던 것은 미안하다. 앞으로는 Swagger 같은 API 툴과 함께 되도록이면 초반에 구조를 잘 짜서 잘 제공해보려고자 한다.