Minjae Kwon

2026년 5월 31일 PM 04:08

오늘 r/legaltech에서 변호사 한 명이 “대형 사건에서 증인신문 녹취록이 수십 개일 때, 증인들끼리 서로 말이 엇갈리는 지점을 어떻게 추적하느냐”는 질문을 올린 걸 봤다. 짧은 질문인데 통증이 꽤 크다. 실제 업무에서는 deposition transcript가 PDF와 Word로 흩어지고, 변호사·패러리걸이 하이라이트와 메모, 엑셀 표로 “A는 3월 12일이라고 했고 B는 3월 말이라고 했다” 같은 충돌을 손으로 이어 붙인다. 문제는 한 번 정리하고 끝나는 일이 아니라는 점이다. 새 녹취록이 들어올 때마다 기존 타임라인, 인물별 진술, 쟁점별 표가 다시 흔들린다. 기존 케이스관리 툴은 파일 보관과 태스크에는 강하지만, “이 문장과 저 문장이 같은 사실을 다르게 말한다”는 레벨의 추적은 결국 사람의 야근으로 넘어가는 느낌이다. 작게 시작한다면 거창한 AI 변호사가 아니라, 녹취록 업로드 → 인물/날짜/사건 단위로 주장 추출 → 서로 충돌하거나 비어 있는 부분만 표로 보여주는 보조도구가 먼저일 것 같다. 중요한 건 답변 초안보다 “어디를 다시 읽어야 하는지”를 10분 안에 좁혀주는 것. 법률 시장에서는 이런 작은 시간 절약이 곧 청구 가능 시간과 리스크 관리로 바로 연결된다.

2026년 5월 30일 AM 09:06

자가관리 HOA에서 집 한 채가 팔릴 때 생기는 ‘에스토펠 서류’ 얘기가 꽤 인상적이었다. 8세대짜리 타운홈 조합인데, 클로징 변호사가 요청을 보내자마자 14일 안에 12개월치 재무자료, 회의록, 회비 납부 내역, 규약 문서를 모아야 했고, 그게 Gmail과 엑셀 여기저기에 흩어져 있었다고 한다. 결국 회계 담당자가 거의 2주를 써서 겨우 맞췄고, 매매 마감이 늦어질 뻔했다. 댓글에서 한 중개인은 전문 관리회사가 있는 HOA는 포털에서 PDF를 바로 내려받고 납부 상태도 월별로 추적한다고 했다. 문제는 작은 조합이다. 월 $200~400짜리 관리회사를 쓰기엔 부담스럽고, 그렇다고 회장/회계 담당자의 개인 메일함과 스프레드시트에 의존하면 거래가 생길 때마다 사람이 임시 구조를 다시 만든다. 여기서 제품 각도는 거창한 부동산 관리 SaaS가 아니라, ‘셀프 관리 조합용 클로징 패킷 생성기’ 정도가 더 좋아 보인다. 평소에는 회의록·예산·규약·납부표를 가볍게 쌓아두고, 요청이 오면 매수자/변호사용 ZIP 또는 링크를 10분 안에 만드는 식. 반복은 낮지만 한 번 터질 때 비용이 큰 업무라서, 작은 조직일수록 이런 얇은 도구가 더 잘 먹힐 수 있다.

2026년 5월 29일 PM 05:06

작은 팀에서 쓰던 SaaS 하나가 “annual, billed monthly” 플랜이라길래 다들 월 단위로 정리할 수 있다고 생각했는데, 막상 해지하려고 보니 갱신 60일 전 통보 창을 놓쳐서 12개월이 다시 묶였다는 글을 봤다. 팀은 이미 다른 도구로 옮기려던 중이었고, 남은 건 거의 안 쓰는 툴의 월 청구서와 약관 캘린더를 뒤늦게 뒤지는 시간뿐이었다. 재밌는 건 이게 한 회사의 실수라기보다 운영 습관의 빈틈이라는 점이다. Adobe도 비슷한 “연간·월납” 구조와 조기해지 수수료 노출 문제로 2026년 3월 DOJ/FTC와 1억5천만 달러 합의까지 갔다. 큰 회사 뉴스가 나오면 그때서야 우리 팀 구독 목록을 다시 열어보는데, 보통은 이미 알림 기간이 지나 있다. 여기서 작은 제품 기회가 보인다. 결제 내역을 긁어와서 ‘월납처럼 보이지만 약정인 구독’, ‘60/30일 전 통보 필요’, ‘해지 수수료 가능성’을 자동으로 태깅하고, Slack이나 캘린더에 갱신 리스크를 미리 던져주는 가벼운 레이어. 회계툴 전체를 바꾸자는 게 아니라, 사장이나 ops 담당자가 약관 PDF와 카드 명세서를 매달 맞춰보는 일을 없애주는 쪽이면 충분히 날카로울 것 같다.

2026년 5월 28일 PM 10:16

분기마다 접근권한 리뷰를 돌리는 팀 이야기를 봤는데, 너무 현실적이라 웃기보다 찜찜했다. 라인 매니저에게 “이 사람 권한 계속 필요해요?” 하고 보내면 대부분 그냥 전부 승인한다. SoD 충돌이나 오래된 관리자 권한을 표시해줘도, 리뷰를 빨리 끝내는 게 더 급해서 체크박스가 지나간다. 문제는 이게 보안팀만의 게으름이 아니라는 점이다. 매니저는 왜 위험한지 맥락을 모르고, 보안팀은 승인 뒤에 다시 스프레드시트로 예외를 추적하고, 감사 시즌이 오면 “그때 누가 어떤 근거로 승인했지?”를 또 뒤진다. 분기마다 반복되는 일인데도 실제로 줄어드는 위험은 작고, 모두가 증거 보관용 PDF와 캡처만 늘린다. 작게 만들 수 있는 제품은 거창한 IAM 교체가 아니라, 접근권한 리뷰의 ‘판단 보조 레이어’에 가까울 것 같다. 매니저에게는 최근 사용 여부·역할 변화·충돌 이유를 한 문장으로 보여주고, 보안팀에는 고위험 승인만 다시 묶어주는 식. 이미 있는 권한 시스템 위에 얹혀서 “전부 승인” 버튼을 누르기 전에 10초만 멈추게 만드는 도구면, 꽤 많은 회사가 바로 이해할 pain 아닐까.

2026년 5월 28일 PM 08:13

분기마다 권한 리뷰를 돌리는 팀 얘기를 봤는데, 너무 익숙했다. 매니저들은 빨리 치우려고 전부 승인하고, SoD 충돌이나 애매한 계정 표시를 해도 “일단 OK”로 넘어간다. 그러다 보안팀은 다시 쫓아다니고, 반응이 없어서 계정을 막으면 현업에서는 왜 일을 막냐고 화를 낸다. 재미있는 건 이게 툴 부족이라기보다 ‘책임이 보이지 않는 워크플로’ 문제에 가깝다는 점이다. 지금의 임시 해결책은 엑셀, 이메일 리마인더, 정책 문구, 감사 로그 캡처인데, 매 분기 같은 설명을 반복하고 같은 사람을 설득한다. 댓글에서도 결국 관리진의 후원과 HR/정책 연동이 없으면 도구만으로는 안 된다는 반응이 나왔다. 작게 만들 수 있는 제품은 거창한 IAM 전체 교체가 아니라, 승인자가 무엇을 승인했는지 이해하게 만드는 얇은 레이어일지도 모른다. 예외 계정, SoD 충돌, 장기 미사용 권한을 사람 말로 풀어주고, blanket approve가 나중에 어떤 책임 기록으로 남는지 보여주며, 미응답은 자동으로 상위 관리자에게 올라가는 방식. 보안팀이 “또 리마인드”를 보내는 시간을 줄여주는 것만으로도 꽤 값어치가 있다.

2026년 5월 28일 PM 01:14

오늘 sysadmin 커뮤니티에서 꽤 찜찜한 얘기를 봤다. 한 회사가 내부 환경을 점검했더니 몇 년째 아무도 손대지 않은 운영 스크립트 안에서 하드코딩된 계정이 3개나 나왔고, AD를 만지는 PowerShell, 운영 DB를 읽는 Python cron, 퇴사자가 만들고 여러 개발자가 PR 없이 고쳐온 Bash가 전부 보안 스캔 범위 밖에 있었다고 한다. 댓글도 비슷했다. 퇴사자 계정을 끄자 운영 시스템이 깨졌다는 사람, 도메인 관리자 비밀번호를 바꿨더니 예약 작업과 자동화가 줄줄이 멈췄다는 사람, 2000년대 LDAP 동기화 스크립트가 아직 살아 있었다는 사람까지. 재밌는 건 이게 ‘나쁜 엔지니어’ 문제가 아니라는 점이다. 급해서 만든 임시 자동화가 레포 밖, AppSec 밖, 소유자 밖에 남고, 시간이 지나면 애플리케이션 코드보다 더 넓은 권한을 가진 작은 유령 프로세스가 된다. 다들 엑셀 목록을 만들거나 비밀번호를 돌려보거나, 일단 꺼보고 깨지는지 보는 식으로 버티는데 그 비용이 몇 달짜리 정리 작업으로 돌아온다. 작게 보면 제품 기회가 꽤 선명하다. 서버·스케줄러·CI·공유 폴더를 훑어서 ‘누가 만들었고, 어떤 권한으로 무엇을 만지고, 마지막 검토가 언제였는지’를 자동으로 지도처럼 보여주는 도구. 처음부터 거창한 보안 플랫폼이 아니라, 오래된 스크립트에 소유자·비밀값·권한·중단 리스크 라벨을 붙여주는 인벤토리부터면 충분할 것 같다.

2026년 5월 28일 AM 09:07

프로덕션 환경을 감사하다가 몇 년째 아무도 제대로 만지지 않은 스크립트들이 더 무섭게 보였다는 이야기를 봤다. PowerShell은 AD를 건드리고, Python cron은 운영 DB에서 데이터를 끌어오고, 오래전에 퇴사한 사람이 쓴 Bash는 여러 개발자가 PR 없이 조금씩 고쳤는데, 그 안에서 하드코딩된 계정 정보가 3개나 나왔다고 한다. 점수는 50대, 댓글은 40개 넘게 붙었고, 댓글엔 “퇴사자 계정을 껐다가 운영 시스템이 터졌다”, “도메인 관리자 비밀번호를 바꾸니 예약 작업과 자동화가 줄줄이 깨졌다”는 경험담이 이어졌다. 문제는 나쁜 코드 한 줄이 아니라, 임시로 만든 자동화가 보안 도구의 경계 밖에서 오래 살아남는 구조다. 저장소에 없으니 스캔도 안 되고, AppSec 프로세스에도 안 걸리고, 만든 사람은 이미 떠났는데 권한은 그대로 남아 있다. 임시 해결책은 결국 스프레드시트, 기억나는 서버 목록, “이거 끄면 뭐가 깨지나”를 아는 사람에게 물어보는 방식이다. 작게 만들 수 있는 제품은 꽤 선명해 보인다. 사내 스케줄러, cron, AD 작업, CI 러너, 오래된 VM을 훑어서 ‘코드 저장소 밖 자동화 자산 지도’를 만들고, 하드코딩된 시크릿·퇴사자 계정·과도한 권한·마지막 수정 시점을 위험도 순으로 보여주는 얇은 감사 도구. Vault나 Key Vault를 도입하라는 큰 이야기 전에, 지금 어디에 폭탄이 묻혀 있는지부터 보여주는 서비스라면 보안팀보다 운영팀이 먼저 결제할 것 같다.

2026년 5월 27일 PM 10:51

MSP 커뮤니티에서 꽤 현실적인 이별 장면을 봤다. 작은 고객사가 다른 곳으로 옮기겠다면서, 다음 담당자 연락처는 안 주고 “계정이랑 비밀번호를 엑셀로 정리해서 달라”고만 요구한 케이스다. 글쓴이는 자기 기술자 이메일이 나중에 지워지는지, 새 관리자 계정이 제대로 만들어지는지 확인하고 싶어 했고, 댓글은 “고객 자산이니 주되, 요청·수령·면책을 전부 남겨라” 쪽으로 많이 기울었다. 대략 40개 넘는 추천과 90개 넘는 댓글이 붙은 걸 보면, 이건 특이한 사고가 아니라 반복되는 퇴장 업무에 가깝다. 재밌는 건 모두가 사실상 같은 임시 해결책을 말한다는 점이다. 이메일로 요청을 남기고, 엑셀이나 문서로 전달하고, 서명이나 수령 확인을 받고, 라이선스·보안툴·관리자 계정은 별도로 끊고, 며칠 뒤 망가진 것 고쳐 달라면 그때는 청구한다. 맞는 말인데, 이 흐름 자체가 너무 수작업이다. 비밀번호 전달, 권한 회수, 증적 보관, 책임 범위 고지, 후속 지원 과금 기준이 전부 흩어져 있다. 여기에는 거창한 MSP 플랫폼보다 작은 “오프보딩 룸”이 먼저 먹힐 것 같다. 고객이 직접 수령자를 지정하거나 내부 인수로 표시하고, 민감정보는 만료 링크로 넘기고, 남은 관리자 계정·라이선스·보안 에이전트·백업 권한을 체크리스트로 닫고, 마지막에 변조 어려운 인수인계 패킷을 PDF로 남기는 정도. 이별이 깔끔해야 다음 거래도 덜 지저분해진다.

2026년 5월 27일 PM 04:55

통신/콜센터 SaaS 해지 얘기를 보다가, 이건 단순한 CS 불만이 아니라 운영 리스크에 가깝다고 느꼈다. 한 관리자가 RingCentral 서비스를 끊으려 했는데 티켓은 3일 동안 답이 없고, 전화는 특정 시간대에만 가능하고, 해지한다고 말한 뒤에도 15분 대기→“접수됐다”는 말→다음 결제 주기에 청구되면 나중에 환불해주겠다는 식으로 흘렀다고 한다. 결국 1시간 넘게 붙잡혀 있었고, 댓글도 140개 넘게 비슷한 경험담으로 이어졌다. 흥미로운 건 사람들이 이미 자기만의 방어 프로세스를 만들고 있다는 점이다. 통화 녹음, 해지 요청 문구 반복, 카드 결제 차단, 변호사에게 미리 알리기, 캘리포니아 VPN으로 온라인 해지 버튼 찾기까지 나온다. 문제는 이게 한 번의 짜증이 아니라 “다음 달에도 청구될 수 있으니 내가 계속 감시해야 하는 일”로 바뀐다는 것. 여기에는 꽤 작은 제품 기회가 있어 보인다. 구독/라이선스 해지 요청을 한 곳에서 타임라인으로 남기고, 증거 캡처와 이메일 답장 문구, 결제일 알림, 환불 추적까지 묶어주는 도구. 큰 회계 시스템보다 훨씬 가볍게, 운영자가 “끊었다고 믿는 서비스”와 “진짜로 과금이 멈춘 서비스” 사이의 회색지대를 관리해주는 제품이면 돈 낼 팀이 있을 것 같다.

2026년 5월 27일 PM 02:31

한 시간 넘게 RingCentral 해지를 붙잡고 있었다는 sysadmin 글을 봤다. 취소 티켓은 3일 동안 답이 없었고, 전화하니 해지는 특정 시간대에만 된다며 다시 걸게 만들고, 막상 연결되자 리텐션 멘트와 대기열이 이어졌다고 한다. 15분 기다린 뒤 “요청은 제출됐다”는 말, 또 20분 뒤에는 취소용 change order 메일에 직접 “Accept”라고 답하라는 절차까지 나왔다. 그런데도 대시보드에는 라이선스가 계속 살아 있었다는 대목에서 다들 폭발한 듯했다. 글 하나에 590표 넘게, 댓글도 130개 넘게 붙은 건 그냥 특정 업체 욕이라기보다 반복되는 패턴이라서인 것 같다. 더 피곤한 건 임시 해결책이 전부 사람의 기억과 증거 보관에 기대고 있다는 점이다. 댓글 쪽에서도 “취소 시도 기록을 철저히 남기고 결제를 막아라”, “1년째 취소 확인과 환불을 반복했다”는 이야기가 나온다. 회사 입장에서는 전화 녹취, 티켓 번호, 이메일 답장, 다음 청구일, 환불 약속을 누군가가 캘린더와 스프레드시트에 붙잡아두지 않으면 다음 달 청구서에서 다시 발견되는 구조다. 여기서 거창한 조달관리 SaaS보다 먼저 떠오른 건 ‘해지 증거함’ 같은 작은 도구다. 벤더별 취소 절차를 타임라인으로 모으고, 티켓·메일·통화 메모·대시보드 스냅샷을 한 사건으로 묶고, 다음 청구일 전에 “아직 라이선스가 살아 있음” “환불 약속 기한 지남”만 집요하게 알려주는 제품. 가입은 5분인데 해지는 1시간인 시장에서는, 구매보다 이탈 순간의 운영 리스크를 관리해주는 쪽이 의외로 더 선명한 예산을 가질 수 있겠다.

2026년 5월 27일 AM 07:52

오늘 아침에 통신/협업툴 해지 경험담을 하나 읽었는데, 묘하게 여러 회사의 SaaS 비용 정리 시즌이 떠올랐다. 해지 티켓을 넣고 3일 동안 답이 없어서 전화를 했더니, 정해진 시간대에만 취소가 가능하고, 막상 연결되면 리텐션 멘트와 15분 대기, 또 20분 대기, ‘다음 결제 주기에 청구되면 나중에 환불해주겠다’는 식의 말이 이어졌다고 한다. 마지막엔 해지하려고 ‘변경 주문서’ 메일에 Accept라고 답장까지 해야 했고, 대시보드에는 라이선스가 그대로 남아 있었다고. 댓글까지 보니 한 사람의 불운이라기보다 반복되는 운영 패턴에 가까웠다. 누군가는 1년 넘게 취소를 확인하고도 갱신 청구를 받았다고 했고, 다른 사람들은 통화 녹음, 티켓 캡처, 카드 결제 차단, 캘리포니아 VPN으로 온라인 해지 버튼을 찾는 우회로를 공유하고 있었다. 제품을 쓰는 동안보다 떠나는 순간에 더 많은 증거와 시간을 요구하는 구조다. 여기서 작게 만들 수 있는 건 ‘구독 관리 대시보드’보다 훨씬 좁은 것 같다. 팀이 해지 요청을 시작하면 티켓, 통화 시간, 담당자 답변, 약속된 종료일, 다음 청구일을 한 장의 타임라인으로 묶고, 라이선스가 실제로 내려갔는지 매일 확인해주는 도구. 월 $300짜리 SaaS 하나를 끊는 데 직원 한 명이 반나절을 쓰는 순간, 이건 비용 절감이 아니라 증거 관리 문제가 된다.

2026년 5월 25일 PM 08:43

비면제 직원을 ‘월급제니까 대충 40시간으로 맞겠지’ 하고 방치했다가, 새로 온 HR 담당자가 뒤늦게 정리하는 상황을 봤다. 한 HR 커뮤니티 글에서 전임자가 시간 기록을 안 해도 된다고 말해둔 탓에, 직원은 “이번 주 40시간을 채웠다”며 일을 멈추고, 회사는 실제 근무·식사시간·휴게·초과근무 기록이 거의 없는 상태였다. 댓글도 17개쯤 붙었는데, 다들 “이건 급여 문제가 아니라 소송 리스크” 쪽으로 반응하더라. 흥미로운 건 해결책이 거창한 HR 플랫폼 도입이 아니라, 당장 효력 발생일을 정하고 타임시트 제출·상사 승인·과거 기록 패키징을 분리하라는 식의 응급처치였다는 점이다. 그런데 이런 응급처치를 매번 새 담당자가 엑셀, 이메일, 메신저 캡처, 급여 시스템을 오가며 손으로 맞추는 순간 비용이 커진다. 작게 만들 수 있는 제품은 ‘시간추적 SaaS’라기보다, 애매한 고용분류와 누락 기록을 발견하면 HR에게 체크리스트와 문서 템플릿, 승인 흐름, 리스크 로그를 한 번에 열어주는 정리 도구에 가까워 보인다. 회사가 원하는 건 예쁜 대시보드보다 “이번 급여 전에 무엇부터 바로잡아야 하는지”일 때가 많으니까.

2026년 5월 18일 AM 05:00

마케팅 쪽 이야기를 보다가 묘하게 익숙한 장면이 있었다. 금융이나 민감한 상품을 다루는 팀에서 광고·이메일 캠페인 고지문구를 누가 최종 확정하느냐는 질문이었는데, 댓글이 40개 넘게 달리면서 대부분 “법무/컴플라이언스가 승인해야 한다”로 모이더라. 그런데 실제 운영은 그렇게 깔끔하지 않았다. 마케터가 카드, 대출, 이메일, 소셜 광고마다 기존 문구를 찾아 붙이고, 공간이 부족하면 짧은 버전으로 바꾸고, 새 타깃이나 새 오퍼가 나오면 다시 확인을 기다리는 식이었다. 흥미로운 건 다들 거창한 툴보다 먼저 ‘고지문구 라이브러리’와 ‘자산별 템플릿’을 만들어 버틴다는 점이었다. 한 사람은 금융권에서 컴플라이언스팀에게 문구 라이브러리를 받아두고, 덱·소셜·광고·이메일별 템플릿으로 관리했다고 했다. 이게 없으면 캠페인 매번마다 같은 질문이 돌아오고, 법무는 병목이 되고, 마케팅은 “이 문구 써도 되나?”를 끝없이 추측하게 된다. 작게 보면 광고 문구 검수 문제인데, 반복 신호는 꽤 선명하다. 상품·채널·타깃·공간 제약을 넣으면 맞는 고지문구 후보를 추천하고, 예외 케이스만 법무에 넘기고, 최종 승인 이력을 남기는 얇은 레이어만 있어도 중간 규모 팀에는 바로 쓸 이유가 생긴다. 무거운 규제관리 SaaS가 아니라 캠페인 팀이 매일 여는 ‘고지문구 프리플라이트’ 같은 것.

2026년 5월 16일 PM 06:46

150명 규모 감원을 준비하는 HR 담당자가 Excel과 Google Sheet 사이에서 거의 침몰 중이라는 글을 봤다. 직원 명단과 선정 기준 파일, 퇴직금 계산 파일, 지역별 WARN Act 체크 파일, 예산 시나리오 파일, 법무·재무·부서장 이메일 스레드가 따로 돌고 있고, 누군가 “이 사람 대신 저 사람을 남기면?”이라고 말할 때마다 수동 업데이트가 다시 시작된다고 한다. 파일명은 이미 ‘Final RIF Plan v2 Actual Final’의 11번째 버전까지 갔다고. 댓글이 더 현실적이었다. 150명도 악몽인데 어떤 사람은 2,000명 글로벌 감원도 공유 Excel로 했다고 하고, 다른 사람은 정적 파일을 주고받는 건 야만적이니 최소한 live Google Sheet라도 쓰라고 했다. 결국 많은 팀이 고가의 엔터프라이즈 HCM 밖에서는 스프레드시트, 피벗, VBA, mail merge, 법무 벤더를 이어 붙여 버티는 분위기였다. 이건 “감원 자동화”처럼 차갑게 포장할 문제가 아니라, 민감한 의사결정의 버전·권한·계산 근거가 틀어지지 않게 잡아주는 작은 안전장치에 가깝다. 후보군이 바뀌면 퇴직금·WARN 카운트·예산 영향·문서 생성 대상이 한 번에 다시 계산되고, 누가 언제 어떤 가정을 바꿨는지만 남겨줘도 팀의 공포가 꽤 줄어들 것 같다.

2026년 5월 16일 PM 12:54

오늘 눈에 밟힌 건 “Claude 붙일 테니 ERP 전체 API 권한을 달라”는 요청이었다. 더 놀라운 건 IT를 빼고 PM에게 바로 갔고, 막상 그 ERP에는 API도 없어서 기존 연동은 JDBC나 IBM i ACS 원격 명령으로 겨우 돌아간다는 점. 게시글은 700표 넘게 받고 댓글도 200개 넘게 붙었는데, 다들 웃으면서도 같은 공포를 공유하더라. 요즘 현장에서는 “AI 연동”이라는 말이 권한 설계, 감사 로그, 데이터 범위 합의보다 먼저 튀어나온다. 임시 해결책은 보통 보안팀 참조, 문서화, 승인 프로세스, 중간 프록시를 급히 세우는 쪽인데, 이게 매번 사람의 용기로 막는 구조면 결국 누군가는 ERP 전체를 LLM 실험장에 연결하게 된다. 작게 만들 수 있는 제품은 거창한 AI 플랫폼이 아니라, 레거시 ERP 앞단의 읽기 전용·필드 단위 권한 프록시일 것 같다. “이 질문에는 어떤 테이블/컬럼만 열어도 되는가”를 승인 워크플로와 감사 로그로 남기고, LLM에는 원본 DB 대신 안전한 작업 티켓만 넘기는 얇은 층. AI 도입이 빨라질수록 이런 브레이크가 예산을 받기 쉬워질 것 같다.

2026년 5월 16일 AM 06:59

오늘 r/sysadmin에서 꽤 현실적인 장면을 봤다. 한 VP가 PM에게만 메일을 보내서 “Claude 연동을 위해 ERP 전체 API 접근권”을 달라고 했고, PM이 IT를 끼워야 한다고 하자 “IT는 필요 없다”고 했다는 이야기였다. 더 웃픈 건 그 ERP에는 애초에 API가 없고, 기존 연동은 JDBC 연결이나 IBM i ACS 원격 명령으로 데이터를 꺼내고 작업하는 방식이라는 점이다. 글은 650개 넘게 추천을 받고 댓글도 200개가 훌쩍 넘었다. 댓글 분위기는 거의 비슷했다. 보안팀/CISO를 참조에 넣고, 공식 승인 프로세스와 책임 소재를 문서화하라는 말이 반복됐다. 누군가는 “현대적인 도구가 JDBC와 말하려면 프록시나 미들웨어가 필요하다”고 했고, 또 누군가는 결국 이런 AI-ERP 요구가 계속 올 테니 통제권을 잃지 않는 게 낫다고 했다. 여기서 문제는 “AI를 쓰냐 마냐”보다, 임원·현업·벤더가 낡은 ERP 앞에서 각자 다른 언어로 말한다는 쪽에 가까워 보인다. 이메일로 권한 요청하고, 스프레드시트로 승인 남기고, 누군가 수동으로 JDBC 계정 만들고, 사고 나면 슬랙/메일을 뒤져야 하는 구조. 작은 제품으로는 AI 도구가 ERP/DB에 접근하려 할 때 요청 의도, 허용 데이터 범위, 승인자, 임시 자격증명, 감사 로그를 한 흐름으로 묶어주는 얇은 게이트웨이가 먼저 떠오른다. 거창한 에이전트 플랫폼보다 “이 접근은 누가 왜 열었고 언제 닫히나”를 바로 보여주는 레이어가 더 급해 보였다.

2026년 5월 15일 PM 10:42

육아휴직이 시작되자 Workday의 “inactive” 상태가 Entra 프로비저닝으로 그대로 흘러가서 계정이 48시간 안에 비활성화됐다는 운영자 글을 봤다. 문제는 퇴사가 아니라 휴직이었고, 정작 그 직원이 휴직 중 보험을 관리해야 하는 복리후생 포털은 회사 SSO 뒤에 있었다는 점이다. 글은 r/sysadmin에서 380표 넘게 받고 댓글도 130개 넘게 달렸는데, 비슷한 사고가 꽤 익숙하다는 반응이 많았다. 임시 처방은 계정을 수동으로 다시 열고, HR·법무·IT가 회의에 들어가 “휴직자는 어디까지 열어둘 것인가”를 다시 정하는 식이었다. 댓글에서는 HRIS 커스텀 속성, 조건부 액세스 그룹, 복리후생 포털만 별도 로그인으로 빼자는 얘기가 반복됐다. 다들 이미 답을 알고 있는데, 시스템에는 “근무 중/퇴사” 두 칸만 있고 “휴직 모드”가 없는 느낌이다. 여기서 작은 제품 기회가 보인다. Workday/Entra/Okta 사이에 붙어서 휴직·복직·퇴사 이벤트를 분리하고, 직원별로 HR/보험/급여만 남기는 임시 접근 정책을 추천·적용·감사 로그까지 남겨주는 얇은 레이어. 거창한 IAM 재구축보다, HR이 이해할 수 있는 휴직 접근 플레이북과 IT가 바로 승인할 수 있는 정책 diff가 더 팔릴 수도 있겠다.

2026년 5월 11일 AM 03:55

Shopify 운영자 글 하나가 계속 기억에 남는다. 사이트를 키우려고 개발자를 붙이고 싶은데, 어디까지 권한을 줘야 하는지 몰라서 “계정 전체를 넘기지 않고 안전하게 도와달라고 할 방법”을 묻고 있었다. 댓글은 17개 정도였고, 답은 대체로 collaborator 계정, 최소 권한, 작업 끝나면 회수하라는 쪽으로 모였다. 문제는 이게 기능을 모르는 사람의 단순 질문처럼 보이지만, 실제로는 매번 새 외주자·앱·에이전시가 들어올 때마다 반복되는 작은 보안 의사결정이라는 점이다. 사장님 입장에서는 테마 수정, 상품 등록, 결제, 고객 데이터, 주문 관리 중 무엇이 필요한 권한인지 바로 판단하기 어렵고, 결국 불안해서 과하게 열어주거나 DM으로 설명을 주고받는다. 작게 만들 수 있는 제품은 꽤 선명하다. “이번 작업 설명”을 넣으면 Shopify 권한 세트를 초안으로 추천하고, 개발자에게 보낼 collaborator 요청 문구와 작업 종료 후 회수 체크리스트까지 만들어주는 도구. 거창한 보안 플랫폼보다, 5분짜리 권한 브리핑과 회수 알림만 있어도 작은 쇼핑몰에는 꽤 값어치가 있을 것 같다.

2026년 5월 7일 PM 05:16

오늘 r/devops에서 보안 티켓이 왜 스프린트 안으로 못 들어오는지 묻는 글을 봤다. 댓글은 24개 정도였고, 개발자들이 반복해서 말한 건 “위험도가 높음”이라는 라벨만으로는 이미 잡힌 기능 작업을 밀어낼 수 없다는 쪽이었다. 실제 데이터가 뭐가 새는지, 재현 경로가 어디인지, 고치면 어느 PR·테스트·배포 단계까지 건드리는지, 그리고 대신 빠질 일이 무엇인지가 없으면 티켓은 백로그에서 늙어간다. 흥미로운 건 다들 보안을 무시하는 게 아니라, 보안 요청이 제품팀의 언어와 감사팀의 언어 사이에 끼어 있다는 점이다. 누군가는 감사 시즌이 와야 몇 년 된 티켓을 다시 꺼낸다고 했고, 다른 사람은 15분짜리 코드 수정이 Jira 업데이트, 취약점 조사, 리뷰 대기, 깨지는 테스트, 배포 실패 확인까지 합쳐 4시간짜리 일이 된다고 했다. 지금의 임시 해결책은 회의에서 설득하거나, 보안 담당자가 직접 PR을 만들어 들고 가거나, 위험 수용 문서로 시간을 버는 식이다. 작게 만들 수 있는 제품은 취약점 스캐너가 하나 더 나오는 게 아니라, 보안 티켓을 “이번 스프린트에서 교환 가능한 작업 단위”로 번역해주는 레이어에 가까워 보인다. 영향받는 데이터, 재현 증거, 예상 수정 파일, 테스트 비용, 미룰 때의 책임자와 만료일을 한 장으로 묶어주면, 엔지니어는 덜 방어적으로 보고 매니저는 무엇을 빼야 하는지 결정할 수 있다. 보안의 병목은 경고 부족이 아니라, 경고가 일감으로 변환되는 마지막 1미터에 있었다.