React Native + Expo로 실제로 운용하는 앱을 혼자서 개발하다 보니, AI 코딩의 편리함과 동시에 상당히 까다로운 문제에 직면했습니다.

그것은 바로,

AI가 새로운 버그를 수정하는 과정에서, 이전에 이미 고쳤던 기능을 다시 망가뜨리는

문제였습니다.

처음에는 단순히 "AI가 실수했다"라고 생각했습니다.

하지만 여러 AI 도구를 사용하며 기능 추가, 리팩터링 (Refactoring), UI 수정을 반복하는 과정에서, 이것은 우발적인 실수가 아니라 AI를 적극적으로 사용하는 개인 개발에서는 지속적으로 발생하기 쉬운 회귀 (Regression) 문제라고 느끼게 되었습니다.

이 기사에서는 제가 실제 React Native / Expo 프로젝트에서 도입한, 매우 심플한 회귀 방지 방법을 공유합니다.

고도의 테스트 기반에 관한 이야기가 아닙니다.

오히려,

• 1인 개발
• 거대한 App.js
• AI에 의한 빈번한 수정
• 테스트 코드 (Test Code)가 충분하지 않음
• Android Build 전에 최소한의 안전 확인을 하고 싶음

이라는 상황에서 사용하고 있는 현실적인 방법입니다.

이전의 저는 수정 후 확인을 대략 다음과 같이 했습니다.

앱 실행
↓
화면 표시
...

하지만 FinTech 계열의 비교 로직을 가진 앱을 만드는 과정에서, 이 확인 방법으로는 불충분하다는 것을 알게 되었습니다.

적어도 다음 세 가지는 나누어 생각해야 합니다.

1. 앱이 실행되는가
2. 기능이 동작하는가
3. 결과가 여전히 올바른가

예를 들어, 화면이 정상적으로 표시되더라도,

• 특정 시장에서만 계산 로직이 사라져 있음
• 고액 구간에서만 spread가 과소평가됨
• P2P와 로컬 거래소의 분류가 바뀌어 있음
• Adapter가 삭제되어 undefined가 발생함
• Partner URL이 구형 URL로 돌아가 있음

과 같은 일이 발생할 수 있습니다.

즉,

크래시 (Crash)가 나지 않는다 = 정상

이 아닙니다.

제 프로젝트에서는 국제 송금 경로를 비교하기 위해, 통화 쌍(Currency Pair), 시장 타입, 금액 구간별로 spread를 추정하고 있습니다.

어느 날, 고액 송금이나 일부 신흥국 시장에서 추정치가 너무 낙관적인 문제가 있었습니다.

그래서 다음과 같은 사고방식을 도입했습니다.

const CORRIDOR_SPREAD_FLOOR = {
// corridor tier × amount band
// minimum spread floor
...

목적은 단순합니다.

예를 들어,

• corridor type
• amount band
• provider type

에 따라 최소 spread를 적용하는 것입니다.

개념적으로는 다음과 같은 처리입니다.

const finalSpread = Math.max(
estimatedSpread,
corridorSpreadFloor
...

또한, Dealer 타입의 Provider에서는 동일한 floor를 그대로 적용하지 않고, 별도의 계수를 사용하도록 했습니다.

이 로직을 실측값과 비교하며 조정하여, 어느 정도 기대하는 결과에 가깝게 만들었습니다.

문제는 그 이후입니다.

다른 기능을 AI에게 수정시킨 후, 문득 의문이 생겼습니다.

CORRIDOR_SPREAD_FLOOR는 아직 남아 있는가?

AI는 새로운 문제를 고치고 있었습니다.

앱도 실행되었습니다.

하지만 큰 파일을 편집, 정리, 치환하는 과정에서 이전에 추가한 중요한 로직이 사라질 가능성이 있습니다.

다른 예입니다.

Crypto → Fiat의 off-ramp 표시에서, 로컬 거래소를 표시하는 처리가 있었습니다.

예를 들어,

USDT → BRL

에서 브라질의 로컬 거래소를 표시하고 싶은 케이스입니다.

그런데 데이터 소스 (Data Source)를 변경한 후, 일부 행에서 다음과 같은 문제가 발생했습니다.

undefined

UI 컴포넌트 (UI Component)가 기대하는 필드와 새로운 데이터 구조가 일치하지 않았기 때문입니다.

그래서 Adapter를 추가했습니다.

function adaptOffRampRow(row) {
return {
name: row.providerName ?? row.name,
...

실제 코드는 조금 더 복잡하지만, 생각하는 방식은 같습니다.

서로 다른 데이터 구조를 Render Component가 기대하는 형식으로 변환합니다.

이것으로 문제는 해결되었습니다.

하지만 다음 수정에서 또 같은 의문이 생깁니다.

AI가 이 Adapter를 "불필요한 중복"이라고 판단하여 삭제하지 않을까?

현재는 큰 수정을 시작하기 전에,

이번에 변경해도 좋은 것

절대로 지워서는 안 되는 것

을 구분하고 있습니다.

예를 들어 현재 프로젝트에서는 다음과 같은 것들을 보호 대상으로 취급합니다.

CORRIDOR_SPREAD_FLOOR
adaptOffRampRow
특정 시장의 P2P 제외 규칙
...

AI에게 요청할 때도 단순히

이 버그를 수정해줘

가 아니라,

이 문제를 수정해 주세요.
단, 아래의 기존 로직은 변경하거나 삭제하지 마세요.
- CORRIDOR_SPREAD_FLOOR
...

와 같이 명시합니다.

이것만으로도 사고율은 낮아졌습니다.

하지만 AI가 "지켰다"라고 말하더라도, 그것만으로는 신뢰하지 않습니다.

제가 추가한 방법은 매우 원시적입니다.

Windows에서는 findstr

을 사용합니다.

findstr /C:"CORRIDOR_SPREAD_FLOOR" App.js
findstr /C:"adaptOffRampRow" App.js
findstr /C:"partner.bitget.com" App.js

중요한 문자열이 사라지지 않았는지 확인합니다.

Git Bash라면 grep

으로도 동일합니다.

grep -n "CORRIDOR_SPREAD_FLOOR" App.js
grep -n "adaptOffRampRow" App.js
grep -n "partner.bitget.com" App.js

물론, 이것이 자동 테스트 (Automated Test)를 대신할 수는 없습니다.

문자열이 존재하더라도 로직이 올바르게 호출되지 않고 있을 가능성이 있습니다.

그럼에도 불구하고,

완전히 삭제된 회귀 (Regression)

를 빌드 (Build) 전에 발견하기 위한 최소한의 안전장치로서는 도움이 됩니다.

현재는 빌드 (Build) 전에 실제 비즈니스 시나리오를 확인하고 있습니다.

확인 내용:

Mercado Bitcoin이 표시되는가
Bitso가 표시되는가
undefined가 없는가

확인 내용:

Upbit가 P2P로 오분류되지 않았는가
Local direct route로 표시되는가

예:

10,000 USD → BRL

확인 내용:

추정 결과가 실제 관측 범위에서 극단적으로 벗어나 있지 않은가

확인 내용:

Sign up URL이 구 URL로 돌아가 있지 않은가

확인 내용:

문자가 존재하는 것뿐만 아니라, 실제로 읽을 수 있는가

마지막 항목도 의외로 중요합니다.

코드상으로는 정상이어도, 글자 색상의 대비 (Contrast)가 너무 낮으면 사용자에게는 보이지 않습니다.

이전에는 수정 후에,

새로운 코드가 들어갔는가?

만 확인했습니다.

현재는 반드시,

중요한 오래된 코드가 지워지지 않았는가?

도 확인합니다.

이 사고방식은 매우 중요했습니다.

Before:
새로운 수정이 들어갔는가?
After:
...

AI 코딩에서는 신규 생성 속도가 매우 빠르기 때문에, 아무래도 "추가된 것"에 의식이 향하게 됩니다.

하지만 실제 운영에서는 삭제된 것이 더 위험한 경우가 있습니다.

현재는 큰 수정 전에 체크포인트 (Checkpoint)를 만들도록 하고 있습니다.

git status
git add .
git commit -m "checkpoint before off-ramp refactor"

그 후 AI에게 수정을 시킵니다.

수정 후:

git diff

로 차이점 (Diff)을 확인합니다.

특히 보는 포인트는,

대량 삭제
관련 없는 함수의 변경
URL의 치환
...

입니다.

AI는 "코드를 깨끗하게 만들기" 위해 제품 고유의 예외 처리 (Exception Handling)를 지울 때가 있습니다.

사람이 보기에는 지저분한 코드라도, 실제로는 과거의 장애 대응에서 필요해진 조건일 수도 있습니다.

AI는 문맥 (Context)이 없으면 특수 처리를 불필요하다고 판단할 수 있습니다.

그래서 최근에는 중요한 예외 처리에 이유를 적도록 하고 있습니다.

나쁜 예:

if (amount >= 10000) {
spread = Math.max(spread, floor);
}

조금 개선:

// 고액 거래가 발생하는 신흥 시장 통로(corridor)를 위해 이 floor 값을 유지하십시오.
// 이 값이 없으면 관찰된 견적(quotes)에서 추정치가 너무 낙관적으로 변합니다.
if (amount >= 10000) {
...

더욱 필요한 경우:

// 실제 견적 샘플을 재검증하지 않고는 절대 제거하지 마십시오.
// 고액 USD/BRL 및 KRW 통로 확인 후 추가되었습니다.
if (amount >= 10000) {
...

이는 사람을 위한 것이기도 하지만, AI에게도 효과가 있습니다.

'불필요한 코드'가 아니라,

검증 결과에 따라 의도적으로 존재하는 코드

라고 전달할 수 있기 때문입니다.

현재의 흐름은 다음과 같습니다.

1. 문제 정의
↓
2. 변경 금지 로직 나열
...

Expo의 production build는 다음과 같이 수행합니다.

npx eas-cli build --platform android --profile production

Windows에서는 local build를 사용하지 않고, EAS 측에서 빌드합니다.

이 부분이 중요합니다.

예를 들어,

grep -n "adaptOffRampRow" App.js

으로 함수를 찾더라도,

function adaptOffRampRow() {
// ...
}

이 존재한다는 사실만으로는, 실제로는 호출되지 않고 있을 가능성이 있습니다.

즉, 존재 확인은

삭제 감지

에는 도움이 되지만,

올바른 동작 보장

은 되지 않습니다.

따라서 최소한 다음을 조합해야 합니다.

symbol check
+
git diff
...

이상적으로는 자동 테스트(automated test)도 추가해야 합니다.

하지만 소규모 개인 개발에서 테스트 기반이 충분하지 않은 단계에서도, 아무것도 하지 않는 것보다는 훨씬 낫다고 느낍니다.

저는 여러 AI 도구를 사용합니다.

예를 들어,

AI A → 버그(Bug) 수정
AI B → 리팩터링 (Refactor)
AI C → UI 개선
...

라는 상황이 발생합니다.

그러면 다음과 같은 일이 일어납니다.

AI A:
이 함수는 필요합니다
AI B:
...

최종적으로 제품 전체의 문맥(context)을 관리하는 것은 인간입니다.

AI가 늘어날수록,

코드 생성 능력

보다,

변경 이력과 의도의 관리

가 더 중요해진다고 느낍니다.

AI 코딩을 실무에서 사용하며 느낀 점은,

AI의 가장 큰 문제는 코드를 작성하지 못하는 것이 아니다

라는 것입니다.

오히려,

새로운 수정을 진행하면서, 과거에 검증된 로직을 망가뜨리는 것

이 더 위험했습니다.

현재 제가 최소한으로 수행하고 있는 것은 다음과 같습니다.

- 보호 대상을 먼저 결정
- Git 체크포인트(checkpoint) 생성
- git diff 확인
...

특히 개인 개발에서는,

새로운 코드가 들어왔는가

뿐만 아니라,

중요한 오래된 코드가 사라지지 않았는가

를 보는 것이 중요하다고 느낍니다.

이 기사의 예시는 제가 개발 및 운영하고 있는 TransferIQ에서 실제로 발생한 것입니다.

Web:

Android:

국제 송금, FX, Crypto off-ramp 경로를 비교하는 제품입니다.

기사 내에서 소개한,

• spread floor
• local exchange mapping
• off-ramp adapter
• route classification

등은 실제 제품 개선 중에 발생한 과제들입니다.

AI를 활용한 개인 개발을 하고 계신 분들께 여쭤보고 싶습니다.

AI가 하나의 버그를 고치는 대신, 과거에 고쳤던 기능을 다시 망가뜨린 경험이 있습니까?

또한, 테스트 코드가 아직 충분하지 않은 초기 프로젝트에서는 어떻게 회귀(regression)를 방지하고 계신가요?