[Java Wep Application] 파이널 프로젝트 Ⅶ. 회고

지난 포스팅에서는 훈련 기간 팀 프로젝트 동안 진행한 내용을 담아왔다. 오늘은 기획 단계부터 구현 단계까지 이르는 모든 과정을 기록하며 담아내지 못한 느낀점을 가감없이 작성해볼까 한다.

목차
1. 목표 달성 여부
  1.1 기존 기획 기능
  1.2 기획 수정 후 기능
  1.3 목표 달성률
2. 성장한 점
  2.1 언어 및 기술
  2.2 소프트 스킬
  2.3 문서화
3. 아쉬운 점
  3.1 절대적 시간 부족
  3.2 "액션 중심" 구성 미흡
  3.3  Service 계층 부재
4. 향후 계획
  4.1 기존 프로젝트 보강
  4.2 자격 시험 준비 및 공부
  4.3 입사 지원
5. 그 외 여담

---

1. 목표 달성 여부

1.1 기존 기획 기능

먼저, 기존에 우리 팀이 기획했던 기능은 크게 아래와 같다.

• [공통] (서비스) 일반 돌봄 제공 등록 및 이용 신청 기능
• [본인/팀장] (서비스) 긴급 돌봄 제공 등록 및 이용 신청 기능
• [팀원1] (회원) 부모 회원 맞춤 기능 - 마이 페이지, 아이 성장 다이어리
• [팀원2] (회원) 시터 회원 맞춤 기능 - 마이 페이지, 시터 스케줄러
• [팀원3] (운영) 관리자 맞춤 기능 - 회원 관리, 서비스 관리, 통계 등 대시보드

이 정도 기능쯤이야 금방 구현해낼 수 있잖아? 오히려 시간 남으면 어떡하지 다른 기능은 뭘 덧붙여볼까? ㅎㅎ

TWO WEEKS LATER...

 
생각보다 기획 과정은 중요했고, 생각보다 DB 작성은 오랜 고민이 필요했으며, 생각보다 우리는 우리 실력을 너무 과대평가 했다.

1.2 기획 수정 후 기능

그래서 당장 수정에 들어가 기능 구현에 대한 새로운 목표를 설정했다. 내용은 아래와 같다.

• [공통] [본인/팀장] (서비스) 일반 돌봄 제공 등록 및 이용 신청 기능
• [본인/팀장] (서비스) 긴급 돌봄 제공 등록 및 이용 신청 기능
• [팀원1] (회원) 부모 회원 맞춤 기능 - 마이 페이지, 아이 성장 다이어리
• [팀원2] (회원) 시터 회원 맞춤 기능 - 마이 페이지, 시터 스케줄러
• [팀원3] (운영) 관리자 맞춤 기능 - 회원 관리, 서비스 관리, 통계 등 대시보드

즉, 2개 서비스 중 1개 기능 구현을 과감히 포기했으며, 각 이용자별 맞춤 기능도 1가지씩 배제 혹은 후순위로 미루었다. 내가 담당했던 기능 구현 영역은 (아마 앞선 포스팅에서 보았겠지만) 긴급 돌봄 → 관리자 → 일반 돌봄 으로 2번이나 바뀌었는데, 이 덕분에 혼란했던 것도 사실이지만 결과적으로는 프로젝트 전반을 이해해야 했기 때문에 도움이 되었다.

1.3 목표 달성률

그렇다면 각 영역의 목표 달성 여부는 어느 정도인가!

• [본인/팀장] (서비스) 일반 돌봄 제공 등록 및 이용 신청 기능 [82.4%] 
• [팀원1] (회원) 부모 회원 맞춤 기능 - 마이 페이지  [80.0%]
• [팀원2] (회원) 시터 회원 맞춤 기능 - 마이 페이지  [88.9%]
• [팀원3] (운영) 관리자 맞춤 기능 - 회원 관리, 서비스 관리  [81.8%]

위 달성률은 대체 어떻게 나온 숫자인가! 내가 담당한 영역을 예로 들면 아래와 같다.

1. 정적 페이지 작성은 모두 완료하였고(6/6),
2. 각 페이지는 더미 기반 동적 기능 구현이 대부분 가능하며(5/6),
3. 서버 데이터 기반 동적 처리는 일부 제외 가능한 상태(3/5) 이다.
4. 단, 공지사항, 시터 로그인 등 기타 완수 작업은 목표 달성 여부 계산에서는 제외했다.

실제로는 각 페이지마다 더 해낸 게 많지만 깐깐하게 보았을 때 나온 결과(14/17, 82.4%)이며, 팀 구성원들도 이와 유사하게 목표 달성률을 구했다. 그렇게 산출된 전체 목표 달성률은 [83.28%]이다. 이 프로젝트를 절반도 마치지 못하면 어쩌지 걱정했던 우리에겐 정말 기특한 수치다.🙌🏻🎉

---

2. 성장한 점

2.1 언어 및 기술

기존에 프로그래밍이라면 대학교 교양으로 수강한 파이썬 거북이 랜덤 이동🐢이 전부였다. 이것도 이제는 가물가물하다. 그런 내가 이제는 HTML, CSS, Javascript로 웹 페이지를 구성하고, Oracle SQL로 DB를 구축하며, Spring과 Mybatis 프레임워크를 기반으로 짠 백엔드 코드를 기반으로 WAS로 Tomcat을 활용 서버 데이터에 접근하여 JSTL로 JSP에 동적 기능을 구현한 경험을 가지고 있다. Web Application 을 만들어본 경험이라니! 비전공자에게 1,120시간 그 이상을 투자한 지난 훈련 과정은 길다면 길고 짧다면 짧았지만, 무에서 유를 만들기까지 정말 비약적 기술 성장의 시간이었다는 점만큼은 확실하다.

2.2 소프트 스킬

훈련 과정이 아닌, 팀 프로젝트만을 고려했을 때 가장 큰 성장은 역시 소프트 스킬에 있다.

• 책임감: 팀장을 맡으며 막중한 책임감을 경험했다. 일정 관리, 작업 분배, 방향성에 대한 결정 등 최종 결정을 하는 사람으로서 가지는 무게가 상당했다. 당장 현업에 종사하면서는 팀장 직책을 맡지 않겠지만 머지 않은 시일 내에 만나뵙게 될 선배들의 입장을 간접체험한 경험이었다.
• 자기주도성: 버전관리에 도움이 되겠다는 판단하에 Git에 대해 누구보다 먼저 공부하고, 팀 프로젝트에 도입했다. 에러가 발생하거나 결과물이 예상과 다를 때 이를 해결하는 것 역시 다른 누군가가 아닌 우리, 그리고 내 몫이었기에 끝없이 정보를 탐색하고 공부하고 수정했다.
• 의사소통: 작은 것도 공유하며 서로의 부담을 경감하고자 노력했다. 팀 프로젝트는 혼자 하는 게 아니라 같이 하는, 협업이다. 서로 밀어주고 끌어주며 목표에 도달하기 위해 의사소통은 필요하다면 주저없이, 그러나 깔끔하게 진행될수록 좋은 것 같다.
• 관찰력: 성장...이라기보다는 의외로 협업에 있어 중요한 역량이라는 생각이 들어서 슬쩍 껴넣은 관찰력! 태생이 오지랖이 넓은 사람이다 보니 세상 돌아가는 이야기에, 남에게 적어도 내게 호의적인 사람에게는 관심이 많다. 팀 프로젝트 진행 전 학습 기간 동안 학우가 무엇을 잘하는지, 또 어떤 영역에 있어 조금은 의기소침한 모습을 보이는지를 알아두었던 부분이 팀장으로서 팀을 이끌고, 업무를 배분하고, 팀원을 격려하는 데 있어 도움이 되었다.

2.3 문서화 

내게 문서화는, 내가 작업한 산출물을 깔끔하게 남기는 것이었다. 모든 경우가 그렇지는 않겠지만, 경영대 재학 때만 돌아보더라도 레포트(보고서) 자체가 산출물이며, 발표자료가 곧 산출물이었다. 즉, 어떤 작업의 결과물과 문서가 같은 경우가 대다수였다. (물론, 회의록은 별개의 영역이다.)
그래서인지 Web Application 작업 초기에 "문서화"라는 걸 어떻게 해야하는지, 무엇이 맞는지 잘 알지 못해 시행착오를 많이 겪었다. 책도 찾아보고 웹문서도 참고하며 고생 끝에 파일 작성 및 정리를 마친 지금 돌아보자면! 문서화는 굉장히 중요한 작업이라는 걸 배웠다. 혹여나 놓친 부분이 없는지 검토할 수 있는 테스터가 되고, 우리가 작업해야 하는 프로젝트의 지표가 되는 게 "문서"라고 생각한다. 그리고 한 번 겪어봤으니 다음 프로젝트에서는, 또 그 다음 프로젝트에서는 더 잘 해낼 수 있지 않을까? 하는 마음이다.

---

3. 아쉬운 점

3.1 절대적 시간 부족

나를 포함한 모든 팀 구성원이 가장 아쉬웠다고 말한 절대적 시간 부족 문제. 파이널 프로젝트 주제를 선정하고 돌입할 때는 우리가 기획 및 개발을 모두 해야한다고 생각하지 않았다. 엄밀히 말하자면, 기획 단계는 가볍게 진행하고 개발 단계에 집중하는 방식이라고 생각했다. 기획의 중요성을 간과했다기 보다는 우리는 훈련 기관에서 Web Application 기획 방법에 대해 배운 적도 없었고, 프로젝트 기획부터 얼마나 심도있게 작업을 수행해야 하는지도 전달받지 못했다. 원래 무엇이든 스스로 알아보고 공부하며 진행하는 것은 너무나 당연하지만, 모든 게 처음이다보니 초기에 우왕좌왕하면 허비한 시간이 많았던 게 아쉽다. 2주 만에 기존 기획안을 대폭 축소하고 DB 설계를 수정한 시간도, 분명 배운 점도 많지만 아쉬움이 짙게 남아있다.

3.2 "액션 중심" 구성 미흡

Spring과 Mybatis를 결합한 형태의 프레임워크를 기반으로 Web Application을 구현하면서 XML Interface나 MapperXML, 그리고 작업 편의상 Java Bean 파일(DTO)을 구성할 때 "액션 중심"으로 구성하라는 말을 많이 보았다. 이때, 액션 중심이 무엇인지 모두 이해하지 못했고, 그 결과 ERD 상의 테이블에 의존하며 각 파일을 구성하는 상황으로 이어졌다. 이후 정적 페이지를 구성하고 서버 데이터를 기반으로 동적 기능을 구현하면서 "액션 중심"이 의미하는 바를 조금씩 깨닫기 시작했다. ERD 상의 테이블도 각각의 액션(ex.회원가입, 근무 등록, 돌봄 신청, ...) 을 의미하지만, "액션 중심"에서 액션은 Application 내 해당 기능을 처리함에 있어 관여되는 모든 속성이나 테이블에 대한 INSERT, SELECT, UPDATE, DELETE 이고, DTO 역시 ERD 테이블별로 존재하는 게 아니라 "액션 중심"으로 존재해야 한다는 것을 깨달았다. 조금 더 빨리 알았다면 Controller 작성 시 보다 깔끔한 코드 작성이 가능하지 않았을까 하는 아쉬움이다. 그치만 우리 선에서의 최선이었음을 알기에 후회는 없다.

3.3 Service 계층 부재

처음 진행하는 Web Application 개발 프로젝트고, 훈련 과정에서도 Controller Layer 만을 사용했기 때문에 우리 프로젝트에는 별도의 Service Layer가 존재하지 않았다. 즉, Service Layer가 수행하는 업무 처리 과정을 Controller Layer가 모두 짊어진 식이다. Spring Application 구조의 주요 계층 중 하나인 만큼 별도로 두고 싶다는 욕심이 있었지만, 결국 모두에게 익숙한 방식을 택했다. 지나고 보니 기존 내용을 복습할 수 있어 훌륭한 선택이었다는 생각이다. 그래도 다음 프로젝트 시에는 한 단계 발전시켜 비즈니스 로직 계층을 별도로 두며 작업을 진행해보고 싶다.

---

4. 향후 계획

4.1 기존 프로젝트 보강

위에서 내 담당 영역의 목표 달성률이 82.4%라고 했는데, 팀 프로젝트 수행 기간(24.03.24. - 25.04.25.) 중 미처 다 구현하지 못한 기능을 소개한다.

• ✅ 일반 돌봄 1차 필터 중 선택 가능 날짜 제한
• ❎ 일반 돌봄 2차 필터 중 지역, 자격증 조건 반영
• ❎ 일반 돌봄 결제 시 외부 결제 대행사 API 사용
• ✅ 일반 돌봄 이용 종료 후 7일 이내 리뷰 미작성 시 시터 평점 열람 제한
• ❎ 공지사항  게시물 등록/수정 기능 구현
• ❎ 알림함 서버 데이터 기반 동적 기능 구현

각 기능 앞에 붙은 아이콘에서 알 수 있다시피 "선택 가능 날짜 제한"과 "평점 열람 제한" 기능은 이미 회고 포스팅 작성 중 추가 구현을 마쳤고, 관련 포스팅도 이미 업로드했다. 그래서 회고 포스팅의 로마 숫자가 더 커져버렸다.

[Java Web Application] 파이널 프로젝트 Ⅵ. 기능 추가 구현 - 1차 필터 신청 날짜 제한 (Flatpickr 라이브

[Java Web Application] 파이널 프로젝트 Ⅵ. 기능 추가 구현 - 리뷰 미작성 시 평점 열람 제한

 

기존 우리 팀의 향후 프로젝트 계획은 (수정된 기획안의) 모든 기능을 구현하는 것이었다. 그러나 팀 구성원 개인 사정을 고려하여, 5월 말까지 추가 기능을 가능한 많이 구현하는 것을 프로젝트 목표로 변경했다. 따라서, 열흘 남짓 남은 기간 동안은 프로젝트 마무리를 잘 지을 수 있도록 틈틈이 작업을 수행할 계획이다. 그리고 만약 기간 이후에도 구현하지 못했거나 아쉬운 부분이 있다면 개인적으로 조금씩 채워나갈 예정이다.

4.2 자격 시험 준비 및 공부

훈련 과정을 담당해주신 강사님 말씀을 빌려, 개발자는 평생을 공부해야하는 직업이다. 그게 새로운 지식 입력일수도, 기존 지식에 대한 복습일수도 있지만 끊임없이 학습해야 한다는 건 변함없는 사실이라고. 비전공자의 입장에서는 더욱 부지런히 해야할 일이 많다.

• 정보처리기사 실기 준비: 이미 지난 3월 필기 합격 이후 4월 시험에 응시한 바 있지만, 팀 프로젝트 기간과 겹쳐 아쉬운 부분이 많았다. 다가오는 6월 발표될 결과와는 별개로 사실 불합격했을 것 같기도 해서 소프트웨어 설계 관련 지식 함양 겸 실기 공부를 쭉 다시 진행할 계획이다.
• 자료구조와 알고리즘 공부: 모두가 중요하다고 입 모아 말하지만 시간을 들여 공부하기 쉽지 않다는 자료구조와 알고리즘 형제..! 마침 Java 기반으로 출간된 서적이 있어 참고하면서 공부해보려 한다. 프로그래머스 플랫폼을 통해 Java 알고리즘 문제를 꾸준히 풀겠다는 다짐도 함께 해본다.
• 정보보안기사 공부: 정처기에도 포함된 내용이지만 날이 갈수록 중요해지는 네트워크 및 보안 지식 함양을 위해 정보보안기사도 준비할 계획이다. 다만, 정처기 응시의 우선순위가 높기 때문에 공부는 진행하되 올해가 가기 전 시험 응시하는 게 목표이다.

4.3 사이드 프로젝트 진행

최근 읽은 서적에 따르면, 개발자는 사이드 프로젝트는 항시 진행해야 한다고 한다. 이 말에는 병아리 개발자인 나도 매우 공감한다. 내가 참여해본 최근 프로젝트이자 유일한 프로젝트인 『I_Look』만 보아도 그렇다. 지난 4월 25일 훈련 과정 수료 이후 내 행적은 아래와 같다.

• (25.04.28. ~ 25.05.04.) 미처 정리하지 못한 부분들 문서화
• (25.05.05. ~ 25.05.11.) 서버 재구축 및 추가 기능 구현을 위한 더미 데이터 정리, 추가 기능 구현
• (25.05.12. ~ 25.05.16.) 티스토리에 프로젝트 기록, 추가 기능 구현
• (25.05.19. ~ ) 이력서 및 포트폴리오 제작, 추가 기능 구현

여기서 주목해야할 부분은 더미 데이터 입력 및 추가 기능 구현까지 공백이 약 1주 정도 발생했다는 것인데, 일주일 만에 생각보다 많은 내용이 휘발되어 애를 먹었다. 물론 훈련과정이 종료되었다는 안도감에 긴장이 풀려 그랬을 수도 있지만 핑계일 뿐이다. 그래서 기존 프로젝트를 마무리 지음과 동시에 사이드 프로젝트의 진행이 꼭 필요하겠다는 생각이 들었다.

 

아직까지 구체적인 결정 사항은 없지만 현재 생각하기로는 아래와 같은 프로젝트를 꿈꾸고 있다.

• API 기능을 추가하여 (기존 파이널 프로젝트로 희망했던) 티켓 예매 웹 사이트 제작해보기
• Flutter 공부 후 간단한 일정 관리 모바일 앱 만들어 배포까지 진행해보기
• 웹 소켓 공부 후 알림함 기능으로 활용하여 실시간 채팅 앱 만들어보기

당연히, 다 해보고 싶은 프로젝트라 당장은 아니더라도 하나씩 시간을 내서 도전해볼 계획이다.🔥

---

5. 그 외 여담

#1.

훈련 과정 수료 전, 그러니까 팀 프로젝트를 진행하기 전까지만 해도 블로그에 진행 상황을 실시간으로 작성하고 싶었다. 그러나 내 예상보다 4월은 정말 바쁜 달이었다.

(사연이 깊지만) 예정에도 없던 팀장 역할을 맡게 되었고, 기획도 설계도 구현도 무엇 하나 쉬운 일이 없었다. 지난 2월 정처기 필기에 이어 4월에 신청해뒀던 정처기 실기 시험 준비는 커녕 하루에 잠을 3시간 이상 잔 날을 손에 꼽는다. 주말도 예외는 아니었으며, 프로젝트 마지막 주에는 일요일 밤부터 금요일 낮까지 총 14시간도 눈을 붙이지 못했을 정도다. 분명 배운 점도 많았지만, 말그대로 정말 힘들고 시간에 쫒기며 살았다.

그리고 어느새 학원 훈련 과정을 수료한지도 4주 가량 지났다. 당시에 힘들어 죽을 것 같은 시간들도 돌아보면 치열하게 살아온 흔적이라는 걸 이제는 잘 알고 있다. 이제껏 그래왔듯이 새로운 도전도 잘 해낼 거라고 스스로 믿어 의심치 않는다.

 

#2.

유한한 기억력을 가진 나를 위해 이걸 어디에 기록할지 고민하다가 어차피 여담까지 읽는 사람은 없겠지 싶어서 결국 여담에 쓰게 되었다. 바로, AI의 사용이다.

AI 도구의 등장과 발전은 학생에게 있어 양날의 검 그 자체이다. AI를 사용하면 원하는 정보를 보다 쉽게 찾을 수 있다. 대신, 해당 정보에 대한 객관적 신뢰 가능 여부는 별개의 문제이다. 난 이번 프로젝트 진행에 있어 AI를 이용한 문제 해결에 찬성하는 입장이었다. (이 입장은 지금도 마찬가지이다.) 이를 테면, 어렵거나 막히는 부분이 있을 때 AI를 활용해 빠르게 해결하는 건 똑똑한 방법이라는 입장이다. 단, AI가 내어준 해결 방안을 사용자가 제대로 이해하거나 검증할 수 있다는 걸 전제로 말이다.

우리 프로젝트 진행 시에도 종종 발생한 일이었는데, 서로의 코드를 리뷰하다보면 꼭 AI가 문제의 중심에 서있곤 했다. 에러가 발생해서 코드를 들여다보고, 이를 해결하기 위해 코드를 작성한 당사자에게 질문을 하면 "아 그거 내가 짠 게 아니라 나도 몰라. AI가 짜준거야."라는 답이 돌아오는 식이었다. 다행히 구글 검색을 통해 어찌어찌 해결한 부분도, 안타깝게도 여전히 해결하지 못한 부분도 있다. 학습 도구로써의 AI와 학습 방해자로써의 AI, 과연 AI를 똑똑하게 사용하는 건 무엇인가 라는 고민을 하게 만든 경험이었다.