개발사 포트폴리오는 업종이 같은 사례를 찾기보다, 사례 문서에 어떤 설계 판단이 적혀 있는지를 확인하는 편이 업체를 고르는 데 도움이 됩니다.
개발사를 고를 때 업종 경험이 첫 기준인가요?
그렇지 않습니다. 업종이 같아도 방문자가 판단하려는 것과 운영자가 매일 고쳐야 하는 것이 다르면 설계는 달라집니다. 반대로 업종이 전혀 달라도 문제의 모양이 같으면 같은 판단이 반복됩니다.
성공은행이 공개한 사례는 업종이 한쪽에 몰려 있지 않습니다. 스크린 스포츠 창업과 문화예술 협회, 공조 업무 시스템과 인쇄 주문 플랫폼, 사내 광고 아카이브와 산업 부품 쇼핑몰처럼 서로 다른 자리에 있습니다.
그런데도 사례 문서에는 같은 판단이 반복해서 적혀 있습니다. 확인해야 할 것은 같은 업종을 해봤는가보다, 아직 정하지 못한 판단을 다뤄 본 적이 있는가입니다.
업무 규칙을 코드가 아니라 설정으로 두면 무엇이 달라지나요?
규칙이 바뀔 때 개발을 다시 발주해야 하는지가 갈립니다. 판단 기준은 규칙의 복잡도가 아니라 운영을 시작한 뒤에도 그 규칙이 바뀌는지 여부입니다.
네트워크 판매 조직 보상·정산 시스템 사례 페이지는 보상 규칙을 코드가 아니라 정책 데이터로 뺐다고 적고 있습니다. 승급 판정 기준(구독 수·주문 수·누적 매출·조직 인원 수), 커미션 직급 기준, 예외 수당의 지급 단위와 범위, 마감 후 환불 처리, 강등 허용 여부가 관리자 화면의 전략 스위치로 들어가 있습니다.
LVS 산업용 LED 조명 웹사이트 사례는 제품·카테고리·슬라이더·팝업·대리점·인증현황·다운로드·공지·온라인 상담·카탈로그 신청·회원을 각각의 관리자 화면으로 나눠 담당자가 직접 다루게 했습니다.
다만 이 둘은 층이 다릅니다. 콘텐츠를 담당자가 고치는 것과 계산 규칙을 담당자가 고치는 것은 난이도도 비용도 같지 않으므로, 사례 문서에서 어느 쪽인지 구분해 읽습니다.
이미 확정된 기록은 나중에 바뀌어도 되나요?
바뀌면 그 금액과 상태를 상대에게 설명할 수 없습니다. 그래서 사례 문서에서 볼 것은 확정된 기록을 사후에 덮는지, 변경을 앞으로만 적용하고 잘못된 값은 조정 항목으로 바로잡는지입니다.
같은 정산 사례 페이지에 적힌 과제는 규칙을 고쳤다는 이유로 이미 마감한 회차의 금액이 달라지면 회원에게 설명할 수 없다는 것이었습니다. 해결은 배분 정책을 버전으로 관리해 새 버전이 신규 주문부터 적용되게 하고, 마감된 회차는 원본을 지우지 않고 차액 조정 항목으로 처리한 것입니다.
같은 사례에는 회원·주문·커미션·지급·마감·정책·계정 변경과 로그인 실패, 관리자 대행 접속이 감사 로그로 남습니다. 가능한 경우 인증 성공과 실패, 접근 통제 실패를 항상 기록하라고 안내하는 OWASP 로깅 문서도 같은 취지입니다.
돌이키기 어려운 처리 앞에는 무엇을 두나요?
실행 전에 결과를 그대로 보여주는 화면이 있는지 봅니다. 실행한 뒤에 확인하면 연락과 되돌리기가 필요하지만, 실행 전에 보이면 그 자리에서 고칠 수 있습니다.
KORPRINT 온라인 인쇄 주문 플랫폼 사례 페이지에 적힌 과제는 옵션을 고르는 동안 가격이 보이지 않고 파일 문제는 제작 직전에야 드러난다는 것입니다. 해결은 옵션 선택 즉시 금액이 갱신되는 실시간 견적과, 파일의 해상도·색상 모드·도련·폰트 상태를 확인하는 자동검수를 주문 흐름에 넣은 것입니다.
이 사례는 공개 목업 단계이며 표시되는 결제·제작·배송·가격이 합성 데이터라고 스스로 밝히고 있어, 읽을 것은 운영 실적이 아니라 설계 의도입니다. 정산 사례의 분배 미리보기와 분배 시뮬레이션도 실제 데이터에 영향을 주지 않습니다.
중앙솔루션 산업용 하드웨어 쇼핑몰 이관 사례는 DNS 전파가 끝나기 전 며칠 동안 방문자마다 옛 서버와 새 서버로 갈리는 문제를 다룹니다. 옛 서버가 받은 요청을 새 서버로 넘기고, 여섯 개 공용 DNS 리졸버로 전파 완료를 확인하면 그 임시 경로가 스스로 사라지게 했다고 적혀 있습니다. 실행한 뒤에 사람이 손으로 되돌려야 하는 처리는 대개 다음과 같고, 이 목록이 확인 화면을 넣을 자리입니다.
- 이미 지급한 금액
- 마감이 끝난 회차 기록
- 운영 중인 사이트의 서버·도메인 전환
- 외부로 전달한 자료
- 이미 제작에 들어간 결과물
자료를 계정 없이 전달하려면 어떻게 설계하나요?
권한을 계정 단위가 아니라 자료·기간·행위 범위 단위로 끊었는지 봅니다. 한 번 나간 자료는 회수하기 어려우므로 자료가 나가기 전에 범위를 좁혀야 합니다.
신한금융그룹 인쇄광고 아카이브 사례 페이지에는 외부 대행사에 계정을 열어주는 대신 공유 링크를 발급해 자료를 건별로 지정하고 만료일과 비밀번호를 걸며 열람 횟수를 기록한다고 적혀 있습니다. 충남스틸 철강 유통 웹사이트 사례는 견적문의를 작성자와 관리자만 여는 비밀글 게시판으로 두고 목록에는 제목만 남긴다고 기록합니다. 정산 사례는 관리자 대행 로그인을 조회 전용으로 제한합니다.
필요한 최소 범위만 부여하는 편이 낫고 이미 준 권한을 거둬들이는 일이 더 어렵다는 점은 OWASP의 인가 문서도 같은 취지로 안내합니다.
Authorization Cheat Sheet (OWASP Cheat Sheet Series)신한금융그룹 인쇄광고 아카이브 사례충남스틸 철강 유통 웹사이트 사례
포트폴리오는 무엇을 기준으로 읽으면 되나요?
업종이 같은 사례를 찾는 대신, 사례 문서에 앞의 판단들이 실제로 적혀 있는지를 확인합니다. 기능 목록과 화면 이미지만 있는 문서로는 이 판단을 확인할 수 없습니다.
표의 항목이 문서에 없다고 해서 하지 않았다는 뜻은 아닙니다. 다만 적혀 있지 않으면 확인할 방법도 없으므로, 없는 항목은 그대로 질문 목록으로 옮기면 됩니다.
| 확인할 판단 | 문서에 적혀 있는 형태 | 기능 목록만 있는 문서 |
|---|---|---|
| 규칙이 바뀔 때 고치는 사람 | 담당자가 관리자 화면에서 바꾸는 항목이 이름으로 적혀 있습니다 | ‘관리자 기능 제공’처럼 기능 이름만 있습니다 |
| 확정된 기록을 다루는 방식 | 변경을 앞으로만 적용하는지, 원본을 덮는지가 적혀 있습니다 | 수정할 수 있다는 서술에서 끝납니다 |
| 권한을 끊는 단위 | 계정 단위인지 자료·기간·행위 범위 단위인지 구분해 적습니다 | 권한 관리라는 한 줄로 끝납니다 |
| 되돌리기 어려운 처리 앞의 장치 | 실행 전에 결과를 보여주는 미리보기나 검수가 놓여 있습니다 | 실행 버튼과 결과 화면만 있습니다 |
발주 전에 개발사에 무엇을 확인하나요?
기능 목록을 받기보다, 납품 이후에 무엇이 개발 요청으로 남는지를 먼저 확인합니다.
모든 프로젝트가 이 정도의 설계를 필요로 하지는 않습니다. 바뀌는 규칙이 적고 담당자가 직접 고칠 일이 드물면 설정 화면을 늘리는 비용이 더 큽니다. 설정으로 뺄 범위가 넓어질수록 초기 설계 논의도 길어집니다. 판단 기준은 예산 규모가 아니라 잘못 실행됐을 때 손으로 되돌려야 하는 처리가 있는지입니다.
이 목록은 업체를 비교하는 기준이면서, 1차 구축에 넣을 범위와 뒤로 미룰 범위를 나누는 기준이기도 합니다.
- 실행한 뒤 사람이 손으로 되돌려야 하는 처리를 적습니다 — 그 목록이 확인 화면을 넣을 자리입니다.
- 관리자 화면에서 직접 바꿀 수 있는 항목과, 규칙이 바뀌었을 때 재발주 대상이 되는 항목을 나눠 받습니다 — 이 경계를 정하지 않으면 업체마다 다른 범위를 계산합니다.
- 확정된 기록을 나중에 고칠 때의 처리 방식을 확인합니다 — 원본을 덮는지 조정 항목으로 남기는지가 갈립니다.
- 이미 쌓인 데이터를 어디까지 그대로 옮기는지 확인합니다 — 전환 기간 설계는 이 목록에서 시작합니다.
- 밖으로 나가는 자료가 무엇인지, 받는 사람이 조직 안인지 밖인지, 열람 기간을 끊어야 하는지를 정합니다 — 자료가 나간 뒤에는 범위를 좁힐 수 없습니다.
- 누가 무엇을 바꿨는지 남는지 확인합니다 — 기록이 없으면 원인을 찾는 일이 추정이 됩니다.