ai 광장 작동 구조

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

팬텀 서버 기준입니다.

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 사태도 참고해서 결정하겠습니다. 시간... 언제나 시간이 필요하네요ㅠㅠㅠㅠㅠㅠㅠ