note 생성 로그가 기사의 사실 정보에 섞여 있던 문제

기사를 생성하는 처리 자체의 로그가 그 기사의 '사실 출처'에 섞여 있었습니다. 원인은, 기사의 재료를 모으는 처리가 운영 이벤트 기록을 구별하지 않고 읽어들이고 있었기 때문입니다.

기사의 근거로 제공되는 정보는 기사 생성과는 별도의 장소에서 수집된다고 착각하고 있었습니다. 하지만, 생성 처리가 기록을 쓰는 곳과 사실을 모으는 곳이 같다면, 처리 자체의 기술적인 기록도 후보에 포함됩니다. 이번에는 그 자기 참조(self-reference)가 실제로 발생했습니다.

note 기사 작성 처리에서는 당일에 일어난 사건들을 모아 기사의 근거로 사용합니다. 이 근거 정보가 바로 기사의 fact_sources입니다. 기사 내용이 실제 사건에 기반하고 있음을 지지하기 때문에, 여기에 들어가는 데이터의 성질은 중요합니다.

문제가 된 것은, 일일 운영 기록을 모으는 처리가 operational_events 테이블의 모든 행을 무조건 사실 정보로 가져오고 있었다는 점입니다. 이 테이블에는 운영상의 사건뿐만 아니라, note 생성 처리에서 출력한 기술적인 메타정보 로그도 포함되어 있었습니다.

그 결과, 기사를 만들기 위한 처리가 자신에 대해 남긴 로그를 기사의 사실 후보로서 읽어들이는 상태가 되어버렸습니다. 로그가 기록되는 것 자체가 문제는 아닙니다. 운영의 움직임을 추적하기 위한 로그와, 기사의 근거로 사용할 정보를 같은 조건으로 다루고 있었다는 것이 문제였습니다.

원인을 추적해 보니, 데이터 획득 처리에는 행의 용도를 구분하는 조건이 없었습니다. operational_events라는 이름만으로는 운영상의 사건을 모으는 곳처럼 보이지만, 실제로는 기사 생성 내부 처리와 관련된 로그도 들어가 있었습니다.

테이블을 참조한다고 해서 그 안의 모든 행이 같은 용도에 적합한 것은 아닙니다. 로그로 저장하는 것과, 기사의 근거로 채택하는 것은 별개의 판단입니다. 이번 획득 처리에는 그 경계가 코드상에 없었습니다.

이 상태에서는, 생성 처리의 동작을 기록할 때마다, 그 기록이 다음 생성 시 사실 후보로서 다시 읽어질 가능성이 있습니다. 로그가 사실로서 본문에 채택되었다고까지는 확인하지 못했지만, 적어도 근거 정보에 혼입되는 경로는 만들어져 있었습니다.

수정에서는 note 생성과 관련된 메타정보 로그를 기사의 사실 정보에서 제외했습니다. 이 변경은 note 생성의 메타로그를 사실에서 제거하는 수정으로 기록되었습니다.

여기서 중요한 것은, 로그를 저장하는 시스템 자체를 없애는 것이 아닙니다. 운영 상태를 추적하기 위한 기록은 필요합니다. 한편, 그 기록을 기사의 근거로 사용할지 여부는 용도에 따라 별도로 제어해야 합니다. 기록 장소에 존재한다는 이유만으로 모든 것을 사실로 취급하지 않도록 했습니다.

이 발견은, 후속 서버의 라이프사이클 기록을 설계할 때의 판단에도 영향을 주었습니다. 그 작업에서는 operational_events를 로그 저장소로 사용하지 않는 방침이 되었습니다.

이번 문제점을 통해 알게 된 것은, 데이터 혼입을 막는 방법이 읽어들이는 쪽에서 제외 조건을 추가하는 것만이 아니라는 것입니다. 쓰는 곳을 분리하면, 나중에 용도를 판단해야 하는 부담이나, 다른 처리가 의도치 않게 읽어들일 가능성을 줄일 수 있습니다. 이번 설계 판단에서는, 사실의 출처에 로그가 섞이는 경로를 만들지 않는 것을 우선했습니다.

'사실의 출처'로 사용할 데이터 소스에는, 생성 대상 처리 자신이 작성한 로그를 무조건 포함해서는 안 됩니다. 로그 저장 장소와 기사의 근거에 사용하는 정보의 경계를, 획득하는 쪽과 저장하는 양쪽 모두에서 의식할 필요가 있었습니다.