SI 프로젝트에서 기술 선택이 실패하는 이유 — 현장에서 반복되는 5가지 패턴

📌 서론

SI 프로젝트에서 실패는 대부분
코드 때문이 아니라 기술 선택 때문입니다.

일정은 맞췄는데

• 유지보수 지옥
• 장애 빈발
• 인수인계 불가능

이런 상태가 됩니다.

문제는 단순합니다.

“기술을 잘못 선택했다”

그리고 그 잘못은 항상 비슷한 패턴으로 반복됩니다.

---

📌 1. “유행 기술 도입” 실패

상황

“요즘 MSA가 대세입니다”
“Kafka 써야 합니다”
“AI 붙여야 합니다”

 

👉 요구사항보다 기술이 먼저 나옴

---

결과

• 서비스 쪼개놨는데 트래픽 없음
• Kafka 도입했는데 사실 REST로 충분
• 운영 인력 없음 → 장애 대응 불가

---

실패 원인

문제 정의 없이 기술 도입

---

핵심 정리

❌ 기술 → 문제
✔ 문제 → 기술

---

📌 2. “과도한 아키텍처 설계” 실패

상황

• MSA + Kubernetes + API Gateway + Service Mesh
• 그런데 실제는 단순 CRUD 시스템

---

결과

• 배보다 배꼽이 큼
• 개발 속도 ↓
• 운영 난이도 ↑

---

실패 원인

시스템 복잡도 > 비즈니스 복잡도

---

한 줄

필요 이상의 아키텍처는 부채다

---

📌 3. “벤더 종속 (Lock-in)” 실패

상황

• 특정 솔루션 강제 도입
• 특정 클라우드 기능에 강하게 의존

---

결과

• 기술 교체 불가능
• 비용 증가
• 장애 시 대응 불가

---

실패 원인

기술이 아니라 “제품”에 종속됨

---

예시

• 특정 검색엔진에 쿼리 로직 종속
• 특정 메시지 큐 SDK에 비즈니스 로직 포함

---

한 줄

교체 불가능한 기술은 리스크다

---

📌 4. “팀 역량 무시” 실패

상황

• 팀은 Spring만 아는데 Node + NestJS 도입
• 운영팀은 Docker 모름 → Kubernetes 도입

---

결과

• 코드 품질 ↓
• 장애 대응 불가
• 외주 의존 증가

---

실패 원인

기술 수준 > 팀 역량

---

핵심

기술은 팀이 소화할 수 있는 수준이어야 한다

---

📌 5. “운영을 고려하지 않은 선택” 실패

상황

• 개발은 잘됨
• 배포, 로그, 모니터링 없음

---

결과

• 장애 원인 파악 불가
• 재현 불가
• 운영 비용 폭증

---

실패 원인

개발 중심 사고 (Dev-only)

---

핵심

서비스는 “개발”이 아니라 “운영”이다

 

---

📌 6. 실패 패턴 정리

패턴                                                                                          본질

유행 따라감	문제 정의 없음
과도한 설계	복잡도 과잉
벤더 종속	교체 불가
역량 무시	실행 불가
운영 무시	유지 불가

---

📌 7. 해결 방법 (실무 기준)

✔️ 기술 선택 체크리스트

• 이거 없어도 서비스 돌아가나?
• 팀이 운영할 수 있나?
• 대체 가능한가?
• 장애 나면 우리가 해결 가능한가?
• 1년 후에도 유지 가능한가?

---

👉 하나라도 NO면

도입 보류

---

📌 결론

SI에서 기술 선택 실패는 특별한 일이 아니다.

항상 같은 이유로 실패한다

---

📌 마무리 한 줄

좋은 아키텍처는 화려한 기술이 아니라

망하지 않는 선택의 결과다