T3rry T3rry

Commit Only 구조를 선택한 이유DB 구조가 어느 정도 정리되자,자연스럽게 다음 질문에 도착했다.“이 데이터를 서버에는 언제 보내야 하지?”입고, 출고, 폐기, 실사…모두 사용자가 여러 단계를 거쳐서 완성하는 작업이다.중간 단계마다 서버에 저장할 수도 있었고,모든 걸 한 번에 보낼 수도 있었다.이 선택이 API 설계의 방향을 결정했다.Draft API를 처음엔 당연하게 생각했다초기에는 이런 구조도 떠올렸다.스캔할 때마다 서버에 임시 저장수정할 때마다 Draft 업데이트마지막에 확정 플래그만 변경UI 기준으로 보면 꽤 자연스럽다.하지만 조금만 더 생각해보니 문제가 보이기 시작했다.Draft를 서버가 들고 있을 때의 문제Draft를 서버에 저장하는 순간, 서버는 이런 상태를 감당해야 한다.아직 확정되..

처음 설계한 것과, 과감히 버린 것들시스템 구조가 잡히고 나면 자연스럽게 이 질문에 도착한다.“그래서… 이걸 DB에는 어떻게 담지?”데이터 모델링은 늘 그렇듯가장 논리적으로 보여야 하지만, 실제로는 가장 많이 흔들리는 단계였다.DB 설계의 첫 기준“이 테이블 하나만 봐도‘왜 이 데이터가 생겼는지’가 보이는가?” 정규화나 성능 이전에,맥락이 사라지지 않는 구조가 목표였다.지금 돌아보면 ERD를 먼저 그리지 않고‘질문’을 먼저 적는게 도움이 될 것 같다.가장 먼저 나눈 기준: 마스터 vs 이력초기 설계에서 가장 먼저 분리한 건 이 두 가지였다.변하지 않는 것계속 쌓이는 것그래서 자연스럽게 구조가 갈렸다.약품 마스터 (Item Master)입고 / 출고 / 폐기 이력약품 이름, 분류, 보관 조건은 바뀌지 않지..

‘기억하는 구조’를 만들다 (설계 + 짧은 회고)UX 흐름이 정리되자, 다음 질문은 아주 현실적인 문제로 바뀌었다.“이 모든 행동을 시스템은 어떻게 기억해야 할까?”단순히 데이터를 저장하는 문제가 아니었다.누가, 언제, 어떤 맥락에서 했는지를 나중에 다시 설명할 수 있어야 했다.시스템 설계의 출발 질문설계를 시작하며 가장 먼저 적었던 문장은 이것이다.“이 로그 하나만 봐도, 그날 무슨 일이 있었는지 설명할 수 있는가?”이 질문이 이후 구조를 나누는 기준이 되었다.지금 돌아보면 ‘기능을 어떻게 나눌까’보다,‘사용자가 어떤 기능을 사용할까, 원할까’를 먼저 본 게 좋았다.세션(Session)을 도입한 이유가장 먼저 등장한 개념은 세션이었다.입고 세션출고 세션관리 세션인수인계 세션세션은 내가 공부했던 웹 기술..

‘사람의 행동’을 기준으로 화면을 그리다기능이 정리되고 나서 가장 먼저 한 일은“사람은 이 냉장고 앞에서 어떤 순서로 움직일까?”UX 설계의 출발점은 행동화면이 아니라 ‘업무 순서’의약품 냉장고 앞에서의 행동은 생각보다 단순하다.냉장고 앞에 선다문을 열기 전에 무언가를 확인한다문을 연다약을 넣거나 꺼낸다문을 닫는다기록을 남긴다문제는 기존 시스템들이이 순서를 거의 고려하지 않는다는 점이었다.문은 그냥 열리고기록은 나중에 하고누가 했는지는 기억에 맡긴다그래서 우리는 UX의 첫 원칙을 이렇게 정했다.“사람의 행동 순서를 시스템이 거스르지 말 것”사전 태깅이라는 개념의 등장UX 설계 중 가장 큰 전환점은**‘문을 열기 전’**에 집중하면서 나왔다.“문을 열기 전에,이 사람이 누구인지부터 알 수는 없을까?”이 질..

브레인스토밍과 MVP 결정 과정“냉장고가 관리자가 된다”“사람의 실수를 시스템이 보완한다” 문제는 아주 단순했다.이걸 어떻게 ‘기능’으로 만들 것인가?막연한 아이디어의 위험함아이디어 단계에서는 무엇이든 가능해 보인다.하지만 개발을 시작하려면 반드시 이 질문을 통과해야 한다.“이걸 지금 당장 구현할 수 있는가?”그래서 두 번째 회의의 목표는 명확했다.할 수 있는 것지금 해야 하는 것지금은 하지 말아야 할 것이 세 가지를 가르는 회의였다.기능 브레인스토밍의 기준브레인스토밍은 자유롭게 했지만,기능으로 채택할지 말지는 아래 기준으로 판단했다.실제 업무 흐름에 등장하는가사람의 판단을 줄여주는가기록을 ‘자동’으로 남길 수 있는가“있으면 좋아요”가 아니라**“없으면 사고가 날 수 있는가”**를 기준으로 걸러냈다.처음..

스마트 냉장고 아이디어에서 출발 한 회의.너무나 다양한 사용자 패턴과 물건들이 많아서 인식이 어려울 것 같아서 더 제한된 환경에서 사용되는 냉장고가 없을까? 라는 생각을 하게되었다.“현장에서 정말 불편한데, 너무 당연해서 아무도 문제라고 말하지 않는 게 뭐가 있을까?”우리가 바라본 현장팀원의 지인중에 간호사로 일하시는 분들이 있어 인터뷰를 진행했다.아이디어 회의의 출발점은 의료 현장, 그중에서도 의약품 관리였다.특히 병동이나 응급실에서 사용하는 의약품 냉장고는 생각보다 많은 규칙과 책임을 안고 있다.냉장 보관 필수 약품 (2~8℃)유효기한 관리향정신성 의약품의 이중 잠금근무자 교대 시 인수인계온도 이탈 시 조치 기록문제는 이 모든 게 사람의 기억과 수기 기록에 많이 의존하고 있다는 점이었다.“온도는 하루..

이번 글에서는 Proxmox에서 window VM을 설치하고 파이코인 채굴 노드 환경을 구축하는 과정을 작성하겠습니다.저는 홈서버에 Proxmox OS를 올려서 사용중입니다. 홈서버에서 코인 채굴을 돌리면 다른 서비스에 영향을 줄 수도 있다고 생각할 수 있지만, 파이코인은 복잡한 연산을 수행하는 방식이 아니라, 인터넷만 연결되어 있으면 내 컴퓨터가 인증 역할을 해주는 방식이라서 리소스 부담이 적습니다. 대신, 코어 수가 많을수록 노드 점수를 높게 받아 채굴 속도가 증가합니다. VM 생성 연습도 할 겸, 서버를 놀릴 수도 없으니 운영해보았습니다. 😃파이코인은 리눅스 환경에서 채굴하기에 리눅스 가상머신을 돌릴수 있는 환경이 필요한데 웃긴게 코인을 채굴하는 걸 인증/보상 확인해주는 프로그램은 windows,..

안녕하세요! 오늘부터 새롭게 시작하는 시리즈 "홈서버 운영기" 입니다.첫이야기로 어쩌다 홈서버를 운영하기로 마음 먹었는지, 홈서버로 어떤 컴퓨터를 구매할지에 대한 이야기 시작합니다.홈서버를 운영하고 싶은 이유모든것의 시작은 아마존 aws가 비싸서... 비용 문제 💸처음 개발을 공부할 땐 AWS 프리티어가 충분했지만, 프로젝트 규모가 조금만 커지면 비용 부담이 생각보다 크더라고요. 작은 개인 프로젝트에 계속 돈을 쓰는 게 부담스러워졌어요. 계속 유지하고싶은 프로젝트들을 비용때문에 종료하는게 아쉽더라구요.서버 하드웨어 설정과 비용 최적화 경험을 얻고 싶어서 🛠️클라우드 서비스에서는 하드웨어 사양을 간편하게 클릭 몇 번으로 정할 수 있지만, 막상 어떤 사양이 내 프로젝트에 딱 맞는지 정확히 판단하기 어려웠..