IT 설계는 종종 “기술적으로 가장 올바른 구조”를 찾는 일로 오해된다.
하지만 실제 현장에서 시스템이 무너지는 이유는 기술 부족이 아니라 현실을 잘못 가정했기 때문인 경우가 훨씬 많다.
경영학과 경제학은 애초에 한 가지 사실을 전제로 출발한다.
정보는 항상 불완전하고,
사람은 항상 합리적이지 않다.
이 전제는 IT 설계에도 그대로 적용된다.
완벽한 요구사항, 합리적인 사용자, 규칙을 잘 지키는 운영자는 존재하지 않는다.
그렇다면 IT 설계의 목적은 무엇이어야 할까.
1. IT 설계는 ‘정답’을 찾는 일이 아니다
경영학은 정답을 가르치지 않는다.
대신 망하지 않을 선택을 반복하는 방법을 다룬다.
IT 설계도 같다.
- 요구사항은 바뀐다
- 일정은 압축된다
- 인력은 교체된다
- 운영 환경은 예측 불가하다
이 상황에서 “가장 이상적인 아키텍처”를 찾는 것은 의미가 없다.
중요한 질문은 이것이다.
이 선택은 나중에 되돌릴 수 있는가?
좋은 설계란,
- 변경 비용이 낮고
- 실패했을 때 피해가 국소화되며
- 일부가 망가져도 전체가 죽지 않는 구조다
즉, 정답 설계가 아니라 생존 설계다.
2. 잘하는 개발자가 아니라, 깨지지 않는 시스템
경영학은 ‘유능한 개인’보다 ‘지속 가능한 조직’을 중시한다.
IT도 동일하다.
에이스 개발자 한 명에 의존하는 시스템은 이미 실패한 구조다.
- 그 사람이 휴가를 가면 멈춘다
- 그 사람이 퇴사하면 공백이 생긴다
- 그 사람만 이해하는 로직이 늘어난다
반대로 좋은 설계는 이렇게 말한다.
“이 시스템은 누가 와도 운영할 수 있다.”
그래서 설계에는 반드시 다음이 포함된다.
- 명확한 책임 경계
- 표준화된 인터페이스
- 로그와 모니터링
- 자동화된 배포와 복구
- 문서와 규칙
이는 기술적 미학이 아니라 조직 리스크 관리다.
경영학적 사고가 없는 설계는 결국 사람 문제로 무너진다.
3. 사람은 합리적이지 않다 — 그래서 시스템이 중요하다
경제학은 인간을 “항상 합리적인 존재”로 보지 않는다.
오히려 비합리적 행동까지 포함해 설명한다.
이 관점은 IT 설계에 매우 중요하다.
- 사용자는 매뉴얼을 읽지 않는다
- 운영자는 귀찮으면 우회한다
- 개발자는 평가 기준에 맞춰 움직인다
이건 도덕의 문제가 아니라 인센티브의 문제다.
- 보안 설정이 복잡하면 → 보안은 꺼진다
- 배포가 번거로우면 → 수동 배포가 된다
- 장애 보고 시 불이익이 있으면 → 장애는 숨겨진다
시스템은 사람을 바꾸지 못한다.
하지만 사람의 행동 방향은 바꿀 수 있다.
그래서 좋은 설계는 이렇게 묻는다.
“이 구조에서 사람들이 가장 쉽게 할 행동은 무엇인가?”
그리고 그 행동이 시스템에 안전한 방향이 되도록 설계한다.
4. 개인의 합리적 선택이 시스템을 망가뜨릴 수 있다
경제학에서 시장은 “의도하지 않은 결과의 집합”이다.
IT 시스템도 마찬가지다.
각 개인은 합리적으로 행동한다.
- 일정이 급하니 테스트를 생략한다
- 장애 대응을 빨리 끝내기 위해 임시 조치를 넣는다
- 다음 배포에 고치자며 기술 부채를 미룬다
하지만 이 선택이 누적되면 결과는 예측 가능하다.
- 테스트 부재 → 장애 상시화
- 임시 코드 → 구조 붕괴
- 기술 부채 → 변경 불가 시스템
대부분의 장애는 악의가 아니라 합리적 판단의 누적 결과다.
그래서 IT 설계는 사람을 통제하는 일이 아니라,
합리적 선택의 결과가 망하지 않도록 구조를 만드는 일이다.
5. 결론: IT 설계의 본질
경영학과 경제학 관점에서 보면,
IT 설계의 본질은 명확해진다.
- 완벽한 요구사항을 가정하지 않는다
- 합리적인 인간을 전제하지 않는다
- 정답 아키텍처를 찾지 않는다
대신,
불완전한 환경에서도 시스템이 버티게 만드는 구조를 만든다.
좋은 IT 설계란,
- 실패를 전제로 하고
- 변경을 허용하며
- 사람이 실수해도 시스템이 보호하는 구조다
이는 기술 역량의 문제가 아니라 사고 수준의 문제다.
그리고 이 관점을 가진 개발자는
단순한 코더가 아니라 설계자, 아키텍트, 시스템 빌더가 된다.
'Architecture' 카테고리의 다른 글
| Settlement(정산 배치) 설계 — JobRun·Item·재처리 중심 (0) | 2026.02.11 |
|---|---|
| Approval(상위 결재) 시스템 설계 — 상태머신·트랜잭션·멱등성 중심 (0) | 2026.02.11 |
| MSA와 MSA 아키텍처 (0) | 2026.02.10 |
| 경영학이 왜 개발자/아키텍트와 궁합이 좋은가 (0) | 2026.02.10 |
| IT프로젝트 기획/설계와 PM (0) | 2026.02.09 |
