SI/SM 환경에서의 실용적 기술 선택: 과도한 엔지니어링을 피하는 지혜

SI/SM 프로젝트를 진행하면서, 저는 "최신 기술 스택"과 "실무 적합성" 사이에서 끊임없이 균형점을 찾아야 했습니다. MSA, Kubernetes, DDD, 헥사고날 아키텍처 같은 매력적인 패러다임들을 실제 프로젝트에 적용하고 싶은 욕구와 프로젝트의 실제 요구사항 사이에서 현실적인 선택을 해야 했던 경험들을 공유하려고 합니다.

기술 선택, 정답이 있을까?

첫 번째 깨달음: "복잡한 요구사항"이라는 착각

최근 진행한 B2B SaaS 프로젝트. 처음 요구사항을 들었을 때는 굉장히 복잡해 보였습니다. 멀티테넌시, 다국어 지원, 결제 시스템, 실시간 알림... 각 도메인 별로 중요해 보여 MSA 구조로 자연스레 생각을 했습니다.

하지만 실제로 요구사항을 분석해보니, 대부분이 CRUD에 약간의 비즈니스 로직이 추가된 수준이었습니다. 복잡해 보였던 건 "기능이 많아서"였지, "기술적으로 어려워서"가 아니었던 거죠.

MSA를 고민했던 이유를 돌이켜보니, 사실은 "MSA 구조를 신규 프로젝트에 써보고 싶어서" 였던것 같습니다. 실제 필요에서 나온 선택이 아니라, 기술적 호기심에서 나온 욕구였던 거죠.

결국 모듈형 모놀리스로 구현했고, 3개월 만에 성공적으로 런칭했습니다. 만약 MSA로 갔다면? 아마 아직도 서비스 간 통신 문제를 해결하고 있었을 것 같다고 생각합니다.

두 번째 깨달음: DDD는 언제 필요한가?

이벤트 시스템 구축 프로젝트였습니다. 예약, 알림, 외부 CRM 연동... DDD 책에서 본 것처럼 도메인 모델을 풍부하게 만들고 싶었습니다.

그런데 실제 비즈니스 규칙을 정리해보니 A4 한 장도 안 되었습니다. 대부분이 "예약 가능한 시간인지 체크" → "저장" → "알림 발송" 형태로 단순한 플로우였습니다.

DDD를 적용하려고 고민했던 시간이 아까웠습니다. 결국 단순한 서비스 레이어 구조로 3일 만에 핵심 기능을 완성했고, 나머지 시간은 실제 비즈니스 요구사항을 구현하는 데 집중할 수 있었습니다.

DDD가 필요한 순간은 분명 있습니다. 하지만 SI 프로젝트 대부분은 그 순간이 아니었습니다.

세 번째 깨달음: 레거시와의 공존

SM 프로젝트를 인수받았을 때의 충격은 아직도 생생합니다. 코멘트 제로, 테스트 코드 제로, 문서화 제로, 모든 로직이 한 프로젝트에...

처음엔 "전부 다시 만들어야 하는 거 아닌가?" 싶었습니다. 클린 아키텍처, 헥사고날, TDD... 배운 모든 걸 적용해서 확장성과 유지보수성을 위해 리팩토링하고 싶었죠.

하지만 현실은? 이미 운영 중인 서비스, 매일 들어오는 수정 요청, 레거시 코드를 완벽히 이해하는 사람 없음.

결국 선택한 전략은 "공존"이었습니다. 기존 코드는 최대한 건드리지 않고, 새로운 기능만 깔끔하게. 점진적으로, 아주 천천히 개선해 나가는 것.

이상적이진 않지만, 현실적이었습니다. 그리고 이것도 하나의 기술 선택이라고 생각합니다.

 

기술 선택의 현실적 기준

몇 년간의 SI 경험을 통해 정리한 나만의 기준들입니다.

프로젝트 생명주기로 판단하기

1-2개월 단기 프로젝트: 복잡한 아키텍처는 오버엔지니어링입니다. MVC 패턴으로 빠르게 구현하고, 핵심 기능에 집중합니다. 이벤트가 끝나면 사라질 시스템에 헥사고날 아키텍처를 적용할 이유는 없죠.

6개월 이상 중장기 프로젝트: 어느 정도 구조화가 필요합니다. 모듈 분리, 기본적인 테스트 코드, API 문서화 정도는 투자할 가치가 있습니다. 하지만 현실은? "일단 빨리 만들고 나중에 리팩토링하자"가 대부분이고, 그 '나중'은 오지 않는 것 같아요.

SI 현장의 인프라 현실

이상적으로는 서비스를 운영한다면 CI/CD 파이프라인, 컨테이너 오케스트레이션, 모니터링 시스템이 갖춰져 있어야겠죠.

하지만 실제 SI 현장은?

• DevOps 팀? 없습니다. 개발자가 서버 세팅부터 배포까지 다 합니다.
• Docker? "그게 뭔가요?" 하는 클라이언트가 대부분입니다.
• 모니터링? 서버 터지면 그때 알게 됩니다.
• 배포? FTP로 WAR 파일 올리는 곳도 아직 있습니다.

이런 환경에서 쿠버네티스를 논하는 건 사치입니다. 단순한 JAR 하나, 또는 전통적인 WAR 배포가 오히려 현실적인 선택이라고 생각합니다.

인수인계라는 현실적 제약

SI의 숙명은 "만들고 떠나기"라고 생각해요. 아무리 멋진 아키텍처를 설계해도, 인수인계받을 사람이 이해하지 못하면 의미가 없습니다. 복잡한 추상화보다는 직관적인 구조가, 세련된 함수형 프로그래밍보다는 익숙한 절차적 코드가 더 나은 선택일 때가 많습니다.

"왜 이렇게 단순하게 짰어?" 라는 질문보다
"왜 이렇게 복잡하게 짰어?" 라는 질문을 받는 게 SI에선 더 위험한 것 같아요.

 

SI 환경의 구조적 한계

SI 환경에서 개발하다 보면 분명한 한계에 부딪힙니다.

넓지만 얕은 지식의 딜레마

매 프로젝트마다 다른 기술 스택, 다른 도메인. 금융에서 제조로, 이커머스에서 공공기관으로. Spring을 쓰다가 Node.js로, Python을 하다가 React로.

이력서에는 많은 도메인과 기술스택이 쌓이는데, 정작 각 기술에 대해 제대로 깊게 아는 게 없다는 불안감이 듭니다. 나는 과연 전문가일까요, 아니면 그저 경험만 많은 초보자일까라는 생각이 듭니다.

시간이라는 절대적 제약

3개월 프로젝트라고 하면 실제로는 2개월 개발에 1개월 테스트와 안정화입니다. 코드를 개선하고 싶어도, 더 나은 구조를 적용하고 싶어도, 일정이라는 현실 앞에서는 무력해집니다.

결국 왜 그렇게 동작하는지 깊이 이해할 시간 없이 다음 태스크로 넘어가게 됩니다. 동작하면 OK, 다음으로. 같은 형태로 되기 쉽상이라고 생각해요.

 

그럼에도 불구하고, SI에서 배운 것들

"완벽한 코드"라는 환상에서 벗어나기

SI를 하면서 깨달은 가장 큰 교훈은 "완벽한 코드는 없다"는 것입니다. 교과서적인 DDD가 항상 정답은 아니고, MSA가 만능 해결책도 아닙니다. 때로는 단순한 MVC가, 때로는 복사-붙여넣기가 최선의 선택일 수 있습니다.

중요한 건 "왜 그 선택을 했는가"를 명확히 아는 것이라고 생각해요.

실용적 판단력이라는 자산

그렇다면 SI 개발자의 진짜 강점은 뭘까요? "주어진 제약 조건 내에서 최적의 해법을 찾는 능력" 이라고 감히 생각합니다.

3개월 안에, 한정된 예산으로, 타 개발자도 유지보수할 수 있게. 이런 현실적 제약을 고려한 기술 선택을 할 수 있는 것. 이것도 분명한 전문성이라고 생각해요.

넓은 시야의 가치

깊이가 부족하다고 자책할 때도 있지만, 다양한 기술과 도메인을 경험한 것도 자산입니다.

• Spring 개발자가 React 프로젝트를 이해할 수 있고,
• 프론트엔드 개발자와 백엔드 개발자의 고충을 모두 알고,
• 금융과 이커머스, 제조업의 도메인을 조금씩이나마 이해하는 것.

이런 넓은 시야가 언젠가는 큰 그림을 그리는 데 도움이 될 거라 믿습니다.

 

현재 환경에서 최선을 다하기

SI의 한계를 인정하되, 멈추지 않기

SI 환경의 구조적 한계는 분명 있습니다.
기술적 깊이를 추구하기 어렵고, 최신 기술을 마음껏 써볼 기회도 적다고 생각합니다. 하지만 이런식의 불평만 하고 있는건 의미가 없다고 생각해요. 따라서 지속적으로 할 수 있는 것들을 탐색하려고 노력합니다.

개인적으로 시도하는 것들

• 매 프로젝트마다 작은 개선 하나씩 (중복코드 통합, 이번엔 테스트 코드, 다음엔 문서화 ...)
• 퇴근 후 개인 프로젝트로 깊이 보완

팀 차원에서 할 수 있는 것들

• 프로젝트 템플릿 만들어 공유
• BE FE 코딩 컨벤션 작성
• 각 프로젝트 이슈 대응 및 조치 방안에 대해 정기적 미팅

기술 선택의 지혜

"우리가 선택할 수 있는 건 기술이 아니라 태도"

• MSA를 쓸 수 없다고 낙담하기보다는, 왜 지금은 모놀리스가 더 나은 선택인지 이해하기.
• DDD를 적용할 수 없다고 아쉬워하기보다는, 현재 도메인에 맞는 최적의 구조 찾기.
• 최신 기술 스택을 못 써본다고 조급해하기보다는, 기본기를 탄탄히 다지는 기회로 삼기.

 

마치며

SI/SM 환경에서 일하면서 가장 많이 듣는 말이 있습니다.

"SI는 기술력이 늘지 않아"

어느 정도는 맞는 말입니다. 하지만 완전히 틀린 말이기도 합니다. SI에서도 충분히 성장할 수 있다고 생각해요. 다만 그 성장의 방향이 다를 뿐이죠. "기술의 깊이"보다는 "선택의 지혜"를, "이상적인 아키텍처"보다는 "현실적인 해법"를, 이것들도 분명 가치 있는 성장이라고 믿습니다.

무엇보다, 지금 현재 상황에 맞춰 최선을 다하는 것. 그것이 SI든, 서비스 회사든, 어디에 있든 중요한 것 아닐까요?

기술은 도구일 뿐, 문제를 해결하는 건 결국 현재까지는 사람이라는게 제 생각 입니다.

- 여전히 SI 현장에서 최선을 다하고 있는 개발자ㅎㅎ -