들어가기에 앞서

의식의 흐름대로 적어 텍스트가 많아 가독성이 안좋을 수 있습니다. 양해 부탁드립니다.

바이브 코딩과의 첫 만남

처음 회사에 들어갔을 때, 바이브 코딩이라는게 유행해 커서로 모든 작업을 진행했었는데 회의감이 많이 들었었다.

AI가 코드를 다 짜면 나는 뭘하지 ? 내가 개발자가 맞는건가? 이런 생각이 머리 속에서 떠나지 않았었다. 그래서 AI의 도움없이 스스로 해결을 하려 했었던 적도 있었다.

하지만 AI 도움 없이 작업을 진행하면 작업 속도가 전 만큼 나오지 않았다. 즉, 아웃풋이 너무 부족했다.

커서의 도움으로 여러 일을 처리하면서 AI에게 화도 정말 많이 냈었다. 의도대로 하지도 않고 맥락 파악도 잘 못하고, 자기 맘대로 수정하는 행동에 애꿎은 AI에게 감정을 소모한적도 있었다.

그러면서 요즘 핫한 클로드 코드라는 것이 나와 써봤었는데 정말 신세계였다.

처음에는 불편한 사항이 몇가지 있었다. 평소에 JetBrains나 Cursor같은 IDE툴을 사용하다가 CLI 터미널 환경에서 사용하려니 너무 불편한점이 많았다.

이미지 넣는것도 불편하고, UI 부분이 많이 불편했다. 하지만 당시에 내가 느꼈을 때 커서보다 문맥 파악도 잘하고, 성능도 훨씬 좋았다. 그래서 당시에는 커서보단 클로드 코드를 주로 사용 했었다.

이때쯤 “아.. 이제는 내가 직접 손으로 코딩을 하는 것보다 이러한 도구들을 잘 활용해야겠구나.. 이게 지금 시대의 흐름이구나” 라는 생각이 들었다.

야근 중 회사 시니어분이랑 같이 저녁을 먹을 때 이 이야기를 했더니, 본인도 처음에 바이브 코딩이란 것에 회의감이랑 불신이 있었는데 지금은 나랑 똑같은 생각을 한다고 하셨다.

“이제는 직접 코드를 치는 것보다는 이런 도구들을 잘 활용해서 구조를 잘 짜고, 오케스트레이션을 할 수 있는 능력을 길러야할 것 같다.” 고 하셨다. 매우 공감했다.

이시기에 AI 활용하는 방법에 대해 엄청 공부하며 어떻게 하면 AI를 잘 활용할 수 있을지 팀원들과 공유를 했다.

skills와 sub agents 활용

당시에 Skills라고 클로드 코드에서 처음 나왔었다. 기존에 반복했었던 작업들을 획기적으로 줄일 수 있는 방법이었다.

처음 사용했을 때는 내가 주로 반복했었던 것들을 만들어서 사용했었다.

git-commit-convention을 skills로 만들어서 항상 이것을 따르게하고, 작업이 끝나면 빌드 테스트와 코드리뷰까지 진행하는 skills도 만들어서 사용했다.

반복하던 작업들을 단순화하고, skills 모아둔 곳에서 나에게 필요한 것들을 골라서 넣기 시작했다. 사실 여러 스킬이 있지만 내가 skills로 만든것들 말고는 잘 사용하고 있는지는 잘 모르겠다.

내가 느꼈을 때 skills는 자주 반복하던 것을 줄이는데 효과적이라고 생각한다. 다른 사람의 skills를 가져오는건 솔직하게 체감이 잘 되는 것 같지가 않다.

Skills를 잘 사용하고 있을 때쯤 클로드 코드가 Sub Agents를 업데이트했다.

공식 문서를 보고 충격을 받았다.

“와 에이전트가 서브 에이전트를 호출해서 병렬로 작업을 한다고?”

이때 서브 에이전트를 사용하며 작업 속도가 압도적으로 빨라졌었다.

회사 규모는 작았지만, 동일한 시간 기준으로 완료한 태스크 양에서 가장 높았다.

어떻게 하면 AI를 잘 활용할 수 있을까

“어떻게 하면 AI를 잘 활용할 수 있을까 ?”에 대한 고민을 항상했다.

여러 유튜브를 찾아보고, 클로드 코드 공식 문서에서 Best Practice도 찾아보고

내가 회사, 사이드 프로젝트에서 쓰는 방법과 다른 사람들이 사용하는 방법에서 어떤점이 다른지 찾아보았다.

처음에 커서를 사용할 때는

“댓글 기능을 만들거야 만들어줘” 이런 방식의 ~해줘를 사용하고 있었다.

하나씩 바꿔가면서 작업을 했었다.

“댓글 기능을 만들거야, 대댓글도 할 수있어야하고 대댓글은 글쓴이만 쓸 수 있어야하해 계획 만들어줘” 이런식으로 상세하게 지시하고 계획을 만들어 그 계획을 보고 수정할 부분은 수정하고 진행을 했었다. 훨씬 효율적이었다.

단순히 ~해줘 했을 때는 추가적인 작업이 필요 했었다.

기본적으로 내가 생각했을 때는 댓글 기능을 만들면 대댓글 기능이 있어야했기에 그냥 댓글 기능을 만들어줘라고 단순하게 프롬프트를 입력했었다. 하지만 AI는 이것을 당연하게 생각하지 않는다. 그렇기에 내가 원하는 것을 명시해서 알려줘야 의도한 대로 잘 동작했다.

이후 Plan을 쓴 이후부터는 진짜 단순 작업을 제외하고는 항상 Plan을 세우고 Plan을 리뷰하고 업데이트하여 작업을 진행했다.

이때 문서를 얼마나 잘 만드는지, 얼마나 고도화를 잘 해야하는지 느꼈다.

이러한 방식은 최근까지 이어져오고 있는데, 처음에는 Plan 모드를 사용해 CLI 내부에서 Plan을 보고 피드백 및 수정을 했다면 이제는 docs라는 폴더를 새로 만들어 md파일로 정리한다.

만들어진 md파일을 codex, gemini에 던져서 피드백을 시키고 그 피드백을 바탕으로 md파일을 디벨롭하며 문서를 고도화시켜 작업을 진행했다.

docs라는 폴더로 정리하면 좋은 이점이 몇 가지가 있다.

첫 번째로, 동료와 공유할 수 있다.

어떤 방식으로 작업했는지, AI에게 어떤식으로 질문했는지, 고려한 점이 무엇이 있는지, 빼먹은 부분은 있는지 알 수 있다. docs폴더에 저장되어 있으니 동료들이 어느 방식으로 진행했는지 알 수 있다.

두 번째로는 여러 AI와 협업할 수 있다.

만들어진 md파일을 gpt모델인 codex와 gemini에게 공유해 놓치고 있는점이 있는지, 더 디벨롭할 부분이 있는지, Flow에 문제가 있는지 피드백을 받을 수 있는 장점이 있다.

omx의 발견 및 워크 플로우

요즘은 Claude Code 토큰이 빠르게 소모되는 이슈가 있어서 Pro 모델 한도를 5분만에 다 사용하는 기이한 상황이 발생하여 Codex로 넘어갔다.

Codex는 Claude Code랑 비교했을 때, 도구들이 좀 부족하다고 느꼈다. (Skills나 Sub Agents나 차이점이 느껴졌었다.)

그러다 oh-my-codex를 사용해봤는데 Skills나 Sub Agents를 처음 사용했을 때의 새로움을 느꼈다.

omx(oh-my-codex)는 tmux에서 돌아가고 멀티 에이전트를 사용한다. 사실 간단한 작업을 할 때는 omx를 굳이 사용할 필요가 없다. 하지만 나는 codex 한도가 많아 단순 작업도 omx를 사용한다.

사용 방법도 명확했다.

$deep-interview를 통해 목적을 구체화한다. 문서를 만들 때 의도와 목적이 분명하지 않을 때가 있다. 이때 deep-interview를 통해 의도와 목적을 명확하게 설정하고 계속해서 고도화를 진행한다.

deep-interview를 통해 의도와 목적이 고도화가 됐다면, $ralplan을 통해 명확해진 범위 내에서 승인된 아키텍처 및 구현 계획을 수립한다.

이제 계획을 바탕으로 $ralph와 $team 중에 선택을 하여 실행을 하면 되는데, ralph는 에이전트 하나가 지속적인 작업과 피드백 루프를 돈다. 반면에 team은 Agent team을 만들어 계획을 병렬로 작업한다.

ralph는 비교적 간단한 작업에 주로 사용하고 team은 작업 규모가 충분히 클 때 사용을 한다.

$ralph와 $team은 CLI 화면에서도 차이가 있다.

ralph를 사용할 땐 일반 CC나 Codex를 사용하는 것과 동일하다. 작업 - 검증이 CLI 화면에서 loop를 돈다.

결정적인 차이는 team기능에 있는데 omx는 tmux를 사용한다고 했다.

tmux에는 pane이라는 기능이 있는데, team 기능을 사용하면 메인(오케스트레이터) 에이전트가 pane을 추가해 다른 에이전트를 호출하여 병렬로 작업하고, 병렬 작업하는 것이 CLI에 보인다.

$team 기능을 사용하면 이런식으로 pane을 만들어서 병렬작업을 진행한다.

CLI에서 서로 세션을 주고 받는게 보이고 병렬 작업하는것이 시각적으로 보이는 장점이 있다. 최근에는 이런식으로 $deep-interview → $ralplan → $ralph/$team Flow로 작업을 진행한다.

마무리

지금까지 내가 어떻게 AI를 다뤄왔는지 간단하게 흐름을 쭉 나열했다.

최근에는 프로덕트 엔지니어라는 직군이 생겼다.

특정 기술 스택이나 역할에 제한되지 않고, 필요한 기술을 빠르게 학습하고 적용하여 프로덕트를 만드는 직군이다.

내가 생각했을 때는 이제 특정 기술 스택의 의미가 옅어진 것 같다.

이제는 개발자가 목적에 맞게 기술 스택을 선택할 수 있다. AI가 발전함에 따라 긍정적이게 바뀐 것은 특정 기술을 배우는게 쉬워지고 접근에 두려움이 없다는 것이다.

처음 입사했을 때 나는 Java, Spring, 간단한 JS정도밖에 할 줄 몰랐다. node.js와 그 생태계에 대해서 아는 것이 없었다.

하지만 AI와 프로젝트 분석하고 문제들을 해결하다보니, 자연스럽게 구조가 보였고 자신감이 붙었다.

이후 Flutter 프로젝트를 처음 했을 때도, FastAPI 프로젝트를 진행했을 때도 처음 해보는 환경이라 두려움이 생기거나 자신감이 떨어지거나 하지 않았다.

오히려 처음 보는 구조에서 프로젝트를 분석하며 새로 배우는것과 낯선 환경에서 문제를 해결할 때마다 재미있었다.

회사에서도 느꼈지만 AI는 사용하는 사람에 따라, 어떻게 사용하는지에 따라 아웃풋이 다르다.

같은 도구와 같은 시간이 주어지더라도 어떻게 사용하는지에 따라 천차만별이다.

앞으로는 AI를 다루는 것은 기본이고, 잘 활용하는 것이 중요한 것 같다.

현재 개발에 대한 패러다임의 변화가 잦다.

AI를 어떻게 잘 활용할 수 있을지, 어떻게 내 work-flow에 녹일 수 있을지 고민하고 새로운 방식을 받아들이고 공부 해야한다.

계산기가 나왔는데 언제까지나 주판을 사용할 이유는 없다.