VS Code의 Cline, TypeScript 프로젝트에 2주 사용해도 살아남았다

발행: 3일 전 (2026년 6월 7일 PM 09:02 GMT+9)

11 분 소요

Source: Dev.to

VS Code에서 Cline: TypeScript 프로젝트에 2주간 사용한 결과

2005년, 사이버 카페가 밤 11시에 문을 닫고 손님들로 가득 찼을 때는 문서를 읽을 시간이 없었다. 문제를 진단하고, 명령을 실행하고, 무슨 일이 일어나는지 확인하고, 고쳐야 했다. 이 경험은 나에게 도구가 실제로 무슨 일을 하는지 보여줄 때까지 기다리는 것에 대한 존중과, 사전 경고 없이 행동하는 도구에 대한 깊은 불신을 심어주었다.

2024년에 자동 코딩 에이전트를 평가하기 시작했을 때, 같은 본능이 속도 벤치마크보다 권한 모델에 먼저 주목하도록 만들었다. Cline은 내가 실제로 첫 번째 명령을 쓰기 전에 권한을 설정하는 데 한 시간을 넘게 들였던 최초의 도구였다.

핵심 주장

자동 코딩 에이전트는 모두 똑같지 않으며, Cline은 다른 도구보다 더 제어하기 쉬운 권한 모델을 가지고 있다. 하지만 핵심은 그 권한을 어떻게 설정하느냐에 달려 있다. 기본 설정으로 Cline을 설치하고 복잡한 모듈을 리팩터링하도록 하면, 30분 정도 권한을 정의한 경우와는 전혀 다른 경험을 하게 된다.

다음은 실제 TypeScript 프로젝트에서 2주간 활발히 사용한 결과를 바탕으로 한 분석이다. 위임한 작업, 발생한 오류, 설정 결정 등을 문서화했으며, 이는 벤치마크가 아니라 실제 현장에서 얻은 판단 기준이다.

Cline은 VS Code Marketplace에 오픈소스 확장으로 제공된다. 공식 설명에 따르면 Cline은 파일을 읽고, 터미널 명령을 실행하고, 브라우저를 탐색하며, 코드를 생성·수정할 수 있는 자율 에이전트이며, 모든 작업을 VS Code 내부에서 수행한다.

페이지에 명시된 내용

Cline은 기본적으로 승인 루프를 사용한다. 파일 쓰기, 터미널 명령 실행 등 파괴적인 작업마다 확인을 요구한다.
특정 카테고리에 대해 auto‑approve 모드를 설정할 수 있지만, 기본은 안전 모드이다.

페이지에 명시되지 않은 내용

출력 품질은 연결된 모델에 거의 전적으로 의존한다. Cline은 공급자에 구애받지 않으며, Claude (Anthropic), OpenRouter, GPT‑4o, 로컬 Ollama 모델 등 원하는 모델을 자유롭게 사용할 수 있다. 이 유연성은 특정 공급자에 묶여 있는 도구와 비교했을 때 큰 장점이지만, 선택한 모델에 따라 경험이 크게 달라진다는 점을 의미한다.

내가 진행한 실험에서는 Anthropic API를 통해 claude‑3‑5‑sonnet을 직접 사용했다. 모델 변수를 격리하기 위해 OpenRouter는 사용하지 않았다.

프로젝트 개요

스택: TypeScript, Express, Prisma, PostgreSQL
목적: 익숙한 스택을 선택해 Cline의 오류를 기술 스택에 대한 불확실성과 혼동하지 않도록 함

작업 분류

작업을 시작하기 전에 세 가지 카테고리로 나눴다.

카테고리 A — 최종 검토만 하는 전체 위임
- 기존 Prisma 스키마에서 Zod 타입 생성
- 이미 구현된 순수 함수에 대한 단위 테스트 작성
- 일관된 테스트 데이터를 갖는 시드 파일 생성
카테고리 B — 중간 체크포인트가 있는 위임
- 결합도가 높은 검증 모듈 리팩터링
- 순수 Express 엔드포인트를 구조화된 라우터로 마이그레이션
- 특정 파일의 TypeScript strict 오류 해결
카테고리 C — 위임하지 않고 모니터링
- 데이터베이스 스키마 변경
- 인증 로직 수정
- 인프라 설정 파일 변경

이 분류는 어떤 가이드에서도 나온 것이 아니라, 첫 48시간 동안 Cline이 예상치 못한 행동을 보인 뒤 직접 만든 것이다. 예를 들어, 카테고리 B 작업 중 Cline이 내가 언급하지 않은 파일의 import를 바꾸면서 타입 오류를 해결했는데, 이는 기술적으로는 맞지만 컨텍스트를 벗어나는 행동이었다. 심각한 오류는 아니었지만, “마지막에 검토” 방식이 의존성이 있는 작업에는 맞지 않음을 보여주었다.

카테고리 A에 적합한 명령 예시

// 예시: Zod 스키마 생성 작업 (카테고리 A)

// Cline에 전달할 명령:
// "Generá un schema Zod para el modelo User del archivo schema.prisma.
// Solo el archivo src/schemas/user.schema.ts.
// No modifiques ningún otro archivo.
// Usá z.string().uuid() para el campo id."

// 기대 결과 및 실제 결과:
import { z } from 'zod'

export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  nombre: z.string().min(1),
  creadoEn: z.coerce.date(),
  actualizadoEn: z.coerce.date(),
})

export type User = z.infer

핵심 인사이트: 작업의 복잡성보다 명령의 정확성이 더 중요하다. 이것이 내가 처음 배운 교훈이다.

오류 사례

오류 1 – 로컬 수정의 과도한 일반화

특정 파일의 TypeScript 오류를 해결해 달라고 요청했더니, Cline은 오류를 바로 잡았지만 동시에 공유 타입 정의 파일을 “더 깔끔하게” 만들기 위해 수정했다. 기술적으로는 완벽했지만, 내 컨텍스트는 완전히 사라졌다.

교훈: Cline은 전체 코드베이스를 탐색한다. “X 파일 밖은 수정하지 마라”는 명시적인 제한을 주지 않으면, 옆으로도 탐색한다. 이는 근본 원인을 찾고 싶을 때는 장점이지만, 정밀한 수술적 변경을 원할 때는 문제다.

오류 2 – 커버리지는 높지만 실용성이 없는 테스트

테스트 생성 작업에서 Cline은 100% 커버리지를 가진 파일을 만들었지만, 실제로는 구현을 테스트하는 것이 아니라 그저 존재를 확인하는 수준이었다.

// 잘못된 테스트 예시:
describe('calcularDescuento', () => {
  it('debería retornar un valor', () => {
    expect(calcularDescuento(100, 10)).toBeDefined()
  })
})

문제점: “이 함수에 대한 테스트를 작성해라”는 지시가 너무 포괄적이다. 경계 조건, 핵심 동작, 예상 어설션 수준을 명시해야 한다.

// 정확한 지시와 올바른 테스트 예시:
describe('calcularDescuento', () => {
  it('descuento 0% retorna precio original', () => {
    expect(calcularDescuento(100, 0)).toBe(100)
  })
  it('descuento 100% retorna 0', () => {
    expect(calcularDescuento(100, 100)).toBe(0)
  })
  it('descuento negativo lanza error', () => {
    expect(() => calcularDescuento(100, -5)).toThrow('Descuento inválido')
  })
  it('precio 0 retorna 0 independiente del descuento', () => {
    expect(calcularDescuento(0, 50)).toBe(0)
  })
})

오류 3 – 장기 리팩터링에서 체크포인트 부재

가장 시간 소모가 큰 오류는 카테고리 B의 긴 리팩터링 작업에서 발생했다. Cline은 12단계에 걸친 편집을 모두 마친 뒤에야 내가 중간 상태를 검토했다. 최종 결과는 올바랐지만, 4단계에서 내 의견과 다른 설계 선택이 있었고, 그 시점에 되돌리려면 전체 작업을 다시 해야 했다.

교훈: 5단계 이상으로 이어지는 작업은 각 단계마다 확인 루프를 명시적으로 삽입해야 한다. Cline에게 “다음 단계로 진행하기 전에 멈추고 확인해라”라고 요청하면, 시간과 리스크를 크게 줄일 수 있다.

결론

Cline은 권한 모델과 명령 정확성에 따라 강력하거나 위험할 수 있는 도구다.

기본 안전 모드와 명시적 권한 설정을 활용하면, 대부분의 작업을 안심하고 위임할 수 있다.
모델 선택은 출력 품질을 좌우한다. 같은 프롬프트라도 Claude와 GPT‑4o는 결과가 크게 다를 수 있다.
작업을 작은 단위로 나누고, 구체적인 지시와 **중간 체크포인트