2025. 1. 15. 12:55ㆍProject Log/학부 졸업프로젝트
교수님과 월요일에 팀 면담, 화요일에 개인 면담을 줌으로 진행했다. 주요 내용을 정리하면서 앞으로 보완할 부분을 찾고자 한다.
팀 면담 내용 요약
✅ Fitbit을 착용하시는 부모님께 구글 폼 작성 요청 또는 통화로 정보를 기록해야 한다. 팀원들이 GPT처럼 Fitbit 데이터에 대해 설명하고, 그에 대한 반응을 수집하라는 것이다. 실제로 경험한 내용은 대화 다이얼로그를 설계하고 전체 서비스를 기획할 때 도움이 될 것이다.
✅ Physical Health Monitoring / Mental Health Monitoring / Daily Activity Monitoring을 구분해야 한다. Physical Health Monitoring은 Fitbit 데이터를 기반으로 모니터링 하는 것이다. Mental Health Monitoring과 Daily Activity Monitoring을 Fitbit의 음성 챗봇으로 뭉쳐버리면 안 된다고 하셨다. 정신 건강과 일별 활동 내용(활동, 식사)을 명확히 구분하라고 하셨다.
✅ Health Analyzer는 분석에 집중하며, Health Advisor는 조언 및 개입에 관여하는데 둘을 명확히 구분해야 한다. 주체에 따라 분석된 정보만 받을 수도 있고, 조언과 개입이 필요한 경우도 있다는 것이다.
✅ 불필요한 코드를 줄이고 서비스에 집중하기 위해, 서버 리스 아키텍처로 수정하라고 하셨다.
✅ 개발 전략은 다음과 같다. 1차는 On-Premise로, 2차는 AWS 기반으로 개발한다. '특정 기능 - Driver - Test Data' 단위의 모듈을 개발하라고 하셨다. 온프레미스 개발을 할 때, 복잡한 서버 측 애플리케이션을 사용하지 말고, 람다 함수의 형태로 간단하게 구현하라고 하셨다.
✅ 주언어는 Node.js로 하고, AI 관련 작업 시 파이썬을 사용하라고 하셨다.
개인 면담 내용 요약: 이벤트란 무엇인가?
어제 서버리스 아키텍처를 만들면서 EventBridge를 몇 개 배치했다. 일정 시간마다 람다 함수를 호출하여 Fitbit 데이터를 DB에 업데이트하거나, 리포트를 생성하도록 했다. 건강에 이상이 감지되거나, 리포트가 생성되면 람다 함수를 호출하여 알람을 보내도록 했다.
아래 아키텍처는 팀원들과 만들었던 기존 서버 기반 아키텍처를 서버리스 아키텍처로 수정한 것이다. 아직 혼자 생각한 내용이고 팀원 피드백을 일부만 받은 상태라서, 앞으로 회의와 수정에 들어가야 한다.
교수님께서 이벤트의 정의에 대해 물어보셨을 때, 나는 위의 내용을 답했다. 그것은 아주 작은 조각에 불과하며, 더 본질적이고 큰 의미의 이벤트에 대해 설명해 주신다고 하셨다. 그래서 어제 개인 면담이 시작된 것이다.
먼저 왜 이벤트가 필요한가?(Why) 이벤트가 무엇인가?(What) 이벤트가 어떻게 작동되는가?(How)를 생각해 보라고 하셨다. 이벤트라는 것은 '사건이 일어났다'는 뜻인데, 이는 이전 상황에서 무언가 바뀌었음을 의미한다.
동시에 이벤트는 독립적으로 존재하는 것이 서로 연결된 것처럼 만들어 준다. 팀원들과 교수님은 각자의 생활 패턴으로, 독립적으로 살아가지만, 프로젝트 완성이라는 공동 목표를 가졌기 때문에, 면담이라는 이벤트가 발생한다.
위의 아키텍처에 리포트 생성이 있다. 교수님은 리포트 생성은 하나의 Operation이고, 이를 트리거하는 이벤트를 잘 생각해 봐야 한다고 하셨다. 나는 매일 아침 6시 30분이라는 시간이 이벤트라고 생각했다.
하지만, 교수님께서 설명하고자 하는 이벤트는 '자식이 리포트를 보는 것' 혹은 '의사가 리포트를 보는 것'으로 설명하셨다. 이것은 EventBridge의 조건을 시간으로 설정하지 말라는 이야기가 아니다. Operation을 트리거하는 다양한 실제 이벤트를 생각해 보고 설계에 들어가라는 것이다.
'Lambda를 배치하고, 이벤트 트리거를 뭘로 할까?'가 아닌, '이러한 실제 이벤트가 발생할 수 있겠군, 이 이벤트가 발생하면 람다를 호출해야겠다!'의 순서로 가라는 것이다. 그래야 형식적인 설계에 그치지 않는다. 마이크로서비스 아키텍처를 설계할 때, 'MSA-event storming'이라는 것을 하니 찾아보라고 하셨다.
Situational awareness에 대해서도 말씀하셨다. 나는 자율 주행 차량이 있다면 주변의 사람, 도로 상황 등을 보는 것이 상황 인지일 것 같다고 말씀드렸다. 서비스를 설계하려면 두루뭉술하게 생각하지 말고, '전방 몇 미터에 차량이 몇 개 있는지 파악한다'와 같이 세밀하게 인식해야 한다고 하셨다.
원래 1월 말쯤에 '이벤트'에 대한 이야기를 하려고 하셨는데, 마침 관련 질문이 나와서 면담으로 얘기해주셨다고 한다. 서비스에서 발생할 수 있는 이벤트에 대한 정리가 마무리되면, DB에 어떤 데이터를 주로 저장할지 설계에도 들어가고, 1월 말까지 이러한 것들을 픽스하는 것이 계획이라고 하셨다.
개인적인 업무로는 Flutter와 GPT 모델에 대해 깊이 공부하라고 하셨다.
MSA-event storming
포스트잇을 붙이면서 event-storming하는 이야기를 해주셔서, 추가로 찾아보았다. 실제로 짧은 영상에 다 같이 포스트잇을 붙이면서 Event storming을 하는 모습이 있었다. 이런 시간이 좋은 서비스를 만드는 데 중요한데 각종 기술을 공부하느라 요새 조금 놓치고 있었던 것 같다.
다른 영상에서는 아래와 같이 컴포넌트를 분류해서, event-storming하는 방법을 설명한다.
유즈 케이스 다이어그램과 비슷한 느낌도 나는데, 틀에 갇히지 말고 정말 상세하고 작은 이벤트까지 생각해 보는 것이 이 활동의 목적인 것 같다.
