당신이 버린 Python의 가장 강력한 도구들 – 우리가 그것들을 사용해 AI를 구축했습니다

서론

AI 산업은 마치 지능이 모델로 시작하고 끝나는 것처럼, 끊임없이 새로운 프레임워크를 찾아 헤매고 있습니다. 하지만 LLM(대규모 언어 모델)은 워크플로우를 클릭하거나, 까다로운 인터페이스를 검사하거나, 모든 시각적 세부 사항을 스스로 신뢰성 있게 이해할 수는 없습니다. 유용한 작업을 수행하려면, 세상과 상호작용할 수 있는 도구가 필요하며—Python은 오랫동안 그러한 도구들을 보유해 왔습니다.
Selenium은 AI 에이전트에게 브라우저 인터페이스에 대한 통제된 접근을 제공합니다: 페이지 열기, 워크플로우 따르기, 사용자가 실제로 볼 수 있는 것을 수집하는 것입니다. OpenCV는 이미지를 처리하고 화면 캡처를 수행하여, 시스템이 무슨 일이 일어나고 있는지 해석하는 데 도움이 되는 시각적 신호를 추출할 수 있습니다. LLM 또는 트랜스포머(transformer)에 의도적인 도구-피드백 루프(tool-and-feedback loop)를 통해 연결함으로써, 이들은 라이브러리 자체가 모델의 일부라고 가장하지 않으면서 모델이 할 수 있는 것을 확장할 수 있습니다.

이 구분이 중요합니다. Selenium과 OpenCV가 LLM을 마법처럼 더 똑똑하게 만들지는 못하며, 그들의 통합 역시 자동적이지 않습니다. 엔지니어링은 이들을 둘러싼 시스템에 존재합니다: 모델이 무엇을 검사해야 할지, 어떤 행동을 취할 수 있는지, 결과가 어떻게 검증되는지, 그리고 인간이 언제 통제권을 유지해야 하는지를 결정하는 것입니다. 잘 구현된 경우, 이러한 확립된 Python 도구들은 언어 모델을 단순히 작업을 설명하는 시스템에서 관찰하고, 행동하며, 자신의 작업을 확인하는 시스템으로 변화시킬 수 있습니다.

섹션 1

AI가 잊은 도구들

업계는 점점 더 큰 모델을 구축하며 그것을 진전이라 부릅니다. 하지만 페이지에 무엇이 있는지 신뢰성 있게 보거나, 새로운 정보를 수집하거나, 자신이 찾은 것을 검증할 수 없는 모델은 여전히 한 손이 뒤로 묶인 채 작업하는 것과 같습니다.

저희는 다른 경로를 택했습니다. SilentRecon의 웹 스크래퍼가 실시간 정보를 수집하고, 그 보고서를 일시적 키 암호화(ephemeral-key encryption)로 보호합니다. LLM은 온라인에 접속할 통제된 권한을 부여받습니다—마구 돌아다니는 것이 아니라, 해당 보고서를 검사하고 최신 정보에 대해 추론하도록 말입니다. OpenCV는 시각적 현미경 역할을 하여 시스템이 웹을 단순히 텍스트로 취급하는 대신 이미지와 화면 콘텐츠를 검사할 수 있도록 돕습니다.

이 도구들 중 어느 것도 새로운 것은 아닙니다. Selenium과 OpenCV는 오늘날의 AI 붐 훨씬 전부터 실질적인 작업을 수행해 왔습니다. 이것이야말로 핵심 주장입니다: AI의 미래는 오래된 도구들을 버리는 것에 달려 있기보다, 그것들을 제대로 연결하는 것에 달려 있을 수 있습니다. 트랜스포머(transformer)가 언어 기반 추론을 제공한다면, 주변 도구들은 정보를 수집하고, 검사하며, 검증할 방법을 제공합니다. 공학적 난이도는 이 부분들이 속도, 정밀도, 통제력을 가지고 함께 작동하도록 만드는 데 있습니다.

왜냐하면 AI 시스템은 단지 강력하다는 이유만으로 유용해지는 것이 아니기 때문입니다. 그것은 자신의 학습 범위를 넘어 도달하고, 눈앞에 있는 것을 검사하며, 그 과정을 보여줄 수 있을 때 유용해집니다.

섹션 2 — 설계상 단순함. 구축상 정밀함.

아키텍처는 의도적으로 간단합니다: 수집(collect), 검사(inspect), 추론(reason), 검증(verify). 목표는 라이브러리들을 LLM에 무작위로 붙이는 것이 아닙니다. 각 구성 요소에 명확한 임무를 부여하고, 모델이 도구의 영역인 작업을 자신이 할 수 있다고 가장하는 것을 막는 것입니다.
Selenium은 브라우저를 처리합니다

Selenium은 정의된 워크플로우를 통해 실제 브라우저를 구동합니다. 페이지를 로드하고, 요소가 나타나기를 기다리며, 컨트롤과 상호 작용하고, 페이지의 보이는 상태를 캡처할 수 있습니다. 따라서 기본적인 HTTP 요청으로는 재현하기 어려운 동적 인터페이스 뒤에 정보가 존재할 때 유용합니다.

하지만 브라우저 자동화는 마법이 아닙니다. 페이지는 변경되고; 셀렉터(selector)는 깨지며; 콘텐츠는 늦게 로드되거나 사용자 세션에 의존할 수 있습니다. 따라서 브라우저 단계에는 명시적인 제한이 필요합니다: 방문할 수 있는 사이트나 페이지, 허용되는 동작, 실행 가능한 시간, 그리고 페이지가 예상과 일치하지 않을 때 무엇을 할 것인지 등이요. Selenium은 증거를 수집하는 것이고; 그 증거가 무엇을 의미하는지 결정해서는 안 됩니다.

OpenCV는 시각적 레이어를 검사합니다

페이지는 텍스트 이상의 것입니다. 스크린샷은 레이아웃, 시각적 변화, 차트, 아이콘 또는 페이지 구조만으로는 포착하기 어려운 콘텐츠를 드러낼 수 있습니다. OpenCV는 파이프라인에 이미지 처리 도구를 제공하여 영역을 비교하고, 변화를 감지하며, 관심 영역을 자르고, 추가 분석을 위한 시각적 입력을 준비할 수 있게 합니다.

이는 마음을 읽는 기계가 아니라 현미경입니다. OpenCV는 픽셀을 변환하고 측정할 수 있지만; 차트를 해석하거나 이미지의 의미를 이해하는 것은 추가적인 논리나 비전(vision) 능력을 갖춘 모델이 필요할 수 있습니다. 이러한 구분을 명확히 하는 것이 결과를 더 신뢰할 수 있게 만듭니다.

모델은 제한된 증거를 바탕으로 추론합니다

The LLM은 수집된 보고서와 관련 시각적 발견을 입력으로 받습니다. 요약하고, 비교하며, 질문에 답할 수 있지만—제공된 자료를 근거로 응답하도록 요청받고, 관찰된 사실과 추론을 구별하며, 증거가 불충분할 때도 말해야 합니다.

통제된 루프는 다음과 같습니다:

1. 작업을 정의하고 접근 제한을 설정합니다.
2. Selenium을 사용하여 허용된 웹 콘텐츠를 수집합니다.
3. 시각적 검사가 가치를 더하는 곳에는 OpenCV를 사용합니다.
4. 시스템의 키 처리 설계를 사용하여 전송 중 및 저장된 보고서를 보호합니다.
5. 모델에게 작업에 필요한 증거만을 제공합니다.
6. 결과를 제시하기 전에 보고서와 비교하여 확인합니다. 디자인을 단순하게 유지하는 것의 장점은 바로 여기에 있습니다: 숨겨진 가정이 적고, 실패 지점이 명확하며, 페이지에서 답변까지 추적 가능한 경로를 갖게 됩니다. Selenium이 브라우징을 수행하고, OpenCV가 시각적 증거를 처리하며, 모델이 이 도구들이 반환하는 내용을 바탕으로 추론합니다. 정밀도는 스택 전체를 'AI'라고 부르는 것에서 나오는 것이 아닙니다. 각 구성 요소가 자신의 역할을 하도록 만들고, 그들 사이의 인계(handoff) 과정을 확인하는 데서 나옵니다.

섹션 3 — 인터페이스 자체가 제품은 아니다

우리는 이 워크플로우를 Python으로 구축된 Streamlit 인터페이스에 통합했습니다. Streamlit이 가장 화려한 선택지였기 때문이 아니라, 인터페이스가 더 중요한 임무를 수행했기 때문입니다: 불필요한 복잡성 속에 시스템을 묻어버리지 않고 사용 가능하게 만드는 것입니다.

원칙은 간단했습니다. 사람들이 필요로 하는 곳에 제어 장치를 배치하고, 그 뒤의 기계는 모듈식으로 유지하는 것이었습니다. 이 인터페이스는 작업을 제출하고, 워크플로우를 실행하며, 결과 보고서를 검토할 수 있는 명확한 방법을 제공합니다. Selenium, OpenCV, 그리고 모델은 여전히 별개의 구성 요소로 남아 있어, 전체 애플리케이션을 하나의 얽힌 코드 블록으로 만들지 않고도 각각 조정할 수 있습니다.

이러한 단순성은 반복(iteration)에 중요합니다. 작고 집중된 인터페이스는 데모에서 인상을 주기 위해 구축된 방대한 프런트 엔드보다 이해하고, 테스트하고, 변경하기가 더 쉽습니다. Streamlit을 사용하면 작업 수행 도구와 가까운 곳에서 Python으로 이러한 제어 표면(control surface)을 직접 구축할 수 있습니다.

또한 이는 보다 간결한 모델 워크플로우를 지원합니다. 모델에게 모든 것을 무분별하게 보내는 대신, 시스템은 작업과 관련된 보고서 및 시각적 발견 사항만을 전달할 수 있습니다. 관련 없는 입력이 적다는 것은 모델이 추론해야 할 노이즈가 적다는 의미입니다.

하지만 Streamlit 자체가 모델을 더 빠르거나 정확하게 만드는 것은 아닙니다. 성능은 브라우저 워크플로우, 네트워크, 모델, 그리고 증거가 얼마나 효율적으로 준비되는지에 달려 있습니다. 이것들이 우리가 측정하고 조정해야 하는 부분입니다.

그 결과물은 단순히 멋지게 보이도록 포장된 쇼케이스가 아닙니다. 그것은 모듈식 파이프라인을 중심으로 구축된 실용적인 인터페이스이며, 작업 과정을 가시화하고 구성 요소를 관리하기 쉽게 하며 노력을 중요한 곳, 즉 유용한 결과에 집중하도록 설계되었습니다.

섹션 4 — 업계는 잘못된 방향을 보고 있다

AI 산업은 새로운 것을 필요한 것으로 혼동하는 습관이 있습니다. 매 주기마다 또 다른 프레임워크, 또 다른 추상화 계층, 그리고 다음 스택이 어려운 부분을 사라지게 할 것이라는 또 다른 약속이 등장합니다. 한편, 그 밑에 깔린 엔지니어링 문제는 여전히 고질적으로 익숙합니다: 신뢰할 수 있는 정보를 수집하고, 변경되는 인터페이스를 처리하며, 실제로 화면에 무엇이 표시되는지 검사하고, 시스템을 범위 내로 유지하며, 결과를 검증하는 것입니다.

바로 이 지점에서 논의가 엇나갈 수 있습니다. 우리는 어떤 모델이 더 크고, 어떤 프레임워크가 유행하며, 어떤 툴체인이 데모에서 가장 인상적으로 보일지 질문하는 데 너무 많은 에너지를 소비하여, 이미 특정 작업을 잘 수행할 수 있는 성숙한 도구들을 간과하기 쉽습니다.

SilentRecon의 철학은 더 실용적입니다. 작업부터 시작하고, 그것을 할 수 있는 가장 작고 신뢰할 수 있는 도구 세트를 선택하며, 핸드오프(handoff)를 명시적으로 만듭니다. 단순히 업계가 이야기한다고 해서 계층을 추가하지 마십시오. 브라우저 자동화로 충분한 일을 할 수 있는데 모델에게 브라우저를 모방하도록 요청하지 마십시오. 관련 증거를 먼저 분리할 수 있는 이미지 처리가 가능한데 스크린샷을 언어 모델에 보내지 마십시오. 그리고 세련된 인터페이스를 신뢰할 수 있는 시스템으로 착각하지 마십시오.

Python의 강점은 결코 하나의 마법 같은 라이브러리에 있지 않았습니다. 그것은 자동화, 이미지 처리, 데이터 처리, 네트워킹, 테스트, 모델 통합을 위한 생태계의 폭넓이에 있습니다. 이 많은 라이브러리들 중 상당수는 현재의 생성형 AI 붐이 일어나기 훨씬 전부터 존재했습니다.

이것은 그것들이 쓸모없거나 오늘날의 AI 문제를 자동으로 해결한다는 의미는 아닙니다. 이것은 우리가 오늘날의 시스템을 염두에 두고 다시 검토할 가치가 있다는 것을 의미합니다.
Selenium과 OpenCV가 그 점을 보여줍니다. Selenium은 브라우저 워크플로우를 자동화할 수 있고, OpenCV는 시각적 입력을 처리할 수 있습니다. 어느 것도 LLM을 대체하지 않으며, 지능으로 가는 지름길로 제시되어서도 안 됩니다. 이들의 가치는 AI 파이프라인에 모델 자체가 가지고 있지 않은 기능을 부여할 수 있다는 점입니다. 의도적으로 사용하면, 모델이 추측해야 하는 양을 줄이고 각 단계에서 무슨 일이 일어났는지 검사하기 쉽게 만들 수 있습니다.
이러한 원칙은 라이브러리를 선택할 때도 동일하게 적용됩니다. Playwright는 많은 현대적인 브라우저 자동화 작업에 강력한 선택지입니다. Selenium은 다른 환경, 기존 인프라 또는 확립된 워크플로우에 더 적합할 수 있습니다. LangChain은 특정 모델 및 도구 워크플로우를 구성하는 데 도움을 줄 수 있지만, 시스템이 몇 가지 명확한 단계만 가지고 있을 때는 작고 사용자 정의된 오케스트레이션 레이어가 이해하기 쉬울 수 있습니다. 여기에는 정직한 보편적 승자가 없습니다. 올바른 선택은 작업 부하, 신뢰성 요구 사항, 팀 경험, 종속성 및 프로젝트가 실제로 얼마나 많은 추상화를 필요로 하는지에 달려 있습니다.
요점이 바로 이것입니다. 최신 도구가 나쁘거나 오래된 라이브러리가 항상 더 빠르다는 것이 아닙니다. 요점은 기본값이 유행이 아니라 평가여야 한다는 것입니다. 성숙하고, 잘 이해되었으며, 충분한 기능을 가진 라이브러리가 기능이 더 많은 새로운 스택보다 더 적합할 수 있습니다. 가벼운 설계는 실패 지점을 찾기 쉽게 하고 출력을 감사하기 쉽게 만듭니다. 하지만 '가볍다'와 '빠르다'는 슬로건으로 다이어그램에 인쇄할 것이 아니라 테스트해야 할 주장입니다.
따라서 전체 워크플로우를 벤치마킹하세요. 페이지 로딩 시간, 콘텐츠 대기 시간, 이미지 처리 시간, 모델 호출 시간 및 답변 검증 시간을 측정하십시오. 변경되는 페이지를 테스트하고, 누락되거나 오해의 소지가 있는 데이터를 테스트하십시오. 최고의 시연 사례뿐만 아니라 실패율을 추적하십시오. 동일한 작업에 대해, 동일한 조건에서 대안들을 비교하십시오. 만약 더 새로운 도구가 승리한다면, 그것을 사용하세요.

만약 더 작거나 이미 확립된 도구가 더 적은 복잡성으로 작업을 수행한다면, 그것이 유행을 타지 않는다는 이유로 무시해서는 안 됩니다. 이것이 SilentRecon의 실용적인 입장입니다: 자리를 얻은 도구를 사용하세요. 모델이 추론에 집중하도록 하세요. 브라우저 자동화가 브라우저 동작을 처리하게 하세요. 이미지 처리 도구가 이미지 작업을 처리하게 하세요. 작업 수행에 충분히 단순한 인터페이스를 유지하세요. 증거는 눈에 보이게, 경계는 명확하게, 성능은 측정 가능하게 만드세요.

업계는 다음 추상화 계층을 쫓아갈지 모릅니다. 하지만 우리는 좀 덜 화려한 질문을 던지고 싶습니다: 이 작업을 신뢰성 있게 수행하는 가장 단순한 시스템은 무엇이며—우리가 그것을 증명할 수 있을까요? 그 질문은 반(反)혁신이 아닙니다. 혁신이 유용해지는 방식입니다.

섹션 5 — 검색 계층에는 Perl, 작업에는 Python