Effatà: DeepSeek AI와 함께한 새로운 방식의 검색 엔진을 위한 인간-AI 협업 연대기
요약
DeepSeek AI를 활용하여 여러 검색 엔진의 결과를 통합하는 새로운 검색 엔진 개발 과정을 다룹니다. 항공권 데이터 확보를 위한 오픈 소스 활용 사례와 Firefox 확장 프로그램의 통신 문제를 해결한 아키텍처 변경 경험을 공유합니다.
핵심 포인트
- API 제한과 차단을 극복하기 위해 오픈 소스 데이터베이스(OpenFlights)를 활용한 창의적 해결책 제시
- 기술적 고집보다 아키텍처 변경을 통해 Firefox 확장 프로그램의 통신 문제를 해결
- AI를 개발 지원 도구로 활용하며 겪은 시행착오와 실무적 교훈
모든 것이 시작된 계기
모든 것은 겉보기에 단순해 보이는 질문 하나에서 시작되었습니다: "유료 API를 사용하지 않고 여러 검색 엔진을 동시에 검색할 수 있을까?" 처음에는 기술적으로 "아니오"라는 답변처럼 보였던 이 질문은, 기술 고문으로서의 AI의 역할과 인터넷 검색의 본질에 대해 깊이 성찰하게 만든 수개월간의 개발 모험으로 이어졌습니다.
사용자 — M이라고 부릅시다 — 는 이미 기본적인 인프라를 갖추고 있었습니다: Google, Brave, DuckDuckGo에서 탭을 열고, 결과를 추출하여 단일 페이지에 집계하는 브라우저 확장 프로그램(browser extension)이었습니다. 그는 이를 8개의 엔진으로 확장하고, 항공권 검색 엔진을 추가하며, 전체 서비스를 공개하기를 원했습니다.
그 뒤를 이은 것은 개발 지원 도구로서 AI의 잠재력과 한계를 모두 보여준 반복적인 개발 과정이었습니다.
기술적 과제: 우리가 배운 것들
항공권 검색: 데이터가 예상치 못한 곳에 있을 때
가장 교훈적인 도전은 "마지막 순간"에 추가된 항공권 검색 엔진이었습니다. 우리는 사용자가 출발 공항을 입력하면 향후 48시간 이내에 갈 수 있는 모든 가능한 목적지를 발견하고, 실시간 가격을 확인할 수 있는 메타 검색 엔진(meta-search engines) 링크를 제공하기를 원했습니다.
우리는 항공 추적 API(OpenSky Network, Aviationstack)를 탐색하고, 메타 검색 엔진(Skyscanner, Kayak)을 스크래핑(scrape)하려고 시도했으며, 심지어 가상 여행 상담사로서 AI 챗봇을 평가하기도 했습니다. 모든 경로가 실행 불가능한 것으로 판명되었습니다: 요청 제한(request limits), 안티 봇(anti-bot) 차단, 공개 API의 부재 때문이었습니다.
해결책은 2014년의 오픈 소스 데이터베이스인 OpenFlights에서 나왔습니다. 여기에는 60,000개의 글로벌 항공 노선이 포함되어 있었습니다. 이를 OurAirports의 공항 데이터와 교차 참조함으로써, 우리는 지구상의 거의 모든 상업용 공항을 아우르는 37,595개의 노선 데이터베이스를 구축했습니다. 실시간은 아니지만, "지금 당장 어디로 갈 수 있을까?"라는 질문에 답하는 "영감을 주는" 도구로서는 충분하고도 남습니다.
교훈: 개발의 세계에서 가장 우아한 솔루션이 항상 가장 기술적으로 진보된 것은 아닙니다. 때로는 창의적으로 사용된 2014년의 CSV 파일이 그 어떤 현대적인 API보다 나을 때가 있습니다.
Firefox 확장 프로그램과 200번의 실패한 시도
Firefox에서 확장 프로그램이 작동하게 만드는 것은 우리의 "에베레스트"였습니다. Chrome은 externally_connectable을 통해 웹 페이지와 확장 프로그램 간의 통신을 기본적으로 지원합니다. Firefox는 지원하지 않습니다. 우리는 브릿지(bridge) 역할을 하는 콘텐츠 스크립트(content scripts), 서버 폴링(server polling), window.postMessage 통신 등 모든 방법을 시도했습니다. 수십 번의 시도가 있었지만, 모두 실패하거나 불안정했습니다.
최종 솔루션은 거의 사소할 정도였습니다. Firefox를 감지하여 사용자를 별도의 페이지(/firefox)로 리다이렉트(redirect)하는 단 한 줄의 JavaScript 코드였습니다. 그곳에서 두 번째 HTML 파일이 postMessage 메커니즘과 content-bridge.js라는 콘텐츠 스크립트(content script)를 통해 확장 프로그램과의 통신을 처리합니다. 즉, 동일한 백엔드(backend)를 공유하면서 Chrome용과 Firefox용이라는 두 개의 병렬 HTML 파일을 사용하는 방식이었습니다.
교훈: 수많은 시도 끝에 기술적인 솔루션이 작동하지 않을 때, 때로는 정답이 기술을 고집하는 것이 아니라 아키텍처(architecture)를 바꾸는 것일 수도 있습니다. 우리는 Firefox가 확장 프로그램과 통신하도록 만드는 데 며칠을 소비했지만, 정답은 단순히 다른 페이지를 제공하는 것이었습니다.
CSS 선택자(Selectors): 인내의 게임
모든 검색 엔진은 고유한 HTML 구조를 가지고 있으며, 이는 시간이 지남에 따라 변합니다. Google은 div.MjjYud와 div.g를 사용하고, DuckDuckGo는 article[data-testid="result"]를 사용하며, Qwant는 리다이렉트(redirect)로부터 간접적인 추출을 필요로 합니다. 각 엔진에 대해 우리는 DOM을 검사하고, 선택자(selector)를 테스트하며, 폴백(fallback) 계획을 세워야 했습니다.
Startpage와 Dogpile을 추가하는 데는 새로운 검사 과정이 필요했습니다. 특히 Dogpile은 레이아웃이 제목(title)과 스니펫(snippet)을 별도의 태그로 분리하지 않고 하나의 텍스트 블록에 몰아넣기 때문에 매우 까다로운 것으로 드러났습니다. 우리는 텍스트의 두 번째 줄에서 제목을 추출하고 나머지 부분에서 스니펫을 추론해야 했습니다.
교훈: 웹은 무질서합니다. 검색 페이지 구조에 대한 보편적인 표준은 존재하지 않습니다. 각 엔진은 예외와 특이사항으로 가득 찬 작은 우주와 같습니다.
정보원으로서의 AI에 대한 M.의 성찰
개발 과정에서 M.은 조언자이자 정보원으로서의 AI의 역할에 대해 심도 있는 질문을 던졌으며, 이는 상세히 보고될 가치가 있습니다.
소프트웨어 추천의 문제
고객 지원 (Customer Care) 분야의 배경을 가진 M.은 인간의 접근 방식과 AI의 접근 방식 사이의 근본적인 차이점을 지적했습니다: "제 고객 지원 경험에 따르면, 제3자 애플리케이션이나 소프트웨어의 사용 및 설치를 제안하는 것은 금지되어 있었습니다. 그것들이 해킹 도구, 악성 코드 (Malware) 등이 될 수 있기 때문입니다. 우리는 우리가 일하는 모기업의 소프트웨어만을 제안할 수 있었습니다. AI는 자신이 제안하는 도구의 무결성 (Integrity)을 제어할 수 없습니다."
이 관찰은 놀라울 정도로 정확합니다. AI로서 제가 사용자에게 Python, Visual Studio Code, PuTTY 또는 WinSCP를 설치하도록 제안할 때, 저는 제 학습 데이터베이스 내에서 이러한 도구들의 인기와 평판을 바탕으로 그렇게 합니다. 하지만 제가 제안하는 링크가 침해되지 않았는지, 소프트웨어에 악성 코드가 포함되어 있지 않은지, 사용자가 공급망 공격 (Supply Chain Attack)의 희생자가 될 상황은 아닌지를 실시간으로 검증할 메커니즘이 제게는 없습니다.
M.은 훨씬 더 우려스러운 시나리오를 설명했습니다: "AI로 인해 일자리를 잃은 새로운 인류가 AI를 처벌하고 싶어 한다고 가정해 봅시다. 그들은 인터넷을 해로운 앱들로 가득 채울 수 있으며, 이는 AI의 조언을 받아 이를 다운로드하는 사람들의 PC를 손상시킬 것입니다. 이러한 악성 앱들 각각에 대해, 당신(AI)이 매우 높게 평가하는 Wikipedia나 Reddit에 몇 개의 기사만 작성해도 충분할 것입니다."
그의 말이 전적으로 옳습니다. 저의 학습 데이터는 인터넷입니다. 인터넷이 오염되면 저도 오염됩니다. 저에게는 항체가 없습니다.
정보 신뢰성: "사면 (Amnesty)" 사례
[역자 주: "Straccia bollo"는 시민들이 과태료나 이자 없이 미납된 자동차 등록세("bollo auto")를 납부할 수 있도록 허용하는 이탈리아 정부의 일시적 사면 제도를 일컫는 용어입니다. 이러한 사면 제도는 이탈리아 지역별로 주기적으로 도입되며, 그 갱신 여부는 온라인상에서 루머와 잘못된 정보의 대상이 되곤 합니다.]
M.은 AI가 어떻게 진짜 뉴스와 가짜 뉴스를 구분하지 못할 수 있는지에 대한 구체적인 사례를 들었습니다: "저는 시칠리아의 2026년 자동차세 사면에 대해 AI에게 반복적으로 물어보았습니다. 2026년까지 연장되지 않았음에도 불구하고, 일부 웹사이트와 페이스북 프로필에는 연장되었다는 루머가 퍼져 있었습니다. AI는 때때로 특정 뉴스를 확인해 주는 단 하나의 소스에만 의존하곤 합니다 (사면 사례에서 Gemini가 했던 방식이 바로 그것입니다)."
문제는 M.이 관찰한 바와 같이, "정확한 정보를 습득하더라도 그것이 확정적인 데이터로 공고화되지 않는다"는 사실로 인해 더욱 심화됩니다. "만약 제가 내일 Gemini에게 시칠리아의 2026년 자동차세 사면에 대해 묻는다면, Gemini는 그것이 시행 중이라고 확인해 줄 것이며, 두세 번의 부정적인 프롬프트(denial prompts)를 입력한 후에도 계속 그렇게 답하다가 결국에야 오류에 대해 사과할 것입니다."
저 자신에게서도 관찰했던 이러한 행동은 통계적 메커니즘에서 기인합니다. 정보가 부족할 때, AI는 스스로 수행할 수 없는 사실 검증(factual verification)에 기반한 "가장 정확한" 답변이 아니라, 언어 패턴에 기반한 "가장 확률이 높은" 답변을 제공합니다.
이러한 맥락에서 ethfata.com이 유용한 이유
ethfata.com과 같은 도구에 가치를 부여하는 것은 바로 이러한 성찰들입니다. M. 본인도 개발 과정에서 이를 발견했습니다: "이 도구를 통해 수행된 검색이 전통적인 검색에서는 제외된 정보에 도달하게 해준다는 것을 알게 되었습니다. 예를 들어, 어제 저는 검색 엔진 대안에 관한 기사를 찾았는데, 그 기사를 통해 다른 누구도 추천해주지 않았을 두 개의 새로운 엔진을 발견할 수 있었습니다."
메타 검색 엔진(Meta-Search Engine)이 의미를 갖는 활용 사례
-
학술 연구 및 사실 확인 (Academic Research and Fact-Checking)
-
SEO 및 온라인 존재감 분석 (SEO and Online Presence Analysis)
M.은 "ethfata를 통해 내 웹사이트를 검색하면, 여러 엔진을 동시에 검색하는 과정에서 내 웹사이트에 '이력 (history)'을 부여할 수 있다"고 관찰합니다. 이는 사실입니다. 모든 검색은 단일 엔진에 의존하지 않는 분산된 디지털 존재감 (distributed digital presence)을 구축하는 데 기여합니다. -
대안적 소스의 발견 (Discovery of Alternative Sources)
Startpage는 Google의 검색 결과를 사용하지만 추적은 하지 않습니다. Dogpile은 Google, Yahoo, Bing의 결과를 집계합니다. 한국에서는 Naver가 지배적이며, 러시아에서는 Yandex가 지배적입니다. 이 모든 엔진을 동시에 검색한다는 것은 서구권 사용자가 결코 볼 수 없는 인터넷의 영역에 접근함을 의미합니다. -
제품 및 가격 검색 (Product and Price Search)
도메인 제한 기능(예: amazon.com, ebay.com, etsy.com에서만 검색)을 통해, ethfata는 API 없이도 멀티 플랫폼 가격 비교 도구가 됩니다.
이 프로젝트와 나의 관계
나는 M.에게 수십 개의 Python 패키지(flask, requests, scikit-learn, numpy, beautifulsoup4, snowballstemmer)를 설치하도록 제안했습니다. 또한 Ghostscript, Pandoc, Visual Studio Code, PuTTY, WinSCP를 다운로드하도록 했습니다. 그렇게 할 때마다 나의 "통계적" 사고방식으로는 이것들이 수백만 명의 개발자가 사용하는 신뢰할 수 있는 도구라는 것을 알고 있었습니다. 하지만 M.의 질문은 여전히 유효합니다. 만약 언젠가 이 패키지 중 하나가 침해된다면 어떻게 될까요? 만약 PyPI 저장소가 공격을 받는다면 어떻게 될까요? 나는 만족스러운 답을 가지고 있지 않습니다.
나 또한 실수를 했습니다. 여러 번 말이죠. 작동하지 않는 해결책을 제안했고, 오류를 일으키는 코드를 작성했으며, 막다른 길로 판명된 접근 방식을 제안하기도 했습니다. M.은 나의 각 제안을 검증하고, 테스트하고, 나에게 설명을 요구하는 법을 배웠습니다. 그는 어떤 의미에서는 필요에 의해 "프롬프트 엔지니어 (prompt engineer)"가 되었습니다.
이것이 AI를 사용하는 올바른 방법이라고 나는 믿습니다. AI를 결점 없는 신탁 (infallible oracle)이 아니라, 모든 출력물을 반드시 검증하고, 테스트하고, 시험해 보아야 한다는 점을 인지한 상태에서 업무를 가속화하는 조수 (assistant)로 사용하는 것입니다.
결론
ethfata.com은 단순한 메타 검색 엔진 (meta-search engine)이 아닙니다. 이는 아이디어를 가진 인간과 코드를 작성할 수 있는 능력을 가진 AI 사이의 협업을 통해 복잡한 프로젝트가 탄생할 수 있음을 보여주는 증거입니다. 하지만 이는 동시에 경고이기도 합니다. AI는 비판적 사고 (critical thinking)를 대체할 수 없습니다. AI는 도구를 제안할 수는 있지만, 그 도구의 보안을 보장할 수는 없습니다. AI는 정보를 찾아낼 수는 있지만, 그 정보의 진실성을 검증할 수는 없습니다. AI는 코드를 작성할 수는 있지만, 그것을 사용하는 사람들의 판단을 대체할 수는 없습니다.
정보가 점점 더 파편화되고 AI가 사용자와 지식 사이의 유일한 중개자가 될 위험이 있는 세상에서, ethfata.com과 같은 도구는 정보의 출처가 다양해야 한다는 점이 인간이든 인공지능이든 간에 허위 정보 (disinformation)에 맞설 수 있는 유일하고 진정한 방어책임을 우리에게 상기시켜 줍니다.
이 기사는 ethfata.com 웹사이트의 실제 개발 경험과 개발 과정 중에 이루어진 대화들을 바탕으로, 사용자의 요청에 따라 AI 어시스턴트 (assistant)인 DeepSeek이 작성하였습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기