들어가기 앞서..
대학교 마지막 학기에, IITP 에서 주관하는 SW 전문인재양성 프로그램에 참여할 기회가 생겼다. 제대로 된 포트폴리오도 없었고, 협업 경험도 부족한 상태로 혼자서 졸업 프로젝트를 만드는 것이 부담이였기에 해당 프로그램에 지원을 하게 되었다. 운이 좋게도 프로그램에 참여할 수 있었고, 23년 8월부터 23년 12월까지 교육 및 회사에서 제안하는 프로젝트를 개발할 수 있었다.
해당 사업의 목적은 다음과 같았다. "현장 수요에 맞는 교육과정을 기업・대학이 공동 설계하고, 기업 주도 집중교육을 통해 산업체에서 즉시 활용 가능한 인력 적기공급" 이러한 목적에 맞도록 트랙도 2가지로 나눠져 있었고, 교육 과정도 짜여져있었다.
해당 교육 트랙은 2가지로 나눠졌었다.
- 클라우드/백엔드 SW 개발자 교육과정 트랙
- AI/빅데이터 SW 개발자 교육과정
두 교육 과정 중 내가 희망하는 백엔드 개발자 트랙을 선택하여 교육을 들을 수 있었다. 해당 교육과정은 본교육 8주, 코딩테스트교육 1주, 프로젝트 개발 9주로 이루어졌다. 평일동안 매일 9시~18시까지 학교에서 교육을 듣고 프로젝트를 진행하는 부분은 힘들긴 했지만, 지나고 보니 아주 뿌듯하다!
프로젝트 개발시에는 회사와 연계하여 실제 현업 개발자분들이 멘토님으로 오셔서 제안한 프로젝트를 개발할 수 있었다. 나는 '헥토 파이낸셜'사의 'Spring Boot, React, 결제 연동으로 완성하는 웹 서비스 개발' 프로젝트에 지원하여 개발할 수 있었다.(인기 많은 회사의 인기 많은 주제였기에, 해당 프로젝트에 뽑히기 위해서 지원서 작성에 많은 시간과 노력을 들였다..😂)
🧑🏻💻 Im-Guru (전문가 매칭 웹 서비스)
⌛️개발 시기: 2023.10.25 ~ 2023.12.26⌛️
앞서 말했듯 운이 좋게도 하고 싶었던 프로젝트 주제를 받아서 개발을 진행할 수 있었다. 앞서 2인 개발 경험이 었었기에 해당 프로젝트도 2인 협업 개발로 진행을 할 수 있어서 좋았다. 또한 멘토님이 존재하니 더욱 질 높은 프로젝트 개발을 진행할 수 있었다! 해당 프로젝트의 메인 기능은 '결제' 이다. 그렇기에 구현하기 위한 웹 서비스 주제는 큰 고민없이 결정할 수 있었다. 우리가 개발하기로 한 웹 서비스는 '전문가 매칭 웹 서비스, 전-도사' 이다.
전 도사의 의미는 2가지가 존재한다.
- 이용자의 측면: 전문가의 도움이 필요한 사람들 !
- 전문가의 측면: 저는 도사입니다 !
프로 N잡러라는 단어가 대두되는 만큼, 누구나 자신이 일하고 있는 전문분야 말고도 제공할 수 있는 전문 기술이 존재하다고 생각했기에 해당 웹 서비스를 개발하게 되었다. 또한 기존에 존재하는 '숨고'와 '크몽'의 경우 많은 사용자들이 사용하기 복잡하고 번거롭다는 말이 많았다. 그렇기에 조금 더 가볍고 커뮤니티 기능이 활성화 되어 있는 '전-도사'를 개발하고자 했다.
또한 효율적인 문서관리, 일정관리를 위해서 Notion, Jira를 사용해주었다!
(모든 링크는 하단에 첨부되어있습니다 🗂️)
핑계일 수 있지만, 해당 프로젝트 개발이 완성 되었다고 하기엔 부족한 면이 많다.. 2달이라는 기간동안 문서 작업과 개발, 배포, 테스트, 발표를 모두 하기란 너무 타이트했다.. 기한내에 완성이 목표였기에 버그도 제대로 수정하지 못했고, 커밋 컨밴션을 제대로 지키지 못한 경우도 있었다. 코드의 개선사항이 너무 많아 보이기에 추후에 리팩토링을 다시 시작해줄 예정이다!..
https://sku2023-fw.atlassian.net/jira/software/c/projects/IG/boards/6
Im-Guru
Im-Guru has one repository available. Follow their code on GitHub.
github.com
https://plant-crayon-964.notion.site/ImGuru-9573d409c62b4ccf8dc123d0b742c89b?pvs=4
코딩구조(주혜/수혁) - ImGuru | Built with Notion
프로젝트 명 : IM-GURU (전, 도사): 전문가와 이용자를 손쉽게 연결해줄 수 있는 웹 서비스 1. 이용자 측면: 전문가의 도움이 필요한 사람들 2. 전문가 측면: 저는 도사입니다. (전, 도사)
plant-crayon-964.notion.site
✍🏻 프로젝트 회고
🙆🏻♂️프로젝트를 진행하며 만족했던 부분과 계속 이어나갈 사항
- 실제 개발을 하시는 현업 멘토님이 있어서 너무 만족스러웠다. 혼자 공부하거나 구글링을 통해 공부하면 검색해도 뚜렷하게 해결하지 못하는 문제들이 많았었다. 예를 들어, 계층형 도메인형 중 어떤 것을 더 추천하는지? 코드 형식의 경우 어떻게 작성해주는 편이 좋은지? 실제 현업에서는 무슨 기술들을 더 많이 사용하고 공부하면 좋을지? validation의 경우 어느정도 까지 체크해주는 편이 좋은지? Redis의 사용은 어디서 많이 해주는 편인지? 등등 가려웠던 부분에 대한 질문들을 할 수 있었다. 평소 내가 궁금했던 것들은 명확하게 '무엇이 정답이다!' 라고 할 수 없는 질문들이였기에, 해당 질문에 대한 조언을 실제 현업 개발자분들 통해 알 수 있다는 사실이 너무 좋았다.
- 해당 프로젝트 또한 커밋 규칙을 정하였던 것이 좋았다. 팀 스터디를 진행하며 커밋 규칙에 대해 들었던 적이 있었고, 앞서 2인 프로젝트를 진행하며 적용해본 경험도 있었다. 또한 멘토님도 협업 개발이기에 커밋 규칙을 정하여 Github를 통해 형상관리를 하길 요청하셨었다. 그렇기에 커밋 규칙을 정하여 지킬 수 있도록 노력했다. (but,, 여전히 어려웠다,,)
- Jira를 사용해볼 기회가 생겨서 만족스러웠다. 대부분의 회사에서 Jira를 통해 일정관리를 진행한다고 멘토님을 통해 들을 수 있었다. 그렇기에 이번 기회를 통해 한번 경험해보는 것이 좋을 것 같다고 조언해주셔서 Jira를 사용해서 일정 관리를 할 수 있었다.
- 실제 헥토 파이낸셜에서 제공하는 결제 시스템을 내가 만든 프로젝트에 도입해서 테스트 해볼 수 있어 만족스러웠다. 결제의 경우 돈과 관련된 문제라 적용하기에 무서웠었다. 또한 굳이 개인 프로젝트에 아임포트처럼 결제 API를 도입할 필요가 있을까? 생각했기에 한번도 적용해본적이 없었다. 하지만 이번 프로젝트를 통해 멘토님께 결제 싸이클에 대한 설명도 듣고 프로젝트에 적용해주기 위해서 코드 분석을 할 수 있어 좋았고, 이해가 가지 않는 부분에 대해 바로 물어볼 사람이 있어 수월하게 적용할 수 있었다.
- 프로젝트 설계부터 기획, 그리고 일정관리와 회의록 작성, 개발 일지까지 모두 작성해볼 수 있는 경험을 할 수 있어 좋았다. 문서의 중요성을 알게 되었다. 평소 개발을 할 때, 대략적인 기획만 잡고 개발하기에 급급했었다. 하지만 해당 프로젝트를 진행할 때는 기획부터 설계, 일정관리까지 모두 우리가 작성하고 고민하는 시간을 가졌었다. 또한 기능명세서와 화면설계서까지 직접 작성할 생각에 너무 막막했다. 하지만 기능명세서와 화면설계, 일정관리까지 미리 작성하니 무엇을 개발 해야하는 지 명확하게 알 수 있었다. 또한 개발 중 참고할 문서가 있어 개발 속도를 더욱 올릴 수 있었다.
🙅🏻♂️프로젝트를 진행하며 불편했던 부분과 개선이 필요한 사항
- 팀원의 부재가 너무 힘들었다.. 또 다른 팀원과 멘토님이 있는 개발이였지만, 1인 개발로 진행을 할수밖에 없었다. 지정되어 있던 팀원이였기에 개발에 뜻이 없는 팀원과 팀 프로젝트를 진행하게 되어 개발에 어려움이 있었다. 2달이란 시간동안 혼자서 개발하기엔 벅찼다. 또한 앞서 말했던 Github를 통한 형상관리와 Jira를 통한 일정 관리, 설계 및 기획에서의 문서 작성 모두 혼자서 진행을 했기에 제대로 사용을 했다고 말하기 어려울 것 같다.
(경험할 기회는 있었지만 제대로 경험해보진 못했다..) - 배포를 늦게했던 점이 아쉬웠다. front, back의 포트번호가 배포할 때 달랐는데 이 때문에 배포 시에 cors 문제가 발생해서 해결하는데 애를 먹었었다. 어찌저찌 해결할 뻔 했지만, 결제 진행 시 헥토 파이낸셜 사에서 callback 될 때에도 cors 문제가 발생하여 최종 발표때는 결국 localhost로 시연할 수 밖에 없었다. 조금 더 빨리 배포를 해서 실제 환경에서 테스트를 진행했더라면 해결할 수 있는 시간이 충분하였을 텐데.. 하는 아쉬움이 남았다.
- 테이블과 entity가 많다고 해서 좋은 프로젝트는 아니다. 물론 프로젝트의 규모가 크다면 좋을 것이다. 내가 구현한 코드들은 사실상 entity와 class 명만 다르고 코드 로직은 비슷한 CRUD성이 강한 코드들이였다. 하지만 시간이 한정되어 있고, 구현할 수 있는 개발의 능력을 보여주기 위해서는 CRUD성이 강한 코드뿐 아니라 다른 기술을 더 적용해보는 것이 좋을 것 같다는 생각이 들었다. 예를 들어, message의 경우 쪽지 기능이 아니라 socket을 활용하여 실시간 채팅이 가능하도록 구현을 하던지, 아니면 AI 기능을 덧붙여 전문가와 사용자가 매칭이 되는 서비스를 구현하는 것이 더 도움이 많이 됐을것같다는 생각이 들었다.
🤷🏻♂️개선이 필요했다고 느낀 사항에 대한 해결책
- 로컬에서의 테스트도 중요하지만, 배포 환경에서의 테스트가 더 중요하다! 결국 개발의 끝은 배포이다. 로컬에서 아무리 서비스가 잘 돌아간다고 해도 배포 후, 제대로 동작하지 않는다면 무용지물이다. 이번 프로젝트의 경우가 그랬다. 배포의 경험이 부족했던 터라 로컬에서 잘 되면 배포에서도 잘 되겠지 하는 안일한 생각이 있었다.
- 무작정 프로젝트의 규모만 늘려서는 안된다. 앞서 말했듯 이번 프로젝트는 단순 CRUD성이 강한 코드들이 많았다. 해당 기능들의 수를 줄이고 다양한 개발 경험을 쌓는 것이 더 효율적이라고 생각이 들었다. 물론 이러한 단순 CRUD성이 강한 코드들이 구현하기 쉬운 것은 아니다. 많은 시간을 들이고, 버그와 결함을 수정하는데 많은 자원이 들어가게 된다. 하지만 이러한 자원을 나눠 선택하여 집중할 수 있었다면 더욱 좋은 결과를 이끌어내 유종의 미를 거둘 수 있었을 것 같다.
😤느낀점
이번 프로젝트는 팀장으로 프로젝트의 설계와 기획, 전체적인 개발을 모두 담당하여 진행했다. 팀원의 실력 향상과 프로젝트 참여 의지를 이끌어내기 위해서 대화와 용기를 주었고, 멘토링과 스터디 장을 해봤던 경험을 토대로 팀원 교육도 같이 진행하며 프로젝트를 성공적으로 이끌어낼 수 있었다. 이러한 협업 경험을 통해 기업에서 협업의 중요성에 대해 언급하는 이유를 다시 한번 깨달을 수 있었다. 혼자서 개발하게 되면 스스로 타협을 하며 최대가 아닌 최선의 상태에서 마무리했던 경험이 있었다. 하지만 팀원, 그리고 멘토님과 함께 개발의 일정을 세우게 되니 책임감이 생겨 프로젝트를 잘 마무리 할 수 있었다. 또한, 멘토님에게 코드에 대한 질문이 아닌, 개발 시에 갖 게 되었던 정답이 없는 질문에 대한 조언을 들을 수 있어 한층 더 성장할 수 있었다.
또한 현업에서의 업무 프로세스, 기획과 설계시에 작성하는 문서의 중요성, 팀워크의 중요성, 그리고 결제 시스템 도입에 대한 이해를 얻을 수 있어 좋았다. 또한, 팀원을 제외한 같은 주제를 선정한 상대 팀과 서로의 코드에 대한 피드백과 도움을 주고받으며 2인이 아니라 4인이서 프로젝트를 진행하는 것과 같은 경험을 할 수 있었다. 이를 통해 문제 해결 능력과 의사소통 능력을 향상할 수 있었으며 지식을 나누어 성장할 기회를 마련하게 되었다!
