[Week 1 항해 일지] 프롬프트도 못 쓰던 초보가 AI와 협업으로 웹사이트를 고치다

2026년 2월 8일

AI협업초보개발자Week1

출발 전 상황: 막막함의 정점

프롬프트가 뭐죠?

Week 1이 시작되기 전, 나는 AI에게 제대로 된 질문조차 할 줄 몰랐다. “이거 고쳐줘”라는 식의 모호한 요청만 반복했고, 당연히 결과는 엉망이었다.

처음에는 AI가 알아서 문제를 찾아서 고쳐줄 거라고 생각했다. 하지만 실제로는 내가 현재 상태를 설명하지 못하면 AI도 엉뚱한 파일을 보거나, 이미 지나간 구조를 기준으로 답을 내놓았다. 이때부터 내가 배운 첫 번째 규칙은 단순했다. “무엇이 안 되는지”보다 “어디에서, 어떤 결과가 나왔는지”를 먼저 적어야 했다.

chulbuji.com은 이미 페이지가 몇 개 있는 상태였지만, 내가 보기에는 전체 구조가 잘 보이지 않았다. 링크가 어디서 깨지는지, 모바일에서 왜 답답하게 보이는지, 한글과 영어 페이지가 어떻게 연결되어야 하는지, 검색 노출 준비는 무엇부터 해야 하는지 하나씩 확인해야 했다. Week 1은 사이트를 멋지게 만든 주라기보다, 문제를 보고하는 법을 배운 주에 가까웠다.

Week 1 목표: 완벽함 대신 작동하는 것

✅ 링크 깨짐 해결: 404 에러를 먼저 줄이기
✅ 모바일 최적화: 스마트폰에서 글과 메뉴가 읽히게 만들기
✅ 다국어 지원: 한글/영어 전환 흐름 확인하기
⏳ SEO 기본 설정: 검색 노출을 위한 최소 구조 점검하기

목표를 이렇게 나눈 이유는 단순했다. 한 번에 예쁜 사이트를 만들려고 하면 내가 무엇을 확인해야 하는지 놓쳤다. 그래서 링크, 모바일, 언어 전환, SEO처럼 눈으로 확인 가능한 항목부터 쪼갰다. AI에게도 “전체를 고쳐줘”가 아니라 “이 경로에서 404가 나는지 확인해줘”, “모바일에서 이 영역이 밀리는지 봐줘”처럼 작은 단위로 요청하기 시작했다.

학습 내용

1. 프롬프트 작성법

Before: “링크 고쳐줘”

After: “log 폴더의 001-rebrand-launch.html로 가는 링크가 404 에러를 반환합니다. 현재 파일 구조를 확인하고 올바른 경로로 수정해주세요.”

이 차이는 생각보다 컸다. Before처럼 말하면 AI는 내가 어떤 링크를 말하는지, 어떤 페이지에서 문제가 나는지, 파일이 실제로 어디에 있는지 알 수 없다. After처럼 쓰기 시작하자 AI가 먼저 파일 구조를 확인하고, 현재 경로와 기대 경로를 나눠서 설명했다.

처음에는 프롬프트를 길게 쓰는 것이 귀찮았다. 그런데 막상 해보니 긴 문장을 쓰는 일이 아니라, 재현 조건을 적는 일이었다. 어느 페이지에서 눌렀는지, 어떤 URL로 갔는지, 결과가 404인지 화면 깨짐인지 적으면 작업 속도가 훨씬 빨라졌다.

2. 링크와 경로를 보는 법

링크 오류를 고칠 때 가장 헷갈렸던 것은 “파일이 있다”와 “브라우저에서 접근할 수 있다”가 다르다는 점이었다. 로컬 폴더에 파일이 있어도 Astro의 라우팅 구조와 실제 URL이 맞지 않으면 사용자는 404를 만난다.

그래서 Week 1에는 링크를 하나씩 누르고, 실제 생성되는 경로와 내부 링크가 가리키는 경로를 비교했다. 이 과정에서 내가 배운 것은 링크 수정은 감으로 하는 일이 아니라는 점이다. 파일명, slug, 언어별 경로, trailing slash까지 같이 봐야 했다.

3. Git 기본

git status
git add .
git commit -m "Fix broken links"
git push

처음에는 Git 명령어가 전부 무서웠다. 특히 git status를 봐도 어떤 파일을 커밋해도 되는지 바로 판단하지 못했다. 이때부터 작업 전후에 상태를 확인하는 습관을 만들었다. 내가 바꾼 파일과 AI가 건드린 파일을 나눠 보는 것이 중요했다.

한 번에 많은 파일을 고치면 커밋 메시지도 흐려졌다. 그래서 가능한 한 “링크 수정”, “모바일 표시 수정”, “SEO 기본 설정”처럼 작업 단위를 나눠 기록하려고 했다. 아직 능숙하지는 않지만, 커밋은 결과물이 아니라 작업 흔적이라는 느낌을 처음으로 이해했다.

4. 모바일과 다국어 확인

데스크톱에서 괜찮아 보이는 페이지가 모바일에서는 답답하게 보였다. 메뉴가 길어지거나, 제목이 줄바꿈되거나, 버튼 간격이 좁아지는 문제가 있었다. 이때부터 화면이 “보인다”와 “읽힌다”는 다르다는 것을 알게 됐다.

다국어 전환도 마찬가지였다. 한글 페이지와 영어 페이지가 각각 존재하는 것만으로는 부족했다. 사용자가 한글 글에서 영어 글로 이동할 때 같은 주제의 페이지로 가야 하고, 없으면 어색하지 않게 처리되어야 했다. Week 1에서는 완벽한 번역보다 연결이 끊기지 않는 흐름을 먼저 확인했다.

5. SEO를 기술 체크리스트로 보기

SEO는 처음에 너무 큰 단어처럼 느껴졌다. 검색 순위를 올리는 마케팅 작업처럼 보였기 때문이다. 하지만 실제로 시작해보니 첫 단계는 더 기본적인 일이었다. 페이지 제목이 있는지, 설명이 비어 있지 않은지, 사이트맵과 robots 설정이 말이 되는지, 내부 링크가 깨지지 않는지 확인하는 일이었다.

이때 배운 점은 검색 노출 준비도 결국 운영 점검이라는 것이다. 좋은 글을 쓰는 것과 별개로, 검색 엔진이 페이지를 찾을 수 있어야 한다. 그래서 SEO를 “마법 같은 성장 방법”이 아니라 “사이트가 제대로 읽히게 만드는 기본 위생”으로 보기 시작했다.

6. 디버깅 마인드셋

에러 메시지는 적이 아니라 힌트다.

예전에는 에러가 나오면 실패했다고 생각했다. Week 1이 지나면서 에러는 현재 위치를 알려주는 신호에 가깝다고 느꼈다. 404는 링크가 틀렸다는 힌트였고, 모바일 레이아웃 깨짐은 내가 화면 크기를 충분히 고려하지 않았다는 힌트였다. AI에게도 “에러가 났다”가 아니라 에러 메시지와 재현 순서를 함께 줘야 다음 대화가 짧아졌다.

성과 측정

링크 에러: 15개 → 0개
모바일 스코어: 60 → 85
커밋 수: 23개
작동하는 기능: 100%

이 숫자들이 대단한 성과라는 뜻은 아니다. 오히려 첫 주에는 숫자를 정확하게 해석하는 법도 부족했다. 다만 최소한 확인 기준이 생겼다는 점이 중요했다. 링크는 실제로 눌러보고, 모바일은 작은 화면에서 다시 보고, 커밋은 기록으로 남겼다. 막연히 “고친 것 같다”에서 “무엇을 확인했다”로 조금 이동했다.

가장 크게 배운 것

AI와 협업한다는 것은 AI에게 일을 던지는 것이 아니었다. 내가 문제를 관찰하고, AI에게 확인할 범위를 주고, 나온 결과를 다시 검토하는 과정이었다. 처음에는 이 순서가 번거로웠지만, 시간이 갈수록 이 방식이 더 빠르다는 것을 알게 됐다.

또 하나 배운 것은 사이트 운영에는 작은 연결들이 많다는 점이다. 글 하나를 고쳐도 링크, 목록, 모바일 화면, 언어 전환, SEO 메타 정보가 같이 따라온다. Week 1에는 그 연결을 전부 이해하지는 못했다. 그래도 적어도 “한 파일만 보면 끝”이 아니라는 감각은 생겼다.

다음 주 계획

Content Collections 완성
RSS 피드 추가
Sitemap 자동 생성
성능 최적화

다음 주에는 기능을 더 붙이기 전에, 내가 바꾼 것이 사이트 전체에서 어떻게 보이는지 확인하는 시간을 더 가져야겠다. AI에게 더 좋은 답을 받으려면 내가 먼저 더 좋은 상황 설명을 해야 한다.

Week 1 완료. 아직 서툴지만, 이제는 어디서부터 봐야 할지 조금 알겠다.