Java, Spring MVC, Spring Security, Javascript, Jquery, Oracle, Mybatis, Elastic search, Kibana, Logstash, Tomcat, Maven, Github REST API
Github : https://github.com/ddit301/gaia

이번 최종 프로젝트까지 세 번의 프로젝트 모두 프로젝트 리더 역할을 맡게 되어서, 믿고 맡겨주신 선생님들의 기대에 대한 책임감과, 부끄럽지 않은 결과를 내야 한다는 스스로의 자존심에 세 번의 프로젝트 모두 정말 최선을 다했습니다. 물론 항상 지나고나면 아쉬움은 남았지만 조금의 후회도 남지 않을 정도로 밥먹는 시간, 쉬는 시간, 주말 등 시간은 모두 쥐어 짜내었고 노력 만큼의 결과물을 얻을 수 있었습니다. 초급, 중급, 최종 프로젝트 모두 최고의 팀원들을 만나서 세 번 모두 그 당시 해낼 수 있는 최선의 프로젝트를 해냈다고 자신합니다.

2. 본론

조편성

총 25명의 학생들이 5개의 조로 편성 되었습니다.

최종 프로젝트에 오기까지 한명의 낙오자도 없었다는게 정말 자랑스러웠는데, 왠걸.. 최종프로젝트를 진행하자 그만 두는 학생들이 속출했고 그 결과

( 5 / 5 / 5 / 5 / 5 ) 명으로 시작한 최종 프로젝트는 ( 저희는 두번째인 2 조 입니다)

(4 / 3 / 3 / 4 / 5 ) 명의 학생들이 남았고. 애석하게도 저희 조도 3명이서 진행하게 되었습니다. 손이 달리는건 그렇다 쳐도 각자의 업무가 늘어난다는게 생각보다 심리적 부담이 상당했습니다.

Gaia의 팀원은 총 3 명 입니다.

Shane(PL)

Eisen(TA)

Josh(DA)

1주. 프로젝트 주제 선정

주제선정에 오랜 시간을 쏟지 말자! 라고 다짐했습니다. 어떤 주제가 나오든 주제가 중요한게 아니고 거기에서 우리가 구현할 기술이 중요하고 완성도가 중요하다고 생각했습니다. 지금와서는 프로젝트 주제가 생각보다 꽤나 중요하다고 생각합니다. 물론 주제선정에 너무 많은 시간을 쏟는건 여전히 반대합니다.

수행 계획서 history는 Github에서도 확인 가능합니다.

수행계획서는 총 6 번 작성했습니다. 주제선정이라는게 딸랑 주제를 선정하면 다가 아니고, 해당 주제에 맞게 계획서를 준비 해서 해당 주제로 프로젝트를 제대로 진행 할 수 있는지 팀원들 끼리도 한번 확인하고 선생님에게도 제안서 컨펌을 받아야 합니다.

1차시도

재밌는 걸 해보자! 하며 그때 당시는 5명이서 몇시간동안 얘기를 하다가 커플들의 웹 메신저 이런 개념으로 초안을 작성해 제출했다가 담임선생님에게 결혼 정보 회사 차릴 일 있냐고 대차게 까였습니다. 사실 지금에 와서는 가슴을 쓸어내리는 순간입니다.

2차시도

머리를 굴렸습니다. 팀원들 모두 머리모아 한개의 제안서를 작성했다가 까였을 때 그 타격이 너무 커서, 다섯명이 제안서를 한개씩 다 작성 해 보았습니다. 다섯개의 제안서를 모두 확인해야 할 선생님에겐 죄송한 일이지만 그 막막했던 상황에서 나름 통과 확률을 높여보고자 머리를 굴려 보았습니다. 한 명이 제출을 제때 해주지 못해 4개의 제안서가 나왔고, 2개는 주제 선정부터 까이고 2개에서 그나마 주제는 가능성이 있는데 이정도 기획으로는 안된다는 피드백을 받았습니다.

여기에서 팀원 한명이 본인은 개발자 할 생각 없다며 이탈해 팀원은 4명이 되었습니다.

3차시도

온라인을 통한 비대면 강의를 진행해야 하는 대학, 학원을 대상으로한 인터넷 강의 제공 서비스. 이미 준비된 동영상 강의 뿐만 아니라 계획된 스케줄 혹은 시간표에 따른 실시간 온라인 강의 또한 제공.

요즘 뜨고있는 인프런이나 콜로소 등을 생각하며 주제를 준비했습니다. 2차때 준비한 주제에 선생님께서 mooc 를 만들겠다는 말이냐고 하셔서 mooc가 뭔지 검색을 해 보았고, K-mooc 이라고 한국에도 제가 생각했던 모델이 이미 서비스까지 이루어 지고 있다는 것을 알게 되어서, K-mooc에서 더 유용한 기능이 추가된 버전을 만들어 보겠다고 했습니다. 선생님께서는 너네 이거 하면 2주만에 뚝딱 만들어 놓고 놀게 될거라며 너무 할게 없는 주제라고 반대하셔서 동영상 스트리밍 부터 시작해 모든 구현을 바닥부터 시작하겠다고까지 해봤지만 소용 없었습니다. 지금와서 프로젝트를 마치고 생각해보면 선생님 말씀이 다 이해 되지만 그때 당시에는 정말 벽에 부딪힐때마다 어떻게 해야할지 막막했습니다. 3차 수행 계획서를 퇴짜맞았을 때는 너무 답답해서 저희는 오죽하면 Github를 우리 손으로 만들어 보자고 까지 얘기 했었다고. 도대체 뭘 해야 할지 모르겠다고 말씀드리며 도대체 어떤 주제를 어떻게 선정해야 하는지 자세히좀 말씀해 달라고 했습니다.

그래! 내가 너희한테 만들으라고 하려고 했던게 바로 그거야

좋은 생각이라고 하십니다. 저는 말도 안된다고 생각해서 회의 때 장난식으로 꺼냈던 주제였는데 선생님께서는 마음에 들어 하셨습니다.

금요일 수업이 끝나는 시간이었기에 더이상 팀원들에게 회의를 하자고는 할 수가 없어서 주말내내 머리를 쥐어 짜내 혼자 수행계획서를 작성 해 보았습니다.

4차시도

사실 4차 수행계획서를 작성할때는 소설을 쓴다는 마음으로 작성했습니다. 어떤 수행 계획서를 준비해가도 너무 쉽다고, 2주~4주 하고 놀게 된다고 하시는 선생님에게 뭔가 정말로 구현할 생각은 1도 안하고, "이정도 까지 한다고 썼는데요?" 라는 뭔가 반항하는 느낌이 들 정도로 작성 해 보았습니다.

Repository X is how developers get together. Reposity X는 개발자들이 함께하는 방법입니다.
기존의 Project Management System들의 높은 진입장벽과 제각각의 서로 다른 사용법과 기능을 보완하기 위해 사용하기에는 쉽지만, 기능은 강력한 프로젝트 관리 및 협업툴을 제공합니다. Issue를 기본 단위로 프로젝트를 관리합니다.
해당 어플리케이션은 아래의 기능들을 대표적으로 지원합니다.

코드 저장소 2. 이슈 트래커 3. 프로젝트 일정 관리 4. 인스턴트 메신저 5. 클라우드 스토리지 6. Web IDE

사실 이때는 말도 안된다고 생각하며 작성한 특이 기술들인데 결국 아래에서 필요가 없어 뺀 몇 개를 제외하고는 전부 구현 했습니다.

4차 계획서 일부

계획서를 작성하며 제가 기대했던 선생님의 반응은 "너네 진짜 이거 다 할 수 있어?" 였는데, 막상 선생님의 반응은

기능을 더 추가해라

였습니다. 어쨌든 이렇게 주제는 통과를 했습니다만 수행계획서는 이후로도 팀원들과 회의를 거쳐 5차, 6차 까지 작성 되었습니다.

2주. 산출물 작성

이때부터 어쩌면 지루한 산출물 작성 기간이 시작되었습니다. 코드는 전혀 작성 하지 않고 아침 부터 밤 10시까지 팀원들이 프로젝트를 어떤식으로 만들지에 대해 대화하며 점점 머리속으로만 생각했던 프로젝트를 구체화 하는 기간인데, 이 기간이 정말 중요합니다.

일단 팀원들 각자가 프로젝트 관리하는 모든 툴들에 대해 조사 및 공부를 해오고 공유를 하기로 했습니다. Github, Redmine, Jira, Monday.com, Jandi, Collabee, Slack 등등 여러가지 협업 툴들을 하나하나 가입해 이것 저것 체험 해 보았습니다.

그 후로는 수시로 정책에 대해 팀원들끼리 이야기를 나누고, 애매한 부분은 회의를 통해 구체화 시킵니다. 사실 많은 학우들이 이 시간을 의미없는 시간으로 생각해서 혼자 인터넷 서핑하며 딴청을 피우거나 팀원들 열심히 회의할 때 엎어져서 자는 사람들도 꽤 있었는데, 그렇게하면 팀원들이 같은 얘기를 몇번씩 또 해야하는 일이 생기기 때문에 시간 낭비가 심해집니다. 이때가 사실상 팀프로젝트에서 가장 중요한 협업의 시간이 아니었나 생각 듭니다.

어느 정도 구체화 되기 시작했을 때 부터는 역할을 나누어서 DA는 DB 설계를 조금씩 하며, 정책적인 부분은 꾸준히 팀원들에게 의견을 묻고, 나머지 팀원들은 화면 설계와 산출물 작성을 했습니다. 주제 선정부터 포함해 2~3주의 기간이 이렇게 사용됩니다.

이 기간동안 팀원들이 배운걸 덜 까먹고 Spring Framework 공부를 할 수 있도록 간단하게 Side Project로 점심 도시락 주문하는 웹 프로젝트를 만들어 보자고 제안 했습니다. 반에서는 오전 11시까지 단체 카톡에 있는 "투표" 기능을 이용해서 각자 주문하고 싶은 도시락 메뉴를 고르고, 그럼 한명이 대표로 전화로 주문 하고 계좌를 통해 학우들이 입금을 하는 식으로 도시락 주문이 이루어 지고 있었는데요. 그 대표로 정리해서 주문 하고 돈을 입금 받고 하는 수고가 얼마나 번거로운지 눈에 보여서 돕고 싶은 마음에 예전부터 꼭 만들고 싶었던 프로젝트 였습니다.
초급프로젝트때 해당 기능을 비슷하게나마 console에 구현 해 봤기 때문에 금방 하겠다는 생각에 제안 했는데 팀원들이 너무 재밌어 보인다며 갑자기 거기에 빠져드는 바람에 갑자기 최종 프로젝트 준비가 뒷전이 되어 버렸고, 생각했던 것 보다 그 간단해 보였던 사이드 프로젝트도 어쨌든 하나의 프로젝트라서 기획부터 구현까지 차근차근 해보니 결국 하나의 프로젝트를 또 하는 셈이 되어서 아쉽지만 며칠 만에 결국 무산 되었습니다. 돈에 관련되었다 보니 대충 만들수가 없었습니다.

3주. 데이터 베이스 및 UI 설계

준비된 산출물들을 바탕으로 데이터베이스와 UI들이 나와야 합니다.

저희 팀은 Figma를 적극적으로 협업에 사용 했습니다. 서로간에 동시에 작업을 할 수 있고, 작업 내용을 언제 어디서든 실시간으로 확인 할 수 있어서 동시에 하나의 작업을 하는데 꽤나 유용하게 사용 했습니다. 서류작업, UI 설계는 열심히 한다고 했음에도 불구하고 나중에 실제 구현할때는 이때 준비한 내용들도 애매하게 느껴져서 꽤나 고생을 했습니다. FIGMA를 통해 UI를 설계하는건 TA를 맡은 Eisen과 PL인 제가 대부분 했습니다.

데이터 베이스는 DA를 맡은 Josh가 준비를 해 줬습니다. 중간 프로젝트도 각각 PL과 DA로 한 팀에서 협업을 한번 이미 해 보았었기 때문에 서로가 좀 더 편하게 작업을 할 수 있었습니다. DB 설계를 하려면 프로젝트와 그 정책에 대해 전반적으로 이해를 잘 하고 있어야 해서 꽤나 힘들어 하긴 했지만 팀원들간에 많은 소통을 할 수 있어서 좋았습니다.

모든 작업을 하는 와중에도 각자 시간을 내서, TA Eisen은 프로젝트에 사용할 API들을 검색 해 주었습니다. ToastUI를 선택해 간단한 샘플 코드도 남겨 주었고, 풀 캘린더 api 등도 골라 주었습니다. openssl을 이용해 https 프로토콜도 도입을 해 주었는데 하루를 꼬박 고생해준 덕에 팀원들이 "Connection is secured" 자물쇠를 얻을 수 있었습니다. dv나 ov 인증서까지 얻었으면 했지만 일단 localhost로 합의를 봤습니다.

PL인 저는, 저희 팀은 MariaDB로 프로젝트를 진행 할 계획 이었는데 학원에서 주는 제공해 주는 서버는 Oracle이었기에 집에 있는 서버로 쓰는 노트북에 MariaDB 서버를 구축 해 두고, 통합 검색 구현을 위해 Elastic Search, Logstash, Kibana 도 준비 시켰습니다. 슬슬 협업을 할 수 있도록 프로젝트를 생성 해서 Spring MVC 패턴으로 backend 패키지 구조도 준비 해 두고 front 쪽도 간단하게 Ajax를 활용한 싱글 페이지를 구현 할 수 있도록 함수들을 작성 해 두었습니다. 결국 DB는 선생님과 상의 끝에에 그대로 Oracle 을 사용 하기로 했지만 여러 가지 이유로 학원 서버를 사용하지는 않고 집에 따로 Oracle 서버를 구축해서 사용 했습니다.

4주 ~ 8주 기능 구현

역할을 분담 해 기능을 한개씩 구현 해 나갔습니다.

처음에 싱글 페이지로 만들기 위한 설계 단계와 path variable을 활용해 네비게이션 역할을 할 수 있는 심플한 url 구조를 만들기 위해 시간을 꽤나 쓰긴 했지만 최대한 협업을 고려한 설계를 해둔 덕에 Git 을 통한 버전 관리시에도 서로 간에 딱히 충돌이 일어나진 않았습니다.

Shane : 메인, 코드, 이슈, 칸반, 뉴스, 통계, 멤버관리, 프로젝트 관리, 단축키, 메뉴언어선택, push알림, 문자전송

Josh : 마일스톤, 위키

Eisen : 회원overview, 회원정보 관리, 간트차트, 캘린더, 통합검색

마치고 나니 각자 이정도씩 기능 구현을 했습니다.

발표를 2주정도 남긴 시점에서 하루는, 그나마 남아 있는 팀원들도 학원에 나오지 않아서 오전 내내 혼자 코딩을 하고 있었는데요, 선생님에게 불려가서 제가 혼나는데.. 열심히 하는 만큼 팀원들이 따라주지 않음에 대한 서운함과 매일 프로젝트 준비한다고 같이 전혀 시간을 보내지 못하고 있는 와이프에 대한 미안함에 설움이 폭발해 엉엉 울기도 했습니다. 그래도 이때 선생님께서 방향을 잘 잡아 주신 덕분에 남은 2주 동안 프로젝트를 잘 마무리 할 수 있었습니다.

어느 과정에서였는지 확실하지는 않은데 모든 FK 제약조건이 싹 다 삭제되어 있었습니다. 그걸 발견한게 발표 5일 전이었습니다. 알 수 없던 버그가 발생해 그 원인을 찾다가 발견했는데 일단 무결성에 위배되는 모든 데이터 찾아서 제거하고, 다시 제약조건을 걸었습니다. 한참 바쁜 시기에 함께 꽤나 고생을 했습니다.

최종 발표를 4일 남긴 상태에서 선생님에게 최종 컨펌을 받았습니다. 팀에 인원이 워낙 부족한 상황이라 중간 중간 보고해야 하는 모든 내용이나 반드시 짚고 넘어가야 했을 내용들도 선생님의 배려로 어느 정도 넘어간 덕에 구현에 집중 할 수 있었는데요. 선생님께서 믿고 기다려주신 덕분에 계획했던 대부분의 내용을 구현 할 수 있었습니다. 이때 남은 내용은 "통계" 와 "통합검색" 이었습니다. 두 기능 모두 상황이 워낙에 안좋아서 포기하려던 참이었는데 선생님께서 포기 하지 말고 끝까지 해 보라고 말씀해 주셨습니다.

생각했던 것보다 프로젝트가 나쁘지 않게 나왔네. 아직 구현 안된게 통계랑 통합검색 두개남은거지? 두개만 마무리 잘 지어봐

1. 통계

여태 추적 코드 심어서 여태 데이터 모은게 Google Analytics 4 인데, GA 3는 API를 활용 할 수 있지만 GA 4 부터는 Analytics API를 사용 할수 없게끔 막혔습니다. Google Analytics 홈페이지를 통해서 통계를 확인 할 수는 있지만 데이터를 json 형태로 받아와서 가공하는 건 할 수 없게끔 되어 있었습니다. 부랴부랴 GA3 코드를 새로 발급해 심어두었지만 데이터가 턱없이 모자란 상황이었습니다.

그래서 일단 DB상에 있는 데이터들로 보기 좋은 통계를 만들고, Google Analytics 에서 수집한 데이터들은 곁다리로 사용하기로 했습니다.

임기응변이라고 해야 할 까요. 한참 단순 CRUD는 물이 올라있던 상황이라 그날 바로 구현 해 냈습니다.

2. 통합검색

이 기능이 제가 꼽는 이번 프로젝트의 백미 입니다. 이 기능을 하나를 구현하기 위해 한주에 한개씩 주말마다 집에 있는 노트북 서버 컴퓨터에 Elastic Search, Kibana, Logstash 올리고, Elastic Search 팀원들이 어렵지 않게 사용 할 수 있도록 하기 위해 Elastic Search High Level client API를 활용해서 Elastic Util 이라는 쉽게 사용할 수 있는 모듈 까지 생성 해 두었는데 이게 도저히 통합검색이라는 산까지 다다르는게 쉽지가 않았습니다. 당장에 발표가 3일 남았는데 통합 테스트 진행하며 영상 녹화하고, 발표 시나리오 준비해야 하는 와중에 이게 기능 구현을 할 수 있을까 싶었습니다. 하지만 결국 Eisen과의 협업을 통해 결국 해낼 수 있었습니다.

저는 Logstash를 이용해 당시의 Oracle 서버에 있는 모든 데이터들을 indexing 해서 Elastic Search에 올려 두었고, 제가 작성해둔 Elastic Util 모듈을 활용해서 Eisen이 통합 검색 구현을 마무리 짓기로 했습니다. 덕분에 저는 발표 준비와 css 개선 및 사소한 버그들을 해결하는데 전념 할 수 있었습니다. eisen이 중간에 막힐때마다 제가 다른 방향을 제시해보고 하는 방식으로 진행 해 보았습니다.

Elastic Util에 작성된 구조가 통합 검색을 위한 구조가 아니라서 모듈이 새로 작성되어야 한다.

제가 새로 모듈을 만들 시간은 없어서 http 리퀘스트로 통합 검색에 해당하는 쿼리를 보내고, elastic search가 응답하는 json 데이터를 가공 하면 될 거라고 말씀드렸습니다.

http로 쿼리를 어떻게 보내는지 ?

ajax 를 활용해서 비동기 요청을 보낼 수 있다고 했습니다.

우리는 https protocol을 사용 하기 떄문에 http 요청을 ajax에서 보내면 the content must be served over HTTPS에러가 발생

저도 꽤나 당황을 했었는데 HttpURLConnection 으로 커넥션을 열어서 서버에서 요청을 보내고 inputstream으로 응답을 받아서 json 형태기때문에 그대로 view단으로 보낸 뒤에 해당 데이터를 가공해서 보여주면 될 거라고 했습니다.

요청을 보내는데 영어는 검색이 잘 되는데 한글이 검색이 안된다! 그런데 같은 요청이 Postman 에서는 된다.

분명 인코딩 문제라고 확신했는데 생각보다 원인을 찾아 해결하기가 쉽진 않았습니다. postman으로 요청 보낼 떄를 확인해보니 UTF-8 형태로 인코딩 된 유니코드를 쿼리에 보내는데, 서버에서 HttpURLConnnection 요청을 보낼때의 쿼리를 찍어 보니 유니코드가 아닌 한글 그대로가 전송이 되었습니다. encodeURI 로 클라이언트 쪽에서 애초에 검색어를 유니코드로 변환하는 방법으로 해결했습니다.

이렇게 몇 번의 난관이 있었지만 결국 통합검색 응답을 받아낼 수 있었고, 해당 json을 가공해서 화면에 보여주는건 eisen이 문제 없이 혼자 잘 처리 해 주었습니다. 리허설 까지만 해도 완성하지 못했지만 발표를 하루 이틀 남기고 결국 통합검색 기능을 구현 해 냈습니다. 협업의 힘을 느낀 짜릿한 순간 이었습니다. keyup 이벤트로 타이핑을 할때마다 검색 결과가 바로바로 새로 갱신됩니다.

발표준비

2021년 6월 28일 월요일이 발표 일이었습니다. 하루 전인 27일 일요일 아침부터 josh가 저희 집으로 와서 함께 발표 준비를 했습니다. 전날 고향집 대구에 내려갔던 eisen은 저녁에 도우러 와줬습니다.

시간이 워낙에 촉박했기 때문에 당장 josh는 옆에서 keynote를 활용해서 발표 자료를 만들고, 저는 발표 시나리오를 작성하면서 keynote를 어떤 식으로 작성해 주라고 바로바로 부탁 했습니다. josh도 keynote는 처음 사용 해 보는 것 이었는데 제가 요구 하는대로 척척 애니메이션도 넣고 발표자료를 잘 만들어 줬습니다.

josh가 keynote를 만들동안 저는 발표 시나리오를 짜고, 시나리오에 맞춰서 대본과 오퍼레이터가 해야 할 일을 작성 했습니다.

이렇게 25분동안 발표간의 멘트와 오퍼레이터가 해야 할 일을 정리한 페이지만 총 67 페이지가 나왔습니다.

프로젝트는 제 맥북과 연결을 하기로 했습니다. 해당 맥북과 Screen mirroring된 iPad를 들고 나가 저는 뒤를 돌아볼 필요 없이 앞을 보며 발표를 하고, 돌발 상황에는 들고간 매직키보드와 매직트랙패드로 대처를 할 수 있도록 준비 했습니다. 맥북도 와이프꺼 한개를 더 들고 가서 옆에 대본도 띄우는데 사용했습니다. 해당 맥북은 제 2 오퍼레이터인 eisen이 원격 조정을 통해 자리에서 제가 보기 편하게 대사에 맞춰서 페이지를 넘겨 주었고, josh는 제 맥북을 조작 해서 제 1 오퍼레이터로 활약해 주었습니다. 어느 한쪽에서라도 삐끗하면 난처 했을 계획이지만 장비를 최대한 활용 하는 만큼 팀원들의 호흡이 잘 받쳐준다면 짧은 발표준비 시간을 충분히 커버해 낼수 있다고 생각 했습니다.

오후 6시쯤 지나 모든 발표에 필요한 자료들이 준비 되었고, 시간을 재 가며 발표 리허설을 몇번 해 할 수 있었습니다. 처음 계획처럼 저희가 구현한 모든 모듈을 하나 하나 설명해 주려고 하니 발표시간이 1시간이어도 부족한 상황이 나와서 어쩔 수 없이 정말 많은 모듈들을 발표에서 제외하고, 발표하는 내용들도 짧게만 짚고 넘어 갈 수 밖에 없었습니다. 늘어지지 않도록 발표자료 5분, 시연 18분 정도로 발표시간을 최대한 맞춰 연습했습니다.

프로젝트를 관리하는 프로젝트라는 특성을 살려 "DDIT302" project도 하나 생성 해 두었습니다. 학우들 25명을 한명 한명 아이디 생성해 저희 사이트에 가입 시키고 해당 "DDIT 302" 프로젝트에 가입시켜 두어서 해당 프로젝트를 종료하는 퍼포먼스 까지 준비했습니다. 효과를 증대시키기 위해 문자메시지 전송 모듈까지 추가 해서 프로젝트에 초대 받았을때, 그리고 내가 속한 프로젝트가 종료 되었을때 두 가지의 경우에 문자메시지가 전송되도록 코드를 작성했습니다. 문자메시지도 해당 프로젝트가 종료될때는 특별 이벤트로 특별한 메시지가 전송되도록 코드를 작성 했습니다. 계획대로라면 발표 마지막에 저희 모두가 함께 해왔다는 DDIT 302 프로젝트를 종료 시키고 모두에게는 그동안 8개월동안 정말 고생했다는 문자메시지가 전송 됩니다.

발표

발표는 모두 계획한 대로 잘 진행 되었습니다.

문자메시지도 성공적으로 전원에게 잘 전송 되었습니다.

발표 후에 몇몇 친구들은 저에게 와서 문자메시지에 정말 감동받았다고 말 해 주었습니다.

이렇게 8개월의 과정이 종료되었습니다.

수료식에서는 최고 프로젝트로 선정된 덕에 상도 받고, 우수상 프로젝트의 PL 자격으로 선생님에게 상장 및 수료증을 대표로 받을 수 있었습니다. 상금도 받아서 그 돈으로 gaia.best 도메인을 구입 할 수 있었습니다. ( 지금은 1년이 만료되어 무료 도메인으로 변경하였습니다)

지난 몇달동안 점심도 빵으로 떼우고, 마지막에 귀가하고 제일 먼저 등교하고, 주말엔 집에서 밥도 선채로 대충 먹곤 그랬는데. 그 노력을 인정받았다는 기분에 정말 울컥했던 순간입니다.

그렇게 8주간의 최종 프로젝트와 8개월간의 풀 스택 교육이 끝을 맺었습니다.

마지막으로.

관심있는분은 아래 내용들을 클릭해서 확인해주세요.

https://github.com/ddit301/gaia

발표영상 과 테스트영상 Youtube 링크 입니다.

프로젝트 소개 블로그 포스팅

저작자표시

'Development > DevLife' 카테고리의 다른 글

INFCON 2022 신청 성공 (0)	2022.08.02
Programmers Weekly Challenge 12주 후기 (1)	2021.10.30
2021 네이버 웹툰 개발 챌린지 후기 (8)	2021.07.11
17주차) 중간프로젝트 PLAYDDIT 회고 (0)	2021.04.04
7주차 ) 초급 조별 프로젝트 "오늘 뭐먹지" 발표 (0)	2021.01.01

현재글최종 프로젝트 ) gaia 후기와 그 과정
관련글 INFCON 2022 신청 성공
관련글 Programmers Weekly Challenge 12주 후기
관련글 2021 네이버 웹툰 개발 챌린지 후기
관련글 17주차) 중간프로젝트 PLAYDDIT 회고

최종 프로젝트 ) gaia 후기와 그 과정

1. 서론

오늘 뭐먹지 ?

playddit

gaia

2. 본론

1. 통계

2. 통합검색

'Development > DevLife' 카테고리의 다른 글

티스토리툴바