재발급 토큰을 돌려 쓰면 어디까지 막을 수 있나
토큰이 한 번 새면 세션 전체를 끊는 구조를 어떻게 만드는지, 그 대가로 무엇을 포기했는지 적습니다.
컨설팅만 하고 빠지거나, 만들기만 하고 떠나지 않습니다. 진단부터 운영까지 이어서 맡습니다.
지금 쓰는 시스템이 왜 느리고 왜 자꾸 터지는지부터 짚습니다. 무엇을 이미 가지고 있는지 정리하고, 무엇을 새로 만들지 말지 가려 드립니다. 고른 이유는 문서로 남깁니다.
요구사항 정의부터 구축과 검수까지 한 흐름으로 진행합니다. 웹 서비스, 관리자 백오피스, API, 외부 시스템 연동을 다룹니다.
지금 어떻게 일하는지부터 봅니다. 그다음 사내에 흩어진 문서와 데이터를 AI가 읽을 수 있게 정리하고, 실제 업무 흐름에 붙입니다. 데모가 아니라 매일 쓰는 도구를 만듭니다.
만든 다음이 더 깁니다. 배포를 자동화하고, 문제가 생겼을 때 어디가 문제인지 바로 보이는 상태로 만들어 넘깁니다.
요즘 어디를 가나 AI 전환 이야기입니다. 우리가 그 말을 어떤 뜻으로 쓰는지 먼저 적어 둡니다.
자동화도 AX, 데이터 분석도 AX, 도구 하나 도입한 것도 AX라 부릅니다. 그러다 보니 AX가 아닌 게 무엇인지 알기 어려워졌습니다. 우리는 AX를 도입의 문제가 아니라 선택의 문제로 봅니다. 빨리 넣는 쪽이 아니라, 우리에게 맞는 것을 정확히 골라 붙이는 쪽입니다.
회사는 새로 시작하지만, 사람은 새롭지 않습니다. 대표가 실무에서 만든 결과를 그대로 적습니다.
아래 수치는 ONNIT 설립 이전, 대표가 재직 중 담당한 프로덕트에서 만든 결과입니다. ONNIT 명의의 실적과는 구분해서 표기합니다.
순서대로 진행합니다. 각 단계가 끝날 때 확인할 산출물이 있습니다.
대표가 기획부터 배포까지 직접 만든 프로젝트입니다. 채워 넣은 사례가 아니라 실제로 돌아가는 것들입니다.
AI에게 던진 질문을 모아 하루 회고로 되돌려주는 모바일 웹앱입니다. 일기를 새로 쓰게 하지 않고, 이미 한 질문에서 그날의 관심과 반복을 읽어냅니다. 밤에는 하루를 가볍게 닫고, 아침에는 손쓸 수 있을 때 돌아보는 두 번의 회고로 나눴습니다.
환자가 태블릿에 적은 내용이 원장 차트와 환자 휴대폰까지 실제로 나가는 시스템입니다. 접수 도메인과 원내 업무 시스템 두 축으로 나눠, 접수 11개 · 업무 29개 테이블을 설계했습니다. 프로그램과 처방, 탕전, 재고, 출고, 해피콜, 정산까지 원내 흐름을 담았습니다. 주민등록번호는 암호화해 보관합니다.
AI 기반 퀀트 투자 플랫폼입니다. 사용자 앱, 운영 백오피스, 코어 API, 데이터 수집 엔진 네 개 서비스를 하나의 저장소에서 관리합니다. 인프라를 코드로 정의해두고, main에 머지하면 네 서비스가 모두 자동 배포됩니다.
개인 지식 베이스에서 내보내도 되는 내용만 골라 반출하는 파이프라인입니다. 민감한 패턴을 차단하고, 기기마다 다른 경로를 일반화하고, 같은 입력이면 언제 돌려도 같은 결과가 나오도록 해시 목록을 남깁니다.
AI 에이전트가 쓰는 기능 묶음을 검증하고 빌드해 배포하는 저장소입니다. 실행 환경은 검증을 통과한 릴리스만 바라보고 원본 디렉토리는 절대 참조하지 않게 해, 수정 중인 코드가 실수로 운영에 흘러드는 경로를 없앴습니다.
유행을 따라가기보다, 오래 굴려본 것을 씁니다. 새 기술은 이유가 설명될 때만 씁니다.
이름에 하려는 일을 그대로 담았습니다.
ONNIT은 종합 IT 컨설팅 및 솔루션 회사입니다. 진단과 설계 같은 컨설팅부터 SI 구축, 외주 개발, 운영까지 한 흐름으로 맡습니다. 복잡한 지식과 AI를 연결해, 누구나 쉽게 쓸 수 있는 서비스로 만드는 것이 하는 일입니다.
요즘은 AI를 어디에 붙일지 골라 드리는 일이 부쩍 늘었습니다. 도구는 넘치는데 우리 조직에 무엇이 있고 무엇이 정말 필요한지는 아무도 정리해 주지 않기 때문입니다. 넣는 것보다 고르는 것이 어렵습니다. 그 판단을 같이 해 드립니다.
컨설팅 회사는 보고서만 남기고 떠나고, 개발 회사는 요구사항을 받아 적기만 합니다. ONNIT은 그 사이를 메웁니다. 왜 이렇게 만들어야 하는지 설명할 수 있는 사람이 직접 만듭니다. 재하청을 주지 않기 때문에, 설계한 사람과 코드를 쓴 사람과 배포한 사람이 같습니다.
대표는 7년 차 백엔드 엔지니어입니다. 인증과 권한, 결제 도메인, 운영 관측성을 실무에서 설계하고 운영해 왔습니다. 구현보다 왜 이 설계를 골랐는지를 드러내는 일을 중요하게 생각합니다.
실무에서 부딪힌 문제와 고른 답을 정리해 올립니다. 첫 글을 준비하고 있습니다.
토큰이 한 번 새면 세션 전체를 끊는 구조를 어떻게 만드는지, 그 대가로 무엇을 포기했는지 적습니다.
멱등 키를 어디에 걸어야 하는지, 외부 결제사 응답이 늦을 때 트랜잭션 경계를 어떻게 나눴는지 다룹니다.
사용량에 비례해 요금이 뛰는 방식 대신, 기존 장비에 얹어 비용을 고정한 과정과 그 한계를 씁니다.
아직 정리가 덜 됐어도 괜찮습니다. 무엇을 하고 싶은지만 알려주시면 나머지는 같이 정리합니다.