빌더 기능 밖의 요구가 이미 있다
결제 조건에 따라 흐름이 갈리는 로직, 운영팀 업무에 맞춘 자체 관리자 화면, 외부 시스템과의 API 연동, 사용자 권한이 여러 단계로 나뉘는 구조는 빌더가 제공하는 기능 목록 안에 없는 경우가 많습니다. 기획 단계에서 이런 항목이 이미 적혀 있다면 직접 개발이 맞습니다.
- 약 350,000 LOC3-사이드 B2B2C 컨설팅 SaaS
- 약 135,000 LOC전문 인력과 발주 기업을 잇는 양면 마켓플레이스
- 250개 시군구 / 3,523개 행정동리테일 입지분석 엔진
- 코드 1개 / 플랫폼 3개웹, iOS, 안드로이드로 함께 나가는 가계부 앱
빌더를 쓸 때와 코드로 만들 때
빌더로 되는 일과코드가 필요한 일은 다릅니다.
노코드 빌더
카페24아임웹식스샵WixSquarespace
노코드 빌더는 첫 화면을 띄우는 데까지 가장 빠른 길입니다. 요구사항이 빌더가 제공하는 기능 안에서 끝난다면 저희도 빌더를 권합니다. 직접 개발이 필요한 경우는 따로 있습니다.
판단 기준은 하나입니다. 아래 세 가지 중 해당되는 항목이 있는지입니다.
코드와 인프라를 회사 자산으로 가져가야 한다
빌더로 만든 사이트는 해당 업체 서버 위에서만 동작하고, 데이터 추출과 이전은 업체가 허용하는 범위 안에서만 가능합니다. CREDO가 만든 결과물은 계약에 따라 코드와 인프라 소유권이 클라이언트에게 완전히 이전됩니다. 저장소와 서버 계정, 배포 설정까지 함께 넘겨드리므로 이후 다른 업체와 작업하셔도 됩니다.
출시 이후에도 기능을 계속 붙일 계획이다
비용이 커지는 쪽은 첫 출시보다 그 다음입니다. 1년 뒤 새 기능을 붙일 때 빌더 기능 밖이면 그 시점에 처음부터 다시 만들게 됩니다. 로드맵이 1회성 사이트가 아니라 계속 자라는 서비스라면, 처음부터 코드로 쌓는 편이 총 비용이 적게 듭니다.
세 가지 중 하나라도 해당되면, 처음부터 코드로 만드는 편이 낫습니다.
Services
기획, 디자인, 프론트엔드, 백엔드, 배포를 외부 하청 없이 내부에서 진행합니다.
01
기획과 디자인
무엇을 만들지 정리하고 화면으로 옮깁니다. 실제로 쓸 담당자를 인터뷰해 업무 흐름을 파악한 뒤 정보 구조를 잡고, Figma에서 주요 화면과 상태를 전부 그립니다. 개발로 넘어가는 산출물은 화면 시안, 컴포넌트 정의, 클릭되는 프로토타입입니다.
요구사항 정의정보 구조화면 설계디자인 시스템프로토타입
02
프론트엔드
디자인 파일과 어긋나지 않는 화면을 만듭니다. 모바일 레이아웃, 키보드 접근성, 초기 로딩 속도는 나중에 손보는 항목이 아니라 처음부터 구현 범위에 넣습니다. 프레임워크는 프로젝트 성격과 이후 운영 주체에 맞춰 고릅니다.
화면 구현반응형접근성성능 최적화인터랙션
03
백엔드와 데이터베이스
화면 뒤의 API와 데이터베이스를 설계하고 만듭니다. 로그인과 권한, 결제 연동, 외부 시스템 연동, 운영팀이 직접 쓰는 관리자 화면까지 다룹니다. 데이터 모델은 구현에 들어가기 전에 문서로 합의합니다.
API 설계데이터 모델링로그인과 권한결제 연동관리자 화면
04
배포와 운영
배포 파이프라인을 만들고 운영까지 맡습니다. 코드가 병합되면 자동으로 배포되고, 에러와 응답 속도는 모니터링에 연결합니다. 검색엔진 대응과 방문 데이터 집계는 출시 전에 설정을 끝냅니다. 출시 후 유지보수는 범위와 기간을 정한 별도 계약으로 진행합니다.
자동 배포모니터링검색 노출방문 분석유지보수
Track Record
아래는 기획부터 배포까지 직접 완료한 프로젝트입니다. 코드는 비공개라서 구조와 규모, 담당 범위만 적었습니다.
모든 프로젝트가 비밀유지계약 대상이라 고객사명은 적지 않습니다. 아래 설명은 계약이 허용하는 범위까지만 적었습니다.
약 350,000 LOC
3-사이드 B2B2C 컨설팅 SaaS
역할이 다른 세 주체를 한 서비스에 넣으면 권한 분기가 화면 전체로 번집니다. 전문직 창업을 다루는 플랫폼이라 세 주체에게 각각 별도 앱을 주되, API 클라이언트와 화면 컴포넌트, 디자인 토큰, 구독 플랜 판정 로직은 공유 패키지로 내려 같은 코드를 세 번 만들지 않게 했습니다. 권한은 화면마다 조건문을 흩뿌리는 대신 조합해 쓰는 가드 8종으로 분리해, 민감한 작업 앞에는 재인증 가드를 한 겹 더 얹는 식으로 처리합니다. 백엔드는 도메인 32개와 테이블 73개, REST 엔드포인트 494개 한 벌로 세 앱을 모두 받고, 결제는 특정 PG사에 종속되지 않도록 추상화 계층을 두어 공급사를 바꿔도 구독 갱신 스케줄러는 건드리지 않습니다. 시간이 걸리는 작업은 큐로 넘겨 요청 경로에서 뺐습니다.
약 135,000 LOC
전문 인력과 발주 기업을 잇는 양면 마켓플레이스
웹과 앱, 백엔드를 동시에 만들면 API가 조용히 두 벌로 갈라집니다. 백엔드를 한 벌로 두고 기능이 아니라 도메인 기준으로 쪼개, 웹 25개와 백엔드 31개, 앱 14개 영역이 같은 경계선을 쓰게 맞췄습니다(테이블 49개, 엔드포인트 327개). 캔버스 디자인 에디터는 브라우저 안에서 돌아야 해서 직접 구현했고, 드래그와 스냅, 작업 취소와 되돌리기, 템플릿 26종, PDF와 이미지와 QR 내보내기까지 이 영역 하나가 약 19,000줄입니다. 인물 이미지 유사도 검색 엔진은 클라이언트에서 직접 부르지 않고 백엔드 프록시로 감싸 호출 키와 조건을 서버에만 남겼습니다. 토큰은 메모리에만 들고 만료되면 자동으로 갱신하되 동시에 몰린 갱신 요청은 줄을 세워 한 번만 실행되게 해서, 앱에서 401이 한꺼번에 터져도 사용자가 로그인 화면으로 튕기지 않습니다.
250개 시군구 / 3,523개 행정동
리테일 입지분석 엔진
전국 입지 점수에서 까다로운 쪽은 모형이 아니라 데이터입니다. 공공데이터 19종은 출처마다 기준이 달라서, 어떤 숫자가 어느 행정동에 속하고 무엇을 뜻하는지부터 합의가 안 됩니다. 수집 커넥터 19개가 재시도와 호출 제한, 페이지 분할을 각각 감당하고 좌표계를 변환해 하나의 행정동 키로 맞춘 뒤에 분석이 시작됩니다. 접근성은 반경 안이면 1, 밖이면 0으로 끊지 않고 거리에 따라 서서히 줄어드는 가우시안 감쇠 커널(σ 4km, 15km 절단)을 얹은 2SFCA와 E2SFCA로 계산했고, 수요가 경쟁 점포로 갈라지는 몫은 Huff 확률선택모형(β 2.0)으로 배분합니다. 축별 가중치는 손으로 정하지 않고 실제 창업과 생존 결과에 맞춰 격자 탐색으로 찾은 뒤 5겹 교차검증으로 과적합을 걸러냈습니다. 자료가 닿지 않는 지역은 추정치로 메우지 않고 중립으로 남기며, 결과는 0에서 100 사이 종합 점수와 보조지표 6개로 나갑니다. 분석 코드는 61개 파일 12,353줄입니다.
코드 1개 / 플랫폼 3개
웹, iOS, 안드로이드로 함께 나가는 가계부 앱
서버와 계정을 두지 않기로 먼저 정하고 설계를 시작했습니다. 기록이 기기 밖으로 나가지 않으면 남의 지출 내역을 보관할 책임도, 계속 띄워 둘 서버도 생기지 않기 때문입니다. 대신 저장소와 파일, 공유 기능은 플랫폼마다 다르기 때문에 화면 코드가 그 차이를 모르도록 실행 시점에 갈라지는 한 겹을 두어, 웹에서는 브라우저 저장소를, 앱에서는 네이티브 저장소를 쓰게 했습니다. 같은 소스를 웹으로 배포하고 Capacitor로 감싸 iOS와 안드로이드에 올렸고, PDF 리포트도 서버를 거치지 않고 기기에서 만듭니다. 한국어와 영어, 일본어 3개 언어를 지원합니다.
브랜드별 테넌트 분리
멀티테넌트 이메일 캠페인 어드민
브랜드가 늘 때 코드를 복사하면 유지보수할 대상도 그 수만큼 늘어납니다. 발신 계정과 발신자 정보, 테마, 로고를 코드가 아니라 데이터로 분리해 요청이 들어오는 시점에 주입하는 구조로 잡아, 브랜드 추가가 설정 등록으로 끝나게 했습니다. 발송은 한 번에 모아 보내지 않고 수신자별로 하나씩 보냅니다. 받는 사람끼리 주소가 노출되지 않고, 건마다 성공과 실패가 따로 남아 일부만 실패했을 때 그 건만 다시 보낼 수 있습니다. 본문 편집기는 외부 라이브러리를 얹지 않고 브라우저 편집 기능 위에 직접 만들어, 실제로 발송되는 메일에 들어갈 HTML을 그대로 통제했습니다. 한글 파일명 인코딩 복구, 엑셀에서 깨지지 않는 CSV, 한국 시간 기준 처리처럼 현업에서 가장 먼저 터지는 지점도 같이 막았습니다.
코드베이스 1개 / 브랜드 다수
멀티브랜드 크리에이티브 스튜디오 사이트
톤이 전혀 다른 브랜드를 한 저장소에 넣으면 스타일과 상태가 서로 새어 나갑니다. 브랜드별로 CSS 적용 범위를 가두고 상태도 브랜드 단위로 분리해, 공유 컴포넌트 28개를 같이 쓰면서도 한쪽을 수정한 것이 다른 브랜드 화면을 건드리지 않게 했습니다. 화면 대부분은 정적 파일로 내보내 CDN에서 바로 내려가고, 문의 폼과 어드민처럼 서버가 꼭 필요한 부분만 요청이 올 때 실행되는 함수로 처리해 평소에 켜 둘 서버가 없습니다. 정적 파일과 그 함수는 같은 도메인 뒤에 두어 브라우저가 외부 호출로 보지 않게 했고, 어드민 로그인에는 비밀번호 해싱과 함께 응답 시간 차이로 계정 존재 여부가 드러나지 않게 하는 처리를 넣었습니다. 지금 보고 계신 이 사이트가 같은 구조입니다.
기업 프로젝트 22건
발주 기업에 납품한 플랫폼 구축
자체 기획물이 아니라 발주를 받아 만들어 넘긴 건수입니다. 쇼핑몰과 모바일 통신판매, 모델과 배우 캐스팅 플랫폼, 세탁과 피부 관리 예약 같은 생활 서비스, 정부 과제 모의심사 시스템, 사내 웹 개발 템플릿, 디자인 서비스 플랫폼이 여기 들어갑니다. 수탁 개발에서 일정이 밀리는 원인은 요구가 바뀌는 것 자체가 아니라, 바뀐 요구를 무엇과 비교해 판단할지가 없는 상태입니다. 그래서 기능 목록과 화면 목록을 문서로 먼저 확정하고 견적과 일정을 그 문서에 붙인 뒤, 이후 변경은 문서를 고치고 늘어난 범위를 같이 계산하는 방식으로 처리했습니다. 요구가 전혀 다른 22건을 공통 템플릿에 끼워 맞추지 않고 각각 별도 제품으로 설계했지만, 거치는 순서는 22건 모두 같았습니다.
업종 8개 영역
업종을 옮겨가며 반복한 구축
커머스, 엔터테인먼트와 캐스팅, 헬스케어, 데이터 분석, 공공과 정부 과제, 미디어, 생활 서비스, 사내 시스템 여덟 영역에 걸쳐 작업했습니다. 영화와 정치인 데이터를 다루는 분석 플랫폼, 의사 매칭, 국제 행사 사이트, 추첨 이벤트와 리뷰어 광고처럼 업무 규칙이 제각기 다른 일이 섞여 있습니다. 처음 접하는 업종에서 위험한 쪽은 기술이 아니라 데이터 모델입니다. 업계가 쓰는 말을 짐작으로 옮기면 테이블 이름부터 틀어지고, 그 오류는 화면을 다 만든 뒤에야 드러나서 되돌리는 값이 가장 비쌉니다. 그래서 착수 전에 실제 그 일을 하는 담당자를 인터뷰해 용어와 예외 처리 규칙을 받아 적고, 그 문서에 적힌 단어를 화면 목록과 테이블 필드 이름에 그대로 씁니다.
기획부터 배포까지 전 공정
반복 구축으로 줄인 일정과 비용
로그인과 권한, 결제 연동, 알림 발송, 운영팀이 쓰는 관리자 화면은 업종이 달라도 구조가 거의 같습니다. 이 축을 매번 새로 짜지 않고 앞선 구축에서 정리해 둔 구조를 가져다 쓰면, 남는 시간을 그 프로젝트에서만 필요한 업무 규칙에 돌릴 수 있습니다. 설계를 전부 끝낸 뒤 착수하면 담당자의 첫 확인이 가장 늦게 들어옵니다. 그래서 동작하는 범위를 먼저 올려 직접 써 보게 하고, 거기서 나온 피드백으로 고쳐 나갑니다. 기한은 먼저 고정하고, 리소스가 빠듯해지면 범위를 그대로 안고 끌지 않고 기능 우선순위를 잘라 쓸 수 있는 선을 맞춥니다. 두 번 손이 가는 작업은 그 자리에서 자동화로 옮겨 다음 건에서 다시 하지 않게 했습니다.
Process
프로젝트마다 다섯 단계를 같은 순서로 밟습니다.
01
Consultation
상담
만들려는 것, 예산, 원하는 일정을 듣습니다. 저희가 맡기에 맞지 않는 일이면 첫 상담에서 말씀드립니다.
02
Planning
기획
기능 목록과 화면 목록을 문서로 만들고, 그 문서를 기준으로 일정과 견적을 확정합니다.
03
Design
디자인
주요 화면을 Figma로 그리고, 확정하실 때까지 수정합니다.
04
Development
개발
확정된 디자인과 기능 목록대로 구현합니다. 작업한 부분은 테스트 서버에 바로 올려서 진행 상황을 아무 때나 확인하실 수 있게 합니다.
05
Launch
런칭
실서버에 올리고 도메인과 모니터링을 연결합니다. 이후 수정 요청과 장애 대응은 계약에서 정한 범위대로 처리합니다.
Team
위 작업은 기획과 설계, 구현까지 내부에서 직접 맡아 진행했습니다. 프로젝트 규모에 맞춰 직군별로 팀을 꾸립니다.
3개발
프론트엔드와 백엔드, 필요하면 모바일까지 나눠 맡습니다. 인원은 범위에 따라 조정합니다.
1디자인
화면 시안과 컴포넌트를 담당하고, 개발 중 생기는 화면 변경까지 끝까지 따라갑니다.
1기획
실제로 쓸 담당자를 인터뷰해 기능과 화면 목록을 문서로 정리하고, 그 문서를 기준으로 범위를 관리합니다.
기획과 디자인, 개발 전 공정을 내부에서 다루기 때문에 외부 인력이 참여한 산출물도 같은 기준으로 검수한 뒤 전달합니다. 상주 인력을 두지 않고 프로젝트별로 팀을 꾸리므로, 맡기에 맞지 않는 일이면 첫 상담에서 말씀드립니다.
기능이 아직 정리되지 않은 단계여도 괜찮습니다. 보내주신 내용을 보고 가능한 범위와 대략의 일정을 정리해 회신합니다.