화면, 업무 규칙, API 통신이 섞인 긴 함수를 역할별로 나누는 초보자 3단계를 설명합니다. 기능을 바꾸지 않고 안전하게 분리하는 방법입니다.
긴 함수는 줄 수보다 화면 표시·업무 규칙·외부 통신이 한 덩어리에 섞였는지를 먼저 봐야 합니다.
연재 안내: 27편 전체 순서와 현재 공개된 글은 비개발자 바이브코딩 로드맵에서 확인할 수 있습니다.
왜 코드가 길고 복잡해졌는지는 AI 코드 꼬임의 원인에서 먼저 확인할 수 있습니다.
한 줄 답변
긴 함수 나누기는 줄 수를 반으로 자르는 작업이 아닙니다. 화면 표시, 업무 규칙, API 통신처럼 서로 다른 책임을 찾고, 각 부분의 입력과 출력을 정한 뒤, 한 번에 하나씩 분리하고 기존 테스트를 다시 실행하는 작업입니다.
몇 줄부터 긴 함수일까
정답이 되는 줄 수는 없습니다. 100줄이어도 한 가지 표를 명확히 변환한다면 읽기 쉬울 수 있고, 30줄이어도 화면·권한·저장이 섞이면 수정하기 어렵습니다.
함수 이름을 한 문장으로 설명할 때 “그리고”가 여러 번 들어가면 역할이 많다는 신호입니다. “예약 폼을 그리고, 입력을 검사하고, 서버에 저장하고, 알림을 보여준다”면 분리 후보입니다.
먼저 정상 동작을 기록한다
리팩토링은 기능을 추가하는 작업이 아닙니다. 겉으로 보이는 동작을 유지하면서 내부 구조를 정리합니다. 그래서 시작 전에 정상 입력, 빈 입력, 서버 실패 등 현재 동작을 테스트하고 Git 커밋을 남겨야 합니다.
정리와 새 기능을 동시에 하면 오류가 구조 변경 때문인지 새 기능 때문인지 구분하기 어렵습니다. 이번 작업의 완료 기준은 “기존 결과가 모두 같고 역할만 분리됐다”로 정합니다.
1단계: 화면과 업무 규칙을 표시한다
긴 함수를 읽으며 코드 덩어리에 색을 붙인다고 생각하세요.
- 화면을 그리고 문구를 바꾸는 부분
- 날짜, 수량, 권한을 검사하는 부분
- 서버와 데이터를 주고받는 부분
처음에는 파일을 옮기지 말고 주석이나 메모에 시작과 끝만 표시합니다. 어떤 부분이 어떤 값을 받아 어떤 결과를 만드는지 적습니다.
예를 들어 validateReservation(input)은 예약 입력을 받아 오류 목록을 돌려주고, 화면이 어떤 색인지 몰라도 됩니다. 업무 규칙이 화면 요소를 직접 바꾸고 있다면 먼저 결과값을 반환하도록 경계를 만듭니다.
2단계: API 통신을 별도 함수로 뺀다
fetch, axios, 서버 주소가 있는 부분은 통신 역할입니다. saveReservation(data)처럼 데이터를 받아 서버 응답을 돌려주는 함수로 분리합니다. 이 함수는 버튼 문구를 바꾸거나 화면 이동을 직접 처리하지 않습니다.
통신을 분리하면 서버 주소나 인증 헤더가 바뀌어도 화면 전체를 수정할 필요가 줄어듭니다. 실패 응답을 숨기지 말고 호출한 쪽이 처리할 수 있는 형태로 돌려줍니다.
3단계: 입력과 출력만 연결한다
원래 긴 함수는 새로 만든 작은 함수들을 순서대로 호출하는 조정자 역할만 남깁니다.
입력 모으기
→ validateReservation(input)
→ saveReservation(validData)
→ 화면에 성공 또는 오류 표시각 함수가 다른 함수의 내부 변수까지 직접 바꾸지 않게 합니다. 필요한 값은 입력으로 받고 결과는 반환값으로 내보냅니다. 이 경계가 있어야 나중에 한 부분만 교체할 수 있습니다.
한 번에 하나씩 이동한다
화면, 검증, 통신을 동시에 여러 파일로 옮기지 마세요. 검증 함수를 먼저 분리하고 테스트한 뒤 커밋합니다. 다음으로 통신을 분리하고 다시 테스트합니다. 마지막에 화면 코드를 정리합니다.
작은 커밋은 문제가 생겼을 때 어느 단계가 원인인지 알려줍니다. AI에게도 한 단계의 변경만 요청하고 수정 전후 차이를 보여달라고 하세요.
분리가 잘됐는지 확인하는 질문
- 함수 이름 하나로 역할을 설명할 수 있는가?
- 입력값과 반환값이 분명한가?
- 화면을 바꿔도 검증 함수는 그대로 쓸 수 있는가?
- 서버 주소를 바꿔도 화면 파일 수정이 최소인가?
- 기존 정상·실패 테스트 결과가 같은가?
파일 수가 늘었는데도 한 값을 바꿀 때 여러 파일의 내부 변수를 함께 수정해야 한다면 책임이 제대로 분리되지 않은 것입니다.
AI에게 요청하는 안전한 프롬프트
이 함수의 기존 동작을 바꾸지 않고 화면, 업무 검증, API 통신 세 역할을 찾아줘. 코드를 바로 수정하지 말고 각 역할의 현재 줄 범위, 입력, 출력, 분리 순서를 먼저 제안해줘. 한 단계씩 적용하고 매 단계 실행할 수동 테스트를 알려줘.
긴 함수는 코드 한 덩어리의 문제입니다.
분리 후 오히려 복잡해졌다면
파일을 여러 개 만들었는데 한 동작을 이해하려고 다섯 파일을 계속 오가야 한다면 경계가 잘못됐을 수 있습니다. 작은 함수마다 공용 상태를 직접 읽거나 매개변수가 지나치게 많아졌는지 확인하세요. 화면 전용 값이 검증 함수까지 전달되거나 통신 함수가 화면 문구를 반환하는 것도 역할 혼재 신호입니다.
이때 다시 하나의 거대 함수로 합치기보다 각 함수가 꼭 알아야 할 입력만 남깁니다. 함께 바뀌고 함께 테스트되는 작은 코드들은 같은 모듈 안에 둘 수 있습니다. 좋은 분리는 파일 수가 아니라 변경 이유가 같은 코드를 가까이 두고 다른 이유로 바뀌는 코드를 떼어놓는 것입니다.
분리 전후의 함수 호출 순서를 간단한 화살표로 비교하면 불필요하게 왕복하는 값과 중복 검증도 찾을 수 있습니다. 구조가 더 단순해졌는지 사람 눈으로 확인한 뒤 다음 함수로 이동하세요.
긴 함수 나누기 최종 점검
긴 함수 나누기는 줄 수를 억지로 줄이는 작업이 아니라 입력 검증, 데이터 처리, API 호출, 화면 갱신처럼 서로 다른 책임을 분리하는 작업입니다. 긴 함수 나누기 전에 현재 입력과 출력, 오류 상황을 적어두면 분리 뒤 결과가 달라졌는지 비교할 수 있습니다.
한 번에 함수 하나만 꺼내고 이름만 읽어도 역할이 드러나게 만드세요. 각 단계마다 정상·빈 값·오류 상황을 실행하고 커밋을 남기면 리팩토링 중 문제가 생겨도 마지막 정상 상태로 쉽게 돌아갈 수 있습니다.
함수를 나눈 뒤에도 작은 수정이 예상 밖의 기능을 깨뜨린다면 다음 글 기능 의존성: 수정하면 깨지는 이유에서 화면·상태·API·DB 사이의 영향 범위를 찾는 방법을 확인하세요.
바이브코딩 전체 순서 보기
바이브코딩 뜻, 하는법, 도구 선택, API 연결, 데이터베이스, 배포 흐름은 바이브코딩 가이드에서 이어서 볼 수 있습니다.
