비전공자가 개발자와 잘 소통하는 방법

개발자와의 대화는 기술 시험이 아니다

비전공자가 개발자와 이야기할 때 가장 먼저 내려놓아야 할 부담이 있다. 모든 기술 용어를 알아야 한다는 부담이다. 개발자와 잘 소통한다는 것은 서버, API, 데이터베이스를 전문가처럼 설명하는 일이 아니다. 내가 만들고 싶은 서비스가 누구에게, 어떤 상황에서, 어떤 문제를 해결해야 하는지 분명하게 전달하는 일이다.

개발자는 코드를 쓰기 전에 질문을 한다. "누가 사용하나요?", "언제 이 버튼을 누르나요?", "실패하면 어떻게 해야 하나요?", "관리자는 무엇을 볼 수 있나요?" 같은 질문이다. 이 질문은 귀찮게 하려는 것이 아니다. 사람의 생각을 컴퓨터가 실행할 수 있는 규칙으로 바꾸기 위해 필요한 과정이다.

좋은 협업은 개발자가 모든 것을 알아서 맞히는 방식으로 이루어지지 않는다. 기획자, 대표, 실무자, 디자이너, 개발자가 각자 알고 있는 정보를 꺼내어 같은 그림을 만드는 과정에 가깝다. 비전공자가 할 수 있는 가장 중요한 역할은 기술을 대신 결정하는 것이 아니라, 서비스가 해결해야 할 현실의 문제를 선명하게 설명하는 것이다.

AI 생성 이미지

"이 기능이 필요해요"보다 상황을 설명하기

"예약 기능이 필요합니다"라는 말은 출발점으로는 괜찮지만, 개발을 시작하기에는 부족하다. 예약이라는 단어 안에는 너무 많은 가능성이 들어 있다. 사용자가 직접 예약하는지, 관리자가 대신 입력하는지, 결제가 필요한지, 취소가 가능한지, 같은 시간에 몇 명까지 받을 수 있는지에 따라 완전히 다른 기능이 된다.

더 좋은 설명은 이렇게 시작한다.

사용자는 가게 영업시간 안에서 원하는 날짜와 시간을 선택한다. 이름과 연락처를 입력하면 예약 요청이 생성된다. 사장님이 관리자 화면에서 요청을 확인하고, 확정 또는 거절을 누른다. 확정되면 사용자에게 문자 알림이 간다.

이 설명은 단순히 "예약 기능"이라고 말할 때보다 훨씬 많은 정보를 담고 있다. 사용자가 누구인지, 어떤 순서로 행동하는지, 관리자가 어디에 개입하는지, 결과가 어떻게 전달되는지 알 수 있다.

개발자는 이런 설명을 바탕으로 화면, 데이터, 서버 처리, 알림, 예외 상황을 나누어 생각한다. 사용자는 날짜를 잘못 고를 수도 있고, 같은 시간에 여러 명이 동시에 예약할 수도 있다. 문자가 발송되지 않을 수도 있고, 관리자가 실수로 거절을 누를 수도 있다. 기능의 품질은 이런 상황을 얼마나 미리 이야기했는지에 따라 크게 달라진다.

따라서 요구사항을 말할 때는 기능 이름보다 다음 네 가지를 함께 설명하는 것이 좋다.

• 누가 사용하는가

• 어떤 상황에서 사용하는가

• 무엇을 입력하거나 선택하는가

• 성공하면 어떤 결과가 나와야 하는가

이 네 가지가 있으면 개발자는 훨씬 정확한 질문을 할 수 있다.

화면 예시와 사용자 흐름을 함께 전달하기

말로만 설명하면 서로 다른 그림을 떠올리기 쉽다. "간단한 신청 화면"이라고 해도 어떤 사람은 이름과 전화번호만 있는 화면을 생각하고, 어떤 사람은 회원가입, 약관 동의, 본인 인증, 결제까지 포함된 화면을 생각할 수 있다.

이럴 때 도움이 되는 것이 화면 예시다. 전문적인 디자인 파일이 아니어도 괜찮다. 종이에 그린 그림, 엑셀로 만든 표, 참고 서비스의 캡처, 간단한 메모도 충분히 출발점이 된다. 중요한 것은 예쁘게 그리는 것이 아니라 무엇이 보여야 하고, 사용자가 어디를 눌러야 하며, 다음에 어떤 화면으로 이동하는지를 드러내는 것이다.

사용자 흐름은 사용자가 서비스를 이용하는 순서다. 처음 들어와서 어떤 화면을 보고, 무엇을 선택하고, 어떤 확인을 거쳐, 마지막에 어떤 결과를 받는지를 한 줄로 이어 보는 방식이다.

예를 들어 강의 신청 서비스라면 흐름은 이렇게 정리할 수 있다.

1. 사용자가 강의 목록을 본다.

2. 원하는 강의를 선택한다.

3. 상세 정보와 남은 자리를 확인한다.

4. 신청 버튼을 누른다.

5. 이름과 연락처를 입력한다.

6. 신청 완료 화면을 본다.

7. 관리자에게 신청 내역이 표시된다.

이 흐름이 있으면 대화가 구체적으로 바뀐다. "로그인이 꼭 필요한가요?", "남은 자리는 실시간으로 줄어야 하나요?", "관리자가 신청을 취소할 수 있나요?", "사용자에게 문자나 이메일을 보내야 하나요?" 같은 질문이 자연스럽게 나온다.

질문이 많아지는 것은 프로젝트가 복잡해진다는 뜻만은 아니다. 오히려 나중에 생길 혼란을 앞에서 발견했다는 뜻에 가깝다.

우선순위와 완료 기준 정하기

개발에서 자주 생기는 갈등은 "거의 다 됐다"는 말의 의미가 서로 다를 때 발생한다. 개발자는 주요 기능이 작동한다고 생각하지만, 요청자는 디자인이 다듬어지지 않았거나 관리자 기능이 없어서 아직 쓸 수 없다고 느낄 수 있다.

이 문제를 줄이려면 우선순위와 완료 기준을 미리 정해야 한다.

우선순위는 무엇을 먼저 만들고, 무엇을 나중으로 미룰지 정하는 기준이다. 모든 기능이 중요하다고 말하면 실제로는 어떤 것도 판단하기 어려워진다. 일정이나 비용이 제한되어 있을 때는 반드시 선택이 필요하다.

예를 들어 쇼핑몰을 처음 만든다면 다음처럼 나눌 수 있다.

• 반드시 필요: 상품 목록, 상품 상세, 장바구니, 주문, 결제, 관리자 주문 확인

• 있으면 좋음: 리뷰, 쿠폰, 추천 상품, 적립금

• 나중에 가능: 개인화 추천, 라이브 방송, 복잡한 등급 제도

완료 기준은 "어떤 상태가 되면 이 기능이 끝났다고 볼 것인가"를 정하는 약속이다. 예를 들어 "검색 기능 완료"라는 말보다 아래 기준이 더 명확하다.

• 사용자가 상품명을 입력하면 관련 상품 목록이 표시된다.

• 검색 결과가 없으면 "검색 결과가 없습니다"라는 안내가 보인다.

• 판매 중지된 상품은 검색 결과에 나오지 않는다.

• 모바일 화면에서도 검색창과 결과 목록을 사용할 수 있다.

완료 기준은 개발자를 감시하기 위한 도구가 아니다. 서로 같은 목표를 보고 있는지 확인하는 기준이다. 기준이 명확할수록 테스트도 쉬워지고, 수정 요청도 감정이 아니라 사실을 기준으로 이야기할 수 있다.

개발자에게 물어보면 좋은 질문

비전공자가 좋은 질문을 하려면 기술을 깊이 알아야 한다고 생각하기 쉽다. 하지만 실제로 중요한 질문은 대부분 서비스의 목적과 선택지에 관한 것이다.

다음 질문들은 개발자와의 대화에서 특히 유용하다.

• 이 기능을 만들 때 가장 시간이 많이 걸리는 부분은 무엇인가요?

• 일정이 부족하다면 어떤 기능을 뒤로 미루는 것이 좋을까요?

• 이 방식 말고 더 단순한 대안이 있나요?

• 사용자가 실수했을 때 어떤 문제가 생길 수 있나요?

• 관리자 화면도 필요한가요?

• 어떤 데이터를 저장해야 하나요?

• 개인정보나 보안상 조심해야 할 부분이 있나요?

• 외부 API나 다른 회사 서비스에 의존하는 부분이 있나요?

• 나중에 사용자가 늘어나면 문제가 될 수 있는 부분이 있나요?

• 배포 후 문제가 생기면 어떻게 확인하고 대응하나요?

이 질문들은 개발자에게 "어떻게 코딩할 건가요?"라고 묻는 것이 아니다. 기능의 범위, 위험, 비용, 운영 가능성을 함께 확인하는 질문이다.

특히 "더 단순한 대안이 있나요?"라는 질문은 중요하다. 처음부터 완벽한 기능을 만들려고 하면 비용과 일정이 커진다. 반대로 핵심 문제를 해결하는 작은 버전부터 만들면 실제 사용자의 반응을 보며 개선할 수 있다. 앞에서 살펴본 MVP의 생각과도 연결된다. 작게 만들자는 말은 대충 만들자는 뜻이 아니라, 검증에 필요한 핵심을 먼저 만들자는 뜻이다.

피해야 할 모호한 표현들

개발 협업에서 가장 위험한 말은 겉으로는 쉬워 보이지만 기준이 없는 표현이다.

"그냥 간단하게 해 주세요."
무엇이 간단한지는 사람마다 다르다. 화면이 단순해도 서버 처리나 권한 확인이 복잡할 수 있다.

"알아서 예쁘게 만들어 주세요."
예쁨은 취향의 영역이다. 참고 화면, 브랜드 색상, 우선적으로 보여야 할 정보가 필요하다.

"네이버처럼 만들어 주세요."
큰 서비스의 일부 화면만 보고 말해도 그 뒤에는 검색, 추천, 광고, 계정, 보안, 운영 시스템이 연결되어 있다. 어떤 부분을 참고하고 싶은지 좁혀 말해야 한다.

"나중에 바꾸면 되죠."
물론 많은 것은 바꿀 수 있다. 하지만 데이터 구조, 결제 방식, 권한 체계처럼 나중에 바꾸기 어려운 것도 있다. 변경 가능성과 변경 비용을 함께 물어봐야 한다.

"다 되게 해 주세요."
모든 사용자를 만족시키려 하면 첫 버전이 늦어진다. 먼저 누구의 어떤 문제를 해결할지 정해야 한다.

모호한 표현을 쓰면 개발자가 나쁘게 해석해서 문제가 생기는 것이 아니다. 각자 다른 가정을 한 채 작업이 진행되기 때문에 문제가 생긴다. 좋은 문장은 화려하지 않아도 된다. 대신 확인할 수 있어야 한다.

기술적 한계는 반대 의견이 아니라 정보다

개발자가 "그건 어렵습니다"라고 말할 때, 비전공자는 자신의 아이디어가 거절당했다고 느낄 수 있다. 하지만 많은 경우 그 말은 반대가 아니라 정보 제공에 가깝다.

어렵다는 말 안에는 여러 의미가 있을 수 있다.

• 기술적으로 가능하지만 시간이 많이 걸린다.

• 지금 예산 안에서는 구현 범위가 너무 크다.

• 보안이나 개인정보 위험이 있다.

• 외부 서비스 정책상 허용되지 않는다.

• 사용자가 많아지면 성능 문제가 생길 수 있다.

• 나중에 유지보수가 어려운 방식이다.

따라서 "왜 안 되나요?"라고 따지기보다 "어떤 점이 어려운가요?", "대안은 무엇인가요?", "비용을 줄이려면 어떤 조건을 바꿔야 하나요?"라고 묻는 편이 좋다.

기술적 한계는 아이디어를 줄이는 벽이 아니라 더 나은 선택을 위한 지도다. 모든 것을 한 번에 만들 수 없다면 무엇을 먼저 만들지 정할 수 있다. 특정 방식이 위험하다면 더 안전한 방식을 찾을 수 있다. 외부 API가 불안정하다면 장애가 났을 때의 안내 문구나 대체 흐름을 준비할 수 있다.

좋은 협업에서는 개발자가 현실의 제약을 설명하고, 요청자는 서비스의 목표와 우선순위를 설명한다. 두 정보가 만나야 합리적인 결정이 나온다.

말로 끝내지 말고 기록으로 남기기

회의에서 모두 이해한 것처럼 보여도 시간이 지나면 기억은 달라진다. 그래서 중요한 결정은 기록으로 남겨야 한다. 기록은 거창한 문서일 필요가 없다. 다음 내용만 정리되어도 큰 도움이 된다.

• 만들 기능과 만들지 않을 기능

• 사용자 흐름

• 화면별 필요한 정보

• 우선순위

• 완료 기준

• 보류된 결정

• 변경된 내용과 이유

• 담당자와 확인 날짜

기록이 있으면 나중에 "그때 그렇게 말하지 않았나요?"라는 대화가 줄어든다. 변경이 생겨도 무엇이 바뀌었는지 확인할 수 있고, 일정과 비용에 어떤 영향을 주는지도 판단하기 쉽다.

개발 프로젝트에서 변경은 자연스러운 일이다. 사용자의 반응을 보며 생각이 바뀔 수 있고, 실제로 만들어 보니 더 나은 방식이 보일 수도 있다. 중요한 것은 변경 자체를 막는 것이 아니라, 변경이 생겼을 때 범위와 영향을 함께 확인하는 것이다.

좋은 소통은 결과물의 품질을 바꾼다

개발 지식은 개발자가 되기 위해서만 필요한 것이 아니다. 서비스를 만들고 운영하고 의사결정을 하는 사람에게도 필요하다. 서버가 무엇인지, 데이터베이스가 왜 중요한지, API가 어떤 역할을 하는지, 테스트와 보안이 왜 필요한지 알면 개발자와의 대화가 달라진다.

하지만 가장 중요한 것은 기술 용어를 많이 외우는 일이 아니다. 사용자의 상황을 구체적으로 말하고, 필요한 기능의 우선순위를 정하고, 완료 기준을 확인하고, 기술적 제약을 함께 판단하는 태도다.

좋은 질문과 명확한 요구사항은 개발 결과물의 품질을 바꾼다. 같은 예산과 같은 시간 안에서도 무엇을 먼저 만들지, 어떤 위험을 줄일지, 어디까지를 이번 버전의 목표로 삼을지에 따라 결과는 달라진다.

비전공자는 개발자의 일을 대신할 필요가 없다. 대신 개발자가 올바른 문제를 풀 수 있도록 현실의 맥락을 제공해야 한다. 그것이 개발을 이해하는 가장 실용적인 방법이며, 좋은 서비스를 만드는 출발점이다.