바이브 코딩 실전 15화: AI가 만든 코드는 왜 점점 엉킬까?

지난 편에서는 MyLog를 실제 스마트폰에 넣어 테스트했습니다.

그 과정에서

키보드가 화면을 가리는 문제도 찾고,

네트워크가 끊겼을 때의 동작도 확인하고,

로그인 세션도 다시 보고,

사용자별 데이터가 제대로 분리되는지도 체크했습니다.

버그 하나를 발견하면 AI에게 수정 요청을 했고,

수정이 끝나면 다시 테스트했습니다.

그렇게 몇 번 반복하다 보니 프로젝트 안에도 제법 많은 코드가 생겼습니다.

처음에는 아주 단순했습니다.

main.dart
Record
목록 화면
작성 화면
상세 화면

그런데 이제는

Auth
Supabase
RecordService
Loading
Error
Session
RLS
화면 상태
로컬 데이터 처리

까지 들어왔습니다.

그리고 어느 순간 AI가 이런 말을 합니다.

이 말을 처음 보면 약간 불안합니다.

리팩터링?

뭔가 대공사 냄새가 납니다. 🏗️

1. 리팩터링은 기능을 새로 만드는 일이 아니다

먼저 리팩터링부터 쉽게 정의해보겠습니다.

리팩터링은

입니다.

예를 들어 사용자는 리팩터링 전에도

로그인
↓
기록 작성
↓
저장
↓
목록

을 사용할 수 있습니다.

리팩터링 후에도 똑같습니다.

사용자 입장에서는 달라진 것이 없을 수도 있습니다.

하지만 내부에서는

하나의 거대한 파일

이

화면
서비스
데이터 모델
공통 UI

처럼 역할별로 나뉠 수 있습니다.

집으로 치면 새로운 방을 만드는 것이 아니라

창고에 뒤섞여 있던 물건을 제자리로 옮기는 작업에 가깝습니다.

2. 그런데 왜 AI가 만든 코드는 점점 복잡해질까?

AI가 코드를 못 짜서만은 아닙니다.

오히려 바이브 코딩의 작업 방식 자체가 이런 상황을 만들기 쉽습니다.

처음에는 이렇게 요청합니다.

다음에는

그다음에는

그리고

그다음에는

각각의 요청은 작습니다.

문제는 AI가 매번 현재 코드에 가장 빠르게 기능을 붙이는 방식을 선택할 수 있다는 것입니다.

그 결과 이런 코드가 생길 수 있습니다.

RecordListScreen

화면 그리기
+
Supabase 호출
+
Loading 처리
+
Error 처리
+
로그인 확인
+
데이터 변환
+
저장
+
재시도

처음에는 괜찮았습니다.

기능이 하나씩 붙으면서 화면 하나가 작은 만능 주방이 된 겁니다.

요리도 하고,

설거지도 하고,

배달 전화도 받고,

회계도 봅니다. 🍳

3. 코드가 길다고 무조건 나쁜 것은 아니다

여기서 오해하면 안 됩니다.

파일이 300줄이라고 무조건 나쁜 코드는 아닙니다.

파일이 50줄이라고 무조건 좋은 코드도 아닙니다.

우리가 봐야 할 것은 역할이 섞여 있는가입니다.

예를 들어 Record 목록 화면이 이런 일까지 하고 있다면 한번 생각해볼 수 있습니다.

UI 렌더링

Supabase 연결

Record JSON 변환

로그인 사용자 확인

API 오류 변환

데이터 저장

날짜 포맷

화면 하나가 너무 많은 책임을 가지고 있습니다.

이 상태에서는 작은 수정이 다른 곳에 영향을 줄 가능성이 높아집니다.

4. 리팩터링이 필요한 신호는 생각보다 눈에 잘 보인다

비개발자라고 해서 코드 품질을 전혀 판단할 수 없는 것은 아닙니다.

몇 가지 신호만 알아두면 됩니다.

예를 들어 세 화면에서 같은 오류 메시지 처리 코드가 반복됩니다.

try
catch
네트워크 오류 처리
SnackBar 표시

계속 복사되고 있다면 공통 처리할 여지가 있습니다.

예를 들어 기록 목록 정렬 하나를 바꾸는데

UI 파일,

Supabase 코드,

데이터 변환 코드

를 모두 동시에 수정해야 한다면 구조가 지나치게 붙어 있을 수 있습니다.

이것도 중요한 신호입니다.

라고 했는데 9개 파일이 변경됩니다.

그렇다면 코드 간 결합이 너무 강하거나 AI가 구조를 잘못 이해하고 있을 가능성이 있습니다.

로그인 실패 처리를 고쳤는데 다른 화면에서는 똑같은 문제가 생깁니다.

공통 로직이 각 화면에 흩어져 있을 가능성이 있습니다.

초반에는

면 끝났는데,

나중에는

설명이 복잡해집니다.

이것도 구조 점검 신호입니다.

5. 그렇다고 조금 복잡해졌다고 바로 리팩터링하지 않는다

이 부분도 중요합니다.

리팩터링은 필요하지만 너무 자주 하면 개발이 앞으로 나가지 않습니다.

기능 하나 만들 때마다

를 고민하면 첫 앱은 영원히 출시되지 않을 수도 있습니다.

그래서 저는 이런 시점을 추천합니다.

작은 기능 몇 개 구현

↓

실제 동작 확인

↓

비슷한 코드가 반복되기 시작

↓

다음 기능 추가가 불편해짐

↓

리팩터링 검토

즉 불편함이 실제로 나타났을 때 정리합니다.

미래의 문제를 전부 예상해서 처음부터 거대한 구조를 만들지는 않습니다.

6. 바이브 코딩에서 가장 위험한 프롬프트 중 하나

이제 오늘 가장 중요한 이야기를 해보겠습니다.

프로젝트가 복잡해 보일 때 이런 말을 하고 싶어집니다.

개인적으로 꽤 위험한 요청입니다.

왜냐하면 AI에게 너무 많은 자유를 주기 때문입니다.

AI는

폴더 구조를 바꾸고,

파일을 나누고,

함수 이름을 바꾸고,

패키지를 추가하고,

상태 관리 방식을 변경하고,

기존 API 호출 방식까지 바꿀 수 있습니다.

결과는 아주 깔끔할 수도 있습니다.

그리고 앱이 안 될 수도 있습니다. 😇

7. 리팩터링도 작은 단위로 한다

기능 개발과 똑같습니다.

한 번에 하나씩 갑니다.

예를 들어 현재 문제가

라면 이번 작업은 이것만 해결합니다.

Before

RecordListScreen
 ├─ UI
 ├─ Supabase Select
 ├─ Insert
 ├─ Error Handling
 └─ Data Mapping

리팩터링 후

RecordListScreen
 └─ UI / State

RecordService
 ├─ getRecords()
 └─ createRecord()

정도로만 나눕니다.

그다음 테스트합니다.

정상이라면 Commit.

다음 문제로 넘어갑니다.

8. 먼저 AI에게 코드 구조를 진단하게 한다

바로 고치게 하지 않습니다.

예를 들어 이렇게 요청할 수 있습니다.

현재 MyLog 프로젝트를 리팩터링 관점에서 분석해줘.

아직 코드를 수정하지 마.

다음 항목을 확인해줘.

1. 역할이 지나치게 많은 파일
2. 중복 코드
3. UI와 데이터 접근 코드가 섞인 부분
4. 작은 수정이 여러 파일에 영향을 주는 부분
5. 현재 MVP 규모에서 불필요하게 복잡한 구조
6. 지금 당장 정리해야 할 것
7. 나중에 정리해도 되는 것

중요:
새로운 아키텍처나 패키지를 먼저 제안하지 말고
현재 구조를 최대한 유지하면서 분석해줘.

마지막 문장이 꽤 중요합니다.

AI가 신나서 갑자기 Clean Architecture 세계 여행을 떠나는 것을 막아줍니다.

9. "Clean Architecture로 바꿔줘"는 왜 조심해야 할까?

Clean Architecture 자체가 나쁘다는 이야기가 아닙니다.

규모가 크고 팀원이 많으며 복잡한 비즈니스 로직이 있다면 충분히 유용할 수 있습니다.

하지만 MyLog MVP에 갑자기

presentation/
domain/
data/
repositories/
usecases/
entities/
datasources/

를 전부 만들 필요가 있을까요?

아직 기록 작성, 조회 정도입니다.

구조가 코드보다 더 커질 수 있습니다.

좋은 아키텍처란 멋진 폴더 이름을 많이 갖는 것이 아니라

현재 프로젝트를 이해하고 수정하기 쉬운 구조입니다.

10. 지금 MyLog에서 먼저 정리할 만한 곳

현재까지 만든 기능을 보면 가장 먼저 정리할 후보는 데이터 접근 부분입니다.

예를 들어 화면 안에 이런 코드가 흩어져 있다고 해보겠습니다.

final data = await supabase
    .from('records')
    .select()
    .order('created_at');

다른 화면에서는

await supabase
    .from('records')
    .insert(record.toMap());

가 있습니다.

이런 코드를 RecordService로 모을 수 있습니다.

RecordService

getRecords()

createRecord()

그러면 화면은 조금 단순해집니다.

화면

"기록 가져와줘"

↓

RecordService

Supabase 호출

↓

Record 반환

↓

화면 표시

11. 화면은 화면 일을 하게 한다

이 원칙 하나만 기억해도 좋습니다.

Screen

사용자에게 무엇을 보여줄지
사용자 입력에 어떻게 반응할지

Service

데이터를 어디서 가져올지
어떻게 저장할지

를 어느 정도 분리하는 것입니다.

완벽하게 분리하지 않아도 됩니다.

다만 화면 파일을 열었는데 SQL과 인증 토큰과 UI 코드가 한 냄비에 들어 있다면 조금 정리할 시점입니다.

12. 오류 처리도 반복되고 있다면 모아볼 수 있다

현재 MyLog에서는

로그인 오류,

Record 조회 오류,

Record 저장 오류

가 있습니다.

각 화면에서 모두

try

↓

catch

↓

메시지 변환

↓

SnackBar

를 반복하고 있다면 중복이 생길 수 있습니다.

다만 여기서 너무 빨리

GlobalErrorManager
ExceptionHandlerFactory
ErrorRepository

같은 구조로 갈 필요는 없습니다.

처음에는

사용자에게 보여줄 오류 메시지 변환 함수

정도만 공통화해도 충분할 수 있습니다.

리팩터링은 정리이지, 새로운 복잡성을 만드는 대회가 아닙니다.

13. 이름이 뒤섞였다면 지금 정리하는 것이 좋다

바이브 코딩을 여러 회차 진행하면 AI마다 조금씩 다른 이름을 사용할 수 있습니다.

예를 들어

Record
Memo
Log
Entry

가 코드 안에 섞이기 시작할 수 있습니다.

우리 프로젝트에서는 이미 사용자 기록 단위를

Record

라고 부르기로 했습니다.

따라서

MemoService

LogItem

같은 이름이 혼재한다면 정리합니다.

이름 하나 맞추는 것이 사소해 보이지만 프로젝트를 이해하는 데 꽤 큰 영향을 줍니다.

사람도 한 사람을 회의마다 다른 이름으로 부르면 헷갈립니다.

코드도 비슷합니다.

14. 리팩터링 전에 반드시 해야 할 세 가지

이제 실제 리팩터링을 시작한다고 해보겠습니다.

먼저 세 가지를 확인합니다.

리팩터링 전에 이미 앱이 망가져 있다면

리팩터링 때문에 고장 난 것인지,

원래 있던 버그인지

구분하기 어렵습니다.

먼저 현재 버전을 정상 상태로 만듭니다.

최소한 우리가 손으로 확인했던 핵심 흐름은 다시 사용할 수 있어야 합니다.

로그인

↓

기록 조회

↓

기록 작성

↓

저장

↓

상세 확인

↓

로그아웃

리팩터링 후 이 흐름이 그대로 동작해야 합니다.

말하지 않아도 이제 익숙합니다.

git status

확인하고,

정상 상태를 저장합니다.

예를 들어

chore: 리팩터링 전 안정 버전

정도입니다.

이제 정말 마음 편하게 구조를 바꿀 수 있습니다.

15. 리팩터링 완료 조건은 "코드가 예뻐졌다"가 아니다

리팩터링 요청을 할 때도 완료 조건이 필요합니다.

나쁜 예:

무엇이 깔끔한지 확인하기 어렵습니다.

조금 더 좋은 기준을 잡아보겠습니다.

이번 리팩터링 완료 조건

- Record 관련 Supabase 접근 코드는 RecordService에 위치한다.
- Screen에서 직접 Supabase Table API를 호출하지 않는다.
- 기존 Record 작성·조회 동작은 동일해야 한다.
- 새로운 외부 패키지를 추가하지 않는다.
- 데이터 구조는 변경하지 않는다.
- RLS 정책은 변경하지 않는다.
- 기존 사용자 기능이 깨지지 않는다.

이제 목표가 명확합니다.

16. AI에게 이렇게 요청해보자

현재 MyLog의 Record 관련 코드를 리팩터링한다.

목표:
화면과 Supabase 데이터 접근 로직을 분리한다.

이번 작업 범위:
- RecordService 생성
- Record 조회 로직 이동
- Record 저장 로직 이동
- 기존 Screen에서 Service를 호출하도록 변경

변경하지 않을 것:
- Record 데이터 구조
- Supabase 테이블 구조
- RLS Policy
- UI 디자인
- Auth 구조
- 상태관리 방식
- 새로운 외부 패키지

작업 전에

1. 현재 중복과 결합 문제
2. 수정할 파일
3. 이동할 코드
4. 동작이 유지되는 이유
5. 리팩터링 후 데이터 흐름

을 먼저 설명해줘.

내가 확인한 뒤 구현해줘.

이렇게 요청하면 AI가 움직일 범위가 꽤 좁아집니다.

17. 파일을 나눴다고 무조건 좋아진 것은 아니다

AI가 리팩터링을 끝냈습니다.

파일이 많이 나뉘었습니다.

왠지 전문적인 프로젝트처럼 보입니다.

하지만 한번 확인해야 합니다.

기존에는 파일 4개였는데 지금은 18개입니다.

기록을 저장하는 흐름을 따라가려면

Screen
↓
Controller
↓
UseCase
↓
Repository
↓
DataSource
↓
Service

를 모두 찾아가야 합니다.

MyLog 규모에서 이 정도가 필요할까요?

리팩터링 후에는 파일 수가 아니라 이해하기 쉬워졌는지를 봅니다.

18. 너무 추상화하지 말자

AI가 코드 중복을 보면 함수를 만들고 싶어 합니다.

두 번 반복되면 공통화하고,

조금 비슷하면 인터페이스를 만들고,

미래 확장성까지 고려하기 시작합니다.

하지만 때로는 코드 몇 줄을 두 군데 두는 것이

공통 구조 하나를 이해하는 것보다 쉬울 수도 있습니다.

특히 MVP에서는 그렇습니다.

저는 이런 기준을 좋아합니다.

후자라면 잠시 기다릴 수 있습니다.

미래의 우리에게도 AI가 있습니다.

오늘 모든 미래를 선점할 필요는 없습니다.

19. 리팩터링 중 기능을 추가하면 안 된다

이것도 자주 발생합니다.

AI에게 구조를 정리해달라고 했더니

친절합니다.

하지만 이번 작업 목적과 다릅니다.

리팩터링은 가능하면 동작을 유지하면서 구조만 바꾸는 작업으로 한정합니다.

기능 변경과 구조 변경을 동시에 하면

문제가 생겼을 때 원인을 찾기 어려워집니다.

리팩터링

≠

새 기능 개발

이 둘은 별도로 진행하는 편이 좋습니다.

20. 리팩터링 후 Diff가 클수록 더 조심한다

구조 변경은 일반 기능보다 Diff가 커질 가능성이 높습니다.

따라서 AI가

라고 하면 바로 커밋하지 않습니다.

먼저

git status

와 Diff를 봅니다.

확인할 것은 이런 것입니다.

삭제된 파일이 예상한 것인가?

이동된 코드가 기능적으로 같은가?

RLS나 Supabase 설정이 건드려졌는가?

Auth 관련 코드가 바뀌었는가?

새 패키지가 추가됐는가?

요청하지 않은 기능이 생겼는가?

특히 리팩터링에서는

"왜 이 파일까지 수정했지?"

라는 질문을 자주 해보는 것이 좋습니다.

21. flutter analyze와 테스트도 다시 돌린다

코드 정리가 끝났다면

flutter analyze

를 실행합니다.

테스트 코드가 있다면

flutter test

도 실행합니다.

그리고 여기서 끝나지 않습니다.

실제 스마트폰에서 다시 핵심 흐름을 확인합니다.

로그인

↓

기록 불러오기

↓

새 기록 작성

↓

저장

↓

목록

↓

상세

↓

로그아웃

리팩터링의 성공 기준은

"새 구조가 멋지다"

가 아니라

"기존 동작은 그대로인데 다음 수정이 쉬워졌다"

입니다.

22. 리팩터링 전후를 AI에게 설명하게 해보자

이 작업은 비개발자에게 꽤 도움이 됩니다.

AI에게 이렇게 요청합니다.

이번 리팩터링 전과 후를 비교해줘.

비개발자가 이해할 수 있게

1. 이전에는 Record가 어떻게 조회됐는지
2. 지금은 어떻게 조회되는지
3. 이전에는 Record가 어떻게 저장됐는지
4. 지금은 어떻게 저장되는지
5. Screen 역할이 어떻게 줄었는지
6. 다음 기능 추가가 왜 쉬워졌는지

를 설명해줘.

코드 문법보다는 책임과 데이터 흐름을 중심으로 설명해줘.

그러면 리팩터링을 단순히

으로 끝내지 않을 수 있습니다.

프로젝트 구조에 대한 이해도 조금씩 쌓입니다.

23. 테스트가 아직 부족하다면 리팩터링 범위를 줄인다

리팩터링의 가장 큰 공포는 이것입니다.

자동 테스트가 충분하면 비교적 안전합니다.

하지만 현재 MyLog는 아직 테스트 자동화가 많지 않습니다.

그래서 큰 리팩터링을 한 번에 하지 않는 겁니다.

현재 검증할 수 있는 범위만 바꿉니다.

Record Service 분리

↓

테스트

↓

Commit


오류 처리 공통화

↓

테스트

↓

Commit

이런 식입니다.

작은 리팩터링은 Git과 정말 잘 맞습니다.

24. 리팩터링도 Branch를 활용하기 좋은 작업이다

#07에서 Branch를 잠깐 배웠습니다.

리팩터링처럼 여러 파일을 건드리는 작업에서는 Branch가 특히 유용합니다.

예를 들어

main

안정적인 MyLog

에서

refactor/record-service

Branch를 만들어 작업합니다.

main
│
└── refactor/record-service
       └── 구조 변경 실험

성공하면 합칩니다.

별로라면 Branch를 버립니다.

본진은 살아 있습니다.

AI에게 구조 변경을 과감하게 맡기고 싶을 때 Branch는 좋은 실험실이 됩니다. 🧪

25. 언제 리팩터링을 멈춰야 할까?

이 질문도 중요합니다.

코드는 끝없이 정리할 수 있습니다.

파일 이름도 더 예쁘게 바꿀 수 있고,

함수도 더 잘게 나눌 수 있고,

아키텍처도 더 멋지게 만들 수 있습니다.

그런데 우리는 앱을 출시하려고 합니다.

리팩터링의 종료 기준은 이런 식으로 잡을 수 있습니다.

현재 구조를 이해할 수 있다.

다음 기능을 추가하기 어렵지 않다.

중복이 심각하지 않다.

역할이 크게 섞여 있지 않다.

핵심 기능이 정상적으로 동작한다.

여기까지면 다시 기능 개발로 갑니다.

코드 정리가 새로운 취미가 되지 않도록 합니다.

26. "기술 부채"라는 말도 알아두자

프로젝트를 하다 보면 Technical Debt, 기술 부채라는 말을 듣게 됩니다.

쉽게 말하면

입니다.

예를 들어 MVP를 빨리 만들기 위해 화면 안에 Supabase 코드를 직접 넣었습니다.

당장은 빠릅니다.

하지만 기능이 늘면서 유지보수가 불편해졌습니다.

이제 RecordService로 분리합니다.

미뤄둔 빚을 조금 갚는 겁니다.

기술 부채가 있다는 것 자체는 나쁜 일이 아닙니다.

문제는 있는지 모르거나 계속 갚지 않는 것입니다.

27. 바이브 코딩에서는 기술 부채가 더 빨리 생길 수 있다

AI는 빠릅니다.

우리가 하루에 만들 수 있었던 기능을 한 시간 만에 만들 수도 있습니다.

그 말은 반대로

구조적 문제도 더 빠르게 쌓일 수 있다는 뜻입니다.

기능 추가 속도 ↑

↓

코드 변경 속도 ↑

↓

기술 부채 생성 속도도 ↑

그래서 바이브 코딩에서는

기능을 몇 개 추가한 뒤

한번 구조를 돌아보는 시간

이 더 중요할 수 있습니다.

AI가 빨라졌다고 정리가 필요 없어지는 것은 아닙니다.

오히려 방을 더 빨리 어지럽힐 수 있게 된 셈입니다. 🧦

28. 프로젝트 규칙에도 리팩터링 원칙을 넣자

이제 PROJECT_RULES.md에 몇 줄 추가해도 좋습니다.

## Refactoring Rules

- 리팩터링과 신규 기능 구현을 동시에 하지 않는다.
- 큰 리팩터링 전에는 변경 계획을 먼저 제시한다.
- 현재 동작을 유지하는 것을 최우선으로 한다.
- 새로운 패키지나 아키텍처를 임의로 도입하지 않는다.
- 한 번에 하나의 구조적 문제만 해결한다.
- 리팩터링 후 기존 핵심 사용자 흐름을 다시 테스트한다.
- 정상 확인 전에는 Git Commit 하지 않는다.

이제 다음에 AI가

라고 해도 프로젝트 규칙이 브레이크 역할을 합니다.

29. 오늘의 삽질 방지 팁 🛠️

프로젝트가 복잡해졌다고 절대 이렇게 시작하지 마세요.

새 프로젝트에서는 모든 것이 다시 깔끔해 보입니다.

문제는

인증,

RLS,

에러 처리,

실기기에서 발견한 예외 상황

같은 기존 경험도 함께 사라질 수 있다는 것입니다.

새로 만드는 것은 마지막 선택지에 가깝습니다.

먼저

무엇이 복잡한가?

어디가 반복되는가?

어떤 부분이 수정하기 어려운가?

를 찾습니다.

그리고 그 부분만 작게 정리합니다.

리팩터링은 철거가 아니라 정리입니다.

30. 오늘 MyLog에서 달라진 것

화면은 거의 그대로입니다.

사용자 입장에서는 아무것도 달라지지 않았을 수도 있습니다.

하지만 내부 구조는 예를 들어 이렇게 바뀝니다.

RecordListScreen

UI
+
Supabase 조회
+
저장
+
데이터 변환
+
오류 처리

RecordListScreen

UI
+
화면 상태

RecordService

Record 조회
Record 저장

Record

데이터 구조
변환

역할이 조금 더 선명해졌습니다.

이제 다음 기능을 추가할 때

를 찾기가 쉬워집니다.

이게 오늘 리팩터링의 가장 중요한 결과입니다.

31. 오늘의 완료 조건

이번 편도 체크해보겠습니다.

[ ] 리팩터링과 신규 기능 개발의 차이를 이해했다.

[ ] 현재 MyLog에서 역할이 섞인 파일을 찾아봤다.

[ ] 중복 코드가 있는지 확인했다.

[ ] 전체 리팩터링 대신 하나의 문제를 선택했다.

[ ] 리팩터링 전에 정상 상태를 Git에 저장했다.

[ ] AI에게 변경 계획을 먼저 제시하게 했다.

[ ] Record 데이터 접근 로직을 Screen과 분리했다.

[ ] 데이터 구조와 RLS Policy를 변경하지 않았다.

[ ] 새로운 외부 패키지를 불필요하게 추가하지 않았다.

[ ] flutter analyze 결과를 확인했다.

[ ] 기존 핵심 사용자 흐름을 다시 테스트했다.

[ ] 실제 스마트폰에서도 주요 기능을 확인했다.

[ ] 리팩터링 전후 구조 차이를 이해했다.

[ ] 정상 상태를 Git Commit으로 남겼다.

여기까지 됐다면 MyLog는 기능만 늘어나는 앱에서

조금씩 관리 가능한 프로젝트

로 넘어가기 시작한 것입니다.

32. 그런데 다음 문제는 코드 구조보다 더 위험하다

지금까지 MyLog에는 Supabase 연결 정보도 들어왔고,

인증도 붙었고,

클라우드 DB도 사용합니다.

앞으로 외부 API를 사용하면 API Key도 추가될 수 있습니다.

그때 아주 흔한 일이 하나 있습니다.

AI에게

라고 시키는 겁니다.

실행은 아주 잘 됩니다.

Git에도 올라갑니다.

GitHub에 Push도 됩니다.

그리고 비밀 값이 전 세계 여행을 시작합니다. 🌍

다음 편에서는 앱 개발에서 자주 등장하는

환경변수,

API Key,

Secret,

.env,

Git 제외 설정

을 제대로 구분해보겠습니다.

[바이브 코딩 실전 #16] API Key를 코드에 넣으면 안 됩니다 | 환경변수와 비밀정보 관리하기

특히 여기서는 한 가지를 확실히 구분할 겁니다.

키 이름에 KEY라고 적혀 있다고 전부 같은 열쇠는 아닙니다.

다음 편에서는 MyLog의 열쇠 꾸러미를 한번 정리해보겠습니다. 🔐

#바이브코딩 #VibeCoding #AI코딩 #리팩터링 #Refactoring #기술부채 #TechnicalDebt #Flutter #Flutter리팩터링 #코드구조 #AI에이전트 #Git #비개발자앱개발 #MVP개발 #MyLog #바이브코딩실전