Molayo

© 2026 Molayo

Zenn헤드라인2026. 06. 02. 10:50

노른(Norn) 개발기: 자율 진화하는 AI 시스템의 설계 사상

요약

16개의 SaaS를 운영하며 발생하는 데이터 분석 병목을 해결하기 위해 설계된 자율 진화형 AI 시스템 '노른(Norn)'의 개발 과정을 다룹니다. 관찰, 판단, 제안의 3단계 레이어를 통해 AI가 데이터 기반의 우선순위를 제안하되, 인간의 최종 승인을 거치는 통제 가능한 에이전트 구조를 제안합니다.

핵심 포인트

  • 관찰-판단-제안으로 이어지는 3단계 AI 루프 설계
  • 인간의 최종 승인을 포함한 통제 가능한 자율성 확보
  • LLM을 활용한 다수 SaaS의 데이터 구조화 및 우선순위 평가
  • 개인 개발자의 운영 효율을 극대화하는 에이전트 활용 사례

서론

16개의 SaaS를 동시에 운영하다 보면, "인간이 병목(Bottleneck)이 되는 순간"이 반드시 찾아온다.

FreelancePainPollBot이 새로운 페인 포인트(Pain Point)를 수집한다. WorkflowNagBot이 워크플로우의 정체를 감지한다. AIHtmlDiffAlert가 HTML 차분을 보고한다. 각각의 시스템이 매일 데이터를 쏟아내고 있지만, 그 데이터를 보고 "다음에 무엇을 만들지" 결정하는 것은 결국 나 자신이었다.

이 비효율성을 해소하기 위해 만들기 시작한 것이 바로 **노른(Norn)**이라는 시스템이다. 이름은 북유드 신화의 "운명을 잣는 존재"에서 따왔다. 스스로 생각하기에도 조금 거창하다고 느끼지만, 하고 있는 일은 단순하고 현실적인 것이다.

과제: 16개의 SaaS를 인간 혼자서 계속 지켜보는 것의 한계

현재 월간 MRR(Monthly Recurring Revenue) 내역을 보면, FreelancePainPollBot이 ¥4,350로 가장 높다. 이는 프리랜서의 "세세한 고민"을 집약하는 봇으로, 매일 100건 전후의 데이터가 들어온다.

문제는 데이터가 늘어날수록 인간의 판단 비용도 늘어난다는 당연한 사실이었다.

  • 어떤 페인 포인트가 "다음 SaaS의 소재"가 될 수 있는가?
  • WorkflowNagBot에서 감지된 워크플로우의 정체는 신기능으로 해결할 수 있는가?
  • SoloTaxReceiptBot의 이탈 포인트는 LP(Landing Page)의 문제인가, UX(User Experience)의 문제인가?

이것들을 매일 아침 Notion에 수동으로 정리하고 있었는데, 솔직히 힘들었다. LP 개선을 위해 PageSpeed Insights를 돌리고, CVR(Conversion Rate)을 계산하고, 다음 가설을 세우고…… 하는 사이클을 16개 분량이나 해내는 것은 더 이상 "개인 개발"의 규모가 아니다.

해결 방향: AI에게 "관찰→판단→제안" 루프를 돌리게 하기

노른의 설계 사상은 3개의 레이어로 나누어져 있다.

  • 관찰 (Observe) ― 각 SaaS의 로그, 사용자 피드백, 수익 데이터를 수집
  • 판단 (Evaluate) ― 수집한 데이터를 LLM(Large Language Model)으로 분석하여 우선순위 점수를 부여
  • 제안 (Propose) ― "다음에 무엇을 해야 하는지"를 Slack에 알림 또는 GitHub의 Issue로 생성

중요한 것은 "자율 실행은 시키지 않는다"라는 설계 판단이다. AI가 마음대로 코드를 배포하거나 결제 설정을 바꾸게 하지는 않는다. 인간의 최종 승인을 반드시 거친다. 이는 통제력을 잃지 않기 위한 의도적인 제약이며, 개인 개발자의 규모에서는 이것으로 충분하다고 생각한다.

구현: 평가 파이프라인의 핵심 부분

노른의 평가 로직의 중심은 각 SaaS의 데이터를 구조화하여 LLM에 전달하는 부분이다. 다음은 간략화한 Python 예시이다:

import openai
import json

def evaluate_saas_health(saas_data: dict) -> dict:
    """
    각 SaaS의 상태를 평가하여 우선순위 점수와 권장 액션을 반환한다
    """
    prompt = f"""
    다음 SaaS 데이터를 분석하여 JSON 형식으로 반환해 주세요.
    
    ```
    데이터:
    - 서비스명: {saas_data['name']}
    - 월간 수익: {saas_data['mrr']}엔
    ...
    ```
    """

이것을 16개 분량만큼 배치(Batch) 처리하여, 점수가 낮은 순서대로 Slack에 알림을 보낸다. 매일 아침 9시에 실행되는 Cron 잡(Job)으로 작동시키고 있다.

다음으로, 노른 스스로가 "어떤 관찰 지표를 추적해야 하는지"를 업데이트하는 메커니즘도 실험 중이다.

# norn_config.yaml - 노른이 자기 업데이트를 수행하는 설정 파일의 일부

observation_weights:
  mrr_growth: 0.35 # 수익 성장으로의 가중치
  churn_rate: 0.30 # 해지율로의 가중치
  feedback_sentiment: 0.20 # 피드백의 감성 점수
  signup_velocity: 0.15 # 신규 가입 속도

# 이 weight는 노른이 주간 단위로 재검토를 "제안"하고,
# 인간이 승인했을 때만 업데이트된다.

self_update_mode: "propose_only" # "auto"로 설정하지 않음

self_update_mode: propose_only라는 플래그가 설계의 핵심이며, AI가 "이렇게 바꾸고 싶다"라고 말하더라도 Git의 Pull Request로 생성될 뿐 자동으로 적용되지는 않는다.

현시점에서의 솔직한 평가

가동한 지 3주가 지났으며, 몇 가지 알게 된 점이 있다.

좋았던 점:

  • 매일 아침 수동 확인 작업이 30분에서 5분으로 단축되었다
  • FreelancePainPollBot의 피드백으로부터 「확정 신고 소재」에 대한 수요를 자동으로 감지하여, SoloTaxReceiptBot의 개선 우선순위를 높이는 판단을 내릴 수 있었다
  • 「왠지 신경 쓰였지만 뒤로 미뤄두었던」 과제들이 가시화되었다

아직 과제인 점:

  • LLM의 평가가 때때로 빗나가는 경우가 있어, 점수에 대한 과신은 금물이다
  • 피드백 데이터의 노이즈 제거 (Noise Removal)가 아직 거칠다
  • 16개의 API 호출 비용이 한 달에 수백 엔 정도 발생한다 (허용 가능한 범위이긴 하지만)

요약: 「자율 진화」는 작게 시작하는 것이 정답이다

노른(Norn)을 만들며 가장 크게 느낀 점은, AI에게 맡길 범위와 인간이 쥐고 있을 범위를 처음에 결정하는 것의 중요성이다.

「AI가 알아서 전부 다 해준다」는 설계는 개인 개발의 규모에서는 오히려 리스크가 높다. 자신의 서비스가 의도하지 않은 방향으로 움직였을 때, 책임을 지고 수정하는 것도 결국 자신이기 때문이다.

「관찰은 AI, 판단은 인간, 하지만 판단 재료의 정리는 AI에게 도움을 받는다」는 분업이 지금의 나에게는 딱 적당하다. 노른은 아직 발전 단계에 있지만, 16개의 SaaS를 혼자서 운영하기 위한 실용적인 파트너가 되어가고 있다.

다음 단계는 노른 스스로가 「새로운 SaaS 아이디어 후보」를 자동 생성하여 GitHub의 Discussion에 게시하는 기능이다. 그것이 정말로 쓸모가 있을지는 조금 더 사용해 본 뒤에 쓰도록 하겠다.

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0