기능 하나를 수정했는데 다른 기능이 깨지는 의존성 문제를 설명합니다. 화면, 상태, API, DB, 권한 연결을 지도처럼 확인하는 방법입니다.
작은 이름 하나를 바꿨는데 다른 화면이 깨졌다면 여러 기능이 같은 값과 규칙에 기대고 있었을 가능성이 큽니다.
연재 안내: 27편 전체 순서와 현재 공개된 글은 비개발자 바이브코딩 로드맵에서 확인할 수 있습니다.
한 함수 안의 역할부터 정리하려면 긴 함수 나누기 3단계를 먼저 확인하세요.
한 줄 답변
기능 의존성은 한 기능이 다른 화면, 상태, API, 데이터 구조, 권한 규칙의 결과에 기대는 관계입니다. 이 연결을 모르고 한쪽의 이름이나 형식을 바꾸면 멀리 떨어진 기능이 같은 값을 찾지 못해 깨질 수 있습니다.
예약 상태 이름 하나가 만드는 연쇄 오류
예약 문의 앱에서 상태값 confirmed를 더 쉬운 approved로 바꿨다고 해보겠습니다. 데이터베이스(DB)만 수정하면 끝처럼 보이지만 목록 필터, 관리자 버튼, 통계, 알림 조건이 모두 기존 값을 사용하고 있을 수 있습니다.
한곳만 바꾸면 데이터는 저장되지만 목록에 나타나지 않거나, 알림이 발송되지 않거나, 통계 숫자가 달라집니다. 이것이 기능 하나를 고쳤는데 다른 기능이 깨지는 대표적인 이유입니다.
의존성은 나쁜 것이 아니다
앱의 기능은 원래 서로 연결됩니다. 로그인 결과를 알아야 내 예약을 불러오고, 예약 데이터가 있어야 상태를 바꿀 수 있습니다. 문제는 의존성이 존재하는 것이 아니라 어디에 있고 어떤 약속으로 연결되는지 모르는 상태입니다.
좋은 구조는 연결을 없애기보다 입력과 출력, 데이터 이름, 오류 처리 같은 경계를 분명하게 만듭니다. 한 기능의 내부가 바뀌어도 약속된 출력이 같으면 다른 기능은 영향을 덜 받습니다.
기능 흐름을 화살표로 그린다
수정 전에 해당 기능의 흐름을 한 줄로 적어보세요.
예약 상태 버튼
→ 화면 상태 변경
→ PATCH /reservations/{id}
→ 서버 권한·상태 검사
→ DB status 수정
→ 새 예약 데이터 응답
→ 목록과 통계 다시 표시각 화살표가 의존 관계입니다. status 이름을 바꾼다면 이 흐름에서 그 값을 읽고 쓰는 모든 위치가 영향 후보입니다.
수정 영향 범위를 찾는 다섯 질문
- 이 값을 만들어내는 곳은 어디인가?
- 이 값을 읽는 화면과 함수는 어디인가?
- API 요청과 응답의 필드 이름이 바뀌는가?
- 데이터베이스의 기존 데이터도 변환해야 하는가?
- 권한, 알림, 통계, 테스트가 같은 값을 사용하지 않는가?
AI에게 프로젝트 전체 검색 결과를 요청할 수 있지만 검색된 모든 위치를 무조건 바꾸지는 않습니다. 같은 단어가 다른 의미로 쓰일 수 있으므로 각 파일의 역할을 확인합니다.
공용 상태와 전역 변수에 주의한다
여러 화면이 하나의 전역 상태를 직접 바꾸면 의존 관계가 보이지 않게 늘어납니다. 예약 목록 화면이 사용자 정보까지 수정하고, 로그인 화면이 예약 상태를 초기화하는 구조라면 작은 변경의 영향이 커집니다.
상태를 변경할 수 있는 통로를 제한하고, 업무 규칙은 한곳에서 관리하는 편이 좋습니다. 화면은 필요한 데이터를 받고 사용자 행동을 전달하는 역할에 집중합니다.
안전하게 바꾸는 순서
먼저 정상 상태를 커밋하고 현재 테스트 결과를 기록합니다. 다음으로 영향 후보를 목록화하고, 데이터 약속을 바꿀지 내부 구현만 바꿀지 결정합니다. 변경을 작은 단위로 적용한 뒤 직접 수정한 기능뿐 아니라 연결된 기능을 다시 테스트합니다.
예를 들어 상태값을 바꿨다면 상태 변경 성공만 보지 말고 목록 필터, 새로고침, 권한 없는 사용자, 알림과 통계까지 확인합니다. 필요하면 이전 값과 새 값을 잠시 함께 읽는 전환 단계도 계획합니다.
AI에게 영향 범위를 묻는 프롬프트
고친 뒤 예전 기능이 그대로인지 다시 확인하는 작업을 회귀 테스트라고 합니다.
예약 상태값을 변경하려 한다. 코드는 아직 수정하지 말고 이 값을 생성·저장·조회·표시·필터·알림에 사용하는 파일과 함수를 찾아 의존성 표로 정리해줘. 직접 영향과 간접 영향을 구분하고, 기존 데이터 변환과 회귀 테스트가 필요한지 알려줘.
기능 의존성을 이해하면 유지보수는 빨리 고치는 일이 아니라 안전하게 바꾸는 일이 됩니다. 변경 내용과 이유, 테스트 결과, 되돌리는 커밋을 함께 남기세요.
의존성 표를 실제 작업에 쓰는 법
기능 이름을 행에 두고 화면, 상태, API, DB, 권한, 알림, 테스트를 열로 둔 표를 만드세요. 예약 상태 변경 행에는 관리자 화면, 상태 저장 함수, 수정 API, 예약 표, 관리자 권한, 상태 알림, 상태 변경 테스트를 연결합니다.
수정 요청이 생기면 해당 행과 같은 열을 공유하는 다른 기능을 영향 후보로 표시합니다. 예를 들어 DB의 status 열을 함께 쓰는 목록 필터와 통계가 보이면 회귀 테스트 목록에 추가합니다. 모든 연결을 완벽히 그릴 필요는 없습니다. 자주 수정하고 실패 비용이 큰 기능부터 작성하세요.
표가 오래되면 오히려 잘못된 판단을 만들 수 있으므로 변경 커밋과 함께 갱신합니다. AI에게 표 초안을 만들게 할 수 있지만 실제 코드 검색과 API·DB 정의로 연결을 검증해야 합니다.
외부 서비스와의 의존성도 빠뜨리지 마세요. 결제, 이메일, 지도 API가 실패하거나 응답 형식을 바꾸면 내 기능이 멈출 수 있습니다. 시간 초과, 재시도, 대체 안내, 사용량 제한을 의존성 표에 추가합니다. 외부 기능이 없어도 핵심 흐름을 계속 사용할 수 있는지, 완전히 멈춰야 한다면 사용자에게 어떤 상태를 보여줄지도 정합니다. 코드 안의 함수 관계뿐 아니라 운영 서비스와 데이터의 관계까지 봐야 실제 수정 영향 범위를 찾을 수 있습니다.
기능 의존성 최종 점검
기능 의존성을 확인하려면 수정할 화면만 보지 말고 공유 상태, 공용 함수, API, DB 필드, 권한 규칙을 화살표로 연결해보세요. 기능 의존성 표에서 여러 기능이 같은 데이터나 함수를 사용한다면 그 지점의 변경은 관련 흐름을 모두 다시 테스트해야 합니다.
AI에게는 “이 파일을 바꿔줘”보다 “이 변경이 읽기·쓰기·삭제·목록 화면에 미치는 영향을 먼저 설명해줘”라고 요청하세요. 영향 목록을 만든 뒤 한 번에 한 연결만 수정하면 다른 기능이 깨졌을 때 원인을 좁히기 쉽습니다.
영향 범위를 찾았지만 낯선 코드의 흐름을 따라가기 어렵다면 다음 글 AI 코드 읽는 법: 비개발자 5단계에서 시작점·입력·출력·외부 영향을 순서대로 확인하는 방법을 이어서 보세요.
바이브코딩 전체 순서 보기
바이브코딩 뜻, 하는법, 도구 선택, API 연결, 데이터베이스, 배포 흐름은 바이브코딩 가이드에서 이어서 볼 수 있습니다.
