AI 활용기: 앱과 서버를 따로 만들었더니 데이터 이름부터 달랐다
표시 날짜는 이 글이 다루는 작업의 대표 기록일이며, 당시 발행된 글을 뜻하지 않습니다. 이후 회고와 적용 방법은 2026년 9월에 정리했습니다.
화면과 서버를 각각 다른 세션에 맡기는 사람에게, 두 결과물이 빌드에 성공해도 실제로 연결되는지는 따로 확인해야 한다는 걸 보여준다.
Focus Relay 서비스에서 회원 식별자를 한쪽은 memberID, 다른 쪽은 member_id로 쓰고 있었다. 9월 2일 CodingKeys를 명시하고 자동 snake_case 변환을 없앤 뒤에야 요청·응답 필드 이름이 맞았다.
앱과 서버를 따로 만들고 있다면 지금 주고받는 JSON 예시 하나를 꺼내 필드명·자료형·필수 여부를 나란히 적어본다.
연재 목차
먼저 답하면
8월 31일에는 서비스 격리 규칙을, 9월 1일에는 Focus Relay·House Ledger·Turnover Crew 세 서비스를 공통 백엔드에 추가했다.
앱과 서버가 각각 빌드됐다고 연결까지 끝나는 것은 아니었다. 백엔드형 앱 프로젝트에서 확인한 수정은 큰 구조보다 JSON 필드 이름에 가까웠다. 같은 회원 식별자가 한쪽에서는 memberID이고 다른 쪽에서는 member_id인 식이다.
이 앱 공장은 동기화와 공유 상태처럼 서버가 필요한 기능을 대상으로 했다. 앱마다 임시 서버를 만드는 대신 공통 백엔드 안에서 서비스별 경계를 나누는 방향이었다. 8월 31일에는 격리 규칙, 9월 1일에는 Focus Relay·House Ledger·Turnover Crew 서비스 추가가 기록됐다.
서로 어떤 이름으로 주고받는지
9월 2일 클라이언트 수정은 서버 JSON 규격에 이름을 맞추는 작업이었다. Focus Relay에서는 회원 식별자와 기기 토큰, 표시 이름을 CodingKeys로 명시했다. 요청 본문에도 display_name과 duration_minutes처럼 실제 전송할 이름을 지정했다. 자동 snake_case 변환을 제거한 변경도 함께 있다.
명시적으로 적으면 코드가 조금 길어진다. 대신 무엇을 보내고 받는지 눈에 보인다. 각 저장소 안에서 맞아 보이는 코드도 서로 다른 가정을 하고 있을 수 있었다.
이 기록만으로 실제 장애가 몇 시간 났다거나 사용자 피해가 있었다고 말할 수는 없다. 확인한 것은 요청·응답 필드 불일치를 정리한 코드 변경이다.
다음에는 앱 화면과 서버 기능을 따로 확인하는 데서 멈추지 않고 요청과 응답 예시를 하나의 기준으로 두려 한다. 앱에서 보낸 값이 서버에 읽히고 응답이 다시 앱 모델로 들어오는지까지 확인하는 것이다.
AI가 각각 맡은 일을 끝냈더라도 사이에 남은 일은 있었다. 이 경우에는 그 빈칸이 거창한 기능이 아니라 필드 이름이었다.
요청과 응답 예시를 계약으로 남기기
앱과 서버를 나눠 만들면 실제 JSON 예시를 공통 기준으로 두는 것이 유용하다. 필드명, 자료형, 필수 여부, 빈 값의 의미를 함께 적는다. 이름이 같아도 숫자와 문자열이 다르면 실패할 수 있다. 값이 없을 때와 빈 문자열일 때를 같은 것으로 처리해도 되는지도 정한다.
검사는 앱이 만드는 요청을 서버가 읽는지, 서버 응답을 앱 모델이 읽는지 양방향으로 한다. 최소한 정상 응답과 누락 필드, 오류 응답 하나씩을 준비한다. 자동 이름 변환을 쓴다면 예외 필드가 변환을 두 번 거치지 않는지도 확인한다.
이렇게 하면 두 구현이 각자 통과했는데 연결에서 실패하는 문제를 좁힐 수 있다. 실제 서비스 데이터 대신 작은 가상 회원과 기기 값을 써도 계약 시험이 가능하다. 인증 정보나 실제 사용자 식별자를 예시 문서에 넣을 이유는 없다.
← 이전 글: AI가 만든 검사기를 일부러 망가뜨려봤다 · 전체 목차 · 다음 글: 로컬 AI 앱은 하나도 만들기 전에 멈췄다 →