입력과 목적을 명확히 분리
같은 AI 모델을 사용해도 카테고리 허브와 세부 키워드 문서는 역할이 다릅니다. 상위 문서는 넓은 맥락과 분류를 설명해야 하고, 하위 문서는 하나의 주제를 깊게 다뤄야 합니다. 작업 유형에 맞는 프롬프트와 출력 형식을 분리하면 결과가 서로 비슷해지는 문제를 줄일 수 있습니다.
TECH & AUTOMATION반복은 자동화하고,
반복은 자동화하고,
중요한 판단은 더 잘 보이게.
YM LABS는 기술을 복잡하게 보이기 위한 장식으로 사용하지 않습니다. 운영자가 반복하는 일을 줄이고, 사용자의 요청을 안정적으로 처리하며, 서비스가 커졌을 때도 현재 상태를 파악할 수 있도록 만드는 도구로 사용합니다.
request → queue → workerworker → api → validatevalidate → file → publishmonitor → retry → improve자동화의 목적은
사람을 없애는 것이 아닙니다.
자동화는 사람이 해야 할 일을 무조건 시스템에 넘기는 과정이 아닙니다. 반복 규칙이 명확한 작업은 시스템이 처리하고, 예외나 중요한 판단이 필요한 순간은 운영자가 쉽게 확인할 수 있도록 만드는 것이 더 현실적인 접근입니다. 예를 들어 수천 개의 키워드 콘텐츠를 생성할 때 사람이 하나씩 실행할 필요는 없지만, 어떤 작업이 실패했고 왜 실패했는지는 관리자에서 확인할 수 있어야 합니다.
그래서 YM LABS는 자동화 기능을 만들 때 ‘성공했을 때’보다 ‘실패했을 때’를 먼저 생각합니다. 작업에는 대기, 처리 중, 완료, 실패 같은 상태를 두고, 일정 횟수 재시도하거나 관리자가 다시 실행할 수 있게 합니다. 외부 API 응답을 그대로 믿지 않고 필요한 형식인지 확인한 뒤 최종 결과로 저장하며, 생성 중인 파일을 바로 공개하지 않고 임시 파일에 완성한 뒤 원자적으로 교체하는 방식을 사용합니다. 이런 작은 원칙들이 운영 중 깨진 결과가 노출되는 문제를 줄입니다.
AI PIPELINE
AI는 독립된 버튼이 아니라 작업 파이프라인의 일부입니다.
AI API를 호출하는 것 자체는 어렵지 않습니다. 실제 서비스에서 중요한 것은 어떤 입력을 보내고, 결과가 조건을 만족하는지 확인하고, 실패했을 때 어떻게 복구하며, 완성된 결과를 어디에 저장할지 결정하는 과정입니다.
대기열로 작업을 분산
AI 생성처럼 시간이 걸리는 작업을 사용자의 웹 요청과 같은 흐름에서 오래 실행하면 타임아웃이나 중복 실행 문제가 생길 수 있습니다. 작업을 DB 대기열에 등록하고 워커가 하나씩 처리하면 요청 수가 많아져도 제어하기 쉬워집니다. 처리 수량과 실행 주기를 조절해 외부 API 사용량도 관리할 수 있습니다.
결과 검증 후 저장
AI 응답은 예상한 JSON 구조가 아닐 수 있고 필수 항목이 비어 있을 수도 있습니다. 결과를 바로 공개하지 않고 제목, 설명, 본문이 존재하는지 확인하고 허용한 HTML 구조만 남긴 뒤 저장합니다. 검증에 실패하면 작업을 실패 상태로 기록해 원인을 확인할 수 있게 합니다.
완성된 결과는 안정적으로 제공
변경이 적은 대형 문서는 매 요청마다 DB에서 본문을 조립하는 대신 완성된 HTML 파일로 보관할 수 있습니다. 임시 파일에 먼저 저장하고 완성 후 이름을 바꾸면 작업 도중 프로세스가 종료되더라도 기존 정상 파일은 그대로 유지됩니다. 읽기 중심 서비스에서 단순하고 안정적인 방식입니다.
WEB ARCHITECTURE도메인은 많아도
도메인은 많아도
애플리케이션은 하나로 관리할 수 있습니다.
열매 지식정보처럼 수많은 서브도메인을 사용하는 서비스에서 서브도메인마다 폴더와 PHP 파일을 만들면 유지관리가 불가능해집니다. 대신 웹서버의 와일드카드 가상호스트가 모든 요청을 하나의 애플리케이션으로 보내고, 애플리케이션이 Host 값을 분석해 해당 카테고리와 키워드를 찾는 방식으로 구성할 수 있습니다.
이 구조에서는 공통 디자인을 한 번 수정하면 전체 문서에 반영되고, 새로운 키워드가 추가돼도 실제 사이트 폴더를 만들 필요가 없습니다. 카테고리 단위의 와일드카드 DNS만 준비하면 그 아래 세부 키워드 호스트는 동일한 라우터가 처리합니다.
Browser키워드.카테고리.열매.com
→CloudflareDNS · TLS · Proxy
→ApacheWildcard VHost
→PHP RouterHost Resolution
→HTML FileFast Output
DATA STRATEGY
무조건 DB, 무조건 파일이라는 정답은 없습니다.
데이터는 변경 빈도와 조회 방식에 따라 저장 방법을 달리해야 합니다. YM LABS는 서비스 특성을 보고 DB와 파일의 역할을 분리합니다.
DATABASE
상태와 관계를 관리
카테고리와 키워드의 관계, 활성·비활성 상태, 작업 대기열, 파일 경로, 생성 시간처럼 자주 조회하고 변경되는 운영 데이터는 DB에서 관리하는 것이 편리합니다. 조건 검색과 정렬, 집계가 필요하기 때문입니다.
- 카테고리·키워드 색인
- 작업 상태와 재시도
- 서비스 설정과 관리자 데이터
- 관계 및 목록 조회
FILE STORAGE
완성된 문서를 빠르게 제공
한 번 생성된 뒤 자주 수정되지 않는 긴 HTML 본문은 파일로 저장할 수 있습니다. 웹 요청에서는 파일을 읽어 바로 출력하고, 광고나 운영 코드는 원본과 분리해 런타임에 합성하면 문서 자체를 다시 생성하지 않고도 운영 요소를 바꿀 수 있습니다.
- 고정 HTML 콘텐츠
- 문서별 광고·삽입 코드
- 정적 캐시에 가까운 빠른 읽기
- 본문과 운영 데이터 분리
이 역할 분리는 백업과 장애 대응에도 도움이 됩니다. 운영 DB의 특정 테이블을 복구해야 하는 상황과 콘텐츠 파일을 복구해야 하는 상황을 구분할 수 있고, 문서 본문을 재생성하지 않고도 운영 메타데이터만 수정할 수 있습니다. 반대로 파일 경로가 바뀌었을 때도 DB의 색인 값을 기준으로 어떤 문서가 연결되는지 확인할 수 있습니다.
대량 파일은 하나의 디렉터리에 무작정 몰아넣지 않습니다. 카테고리와 숫자 ID를 기준으로 하위 폴더를 나누고, 필요하면 일정 단위로 샤딩해 파일 수를 분산합니다. 파일명은 사용자에게 보이는 URL과 분리해 숫자 기반 ASCII로 유지하면 서버 이전, 압축, 백업, 배치 작업에서 한글 파일명 인코딩 문제를 줄일 수 있습니다.
이처럼 저장 구조는 단순한 기술 취향이 아니라 운영 방식과 직접 연결됩니다. 사용자가 보는 주소는 읽기 쉬운 한글 키워드를 유지하면서 서버 내부에서는 안정적인 ID와 경로를 사용해 두 요구를 함께 만족시킬 수 있습니다.
SECURE OPERATIONS외부 API와 관리자 기능은
외부 API와 관리자 기능은
편리함만큼 경계를 중요하게 봅니다.
Cloudflare나 OpenAI 같은 외부 API는 서비스 자동화를 크게 단순화하지만 인증 정보가 노출되면 위험합니다. 브라우저에서 직접 사용할 필요가 없는 키는 웹루트 밖의 서버 설정 파일에 두고, 공개 소스와 분리해 관리합니다.
관리자에서 HTML이나 광고 코드를 직접 입력하는 기능은 강력한 만큼 관리자 인증과 CSRF 검증을 거친 요청에서만 저장합니다. 문서별 삽입 코드는 원본 콘텐츠와 분리해 변경 영향 범위를 작게 유지합니다.
API 키와 DB 비밀번호는 공개 웹 디렉터리 밖에 두고 애플리케이션에서 서버 내부 경로로 읽습니다.
외부 API 토큰은 필요한 도메인과 작업 권한만 부여해 한 토큰이 불필요하게 넓은 범위를 제어하지 않게 합니다.
운영 코드 입력과 상태 변경은 인증된 관리자 세션과 CSRF 토큰을 통해서만 처리합니다.
실패 원인을 기록하되 비밀값이나 민감한 요청 전체가 로그에 남지 않도록 필요한 메시지만 저장합니다.
서비스의 성능 문제는 항상 복잡한 서버 증설로 해결되는 것이 아닙니다. 불필요한 쿼리가 반복되거나, 매 요청마다 바뀌지 않는 데이터를 다시 계산하거나, 하나의 요청 안에서 오래 걸리는 외부 작업을 모두 처리하는 구조가 원인일 수 있습니다. YM LABS는 문제가 생기면 먼저 실제 병목을 확인하고 데이터 조회, 파일 캐시, 작업 분리, 인덱스 같은 기본 구조에서 해결할 수 있는지 살펴봅니다.
자동화 역시 실행 빈도를 높이는 것이 항상 좋은 것은 아닙니다. 외부 API의 처리 속도와 비용, 서버 자원, 작업 누적량을 보고 적절한 주기를 선택해야 합니다. 실패가 반복되는 작업을 무한히 다시 실행하면 비용만 증가할 수 있기 때문에 재시도 횟수와 최종 실패 상태를 명확하게 관리합니다. 운영자는 실패 목록을 보고 필요한 경우 원인을 수정한 뒤 다시 실행할 수 있습니다.
결국 기술의 목적은 서비스 운영을 더 단순하고 예측 가능하게 만드는 것입니다. 시스템이 무엇을 하고 있는지 알 수 없게 만드는 자동화보다, 현재 상태가 보이고 문제가 생겼을 때 정확히 개입할 수 있는 자동화가 더 좋은 시스템이라고 생각합니다.
OBSERVABILITY
자동화된 시스템일수록 지금 무엇을 하는지 보여야 합니다.
워커가 백그라운드에서 많은 일을 처리하면 운영자는 화면만 보고는 현재 상황을 알기 어려울 수 있습니다. 그래서 작업의 시작과 완료 시각, 실패 이유, 재시도 횟수, 마지막 처리 결과처럼 필요한 정보를 남깁니다. 로그는 모든 내부 데이터를 무작정 기록하는 것이 아니라 장애를 재현하고 원인을 찾는 데 필요한 수준으로 설계합니다.
대량 작업에서는 한 건의 실패가 전체 작업을 멈추지 않도록 만드는 것도 중요합니다. 서로 독립적인 작업이라면 실패한 항목만 별도로 기록하고 다음 작업을 계속 진행하는 편이 효율적입니다. 반대로 선행 작업이 반드시 성공해야 하는 흐름에서는 실패 시 후속 작업을 시작하지 않아야 합니다. 자동화는 작업의 관계를 정확히 이해할 때 안정적으로 동작합니다.
배치와 크론 역시 단순히 자주 실행한다고 좋은 것이 아닙니다. 실행 시간이 다음 주기보다 길어질 수 있는지, 중복 실행이 발생하면 같은 데이터를 두 번 처리할 수 있는지, 외부 API 제한을 넘길 가능성이 있는지 확인해야 합니다. 필요하면 잠금과 작업 소유자를 기록하고, 실행 주기를 서버와 API의 처리량에 맞게 조절합니다.
AI
TECHNOLOGY AT YM LABS기술은 더 복잡하게 만들기 위한 것이 아니라
기술은 더 복잡하게 만들기 위한 것이 아니라
더 적은 반복으로 더 안정적으로 운영하기 위한 것입니다.
AI, 워커, 파일 저장, DB, 와일드카드 라우팅, 외부 API는 각각 목적이 있을 때 사용합니다. 필요한 위치에 필요한 기술만 배치하는 것이 YM LABS의 기술 방향입니다.