반드시 알아야 하는 엔지니어링

LTT·2026년 7월 13일

AI 학습노트 협찬

본 콘텐츠는 길벗출판사에서 보내준 《바이브 엔지니어링》을 읽고 작성한 콘텐츠입니다.

이전에 AI 코딩 툴, 제대로 쓰고 계신가요?라는 글을 작성하며 마지막에 이런 이야기를 했습니다.

개발은 AI에게 맡기고, 엔지니어링은 사람이 맡아야 한다.

그리고 얼마 지나지 않아 제목부터 아예 《바이브 엔지니어링》인 책을 읽게 됐습니다.

그래서 이번에는 책의 내용을 순서대로 소개하기보다, 책을 읽으며 이전에 했던 생각이 어떻게 구체화되었는지 이야기해보려고 합니다. 여기에 제가 실제로 AI 코딩 도구를 사용하며 정착시킨 방법도 함께 소개하겠습니다.

바이브 코딩은 너무나 익숙해졌다

현시점에서 AI를 전혀 사용하지 않는 개발자는 찾기 힘들 겁니다.

처음에는 브라우저에서 모르는 내용을 물어보고 코드를 복사해오는 정도였다면, 이제는 AI가 코드베이스를 직접 읽고 파일을 수정하며 테스트까지 실행합니다.

우리의 요청도 점점 짧아졌습니다.

사용자 목록을 조회하는 API를 만들어줘.

JWT 기반의 로그인 기능을 구현해줘.

이 에러 원인을 찾아서 고쳐줘.

이 정도만 이야기해도 AI는 꽤 그럴듯한 결과물을 만들어냅니다. 개발 속도만 보면 과거로 돌아가기 어려울 정도로 편리합니다.

문제는 그럴듯하게 동작하는 코드와 실제 서비스에 배포할 수 있는 코드가 같지 않다는 것입니다.

사용자가 동시에 몰리면 어떻게 되는가?
외부 API가 응답하지 않으면 요청이 계속 쌓이지 않는가?
데이터가 중복으로 저장될 가능성은 없는가?
정상적인 로그인 외에 토큰 탈취와 재사용에도 대응하는가?
지금 만든 구조를 다른 개발자가 수정할 수 있는가?

이런 문제는 컴파일 에러처럼 빨간 줄을 보여주지 않습니다. 정상적으로 동작하는 것처럼 숨어 있다가 운영 환경에서 뒤늦게 나타납니다.

바이브 코딩이 “기능이 돌아가도록 만드는 일”이라면, 바이브 엔지니어링은 “요구사항과 엣지 케이스, 테스트와 운영까지 통제할 수 있는 상태로 만드는 일”에 가깝습니다.

저는 엔지니어링을 다음과 같이 정의합니다.

엔지니어링이란, 불확실한 문제를 제약 조건 안에서 재현 가능하고 유지 가능한 해법으로 바꾸는 일입니다.

그렇다면 AI가 코드를 작성하는 시대에는 어떻게 엔지니어링해야 할까요?

기능이 아니라 완료 조건을 지시하기

책을 읽으며 가장 먼저 공감했던 부분은 비기능 요구사항에 관한 내용이었습니다.

AI에게 단순히 기능만 요청하면 AI는 기능을 완성하는 데 집중합니다. 3초 이내에 응답해야 하는지, 동시에 몇 건을 처리해야 하는지, 장애가 발생하면 어떻게 복구해야 하는지는 우리가 알려주지 않는 이상 적당히 판단하거나 생략합니다.

예를 들어 다음과 같은 요청이 있습니다.

OpenAI API를 이용하여 대화 내용 요약 API를 만들어주세요.

기능 자체는 충분히 만들어낼 겁니다. 하지만 실제 서비스에서 사용하려면 적어도 다음과 같은 조건이 추가로 필요합니다.

OpenAI API를 이용하여 대화 내용 요약 API를 구현해주세요.

- 전체 요청 타임아웃은 5초입니다.
- 429와 5xx 응답에만 최대 2회 재시도합니다.
- 재시도에는 지수 백오프를 적용합니다.
- 외부 API의 동시 요청은 50개를 넘을 수 없습니다.
- 최종 실패 시 일관된 에러 응답을 반환해야 합니다.
- 요청 수, 응답 시간, 재시도 횟수와 최종 실패를 확인할 수 있어야 합니다.
- 정상, 타임아웃, 재시도, 동시 요청 초과 상황의 테스트를 작성해주세요.

두 요청 모두 같은 요약 API를 만들어달라는 내용입니다. 하지만 두 번째 요청에는 언제 완성되었다고 판단할 수 있는지가 담겨 있습니다.

물론 매번 처음부터 이 모든 조건을 떠올리기는 어렵습니다. 특히 경험해보지 않은 문제라면 무엇을 빠뜨렸는지조차 알기 어렵죠.

그럴 때는 AI에게 곧바로 구현을 시키기보다 먼저 질문을 시킬 수 있습니다.

이 기능을 실제 운영 환경에 배포한다고 가정하세요.

바로 구현하지 말고 성능, 동시성, 장애 대응, 보안, 관측 가능성 측면에서
결정해야 할 사항과 누락된 요구사항을 먼저 질문해주세요.
제가 답변하면 요구사항과 테스트 조건을 정리한 뒤 구현 계획을 작성해주세요.

AI에게 더 자세하게 명령하는 것만이 프롬프트를 잘 쓰는 방법은 아닙니다. 내가 모르는 부분을 AI가 질문하게 만드는 것도 좋은 활용법입니다.

AI를 구현자가 아니라 리뷰어로 사용하기

JWT 기반 로그인 기능을 예로 들어보겠습니다.

JWT 토큰 기반 로그인 API를 만들어주세요.

이 요청만으로도 로그인은 됩니다. 하지만 엔지니어링의 영역으로 들어가면 결정할 내용이 급격히 많아집니다.

액세스 토큰과 리프레시 토큰의 만료 시간
클라이언트에서 토큰을 저장하고 전달하는 방법
리프레시 토큰 회전과 재사용 탐지
로그아웃과 강제 만료 처리
여러 기기에서 로그인하는 경우의 정책
인증과 인가 실패 응답
토큰에 포함할 최소한의 정보

주니어 개발자가 이 조건을 하나하나 알고 지시하기란 쉽지 않습니다. 저 역시 익숙하지 않은 영역에서는 놓치는 부분이 생깁니다.

그럴 때 AI를 단순 구현자가 아니라 시니어 엔지니어 역할로 사용합니다.

현재 JWT 인증 로직을 시니어 백엔드 엔지니어의 관점에서 검토해주세요.

- 보안 취약점과 악용 가능한 시나리오
- 동시 요청과 장애 상황에서 발생할 수 있는 문제
- 토큰 발급, 재발급, 폐기 정책의 누락
- 과도하게 복잡하거나 책임이 잘못 배치된 설계
- 테스트되지 않은 성공, 엣지, 실패 케이스

반드시 수정해야 하는 문제와 선택적으로 개선할 문제를 구분하고,
각 항목의 발생 조건과 수정 방향을 함께 설명해주세요.

이렇게 요청하면 단순히 “SOLID 원칙을 지키세요” 같은 추상적인 답변보다 확인할 수 있는 조건이 있는 리뷰를 받을 가능성이 높아집니다.

다만 AI에게 시니어 역할을 부여했다고 결과까지 시니어급이 되는 것은 아닙니다. AI가 제시한 문제의 근거가 맞는지, 현재 서비스에서 정말 필요한 설계인지 판단하는 것은 여전히 사람의 몫입니다.

AI가 모르는 내용을 알려주는 도구라면 좋겠지만, 실제로는 모르는 내용도 알고 있는 것처럼 말할 수 있는 도구이기도 하니까요.

코드보다 기획을 먼저 이해시키기

책에서는 AI에게 도메인 지식을 이해시키며 개발해야 한다고 이야기합니다. 저는 이를 기획과 개발 의도를 AI에게 주입하는 일이라고 생각합니다. 결국 같은 의미입니다.

예를 들어 “예약 취소 API를 만들어달라”고 요청하면 기술적으로는 멀쩡한 CRUD 코드가 나올 수 있습니다.

하지만 실제 예약 서비스라면 이야기가 달라집니다.

당일에도 취소할 수 있는가?
결제 수단별 환불 방식은 어떻게 다른가?
사용한 쿠폰은 어떤 조건에서 복구되는가?
취소한 수량을 재고에 언제 반영하는가?
이미 사용된 예약을 취소할 수 있는가?

AI가 이 정책을 모른다면 아무리 깔끔한 코드를 작성해도 올바른 기능을 만들 수 없습니다.

저도 CMUX 해커톤에서 monix를 개발할 때 비슷한 경험을 했습니다.

tool calling 관련 문제가 계속 발생하여 코드와 에러를 보여주며 수정을 요청했지만, 좀처럼 원하는 방식으로 해결되지 않았습니다. AI는 눈앞에 보이는 오류를 없애는 데만 집중했고, 수정할수록 오히려 기획과 멀어지는 경우도 있었습니다.

그래서 제품이 해결하려는 문제와 전체 사용자 흐름, 각 도구가 호출되어야 하는 이유부터 다시 설명했습니다. 그제야 AI가 단순한 코드 오류가 아니라 구조와 호출 흐름의 문제로 접근하기 시작했습니다.

AI에게 부족했던 것은 코드가 아니라 왜 이 코드를 만들고 있는지에 대한 정보였습니다.

이후에는 구현 전에 다음 내용을 먼저 정리해서 전달하려고 합니다.

구현에 앞서 아래 내용을 읽고 이 기능의 목적을 먼저 요약해주세요.

1. 해결하려는 사용자 문제
2. 핵심 사용자 흐름
3. 반드시 지켜야 하는 비즈니스 규칙
4. 기존 시스템과의 경계
5. 실패해도 되는 것과 절대 실패하면 안 되는 것

모호하거나 서로 충돌하는 내용은 임의로 결정하지 말고 질문해주세요.

AI가 프로젝트의 모든 것을 알 필요는 없습니다. 다만 현재 작성할 코드가 전체 제품에서 어떤 역할을 하는지는 알아야 합니다.

귀찮으니 반복되는 엔지니어링은 자동화하기

여기까지 읽으면 한 가지 문제가 생깁니다.

그래서 이걸 매번 프롬프트로 길게 작성해야 하나?

저는 귀차니즘이 꽤 심하기 때문에 같은 내용을 계속 입력하고 싶지는 않습니다. 자주 사용하는 지시는 Skill과 프로젝트 규칙으로 만들어두는 편입니다.

자주 하는 작업은 Skill로 만들기

코드 리뷰를 요청할 때마다 보안, 성능, 동시성, 예외 처리와 테스트를 확인하라고 입력한다면 그 자체가 반복 작업입니다.

이런 절차는 코드 리뷰 Skill로 만들어둘 수 있습니다.

# 백엔드 코드 리뷰

- 먼저 변경 목적과 영향 범위를 파악한다.
- 정확성, 보안, 동시성, 트랜잭션, 성능, 예외 처리를 검토한다.
- 기존 테스트가 보장하지 못하는 엣지 케이스를 찾는다.
- 반드시 수정할 문제와 개선 제안을 구분한다.
- 문제를 지적할 때 발생 조건과 수정 방향을 함께 제시한다.
- 근거 없는 칭찬과 단순한 취향 차이는 제외한다.

이렇게 만들어두면 필요한 순간에 같은 기준으로 리뷰를 요청할 수 있습니다. 프로젝트 특성에 맞는 규칙을 계속 추가하며 개인이나 팀의 리뷰 기준으로 발전시킬 수도 있습니다.

프롬프트가 그때그때 사용하는 요청이라면 Skill은 반복해서 실행할 수 있도록 저장한 엔지니어링 절차에 가깝습니다.

프로젝트 규칙과 작업 절차 분리하기

이전 글에서는 CLAUDE.md, AGENTS.md와 같은 컨텍스트 파일을 소개했습니다.

프로젝트 규칙에는 다음처럼 항상 지켜야 할 내용을 담습니다.

# 프로젝트 개발 규칙

- 기존 아키텍처와 패턴을 우선 사용한다.
- 새로운 의존성을 추가하기 전에 필요성과 대안을 설명한다.
- 설정값과 비밀값을 코드에 하드코딩하지 않는다.
- 로그에 개인정보와 인증 정보를 남기지 않는다.
- 변경 후 빌드와 테스트를 실행하고 결과를 보고한다.

반면 Skill에는 코드 리뷰, 장애 분석, API 설계처럼 특정 작업을 수행하는 절차를 담습니다.

프로젝트 규칙: 이 프로젝트에서 항상 지켜야 하는 것
Skill: 특정 작업을 어떤 순서와 기준으로 수행할 것인지

이 둘을 구분해두면 모든 지시를 하나의 거대한 파일에 넣지 않아도 됩니다. AI에게 필요한 순간에 필요한 기준만 전달하기도 쉬워집니다.

개인적으로 자주 쓰는 Skill들

몇 가지 제가 자주 사용하는, 또는 설치해둔 Skill들입니다.

garrytan/gstack: 프로덕션 엔지니어링에 관한 전반적인 품질을 높여줄 수 있는 스킬입니다.
clean-code(자체개발): https://github.com/ksj000625/template-for-claude-code 에 추가해 두었습니다. 클린 코드 원칙으로 코드리뷰를 할 수 있는 스킬입니다.

이 외에 몇가지를 쓰지만 자주쓰지는 않으므로 말았고, 추가적으로 좋은게 있으면 공유해주세요 :)

AI가 만든 결과는 다른 시선으로 검증하기

한 번의 요청으로 설계, 구현, 테스트와 리뷰를 모두 끝내면 편리합니다. 하지만 같은 대화에서 AI가 자신이 방금 만든 코드를 검토하면 처음에 세운 잘못된 가정을 그대로 유지하는 경우가 있습니다.

구현 코드의 실수를 정답으로 가정하고 그 코드에 맞는 테스트를 작성해버리는 식입니다. 테스트가 모두 통과하니 더 그럴듯해 보이기까지 합니다.

그래서 저는 가능하면 생성과 검증의 단계를 나누려고 합니다.

요구사항을 읽고 모호한 부분을 질문하게 합니다.
구현 계획과 변경 범위를 먼저 검토합니다.
작은 단위로 구현하고 테스트를 실행합니다.
최초 요구사항을 기준으로 결과를 다시 확인합니다.
가능하다면 별도의 에이전트나 새로운 컨텍스트에서 코드 리뷰를 요청합니다.

여기서 중요한 것은 AI를 여러 번 사용하는 것이 아닙니다. 코드를 생성하는 일과 그 코드가 맞는지 증명하는 일을 같은 작업으로 취급하지 않는 것입니다.

테스트 코드도 마찬가지입니다. 테스트 이름과 통과 여부만 볼 것이 아니라, 각 테스트가 어떤 요구사항을 증명하는지 확인해야 합니다.

바이브 엔지니어링은 긴 프롬프트를 쓰는 기술이 아니다

책을 읽기 전에는 바이브 엔지니어링이라는 단어가 바이브 코딩을 조금 더 체계적으로 하는 방법 정도라고 생각했습니다.

읽고 나서 가장 크게 남은 생각은 AI를 잘 지시하는 능력보다 AI의 결과를 판단할 기준을 갖는 능력이 더 중요하다는 것이었습니다.

요구사항을 정의하려면 무엇이 정상인지 알아야 합니다. 아키텍처를 선택하려면 선택지의 장단점을 이해해야 합니다. AI가 만든 코드의 문제를 발견하려면 컴퓨터 공학 기초와 도메인 지식이 필요합니다. 테스트를 작성하게 하더라도 무엇을 검증해야 하는지는 사람이 결정해야 합니다.

AI가 주니어 개발자를 단숨에 시니어로 만들어주는 것은 아닙니다.

대신 주니어도 이전보다 훨씬 넓은 범위의 구현을 시도하고, AI에게 질문과 리뷰를 요청하며 더 빠르게 배울 수 있게 해줍니다. 그 과정에서 AI의 답변을 그대로 받아들이지 않고 판단할 수 있는 지식을 쌓는 것이 중요합니다.

이번 글에서는 제가 특히 공감했던 비기능 요구사항, 설계 검토, 도메인 지식과 반복 작업의 자동화를 중심으로 이야기했습니다.

이외에도 아키텍처 설계, 논리 오류와 디버깅, 테스트를 이용해 AI를 통제하는 방법 등은 책에 사례와 프롬프트가 예시와 함께 더 상세하게 정리되어 있으니 참고하시면 많은 도움이 될 것 같습니다.