이전에 이 주제로 관점을 한 번 정리한 적이 있습니다. 자동 생성이 아니라 이어 쓰기여야 한다는 이야기였는데, 그때는 문제 제기에 가까웠습니다. 이번 글은 그 뒤의 기록입니다. 실제로 메리톡톡을 만들면서 어디서 멈출지, 무엇을 포기할지를 코드 단위로 정해야 했고, 그 결정들을 남겨둡니다.가장 먼저 확인한 것은 제 자신의 반응이었습니다. 초기 버전에서 문단 하나를 통째로 생성해 화면에 띄워봤는데, 문장은 꽤 그럴듯했는데도 손이 멈췄습니다. 고쳐 쓸지 지울지를 판단하는 동안, 원래 쓰려던 문장이 머릿속에서 사라졌습니다. 잘 쓰인 남의 문장이 내 문장을 덮어쓴 셈입니다.그때 알았습니다. 창작 보조 도구에서 진짜 위험한 것은 품질이 낮은 결과물이 아니라, 품질이 적당히 높아서 판단을 대신해버리는 결과물입니다. ..

메리톡톡을 다시 만들면서, 서비스가 스스로 상태를 점검하고 문제를 발견한 뒤, 필요하다면 개선 제안까지 할 수 있는 시스템이 필요하다는 생각이 들었습니다.단순히 장애 여부를 감시하는 모니터링 수준이 아니라, 사람의 개입을 최소화하면서도 위험한 작업은 자동으로 실행되지 않도록 막아주는 구조가 필요했습니다. 그래서 백그라운드 서비스를 몇 가지 계층으로 나누어 설계하기로 했습니다.전체 구조전체 구조는 크게 세 가지 계열로 구분했습니다.Watcher 계열, Control 계열, Communication 계열입니다. 각각의 역할은 명확하게 분리했습니다.WatcherWatcher는 말 그대로 관찰만 담당합니다.Site Health Watcher, Log Analyzer, GitHub Watcher, Content ..

메리톡톡은 처음부터 지금의 모습으로 시작한 서비스가 아니었다.가장 처음의 메리톡톡은 ASP.NET MVC로 만들었다. 당시의 나는 지금처럼 “글쓰기 경험”이나 “창작자의 리듬” 같은 표현을 명확히 붙잡고 있지는 못했다. 그래도 한 가지는 분명하게 알고 있었다.이 서비스는 단순한 게시판이 아니어야 했다.작품과 작가가 있고, 그 정보가 링크 하나로 외부에 공유될 수 있어야 했다.누군가 특정 작품의 링크를 SNS에 붙여 넣었을 때, 그냥 밋밋한 URL 한 줄만 보이는 것이 아니라 작품 제목, 소개, 대표 이미지가 카드처럼 보여야 했다. 작가 페이지도 마찬가지였다. 링크 하나만으로도 “이 글이 무엇인지”, “누가 쓴 글인지”, “읽어볼 만한지”가 전달되어야 했다.그래서 당시에는 서버에서 HTML을 만들어 내려주..