요청은 짧게, 확인은 꼼꼼하게, 결정은 사람이.

황총무의 실험실은 도구 14개짜리 작은 사이트입니다. 2026년 9월 첫 두 주 동안 이 사이트에 커밋 129건이 쌓였습니다. 기획서를 쓰고, 화면을 그리고, 인터랙션을 붙이고, 저장 공간 구조를 손보고, 배포까지 한 사람이 했습니다. 다만 혼자는 아니었고, 클로드 코드와 둘이서였습니다.

이 글은 그 2주의 기록입니다. 어떤 일을 어떻게 나눠 맡았는지, 실제로 어떤 말로 요청했는지, 어디서 사람이 판단했는지, 그리고 그 과정에서 굳어진 클로드 사용 개념을 정리합니다. 지어낸 사례는 없고, 아래 요청 문장은 그때 실제로 쓴 말 그대로입니다.

역할을 어떻게 나눴나

가장 먼저 정리된 건 역할표였습니다. 프론트 개발자인 제가 하는 일과 클로드가 하는 일이 겹치지 않도록, 단계마다 누가 주도하는지를 정했습니다.

• 기획: 사람이 방향과 우선순위를 정하고, 클로드가 요구사항을 문서와 선택지로 풀어 줍니다. "일반 대회 양식이 필요해"라고 하면 리그·토너먼트·조별 리그 중 무엇이 흔한지 표로 정리해 오고, 고르는 건 사람이 합니다.
• 디자인: 사람이 스크린샷으로 "이게 어색해"를 짚고, 클로드가 여백·글자 크기·정렬을 수치로 맞춥니다. 기존 디자인 시스템(테마 토큰, St 접두어 컴포넌트)을 먼저 찾아 쓰는 게 규칙입니다.
• 화면과 인터랙션: 클로드가 구현하고, 반드시 자동 화면 검사(Playwright)로 폭 3종과 다크 모드를 재고 스크린샷을 남깁니다. 사람은 그 결과를 보고 승인합니다.
• 백엔드: 저장 공간 구조 변경은 클로드가 SQL 파일을 써 두고, 실행은 사람이 백업을 확인한 뒤 직접 합니다. 비밀번호·키는 채팅으로 주고받지 않습니다.
• 배포: 커밋은 클로드가 상세히 남기고, 푸시는 사람이 로컬에서 보고 결정합니다. 이번 2주 동안 푸시 결정은 모두 사람이 했습니다.

실제로 한 일 — 사례 다섯 개

사례마다 세 줄입니다. 요청은 그때 실제로 쓴 말 그대로이고, 처리한 내용은 클로드가 한 일, 배운 점은 사람이 얻은 것입니다. 요청은 대부분 한 줄이고 개발 용어가 없습니다.

1. 레이아웃 전체 점검

요청: "전반적인 레이아웃 둘러보면서 틀어지거나 이상한 부분 체크해서 고쳐줘."

처리한 내용: 화면 26개를 세 가지 폭(1280·945·390)과 다크 모드로 열어 가로 넘침, 같은 줄 카드 높이 어긋남, 글자 잘림, 겹침을 자동으로 재고 스크린샷 108장을 남겼습니다. 어긋남 13건이 나왔고, 11건을 고쳤으며 2건은 의도된 것으로 두었습니다.

배운 점: 945px는 제가 늘 쓰는 창 크기였는데 검사 대상에 없었습니다. 그 폭에서 본문이 540px로 줄어드는 오래된 규칙이 걸려 있었고, 이후로 검사 폭에 945를 넣었습니다. 검사 기준은 사람의 실제 환경에서 나옵니다.

2. 링크 공유 이미지 개편

요청: "링크 공유하면 이렇게 이미지 뜨잖아, 디자인 좀 더 예쁘게 수정해줘라." (카카오톡에 링크를 붙였을 때 뜨는 그림)

처리한 내용: 이미지 16장을 표준 크기(1200×630)로 다시 만들고, 한글 폰트를 직접 실어 어떤 환경에서도 같은 모양이 나오게 했습니다. 빠져 있던 서비스 4개의 이미지를 추가했고, 미리보기 제목이 사이트 기본 문구로 나오던 것도 서비스 이름으로 바꿨습니다.

배운 점: 한 줄 요청 뒤에 실제로는 크기 규격, 폰트, 빠진 페이지, 메타 정보 네 가지 일이 숨어 있었습니다. 클로드가 그걸 펼쳐서 보여 주면, 사람은 펼쳐진 목록을 보고 빼거나 더할 것을 정하면 됩니다.

3. 테니스 일반 대회 양식

요청: "보통 대회나 토너먼트로 쓰는 양식 기준으로 노멀한 걸 만들 수 있는 신규 양식도 만들어 줄 수 있어?"

처리한 내용: 먼저 설계 문서를 쓰고, 대진 생성 규칙(리그·토너먼트·조별 리그, 부전승, 시드 교차 배치)을 표본 입력 세 가지로 실행해 경기 수를 검증한 뒤 구현했습니다. 구현 뒤에는 별도 검토 담당이 코드를 읽어 문제 7건을 찾았고, 그중 하나는 결선 점수가 엉뚱한 팀에 붙을 수 있는 실제 결함이었습니다. 모두 반영한 뒤 커밋했습니다.

배운 점: 만드는 쪽과 검토하는 쪽을 나누면 결함이 잡힙니다. 같은 대화 안에서 스스로 검토하게 하지 않고, 아무것도 모르는 검토자에게 새로 읽게 하는 게 핵심입니다.

4. 경조사비 장부 정리

요청: "입력이랑 전체내역이랑 탭으로 분리해줘" → "불필요한 보더라인 제외하고 가독성 높이고 폰트 사이즈 조정도 해줘" → "주고받음 내역에서도 테이블 정렬이 안 맞아" → "냈음 표기하고 금액 미기록 부분은 수정할 수 있게 해줬으면 해." (여러 번에 걸쳐 짧게)

처리한 내용: 입력과 전체 내역을 탭으로 나누고, 카드 안 테두리를 걷어내고 글자 크기 체계를 세웠으며, 대조 표를 실제 표 구조로 바꿔 열을 맞췄습니다. 그 다음 '냈음' 표시에 금액과 날짜를 적는 기능을 붙였습니다. 화면 정리와 새 기능이 섞여 있어, 같은 파일을 둘이 동시에 고치지 않도록 작업을 순서대로 줄 세웠습니다.

배운 점: 요청이 짧아도 괜찮습니다. 대신 하나씩 확인하고 다음으로 넘어가는 리듬이 중요합니다. 한 번에 다 말하면 무엇이 어긋났는지 찾기 어려워집니다.

5. 내가 만든 실수를 클로드가 찾은 날

요청: "헤더 쪽 왜이래?" (짧은 화면에서 푸터를 맨 아래에 붙이려고 화면 전체를 세로 정렬로 바꾼 다음 날, 헤더가 가운데 작은 상자로 쪼그라들어 있었습니다.)

처리한 내용: 원인은 전날 수정의 부작용이었고, 헤더가 전체 폭을 쓰도록 바로 고쳤습니다. 그런데 같은 원인으로 도구 페이지 본문도 절반 폭으로 줄어 있었고, 이 두 번째 문제는 제가 아니라 다른 작업을 하던 클로드가 스크린샷을 찍다 발견해 알려 왔습니다. 그것도 같은 방식으로 고쳤습니다.

배운 점: 전역에 손대는 수정은 반드시 다른 화면에서 다시 봅니다. 그리고 실수의 원인이 사람이든 클로드든, 커밋 기록에 '왜 이렇게 됐는지'를 남겨 두면 되돌리기가 쉽습니다.

클로드를 잘 쓰는 개념 — 여섯 가지

2주 동안 굳어진 원칙입니다. 도구 사용법이 아니라 일하는 개념에 가깝습니다.

• 요청은 결과로 말한다: "그리드를 플렉스로 바꿔"보다 "세 막대가 같은 위치에서 시작하게"가 낫습니다. 방법은 클로드가 고르고, 사람은 결과를 봅니다.
• 스크린샷이 가장 좋은 명세다: 말로 설명하기 어려운 어긋남은 화면을 찍어 붙이면 한 번에 전달됩니다. 이번 2주의 요청 절반 이상이 스크린샷 한 장과 한 줄이었습니다.
• 증거 없는 완료는 완료가 아니다: "됐어요"가 아니라 측정값과 스크린샷을 요구합니다. 카드 높이는 픽셀로, 정렬은 좌표로, 저장은 실제 요청 본문으로 확인합니다.
• 만드는 쪽과 검토하는 쪽을 나눈다: 큰 변경은 구현 담당과 검토 담당을 따로 두고, 검토 결과를 다시 구현 담당에게 돌려보냅니다.
• 되돌릴 수 없는 일은 사람이 한다: 저장 공간 구조 변경, 배포, 비밀번호가 관련된 일은 클로드가 준비만 하고 실행은 사람이 합니다. 자동 검사에서도 실제 저장 공간에는 절대 쓰지 않도록 요청을 막아 둡니다.
• 기록이 곧 문서다: 커밋마다 바뀐 것·이유·영향 범위·확인 방법을 적게 하면, 나중에 사람이 읽고 검토할 수 있고 이 글처럼 다시 꺼내 쓸 수도 있습니다.

안 되는 것도 있었다

• 취향은 여전히 사람 몫입니다. 포트폴리오를 "더 다이나믹하게" 해 달라고 하자 정신없이 움직이는 화면이 나왔고, "너무 정신사납다"로 되돌렸습니다. 어디까지가 적당한지는 보고 정하는 수밖에 없었습니다.
• 1400px처럼 과한 답이 나올 때가 있습니다. 넓게 해 달라는 말을 문자 그대로 받은 경우인데, 한 번 보면 바로 잡히는 종류라 크게 문제되지는 않았습니다.
• 통신이 끊기면 작업이 중간에 멈춥니다. 이번에도 두 번 있었고, 끊긴 자리에서 이어 가게 하면 됐지만 그 상태를 사람이 확인해야 했습니다.

OMC를 쓰면 무엇이 달라지나

클로드 코드 위에 oh-my-claudecode(OMC)라는 조율 층을 얹어 씁니다. 클로드 하나가 모든 일을 하는 대신, 일의 종류에 따라 역할이 다른 클로드에게 나눠 맡기고 그 결과를 한 명이 모아 확인하는 방식입니다. 이번 2주 동안 이렇게 따로 불러 쓴 역할이 38번이었습니다.

• 역할이 나뉜다: 설계(planner·architect) → 구현(executor) → 검토(code-reviewer·security-reviewer) → 검증(verifier) 순서가 기본 흐름입니다. 이번에는 구현 16번, 화면 디자인 10번, 코드 검토 4번, 검증 2번, 설계·보안 검토·문서 작성이 각각 한두 번이었습니다.
• 만든 사람이 스스로 검토하지 않는다: 일반 대회 양식에서 결함 7건을 찾은 건 구현 담당이 아니라 새로 투입된 검토 담당이었습니다. 같은 대화 안에서는 자기 결과를 관대하게 보기 쉬운데, 역할을 나누면 그게 막힙니다.
• 동시에 여러 일이 돈다: 링크 공유 이미지를 만드는 동안 다른 담당이 토이 프로젝트 미리보기를 만들고, 또 다른 담당이 경력 띠를 손봤습니다. 사람은 각 결과가 돌아올 때 하나씩 확인하면 됩니다.
• 증거를 요구하는 습관이 기본값이다: OMC의 규칙에 "완료를 주장하기 전에 검증하라"가 들어 있어, 화면 검사 스크린샷과 측정값을 남기는 게 매번 따로 시키지 않아도 되는 일이 됩니다.
• 안전장치가 규칙으로 걸려 있다: 한 작업에서 300줄 넘게 바뀌면 멈추고 알리기, 저장 공간 구조·배포·비밀번호 관련 일은 사람에게 넘기기 같은 규칙을 설정 파일에 적어 두면 어떤 담당이 일하든 같은 선을 지킵니다.

대신 비용이 있습니다. 역할을 나누면 대화가 길어지고 토큰을 더 씁니다. 한두 줄 고치는 일에는 과합니다. 이번에는 파일 여러 개를 건드리는 일, 화면을 새로 짜는 일, 남이 검토해야 안심되는 일에만 나눴고, 작은 수정은 한 클로드가 바로 했습니다.

LLM을 쓰는 방법과 OMC로 역할을 나누는 방법은 다음 글에서 설정 파일과 함께 따로 정리하겠습니다.

정리

프론트 개발자가 클로드와 둘이서 기획부터 배포까지 도는 건 가능했고, 속도보다 더 크게 달라진 건 역할이었습니다. 저는 코드를 덜 쓰고 대신 방향을 정하고, 결과를 확인하고, 되돌릴 수 없는 결정을 내리는 데 시간을 썼습니다. 클로드는 구현하고, 재고, 기록했습니다.

아직 익숙해지는 중이고, 위의 원칙도 실수를 겪으며 하나씩 생긴 것들입니다. 이 사이트의 도구들은 앞으로도 이 방식으로 조금씩 고쳐 나갈 예정입니다.