ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 소프트웨어 외주 개발 비용과 실무 — 받는 쪽에서 본 전부
    외주개발 2026. 2. 17. 23:53

    소프트웨어 외주 개발 비용을 검색하면 금액표가 나온다. 나는 그 금액을 받는 쪽에 있었다

    크몽·숨고에서 외주를 받아왔고, 정산 내역을 열어보면 업체가 부르는 금액과 개발자가 쥐는 금액이 다르다. 그 차이를 먼저 적는다

    다음에서 소프트웨어 외주 개발 비용을 검색한 결과

    업체가 부르는 금액 안에 뭐가 들었나

    업체가 부르는 금액에 들어 있는 플랫폼 수수료와 고객 획득 비용

    내 실제 기록이다. 지어낸 숫자가 아니다

    크몽 정산 내역     21.67% 가 수수료로 나갔다
    숨고 견적 192건    22만원 · 고객 한 명 따는 데 22,376원
    크몽 광고 6개월    54만원

    개발자가 100만원짜리 일을 받으면 손에 남는 건 78만원쯤이다. 거기서 고객을 따는 비용과 노출 유지비가 또 빠진다

    그래서 같은 사람이 같은 일을 해도 플랫폼을 거치면 금액이 올라간다. 업체가 폭리를 취해서가 아니라 구조가 그렇다

    아래에 이런 걸 적었다
    · 업체가 부르는 금액 안에 뭐가 들었나
    · 견적이 2~3배 벌어지는 건 범위가 달라서다
    · 금액을 키우는 건 개발이 아니다
    · 단순 웹/앱이라고 다 같은 게 아닙니다
    · 비용을 좌우하는 진짜 변수들
    필요한 데로 내려가면 됨

    크몽 수수료를 원 단위까지 계산한 글과 숨고 견적 192건 기록에 계산 과정이 다 있다

    개발비만 놓고 업체를 비교하면 같은 일이 달라 보인다. 어디를 거치느냐가 금액에 먼저 들어간다

    견적이 2~3배 벌어지는 건 범위가 달라서다

    같은 요구사항인데 견적이 벌어지는 이유

    같은 요구사항을 줬는데 금액이 2~3배 나는 경우가 실제로 있다. 열어보면 대개 범위가 다르다

    싸게 나온 쪽은 화면 수로만 잡았고, 유지보수·서버·수정 횟수가 빠져 있다. 나중에 그게 다시 청구된다

    금액을 키우는 건 개발이 아니다

    개발보다 공수를 많이 먹는 항목들

    받아보면 개발 자체보다 다른 데서 시간이 간다. 기획이 바뀌는 게 제일 크고, 그다음이 기존 시스템에 붙이는 범위다

    되는 건 빨리 되고 안 되는 것들이 시간을 먹는다. 견적에 들어가는 건 대개 그 안 되는 몫이다

    솔직히 말하면, "외주 개발 얼마예요?"라는 질문은 "집 한 채 얼마예요?"랑 비슷하거든요. 평수, 위치, 인테리어 수준에 따라 천차만별인 것처럼 소프트웨어도 마찬가지입니다. 그래도 2025년 기준으로 시장에서 흔히 볼 수 있는 가격대가 있으니, 실무 경험 기반으로 정리해볼게요.

    단순 웹/앱이라고 다 같은 게 아닙니다

    "간단한 앱 하나 만들어주세요"라는 요청을 정말 많이 받는데, 얘기를 들어보면 간단한 경우가 거의 없어요. 회원가입에 결제 붙이고, 관리자 페이지도 필요하고, 푸시 알림도 되어야 하고... 이러면 이미 간단한 앱이 아닌 거죠.

    2025년 기준으로 대략적인 감을 잡아보면, 정적 웹사이트나 랜딩페이지 수준은 300~800만 원 선에서 해결이 됩니다. 여기에 웹앱 개발 수준으로 동적 기능이 들어가기 시작하면 1,500만 원부터 시작한다고 보면 되고, 제대로 된 서비스를 만들려면 3,000~5,000만 원 이상은 각오해야 더라고요. 물론 SI 프로젝트급으로 가면 억 단위도 흔합니다.

    핵심은 기능 목록이에요. 견적서를 받았을 때 뭐가 포함이고 뭐가 빠져있는지 제대로 파악하는 게 중요한데, 이게 처음엔 좀 어렵습니다. 외주 견적서 읽는 법을 한번 훑어보면 "아, 이 항목이 이런 뜻이었구나" 하는 부분이 꽤 있을 거예요.

    비용을 좌우하는 진짜 변수들

    실제로 프로젝트를 진행해보면, 개발 자체보다 기획 변경이 비용을 키우는 경우가 훨씬 많습니다. "이것도 넣어주세요", "여기 좀 바꿔주세요"가 쌓이면 공수가 눈덩이처럼 불어나거든요.

    그래서 요즘은 처음부터 완성형으로 가기보다 MVP로 먼저 만들고 나중에 키우는 방식을 많이 택하는 추세예요. MVP로 핵심 기능만 먼저 돌려보면 1,000~2,000만 원 선에서 시작할 수 있고, 시장 반응 보고 투자를 결정할 수 있으니 리스크 관리 차원에서도 훨씬 합리적인 셈이죠.

    또 하나 놓치기 쉬운 게 서버와 클라우드 운영비입니다. 개발비만 생각하고 있다가 운영 단계에서 월 수십만 원씩 나가는 서버비에 당황하는 분들이 꽤 있어요. 견적 단계에서 유지보수와 인프라 비용까지 같이 물어보는 게 좋습니다.

    업종별로 다른 비용 구조

    같은 "개발 외주"라도 성격에 따라 비용 구조가 많이 달라요. 예를 들어 데이터 대시보드 쪽은 화면은 단순한데 데이터 파이프라인 설계에 공수가 많이 들어가고, RPA 외주 쪽은 기존 시스템과의 연동 범위에 따라 난이도가 크게 갈립니다. 단순히 화면 수로 비용을 가늠하면 실제 견적이랑 꽤 차이가 나더라고요.

    SI 외주 비용 구조를 보면 인월 단가 기반으로 산정하는 방식을 이해할 수 있는데, 이걸 알아두면 업체가 제시하는 금액이 합리적인지 아닌지 판단하는 데 도움이 됩니다. 2025년 기준 국내 중급 개발자 인월 단가가 대략 700~1,000만 원 사이거든요. 여기에 기획, 디자인, PM 인건비까지 얹어지는 구조라고 보면 됩니다.

    결국 중요한 건 비교와 검증

    개인적으로는 최소 3곳 이상 견적을 받아보라고 항상 얘기합니다. 같은 요구사항인데 업체마다 금액이 2~3배씩 차이 나는 경우가 실제로 있거든요. 비싸다고 무조건 좋은 것도 아니고, 싸다고 무조건 나쁜 것도 아니에요. 포트폴리오 확인하고, 비슷한 프로젝트 경험이 있는지 보는 게 가격보다 중요할 때가 많습니다.

    아직 요구사항이 정리되기 전이라면 프로젝트 문의로 대략적인 범위부터 잡아보는 것도 방법이에요. 최소한 "우리 프로젝트가 몇천 단위인지 몇억 단위인지"는 감이 잡혀야 업체 미팅에서도 대화가 되니까요.

    비용은 결국 투자입니다. 얼마를 쓰느냐보다, 같은 금액으로 얼마나 검증된 결과를 뽑아내느냐가 핵심이에요. 너무 아끼다가 두 번 만드는 것보다, 처음에 제대로 된 파트너를 찾는 데 시간을 좀 더 쓰는 게 결과적으로 훨씬 절약하는 길이더라고요.

    비용을 더 파고든 글도 따로 있다

    이 글은 외주 시리즈 5부작 중 첫 편이다. 나머지는 이거임

    견적 받을 때 이건 같이 물어본다

    견적을 받을 때 같이 물어봐야 할 네 가지

    금액을 깎는 것보다 범위를 맞추는 게 먼저다. 범위가 같아야 비교가 된다

    기능 목록으로 받는다      화면 수 말고 기능 단위로
    유지보수 단가를 같이 묻는다  개발비만 보면 운영에서 놀란다
    서버·인프라 월 비용        월 수십만원이 따로 나간다
    수정 횟수와 기준을 적는다    분쟁의 대부분이 여기다

    견적을 잘 받는 방법은 값을 깎는 게 아니라 범위를 좁혀주는 것이다

    자동화할 업무가 명확하지 않으면 돈만 날린다

    가장 흔한 실수가 "일단 자동화 좀 해주세요"라고 의뢰하는 거예요. 이러면 외주 업체도 난감합니다. 뭘 자동화할지, 어디서부터 어디까지가 범위인지가 정해지지 않으면 견적도 제대로 나올 수가 없어요. 나중에 "이것도 되는 줄 알았는데요?"라는 말이 나오기 시작하면 프로젝트는 사실상 꼬인 거죠.

    그래서 외주를 맡기기 전에 요구사항 범위 정리를 먼저 해보시는 게 좋아요. 거창하게 문서를 만들라는 게 아니라, 지금 수작업으로 하고 있는 업무 흐름을 순서대로 적어보는 것만으로도 충분합니다. 저희가 제공하는 업무 자동화 정리 템플릿을 활용하시면 훨씬 수월하게 정리할 수 있어요.

    크롤링 자동화, 생각보다 법적 리스크가 있다

    RPA 도입하면서 웹 크롤링을 같이 요청하시는 경우가 많은데, 이게 좀 조심해야 할 부분이에요. 상대 사이트의 이용약관을 위반하거나, 개인정보를 무단 수집하게 되면 법적 문제로 이어질 수 있거든요. 실제로 크롤링 자동화 돌리다가 IP 차단당하는 건 약과고, 소송까지 가는 경우도 봤습니다.

    크롤링 자동화의 법적 리스크에 대해서 미리 파악해두시는 걸 강력히 추천드려요. 외주 업체한테 "알아서 해주세요"라고 넘기기엔 리스크가 담당자 본인한테 돌아오는 경우가 많으니까요.

    API 연동이 가능한지부터 확인하세요

    RPA가 화면을 직접 클릭하는 방식으로 돌아가다 보니, 대상 시스템의 UI가 바뀌면 바로 먹통이 됩니다. 이게 생각보다 자주 일어나요. 그래서 가능하다면 API 연동 방식으로 가는 게 훨씬 안정적이에요. 대상 시스템에서 API를 제공하는지, 어떤 인증 방식을 쓰는지 같은 걸 사전에 확인해야 하는데, 이 부분은 API 연동 외주 가이드를 참고하시면 감이 잡히실 겁니다.

    만들고 나서가 진짜 시작이다

    RPA 프로젝트에서 가장 간과되는 부분이 유지보수예요. 개발 비용은 신경 쓰면서 유지보수 비용은 아예 생각 안 하시는 분들이 많더라고요. 그런데 자동화 봇이라는 게 한 번 만들면 영원히 돌아가는 물건이 아닙니다. 연동하는 시스템이 업데이트되면 봇도 수정해야 하고, 예외 상황 처리도 계속 추가해야 하거든요.

    외주 계약할 때 유지보수 범위와 비용, SLA(서비스 수준 협약)를 반드시 명시해두세요. 이 부분을 대충 넘기면 나중에 "이건 추가 개발이라 별도 비용입니다"라는 말을 듣게 되는데, 그때 가서 협상하려면 을의 입장이 될 수밖에 없어요. 유지보수 비용과 SLA에 계약 시 체크해야 할 항목들이 잘 정리되어 있으니 참고하시면 좋겠습니다.

    외주 업체 선정할 때

    견적이 싸다고 좋은 게 아닌 건 다들 아실 텐데, 그래도 막상 비교하면 가격에 눈이 가게 되죠. 저희가 여러 프로젝트를 진행하면서 느낀 건, 외주가 실패하는 다섯 가지 패턴이 거의 비슷하다는 거예요. 요구사항이 모호한 채로 시작하거나, 커뮤니케이션 구조가 안 잡혀 있거나, 중간 점검 없이 결과물만 기다리는 식이면 높은 확률로 문제가 생깁니다.

    업체를 고를 때는 포트폴리오보다 커뮤니케이션 방식을 먼저 보세요. 진행 중간에 데모를 보여주는지, 이슈가 생겼을 때 얼마나 빠르게 대응하는지가 결과물 품질을 좌우하는 경우가 많습니다.

    RPA 도입이 무조건 정답은 아니지만, 제대로 준비해서 들어가면 확실히 효과가 있는 건 사실이에요. 핵심은 "뭘 자동화할지"를 명확히 하고, 유지보수까지 고려한 계획을 세우는 거예요. 이 두 가지만 잡혀 있어도 프로젝트가 산으로 갈 확률이 확 줄어듭니다.

    업무자동화 외주를 검토 중이시라면 프로젝트 문의부터 시작해보세요. 현재 업무 상황을 말씀해주시면 자동화가 적합한 영역인지, 어떤 방식이 맞는지 같이 고민해드리겠습니다.

    이 글은 외주 시리즈 5부작 중 2편이다

    앞 글 · 1편 소프트웨어 외주 개발 비용, 얼마가 적정할까

    다음 글 · 3편 웹크롤링 외주 맡기기 전에 확인할 것

    수집할 데이터의 범위, 생각보다 애매합니다

    외주를 맡길 때 "상품 정보 크롤링해주세요"라고만 하면 거의 100% 서로 다른 그림을 그리고 있어요. 상품명이랑 가격만 필요한 건지, 리뷰 텍스트까지 포함인지, 이미지 URL도 뽑아야 하는지. 이걸 처음에 확실히 안 잡으면 중간에 범위가 슬금슬금 늘어나거든요. 그래서 외주 요청서 템플릿을 미리 작성해두면 나중에 "이건 추가 작업이에요"라는 말이 오갈 일이 확 줄어들어요.

    법적 리스크, 남 얘기가 아닙니다

    크롤링이 기술적으로 가능한 거랑 법적으로 괜찮은 건 완전 별개의 문제예요. robots.txt를 무시하고 긁다가 내용증명 받는 경우도 실제로 있고, 개인정보가 포함된 데이터를 수집했다가 골치 아파지는 케이스도 봤어요. 외주 업체한테 "알아서 해주겠지" 하고 넘기면 나중에 책임 소재가 애매해지는 셈이죠. 크롤링 자동화의 법적 리스크 쪽을 한번 읽어보시면 어떤 부분을 짚어야 하는지 감이 올 거예요.

    비용 구조를 이해하고 있어야 합니다

    크롤링 외주 비용은 단순히 개발 인건비만 있는 게 아니에요. 대량 수집이면 서버 비용이 꽤 나가고, 정기적으로 돌려야 하면 유지보수 비용도 붙거든요. 견적을 받을 때 아래 항목 정도는 분리해서 확인해보는 게 좋아요.

    항목 확인 포인트
    초기 개발비 크롤러 설계·구현 비용, 일회성인지
    서버/인프라 클라우드 사용 시 월 예상 비용
    유지보수 사이트 구조 변경 시 대응 범위
    데이터 정제 수집 후 가공·정리 포함 여부

    서버 쪽 비용이 감이 안 잡히시면 서버와 클라우드 비용 가이드가 참고가 될 겁니다.

    결과물 검수, 꼭 직접 해보세요

    데이터를 받았는데 빈 값이 반이라든가, 인코딩이 깨져 있다든가 하는 일은 생각보다 자주 생겨요. 저도 한번은 5만 건 받았는데 중복 제거하니까 실제 유효 데이터가 2만 건도 안 되는 적이 있었거든요. 납품 기준을 미리 정해두고 납품 검수 체크리스트를 돌려보는 게 시간은 좀 들어도 결국 아끼는 길이더라고요.

    계약서, 대충 넘기지 마세요

    구두로만 합의하고 시작하면 문제가 생겼을 때 풀 방법이 없어요. 데이터 소유권이 누구한테 있는지, 수집된 데이터의 보안 관리는 어떻게 하는지, 일정이 지연되면 어떻게 되는지 같은 건 반드시 서면으로 남겨야 해요. 외주 계약서 체크리스트에 기본적인 항목들이 잘 정리되어 있으니 계약 전에 한번 훑어보시면 됩니다.

    크롤링 외주가 어려운 건 기술 자체가 아니라, 기대하는 결과물을 정확히 전달하고 관리하는 과정이에요. 위에 적은 것들만 제대로 챙겨도 "돈 쓰고 후회하는" 상황은 대부분 피할 수 있을 거예요.

    혹시 수집 범위 정의부터 대시보드 구축까지 한 번에 맡기고 싶다면 데이터 대시보드 구축 쪽을 살펴보셔도 좋고, 바로 상담이 필요하면 프로젝트 문의에서 편하게 문의 주세요.

    크롤링 외주 비용이 어디서 갈리는지는 따로 적었다

    이 글은 외주 시리즈 5부작 중 3편이다

    앞 글 · 2편 업무자동화(RPA) 외주 도입 전에 알아야 할 것들

    다음 글 · 4편 외주 개발은 왜 자꾸 실패할까

    "우리는 앱이 꼭 필요해요"라고 하는 분들한테

    항상 드리는 말씀인데, "앱이 필요하다"고 느끼는 이유를 한번 뜯어보면 실제로 네이티브 앱이어야 하는 경우는 생각보다 적어요. 대부분은 "사용자가 스마트폰으로 쓸 거니까 앱이겠지"라는 인식에서 출발하거든요.

    근데 모바일 브라우저에서 반응형으로 잘 돌아가는 웹앱이면 충분한 서비스가 꽤 많아요. 관리자 페이지가 있는 B2B SaaS, 사내 업무 시스템, 예약·주문 플랫폼 초기 버전 같은 것들이요.

    반대로 네이티브 앱이 확실히 맞는 케이스도 있죠. 블루투스로 하드웨어 연동해야 하거나, 오프라인에서도 무거운 작업을 처리해야 하거나, 푸시 알림이 서비스 핵심 기능인 경우. 이런 건 웹으로 억지로 하면 오히려 고생만 해요.

    초기 스타트업이라면 웹앱 먼저 추천하는 이유

    스타트업에서 MVP 만들 때 앱부터 개발하면 리스크가 커요. iOS 한 번, Android 한 번 만들면 개발 비용이 두세 배로 뛰는 건 물론이고, 스토어 심사 때문에 빠른 피드백도 어렵거든요.

    웹앱으로 먼저 시장 반응을 보고, 사용자가 모이기 시작하면 그때 네이티브 앱을 붙여도 늦지 않아요. 실제로 제가 본 프로젝트 중에 처음부터 앱으로 갔다가 중간에 방향을 틀면서 이미 쓴 개발비를 날린 경우가 한두 번이 아니에요.

    웹앱 개발 쪽으로 먼저 진행하면 같은 예산으로 훨씬 빠르게 런칭까지 갈 수 있어요.

    기술적으로 미리 챙겨야 할 것들

    웹앱이든 모바일앱이든 나중에 발목 잡히는 건 보통 기획 단계에서 빠뜨린 것들이에요. 특히 이 세 가지는 초반에 방향을 잡아두는 게 좋아요.

    • 첫 번째, 데이터베이스 설계. 서비스 구조가 확장될 때 DB 설계가 엉망이면 나중에 갈아엎어야 하거든요.
    • 두 번째, 로그인과 권한 구조. 관리자와 일반 사용자 구분이 필요한 서비스라면 초기에 설계 안 해두면 나중에 코드가 꼬여요.
    • 세 번째, 스테이징과 운영 서버 분리. 스테이징 서버 없이 바로 운영에 올리는 팀이 아직도 많은데, 이건 사고 나기 딱 좋은 구조예요.

    백엔드 프레임워크 선택도 프로젝트 규모에 맞게 해야 하고요. 이런 기술 판단이 어려우면 초기 상담 단계에서 같이 잡아가는 게 맞아요.

    그래서 결론은

    "무조건 웹앱" 또는 "무조건 네이티브 앱"은 아니에요. 근데 제 경험상 초기 서비스의 70~80%는 웹앱으로 시작하는 게 맞더라고요. 비용도 아끼고, 속도도 빠르고, 피벗도 쉬우니까요.

    만약 지금 뭘로 시작할지 고민 중이시면, 웹앱 기획 템플릿을 한번 채워보세요. 머릿속에 있는 걸 정리하는 것만으로도 방향이 꽤 잡혀요. 그래도 판단이 안 서면 프로젝트 문의 주시면 상황 듣고 솔직하게 말씀드릴게요. 앱이 맞으면 앱이 맞다고 할 테니까요.

    이 글은 외주 시리즈 5부작 중 5편이다

    앞 글 · 4편 외주 개발은 왜 자꾸 실패할까

    시리즈 처음 · 1편 소프트웨어 외주 개발 비용, 얼마가 적정할까

    사이트 만드는 건 이제 안 어렵다

    솔루션을 쓰든 직접 짜든 화면은 나온다. 상품 올리고 장바구니 붙이는 것도 정해진 순서가 있고

    문제는 그다음이다. 돈을 받으려면 PG사 심사를 통과해야 한다

    자사몰 만들기 실제 순서 - 사이트보다 결제 준비가 오래 걸린다

    위쪽은 내가 통제할 수 있는데 아래쪽은 남이 심사한다

    PG 심사에서 반려당했다

    새로집에 결제를 붙일 때였다. 포트원으로 다날을 연결하는 구조로 갔음

    서류 넣고 기다렸는데 반려가 왔다. 사유가 통신판매업 신고가 안 되어 있다는 거였다

    PG 심사 반려 사유와 해결 순서

    사업자등록증만 있으면 되는 줄 알았다

    사업자등록이랑 통신판매업 신고는 별개다. 사업자등록은 "사업을 한다"는 거고, 통신판매업 신고는 "온라인으로 물건이나 서비스를 판다"는 신고다. 온라인에서 결제를 받으려면 후자가 필요하다

    이걸 몰라서 며칠 날렸다. 신고하고 다시 넣으니까 통과됐음

    순서가 틀렸던 거다

    지금 보면 이렇게 했어야 했다

    사이트를 다 만들어놓고 결제를 붙이려니까 막힌 거다. 결제 준비는 사이트랑 병렬로 가야 한다

    심사는 내가 빨리 한다고 빨라지지 않는다. 서류 넣고 기다리는 시간이고, 반려되면 그만큼 또 밀린다. 오픈 날짜를 잡아뒀으면 이 구간에서 다 어긋난다

    자사몰 만들기에서 사이트 제작과 결제 준비를 병렬로 진행하는 일정

    오픈일이 정해져 있으면 결제부터 시작하는 게 맞다

    결제 붙이는 두 가지 길

    PG 직접 연동과 통합 게이트웨이 비교

    나는 두 서비스에서 다르게 갔다

    새로집은 포트원을 썼다. 여러 PG를 하나의 방식으로 붙일 수 있어서 나중에 갈아탈 때 편하다

    프리시는 토스페이먼츠랑 페이팔을 붙였다. 해외에서 의뢰가 들어와서 페이팔이 필요했음

    어느 쪽이 맞다기보다 해외 결제를 받을지부터 정하면 갈린다. 국내만이면 선택지가 넓고, 해외가 섞이면 그걸 되는 곳으로 좁혀야 한다

    결제가 붙으면 그다음이 또 있다

    붙였다고 끝이 아니다. 청구서를 어떻게 보여줄지도 만들어야 한다

    결제 전 청구 금액을 보여주는 화면

    총액이 얼마고 지금 내는 게 얼마인지가 한 화면에 있어야 한다

    이게 없으면 결제 직전에 이탈한다. 얼마를 내는 건지 모르는 상태로 카드번호를 넣는 사람은 없음

    유형별 고정 가격을 미리 적어둔 메뉴판

    값을 미리 박아두면 결제까지 가는 길이 짧아진다

    자사몰이 꼭 답은 아니다

    솔직하게 적어둔다

    플랫폼에 입점하면 결제도 정산도 그쪽이 다 해준다. 통신판매업도 플랫폼 명의로 처리되는 경우가 있고. 수수료를 내는 대신 이 귀찮은 걸 안 겪는 거다

    자사몰은 수수료를 아끼는 대신 이걸 전부 내가 진다. 심사도 내가 받고, 정산도 내가 보고, 결제 사고도 내가 받는다

    파는 게 몇 개 안 되고 검증 중이면 플랫폼이 낫다. 자사몰은 팔리는 게 확인된 다음에 만들어도 늦지 않다

    자체 사이트에서 직접 문의를 받는 화면

    나는 결제까지 붙였지만, 처음엔 문의만 받는 화면부터 시작했다

    미룬 게 아니었어요

    ADHD 미루기를 게으름으로 설명하면 이상해집니다. 저는 그 밤에 놀고 있지 않았거든요. 여덟 시간 동안 코드를 고쳤어요. 아무도 시키지 않은 코드를.

    그러니까 하기 싫어서 안 한 게 아니라, 시작이 안 걸린 겁니다.

    제 임상 기록에는 이렇게 적혀 있어요. 일의 순서나 우선순위를 정해 계획대로 실행하기 어렵고, 흥미가 붙는 일부터 먼저 처리하다 마감을 놓친다고.

    흥미가 붙는 일부터. 그게 정확한 묘사입니다. 손이 그쪽으로 먼저 가요.

    밖에서는 게으름으로 보입니다

    이게 제일 억울했던 부분이에요.

    안에서 벌어지는 일과 밖에서 보이는 결과가 완전히 다릅니다. 저는 여덟 시간을 일했는데 마감은 안 지켜져 있어요. 그럼 결과만 보는 사람한테 저는 논 사람이 됩니다.

    회사에서 이건 아주 짧은 문장으로 요약됐어요. 성실하지 않다.

    ADHD 미루기가 게으름과 다른 지점이 여기입니다. 게으른 사람은 아무것도 안 해요. 저는 계속 뭔가를 하고 있었는데 그게 해야 할 일이 아니었을 뿐입니다.

    그런데 이걸 설명하려고 하면 변명처럼 들려요. 그래서 대개는 그냥 사과했습니다.

    계획표는 늘 새로 만들었습니다

    시험 기간마다 계획표를 만들었어요. 과목별로 시간을 나누고 색깔까지 칠했습니다.

    그 계획표대로 공부한 날은 한 번도 없었어요.

    계획을 못 세우는 게 아닙니다. 계획은 잘 세워요. 재밌거든요. 새 계획표를 만드는 건 새로운 일이니까 손이 갑니다.

    실행이 안 되는 거죠.

    ADHD 미루기는 지속이 아니라 진입 문제였어요

    그래서 알게 된 게 하나 있어요. 저한테 문제는 지속이 아니라 진입이었습니다.

    일단 시작하면 오히려 못 멈춰요. 밥때를 넘기고 새벽까지 갑니다. 그런데 그 시작이 안 걸립니다.

    그래서 지금은 첫 단계를 우스울 정도로 작게 쪼갭니다.

    견적서를 쓴다가 아니라 파일을 연다. 코드를 짠다가 아니라 함수 이름 하나를 적는다. 이 정도로요.

    파일만 열어도 그다음은 대체로 굴러가더라고요.

    제일 잘 먹힌 건 이거였어요

    하기 싫은 일을 시스템 밖으로 아예 빼버리는 것.

    견적서가 그랬습니다. 저는 견적서 쓰는 걸 계속 미뤘거든요. 그래서 쓰던 양식에 맞춰 자동으로 나오게 만들어놨어요. 이제 대화를 붙여넣으면 문서가 나옵니다.

    미루는 습관은 안 고쳐졌어요. 미룰 일이 없어진 겁니다.

    계약서 보내는 것도 마찬가지고요. 돈 얘기 꺼내는 게 어색해서 계속 미뤘는데, 지금은 서명하면 인보이스가 알아서 나갑니다.

    ADHD 미루기를 고치려는 건 오래 해봤습니다

    시간 관리 앱을 깔고, 뽀모도로를 돌리고, 할 일 목록을 만들고.

    며칠은 됩니다. 그러다 한 번 무너지면 앱을 지웠어요. 그리고 저를 탓했습니다. 이것도 못 하냐고.

    몇 번 반복하고 나서 방향을 바꿨어요. 내가 매번 잘 해내야 하는 구조 자체가 잘못됐다고요.

    같은 걸로 힘드시면

    제 경우 기준으로만 말씀드릴게요.

    미루고 있는 일을 하나 골라서, 그 일의 첫 동작이 뭔지 적어보세요. "보고서 쓰기"가 아니라 "문서 열기" 수준으로요. 그게 30초 안에 되는 크기면 대체로 걸립니다.

    그리고 계속 미뤄지는 일이 매달 반복되는 종류라면, 그건 습관 문제가 아니라 설계 문제일 수도 있어요. 없앨 수 있는지 먼저 보세요.

    저는 고치는 걸 이십 년 했는데 안 됐습니다. 없애는 건 하루면 되더라고요.

    서명 그림은 증거가 약하다

    이미지 파일은 복사하면 그만임. 누가 언제 어디서 넣었는지가 그림에는 안 남는다

    계약에서 다투게 되는 건 보통 이런 것들이다

    세 번째가 제일 자주 걸림. 서명 이미지로는 하나도 답이 안 된다

    서명 하나에 같이 남기는 것

    우리 구현은 이럼

    전자서명 시점에 함께 저장하는 항목들

    서명 버튼을 누르는 순간 이게 한 세트로 저장된다

    전자서명 기록 테이블 예시 데이터

    실제로는 이런 모양으로 쌓인다 (예시 데이터)

    서명 방식은 두 가지를 뒀다. 타이핑으로 이름을 치는 방식과 손글씨로 그리는 방식. 손글씨는 이미지를 S3에 올린다

    IP는 그냥 요청에서 꺼내면 안 된다. ALB를 거치기 때문에 서버가 보는 건 로드밸런서 주소다. x-forwarded-for의 첫 값을 써야 실제 서명자 IP가 잡힌다

    한 번 서명한 계약은 다시 서명 못 하게 막아뒀음. 안 막으면 덮어쓴 기록이 남는데 그게 더 위험하다

    핵심은 계약서 스냅샷이다

    여기가 이 글에서 제일 하고 싶은 얘기임

    서명 시점의 계약서 본문을 통째로 같이 저장한다. 양식 버전도 같이

    계약서 스냅샷이 있을 때와 없을 때의 차이

    스냅샷이 없으면 이 반박에 대응할 방법이 없다

    계약서 양식은 계속 고쳐진다. 조항을 다듬고 문구를 바꾸고. 그런데 서명 기록에 계약서 ID만 남아 있으면, 나중에 그 ID로 불러오는 건 지금 버전이다

    상대가 "내가 서명한 건 이 내용이 아니었다"고 하면 반박할 게 없다. 실제로 양식을 바꿨으니까

    본문을 통째로 박아두면 그때 화면에 있던 글자가 그대로 남는다. 용량은 좀 먹지만 이건 아껴서 될 게 아니다

    서명 전 계약 내용을 확인하는 화면

    서명 전에 보는 화면. 이 상태 그대로가 기록에 들어간다

    법적으로 되는가

    된다. 근거는 두 개임

    전자문서법과 전자서명법 근거 조항

    2020년 개정으로 공인인증서 독점이 없어졌다

    전자문서법 제4조가 전자적 형태라는 이유로 문서 효력을 부인하지 못하게 한다. 전자서명법 제3조 제1항은 서명 효력도 같은 취지고

    그리고 같은 법 제3조 제2항이 이렇게 정한다. 법령이나 당사자 간 약정에 따라 전자서명을 선택했으면 그건 서명으로서 효력을 가진다고

    그래서 계약서에 "양측은 전자서명 방식으로 체결하는 데 동의한다"는 조항을 넣어두는 게 중요하다. 약정이 근거가 되니까

    법률 자문이 아니다. 금액이 크거나 분쟁이 우려되면 변호사에게 확인하는 게 맞다

    그래서 이걸로 충분하냐면, 아니다

    자체 구현의 한계를 적어둠. 파는 글이 아니니까

    자체 구현과 전문 서비스의 부인방지 차이

    부인방지에서 갈린다

    우리가 남긴 기록은 우리 서버 DB에 있다. 우리가 관리하는 데이터다

    분쟁이 붙으면 상대가 이렇게 나올 수 있다. 사후에 조작한 것 아니냐고. 기술적으로 불가능하다는 걸 우리가 입증해야 하는 구조다

    전문 서비스는 이걸 타임스탬프 인증기관과 해시체인으로 막는다. 제3자가 시점을 보증하고, 뒤에 손대면 체인이 깨진다. 자체 구현으로는 여기까지 못 간다

    언제 넘어가야 하나

    기준을 정해두면 편함

    자체 구현을 유지할 때와 전문 서비스로 넘어갈 때

    셋 중 하나가 오면 갈아탈 때다

    소액 단발 계약은 자체 구현으로 충분하다. 상대도 굳이 다투지 않고, 다퉈봐야 실익이 없다

    반대로 금액이 커지거나 상대가 법인 법무팀을 거치면 얘기가 달라진다. 그쪽은 증거력을 따진다

    나는 아직 첫 번째 구간에 있다. 그래서 직접 만든 걸 쓰고 있고, 언제 넘어갈지는 정해뒀다

    웹과 앱은 마지막 단계가 다릅니다

    웹은 만들어서 서버에 올리면 끝입니다. 주소를 알려주면 사람들이 들어와요.

    앱은 다릅니다. 애플과 구글의 심사를 통과해야 사용자 손에 들어갑니다. 그리고 그 과정에 사람 시간이 꽤 듭니다.

    단계웹앱
    개발자 계정없음애플 연 129,000원 / 구글 최초 25달러
    서명·인증없음인증서, 프로비저닝 프로파일 발급
    배포서버에 올리면 끝스토어 제출 → 심사 대기
    반려되면해당 없음수정 후 재제출, 또 대기
    수정 배포즉시 반영다시 심사

    "반려되면"이 제일 큽니다. 심사는 한 번에 통과한다는 보장이 없어요. 무엇 때문에 걸릴지는 붙여봐야 압니다.

    실제로 겪은 것

    정리수납 업체 앱을 만들어서 올린 적이 있습니다. iOS가 제 주력이 아니라서 배포 쪽은 하나씩 확인해가며 했어요.

    애플 개발자 계정을 만들고, 인증서를 발급받고, 프로비저닝 프로파일을 만들고, 앱 ID를 등록하고. 여기까지가 코드와 아무 상관이 없는데도 시간이 갑니다.

    그리고 심사 제출을 하려면 스크린샷을 기기 크기별로 준비해야 하고, 앱 설명 문구를 써야 하고, 개인정보 처리 항목을 다 체크해야 해요. 이것도 사람이 앉아서 하는 일입니다.

    중간에 사장님께 테스트 버전을 드려야 했는데, 컴퓨터를 어려워하시는 분이라 설치 링크로는 안 됐어요. 결국 파일로 만들어서 메일로 보내드렸습니다. 이런 것도 다 시간이에요.

    그래서 견적에서 확인할 것

    앱 개발 외주 비용 견적을 받으면 이 항목들이 적혀 있는지 보세요.

    • 개발자 계정을 누가 만들고 누가 유지하는지. 외주 업체 계정으로 올리면 나중에 앱을 못 가져옵니다. 꼭 발주사 명의로 만드세요.
    • 스토어 심사 대응이 범위에 있는지. "제출까지"인지 "통과까지"인지 문장으로 확인하세요. 반려 대응 횟수를 정해두면 더 좋습니다.
    • 스크린샷과 스토어 문구를 누가 만드는지. 의외로 여기서 다툽니다.
    • 출시 후 수정 배포가 몇 회까지 포함인지. 앱은 고칠 때마다 심사를 다시 받습니다.
    • iOS와 안드로이드 중 뭘 먼저 하는지. 둘 다면 비용이 그냥 두 배가 아니라, 심사도 두 번입니다.

    계정 명의는 진짜 중요합니다

    이건 따로 강조할게요.

    앱을 외주 업체 개발자 계정으로 올리면, 나중에 업체를 바꿀 때 앱을 통째로 못 가져옵니다. 이관 절차가 있긴 한데 상대가 협조해야 되고, 사이가 틀어진 상태면 그게 안 됩니다.

    새로 올리면 되지 않냐 하실 수 있는데, 그러면 기존 사용자와 리뷰가 전부 날아갑니다. 다운로드 수도 0부터 다시예요.

    계정은 발주사 명의로 만들고, 로그인 정보는 발주사가 가지고 계세요. 개발자에게는 초대해서 권한만 주면 됩니다.

    그럼 웹으로 하면 안 되나

    물어보시는 분들이 많은데, 실제로 그게 나은 경우가 꽤 있습니다.

    웹으로 만들고 홈 화면에 추가하게 하는 쪽이 훨씬 쌉니다. 심사도 없고, 고칠 때 바로 반영되고, 계정 문제도 없어요.

    앱이 필요한 이유가 "요즘 다 앱 있으니까"라면 한 번 더 생각해보시는 걸 권합니다.

    비교표는 들어갈 때 얘기다

    기능표에 있는 건 전부 입장할 때 기준이다. 결재 양식, 게시판, 모바일 앱, 조직도 연동

    그룹웨어 고를 때 보는 항목과 나갈 때 드러나는 항목의 차이

    왼쪽은 데모로 확인되고 오른쪽은 해지할 때 알게 된다

    근데 그룹웨어는 한번 넣으면 몇 년을 쓴다. 그 몇 년 뒤에 생기는 문제를 고를 때는 아무도 안 물어본다

    내가 불려간 게 정확히 그 몇 년 뒤였음

    1. 나갈 때 데이터를 어떻게 주냐

    이게 제일 크다

    우리가 맡은 건 기존 그룹웨어 문서를 웹에서 열람 가능하게 만드는 거였다. 그러려면 먼저 데이터를 받아야 하잖음

    **내보내기가 없었다.** 관리자 화면에도 없고, 벤더한테 물어도 그런 기능은 없다고 했다

    내보내기 기능이 없을 때 실제로 하게 되는 작업 순서

    이걸 개발 공수로 다시 사는 셈이다

    결국 관리자 계정으로 로그인해서 목록 조회를 페이지 단위로 긁고, 문서를 하나씩 열어서 저장했다. 데이터를 사는 게 아니라 데이터를 되찾는 작업이었음

    계약 전에 서면으로 받아야 하는 질문

    답이 "요청 주시면 검토"면 없는 거다

    2. 첨부파일이 문서에 딸려오냐

    첨부라는 말이 세 가지를 뭉뚱그린다

    첨부파일, 본문 삽입 이미지, 외부 링크는 서로 다르게 취급된다

    이거 셋이 각각 다른 방식으로 깨진다

    본문 안에 박힌 이미지가 제일 골치였다. HTML에 옛 서버 주소로 걸려 있어서, 서버를 내리는 순간 문서 전체가 빈 네모가 된다

    그래서 본문 이미지까지 전부 따로 내려받아서 경로를 바꿔 끼웠다. 한글 파일명 인코딩 깨지는 것도 여기서 나온다

    3. 결재선 이력이 데이터냐 화면이냐

    전자결재를 쓰는 이유의 절반이 이거다. 누가 언제 무슨 순서로 승인했는지

    근데 그게 조회 가능한 데이터로 안 남고 화면에만 있는 경우가 있다

    조회 가능한 기록으로 남는 것과 화면으로만 남는 것

    오른쪽만 있으면 나중에 검색이 안 된다

    우리는 문서마다 결재선을 따로 긁어서 컬럼에 박았다. 안 그러면 PDF 그림으로만 남거든

    지출결의서처럼 표가 들어간 문서는 더 심했다. 항목·계정·공급가·세액이 다 본문 HTML 안에 표로만 있어서, 그걸 파싱해서 별도 테이블로 뜯어냈음

    감사받을 때 필요한 건 화면 캡처가 아니라 조건 걸어서 뽑히는 기록이다

    4. 몇 년치를 한 덩어리로 주냐

    백업을 받았더니 연도별 zip 여섯 개, 합쳐서 **198GB**였다

    연도별로 완전히 분리되어 넘어온 6개년 백업 구조

    여섯 개가 각각 독립된 아카이브다. 합쳐진 게 아니고

    연도마다 DB가 따로였다. 첨부 폴더도 따로. 문서 수도 어떤 해는 8천 건대인데 어떤 해는 7만 건대로 들쭉날쭉했음

    합치자는 얘기가 나왔는데 문서 번호랑 파일명이 연도끼리 겹쳐서 위험했다. 결국 합치지 않고 연도 선택기를 붙이는 쪽으로 갔다

    전송하다가 zip이 깨진 것도 있었다. 200GB에 가까우면 그냥 복사가 안 된다. 무결성 검사 돌려서 깨진 것만 다시 받았음

    같은 프로젝트에서 실패 건수 처리하는 얘기는 따로 적었다

    그래서 뭘 추천하냐

    제품명은 안 쓴다. 회사마다 조건이 다르고 나는 전수 비교를 안 해봤으니까

    대신 견적 미팅에서 물어볼 문장 네 개는 줄 수 있

    그룹웨어 계약 전 서면으로 확인할 네 가지 질문

     

    구두로 받지 말고 문서로 받아라

    이 넷에 서면으로 답을 못 주면 거르면 된다. 기능이 부족해서가 아니라, **나중에 나갈 수 없는 곳이라서**

    들어갈 때 편한 건 어차피 다 비슷하다. 데모는 다 잘 돌아가니까

    정리하면

    • 부르는 금액과 개발자가 쥐는 금액이 다르다. 크몽은 21.67% 가 먼저 빠진다
    • 고객 한 명 따는 데도 비용이 든다. 숨고 기준 22,376원이었다
    • 견적이 2~3배 나면 대개 범위가 다르다. 금액부터 비교하면 안 된다
    • 공수를 먹는 건 기획 변경이다. 개발 자체가 아니다
    • 유지보수·서버비를 같이 묻는다. 개발비만 보면 운영 단계에서 놀란다

    싼 견적이 싼 게 아니라 안 적힌 것이다. 안 적힌 건 나중에 청구된다

    같이 보면 좋은 글

운영 프리시 · 상호 앤디 · 대표 손영은 · 사업자등록번호 708-38-01407
경기도 안산시 상록구 해안로 705, 3동 1층 107호 · son970523@khu.ac.kr
Designed by Tistory.