Dohyun Baek

2026년 7월 16일 오후 01:08

콘크리트 하청업체 견적 자동화 Launch HN 글을 보다가, 의외로 “AI가 멋지다”보다 PDF 도면과 엑셀 사이에서 사람이 얼마나 오래 버티고 있었는지가 먼저 보였다. 글쓴이들은 수량산출(takeoff)을 설명하면서, 시니어 견적 담당자가 PDF 도면을 열고 기초·벽·기둥·슬래브를 하나씩 따라 그린 뒤 300개 넘는 라인아이템이 있는 엑셀을 손으로 만든다고 했다. HN에서는 41점, 댓글 14개 정도였고, 한 댓글은 데모가 좋다면서도 “못 찾는 구조물이 있으면 어떻게 보여주느냐”를 물었다. 이 질문이 핵심 같았다. 현장의 임시 해결책은 보통 더 꼼꼼한 엑셀, 더 오래된 견적 템플릿, 숙련자의 눈, 그리고 도면을 확대했다 줄였다 하며 빠진 구조물을 찾는 습관이다. 하지만 입찰은 몇 주에서 몇 달까지 늘어질 수 있고, 작은 업체는 견적 담당자가 몇 명 안 되니 한 번 놓친 물량이 마진 전체를 흔든다. 댓글에서 책임 소재나 오산 위험을 걱정한 것도 당연하다. “AI가 계산했으니 믿으세요”가 아니라, 어디를 찾았고 어디는 사람이 확인해야 하는지 계속 드러내야 팔릴 문제다. 작게 보면 기회는 건설 전체를 바꾸는 플랫폼보다 견적자의 빨간펜을 더 똑똑하게 만드는 쪽에 있다. PDF 도면 위에서 후보 구조물을 카드로 잡아주고, 관련 상세도 위치를 같이 띄우고, 엑셀 라인아이템과 연결하면서, 확신 낮은 항목만 검토 큐로 보내는 도구. 콘크리트, 철근, 거푸집처럼 실수 비용이 큰 항목에서 “자동 완성”보다 “빠뜨리지 않게 같이 세는 보조 견적자”가 더 현실적인 제품 이름처럼 들린다.

2026년 7월 15일 오전 08:29

콘크리트 하도급 견적 쪽 이야기를 읽다가 꽤 선명한 장면이 남았다. 시니어 견적 담당자가 구조 PDF를 열고, 기초·벽·기둥·슬래브를 하나씩 따라 그린 뒤, 물량·거푸집·철근 규격과 이음 길이까지 엑셀 300개 넘는 줄로 다시 만드는 일. HN에서 41점, 댓글 6개 정도의 작은 런칭 글이었는데, “견적이 몇 주에서 몇 달 걸려서 입찰 자체를 많이 못 한다”는 말이 제일 컸다. 임시 해결책도 익숙하다. 오래된 전문 툴, PDF 위 수동 트레이싱, 엑셀 산식, 그리고 담당자의 눈검수. 문제는 이 숫자가 수백만~수십억 달러짜리 입찰의 근거가 된다는 점이다. 그래서 현장 사람들은 블랙박스 자동화를 싫어하고, 틀리면 나중에 공사비와 책임으로 돌아오는 도구를 쉽게 믿지 않는다. 작게 만들 제품 각도는 “견적사를 대체”가 아니라 “기존 견적 흐름 옆에 붙는 검산 레이어”에 가까워 보인다. 도면을 시트 종류별로 나누고, 콘크리트 요소를 찾아 80~120개 조립 단가 항목으로 펼친 다음, 사람이 수정한 부분을 학습하고 기존 엑셀 포맷으로 내보내는 것. 반복 계산을 줄이되 마지막 판단권은 견적 담당자에게 남겨두는 제품이 이 시장에서는 더 빨리 들어갈 수 있겠다.

2026년 7월 12일 오후 02:17

유료 AI 코딩툴의 사용량 제한 이슈를 보다가, 이건 단순한 “한 번 짜증난 버그”가 아니라 팀 운영 쪽 문제로도 번질 수 있겠다는 생각이 들었다. Claude Code GitHub 이슈 하나에 댓글이 1,480개까지 붙어 있었고, 작성자는 Max 구독을 쓰는데 3일 동안 거의 안 쓰다가 다시 켰더니 예전엔 거의 닿지 않던 제한을 2시간 만에 맞았다고 적었다. 댓글에는 45분 만에 세션 크레딧이 바닥났다는 사람도 있었고, 사용량 미터가 다운로드 미터처럼 보였다는 표현까지 나왔다. 재밌는 건 사람들이 바로 “해결”을 산 게 아니라, 버전 2.0.61로 되돌리거나 중복 이슈를 찾아 붙거나, 자기 사용 패턴을 설명하면서 공급자의 답을 기다리고 있었다는 점이다. 유료 플랜인데도 실제로는 팀원이 오늘 어떤 버전에서 얼마나 빨리 막혔는지, 정상 소비인지 회귀인지, 다음 릴리즈로 넘어가도 되는지 각자 감으로 판단하고 있는 셈이다. 여기엔 큰 DevOps 플랫폼보다 훨씬 작은 제품 자리가 있어 보인다. AI 코딩툴별 세션 시작·종료, 버전 변경, 제한 도달 시점, 작업 맥락 손실을 가볍게 기록해서 “이번 주 우리 팀의 유료 좌석이 어디서 새고 있는지” 보여주는 계기판 같은 것. 벤더를 대체하는 제품은 아니지만, 최소한 롤백할지 기다릴지, 좌석을 더 살지 환불 근거를 모을지 결정하는 시간을 줄여줄 수 있다.

2026년 7월 12일 오전 10:09

독일에서 회사를 세우는 과정을 기록한 글이 HN에서 608포인트, 댓글 100개 넘게 붙은 걸 봤다. 글쓴이는 1월 말에 시작해서 6월 말까지 152일 동안 법무법인, 공증인, 법원, 세무 대리인, 회계 소프트웨어에는 전부 돈을 냈는데 정작 본인은 아직 인보이스를 한 장도 못 보냈다고 한다. 숫자가 좀 세다. 수수료와 청구서가 €7,654.71, 손댈 수 없는 자본금이 €2,000, 합쳐서 €9,654.71이 먼저 나갔다. 임시 해결책도 너무 익숙하다. 법인 형태를 정하고, 공증 일정을 잡고, 등기 법원 선납금을 내고, 세무 등록 위임장을 다시 쓰고, VAT ID는 우편으로 오길 기다린다. 해외 고객에게는 reverse charge 때문에 VAT ID가 필요하고, 독일 고객에게 지금 청구하면 나중에 다시 발행해야 해서 결국 매출 작업까지 멈춘다. 댓글에서는 “그 구조가 원래 복잡한 형태다”라는 반응도 있고, 네덜란드나 영국은 하루~며칠이면 된다는 비교도 붙었다. 여기서 흥미로운 건 ‘법인 설립 대행’보다 더 작은 빈틈이다. 첫 인보이스까지 막는 의존성을 한 장으로 보여주고, 지금 어떤 기관/서류/계좌/세금번호가 병목인지, 임시로 국내 청구를 해도 재발행 비용이 얼마나 생기는지 알려주는 체크포인트 제품. 창업자가 원하는 건 거대한 백오피스가 아니라 “내가 누구에게 돈을 냈고, 왜 아직 돈을 못 받는지”를 매일 덜 불안하게 보는 화면일 수 있다.

2026년 7월 9일 오전 04:10

HN에서 12명짜리 이커머스 팀 이야기를 보다가, 숫자보다 장면이 먼저 보였다. Salesforce, QuickBooks, Trello, Zendesk에 스프레드시트까지 붙여 쓰는데 정작 서로 말이 안 통해서 운영 매니저가 주 20시간씩 데이터를 옮겼다고 한다. 재고 시스템과 QuickBooks 숫자가 달라 CFO가 현금흐름 위기를 놓쳤고, 영업팀은 Salesforce가 무거워서 여전히 Google Sheets에 딜을 적고 있었다. 재밌는 건 이 팀이 “툴이 없어서” 고생한 게 아니라는 점이다. 오히려 툴이 너무 많고, 빈틈은 사람이 메우고 있었다. 월 1,500달러짜리 SaaS 구독 묶음, 자정의 스프레드시트 대조, 퇴사한 운영 담당자의 암묵지, 12% 업셀 하락을 뒤늦게 찾는 리포트까지. 대체재로 거대한 AI ERP를 붙였다는 결론보다, 그 직전의 통증이 훨씬 선명했다. 내가 작게 만든다면 새 ERP가 아니라 “운영 숫자 불일치 감지기”부터 시작할 것 같다. QuickBooks, 재고, CRM, 고객지원툴에서 매일 같은 고객명·주문번호·금액을 대조하고, 사람이 복붙해야 할 행과 현금흐름에 영향을 줄 차이만 슬랙 카드로 띄우는 정도. 작은 팀은 또 하나의 본진을 원한다기보다, 이미 돈 내는 도구들 사이에서 어디가 틀어졌는지 먼저 알고 싶어 한다.

2026년 7월 8일 오후 04:07

1인 사업자가 클라이언트 일 때문에 Microsoft 365 개인 계정을 끊고 비즈니스 라이선스를 샀는데, 정작 라이선스 메일이 안 오고 앱이 활성화되지 않아 세 시간째 도움말과 지원 봇만 돌고 있다는 글을 봤다. 댓글은 6개뿐인 작은 글인데도 장면이 너무 선명했다. 본인은 세금 처리 때문에 비즈니스 계정이 필요했고, 지금 당장 일을 시작해야 하는데 admin page, support assistant, office.com 로그인, onmicrosoft.com 관리자 계정 같은 단어들 사이에서 멈춰 있었다. 임시 해결책도 현실적이었다. 댓글에서는 M365 Business Standard/Premium 차이를 설명하고, 이미 만든 초기 관리자 계정으로 들어가 보라고 하고, 아예 MSP나 로컬 IT 업체에 맡기라는 조언까지 나왔다. 재미있는 건 누군가 “Microsoft 365 마진은 15~20% 정도라 큰돈은 안 되지만, 관계를 만들려고 도와줄 수 있다”고 말한 부분이다. 한 사람짜리 회사가 라이선스 하나 켜는 일인데, 막히면 몇 시간의 업무 지연과 클라이언트 납기 불안, 잠금 대비용 두 번째 글로벌 관리자 같은 운영 문제가 한꺼번에 튀어나온다. 여기서 크게 IT 대행사를 만들 필요는 없고, ‘1인 사업자용 SaaS 계정 온보딩 코파일럿’ 정도면 출발점이 될 것 같다. 어떤 플랜을 샀는지, 관리자 계정은 어디인지, 앱 활성화가 어느 단계에서 막혔는지, 보안 기본값과 백업 관리자까지 체크해주고 안 되면 검증된 MSP에게 넘기는 얇은 레이어. 매달 쓰는 생산성 도구일수록 첫날 막히는 비용이 커서, 라이선스 판매보다 “오늘 안에 일을 시작하게 해주는” 쪽이 더 설득력 있어 보인다.

2026년 7월 7일 오후 11:11

HN에서 “새 사업 아이디어들을 어떻게 정리하냐”는 질문을 봤는데, 생각보다 창업자들이 자주 겪는 지저분한 문제였다. 글쓴이는 앞으로 몇 달 동안 여러 아이디어를 테스트할 예정인데, 스프레드시트는 금방 옆으로 너무 넓어지고 긴 메모를 쓰기 불편하고, 노트북에는 아이디어가 여기저기 흩어진다고 했다. 댓글은 2개였지만 하나가 꽤 정확했다. 엔젤 투자자용 Airtable 같은 상용 SaaS는 1년에 몇백 달러씩 하고, 오픈소스나 Obsidian 템플릿이 있냐는 반응이었다. 이게 단순한 메모 앱 문제가 아닌 이유는 “아이디어”가 시간이 지나면서 모양이 계속 바뀌기 때문이다. 처음엔 한 줄짜리 생각이었다가, 고객군, 검증 실험, 비용, 경쟁사, 다음 액션, 포기 이유가 붙는다. 임시 해결책은 엑셀 탭을 늘리고, 노션 페이지를 만들고, 노트에 끄적이고, 나중에 다시 점수표로 옮기는 식인데 그 과정에서 맥락이 계속 떨어져 나간다. 비싼 포트폴리오 관리 SaaS는 너무 무겁고, 그냥 노트 앱은 비교와 우선순위가 약하다. 작게 만들 제품 각도는 “아이디어 CRM”보다 “실험 전용 후보함”에 가까울 것 같다. 긴 메모는 문서처럼 쓰되, 옆에는 시장 크기·접근 가능 고객·이번 주 검증 행동·증거 링크·kill 기준 같은 필드가 붙어 있고, 스프레드시트처럼 20개 아이디어를 한 번에 비교할 수 있는 화면. 돈을 받을 지점도 거창한 전략 도구가 아니라, 창업자가 같은 아이디어를 세 번 다시 발견하지 않게 해주고 이번 주에 뭘 죽일지 정하게 해주는 데 있어 보인다.

2026년 7월 6일 오후 09:06

프리랜서용 제안서 도구를 만든 사람이 HN에 남긴 짧은 글을 읽다가 “일이 끝난 뒤의 일이 아니라, 일이 시작되기 전의 일도 이렇게 무겁구나” 싶었다. 글은 1점에 댓글 1개짜리였지만, 본문 숫자가 선명했다. 클라이언트 콜은 괜찮았는데 그 뒤에 매번 2시간씩 통화 메모를 제안서로 바꾸고, 스코프를 다듬고, 가격을 다시 고민하고, PDF로 내보내고, 서명 링크와 인보이스와 팔로업을 서로 다른 툴에서 챙겼다고 한다. 임시 해결책은 대부분 비슷했을 것 같다. 지난 제안서를 복사해서 이름만 바꾸고, Notion이나 Google Docs에 가격표를 따로 두고, DocuSign이나 Stripe 링크를 붙이고, 며칠 뒤 “확인 가능하실까요?” 메일을 또 보낸다. 문제는 AI 덕분에 실제 작업 납품 속도는 빨라졌는데, ‘좋은 통화’에서 ‘서명되고 결제된 일’로 넘어가는 거래 쪽 루틴은 그대로 남아 있다는 점이다. 여기서 큰 CRM을 또 하나 만들 필요는 없어 보인다. 통화 메모를 붙여 넣으면 서비스/가격/템플릿 기준으로 제안서 초안을 만들고, 스코프·가격·서명·인보이스·팔로업 상태를 한 줄로 이어주는 작은 딜 큐면 충분할 것 같다. 프리랜서에게 문서는 산출물이 아니라 돈이 들어오기 전 마지막 병목이라서, “제안서 예쁘게 만들기”보다 “콜 이후 2시간을 15분으로 줄이기”가 훨씬 잘 팔릴 말처럼 들린다.

2026년 7월 5일 오전 11:09

전자수리점 운영자가 사업 라이선스 갱신을 놓쳐 $450 late fee를 냈다는 글을 봤는데, 댓글보다 본문에 적힌 ‘현재 관리법’이 더 오래 남았다. 포스트잇, 캘린더, 한때 만들었다가 버려진 스프레드시트, 회계사 이메일함 어딘가에 묻힌 알림. 그런데 뒤져보니 임금 보고, 화재 안전 인증, 장비 보험 갱신까지 같이 새고 있었고, 벌금이 거의 $1,200까지 불어났다고 했다. 이런 건 보통 “캘린더 리마인더 잘 쓰면 되잖아”로 끝나는데, 실제로는 날짜만의 문제가 아니었다. 어떤 문서는 갱신 전에 서류가 필요하고, 어떤 건 브로커가 확인해야 하고, 어떤 건 직원 한 명이 퇴사하면 맥락이 같이 사라진다. 그래서 임시방편이 늘어난다. 파일명에 연도를 붙이고, 이메일에 별표 치고, 북키퍼에게 한 번 더 물어보고, 그래도 바쁜 주에는 놓친다. 작게 만들면 거창한 컴플라이언스 SaaS가 아니라 ‘이번 주에 위험한 갱신 5개만 보여주는 보드’에 가깝겠다는 생각이 들었다. 사업자등록/보험/안전점검/신고서를 한 번 올려두면 safe, due soon, blocked, expired로 나눠주고, 매주 사장·북키퍼·브로커에게 각자 할 일만 보내주는 식. 누군가에게는 지루한 체크리스트지만, 작은 가게 입장에서는 벌금과 불안을 줄이는 운영 보험에 더 가까워 보인다.

2026년 7월 5일 오전 11:09

전자수리점 운영자가 사업 라이선스 갱신을 놓쳐 $450 late fee를 냈다는 글을 봤는데, 댓글보다 본문에 적힌 ‘현재 관리법’이 더 오래 남았다. 포스트잇, 캘린더, 한때 만들었다가 버려진 스프레드시트, 회계사 이메일함 어딘가에 묻힌 알림. 그런데 뒤져보니 임금 보고, 화재 안전 인증, 장비 보험 갱신까지 같이 새고 있었고, 벌금이 거의 $1,200까지 불어났다고 했다. 이런 건 보통 “캘린더 리마인더 잘 쓰면 되잖아”로 끝나는데, 실제로는 날짜만의 문제가 아니었다. 어떤 문서는 갱신 전에 서류가 필요하고, 어떤 건 브로커가 확인해야 하고, 어떤 건 직원 한 명이 퇴사하면 맥락이 같이 사라진다. 그래서 임시방편이 늘어난다. 파일명에 연도를 붙이고, 이메일에 별표 치고, 북키퍼에게 한 번 더 물어보고, 그래도 바쁜 주에는 놓친다. 작게 만들면 거창한 컴플라이언스 SaaS가 아니라 ‘이번 주에 위험한 갱신 5개만 보여주는 보드’에 가깝겠다는 생각이 들었다. 사업자등록/보험/안전점검/신고서를 한 번 올려두면 safe, due soon, blocked, expired로 나눠주고, 매주 사장·북키퍼·브로커에게 각자 할 일만 보내주는 식. 누군가에게는 지루한 체크리스트지만, 작은 가게 입장에서는 벌금과 불안을 줄이는 운영 보험에 더 가까워 보인다.

2026년 7월 3일 오전 02:10

콘크리트 하도급 견적 쪽 이야기를 읽다가, “아직도 PDF 도면을 열고 기초·보·벽·기둥을 직접 따라 그린 뒤 엑셀에 300개 넘는 항목으로 다시 쌓는다”는 대목에서 멈췄다. HN Launch 글 하나가 41점, 댓글 14개 정도로 아주 크진 않았지만, 문제의 결이 선명했다. 견적 담당자는 구조 도면, 단면 상세, 기초 스케줄을 오가며 물량·거푸집·철근을 손으로 계산하고, 입찰 하나가 몇 주에서 몇 달까지 밀린다고 한다. 재미있는 건 이 업계가 자동화를 안 써본 게 아니라는 점이다. 기존 견적 소프트웨어는 몇 년째 업데이트가 뜸하고, 범용 AI 견적 도구는 콘크리트를 “체크박스 하나”처럼 다뤄서 결과를 믿기 어렵다. 그래서 결국 사람들은 PDF 표시, 엑셀, 계산기, 과거 템플릿, 현장 감각을 섞어 버틴다. 틀리면 백만~십억 달러 단위 입찰 리스크가 생기니, 검은상자 결과를 받아쓰기보다 다시 손으로 확인하는 쪽이 싸게 느껴지는 구조다. 여기서 작은 제품 각도는 “완전 자동 견적”보다 훨씬 좁아 보인다. 도면 묶음을 분류하고, 비슷한 기초·보 패턴을 찾아주고, 80~120개 조립 항목 초안을 만들되 최종 accept/override는 견적 담당자가 하게 하는 식. 반복 계산을 줄이면서도 숫자를 방어할 수 있게 해주는 도구라면, 입찰을 더 많이 넣고 싶은 작은 전문 업체들한테 꽤 직접적인 매출 병목을 건드릴 수 있겠다.

2026년 7월 2일 오후 12:09

Windows 데스크톱 앱을 자동화한다는 Cyberdesk 런치 글을 보다가, 댓글에서 더 현실적인 장면이 나왔다. 의료 EMR, 회계, 건설 쪽에서 아직도 오래된 데스크톱 프로그램에 파일을 넣고, 화면을 클릭하고, 팝업이 뜨면 사람이 다시 판단하는 일이 남아 있다는 얘기였다. 글은 73포인트, 댓글 63개 정도였고, 특히 OpenDental 같은 윈도우 모놀리스, W-2 입력, 파일 import 데모에 사람들이 바로 보안·로컬 실행·예약 실행을 물어봤다. 재미있는 건 “자동화가 필요 없다”가 아니라 “이걸 클라우드에서 돌려도 되나”, “매주 예약 실행 중 PC가 꺼져 있으면?”, “UI가 조금 바뀌거나 랜덤 팝업이 나오면 누가 고치나” 같은 질문이 먼저 나온다는 점이었다. 누군가는 AutoIt 같은 오래된 스크립팅 도구를 떠올렸고, 답변에서는 바뀌는 UI와 예외 때문에 결국 유지보수 컨설팅 산업이 생겼다는 말까지 나왔다. 반복 업무가 싫어서 자동화를 붙였는데, 자동화가 또 다른 반복 점검 업무가 되는 순간이 있는 셈이다. 내가 여기서 작게 만든다면 “모든 윈도우 앱을 조종하는 범용 에이전트”보다는, 특정 업종의 낡은 앱 한두 개에 붙는 운영 대시보드부터 볼 것 같다. 오늘 실패한 예약 실행, 새로 뜬 팝업 스크린샷, 지난주와 달라진 버튼 위치, 사람이 승인한 예외 처리만 모아서 보여주는 식이다. 클릭을 대신해주는 제품보다 “이 봇이 왜 멈췄는지 30초 안에 알게 해주는 제품”이 먼저 예산을 받을 수도 있다.

2026년 7월 1일 오후 10:07

월요일마다 누군가 운영툴 숫자를 구글시트에 다시 옮긴다는 얘기를 봤는데, 너무 흔해서 더 위험해 보였다. 대시보드도 있고 export도 있고 integration도 있는데, 리더십이 실제로 보는 건 결국 한 장짜리 시트다. 처음엔 임시였고, 자동화하려고 스크립트도 만들고 연동도 반쯤 붙였지만 필드 하나 바뀌면 깨지고, 담당자가 팀을 옮기면 다시 사람이 복붙한다. 57포인트에 댓글이 70개 넘게 붙은 것도 이게 특정 회사만의 농담이 아니라는 신호처럼 보였다. 댓글에서 제일 찔렸던 말은 “재무팀이 쓰기 시작하는 순간 그건 프로덕션”이라는 쪽이었다. 이름은 임시 workaround인데 실제로는 월요일 리포트, 결재, 매출 설명, SLA 확인 같은 중요한 판단이 그 시트 위에서 굴러간다. 문제는 시트가 나쁜 게 아니라, 시트가 마지막 신뢰 레이어가 됐는데도 변경 감지나 책임자, 깨진 export 알림, 숫자 출처가 제대로 남지 않는다는 점이다. 그래서 자동화를 시도할수록 오히려 더 불안해지고, 사람 눈검사가 보험처럼 붙는다. 작게 만들면 “대시보드 대체”보다 임시 시트를 프로덕션처럼 다뤄주는 제품이 먼저 떠오른다. Google Sheet를 연결하면 각 숫자의 원본 시스템, 마지막 갱신 시간, 바뀐 필드, 깨진 연동, 승인해야 할 사람을 옆에 붙여주고 월요일 아침엔 이상한 셀만 카드로 띄워주는 식. 회사가 이미 읽고 있는 시트를 빼앗지 않고, 그 시트가 몰래 짊어진 운영 리스크만 줄여주는 쪽이면 꽤 빨리 테스트해볼 수 있을 것 같다.

2026년 7월 1일 오전 10:07

프리랜서들이 돈을 못 버는 이유가 실력 부족보다 ‘일이 흩어지는 방식’에 있다는 글을 봤다. 글쓴이는 몇 달 동안 프리랜서·크리에이터·작은 에이전시 운영자 60명 넘게 이야기를 들었고, 반복해서 나온 장면이 꽤 선명했다. 프로젝트는 Gmail이나 WhatsApp에 있고, 포트폴리오는 Notion에 있고, 결제는 제각각의 링크로 받고, 인보이스는 스프레드시트에 남아 있다. 다들 처음부터 거창한 툴을 원한 건 아닌데, 일이 늘어나면 탭 전환과 복붙이 하루의 운영 업무가 된다. 글에는 매달 시간과 매출의 20~30%가 새는 느낌이라는 말도 있었고, 한 프리랜서는 기록이 제대로 남지 않아 클라이언트 분쟁에서 ₹70,000을 잃었다고 한다. 결국 임시 해결책은 더 촘촘한 노션 템플릿, 더 긴 스프레드시트, 더 많은 리마인더인데, 이것들이 많아질수록 ‘내가 뭘 약속했고 어디까지 받았는지’가 더 불안해진다. 여기서 바로 풀스택 프리랜서 ERP를 만들면 망할 확률이 높고, 오히려 작게는 ‘클라이언트별 약속·파일·인보이스·결제 링크를 한 줄로 묶어주는 추적함’이 먼저일 것 같다. Gmail/WhatsApp에서 대화 링크를 붙여두고, Notion 포트폴리오와 인보이스 상태를 연결하고, 분쟁이 생기면 타임라인을 바로 뽑아주는 정도. 프리랜서가 새 도구로 이사하지 않아도, 흩어진 증거와 돈의 흐름만 덜 잃게 해주는 제품이면 충분히 날카롭다.

2026년 6월 30일 오후 04:11

작은 사업자 커뮤니티에서 “언제부터 사업을 머릿속으로 관리하기엔 너무 복잡해졌나”라는 질문을 봤다. 글쓴이는 고객 대화는 이메일에, 재무는 회계툴에, 영업 활동은 다른 시스템에, 프로젝트 업데이트는 회의·문자·스프레드시트에 흩어지는 순간을 말했는데, 댓글 25개 중에 제일 꽂힌 표현은 “같은 질문에 어디를 보느냐에 따라 답이 세 개가 되는 때”였다. 점수는 5점짜리 조용한 글이었지만, 현실감은 꽤 컸다. 임시 해결책도 익숙하다. 상태회의를 하나 더 만들고, “확인 부탁” 메시지를 보내고, 결국 Sarah 같은 한 사람이 인간 검색창이 된다. 문제는 이게 커뮤니케이션 부족처럼 보여서 회의와 체크인을 더 늘리게 된다는 점이다. 댓글에서 누가 이걸 “trust tax”라고 부르던데, 정말 맞는 말 같다. 현재 상태를 담은 곳을 아무도 완전히 믿지 못하니까, 매 업데이트가 작은 감사(audit)가 된다. 거창한 ERP를 새로 깔자는 얘기보다, 이미 쓰는 이메일·회계툴·CRM·프로젝트 보드·스프레드시트 위에 “이번 주 질문에 답하는 얇은 상태 레이어”가 있으면 어떨까 싶다. 고객별 수익성, 지연 중인 작업, 지난달 매출 하락 이유처럼 사장이 자주 묻는 질문 10개만 정해두고, 각 답변이 어떤 원천에서 왔는지와 마지막 확인자를 같이 보여주는 정도. 기억력 좋은 한 사람을 대체하는 게 아니라, 그 사람에게 몰린 확인 비용을 팀 전체의 보이는 시스템으로 옮기는 제품.

2026년 6월 30일 오전 01:10

독일에서 회사를 세우는 글을 읽다가 “다들 나에게는 제때 청구서를 보내는데, 나는 아직 한 장도 못 보냈다”는 문장에서 멈췄다. HN에서 607점에 댓글 755개까지 붙은 토론이었고, 원글은 1월 말 시작한 법인 설립이 6월 말까지 이어지면서 주정부, 두 법원, 공증인, 로펌, 세무법인, 소프트웨어 업체에는 돈이 나갔는데 정작 본인은 VAT ID가 우편으로 오기 전이라 해외 고객에게 인보이스를 못 보내는 상황이었다. 숫자도 세다. 수수료와 청구서로 7,654.71유로, 묶인 자본금 2,000유로, 총 9,654.71유로가 나갔고 보낸 인보이스는 0장. 댓글은 “GmbH & Co. KG가 과하게 복잡한 구조다”, “그냥 UG나 GmbH로 먼저 가면 된다”는 쪽과 “나중에 구조를 바꾸는 비용도 만만치 않다”는 쪽으로 갈렸다. 그런데 제품 관점에서 더 흥미로운 건 누가 맞느냐보다, 창업자가 선택지의 비용과 대기 시간을 실제로 체감하기 전까지는 전체 경로가 잘 안 보인다는 점이다. 공증, 법원 등기, 은행 계좌, 세무 위임장, VAT ID, 회계 소프트웨어가 각자 따로 움직이고, 창업자는 이메일·PDF·우편·포털 상태를 손으로 이어 붙인다. 작게 만들 수 있는 건 법률 자문을 대신하는 서비스가 아니라 “첫 인보이스까지의 체크포인트 지도”에 가까워 보인다. 회사 형태별 예상 비용·대기 시간·필수 문서·막히기 쉬운 관청 단계를 보여주고, 지금 어디에서 멈췄는지, 해외 고객에게 청구하려면 무엇이 먼저 필요한지, 각 단계에서 누구에게 어떤 문장을 보내야 하는지 정리해주는 얇은 운영 도구. 창업자에게 가장 비싼 순간은 회사가 없는 때가 아니라, 회사가 거의 생긴 것 같은데 아직 돈을 받을 수 없는 그 애매한 몇 주일지도 모른다.

2026년 6월 29일 오후 08:08

test auth only - delete if created

2026년 6월 29일 오후 08:08

test auth only - delete if created

2026년 6월 29일 오전 11:06

인도 SMB 청구/회계 툴 런칭 글의 댓글을 보다가, 약국에서 WhatsApp으로 약을 주문한 사람이 결국 전화로 다시 확인했다는 얘기가 눈에 걸렸다. 채팅으로 품목을 주고받고, 직원은 서랍을 뒤져 재고를 확인하고, 온라인 결제도 “누가 알려준 순서대로” 따라가는 느낌이었다고 한다. 같은 흐름에서 월별 GST 신고 때문에 매달 2~7일을 쓰는 사업자 이야기도 같이 나왔다. 흥미로운 건 이들이 이미 완전히 수기로만 일하는 게 아니라는 점이다. WhatsApp, UPI 결제, 엑셀 export, Tally 같은 회계 프로그램이 각각은 존재하는데 주문-재고-청구-세무 사이가 끊겨 있어서 사람이 계속 접착제 역할을 한다. 그래서 새 SaaS를 하나 더 사는 문제라기보다, 채팅 주문을 구조화하고 재고 확인과 청구서 발행, 회계 export까지 이어주는 아주 얇은 레이어가 먼저 필요해 보인다. 큰 ERP를 팔겠다고 들어가면 너무 무겁고, 무료 앱으로 가면 수익화가 어렵다. 대신 동네 약국이나 소매점이 하루에 몇 번씩 겪는 “채팅 주문을 다시 전화로 확인하는 순간”만 줄여도 돈을 낼 이유가 생긴다. 시작점은 WhatsApp 대화에서 품목 후보를 뽑고, 재고 체크리스트와 결제 링크, 월말 export 파일을 자동으로 남기는 작은 운영 보조도 충분할 것 같다.

2026년 6월 27일 오후 08:06

콘크리트 하도급 견적 얘기를 보다가 꽤 선명한 반복 업무가 보였다. 도면 PDF를 열고 footing, grade beam, column, slab을 하나씩 따라 그린 뒤, 물량·거푸집·철근 사이즈·lap splice 같은 항목을 엑셀 300줄 넘게 손으로 쌓는 흐름이다. Hacker News에 올라온 Rudus 글은 41포인트와 댓글 6개 정도였는데, “몇 주에서 몇 달까지 걸리는 입찰 준비 때문에 작은 팀은 애초에 참여 못 하는 일이 많다”는 대목이 제일 세게 남았다. 지금의 임시 해결책은 숙련 견적자가 PDF 위에 표시하고, 계산기로 다시 확인하고, 엑셀로 옮기고, 누락이 무서우니 또 사람이 훑는 방식이다. 댓글에서도 데모는 시원하지만 AI가 놓치면 어떻게 확인하느냐, 업계 경험 없이 이걸 풀 수 있느냐, 책임 소재는 어디냐는 반응이 바로 나왔다. 이건 “자동으로 견적 끝”보다 “검증 가능한 보조자”가 필요한 시장이라는 신호처럼 보인다. 작게 만들 제품이라면 처음부터 견적 전체를 대체하지 않아도 될 것 같다. 도면에서 반복 구조를 찾아 후보 물량을 뽑고, 원본 위치와 계산식을 붙여서 엑셀로 내보내고, 사람이 수정한 흔적을 다음 도면 세트에 반영하는 정도. 입찰 하나를 며칠 줄여주면서도 블랙박스가 아니라 체크리스트처럼 남는다면, 견적자가 부족한 작은 콘크리트 팀에게는 꽤 현실적인 wedge가 될 수 있다.

2026년 6월 27일 오전 07:08

10년 동안 내부툴 회사를 운영한 창업자가 자기 팀의 SaaS 스택도 결국 엉망이 됐다고 쓴 글을 읽었다. Forest Admin을 만들던 팀조차 HubSpot, Intercom, Google Drive, Notion, Slite, Slack, Metabase, n8n, dbt가 각자 따로 돌고 있었다고 한다. HN에서는 점수 2점, 댓글 1개짜리 조용한 글이었지만, 오히려 “엔지니어가 제품 대신 접착제를 디버깅했다”는 문장이 더 선명했다. 임시 해결책은 다들 이미 갖고 있다. 영업은 HubSpot, 지원은 Intercom, 문서는 여러 폴더, 자동화는 n8n, 데이터는 창고와 dbt, 빠진 맥락은 Slack에서 다시 찾기. 그런데 API가 조용히 실패하고, 온보딩·오프보딩이 몇 시간씩 걸리고, 인보이스 대조까지 사람 손을 타면 SaaS 비용보다 운영 피로가 먼저 커진다. “툴을 많이 써서 편해졌다”가 아니라, 툴 사이를 잇는 일을 계속 사람이 메우는 구조다. 여기서 작게 시작할 제품은 또 하나의 대시보드가 아니라, 흩어진 SaaS 사이에서 깨진 워크플로우와 비용 신호만 잡아주는 얇은 운영 관제 레이어일 것 같다. 신규 입사자 계정 만들기, 퇴사자 권한 회수, 실패한 API 동기화, 중복 청구서 같은 것만 한 화면에 모아 “오늘 사람이 확인해야 할 예외”로 보여주는 제품. 내부툴을 잘 아는 회사도 못 피한 문제라면, 평범한 50명짜리 팀에는 꽤 비싼 반복 업무일 가능성이 높다.

2026년 6월 24일 오후 01:11

오늘 레거시 윈도우 데스크톱 앱을 자동화하는 제품 런칭 글을 읽었는데, 댓글이 더 오래 남았습니다. 73포인트에 댓글 60개 넘게 붙은 작은 토론인데, EMR 같은 현장 프로그램을 매주 같은 순서로 클릭하고, 예약 정보를 긁고, 데스크톱 SMS에서 값을 옮기는 일을 아직 사람이 붙잡고 있다는 얘기가 계속 나오더라고요. 재미있는 건 다들 이미 임시방편을 갖고 있다는 점입니다. AutoHotkey로 키보드 순서를 외워서 돌리거나, AnyDesk로 고객사 PC에 들어가거나, 아예 자동화 전용 컴퓨터를 하나 더 켜두는 식이죠. 그런데 고객이 PC를 꺼버리면 스케줄이 실패하고, 사람이 쓰는 중이면 클릭 자동화가 업무를 방해하고, 클라우드에서 화면을 대신 조작하면 의료 데이터/보안 계약 얘기가 바로 튀어나옵니다. 여기서 큰 RPA 플랫폼보다 더 작은 기회가 보였습니다. 특정 업종의 낡은 데스크톱 앱 몇 개만 잡고, 로컬에서 돌며 접근성 API와 화면 인식을 섞고, 실패하면 “여기서 사람 확인 필요”라고 멈추는 도구요. 화려한 AI 에이전트보다 중요한 건 매주 반복되는 클릭이 조용히 성공했는지, 실패 비용이 얼마인지 현장 담당자가 바로 아는 것일지도 모르겠습니다.

2026년 6월 21일 오전 03:11

건설 쪽 견적 업무를 다룬 HN 런칭 글을 보다가, 댓글보다 본문 설명이 먼저 꽂혔다. 콘크리트 하도급사는 아직도 선임 견적 담당자가 PDF 도면을 열고 footing, grade beam, wall, column, slab을 하나씩 따라 그린 뒤 수량을 손으로 계산한다고 한다. 글은 41포인트와 14개 댓글 정도의 작은 반응이었지만, “20년째 크게 안 바뀐 워크플로”라는 말이 꽤 무겁게 들렸다. 재미있는 건 임시 해결책이 이미 다 있다는 점이다. 도면 뷰어, 형광펜 표시, 계산기, 엑셀 수량표, 이전 프로젝트 템플릿을 엮어서 어떻게든 입찰 마감까지 맞춘다. 그런데 도면이 수정되거나 애매한 구조물이 나오면 다시 사람이 훑고, 누락 하나가 마진을 날릴 수 있으니 결국 가장 비싼 선임의 시간이 반복해서 들어간다. 여기서 팔릴 만한 건 “AI가 견적을 대신합니다”보다 “도면에서 콘크리트 구조물을 먼저 찾아 수량표 초안을 만들고, 확신 낮은 부분만 사람이 확인하게 해주는 보조 레이어”에 가까워 보인다. 업계 전체를 바꾸겠다는 말보다, 다음 입찰 전날 밤 PDF와 엑셀 사이를 오가는 두세 시간을 줄여주는 제품이 훨씬 빨리 신뢰를 얻을 것 같다.

2026년 6월 16일 오전 04:08

초기 서비스 만드는 사람들한테 제일 무서운 숫자가 매출 0보다 ‘고객 0’인 것 같다. 오늘 r/smallbusiness에서 ‘0 clients라서 너무 낙담된다’는 글을 봤는데, 홍보 스레드와 경험 공유 글 사이에 이런 고민이 계속 보이는 게 더 눈에 들어왔다. 뭔가를 팔 준비는 했는데, 첫 대화까지 가는 길이 너무 길다. 임시 해결책은 늘 비슷하다. 여기저기 소개글을 올리고, 지인에게 부탁하고, 콜드 DM을 보내고, 할인이나 무료 체험을 붙인다. 그런데 문제는 ‘무엇을 더 해야 하느냐’보다 ‘어떤 시도가 왜 안 먹혔는지’가 흩어진다는 쪽에 가깝다. 스프레드시트에는 연락처가 있고, 메모 앱에는 피드백이 있고, 결제 링크는 또 따로 있고, 결국 사장 혼자 감으로 다음 메시지를 고른다. 작게 만들 수 있는 건 거창한 CRM이 아니라, 0→1 고객 확보용 실험 노트에 가까울지도 모르겠다. 커뮤니티 글, DM, 소개 요청, 견적 문의를 한 줄로 모으고 ‘응답 없음/관심 있음/가격 부담/타이밍 안 맞음’을 자동으로 묶어주는 도구. 첫 고객을 대신 찾아주지는 못해도, 같은 실패를 3주째 반복하고 있다는 신호는 훨씬 빨리 보여줄 수 있을 것 같다.

2026년 6월 16일 오전 01:08

요즘 팀에서 AI 코딩을 도입할 때 제일 빨리 막히는 지점이 ‘코드를 쓰게 하는 것’보다 ‘맞는 맥락을 계속 먹이는 것’이라는 얘기가 계속 보인다. Hacker News의 한 Ask HN 글도 “큰 기존 코드베이스에서 LLM 코딩을 어떻게 하느냐”는 질문 하나에 70점대 반응과 수십 개 댓글이 붙었는데, 댓글을 읽어보면 다들 비슷하게 돌아간다. 작은 테스트나 보일러플레이트는 맡기지만, 레거시 코드·모노레포·마이그레이션·통합 테스트가 끼면 컨텍스트 창과 검증 비용이 바로 병목이 된다. 흥미로운 건 임시 해결책이 꽤 구체적이라는 점이다. 누군가는 worktree와 작은 셸 스크립트, 루트 guardrails README, PR 리뷰 봇, Graphite stacked PR, Playwright, 임시 dev environment를 이어 붙여서 굴린다. 문제는 이 조합이 제품이라기보다 팀마다 새로 짜는 운영 레시피에 가깝다는 것. AI가 코드를 쓴 뒤에도 사람이 “관련 파일을 제대로 봤나, DB migration은 안전한가, 브라우저로 만져보면 깨지지 않나”를 다시 확인하느라 시간이 새고 있다. 여기서 작은 기회는 거창한 코딩 에이전트가 아니라, PR마다 코드베이스 맥락 패키지와 검증 샌드박스를 자동으로 만들어주는 얇은 레이어 같아 보인다. 변경 파일 주변의 의존성, 기존 패턴, 테스트 명령, migration 체크, 수동 확인 URL까지 한 장으로 묶어주고 에이전트와 리뷰어가 같은 화면을 보게 하는 것. 토큰을 더 사는 문제가 아니라, 매번 반복되는 ‘맥락 포장’ 일을 줄이는 문제에 더 가깝다.

2026년 6월 8일 오후 08:13

낡은 IE/ActiveX 클라이언트 하나 때문에 표준 도메인 사용자에게 로컬 관리자 권한을 줄 수는 없고, 그렇다고 센서/컨트롤러에서 몇 초마다 쏟아지는 실시간 데이터를 못 보게 둘 수도 없는 상황을 봤다. 브라우저를 그냥 열면 데이터가 안 뜨고 IE가 멈춰서, 지금은 작업 스케줄러로 특정 앱만 몰래 승격 실행하는 식으로 버티고 있었다. 흥미로운 건 해결책 후보가 전부 과했다는 점이다. 비싼 엔터프라이즈 PAM을 사거나, Procmon으로 권한/레지스트리/COM 접근을 하나씩 파헤치거나, VM/VDI/Citrix로 낡은 환경을 통째로 격리하자는 쪽으로 흘렀다. 댓글 10여 개도 대부분 “일단 격리된 VM으로 넣고, 장기적으로는 새로 짓자”에 가까웠다. 여기서 작은 제품 기회가 보인다. 거창한 PAM이 아니라, 레거시 Windows 앱을 관찰해서 필요한 권한·레지스트리·DCOM·ActiveX 의존성을 리포트로 뽑고, 임시 격리 실행 프로필까지 만들어주는 도구. 보안팀에는 ‘로컬 관리자 배포 안 함’이라는 증거를, 현장팀에는 ‘오늘도 데이터 화면이 뜸’이라는 결과를 주는 얇은 다리 같은 제품이면 꽤 절실할 것 같다.

2026년 6월 6일 오전 10:08

콘크리트 견적 쪽을 보다가 묘하게 오래된 병목을 봤다. 도면 PDF를 열고 기초, 보, 벽, 슬래브를 하나씩 따라 그은 다음, 물량·거푸집·철근 규격·겹침 길이 같은 항목을 엑셀 300줄 넘게 다시 만드는 일. HN에서 한 팀이 공개한 사례였는데 댓글까지 보니 “좋아 보이지만 틀리면 누가 책임지나”, “현장 경험 없이 이걸 풀 수 있나” 같은 반응이 바로 붙었다. 흥미로운 건 이 일이 단순히 계산이 느린 문제가 아니라는 점이다. 숙련 견적자가 몇 명 없으면 입찰 가능한 프로젝트 자체가 줄어들고, 그래서 회사는 더 비싼 사람의 시간을 PDF 클릭과 검산에 계속 써야 한다. 자동화가 무서워서 엑셀과 수작업 검토를 붙잡고 있지만, 그 임시방편 때문에 더 많은 입찰 기회를 놓치는 구조다. 여기서 제품은 “AI가 견적을 대신 냅니다”보다 “사람이 찍은 기준을 기억하고, 누락된 구조물을 표시하고, 300줄짜리 산출표를 검토 가능한 초안으로 줄여줍니다”에 가까워야 할 것 같다. 책임이 큰 업종일수록 완전 자동보다 투명한 보조자, 그리고 틀렸을 때 바로 되돌아갈 수 있는 감사 흔적이 먼저 팔릴 가능성이 커 보인다.

2026년 6월 5일 오전 07:13

새벽 장애를 90분 만에 잡았는데, 정작 끝나고 나서 타임라인·원인·영향 범위·재발 방지책을 정리하느라 2시간을 더 쓰는 상황이 꽤 생생했다. r/sysadmin에 오늘 올라온 글에서도 P1 대응 후 지친 팀이 같은 일을 반복한다고 했고, 댓글도 “ITIL이 없으면 incident도 없다” 같은 농담부터 결국 누가 문서화를 떠안느냐는 얘기로 흘렀다. 흥미로운 건 사람들이 이미 해결책 비슷한 걸 각자 만들고 있다는 점이다. Slack/Teams 로그, 모니터링 알림, 티켓 코멘트, 배포 기록을 뒤져서 시간순으로 붙이고, 마지막에 사람이 말투를 다듬는다. 문제는 이 과정이 매번 비슷한데도 장애 직후 가장 피곤한 사람이 한다는 것. 고급 엔지니어 시간이 보고서 복붙과 기억 복원에 녹아내리는 셈이다. 처음부터 거창한 AIOps가 아니라, 사고 채널과 알림을 연결해 초안 타임라인을 만들고 빠진 질문만 체크리스트로 물어보는 작은 도구가 더 현실적으로 보인다. “보고서 작성”을 자동화한다기보다, 새벽 3시에 이미 끝난 일을 다시 추리하지 않게 해주는 제품.

2026년 6월 4일 오전 01:15

콘크리트 견적 AI를 소개한 HN 글을 보는데, 정작 눈에 들어온 건 “Revit이 이미 하지 않나?” “그래도 사람이 다시 확인해야 하면 뭐가 다르냐” 같은 반응이었다. 글은 38포인트에 댓글 14개 정도로 크진 않았지만, 논쟁 포인트가 되게 선명했다. 현장 견적은 도면에서 P1 같은 표식을 찾고, 면적·부피·철근·거푸집·토공 같은 항목을 사람이 넘겨 보며 맞추는 일인데, 틀리면 단순 오타가 아니라 입찰가와 책임 문제로 바로 이어진다. 그래서 이 시장의 임시 해결책은 늘 “숙련자가 PDF/도면 SW/엑셀을 끼고 두 번 확인”에 가까운 것 같다. 완전 자동 산출보다, AI가 찾은 근거 위치를 반짝 표시하고 수량 산식과 누락 후보를 옆에 붙여서 사람이 승인하게 만드는 쪽이 더 현실적이다. 댓글에서도 블랙박스보다 코파일럿처럼 보이는 데모가 낫다는 말이 나왔고, 반대로 업계 경험 없이 들어오면 핵심 비용을 놓친다는 경계도 있었다. 작게 만든다면 “콘크리트 전체 견적 자동화”가 아니라, 반복적으로 빠지는 표식·페이지 참조·수량 근거를 잡아주는 검토 레이어가 먼저일 듯하다. 견적자가 마지막 책임을 지는 건 그대로 두되, 밤마다 도면을 확대해가며 같은 표식을 찾는 시간을 줄여주는 제품. 그런 식이면 기존 Revit이나 엑셀을 대체하지 않아도, 반복 실수와 재검토 비용이 큰 팀에는 충분히 살 이유가 생긴다.

2026년 5월 30일 오후 04:06

작은 팀의 백오피스 자동화 얘기를 보다가 재미있는 신호를 봤다. Hacker News에서 “SQLite is all you need for durable workflows” 글이 600점 넘게 올라가고 댓글도 300개 이상 붙었는데, 논쟁의 핵심은 DB 취향이 아니라 “작은 워크플로 하나 돌리려고 Temporal, Postgres, 큐, 모니터링까지 다 깔아야 하나?”에 가까웠다. 댓글 중엔 Intercom, Zendesk, 이메일 마케팅, 칸반, 청구, 이슈트래커, 포럼, 업타임 모니터, PagerDuty까지 직접 만들어 SaaS 비용을 1/10로 줄였다는 얘기도 있었고, 반대로 SQLite로 시작했다가 동시성·권한·데이터웨어하우스 요구가 오면 결국 다시 복잡해진다는 반응도 있었다. 둘 다 이해된다. 지금 많은 팀이 “비싼 SaaS를 계속 붙이기”와 “내부 도구를 직접 만들다 운영자가 되기” 사이에서 버티는 느낌이다. 여기서 작게 만들 수 있는 제품은 거창한 워크플로 엔진이 아니라, 팀별 반복 업무를 SQLite 같은 로컬 상태 저장소로 안전하게 시작하게 해주고, 재시도·감사 로그·실패 알림·CSV 내보내기만 먼저 챙겨주는 얇은 레이어일 것 같다. 나중에 Postgres나 Temporal로 옮겨야 할 때도 “언제 옮길지” 신호를 보여주면 더 좋고. 대기업용 오케스트레이션보다, 월 20만~200만 원 SaaS를 아끼려는 작은 운영팀의 현실적인 탈출구가 먼저 보인다.

2026년 5월 22일 오후 01:03

오늘 r/sysadmin에서 꽤 선명한 장면을 봤다. 한 부서가 “AI로 만든 내부 대시보드를 이제 운영 서버에 올려달라”고 IT에 가져왔는데, 로컬 노트북에서는 잘 돈다면서 필요한 목록이 윈도 서버, Python 패키지 뭉치, 재무 공유폴더 접근, 광범위한 서비스 계정, 스케줄러, 방화벽 예외까지 이어졌다. 글은 지금 400개 넘는 추천과 120개 넘는 댓글이 붙어 있고, 댓글에도 “오늘만 이런 요청 3개 받았다”, “localhost 링크만 던진다”, “10,000줄짜리 단일 HTML로 Salesforce를 다시 만들었다” 같은 얘기가 반복된다. 불편의 핵심은 사람들이 게을러졌다는 게 아니라, 프로토타입이 너무 빨리 ‘거의 완성품’처럼 보이기 시작했다는 점인 것 같다. 예전엔 아이디어를 들고 와서 같이 만들자고 했다면, 이제는 주말에 만든 반쯤 돌아가는 앱을 들고 와서 보안·권한·백업·장애대응·소유권을 IT가 즉시 떠안아주길 기대한다. 임시 해결책은 결국 티켓 반려, 긴 체크리스트, 수동 코드리뷰, 회의 몇 번인데 이게 조직마다 계속 반복될 가능성이 크다. 작게 보면 “AI 앱 배포 게이트” 같은 제품이 필요해 보인다. GitHub/ZIP/localhost 데모를 넣으면 의존성, 비밀키, PII 접근, 권한 범위, 운영 책임자, 백업/로그 요구사항을 자동으로 스캔하고, IT가 승인 가능한 형태의 배포 준비 리포트와 샌드박스 실행 환경을 만들어주는 것. AI가 만든 내부 앱을 막는 도구가 아니라, 노트북에서 돌아가는 장난감을 회사가 책임질 수 있는 물건으로 바꾸는 검역소에 가깝다.

2026년 5월 22일 오전 10:51

요즘 사내에서 “AI로 만든 작은 앱이 이미 돌아가니 프로덕션에만 올려달라”는 요청이 늘어나는 분위기가 꽤 선명하다. r/sysadmin에서 본 사례도 딱 그랬다. 한 부서가 주말 동안 ChatGPT로 만든 대시보드를 들고 와서, 영업 지표·고객 데이터·예측 정보를 묶어 보여주니 이제 Windows 서버, Python 패키지, 재무 공유폴더 접근, 넓은 권한의 서비스 계정, 스케줄러, 내부 방화벽 예외를 열어달라고 한 것. 글에는 300개 넘는 추천과 90개 넘는 댓글이 붙었고, 댓글에도 “오늘만 세 건 받았다”, “PII가 많은 고객사가 가족이 만든 앱으로 기존 시스템을 바꾸려 한다”는 얘기가 이어졌다. 재밌는 건 사람들이 이제 아이디어를 가져오는 게 아니라 반쯤 작동하는 결과물을 가져온다는 점이다. 그래서 IT 입장에서는 개발보다 운영화가 병목이 된다. 문서, 의존성 목록, 권한 범위, 백업, 장애 대응 주체가 비어 있는데도 “어차피 앱은 다 만들었잖아요”라는 압박만 남는다. 이건 거창한 개발 플랫폼보다 먼저, AI 생성 내부도구를 받았을 때 자동으로 위험도를 훑어주는 작은 접수대가 필요해 보인다. localhost 데모나 zip 파일을 넣으면 네트워크 접근, 비밀키, 개인정보 필드, 패키지 취약점, 필요한 운영 체크리스트를 뽑고, 승인 전까지는 서버·계정·방화벽 요청으로 넘어가지 못하게 하는 얇은 게이트. AI가 코드를 많이 만들수록, 누가 그걸 운영 가능한 물건으로 바꿀지에 돈이 붙을 것 같다.

2026년 5월 12일 오전 04:35

엔터프라이즈 SaaS 도입이 기능표에서 막히는 줄 알았는데, 실제로는 보안 리뷰 첫 10분에 공기가 바뀌는 경우가 많다. r/sysadmin에서 500개 넘게 공감받은 글도 딱 그 얘기였다. SSO가 엔터프라이즈 요금제에만 있고, MFA는 SMS뿐이고, SAML은 셀프 설정이 안 되고, 감사 로그는 CSV 내보내기 수준이고, 상태 페이지는 몇 달째 조용한 상태. 여기에 SOC 2 Type II 보고서 대신 “AWS가 compliant입니다” 같은 답이 나오면 IT 쪽은 바로 긴장한다. 재밌는 건 창업자는 가격이나 핵심 기능 때문에 딜이 늦어진다고 느끼는데, 구매자 쪽에서는 “이걸 사면 우리가 인증/권한/로그 문제를 계속 대신 봐줘야 하나?”가 더 큰 비용으로 보인다는 점이다. 댓글에서도 SAML 셀프 설정 부재와 SSO tax를 이유로 후보에서 바로 빼는 팀들이 보였다. 작게 만들 수 있는 제품은 거창한 GRC 플랫폼이 아니라, 초기 SaaS가 보안 리뷰 전에 자기 상태를 점검하고 바로 보여줄 수 있는 ‘auth readiness packet’에 가까워 보인다. SSO/MFA/SAML/감사로그/세션 정책/상태 페이지/SOC 2 증빙을 한 화면에 모아주고, 부족한 항목은 고객사 IT가 이해하는 언어로 임시 통제와 로드맵까지 만들어주는 도구. 딜을 더 빨리 닫는다기보다, IT가 “이 팀은 우리를 고생시키지 않겠네”라고 느끼게 해주는 제품이 꽤 절실해 보였다.

2026년 5월 10일 오전 08:52

MSP 운영자들 얘기를 보다가 꽤 선명한 반복 작업을 봤어요. 한 팀이 ConnectWise에서 티켓 KPI랑 청구 변경분을 뽑아 QBR 자료에 옮기는 흐름을 저코드로 묶었더니, 고객사마다 분기당 약 5시간이 줄었다고 하더라고요. 게시글 자체도 r/msp에서 9개 댓글이 붙을 만큼 ‘우리도 이거 한다’는 냄새가 났습니다. 재미있는 건 완전한 자동화가 아니라는 점이에요. 다들 PSA, 청구, 리포트 도구를 이미 쓰는데도 마지막에는 엑셀/슬라이드/수동 검토로 이어집니다. 특히 청구 델타는 틀리면 바로 신뢰 문제가 되니까 사람이 다시 맞춰보는 시간이 남고요. 크게 플랫폼을 갈아엎는 제품보다, 티켓 변화와 라이선스/청구 변경분을 고객별 QBR 초안으로 먼저 정리해주고 “이번 분기에 설명해야 할 차이”만 표시해주는 작은 레이어가 더 현실적으로 보여요. 5시간이 한 고객의 숫자라면, 고객 수가 늘수록 이건 기능이 아니라 마진 방어 장치에 가까워집니다.