안녕하세요, 저는 SLEXN의 Nikita입니다. 최근 LLM 기반 AI 에이전트의 활용이 급격히 확산되고 있습니다. 저 또한 개발자로서 이런 도구들에 관심을 가져왔고, 약 한 달 전쯤 Windsurf(구 Codeium)를 구독하며 본격적으로 테스트해 보기로 했습니다. ㅡ이전에 VS Code 플러그인을 사용하며 좋은 인상을 받았던 경험이 있어 자연스럽게 Cascade에 관심을 갖게 되었습니다.
Cascade는 IDE 내에서 코드 생성과 수정을 실시간으로 도와주는 에이전트인데, 처음엔 꽤나 인상적이었습니다. “충분히 발전한 기술은 마법과 구별할 수 없다”는 Arthur Clarke 의 말이 떠오를 정도였죠. 머신러닝과 LLM에 대한 기본적인 이해가 있었음에도, 초기의 사용 경험은 꽤 놀라웠습니다.
하지만 시간이 지나면서 기대감은 점차 현실적인 인식으로 바뀌었습니다. Cascade는 문제를 정확히 이해하지 못하거나, 비효율적인 해결책을 제시하거나, 코드 변경이 엉뚱하게 반영되기도 했습니다.
물론 “일단 동작하는 것을 만들고, 나중에 개선하라”는 개발 원칙에 따르면 이해 가능한 수준이었고, 그럼에도 불구하고 개발 생산성을 높여준 것은 분명했습니다. 그래서 궁금해졌습니다.
“Cascade 하나만으로, 전혀 모르는 도메인의 서버 개발을 시작하고 마무리할 수 있을까?”
저는 다음 두 가지 접근을 비교하며 실험해 보기로 했습니다
- 아무런 문서나 배경 지식 없이 Cascade에 의존
- 기초 문서 학습 후 Cascade 활용 (수정 및 리뷰 포함)
1단계 - Cascade 단독 사용 : "장님이 귀머거리에게 설명하려는 상황"
첫 번째 시도는 말 그대로 “맹목적인 Cascade 의존”이었습니다. MCP 서버 개발에 대한 기본 개념이나 템플릿 없이, 단지 Cascade에게만 의존해 프로젝트를 진행했습니다.
이 과정의 상세 내용을 전부 기술할 필요는 없을 것 같습니다. 결과적으로 프로젝트는 완성되지 않았고, 시도할수록 오히려 결과가 악화되었습니다. 문제의 본질은 저 자신이 무엇을 하고 있는지 제대로 이해하지 못했다는데 있습니다. 다소 미흡한 요약이지만 참고삼아 아래에 정리합니다.
MCP 서버 구축 실험 요약 (with GitOn)
- 목표: TypeScript SDK 기반으로 GitOn API에 연결되는 MCP 서버 개발
- 초기 작업: 기존 GitLab 예제를 정리해 최소한의 모듈형 MCP 서버 구성
- 문제:
- TypeScript 의존성 문제
- SDK 문서 부실, 입출력 프로토콜 미정의
- stdin 테스트 시 응답 없음, 핸들러 작동 확인 불가
주요 단계에 대한 상세 여정은 아래와 같습니다.
Cascade에게 요구한 작업
- GitLab용 MCP 서버 예제를 GitOn 전용으로 변환
- TypeScript 기반으로 최소한의 동작 구조 구성
- 기존 레거시 코드 제거 및 의존성 구성
- 기본 기능: 프로젝트 목록 조회, 특정 ID로 상세 조회
기술적 시행착오
- 프로젝트 초기화 & 코드 정리
- GitLab용 코드 제거 후 MCP SDK 기반으로 코드 재구성
- 문제: TypeScript에서 모듈 누락, import 오류 등 발생
- → SDK 설치 순서 오류, node-fetch, fs, Buffer 등에서 타입 충돌
- 환경 설정 및 의존성 해결
- Node.js 20 사용 (nvm use 20)
- package.json, tsconfig.json, src/index.ts 수동 재설정
- 설치한 의존성: @modelcontextprotocol/sdk, zod, node-fetch, @types/node 등
- 문제: Node 내장 모듈에 대한 타입 에러
- → @types/node 추가로 해결
- GitOn API 연동 로직 작성
- config.json에서 사용자 정보와 API 주소 읽기
- getProjectsInfo, getProjectInfo 도구 구현
- SDK에서 요구하는 출력 형식(text)을 맞추기 위해 JSON 문자 열화 처리
- 서버 실행 및 테스트
- TypeScript로 컴파일 후 Node.js로 실행
- stdin 테스트 시 아무런 응답 없음
- 디버깅용 console.log 추가했지만 로그조차 출력되지 않음
- 프레이밍 및 프로토콜 이슈
- SDK 문서 확인 결과, Content-Length 기반 메시지 프레이밍(LSP와 유사)이 필요
- 문제: 프레이밍을 맞췄는데도 응답 없음
- → 핸들러 자체가 트리거되지 않음
- 가능성: SDK가 세션 핸드쉐이크나 전용 클라이언트를 요구하는 구조일 수 있음
결국 서버는 실행되었지만 테스트 요청에 응답하지 않았고, SDK가 요구하는 메시지 포맷(Content-Length framing 등)을 만족시키지 못했습니다. “잘 작동하는 것처럼 보이지만, 실제로는 아무 반응도 없는” 상태였죠.
- 속도: 총 3회 시도, 약 4시간 소요
- 코드 난이도: Cascade로 작성된 코드는 단순하고 명확했음
- 프로토타입 완성도: 구현은 완료됐지만 작동하지 않음
- 코드 숙지 정도: 명확히 보이던 코드가 실제로 문제에 봉착하면 전혀 감이 잡히지 않음
2단계 – 문서 기반 협업: “페어 프로그래밍의 시작”
1단계를 통해 Cascade 단독 사용의 한계를 깨달았고, 2단계에서는 전략을 바꿨습니다. 공식 문서를 숙지하고, Cascade를 도구로 활용하는 방식으로 접근하자 상황은 완전히 달라졌습니다.
- 학습한 자료
- 작업 흐름 - 개발 환경 초기화
- Cascade에게 MCP 예제를 참고해 개발 환경 구성 요청
- package.json, tsconfig.json, 초기 템플릿 구성
- MCP Inspector로 즉시 테스트 → 한 번에 실행 성공
- GitOn API 연동 통합
- 1단계에서 작성한 API 연동 함수를 Cascade에게 통합 요청
- Inspector를 통해 정상 작동 확인
- Windsurf 연동 테스트
- Cascade가 mcp_config 수정 후 Windsurf 재시작 안내
- 연결 성공, 요청/응답 흐름 정상 작동
- 코드 정리 및 문서화
- 템플릿 단계에서 남은 불필요한 메서드 제거 요청
- README 작성, GitLab에 초기화 및 푸시 완료
- 결과물: GitonMCPServer
- 개발 속도: 문서 조사 약 1시간, Cascade 활용 1시간 이내
- 코드 난이도: 라이브러리 내부까지 깊이 이해하지는 않았지만 구조와 확장 방법은 충분히 파악
- 프로토타입 완성도: 기대한 대로 정확히 동작하는 결과물 확보
- 코드 숙지 정도: 예상한 코드 구조 그대로 나왔고, 직접 작성한 것처럼 이해 가능
최종 정리
|
항목
|
1단계
|
2단계
|
|---|---|---|
|
개발 속도
|
3~4시간
|
약 2시간
|
|
이해 난이도
|
코드 이해는 가능, 오류 원인은 불명확함
|
구조와 흐름 모두 명확히 파악
|
|
결과 완성도
|
작동 실패
|
기대한 대로 정확히 동작
|
|
개발자 체감
|
무력감, 맥락 부족
|
예측 가능한 결과, 신뢰도 확보
|
마무리
Cascade를 ‘만능 개발 에이전트’로 기대하고 전적으로 의존한다면 실망할 수 있습니다. Cascade는 “코드를 대신 써주는 AI”가 아니라, 잘 훈련된 페어 개발자”로 보는 것이 정확합니다. 일정 수준의 배경 지식과 구조 이해를 갖춘 상태에서 보조 도구로 활용한다면, 상당한 생산성 향상을 기대할 수 있을 것입니다.
이번 실험을 통해 확인한 가장 중요한 사실은, 도구의 성능보다 그것을 다루는 개발자의 문제 정의 능력과 선택이 훨씬 더 중요하다는 점입니다.
결국 AI는 정답을 주는 존재가 아니라, 우리가 더 빠르고 정확하게 정답에 다가갈 수 있도록 도와주는 증폭기입니다.
AI가 개발의 모든 것을 대체하진 않겠지만, 잘 활용하는 개발자는 확실히 더 빠르게 앞으로 나아갈 수 있습니다. 앞으로도 이런 실험과 관찰을 통해, 인간과 AI가 함께 만들어갈 개발 방식의 미래를 더 깊이 탐색해 보고자 합니다.
