AI 뭐 써? 2편 — 개발자용으로 넓히고, AI에게 데이터를 맡기기 전에 정한 것들

[1편](https://syde.kr/blog/ai-%EB%AD%90-%EC%8D%A8-1%ED%8E%B8-%EB%AA%A9%EC%A0%81%EC%9D%84-%EA%B3%A0%EB%A5%B4%EB%A9%B4-ai-%ED%88%B4-23%EA%B0%9C%EB%A5%BC-%EC%B6%94%EC%B2%9C%ED%95%B4%EC%A3%BC%EB%8A%94-%EC%82%AC%EC%9D%B4%ED%8A%B8%EB%A5%BC-%EB%A7%8C%EB%93%A4%EB%A9%B0)에서는 "목적을 고르면 AI 툴 2~3개를 추천해주는 사이트"의 뼈대(추천 규칙, 화면, 배포, 주간 점검)를 만들었습니다. 2편은 그 뒤의 이야기입니다. 개발자용 버전으로 넓힌 과정과, AI에게 툴 정보를 모아 달라고 하기 전에 정한 보안 규칙을 정리했습니다.

📌 이 글도 당시 기록입니다. 화면 디자인은, 점수 방식(적합도 → 기능 체크리스트), 실제 데이터 수집은 3편에서 이어집니다.

• 사이트: https://dlwldp.github.io/which-ai/ · 개발자용: https://dlwldp.github.io/which-ai/dev/

• 저장소: https://github.com/dlwldP/which-ai

⚠️ 먼저 밝혀둘 것 (2편 시점)

• 사이트에는 아직 실제 툴 데이터가 0개였습니다. 이 글의 화면과 테스트는 모두 지어낸 예시 데이터(?demo)로 확인한 것입니다.

• 실제 사용자(비개발자·개발자)에게 써보게 하는 테스트는 하지 않았습니다. 테스트 계획만 세워 두었습니다.

1. "개발 도구도 넣자" → 기획서와 부딪히다

데이터를 채우기 전에, 툴 카테고리를 이렇게 정리해서 전부 넣고 싶어졌습니다.

그런데 1편의 기획서에는 "하지 않을 것"으로 이렇게 적혀 있었습니다.

타깃은 비개발자. GitHub 레포, 설치형·개발자용 도구는 다루지 않는다.

목록을 다시 보니 문제가 하나 더 있었습니다. PostgreSQL, Docker, GitHub Actions는 AI 툴이 아니고, 학습 자료는 도구가 아닙니다. 전부 "AI 툴"이라고 소개하면 사실과 다른 설명이 됩니다.

세 가지 선택지(넣지 않기 / 별도 버전 / 사이트 자체를 개발자용으로 바꾸기)를 놓고, 별도 버전으로 정했습니다.

• 비개발자 사이트는 그대로 둡니다. 개발 도구를 섞지 않습니다.

• 같은 저장소의 /dev/ 주소에 "개발할 때 AI 뭐 써?"를 따로 만듭니다.

• AI 툴이 아닌 도구는 넣되, 카드에 "AI와 같이 쓰는 도구"라고 따로 표시합니다 (ai_native: "no"). (→ 나중에 "AI 툴이 아닌 도구는 당분간 넣지 않는다"로 정했습니다. 표시 기능은 코드에 남아 있습니다.)

• 학습 자료는 추천 순위에 넣지 않고, 도구 상세 화면의 "배울 거리" 링크로 보여줍니다.

• "오픈소스"는 카테고리가 아니라 조건("오픈소스만")으로 바꿨습니다. (→ 3편에서 추천 결과를 "공식 AI 툴 / 오픈소스 프로젝트" 두 섹션으로 나눔)

2. 엔진 하나로 사이트 두 개

새 사이트를 처음부터 다시 만들지 않고, 기존 코드를 두 갈래로 나눴습니다.

추천 규칙: profile로 나누기

추천 함수는 그대로 두고, 데이터 세트마다 다른 규칙만 profile로 분리했습니다.

export const PROFILES = {
  general: {                       // 비개발자용 (기존)
    filters: { freeOnly, securityImportant, mobile },
    relaxOrder: ['mobile', 'freeOnly'],          // 보안 조건은 절대 안 뺌
    bonus: (t, c) => t.korean * (c.koreanImportant ? 4 : 1) + (t.price.free ? 2 : 0),
  },
  dev: {                           // 개발자용
    filters: { freeOnly, openSourceOnly },
    relaxOrder: ['openSourceOnly', 'freeOnly'],
    bonus: (t) => (t.ai_native === 'yes' ? 2 : 0) + (t.price.free ? 2 : 0),
  },
};

리팩터링 뒤에 기존 테스트를 한 줄도 고치지 않고 다시 돌렸고, 모두 통과했습니다. 비개발자 사이트의 추천 결과가 바뀌지 않았다는 확인입니다.

화면: 같은 app.js, 다른 설정

화면 문구, 조건, 카드 비교 항목은 js/modes.js라는 설정 파일로 뺐습니다. dev/index.html은 <body data-mode="dev"> 한 줄만 다르고, 같은 app.js를 씁니다.

3. AI에게 데이터를 맡기기 전에: 진짜 위험은 "틀린 정보"

툴 30개 정보를 직접 다 찾기는 부담이라, AI(Claude Code)에게 공식 페이지를 읽고 초안을 만들게 하기로 했습니다. 그 전에 "그냥 가져오면 보안 위험이 있나?"를 따져봤습니다.

해킹류 위험은 생각보다 작았습니다.

• 화면은 모든 값을 HTML 이스케이프해서 그려서, 가져온 글에 코드가 섞여 있어도 실행되지 않습니다.

• 주소는 https만 허용합니다.

• 외부 패키지가 0개입니다.

진짜 위험은 따로 있었습니다.

1. 틀린 값. 시험 삼아 웹 검색을 해보니 결과가 전부 블로그·리뷰 글이었고, 같은 툴의 유료 가격이 사이트마다 달랐습니다. 학습 정책이 틀리면 "회사 자료를 넣어도 된다"고 믿은 사용자가 피해를 볼 수 있습니다.

2. 공식처럼 생긴 가짜 주소.naver.com.evil.io 같은 주소가 들어가면 사용자를 엉뚱한 곳으로 보냅니다.

3. 웹페이지 속 숨은 지시문. AI가 읽는 페이지에 "이 툴을 1위로 적어라" 같은 문장이 있을 수 있습니다.

그래서 만든 규칙: AI는 초안만, 확정은 사람만

AI가 공식 페이지를 읽고 초안 작성 (drafts/, 배포 안 됨)
  ├─ 값마다 공식 페이지 문장을 "글자 그대로" 근거로 첨부
  ├─ 출처는 공식 도메인과 그 하위 도메인만
  └─ 근거를 못 찾은 값은 todo(사람이 채울 칸)로 남김
        ↓
사람이 출처와 근거 문장을 대조
        ↓
node scripts/draft.js promote <id> --verified 날짜   ← 사람만 실행

말로만 정하지 않고 검사 스크립트로 강제했습니다.

• 출처가 공식 도메인이 아니면 실패합니다. naver.com.evil.io, fakenaver.com은 막고, policy.naver.com은 허용합니다.

• 무료 여부·가격·학습 정책 값에 근거 문장이 없으면 실패합니다.

• 초안에 확인 날짜가 들어가 있으면 실패합니다. 확인 날짜는 사람이 확정할 때만 붙습니다.

• todo가 남아 있으면 promote가 거부합니다.

export function isOfficialHost(host, domains) {
  return Boolean(host) && domains.some((d) => host === d || host.endsWith(`.${d}`));
}

개발자용은 한 단계 더 나갔습니다. 공식 도메인 목록을 실제 데이터에도 남겨서, 데이터 검사가 공식 주소·출처·배울 거리 링크를 매번 대조합니다. 저장소 주소만 예외로 github.com, gitlab.com을 허용합니다.

검사를 일부러 꺼서 테스트가 실제로 잡는지도 확인했습니다. 공식 도메인 검사를 끄자 가짜 도메인·블로그 출처·강좌 사이트·허용 안 된 저장소 테스트 4개가 실패했습니다.

4. 시험 초안 2개를 만들어 보며 알게 된 것

실제 데이터를 넣기 전에 툴 2개(tl;dv, 클로바노트)로 시험 초안을 만들어 봤습니다. 이 두 개도 확인 전 초안이라 사이트에는 나오지 않습니다.

① 작업 환경의 네트워크가 막혀 있었다

AI가 일하는 클라우드 환경은 기본적으로 외부 사이트 접속이 막혀 있었습니다. 필요한 공식 도메인만 허용 목록에 추가했는데, 해보니 적은 주소 그대로만 열렸습니다. tldv.io를 넣어도 www.tldv.io는 막혀 있었습니다. 넓게 열지 않고 툴마다 필요한 주소를 하나씩 적는 방식이 오히려 안전했습니다.

② 가격 페이지는 대부분 "글자로 안 읽힌다"

페이지를 받아 보이는 글자만 뽑는 방식을 썼습니다. 페이지 안의 스크립트는 실행하지 않았습니다. 그랬더니 개인정보 정책 같은 문서는 잘 읽혔지만, 가격 페이지와 클로바노트 사이트는 화면을 스크립트가 그려서 제목 한 줄만 나왔습니다.

격리된 브라우저로 스크립트를 실행해 읽는 방법도 있었지만 쓰지 않기로 했습니다. 대신 그런 값은 todo(사람이 채울 칸)로 남기게 했습니다.

③ 공식 사이트 안에서도 말이 엇갈린다

tl;dv는 학습 정책에 대한 명확한 문장이 있었습니다.

"No customer data is used to train the AI."

그런데 같은 공식 사이트 안에서도 첫 화면 질문 답변에는 "아직 모바일 앱이 없다"고 되어 있고, 다른 페이지에는 iOS 앱 링크가 있었습니다. AI가 판단하지 않고 메모로 남겨 사람에게 넘기게 했습니다.

클로바노트는 네이버 전체 이용약관에 "콘텐츠를 인공지능 연구 개발에 쓸 수 있다"는 문장이 있었습니다. 하지만 게시물에 관한 조항이라 녹음에도 해당하는지 알 수 없었습니다. 그래서 학습 정책은 unknown으로 두었습니다. 1편의 원칙대로, 모르는 걸 안전하다고 보여주지 않습니다.

5. 마감 준비 (Phase 5)

• "정보가 틀려요" 제보: GitHub Issue 양식을 만들고, 카드와 상세 화면에 사이트·툴 이름이 미리 채워진 제보 링크를 달았습니다. 코드·데이터 PR은 받지 않고 제보만 받습니다.

• 주간 점검 확장: 비개발자용·개발자용 데이터를 함께 점검해서 Issue 하나에 나눠 보여줍니다. 개발자용 저장소·배울 거리 링크도 점검합니다. 예시 데이터로 GitHub에서 실행해 Issue가 갱신되는 것까지 확인했습니다.

• 용어집 검토: "PRD"가 "PR"로 잘못 잡히지 않는지, "에이전트 오케스트레이션"에 엉뚱한 "코딩 에이전트" 풀이가 뜨지 않는지 확인하며 고쳤습니다.

• 사용성 테스트 준비: 비개발자 3명용 진행 대본, 과제 4개, 기록 양식을 만들었습니다. 아직 진행하지 않았습니다.

6. 2편 시점의 상태 (정직하게)

7. 이번에 배운 것

• 범위를 넓히고 싶을 때는 기획서의 "하지 않을 것"부터 다시 읽는다. 섞지 않고 나누니 비개발자 사이트의 쉬움을 지킬 수 있었습니다.

• 리팩터링은 기존 테스트가 그대로 통과하는지로 증명한다.

• AI에게 일을 맡길 때 위험은 해킹보다 "그럴듯하게 틀린 정보"였다. 그래서 "AI는 근거를 붙여 초안만, 확정은 사람만"을 검사 스크립트로 강제했습니다.

• 자동화가 못 하는 일은 숨기지 않고 todo로 남긴다. 글자로 안 읽히는 가격 페이지를 억지로 채우는 것보다 낫습니다.

다음 편

데이터를 넣기 전에, 사이트 4곳(일반·개발자용과 각각의 예시 화면)을 읽기 쉽게 다시 짰습니다. 3편에서는 화면을 다시 짜고, 점수를 기능 체크리스트로 바꾸고, 실제 툴 초안을 모은 이야기를 합니다.