2026_01_25 소개용 웹 개발일지
소개용 홈페이지 개발일지(스압주의)
또한 본 글은 당시의 채팅 로그, 실제 대화 내용, 통화 내역 등을 바탕으로 하되,
개인을 특정할 수 있는 정보는 모두 제거하거나 간소화하여 작성되었다.
1. 소개
25년 11월 15일~25년 11월 16일
지인이 홈페이지 하나 만들어보지 않겠냐고
카톡이 온다.
엄청 간단하고,
이미지 소스는 요청 하면
상대 쪽에서 제공 해 준단다.
어떤 의뢰고,
누가 의뢰했고,
개발 범위
같은 부분이 오고간다.
다만 지인도,
정확한 정보는 모르는 듯 하다.
의뢰를 맡긴 사람 이름을 보니
아는 사람이다.
25년 11월 17일
내 지인을 통해 처음 의뢰했던,
디자이너로 일하고 있는 대학교 후배에게 연락했다.
후배를 통해 기능·운영 요소에 대한 사전 질의를 진행했다.
개발범위 확인, 개발 방안 구성을 위해
로그인·회원 관리, 게시판 공개 범위,
개인정보 수집 항목 및 약관,
서버·DB 필요 여부 등
요구사항을 비교적 구체적으로 질문했다.
실제로는 리스트를 만들어
세부적으로 물었지만 간략하게 말하면,
"DB는 어떤거 쓰나요?"
,
"서버는 있나요?"
,
"홈페이지에 어떤 기능들이
들어가나요? "
늘 있는 질문들이였다.
단순 프론트 영역과
운영·백엔드가 수반되는 영역을
명확히 분리하기 위한 사전 확인 절차였다.
해당 질의는 프로젝트 시작 이전에 전달되었으며,
가능 범위 내에서 편하게 답변해 달라는 취지로 요청했다.
그러나 돌아온 답변은 전반적으로 명확하지 않고 추상적이었다.
서버가 실제로 존재하는지 여부조차 분명하지 않았고,
구성 중인 핵심 데이터에 대해서는
API를 링크 형태로 전달하겠다는 설명만 있었다.
다만 해당 API가 어떤 방식으로 구성되어 있는지,
어떤 데이터를 전달하는지,
어떤 역할을 하는지에 대한 구체적인 설명은 없었고,
디자이너 역시 이를 명확히 설명하지는 못했다.
결과적으로 당시 제공된 정보만으로는
API의 성격이나 활용 범위를 가늠하기 어려운 상태였다.
이와 관련해 두 차례 정도 추가 대화를 나눈 뒤,
디자이너가 통화를 요청해 왔다.
통화 내용은
디자이너 본인도 잘은 모르고 발주처도 개발자도 아닌 분들이라
대표 측과 직접 미팅을 잡는 것이 어떻겠냐는 제안이었다.
나는 그 요청에 동의했고,
그렇게 발주처 측과 나의 첫 공식 미팅이 이루어지게 되었다.
2.미팅
25년 11월 21일
미팅 전, 나는 혹시 모를 상황에 대비 하여
추가 개발자도 구해뒀었다.
야근 등으로 인해 작업이 지연될 가능성도 있었고,
개인적으로도 실무에서 일정 기간 벗어나 있었기 때문에
모든 부담을 단독으로 감당하는 것은
적절하지 않다고 판단했다.
이에 따라 지인들을 통해
소개 페이지 개발 건이 있으며,
향후 추가개발 가능성도 있다는 점을 공유했고,
관심 있는 분이 있다면 연락을 요청했다.
그 결과, 프론트엔드 개발을 본업으로 하는
회사 동료분의 지인이 참여 의사를 밝혔다.
해당 인력은 백엔드엔드 중심의 개발 경험을 갖추고 있었고,
프론트 영역에 대한 실무 경험도 있어
협업 및 의사소통 측면에서
리스크를 줄일 수 있다고 판단했다.
개발자에겐 미팅 후 세부내용을
진행 여부와 함께 전달 주겠다고 했다.
미팅 시간이 다가올 때 쯤,
나와 디자이너는 프로젝트 내용에
대해 한 번 더 사전 확인이 필요하다고 판단해,
약속 시간보다
약 한 시간 정도 일찍 회사 근처 카페에
도착해 논의를 진행하고 있었다.
해당 시점의 상황과 경과는
비교적 명확하게 기억하고 있다.
주문한 음료도 바닥을 보이고,
대기시간이 길어지면서,
시간을 여러 차례 확인하고 있었기 때문이다.
한참 논의중에 멀리서 두사람이 보였다.
발주처 사람들이였다.
시간을 보니
발주처 측은 미팅 시간에 5~10분 늦게 도착했다.
이때 디자이너가 대표로 소개했던 인물과
제3의 인물이 함께 자리했다.
형식적인 소개 이후 업무 이야기를 시작했는데,
대화를 이어가다 보니 실제로 의사 결정과 발주를 담당하는 쪽은
제 3의 인물인 법무 이사 쪽이라는 점이 드러났다.
디자이너가 말한 ‘대표’는 실질적인 발주자가 아니라
지인 관계에 가까운 인물이었다.
다소 의아했지만,
지인 소개로 연결된 구조였기에
그 시점까지는 그럴 수 있다고 받아들였다.
회의 전반에서는
“업계 표준”
이라는 표현이 반복적으로 사용됐다.
작업 방식, 비용 산정 등 여러 맥락에서 등장했지만
이를 뒷받침할 구체적인 기준이나 문서는 제시되지 않았다.
예시 플랫폼이 있느냐? 라는 질문에
나는
지인 홈페이지 만들어줄 때 썼던
예시 플랫폼을 보여주었고,
발주처 측은 나쁘지 않다는 평과 함께
이전에 다른 쪽에 작업 맡겼었던
홈페이지는 있었다며
웹 브라우저에
주소를 입력하고 이동했다.
그 홈페이지는
내가 만든 예시 보다 더 많은 기능이있다.
'반응형
프로필 홈페이지'
내 홈페이지 레이아웃
성격과도 다르다.
어떤 레이아웃을 선호하는지,
어떤 형태를 원하는지 조차 명확하지 않다.
프로필 형태면 된다고 한다.
간단한 설명과
문의 기능이 있으면 된다한다.
다만 이전 홈페이지랑 비슷하게 가고싶지 않단다.
로그인이나 결제 부분은 선택사항이고
추후 개발이 가능하냐 한다.
심지어 미팅 때만 접근이 됐고, 미팅 이후에는
발주처에서 예시로 보여준 도메인으로 접근이 안됐다.
한참 이야기들이 진행되고 나서,
연락처를 주고 받기 위해,
명함을 꺼내려 했는데
난감한 부분이 있었다.
개인 신분으로
이렇게 기업 상대로 미팅까지 잡고
해본적은 처음이다.
개인적으로 쓸 명함이 없다.
당시 사적인 일에 연관된 직군도 아닌
현 직장 명함을 사용하는 것이
적절하지 않다고 판단해,
잠시 시간을 요청하고
명함을 대체하면서 신분을 증명할
수단을 찾아 보려했다.
예전 다니던 회사 명함,
거래처 명함들,
가족사진만 나올 뿐이였지
사실 처음엔 과거 재직했던,
당시 회사 사정으로 나에게는
업체 명이 다른
여러 개의 명함이 많았다.
그 중 하나라도 전달 하려했다.
하지만 명함을 잡자마자,
이 명함을 사용하는 것 역시
허위 정보를 전달하는 셈이 될 수 있어
적절한 선택지는 아니었다.
앞에서는 나를 바라보며 기다리고 있다.
천천히 하셔된다는 말을 한다.
아무리 찾아도
대신 전달할게 없다.
머쓱해 하며, 어쩔 수 없이
현 직장 명함을 급히 내밀었다.
그 순간
법무 이사로부터
비즈니스 예의에 대한 이야기가 나왔다.
명함 전달 방식이나 사회생활의 기본에 관한 내용이었다.
물론 실수는 했다, 명함 교환 시
앉은 상태로 건낸 실수는 한건 맞으니까.
속으로 그렇게 생각하고 있던 찰나,
유심히 명함을 보던 발주처가
"
OOO 근무하시면
OO지역에 OO본부 있던데...
나 여기
OO 본부 본부장 인가
부장인가?
~~ 경로로
압니다.
"
내 명함 속 소속을 보고 말한 듯하다.
그 대답에 나는
"어..
본부장님이면,
상무님
일텐데요?
"
라며 대답을 흐렸다.
누구라고 이름도 말하지 않는다
누구 아직 계시냐, 이런 질문은 할 수 있다.
발주처 비즈니스와 연관하여
발주처와 현 직장 임원과
이해관계가 있다는 걸,
지금 사적인 계약 체결 상황과
나와는 무슨 상관인가?
가끔 출근에 늦어서 택시를 탈 때도 목적지를 보고
기사님들이 흔히 물어보는
"이야~ 손님 여기 근무하세요?"
난 이 질문도 꺼려한다.
난 그저 손님이고,
목적지가 그 곳 일뿐이고,
직원이여도 말단 직원일 뿐인데
회사 이름 때문에 상황과 관계없는 질문이 많아지거든.
이러한 이유에서도, 현직 명함을 내밀기 싫었다.
이후에도
업무와 직접적인 관련이 없는 개인정보나
사적인 이야기들도 함께 오갔고,
“이제 한 가족이니 프로젝트
외적인 부탁도 드린다”
그 한마디와 함께,
영수증을 건네며 본인들이 소속된 법무법인에
대한 의뢰 경험을 바탕으로 특정 플렛폼 리뷰 작성을 요청받았다.
'나는
가본 적도 ,
의뢰하지 않은
내용을
적어 달라면서 '
그 날 내가 왜 그랬는지는
정확히 기억나진 않지만,
명함과 영수증을
같은 자리에서 둘 다 찍어두었다.
여전히 지우지 않고 보관 중에 있고,
이것 말고도 증명 할 자료는 더 있다.
그리고 만약 지시한 인물과 발주사 측과
당시 이해관계가 없는 인물이라면,
이 미팅 자체가 성립할 수 없었던
상황이다.
후에 디자이너가 말하길, 발주사와 일 할때,
관행적으로 하는 일이라고 말했다.
본인도 처음 소개 받았을 때 했었다고.
그리고 그들이 말한 플랫폼은,
허위 리뷰를 막기 위해 영수증 이나 결제를
증명할 수단이 있어야 리뷰 작성이 가능한 곳이다.
의뢰 내용 자체는 사실이라 하더라도,
연관없는 제 3자에게
그 내용과 영수증이 전달 된다는 사실이
그게 법조인 본인이 아닌
사무직원 혹은 이해관계자를 통해서
전달된다 하더라도, 사실은 변함이 없고,
해당 법무법인에 대한 리뷰가
모두 허위라고 단정하지는 않지만,
구조적으로 리뷰에 대한 신뢰성
및 필자에게 그렇게 강조하던
비밀보호 원칙의 ‘운용 방식’에 있어
신빙성이 낮다고 판단된다..
개인적으로는,
비즈니스를 전제로 한 미팅 자리에서
지나치게 사적인 질문이나,
회사 홍보를 위한 부탁으로 보이는 별도의 요청이
함께 오가는 방식이 적절한지에 대해서는 다소 다른 생각을 가지고 있었다.
다만 그 자리에서 해당 부분을 문제 삼거나
논점으로 확대하지는 않았다.
그럼에도 불구하고 예의에 대한 문제 제기는
발주처 쪽에서 먼저 이루어졌다.
나 역시 불편함은 있었지만,
그 자리에서 이를 문제 삼지는 않았다.
미팅 중에는 다음과 같은 발언도 있었다.
“원래
계약서랑
기능 정의서는
개발자가
써오는 거다.”
이에 대해 겉으로는 수긍하는 답변을 했지만,
그 상황에서 기능 정의서를 먼저 요구하는 방식은
업무 순서상 맞지 않다고 판단했다.
미팅 과정에서 확인 된 것을 한번 더 정리하면,
발주사가
어떤 사업을 기획하고 있고,
세미나에서 사업 아이템을 홍보하기 위한 소개 페이지,
추후 서비스가 가능한 홈페이지가 필요하다는 것,
어떤 DBMS를 사용한다는 정보,
내부 개발자가 있다,
는 정도에 그쳤다.
정작 필요한 실 개발에 필요한
- 홈페이지 레이아웃 구성 세부 요소
- 구체적인 스키마
- 접근 방식
- 연동 범위
- 서버 유무
에 대한 설명은 제공되지 않았다.
그 후 발주사가 말하길.
"발주사 측
내부 개발자는
추진 사업 안
핵심 기술 개발
진행 중 이라,
2차 진행 확정 후
미팅 마련 하겠다고,
그때 세부적인
내용 나누자,
Sonny님이
잘해 주시면,
유지보수까지
맡기고 싶다"
이 과정에서 또 하나 인상 깊었던 점은
상대가 법무 법인에 근무하고 있다는 점이
대화의 톤과 표현 방식에 영향을 주고 있다는 느낌이었다는 것이다.
“구두 계약도
계약인거
아시죠?"
“포트폴리오 사용할 땐
우리 쪽 허락 받고
공개 가능하게
해줄게요.”
“같이하면 커리어에
큰 도움이
될 거다”
웃는 표정에 표현은 부드러웠지만,
확정적인 언급은 피하면서
책임이 될 수 있는 여지는 내 쪽으로 이동하는 흐름이 보였다.
단정할 수는 없지만,
해당 미팅은 일반적인 개발 협의라기보다는
법률적 해석을 염두에 둔 대화 방식으로 느껴지는 순간들이 있었다.
이 미팅을 통해 가장 강하게 든 생각은 하나였다.
이 지점에서 명확한 선을 긋지 않으면
추후 문제가 될 가능성이 높다는 판단이었다.
요구사항 자체보다
표현과 해석, 책임의 방향이 더 중요해
보이는 자리라는 인상이 강했다.
그래서 미팅 과정에서
내 상황 역시 솔직하게 전달했다.
- 개발 실무에서 한동안 거리를 두고 있었다는 점
- 본업이 있어 일정에 제약이 있다는 점
또한 발주처가 선택사항으로 제시한 운영 영역에 대해서는
프론트 개발과 분리해
1차와 2차 계약으로 나누어 진행하자고 제안했다.
이 제안에 대해서는
별다른 이견 없이 수락이 이루어졌다.
사전 질의에 대한 답변이 거의 없고
크게 의미있는 대화가 없는 상황에서 미팅은 끝이났다.
3. 진행
25년 11월 24일 (단톡방 생성)
솔직히 미팅이 끝나도 머릿속이 정리되지 않는다.
지인 개발자와도 의견을 나누려면 뭔가 필요한데,
우리에겐 디자이너가 가지고 있는
사업계획서 하나가 전부 다.
그마저도 추상적인 내용들 뿐.
그래도 프로젝트는 시작이 되었다.
마냥 손 놓고 있을 순 없다.
발주처 말대로 구두 계약도
계약이라면,
시간은 우리편이 아니였다.
한참 프로젝트 돌입하면서
프레임워크는 무엇을 쓸지 누가 어디서부터 어디까지 할지,
참고 플랫폼 조사와 함께 구성원과 이야기하는 중
발주처에서 약속대로 계약서를 써오라고 한다.
초기 신뢰 문제에 대한 우려로 받아들였고,
신뢰 관계를 위해서 작성을 해서 주기로 했다.
25년 11월 25일
그와 더불어 나는 PG 연동부분에 필요한 API 발급 요청을 했다,
이 부분은 2차 개발 착수 여부를 떠나서
PG연동을하려면
발급 절차 중 통신판매사업자 등록 과정이 필수이며,
해당 절차가 길기 때문에,
테스트도 진행 해야하며,
혹시나 일정에 차질 생길 것을 우려하여 요청하였다.
25년 11월 26일 ~ 25년 12 월 06일
초기에는 내가 예전 회사에 다닐 때 사용하던
SI 표준 계약서 양식을 기준으로 참고용 초안을 먼저 전달했다.
여기에는 양측이 균일하게 책임을 보장하는 내용들이 많았다.
- 계약이행보증금 (계약금액의 10% 이내로 정함)
- 과업내용서 발급시기
- 지연이자요율 (연 5%)
- 지체상금요율 (1천분의 0.75)
- 지체상금 한도 (계약금액의 30% 이내로 함)
- 하자담보책임
- 하자보수보증금 (계약금액의 10% 이내로 정함)
- 하자담보책임기간 (1년 이내의 기간으로 정함)
- 하도급 금지 및 승인 조항
- 부정 특약 무효규정
- 과업내용 확정 조항
- 계약 체결 후 상황변동에 대한 협의
- 대금지급 조항
- 이행보증 조항
- 대물변제 금지 조항
- 작업장소 제한 조항
- 관리감독 조항
- 납품 조항
- 수령 및 반품조항
- 검사 조항
- 검사 후 인수 과정 조항
- 계약목적물의 멸실 훼손에 대한 책임조항
- 지체상금 조항
- 품질보증 조항
- 하자보수 조항
- 하자보수보증금 조항
- 지식재산권 조항
- 기술지원 및 교육조항
- 기술자료 제공 조항
- 기술자료 임치조항
- 비밀유지 조항
- 계약의 해제, 해지조항
- 손해배상 조항
- 이의 및 분쟁의 해결관련 조항
그러자 상대 측에서
"계약 금액이
구두로
말한 것과
다르네요"
라는 말을 했다.
금액은 전체 금액 2만원’이 아니라,
장(페이지)당 2만원 기준
소통방식에서
오해로 발생한 일이라고 서로가 합의했다.
금액은 원래 미팅 때 확정했던
금액 그대로 가기로 했다.
그 직후
“SI 계약은
과한 것 같다
금액/
지식재산권/
하자보수보증금
부분만 간단히 정리해서
수정계약(부속합의서)으로
업데이트하면 바로 진행”
는 의견이 나왔고,
그 요구에 맞춰 별도로 계약 양식을 다시 찾아
이번 작업에 맞게 범위를 줄이고
표현을 완화한 계약서를 새로 작성해 다시 전달했다.
이 과정에서 발주처 쪽에서
계약금을 먼저 선 입금 했다.
즉, 처음부터 과한 계약을 밀어붙인 것이 아니라,
상대 요구에 맞춰 계약 형태를 한 단계 낮춰 조정했다.
그럼에도 대금 입금과 함께 계약서 조항은 이후 4~6 차례에 걸쳐 수정됐다.
상대가 요청해 추가·강화되거나 조정된 주요 내용은 다음과 같았다.
- 비밀유지 조항 강화 및 별도 특약 추가 (5년간 유지)
- 포트폴리오 사용 금지 명시 (발주처 승인 시 가능)
- 손해배상 책임 강화 (손해배상 무한대 청구)
- 결과물 범위의 상세 명시 (HTML, 이미지, 피그마 파일 등)
- 운영 환경 및 서버 파일 삭제 의무 명시
- 중재원에서 관할 법원 지정 변경
- 지식재산권 관련 표현 수정
말로는 “SI 계약은 과하다”고 했지만,
조항이 누적·보완되는 과정에서
계약 구조는 결과적으로
일반적인 소개 페이지 용역 계약의 범위를
SI 계약서보다도 상당 부분 확장하는 형태로 변화해 갔다.
이후 정식 법률 자문은 아니었으나,
로스쿨에 재학 중인 지인에게
해당 계약 구조에 대해 의견을 구한 적이 있다.
그 과정에서,
특약 조항이 추가되거나
책임 범위가 확대되는 경우에는
즉시 서명하지 않고,
충분한 검토 기간을 요청한 뒤 서명하는 것이
계약 당사자로서 정당한 권리이자
일반적인 대응이라는 의견을 들었다.
또한 계약 상대방의 지위와 관계없이,
이러한 검토 요청은 부당한 요구가 아니며
거절되어서도 안 되는 절차라는 점을 확인했다.
이 지점부터 나는
이 문제가 단순한 개발 범위의 문제가 아니라,
리스크가 어디로 귀속되고 있는지,
어떤 형태로 다가와 있다는 걸
인지는 했지만,
그때 까지는 심각성이 없었다.
이때까지도
지인소개인데,
작은 프로젝트이고 형식상인 과정일거라,
금방 끝내버릴 일이라 생각했다
조항 수정이 어느정도 마무리 되어갈 때 쯤,
이어서 발주처는 내용이 흡족했는지
“계약서
잘 써두면
나중에
도움이 될 거다”
라는 말을 했다.
하지만, 계약서 잘 써두면 도움이
된다는 말 당시의 내 인식은 달랐다.
그 말들은 책임이 확대되는 구조에 대한 설명이나 보완 없이,
결과만 긍정적으로 포장하는 표현처럼 느껴졌고,
솔직히 말해 실무적인 조언과는 거리감이 있었다.
어쨌거나,
개발은 진행하기로 했으니,
발주처와
세부적인 필요사항을 나누다보니
서버는 제공이 당장 어렵단다.
그러면서 세미나 기간에는
노출을 시켜야한단다.
개발기간 내에는
개발팀 서버를 써야겠단다,
도메인 연결도 해달란다.
'난감하다.'
해당 요청들은 계약서에 명시된 범위를 벗어나는
운영·배포 영역에 해당했으며,
초기 미팅에서도 구체적으로 합의된 사항은 아니었다.
요구는 계속적으로 늘어나는 느낌이지만,
역시 초기 신뢰 관계형성을 위해,
발주처가 말한 세미나 기간에
임시 활용하는 걸
승낙했다.
작업 간 원활한 내부 협업을 위해
역할 분담은 다음과 같이 설정되었다.
역할 정의
개발 (프론트엔드 개발자 · 지인 소개)
- 소개용 정적 웹페이지 프론트엔드 구현
- HTML / CSS / JavaScript 기반 화면 구현
- 디자인 시안을 기준으로 한 UI 반영
- 발주처 요구사항 중 계약 범위 내 기능 구현
- 구조 변경 또는 추가 개발 요청 시
- 기술적 구현 가능 여부 검토
- 작업 범위 산정에 대한 의견 제공
디자인 (디자이너 · 프로젝트 소개자)
- 소개용 웹페이지 디자인 시안 제작
- 레이아웃, 색상, 폰트 등 시각 요소 정의
- 발주처의 디자인 관련 요청 사항 정리
- 디자인 수정 및 보완 작업
나의 역할 (조율 및 운영 관리)
- 프론트 서버 환경 관리
- 도메인 연결 및 테스트 서버 운영
- 긴급 대응 가능한 경미 수정 처리
- 구조 변경·추가 개발 요청을 개발자에게 전달
- 발주처–개발자 간 조율 및 커뮤니케이션 관리
역할 분담에 있어 내가 PM을 맡은이유는
계약서 상 결과물 책임 주체가 본인으로 명시되어 있었고,
실질적인 결과물 품질과 일정 관리에 영향을 주지 않는 범위의
내부 작업 분담에 해당한다고 판단했기 때문이다.
발주처에도 추가 개발자에 대한
말을 굳이 전달하지 않았다.
하청 및 하도급과 같은 금지 조항도 없었으며,
이미 계약 전 구해놓은 인력였고,
지인 개발자 입장에서도 요청이 있었으며,
오해나 불필요한 이의가 발생할 가능성을
최소화하기 위한 판단이기도 했다.
이러한 판단의 배경에는 과거 SI 스타트업 근무 경험에 있었다.
발주자가 요구사항을 제시하는 행위 자체는 정당하지만,
해당 요구가 계약 범위나 역할 정의를 벗어나는 경우
프로젝트 수행에 부정적인 영향을
미치는 사례를 반복적으로 경험해왔다.
특히 중간 전달자인 PM을 거치는 구조에서는,
프로젝트 및 기술 이해도가 충분하지 않은 경우
요구사항이 단순화되거나 일부 맥락이 누락되는 등
전달 과정에서 왜곡이 발생하는 경향이 두드러졌다.
실제로 개발 범위 질의나 기술적 설명 과정에서
이해에 어려움을 보이는 사례도 관찰되었다.
이러한 이유로,
본 프로젝트에서는 디자이너를 PM 역할로 두는 것이
적절하지 않다고 판단했다.
이는 개인의 역량 문제가 아니라,
디자인 역할과 프로젝트 범위·기술 판단을 동시에 수행할 경우
발생할 수 있는 역할 충돌을 고려한 결정이었다.
반대로 PM 없이 발주자의 요구가 개발자에게 직접 전달되는 구조 역시,
요구사항의 범위가 과도하게 확장되거나
개발 부담이 급격히 증가하는 상황을 빈번히 초래했다.
이러한 구조는
결과적으로 납품 품질 저하 또는 프로젝트 방향성 상실로
이어지는 경우가 많았으며,
프로젝트 전반에 중대한 리스크를 남기는 원인이 되었다.
이에 본 프로젝트에서는 동일한 문제가 재발하지 않도록,
계약 책임 주체가 조율과 의사결정을 담당하고
각 참여자의 역할과 책임을 명확히 분리하는 운영 방식을 채택했다.
다만 디자이너가 발주처와
이해관계가 있는 인물이었기 때문에,
일부 지시 사항은 발주처에서
필자에게 직접 전달되지 않고
디자이너를 경유해 전달되는 경우도 있었다.
이는 프로젝트 진행에 중대한 지장을 초래하지는 않았으나,
의사소통 구조상 아쉬운 지점으로 인식되었다.
각자 다 본업이 있던 상황이라,
연락이 그리 잦은 편은 아니였어도,
개발자와 디자이너 모두
신속하고 성실히 기한까지 완료해주었다.
'오히려 내가 못 따라갔던게 더 많았지.'
4. 결말
25년 12 월 07일 ~ 26년 01월 08일
A 프로젝트를 다 마무리할 때 쯤,
세미나에 잘 썼다고, 추가 사이트 개발 건도 맡기겠단다.
기한은 2주 정도고 똑같이 소개 페이지에
몇 가지 형식만 갖추면 된다는 말이였다.
나는 이걸 좋은 신호라 생각했었다.
그러면서 세미나에 써야하니까
도메인 구매 및 연결도 A 프로젝트처럼 진행 해 달라 한다.
하지만 이번엔 나는 조건 수용으로 진행했다.
도메인 구매는 비용 발생 부분이 있고,
기관 및 명의 이전 과정이 필수 이기 때문에,
내가 부담해야하는 영역은 아닌 것 같다고
발주처에서 구매가 어렵다면,
내가 보유한 도메인으로 A 레코드만 추가해서 쓰기로
예를 들면 sonny.co.kr 앞에 blog. 를 붙여쓰는
지금 내 블로그와 같은 형태이다.
이 방식도 솔직하게 껄끄러웠지만
발주처 승낙 과 함께 잘 넘겼다.
B 프로젝트 계약서도 동일 내용으로 작성해 전달했고,
양쪽 서명이 끝났었다.
A/B프로젝트도 잘 마무리했고
한동안 연락이 없었다.
26년 01월 14일
그러다 정산 이슈가 발생했다.
이는 모두 프로젝트 개발 건에 대한 정산이었다.
발주처가 제시한 A 프로젝트 1차 개발 대금 지급 때는
아무 문제도 제기되지 않았다.
내 명의로, 부가세 포함해 정상 지급됐다.
B 프로젝트에서도 같은 조항, 같은 금액, 같은 명의였다.
그러나 같은 조건의 계약서와 서명까지 마친 상태에서
B 프로젝트 대금 지급 시점이 되자,
내가 부가세 적용을 언급하자, 발주처는 계약서를 다시 검토했다.
하지만 그들이 실제로 내민 것은
- 사업자 없는 프리랜서
→ 부가세 미적용, 3.3% 원천징수 - 사업자 있는 프리랜서
→ 공급가액 + 부가세 10%, 세금계산서 발행
발주처는 계약서에 기재된 금액이
세법 상 정당하지 않다는 입장을 밝혔다.
그래서 이전 A 결과물에 부가세만큼의 차액을
B 결과물 대금지급액으로 받는 것으로 합의했다.
'정말 아차 싶었다.'
나 역시 실수가 없었다고
말할 수는 없다.
사업자 등록이 없는 상태에서
부가세 처리에 대한 부분을
계약 초안 단계에서 생각하지 못한 점은
분명 내 판단의 부족이었다.
그럼에도 불구하고,
계약서 작성 당시에는 내가 비사업자인걸 알면서도,
본인들 조항을 추가하겠다며 여러 차례나 수정을 요청해 놓고,
정산 단계에 와서 계약서의 문제점을 제기하는것은
나로 하여금 한 가지 판단을 하게 만들었다.
'이 경우,
계약 자체보다
사후 해석이
더 큰 변수가
될 수 있겠다.'
이 생각이 들 때쯤 한 가지 일이 더 터진다.
페이지에 요금제 하나 추가 해달라며 추가 수정 요청을 한다
그리고 계좌번호로 요금 입금할 수 있게,
실제 서비스 사용할 수 있게 회원가입,
로그인 등 기능 구현을 요청한다.
'갑자기 왜?'
당시에는 명확한 문제 제기로 이어가지는 않았다.
갈등으로 번지지 않기를 바라는 마음이 컸고,
요금제 추가 자체를 사소한 수정으로 판단했기 때문이다.
다만 글을 작성하는 현재 시점에서 당시 상황을 다시 정리해 보면,
해당 요청은 계약상 의무에 해당하지 않았고
약정된 유지·지원 기간 역시 이미 종료된 상태였다.
목적이였던 세미나도 끝난 기간이다.
그럼에도 요금제가 추가되었고,
해당 요금제의 명칭이 ‘기술 검증’으로 설정되어 있었다는 점은
사실로 남아 있다.
이 부분에 대해
구체적인 의도나 목적을 단정할 수는 없으나,
당시 맥락상 여러 해석이 가능하다는 정도의
의문은 남게 되었다.
때문에 발주처가
테스트용 결제기능을
실제 영업에 사용할까 봐
나는 세미나 때와 같이 주의사항도 함께 보냈다.
결제하기 버튼을 눌렀을 때 넘어가는 결제 페이지는
테스트용 API이기 때문에,
실제 결제는 되지 않고 형식상 있는 기능이며,
작동하지 않는다고.
또한
페이지도
회원가입 페이지,
로그인 페이지,
회원 페이지 등
작업 소요가 큰 요소들이 많다고 답변했다.
그러자 발주처 대답은 아래와 같았다
“네 테스트용인건 알고 있구
상반기에 작업을 시작한다고
말씀드렸듯이
추가적인 부분을
시작해야 할 것 같아서요.
결제 페이지는
(만들어지기 전까지 현금 유도)
추후 작업해도 돼요.
회원가입 → 로그인 후 실제 서비스를
이용할 수 있는 부분이 필요합니다.
(페이지도 회원가입 페이지,
로그인 페이지,
회원 페이지 등
작업 소요할 요소)
이 부분을 시작해야
할 것 같은데
대략적인 작업 기간과 준비해야
할 부분을 알려주세요.”
설명하기 어려운 감각이 들었다.
이건 분명 2차 계약 사항에 들어가는 내용들이고,
요구는 늘어나고, 표현은 애매해지고,
책임의 방향이 조금씩 내 쪽으로 모이는 느낌이었다.
이대로 가면 문제가 생겼을 때
문서상 책임이 전부 내게 돌아올 수 있겠다는 감각이 분명해졌다.
그래서 계속 진행할지를 고민하지 않았다.
어디서 멈춰야 하는지를 고민했다.
그 판단 끝에
A 프로젝트 2차 진행안 정리를 시작했다.
하기 싫어서가 아니라,
가능 범위와 책임 경계를 문서로 명확히 남기기 위한 마지막 안전장치였다.
문서를 정리한 뒤, 3자의 시선에서 어때 보이는지,
현 직장에서 일하는 부장님께
자문 삼아 식사 자리에서
A 프로젝트 2차 진행안 관련
문서를 보여드린 적이 있다.
회사 대표직도 해보셨고,
개발 계약 건도 많이 채결했던 분이고,
다른 지식도 빠삭하신 분이였으니까.
그렇게 부장님은 상황을 처음부터 끝까지 훑어보신 뒤,
토씨 하나 빠짐없이 나에게 이렇게 말했다.
“소액 받자고 이 정도로
문서 정리하고,
비사업자가 사업자 인 것처럼
부가세는 왜 붙였으며,
서버 전기세까지 대신
다 써가면서 계약서 니 명의로,
상대가 쓰라는데로
다써주고 이제와서
고민하는 너나,
일회성 용역으로 처리할 일에,
별다른 서비스도
없는 작업에
계약서 쓰자고 하고,
고맙다고 더 챙겨주지는 못할망정
부가세니 뭐니 따지면서
금액을 깎아내리는 저쪽이나,
진짜 가지가지들 한다.
처음 문서 보고 이야기 들었을 때
나는 이게 최소 300만 원 이상 규모의
프로젝트인 줄 알았다.
솔직히 말이 안되잖아,
1차 끝났다고?
그냥 프로젝트에서 손 떼.
너 이거 그냥 넘어가면....
에휴.... 니 알아서 해”
그 말에 나는 멋쩍게 웃기만 했다.
사실 틀린말도 반박 할 말이 없었거든.
다른 친구나 지인들에게도 물었을 때
대부분 비슷한 반응이었다.
그렇게 마음고생을 하길래
돈을 많이 받고 하는 일인 줄 알았다고 했다.
그 말을 듣고 나서야
내가 이 일을 과하게 받아들인 게 아니라는 확신이 들었다.
문제가 된 건 금액의 크기가 아니라,
발주처 요구사항을 초과해 수용한 점과
계약 사항을 명확히 정리하지 못했던
나의 판단,
그리고 그에 비해
지나치게 불균형했던
발주처의 책임 요구와 태도였다.
26년 01월 22일 ~ 26년 01월 23일
5. 전달 및 인수 내용 정리 (사실 관계)
A프로젝트 1차 종료 국면에서 나는
계약 범위에 따른 결과물 인수 절차와 책임 경계를 명확히 하기 위해
전달 대상과 비전달 대상을 문서와 메시지로 반복 안내했다.
5.1 전달한 내용 (계약상 결과물)
- 정적 결과물 파일
- HTML
- CSS
- JavaScript
- 이미지 파일
- 결과물 기준
- 소개용 웹페이지
- 전달 방식
- 지정 이메일로 압축 전달
- 계약 종료 시점에 맞춰 인수 완료
로컬 환경에서 확인이 필요한 경우를 대비해
최소한의 실행 안내도 함께 전달했다.
이는 결과물 검증을 위한 참고 안내이며,
운영 환경 구성이나 지원을 의미하지는 않는다는 점을 명확히 했다.
5.2 전달 대상에서 제외된 내용 (계약 범위 외)
- 서버 OS 설정
- Node.js 런타임 및 버전 관리
- Docker / Nginx / 배포 스크립트
- CI/CD 및 자동 배포 구성
- PG사 테스트/운영 API 키
- 인증 토큰, 시크릿 키
- 세미나용 임시 테스트 서버
위 항목들은 모두 운영 영역에 해당하며,
환경에 따라 동작이 달라질 수 있어,
설정값이 동일하지 않으며,
“파일을 그대로 옮기면 동일하게 동작한다”는
보장을 할 수 없는 영역임을 문서와 카톡으로 반복 설명했다.
5.3 테스트 서버 제공에 대한 정리
테스트 서버는
세미나 시연 목적과 일정상 긴급 요청에 따라
개발자 판단으로 임시 제공된 것이었다.
계약상 의무는 아니었으며,
계약 종료 시점 이후
유지·보안·가용성에 대한 책임은 지지 않음을 명확히 고지했다.
이 시점은 React 및 Node.js 기반 웹 기술 스택과 관련된
보안 취약점(React2Shell, CVE-2025-55182)이
공개된 직후였다.
나는 이 이슈를 개발기간 중에 듣고 이미 인지하고
신속하게 프로젝트 팀원들에게 고지까지 했었다
보안 메뉴얼대로 프레임워크 및 런타임 업데이트
조치는 취했지만,
임시 테스트 서버 특성상 지속적인 보안 책임을 전제로
내 본업의 업무 지원를 위한 서비스도 운영하는 상태에서
더 이상 운영을 이어갈 수 있는 상태는 아니었다.
이에 따라
결과물 인수 완료 후
테스트 서버 및 작업 PC 내 원본 파일은
계약서 조항에 따라 정리·삭제 절차를 진행하겠다는 문서다.
5.4 정리
문서는 전달했다. 검토하겠다는 답변이다.
추가 정리한 문서까지 전달했다.
그러자
“전화 가능할 때 통화 달라”
,
“업계 말 말고 결론만 말해 달라”
는 반응이 나왔다.
그 시점에서 나는
이 문제가 더 이상 기술 설명의 문제가 아니라
사후 해석과 책임 귀속의 문제로 이동하고 있음을 확신하게 되었다.
나는 다음 세 가지 원칙을 일관되게 유지했다.
- 결과물은 계약 범위까지만 전달
- 운영·배포·결제는 별도 영역으로 명확히 분리
- 비전문가도 이해했는지 검증과 함께 전달했음을 고지하고, 더 세부적으로 설명
- 임시 서버 유지로 보안적 이슈사항이 있고, 그에따라 시급히 정리가 필요한 점
- 당시 야근 중이어서 즉각적인 통화는 어려운 상황이었다는 점
결국 발주처는
A안(소개용 정적 페이지)까지만 진행한다고 정리했고,
NDA 조항은 여전히 5년동안 유효하니, 준수 요청드리며,
기타 문의는 법무법인으로 달라는 이야기였다.
그에 따라
나는 결과물 전달과 함께
테스트 서버 및 작업 환경을 정리했다.
업무적으로는 정상 종료였다.
돈은 적었고 몫을 나누니 나는 오히려 손해였다.
하지만 더 큰 리스크를 안고 가지 않은 것이 다행이었다.
조금만 더 갔으면
이건 일이 아니라
법적으로 문제가 제기됐을 가능성이 컸다.
사회는, 아무리 지인 관계라 하더라도
안일하게 접근하면 언제든 큰 문제가 될 수 있다는 사실을
그 동안은 SI 스타트업에서 2년간
근무하던 시절에 간접적으로만 접해왔다.
이번에는 그 경고를
직접 겪으며 확인하게 되었다.
디자이너가, 발주처 측에서
원래는 실력있고, 비교적 일정이 여유로운
대학생을 구하려고 했었다고,
나에게 말해주었다.
저 말이 의미하는게 내가 겪은 상황들과 함께 본다면
많은 생각을 스쳐 지나가게 함은 분명하다.
더 이상 나는 애가 아니다. 나를 보호 해 줄 사람은 나 자신뿐이다.
앞으로는 더욱 조심해야겠다.
이 경험을 통해, 계약은 단순한 형식 문서가 아니라
책임의 범위와 리스크의 상한선을 결정하는
설계 요소임을 분명히 인식하게 되었다.
나 역시 판단이 충분하지 못했던 지점이 있었고,
그 과정을 돌아보는 기록을 누구나
볼 수 있는 공간에 남겨두는 이유도 분명하다.
다시는 같은 실수를 반복하지 않기 위함이다.
또 하나의 이유는,
A안(소개용 정적 페이지) 는 처음부터 공개목적에 둔 사안이며,
필자 도메인과 서버 자원을 사용하여,
발주처가 이미 세미나 자료로 활용했고
별도 접속 제한이 없는 조건에서
불특정 다수에게 공개된 사업 아이디어를,
범용기술을 활용하여 구성한 자동화 사업을
동종 업계 쪽 시장이 적을 뿐 이라는 이유로,
특히 세부 기술이나 구현 방식에 대해
구체적으로 공유된 바가 없는 상태에서,
공개된 추상적 아이디어 자체만을 근거로
해당 아이디어에 대해 비밀유지
의무가 계속 유효하다는 주장에 대해
개인적으로 합리적인 의문을 갖게 되었기 때문이다.
비밀유지 조항이 계속 적용된다는 해석에는
현실적인 검토가 필요하다고 느꼈다.
이러한 해석이 문제의 핵심이었다면,
프로젝트 착수 단계에서 해당 전제와 범위를 보다
명확히 정리했어야 한다고 본다.
그럼에도 이러한 맥락에 대한 정리나 논의 없이,
마무리 과정에서도 비밀유지
조항을 앞세운 접근이 반복되었고,
이는 문제를 정리하기보다는
오해를 키울 수 있는 방식이라고 판단했다.
이 글은 누군가를 비난하거나
분쟁을 확대하기 위한 것이 아니라,
해당 접근 방식이 실질적인 해결책이
되기 어렵다는 점을 기록으로 남기고,
해당 사례를 통해,
발주자와 개발자가 협력 관계, 지인관계에 있을 때조차
조건과 해석에 따라 언제든
상호 협력을 저해하고,
분쟁의 당사자가 될 수 있다는 점을 기록으로 남기고자 했다.
또한 감정적 대응은 절대 도움이 되지 않는다고.
나 개인의 경험에 국한된 이야기가 아니라,
유사한 상황에서 같은 방식의 문제가
반복되지 않기를 바라는 목적에 가깝다.