기술보다 중요한 것은 “왜?”
오늘 오전 회의에서는 단순히 어떤 기술을 사용할지보다,
“왜 이 프로젝트를 만들고 어떤 문제를 해결하려 하는가?”에 대한 이야기를 중심으로 논의를 진행했다.
기술보다 중요한 것 = WHY
이번 회의에서 가장 인상 깊었던 말은 다음이었다.
“Redis, Kafka 같은 기술은 결국 도구일 뿐이다.”
그동안은 어떤 기술을 사용할지에 초점이 많이 맞춰져 있었다.
Kafka를 붙이고, Redis를 쓰고, OpenSearch를 넣는 구조 자체에 집중했지만,
오늘은 그보다 더 중요한 것이 있다는 피드백을 받았다.
- 왜 Kafka가 필요한가?
- 왜 Redis를 사용하는가?
- 왜 이 관제 시스템이 필요한가?
- 기존 관제 시스템과 무엇이 다른가?결국 발표에서 중요한 것은 기술 나열이 아니라,
그 기술을 사용하게 된 배경과 목적이라는 점이었다.
프로젝트 발표에서 중요한 “스토리텔링”
이번 회의에서는 발표 방향성에 대한 이야기도 많이 나왔다.
단순히:
1. Kafka 사용
2. Redis 사용
3. OpenSearch 사용
4. AI 예측 적용처럼 나열하는 방식은 기술 설명으로 끝나버릴 가능성이 크다는 의견이 있었다.
대신 아래와 같은 흐름이 중요하다는 피드백을 받았다.
예시 흐름
공정 이상 발생
AGV 이동 지연 발생
특정 공정 병목 확대
후속 공정까지 영향 전파
관제 시스템이 위험도를 분석
관리자에게 알림 및 대응 가이드 제공즉, “기술 설명”이 아니라
“어떤 상황에서 어떤 문제를 어떻게 해결하는가”를 보여줘야 한다는 것이다.
기능 중심 vs 서비스 중심
오후 회의에서는 프로젝트 방향성을 두고 팀 내부 논의도 진행했다.
# 기술 중심 접근
장점:
- 다양한 기술 스택을 강조 가능
- 시스템 구조 설명에 강함
단점:
- 발표에서 기술 나열만 하다가 끝날 가능성 존재
- 실제 사용자 관점이 약할 수 있음# 서비스 중심 접근
장점:
사용자 입장에서 이해하기 쉬움
AI 매뉴얼 같은 차별화 요소 추가 가능
단점:
자칫 주제가 “관제”보다 “서비스 기능” 중심으로 흐를 수 있음아직 팀 내부적으로 어느 방향에 더 집중할지는 결정하지 못했지만,
우선 ERD를 정의하고 데이터 구조를 먼저 정리한 뒤 다시 논의하기로 했다.
현재 진행 상황
현재는 다음 작업들을 병행 중이다.
- ERDCloud 기반 테이블 설계
- 공용 테이블 정의
- 각 기능별 데이터 구조 정리
- 데이터셋 정규화
- 샘플 데이터 생성특히 단순 더미 데이터가 아니라,
실제 공정 흐름처럼 보이는 데이터를 만드는 것이 중요하다는 이야기도 나왔다.
오늘 회의를 통해 느낀 점
오늘 회의를 통해 가장 크게 느낀 점은
“좋은 프로젝트는 기술이 아니라 문제 해결 흐름으로 설명된다”는 점이었다.
Kafka, Redis, OpenSearch 같은 기술은 분명 중요하지만,
그보다 중요한 것은:
- "왜" 필요한지
- 어떤 문제를 해결하는지
- 사용자가 어떤 도움을 받는지
를 설명할 수 있어야 한다는 것이다.
앞으로는 단순 구현보다도
“이 시스템이 실제 현장에서 어떻게 사용될 수 있을까?”를 더 많이 고민해보려 한다.
