IT 프로젝트 실행을 방해하는 요인

Source: Dev.to

Cover Image

Author

자세한 내용을 여기에서 공개했습니다.

저는 시스템을 구축하는 데 18년 이상을 보냈습니다. 이것은 실패한 프로젝트들을 연구하면서 배운 점입니다. 코드 품질에 관한 것이 아니라, 실패 6–12 개월 전에 내려진 결정에 관한 것입니다.

실패는 일곱 가지 범주로 나뉩니다

1. 실행 모델 불일치

실수
현실: 고객 계약은 고정 범위를 요구합니다.
결과: 지속적인 범위 확대, 고객 분노, 그리고 약 18 개월 후 워터폴로 재전환.

사례 – 제조 소프트웨어 회사가 고정‑가격 계약과 스크럼을 동시에 사용했습니다. 범위가 계속 바뀌어 스프린트 내에 기능을 전달할 수 없었습니다. 범위를 제한하려고 하자 고객은 “원래 계약에 없던 내용입니다.”라고 답했습니다. 그들은 스크럼이 고정‑범위 비즈니스 모델과 맞지 않는다는 것을 깨닫는 데 2년이 걸렸습니다.

더 나은 접근법

프레임워크가 중요합니다. 비즈니스 모델이 프레임워크를 결정합니다.

2. 추정 연극

실수
스토리 포인트, 함수 포인트, 티‑셔츠 사이징, 혹은 AI‑기반 추정을 선택하면 모두가 자신감 있게 느낍니다. 6개월 후 속도가 40 % 감소하고 팀은 통합 지옥에 빠집니다.

왜 모든 방법이 실패하는가 – 세 가지 별도 차원을 혼합합니다:

1. 노력 – 엔지니어‑시간은 얼마나 되는가?
2. 복잡도 – 미지수가 얼마나 많은가?
3. 실행 위험 – 무엇이 잘못될 수 있는가?

예시 – 마이크로서비스 마이그레이션

노력은 일관됐지만 복잡도가 폭발했습니다.

더 나은 접근법 – 각 차원을 별도로 추정하고 복잡도/위험에 따라 완충을 추가합니다.

- **노력**: 120 엔지니어‑시간
- **복잡도**: 낮음(5개 미지) / 중간(15개 미지) / 높음(40개 이상 미지)
- **위험**: 기술, 통합, 공급업체, 인재
- **완충**: +30‑50 % 버퍼(복잡도/위험에 따라)

노력에 커밋하고, 일정에는 커밋하지 마세요.

3. 테스트 신뢰도

실수
팀 지표: 코드 커버리지 80 % + 좌측‑전환 테스트 + AI‑생성 테스트.
운영 지표: 두 해 전과 동일한 사고율.

왜 지표가 거짓말을 하는가

• 코드 커버리지는 **“코드가 실행됐는가?”**만 알려주고, **“제대로 동작하는가?”**는 알려주지 않는다.
• 좌측‑전환 테스트는 정상 경로에 집중하고, 운영에서는 99 %가 에지 케이스다.
• AI‑생성 테스트는 인간이 만든 테스트와 같은 맹점을 갖는다(잘못된 데이터, 잘못된 규모).

사례 – 자동화 커버리지 85 %인 소매 기업. 블랙 프라이데이에:

• 테스트는 깨끗한 데이터와 안정적인 트래픽에서 실행됨.
• 실제 트래픽은 100배 급증, 캐시 무효화 발생, 커넥션 풀 고갈.
• 운영이 6시간 다운 → 5 백만 달러 매출 손실.

더 나은 접근법 – 질문을 *“잘 동작하는가?”*에서 *“언제 깨지는가?”*로 바꾼다 – 즉, 카오스 엔지니어링과 실패 주입을 도입한다.

# Instead of this simple happy‑path test:
def test_user_creation():
    user = create_user("john@example.com", "password123")
    assert user.id is not None

# Do this:
def test_user_creation_under_load():
    # What breaks at 1 000 req/sec?
    load_test(create_user, requests=1000)

def test_user_creation_with_slow_db():
    # What if the DB is slow?
    slow_db_connection()
    user = create_user("john@example.com", "password123")
    assert user.id is not None  # or does it timeout?

def test_user_creation_concurrent_writes():
    # What if duplicate emails hit simultaneously?
    concurrent(lambda: create_user("john@example.com", "pass"))
    assert no_duplicates()

이 방식을 채택한 팀은 ~70 % 적은 사고를 경험합니다.

4. AI‑생성 코드 부채

실수

Source: …

| Month 1 | “우리는 Copilot을 사용하고 있어! 생산성 +30 %!” | | Month 6 | 코드 리뷰가 불가능해지고, 버그가 두 배가 되며, 리팩토링이 악몽이 된다. | | Month 9 | 코드베이스 정리하는 데 2 개월이 걸려 생산성이 마이너스로 전환된다. |

왜 이런 일이 발생하는가 – AI가 정상 흐름(해피 패스)에서는 동작하는 코드를 작성하지만, 오류 처리, 타입 검사 등이 부족하고 숨겨진 버그를 도입하는 경우가 많다.

예시 생성 코드

def process_orders(orders):
    results = []
    for order in orders:
        price = order['price'] * order['quantity']
        if price > 1000:
            price = price * 0.9   # 10% discount
        results.append({'order_id': order['id'], 'total': price})
    return results

즉시 동작하지만:

• 오류 처리 부재(예: 키 누락).
• 타입 검사 부재.
• 할인 로직이 다른 곳에도 복제 → 기술 부채(현재 47곳에 할인 코드가 존재).

더 나은 접근법

측정 지표

• 코드 품질 메트릭(순환 복잡도, 테스트 커버리지)
• 버그 밀도(1 000 LOC당 버그 수)
• 유지보수 비용(분기당 리팩토링 시간)

5. 관측성(Observability) 연극

실수
팀이 10 000개의 메트릭을 수집하지만 실제로 사용하는 것은 3개뿐이며, 나머지는 대시보드에 방치된다.

엔지니어가 관측성을 무시하는 이유

• 과부하된 대시보드 때문에 신호를 찾기 어렵다.

더 나은 접근법 – 대시보드를 간결하고 실행 가능하게 유지한다:

1. 명확한 SLO/SLI 정의.
2. 5‑7개의 핵심 메트릭을 선택해 직접적인 건강 상태를 나타내게 한다(예: 오류율, p95 지연 시간, CPU 사용량, 요청량, 큐 깊이).
3. 관련 메트릭을 하나의 시각화에 묶는다.
4. 중요한 임계값에만 알림을 추가해 알림 피로도를 방지한다.

엔지니어가 “시스템이 정상인가?” 라는 질문에 빠르게 답할 수 있을 때, 더 신속히 조치를 취할 수 있다.

엔지니어 워크플로 예시

tail -f /var/log/app.log | grep "slow"

• 2 분 만에 문제를 발견
• 대시보드는 “모든 시스템 정상”이라고 표시
• 로그에 “데이터베이스 쿼리가 45초 걸림” 기록

관측성은 데이터 수집이 아니라 의사결정을 위한 설계다.

묻는다: CTO가 의사결정을 위해 알아야 할 것은 무엇인가?

답변 – 5가지 필수 질문:

1. 이것이 장애인가? (예/아니오)
2. 몇 명의 사용자가 영향을 받는가? (숫자)
3. 무엇이 고장 났는가? (서비스명, 오류 유형)
4. 영향 범위는 어느 정도인가? (연쇄 실패 여부)
5. 롤백이 가능한가? (마지막 배포를 되돌릴 수 있는가)

위 다섯 항목에 답할 수 있는 대시보드를 구축한다. 나머지는 선택 사항이다.

사례 연구: 미디어 기업 – 알림 피로

• “최첨단” 관측성을 구축함.
• 알림 피로가 도입을 저해함.
• 45분 장애: 알림이 발생했지만 아무도 확인하지 못함.
• 비용: $2 M.

조직 변환 중력

실수

기술 스택을 현대화합니다:

• 마이크로서비스? ✓
• DevOps? ✓
• 클라우드? ✓

하지만 1995년 조직 구조는 그대로 유지합니다:

• 승인 프로세스: 12개월
• 채용: 인당 3개월
• 팀 구조: 기능별 사일로

결과: DevOps는 5분 만에 배포할 수 있지만 승인 대기 시간이 12개월입니다.

실제 사례: 통신 회사

• DevOps + 마이크로서비스로 현대화하고, “고급” 아키텍트를 채용했으며, 멋진 인프라를 구축했습니다.
• 하지만:
  • 기능 요청이 여전히 레거시 청구 시스템 승인 프로세스를 거칩니다.
  • 청구 시스템이 “모듈” 형태로 판매됩니다(유연성 없음).
  • 고객 계약은 12개월 고정 범위였습니다.

애자일 개발 팀이 고정 범위 요구사항과 충돌했습니다.

결과 (3년 후):

• 5천만 달러를 사용했지만 시장 출시 시간은 전혀 개선되지 않았으며, 리더십 교체가 세 번 있었습니다.

더 나은 접근법

먼저 조직을 변혁하세요—기술은 뒤따라야 하며, 그 반대가 아닙니다.

질문:

• 얼마나 빠르게 결정을 내릴 수 있나요? (1주? 1개월? 1분기?)
• 팀의 자율성은 어느 정도인가요? (완전? 승인에 따르는가?)
• 인센티브는 얼마나 정렬되어 있나요? (빠른 출시? 비용 관리? 위험 회피?)
• 사람들을 팀 간에 이동시킬 수 있나요? (조직 재편 비용? 유지 위험?)

레거시 중력이 새로운 기술보다 강합니다. 깨진 인센티브를 마이크로서비스만으로 해결할 수 없습니다.

혁신으로 최적화된 벤더 종속성

실수

“선도적인 벤더, 업계 표준, 훌륭한 사례 연구”를 선택한다.

벤더는 다음을 최적화한다:

• 종속성 (독점 API, 맞춤형 언어, 높은 전환 비용)
• 가장 높은 비용을 지불하는 고객(보통은 당신이 아님)의 요구에 따라 로드맵이 결정됨

벤더가 인수되면 → 제품 라인이 중단된다.

결과: $5 M 이상의 전환 비용에 얽매이거나 재작성 강요.

실제 사례: 핀테크 기업

• “핵심 플랫폼” 벤더를 선택했다.
• 벤더 메시지:
  • “핀테크 전용”
  • “엔터프라이즈 급”
  • “무중단 배포”

3년 후:

• 벤더가 인수 → 새로운 소유자가 제품 라인을 중단.
• 마이그레이션을 위해 완전 재작성 필요.
• 비용: $8 M, 18개월, 3명 퇴사.

더 나은 접근법

벤더가 실망시킬 것을 가정한다.

• 오픈 표준 사용 (SQL, REST, 표준 프레임워크).
• 핵심 데이터 흐름을 직접 관리 (벤더가 데이터를 소유하게 하지 않는다).
• 전환 비용을 낮게 유지 (독점 API 회피).
• 퇴출 계획 (마이그레이션 비용은 얼마인가?).
• 위험 분산 (가능한 경우 다수 벤더 사용).

실제로 효과가 있는 의사결정 프레임워크

6개월 후에, 왜 이 결정을 내렸는지 기억해야 할 것입니다.

당신의 판단을 테스트해 보세요

이 프레임워크를 2 분 안에 안내해 주는 간단한 시뮬레이터를 만들었습니다.

• 시도해 보기:
• 로그인도, 회원가입도 필요 없습니다. 그냥 직접 테스트해 보세요.