한국 소프트웨어 산업협회의 엑셀 템플릿을 이용해 SW의 사업대가 산정하기(feat. 헤이영캠퍼스)

우리의 프로젝트는 얼마의 대가를 받아야하는 것일까?

 

눈에 보이지 않는 소프트웨어의 가치를 산정하기 위해

한국인공지능 및 소프트웨어 산업협회에서는 엑셀 템플릿으로 개발에 투입되는 공수를 계산할 수 있는 서비스를 제공한다.

이 글에 등장하는 템플릿 출처:

https://www.sw.or.kr/site/sw/ex/board/View.do?cbIdx=276&bcIdx=65004&searchExt1=

 

공식 홈페이지에 들어가서 SW사업대가 산정 방식별 엑셀 템플릿 (2026년도) 압축 폴더를 받아주고

그 중에서 아래의 파일을 열어준다.

 

 

 

열어보면 3개의 탭으로 되어있다.

 

 

 

 

 

 

1. FP 산정하기

첫번째 탭의 FP 산정 셀을 채우기 위해 실습 예제 신한 헤이영 어플리케이션을 열어서 5가지의 유형 중 하나로 분류해본다.

 

구분	유형	설명	헤이영 캠퍼스 예시
데이터 기능	ILF	내가 직접 만들고 관리하는 데이터	앱 내 개인 메모, 커뮤니티 게시글
	EIF	남이 만든 데이터를 빌려와서 보기만 함	대학교 학사 정보, 은행 잔액
트랜잭션 기능	EI	데이터를 넣거나 수정/삭제함	시설 예약 신청, 프로필 사진 변경
	EO	계산/가공 로직이 포함된 결과 출력	이번 학기 평점 그래프, 푸시 알림
	EQ	저장된 데이터를 그대로 꺼내 보여줌	학사 일정 조회, 강의실 목록 조회

 

앱의 첫화면은 아래와 같다.

시간 관계상 아래 8개의 MY 메뉴에 대해서만 이 글에서는 다루고 있다.

 

MY 메뉴의 8개 항목을 윗줄, 왼쪽부터 각각 1~8번 메뉴라고 하겠다.

각 메뉴에 대해서 FP와 아래의 항목들을 고려해야한다. 

 

RET(Record Entity Type)는 

각 기능이 참조하는 내부 논리 파일(학생정보, 학사일정, 시설정보 등)의

개수로 설정하면 된다. 논리적으로 구분 되는 요소를 세는 것이다.

데이터 기능(ILF, EIF)의 경우 이쪽을 사용한다.

FTR(File Type Referenced)은 

하나의 트랜잭션(입력, 출력, 조회 등)을 처리하기 위해 읽거나 쓰는 내부/외부 파일의 개수이다. 트랜잭션 기능(EI, EO, EQ)의 경우 이쪽을 사용한다.

같은 파일을 여러 번 읽는 경우 중복해서 세지 않는다. 

DET(Data Element Type)는 

화면에 나타나는 필드(텍스트 입력창, 버튼, 데이터 항목 등)

사용자가 식별 가능한 최소 단위의 개수를 세면 된다.

 

 

 

 

더 자세하게, 8개 메뉴 중에서 공지사항을 예시로 들어보겠다.

공지사항을 누르면 아래와 같은 화면이 된다.

 

가장 위쪽의 탭을 선택하면 해당 탭으로 분류된 공지사항들을 불러온다.

즉, 내부에 저장된 데이터 중 사용자의 선택에 따라 필터링해서 보여주는 방식이므로

EQ이다.

사용자가 데이터를 새로 생성하거나 수정, 삭제 등을 하는게 아니라 EI가 아니고,

수학적 계산이나 파생 데이터 생성 없이 데이터만 필터링 하므로 EO도 아니다.

 

FTR(트랜잭션이므로)은 1이다.

참조하는 파일이 학교 DB 내에 저장된 공지사항 마스터 테이블 1개이기 때문이다.

 

데이터 요소 분별 상세인 DET는 6이다.

사용자가 화면에서 식별할 수 있는 데이터 필드가 아래의 6가지이다.

 

1. 탭 선택 값 (일반, 대학, 교강사, 세종캠퍼스 등 - 사용자의 입력 조건)

2. 공지 제목

3. 작성 부서명 (예: 학생상담센터, 공학교육혁신센터 등)

4. 등록일

5. 첨부파일 유무 아이콘

6. 상세보기 이동 버튼 (각 리스트 항목 클릭 이벤트)

 

여기서 상세보기 이동 버튼을 누르면 새로운 페이지로 넘어가는데

DB에서 본문과 같은 다른 필드를 가져와서 보여주므로 대가 산정에 EQ로 새로운 항목으로 추가해야한다.

 

다른 항목들에 대해서도 RET/FTR과 DET를 생각해보자.

정통법에서는 사용자가 식별 가능한 데이터가 많을수록 DET가 올라간다.

참조하는 테이블(파일) 군이 많을수록 FTR이 올라간다.

찾아보니 대가를 산정할 때에는 보통 상세 페이지까지 포함하여 넉넉하게 잡는다고 한다.

 

참조하는 파일의 수인 RET/FTR은 최소 1~2개가 된다.

왜냐하면 보통 하나의 메뉴가 하나의 테이블을 보는 방식이 아니라

'내 정보(사용자)'와 연동되거나 '캠퍼스 구분(공통 코드)' 등을 함께 참조하기 때문이다.

특히 쿠폰함이나 전자출결은 접속한 계정에 따라 데이터가 달라져서 사용자 관련 테이블이 반드시 필요, FTR이 증가한다.

 

데이터 요소의 수인 DET는 화면에 보이는 글자 마디 하나하나를 세면 된다.

상세 페이지로 들어가면 본문 내용, 첨부파일명, 이전글 제목, 다음글 제목 등이 추가되어 합산 10~15개가 되는게 일반적이라고 한다.

 

조금 생각해보면 당연하게도

대가 산정 시에 리스트 조회와 상세 조회를 별개의 단위 프로세스로 쪼개서 각각 FP를 메기는 게 유리하다는 것을 알 수 있다.

(실제로 리스트 페이지의 검색 로직을 짜는 것과 상세 페이지의 데이터 렌더링을 구현하는 것은 별개의 작업이니까)

 

이번에는 쿠폰함의 경우를 살펴보겠다.

 

 

단위 프로세스는 쿠폰 목록 조회, 쿠폰 바코드 상세 조회, 제휴 혜택 페이지 연동의 3개이다.

 

쿠폰 목록 조회(EQ)는 탭 메뉴, 전체 쿠폰 개수 표시, 쿠폰 브랜드 이미지, 쿠폰명, 유효기간, 쿠폰 설명 문구, 상세 보기 버튼, 뒤로가기 버튼

이렇게 8개의 DET로 되어있다.

RET는 사용자 보유 쿠폰 마스터 파일(ILF)를 참조하는 것으로 1개이다.

 

쿠폰 바코드 상세 조회(EQ)는 

DET가 바코드 이미지, 쿠폰 번호(텍스트), 사용 방법 안내, 닫기 버튼의 4개일 것이다.

RET는 쿠폰 상세 정보 파일을 참조하는 것으로 1개다.

 

마지막으로 제휴 혜택 페이지 연동(EO)는 외부 연동 인터페이스로 FTR이 1이다.

DET는 외부 페이지 연결 정보, 클릭 이벤트 수신값의 2개이다.

 

위 3가지 말고도 쿠폰함 내부에 '사용하기' 등과 같은 버튼을 눌러 상태가 사용완료로 업데이트 되는 로직이 존재한다면

EI 유형을 추가로 도출하면 된다.

 

 

쿠폰함의 단위 프로세스 3가지를 가지고 표를 채우면 열에 있는 FP 산출 내역이 알아서 채워진다.

 

⑦의 복잡도는 각 기능(EI, EO, EQ)의 상대적인 난이도를 나타내는 것이다.

RET/FTR의 개수와 DET의 개수를 매트릭스(표)에 대조해서 L(Low, 낮음), M(Average, 보통), H(High, 높음) 중 하나로 결정한다.

 

⑧의 가중치는 위에서 결정된 복잡도(L, M, H)에 따라 실제로 부여되는 점수(FP) 값이다.

소프트웨어 사업 대가 산정 가이드에 정해진 표준 수치가 알아서 들어간다.

 

나머지 메뉴들도 전부 채워서 화면에 보이는 8개 메뉴에 대해 표를 아래와 같이 완성한다.

ILF와 EIF는 나머지 3가지 화면에 보이는 요소들과 다르게 뒤에서 돌아가고 있는 서비스를 생각해서 작성한다.

 

2. 산정된 개발비 확인하기

이제 두번째 탭으로 들어가면 알아서 계산이 되어있다.

저 8개의 메뉴에 대해서 약 7300만원 즈음을 받을 수 있다는 것을 알게 된다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

26.03.19 추가

검색으로 들어오신 분들이 좀 계셔서 말 남깁니다.

혹시 귀하가 이번 학기(26-1) 홍익대학교 윤 교수님 소프트웨어공학 수업을 듣고 있으시다면 저희 좀 친하게 지냅시다...

보안 공부하는 사람 하나 알고 있으면 언젠가 쓸모 있을지도 모르지 않습니까?(뻔뻔)

아직 제 블로그는 누추하지만 저점일 때 매수하십시오.

이상한 거 있으면 댓글도 좀 부탁드리겠습니다.

감사합니다.