AI에게 원하는 사이트를 설명하면 예전보다 훨씬 빠르게 첫 화면을 볼 수 있습니다. 문장 몇 줄로 화면을 만들고, 색상이나 구성을 바꾸고, 간단한 기능까지 붙일 수 있습니다. 아이디어를 눈으로 확인하는 데 걸리는 시간이 크게 줄었습니다.
이노자일 사이트를 만들 때도 AI를 적극적으로 활용했습니다. 속도가 필요한 작업에서는 확실히 도움이 됐습니다. 다만 사이트를 실제로 운영하기 시작하자, 처음 화면을 만드는 일과 계속 고쳐 쓰는 일은 조금 다른 문제라는 걸 다시 확인하게 됐습니다.
사이트는 완성된 뒤에도 계속 바뀌었습니다
사이트를 공개한 뒤에는 예상보다 자주 작은 수정이 생겼습니다. 상담 신청서의 항목을 다듬고, 서비스 설명을 고치고, 새 글을 올릴 수 있는 기능을 추가했습니다. 개인정보와 관련된 안내도 실제 운영 방식에 맞춰 계속 살펴봐야 했습니다.
각각은 큰 작업처럼 보이지 않았습니다. 문장 하나, 버튼 하나, 입력 항목 하나를 바꾸는 일이 대부분이었습니다. 그런데 사이트 안의 요소들은 생각보다 많이 연결돼 있었습니다. 상담 버튼의 이름을 바꾸면 다른 화면의 안내 문구도 함께 확인해야 했고, 방문자를 분석하는 기능을 추가하면 관리자 화면에는 적용되지 않는지도 살펴야 했습니다.
처음에는 이런 연결 관계가 만든 사람의 머릿속에 남아 있습니다. 시간이 지나거나 담당자가 바뀌면 그 기억은 금세 흐려집니다. AI로 만든 코드도 마찬가지였습니다. AI는 지금 받은 요청에는 빠르게 답하지만, 몇 달 전에 어떤 이유로 그렇게 정했는지까지 자연스럽게 이어서 기억하지는 못했습니다.
그래서 수정 자체보다 먼저 필요한 일은, 당시의 결정을 다시 확인하는 일이었습니다.
오래된 코드를 읽는 것보다 오래된 결정을 찾는 일이 어려웠습니다
운영 중인 사이트를 수정할 때 가장 궁금한 것은 코드가 어떻게 쓰였는지만이 아니었습니다.
- 이 버튼은 누구를 위해 만든 것인지
- 누르면 어떤 정보가 저장되어야 하는지
- 실패했을 때 사용자는 무엇을 보게 되는지
- 관리자와 방문자 중 누가 볼 수 있는지
- 무엇까지 확인되면 작업이 끝난 것으로 볼지
이런 내용이 남아 있지 않으면, 화면을 보며 처음 의도를 다시 추측해야 합니다. 겉으로는 같은 결과가 나오더라도 처음과 다른 방식으로 고칠 수 있고, 그 차이는 다음 수정에서 문제로 나타나기도 했습니다.
실제로 한 곳을 고친 뒤 다른 화면의 동작이 달라지거나, 예전에 정리한 내용을 반대 방향으로 다시 수정하는 경우가 생길 수 있었습니다. 개발에서는 이렇게 변경 후 기존 기능이 깨지는 일을 회귀라고 부릅니다. 이름은 낯설지만, 사용자의 입장에서는 “전에는 됐는데 지금은 안 되는” 상황입니다.
이 경험 이후에는 AI에게 더 자세히 설명하는 것만으로는 충분하지 않다고 생각하게 됐습니다. 설명을 매번 새로 만드는 대신, 프로젝트가 기억해야 할 내용을 사람이 읽을 수 있는 형태로 남기는 편이 안정적이었습니다.
만들기 전에 몇 가지를 글로 적어 두었습니다
새 기능을 시작할 때 거창한 문서를 만들지는 않았습니다. 대신 화면을 만들기 전에 몇 가지를 먼저 정리했습니다.
먼저 이 기능이 왜 필요한지 적었습니다. 그다음 화면에 무엇이 보여야 하는지, 버튼을 누르면 어떤 일이 일어나는지, 사용자가 중간에 멈추거나 오류가 생기면 어떻게 안내할지를 정리했습니다. 마지막에는 어느 상태까지 확인되면 작업이 끝난 것인지 적었습니다.
예를 들어 진단 기능은 단순히 결과 화면이 보이는 것으로 끝나지 않았습니다. 사용자가 답변을 제출하면 문의 정보가 안전하게 저장되고, 결과가 표시되며, 필요한 안내가 전달되는 과정까지 이어져야 했습니다. 이 흐름을 먼저 적어 두니 개발 중간에 화면 모양이 달라져도 놓치면 안 되는 기준은 유지할 수 있었습니다.
문항, 점수, 안내 문구처럼 자주 바뀔 수 있는 내용은 가능한 한 한곳에 모았습니다. 담당자가 문구 하나를 고치기 위해 여러 파일을 찾아다니지 않도록 하기 위해서였습니다.
이 기록은 AI에게 작업을 맡길 때도 유용했습니다. 무엇을 만들지뿐 아니라 무엇을 지켜야 하는지 함께 알려줄 수 있었습니다. 시간이 지난 뒤 다른 개발자가 참여했을 때는 그 자체가 인수인계 자료가 됐습니다.
기억해야 할 내용은 자동 확인으로도 옮겼습니다
문서는 시간이 지나면 잘 읽히지 않을 수 있습니다. 그래서 반복해서 확인해야 하는 내용은 자동 검사로 옮겼습니다.
사용자가 진단을 시작해 결과를 확인하는 흐름, 상담 신청이 저장되는 과정, 관리자 화면과 방문자 화면이 분리되는지 같은 항목을 실제 사용 순서대로 확인했습니다. 코드의 기본 오류와 화면 속 값의 형태도 함께 검사했습니다.
모든 상황을 자동으로 확인할 수는 없습니다. 문장이 자연스러운지, 서비스의 인상이 적절한지는 결국 사람이 봐야 합니다. 반면 버튼이 눌리는지, 제출한 정보가 저장되는지, 수정 전 기능이 그대로 동작하는지는 반복해서 확인할 수 있습니다. 사람이 판단할 부분과 기계가 반복할 부분을 나누니 수정 후 확인하는 과정도 한결 분명해졌습니다.
화면만 봤다면 지나쳤을 문제도 있었습니다
사이트를 만드는 동안 자동 확인 과정에서 몇 가지 문제가 발견됐습니다.
한 번은 개발 중 화면이 정상적으로 보였지만 실제 배포 과정에서만 오류가 났습니다. 파일을 놓은 위치가 배포 환경의 규칙과 맞지 않았기 때문이었습니다. 문제를 고친 뒤에는 같은 유형을 확인하는 항목을 추가했습니다.
방문자의 이용 흐름을 알아보기 위한 분석 기능이 관리자 화면에서도 작동할 가능성도 발견했습니다. 화면에는 아무런 표시가 없어서 눈으로만 확인했다면 지나치기 쉬운 부분이었습니다. 관리자 영역에서는 작동하지 않도록 범위를 다시 나눴습니다.
영문 주소에서는 열리지만 한글 주소에서는 열리지 않는 글도 있었습니다. 글의 개수가 적을 때는 직접 찾을 수 있지만, 콘텐츠가 늘어나면 매번 모든 주소를 확인하기 어렵습니다. 주소 형식이 달라도 글이 열리는지 검사에 포함했습니다.
성능 점수가 기준 아래로 내려간 적도 있었습니다. 원인은 글꼴 파일이 화면을 보여주는 시점을 늦추고 있었기 때문이었습니다. 불러오는 순서를 조정한 뒤 해당 글 페이지뿐 아니라 다른 화면의 속도도 함께 개선됐습니다.
문제가 전혀 생기지 않게 만드는 것은 현실적으로 어렵습니다. 대신 한 번 발견한 문제를 다음 변경에서도 다시 확인할 수 있게 남겨 두는 것이 운영에는 더 도움이 됐습니다.
새 기능을 붙일 때 차이가 드러났습니다
지금 읽고 있는 인사이트 기능은 사이트를 처음 공개할 때부터 있던 기능이 아닙니다. 운영을 시작한 뒤 추가했습니다.
이미 사용 중인 사이트에 새 기능을 넣을 때는 기존 화면에 영향이 없는지 함께 확인해야 합니다. 글을 작성하고 발행하는 기능을 만들면서도 상담과 진단처럼 이미 운영 중인 흐름을 계속 확인했습니다. 새 기능에 필요한 검사도 같은 과정에 추가했습니다.
운영자가 개발자에게 매번 요청하지 않고 글을 작성할 수 있도록 관리자 화면도 마련했습니다. 검색 결과에 필요한 제목과 설명 등이 빠졌을 때는 발행 전에 알 수 있게 했습니다. 담당자가 모든 규칙을 외우기보다 화면이 필요한 내용을 알려주는 편이 실제 운영에 잘 맞았습니다.
이 과정을 거치며 유지보수가 쉬운 사이트는 코드만 깔끔한 사이트와는 조금 다르다고 느꼈습니다. 처음의 판단이 기록돼 있고, 자주 바뀌는 내용은 운영자가 직접 관리할 수 있으며, 변경 후 확인할 방법이 남아 있는 사이트에 가까웠습니다.
다른 회사의 제안을 볼 때도 비슷한 부분이 눈에 들어옵니다
개발 제안서를 검토하다 보면 기술 이름과 제작 일정은 자세히 적혀 있어도, 완성된 뒤의 운영 방식은 짧게 다뤄지는 경우가 있습니다. 실제로 오래 사용하는 서비스라면 몇 가지가 함께 설명되어 있는지 살펴보게 됩니다.
화면과 기능의 기준을 어떤 형태로 남기는지, 수정 후 기존 기능을 어떻게 확인하는지, 자주 바뀌는 문구와 콘텐츠를 담당자가 직접 관리할 수 있는지, 담당자가 바뀌어도 이어서 운영할 자료가 제공되는지 같은 내용입니다.
모든 프로젝트에 많은 문서와 자동 검사가 필요한 것은 아닙니다. 짧게 사용해 볼 시제품이라면 속도가 더 중요할 수 있습니다. 반대로 고객 정보가 저장되고, 상담이나 결제가 이어지며, 앞으로 기능을 계속 추가할 서비스라면 운영을 위한 준비의 비중이 커집니다.
견적의 차이도 이 지점에서 생기는 경우가 많았습니다. 같은 화면을 만드는 비용처럼 보여도 한쪽에는 화면만 포함되고, 다른 쪽에는 기준을 정리하는 일과 변경 후 확인하는 과정, 운영자가 사용할 관리 기능까지 포함될 수 있습니다. 처음 제안을 비교할 때 이 범위를 함께 보면 금액의 차이를 이해하기가 조금 쉬워집니다.
AI가 빨라질수록 사람이 정할 일은 더 선명해졌습니다
AI를 사용하면서 개발 속도는 실제로 빨라졌습니다. 반복 작업을 줄이고 여러 가능성을 빠르게 확인하는 데 도움이 됐습니다. 동시에 무엇을 만들지, 어떤 상태를 완료로 볼지, 변경으로 무엇이 영향을 받는지는 사람이 정리해야 했습니다.
좋은 결과는 AI를 사용했는지 여부보다 그 앞뒤의 과정에서 갈렸습니다. 처음의 요구를 어떻게 이해했는지, 결정한 내용을 어떤 형태로 남겼는지, 완성된 뒤 누가 어떻게 운영할지를 함께 생각한 프로젝트가 시간이 지나도 다루기 편했습니다.
이노자일 사이트도 앞으로 계속 바뀔 것입니다. 새로운 기능을 붙이고 문장을 고치면서 예상하지 못한 문제도 다시 만날 수 있습니다. 다만 그때마다 처음부터 추측하지 않도록, 알게 된 내용을 기록과 확인 과정에 조금씩 더해 가고 있습니다.