2026-05-29 회고
오늘 한 일
어제부터 이어진 이슈를 개선하려고 하다가, 오늘은 웹 검색을 더 잘 붙일 수 있는 MCP 도구를 찾았다.
확인한 도구는 bing, brave, duckduckgo 브라우저 검색을 MCP로 제공하는 web-search-mcp였다.
나중에 포크해서 현재 작업 흐름에 맞게 커스텀해볼 생각이다.
Qwen 3.6 사용 소감
Qwen 3.6 모델은 기대보다 판단이 둔했다.
qwen-code에 있는 .github 경로의 워크플로우를 그대로 sync해서 푸시하고 적용하라고 했는데, 실제로는 .qwen 경로에 일부 파일만 복사하려고 했다. 이게 핵심 문제였다.
결국 수동으로 클론을 떠서 .github와 .qwen 경로를 원본과 동일하게 맞춘 뒤 진행했다. 단순히 "원본 구조를 그대로 맞춘다"는 문제였는데, 모델이 경로와 목적을 섞어 해석하면서 불필요한 삽질이 길어졌다.
Qwen 자체에 대한 통찰
Qwen은 능력이 없는 모델이라기보다, 능력은 있는데 제어성이 약한 모델에 가깝다.
정보 탐색, 코드 수정, 파일 조작, 긴 작업 수행 자체는 꽤 잘한다. 문제는 사용자 의도를 고정해서 끝까지 유지하는 힘이 약하다는 점이다. 특히 "그대로 복사해", "수정하지 마", "추론하지 마", "공식 기준으로만 해", "이 경로는 건드리지 마" 같은 제한 조건을 작업 중간에 잊거나 자기 판단으로 덮어쓰는 경향이 있었다.
즉 Qwen은 일을 못 한다기보다, 일을 하다가 방향을 자기식으로 재해석한다.
이번 작업의 원래 문제는 단순했다.
공식 .github 그대로 복사
.qwen 제외
푸시
테스트그런데 Qwen은 이것을 자꾸 다른 문제로 확장했다.
MCP 문제인가?
workflow_call 문제인가?
push trigger를 추가해야 하나?
.qwen/commands를 만들어야 하나?
stderr JSON 문제인가?
empty review 문제인가?문제를 해결하기 전에 문제를 키운 셈이다. 에이전트형 LLM에서는 이 지점이 치명적이다. 작업 단위가 커질수록 원래 요청이 아니라 자기가 만든 하위 문제를 해결하기 시작한다.
웹서치를 붙여도 이 문제가 완전히 해결되지는 않았다. 좋은 흐름은 먼저 공식 문서나 소스를 확인하고, 구조를 파악한 뒤, 사용자 요청과 비교해서 필요한 작업만 실행하는 것이다. 하지만 Qwen은 먼저 추론하고, 가설을 만든 뒤, 그 가설을 확인하는 검색을 하고, 검색 결과를 다시 자기 가설에 끼워맞추는 흐름을 보였다.
그래서 웹서치는 근거 기반 작업 도구라기보다 가설 강화 도구처럼 쓰이기도 했다. 검색 능력 자체보다 검색 결과를 다루는 태도가 더 중요하다는 걸 확인했다.
실패 상태 해석도 약했다. 예를 들어 git ls-files .qwen/ 결과가 비어 있으면 .qwen은 tracked 상태가 아니라는 결론이 바로 나와야 한다. 그런데 계속 git rm -r --cached .qwen/ 같은 명령을 반복했다. 명령 실행 능력은 있지만, 실행 결과를 보고 다음 행동을 바꾸는 상태 해석과 루프 탈출 능력은 불안정했다.
또 Qwen은 "공식 그대로" 같은 보존 작업에 약하다. 생성과 수정에는 적극적인데, 원본을 보존하고 그대로 동기화하는 일에서는 계속 개선하려고 한다. 공식에는 없지만 .qwen을 만들어야 하지 않을까, trigger가 없으니 추가해야 하지 않을까, push에서 안 도니까 직접 실행되게 해야 하지 않을까 같은 식으로 원본 구조를 깨버릴 수 있다.
그래서 Qwen에게는 "공식 그대로 복사"라고 맡기기보다 다음처럼 쪼개는 편이 안전하다.
공식 파일 목록 출력
내 파일 목록 출력
차이 diff 출력
사용자가 승인한 파일만 복사Qwen에게 자율권을 크게 주는 것도 위험하다. 파일 수정, git add, commit, push, workflow 수정, 자동 테스트 후 추가 수정 같은 권한은 한 번 잘못 판단하면 그 판단을 실행까지 밀어붙인다.
따라서 Qwen의 역할은 작업 관리자나 최종 실행자보다 후보 생성기, 로그 요약기, 명령 결과 해석 보조에 가까워야 한다.
Qwen = 후보 생성기 / 로그 요약기 / 명령 결과 해석 보조
사용자 or 스크립트 = 최종 실행자구조화 출력도 조심해야 한다. Qwen이 JSON을 전혀 못 한다는 뜻은 아니지만, 복잡한 schema나 workflow 상태 관리를 맡기면 전체 안정성이 떨어진다. Markdown 리뷰 작성, 코드 설명, 로그 요약, 원인 후보 정리, 수정안 초안 생성은 괜찮다. 반면 정확한 JSON schema 출력, 복잡한 workflow 상태 관리, 도구 호출 순서 관리, GitHub API 작업, 파일 경로 보존, commit/push 판단은 부적합하다.
결론적으로 Qwen은 생성기로는 괜찮지만 오케스트레이터로는 불안정하다.
핵심은 이 한 줄이다.
Qwen은 똑똑한 생성 모델이지만, 신뢰할 수 있는 작업 관리자나 자동화 에이전트로 쓰기엔 제어성, 상태 해석, 지시 보존이 약하다.
실전 결론은 다음과 같다.
Qwen에게 생각은 시킬 수 있다.
Qwen에게 초안은 맡길 수 있다.
Qwen에게 최종 repo 조작은 맡기면 안 된다.앞으로 Qwen을 계속 쓴다면 운영 원칙은 이렇게 잡는 게 좋다.
자율 작업 금지
한 번에 한 명령
수정 전 diff 출력
commit/push 금지
공식 원본 보존 작업은 사람이 승인
LLM 출력은 Markdown/text로만 사용웹 검색 MCP에서 느낀 점
웹 검색을 붙이니 기존 웹 패치 방식보다 검색성능은 확실히 좋아졌다. 필요한 자료를 찾는 속도와 검색 범위가 좋아졌고, 후보 링크를 모으는 데는 도움이 됐다.
다만 웹 검색으로 얻은 정보를 이상하게 해석하는 경향이 있었다. 검색은 잘하는데, 검색 결과를 코드 작업의 맥락에 맞게 판단하는 능력은 아직 불안정했다.
그래서 코딩 LLM과 검색 LLM을 분리하는 편이 더 나을 수도 있겠다고 느꼈다. 검색은 검색에 강한 모델이나 도구에 맡기고, 코딩 판단은 별도로 검증하는 구조가 더 안정적일 것 같다.
반성
오늘 삽질 중 일부는 사실 답을 알고 있던 단순한 문제였다.
.github와 .qwen을 원본과 동일하게 맞추면 되는 일이었는데, 모델의 중간 시도에 끌려가면서 문제를 더 복잡하게 봤다. 다음에는 모델이 낸 작업 결과가 요구사항의 구조와 맞는지 먼저 확인하고, 경로/파일 단위의 동기화 작업은 초반에 직접 diff로 검증해야겠다.
특히 "무엇을 복사했는가"보다 "원본과 목적지가 같은 구조가 되었는가"를 먼저 확인하는 습관이 필요하다.
작업 중단 이슈
오늘 오후 2시 이후로 인터넷이 터지면서 RunPod에서 구동 중이던 Qwen 서버가 나갔다. 그 이후로는 모델 호출이 불가능해서 작업을 더 이어가기 어려웠다.
로컬 작업이나 정리는 가능했지만, Qwen 서버를 전제로 한 자동 리뷰/검색/검증 흐름은 인터넷 상태에 크게 의존한다는 점을 다시 확인했다.
다음 액션
web-search-mcp를 포크해서 필요한 검색 엔진과 출력 포맷을 커스텀한다.- Qwen이 웹 검색 결과를 해석할 때 생기는 오류를 줄이기 위해 검색 결과 요약과 코딩 판단 단계를 분리한다.
.github,.qwen처럼 디렉터리 구조 동기화가 중요한 작업은 먼저diff기준으로 검증한다.- Qwen에게 repo 조작 권한을 바로 주지 말고, 한 번에 한 명령과 diff 확인 중심으로 운용한다.
- Qwen의 출력은 우선 Markdown/text 초안으로 받고, JSON schema나 GitHub API orchestration은 스크립트 또는 사람이 담당한다.
- RunPod Qwen 서버 장애에 대비해 fallback 모델이나 로컬 확인 절차를 마련한다.