- AI를 잘 쓰고 있는지 AI에게 물어봤다2026년 05월 24일 14시 52분 58초에 업로드 된 글입니다.작성자: 핀수728x90반응형
들어가며
AI를 활용한 코드 작성은 어느새 자연스러운 행위가 되었다.
지금 작업 중인 사이드 프로젝트도 React Native로 개발하고 있다.
나는 원래 안드로이드 네이티브를 주로 개발해왔는데, AI의 발전 덕분에 Flutter나 React Native 같은 다른 스택도
예전보다 훨씬 가볍게 시도해볼 수 있게 되었다.
물론 그렇다고 해서 기술 스택에 대한 이해가 필요 없어졌다고 생각하지는 않는다.
아직은 사람의 능력을 더 믿는다..!
다만 개인 각각의 전문성이 점점 AI 활용 능력 하나로 덧씌워지고 있는 시점이라는 생각은 든다.
같은 AI를 사용하더라도 어떤 사람은
단순히 코드를 생성하는 데 그치고,
어떤 사람은 문제를 정의하고,
범위를 줄이고,
결과를 검증하며 더 나은 방향으로 끌고 간다.
그렇다면 나는 AI를 어떻게 활용하고 있을까?
4년 넘게 이어지고 있는 스터디 동료 덕에 알게된 Vibe-sunsang, 일명 바선생을 한번 사용해봤다.
Vibe-sunsang (바선생)이란?
GitHub - fivetaku/vibe-sunsang: AI mentor agent for vibecoders on Claude Code — conversation analysis, mentoring, growth repor
AI mentor agent for vibecoders on Claude Code — conversation analysis, mentoring, growth reports - fivetaku/vibe-sunsang
github.com
바선생은 AI와 나눈 대화를 분석해 사용자의 AI 활용 방식을 진단하고 멘토링해주는 도구다.
단순히 '프롬프트를 잘 썼는가?' 만 보는 것은 아니다.
작업을 어떻게 나누는지, AI에게 충분한 맥락을 제공하는지, 결과물을 검증하는지, 실패 상황에 어떻게 대응하는지
같은 요소를 함께 본다(고 한다.)
바선생에서는 AI 활용 능력을 크게 여섯 가지 축으로 나눈다.
(자세한 내용은 위 링크를 참고하면 된다.)
- 작업 분해
- 검증 전략
- 오케스트레이션
- 실패 대응
- 맥락 관리
- 메타인지
그런데 한 가지 문제가 있었다.
바선생은 기본적으로 Claude 대화를 기준으로 동작하는 도구인데,
나는 Codex를 주로 사용하고 있다.
다행히 Codex도 로컬에 대화 로그를 저장하고 있어서
Codex의 jsonl 로그를 Markdown 형태로 변환하고, 프로젝트별로 정리해 바선생이 읽을 수 있도록 했다.
(알고 있겠지만 Codex가 한것이다.)
나는 AI를 어떻게 활용하고 있을까?
현재 작업 중인 사이드 프로젝트를 대상으로 분석했다.

실제로 써보실 분들은 성장 리포트를 꼭 생성해서 보시길 바란다.
자세하게 나와 있어 도움이 많이 된다.
나의 활용 능력을 2-3문장으로 요약하면 아래와 같다.
당신은 AI에게 단순히 '구현해줘' 라고 맡기는 수준을 넘어서, API 계약·권한 정책·OS 제약·운영 리스크
까지 맥락으로 제공하며 작업을 주도하는 L4.5 Pilot+ 수준의 Builder입니다.
강점은 맥락 제공과 작업 분해이고, 다음 성장 포인트는 AI를 한 명의 실행자처럼 쓰는 것에서 벗어나
분석자 / 구현자 / 검증자 역할로 나눠 운영하는 오케스트레이션입니다.
출처 : Vibe-sunsang github 
출처 : Vibe-sunsang github AI 활용 능력을 높이기 위해 실천할 것?
1. 큰 작업을 요청할 때 끝에 검증 기준을 붙이기
- 작업 후 변경 파일, 영향받는 화면/API, 실패 케이스, iOS/Android 차이, 수동 테스트 절차를 정리하기
2. 바로 구현시키지 말고 먼저 역할별 검토를 시키기
- 구현하지 말고 먼저 분석자/구현자/검증자 관점으로 나눠 계획을 세우기
3. 요청 범위가 커지면 새 작업으로 끊기
- 이건 기존 작업과 별도 이슈로 보고, 새 TODO로 계획부터 세워달라고 하기
4. AI가 실수하면 고쳐달라고 하기 전에 원인 회고를 요청하기
- 왜 이 실수가 발생했는지, 내 지시의 모호한 부분과 AI가 임의 추론한 부분을 나눠 정리하기
5. 구현 승인 전에 완료 기준을 확인하기
- 이 작업이 완료됐다고 판단할 기준을 먼저 5개로 정리해달라고 하기
6. 반복되는 작업은 템플릿화하기
- 예: 계획 -> 승인 -> 구현 -> 검증 -> 커밋 메세지 -> 회고 흐름을 AGENTS.md나 개인 메모에 고정하기
7. 긴 세션 중간에 상태 정리를 요구하기
- 지금까지 결정된 것, 변경된 것, 남은 것, 위험한 것을 나눠 정리하기
느낀 점
예전에는 하나의 기술 스택에 대한 깊이 있는 지식을 쌓는 것이 취업과 개인의 성장에 가장 적합한 방법이라고 생각했다.
물론 지금도 그 생각이 완전히 틀렸다고 보지는 않는다.
기술에 대한 이해 없이 AI가 만들어준 결과를 그대로 받아들이는 것은 꽤 위험하다.
하지만 지금은 그 위에 다른 능력들이 덧붙고 있는 것 같다.
- AI에게 질문하는 능력
- 문제를 정의하는 능력
- 결과를 의심하는 능력
- 필요 없는 구현을 멈추는 능력
- AI가 만든 결과를 내 책임으로 받아들일 수 있는 판단력
이런 것들이 점점 더 중요해지고 있다는 생각이 든다.
AI를 화려하게 잘 쓰는 것도 중요하다.
새로운 도구를 빠르게 익히고, 여러 모델과 플러그인을 조합하고, 자동화 흐름을 만드는 능력도 분명히 가치가 있다.
하지만 그보다 더 본질적인 능력에 대한 탐구가 필요하다고 느꼈다.
무엇을 만들것인가
왜 만들어야 하는가
어디까지 AI에게 맡길 것인가
결과를 어떤 기준으로 검증할 것인가
그런데 문제는 이런 능력을 어떻게 보여줄 수 있느냐다..
예전에는 사용한 기술 스택, 구현한 기능, 해결한 버그를 보여주면 됐다.
그런데 AI와 함께 일하는 능력은 결과물만 봐서는 잘 드러나지 않는 것 같다..
이에 대한 고민도 함께 해봐야겠지? 참 쉬운게 하나 없다. ㅋㅋ
AI가 일을 대신 해주는 시대라면,
나는 내가 어떤 개발자로 남을 수 있을지 계속 자문해야할 것 같다.
728x90반응형'pinslog > Log.daily()' 카테고리의 다른 글
AI로 친구들의 영웅이 되는 법 (feat. 개발자가 AI를 대하는 자세) (0) 2026.05.22 가장 훌륭한 코드는 작성하지 않은 코드다: 입사 3주 만에 프로젝트 중단을 건의한 이유 (0) 2026.04.07 [git] git stash 쓰다 식겁한 이야기 (4) 2024.07.03 [Kotlin] Kotlin Destructuring (0) 2023.12.27 [Kotlin] takeIf (0) 2023.12.26 다음글이 없습니다.이전글이 없습니다.댓글