개발 중 기능 추가 요청, 비용은 어떻게 매겨질까요 | 변경 기준

핵심 요약

• 개발 중 기능 추가 비용은 대부분 예상 작업일수 × 인력 단가로 매겨져요.
• 공식 참고선인 2026년 적용 응용SW개발자 일평균임금은 37만 8,250원이에요. 5일짜리 변경이면 인건비만 약 189만 원이고, 외주 단가는 여기에 운영비와 기술료가 더해져요.
• 비용을 키우는 건 요청의 크기보다 시점과 파급 범위예요. 같은 변경도 테스트가 끝난 뒤에 들어오면 다시 확인할 화면이 늘어요.
• 직접 만들고 자체 SaaS를 운영해온 개발사 기준으로, 변경 요청을 계약서와 진행 방식에 어떻게 적어둘지 정리했어요.

“이거 하나만 추가해 주시면 되는데, 왜 견적이 또 나와요?”

개발 중반쯤 거의 모든 프로젝트에서 한 번은 나오는 말이에요. 발주하는 쪽에서는 작은 부탁이고, 개발하는 쪽에서는 이미 짜둔 구조를 다시 열어야 하는 일이에요. 둘 다 틀린 말은 아니라서 기준이 없으면 서운함만 쌓여요.

---

1. 기능 추가 요청은 왜 매번 서로 다르게 느껴질까요

화면에서 보는 크기와 개발에서 드는 크기가 다르기 때문이에요.

“회원 목록에 전화번호 칸 하나 추가해 주세요”를 예로 들어볼게요. 화면에서는 한 칸이에요. 그런데 뒤에서는 가입 화면에 입력 칸이 생기고, 저장 구조가 바뀌고, 개인정보라서 암호화와 마스킹이 붙고, 관리자 권한별로 보이는 범위를 나눠야 해요. 이미 가입한 회원의 빈 값은 어떻게 둘지도 정해야 하고요.

그래서 변경 요청의 크기는 화면 몇 개가 아니라 몇 군데가 같이 움직이느냐로 봐요. 이 감각이 서로 맞으면 견적 대화가 훨씬 짧아져요.

2. 변경 비용은 실제로 어떻게 계산되나요

가장 흔한 방식은 예상 작업일수 × 인력 단가예요. 공식 참고선부터 볼게요.

직무	월평균임금	일평균임금
응용 SW 개발자	775만 4,124원	37만 8,250원
IT PM	1,008만 6,804원	49만 2,039원
IT 기획자	1,185만 3,218원	57만 8,206원

공식 외부 기준 — 한국소프트웨어산업협회 「2026년 적용 SW기술자 평균임금」(조사년도 2025년, 2026년 1월 1일~12월 31일 적용)이에요. 일평균임금은 월평균임금을 근무일수 20.5일로 나눈 값이고, 전체 평균은 전년보다 4.7% 올랐어요.

이 표는 인건비예요. 공공 SW사업 대가 산정에서는 이 직접인건비에 회사 운영비인 제경비와 기술료를 더해 금액을 잡아요. 그래서 민간 외주 견적의 일 단가도 이 표보다 높게 나오는 게 정상이에요.

계산 예시를 하나 보면 감이 와요.

변경 내용(자사 실무 기준 예시)	개발	기획·확인	테스트	합계
목록 화면에 검색 조건 1개 추가	1일	0.5일	0.5일	2일
주문에 “부분 취소” 흐름 추가	5일	1일	2일	8일
회원 등급별 가격 정책 추가	8일	2일	3일	13일

위 일수는 저희가 범위를 나눌 때 쓰는 예시예요. 기존 구조에 따라 절반이 되기도, 두 배가 되기도 해요.

표에서 눈여겨볼 건 개발 옆의 두 칸이에요. 변경 요청 견적에 기획·확인과 테스트가 빠져 있으면 나중에 따로 붙거나, 확인 없이 넘어가서 오류로 돌아와요.

3. 같은 요청인데 왜 언제 하느냐에 따라 값이 달라질까요

요청이 들어오는 시점에 따라 다시 해야 할 일이 달라져요.

• 설계 단계 — 문서 몇 줄을 고치면 끝나요. 거의 비용이 안 붙어요.
• 개발 중 — 이미 만든 부분 중 영향을 받는 곳을 다시 열어요.
• 테스트 이후 — 고친 곳뿐 아니라 연결된 화면을 다시 전부 확인해야 해요.
• 오픈 이후 — 운영 데이터가 쌓여 있어서 기존 데이터를 옮기거나 보정하는 작업이 붙어요.

흔한 실수 — “오픈하고 나서 천천히 붙이죠”라는 결정이 가장 비싸게 끝나는 경우가 있어요. 화면 추가는 오픈 후에 해도 괜찮지만, 데이터 구조를 바꾸는 변경(가격 정책, 회원 유형, 주문 상태 같은 것)은 오픈 뒤에 하면 기존 데이터 보정 작업이 따로 생겨요. 이런 항목은 늦더라도 오픈 전에 결정해 주세요.

오픈 뒤에 들어오는 수정이 유지보수 범위인지 새 개발인지는 유지보수 비용은 얼마를 잡아야 할까요에 경계선을 정리해뒀어요.

4. “범위 안 조정”과 “추가 과업”은 어디서 갈리나요

여기서 분쟁이 가장 많이 나요. 기준은 요구사항 정의서에 그 기능이 적혀 있었느냐예요.

구분	예시	처리
범위 안 조정	문구·색상·배치 변경, 정의서에 있던 기능의 세부 동작 조정	추가 비용 없이 반영하는 경우가 많아요
경계 영역	정의서에 “검색”만 적혀 있고 조건 개수는 없던 경우	협의로 정해요. 그래서 정의서를 구체적으로 써야 해요
추가 과업	정의서에 없던 새 기능, 새 사용자 유형, 새 외부 연동	별도 견적과 일정 조정이 필요해요

경계 영역이 넓을수록 분쟁이 커져요. 정의서에 “관리자가 회원을 관리한다” 한 줄만 있으면 조회만인지, 수정·탈퇴 처리까지인지 해석이 갈리거든요. 정의서를 어떻게 적으면 이 영역이 줄어드는지는 요구사항 정의서 어디까지 써야 하나요에 예시가 있어요.

5. 공공 SW사업은 과업 변경을 어떻게 다루나요

공공 쪽은 법에 절차가 있어요. 「소프트웨어 진흥법」은 발주기관과 계약한 사업자가 과업 내용 변경에 따른 계약금액 조정이 필요할 때 과업심의위원회 개최를 요청할 수 있게 해두었어요.

그런데 현장에서는 과업이 늘어도 예산 부족을 이유로 실제 계약 변경으로 잘 이어지지 않았다는 지적이 계속 나왔어요. 그래서 2026년 7월 국회를 통과한 개정안이 세 가지를 바꿨어요.

• 과업 변경 시 과업심의위원회 개최를 의무화
• 발주기관이 스스로 심의 절차를 진행
• 심의 결과 반영에 필요한 예산 확보를 국가기관 장에게 의무화

개정 법률은 공포 후 6개월 뒤 시행되고, 시행 이후 체결하는 계약부터 적용돼요. 업계에서는 시행령과 예산 배정 기준 같은 후속 정비가 따라와야 현장이 바뀐다고 보고 있어요.

공식 외부 기준 — 개정안 내용은 지디넷코리아 보도(2026년 7월 27일)를 기준으로 했어요. 시행일과 세부 절차는 공포 후 법제처 국가법령정보센터에서 확인하세요.

민간 프로젝트에는 이 법이 적용되지 않지만, 원칙은 그대로 빌려 쓸 수 있어요. 과업이 바뀌면 절차를 거쳐 금액과 일정을 같이 조정한다는 거예요.

6. 계약서와 진행 방식에 적어둘 6가지

변경은 막을 수 없어요. 대신 변경이 들어왔을 때 어떻게 처리할지를 미리 정해두면 싸움이 줄어요.

1. 변경 요청서 양식 — 요청 내용, 요청자, 요청일, 이유를 한 장에 적어요. 메신저 한 줄로 받은 요청이 가장 많이 사라져요.
2. 영향 분석 기한 — 요청을 받으면 며칠 안에 “영향받는 곳·작업일수·일정 영향”을 회신한다고 적어요.
3. 단가 기준 — 추가 과업을 어떤 일 단가로 계산할지 계약 때 미리 정해요. 변경 때마다 단가를 협상하면 대화가 길어져요.
4. 범위 안 조정의 한도 — 문구·배치 수정 같은 조정을 몇 회, 또는 몇 일까지 추가 비용 없이 반영할지 숫자로 적어요.
5. 일정 조정 규칙 — 추가 과업이 들어오면 오픈일이 얼마나 밀리는지, 아니면 다른 기능을 빼서 맞출지 선택지를 둬요.
6. 승인권자 — 누가 승인해야 개발에 들어가는지 정해요. 실무 담당자 요청을 개발사가 바로 받으면 결재 뒤에 뒤집히는 일이 생겨요.

운영사 Tip — 저희는 변경 요청마다 “넣으면 무엇이 밀리나요”를 같이 적어서 드려요. 금액만 보면 “그 정도면 넣죠”가 되는데, 오픈이 2주 밀린다는 걸 같이 보면 “이건 오픈 뒤로 미루죠”로 결정이 바뀌는 경우가 꽤 많아요.

7. 운영까지 보면 무엇이 달라질까요

자체 SaaS 4종을 직접 운영하며 배운 게 하나 있어요. 개발 중에 추가한 기능 가운데 오픈 뒤에 거의 안 쓰이는 것들이 꽤 나와요. 회의에서는 꼭 필요해 보였는데, 실제 사용자는 다른 방식으로 일을 하더라고요.

그런데 한번 들어간 기능은 운영비를 계속 먹어요. 운영체제가 업데이트될 때마다 확인해야 하고, 다른 기능을 고칠 때 같이 테스트해야 하고, 문의가 들어오면 답해야 해요.

그래서 변경 요청을 받을 때 저희가 하나 더 여쭤보는 게 있어요. “오픈 첫 달에 이 기능을 누가, 하루 몇 번 쓸까요?” 답이 선명하면 넣고, 흐리면 오픈 뒤 사용 데이터를 보고 결정하자고 제안해요. 결과적으로 처음 예산 안에서 오픈할 확률이 높아져요.

비용 구조 전체를 한 번 훑고 싶으시면 소프트웨어 개발 외주 비용 가이드부터 보시면 순서가 잡혀요.

변경 요청 때문에 일정과 금액이 계속 흔들리고 있다면, 지금 계약서와 진행 방식부터 같이 짚어볼게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 요청을 받는 쪽과 운영하는 쪽을 둘 다 해봐서, 어떤 변경이 오픈 뒤에 비용으로 돌아오는지 겪어서 알아요.

8. 자주 묻는 질문

버튼 하나 추가하는 것도 추가 비용을 내야 하나요?

화면에 버튼만 붙는 거라면 대개 계약 범위 안의 조정으로 처리돼요. 비용이 붙는 건 그 버튼 뒤에 새 데이터나 새 처리 흐름이 생길 때예요. 예를 들어 “엑셀 내려받기” 버튼은 화면은 한 줄이지만 조회 조건·권한·대용량 처리가 같이 붙어요.

변경 요청 비용은 보통 어떻게 계산하나요?

예상 작업일수에 인력 단가를 곱하는 방식이 가장 흔해요. 공식 참고선으로는 한국소프트웨어산업협회가 공표하는 SW기술자 평균임금이 있고, 2026년 적용 응용SW개발자 일평균임금은 37만 8,250원이에요. 실제 외주 단가에는 여기에 회사 운영비와 기술료가 더해져요.

변경을 여러 개 모았다가 한 번에 요청하는 게 나을까요?

작은 조정은 모아서 주 단위로 전달하는 편이 나아요. 개발자가 흐름을 끊지 않아서 전체 시간이 줄어요. 다만 데이터 구조를 바꾸는 변경은 늦을수록 비싸지니 발견하는 즉시 알려주세요.

공공 SW사업은 과업이 바뀌면 어떻게 처리되나요?

소프트웨어 진흥법에 따라 과업 변경에 따른 계약금액 조정이 필요하면 과업심의위원회를 거쳐요. 2026년 7월 국회를 통과한 개정안은 과업 변경 시 심의 개최와 반영 예산 확보를 발주기관에 의무화했어요. 공포 후 6개월 뒤 시행되고, 시행 이후 체결하는 계약부터 적용돼요.

9. 마무리

기능 추가 요청 자체는 나쁜 신호가 아니에요. 만들면서 더 잘 알게 됐다는 뜻이기도 해요.

문제는 기준 없이 들어올 때예요. 계산 방식은 단순해요. 작업일수 × 단가, 여기에 기획·확인과 테스트를 빼먹지 않는 것. 그리고 언제 요청하느냐가 그 일수를 정해요.

계약서에 변경 요청서 양식, 단가 기준, 승인권자 세 줄만 먼저 넣어두세요. 그다음 변경부터는 서운함 대신 선택지가 남아요.

함께 보면 좋은 글

• 개발 외주 검수, 어떻게 해야 분쟁이 줄어들까요
• 저가 견적의 함정은 어디에 숨어 있을까요
• 개발 외주 견적 방식 3가지, MM·시간제·고정가 비교