내가 AI로 만든 참고 화면이 실제 제품이랑 다르다고, 개발 이슈(개발자에게 '이걸 고쳐 주세요' 하고 남기는 작업 요청)를 쓴 적이 있다. 근데 적어 둔 파일 여섯 곳 중 세 곳은 실제 제품에 없는 파일이었다. 『강릉, 오늘』에서 내 역할은 기획과 디자인, 그리고 AI 기능이었다. 앱과 서버는 개발자들이 만들었다. 그 사이에서 내가 제일 많이 한 일은 결국 같은 그림을 보게 만드는 일이었고, 이 실수도 거기서 나왔다.
기획서를 먼저 고친다
화면이나 정책을 바꿔야 하면 코드보다 기획서를 먼저 고쳤다. 코드가 기획서를 앞질러 가면, 다음 사람은 거짓말이 된 문서를 보고 일하게 되니까.
기획서에는 버전이 있다. 5월 19일 0.1.0에서 시작해서 지금은 0.169.0까지 왔다. 버전마다 뭘 왜 바꿨는지, 그리고 그 결정을 누가 내렸는지를 적는다. 내가 정한 건지, 실행 결과로 정해진 건지, 앞 버전에서 이어받은 건지 구분해 두면, 나중에 "이거 왜 이렇게 됐지?" 할 때 답이 남아 있다.
요구사항마다 'FR-CARD-8' 같은 번호를 붙였다. 개발 이슈 제목에도 같은 번호를 달아서, 어떤 요구를 구현하는 작업인지 바로 찾을 수 있게 했다. 기획서를 고치면 이 번호를 따라 어떤 이슈가 영향을 받는지도 찾을 수 있다.
화면은 먼저 보고 정한다
글로 쓴 요구사항만으로는 판단이 안 되는 화면이 많았다. 공유 시트처럼 처음 정의하는 화면은 더더욱. 그래서 AI로 참고 구현을 따로 만들었다. 실제 제품이랑은 별개로, 화면을 띄워서 눈으로 보고 판단하려고 만든 앱이다. 피그마(Figma)를 쓸 수도 있었다. 그런데 AI로 바로 화면을 만들 수 있는 지금, 피그마로 그리고, 그걸 다시 옮겨서 개발하는 과정은 비효율로 느껴졌다. 그래서 처음부터 AI로 실제로 움직이는 화면을 만들어 보고 정하는 방식을 택했다. 규칙도 하나 정해 뒀다. 참고 구현의 코드를 고치는 건 화면을 보고 판단하기 위해서지, 실제 기능을 만들려는 게 아니다. 실제 기능은 개발자들이 제품 쪽에서 만든다.
참고 구현이 실제 제품보다 앞서기도 하고 뒤처지기도 하는 건 정상이다. 그래서 참고 구현에서 이상한 걸 봤을 때 "결함"이라고 부르기 전에 실제 제품 코드부터 확인한다는 규칙을 세웠다. 제품에 이미 고쳐져 있으면 참고 구현이 뒤처진 거고, 제품에 아예 없으면 참고 구현이 앞선 거니까 이슈로 넘기고, 양쪽에 다 있을 때만 진짜 결함이다.
이 규칙은 맨 앞에 쓴 그 실수에서 나왔다. 9월 7일, 참고 구현의 파일 경로를 기준으로 개발 이슈를 썼더니 여섯 곳 중 세 곳이 실제 제품에 없는 파일이었고, 한 곳은 빠져 있었다. 개발자가 있지도 않은 파일을 찾게 만든 거다. 그 뒤로 이슈에 적는 경로는 꼭 실제 제품 저장소(제품 코드를 모아 두는 곳) 기준으로 쓴다.
다른 관점으로 한 번 더 본다
만든 쪽이 스스로 확인하면 같은 곳을 놓치기 쉽다. 그래서 중요한 경계에서는 다른 관점으로 한 번 더 봤다. 7월 초에는 앱과 서버 코드를 다섯 갈래로 나눠서 동시에 점검했다. 잘될 때 말고 어긋날 때 무슨 일이 생기는지, 개발 환경에서 되는 게 운영에서도 되는지, 상태가 바뀌는 순서는 맞는지, 실패했는데 화면은 조용한 곳은 없는지, 데이터 규칙은 지켜지는지.
후보 40여 건 중 확정 결함 26건을 찾아서 고쳤다. 제일 위험했던 건 하나씩 보면 작은데 이어지면 큰 사고가 되는 묶음이었다. 실제 사용자에게 나가는 앱 파일(운영용 빌드)에 필요한 설정이 빠져 있던 것, 푸시 알림이 조용히 꺼질 수 있던 것, 약관 동의가 계정이 아니라 기기에 저장되던 것. 7월 말에는 약관과 재동의를 앱이 아니라 서버에서 관리하는 기획을 새로 세웠다.
같은 무렵 서버와 AI가 서로 주고받는 데이터의 모양이 어긋나서, AI가 사용자 반응을 배우는 요청이 매번 실패하던 문제도 찾았다. 이후 주고받는 모양이 맞는지 자동으로 확인하는 테스트를 만들어서, 같은 어긋남이 다시 생기면 바로 드러나게 했다.
됐다고 말하는 기준
제일 자주 다시 배운 건 "됐다"의 기준이다. 이슈가 닫혔다, 배포됐다(사용자 앱에 실제로 반영됐다), 참고 이미지가 붙어 있다. 셋 다 서로 다른 사실이다. 이슈가 닫혔고, 배포됐고, 참고 이미지까지 붙어 있어도, 그 기능이 원래 정한 조건을 다 채웠는지는 따로 확인해야 한다.
그래서 작업 기록은 늘 네 줄로 닫는다. 뭐가 궁금했나, 어떻게 확인했나, 뭘 알았나, 이제 뭘 하나. 확인 못 한 건 확인 못 했다고 쓴다. 안 쓰고 넘어가면 읽는 사람은 확인한 걸로 받아들이니까. 이 네 줄은 지금 그리다꿈의 다른 프로젝트 작업 기록에도 그대로 쓰고 있다.
환경이 없는 회사에서 AX를 만들어 가려면
처음 이걸 시작한 이유로 돌아가 보면, 회사에서 막혔던 건 기술보다 해 볼 수 있는 자리였다. 보안 때문에 테스트로 적용해 보는 것조차 쉽지 않았고, 개발자들을 설득해서 분위기는 바꿔 놨는데 실제 업무로는 잘 이어지지 않았다. 『강릉, 오늘』은 그 자리를 회사 밖에 만든 셈이다.
끝까지 해 보고 나니, 회사로 들고 갈 만한 건 특정 도구보다 일하는 방식 쪽이었다.
- 기획서를 먼저 고친다. AI가 코드를 빨리 만들수록, 기준이 되는 문서가 먼저 서 있어야 다른 사람이 같은 그림을 본다.
- 화면은 제품과 떨어진 곳에서 먼저 본다. 참고 구현은 판단용이고, 실제 제품은 건드리지 않는다. 보안이 까다로운 환경일수록 이렇게 제품과 분리된 자리에서 먼저 보고 정하는 방식이 쓸모 있다고 본다.
- 만든 쪽이 아닌 관점으로 한 번 더 본다. 스스로 확인하면 같은 곳을 놓친다.
- "됐다"를 쪼개서 말한다. 닫힘, 배포, 실제로 확인한 것을 섞지 않는다.
회사 안에서 이걸 그대로 다 할 수 있을지는 아직 모른다. 다만 AI 네이티브(처음부터 AI와 함께 일하는 걸 전제로 짜는) 방식으로 일하고 운영하려면 무엇을 어떻게 해야 하는지는, 이 프로젝트를 하면서 정말 많이 배웠다.