나빌레라의 프로그래밍하기 #8 (마지막)

8. 오브젝트 도출
이번 편을 쓰기 전에 제목을 무엇으로 해야 하나 약 1분간 깊은 고민을 했다. 제목을 정하기 위해 구글 검색을 할 정도였다. 이번 편에 작업하고자 하는 내용은 단순하고 명확하다. 지난 글에서 분석한 명사와 동사를 기준으로 데이터 베이스의 테이블과 코드 로직의 메소드, 코드 로직의 자료 구조등을 도출해 내는 작업이다. 나는 이것들을 통칭할 수 있는 용어로 "오브젝트"라는 용어를 직관적으로 떠올렸다. 하지만 바로 이어서 "엔티티"라는 용어가 치고 올라왔고 내 머릿속은 복잡해 졌다.

분명한것은 데이터를 기술하는 속성과 행동(동작)을 기술하는 속성이 분리되어 도출되어야 한다는 것이다. 학문적으로 접근하면 오브젝트와 엔티티의 차이가 분명하게 있겠지만 데이터베이스에서 말하는 엔티티와 OOP에서 말하는 오브젝트가 뭔가 유사하다는 생각은 지울 수 없었다. 약 1분간의 고민 끝에 "오브젝트 어트리뷰트(Object Attribute)"와 "오브젝트 메소드(Object Method)"로 명확히 분리되는 오브젝트라는 용어를 제목으로 선정했다. 그러나 글을 쓰고 있는 이 시점에서도 이 글에서 수행하는 작업을 오브젝트 도출이라는 용어로 대표화 할 수 있는지 의문이 든다.

뭐가 되었든 그냥 "시나리오에서 설계로 가는 과정"이라고 이해해 주기 바란다.

먼저 쉬운 명사부터 처리해보자. 지난 글에서 정리한 명사를 다시 본다.

사용자,
- 사용자 정보,
-- 아이디,
-- 비밀번호,
-- 이메일,
-- 닉네임,
-- 성별 정보(남자, 여자,)
서비스,
게시판,
- 화면
-- 위: 글 목록의 위에 글쓰기 폼, -- 아래: 댓글 목록의 아래에 댓글 쓰기폼
- 게시판리스트
-- 본문 최근글(맨위),
-- 댓글 최근글(맨아래)
- 남자게시판, 여자게시판
- 타임라인게시판(문자 주고 받는 컨셉)
글,
- 본문, (제목 내용 구분안함, 길이 150자 제한)
- 댓글, (제목, 내용 구분안함, 길이 150자 제한)
- 글쓴사람 (삭제 가능, 5분 안에 수정가능),
활동점수
- 10점(본문 쓸 때)
- 5점(댓글 쓸 때),
- 10000점(이성 게시판에 쓸 때 사용)
데이트
- 괜찮아보이는사람,
- 이성, - 신청받은사람,
- 신청한사람,
- 두 사람,
- 현재(데이트 중)
- 다른사람

계층화까지 다 해 놓은 덕분에 거의 그대로 객체화 시킬 수 있다. 나는 웹 서비스를 만들고 있으므로 DB 테이블을 구성하겠다.

사용자,
- 사용자 정보,
-- 아이디,
-- 비밀번호,
-- 이메일,
-- 닉네임,
-- 성별 정보(남자, 여자)
활동점수
- 10점(본문 쓸 때)
- 5점(댓글 쓸 때),
- 10000점(이성 게시판에 쓸 때 사용)

사용자로 정리된 명사 목록이다. 그대로 User라는 테이블로 도출 가능하다.

User
===
id int auto_increase
username char
password char
email char
nickname char
sex bool
point int
profile_image char
create_date datetime
last_login datetime

이정도로 User 테이블이 도출되었다. 시나리오에서 나온 명사 목록보다 몇 개 더 많다. id는 명사 목록에 있는 아이디가 아니라 DB 테이블의 primary key이다. 명사 목록의 아이디는 username으로 추상화되었다. password, email, nickname, sex는 일대일로 추상화되었고, point는 활동 점수 항목으로 나온 명사 도출 내용을 반영한 것이다. 그 아래 나오는 profile_image는 게시판에서 사용자의 사진 같은것을 보여줄 필요가 있을 때 그 이미지 파일의 경로를 저장하는 필드, create_date는 가입한 날짜, last_login은 마지막 로그인한 날짜를 저장하는 필드이다. 이 추가된 세 개의 필드는 추상화 과정에서 필요하다고 생각되어 설계자가 넣은 것이라고 생각하면 된다. 이런식으로 도출된 명사만 가지고 그대로 추상화하는 것이 아니라 그 내용을 바탕으로 정보를 추가로 넣기도 한다.

다음으로 나오는 명사는 서비스와 화면인데, 이 둘은 DB 테이블로 추상화되기 보다는 CGI로직 단에서 함수나 객체로 추상되어야 할 것 같다. 일단 두고 넘어간다.

글,
- 본문, (제목 내용 구분안함, 길이 150자 제한)
- 댓글, (제목, 내용 구분안함, 길이 150자 제한)
- 글쓴사람 (삭제 가능, 5분 안에 수정가능)

글에대한 명사 목록이다. 제대로 도출되지 않은 대표적인 예라고 할 수 있다. 시나리오 기반 작업 절차의 약점을 드러내는 것이라고 볼 수 있다. 위에 도출된 내용만 보고서는 이것이 게시판을 구성하는 각 글에 대한 설명이라는 것만 알 수 있을 뿐, User 테이블을 구성할 때처럼 구체적이고 실체적인 정보를 얻어낼 수 없다. 그래서 이런 경우에는 설계자의 해석 능력에 의해 추상화의 품질이 좌우된다.

Board
====
id int auto_increase
user foreign_key(User)
contents text
ip char
create_date datetime
hit int
reply_count int

추상화되어 나온 Board 테이블에서 명사 목록에 나온 내용 중 반영되지 않은 것은 길이제한, 5분안에 수정가능, 삭제 가능 등이다. 이들은 DB 테이블로 표현될 수 없고 CGI 로직에서 코딩으로 구현되어야 한다. 그리고 ip, hit 같은 필드는 설계자가 임의로 필요하다고 생각하여 넣은 필드이다. 글쓴이의 IP정보와 조회수를 기록하는 필드이다. 마지막 reply_count 필드는 사실 없어도 표현이 가능하다. 댓글로 달린 DB 인스턴스의 개수를 뽑으면 되기 때문이다. 하지만 매 리스트를 출력할 때마다 이 작업을 하기엔 DB에 부하가 많이 걸리므로 필드로 넣어서 그때 그때 로직에서 처리하도록 했다.

데이트
- 괜찮아보이는사람,
- 이성, - 신청받은사람,
- 신청한사람,
- 두 사람,
- 현재(데이트 중)
- 다른사람

데이트는 영어로 date이다. 이것은 날짜를 의미하는 date와 철자가 같다. 왠지 이런 이름은 키워드일 가능성이 높아서 DB 테이블 이름으로 사용하기 꺼려진다. 그냥 미팅이라고 이름 짓자.

Meeting
=====
id int auto_increase
man foreign_key(User)
woman foreign_key(User)
now_date bool
create_date datetime

도출된 명사 목록에서 이성, 신청받은 사람, 신청한 사람, 두 사람. 이렇게 네 개의 명사는 모두 User 테이블을 참조하는 man, woman이라는 필드로 추상화되었다. 도출된 명사를 추상화 하는 과정에서 앞서와 같이 도출되지 않은 항목을 끄집어 내는 경우도 많지만 방금처럼 도출된 명사 여러개를 몇 개로 줄이는 경우도 많다. 이러한 판단은 설계자가 하게 된다. 물론 이 글에서 하는 프로그래밍은 혼자하는 프로그래밍이기 때문에 모든 작업은 혼자 하게 된다. 이런 과정을 혼자서 많이 연습하다보면 나중에 돈을 버는 프로그래밍을 하게 될 때 자신에게 어떤 역할이 주어지더라도 중간이상은 능력을 보여주게 되는 자신을 발견하게 될 것이다.

다음은 명사 목록에 명확히 도출되지 않은 객체 자체를 끄집어 내는 과정이 필요하다. 지금까지는 객체는 명사 목록을 통해서 도출했고, 그 안의 필드를 설계자가 추가하거나 합쳤는데, 이제는 객체 자체를 도출해 본다. 명사 목록을 보면 스치듯이 이런 항목이 있다.

- 남자게시판, 여자게시판
- 타임라인게시판(문자 주고 받는 컨셉)

남자게시판과 여자게시판은 Board 테이블을 일반화해서 생성한다.

ManBoard, WomanBoard

테이블의 구성은 동일하다. 타임라인 게시판은 조금 다르게 구성해야 한다. 왜냐면 User 테이블을 참조하는 것이 아니라 Meeting 테이블을 참조하도록 해야 하기 때문이다.

TimeLine
======
id int auto_increase
meeting foreign_key(Meeting)
contents text
ip char
create_date datetime
hit int

Board 테이블과 거의 비슷하지만 reply_count가 없고, User 테이블 대신 Meeting 테이블을 참조한다. 그리고 댓글에 대한 테이블을 구성한다. 댓글 테이블을 Board 하나로 구성해서 self reference하도록 할 수도 있지만 왠지 복잡하다. 간단하게 따로 만들자.

ReplyManBoard
===========
id int auto_increase
mother foreign_key(ManBoard)
contents text
ip char
create_date datetime
hit int

ReplyWomanBoard
===========
id int auto_increase
mother foreign_key(WomanBoard)
contents text
ip char
create_date datetime
hit int

쉽다. Board 테이블과 거의 구조가 같지만 참조하는 대상이 각각 ManBoard와 WomanBoard이다.

명사를 통해 웹 서비스의 근간이 되는 DB 테이블을 설계했다. 이전 글에서도 썼지만, 익숙해지면 시나리오에서 바로 DB 테이블을 뽑아낼 수도 있게 된다. 익숙함에 의해 중간 과정은 머릿속으로 그냥 해버리게 되는 것이다. 멋지지 않은가!

다음은 동사와 남겨놨던 명사를 통해 메소드를 설계해 보자. 이전에 정리해 놓은 명사 목록을 다시 본다.

데이터를 만들어내는 메소드
* 데이터를 추가
서비스에 접속하다.
쓰다,
- 본문을 쓰다
- 댓글을 쓰다
- 남자가 여자게시판에 쓰다.
- 여자가 남자게시판에 쓰다.
서비스에 가입하다,
가입자 정보를 받다.
서비스에 로그인하다,
서비스에서 로그아웃하다.
성별 정보를 추가로 받다.
활동 점수를 부여하다,
데이트를 신청하다.
타임라인 게시판을 생성하다.

* 데이터를 변경
본문, 댓글을 수정하다,
활동 점수를 유지하다.
활동 점수를 소비하다,
데이트 신청을 수락하다.

* 데이터를 삭제
본문, 댓글을 삭제하다.

데이터의 값을 읽는 메소드
* 값을 읽음
글을 읽다.
- 본문을 읽다.
- 댓글을 읽다.
화면에 뿌리다.
남자게시판, 여자게시판으로 나누다.
타임라인 게시판을 공유하다.
대화를 주고받다.

* 값의 상태를 확인
(이성 게시판엔) 본문을 쓸 수 없다.
본문과 댓글을 구분하다.
구분하지않는다.
- 본문의 제목, 내용을 구분하지 않는다.
- 댓글의 제목, 내용을 구분하지 않는다.
본문, 댓글의 길이를 제한한다.
글을 쓴 시간이 오래되다,
본문, 댓글을 수정할수없다.
데이트 신청이 가능하다.
현재 데이트를 진행중이다.

이미 메소드라는 용어를 사용했다. 즉, 별일이 없는한 각각의 동사는 하나하나가 개별 함수로 구현될 가능성이 높다는 것이다. 그리고 이 글에서 사용하기로 한 Django 프레임워크는 view 모듈의 메소드 하나당 URL이 하나씩 매핑되는 구조를 가지고 있다. 이 구조를 그대로 적용해서 메소드와 개별 메소드의 구현 시나리오(알고리즘이라고 할 수도 있겠다.)를 설계하겠다. 이 글에서는 함수(function)과 메소드(method)라는 용어를 구분하지 않고 쓰겠다.

+서비스에 접속하다.
URL: /
function: ViewMainPage()
scenario:
1. static page인 main.html을 보내준다.

+본문을 쓰다
URL: /write/[man|woman]/[imrich]/
function: WriteBoard(boardname, imrich)
scenario:
1. 로그인한 사용자인지 확인한다. 로그인 하지 않았다면 에러메시지 출력후 이전 페이지로 간다.
2. 로그인한 사용자의 사용자 정보에서 남자, 여자를 읽어온다.
3. 남자가 여자 게시판에, 여자가 남자 게시판에 글을 쓰려고 시도하면 imrich 플래그를 확인한다.
4. imrich 플래그가 false라면 포인트를 확인하고 10000포인트 이하라면 에러를 출력, 10000 포인트가 넘으면 사용할것이냐고 물어보는 화면으로 이동한다.
5. 사용자가 10000 포인트를 사용한다고 했으면 /write/[man|woman]/imrich/ 라는 URL로 POST정보를 유지하여 재진입한다.
6. imrich 플래그가 True면 해당 사용자에게서 점수를 10000 포인트 뺀다.
7. boardname이 man이면 ManBoard, woman이면 WomanBoard의 인스턴스를 얻는다.
8. POST로 넘어온 필드의 내용을 verify한다. 실패하면 에러 페이지로 간다.
9. verify 통과하면 DB 인스턴스에 데이터를 입력하고 업데이트한다.
10. 사용자 정보에서 포인트 +10한다.
11. 해당 게시판의 첫 페이지로 이동한다. (/board/[man|woman]/page/1/)

+댓글을 쓰다
URL: /write/[man|woman]/번호/reply/
function: WriteBoardReply(boardname, mothernum)
scenario:
1. 로그인한 사용자인지 확인한다. 로그인 하지 않았다면 에러메시지 출력후 이전 페이지로 간다.
2. boardname이 man이면 ReplyManBoard, woman이면 ReplyWomanBoard의 인스턴스를 얻는다.
3. POST로 넘어온 필드의 내용을 verify한다. 실패하면 에러 페이지로 간다.
4. verify 통과하면 mothernum을 인덱스로 엄마글의 인스턴스를 얻어온다.
5. 엄마글의 인스턴스를 foreign_key하여 댓글 DB 인스턴스에 데이터를 입력하고 업데이트한다.
6. 사용자 정보에서 포인트 +5한다.
7. 해당 글을 보여준다. (/board/[man|woman]/num/번호/)

본문을 쓰다의 시나리오를 보면 남자가 여자게시판에 쓰다, 여자가 남자 게시판에 쓰다라는 동사가 시나리오에 녹아서 처리되어 있고, 명사 목록에서 뒤로 미뤘던 +10, +5, 10000포인트에 대한 내용 역시 시나리오에 녹아서 도출되어 있다. 동사에 대한 내용은 전부다 쓰려니 지루하고 너무 길다. 위 두 개 정도 예제만으로도 충분히 어떤식으로 작성되는지 알 수 있을 것이라 생각된다. (귀찮아서 안쓰는 것 아니다!-_- 여러분의 능력과 실력을 믿기 때문이다.)

이번 글에서 뽑아낸 자료 정도가 있으면 이제 프로그래밍이 아닌 실제적인 코딩이 가능한 수준이 된다. 코딩하는 법까지 이 글에서 쓰진 않을 것이다. 이 글을 처음 쓴 목적이 코딩을 할 줄 모르는 사람들을 위해 쓴 것이 아니라 프로젝트를 하고 싶긴 한데 어디부터 어떻게 시작해야 할지 모르는 사람들을 위해 쓴 글이기 때문이다.

나는 처음에 어떻게 생각을 하고 어떤 목적을 정하고, 그것으로부터 시나리오를 도출해서 어떤 과정을 거쳐 설계 비슷한 것까지 나오게 되는지를 썼다. 제대로 절차와 형식을 갖춘다면 꽤나 두터운 책 한권이 나올만한 분량의 이야기이다. 혼자하는 돈을 벌지 않는 프로그래밍에서 그런것까지 다 갖추면 정말 좋겠지만 그래서 재미 있다면 금상첨화! 아니라면 그냥 이렇게 대충하면 된다.

나는 이 글을 쓰면서 실제로 웹 사이트를 만들었다. 그리고 알게 모르게 그냥 저냥 운영중이다. 실제 돌고 있는 사이트는 이 글에서 쓴 내용보다 좀더 기능이 많고 복잡하지만 시작은 이 글에서 쓴 내용 그 자체이다.

사이트 주소는

http://manitto.me

이다. 이 글을 읽는 여러분들도 이렇게 하나씩 만들고 눈으로 보고 사용해보는 즐거움을 느껴보길 바란다. 이렇게 한 번이라도 완성해보는 쾌감을 알면 이 자체가 너무 재미있고 좋아서 또하게 된다. 그리고 당연히 하면 할 수록 본인의 실력과 포트폴리오는 늘게 된다. 일석이조아닌가!

실제로도 나는 이 프로젝트를 통해 내 포트폴리오에서 임베디드 분야 뿐아니라, 웹 프로그래밍 관련 포트폴리오도 추가했다. 웹으로 밥 먹고 살 정도 수준은 못되고 알바정도는 할 수 있을 것 같다.

이것으로 짧은 글 마무리 할까 한다.

다음에 좀더 재미 있는 주제로 또 글 쓸 날이 왔음 좋겠다.

===
이 글은 CC이지만 다른곳에 불펌은 하지 말아 주세요. KLDP와 raonlife에(http://raonlife.com/navilera/blog/view/58/)만 연재합니다. 다른 곳에 연재되어 있는 것은 불펌이오니 저에게 알려주세요.