띠띠 띠리리리 띠띠띠리 띠띠 띠리리리 띠띠띠리~ 추억의 테트리스 게임을 완성한 후 다음 미션은 ‘더 제대로 만들어 볼거야!’라는 다짐을 하는 dimanche와 summer. 그 때! 드디어 새로운 미션을 받게되는데.. 이번 미션은 어떤 어려움이 있을까?!
두근?거리는 새로운 미션
어려웠지만 재밌었던 테트리스 미션이 끝났지만, 어설프고 허술한 점이 많았던 터라 아쉬움이 많았습니다.
그래서인지 다음 미션은 더 잘 만들고 싶은 욕심이 생겼습니다.
‘잘 할거야!!!!!! 불 속에 들어간거 아니에요..‘
2016.10.31 드디어 새로운 미션을 받게되었습니다. 요구사항은 아래와 같습니다.
- 미션의 주제는 메시지를 주고 받을 수 있는 메신저이다.
- 메신저를 사용하기 위해서는 사용자를 식별할 수 있는 고유한 값이 필요하다.
- 사용자를 식별할 고유한 값은 폰 번호이다.
- 사용자는 폰 번호를 입력하고 비밀번호를 문자로 받아 가입을 한다.
- 사용자는 가입된 폰 번호와 발급받은 비밀번호로 로그인을 할 수 있다.
- 가입은 했으나 비밀번호를 모르는 경우 재발급 받을 수 있다.
- 서버에서 회원정보를 저장하는 DB가 있다.
- 로그인 성공 시 서버에서 인증 정보를 클라이언트에 발급하게 된다.
- 클라이언트의 회원가입, 비밀번호 재발급, 로그인을 제외한 통신은 발급받은 인증 정보가 유효해야 가능하다.
- 채팅 페이지에는 연락처 목록과 채팅화면이 있다.
- 사용자는 연락처를 추가, 삭제, 별명 변경을 할 수 있다.
- 연락처에 새 메시지(읽지 않은) 개수가 표시된다.
- 연락처 하나에 채팅방이 하나 만들어 진다.
- 채팅방은 사용자와 연락처를 가진 상대방이 1:1 대화를 할 수 있다.
- 서버는 메시지를 받아 잠시 저장할 뿐이다. 즉 메시지 받는 사람이 받아가면 서버에서는 삭제된다.
- 메시지는 클라이언트쪽에 저장된다 -> IndexedDB 사용
요즘 흔히 사용하는 메신저들과는 달리 단체 대화도 없고, 프로필 사진도 없습니다. 저희 수준에 맞춰 몇 가지 기능만 넣다보니.. 메신저라기 보단 문자에 가까운 느낌이 들었습니다. 그래도 전혀 만만해 보이지는 않은 미션이었습니다.
이전 미션과 달리 데이터베이스를 사용하고, 서버도 만들어 통신을 해야한다라는 점이 막막하게 느껴졌습니다.
클라이언트쪽 DB는 IndexedDB, 서버는 Node.js로 구축, 서버쪽 DB는 MySql. 세가지 모두 제대로 사용해 본 적이 없어서 미션을 받기 전 욕심과는 달리 ‘내가 할 수 있으려나’라는 걱정도 들었었습니다.
내가 이러려고 설계를 했나
자 이제 막막함과 걱정은 접어두고, ‘모르면 물어보면서 하면돼!’를 마음 속에 넣고 설계를 시작해 봅니다.
개발의 기초는 딕셔너리라고 했습니다.
엔티티의 정의와 시나리오를 구체적으로 그려보아야 무엇을 만드는지 정확히 알 수 있습니다.
그래서 첫 번째 작업으로 용어집을 작성해보았습니다.
두 번째 작업으로 설계문서를 작성을 하기 위해 ppt를 켰습니다. 화면 구성 슬라이드도 추가하고~ 시나리오 슬라이드도 추가하고~
시나리오 슬라이드를 추가하던 그 때! ‘어? 시나리오 작성은 어떻게 해야하지..?’라는 생각과 함께 멍해졌습니다.
설계문서는 구체적이고 명확해야합니다. 그 누가 봐도 똑같은 제품이 나올 수 있도록 작성되어야 합니다.
그런데 이번 미션에는 클라이언트만 있는 것이 아니라 서버가 있고 서로 통신을 합니다. 이 흐름을 어떻게 표현해야할지 난감했습니다.
그래서 제가 선택한 방법은 글로 설명하기 힘든 것을 시각화 시키는 것이었습니다.
클라이언트와 서버를 그림으로, 흐름 순서를 화살표에 번호를 붙여 나타냈습니다. 그렇게 작성한 시나리오 중 로그인 부분입니다.
이렇게 여러개의 시나리오를 작성하고 봤을 땐 흐름이 간단하게 표현되었다고 착각했습니다. 하지만 간단해도 너~~~~무 간단해 많은 내용들이 생략되었고, 이는 너무 많은 오해를 일으키는 설계문서가 되어버렸습니다.
아니… 오해 투성이라 설계문서라고 할 수 없게 되었습니다.
‘이게 무슨 말이야?’
이를 보완하기 위해 시퀀스 다이어그램을 사용해보았습니다.
시퀀스 다이어그램은 여러 객체들이 어떻게 교류하는 지를 보여줄 수 있도록 하는 수단입니다. 그래서 IndexedDB, 메신저, 서버, 서버 DB 사이에 어떤 값들이 보내지는지, 어떤 순서로 발생하는지를 잘 나타내 줄 수 있었습니다.
아래는 시나리오 중 일부를 시퀀스 다이어그램으로 나타낸 것입니다.
1.로그인
2.메시지 발신
3.메시지 수신
서버! 클라! 연결! 고리!(털ㄴ업)
설계문서를 작성해보며 클라이언트-서버 간에 통신들이 무엇이 있고, 어떤 순서로 진행되며, 어떤 데이터들이 필요한지 알게되었습니다.
그럼 이제 바로 시나리오에 맞춰 코드를 작성해볼까요??!
‘아직 코딩은 안돼~’
회사 실무에서는 그 전에 통신에 필요한 데이터를 JSON 형식으로 작성을 하는 작업을 합니다. 무슨 데이터가 가는지 알고 있는데 바로 코딩 작업을 하면 되지 않을까 싶었습니다. 이게 왜 필요한걸까요?
하나의 통신이라도 보내져야 할 데이터는 여러개 입니다.
데이터를 보내는 쪽과 받는 쪽에서 각자 다른 구조를 생각하고 있다면 어떻게 될까요?
아마 필요한 데이터를 다 보냈다고 하더라도 제대로 사용할 수가 없을 것입니다. 어디에 무슨 데이터가 들어있는지도 모르니까요ㅠㅠ
그래서 클라이언트-서버 간에 데이터를 어떻게 보내줄 것인지 약속이 필요합니다.
약속에 따라 데이터의 구조를 만들어 놓은 것이 바로 API였습니다.
이렇게 작성된 API를 바탕으로 데이터를 명확하게 알 수 있어서 클라이언트는 서버가 구축되지 않아도 프로그래밍을 진행할 수 있게 됩니다.
와우! 저는 이제 총 5가지의 통신(회원가입, 비밀번호 재설정, 로그인, 메시지 받기, 메시지 보내기)의 데이터 구조를 JSON 형식으로 작성해 보았습니다. 아래는 그 중 일부입니다.
1.로그인 api
{
"etc":{
"request":{
"phone":"01000000000",
"pw":"11AA22"
},
"memo":[
"로그인 요청",
"요청 시에는 폰번호와 비밀번호를 post로 전송",
"로그인 성공 시에 토큰, 회원정보(rowid, phone)을 반환한다",
"가입이 안된 폰 번호거나, 비밀번호가 맞지 않을 경우 로그인 실패",
"로그인 실패 시 응답 메시지에 [error] 데이터가 전송됨"
],
"error":[
{
"code":"notjoin",
"messege":"가입되지 않은 회원입니다. 비밀번호 발급받아 가입하세요."
},
{
"code":"wrongpw",
"messege":"비밀번호가 맞지 않습니다."
}
]
},
"auth":{
"status":"loginreq"
},
"data":{
"token":"74b87337454200d4d33f80c4663dc5e5",
"user":{
"rowid":"0",
"phone":"01000000000"
}
}
}
2.메시지 수신 api
{
"etc":{
"request":{
"token":"74b87337454200d4d33f80c4663dc5e5"
},
"memo":[
"새 메시지 요청",
"서버에 쌓인 메시지를 모두 받아오고, 서버에서는 삭제한다",
"유효하지 않은 token일 때 에러 발생",
"에러 발생 시 응답 메시지에 [error] 데이터가 전송됨"
],
"error":[
{
"code":"authInvalid",
"messege":"다시 로그인 후 이용해주세요."
}
]
},
"auth":{
"status":"login",
"token":"74b87337454200d4d33f80c4663dc5e5"
},
"data":{
"messeges":[
{
"origin":"01011111111",
"date":"2016-11-16 22:32:16:48",
"content":"랄랄라라랄~ 첵스초코!"
},
{
"origin":"01011111111",
"date":"2016-11-16 22:32:17:48",
"content":"졸려졸려"
},
{
"origin":"01022222222",
"date":"2016-11-16 22:32:19:48",
"content":"가나다라마바사"
}
]
}
}
전에 했던 [초보자들 EP.03] 미션 : To Do List 프로그램 만들기 미션에서 할 일 목록을 JSON 형식으로 출력했습니다. 그땐 몰랐지만…
역시 의미없이 한 작업은 하나도 없었습니다!
어디까지 진행됐어?
미션을 시작한지 몇 주가 지났습니다. 설계문서도 계속 보완하는 중이었고, 처음 사용해보는 IndexedDB와 node.js의 예제 코드를 작성해 보며 사용법에 대해 익히고 있었습니다.
어느날..!! 실장님께서 저에게 어디까지 했는지를 물어보셨습니다.
저는 대답했습니다. ‘구현하기 전에 IndexedDB 사용법을 공부하고 있습니다.’
실장님의 표정이 좋지 않습니다. ‘으응????????? 일정은? 뭘 한거야?’
‘열심히… 난 뭘 한거야?’
만약 이 질문을 한 사람이 실장님이 아닌 저에게 돈을 주고 일을 맡긴 업체였다면 어떻게 되었을까요?
지금 제가 개발을 위해 뭘 공부하고 있는지 궁금했을까요?
업체의 궁금점은 이 프로젝트가 얼마나 걸릴 것 인지, 지금 얼마나 진행되고 있는지, 잘 진행되는게 맞는지일 것입니다.
하지만 저는 단 한가지의 궁금점도 풀어드리지 못 했습니다.
일정을 계산해 보지 않아 얼마나 걸릴지 대답하지 못 했습니다.
개발해야하는 페이지나 기능마다 진행상태를 체크하지 않아 전체 진행률도 대답하지 못 했습니다.
올바른 진행인지 아닌지를 판단할 수 있는 기준이 되는 문서도 완성되지 않았습니다.
몇 주동안 저는 무엇을 한 것일까요? 저의 미션 과정에 필요한 것은 무엇일까요?
바로 사이트맵과 테스트리스트 작성입니다.
사이트맵이란 페이지의 종류와 중요한 기능들이 무엇이 있는지를 작성해보는 문서입니다.
테스트리스트란 페이지의 레이아웃이 올바른지, 동작들이 예상한대로 움직이는지 등을 하나씩 올바른 개발이 되었는지 체크해보는 문서입니다.
사이트맵을 통해 개발 일정과 공정률을 계산하고, 테스트리스트를 통해 올바른 진행인지 아닌지를 판단할 수 있게됩니다.
저는 이 두 개의 문서를 누락한 채 개발을 진행하고 있었습니다. 업체에서는 아마 저에게 다시는 일을 주지 않았을 거에요ㅠㅠ
다시 정신을 차리고 누락한 문서들을 작성했습니다!
1.사이트맵
2.로그인 페이지 테스트 리스트
이제는 개발이 어디까지 되었는지 퍼센트로 대답할 수 있고, 올바른 개발을 하고 있다는 것을 판단할 수 있는 기준이 생겼습니다.
미션완료 : 나의 메신저
10월 말에 시작했던 저의 메신저 개발은 12월 중반이 되서야 버전 1이 완성되었습니다.
1.로그인 페이지
2.채팅 페이지
메신저 버전 1을 완성하고 나니 기뻤습니다! 그리고 완성됨을 알리고 회사에서 같이 테스트를 해보았습니다.
메시지가 잘 주고 받아지길 바랬습니다. 기본적인 동작인 회원가입, 로그인, 메시지 주고 받기가 되는 것을 확인했습니다. 오예~
하지만 물론 버그도 많았습니다. 제가 생각을 못 했던 부분들이 너무 많았습니다.
- 연락처 편집 모드일 때도 새로운 연락처 추가가 가능하다.
- 닉네임 변경 창에서 스크립트 코드를 입력하면 실행된다.
- 여러개의 탭에서 로그인했을 경우의 대처가 되어있지 않다.
- 메시지 보낸 시간이 클라이언트 시간 기준이다. 서버에서 메시지를 받은 시간으로 정해야한다.
- 메시지 내용에 작은 따옴표를 보내면 큰 따옴표로 저장된다.
- 로그인 시 비밀번호를 여러번 틀려도 무한히 시도 가능하다.
- 메시지를 서버로 보낼 때 인증정보인 토큰을 사용해 누가 보낸 메시지인지 확인을 하도록 변경한다. (현재는 보낸사람 정보를 같이 보내줌)
- 비밀번호 재설정은 폰번호만 안다면 무한히 가능하다. 그리고 재설정하게 되면 문자가 전송된다. 그렇다면 누군가 악의적으로 계속 재설정한다면?
‘이외에도 허술한 부분들이 많지만 다 언급하면 글을 마칠 수가 없기에 여기까지…’
나름 이 경우 저 경우 생각해보며 만들었지만.. 그래도 버그는 있을 수 밖에 없겠지라고 생각했지만..막상 많이 발견되니 기쁨이 상실되고 있었습니다. 메신저를 버전업 시켜가며 버그도 잡아내고! 완성의 기쁨을 다시 찾아보겠습니다!
다시 기쁨을 찾길 간절히 원하는 모습
개발성찰과 깨달음
미션을 진행하면 여러 감정들이 생겼다가 사라졌다를 반복합니다. 그래서인지 저의 개발 과정을 글로 쓰는 이 순간에도 떨리기도하고 아쉽기도 합니다.
매번 하는 생각이지만 다음에는 아쉬움이 덜 하길 바랍니다.
더 발전할 수 있도록 이번 미션에서 무엇이 문제가 되었는지 살펴보도록 하겠습니다.
미션을 시작할 때 너무나 잘하고 싶은 욕심이 생깁니다. 그런데 이 욕심이 중간중간 빨리 무언가를 만들어 내고픈 욕심으로 바뀌어 버립니다.
위에서 언급했었지만 저는 사이트맵을 작성하지 않아 개발 일정조차 알지 못 했습니다.
사실 저는 이 문서들을 작성해야한다는 것을 알고 있었습니다. 회사에서 실무를 진행하는 것을 봐왔고, 같이 참여도 했었기에 기획이 끝나면 가장 먼저하는 일이란 것을. 그럼에도 불구하고 왜 저는 하지 않았을까요?
설계했을 때와는 다르게 코딩을 하다보면 제가 생각했던대로 흘러가지 않는 경우가 많습니다.
그러면 사이트맵이나 설계문서를 자주 수정하게 됩니다. 그리고 이 수정작업에 많은 시간이 소요됩니다. 그렇다보니 무언가를 만들어 내고픈 욕심이 근질근질 거리고 성급해집니다.
그래서 저는 사이트맵 작성부터 하지 않았고 뒤로 미루어 버렸습니다.
구현보다는 개발문서가 먼저인 것을 알고 있지만, 개발이 시작되는 순간 또 다른 제가 ‘내가 할거야!!!!!!!!’라고 튀어나오나 봅니다.
그리고 실장님의 충고를 들으며 제 정신으로 돌아오곤 합니다.
제가 미션을 끝내고 이렇게 글을 쓸 때마다 얘기를 했었습니다. 문서가 중요하다고.
‘꼭 저 욕심을 이겨내 올바른 개발을 해야겠다’ 다짐합니다.
‘다음엔 같은 실수를 반복하지 말아야지’라는 다짐도 합니다.
dimanche | bsidesoft 신입사원
좋은 개발자가 뭔지도 모르고 좋은 개발자가 되고 싶은 초보 개발자입니다.
회사에서는 열심히 교육받고 발전하는 운 좋은 개발자로 일하고 있습니다.
recent comment