IT 기획 직무를 준비하는 취업 준비생의 포트폴리오와 과제 결과물을 함께 점검하다 보면 화면 설계서와 서비스 소개는 상당히 잘 정리되어 있는데, 개발 단계에서 필요한 질문이 들어오면 답변이 갑자기 모호해지는 경우가 있습니다. 예를 들어 회원가입 화면을 기획하고 필수 입력값과 버튼 동작까지 작성했지만, 이미 가입된 이메일이 들어왔을 때 어떻게 처리할지, 인증번호가 만료되었을 때 어떤 화면으로 연결할지, 가입 정보가 서버와 데이터베이스에 어떤 방식으로 저장되는지까지는 정리되지 않은 경우입니다. 화면은 완성되어 있지만 시스템이 실제로 어떻게 동작해야 하는지는 충분히 정의되지 않은 것입니다.
개발자와 협업하는 상황을 가정하면 이런 차이는 더 분명해집니다. 기획서에는 결제 취소 기능 추가라고 한 줄로 적혀 있지만 개발자는 전체 취소인지 부분 취소인지, 이미 배송된 주문도 가능한지, 취소 결과는 어떤 데이터로 저장하는지, 외부 결제 시스템에서 실패했을 때는 어떻게 처리할지를 다시 확인해야 할 수 있습니다. 이 질문에 대한 기준이 없다면 개발자가 요구사항을 다시 정의하게 되고, 구현 이후에도 기획 의도와 실제 기능 사이에 차이가 생길 가능성이 커집니다.
반대로 직접 코드를 작성하지 않더라도 요청과 응답, 화면과 데이터, 사용자 권한, 예외 상황의 기본 구조를 이해하는 기획자는 요구사항을 훨씬 구체적으로 만들 수 있습니다. 개발자가 왜 특정 질문을 하는지도 이해하기 쉬워지고, 구현 난도와 변경 영향을 고려해 우선순위를 조정하기도 수월해집니다. IT 기획자에게 필요한 기술 이해는 개발자처럼 코드를 작성하기 위한 지식이 아니라 요구사항을 구현 가능한 수준으로 정의하고, 시스템의 연결 관계를 이해하며, 여러 직군 사이의 의사소통 오류를 줄이기 위한 기반에 가깝습니다. 이번 글에서는 이를 요구사항, 시스템, 협업 세 가지 기준으로 나누어 정리하겠습니다.
요구사항은 아이디어를 실제 개발 가능한 기능으로 바꾸는 기준입니다
- 좋은 아이디어보다 조건과 범위가 구체적인 요구사항이 필요합니다
IT 기획에서는 무엇을 만들 것인지 정하는 것도 중요하지만 실제 개발 단계에서는 기능이 어떤 조건에서 어떻게 동작해야 하는지가 더 구체적으로 필요합니다. 사용자는 버튼 하나를 누르는 단순한 행동으로 보더라도 시스템에서는 입력값 확인과 데이터 조회, 저장, 오류 처리 등 여러 과정이 동시에 발생할 수 있기 때문입니다.
요구사항을 구체화할 때는 다음 항목을 함께 볼 수 있습니다.
- 사용자가 어떤 행동을 하는지 구분합니다.
- 기능이 실행되기 위한 조건을 확인합니다.
- 필요한 입력 데이터가 무엇인지 정리합니다.
- 정상 처리 이후 어떤 결과가 나타나는지 확인합니다.
- 실패하거나 조건이 맞지 않을 때의 결과를 구분합니다.
- 다른 기능이나 시스템에 영향을 주는 부분이 있는지 살펴봅니다.
예를 들어 비밀번호 찾기 기능을 기획한다면 이메일 입력 화면과 인증 버튼만 정의하는 것으로는 부족할 수 있습니다. 존재하지 않는 이메일을 입력한 경우, 인증번호가 만료된 경우, 여러 번 잘못 입력한 경우, 비밀번호 변경 이후 기존 로그인 상태가 어떻게 되는지까지 요구사항으로 이어질 수 있습니다. 이런 조건이 준비되어 있어야 기획서가 단순 화면 설명에서 개발자가 실제로 구현할 수 있는 기능 정의로 발전합니다.
- 화면 기획과 기능 요구사항은 같은 문서 안에서도 역할이 다릅니다
기획서를 만들 때 화면 구성에 집중하다 보면 기능이 실제로 어떤 조건으로 동작해야 하는지는 상대적으로 약해질 수 있습니다. 화면은 사용자가 보는 결과이고 요구사항은 그 결과를 만들기 위한 시스템의 동작 기준이라는 차이가 있습니다.
- 화면 중심의 설명: 회원은 주문내역 화면에서 취소 버튼을 선택할 수 있습니다.
- 기능 중심의 설명: 취소 가능한 주문 상태에서만 버튼이 노출되고 이미 처리 완료된 주문은 취소할 수 없도록 조건을 구분합니다.
- 데이터까지 연결한 설명: 취소가 완료되면 주문 상태와 결제 상태가 함께 변경되고 변경 시점이 기록되어야 합니다.
- 예외까지 포함한 설명: 외부 결제 취소는 실패했지만 내부 주문 상태가 먼저 변경되는 상황처럼 데이터가 서로 어긋날 수 있는 경우도 고려할 필요가 있습니다.
이처럼 화면만 설명하는 것과 실제 기능의 조건을 정의하는 것은 차이가 있습니다. 기획자가 기술 구조를 기본적으로 이해하면 개발자가 나중에 다시 질문해야 할 조건을 미리 발견하기 쉬워집니다.
- 요구사항에는 정상 흐름뿐 아니라 예외 상황도 포함되어야 합니다
기획 단계에서는 사용자가 정상적으로 행동하는 장면을 중심으로 생각하기 쉽습니다. 하지만 실제 서비스에서는 잘못된 입력, 네트워크 오류, 중복 요청, 권한 부족처럼 정상 흐름에서 벗어나는 상황이 발생합니다.
요구사항을 검토할 때는 다음 내용을 함께 확인할 수 있습니다.
- 필수 입력값이 없는 경우를 구분합니다.
- 이미 존재하는 데이터가 다시 입력되는 상황을 확인합니다.
- 사용 권한이 없는 기능에 접근하는 경우를 고려합니다.
- 외부 시스템 응답이 늦거나 실패하는 상황을 구분합니다.
- 사용자가 같은 요청을 반복하는 경우를 확인합니다.
- 중간 단계에서 처리가 실패했을 때 이전 상태가 어떻게 남는지 살펴봅니다.
예를 들어 사용자가 결제 버튼을 여러 번 누르는 상황을 고려하지 않으면 같은 요청이 반복 전달될 가능성이 있습니다. 개발자가 기술적으로 이를 제어할 수도 있지만 기획 단계에서도 중복 처리 시 어떤 결과가 되어야 하는지 명확한 기준이 있으면 구현 방향이 훨씬 선명해집니다. 좋은 요구사항은 정상 사용자를 위한 흐름만 설명하는 것이 아니라 예상 가능한 문제 상황에서도 서비스가 어떤 결과를 보여줘야 하는지 정의하는 것입니다.
- 기술 이해가 있으면 구현 가능성과 우선순위 판단도 달라집니다
기획자는 새로운 기능을 제안하면서 사용자 가치와 비즈니스 효과를 먼저 생각하게 됩니다. 하지만 실제 개발에서는 기존 시스템과 데이터 구조, 외부 API, 개발 일정에 따라 구현 난도가 달라질 수 있습니다.
- 기술 이해가 부족한 경우: 화면에 버튼 하나를 추가하는 변경이기 때문에 간단한 작업이라고 판단할 수 있습니다.
- 시스템까지 이해한 경우: 버튼 하나가 추가되더라도 새로운 API와 데이터 상태, 외부 서비스 연동이 필요하면 개발 범위가 커질 수 있다는 점을 예상할 수 있습니다.
- 우선순위 판단이 가능한 경우: 모든 기능을 동시에 요구하기보다 필수 기능과 이후 개선 기능을 나눌 수 있습니다.
- 변경 영향을 고려한 경우: 기존 사용자나 기존 데이터와 충돌하는 부분이 없는지 먼저 확인한 뒤 요구사항의 범위를 조정할 수 있습니다.
기획자가 개발 세부 구현까지 결정할 필요는 없지만 어느 변경이 단순한 UI 수정이고 어느 변경이 전체 시스템에 영향을 줄 수 있는지는 이해할 필요가 있습니다. 이 차이가 일정 협의와 기능 우선순위를 결정할 때 중요한 기준이 됩니다.
시스템 이해는 화면 뒤에서 데이터와 기능이 어떻게 연결되는지 보는 기준입니다
- 사용자가 보는 화면과 실제 처리 과정은 구분해서 이해할 필요가 있습니다
사용자에게는 하나의 화면과 버튼으로 보이는 기능도 시스템 내부에서는 여러 구성요소가 연결될 수 있습니다. 기획자가 모든 기술 세부사항을 알아야 하는 것은 아니지만 화면 뒤에서 요청이 어떤 과정을 거치는지를 기본적으로 이해하면 요구사항을 더 정확하게 만들 수 있습니다.
서비스 흐름은 다음과 같이 나누어볼 수 있습니다.
- 사용자가 화면에서 어떤 요청을 보내는지 확인합니다.
- 서버가 어떤 조건을 검증하는지 구분합니다.
- 필요한 데이터를 어디에서 조회하는지 살펴봅니다.
- 처리 결과가 어떤 데이터로 저장되는지 확인합니다.
- 다른 시스템이나 외부 API 호출이 필요한지 구분합니다.
- 최종 결과가 어떤 형태로 사용자에게 전달되는지 확인합니다.
예를 들어 배송조회 화면에서 운송장 번호를 보여주는 기능은 단순 텍스트 출력처럼 보일 수 있습니다. 하지만 실제로는 주문 데이터에서 운송장 정보를 조회하거나 외부 배송사 시스템에서 현재 상태를 가져와야 할 수도 있습니다. 이런 흐름을 이해하면 기능을 기획할 때 화면과 시스템 처리 사이에 필요한 연결 요소를 미리 생각할 수 있습니다.
- API와 데이터베이스를 개발자 수준으로 만들지 않아도 역할은 이해해야 합니다
IT 기획자에게 API 코드를 작성하거나 데이터베이스 쿼리를 직접 만드는 능력이 반드시 필요한 것은 아닙니다. 다만 각각이 어떤 역할을 하는지는 알아야 개발자와 요구사항을 논의하기 쉬워집니다.
- API를 이해하는 수준: 화면이나 시스템 사이에서 필요한 데이터를 요청하고 결과를 전달하는 통로라는 기본 역할을 이해할 수 있습니다.
- 데이터베이스를 이해하는 수준: 사용자와 주문, 상품처럼 서비스에서 관리해야 할 정보가 구조화되어 저장된다는 점을 이해할 수 있습니다.
- 데이터 관계를 이해하는 수준: 한 사용자가 여러 주문을 가질 수 있고 하나의 주문에 여러 상품이 포함될 수 있다는 관계를 서비스 관점에서 이해할 수 있습니다.
- 변경 영향을 이해하는 수준: 새로운 정보를 저장해야 하는 기능이라면 단순 화면 수정만으로 끝나지 않고 데이터 구조에도 영향을 줄 수 있다는 점을 예상할 수 있습니다.
이 정도의 기술 이해만 있어도 개발자의 설명이 훨씬 구체적으로 들립니다. 무엇보다 기획 단계에서 어떤 정보가 필요한데 현재 시스템에 그 데이터가 존재하는지부터 확인하는 사고가 가능해집니다.
- 시스템 흐름을 이해하면 장애와 오류에 대한 기획도 달라집니다
기획자는 정상 화면뿐 아니라 문제가 생겼을 때 사용자가 어떤 안내를 받아야 하는지도 결정해야 합니다. 이때 모든 오류를 서버 오류가 발생했습니다라는 하나의 메시지로 처리하면 사용자가 무엇을 해야 할지 알기 어렵습니다.
오류 상황을 설계할 때는 다음처럼 구분할 수 있습니다.
- 사용자가 잘못된 값을 입력한 상황인지 확인합니다.
- 권한이 없어 접근할 수 없는 기능인지 구분합니다.
- 서버 내부 처리 과정에서 문제가 발생했는지 살펴봅니다.
- 외부 서비스 연결에 실패한 상황인지 확인합니다.
- 잠시 후 다시 시도할 수 있는 문제인지 구분합니다.
- 고객센터나 운영 담당자의 추가 확인이 필요한 경우를 정리합니다.
예를 들어 본인인증 서비스가 일시적으로 응답하지 않는 상황과 사용자가 인증번호를 잘못 입력한 상황은 사용자에게 보여줘야 할 안내도 달라질 수 있습니다. 기획자가 오류 원인의 기술적 세부사항까지 판단할 필요는 없지만 어떤 종류의 실패가 존재할 수 있는지를 시스템 흐름 안에서 이해하는 것은 필요합니다.
- 시스템 이해는 개발자 역할을 대신하기 위한 것이 아니라 질문의 수준을 높이기 위한 것입니다
기술을 공부하다 보면 기획자가 어디까지 알아야 하는지 고민이 생길 수 있습니다. 모든 기술을 깊게 공부하면 개발 직무와 경계가 모호해질 수 있고 반대로 기술을 전혀 모르면 협업 과정에서 기획 의도를 구현하기 어려워질 수 있습니다.
- 기술 이름만 아는 단계: API, 서버, 데이터베이스라는 용어를 들어본 상태입니다.
- 역할을 이해하는 단계: 각각이 서비스에서 어떤 역할을 하고 서로 어떻게 연결되는지 설명할 수 있습니다.
- 질문이 가능한 단계: 필요한 데이터가 기존 시스템에 존재하는지, 외부 API가 필요한지, 특정 변경이 다른 기능에 영향을 주는지를 개발자에게 확인할 수 있습니다.
- 기획에 활용하는 단계: 기술적 제약과 구현 가능성을 반영해 요구사항의 범위와 우선순위를 조정할 수 있습니다.
IT 기획자에게 필요한 기술 이해는 개발자와 같은 수준의 구현 역량이 아닙니다. 개발자가 설명한 내용을 이해하고 필요한 질문을 만들 수 있는 수준이 실무 협업에서는 더 중요합니다.
협업은 기획 의도를 개발 가능한 언어로 연결하는 과정입니다
- 기획자와 개발자는 같은 기능도 서로 다른 기준으로 바라볼 수 있습니다
기획자는 사용자 경험과 비즈니스 목적을 중심으로 기능을 생각하는 경우가 많고 개발자는 구현 조건과 데이터, 시스템 영향까지 함께 봅니다. 어느 한쪽이 더 중요한 것이 아니라 서로 다른 기준을 하나의 결과물로 연결해야 합니다.
협업 과정에서는 다음 차이를 이해할 필요가 있습니다.
- 기획자는 사용자가 왜 이 기능을 필요로 하는지를 설명합니다.
- 개발자는 어떤 조건과 데이터가 필요한지를 확인합니다.
- 디자이너는 사용자가 기능을 쉽게 이해하고 사용할 수 있는지를 봅니다.
- 운영 담당자는 실제 서비스에서 관리 가능한지를 확인합니다.
- 보안 담당자는 접근권한과 정보 노출 위험을 살펴볼 수 있습니다.
- 각 직군의 의견을 요구사항과 우선순위로 다시 연결할 필요가 있습니다.
이 차이를 이해하지 못하면 개발자의 추가 질문을 기획을 어렵게 만드는 질문으로 받아들일 수도 있습니다. 반대로 기술적인 이유만으로 사용자 요구가 사라지는 상황도 생길 수 있습니다. IT 기획의 협업은 한쪽의 의견을 전달하는 역할이 아니라 서로 다른 판단 기준을 하나의 요구사항으로 맞추는 과정에 가깝습니다.
- 좋은 협업은 개발 용어를 많이 사용하는 것보다 질문과 답변이 정확해야 합니다
기획자가 기술적으로 보이기 위해 전문 용어를 많이 사용할 필요는 없습니다. 오히려 의미를 정확하게 이해하지 못한 상태에서 API나 데이터베이스 구조를 임의로 결정하면 개발 과정에서 혼선이 생길 수 있습니다.
- 모호한 협업: 데이터를 API로 연동해 자동으로 처리하면 된다는 식으로 구현 방법까지 추상적으로 제시합니다.
- 목적이 분명한 협업: 사용자가 어떤 정보를 확인해야 하고 해당 정보가 언제 갱신되어야 하는지를 먼저 설명합니다.
- 개발자가 판단할 영역을 남긴 협업: 구체적인 기술 구현 방법은 개발자와 논의하면서 사용자에게 필요한 결과와 필수 조건을 기획자가 명확하게 제공합니다.
- 결정 사항이 남는 협업: 논의 결과 변경된 조건과 예외 상황을 기획 문서에 반영해 이후에도 같은 기준을 사용할 수 있게 합니다.
기술 이해가 필요한 이유는 기획자가 개발 결정을 대신하기 위해서가 아닙니다. 개발자의 설명을 이해하고 기획 의도를 정확한 질문과 조건으로 바꾸기 위해서입니다.
- 변경 요청에서는 한 기능만 보는 것이 아니라 영향 범위를 함께 확인해야 합니다
실제 프로젝트에서는 처음 작성한 기획서가 그대로 끝까지 유지되는 경우보다 개발 과정에서 요구사항이 변경되는 경우가 많습니다. 작은 변경처럼 보여도 다른 화면과 데이터, 일정에 영향을 줄 수 있습니다.
변경이 발생하면 다음과 같은 부분을 함께 살펴볼 수 있습니다.
- 기존 사용자 흐름이 바뀌는지 확인합니다.
- 이미 개발된 기능을 수정해야 하는지 살펴봅니다.
- 새로운 데이터 저장이 필요한지 확인합니다.
- 다른 화면이나 기능에서도 같은 데이터를 사용하는지 구분합니다.
- 테스트해야 할 범위가 얼마나 늘어나는지 확인합니다.
- 전체 일정과 우선순위에 어떤 영향이 있는지 살펴봅니다.
예를 들어 회원등급 기준을 변경하는 요구는 화면의 등급 이름만 바꾸는 것으로 끝나지 않을 수 있습니다. 할인과 쿠폰, 혜택, 관리자 화면처럼 등급 데이터를 사용하는 여러 기능에 영향을 줄 가능성이 있기 때문입니다. 기술 구조를 기본적으로 이해하면 변경 요청을 전달할 때도 무엇이 함께 달라질 수 있는지 고려하는 기획이 가능해집니다.
- 기술 이해가 있는 기획자는 협업 과정에서 의사결정 근거를 더 명확하게 만들 수 있습니다
기획과 개발 사이에서 의견이 다를 때 단순히 사용자에게 필요하다는 이유나 개발이 어렵다는 이유만으로 결론을 내리면 협업이 반복해서 막힐 수 있습니다. 기술 이해가 있으면 서로의 기준을 비교하면서 선택지를 만들기 쉬워집니다.
- 사용자 가치 기준: 반드시 필요한 기능인지, 있으면 좋은 기능인지 구분합니다.
- 개발 난도 기준: 현재 시스템에서 단순 수정인지 큰 구조 변경이 필요한지 확인합니다.
- 일정 기준: 이번 배포에 포함할 수 있는지 이후 단계로 나누는 것이 적절한지 판단합니다.
- 위험 기준: 급하게 적용했을 때 기존 기능이나 데이터에 영향을 줄 가능성을 확인합니다.
- 대안 기준: 전체 기능을 한 번에 개발하기 어렵다면 핵심 기능부터 단계적으로 제공할 수 있는지 논의합니다.
이런 기준을 가지고 대화하면 기획자는 요구사항 전달자가 아니라 여러 조건을 비교해 프로젝트의 방향을 정하는 역할에 가까워집니다. 결국 협업에서 기술 이해의 가치는 어려운 개발 용어를 많이 말하는 데 있지 않습니다. 각 직군의 설명을 이해하고 요구사항, 구현 가능성, 일정과 사용자 가치를 하나의 판단으로 연결하는 것에 있습니다.
- conclusion
IT 기획자가 직접 코드를 작성하지 않는다고 해서 기술을 알 필요가 없는 것은 아닙니다. 다만 필요한 기술의 깊이는 개발자와 다릅니다. 기획자에게 필요한 것은 특정 프레임워크의 문법이나 복잡한 알고리즘을 구현하는 능력이 아니라 자신이 기획한 기능이 시스템 안에서 어떤 과정을 거쳐 동작하고, 어떤 데이터가 필요하며, 문제가 생기면 어떤 예외가 발생할 수 있는지를 이해하는 능력입니다.
요구사항에서는 아이디어와 화면을 개발 가능한 조건으로 구체화할 수 있어야 합니다. 시스템에서는 화면 뒤에서 서버와 데이터, 외부 서비스가 어떻게 연결되는지 기본 흐름을 이해해야 합니다. 협업에서는 개발자가 설명하는 제약과 영향 범위를 이해하고 사용자 가치와 일정, 우선순위를 함께 비교할 수 있어야 합니다. 이 세 가지가 연결되면 기획서는 단순 화면 설계 자료가 아니라 개발과 테스트, 운영까지 이어지는 공통 기준으로 활용될 수 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 기능의 정상 흐름과 예외 상황이 함께 정의되어 있는지 확인합니다.
- 화면에서 사용하는 데이터가 어디에서 오는지 이해하고 있는지 살펴봅니다.
- API와 서버, 데이터베이스의 기본 역할을 구분할 수 있는지 확인합니다.
- 기능 변경이 다른 화면이나 데이터에 영향을 주는지 점검합니다.
- 개발자의 기술 설명을 이해하고 필요한 추가 질문을 만들 수 있는지 살펴봅니다.
- 기획 의도와 구현 가능성, 일정 사이의 우선순위를 판단할 기준이 있는지 확인합니다.
IT 기획 직무 준비 흐름은 다음과 같이 연결할 수 있습니다.
- 사용자 문제 정의 → 기능 목적 설정 → 사용자 흐름 작성 → 요구사항 조건 구체화 → 예외 상황 정의 → 데이터 흐름 이해 → 시스템 구성요소 확인 → 개발 가능성 논의 → 변경 영향 확인 → 기획 문서 수정 → 테스트 기준 연결 → 프로젝트 경험 기록 → 면접 답변 연결.
결국 IT 기획자에게 기술 이해가 필요한 이유는 개발자처럼 코드를 작성하기 위해서가 아닙니다. 사용자의 요구를 개발 가능한 요구사항으로 바꾸고, 화면 뒤에서 시스템이 어떻게 연결되는지를 이해하며, 개발자와 디자이너, 운영 담당자 사이에서 같은 기준으로 의사결정을 하기 위해서입니다. 이 정도의 기술 이해가 갖춰지면 기획 경험도 화면 설계에 머물지 않고 실제 서비스가 만들어지고 운영되는 전체 과정과 연결할 수 있습니다.
