최근 개발 속도가 크게 향상되었습니다. 인공지능을 활용하여 1일 만에 작동하는 결과물을 개발하는 경우도 있고, 코딩 경험이 없는 사람도 화면을 직접 제작할 수 있는 환경이 되었습니다.
이에 따라 다음 질문이 발생합니다. 개발 속도가 빠른 환경에서도 화면 설계가 필요한지에 대한 질문입니다. 기획서와 요구사항을 정리한 후 설계 단계를 추가로 거치는 것을 부담으로 판단할 수 있습니다. 바로 개발하고 문제가 있으면 수정하면 된다고 판단하기 때문입니다.
그러나 설계를 생략한 프로젝트의 실제 결과를 확인하면 판단이 달라집니다.
화면 설계 생략 시 발생하는 문제
개발이 일정 부분 진행된 후 결과물을 최초 확인하는 시점이 있습니다. 이 시점에 다음 의견이 자주 발생합니다.
"이건 제가 생각한 거랑 다른데요."
화면은 있으나 흐름이 상이하고, 기능은 있으나 이용 순서가 상이합니다.
원인은 다음과 같습니다. 기획서에는 개발 대상은 기재되어 있으나 표출 방식과 작동 순서는 기재되어 있지 않기 때문입니다. 이 누락 부분을 개발사가 자체 판단으로 보완한 것입니다. 그 판단이 발주처의 구상과 상이하면 결과물도 상이해집니다.
이 단계에서 문제가 확대되는 이유가 있습니다. 개발 완료 후 화면 변경을 요청하면 화면 1개만 변경되지 않습니다. 화면이 변경되면 데이터 이동 경로가 변경되고, 경로가 변경되면 서버 처리도 변경해야 합니다. 설계서 단계에서 30분이면 완료되는 수정이 개발 후에는 수일이 소요되기도 합니다.
인공지능 활용 환경에서 설계의 중요도 증가
이 부분에서 확인할 오해가 있습니다. 인공지능이 코딩을 대행하므로 설계가 불필요해진 것이 아니라, 설계의 비중이 증가한 것입니다.
기존 방식
개발자가 기획서를 접수하여 누락 부분을 경험으로 보완하고 구현 방식을 판단하면서 설계를 겸했습니다.
현재 방식
인공지능은 그 판단을 대행하지 않습니다. 지시한 내용대로만 개발합니다. 다음에 표출할 화면과 이전 화면으로 이동할 때 입력 내용의 처리 방법을 지정하지 않으면 의도와 다른 결과물을 개발합니다.
따라서 인공지능을 효과적으로 활용하는 개발자는 코딩 전에 서비스의 작동 방식을 우선 작성합니다. 화면 흐름, 기능 간 연결, 데이터 이동 경로를 명확하게 작성한 후 전달합니다.
외주 개발도 동일합니다. 기획서만 전달하면 미기재 부분은 개발사가 자체 판단합니다. 그 판단이 발주처의 의도와 상이하면 결과물이 달라지고 이후 수정 비용이 발생합니다. 설계서로 화면 흐름과 기능 구조를 사전 합의하면 누락 부분이 해소됩니다.
설계 단계의 발주처 확인 사항
설계는 개발사 업무로 인식되지만, 발주처가 반드시 참여해야 하는 부분이 있습니다. 핵심은 두 가지입니다.
설계 단계의 산출물 중 하나가 화면 설계서입니다. 첫 화면부터 목적 달성까지 경유하는 화면과 순서를 작성한 문서입니다. 검토 시 중요한 기준은 디자인의 완성도가 아닙니다. 버튼을 선택하면 이동하는 화면, 단계마다 표출되는 정보, 이전 화면으로 이동할 때의 처리를 확인합니다. 설계서 단계에서 수정하면 연결선 1개만 변경하면 되고, 개발 후 수정하면 코드를 재작성해야 합니다.
설계 과정에서는 기능 추가 요구가 계속 발생합니다. 흐름 작성 중 추가 기능이 지속적으로 검토되기 때문입니다. 그러나 전체를 포함하면 범위가 확대되고 일정이 지연되며 비용이 증가합니다. 첫 버전에 포함할 기능과 나중에 개발할 기능을 정하는 것이 설계 단계에서 가장 중요한 판단입니다. 이 판단은 개발사가 대행할 수 없습니다. 서비스의 핵심 가치를 가장 정확히 파악하는 주체는 발주처이기 때문입니다.
설계 생략 시
기획서 → 즉시 개발 → 결과물 확인 → 의도와 상이 → 수정 반복 → 비용과 일정 초과
설계 후 개발 시
기획서 → 화면 설계와 기능 구조 합의 → 개발 → 결과물 확인 → 의도대로 작동
개발 속도 향상과 방향 설정의 중요성
코드 생성 속도는 계속 향상되고 있습니다. 그러나 속도가 향상될수록 방향 오류 시의 손실도 증가합니다. 빠르게 개발했더라도 의도와 다른 결과물이면 개발 비용 전체가 손실됩니다.
화면 설계는 개발 방향을 확정하는 과정입니다. 사용 도구와 개발 주체와 무관하게 서비스의 작동 방식이 정리되어 있으면 불필요한 작업이 감소합니다.
다만 이 과정을 단독으로 수행하기는 어렵습니다. 화면 흐름 작성은 가능하나, 기술적 누락 여부와 데이터 구조의 적합성을 판단하려면 개발 경험이 필요하기 때문입니다. 발주처가 설계서를 단독으로 완성하기보다 경험 있는 협력사와 공동 작성하는 방식이 현실적입니다.
흐름소프트가 설계 단계에서 협의를 가장 많이 진행하는 이유입니다. 설계서 작성 중 화면마다 다음에 이동할 경로와 첫 버전에 꼭 필요한 기능인지를 함께 정리합니다. 이 과정을 거치면 개발 도중의 방향 변경이 감소합니다.
요약
화면 설계를 생략하려는 판단은 일반적입니다. 즉시 개발이 가능한 환경에서 단계를 추가하는 것이 불필요하게 판단될 수 있습니다. 그러나 설계를 생략한 프로젝트에서는 의도와 다른 결과물이 발생하고, 수정 비용이 설계 단계 대비 수배로 증가하는 상황이 반복됩니다.
코드 작성 속도는 향상되었으나
개발 대상을 정하는 일은 여전히 사람의 업무입니다.
설계는 개발 전에 작동 방식을 확정하는 과정입니다. 이 과정을 거치면 인공지능과 개발사 모두 의도대로 개발할 가능성이 높아집니다.
화면 수가 견적의 근거가 되는 이유는 화면 설계 방법에, 추가 비용이 발생하는 원인은 기획 수준에 따른 견적 차이에 정리했습니다.
자주 묻는 질문
01빠르게 만들 수 있는데 화면 설계가 꼭 필요합니까
필요합니다. 기획서에는 무엇을 만들지는 담기지만 어떻게 보여주고 어떤 순서로 움직이는지는 담기지 않아, 설계 없이 개발하면 만드는 쪽이 빈 곳을 스스로 판단해 채우고 결과물이 생각과 달라집니다.
02개발 후에 화면을 바꾸면 왜 비용이 커집니까
화면이 바뀌면 자료가 오가는 길과 뒤쪽 처리도 함께 바꿔야 하기 때문입니다. 설계서에서 잡았으면 30분이면 끝날 수정이 개발 이후에는 며칠이 걸리기도 합니다.
03AI로 직접 개발할 때도 설계가 필요합니까
오히려 더 중요합니다. AI는 화면 다음에 무엇을 보여줄지, 뒤로 갔을 때 작성하던 내용이 어떻게 되는지를 대신 판단하지 않고 시킨 대로만 만들기 때문에, 설계 없이 기능을 쌓으면 서로 부딪히고 한 곳을 고치면 다른 곳이 깨지는 일이 반복됩니다.
04의뢰자가 설계 단계에서 확인할 것은 무엇입니까
화면 설계서에서 단추를 누르면 어디로 가는지, 단계마다 무엇을 보는지, 뒤로 갔을 때 어떻게 되는지를 확인합니다. 또 첫 판에 넣을 기능과 다음으로 미룰 기능을 정하는 것은 서비스의 핵심을 가장 잘 아는 의뢰자가 직접 판단해야 합니다.