Aidengoldkr – Tech Blog

1. 도입 — 정보는 넘치는데, 실행은 왜 여전히 우리 몫인가

우리는 매일 엄청난 양의 정보를 소비한다. 학교 공지, 과제 안내문, 이벤트 포스터, 회의 자료, PDF 문서. 스마트폰을 켜면 쏟아지는 정보들을 캡처하고, 저장하고, 때로는 다시 꺼내 읽는다. 그런데 여기서 하나의 근본적인 문제가 있다.

정보를 이해하는 것과, 정보를 실행하는 것은 전혀 다른 일이다.

OCR은 이미지에서 텍스트를 뽑아낸다. 요약기는 긴 글을 짧게 만든다. 생산성 앱은 할 일 목록을 관리한다. 그런데 이 세 가지 도구를 다 사용해도, 결국 "이 문서에서 내가 뭘 해야 하는가"를 판단하는 건 여전히 인간이다.

정보 이해와 실행 사이에는 여전히 인간의 해석이라는 마찰이 존재한다.

Actonix는 이 마찰을 제거하기 위해 만들어졌다.

---

2. 문제 정의 — 실제로 어떤 상황에서 이런 일이 벌어지는가

상황 1: 학교 공지 캡처

수행평가 안내문을 캡처해서 갤러리에 저장했다. 마감일이 언제였더라? 제출 방식이 뭐였지? 다시 꺼내 읽고, 달력에 직접 입력하고, 할 일 앱에 따로 등록한다. 이 과정을 매번 반복한다.

상황 2: 해커톤 규칙 PDF

참가 규정 PDF를 받았다. 팀 구성 조건, 제출 기한, 발표 일정이 전부 텍스트로 산재해있다. OCR로 긁어봤자 텍스트 덤프만 나온다. 결국 직접 읽고 정리한다.

상황 3: 과제 안내문 스크린샷

교수님이 수업 중 슬라이드로 보여준 과제 안내를 스크린샷 찍었다. 요약기에 넣으면 의미가 압축되긴 하는데, "그래서 내가 언제까지 뭘 제출해야 하는지"는 여전히 내가 판단해야 한다.

---

기존 도구의 한계

도구	결과물	한계
OCR	텍스트 덤프	의미를 이해하지 못한다
Summarizer	압축된 텍스트	실행 단위로 변환하지 못한다
생산성 앱	할 일 목록	수동 입력이 필요하다

우리는 정보를 이해하는 도구는 많지만, 정보를 실행하게 만드는 도구는 거의 없다.

---

3. Actonix의 접근 방식

핵심 개념

Actonix는 단순한 문서 AI가 아니다. Execution Transformation Engine이다.

문서를 읽고 요약하는 것이 목표가 아니라, 문서 안에 담긴 의도를 파악하고 실행 가능한 행동 단위로 변환하는 것이 목표다.

실행 파이프라인

Image / PDF
   ↓
OCR Extraction          — 입력을 정규화한다
   ↓
Semantic Reasoning      — 문서 유형과 맥락을 판단한다
   ↓
Intent Detection        — 해야 할 일을 추출한다
   ↓
Task Structuring        — JSON 스키마로 정형화한다
   ↓
Schema Validation       — ActionPlan 구조를 검증한다
   ↓
Schedule Transformation — 날짜·우선순위를 계산한다
   ↓
ActionPlan JSON         — 실행 가능한 결과물을 출력한다

각 단계가 독립적으로 작동하는 것이 아니라, 이전 단계의 결과가 다음 단계의 입력이 되는 연속적인 파이프라인이다. "이 문서가 무엇인가"를 판단하는 것에서 시작해서, "이 문서로부터 무엇을 해야 하는가"를 출력으로 끝낸다.

---

4. 왜 단순 프롬프트 엔지니어링이 아닌가

여기서 자연스럽게 드는 의문이 하나 있다.

"그냥 GPT한테 '할 일 정리해줘'라고 하면 되는 거 아닌가요?"

결론부터 말하면, 안정적으로 작동하지 않는다.

 

LLM은 확률 기반 생성 모델이기 때문에 동일 입력에 대해서도 출력 변동이 발생한다. 자연어 요약에서는 허용 가능한 변동이지만, 스키마 기반 시스템에서는 단 하나의 필드 누락도 치명적이다.

 

LLM에게 단순히 "할 일을 추출해줘"라고 요청하면 출력 형식이 매번 흔들린다. 어떤 때는 배열로 오고, 어떤 때는 자연어 문장으로 온다. 날짜 표현도 2026-03-10이 되기도 하고, 3월 10일이 되기도 한다. 이 상태로는 UI 렌더링이 깨지고, 일정 계산이 불가능해진다.

 

그래서 Actonix는 LLM 출력을 그대로 사용하지 않는다. 출력 이후 반드시 ActionPlan 스키마 검증 단계를 거친다. 필수 필드가 누락됐는지, 날짜 형식이 ISO 8601을 따르는지, category가 정해진 enum 안에 있는지를 전부 검사하고, 실패하면 재요청하거나 fallback 처리한다.

 

또한 Actonix는 OCR 단계와 Semantic 추론 단계를 분리했다. 이미지와 PDF는 먼저 텍스트로 정규화되고, 이후 LLM에는 정제된 텍스트만 전달된다. 이는 토큰 비용을 줄이고, 파이프라인 안정성을 확보하기 위한 설계다. 그리고 크레딧 차감은 OCR 이후가 아닌, 파싱 검증이 완료된 시점에 수행된다. 실패한 요청에 비용이 소모되지 않도록 하기 위해서다.

---

5. 기존 도구와의 비교

구분	기존 OCR	요약기	Actonix
텍스트 추출	O	O	O
의미 해석	X	부분	O
실행 변환	X	X	O
스키마 검증	X	X	O
자동 일정화	X	X	O

 

기존 도구들이 정보를 처리한다면, Actonix는 정보를 실행한다.

---

6. 핵심 차별점 — ActionPlan JSON

Actonix가 만들어내는 결과물은 단순한 요약이나 키워드 추출이 아니다. 검증된 Actionable JSON이다.

{
  "category": "공지문",  // enum: 공지문 | 과제 | 일정 | 규정 | 기타
  "title": "수행평가 제출 일정",
  "analysis": "3월 중 제출 마감이 있는 수행평가 안내문으로, 보고서 작성과 발표 준비가 필요하다.",
  "keywords": ["수행평가", "제출", "마감", "보고서"],
  "actions": [
    {
      "task": "보고서 작성",
      "due": "2026-03-08",         // ISO 8601, fallback: null
      "priority": "high",          // enum: high | medium | low
      "done": false
    },
    {
      "task": "발표 준비",
      "due": "2026-03-10",
      "priority": "medium",
      "done": false
    }
  ],
  "requirements": ["A4 5페이지 이상", "참고문헌 필수"],
  "unknowns": ["제출 플랫폼 미명시"]
}

 

unknowns 필드는 문서에서 의도는 감지됐지만 정보가 불충분한 항목을 명시한다. requirements는 조건이나 제약을 별도로 분리한다. LLM이 "모르겠으면 그냥 생략"하는 것이 아니라, 불확실성을 구조화해서 출력한다.

 

이 구조화된 출력은 캘린더, 할 일 앱, 자동화 워크플로우 어디에든 바로 연결할 수 있다.

Actonix는 inPaser 시맨틱 엔진 위에서 동작하는 Execution Layer로 설계되었다. Execution Layer는 자연어 의미 공간을 정형화된 상태 공간으로 사상(mapping)하는 계층이다. 의미를 이해하는 엔진이 inPaser라면, 그 의미를 실행으로 바꾸는 엔진이 Actonix다.

Actonix는 정보를 이해하는 AI가 아니라, 현실을 실행하게 만드는 AI다.

---

7. 현재 상태

• MVP 완료 및 베타 오픈
• OCR → Semantic Reasoning → Schema Validation → Task 파이프라인 정상 동작
• 웹 기반 인터페이스 공개
• 크레딧 시스템 운영 중 (PG 미도입)

Live: https://actonix.vercel.app

---

8. 한계와 개선 방향

현재 MVP 단계에서 확인된 한계점들도 솔직하게 공유한다.

 

일정 추출 정확도는 아직 개선이 필요하다. 날짜 표현이 복잡하거나 문서 구조가 비정형적인 경우 오인식이 발생한다. 단일 문서 처리는 안정적이지만, 다중 문서 배치 처리는 아직 미지원이다.

 

로드맵 상 단기적으로는 캘린더 자동 연동, 일정 정확도 개선, 다중 문서 처리를 목표로 하고 있으며, 중장기적으로는 API 공개와 B2B 워크플로우 자동화로 확장할 계획이다.

 

현재 Actonix는 완성형이 아니다.

 

지금 구조는 범용 LLM 기반 zero-shot 추론으로, 파이프라인의 핵심 추론을 외부 모델에 의존하고 있다. category classification의 정확도, deadline extraction의 안정성, unknowns 처리의 일관성 — 이 모든 것이 범용 모델의 한계에 묶여 있다.

 

현재 소프트웨어 마에스트로 과정 지원을 준비하고 있다. 합격 시, 연수 과정을 통해 Actonix 전용 도메인 특화 fine-tuned 모델을 직접 구축할 계획이다. category classification과 deadline extraction을 분리 학습하고, ActionPlan 스키마에 최적화된 추론 구조를 설계하여 범용 모델 의존도를 단계적으로 축소하고, 도메인 특화 모델을 핵심 추론 계층으로 전환할 계획이다. 그때 Actonix는 진짜 완성형이 된다.

---

9. 마무리

정보가 많아질수록 실행은 오히려 더 어려워진다. 무엇을 해야 하는지 판단하는 데 너무 많은 에너지가 소모된다.

Actonix는 그 판단을 AI에게 위임하자는 제안이다.

정보를 이해하는 것에서 멈추지 않고, 현실에서 실행하게 만든다.

 

Actonix는 시각적 지식을 위한 Universal Action Layer를 목표로 한다. 단순한 문서 도구가 아니라, 다음 세대 AI 생산성 시스템의 실행 엔진으로.