“기술을 선택하기 전에 반드시 던져야 할 3가지 질문 — 생존하는 아키텍처의 기준”

📌 서론

새로운 기술은 계속 등장합니다.

• Kubernetes
• Spring AI
• LangChain
• Kafka
• OpenSearch

문제는 기술이 아니라 선택입니다.

많은 개발자들이 “좋은 기술”을 찾지만,
실제로 중요한 건 이것입니다.

“이 선택이 1년 뒤에도 유효한가?”

기술 선택은 코드가 아니라
비즈니스 리스크를 결정하는 행위입니다.

---

📌 1. 이 기술이 1년 후에도 존재할 것인가?

✔️ 본질

• 기술 자체가 사라질 가능성
• 커뮤니티 / 기업 backing 여부

---

❌ 잘못된 선택

• 유행만 보고 도입
• 레퍼런스 없음
• 유지보수 불가능

“요즘 이거 핫하다던데요?”

 

👉 이건 기술 선택이 아니라 유행 추종

---

✔️ 올바른 질문

• 누가 만들었는가?
• 누가 쓰고 있는가?
• 유지보수되고 있는가?

---

✔️ 예시

• Spring → 20년 이상 생존
• Kubernetes → CNCF 표준
• LangChain → 빠르게 변하지만 아직 불안정

---

👉 결론

기술은 기능보다 지속성이 먼저다

---

📌 2. 이 기술이 바뀌면 우리 서비스의 핵심 가치도 바뀌는가?

이 질문이 제일 중요합니다.

---

✔️ 본질

👉 “이 기술이 우리 서비스의 ‘본질’인가?”

---

❌ 위험한 구조

서비스 = 특정 기술

 

예:

• “우리 서비스는 LangChain 기반이다”
• “우리 시스템은 Kafka 없으면 안 된다”

👉 이건 강결합 구조

---

✔️ 올바른 구조

서비스 ≠ 기술
서비스 > 기술

 

👉 기술은 교체 가능해야 함

---

✔️ 예시

❌ 잘못된 설계

• 비즈니스 로직이 Kafka Consumer 안에 있음

✔️ 좋은 설계

• Kafka는 단순 전달 수단
• 도메인 서비스는 독립

---

👉 결론

기술은 교체 가능해야 한다
교체 불가능하면 그건 기술이 아니라 의존성 리스크다

---

📌 3. 우리가 해결하려는 문제의 본질은 무엇인가?

이 질문을 안 하면 100% 망합니다.

---

✔️ 본질

👉 기술은 문제 해결 수단이다
👉 그런데 문제 정의 없이 기술부터 고름

---

❌ 흔한 실수

“MSA로 가야 합니다”
“AI 붙여야 합니다”
“Kafka 써야 합니다”

 

👉 문제 없음
👉 해결책만 있음

---

✔️ 올바른 접근

문제 → 제약 → 해결 → 기술

 

 

---

✔️ 예시

❌ 문제 정의 없음

• “검색 시스템 만들어야 하니까 OpenSearch”

✔️ 문제 정의 있음

• “데이터 1억건, 부분검색 필요, latency 100ms 이하”

👉 그때 OpenSearch 선택

---

👉 결론

문제 없이 선택한 기술은
결국 유지보수 비용으로 돌아온다

---

📌 4. 세 질문을 하나로 묶으면

이 3개는 따로가 아니라 연결됩니다.

---

✔️ 구조

지속성 (1년 후 존재?)
↓
결합도 (핵심 가치 영향?)
↓
문제 정의 (왜 쓰는가?)

 

---

✔️ 최종 판단 기준

👉 이 3개 중 하나라도 YES 못 하면

❌ 도입하면 안 된다

---

📌 5. 실무에서 바로 쓰는 체크리스트

기술 도입 전 회의 질문

• 이거 없어지면 우리 서비스 영향 있나?
• 대체 가능한가?
• 이걸 왜 쓰는가?
• 안 쓰면 어떤 문제가 생기나?

---

👉 이 질문 못 답하면

도입 보류

---

📌 결론

좋은 개발자는 기술을 많이 아는 사람이 아니라

기술을 “선택할 줄 아는 사람”이다

---

📌 마무리 한 줄

기술은 답이 아니다

질문이 답이다