-
시스템 설계Projects/약품고 (스마트 의약품냉장고) 2026. 2. 10. 12:49
‘기억하는 구조’를 만들다 (설계 + 짧은 회고)
UX 흐름이 정리되자, 다음 질문은 아주 현실적인 문제로 바뀌었다.
“이 모든 행동을 시스템은 어떻게 기억해야 할까?”
단순히 데이터를 저장하는 문제가 아니었다.
누가, 언제, 어떤 맥락에서 했는지를 나중에 다시 설명할 수 있어야 했다.
시스템 설계의 출발 질문
설계를 시작하며 가장 먼저 적었던 문장은 이것이다.
“이 로그 하나만 봐도, 그날 무슨 일이 있었는지 설명할 수 있는가?”
이 질문이 이후 구조를 나누는 기준이 되었다.
지금 돌아보면 ‘기능을 어떻게 나눌까’보다,
‘사용자가 어떤 기능을 사용할까, 원할까’를 먼저 본 게 좋았다.
세션(Session)을 도입한 이유
가장 먼저 등장한 개념은 세션이었다.
- 입고 세션
- 출고 세션
- 관리 세션
- 인수인계 세션
세션은 내가 공부했던 웹 기술의 세션이 아니라 그냥 우리만의 논리적 단위로 '세션'이라고 했다.
**“이 사람이 이 시간 동안 이 일을 했다”**라는 문맥 덩어리다.세션이 없으면 생기는 문제
- 로그가 전부 흩어진다
- 행동의 시작과 끝이 불분명해진다
- “왜 이 기록이 생겼는지” 설명하기 어렵다
그래서 모든 업무는 반드시:
- 세션 시작
- 행동 기록
- 세션 종료(커밋)
이라는 흐름을 갖게 했다.
처음엔 세션이 과하다고 느꼈지만,
로그가 쌓이기 시작하니 이게 없었으면
감사 대응은 거의 불가능했을 것 같다.
로그(Log)는 “기록”이 아니라 “증거”였다
다음으로 고민한 건 로그였다.
처음엔 단순했다.
- 누가
- 언제
- 무엇을
하지만 곧 깨달았다.
로그는 나중에 ‘설명해야 하는 데이터’다.
그래서 로그는 단순 이벤트가 아니라
행위의 타임라인으로 설계했다.- 태깅
- 문 열림
- 스캔
- 수정
- 커밋
이 흐름이 끊기지 않도록 했다.
로그를 “디버깅용”으로만 생각하면 항상 부족해진다.
운영과 감사까지 생각하면 처음부터 다르게 설계해야 한다.
왜 Draft 데이터를 서버에 저장하지 않았는가
입고/출고 중 만들어지는 임시 목록(Draft)은
의도적으로 서버에 저장하지 않았다.- 브라우저 상태로만 유지
- 커밋 시점에만 서버 전송
이 선택에는 두 가지 이유가 있었다.
- 실수 복구를 UX 차원에서 보장
- 서버를 ‘확정된 사실’만 기억하게 만들기
약품을 다루다가 갑자기 시스템이 다운되었을때 해당 과정의 기록이 날라가는 것에 대해선 아직도 고민이다. 단순히 이것을 위해 저장하는 행위를 하는게 트레이드오프할일인가? 에 대한 고민은 여전히 있으며, 레디스같은 캐싱을 하더라도 같은 보드에서 전부 운영되는 서비스가 다운이 되면 날라갈 것이라고 생각했다.
캐시(Cache)를 분리한 이유
시스템을 쓰다 보니 또 다른 문제가 보였다.
“어떤 데이터는 너무 자주 조회된다.”
- 현재 온도
- 최근 온도 추이
- 상단 상태바 정보
- 약품 마스터
이걸 전부 DB에서 읽으면
시스템이 상태 확인용으로 소모된다.그래서 역할을 나눴다.
- Redis: 지금 상태
- DB: 이력과 증거
설계 당시에 캐시가 과하다고 느꼈다. 적용할만한 지점이지만, 실제로 모니터링하고 응답속도를 보고 적용해나가는게 좋다고 느꼈다. 그렇지만 추후에 적용하는게 더 품이 많이 들수도있으니 여전히 고민이다.
시스템 구조를 관통한 하나의 기준
모든 설계를 관통한 기준은 이거였다.
“이 데이터는 ‘지금 보여주기 위한 것’인가,
아니면 ‘나중에 설명하기 위한 것’인가?”- 지금 보여주기 → 캐시
- 나중에 설명하기 → DB
- 그 둘을 묶는 맥락 → 세션
이 기준 덕분에 구조가 복잡해지지 않았다.
이 단계에서 남기는 짧은 회고
이 시스템 설계를 하면서 느낀 점은 하나다.
- 구조는 기능보다 늦게 보이지만
- 한 번 잘못 잡으면 되돌리기 어렵다
특히 의약품 / 안전 / 감사 도메인에서는
“나중에 설명할 수 있는 구조”가 거의 전부였다.