처음부터 여러 서비스를 묶은 플랫폼을 만들 생각은 없었습니다. 시작은 늘 더 작은 문제였습니다. 시장 데이터를 여러 화면에서 확인하는 시간이 아까웠고, 경매 원문은 정보가 많지만 비교가 어려웠고, 캠핑을 가기 전에는 날씨와 시설을 따로 찾아야 했습니다. 영상 제작은 도구를 바꿀 때마다 맥락이 끊겼습니다. 이런 작은 불편을 하나씩 해결하다 보니 서로 전혀 달라 보이는 여섯 개 서비스가 생겼습니다.
분야가 아니라 ‘결정’을 기준으로 서비스를 나눴습니다
AlgoPick은 시장을 볼 때 “지금 무엇을 더 확인해야 하는가”를 정리합니다. 집찰은 법원 경매와 온비드 공매에서 “이 물건을 더 볼 가치가 있는가”를 판단하기 위한 출처와 조건을 모읍니다. 가기전에는 캠핑장 시설과 기상청 예보를 겹쳐 “무엇을 챙겨야 하는가”를 줄이고, 지금사도돼?는 서로 다른 판매 단위를 맞춰 “정말 싼가”를 비교합니다.
한줄정원은 짧은 문장 자체보다 출처와 해설을 함께 두어 “왜 지금 이 문장을 읽을 만한가”를 설명하고, AI Video Studio는 시나리오부터 업로드까지 흩어진 제작 과정을 이어 “다음 단계가 무엇인지”를 놓치지 않게 만드는 도구입니다. 제품의 소재는 다르지만 모두 사용자의 다음 행동 직전에 생기는 마찰을 줄이는 방향으로 설계했습니다.
공통 규칙 1: 원천 데이터와 우리의 해석을 섞지 않습니다
공공데이터나 시세 데이터는 숫자가 있다고 끝이 아닙니다. 조사 시점이 다를 수 있고, 값 0이 실제 ‘없음’인지 미확인인지 구분되지 않을 수도 있습니다. 그래서 ICT 서비스에서는 원문·조사 시점·갱신 시각처럼 원천에서 확인 가능한 사실과, 비교·정렬·주의 신호처럼 우리가 계산한 결과를 가능한 한 화면에서 구분하려고 합니다.
공통 규칙 2: 자동화는 결과를 대신하는 게 아니라 반복 작업을 줄입니다
서비스 제작과 운영에는 자동화와 AI를 적극적으로 씁니다. 하지만 자동화가 만들었다는 이유만으로 결과를 사실처럼 노출하지는 않습니다. 최신성이 중요한 화면은 원자료 시각을 함께 보여주고, 오래된 분석은 현재 상태와 분리합니다. 콘텐츠도 초안을 자동화할 수 있지만 출처 확인, 제품 맥락, 실제 경험을 추가하지 않은 글을 발행하는 방식은 피합니다.
공통 규칙 3: 한 브랜드지만 서비스는 독립적으로 실패할 수 있어야 합니다
여섯 서비스는 각각 별도 서브도메인에서 운영합니다. 하나의 기능이 느려지거나 외부 데이터 제공처가 흔들려도 다른 서비스까지 같이 멈추지 않도록 하기 위해서입니다. 반면 사용자 입장에서는 같은 운영 주체, 같은 계정 체계, 같은 개인정보·콘텐츠 원칙을 확인할 수 있도록 루트 도메인에서 연결합니다.
이 구조는 개발 편의보다 운영 책임을 분명하게 하는 데 도움이 됐습니다. 어느 화면의 데이터인지, 어느 서비스의 기능인지, 문제가 생겼을 때 어디를 고쳐야 하는지가 명확해집니다.
이제 결과뿐 아니라 만드는 과정도 기록합니다
루트 사이트에 Articles를 만든 이유도 같습니다. 완성된 서비스 카드만 보면 “무엇을 만들었는지”는 알 수 있지만 “왜 이렇게 만들었는지”는 알기 어렵습니다. 앞으로는 실제 개발 과정에서 문제가 됐던 데이터 품질, UI 판단, 자동화의 한계와 수정 과정을 이 공간에 기록하려고 합니다.
검색엔진을 위한 글 수 채우기가 아니라, 서비스를 쓰는 사람이 기능의 배경을 이해하고 개발자에게는 같은 시행착오를 줄여주는 기록이 목표입니다. 그래서 글마다 실제 화면과 구체적인 실패 사례를 남기고, 바뀐 내용이 있으면 날짜와 함께 수정할 예정입니다.