15. TEAM 프로젝트: Status 200 개발 후기

1. 팀 프로젝트 시작!

공부를 시작한지 6개월이 지나고, 개인 프로젝트로 일기장, 엑셀 내 데이터로 차트를 그려주는 프로그램을 만들었다.

실력이 늘어간다는 자각보다는 늘 부족하다는 갈증에 헤맬 무렵, 실제 개발 현장에 대해서 강좌 하는 Wanted를 신청하고 볼 수 있었다.

많은 사람들이 개발자를 하길 원하고, 이 길로 정진한다는 사실을 알았을 때 뭔가 답답한 기분이 들었다.

대부분 팀으로 무언가를 만들고, 아주 멋진 프로그램들을 세상에 내놓는 사실은 내 부족한 면모를 자극하는 것 같았다. 

 

그러던 중, 우연치 않게 같이 공부하는 동기들과 팀을 결성해 팀 프로젝트를 진행할 수 있는 기회가 생겼다. 

모두 나보다 실력이 출중하고, 또한 노력도 많이 하는 친구들이기 때문에 평소에도 많이 배우고 있었다.

그런 친구들과 팀으로 무언가를 만든다는 것 자체가 설레고 자극적인 일이다. 

 

 

2. 팀 프로젝트 주제 선정

세상에는 정말 많은 개발자들이 있다. 

많은 개발자들은 각자의 재능과 역량을 살려 멋진 프로그램을 만들고, 세상에 내놓는다.

프로젝트에서 주제를 선정한다는 것은 '어떤 프로그램'을 만들지를 결정하는 것이다. 

 

우리 팀은 누군가의 의뢰에 따라 프로그램을 만드는 것이 아니고, 주제를 정하고 모인 그룹도 아니다.

때문에 우리가 직접 하나의 주제를 선정해서 개발을 진행해야 했다. 

나는 프로젝트를 시작할 당시 이미 일반적인 게시판을 제작해 보았기 때문에, 그것과는 다른 기능을 구현하고 싶었다. 

 

다양한 예비 주제가 제기되었으나, 일반적인 게시판을 벗어나지 못했다.

각자 접해본 프로그램이나 서비스 중에 참신하거나 재밌던 것을 의견으로 내보기로 했다.

교육에 관련된 사이트를 비롯하여 다양한 아이디어가 제기되었고, 팀원 중 한 분이 'Stack Overflow'가 개발에 도움이 되었다고 말했다.

 

Stack Overflow... 개발자들의 마당장터, 대도서관 같은 사이트이다. 

SMTP 포트가 접속되지 않아 다양한 경우의 수를 대조하는 과정에서 SSL 인증 문제임을 알게 된 것은 Stack Overflow 덕이였다. 

물론 우리가 Stack Overflow와 같이 매우 잘 기능하는 서비스를 만드는 것은 쉽지 않다.

하지만 기본적인 기능을 만들고, 그와 더불어 업무 협업에 필요한 툴을 제작하면 개발자 협업 도구로 용이할 것이란 생각이 들었다. 

 

우리는 Status200 이라는 프로젝트 이름을 정하고, 프로젝트에 필요한 기능을 축약하였다. 

프로그램에 필요한 기능은 크게 다음과 같다. 

 

 

1) Member & Admin: JH Park, JE Seok

기본적으로 게시글을 중심으로 서비스가 제공되기 때문에, 이를 식별하고 작성 및 수정이 가능해야 한다.

식별은 결국 회원에 대한 권한으로 진행되어야 한다. 

멤버에 대한 기능 정립과 안정화가 없다면 게시글, 캘린더에 대한 기능이 성립할 수 없다. 

서버를 제외하고 App의 관점에서 보자면 해당 기능이 우리 프로젝트의 기초인 셈이다. 

 

이전에는 몰랐으나, 이를 기획할 당시 서비스를 제작하는 개발자에게 있어서 '사용자'만이 아니라 '관리자'도 개발자가 개발하는 서비스를 경험하는 '사용자'임을 알 수 있었다. 

이전에 게시판을 만들 때(일기장), 이러한 사항을 고려하지 못했다. 

관리자에게 특별히 부여된 권한이나 데이터가 없기 때문에 축적되는 데이터를 활용하지도, 마케팅을 하는 것도 불가능했다.

이는 결국 사업의 확장은 고사하고 유지에도 미흡한 요소로 남았다.

나는 이덕에 관리자의 권한에 따른 회원 관리는 당연하고 더불어 사용자들의 이용 동향을 파악하는 것이 중요하다는 사실을 알 수 있었다. 

내가 깨달았던 내용을 팀원들과 공유하였고, 다음과 같은 기능 단위가 정해졌다. 

 

• 회원 관리 (로그인, 회원가입, 탈퇴, 수정)
• 게시글 관리 (삭제) 
• 신고 및 정지 기능 
• 이용자의 이용 동향을 확인하여 Chart로 표현

해당 단위는 JH Park님과 JE Seok님이 개발하기로 하셨다. 

 

2) Editor: DH Lee, HY Yun 

에디터는 게시글을 작성, 수정, 삭제하는 기능을 포괄하여 게시글에 대한 기능 단위를 말한다.

내가 생각하기엔 Stack Overflow와 같은 질문 및 답변 형식의 게시판에선, 분류와 답변을 달 수 있는 환경(UI)이 중요했다. 

이유는 분류가 없으면, 답변자나 질문자 모두 어떠한 주제를 선정하여 답변을 진행할지 알 수 없기 때문이다. 

알 수 없다는 것은 곧 사용자의 '불편함'을 유발한다. 

물론 의도적으로 '비공개 정보'를 통해서 사용자에게 과도한 정보를 제공하지 않아 편안함을 제공하는 경우도 있다.

하지만 대개 사이트를 이용하다가 불편함을 겪는다면 이는 '몰라서' 겪는 어려움 때문이다. 

 

또한, 답변을 작성하는 것이 복잡하지 않아야 한다. 

직관적으로 자신이 작성하는 글이 답변임을 알 수 있어야 하고, 이 내용 또한 질문자에게 부담 없이 전달되어야 한다.

쉽게 말해 폰트의 모양이 일관되고 크기 또한 일정해야 한다. 

 

그리고 에디터는 글을 작성하는 과정에서 사용자에게 더욱 편안하고 쾌적한 글쓰기 환경을 제공해야 한다.

때문에 아이콘은 직관적이고, 버튼을 누를 경우 바로 변경 사항이 확인되어야 한다. 

이미지 업로드나 정렬, Bold 등 다양한 기능이 탑재된 한편 Status200의 목적과 일치하도록 'Code' 입력이 가능해야 한다. 

 

이를 기반으로 다음과 같은 기능 단위가 결정되었다. 

 

• 게시글 관리(게시글 작성, 삭제, 수정 등) 
• 댓글 기능 
• 이미지 업로드 및 표현 기능 
• 글쓰기에 필요한 Editor 기능 

해당 단위는 DH Lee, HY Yun 님이 맡아 주셨다. 

 

3) Calendar: JongHyun Kim, JM Yoo

캘린더는 Status200의 부가 기능으로 개발자들이 협업할 수 있도록 달력과 스케줄, To do list를 제공한다. 

실제 돈을 받고 프로젝트를 수주한 적은 없지만, 개발이 PM이 설정한 일정에 따라 진행된다는 것을 알 수 있었다. 

질문이 가능하면서 자신이 해야 할 작업과 스케줄을 할 수 있다면, 개발자에게 맞는 '커뮤니티'인 동시에 '협업 툴'이 될 것에는 생각이 들었다. 

 

이에 해당 주제가 정해졌을 때, 개발자 협업을 위해 캘린더 기능을 추가해보는 것이 어떨지 제안하였다. 

다행스럽게도 팀원들에게 긍정적인 지지를 받고, 하나의 기능 단위로 할당하고 개발을 진행했다. 

 

기본적으로 Group 별로 스케줄을 확인할 수 있어야 하고, 스케줄에 대한 수정 권한을 부여하는 것도 가능해야 한다. 

더불어 To do list 기능이 있으면 편의성이 증대될 것이라는 생각을 했다.

 

이에 필요한 기능 단위는 다음과 같다. 

 

• 달력 모양 표시 
• 스케줄 관리 (추가, 삭제, 수정) 
• 그룹 관리 (추가, 삭제, 수정) 
• 그룹 멤버 및 수정자 관리 (추가, 삭제, 수정)
• 투두 리스트 

이 단위는 나와 JM Yoo님 담당하여 개발하였다. 

 

 

3. 기능 단위 세분화 

나와 JM 님은 캘린더의 전체적인 기능을 구현하는 것을 목표로 하였다.

우선 사용이 가능한 라이브러리를 검색하고 탐색하였으며, Full Calendar라는 라이브러리가 있음을 알았다. 

문제는 해당 라이브러리의 일부 기능이 비용 지불이 필요했다는 것, 기능 구현에 있어서 라이브러리 특성상 제약 조건이 발생한다는 점이다. 

특히 그룹 별로 스케줄을 표현해야 하는데, 이를 기능으로 제공하지 않았다. 

 

이에 나와 JM 님은 상의를 통해 직접 Calendar를 제작해보자는 결론을 내렸다. 

다만 JM 님이 Java를 주로 사용하여 개발을 하셨기 때문에, Java Script가 익숙하지 않다는 문제가 있었다. 

때문에 JM 님이 개발을 진행하는 과정에서 Java Script를 익히셔야 할 시간이 필요했고, 이에 기능 단위를 나눌 때 정확한 절반이 아닌 서로의 조율점을 정하여 기능 단위를 설정했다. 

 

다음은 각자 맡은 기능 단위를 정리한 것이다. 

 

JM Yoo 

• 캘린더 일간 모양 구현
• 캘린더 일간에서 스케줄 표현
• 캘린더 일간에서 그룹에 따라 스케줄 보기 기능
• 캘린더 일간에서 스케줄 추가하기
• 캘린더 레이아웃 중 [이전 및 다음 날짜 이동 기능]을 일간 모양에 맞게 구현
• 캘린더 일간 디자인

 

JongHyun Kim 

• 캘린더 레이아웃 모양 구현
• 캘린더 레이아웃 기능 구현 
• 캘린더 연간 모양 구현
• 캘린더 연간 스케줄 표현
• 캘린더 연간 모양의 요소 클릭 시 해당 월로 이동
• 캘린더 월간 모양 구현 
• 캘린더 월간 스케줄 표현 
• 캘린더 월간에서 그룹에 따라 스케줄 보기 기능
• 캘린더 월간에서 스케줄 추가하기  
• 캘린더 그룹 관리 레이아웃 구현
• 캘린더 그룹 관리 기능 구현 
• 캘린더 그룹원 추가 및 실시간 알림 기능 구현 
• 캘린더 그룹원 중 수정자 권한을 추가 및 삭제 
• 투두 리스트 레이아웃 구현
• 투두리스트 추가, 삭제, 수정 기능 구현
• 투두리스트 완료된 목록 한 번에 삭제 기능 구현
• 캘린더 월간, 연간, 레이아웃, 투두 리스트, 그룹에 대한 디자인 

위와는 별개로 나는 아래의 단위로 추가로 개발하였다. 

• 사이트의 Header 영역의 디자인 및 메뉴 표시 기능

 

4. 주로 사용한 언어 및 기술

1) 공동 사용 언어 및 도구

 

기본적인 개발 툴은 Eclipse와 Mysql 8.0으로 설정하였다. 

기술원 동기들이기 때문에 같은 버전의 개발 툴로 개발을 했기 때문에 개발 툴 및 언어의 버전 설정은 어려움이 없었다. 

 

다만 Git은 우리가 배우는 과정 커리큘럼에 없었기 때문에, 별도로 공부가 필요했다. 

이에 나는 조장인 DH Lee 님과 여러 차례 이야기를 진행하였고, 나중을 위해서라도 Git을 사용하기로 결정하였다. 

 

팀원 중 누구도 Git을 사용해본 경험이 없고, 배운 적도 없었기 때문에 나는 이를 정리하고 익히기로 결정하였다.

정리하는 이유는 팀원들에게 공유하고, Git에 대한 내용을 알려주기 위해서이다. 

 

평일에 시간을 내서 Git을 별도로 정리하였고, 총 49 페이지의 정리본을 만들었다. (블로그에는 추후에 업데이트할 예정이다.)

해당 정리본을 팀원에게 공유하고, 주말 동안 공부해올 것을 권유하였으며, 이후 개발 초기 단계에서 거의 매일같이 사용방법이나 기본적인 Git의 개념을 설명해주었다. 

 

약 1주일간 Git에 대한 개념과 방법을 익혔고, 이후 본격적으로 개발이 시작할 수 있었다. 

 

2) 캘린더에 적용된 기술

캘린더에는 주로 AJAX를 통한 통신과 Servlet 통신이 활용되었다.

캘린더 자체가 Java Script로 구현되었고, 해당 Java Script는 창이 새로고침 되면 데이터를 유지할 수 없다.

때문에 AJAX로 동적인 움직임에 따른 변경점을 DB에 저장하는 것을 기본으로 하였고, DB와 통신을 위해 Servlet을 사용했다.

HTML 5 표준에 따라 Color, Date 타입의 Input 태그를 사용하였으며, Socket 네트워크를 생성하여 통신을 진행했다.

Socket 네트워크는 캘린더 페이지에 접속한 상태라면, 초대가 올 시 (그룹원으로 초대) 바로 알림을 통해 표시해준다. 

 

• JSP
• Java (Servlet)
• Java Script 
• Apache Tomcat
• Git hub
• Http Request, Response
• Ajax 
• Socket Network 
• MySQL
• JSON 
• JSTL(Tag Library)

 

 

5. DB 설계 

해당 설계 및 이미지 촬영은 ERD 웹에서 진행하였다.

 

Member 및 Paragraph에 대한 DB 설계 및 쿼리문은 우리 조장님인 DH Lee 님께서 작성해주셨다. 

이외에 Calendar에 관련된 DB는 모두 내가 설계하고 SQL을 구성하였다. 

 

E-R 모델에 익숙하지 않아 DB에서 적용하는 관계와 그 유용성에 대한 이해도가 부족하였다.

때문에 고유키를 설정할 때, 외래 키 혹은 복합키로 구현이 가능한 영역도 Num을 따로 설정하여 구현하였다.

데이터 정제하는 과정은 편하지만, DB에 대한 이해도가 더 있었다면 정확한 관계도 및 구성을 최적화하는 것이 가능했을 것이다. 

 

위의 이미지는 다음 사이트에서 진행하였다. 

해당 웹페이지를 개발해주신 개발자분 혹은 개발자분들의 노고에 감사드린다. (https://www.erdcloud.com/)

 

 

6. 개발 진행 및 디버그

1) 개발 기간

 

해당 프로젝트는 약 1달여 시간을 들여서 개발을 진행하였다.

기술원 주관으로 진행한 팀 프로젝트이기 때문에 마지막 3일은 발표를 준비하는 데 사용하였다. 

Git을 학습하는 시간 및 2차례의 공휴일(10월 3일, 10월 9일)로 개발 시간에 다소 차질이 발생하였다. 

 

Calendar 및 Editor 개발 단계에서 발생한 오류를 해결하는 디버깅 과정에 시간이 다소 소요되었고, 협업 과정에서 방지할 수 있는 혼선 또한 개발 시간을 늦추는데 일조하였다. 

 

추후에 개선점에서 다루겠으나, 다사다난한 개발 과정에서 정확하게 짚지 못한 항목이 몇 가지 존재하였다. 

발표는 무리 없이 잘 진행되었으며, Calendar 기능 단위 개발과 발표는 내가 전담하였다.

발표 과정에서도 목소리나 어조에 대한 개선점을 발견할 수 있었다. 

 

2) 개발 중 발생한 문제점과 해결

개발 중에 발생했던 오류들은 대부분 문법이나 철자 오류 등이었으나, 간혹 라이브러리 참조 오류가 발생하였다. 

DH Lee님이 사용하는 lib 파일들이 갑자기 손상되는 문제가 발생하였고, 해당 문제로 인해 나 또한 개발을 중단하고 코드를 확인하면서 같이 문제를 탐색했다. 

문제를 탐색하던 도중 status 500 이 확인되며 일부 페이지에서 문제가 발생하는 것을 알게 되었다. 

문제가 발생하는 Exception 항목이 JSTL 구문과 연관이 있음을 파악했고, 라이브러리를 삭제 후 재차 다운로드하여 삽입하는 것으로 문제를 해결하였다. 

 

이외에도 개발 과정에서 겪는 크고 작은 문제들에 대해서 팀원들과 협력하여 문제를 해결하는 과정을 즐겼으며, 캘린더의 경우 JM Yoo님이 요청하는 항목에 대해서 최선을 다해 해결책을 모색하였다.

물론 JM Yoo님이 스스로 대부분 문제를 해결하기도 하였으나, 내가 만들어둔 function과의 호환 문제 등으로 발생하는 문제 해결은 같이 진행하였다. 

 

프로그래머의 역량에서 문제 해결을 중요시한다면, 이 문제를 해결하기 위해서 어떻게 접근하냐는 말할 것도 없이 중요한 기초 항목일 것이다. 

비전공자, 거기다가 이전에는 주로 인문학이나 사회복지에 관련된 공부를 진행했기 때문에 프로그램에서 발생한 오류를 해결하는 과정은 늘 조심스럽다.

팀 프로젝트를 하면서 팀원들이 맞닥뜨린 문제는 대부분 처음 경험하는 류의 오류였다.

Classpath를 수정하여 문제를 해결하거나 Exception이 발생할 수 있는 경우의 수를 추적하면서 문제를 해결하려고 노력하였다. 

 

나에게 높은 지능이 있어서 문제를 곧바로 해결하는 영민함은 없지만, 적어도 문제를 보고 이를 접근하는 방법은 알고 있다. 

내게 비상한 머리가 있다면 시행착오를 최소화하면서 모든 경우의 수를 계산하고 프로그래밍을 진행하겠으나, 그렇지 않기에 지속적으로 도전하고 시도해서 문제를 해결했다.

 

3) 디버그 

디버그는 팀원들이 각자 개발한 개발 단위에서 진행하였다.

디버그와 함께 CSS 삽입도 같이 진행하여, CSS 조정에 따라 코드 수정이 발생하기도 했다. 

 

캘린더 또한 디버깅을 진행하면서 오류가 발생할 수 있는 경우의 수를 탐색하고, Dead Code는 없는지 확인하였다. 

대부분 Java Script에서 코드를 작성하여, 문법 오류나 참조 오류 시 기능이 멈추는 일이 많았다.

때문에 버그를 끊임없이 수정하면서 개발을 진행하였다. 

 

결과 디버그 과정에서 발견하고 확인한 버그는 기능에 따라 변화하는 변수들에 대해서 미처 고려하지 못한 예외 상황일 경우가 대부분이었다. 

이를 해결하기 위해 접근 방법이나 변수를 참조하는 방식을 변경하는 식으로 변경을 줬다. 

기능 단위에서 세부적으로 발생할 수 있는 UI 문제는 실제 사용을 통해서 파악해야 하므로 완벽한 파악이 어려웠다.

UI의 경우 사용자의 환경에 영향을 많이 받아서 실제 다른 기기나 컴퓨터로 테스트가 필요한데, 이런 장비가 녹록지 않았기 때문이다. 

 

디버그가 완료된 후에 3WC 표준 검사를 통해 HTML 및 CSS에 대한 적합성을 확인하고, 이에 맞게 수정하며 마무리하였다. 

 

7. 개선점과 느낀 점 

1) 개선점 

개발 과정에서 기능에 대한 개선점을 말하자면, 다음 5가지를 이야기할 것이다.

 

1. 캘린더 스케줄 요소 정렬
2. 캘린더 스케줄 요소의 동기화
3. 그룹의 검색 기능 
4. 그룹 별 게시판 제작 및 서비스 확대
5. To do list의 정렬 알고리즘 개선

 

스케줄 요소의 정렬은 2차 배열을 사용하여야 하는데, 브라우저의 메모리 용량에 한계로 한 번에 이를 생성하고 해결할 수 없다. 

또한 정렬할 때 스케줄에 대한 데이터를 기준으로 영역을 계산하고, 계산한 영역을 적용해서 알고리즘을 구현해야 한다. 

이러한 과정에서 몇몇 호환 코드를 수정하여야 하는 문제를 직면하였고, 개발 시간 내로 진행이 어렵다고 봐서 이를 진행할 수 없었다. 

그 외에 요소 또한 방법을 숙지하고 있으나 시간적 여유가 없어 진행이 불가능했다. 

 

시간이나 인력이 더할당되면 해결이 가능한 영역이었고, 해결책에 대한 방법을 이해하고 있었어 기능적인 개선점보다 팀 프로젝트를 하면서 내가 느낀 '자신에 대한 미숙함'이 더 큰 자산으로 남았다고 생각한다. 

 

내가 팀프로젝트를 하면서 느낀 '자신'에 대한 개선점은 다음과 같다.

 

• 팀프로젝트를 진행할 때, 실제로 어떻게 개발 과정과 프로세스가 진행되어야 하는지를 충분히 인지하지 못하고 개발을 진행했다. 
• 개발 프로세스를 이해하지 못한 상태이기 때문에, 요구 사항 확인 과정이 매우 미숙하였다.
• DB에 대한 이해도가 빈약하여, E-R 모델링 등을 진행하는 것이 어려웠다. DB에서 Join이나 Union을 어떻게 사용하고, 어떤 이점이 있는지 등 기초적인 지식이 미흡하다. 
• 의사소통 과정에서 정확한 정보 전달을 위한 언어 선택이 미흡했다. 예를 들어, 문장에서 조사나 목적어가 생략되거나 2 중적 해석이 가능한 문장을 간혹 사용하였다. 
• 팀원의 역량을 정확히 파악하고, 적절한 백업을 진행하지 못했다. 팀원들이 어려워하는 영역에 대해서 대략적인 해결책이나 조언, 피드백만을 진행하고 실제 해당 문제를 해결하기 위한 자세하고 계획적인 절차를 이행하지 못한 경우가 있다. 자신의 개발 단위를 위해서였지만, 팀원에게 좀 더 관심을 기울일 필요가 있었다. 
• EL 및 JSTL에 대한 이해와 사용이 완벽하지 않았다. 생소하지는 않았으나 구체적으로 어떻게 사용하며, 바로 사용이 가능한 수준으로 숙달되지 못했다. 
• Java의 람다 및 File buffer에 대한 전반적인 이해도가 부족했다. 

 

위의 개선점은 현재 진행하고 있는 개인 프로젝트와 병행하여 하나하나 해결하려 한다.

 

2) 느낀 점 

팀 프로젝트를 하면서 느낀 점은 나의 부족하고 모자란 능력을 다른 사람이 채워줄 수 있다는 것이다.

난 늦은 나이에 개발 공부를 시작했고, 이전에는 인문학이나 사회과학은 주로 공부했다. 

늦은 나이에 시작했다는 자각이 있었기 때문에 늘 초조하고 또한 불안한 마음도 든다.

 

팀프로젝트를 하면서 같이 노력하는 동기들은 끊어지지 않는 열정과 노력으로 문제를 해결하려고 최선을 다했다. 

나 또한 그들에게 고무되어 최선을 다할 수 있었다.

동기 중에 한 분이 오류를 어떻게 다 해결하고, 어떻게 이 문제들을 다 해결할 수 있냐는 질문을 했었다.

 

솔직하게 말하자면, 나는 그 오류를 처음 보고 처음 경험했다.

난 그저 내가 아는 한도에서 그 문제에 순차적을 접근했던 것뿐이다.

그리고 운 좋게 해결되었다고 밖에 말할 수 없다.

 

대개 모든 오류들이 해결하고 보면 그 원인이 보이듯이, 우연히 나도 원인을 찾은 것뿐이다.

운도 실력이라고 말할 수 있겠지만, 난 논리적으로 프로그램을 만드는 사람이 되고 싶다.

다르게 말하자면 'Lucky quess'가 아닌 논리적인 해결이 필요하다는 것이다.

 

나는 수재도 아니고 천재도 아니다. 

나보다 똑똑한 사람들도 많고, 지능과 상관없이 누군가에게 배울 점은 늘 있다.

난 내가 아는 것 밖에 보지 못하고, 내가 아는 내에서 밖에서 생각하지 못한다.

나의 시선은 내 생각보다 편협하다.

 

그렇기 때문에 이번 팀 프로젝트는, 나의 시선을 확장하는데 큰 도움이 됐다. 

무엇보다 좋은 사람들과 좋은 주제로 공부를 하고, 프로그램을 만들었다는 것에 크게 만족하고 있다.

 

많은 것을 느끼고 개선할 점을 찾은 매우 귀중한 시간이었다. 

실무에서도 많은 것을 배우고, 회사와 프로젝트에 기여할 수 있는 개발자가 되기를 바라면서 긴 여정을 마친다.