Cocoa/위키 봇을 처음 만드는 사람들을 위한 가이드

이 문서는, 봇을 만드는 방법 등 기술적인 측면보다는 유의해야 할 점과 같은 내용을 중점으로 다룹니다.

어떤 프로그램도 오류가 없을 수는 없습니다. 단순히 "Hello, World!"만 출력하다고 하더라도 극단적인 상황에서는 오류가 발생할 수 있습니다.
중요한 건, 오류가 발생할 수 있음을 인정하고 오류 발생 시에 대처할 방법을 만드는 것입니다.

나무위키 서버는 상당히 안정적입니다. 위키백과 서버도 안정적인 편입니다. 그래서 주로 하는 실수가, 네트워크를 다루는 부분에 예외 처리를 하지 않는다는 것입니다. 만들 때도, 평소에 운용할 때도 문제가 생기지 않습니다. 잊고 지나갑니다. 그러다가 서버에 장애가 발생하거나, 순간적인 오류로 비정상적인 응답이 돌아왔을 때 이러한 예외 처리가 정상적으로 이루어지지 않았다면 봇은 예기치 않은 동작을 할 수 있습니다.

예외 처리는 중요합니다. 통신이 일어나는 모든 부분을 예외 처리해야힙니다. 그렇다고 모든 곳에 try-catch를 넣을 수는 없으니, 외부 통신을 처리하는 함수를 만들어 함수 내에서 예외 처리를 하는 방법도 고려해 볼 수 있습니다.

간혹 빠른 봇을 원해서 극단적인 속도로 봇을 운용하는 분들이 있습니다. 바로 제가 그랬습니다.

하지만 중소규모의 위키에 극단적인 속도로 봇을 가동하면 서버가 버티지를 못합니다. 적당한 속도로 가동하세요. 그렇지 않으면 서버를 터뜨린 봇이 되고 말 것입니다.

가동 전 서버를 관리하는 분과 이야기를 해 보는 것도 좋은 방법입니다.

잘못된 명령을 내렸던, 로직을 잘못 작성했던 결국 언젠간 오류가 발생합니다. 그렇다면 이를 해결할 수도 있어야 합니다. 그렇다고 봇을 쫓아다니면서 되돌리거나 일괄 되돌리기를 사용하는 것도 쉽지만은 않습니다.

당연한 말입니다. 하지만 복잡하거나 범위가 넓은 작업을 처리한다면 예시를 몇 개 만들어 테스트를 진행해 보는 것이 좋습니다.

너무 늦게 알면 고생하는 건 운용하는 사람이니까, 작동하기 전에 꼭 테스트를 해봅시다. 잘못 동작해도 덜 후회합니다.

the seed 엔진은 특히나 더 그렇습니다만, 나무마크 자체가 휴먼 에러를 적절히 처리해 주는 특징이 있습니다. [include(틀:틀 이름, 인자1=값1)]을 [include( 틀: 틀 이름 , 인자1 = 값1)]처럼 적어도 동작합니다. 적당히 정규식으로 봇을 만든다면, 이러한 경우에 편집이 잘 되지 않을 수 있습니다. 제가 그랬습니다.

틀린 문법을 잔뜩 찾으세요. 틀린 문법으로 테스트를 해보세요. 이러한 "틀린 문법"까지 대응할 수 있어야 장기적으로 편해집니다. 잘 편집한 줄 알고 넘겼는데 알고 보니 일부 문서에 동작하지 않았다는 것을 늦게 알게 되면 막막해집니다.

일시적으로 편집 전후의 본문을 저장해 두는 것이 도움이 될 수 있습니다. 후술할 사후 검증 프로세스 개발에도 필요합니다. 물론 이를 저장하는 시스템 구축과 용량 사용 등은 다소 부담될 수 있으나, 어떠한 문제가 발생했을 때 검증하고 해결할 수 있는 가장 쉬운 방법의 토대를 만들어줍니다. 용량 등이 부담스럽다면 봇을 새로 작동할 때마다(=새 요청을 처리할 때마다) 기록한 값을 초기화하는 것도 방법일 수 있습니다.

봇 동작에 오류가 발생했을 때, 차라리 모든 편집이 오류였다면 쉬울 수도 있겠지만 보통은 그렇지 않습니다. 일부에만 문제가 발생합니다. 그럴 때는 봇을 수정해서 문제를 해결하더라도 이미 일어난 편집에 대응해야 합니다.

앞에서 기록한 정보를 이용하면 이를 좀 더 쉽게 해결할 수 있습니다. 기록했던 원본을 새 로직으로 처리한 뒤 결과 값을 기록한 결과 값과 비교하여 다르다면 검토하고, 다르지 않다면 문제가 없는 것으로 간주할 수 있습니다.

만약 병렬 처리로 긴급 중단 시스템을 처리하여 편집과 별개로 동작한다면, 반드시 긴급 중단 시스템에 오류가 발생했을 때도 중단하도록 하거나, 시스템에 오류가 발생해도 다시 처리할 수 있어야 합니다.

사용자 토론에 새 글이 올라왔을 때 긴급 중단하는 것이 많은 위키 봇들의 동작입니다. 만약 어떠한 오류로 인해서 이 시스템이 중단됐는데, 편집은 그대로 동작하고, 이 편집에 문제가 발생한다면 피해는 점점 커질 것이고 이를 지켜보는 다른 기여자들에게 좋은 인상을 남기진 못할 것입니다.

발전소에서 중요한건 뭘까요? 전기를 잘 만드는 것도 중요하지만 긴급한 상황에 잘 멈추는 것이 가장 중요합니다. 자동차에서 중요한건 뭘까요? 잘 주행하는 것도 중요하지만 긴급한 상황에 잘 멈추는 것이 가장 중요합니다. 봇의 긴급 중단 시스템은 핵심입니다.

모든 사람은 실수를 합니다. 평생 실수를 안 하셨다고요? 컴퓨터도 오류를 내는데 정말 앞으로도 실수를 안 하실 거라 단언하실 수 있나요?

중요한 건 실수를 하지 않는 것이 아닙니다. 실수를 하더라도 복구할 수 있는 것이 중요하고, 그전에 실수 자체를 막을 수 있는 것이 중요합니다. 대한민국 행정에서 잊을 만하면 발생하는 "실수"가 바로 "사망 처리"입니다. 2022년에는 이 때문에 선거에 참여하지 못한 사람도 있었고, 2024년에 한 면사무소는 상반기에만 두 번이나 실수를 저질렀습니다. 그렇다면 반복적으로 실수가 일어난다는 것을 알 수 있습니다. 사망 처리는 부활[1]로 회복시킬 수 있지만, 사실 이 실수 자체를 시스템에서 최대한 막는 게 근본적인 해결책입니다.[2]

봇을 운용하면서 실수할 수 있는 부분은 상당히 많습니다. 요청자가 역링크 정리 요청을 반대로 했다거나, 틀린 요청을 하는 경우부터 시작해서 편집 요약을 잘못 설정한다거나 하는 등 실수할 수 있는 부분이 잔뜩 있습니다.

사람이 검증하는 것엔 실수가 일어날 수밖에 없습니다. 모든 것을 자동으로, 기계가 하는 것이 그나마 오류 가능성을 낮출 수 있는 방법입니다. 위에서 컴퓨터도 오류가 발생한다고 했지만, 그 오류 가능성이 사람의 오류 가능성보단 현저히 낮은 것이 사실입니다.

역링크 정리를 요청받았을 때, 요청이 수십 건이라면 이를 모두 검증하는 것 자체가 상당히 번거롭습니다. 그러면 결국 일종의 안전불감증이 생겨서 표제어를 토대로 "추측"해서 동작하는 일이 언젠간 올 수도 있습니다. 하나하나 확인하더라도 실수할 가능성이 높은 것 또한 사실입니다.

자동으로 "편집" 할 수 있다는 것은, 문서의 원문을 자동으로 알 수 있다는 것입니다. A에서 B로 바꿀 때, 바로 역링크를 탐색하는 것이 아니라 먼저 A에 편집 요청을 보낸 뒤 돌아온 원문으로 "정말 A가 B에 대한 역링크가 맞는지" 확인하는 과정을 자동으로 진행한다면 상당량의 작업을 자동화하는 것이 가능하고, 실수의 여지도 상당히 줄일 수 있습니다.

역링크 정리와 같은 "반복되는" 작업은 모두 자동화하는 것이 장기적으로도 이득입니다. 자동화를 하게 되면 정해진 입력으로 정형화를 하게 될 것이고, 오류 검증이 더욱 쉬워집니다.

위의 이미지는, 제가 역링크 정리 요청을 처리할 때 사용하는 스크립트입니다. 역링크 정리 요청의 스레드 주소와 요청 리스트를 넣게 되면 이를 내부에서 사용하는 JSON 형식으로 변환해 주는 스크립트로, 단순 반복 작업을 획기적으로 줄여줄 뿐만 아니라 URL 검증 등을 자동으로 진행해 주기 때문에 실수 가능성을 낮출 수 있었습니다.