컴퓨터 특성화고 2학년이 생각한 AI 알차게 사용하는 법

김건우·2026년 8월 24일

AI

목록 보기

1/1

𝐡𝐞𝐥𝐥𝐨 𝐰𝐨𝐫𝐥𝐝

2026/08/24

뭔가 글을 작성해야 할 것 같아서 무슨 주제로 작성해볼까 하다가

AI가 발전하기 시작한 초기인 2024년부터 AI로 개발&해킹 공부/개발을 하던 나만의 사용법과 팁을 작성해보려고 한다.

처음 AI를 사용했을 때는 단순히 모르는 코드를 물어보거나, 오류가 발생했을 때 해결 방법을 찾는 정도로만 사용했었다. 하지만 계속 사용하다 보니 AI를 단순한 질문용 도구로 사용하는 것과 하나의 개발 팀원처럼 사용하는 것은 차이가 엄청 크다는 것을 알게 되었다.

특히 요즘은 AI 모델 하나만 사용하는 것이 아니라 각 모델과 에이전트의 장점을 나눠서 사용하는 편이다.

계획을 세울 때 잘하는 모델, 실제 코드를 작성할 때 잘하는 모델, 대규모 프로젝트를 오래 작업할 때 좋은 모델들이 서로 다르기 때문에 상황에 따라 여러 AI를 같이 활용하고 있다.

이번 글에서는 내가 실제로 자주 사용하는 AI들과 각각 어떻게 활용하고 있는지, 그리고 혼자 프로젝트를 개발할 때 AI를 어떤 방식으로 사용하는지 적어보려고 한다.

사용하는 AI_MODEL 소개

먼저 나는 주로 OpenAI의 GPT(ChatGPT, CODEX), OpenCode CLI를 사용한다.

물론 Claude도 사용해봤고 다른 여러 모델들도 사용해봤지만, 현재 내가 개인 프로젝트나 공부를 할 때 가장 많이 사용하는 조합은 이 세 가지다.

"요즘 Claude와 GPT 중 어디가 좋다"라는 주제로 개발자, 컴퓨터 전공자들이 많이 싸우는 것 같은데 사실 둘 다 장단점이 확실하게 있다고 생각한다.

개인적으로 Claude는 회사 요금으로 사용할 때 뛰어난 문서 분석, 코딩, 에이전트 기능을 바탕으로 보고서 작성, 데이터 정리, 업무 자동화 등에 널리 쓰이는 생성형 AI라고 생각한다.

특히 긴 문서를 한 번에 읽거나 이미 존재하는 코드베이스의 구조를 빠르게 파악하는 능력은 굉장히 좋은 편이라고 느꼈다.

하지만 개인 요금으로 사용할 때는 토큰 한도나 사용량 제한이 꽤 신경 쓰이고, 프롬프트 내용이 부족하거나 컨텍스트가 꼬였을 때 할루시네이션이 발생하는 경우도 개인적으로 많이 겪었다.

그래서 개인 프로젝트 or 공부용으로는 ChatGPT, CODEX가 더 편하게 느껴졌다.

물론 Claude Code만으로 봤을 때는 CODEX보다 코딩을 더 잘한다고 느끼는 순간도 많았다. 특히 이미 어느 정도 만들어진 프로젝트에서 코드를 빠르게 이해하고 수정하는 작업은 Claude Code가 굉장히 잘한다고 생각한다.

결론적으로 무조건 어떤 AI가 더 좋다기보다는 내가 어떤 작업을 하느냐에 따라 달라진다.

그리고 OpenCode는 들어본 사람도 있고 모르는 사람도 있을 것이다. 일단 내 주변에서 사용하는 사람은 많이 없는 것 같다.
(이거 개좋은데 왜 아무도 모르지)

OpenCode를 처음 봤을 때 나도 그냥 또 하나의 AI CLI 정도로 생각했는데, 실제로 사용해보니 생각보다 자유도가 높아서 지금은 프로젝트를 만들 때 굉장히 자주 사용하고 있다.

먼저 화면을 보여주겠다.

WSL(Windows Subsystem for Linux)에서 OpenCode CLI를 실행한 화면이다.

OpenCode CLI는 GPT나 Claude 같은 AI 모델들을 터미널에서 사용할 수 있게 만들어주는 오픈소스 AI 코딩 에이전트다.

쉽게 설명하면 터미널 안에서 AI가 프로젝트 파일을 직접 읽고, 코드를 분석하고, 수정하고, 명령어까지 실행하면서 개발을 도와주는 방식이다.

일반적인 ChatGPT 웹에서는 내가 코드를 복사해서 보내고 답변을 받은 뒤 다시 직접 코드를 수정해야 하는 경우가 많지만, 이런 CLI 기반 에이전트들은 프로젝트 자체를 읽고 직접 파일을 수정할 수 있어서 개발 속도가 훨씬 빨라진다.

내가 OpenCode를 많이 사용하는 가장 큰 이유 중 하나는 무료로 사용할 수 있는 모델 선택지가 많고 사용량에 대한 부담이 비교적 적다는 점이다.

프롬프트 작성 실력만 어느 정도 있다면 비용 부담을 줄이면서도 CODEX나 Claude Code처럼 꽤 큰 프로젝트를 개발할 수 있다.

특히 테스트용 프로젝트나 새로운 아이디어를 빠르게 구현해볼 때 굳이 유료 모델의 토큰을 많이 사용하지 않아도 된다는 점이 좋다.

설치 방법도 엄청 간단하다.

WSL에서 아래 명령어를 작성하면 바로 설치가 완료된다.

curl -fsSL https://opencode.ai/install | bash

설치가 완료되고 아래 명령어를 치면 바로 위 사진처럼 프롬프트 입력창이 나온다.

opencode

여기까지만 설치해도 기본적인 코딩 에이전트 기능은 바로 사용할 수 있다.

프로젝트 디렉터리에서 OpenCode를 실행하면 현재 프로젝트의 파일을 읽고 코드를 분석할 수 있고, 원하는 기능을 설명하면 AI가 관련 파일을 찾아 수정하는 방식으로 작업한다.

아마 OpenCode를 처음 실행하면 위 사진처럼 Ultraworker 같은 기능은 없고 플랜 모드와 빌드 모드 정도만 있을 것이다.

이유는 oh-my-opencode 설정을 하지 않았기 때문이다.

oh-my-opencode는 간단하게 설명하면 OpenCode CLI의 성능과 사용성을 향상시켜주는 확장팩 같은 개념이다.

기본 OpenCode만 사용해도 충분히 개발할 수 있지만 oh-my-opencode를 추가하면 작업 목적에 따라 여러 에이전트나 모드를 나눠서 활용할 수 있기 때문에 복잡한 프로젝트를 할 때 훨씬 편하다.

설치 방법은 아래 명령어를 치면 설치 마법사가 작동하면서 설치를 도와줄 것이다.

npx oh-my-opencode install
# 또는 bunx 사용 시
bunx oh-my-opencode install

설치하면 여러 모드들을 활용할 수 있는데 내가 주로 사용하는 것은 Ultraworker, Deep Agent, Plan Builder다.

각각 역할이 조금씩 다르기 때문에 작업에 맞춰서 선택하면 된다.

Deep Agent

복잡하고 큰 규모의 과제를 해결하기 위해 AI가 스스로 리서치와 코드 분석, 실행을 병행하도록 역할을 부여받은 전담 전문 에이전트 세트 및 실행 모드다.

예를 들어 단순히 버튼 하나 추가하는 작업보다는

프로젝트 전체 구조 분석
여러 파일에 걸친 오류 원인 추적
새로운 라이브러리 조사
기존 코드 구조에 맞는 기능 설계

처럼 한 번에 여러 단계가 필요한 작업에 사용하는 편이다.

내가 직접 하나씩 파일을 지정하지 않아도 모델이 필요한 파일들을 찾아보면서 작업하기 때문에 큰 프로젝트를 분석시킬 때 편하다.

Ultraworker

이 모드는 그냥 올라운더라고 생각하면 된다.

간단한 기능 추가부터 코드 수정, 오류 해결, 파일 생성 등 일반적인 개발 작업에서는 대부분 이 모드를 사용한다.

굳이 깊은 조사나 장시간 분석이 필요하지 않을 때는 Deep Agent를 사용하는 것보다 Ultraworker로 빠르게 작업시키는 것이 더 효율적인 경우가 많다.

그래서 나는 평소에

"이 컴포넌트 디자인 수정해줘."
"이 API 오류 원인 찾아서 수정해줘."
"현재 페이지 모바일 반응형 적용해줘."

같은 작업들은 대부분 Ultraworker로 처리한다.

Plan Builder

계획할 때 사용하기 좋은 모드다.

파일 수정 기능이 꺼져 있어서 프로젝트를 직접 수정하지 않고 현재 프로젝트의 구조를 탐색하고 어떤 식으로 작업해야 할지 계획을 만들 수 있다.

이 기능이 생각보다 중요한 이유는 AI한테 바로

"이 기능 만들어줘"

라고 시키는 것과

"먼저 프로젝트 전체를 분석하고 구현 계획부터 만들어줘"

라고 시키는 것의 결과 차이가 굉장히 크기 때문이다.

특히 프로젝트 규모가 커질수록 AI가 아무 계획 없이 바로 코드를 수정하기 시작하면 기존 기능과 충돌하거나 이상한 파일을 새로 만드는 경우가 생긴다.

그래서 계획이 아직 없을 때는 이 모드를 사용해서 프로젝트를 탐색하고, 어떤 파일을 수정해야 하는지와 구현 순서를 먼저 정한 뒤 실제 개발에 들어가는 편이다.

간단하게 OpenCode의 기능을 설명했다.

다음은 OpenCode에서 내가 자주 사용하는 AI_MODEL들을 설명하겠다.

OPENCODE MODEL 소개

위 사진처럼 엄청 많은 모델이 있지만 그중 내가 자주 사용하는 모델은 Muse Spark 3.5와 Hy3 Free다.

모델이 많다고 해서 무조건 가장 성능이 좋은 모델 하나만 계속 사용하는 것은 아니다.

간단한 작업에 너무 무거운 모델을 사용하면 응답 속도가 느려지고, 반대로 복잡한 작업에 가벼운 모델을 사용하면 코드를 제대로 이해하지 못하는 경우가 생기기 때문이다.

그래서 나는 작업 난이도에 따라 모델을 바꾸면서 사용한다.

Muse Spark 3.5는 내가 사용해본 OpenCode 네이티브 멀티모달들 중 가장 성능이 좋다고 느꼈고, 프롬프트를 어느 정도 대충 작성해도 내가 원하는 의도를 잘 이해하는 편이어서 가장 많이 사용하는 모델이다.

프로젝트 구조를 분석하거나 여러 파일을 동시에 수정해야 하는 작업에서도 생각보다 잘 따라와준다.

특히 내가 프롬프트를 완벽하게 정리하지 않고

"여기 UI 이상한 부분 알아서 찾아서 전체적으로 수정해줘."

처럼 조금 애매하게 이야기해도 어느 정도 의도를 파악하는 편이라 편하다.

Hy3 Free는 친구가 추천해줘서 처음 사용하게 되었다.

직접 써봤는데 프롬프트 이해, 구상, 생각 속도가 다른 모델들과 비교했을 때 내 기준으로 한 2~3배 정도 빠르게 느껴졌다.

물론 복잡한 추론이나 대규모 코드 수정에서는 성능 차이가 느껴지는 경우가 있지만, 빠른 작업이 필요할 때 어느 정도 성능을 타협하면서 쓰기에는 굉장히 편하다.

예를 들어

간단한 오류 수정
CSS 수정
컴포넌트 생성
간단한 API 구현

같은 작업에서는 굳이 무거운 모델을 사용할 필요가 없기 때문에 Hy3 Free를 자주 사용하는 편이다.

결국 OpenCode에서는 무조건 하나의 모델만 사용하는 것보다 작업에 따라 모델을 바꾸는 방식이 가장 효율적이라고 생각한다.

다음은 내가 가장 많이 사용하는 Codex를 설명하겠다.

Codex 사용 가이드

Codex를 간단하게 소개하자면 OpenAI가 만든 AI 코드 에이전트다.

현재 내가 가장 아끼고 사랑하는 에이전트다.
(사랑해요 Codex!)

Codex를 본격적으로 사용하기 전에는 AI한테 코드를 하나씩 물어보고 직접 파일을 수정하는 방식으로 개발했는데, Codex를 사용한 이후에는 아예 프로젝트 단위로 일을 맡기는 경우가 많아졌다.

단순히 코드를 작성하는 것뿐만 아니라 현재 프로젝트의 파일들을 분석하고, 오류를 찾고, 테스트를 실행하고, 문제가 발생하면 다시 수정하는 과정까지 어느 정도 맡길 수 있어서 혼자 프로젝트를 개발할 때 굉장히 편하다.

토큰 한도도 전에는 5시간 한도, 7일 한도 이렇게 두 개여서 조금 사용하면 바로 5시간 한도에 걸려서 불편했는데, 최근에는 사용 가능한 한도가 바뀌면서 예전보다 장시간 작업하기 편해졌다.

나는 프로젝트를 개발할 때 Codex를 굉장히 많이 사용하는 편이라 가끔 하루 만에 주간 사용량을 엄청 많이 사용하기도 한다.

OpenAI에서 제공되는 초기화권까지 사용하면서 돌리고 있으면 진짜 한도 초과 버닝 이벤트를 하는 기분이 든다.

위 사진은 현재 내가 Codex를 돌리고 있는 화면이다.

현재 하고 있는 웹 프로젝트의 코드를 최적화하고, 오류를 디버깅&수정하는 작업을 goal이라는 스킬을 사용해서 시키고 있다.

Codex도 단순히 프롬프트만 입력하는 것이 아니라 작업 방식에 따라 여러 스킬과 기능을 활용할 수 있다.

내가 실제 프로젝트에서 많이 사용하는 기능들을 설명해보겠다.

goal(목표 모드)

현재 한국어에서는 "목표"라는 스킬인데, user가 요청한 목표가 완료될 때까지 계속 작업하도록 만드는 기능이다.

쉽게 말하면

"이 오류 수정해줘."

라고 한 번 시키고 끝나는 방식이 아니라,

오류 원인을 찾고 → 코드를 수정하고 → 테스트하고 → 새로운 오류가 생기면 다시 수정하는 과정을 반복하면서 최종 목표를 최대한 완료하는 방식이라고 보면 된다.

그래서 내가 Codex를 사용할 때 가장 많이 쓰는 기능 중 하나다.

특히 프로젝트 전체 오류 수정이나 리팩토링처럼 작업 시간이 오래 걸리는 경우에는 직접 중간중간 프롬프트를 다시 보내지 않아도 계속 작업할 수 있어서 편하다.

1시간, 2시간처럼 작업이 길어져도 사용 가능한 한도가 남아 있다면 목표를 완료하기 위해 계속 작업하도록 맡기는 편이다.

다만 goal을 사용할 때는 처음 목표를 애매하게 작성하면 AI가 내가 원하지 않는 방향으로 오랫동안 작업할 수도 있기 때문에 처음 목표를 정확하게 작성하는 것이 중요하다.

예를 들어

"프로젝트 고쳐."

보다는

"현재 웹 프로젝트 전체를 분석해서 TypeScript 오류와 빌드 오류를 모두 수정하고, 기존 기능이 깨지지 않는지 테스트까지 진행해줘."

처럼 완료 조건을 같이 작성하는 게 훨씬 좋다.

Plan(계획 모드)

OpenCode에도 있던 기능인데 간단하게 설명하면 user가 보낸 프롬프트와 현재 프로젝트를 바탕으로 모델 스스로 작업 계획을 세우는 기능이다.

나는 프로젝트를 시작할 때 바로 goal부터 돌리는 것보다 Plan + goal 조합을 많이 사용한다.

먼저 Plan으로

현재 프로젝트 구조 분석
문제점 확인
수정해야 할 파일 정리
구현 순서 결정
테스트 방법 결정

까지 계획을 세운다.

그다음 그 계획이 마음에 들면 goal을 사용해서 그대로 실행시킨다.

이 방법을 사용하면 AI가 무작정 코드를 건드리는 것보다 훨씬 안정적으로 작업하는 편이다.

특히 프로젝트 규모가 커질수록 Plan 단계가 중요하다.

작은 프로젝트는 파일이 몇 개 없어서 AI가 바로 수정해도 큰 문제가 없지만, 수십~수백 개의 파일이 있는 프로젝트에서는 잘못된 방향으로 수정하기 시작하면 되돌리는 것도 일이기 때문이다.

그래서 나는 가능하면

Plan으로 생각시키고 → 내가 계획을 확인하고 → goal로 실행

하는 방식을 사용한다.

상태

이 기능은 위 사진처럼 내 토큰 한도가 어느 정도 남았는지, 현재 컨텍스트가 얼마나 남았는지 확인할 수 있다.

생각보다 컨텍스트 확인이 중요하다.

AI랑 대화를 오래 하다 보면 처음에 이야기했던 내용들이 컨텍스트에서 밀려나면서 모델이 이전 요구사항을 제대로 기억하지 못하는 경우가 생긴다.

그래서 대규모 프로젝트를 오랫동안 작업할 때는 컨텍스트가 얼마나 남아 있는지 확인하면서 필요하면 새 세션을 만들거나, 지금까지 진행한 작업을 문서로 정리한 다음 새로운 세션에서 이어가는 편이다.

특히 AI가 갑자기 이상한 코드를 작성하거나 이미 수정한 내용을 다시 되돌리기 시작한다면 컨텍스트가 너무 복잡해진 건 아닌지 확인해보는 것도 좋다.

지금까지 Codex의 스킬과 기능을 간단하게 소개했다.

다음은 내가 실제로 혼자 프로젝트를 개발할 때 이런 AI들을 어떤 식으로 활용하는지 설명하겠다.

프로젝트 개발 때 AI 활용법

먼저 나는 간단한 웹사이트부터 사업 정도 사이즈의 프로젝트까지 여러 프로젝트를 개발해봤다.

AI를 활용할 때 가장 중요한 것은 AI한테 모든 걸 맡기는 것이 아니라 내가 프로젝트의 방향을 잡고 AI를 이용해서 속도를 높이는 것이라고 생각한다.

AI가 아무리 좋아져도 프로젝트가 왜 필요한지, 어떤 사용자에게 제공할 것인지, 어떤 기능이 핵심인지까지 전부 AI에게 맡기면 결과물이 애매해지는 경우가 많다.

그래서 최소한 프로젝트의 핵심 아이디어와 방향은 내가 먼저 정하고 그 이후에 AI를 사용한다.

이제 간단한 프로젝트 ~ 복잡한 대규모 프로젝트까지 내가 AI를 어떤 식으로 활용하는지 설명하겠다.

간단한 프로젝트

간단한 프로젝트를 진행할 때는 먼저 내가 정말 간단한 플랜을 만든다.

예를 들어 간단한 공부 사이트를 만든다고 하면

- 로그인
- 문제 목록
- 정답 확인
- 사용자 기록 저장

정도로만 작성한다.

처음부터 DB 구조, API 설계, 컴포넌트 구조까지 내가 전부 작성하지는 않는다.

이 간단한 플랜을 OpenCode Plan 모드에 넣고 좀 더 자세하고 전문성 있게 재구성한다.

그러면 AI가

사용할 기술 스택
필요한 페이지
API 엔드포인트
개발 순서

같은 내용을 추가해서 좀 더 개발 가능한 형태의 계획으로 만들어준다.

계획이 괜찮으면 Ultraworker 모드로 개발을 시작한다.

나는 개발을 완전히 방치하지 않고 대략 1시간 간격으로 어느 정도 개발되었는지 보고서를 받는다.

보고서를 보면서

어떤 기능이 완료됐는지
어떤 오류가 발생했는지
다음 작업이 무엇인지

확인한다.

그리고 내가 직접 빠르게 수정할 수 있는 부분은 직접 수정한다.

예를 들어 CSS 몇 줄 수정하거나 단순한 변수명 변경 같은 것까지 굳이 AI한테 맡기면 토큰과 시간이 아깝기 때문이다.

AI는 사람이 직접 하기 귀찮거나 오래 걸리는 부분을 맡기고, 내가 빠르게 할 수 있는 부분은 직접 수정하는 방식이 가장 효율적이라고 생각한다.

이런 식으로 개발하면 규모에 따라 다르지만 비교적 짧은 기간 안에 하나의 프로젝트를 완성할 수 있다.

예전에는 혼자 2~3주 걸렸을 기능들도 AI를 잘 활용하면 훨씬 빠르게 목업이나 MVP까지 만들 수 있다.

복잡한 대규모 프로젝트

대규모 프로젝트는 방식이 조금 다르다.

간단한 프로젝트처럼 아이디어 하나 던지고 바로 개발을 시작하면 나중에 거의 무조건 구조를 다시 뜯어고치게 된다.

팀원이 있다면 여러 번 회의를 하고 계획을 수립하겠지만, 혼자 프로젝트를 진행한다면 회의할 사람이 없다.

그래서 나는 엄청 유능한 AI 모델을 하나의 팀원처럼 사용하면서 의견을 조율한다.

위 사진처럼 먼저 GPT에게 내가 관심 있어 하는 분야나 조건을 설명하고 여러 프로젝트 주제들을 가져오게 한다.

예를 들면

"정보보안 분야에서 고등학생이 개발할 수 있지만 실제 서비스까지 확장할 수 있는 대규모 프로젝트 아이디어를 추천해줘."

처럼 요청한다.

여러 주제를 받은 다음 내가 재미있어 보이는 프로젝트를 하나 고른다.

그다음 바로 개발하는 것이 아니라 GPT랑 계속 대화하면서 프로젝트를 좀 더 구체화한다.

예를 들어

이 프로젝트가 해결하려는 문제가 무엇인지
실제 사용자는 누구인지
기존 서비스와 차별점은 무엇인지
핵심 기능은 무엇인지
어떤 기술 스택을 사용할지
보안적으로 고려할 부분은 무엇인지
나중에 어떻게 확장할 수 있는지

같은 내용을 계속 이야기한다.

이 과정을 거치면서 처음에는 단순했던 아이디어가 점점 실제 프로젝트 기획서처럼 구체적으로 변한다.

어느 정도 아이디어가 정리되면 이제 개발용 프롬프트를 만든다.

처음 만든 프롬프트를 그대로 Codex에 보내지는 않는다.

한 번 GPT한테

"이 내용을 실제 AI 코딩 에이전트가 이해하고 개발할 수 있도록 더 자세하고 전문적인 개발 프롬프트로 재가공해줘."

라고 요청한다.

그러면 단순한 아이디어를 실제 개발에 필요한 요구사항으로 변환할 수 있다.

예를 들어

로그인 기능 만들어줘.
게시판 만들어줘.
보안 기능 넣어줘.

정도였던 프롬프트가

- 인증 방식
- 사용자 권한 구조
- 데이터베이스 스키마
- API 설계
- 프론트엔드 구조
- 입력값 검증
- 에러 처리
- 보안 요구사항
- 테스트 조건

까지 포함된 훨씬 구체적인 프롬프트가 된다.

그다음 재가공한 프롬프트를 Codex에 전달한다.

이때 모델의 추론 강도를 높게 설정하고 먼저 Plan으로 프로젝트 구조와 구현 계획을 만들게 한다.

계획을 확인했는데 크게 문제가 없다면 goal을 사용해서 초기 프로젝트 목업을 만든다.

처음부터 완벽한 서비스를 만들려고 하지는 않는다.

먼저

로그인 → 핵심 기능 → DB 연결 → 기본 UI

정도까지 작동하는 초기 목업을 만든다.

그다음 실제로 내가 실행해보면서 필요한 기능을 하나씩 추가한다.

예를 들어

"현재 로그인 기능에 OAuth 추가해줘."
"관리자 페이지 만들어줘."
"모바일 반응형 수정해줘."
"현재 API 구조에서 발생할 수 있는 보안 문제를 분석해줘."
"전체 프로젝트 테스트하고 오류를 수정해줘."

같은 방식으로 점점 프로젝트를 확장한다.

중간중간 코드가 너무 복잡해지면 리팩토링도 시키고, 프로젝트 전체를 다시 분석해서 구조상 문제가 있는 부분을 찾아달라고 요청하기도 한다.

이런 식으로 기획 → 계획 → 초기 목업 → 기능 추가 → 테스트 → 리팩토링 과정을 반복하면서 프로젝트를 완성해간다.

개인적으로 AI를 사용해서 프로젝트를 만들 때 가장 중요한 것은 프롬프트를 엄청 길게 쓰는 것이 아니라 AI가 현재 뭘 해야 하는지 명확하게 알 수 있게 만드는 것이라고 생각한다.

그리고 AI가 작성한 코드를 무조건 믿으면 안 된다.

AI가 아무리 성능이 좋아도 존재하지 않는 라이브러리를 사용하거나, 이미 deprecated된 코드를 작성하거나, 보안상 위험한 방식으로 기능을 구현하는 경우가 있다.

그래서 최소한 내가 작성된 코드를 어느 정도 읽을 수 있어야 하고, 문제가 발생했을 때 어떤 부분을 확인해야 하는지는 알고 있어야 한다.

결국 AI는 개발자를 완전히 대신해주는 도구라기보다는 내가 할 수 있는 일을 훨씬 빠르게 만들어주는 개발 도구에 가깝다고 생각한다.

나는 지금도 프로젝트를 만들면서 계속 AI 사용 방법을 바꾸고 있다.

예전에는 단순히

"코드 작성해줘."

라고 했다면 지금은

"먼저 프로젝트를 분석하고 계획을 만들어. 기존 구조를 최대한 유지하고, 변경 이유와 테스트 결과까지 정리해줘."

처럼 훨씬 작업 단위로 요청하는 편이다.

AI 모델 성능도 계속 발전하고 있고 새로운 코딩 에이전트도 계속 나오고 있기 때문에 지금 사용하는 방법이 몇 달 뒤에는 또 바뀔 수도 있다.

그래도 현재까지 사용해본 방식 중에서는 내가 방향을 잡고, AI에게 계획과 반복 작업을 맡기고, 결과를 직접 검토하면서 개발하는 방식이 가장 잘 맞는 것 같다.

다음 글에서는 가능하면 내가 실제 프로젝트에서 사용하는 프롬프트 작성 방식이나, AI한테 프로젝트를 맡겼을 때 자주 발생하는 문제와 해결 방법도 정리해보려고 한다.

긴글 읽어주셔서 감사합니다.

김건우

보안 프로그램 엔지니어 & 프론트엔드 개발자 지망합니다

2개의 댓글

_뉴비_

2026년 8월 24일

1빠

1개의 답글