[회고] 캡스톤 졸업 프로젝트를 마치며 (feat. 외국민 프로젝트) - (1)

외국민 프로젝트

• 2024학년도 1학기
• 캡스톤 디자인 프로젝트
• 인원 : 6명 (FE(2), BE(2), AI(2))
• 담당한 역할 : 백엔드
• 수상 : 장려상

 

Github 링크

GitHub - kookmin-sw/capstone-2024-30: 외국인 유학생을 위한 앱서비스

 

 

소개페이지

💻 캡스톤 30조 결과물 소개

 

플레이스토어 링크

외국민 - Google Play 앱

---

길고 길었던 졸업작품 프로젝트가 끝났다. 이번 학기 너무 힘들었다...  이번 1학기에 프로젝트를 2개나 진행했었다. 하나는 지금 소개하고 있는 외국민 프로젝트고, 나머지 하나는 알파프로젝트로 진행했던 이음 프로젝트이다. 거기에 이음 프로젝트는 내가 팀장으로 진행했던 프로젝트고, 서류 작업도 너무 할게 많아서 매우 힘들었다. 하지만, 두 프로젝트 모두 너무 좋은 팀원들을 만나서 재밌게 진행하였고 많이 배웠던 프로젝트였던 것 같다. (비록 이음은 좀 더 장기 프로젝트 느낌으로 잡고가서 아직 안끝났지만...)

 

너무 어려웠던 주제 정하기

우리 프로젝트는 너무나도 늦게 시작해서 개발 기간이 촉박했다. 왜냐하면 주제가 계속 확정이 안됐기 때문이다... 팀은 이미 1월에 꾸려져서 1월 중순부터 계속해서 주제를 생각했다. 아주 많은 주제가 나왔었다.

 

• 마니또 앱
• 스몰토크 주제를 추천해줄 수 있는 앱
• 일기를 입력하면 생성형 모델을 이용하여 AI가 그림일기를 그려주고 공유하는 서비스
• Azure 발음평가 SDK를 이용한 한국어 발음 연습과 MZ 세대들을 위한 어휘 향상 서비스
• 맞춤형 챗봇 서비스
• 카메라로 쓰레기 사진을 찍으면 분리수거를 어떻게 해야되는지 알려주는 서비스

위에 말고도 여러가지 의견이 많이 나왔었다. 하지만, 딱 꽂히는게 없고 계속 1월 중순부터 주제만 생각했던 것 같다... 이게 3월말까지 이어졌다. 그래서 우리팀은 위기감을 많이 느꼈었다... 이제 진짜 개발을 들어가야하는데, 다른 팀은 다 개발을 들어갔는데 6명이서 아직 주제 확정을 못하고 있으니 말이다. 그러던중, 지도교수님께 자문을 구하기 위해 우리가 생각했던 아이디어 목록을 보여드렸다. 그랬더니 교수님께서 발음평가에 대해서 흥미롭게 보시며, 이걸 한국인 대상 발음평가가 아니라 외국인 대상으로 하면 어떻냐고 물어보셨다. 여기서 우리는 정말 좋은 아이디어를 하나 떠올렸다. 생각해보니 우리 국민대학교는 그 어떤 대학들보다 유학생 비율이 굉장히 높은 학교였는데 (특히 중국인) 그에 비해 유학생들을 위한 지원이 턱없이 부족했던 것이다!

 

유학생 앱의 필요성

유학생 지원 앱이 왜 필요한가에 대해서 팀원들끼리 여러가지 고민해보았다.

 

일단 첫번째, 공지사항 번역이랑 자주 물어보는 FAQ 질문들이 한국어로만 제공된다. 두번째, 학식도 한국어로만 제공된다. 세번째, 외국인 유학생들은 에브리타임 이용을 어려워한다. 그래서 외국인들이 서로 질문할 수 있는 커뮤니티가 부족하다. 네번째, 국민대에서 제공하는 챗봇의 성능이 너무 안좋고 (자꾸 동문서답함) 한국어만 지원한다. 다섯번째, 유학생들의 적응을 돕기 위한 헬퍼 매칭 서비스 홍보가 너무 부족하고, 이 또한 진짜 돈받고 하는 헬퍼 느낌이라 유학생들이 친구 사귀기가 어렵다는 점이다. 여섯번째, 유학생들도 한국인들과 수업을 같이 듣다보니, 수업에서 한국어로 발표를 해야되는 경우가 종종있다. 하지만, 발표 스크립트를 짜와도 자신의 발음이 맞는지 봐줄 사람이 없다.

 

우리는 그래서 위 문제들을 해결할 수 있는 국민대를 위한 유학생 지원 앱을 만들면 좋다고 생각했다. 타겟도 명확하고, 공익적인 목적도 있고, 실제로도 도움이 될 것 같아서 주제를 확정지었다.

 

 

또한, 실제로 외국인 유학생들이 어려움을 알기 위해 국민대 유학생들을 대상으로 인터뷰를 진행하였다. 인터뷰는 유학생들을 대상으로 수업을 진행하시는 교수님께 도움을 구해서 컨텍하게 되었다. 위에는 진행했던 인터뷰 내용을 정리했던 것의 일부이다. 해당 인터뷰를 통해서 우리는 유학생분들이 매번 공지사항이나 학식 정보를 캡처해서 파파고 같은 이미지 번역기를 돌려 확인하는 식으로 정보를 휙득했다는 정보도 알게 되었다. 또한, 발음평가 같은 기능 있으면 굉장히 잘 쓸 것 같다고 의견도 주셨다. 덕분에 이 서비스가 필요한 서비스이며, 의문이었던 발음평가 기능도 도입하기로 결정했다.

 

솔직히, 제일 원했던 것은 국민대 유학생 지원센터나 유학생 연합 동아리에 컨텍을 넣어서 설문조사를 진행하는 것이었다. 하지만, 아쉽게도 개인이 진행하는 프로젝트에 대해서는 홍보가 어렵다고 연락을 받아서 인터뷰밖에 진행할 수 없었다....

 

기능 선정하기

우선 우리가 앞서 한 인터뷰와 지인들을 통해서 우리 서비스의 기능들을 확정시켰다.

 

1. 국민대학교 공지사항 번역하여 제공

국민대학교 사이트로 부터 공지사항을 크롤링해서 DeepL API를 이용하여 번역을 거쳐 DB에 보관하도록 구성하였다. 이때, 공지사항 목록들은 Cursor 기반 페이지네이션으로 SNS 피드처럼 무한 스크롤 될 수 있도록 구성하였다.

 

2. 국민대학교 학식 번역하여 제공

국민대학교 학식 API로부터 정보를 받아와 번역하여 제공하도록 구성하였다.

 

3. 발음연습 기능

 

자주 쓰이는 한국어 표현 리스트를 제공하여 발음 연습을 할 수 있도록 했다. 또한, 발표 스크립트 같이  자신이 원하는 스크립트로 발음 연습을 할 수 있는 기능도 제공한다. 발음평가는 Microsoft Azure의 발음평가 SDK를 사용하여 구현했다.

 

4. 헬퍼 및 헬피 게시판

유학생들은 자신을 도와줄 헬퍼가 필요할 수 있다. 그래서 해당 게시판을 통해 헬퍼를 구할 수 있도록 게시판을 제공하였다. 또한, 유학생활을 3~4년 정도 하여 어느정도 유학생활에 적응한 학생이 다른 사람을 도와주고 싶을 수도 있다. 이때, 헬피 게시판을 통하여 도움이 필요한 사람을 찾을 수도 있다.

이때, 채팅 기능을 제공하여 상대방과 매칭 전, 필요한 정보를 추가로 얻을 수 있도록 구성했다. 이때, 채팅은 일반적인 Websocket 방식이 아닌 Long Polling 방식으로 구현했다.

 

5. Q&A와 FAQ 게시판

유학생들이 한국생활에서 궁금한 것을 물어볼만한 곳이 마땅치 않고, ON국민에 있는 FAQ의 존재를 알기 쉽지 않다. 따라서, 외국민은 Q&A 게시판과 다국어로 번역된 FAQ를 제공한다.

 

6. 국민대 전용 챗봇 기능

마지막으로, 국민대에 특화된 챗봇을 제공해준다. 해당 챗봇은 국민대학교 기본 정보, 공지사항, 국민대학교 소개 블로그 등을 학습하여 국민대 맞춤 정보를 제공해준다. 이때,  RAG와 LLM을 사용하여 더 국민대학교에 특화된 답변을 제공하도록 구성하였다.

 

프로젝트 관리는 어떻게 진행했는가?

우리는 다른팀보다 훨씬 늦게 개발을 시작하였다. 그렇다보니 보다 빠르게 개발할 필요성이 있었다. 그래서 우리가 어떻게 개발을 진행하였는지 한번 이야기해보고자 한다.

회의는 어떻게?

 

일단 우리는 정기 회의를 주당 2회로 잡았다.월요일에 한번, 금요일에 한번 이렇게 2번 하였다. 우리가 개발을 너무 늦게 시작해서 보다 빠른 개발과 성과를 위해서 주 2회 회의를 진행하기로 하였다. 월요일에는 금~일요일 주말동나 작업한 것에 대한 리뷰를, 금요일에는 월~목 평일동안 작업한 것에 대한 리뷰를 진행하였다.

그래서 우리들의 방식은 애자일 프로세스에서 말하는 스크럼 단위가 됐다. 주 2회 전체 회의를 가지면서 자신이 한 작업물 성과에 대해 공유하고, 어떤 점을 고민하고 개선했는지 리뷰하며, 각자 새로운 할 일을 부여했다. 이게 각자 수업이 있고, 사는 곳도 다 다르다보니 회사처럼 Daily Scrum까지는 진행하지 못했지만... 그래도 매일 Slack을 통해 지속적으로 개발 내역 및 고민 내역을 공유하였다. 완전 Agile에서 추구하는 Scrum Process까진 아니지만... 그래서 우리만의 비스무리한 Scrum을 추구하였다.

 

아래는 "외국민" 프로젝트 뿐만 아니라 다른 "이음" 같은 프로젝트에서도 회의를 내가 어떻게 진행하였는지 내용을 담은 글이다. 회의 방식에 대해서는 아래 글을 참고해주면 좋을 것 같다.

[프로젝트 진행하기 #4] 회의 진행

 

소통은 어떻게?

 

우리팀은 소통을 Slack으로 진행하였다. 

 

내가 아래 글에서도 작성하였는데, Slack은 보다 빠르고, 명확하게 소통을 할 수 있는 좋은 도구이다. 또한, Github과 연동하여 다양한 기능도 활용할 수 있어서 카카오톡보다 훨씬 좋다. 내가 왜 Slack을 선호하는지는 아래 글 "팀원간 소통" 부분을 참고해주면 좋을 것 같다.

[프로젝트 진행하기 #1] 프로젝트 시작 준비

 

어쨋든 우리 팀원 6명 모두 친한 사이여서 새벽에도 Slack을 보내며 개발 내역을 공유하고, 자신이 현재 고민하고 있는 부분에 대해서 토론하고, 오류를 수정해주는 등 소통을 진행하였다.

 

진짜 개인적으로 소통의 중요성을 많이 느끼는데, 개발자들끼리는 좀 많이 갈리긴 했지만... 새벽 3시에도 오류에 대한 Slack을 보내서 고치고, 자신이 고민하는 문제를 즉시 팀원들과 공유해서 빠르게 해결하는 등 우리 팀은 소통이 잘 되었기 때문에 짧은 시간내에 프로젝트를 완성도있게 마칠 수 있었던 것 같다.

 

Git은 어떻게?

나는 Git 체계가 굉장히 중요하다고 생각하는 사람이다. 왜냐하면, Git이야 말로 협업의 중심지이며 실제 배포가 일어나기 전에 코드가 모이는 마지막 관문이기 때문에 이 곳에서 일어나는 일이야 말로 그 어떤 곳 보다 중요하다고 생각하는 사람이다. 그래서 프로젝트 시작전, 팀원들에게 나는 Git의 중요성을 엄청 강조하고 체계를 잡는데 열중했다. 팀장도 내 모습을 보고 "Git 경찰"이라는 특수한 역할을 나에게 부여하기도 하였다 ㅋㅋ

 

브렌치 전략

우리는 Git Flow 전략을 활용하여 Branch를 나누었다. 개인적으로 조금 복잡해질 수 있어도, 위처럼 브렌치를 나누어 개발하는 것이 매우 중요하다고 생각한다. Hotfix나 Release 브렌치는 거의 안쓰긴 했지만.... Master, Develop, Feature 이 3가지의 브렌치는 적극 활용했다. Master는 지금 당장 바로 배포할 수 있을 정도의 코드만 올라가야한다. 따라서, 각자 담당한 기능을 Feature 브렌치에서 개발하고, PR을 올려 코드 리뷰를 한 후, Develop 브렌치에 합쳐서 충분히 테스트를 진행한 후, Master 브렌치에 올려서 배포하도록 구성했다. 어떤 사람들은 이렇게 하면 귀찮고 복잡하기만 하지, 굳이 왜 해야되냐고 생각할 수 있는데, 나는 오히려 이 과정을 하는 시간보다, 이 과정을 스킵함으로써 발생하는 오류 고치는 시간과 비용이 더 크다고 생각한다. 사전에 충분한 테스트를 통해 오류를 방지하는 것이다!

 

Issue와 PR

우리 팀은 앞으로 해야될 일과, 각자 무슨 일을 하고 있는지에 대해서 한눈에 볼 수 있도록 하기 위해 Issue 기능을 적극 활용하였다. 끝나고 보니 Issue가 104개에 PR은 135개 ㅋㅋ....

추가적으로, 특정 이슈나 버그에 대해서 설명이 부족하면, 다른 팀원들이 봤을때 어떤 것을 원하는건지, 어떤 버그인 것인지 알기 힘들 것이다. 따라서, 나는 Issue Template을 생성해서 어떤 내용을 적어야 하는지 확실히 해놨다. 특히, 버그 내용에 대해서 작성하는 템플릿은 given, when, then 포멧으로 작성하도록 구성해서 어떤 조건에서 어떤 상황에서 버그가 발생하는지 다른 팀원들도 쉽게 알 수 있도록 구성했다. 궁금하다면 아래 예시를 봐주면 좋겠다.

 

[BE] Redis Rate Limiter 사용시, Lua 스크립트를 읽지 못하는 현상 · Issue #167 · kookmin-sw/capstone-2024-30

 

PR도 역시 Template을 작성해두어 어떤 내용을 써야되는지 사전에 정의해두었다. 나는 개인적으로 이 PR이 굉장히 중요하다고 생각하는 사람이다. 서로 코드를 리뷰해보고 개선하고, pull을 땡겨봐서 테스트도 해보고, 이를 통해서 코드의 품질을 높이고, 사전에 심각한 오류를 방지할 수 있다고 생각한다. 뿐만 아니라, 상대방이 작업한 내용에 대해서도 다른 팀원들과 공유할 수 있는 자리라고 생각한다. 아래는 내가 작성했던 PR들 예시 중 하나이다.

 

Feature/be/#81 chatting 채팅 서버 구현 by mclub4 · Pull Request #104 · kookmin-sw/capstone-2024-30

 

사실... 이 PR에 관해서 처음에 팀원들의 반발이 좀 있었다. 우리끼리 하는 프로젝트인데 이렇게 까지 PR을 할 필요가 있는가에 대해서 반발이 있었다. 그래서 왜 PR이 필요한지 팀원들을 설득하는 과정이 좀 있었다. 결과적으로, 끝나고 나서 팀원들도 이 과정이 필요하다고 느꼈고, 많이 배웠다고 한다. PR같은 것이 개인적으로 경험이 없다면 왜 필요한지 납득이 안갈 수 있다고 생각하긴 한다. 하지만, 직접 겪어보면 왜 중요한 과정인지 이해가 갈 것이다. 많이 귀찮아도, 내 Git 철학에 대해서 믿고 따라와준 팀원과 내 철학에 대해서 지지해준 팀장에게 매우 고맙다...

 

[프로젝트 진행하기 #5] Git

 

개발은 어떻게 진행했는가?

기술적인 내용과 관련해서 적으려면 굉장히 길어질 것 같아서, 해당 내용에 대해서는 2편으로 따로 작성해보고자 한다.

여기서는 간단하게 내가 무엇을 담당했는지, 코드 구성은 어떻게 추구했는지만 다뤄보고자 한다.

 

일단 내가 했던 내용들은 아래와 같다.

• 공지사항 크롤링 및 커서 기반 페이지네이션 기능
• 로그인/회원가입 기능
• JWT 토큰 발급 기능
• 채팅 기능
• 발음평가 관련된 치명적인 오류 수정
• 전반적인 시스템 아키텍처 설계
• API Gateway 구축 (JWT Token 확인 및 API Rate Limiter 구축)
• Https 적용
• Docker Container화
• Git Actions을 이용한 CI/CD 적용
• Test Container를 활용한 테스트 환경 구축
• 캐싱을 통한 응답시간 향상
• 전반적인 인프라 및 배포에 관련된 내용 진행
• Apache Jmeter를 통한 부하 테스트
• Swagger를 통한 API 문서화 도입

전반적인 배포 및 시스템 개발을 담당했다고 보면 된다. 

 

코드 구성은 우리는 Domain 중심형으로 디렉토리를 설계했다. 또한, 사전에 코드 컨벤션을 정해서 동일한 스텐스의 코드를 작성할 수 있도록 추구했다. 예를 들어서 몇가지를 들어보겠다.

• 변수는 CamelCase를 기본으로 한다.
• ENUM이나 상수는 대문자로 네이밍한다.
• 클래스명은 명사로 작성하고 UpperCamelCase를 사용한다.
• 함수명은 소문자로 시작하고 동사로 네이밍한다.

이런식으로 코드 컨벤션을 정했다. 이에 대해서는 역시 "프로젝트 진행하기" 개발 편에서 더 자세히 다뤄보고자 한다. 또한, SOLID 원칙을 생각하면서 코드를 짤려고 노력은 했다. 근데 이제와서 생각해보면 잘 지켜졌는지 좀 의문이긴 하다. 내가 진행했던 다른 프로젝트인 "이음"에서는 OCP, ISP, SRP 등등을 생각하면서 코드를 짰는데 (이 프로젝트는 좀 장기로 잡아서 여유가 있기 때문) "외국민" 프로젝트는 시간에 너무 쫓겨서 그런지 그런게 좀 많이 부족한 것 같다. 

전시회와 수상

 

전시회는 6시간동안 진행되었다. 사실 우리 팀은 이 전시회를 하면 외국인 유학생들이 알아서 와서 직접 써보고 그럴 줄 알았다. 하지만 그럴 일은 없었다... 지금와서 생각해보면 당연한 것이다. 유학생들이 우리 학과 건물에서 전시회가 열린다는 것을 어떻게 알 것 인가? 또, 전시회에 이런 어플이 있다는 것을 어떻게 알 것인가? 당연히 모른다. 게다가 옆에 "디클"이라는 팀이 있었는데, 상품을 통하여 적극적으로 유저 유치를 하고 있었다. 솔직히 우리 팀은 그래서 위기감을 느꼈다. 옆팀은 저렇게 적극적으로 유저를 유치하고 다니는데 우리는 지금 이게 뭐하는 짓인가? 생각이 들었다. 그래서 우리 팀의 팀장이 "이대론 안된다! 우리도 유저 유치를 해보고 실제 유저의 평가를 받아볼 필요가 있다!"라고 생각했고, 팀장과 나는 유저 유치를 위해 건물 밖으로 나갔다. 그리고 지나가는 외국인들에게 어설픈 영어로 말을 걸었다. 외국인 유학생을 직접 밖에서 데려와서 우리 서비스에 대해 설명해주고, 양해를 구해 실제 우리 서비스를 써보게 하였다. 반응이 굉장히 좋았다. 외국인들을 위한 정보를 너무 잘 제공해주지 않아서 힘들었는데, 이런 서비스가 있다니 너무 좋다고 하였다. 그렇게 10여명의 유학생들에게 우리 서비스를 홍보할 수 있었다. 

 

다만, 문제가 있었다면 중간에 사우디아라비아 사람들도 왔었는데, 왜 아랍어는 없냐고 물어보았다. 비용 문제로 아직 한국어, 영어, 중국어만 지원하고 있어서...

 

어쨌든, 솔직히 나는 이렇게 할 생각을 전혀 못했는데, 적극적으로 밖으로 나가 유학생들에게 말을 걸고 데려와서 홍보할 생각을 하고 추진까지 한 우리 팀장님이 너무 멋있었다.... 우리 팀장님의 회고록도 한번 읽어주면 감사하겠다. 

 

이렇게 외국인들을 많이 데려오는 모습을 보고, 한 교수님께서 우리 서비스를 유학생이 많은 자신의 원어 강의에서 소개해보지 않겠냐고 제안을 주셨다. 정말 좋은 기회였고,  당연히 추진하였다.

 

 

그래서 며칠 후, 논문도 많이 읽고, 영어로 미팅도 많이해서 영어를 제일 잘하는 AI 팀원이 발표를 진행하였다. 반응은 너무 좋았다. 특히, 공지사항과 학식 번역 부분에서 아주 큰 호응을 얻었다. 그동안 공지사항, 학식, 학교 정보를 다양한 언어로 제공 안해서 너무 힘들었는데, 이런 앱이 있다면 너무 좋다는 것이다! 그런데... 정작 플레이스토어 QR 코드를 띄우는데 아무도 찍지 않았다. 그래서 뭐지? 이렇게 반응이 좋은데 왜 아무도 다운을 안받는거지 싶었다. 알고보니 다들 아이폰이여서 안 다운받는게 아니라 못 다운 받는 것이었다... 교수님께서 안드로이드 휴대폰 사용자 손 들어보라고 하셨는데... 아무도 손을 들지 않았다. 유학생들은 대부분 아이폰을 썼던 것이다... 우리는 비용적 문제와 배포가 까다로운 애플 스토어로 인해 시간적 문제가 있어서 우서너적으로 플레이스토어에만 배포를 했었다. 하지만, 정작 우리의 서비스 이용자들은 대부분 아이폰이었다... 그래서 하반기에 아이폰으로 출시할 계획이다.

 

 

결과적으로 우리 팀은 장려상을 탔다!! 개발 늦게 시작해서 많이 빡셌지만, 6명 모두 열정적으로 참여하고 한명도 무임승차가 없어서 이루어 낼 수 있었던 결과인 것 같다!

 

배웠던점과 아쉬웠던 점

• 전에도 많은 프로젝트를 해봤지만, 이렇게 제대로 협업을 진행해본 것은 동시에  진행한 "이음"과 함께 처음이었다. 굉장히 값진 경험이었다.
• 이번에 Redis를 이렇게 제대로 써본 것은 처음이다. Refresh Token, API Rate Limiter, Caching 이렇게 3가지에 활용하였는데, 덕분에 Redis에 대한 이해가 높아졌다.
• Spring Cloud는 이번에 처음 써보는데, 처음에 이게 Tomcat이 아니라 Netty라서 Spring MVC랑 너무 달라서 굉장히 애먹었다. Mono나 Flux에 대한 이해가 좀 생겼으니, 다음 프로젝트에는 Webflux를 이용하여 비동기처리를 보다 효율적으로 진행해보고자 한다.
• Ruby On Rails를 이번에 처음 써봤다. 사실 Ruby 언어는 내가 예에에전에 RPG VX ACE로 게임 만들면서 써봐서 잘 알고 있었는데, Ruby On Rails에 관련된 자료가 너무 없다보니 많이 애를 먹었다... 그래도 덕분에 한층 더 성장한 느낌이다.
• 일반적으로 채팅을 Web Socket으로 많이 구현하는데, 이번에 Long Polling 방식으로 구현해봤다. 다양한 방식으로 기능을 구현해보는 것도 성장하는데 큰 도움이 되는 것 같다.
• 실사용자를 받았던 서비스는 이번이 처음이다. 백엔드 입장에서 이는 너무 흥분되는 일이다. 다만, 타깃이 너무 좁아서 유저층을 더 늘리기는 어려워 보인다...
• 아이폰을 출시 하지 못한 점이 너무너무 아쉬웠다... 아이폰만 출시했어도 지금보다 몇배는 유저 수가 더 늘었을텐데 너무 아쉬웠다.
• 학교랑 연계해서 서비스를 진행하고 싶었는데.... 개인이 한 프로젝트를 홍보해줄 수 없다고 답변을 받았다. 이 점은 너무나도 아쉬웠다.
• 어드민 페이지를 만들어서 관리하고 싶었는데 시간이 부족해서 못했다.
• 소프트웨어공학에 관심이 많아서 보다 체계적으로 Agile Process를 적용하고 싶었는데... 너무 시간에 쫓기는 바람에 잘 못했던 것 같다.
• 테스트 코드도 역시, 테스트 환경은 구축을 잘 해놨는데 시간이 부족해서 Test Code를 제대로 작성하지 못했다. 그래서 내가 추구하는 이상적인 CI/CD 파이프라인이 아닌 것이 너무 아쉽다.
• 내 꿈은 대규모 트래픽을 감당할 수 있고, 고가용성을 추구하며, 동시성 처리가 잘 이루어지는 서비스 구축을 하는 것이다. 이번 외국민도 사실 ArgoCD, Kubernetus, Istio, Prometeus, Grafana 등등을 사용해서 고가용성을 추구하고 모니터링을 할 수 있는 아키텍처를 구성하려고 했다. 하지만... 시간이 너무나도 부족해서 이 점을 하지 못한 것이 너무 아쉽다.

 

글이 너무 길어질 것 같아서, 백엔드 기술적인 내용에 대한 회고는 2편으로 나누겠다.