텍스트 중심 미니멀 플랫폼이 말하는 것
소셜 미디어가 점점 무거워지는 시대에, textlog는 정반대 방향을 선택했다. JavaScript 없이 동작하는 텍스트 전용 마이크로블로깅 플랫폼으로, 280자 제한의 짧은 노트, 팔로우, 해시태그, 대화 기능만을 제공한다. 알고리즘 추천도 없고, 인게이지먼트 유도 장치도 없다. 기능을 덜어낼수록 플랫폼의 의도가 더 선명해진다는 것을 보여주는 사례다.
백엔드 개발자 관점에서 "No JS"라는 선택은 단순한 철학이 아닌 설계 결정이다. 서버 사이드 렌더링만으로 모든 인터랙션을 처리한다는 의미이고, 이는 클라이언트 번들 크기, 하이드레이션 비용, 상태 관리 복잡도를 원천적으로 제거한다. 요청-응답 사이클을 단순하게 유지하면 캐시 전략도 단순해지고, CDN 활용도 직관적이 된다.
작게 유지한다는 것의 기술적 의미
textlog는 "intentionally small"을 명시적으로 표방한다. 이는 기능 목록을 줄인다는 말이기도 하지만, 동시에 데이터 모델과 API 표면적을 최소화한다는 뜻이기도 하다. 노트, 사용자, 해시태그, 대화라는 네 가지 개념만으로 시스템 전체를 설명할 수 있다면, 스키마 복잡도와 조인 비용이 낮아지고 유지보수 부담도 줄어든다.
280자 제한이라는 단순한 제약도 시스템 설계에 영향을 준다. 컬럼 길이가 고정되고, 인덱싱 전략이 단순해지며, 전체 텍스트 검색 비용이 낮아진다. 제약이 설계를 돕는 대표적인 사례다.
-- 노트 테이블 예시: 제약이 스키마를 단순하게 만든다
CREATE TABLE notes (
id BIGSERIAL PRIMARY KEY,
author_id BIGINT NOT NULL REFERENCES users(id),
content VARCHAR(280) NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
오픈소스 플랫폼 운영에서 눈여겨볼 점
textlog는 계정 데이터를 다운로드하거나 삭제할 수 있는 기능을 제공한다. 이는 단순한 UX 배려가 아니라 GDPR 등 데이터 주권 규정에 대한 실질적 대응이다. 백엔드 입장에서는 사용자 데이터를 어떻게 격리하고, 삭제 요청 시 연관 데이터(팔로우, 노트, 댓글 등)를 어떻게 일관성 있게 처리할지를 미리 설계해야 한다는 의미다. Soft delete와 Hard delete를 언제 구분할지, 비동기 삭제 파이프라인이 필요한지도 초기 설계에서 결정해야 할 문제다.
콘텐츠 모더레이션 정책도 명시되어 있다. 커뮤니티 안전을 위협하는 콘텐츠는 제거할 수 있다고 밝히는데, 이를 구현하려면 신고 기능, 관리자 도구, 상태 필드 관리가 필요하다. 오픈소스로 운영한다면 이 부분의 확장 지점을 처음부터 인터페이스로 추상화해두는 것이 좋다.
정리
- JavaScript 없이 서버 사이드 렌더링만으로 운영하는 방식은 캐싱과 성능 전략을 단순하게 유지할 수 있는 실질적인 장점이 있다
- 도메인 개념을 최소화하면 스키마와 API 설계가 단순해지고 장기 유지보수 비용이 낮아진다
- 데이터 삭제·다운로드 기능은 규정 대응인 동시에, 초기 설계 단계에서 데이터 격리 전략을 강제하는 좋은 요구사항이다