바이브 코딩(Vibe Coding)을 하며 AI 코드를 읽지 않는 내가 리뷰에서 보고 있는 중요한 포인트

「코드도 읽지 않고 무슨 엔지니어냐」——AI 구동(AI-driven) 방식으로 SaaS를 혼자 만들고 있으면, 이렇게 들릴 법한 방식으로 일하게 된다.

하지만 9개월간 1인 개발을 완주하며 확신했다. 리뷰가 필요 없어진 것이 아니다. 리뷰하는 대상이 코드에서 다른 것으로 옮겨간 것이다.

기존의 코드 리뷰(Code Review) 관점을 업데이트하지 않으면, AI 시대의 엔지니어는 소모될 뿐이다.

이 기사는 바이브 코딩(Vibe Coding)을 하며, AI 코드를 읽지 않는 내가 리뷰에서 보고 있는 중요한 포인트의 다이제스트 버전입니다.

소수 정예 시대의 개발 팀상이나, 위태로운 엔지니어상의 상세한 내용은 위의 완전판을 참조해 주세요.

먼저 오해받고 싶지 않은 점을 적는다.

「AI의 코드는 완벽하니까 읽지 않는다」라고 한마디도 말하지 않았다. 오히려 반대다. 생성형 AI(Generative AI)가 내뱉는 코드에는 구멍이 있다. 논리의 누락, 고려의 미비, 파괴적 실행——하나의 AI에게 맡기면, 그 AI의 습성을 통째로 떠안게 된다.

그렇다면 그 구멍을 어떻게 할 것인가. 답은 "자신의 눈으로 한 줄씩 쫓는 것"이 아니다.

여러 개의 AI로 리뷰를 순환시킨다.

어떤 AI가 쓴 것을 다른 AI가 검토한다. 그것을 다시 돌려보내 수정한다. 삼각 구도(三すくみ)로 구멍을 메우는 것이 기본이다. 메커니즘의 상세한 내용은 요구 정의(Requirement Definition)가 전부다——AI 구동 개발을 삼각 리뷰로 돌린 이야기도 썼다.

구멍을 메우는 메커니즘이 있기 때문에, 코드 그 자체를 일절 보지 않는다. 코드를 보지 않는 것은 게으름을 피우는 것이 아니라 「설계(Design)」의 문제다.

코드를 보는 대신 무엇을 하고 있었나. 프로덕트의 오너(Owner)로서 AI가 원활하게 달릴 수 있는 장을 마련하고 있었다. 마련한 것은 대략 3가지다.

마련하는 것	내용
맡기는 방식의 설계	어떤 AI에게 무엇을 맡길 것인가. 어디서부터 사람이 판단을 쥐게 할 것인가
...
바이브 코딩(Vibe Coding) 업계에서는 이 프레임워크를 「가드레일(Guardrail)」이나 「Skill」이라고 부른다. 부르는 방식이 어떻든 하고 있는 일은 같다. 코드를 쓰는 것보다, AI가 기분 좋게 달릴 수 있는 장을 마련하는 것이다. 오너의 업무는 어느샌가 그쪽으로 옮겨져 있었다.

이 부분이 가장 전달하고 싶은 변화다. 예전과 지금, 리뷰의 내용은 이렇게 바뀌었다.

예전의 리뷰	지금의 리뷰
보는 것	이 구현은 올바른가. 버그는 없는가
...
개별 부품은 신뢰할 수 있는 메커니즘에 맡긴다. 자신은 전체가 의도에서 벗어나지 않는지만 감시한다.

결국 리뷰에서 보고 있는 것은, 이 중요한 포인트 딱 하나다.

무수한 코드가 아니라, AI가 의도대로 움직이고 있는가.

그것만 놓치지 않는다면, 한 줄씩 쫓지 않아도 품질은 지킬 수 있다.

▶ 소수 정예 시대의 개발 팀상이나, 위태로운 엔지니어상의 상세한 내용은 이쪽으로 → 바이브 코딩(Vibe Coding)을 하며, AI 코드를 읽지 않는 내가 리뷰에서 보고 있는 중요한 포인트

「혼자서 SaaS를 만드는 것 따위, 자신과는 상관없다」라고 느낀 사람도 있을 것이다. 하지만 기다려 달라. 가져가야 할 것은 규모의 이야기가 아니라, 대하는 마음가짐(Mindset)이다.

하고 있는 일을 작게 풀어보면 다음과 같다.

• AI에게 무엇을 맡기고, 무엇을 맡기지 않을지를 결정했다
• 탈선하지 않도록 규칙을 세웠다
• 나온 결과물에 책임을 질 수 있는 메커니즘을 만들었다

이것은 1인 개발이 아니더라도 할 수 있다. 지금 있는 현장에서 AI를 어떻게 맡길지 정리해 본다. 팀의 리뷰에 AI를 전제로 한 한 끗 차이의 아이디어를 더해 본다. 작은 범위라도 좋다.

「AI를 사용한다」에서 「AI를 통제한다」로, 위치를 반 걸음 옮긴다.

그 반 걸음이 AI 시대의 성장 전략이 된다. 코드를 빠르게 쓰는 경쟁에서 소모되는 것이 아니라, AI를 어떻게 다스릴지에 축을 옮긴다. 이 대하는 방식의 차이가 몇 년 후에 큰 차이를 만든다.

두 사람을 떠올려 보길 바란다.

A씨	B씨
강점	한 줄씩 정성스럽게 읽을 수 있다
...
조금 전이라면 A씨가 신뢰받았을 것이다. 하지만 AI가 구현을 담당하는 지금, 평가는 역전되어 간다.

A씨의 업무는 AI가 대신할 수 있는 영역에 가깝다. 반면, B씨의 메커니즘 만들기나 규칙 정비는 AI에게 통째로 맡길 수 없다. 무엇을 만들 것인가, 무엇을 만들지 않을 것인가, 어떻게 통제할 것인가——이곳은 사람이 결정할 수밖에 없다.

이 변화는 스킬 시트(Skill Sheet)를 쓰는 방식과도 직결된다.

많은 사람은 이렇게 쓴다. 「Cursor 사용」, 「ChatGPT로 코딩」. 하지만 도구를 사용했다는 것만으로는 더 이상 차별화되지 않는다. 사용하는 것이 당연해지고 있기 때문이다.

차이가 나는 것은 AI를 어떻게 통제했는가이다.

| Before (도구 이름만)
|---|---
| 예시 | 생성형 AI를 활용하여 개발 효율화 |
| 읽는 사람의 인상 | 도구를 사용해 보았다 |

| After (통제를 이야기함)
|---|---
| 예시 | 여러 AI를 활용해 리뷰를 순환시켜 코드의 허점을 메우는 체제를 설계. 개발 규칙을 정비하여 탈선을 방지하며 혼자서 SaaS를 개발했다 |
| 읽는 사람의 인상 | AI를 어떻게 통제하여 무엇을 성취했는지 보인다 |

|---|---|

앞으로의 스킬 시트(Skill sheet)에서 강력한 것은 의심할 여지 없이 후자다.

통제한 경험을 지속적으로 기록하려면, 폼 입력으로 형식이 자동 통일되는 Skillsheet-Port와 같은 도구를 사용할 수 있다. 이는 AI 활용란을 '도구 이름의 나열'에서 '통제 프로세스의 기록'으로 격상시키기 위한 토대가 된다.

• AI 코드를 읽지 않는 것 자체가 태만한 것은 아니다.
  허점을 메우는 메커니즘이 있는가가 분수령이다 - 리뷰는 사라지지 않았다.
  대상이 '코드'에서 '메커니즘에 대한 충실함'으로 격상되었다 - 해야 할 본질적인 일은 세 가지: ① 맡기는 방식의 설계 ② 진행 방식의 규칙 ③ 탈선을 방지하는 프레임워크
• 규모의 문제가 아니라 마인드셋의 문제다.
  'AI를 사용한다'에서 'AI를 통제한다'로 반 걸음 옮기기 - 스킬 시트에는 '사용했다'가 아니라 **'어떻게 통제했는가'**를 적는다.

다음에 스킬 시트를 열었을 때, 한번 생각해 보길 바란다. 'AI를 사용했다'라고 적을 것인가, 아니면 'AI를 어떻게 통제했는가'를 적을 수 있는가. 아직 적을 수 없다면, 내일의 현장에서 그 반 걸음을 내딛는 것부터 시작하면 된다.

▶ 완전판 가이드는 이쪽으로 → 바이브 코딩(Vibe Coding)을 하며 AI 코드를 읽지 않는 내가, 리뷰에서 보고 있는 중요한 포인트

▶ 무료로 스킬 시트를 만들어 보기 → https://www.skillsheet-port.com/