053. 백파이어링 기법 (Backfiring Technique)

핵심 인사이트 (3줄 요약)

본질: 백파이어링(Backfiring) 기법은 이미 짜여 있는 기존 프로그램의 **소스 코드 라인 수(LOC)**를 기반으로, 프로그래밍 언어별 환산 계수를 곱해 역으로 소프트웨어의 **기능 점수(FP, Function Point)**를 추정하는 리버스 엔지니어링 척도다.

가치: 설계 문서가 증발해 버린 수십 년 된 레거시(Legacy) 시스템을 차세대 시스템으로 전환(Migration)할 때, 코드 길이만으로 기능의 규모와 재구축 예산을 빠르고 저렴하게 산정하는 유일한 구명조끼 역할을 한다.

판단 포인트: 프로그래머의 개인 코딩 스타일이나 불필요한 주석, 빈 줄까지 규모로 과대 포장될 위험이 있으므로, 단순 LOC가 아닌 논리적 명령문 수(Logical SLOC)를 기준으로 엄격히 환산해야 한다.

Ⅰ. 개요 및 필요성

소프트웨어 규모 산정의 두 축은 소스 코드의 길이(LOC)를 세는 방식과 논리적 기능의 개수(FP)를 세는 방식이다. 이상적으로는 사용자의 요구사항을 분석해 기능 점수(FP)를 계산하는 것이 맞다.

하지만 1990년대 코볼(COBOL)로 짜인 은행의 코어 뱅킹 시스템을 뜯어고친다고 가정해 보자. 설계 문서는 불타 없어졌고, 코드를 짠 개발자는 은퇴했다. 이 시스템의 기능이 정확히 몇 개인지 세는 것은 불가능하다. 이때 소프트웨어 공학자들은 "코드가 10만 줄짜리 코볼이라면, 과거의 통계에 비추어 볼 때 대략 기능 점수(FP) 1,000점어치 분량이겠군!"이라고 역산하는 통계학적 꼼수를 발명했다. 총구에서 불이 뒤로 뿜어지는 백파이어(Backfire)처럼, 결과물(코드)에서 원인(기능 규모)을 역방향으로 쏴서 맞추는 이 기법이 바로 백파이어링이다.

📢 섹션 요약 비유: 백파이어링은 '건물 철거 견적 내기'다. 건물의 설계도(요구사항 문서)가 없어서 방이 몇 개인지(기능 점수) 모를 때, 밖에서 건물의 전체 높이와 평수(소스 코드 라인 수)만 줄자로 재보고 "이 정도 크기면 철거비가 대략 10억쯤 나오겠다"고 역산하는 것이다.

Ⅱ. 아키텍처 및 핵심 원리

언어별 환산 계수(Conversion Factor)의 논리 구조

백파이어링의 핵심은 "프로그래밍 언어의 추상화 레벨이 다르면 동일한 기능을 구현하는 데 필요한 코드 라인 수도 다르다"는 절대 원칙에 기반한다.

┌────────────────────────────────────────────────────────┐
│           백파이어링(Backfiring) 기능 점수 역산 모델 로직     │
├────────────────────────────────────────────────────────┤
│   [ 공식 ]                                             │
│   기능 점수(FP) = 소스 코드 라인 수(SLOC) / 언어별 환산 계수 │
│                                                        │
│   [ 프로그래밍 언어별 1 FP당 평균 라인 수 (환산 계수 통계) ]  │
│   - 어셈블리어 (Assembly) : 320 줄 (저급 언어, 매우 김)       │
│   - C 언어               : 128 줄                      │
│   - 코볼 (COBOL)         : 105 줄                      │
│   - C++ / Java           : 53 줄 (객체지향, 짧아짐)          │
│   - 파이썬 (Python)       : 24 줄 (고급 스크립트, 매우 짧음)     │
│                                                        │
│ * 역산 예시: 53,000줄짜리 Java 레거시 코드를 발견했다면?      │
│   ──▶ 53,000 / 53 (환산 계수) = 대략 "1,000 FP"의 규모!       │
└────────────────────────────────────────────────────────┘

이 통계적 환산표를 거치면, 개발 언어에 상관없이 이 소프트웨어가 궁극적으로 사용자에게 제공하는 '비즈니스적 가치(기능 점수)'의 객관적 지표로 시스템의 덩치를 표준화할 수 있다.

📢 섹션 요약 비유: 언어별 환산 계수는 '화폐 환율'이다. 일본 돈(어셈블리) 320엔과 한국 돈(C언어) 128원, 달러(파이썬) 24달러가 모두 똑같은 '가치(1 FP)'를 지니듯, 화폐(언어)의 종류가 달라도 환율을 알면 원래 물건의 가치를 역으로 계산해 낼 수 있다.

Ⅲ. 비교 및 연결

정방향 FP 산정 vs 역방향 백파이어링

규모를 재는 두 가지 척도의 충돌이다.

항목	정통 기능 점수 (IFPUG FP)	백파이어링 (Backfiring)
산정 시점	프로젝트 기획 및 설계 단계	프로젝트 종료 후, 또는 유지보수/재구축(Re-engineering) 시점
분석 대상	사용자 요구사항 문서, 화면 설계서	완성된 물리적 소스 코드 파일(Source Code)
정확도	높음 (업무 로직 복잡도 정밀 계산)	낮음 (통계적 꼼수에 가까움, 코딩 스타일에 오차 큼)
비용 및 속도	분석 전문가 투입 필요 (비싸고 느림)	자동 툴(SLOC 카운터)로 돌리면 끝 (싸고 광속임)

정통 FP 방식은 설계도를 돋보기로 보며 문의 개수, 창문의 개수를 세는 정밀한 작업이다. 하지만 문서를 다 잃어버린 수십 년 된 레거시 환경에서는 이 돋보기를 댈 곳조차 없다. 이때는 오차가 좀 나더라도 코드를 통째로 긁어 라인 수를 세고 나누기만 하면 되는 백파이어링이 프로젝트 예산 산정을 위한 유일한 생명줄이 된다.

📢 섹션 요약 비유: 정통 FP가 책을 읽기 전에 '목차'를 보고 책의 내용과 깊이를 분석하는 것이라면, 백파이어링은 책의 내용(코드)을 안 읽고 그냥 '책의 두께(라인 수)'만 자로 재서 "음, 이 정도 두께면 5시간은 읽어야겠네"라고 거칠게 견적을 내는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

실무 시나리오

레거시 차세대 프로젝트 (Migration & Re-engineering) 예산 수립: 공공기관이 20년 된 C언어 기반의 시스템을 Java 기반의 최신 마이크로서비스(MSA)로 전환하는 사업을 띄운다. SI(시스템 통합) 업체 아키텍트는 C언어 100만 라인을 백파이어링 기법으로 나누어 약 7,800 FP를 도출해 낸다. 이를 바탕으로 "재구축에 필요한 투입 인력(Man-Month)과 수주 예산은 50억 원이 타당하다"는 물리적 근거 자료를 제안서에 박아 넣는다.
외주 소프트웨어 납품 단가 사후 검증: 외주 업체가 기능 점수 베이스로 돈을 받아 갔는데, 납품된 결과물(소스 코드)이 너무 빈약해 보일 때. 발주처는 납품된 코드의 라인 수를 백파이어링으로 역산해 보고, 사전에 합의한 기능 점수(FP)에 턱없이 못 미치면 "너희 기능 빼먹고 코딩 안 했지?"라며 감리(Audit) 딴죽을 거는 방어 무기로 활용한다.

안티패턴

물리적(Physical) 라인 수의 맹신: 소스 코드 라인을 셀 때 빈 줄(Blank line), 주석(Comments), 의미 없는 괄호({, })까지 전부 세어버리는 자동화 툴의 폐해. 실력 없는 개발자가 복사-붙여넣기(Copy & Paste)로 코드 길이를 뻥튀기해 놓으면, 백파이어링 공식은 이 쓰레기 코드를 '어마어마하게 거대하고 훌륭한 기능'으로 착각해 버린다. 반드시 실제 명령문 단위의 **논리적 라인 수(Logical SLOC)**만 정제해서 카운트해야 한다.
📢 섹션 요약 비유: 물리적 라인을 세는 것은 과대 포장된 과자 상자의 '부피'만 보고 돈을 내는 짓이다. 질소(주석과 빈 줄)를 쫙 빼고 진짜 들어있는 과자의 알맹이(논리적 실행 코드) 무게만 재어서 역산해야 바가지를 쓰지 않는다.

Ⅴ. 기대효과 및 결론

소프트웨어 공학에서 "정확히 틀리는 것보다, 거칠게라도 맞는 것이 낫다"는 명언을 가장 잘 대변하는 기법이 바로 백파이어링이다.

물론 개발자의 스킬이나 코드의 중복성에 따라 오차가 20~30% 이상 벌어질 수 있는 불안전한 수학 모델이다. 하지만 문서화의 무덤이 되어버린 거대한 레거시 시스템을 해체하고 재조립해야 하는 현대의 SI 유지보수 환경에서, 코드를 일일이 분석하는 천문학적 비용을 제거하고 단 몇 분 만에 규모의 '견적'을 뽑아낼 수 있는 이 기법의 가치는 여전히 절대적이다.

📢 섹션 요약 비유: 백파이어링은 미지의 밀림(레거시 코드)으로 들어가는 '대략적인 나침반'이다. 이 나침반이 정확한 GPS 좌표(정통 FP)를 알려주지는 않지만, 식량이 얼마나 필요하고 몇 명이 탐험을 가야 하는지 가장 싸고 빠르게 결정해 주는 유일한 길잡이다.

📌 관련 개념 맵

개념	연결 포인트
FP (Function Point, 기능 점수)	사용자의 시각에서 소프트웨어가 제공하는 논리적 기능의 개수와 복잡도를 세는, 백파이어링이 궁극적으로 역추적해서 도달하려는 최종 목표 지표
SLOC (Source Lines of Code)	소프트웨어의 소스 코드 줄 수. 백파이어링 공식의 입력값으로 쓰이는 가장 원초적인 규모 산정 척도
소프트웨어 리엔지니어링 (Re-engineering)	낡은 시스템 코드를 뜯어고쳐 새 시스템을 만드는 작업. 잃어버린 문서를 대신해 백파이어링이 가장 강력하게 쓰이는 주 무대

📈 관련 키워드 및 발전 흐름도

개발 전 규모 산정 지표로서의 LOC(Line of Code) 한계 (언어별 편차 심각)
    │
    ▼
기능 중심의 표준 지표 FP (Function Point) 도입
    │
    ▼
레거시 시스템 유지보수 시대 도래 (설계 문서 유실로 FP 산정 불가 현상)
    │
    ▼
과거 통계 데이터(언어별 생산성) 기반의 백파이어링(Backfiring) 기법 창안
    │
    ▼
소프트웨어 자산 관리 및 차세대 마이그레이션(Migration) 예산 산정의 표준으로 정착

이 흐름도는 "코드 중심 → 설계 중심(FP) → 레거시 환경의 제약 직면 → 과거 데이터(통계)를 활용한 역방향 추정 모델의 개발"로 귀결되는 소프트웨어 규모 산정(Size Estimation) 기법의 진화사를 보여준다.

👶 어린이를 위한 3줄 비유 설명

백파이어링은 겉모습만 보고 "이 공룡이 얼마나 무거운지" 거꾸로 맞추는 마술이에요.
건물의 설계도가 불타버려서 방이 몇 개인지 모를 때, 밖에 있는 벽돌(코드 라인 수) 개수만 세어서 방이 대충 몇 개인지 척척 수학으로 계산해 내죠.
아주 정확하지는 않지만, 수백만 줄의 낡은 코드를 뜯어고칠 때 비용이 얼마나 들지 제일 빠르고 싸게 알아내는 최고의 방법이랍니다!