리퍼러 대체 기능, 특정 조건 하에서의 워드 변경, 간소하지만 링크도 구현했고 (정규식이 있다는 걸 깜빡했네요. 좀 더 응용하면 뭔가 더 될 것 같기도한데...) 워드 추가 화면도 조금 바꿨고.

새로운 버전 워드로 먼저 잠깐 테스트를 해 본 후에 완전히 기반을 옮기는 쪽으로 생각해봐야겠어요. 도움, 의견 주신 분들 모두 감사드려요 :)

그런데 지금은 또 호스팅이 접속이 안 되는 상황이라... 시스템을 좀 더 가다듬어 봐야겠습니다.

경험과 머릿속에 있는 지식만을 바탕으로 한 추측입니다. 사실과 다른 부분이 있을 수 있습니다. 문제점이 있거나 그 부분은 이런 방법일 것 같다, 아니면 이런 더 나은 방법이 있다, 하는 것들이 있으면 말씀해주셨으면 하는 마음으로 공개해둡니다. 개발자를 위한 글이므로 방문해주시는 분들께서는 이해하지 못하셔도 됩니다 :)

팬텀 서버 기준입니다.

1. 데이터베이스 : 워드 테이블의 구성(column)은 No, Keyword, 본문, 완전일치, 이미지, 기록여부, 태그, 클러스터, 변수, 등록일, Good, Hit

이 중 No는 AUTO_INCREMENT, PRIMARY KEY로 사용된다

Keyword, 본문, 이미지, 태그, 변수는 문자열형

완전일치, 기록여부, 클러스터, Good, Hit은 수치형. Good과 Hit은 시스템에 의해 관리되며 편집 화면에서 수정할 수 없다.

등록일은 DATETIME 형

2. 데이터베이스2 : 워드 테이블 외에 베이비별로 필요한 시스템 변수를 할당하고 있다.

배경색, 문자색, 캐릭터이름, 변수목록, 태그 목록, 템플릿, 이미지 카테고리, 이미지 목록, NG 워드 등등.

3. 베이비 작동은 이하의 절차

1) 베이비 no를 기준으로 접근할 테이블을 결정 (GET 방식으로 몇가지 정보를 가져오는 듯 하다)

2) 워드 검색(매칭)을 실행 (처리속도, 과부하, 워드 매칭률을 결정하는 시스템의 핵심)

입력 워드를 기준으로 무언가의 처리를 한 후 LIKE 검색? (이 부분은 불명확... 워드 기준 like 검색이면 시간이 너무 오래걸리지 않을까 하는 생각도 드는데...)(등록된 워드를 입력된 단어에 매칭시키는 방식...일지도 모른다 어쩌면)

검색은 Keyword의 그룹화, AND, OR에 대응하도록 만들어야한다 (그룹화 및 AND OR의 병용 사용은 구현하기 쉽지 않을 듯 하다. ai에서도 몇 번이나 버그가 발생한 전례가 있다)

이 때, 검색은 아마도 2차례 실행된다. ①클러스터 없음 ②클러스터 있음

①은 결과값이 없는 경우 No Word를 불러온다 (혹은 No Word는 무조건 결과에 포함된다, 일지도. if 조건을 넣었을때의 결과를 생각하면 후자가 더 정확한가?)

①②에서 검색된 레코드 중 변수 컬럼을 참고, if 조건이 있는 것들의 true 여부를 검토한다

②는 조건이 false인 것만을 제외

①은 조건이 전부 true이며, 조건의 수가 가장 많은 값을 우선적으로 선택한다.

①에서 같은 조건하의 레코드가 여럿 있을 경우 이 중 1개만을 랜덤 선택한다

3) 2)에서 선택된 워드들을 클러스터 순서대로 나열한다. 같은 레벨의 클러스터라면 No가 빠른 쪽이 우선된다

나열된 레코드들 중에서 변수를 참고해 변수의 대입 등을 처리한다(ins) (세이브 데이터가 있다면 세이브 데이터에서 먼저 값을 불러오고 처리할 듯)

가장 마지막에 있는 (이미지 값이 있는) 레코드의 이미지를 출력할 이미지로 선택한다

4) 3)의 결과를 바탕으로 출력화면을 만든다

배경색, 문자색의 셋팅, 이미지 셋팅, 그리고 본문을 워드를 차례대로 출력.

이 때 출력되는 본문의 내용은 일부 변환된다 (변수 출력이나 링크 출력 등)

5) Hit수, 로그에 이번에 선택된 워드, 입력된 워드 등의 정보를 추가한다. 기록 여부가 X라면 기록하지 않는다?

NG워드, NG유저등의 처리가 이 단계에서 행해지는지, 아니면 관리 화면에서 불러올때 행해지는지는 의문. 어느쪽이라도 좋지만.

(이 부분은 ai의 로그 시스템 자체가 현재 제대로 작동하지 않아서 거의 모르겠지만...)

5-1) 사용자가 Good을 눌렀을 경우 화면 이동 후 해당 화면에서 해당 워드(No 기준)의 Good에 가산처리

4. 편집 화면은 특정 갯수만큼(ai는 20개 기준) 형식에 맞춰 출력 (for문이나 while이나... 방법은 많다)

편집 화면의 검색은 출력시의 워드 검색보다는 훨씬 간편할 듯 (조건에 맞는 레코드들을 가져오기만 하면 OK이니)

5. 세이브데이터 및 변수 관련 : 서버측에서 베이비의 No, 해당 베이비의 변수 목록등을 참고해 해당 테이블에 유저별로 값을 보존하고 있을 듯 하다. 유저를 구분하는 방식, 필요 없는 데이터의 삭제등이 어떻게 처리되는지 등이 의문.

또, 임시 변수를 사용할 수 있다는 점을 생각하면 ins와 변수 기록(세이브 데이터)은 각각 독립적으로 작동하고 있다고 볼 수 있다.

name은 예외적으로 GET 방식으로 변수를 매번 셋팅해주는 듯. (존재하는 경우에만)

-----------------------------------------------------------------------

현재 시스템 구현의 장애물

1. DB 문제...

DB를 이용하는 것이 '관리' 및 '속도' 측면에서 매우 유리할 것으로 예상되지만 아직 지식 및 경험이 부족. DB를 사용한 시스템을 쓰려면 사이트 초창기부터 구현해야하는데(도중에 구현할 경우 재이식 필요), 구현하는데 매우 많은 시간이 걸린다는 점이 걸림돌. 그래도 언젠가는 DB 식으로 옮길 예정

2. 키워드의 그룹화 및 OR 대응

기존의 AND 시스템에까지 버그가 발생할 우려가 있다. 또, 테스트에 시간이 걸린다는 게 가장 큰 문제점. 속도 문제도 약간 걱정스럽다. 관리 측면에서는 구현하는 편이 훨씬 깔끔한데... DB로 옮기게 되면 검색 시스템도 어차피 새로 짜야할테고 지금은 미뤄두는 게 효율적일지도.

3. 본문 변환

변환을 등록 단계에서 할지 출력 단계에서 할지 고민. 전자는 (출력)속도상 유리하고 후자는 워드 관리상 유리하다. 한번에 대량의 워드의 내용을 바꿀수도 있다는 점에서 후자인 편이 나으려나...? 차후 이식을 생각해도...

그 외에는 링크 변환이 은근히 어렵다. <<링크워드>> 만으로 <a href=…>를 구현하려면 어떻게 해야할까. split 만으로는 한줄에 2개 이상이 나왔을때 등이 걱정. 꼬일 우려가 있다.

[word=''][/w] 정도는 그럭저럭 구현할 수 있을지도.

4. 변수 관련

가장 핵심적인 '문제'. 자바스크립트를 이용해 비슷한 시스템을 구현하는 것도 가능하긴 하지만 무척 번거롭다. 변수 1개만을 사용하는 경우는 비교적 간단히 구현할 수 있지만...

ai와 비슷한 시스템을 만든다면 변수는 서버측에서 관리하는 게 best. 문제는 이 변수 데이터를 어떻게 만들고 관리할 것인가. 가입, 로그인을 구현하는 게 안정적일 것 같지만 이 경우 가입, 관리 폼을 따로 구현해야하고 그 외에도 대화하기 사이트에 가입은 여러모로 생소하지 않을까...

어차피 호스팅을 쓰면 php 등을 써서 여러가지를 구현할 수 있긴 하지만 '워드' 레벨에서 관리할 수 있는 변수 시스템이 무척 편해서 고민중. …하지만 이것도 결국은 DB 시스템과 함께 가야하는 부분일지도 모른다.

5. 클러스터, 랜덤 워드

현재 임시로 구현해 둔 대화하기 시스템은 딱 한 워드만을 찾고 거기서 검색을 중지하므로 아마 구현하기는 힘들 듯 하다. 랜덤 워드는 간단한 방법으로 구현 완료. …이식할 때는 제법 불편할지도. 이식은 3번의 본문 변환과도 크게 관련이 있지만.

-----------------------------------------------------------------------

머릿 속 정리도 할 겸 일단 적어봤습니다. 요즘들어 ai가 계속 불안정하기도하고 관리상의 불편을 감수하면 출력 자체는 기존의 ai와 큰 차이 없이 가능할 것 같으니... 빨리 이식 쪽으로 눈을 돌려야하는 건가 싶습니다. 뭐 시스템이 하루 이틀만에 뚝딱 완성되는 게 아닌 한 재이식은 피할 수 없을 것 같고 그냥 여러가지로 각오해 둬야겠네요 orz

더 불편한 시스템에서 업뎃하는 분들도 계시고 그저 이것저것 구현해보고 싶은 제 욕심이 큰게 유일한 문제인 것 같기도해서 많이 생각해보고 있습니다. 한가지 확실히 알게된 건 역시 남의 시스템에 너무 의존하면 곤란하다는 것(AND사태나 지금의 세이브 데이터나). 직접 백업할 수 있는 환경이 제일 좋다는 것, 이네요.

본가, 별관은 아주 복잡한 처리를 하는 게 아니라 큰 문제는 없을 것 같고 (리퍼러 기능을 기존과 동일한 방식으로 구현해야할지 고민인데... 키세 이식을 생각하면 어쨌거나 빨리 구현해둬야겠네요. 어차피 재이식 하면 뜯어 고쳐야할 게 한두개도 아니고) 다크룸은 php를 써서 새로 만들어야할 것 같습니다. ...그나마 javascript를 즐겨 썼던 게 다행이네요. 쿠로바스룸이나 하트 시스템을 그럭저럭 옮겨올 수 있을 것 같으니까요.

앞으로의 업뎃 워드를 등록할 사이트는 오늘의 ai 사태도 참고해서 결정하겠습니다. 시간... 언제나 시간이 필요하네요ㅠㅠㅠㅠㅠㅠㅠ

안녕하세요. 오늘자 업뎃 워드는 즐기셨나요? :) 문제점 중 하나였던 '뒤로가기 2회' 문제는 일단 대응해뒀습니다. 지금부터는 한번만 누르셔도 제대로 뒤로 돌아갈 수 있습니다.

그 외에 현재 문제가 되는 부분을 정리하자면

본가 여동생 워드 (일부 혹은 전부) 사용 불가

키세 속마음 시스템 사용 불가

미도리마 호감도 시스템 사용 제한 (현재 레벨 2 호감도로 강제 고정됩니다)

최근에 추가된 다크룸 이용 불가

정도가 있을 것 같네요. 본가 이용시 속도가 너무 느린 문제도 여기에 추가 될 것 같구요. 그야말로 폭탄을 맞은 것 같은 상황입니다 orz 

이런 와중에 이전할 사이트의 정말정말 기본적인 베이스가 구축이 되어서 앞으로 업뎃을 어떻게 할지 조금 고민하고 있어요. 간단한 2택입니다.

1번으로 가게 되면... 아시다시피 현재 본가쪽 속도가 매우 느립니다. 앞으로도 이 속도대로 사이트를 이용하셔야 한다는 뜻이구요, 계속해서 워드가 ai에 추가되므로 나중에 이전되는 속도가 느려질 수 있다는 단점이 있습니다.

2번으로 가게 되면... 링크 시스템 구축시까지 워드집이 간이워드집(?) 상태로 돌아갈 가능성이 있고, 하트 시스템 재구축시까지 하트가 모이지 않고 + 사용 불가, 기존 워드는 여전히 ai에서 이용해야한다...는 등등의 단점이 있습니다. 이건 설명할 게 너무 많아서 당황스럽네요 orz 장점이라면 말할 것도 없이 속도, 한글화, 안정화입니다. ai처럼 어느날 갑자기 사이트가 안되고... 이런 일은 절대 없을테니까요.

현재 워드 추가 및 워드 작동 자체는 앞으로 이전 될 사이트도 당장 사용 가능한 상태입니다. 그리고 이런 상황에서 어떤 사이트를 이전하는게 제일 적합한가 생각해봤더니 의외로 본가가 1순위로 올라서 조금 당황하고 있습니다. 생각해보면 특별한 변수 사용도 없고, 리퍼러도 사용하지 않고, 링크도 그리 많지 않고... 등등. 당연한 결론인 것 같기도 하네요. 제일 문제인 건 다크룸입니다. 이건 따로 페이지를 만들어서... 으으 사용 가능한 상태로 하려면 할 게 정말 많아요.

어쨌거나 이런 상황에서 앞으로 업뎃을 어느쪽에 할지 가능한 한 빨리 정해야겠다는 생각이 들었습니다. 따로 설문으로 뺄 정도는 아닌 것 같고 블로그에 찾아주시는 분들만을 대상으로 의견을 여쭤보려고해요.

앞으로의 업뎃은

1. 기존 사이트에서 한다

2. 이전할 사이트에서 한다

이 2가지 중 하나를 골라주시면 됩니다. 이전 사이트로 결정될 경우 기존 워드를 옮겨오는 작업도 같이 할 예정이에요.

하루나 이틀 정도 의견을 받으려고 합니다. 의견 남겨주실 분께서는 반드시 '비밀글'로 작성해주세요. 공개글로 남겨주신 의견은 무효처리합니다.

전에도 말씀드린 적 있지만 사이트 관리 순서는 워드 업뎃이 최우선, 개발이 최하위이므로 이전 사이트가 빠른 시일내에 완벽에 가까워지는 일은 없을거에요. …라고해도 방문해주시는 분들 입장에서는 큰 차이나 불편이 없도록 할 예정입니다. 제가 그냥 좀 더 고생하면 출력을 비슷하게 만드는 것 자체는 그리 어렵지 않으니까요 orz

짧게 요약하면

1. 기존 사이트 = 속도 느림, 불안정, 기존 시스템 사용 가능

2. 이전 사이트 = 속도 빠름, 안정, 일부 시스템 사용 불가 및 기존 워드 사용 불가 (이전완료까지)

가 되겠네요.

아니면 테스트도 겸해서 지금 만들고 있는 시스템에는 새로운 버전 워드를 오픈해볼까... 하는 생각도 하고 있습니다. 이 점에 대해서도 의견 있으시면 남겨주시면 감사할거에요 :)

요새 워낙 피곤하다보니 더 횡설수설하는 느낌입니다 orz 궁금한 점이나 이상한 점 있으면 말씀해주세요.

탈 ai + 시스템 완벽 구현을 위해서는 무엇보다도 DB부터 배워야겠네요