요즘 개발하는 분들이랑 이야기하다 보면 AI 코딩 도구 얘기를 안 할 수가 없더라고요. 저도 개발자로 밥 먹고 산 지 어느덧 20년이 넘었는데, 처음에는 솔직히 좀 삐딱하게 봤어요. “뭐, 자동완성 조금 똑똑해진 거겠지.” 딱 이 정도였거든요. 그런데 작년에 우연히 오픈소스 AI 코딩 도구인 Continue를 써보고 나서는 생각이 꽤 바뀌었습니다. 특히 요즘 말하는 AI 바이브 코딩, 그러니까 AI랑 대화하면서 흐름 타듯이 코드를 만들어가는 방식에는 이 도구가 생각보다 잘 맞더라고요.
그래서 이 글은 Continue 소개글이라기보다는, 제가 실제로 업무랑 사이드 프로젝트에서 어떻게 써봤는지에 가까워요. 뭐랄까, 친한 개발자 친구한테 “야, 이거 한 번 써봐. 근데 이런 건 조심하고.” 하고 커피 마시면서 이야기하는 느낌으로 적어보려고 합니다. 좋은 점도 있고, 귀찮은 점도 있어요. 그런 걸 좀 솔직하게 풀어볼게요.
Continue를 굳이 써본 이유
사실 이미 GitHub Copilot이나 ChatGPT 같은 도구를 쓰는 분들 많잖아요. 저도 당연히 써봤습니다. 둘 다 좋은 도구예요. 그런데 쓰다 보면 은근히 답답한 순간이 생깁니다. 지금 내가 보고 있는 프로젝트 구조를 제대로 이해하지 못한다거나, 특정 파일의 맥락을 놓친 채로 그럴듯한 코드를 던져준다거나. 겉보기엔 맞는데 막상 붙이면 묘하게 안 맞는 그런 코드요.
Continue가 마음에 들었던 건, 이 녀석이 IDE 안에서 제 프로젝트와 꽤 가깝게 붙어 움직인다는 점이었어요. VS Code나 JetBrains IDE에 붙여서 쓰면, 단순히 열린 파일만 보는 게 아니라 폴더 구조, 선택한 코드, 터미널 출력, 특정 파일까지 같이 참고하게 만들 수 있습니다. 이게 별거 아닌 것 같지만 실제로는 꽤 큽니다.
예를 들어 “이 함수 리팩토링해줘”라고 말하는 것과, “@/src/models/user.py랑 @/src/services/auth_service.py를 보고 이 함수 리팩토링해줘”라고 말하는 건 결과가 완전히 달라요. 후자는 적어도 우리 프로젝트의 냄새를 조금은 맡고 대답합니다. 저는 이 차이가 Continue를 계속 쓰게 된 가장 큰 이유였어요.
물론 처음 설정은 살짝 귀찮습니다. 오픈소스 도구들이 대체로 그렇잖아요. 뭔가 자유롭고 좋긴 한데, 처음 문턱에서 “자, 이제 네가 좀 알아서 해봐” 하는 느낌이 있습니다. 모델 연결하고, 설정 파일 만지고, API 키 넣고, 로컬 모델 붙여보고. 저도 처음에는 한두 번 삽질했어요. 그런데 한 번 자리를 잡아두면 그다음부터는 편합니다.
| 구분 | 상용 AI 코딩 도구 | Continue |
|---|---|---|
| 설정 난이도 | 상대적으로 쉬움 | 처음에는 조금 손이 감 |
| 커스터마이징 | 제한적인 편 | 설정 파일로 꽤 자유롭게 조정 가능 |
| 로컬 모델 사용 | 대체로 어려움 | Ollama, LM Studio 등과 연결 가능 |
| 보안 통제 | 서비스 정책에 의존 | 로컬 모델을 쓰면 통제 범위가 넓어짐 |
| 프로젝트 맥락 활용 | 도구마다 차이가 큼 | 파일, 폴더, 터미널 출력 등을 직접 지정 가능 |
저는 민감한 코드나 고객사 관련 작업은 로컬 모델 쪽으로 붙이고, 일반적인 사이드 프로젝트나 빠르게 초안이 필요한 작업은 GPT-4 계열 API를 붙여서 씁니다. 이 방식이 제일 현실적이더라고요. 전부 로컬로 하자니 답답할 때가 있고, 전부 클라우드로 보내자니 마음이 불편한 코드도 있으니까요.
실제로 Flask 앱에 붙여보니 이랬습니다
말로만 하면 좀 공허하니까, 제가 최근에 만들었던 작은 Flask 앱 이야기를 해볼게요. 사이드 프로젝트로 이메일 발송 서버를 하나 만들고 있었어요. 아주 거창한 건 아니고, JSON 요청을 받아서 Gmail SMTP로 메일을 보내는 정도의 기능이었습니다.
예전 같았으면 일단 검색부터 했을 겁니다. “Flask Gmail SMTP example” 검색하고, smtplib 문서 보고, MIMEText 예제 복사하고, 에러 나면 다시 검색하고. 저도 오래 개발했지만 이런 자잘한 코드는 매번 기억나는 게 아니거든요. 정확히는 기억하고 싶지 않은 쪽에 가깝습니다. 머릿속 공간이 아깝잖아요.
이번에는 Continue에게 그냥 이렇게 말했습니다.
이 Flask 앱에 Gmail SMTP를 이용한 이메일 발송 기능을 추가해줘. 에러 로그는 콘솔에 찍히게 하고, 요청 본문은 JSON으로 받아.
그랬더니 Continue가 이런 식으로 초안을 만들어줬습니다.
from flask import Flask, request, jsonify
import smtplib
from email.mime.text import MIMEText
import logging
app = Flask(__name__)
logging.basicConfig(level=logging.ERROR)
@app.route('/send-email', methods=['POST'])
def send_email():
data = request.get_json()
if not data or 'to' not in data or 'subject' not in data or 'body' not in data:
return jsonify({'error': 'Invalid request'}), 400
msg = MIMEText(data['body'])
msg['Subject'] = data['subject']
msg['From'] = 'your-email@gmail.com'
msg['To'] = data['to']
try:
with smtplib.SMTP('smtp.gmail.com', 587) as server:
server.starttls()
server.login('your-email@gmail.com', 'your-password')
server.send_message(msg)
return jsonify({'status': 'Email sent'}), 200
except Exception as e:
logging.error(f"Failed to send email: {e}")
return jsonify({'error': str(e)}), 500
당연히 이 코드를 그대로 운영에 넣으면 안 됩니다. 특히 비밀번호를 코드에 박아 넣는 부분은 바로 고쳐야죠. 저는 환경 변수로 빼고, Gmail 앱 비밀번호를 따로 쓰게 만들고, 에러 메시지도 사용자에게 너무 자세히 노출되지 않도록 수정했습니다. 이런 건 AI가 해준다고 해서 그냥 믿으면 안 됩니다. 오래 개발하다 보면 알잖아요. 제일 위험한 코드는 “그럴듯하게 맞아 보이는 코드”입니다.
그래도 좋았던 건, 빈 화면에서 시작하지 않아도 된다는 점이었어요. Continue가 뼈대를 만들어주니까 저는 그다음부터 구조를 다듬고, 보안을 체크하고, 우리 프로젝트 스타일에 맞추는 일에 집중할 수 있었습니다. 이게 제가 느낀 AI 바이브 코딩의 진짜 장점이에요. 단순히 빨라지는 게 아니라, 머리를 써야 할 곳과 안 써도 되는 곳을 나눠주는 느낌입니다.
제가 실제로 바꾼 부분
Continue가 만들어준 초안에서 저는 대략 이런 부분을 손봤습니다.
- 계정 정보 제거: Gmail 계정과 비밀번호를 환경 변수로 분리했습니다.
- 에러 응답 정리: 내부 예외 메시지를 그대로 내려주지 않도록 바꿨습니다.
- 요청값 검증 강화: 이메일 형식, 제목 길이, 본문 누락 여부를 조금 더 꼼꼼하게 확인했습니다.
- 로깅 레벨 조정: 운영 환경에서는 error, 개발 환경에서는 debug까지 볼 수 있게 나눴습니다.
- 테스트 코드 추가: 정상 요청, 필드 누락, SMTP 실패 케이스를 테스트로 넣었습니다.
이런 식으로 쓰면 AI가 개발자를 대체한다기보다, 옆에서 초안 잡아주는 꽤 성실한 후배처럼 느껴집니다. 다만 그 후배가 가끔 말도 안 되는 자신감을 보일 때가 있어서, 시니어가 옆에서 봐줘야 합니다. 이건 진짜 중요해요.
예전 방식과 Continue를 쓴 방식, 시간이 꽤 달랐습니다
제가 이 작업을 하면서 시간을 대충 재봤거든요. 아주 엄밀한 실험은 아니지만, 현업에서 체감하는 정도로는 충분히 의미가 있었습니다.
| 작업 항목 | 예전 방식 | Continue 활용 방식 |
|---|---|---|
| 문서와 예제 찾기 | 약 15분 | 거의 없음 |
| 초안 작성 | 약 20분 | 약 2분 |
| 실행 후 오류 확인 | 약 10분 | 약 5분 |
| 프로젝트 스타일에 맞게 수정 | 약 10분 | 약 10분 |
| 전체 소요 시간 | 약 55분 | 약 17분 |
숫자로 보면 꽤 차이가 납니다. 그런데 저는 시간보다 더 좋았던 게 흐름이 끊기지 않았다는 점이에요. 개발하다가 검색창 열고, 문서 보고, 블로그 들어가고, 중간에 광고 보고, 갑자기 다른 글 읽고. 이런 식으로 집중이 새는 일이 줄었습니다. 나이 들수록 이게 더 크게 느껴져요. 집중력이 예전처럼 막 샘솟지는 않거든요. 아껴 써야 합니다.
Continue로 바이브 코딩할 때 제가 꼭 지키는 습관
한동안 써보니 대충 감이 오더라고요. Continue를 그냥 자동완성 도구처럼 쓰면 아깝습니다. 이 도구는 맥락을 잘 먹여야 힘을 냅니다. 사람도 그렇잖아요. 아무 배경 설명 없이 “이거 해줘” 하면 이상한 결과가 나오고, 상황을 조금 알려주면 훨씬 나아집니다.
파일을 콕 집어서 알려주는 게 좋습니다
Continue에서는 @ 기호로 특정 파일이나 폴더를 참조하게 할 수 있습니다. 저는 이 기능을 정말 자주 써요.
@/src/models/user.py @/src/services/auth_service.py 이 두 파일 구조를 보고 로그인 실패 시도 제한 기능을 추가해줘.
이렇게 말하면 그냥 “로그인 제한 기능 만들어줘”라고 했을 때보다 훨씬 낫습니다. 모델 이름, 함수명, 예외 처리 방식이 기존 코드와 비슷하게 나올 확률이 높아요. 물론 완벽하진 않습니다. 그래도 출발점이 달라요.
에러 로그는 그대로 보여주는 게 제일 빠릅니다
예전에는 에러 메시지를 복사해서 검색했죠. Stack Overflow 들어가고, 비슷한 글 찾고, 답변 날짜 확인하고. 요즘은 그냥 터미널 로그를 Continue에 던져봅니다.
이 에러가 왜 나는지 봐줘. 현재 Flask 앱에서 /send-email 호출할 때 발생했고, 관련 파일은 @/app.py야.
이렇게 물어보면 단순히 에러 메시지만 해석하는 게 아니라, 내가 지정한 파일과 함께 원인을 찾아줍니다. 특히 import 경로 문제, 환경 변수 누락, 패키지 버전 충돌 같은 건 꽤 잘 잡아냅니다. 물론 “이게 100% 정답이다”라고 믿지는 말고요. 그래도 검색 시간을 줄이는 데는 확실히 도움이 됩니다.
한국어로 말해도 충분히 잘 알아듣습니다
처음에는 저도 괜히 영어로만 프롬프트를 썼어요. 개발 도구니까 영어로 해야 더 잘 알아듣겠지 싶었거든요. 그런데 막상 써보니 한국어도 꽤 잘 됩니다. 오히려 제가 의도를 편하게 설명할 수 있어서 결과가 더 좋을 때도 많았어요.
예를 들면 이런 식입니다.
이 함수가 너무 길어졌어. 동작은 그대로 두고, 검증 로직이랑 SMTP 발송 로직을 함수로 분리해줘. 함수 이름은 너무 과하게 추상화하지 말고 읽기 쉽게 해줘.
이런 요청은 영어로 딱딱하게 쓰는 것보다 한국어로 말하는 게 제 의도가 더 잘 담기더라고요. “너무 과하게 추상화하지 말고” 같은 표현은 참 한국 개발자다운 요청인데, 이런 뉘앙스를 의외로 잘 받아들입니다.
로컬 모델과 클라우드 모델을 나눠 쓰면 마음이 편합니다
저는 모든 코드를 클라우드 모델에 보내는 걸 좋아하지 않습니다. 개인 프로젝트야 괜찮지만, 회사 코드나 고객사 코드가 섞이면 이야기가 달라지죠. 그래서 민감한 작업은 Ollama나 LM Studio로 로컬 모델을 붙여서 처리합니다.
물론 로컬 모델은 속도나 품질 면에서 아쉬울 때가 있어요. 특히 복잡한 설계나 긴 리팩토링은 클라우드 모델이 더 잘합니다. 대신 로컬 모델은 마음이 편합니다. 이게 은근히 중요해요. 개발자는 손이 편한 것도 중요하지만, 마음이 불편하면 결국 오래 못 씁니다.
| 상황 | 제가 주로 쓰는 방식 |
|---|---|
| 개인 사이드 프로젝트 | GPT-4 계열 API 또는 Claude 계열 모델 |
| 회사 내부 코드 | 로컬 모델 우선 검토 |
| 고객사 정보가 섞인 코드 | 로컬 모델만 사용하거나 아예 AI 사용 제외 |
| 단순 코드 변환 | 로컬 모델로 빠르게 처리 |
| 복잡한 설계 검토 | 민감 정보 제거 후 클라우드 모델 활용 |
오픈소스 도구라서 좋은데, 그래서 손이 가는 부분도 있습니다
Continue가 오픈소스라는 점은 분명 매력입니다. 원하는 모델을 붙일 수 있고, 설정을 직접 만질 수 있고, 도구가 어떤 방향으로 움직이는지도 어느 정도 들여다볼 수 있으니까요. 그런데 반대로 말하면 사용자가 챙겨야 할 것도 있습니다.
저도 LM Studio를 처음 연결할 때 API 엔드포인트 설정 때문에 꽤 헤맸습니다. 포트는 맞는 것 같은데 응답이 안 오고, 모델은 떠 있는데 Continue에서는 못 찾고. 이런 식으로 한 시간 정도 날렸던 기억이 있어요. 그때는 좀 짜증 났는데, 지나고 보니 오픈소스 도구랑 친해지는 과정이 늘 그렇더라고요.
- 모델 연결 설정: Ollama, LM Studio, OpenAI API 등 모델마다 설정 방식이 조금씩 다릅니다. 처음에는 공식 문서를 옆에 열어두는 게 마음 편합니다.
- 로컬 모델 성능: GPU가 없으면 7B 모델도 답답하게 느껴질 수 있습니다. 작은 코드 수정은 괜찮지만, 긴 컨텍스트 작업은 꽤 버벅일 수 있어요.
- 보안 설정: 텔레메트리나 외부 전송 관련 설정은 꼭 확인하는 편이 좋습니다. 저는 로컬 모델을 쓸 때 불필요한 전송 옵션은 꺼둡니다.
- 코드 검증: AI가 만든 코드는 반드시 테스트를 돌립니다. 특히 인증, 결제, 개인정보, 파일 업로드 쪽은 사람이 다시 봐야 합니다.
- 프롬프트 관리: 대화가 길어지면 AI가 앞뒤를 헷갈릴 때가 있습니다. 그럴 땐 새 대화를 열고 필요한 파일만 다시 지정하는 게 낫습니다.
이 부분은 조금 주관이 강한데요. 저는 AI 코딩 도구를 “정답 생성기”로 쓰는 건 위험하다고 봅니다. 대신 “초안 생성기”, “디버깅 파트너”, “리팩토링 대화 상대” 정도로 두면 만족도가 훨씬 높아요. 기대치를 잘 잡아야 오래 씁니다.
제가 Continue를 쓰면서 제일 많이 하는 요청들
Continue를 쓰다 보면 자주 쓰는 패턴이 생깁니다. 저는 아래 요청들을 거의 매일 씁니다.
- “이 코드의 의도를 설명해줘” — 남이 짠 코드나 오래전에 제가 짠 코드를 볼 때 씁니다. 가끔 제 과거 코드는 남의 코드보다 더 낯설거든요.
- “테스트 케이스를 만들어줘” — 특히 경계값 테스트 초안 만들 때 편합니다.
- “이 함수 이름 좀 더 읽기 좋게 추천해줘” — 이름 짓다가 멍해질 때 은근히 도움 됩니다.
- “이 에러 로그 기준으로 원인 후보를 좁혀줘” — 바로 정답을 기대하기보다 가능성을 줄이는 용도로 씁니다.
- “동작은 바꾸지 말고 가독성만 개선해줘” — 리팩토링할 때 제일 많이 쓰는 문장입니다.
특히 “동작은 바꾸지 말고”라는 말을 자주 붙입니다. 이 말을 안 하면 AI가 친절하게도 기능까지 고쳐버릴 때가 있어요. 참 고맙긴 한데, 그 고마움이 장애로 이어질 수도 있습니다. 그래서 저는 요청할 때 경계를 꽤 명확히 말하는 편입니다.
이런 분들은 Continue를 한 번 만져보면 좋겠습니다
Copilot을 이미 잘 쓰고 있다면 굳이 당장 갈아탈 필요는 없다고 생각합니다. 도구는 손에 익은 게 제일이니까요. 다만 AI 바이브 코딩을 조금 더 내 방식대로 해보고 싶다거나, 로컬 모델을 붙여서 써보고 싶다거나, 회사 보안 정책 때문에 클라우드 기반 도구가 부담스럽다면 Continue는 꽤 괜찮은 선택지입니다.
특히 이런 분들께 잘 맞을 것 같아요.
- AI 코딩 도구를 쓰긴 쓰는데, 프로젝트 맥락을 더 정확히 먹이고 싶은 개발자
- 오픈소스 기반으로 내 입맛에 맞게 코딩 환경을 꾸미는 걸 좋아하는 분
- 구독형 도구만 쓰기에는 비용이 부담되는 개인 개발자나 프리랜서
- 회사 보안 정책 때문에 클라우드 AI 도구 사용이 조심스러운 개발팀
- 단순 자동완성보다 AI와 대화하면서 설계와 리팩토링을 같이 해보고 싶은 분
저는 Continue를 쓰면서 개발이 완전히 쉬워졌다고 말하고 싶진 않습니다. 그런 말은 좀 과장 같아요. 대신 개발할 때 귀찮고 반복적인 부분이 줄었고, 막히는 순간에 혼자 끙끙대는 시간이 줄었습니다. 이 정도만 해도 꽤 큰 변화입니다. 20년 개발해도 여전히 막히는 날은 있고, 그럴 때 옆에서 같이 봐주는 도구가 있다는 건 생각보다 든든하거든요.
시간 날 때 한 번 설치해서 작은 프로젝트에 붙여보세요. 처음부터 회사 핵심 프로젝트에 넣지는 말고요. 작은 Flask 앱이든, 개인용 스크립트든, 테스트 코드 생성이든 가볍게 시작하는 게 좋습니다. 그러다 보면 “아, 이건 내 워크플로에 들어오겠는데?” 하는 순간이 올 수도 있어요. 저는 딱 그랬습니다.
이 글은 Continue가 궁금했던 개발자, 오픈소스 AI 코딩 도구를 찾고 있던 분, 그리고 요즘 말하는 AI 바이브 코딩을 실제 업무에 어떻게 녹일지 고민하는 분들께 특히 도움이 될 거예요. 너무 믿지도 말고, 너무 멀리하지도 말고. 딱 좋은 거리에서 써보면 꽤 쓸 만합니다.
댓글
댓글 쓰기