커스텀 웹 클리핑 구축기 2 - 과욕은 금물이다

# 🖥️ 커스텀 웹 클리핑 구축기 2 - 과욕은 금물이다

## 🤦‍♂️ 소개

안녕하세요! 지난번에 GPters 전용 클리핑 도구를 만들었더니, 
마음 한편에 아쉬움이 남더라고요. 
"이거 GPters만 되네? 다른 사이트도 클리핑하고 싶은데..." 

1편 : https://www.gpters.org/dev/post/my-own-web-clipper-Wv5zLAi2QJ41TWq

그래서 이번엔 **범용 웹 클리핑 도구**를 만들어보기로 했습니다! 🚀


### 이번 목표는 욕심쟁이 버전이었어요:
- ✅ 어떤 웹사이트든 클리핑 가능하게
- ✅ LLM 요약까지 자동으로
- ✅ Reference 폴더에 저장 + 일간노트에 3줄 요약&백링크 연결
- ✅ 완벽한 자동화!

보기만 해도 야무진 계획이죠? 근데... 결론부터 말하면 **"과욕은 금물"**이라는 교훈을 얻었습니다. 😅

## 🔥 개발 과정: 꿈과 현실 사이

### 1단계: 장밋빛 계획 수립

처음엔 정말 간단해 보였어요:

```
URL 입력 → 사이트 감지 → 맞춤 크롤링 → LLM 요약 → Obsidian 저장 → 완료!
```

"어? 이거 금방 되겠는데?" 싶었죠. 하지만 현실은...

### 2단계: 첫 번째 문제 - 사이트별 차이

각 웹사이트마다 HTML 구조가 다르다 보니, 사이트별로 JSON 설정을 만들어야 했어요:

```json
{
  "sites": {
    "gpters.org": {
      "name": "GPters",
      "selectors": {
        "title": ["h1", "title"],
        "content": ["main", "[class*='content']", "[class*='post']", "[class*='article']", ".post-content"]
      },
      "waitOptions": {
        "waitUntil": "domcontentloaded",
        "timeout": 60000
      },
      "keywords": ["[[GPters]]", "[[커뮤니티 16기]]", "[[AI 커뮤니티]]"],
      "enabled": true
    },
    "naver.com": {
      "name": "네이버",
      "selectors": {
        "title": ["h1", "h2", ".title", "title"],
        "content": [".news_content", ".se-main-container", "#articleBody", ".article_body", "main", "article"]
      }
    }
  }
}
```

보기만 해도 복잡하죠? 😵

### 3단계: GPters 전용 프롬프트의 함정

더 큰 문제는 GPters에 특화된 LLM 프롬프트였어요:


```javascript
// ❌ GPters 전용 프롬프트가 없음!
// if (url.includes('gpters.org')) { ... }

// 기존 일반 사이트 프롬프트 (GPters도 여기 사용)
return `당신은 IT 개발 분야의 전문 콘텐츠 큐레이터입니다`;
```

"아, 이거 GPters에만 맞춰져 있네..." 🤦‍♂️

### 4단계: 해결책 구현

뭔가 대단한 해결책을 찾은 줄 알았어요:

**📋 코드베이스 아키텍처 분석**

🏗️ **다중 사이트 처리 구조:**

1. **URL 입력** → `detectSiteConfig()` → **사이트 감지**
2. **사이트별 설정 로드** → `handleSpecialSite()` → **크롤링**  
3. **사이트별 프롬프트** → `generateSiteSpecificPrompt()` → **요약**
4. **일간노트 저장** → **백링크 파일 생성**

**✅ 지원 사이트별 특화 처리:**

- 🔗 **GPters**: AI 커뮤니티 개발자 관점 (신규 추가!)
- 🥞 **브런치**: 감성적 에세이 관점
- 🔧 **GitHub**: 오픈소스 기술 관점  
- 📰 **네이버**: 뉴스 정보 관점
- 📺 **YouTube**: 동영상 학습 관점
- 📝 **Medium**: 아티클 블로그 관점
- 🌐 **기타**: 일반 사이트 관점

"이제 GPters 게시글이 전용 프롬프트로 정확하게 클리핑됩니다!"

### 5단계: 현실의 벽

그런데 막상 테스트를 해보니... 💥

**❌ 문제 발견: GPters 전용 프롬프트 누락**

```
💡 🔍 코드베이스 전체 분석 결과

Difficulty: Mid
Learning Keywords: 사이트 감지, 도메인 매칭, 프롬프트 생성, 다중 사이트 처리

🧐 문제 발견 및 분석
❌ 핵심 발견: GPters URL은 올바르게 감지되고 있으나, GPters 전용 프롬프트가 없습니다!
```

"매우 충미로운 절과입니다! 테스트 결과를 보면 GPters URL은 올바르게 감지되고 있습니다. 그런데만 실제 사용 시에 왜 일반 사이트로 처리되는지 확인해보겠습니다."

### 6단계: 더 큰 문제들의 연쇄 반응

#### 문제 1: Node.js 다중 서버 실행 이슈 🔥

클리핑 실패가 발생하는데, 터미널에서는 정상 처리로 표시되어서 디버깅이 정말 어려웠어요.

**가설**: Node.js 서버 동시 실행 문제일까?

그래서 PM2 라이브러리를 설치해봤어요:

```bash
PS C:\Users\audrmn\OneDrive\Gpters_16_Cursor\Gpters_16_Obsidian_Clipping> npm install -g pm2

added 135 packages in 4s
13 packages are looking for funding
  run `npm fund` for details
```

#### 문제 2: 환경변수 설정과 라이브러리 설치의 늪 💀

**구현 완료된 해결책들:**

✅ **1. PM2 프로세스 매니저**
- 전문적인 Node.js 애플리케이션 관리
- 단일 인스턴스 보장으로 중복 프로세스 방지  
- 자동 재시작, 메모리 관리, 로그 관리
- 프로덕션 환경에 최적화

✅ **2. 스마트 시작 스크립트**
- 포트 충돌 자동 감지 및 해결
- 기존 프로세스 자동 정리
- PID 파일 관리로 프로세스 추적
- 우아한 종료 처리

✅ **3. package.json 스크립트 최적화**
- 다양한 시나리오별 실행 명령
- 개발/프로덕션 환경 분리  
- 문제 해결을 유틸리티 명령
- 

하지만 환경변수 설정 및 라이브러리 설치 과정에서 어려움을 계속 경험했어요... 😵‍💫

## 💡 깨달음의 순간들

### 1. 범위 설정의 중요성 🎯

개인용 커스텀 툴 개발이 목적이라 무한대의 가능성을 상정한 것이 패착이었어요.

**❌ 잘못된 접근:**
- "모든 웹사이트를 클리핑하자!"
- "사이트별 맞춤 요약도 다 만들자!" 
- "완벽한 자동화를 구현하자!"

**✅ 올바른 접근:**
- 핵심 기능 몇 개에 집중
- 자주 사용하는 사이트 2-3개만 우선 지원
- 점진적 확장

### 2. 디버깅 체계의 중요성 🔍

초기에 디버깅 로그 확인 기능이 없어서 문제 해결이 정말 오래 걸렸어요.

**❌ 문제점:**
- 에러가 발생해도 어디서 문제인지 모름
- 정기적인 백업 부재로 문제 대응 능력 저하
- 로그 시스템 없어서 디버깅 지옥

**✅ 교훈:**
- 처음부터 로깅 시스템 구축하기
- 단계별 체크포인트 만들기  
- 버전 관리 철저히 하기

### 3. 복잡성 관리 🤯

웹사이트별 맞춤 요약 프롬프트 설정의 비효율성을 뼈저리게 느꼈어요.

**현실:**
- 소수의 사이트에도 개별 LLM 프롬프트 관리가 과도하게 복잡해짐
- 각 사이트마다 JSON 엘리먼트를 일일이 코딩하는 비효율 발생
- n8n, Make 같은 기존 도구 활용의 장점을 재인식

### 4. 코드 구조화의 중요성 🏗️

체계적인 계획 없이 기능을 추가하다 보니 코드베이스 품질이 저하됐어요.

최종적으로는 이렇게 복잡한 프로젝트 구조가 되어버렸네요... 😅

## 🎓 주요 교훈들

### 1. **과욕은 금물** 
작은 범위에서 완성도 높은 기능 구현이 훨씬 중요해요.

### 2. **핵심 기능 우선**
불필요한 복잡성보다 핵심 기능에 집중하는 게 현명해요.

### 3. **체계적 접근**  
계획적인 개발로 유지보수 가능한 코드베이스를 구축해야 해요.

### 4. **기존 도구의 가치**
처음부터 모든 걸 만들려고 하지 말고, n8n이나 Make 같은 검증된 도구의 활용도 고려해야 해요.

## 🔮 다음 프로젝트에서는...

이번 경험을 바탕으로 다음엔 이렇게 접근할 예정이에요:

- **🎯 명확한 범위 설정**: "GPters + 네이버 뉴스만 우선 지원"
- **📝 단계별 개발**: MVP부터 시작해서 점진적 확장  
- **🔍 디버깅 우선**: 로깅 시스템부터 구축
- **📚 기존 도구 활용**: 완전 커스텀보다는 기존 솔루션 조합

## 💬 마무리

솔직히 이번 프로젝트는 "실패"라고 볼 수도 있어요. 처음 목표했던 "범용 웹 클리핑 도구"는 완성하지 못했거든요.

하지만 **정말 많은 걸 배웠어요**:
- 프로젝트 범위 설정의 중요성
- 체계적인 개발 프로세스의 필요성  
- 디버깅 시스템의 중요성
- 기존 도구들의 가치

무엇보다 "완벽한 걸 만들려고 하지 말고, 작동하는 걸 먼저 만들자"는 마인드를 갖게 됐어요.

### 🤔 여러분은 어떠신가요?

비슷한 경험 있으시나요? 개발 과정에서 "이거 간단할 줄 알았는데..." 하면서 늪에 빠진 적 있으신지 궁금해요!

댓글로 여러분의 시행착오 경험담도 공유해 주세요. 서로의 실패담을 나누다 보면 더 나은 개발자가 될 수 있을 것 같아요! 😊

---

**🏷️ 태그:** #개발일기 #시행착오 #웹클리핑 #Node.js #교훈 #과욕금물