웹 사이트의 자동화 시스템 정책

웹 사이트를 만들 때 만약 어떤 페이지가 동적으로 자동 구성되게 만들려면 반드시 어떤 정책(policy)이 필요하다. 자동화 시스템은 대부분 매우 간단하다. 그러나 본질적인 측면에 접근하면 자동화 시스템은 필연적으로 복잡해 진다. 대부분의 시스템은 더 복잡해지려는 속성이 있고, 그 시스템을 사용하는 사람들의 요구에 의해 더 복잡해지기도 한다. 더 많은 '조건'이 있을수록 보다 '신뢰할 수 있다'고 많은 사람들이 생각하기 때문이다.






2001년 즈음에 한 웹 사이트를 만들며 메인 페이지에 <오늘의 인기 글>을 포함시킬 계획을 세웠다. 회사 경영진은 웹 사이트 운영을 위한 인건비를 최소화하길 바랬다. 때문에 매일 <오늘의 인기 글>을 선정하는 것이 아니라 자동으로 이 부분이 구성되어야 한다고 지시했다. 나는 몇 가지 이유를 들며 그런 구성이 바람직하지 않다고 지적했지만 일단 지시한 것을 구현하기로 했다.


정의

<오늘의 인기 글>이라는 것에 대해 정의를 먼저 해야 했다. 개념적 정의지만 이 정의 때문에 멍청한 짓을 반복할 수도 있고 그렇지 않을 수도 있다. 내가 <오늘의 인기 글>을 정의하는 토론을 하자고 제안하자 일부 사람들이 "다 알고 있는 걸 왜 정의해야 하죠?"라고 의문을 제기했다. 최초의 반발에 대해 우리가 알고 있는 정의가 일치하지 않을 수 있고, 설령 일치하더라도 틀렸을 수 있으니 한 번 검토해 보자고 이야기했다. 못마땅한 표정을 짓는 몇 명과 함께 회의실에서 그들이 생각하는 <오늘의 인기 글>에 대해 이야기를 시작했다.

화이트 보드에 커다랗게

오늘 // 의 // 인기 // 글

이라고 적었다. 그리고 사람들에게 지금부터 우리가 해야 할 토론 주제는 5가지인데 각각 "오늘", "의", "인기", "글"이며 끝으로 "오늘의 인기 글"에 대해 토론할 것이라고 말했다. 회의에 참석한 사람들이 웅성대기 시작했다.

"도대체 무슨 소리하는 거야?"
"바빠 죽겠는데 뭘 하자는 거지..."
"저게 프로그램 개발과 무슨 관계가 있어!"

이런 수근거림이 회의실을 가득 메웠다. 그러나 단 한 명은 조용히 이야기를 듣고 있었다, 2주일 전에 입사한 프로그램 팀장이었다. 그는 이전 회사에서 커뮤니티 소프트웨어를 5년 간 개발한 경험이 있는 사람이었는데 내 이야기에 매우 흥미있어 하는 표정이었다. 웅성거림 속에서 그가 이야기를 했다,

"저 주제는 이야기해 볼만 한 것 같습니다. 오늘에 대해 누가 정의해 볼 사람이 있나요?"

순간 회의실은 조용해졌다. 머뭇거리던 사람 중 하나가 대답했다,

"24시간을 기준으로 볼 때 00:00:00에서 23:59:59까지를 오늘이라고 말할 수 있겠죠."

그가 물었다,

"그럼 오늘의 인기 글은 그 하루를 기준으로 해야겠네요?"

다른 사람이 대답했다,

"그렇죠, 오늘의 인기 글이니까요."

그는 고개를 갸웃거리며 말했다,

"그렇다면 00:00:01에 웹 사이트에 접속한 사람은 1초 사이에 선정된 오늘의 인기 글을 봐야 할텐데 1초 사이에 아무런 글이 올라와 있지 않으면 어떻게 되죠?"

회의실은 순간 매우 조용해졌다. 나는 그 팀장에게 감사의 눈빛을 보낸 후 바로 그런 이유 때문에 토론이 필요한 것이라고 말했다. 우리가 '오늘'을 어떻게 정의하는 가에 의해 <오늘의 인기 글>을 개발하는 방식이 매우 달라진다. 우리가 알고 있는 '오늘'과 웹 사이트에서 정의한 '오늘'은 다른 경우가 흔하다. '오늘'의 정의에 대해 토론하는 과정에서 우리는 시스템과 사람들의 인지 사이에 존재하는 부조화를 알게 되었다. 그 결과 '오늘'은 다음과 같이 정의되었다.

- '오늘'을 4개로 나눈다
- 시스템은 6시간 간격으로 새로운 '오늘'을 정의한다
- 24시간 기준의 '오늘'은 새로운 데이터로 저장한다

위와 같이 '오늘'에 대한 정책을 정하게 되었다. 이 정책에 의해 <오늘의 인기 글>은 6시간 간격으로 업데이트되고 하루치 모든 글을 수집하고 통계하는 대신 6시간 간격으로 업데이트된 글만 따로 데이터베이스를 구성하기로 했다. 또한 <어제의 인기 글>이라는 데이터베이스는 24시간을 기준으로 저장되어 보여주기로 했다.

우리는 이어서 "인기"와 "글"에 대한 토론을 했고 각각을 새롭게 정의했다. "의"는 시스템의 시간과 사용자가 인지하는 시간에 대한 토론이었다. 끝으로 "오늘의 인기 글"이라는 통합 개념에 대해 토론했다. 모든 토론을 끝내는데 3시간이 걸렸다. 그러나 이 토론을 통해 시스템을 개발하는 과정에서 만날 수 있는 대부분의 문제를 발견할 수 있었고 실제 개발을 하는 과정에서 추가로 발견되는 문제는 없었다.


한계

이렇게 정의를 하자 <오늘의 인기 글>이라는 시스템의 한계가 드러났다. 만약 00:00:01초에 업데이트된 글이 있다면 이 글이 아무리 인기 있는 글이 올라왔더라도 <오늘의 인기 글>에 반영되는데 최소한 6시간 지연된다. 이 문제를 해결하는 방법으로 "실시간 인기 글을 만들자"는 주장이 있었고 "지연 시간을 1시간으로 줄이자"는 의견도 있었다. 그러나 그렇게 할 경우 시스템이 불필요하게 동작하여 과부하를 발생시키는 문제와 인기 글이 너무 자주 바뀌어 인기 글에 대한 주목을 떨어 뜨리는 문제가 있었다.

한계를 어떤 식으로 극복할 것인지 고민하던 우리는 갑자기 이런 질문에 부딪치게 되었다,

"6시간 업데이트가 과연 적절한가?"

왜 우리는 6시간 간격으로 인기 글을 업데이트하기로 정의한 것일까? 아직 웹 사이트가 서비스를 시작하지도 않았기 때문에 과거에 우리가 경험했던 어떤 웹 사이트에 대한 서로 다른 경험에 기초하여 6시간이라는 지연 시간을 선택했다. 우리는 그 경험 즉 우리들이 경험했던 다양한 웹 사이트의 사례에 대해 이야기했다. 2시간 동안 그 이야기를 더 한 후 우리는 다음과 같은 결론에 이르렀다.

- 하루에 업데이트되는 글이 1백 개 미만일 때까지 6시간 유지
- 3백 개 미만일 때 3시간으로 조정

하루에 새로운 글이 3백 개 이상 올라올 경우 전반적인 하드웨어 추가와 웹 사이트의 질적 업그레이드가 필요하다며 <오늘의 인기 글>에 대한 정책 또한 전반적으로 변화해야 한다고 판단했다. 초기에 곧장 1백 개 이상의 글이 올라 올 가능성은 매우 낮았다. 당시 우리가 기획하던 웹 사이트는 블로그나 BBS와 같은 형태가 아니었기 때문이다. 만약 사용자 제작 콘텐츠에 의해 구성되는 웹 사이트였다면 처음부터 이 정책에 포함된 숫자는 매우 달랐을 것이다.

이렇게 한계에 대해 정의를 했음에도 여전히 문제는 있었다. 매우 중요한 글이나 사용자에 의해 주목받는 글이 갑자기 나타났을 경우 대응책이 없었기 때문이다. 이 부분에 대해 기술적인 시도를 계속하려는 것은 무의미하다고 생각했다. 지금까지 토론하고 정의한 부분으로 기술적인 과제는 충분히 나온 상태이며 완벽히 프로그램에 의해 돌아가는 웹 사이트를 만들 생각은 없었기 때문이다. 나는 "운영자 당번제"를 실시하자고 제안했다.

운영자 당번제는 여러 운영자가 돌아가면서 웹 사이트에서 갑자기 주목받는 글을 <오늘의 인기 글>에 임의로 등록하는 것을 말한다. 이것을 위해 다음과 같은 정책을 정했다

- 해당 글의 조회수가 급등할 경우 해당 운영자 휴대 전화로 문자 메시지 자동 발송
- 급등의 기준은 1시간 이내 100회 이상의 히트수 증가가 있는 경우

SMS로 문자 메시지를 자동 발송하는 소프트웨어는 이미 존재하고 있었기 때문에 어려울 것이 없었다. 급등 기준은 시스템 관리 메뉴에서 임의로 수정할 수 있도록 했다. 나중에 이 시스템은 고의적으로 게시글의 히트수를 증가시키는 어뷰징(abusing) 관리 시스템으로 동작하기도 했다. 자동화를 위해 기술적인 측면으로 접근하는데 몰입했다면 한계는 여전히 한계로 남아 있었을 것이다.



자동화의 현실

웹 사이트를 만드는 사람 대부분은 '자동화'라는 것이 '코드없는 프로그래밍'만큼 비현실적인 이야기임을 잘 알고 있다. 앞서 이야기한 <오늘의 인기 글>의 경우도 결국 자동화의 한계에 부딪치고 말았다. 앞서 이것을 자동화시켜 달라는 경영진에게 반대 이유를 이야기했다고 말한 바 있다. 내가 자동화에 반대한 이유는 세 가지 였다.

첫째, <오늘의 인기 글>은 웹 사이트 운영에 있어서 매우 주요한 요소이며 변동성이 크기 때문에 매일 사람에 의해 '편집되는 것'이 맞다
둘째, 편집하는 행위를 통해 웹 사이트의 현재 상태를 정기적이며 타이트하게 파악할 수 있다. 웹 사이트 운영 회의와 기획 회의를 동시에 진행할 수 있다
셋째, 우리 웹 사이트에 어떤 글이 '인기 글'로 올라 올 지 추측할 수 있을 뿐 정확히 알 수 없다. 추측으로 자동화시킨 시스템은 사람을 더 힘들게 할 뿐이다.

이런 세 가지 이유로 <오늘의 인기 글>은 운영자에 의해 선정되고 편집되는 것이 옳다고 주장했다. 자동화 시스템은 웹 사이트를 연 후 계속 사용되긴 했지만 실제로 그 웹 사이트가 살아 있는 동안 대부분의 <오늘의 인기 글>은 운영자에 의해 편집되었다. 웹 사이트의 많은 부분은 현재도 사람의 판단에 의해 편집되고 있다. 어떤 사람들은 잘 만들어 둔 로직(logic)과 코드(code)에 의해 웹 사이트가 자동으로 구성되어 운영될 수 있다고 이야기한다. 웹 사이트는 많은 하드웨어와 소프트웨어에 의해 움직이지만 그렇다고 웹 사이트 자체가 로직이나 코드로 구성된 소프트웨어는 아니다. 아직까지 인간이 입력한 콘텐츠를 인간답게 완벽히 이해하는 소프트웨어는 존재하지 않는다.

웹 사이트에 게시판을 만들었다는 것은 어떤 종류의 콘텐츠가 올라올 지 예측할 수 있을 뿐 반드시 그 결과가 예측과 일치하는 것은 아니다. 이런 불확실성을 극복하기 위해 게시판의 이름을 '브라우저에 대한 이야기'라고 정하는 대신 "매킨토시에서 동작하는 오페라 브라우저에서 CSS를 구현하는 표준화에 대한 5년차 C++ 프로그래머의 라이브러리에 대한 질문과 대답"이라고 정할 수도 있을 것이다. 그런 게시판을 만들어 보라. 누군가 그 게시판에 "오늘 점심 메뉴는 뭐가 좋을까요?"라는 질문을 하지 않을 것이라고 확신할 수 있는가? 그런 게시물을 다른 게시판으로 옮기는 자동화 소프트웨어를 만드는 것이 무슨 의미가 있겠는가?

그러나 웹 사이트 자동화 시스템에 대한 관점을 조금 바꾼다면 지금보다 훨씬 행복하게 웹 사이트를 만들 수 있다. '귀찮은 것', '반복되는 것', '사람으로 할 짓이 아닌 것'을 코드로 바꿔서 소프트웨어가 반복하도록 만드는 것을 자동화라고 정의해 보면 어떨까. 그렇게 생각을 바꾼다면 웹 사이트를 자동화할 수 있는 요소는 분명히 존재한다. 사람이 해야 할 '마땅한 일'을 자동화하려는 멍청한 시도보다 사람이 하지 않아도 되는 '멍한 일'을 자동화하는 게 아름답다.