평행일기

1. 1 / 22
평행일기 결과보고서
고급 웹프로그래밍
14109388 홍 진 백
14109362 이 창 재
14109367 장 종 진

2. 2 / 22
1. 팀원
성명 소속 학년 학번 연락처 e-mail
홍진백 컴퓨터공학과 3 14109388 01034069654 eurobin1234@gmail.com
이창재 컴퓨터공학과 3 14109362 01029821831 ckdwomn@live.com
장종진 컴퓨터공학과 3 14109367 01055287018 triplejjj03@gmail.com
2. 프로젝트 개요 및 목표
현재 연인들에 관련한 대부분의 애플리케이션들은 단순히 서로 간의 메신저 및 미디어 공유 기
능만 지원할 뿐 그 이상의 기능을 제공하지는 않습니다. 게다가 메신저 및 미디어 공유는 카카오
톡이나 라인과 같이 이미 대체 가능한 좋은 서비스들이 많습니다.
본 프로젝트에서는 '평행일기(Parallel Diary)'라는 프로그래시브 웹 애플리케이션(Progressive
Web Application)을 만들고자 합니다. 이 웹 앱은 그저 단편적인 메신저가 아닙니다. 하루를 마
무리하면서 오늘 하루가 어땠는지, 어떤 일이 있었는지를 기록하여 서로의 일상을 한 화면에 공
유하는 '일기' 애플리케이션입니다.
평행일기는 서로 자주 만나지 못하는 장거리 커플이 주요 타겟입니다. 보통 장거리 커플은 메
신저로만 단편적으로 감정 없이 이야기를 하다가, 결국 바쁘기도 하고 대화도 부족하다 보니 연
락이 끊어져 버리는 경우가 많습니다.
따라서 본 프로젝트는 평행일기를 통해 인스턴트식품 같은 메신저가 아니라 마치 옛 시절의 편
지처럼, Slow-food 같은 서비스를 제공하는 것이 최종 목표입니다. 평행일기는 연인에게 나의 일
상을 공유하고, 자신의 이야기를 공유하여, 서로의 마음을 이어 나갈 수 있게 도와줄 것입니다.

3. 3 / 22
3. 프로젝트 진행 방법 및 절차
초반 절차는 먼저 디자인과 기능을 간략하게 구상하기 위한 Prototype을 제작하였고, 이 과정
에서 필요한 기능과, 해당 기능에 대한 개선점을 팀 내부적으로 논의하였습니다. 최종 Prototype
이 완성된 이후, 본격적인 “살 붙이기 작업”인 Front-end와 Back-end 작업을 시작했습니다.
Front-end 작업의 경우 Back-end 즉, Controller에서 오는 JSON 및, http Request를 효과적으로
전달받아 표현하기 위한 레이아웃과 정렬 방식에 집중했습니다. Back-end의 경우 기본적인 DB 액
세스 기능(삽입, 삭제, 수정) 기능을 먼저 구현하고 난 이후, 회원 탈퇴 기능, 로그인 기능, 회원관
리 기능을 넣음과 동시에 Progressive Web App을 구현하는 작업을 했습니다.
[Heroku PaaS 기능 설명도]
프로젝트는 Node.js의 Express 프레임워크와 MySQL 환경을 먼저 로컬에서 구현을 한 다음, 로
컬 상에서 정상적으로 작동하는지를 체크하고 실 서버인 Heroku에 배포하는 과정으로 이루어졌
습니다. Heroku의 경우 PaaS 특성상 뛰어난 서버 관리기능(dynos 설정, 로그 분석, DB관리, 유지보
수 모드)을 가지고 있기 때문에 배포 후 관리과정이 간편하기 때문입니다.
초기에는 서버 Hosting 및 Database사용을 위해 PaaS 클라우드 서비스로 구글의 Firebase를 이
용하려고 하였으나, 사용하고자 하였던 Cloud Firestore Database가 아직 beta버전이었기에 관련
document가 부족하여 사용하기 힘들다고 판단하였습니다. 따라서 친숙하면서도 확실한 관계형
데이터 베이스인 MySQL을 이용하기로 하였고 해당 MySQL Database 환경을 ClearDB add-on을
통해 지원하는 Heroku 서비스를 이용하게 되었습니다.

4. 4 / 22
4. 프로젝트 설계
평행일기는 Node.js의 Express와 MySQL을 이용한 MVC 구조로 설계되었습니다. DB에 해당하는
Model의 경우에는 MySQL을 사용하였고, 클라이언트 페이지에 해당하는 View의 경우에는 EJS 템
플릿 엔진을 사용하였으며 더불어 Materialize 라이브러리와 JQuery를 사용하였습니다. 사이트의
서버 측 기능에 해당하는 Controller의 경우에는 각 Router에 해당하는 페이지의 기능을 직접 작
성했습니다. 각각의 디렉터리와 정보는 다음과 같습니다.
[ Model ] [ View ] [ Controller ]

5. 5 / 22
4-1. DB 구조
USER TABLE
• USER_PID : PRIMARY_KEY 각 유저를 식별하기 위한 키.
• NICKNAME : 각 유저의 닉네임 / ID 대용으로 사용.
• PASSWORD : 패스워드 / 보안을 위해 SHA-256 으로 인코딩.
• E_MAIL : 유저의 이메일 / 로그인용, 식별용으로 사용.
• MATCH : 서로 커플로 등록되어 있는 유저의 PID 값이 저장됨.
• IS_COUPLE : 커플인지의 여부를 저장하는 키
연인이 없을 경우엔 null / 커플 요청을 받았을 경우엔 0
현재 커플일 경우엔 1 / 커플 요청을 보냈을 경우엔 2
• OP1 : 비밀번호 찾기를 위한 질문키 1 / 보안을 위해 SHA-256 으로 인코딩.
• OP2 : 비밀번호 찾기를 위한 질문키 2 / 보안을 위해 SHA-256 으로 인코딩.
• OP3 : 비밀번호 찾기를 위한 질문키 3 / 보안을 위해 SHA-256 으로 인코딩.
• ANSWER1 : 비밀번호 찾기 질문 답변이 저장 1 / 보안을 위해 SHA-256 으로 인코딩.
• ANSWER2 : 비밀번호 찾기 질문 답변이 저장 2 / 보안을 위해 SHA-256 으로 인코딩
• ANSWER3 : 비밀번호 찾기 질문 답변이 저장 3 / 보안을 위해 SHA-256 으로 인코딩
• TOKEN : FCM 을 위한 토큰 정보
DIARY TABLE
• DIARY_PID : PRIMARY_KEY 각 일기를 식별하기 위한 키
• DATE : 일기를 작성한 날짜. / YYYYMMDD 으로 저장됨.
• USER_PID : FOREIGN KEY 일기를 작성한 유저의 USER_PID 의 값.
• TEXT : 일기의 내용. / HTML 코드가 들어감.
• IMG_URL : 일기에 사용될 이미지의 이미지 url 이 저장됨.
• TIME : 일기를 작성한 정확한 시간이 저장됨. / JS 의 Date() 객체 값
• IS_DELETED : 일기를 삭제한 여부를 저장함
DB 구조는 다음과 같습니다. 한 유저는 여러 일기를 작성할 수 있습니다. 따라서 USER TABLE
과 DIARY TABLE은 일 대 다 관계를 가지고, DIARY TABLE의 ‘USER_PID’가 USER TABLE의
‘USER_PID’와 Foreign Key를 맺고 있습니다.
사용자들의 보안을 위해 테이블 중 개인정보가 되는 정보, 예를 들어 비밀번호, 질문 키, 질문
키에 대한 답, 토큰 정보 등은 전부 SHA-256으로 암호화됩니다. 닉네임, 일기의 내용(TEXT)의 경
우에는 한글처리와 내용 보호를 위해서 BASE64로 인코딩 했습니다.

6. 6 / 22
4-2. 기능도
4-3. 각각에 사용된 모듈
각각의 기능에 사용된 모듈은 다음과 같습니다.
1. mysql 모듈
2. express 기본 제공 모듈들 : ejs, body-parser, …
3. 한국시간 설정 모듈 : moment, moment-timezone
4. Firebase 모듈 : firebase, firebase-functions, firebase-admin
5. 암호화/인코딩 모듈 : sha-256, base64, utf-8
6. 이미지 업로드 모듈 : multer
7. 파일 입출력 모듈 : path

7. 7 / 22
4-4. Progressive Web App
본 평행일기는 일반적인 Web App이 아닌 Progressive Web App(이후 PWA)으로 구현되었습니
다. 일반적인 Web App이 PWA가 되기 위해서는 여러 조건을 만족해야 하지만 그 조건들 중 대
표적인 것이 Native App / Push Alarm / Offline 세가지입니다. 해당 세가지 조건을 만족하기 위해
다음과 같이 설계하였습니다.
1. Native App
먼저 PWA가 되기 위해서는 Native App처럼 설치가 가능해야 합니다. 이를 위해 다음과
같이 Web App Manifest를 구성하였습니다.
이후 해당 manifest를 각 페이지에 link시켰고, 각 운영체제별로 적합한 Native Application
환경을 제공하기 위해 아이콘 및 테마 설정을 다음과 같이 설계하였습니다.

8. 8 / 22
2. Push Alarm
두 번째로 PWA가 되기 위해서는 사용자들의 재참여성을 위해 Push Alarm을 지원해야 한
다는 점입니다. 이를 위해 본 평행일기에서는 Firebase Cloud Messaging(이후 FCM)서비스를
이용하여 다음과 같이 설계하였습니다.
먼저 FCM을 이용하기 위해서는 사용자의 기기 인식을 위해 토큰 값이 필요합니다. 사용
자가 로그인을 하고 Push Alarm을 허용했을 때, 클라이언트단에서 Firebase messaging 함수
를 이용하여 FCM 서버로부터 생성된 사용자 기기의 토큰 값을 받아 ajax을 통해 서버단으
로 넘겨 DB에 저장을 합니다.
Push Alarm의 송신은 서버단에서 이루어집니다. 수신할 유저의 토큰 값과 수신할 메시지
의 제목, 본문, 알림 사운드, 알림 아이콘, 그리고 알림을 클릭할 시에 보일 액션, 중요도를
설정하여 payload변수에 담아 fcm함수를 이용하여 송신합니다.
Push Alarm의 수신은 두 가지로 나뉩니다. 첫 번째로 평행일기 애플리케이션을 사용하고
있을 경우인 Foreground상태일 경우, 두 번째로 애플리케이션을 사용하고 있지 않은 상태인
Background상태일 경우 각각 알람을 어떻게 수신해야 할지 설정해야 합니다. 보통은 두가지
경우를 구분하여 수신부를 구현하지만 해당 프로젝트에선 foreground와 background 모두
Service Worker를 이용하여 구현하였습니다. Push 이벤트가 발생했을 경우에 해당 알람을 띄
우는 함수를 firebase-messaging-sw.js를 통해 Service Worker를 구현하여 평행일기를 처음
접속했을 때 해당 서비스 워커가 설치되도록 설계하였습니다.

9. 9 / 22
3. Offline
세 번째로 PWA가 되기 위해서는 네트워크에서 독립적이여야 한다는 점입니다. 오프라인
이나 불안한 네트워크 연결에서도 해당 애플리케이션이 동작 가능해야 합니다. 실제로 설치
가능한 Native App을 떠올려보면 오프라인 상태에서 현재 오프라인 상태라는 정보를 해당
애플리케이션에 맞는 UI로 알려줍니다. 따라서 해당 기능을 구현하기 위해 다음과 같이
Service Worker를 설계하였습니다.
먼저 pwabuilder-sw-register.js를 통해 현재 navigator에 Service Worker가 설치되어 있는지
확인합니다. 설치되어 있으면 설치되어 있다는 로그를 콘솔상에 남기고, 설치되어 있지 않으
면 pwabuilder-sw.js를 Service Worker상에 설치합니다.
pwabuilder-sw.js는 다음과 같은 기능을 담당하도록 설계하였습니다. 일단 해당 Service
Worker가 설치될 때 미리 구현해 놓은 오프라인을 위한 페이지를 캐시에 설정해 둡니다. 만
약 패치에 실패하였을 경우(Error) 오프라인 상태로 간주하고 이전에 캐시에 설정해둔 오프
라인 페이지를 띄워줍니다. 제대로 설치가 되었다면 활성화되어 있다가 만약 페이지가 fire
되었을 때는 Service Worker에게 오프라인 페이지를 업데이트하도록 요청합니다.

10. 10 / 22
5. 프로젝트 진행 내용
주차 세부 계획
1주차 기본 구조 및 디자인 설계 (Prototype)
2주차
Front-end 제작 + Back-end 설계/구현
3주차
4주차 호환 작업 및 리팩토링
5주차 디버깅 및 베타 테스트, 클라우드 서버 배포
프로젝트 진행과 관련된 협업과 버전 관리 및, 디버깅 작업을 위해 본 프로젝트에서는 GitHub를
사용하여 개발을 시작하였습니다.
1주차 기본구조 및 디자인 설계는 먼저 프로토타입을 작성하고 설계를 시작했습니다. 프로토타
입의 경우 Materialize CSS Library를 사용하여 디자인 및 레이아웃을 간략하게 설정했습니다. 그리
고 사이트에 사용될 DB의 table 구조를 정하고, 개발 방식과 코드 작성 규칙을 정했습니다.
2~3주차의 경우에는 1주 차에 설계한 프로토타입을 기반으로, 클라이언트 측의 페이지인 Front-
end 작업과 서버 측 Back-end 작업을 같이 진행하였습니다. 이 과정은 GitHub를 통해 개발이 이
루어졌으며, 한 사람당 작업할 부분을 서로 정하고 작업이 완료되는 대로 팀원들에게 알리고 자
신이 개발한 부분을 커밋(Commit) 하는 방식으로 진행되었습니다. 해당 부분의 자세한 진행 사항
은 GitHub의 Commit 로그에 기록되어 있습니다.
4주 차에서는 이후 실 서버에 배포하기 위한 전 작업으로 실 서버와의 호환성 작업을 거쳤습니
다. 이 과정에서 발생하는 오류를 최대한 디버깅(Debugging) 하는 작업을 거쳤고 또한 코드의 에
러를 줄이기 위해 Hard-coding된 부분을 리팩토링(Refactoring) 하는 작업이 있었습니다.

11. 11 / 22
5주 차에서는 디버깅 작업 팀원 두 명, 베타 테스트 작업을 하는 팀원 한 명으로 구성하여, 집중
적인 팀 내 디버깅작업을 거쳤고 이후 실 서버, Heroku에 배포 작업을 하였습니다. 그 후 평행일
기의 주요 기능들과 Progressive Web App의 기능들이 실 서버 환경에서도 제대로 동작하는지, 다
른 운영체제 및 타 플랫폼 환경에서도 올바르게 동작하는지, 그리고 디자인 측면에서 CSS가 깨지
는 부분이 없는지 등을 팀 내부적으로 테스팅 하였습니다. 그리고 어느정도 내부 테스팅이 완료
된 이후 주변 친구나 지인분들께 베타 테스팅 및 피드백을 요청하였습니다. 해당 버그 리포트 및
피드백 사항을 받아 검토하였고 필요한 부분들은 채택하여 구현함으로써 평행일기의 완성도를 더
욱 높일 수 있었습니다. 해당 로그들의 자세한 사항은 GitHub의 wiki에 1차, 2차 로그 페이지에서
확인할 수 있습니다.
6. 프로젝트 수행 결과
6-1. 메인 기능
6-1-1. 메인 페이지
메인 페이지에서는 평행일기에 대한 소개 글을 볼 수 있고 상단 nav바를 통해 다른 페이
지로 이동할 수 있습니다. 반응형 디자인을 채택하였기에 모바일 화면에서는 상단 바에 햄
버거 메뉴가 생성되고, 사이드바를 통해 다른 페이지로 이동할 수 있습니다.

12. 12 / 22
6-1-2. 로그인 페이지
로그인 페이지에서는 로그인 폼과, 회원가입, 비밀번호 재설정 페이지 링크가 있습니다.
6-1-2. 회원가입 페이지
회원가입의 경우에는 닉네임과 비밀번호, 그리고 이메일을 수집합니다. 또한 비밀번호
찾기용 질문은 향후 비밀번호를 잊어버리거나 재설정을 할 시에 본인인증용으로 사용합
니다. 사용자가 직접 비밀번호 찾기용 질문의 공란과 답변의 공란을 채워서 복잡도를 늘
리는 방향으로 설계하였습니다.

13. 13 / 22
향후 비밀번호를 잊어버렸을 때 비밀번호를 찾기 위해 반드시 필요한 정보이므로, 당
부사항을 체크하도록 구현하였습니다. 체크하지 않은 상태에서는 회원가입이 이루어지지
않습니다.
6-1-3. 비밀번호 재설정 페이지
기본정보와 비밀번호 찾기 질문을 통해 비밀번호를 재설정하는 페이지입니다. 모든 정
보가 정확히 일치되어야 비밀번호를 수정할 수 있습니다. 해당 페이지는 로그인을 하지
않은 상태, 즉 비밀번호를 잊어버렸거나 로그인 후 비밀번호를 변경할 때 두 케이스에서
사용되는 페이지입니다.

14. 14 / 22
6-1-4. 일기 페이지
각각의 일기 페이지는 모바일 기준 위쪽, 데스크탑 기준 왼쪽에 자신의 일기가 보이며,
반대편에서는 상대방의 일기가 보입니다. 처음 접속하여 보이는 일기는 접속 일을 기준
으로 한 날짜에만 작성한 페이지가 나타납니다. 일기의 상단에는 오늘 쓸 일기를 작성할
수 있습니다. 또한 이미지 첨부도 가능합니다.
페이지 오른쪽 아래 부분에서는 떠다니는 버튼이 있는데 해당 버튼은 클릭하면 다음과
같이 펼쳐지는 Floating Action Button입니다. 처음 달력모양은 다음과 같이 과거에 작성한
일기로 이동할 수 있습니다. 그리고 그 다음에는 새로고침, 그 밑에는 페이지 최상단으로
스크롤되는 편의기능이 있습니다.

15. 15 / 22
6-1-5. 계정 페이지
계정 페이지 에서는 비밀번호 업데이트, 커플신청(커플 등록 전), 이별신청(커플 등록
후)을 할 수 있습니다. 상단에는 닉네임과 이메일, 그리고 커플 요청를 위한 유저번호가
있습니다.

16. 16 / 22
실제 커플 요청을 보내게 되면 중간 타일이 다음과 같이 변경됩니다. 요청을 보낸 사
람은 상대방이 커플요청을 받을 때 까지 기다리거나 취소할 수 있고 요청을 받은 사람은
수락하거나 거절할 수 있습니다.
이별신청을 요청할 시에는 위과 같이 총 5번의 경고 창을 띄웁니다. 회원이 이별을 신
청하기 전 다시 한번 진심으로 생각해 볼 수 있도록 하기 위한 배려로 제작되었습니다.
이별신청이 이루어지면 본인의 일기와 해당 커플이 작성한 일기, 그리고 모든 이미지 파
일이 상대방에게 통보 없이 즉시 삭제되고 본인의 계정이 파기됩니다.

17. 17 / 22
6-2. Progressive Web App
6-2-1. Native App
위와 같이 Web App Manifest를 구성한 평행일기는 마치 하나의 Native App처럼 설치
가 되는 것을 확인할 수 있습니다.
실제로 구동을 할 시, 기존 Web App은 왼쪽과 같이 단순히 인터넷 브라우저 내에서
마치 애플리케이션처럼 사용할 수 있었던 것에 반해, PWA는 오른쪽과 같이 실제 하나의
애플리케이션처럼 작동하는 것을 확인할 수 있습니다.
해당 Native App 기능은 PC 운영체제로는 Windows OS, 모바일 운영체제로는
Android, iOS의 경우에는 11.3이상 버전부터 사용할 수 있습니다. Mac OS나 iOS 11.3 미
만 버전에서는 설치는 가능하지만 Native App처럼 작동하지 않습니다.

18. 18 / 22
6-2-2. Push Alarm
Firebase Cloud Messaging 서비스를 이용해 Service Worker를 통하여 Push Alarm을 구
현한 평행일기는 위와 같이 PC에서도 모바일에서도 Push Alarm 수신할 수 있음을 확인
할 수 있습니다. 평행일기에서 현재 제공하는 Push Alarm은 다른 누군가로부터 커플 요
청을 받았을 때, 요청을 수락했을 때, 요청을 거절했을 때, 그리고 커플이 새로운 글을
등록했을 때 Push Alarm이 발송됩니다.
해당 Push Alarm 기능은 PC 운영체제로는 Windows OS, 모바일 운영체제로는 Android
에서 사용할 수 있습니다. Mac OS나 iOS에선 아직까지 PWA기능으로 Push Alarm을 지원
하지 않기 때문에 사용할 수 없습니다.
6-2-3. Offline
Service Worker를 통해 오프라인을 위한 페이지를 캐시상에 설정해 둔 평행일기는 위
와같이 오프라인 상태일 때 해당 페이지를 띄워주는 것을 확인할 수 있습니다. 이를 통
해 한층 더 Native App과 같은 환경을 사용자들에게 제공해 줄 수 있습니다.
해당 Native App 기능은 PC 운영체제로는 Windows OS와 Safari 11.1 이상 버전이 설
치된 Mac OS, 모바일 운영체제로는 Android, iOS의 경우에는 11.3이상 버전부터 사용할
수 있습니다. Safari 11.1 미만의 Mac OS나 iOS 11.3 미만 버전에서는 해당 기능의 핵심
기술인 Service Worker를 지원하지 않기 때문에 사용할 수 없습니다.

19. 19 / 22
7. 설계 요소 평가
7-1. 성능
[Lighthouse Report]
Lighthouse는 웹 앱 품질을 개선할 수 있도록 report해주는 오픈 소스 자동화 도구입니다. 해
당 평행일기를 Lighthouse를 통해 성능(Performance), 프로그래시브 웹 앱(Progressive Web App),
두 부분을 검사해 보았습니다.
먼저 성능면에서는 엄청 느린 속도가 문제가 되었습니다. 하지만 해당 문제의 가장 큰 원인은,
평행일기는 현재 실 서버 및 실 데이터베이스로 Heroku 서비스를 이용하고 있는데 북미에 위치
하고 있는 Heroku의 무료 서버 특성상 낮은 접속 속도를 보일 수밖에 없습니다. 해당 문제는 유
료 서비스를 이용한다면 대폭 개선할 수 있을 것이라 예상됩니다.
PWA는 굉장히 높은 점수를 보였습니다. 단 하나의 문제가 존재했는데 PWA 특성상 HTTPS로
접근을 했을 때만 PWA의 대다수 기능이 동작하기에 HTTP로 접근했을 시에도 HTTPS로 redirect
시켜줄 필요성이 있습니다. 하지만 해당 기능을 제공하기 위해서는 CloudFlare와 같은 전용
HTTPS CDN을 사용해야 하는데 해당 서비스들은 유료이기에 현 시점에서는 이용하기 어렵습니다.
후에 실제로 해당 평행일기를 런칭하게 된다면 해당 유료 서비스를 이용함으로써 해결할 수 있을
것입니다.

20. 20 / 22
7-2. 안정성
먼저 보안의 경우에는 모든 유니코드는 base64로 암호화되어 있으며, 민감한 개인정보의 경우
에는 안정성이 검증된 sha256 암호화 알고리즘을 통해 이루어지고 있습니다. 또한 사용자의 이미
지가 탈취되지 않도록 모든 이미지의 이름을 sha256으로 암호화했습니다.
여러 번의 디버깅 과정을 거친 결과 현재는 서버가 통째로 다운되는 등의 심각한 에러는 없습
니다. 해당 베타 테스팅 로그는 GitHub wiki에 작성되어 있습니다.
https://github.com/eurobin4321/parallel_diary/wiki
7-3. 구현기간
구현 기간은 총 5주 동안 이루어졌으며, 짧은 개발기간 동안 기획한 대로 다양한 기능을 넣는
과정에서 어려운 점이 많았습니다. 특히 수많은 다양한 에러를 접하면서 개발이 지체되는 상황도
있었습니다. 하지만 해당 과정을 모두 극복해내면서 모든 핵심적인 기능과, 초기 기획 목적에 부
합하는 결과를 최종적으로 만들어낼 수 있었습니다.
7-4. 기능점수
기능점수의 평가항목은 다음과 같습니다.
데이터 기능
내부논리 파일(ILF) : 2개(유저, 다이어리페이지)
외부연계파일(EIF) : 1개(Firebase)
트랜잭션
외부입력(EI) : 회원가입, 회원탈퇴(이별신청), 토큰 입력, 일기작성, 일기수정, 일기삭제, 커플신청
외부출력(EO) : 0
외부조회(EQ) : 회원정보 조회, 로그인, 일기페이지 리스트, 커플조회

21. 21 / 22
총 64점이며 개발 원가와 보정 전 개발 원가는 다음과 같습니다.
8. 추후 프로젝트 발전 방향
현 평행일기는 충실한 기본 기능과 뛰어난 안정성, 그리고 PWA를 통한 사용자의 높은 접근성
과 편의성을 보장하고 있습니다. 하지만 실제 평행일기 사용에 있어서 몇 가지 개선해야 할 사항
이 존재합니다.
우선적으로 디자인적 개선입니다. 특히 메인 페이지가 아직 평행일기를 나타내거나 외부 사용
자들을 끌어들이는데 있어 상당히 부실합니다. 그리고 평행일기를 사용하는 과정에서도 베타 테
스터들이 특정 기능이나 정보가 어디에 있는지 찾기 어려워하는 경우가 있었습니다. 따라서 좀
더 직관적이고 평행일기를 더욱 부각할 수 있도록 몇몇 페이지들의 디자인 개선이 필요합니다.
평행일기는 현재 기본 기능이 충실합니다. 하지만 지극히 기본 기능에만 충실하기에 사용자들
을 위한 부가적인 편의 기능들이 많이 부실합니다. 베타 테스터들의 의견으로는 자동 로그인을
지원해줬으면 좋겠다, 일기에 올린 사진을 클릭했을 때 원본 사진을 볼 수 있었으면 좋겠다, 일기
페이지에서 달력 모달을 띄우지 않고도 간단히 전날이나 다음날 이동이 가능한 버튼이 있었으면
좋겠다 등 다양한 피드백이 있었습니다. 이러한 유저들의 피드백을 반영하여 사용자들의 편의성
을 위한 부가기능을 늘여갈 필요성이 있습니다.
PWA에 있어서는 Offline 기능을 좀 더 발전시킬 필요성이 있습니다. 현재는 단순히 오프라인일
시에 오프라인 전용 페이지를 띄워주는 기능만 제공합니다. 하지만 주기적으로 페이지를 캐시에
저장시켜 오프라인이 되었을 때 캐시에 백업된 페이지일 경우에는 오프라인 전용 페이지가 아닌
해당 페이지를 띄워주는 방식으로 발전시켜 사용자의 편의성을 높일 수 있을 것입니다.
현 평행일기는 건물을 짓기에 매우 적합한 부지와 같습니다. 이 든든한 기반에 유저들의 피드
백을 받아들여 여러 부가기능들과 직관적이면서도 적합한 디자인을 쌓아 나감으로써 추후 해당
프로젝트를 발전시켜 나갈 수 있을 것입니다.

22. 22 / 22
9. 종합 토의
홍진백(팀장)
기존의 아이디어 발표자이며, Front-end와 Back-end를 동시에 구현하는 과정에서 수많은 시행착
오가 있었습니다. Pure CSS와 JQuery를 사용하는 과정에서 생산성이 저하되는 부분이 많았습니다.
또한 jQuery의 사용은 자칫 성능 문제가 많이 발생하는 것 같습니다. 기존의 기획(CRUD 구현)에
는 성공하였지만 더 많은 관리 기능과, 예외처리, 그리고 서버 관리 매뉴얼을 더 만들면 좋을 것
같다고 생각합니다.
이창재
지난 Google I/O 2016에서 발표된 PWA 기술을 보고 정말 흥미로운 기술이라고, 앞으로 기회가
있다면 정말 구현해 보고 싶다는 생각을 막연히 가져왔었는데 이번 프로젝트를 통해 해당 기술을
제대로 접목시켜 볼 수 있어서 좋았습니다. 아직까지 PWA는 개발 중인 기술이기에 생각보다 관
련 자료들이 깊게 파고들어갈수록 많이 부족하고 해당 기술을 공개한 구글 플랫폼을 제외하고 타
OS의 경우에는 지원되는 부분에도 제약이 있어 실제 테스트하는 과정에서도 많은 어려움과 시행
착오가 있었지만 결국 현재 PWA가 지원하는 부분까진 문제를 전부 해결할 수 있었습니다. 하지
만 오프라인 캐시부분에 있어서는 단순한 예제수준의 기능만 구현을 하였고 해당 기술을 응용하
는 부분까진 구현을 해 보지 못해 기회가 된다면 이후 해당 부분을 좀 더 발전시켜봤으면 합니다.
평행일기 전체에 있어서는 전체적인 디자인과 계정 페이지를 담당했던 만큼 해당 부분에 있어
서 최대한 사용자의 편의성을 도모하고자 했으나 아직 메인 페이지의 디자인은 사용자들의 눈길
을 끌기엔 많이 부족하고, 그 외 부가기능도 부족하다고 생각합니다. 이후 평행일기에 있어서는
해당 부분의 발전이 필요하다고 생각합니다.
장종진
튜토리얼과 같이 서비스를 사용하는 방법을 나타내는 소개 페이지가 있으면 좋겠습니다. 기능
을 갖춘 대부분의 웹 서비스들은 사용화면을 같이 첨부하여 유저가 서비스를 쉽게 사용하도록 튜
토리얼을 제공해 줍니다. 이 웹 서비스는 단순한 게시판 용도를 넘어서 application program에 가
까운 모습을 보이므로 사용자 설명서와 같은 것이 필요하다고 생각합니다.
평행일기는 후원자가 나타난다면 상용서비스도 충분히 가능할 것 같습니다. 이 웹사이트는 앱
(application program)에 가까운 서비스를 제공하므로 충분히 사용 가치가 있습니다. 따라서 기존
의 시장에 없는 일기공유라는 차별화된 서비스를 통해 경쟁력을 갖추고 있다고 생각합니다.
여러 가지 새로운 기능을 추가하는 시도를 할 수도 있었지만 빠듯한 학기 일정 때문에 포기한
기능들이 많았기에 프로젝트의 개발기간이 짧아서 아쉬웠습니다.