https://arca.live/b/writingnovel/63473567

이 글 보고 구상해본 것. 수능 비문학 지문을 읽는 느낌으로 한번 대충 훑고 일견 간단해 보이는 절차라도 실제로 하나하나 구현하려면 어떠한 세심한 설계 과정이 필요한지 한번 느껴보자.

미리 참고하면 좋은 것 : 아카 공지글) DDOS 및 크롤링에 의한 아카라이브 서비스 장애 및 대응 안내

서론

본 알고리즘은 창문챈의 글 작성 시점, 댓글 등록 시점을 크롤링 기법을 통해 데이터마이닝 하여, 유동인구가 가장 많은 시간대에 대한 통계를 내기 위해 설계한다.

1. 단위 게시물의 구성요소

각각의 단위 게시물은 html 페이지와 같다. 그리고 각 요소들은 해당 페이지 어딘가에 html 태그로서 존재한다.

1.1. 게시물 구분 넘버

하나의 게시물은 하나의 페이지를 차지하며, 그 주소는 우상단에 표기되어 있다.

다음과 같이 공통된 주소형식과 마지막의 일련의 길이가 정해지지 않은 digit의 문자열로 구성되어 있다. 이를 통해 각각의 게시물을 일대일로 구분할 수 있다. 그러나, 해당 숫자가 부여되는 순서는 아카라이브 전체의 게시물의 작성순으로 부여되므로 바로 다음번에 등록된 창문챈의 게시물을 알아낼 수는 없다.

그렇다고 1부터 임의의 숫자까지 모든 숫자 하나하나를 일일히 접속하면서, 그것이 창문챈 소속인지 아닌지 따지는 것은, 사실상 디도스와 같은 서버에 대한 공격행위와 다를 바 없으며 단순히 챈 하나를 대상으로 하기에는 극도로 비효율적인 방법이므로 이 방법은 배제한다. (※주 : 만일 아카라이브 전체에 대한 크롤링 시도라면 이야기가 다르겠지만, 여전히 서버에 부담을 주는 파괴적 행위이니 설령 비영리적 목적을 띤다 한들, 권장되지 않는다.)

따라서, 해당 구분 넘버는 단순히 게시물 페이지에 대한 독립적인 구분 번호로 고려한다.

html 상에서는 body->div->...->div-><a href="https://arca.live/b/writingnovel/넘버" title="게시물 주소">https://arca.live/b/writingnovel/ 넘버 </a>로 구현되어 있다.

(※주 : 보다 상세한 태그 위치와 클래스를 적시할 수도 있겠지만, 이를 기반으로 불특정 다수의 어중간한 인물들이 마구잡이로 공격적인 툴들을 만들어내는 것에 대한 지식적 문턱을 조금이라도 높이고자 상세한 구현들은 본지에서는 고의적으로 생략하겠다.)

1.2. 작성일과 수정일

게시물이라면 필연적으로 작성일이 반드시 1개 존재하며, 경우에 따라 수정일이 병기된 경우도 있다. 시스템의 안정성과 분성의 간결함을 위해서라면 수정일을 생략하는것이 옳겠으나, 수정일 역시 중요한 정보를 담은 데이터로 기능할 수도 있으므로, 적절한 예외처리로 함께 수집하는것이 좋겠다.

html 상에서는 <span class="head">작성일</span> 및 <span class="head">수정일</span>의 body 요소로 가져올 수 있다.

1.3. 댓글 작성일

댓글들은 class="comment-wrapper"들로 나열되어 있는데, 그 내부의 특정 시일 요소를 가져오는 것으로 긁어올 수 있다. 

2. 데이터베이스(DB) 요소 화

DB schem을 만듦에 있어, 최대한 간결하게 단 2개의 col만으로 구성하기로 하였다. 첫번째 col을 구분자로 하여 1.1의 구분넘버를 사용한다. 두번째 col을 본지의 핵심 데이터인 날짜값으로 한다. 

 1st col에 정직하게 구분넘버만 들어있을 경우, 이는 게시물의 작성일을 의미한다. (1)

 1st col이 넘버_0의 꼴을 가질 경우 이는 게시물의 수정일을 의미한다. (2)

 1st col이 넘버_임의의넘버 꼴을 가질 경우 이는 해당 게시물의 해단 번째 댓글을 의미한다. (3)

위 (1-3)의 오른쪽 2nd col에는 해당하는 요소의 작성일이 기록된다.

표현하자면 다음과 같은 꼴로 DB가 구성된다.

이 데이터를 잘 처리하기 위해서는, 1st col의 값에 대하여, (1) 순수히 넘버만으로 이뤄진 게시물 작성일을 의미하는지, (2) _0꼴의 수정일을 의미하는지, (3) 댓글을 의미하는지 처리할 수 있는 매써드를 따로 구현할 필요가 있겠다.

DB는 텍스트 기반으로도, csv 기반으로도 사용해도 되겠으며, 매 한 페이지를 추가할 때 마다 append_row로 계속 추가해 나갈 수 있다.

본지에서는 DB 요소의 삭제는 필요 요소가 아니므로, 이 DB의 경우, append_row(), read_first(), read_next()에 해당하는 매써드만 가지면 충분하며, 데이터 저장을 위한 2-D 배열, 현재 포인터 int변수의 간단한 요소로 구현할 수 있겠다.

3. 크롤링 기법

창문챈의 구조를 잘 살펴보면, 대단히 규칙적인 요소를 볼 수 있다.

https://arca.live/b/writingnovel?p=2

이것은 현 시점에서 2번째 페이지에 해당하는 최신 게시물들의 접속 포인터를 담은 페이지라 볼 수 있다.

또한, https://arca.live/b/writingnovel?p=1 url 역시 동작하므로, 이는 대단히 귀납적으로 작동한다 볼 수 있다.

즉 기본적인 작동 기초는 다음과 같다.

루프 시작, count=1 :

https://arca.live/b/writingnovel?p=%count% 크롤링

 해당 요소들에 기입된 게시물들로 접속 가능한 <a href> 태그에 기입된 1.1 넘버를 긁어와 stack 저장.

 stack에 대한 내부 루프 :

  https://arca.live/b/writingnovel/%stack.pop()% 접속하여, 1.1, 1.2, 1.3의 요소들 수집하여 DB.append_row()로 저장

 break 조건

 count++

end루프

break 조건에는 날짜를 지정하여 해당 날짜까지만 크롤링을 수행할 수도 있고, 특정 넘버의 게시물 또는 페이지 까지만 크롤링 하라 지정할 수도 있겠다. 루프 시작시 count를 지정할수도 있겠다.

3.1. 크롤링 중 에러 조우

크롤링이 진행되는 중에 새로운 게시물이 등록될 경우, 페이지별로 게시물이 하나씩 밀리며, 이미 DB에 등록된 게시물이 한번 더 등록될 수도 있다. 이를 위해, 매 페이지의 1.1의 넘버를 읽을 때 마다 이미 DB에 등록되었는지 확인하는 과정을 추가할 수 있다.

권한이 없는 게시물에 대한 접속시도 시, 비정상적인 페이지를 조우할 수 있는데, 이를 continue 할 절차가 필요하다.

4. DB 데이터를 활용한 통계 후처리

4.1. 샘플링 및 히스토그램 작성

시간에 따른 유동인구를 분석하는 가장 대표적인 방법으로 히스토그램을 작성하는 방법이 있다. 이를 만들기 위해, 단위 샘플의 크기를 정해야 하는데, 요일별, 시간별 등으로 다양하게 기준을 잡을 수 있을 것이다. 본지에서는 a. 요일별, b. 시간별, c. 요일당 시간별 등 3가지 방식으로 모두 샘플링 하는것이 좋겠다 여겨진다. 이를 위해 a. 길이 7, b. 길이 24, c. 길이 168의 3가지 배열을 각각 2개씩 할당하며, DB 내 매 row마다 2nd row의 시간을 읽고 해당하는 배열에 count를 추가하는 방식으로 통계화 할 수 있을 것이다.

4.2. 게시물과 댓글

앞서 동일한 배열을 2개씩 할당하였는데, 이는 게시물과 댓글 각각 통계처리하기 위해서이다. 기본적으로 두 통계는 동일한 결론을 유도하리라 예상되나, 만일 두 통계가 일치하지 않는다면, 독자와 작가는 서로 다른 시간대에 활동함을 의미한다는 고무적인 결론을 얻을 수 있을 것이다. 단순히 총 유동인구를 얻기 원한다면 두 데이터의 단순합으로 통계를 얻을 수 있다.

결론 및 고찰

본지에서는 단순히 시간 요소만을 데이터마이닝 하였으나, 본 설계대로 구현될 시스템이 일으킬 트래픽 소모를 고려한다면, 이는 서버 및 클라이언트 리소스의 낭비와 같다. 때문에, 한번 이 시스템이 작동할 경우 같이 얻을 수 있는 다른 정보를 페이지 내에서 동시에 얻어내야 할 추가적인 고찰이 필요하다.

예를 들어, 작성자 정보를 추가로 라벨링하여, 해당 작성자의 활동 시간대만 필터링 할 수 있겠다.

예를 들어, 게시물 내 총 글자 수를 추가로 라벨링하여, 일정 분량 이상의 게시글이 업로드 되는 시간대 통계를 필터링 할 수 있겠다.

일반적으로, 서버 단위에서는 이러한 시간대 별 접속자 및 업로드 정보가 중요하게 받아들여지므로, 대부분의 back-end 시스템에는 본지의 시스템이 이미 DB 단위에서 구현된 경우가 많다. 그러나 서비스 제공자 측면에서는 그러한 데이터가 수익에 대한 정보가 될 수 있으므로 공개를 꺼리는 경우도 있다. (※주 : 시간대 별 광고 액면가 책정 등) 또한 과중한 서버 트래픽 부하는 해당 서버 운영자 뿐 아니라, 네트워크 제공자에 대한 업무방해로 이어질 수 있으므로 실제 시스템 가동에 있어 이는 매우 주의가 요구된다.

사사 및 권리주장

본지는 https://arca.live/b/writingnovel/63473567 부터 모티브를 얻었으나 그 과정에 일체의 연락·대가제공·작성의뢰를 받지 않았으며, 별개의 인물임을 명시한다. 해당 페이지 또한 인터넷에 공개된 정보로부터 얻었으므로 지적재산권의 보호 대상이 아님을 주장하는 바이다.