[현장 업무 앱 만들기] 1편
안녕하세요! AiApp을 만드는 엠바스의 신입 개발자입니다.
우리 서비스로 사무실과 현장이 같이 쓰는 앱을 만들어 봤습니다. 코드는 한 줄도 쓰지 않고 오직 채팅으로만 요청했습니다.
중요하게 생각한 건 개발 용어를 빼고 업무 담당자처럼 채팅을 입력하는 것입니다. 이제 진행 과정을 따라가 보겠습니다.
무엇을 만들지 정하고 첫 요청
현장이 있는 업무를 찾다가 항만에서 화물을 검수하는 일로 정했습니다. 실제 회사가 아니라 가상의 시나리오입니다.
업무 앱과 소개 페이지는 지켜야 할 것이 다릅니다
업무 앱은 소개 페이지와 다릅니다. 매일 열어야 하고 쓸수록 데이터가 쌓입니다. 게다가 사무실과 현장이 같은 자료를 다른 화면으로 봅니다.
사무실에서 쓰는 관리자 사이트가 필요하고 현장에서는 검수원이 단말기로 바코드를 찍는다고 적었습니다. 마지막 줄은 이것입니다. "현장에서 고친 내용은 사무실에서 바로 볼 수 있어야 합니다."
사용 환경은 나뉘어도 데이터는 공유돼야 한다는 뜻인데, 일부러 거기까지는 적지 않았습니다. 숨은 의도를 읽어 내는지 보고 싶었고, 그대로 나온다면 원하는 기능만 말해도 되겠다고 봤습니다.
기획서를 함께 다듬기로
요청을 보내면 선택지가 뜹니다. AI에게 다 맡기기, 그리고 기획서 함께 다듬기.
후자를 골랐습니다. 한 번 보고 나가는 페이지라면 맡겼을 겁니다. 이건 매일 여는 사이트이고 자료가 쌓이니 저장할 것부터 정해야 했습니다.
기능 질문은 두 개였습니다. 현장에서 뭐가 가장 중요한지, 문제를 발견하면 어떻게 처리하는지. 답하자 더 알려줄지 이대로 만들지를 물었습니다. 비워둔 곳을 어떻게 채우는지 궁금해서 그대로 만들어 달라고 했습니다.
'이렇게 이해했어요' 항목마다 출처가 붙어 있습니다
기획서는 개요·화면 구성처럼 여러 부분으로 나뉩니다. 그중 '이렇게 이해했어요' 항목에는 하나하나 출처가 붙습니다. 요청하신 내용·대화로 확정·추측함 셋으로 갈립니다. 내가 한 말과 AI가 채운 말이 구분되니 추측으로 메운 자리가 바로 보입니다. 두 곳이었습니다.
채팅으로 요구 구체화하기
처음에는 막연하게 적었습니다. "다른 건 그 자리에서 고칩니다"라고만 썼더니 두 번을 시도해도 원하는 대로 나오지 않았습니다. 한 번은 체크박스로, 한 번은 문제 종류 고르기로.
고친다는 말만 있고 무엇을 고치는지가 빠진 것입니다. 그래서 다시 썼습니다. 등록된 값이 실물과 다르면 그 값을 실제 값으로 바꿔서 보낸다고 하고, 등록된 크기가 100인데 재보니 120이면 120으로 보낸다는 예를 들었습니다.
이번엔 기획서에 그대로 반영됐습니다.
등록값이 라벨에 적히고 입력창에 미리 채워졌습니다
기획서 항목 수정하기
다음은 '이렇게 이해했어요' 파트입니다. 업무 앱의 뼈대가 되는 부분이고, 여기를 고치면 다른 파트까지 따라 바뀌는지 보고 싶었습니다.
항목에 마우스를 올리면 '이 부분 수정하시겠어요?'가 뜹니다. 눌러서 품명·수량·규격 셋이 아니라 화물 하나당 수십 개 항목을 대조한다고 적었습니다.
바뀐 건 그 항목뿐이었습니다. 저장하는 정보는 그대로였습니다. 이 기능은 해당 항목만 수정할 때 쓰는 것입니다.
그래서 저장하는 정보도 같은 방법으로 하나씩 열어 수정했습니다. 현장에서 다시 재는 건 수량·중량·부피·길이·너비·높이·일련번호·차대번호·모델명이라고 적고, 등록한 값과 잰 값을 따로 남겨 비교할 수 있어야 한다고 썼습니다.
화물 스물여섯 개, 검수 결과 열세 개로 정리됐습니다. 잰 값에는 '실측'이 붙어 등록값과 나뉩니다.
남은 부분도 같은 방법으로 정리했습니다. 큰 흐름은 채팅으로 요청하고, 한 항목만 수정할 때는 '이 부분 수정하시겠어요?'를 썼습니다.
승인하고 첫 화면 확인하기
기획서가 정리되자 다음은 디자인입니다. 분위기와 글씨 느낌 두 가지를 물었습니다. 명확하고 직관적, 견고한 고딕을 골랐더니 색까지 한 벌로 따라왔습니다.
마지막에는 확정한 기획서와 디자인대로 만들지 묻습니다. 이대로 만들기를 누르자 입력창이 잠깁니다. 구현 설계·화면 구현·통합 검증 세 단계가 지나고 화면이 나왔습니다.
첫 화면에서 관리자와 현장을 고르게 되어 있었습니다
첫 화면은 관리자와 현장을 고르는 자리입니다. 사용 환경은 나뉘어도 데이터는 공유돼야 한다고 따로 적지 않았는데, 한 앱 안에서 역할만 갈라지는 구조로 나왔습니다. 기능만 말해도 되겠다고 본 게 맞았습니다.
말을 바꾸자 결과가 달라졌습니다
배운 것은 세 가지입니다. 요구하는 바를 구체적으로 작성합니다. 추상적인 표현 대신 필요한 항목을 나열합니다. 그리고 수정할 대상을 지정해 요청합니다.
여기까지가 이번 편입니다. 나온 결과는 손대지 않고 그대로 뒀습니다.
다음 편에서는 로그인과 계정 만들기를 붙여 보겠습니다.
