코딩 모르는 회사 대표가 컨텐츠발행 자동화 대시보드 만드려다가 AI 개발 스택을 세 번 갈아엎고, 결국 "설계부터"로 돌아온 후기 (Phase 2-1)

소개

저는 코딩을 전혀 모르는 소규모 전문직 회사 대표입니다. 블로그에 올릴 실적 사례글과 칼럼을 반자동으로 만드는 대시보드를 제작하고 있습니다.

이번 편은 성공담이 아닙니다. 두 달 가까이 돌아온 길을 되짚고, 왜 돌아왔는지를 정리한 글입니다.

결론부터 말하면 — 저는 도구를 고르는 단계에서 세 번 잘못 판단했고, 그 대가를 시간과 토큰으로 치렀습니다. 지금은 구조를 갈아엎고 다시 설계 단계로 돌아온 상태입니다.

비용: 0원 (기존 구독 외 추가 지출 없음)

배경: 무엇이 잘못됐나

문제 상황

작업이 끝없이 늘어졌습니다. 표면적으로는 에러 때문이었지만, 원인을 되짚어보니 셋이었습니다.

1. 기능을 정확히 모르는 도구를 파이프라인에 끼워 넣었다

처음에 오케스트레이션 레이어(여러 도구를 엮어주는 중간 단계)를 하나 두고 그 위에서 코딩 에이전트를 돌리는 구성으로 시작했습니다. 그런데 저는 그 중간 레이어가 정확히 무엇을 해주는지 모르는 상태였습니다.

결과는 단순했습니다. 작업 하나당 시간이 훨씬 오래 걸렸습니다. 뭔가 잘못되면 중간 레이어 문제인지 코딩 에이전트 문제인지 제 지시 문제인지 구분할 수가 없었습니다. 비개발자에게 이건 치명적입니다. 개발자라면 로그를 보고 층을 짚어내겠지만, 저는 그럴 수 없으니까요.

2. 설계를 논의할 AI를 잘못 골랐다

대시보드 구조를 함께 논의할 파트너로 처음에 다른 LLM을 선택했습니다. 대화는 잘 됐지만, 코드 설계에 대한 이해와 판단이 기대에 못 미친다고 느꼈습니다.

이건 성능 우열을 말하려는 게 아닙니다. 용도가 다르다는 뜻입니다. 저는 "이 구조가 나중에 문제를 일으키지 않겠는가"를 물어볼 상대가 필요했는데, 그 질문에 답하는 능력이 모델마다 꽤 다릅니다.

3. 무엇을 만들지 정하지 않고 코딩부터 시켰다

이게 가장 컸습니다.

저는 코딩 에이전트에게 "이런 걸 만들어줘"라고 추상적으로 지시했습니다. 그러면 뭔가가 만들어집니다. 그런데 그걸 보면 제가 원하던 게 아니고, 그래서 수정을 시키고, 또 아니어서 또 수정하고. 중간에 방향이 계속 바뀌었습니다.

특히 제 대시보드에는 두 개의 큰 줄기가 있습니다. 실적 사례글 작성과 칼럼 작성입니다. 이 둘은 시작점이 완전히 다른데(하나는 업무 문서에서, 하나는 인터넷 수집에서), 저는 이걸 충분히 세부적으로 나누지 않은 채 진행했습니다.

결과는 뒤죽박죽이었습니다. 두 줄기의 코드가 섞이고, 어느 파일이 어느 줄기 것인지 모르게 되고, 하나를 고치면 다른 하나가 영향을 받았습니다.

목표

• 도구 구성을 단순화한다

• 코딩을 시작하기 전에 설계를 문서로 확정한다

• 두 줄기를 명확히 분리한다

사용 도구

처음 구성 (실패)

현재 구성

중간 레이어를 걷어냈습니다. 층이 줄어드니 문제가 생겼을 때 어디를 봐야 할지 바로 보입니다.

역할 분담 원칙

나(비개발자)  ─→  의사결정, 코딩 에이전트 실행, 결과 확인
Claude        ─→  설계 판단, 작업 쪼개기, 지시문 작성, 결과 검토
Codex         ─→  실제 파일 읽기·쓰기, 코드 생성, 빌드

핵심은 Claude가 코드를 직접 쓰지 않는다는 점입니다. Claude가 만들어준 코드를 제가 복사해 옮기는 건 낭비입니다. 코딩 에이전트는 파일을 직접 읽고 씁니다. 반대로 코딩 에이전트는 "이 설계가 맞는가"를 판단하는 데는 약합니다.

각자 잘하는 것만 시킵니다.

진행 과정

Step 1. 토큰이 떨어져서 강제로 갈아탄 날

수정을 반복하다 보니 사용량 한도에 걸렸습니다. 마감은 다가오는데 도구가 멈추니, 급하게 다른 AI로 갈아탔습니다.

그런데 여기서 새 문제가 생겼습니다. 맥락이 전부 이전 대화창 안에만 있어서, 새 AI는 아무것도 모릅니다. 그래서 이전 AI에게 "지금까지 한 작업을 md 파일로 정리해줘"라고 요청해 인계 문서를 받았습니다.

시행착오 1: 인계 문서의 오타 때문에 없는 버그를 쫓음

인계 문서에는 상태값 enum이 실제 코드와 다르게 적혀 있었습니다. 새 AI는 이걸 근거로 "코드와 불일치한다, 목록 전체가 죽을 수 있다"고 경고했고, 저는 그걸 확인하느라 시간을 썼습니다.

나중에 원본 파일을 직접 올려보니 실제 코드는 처음부터 일치하고 있었습니다. 요약 문서 쪽이 틀렸던 겁니다.

해결: 요약본 대신 원본 파일을 직접 보여주는 것으로 바꿨습니다.

급하게 갈아탈 때 생기는 손실은 "설명하는 시간"이 아니라 "잘못 옮겨진 정보로 인한 오판"입니다. 이게 훨씬 비쌉니다.

Step 2. 방향이 계속 바뀐 대가를 눈으로 확인하다

새 AI와 설계를 다시 짜면서, 제가 그동안 만든 것들을 훑었습니다. 그러다 src/lib/ 아래에서 낯선 파일 여러 개를 발견했습니다.

코딩 에이전트에 물어봤습니다.

아래 파일들이 각각 무슨 일을 하는지 3~4줄로 요약해 줘.
코드는 수정하지 마.

(파일 목록)

그리고 아래 두 가지가 이미 구현돼 있는지 알려 줘.
1. PDF에서 텍스트를 추출하는 기능
2. 민감정보를 찾아 마스킹하는 기능

답은 "두 기능 모두 이미 있습니다"였습니다.

저는 그 시점에 똑같은 기능의 모듈 설계서를 두 번(v1, v2)이나 새로 쓴 상태였습니다. 좌표 단위 마스킹, 검증 로직까지 상세하게요.

방향이 계속 바뀌면 이렇게 됩니다. 예전에 만든 걸 본인이 기억 못 합니다. 그리고 비개발자는 파일 목록을 봐도 그게 뭔지 모릅니다.

이미 있는 걸 또 만들면, 나중에 어느 쪽이 진짜인지 몰라 헤매게 됩니다.

Step 3. 화면이 왜 깨졌는지 — "고쳐줘" 대신 "진단해줘"

대시보드 메인 화면이 스타일 없이 글자만 세로로 늘어진 상태였습니다.

여기서 처음으로 제대로 된 순서를 밟았습니다. 바로 고치라고 하지 않고, 원인부터 물었습니다.

개발 서버에서 Tailwind CSS 클래스가 전혀 적용되지 않고 있어.
JSX는 정상 렌더링되는데 className 으로 준 스타일만 무시되는 상황이야.
인라인 style 속성은 정상 동작해.

먼저 아래를 순서대로 확인하고, 무엇이 문제인지 진단 결과부터 알려 줘.
고치는 건 진단 결과를 보고 내가 판단할게.

1. package.json 에서 tailwindcss 의 설치 버전
2. postcss.config 존재 여부와 내용
3. tailwind.config 존재 여부와 content 배열
4. globals.css 의 최상단 몇 줄
5. layout.tsx 에서 globals.css 를 import 하고 있는지

주의:
- page.tsx 는 절대 수정하지 마. 그 파일에는 문제가 없어.
- 진단만 하고 임의로 고치지 마.

원인은 Tailwind가 애초에 설치된 적이 없다는 것이었습니다. 화면 코드는 Tailwind가 있다는 전제로 쓰였는데 실제로는 없었으니, 클래스가 "안 먹은" 게 아니라 해석할 주체가 없었던 겁니다.

설치 후에도 여백만 전부 0으로 나왔습니다. 제가 세운 가설을 코딩 에이전트가 증거로 반박했습니다.

진단 결과, --spacing 문제가 아닙니다. 직접적인 원인은 globals.css 의 전역 * reset입니다. Tailwind v4 유틸리티는 @layer utilities 안에 생성되지만, 현재 * { padding: 0; margin: 0; } 는 레이어 밖에 있습니다. CSS cascade에서 레이어 밖의 스타일이 레이어 내부 스타일보다 우선하므로 p-6, px-4, mt-6, py-8 이 0으로 덮어써집니다. 다만 gap 은 해당 reset에 포함되지 않습니다. 실행 중인 브라우저에서 gap-5 는 실제로 20px로 계산됐습니다.

한 줄에서 두 속성만 제거해 해결했습니다.

* { box-sizing: border-box; padding: 0; margin: 0; }
    ↓
* { box-sizing: border-box; }

변경 파일 4개, +9줄 −2줄. "화면이 깨졌으니 고쳐줘"라고 했다면 700줄짜리 화면 파일이 통째로 다시 쓰여졌을 겁니다.

Step 4. 반복 지시를 없애는 파일 하나

여기까지 오면서 코딩 에이전트에 같은 말을 계속 적고 있었습니다. "이 파일 건드리지 마", "진단만 해", "민감 정보를 로그에 남기지 마".

코딩 에이전트는 프로젝트 최상단의 AGENTS.md를 세션마다 자동으로 읽습니다. 여기 적어두면 매번 안 적어도 됩니다.

저는 이미 1,500줄이 넘는 기준 문서를 갖고 있었지만, 그걸 그대로 쓰지 않았습니다.

긴 문서는 "왜"를 담는 헌법이고, AGENTS.md는 "지금 뭘 하지 말아야 하는가"를 담는 작업 수칙입니다. 성격이 다릅니다.

넣은 것은 실제로 사고가 났거나 날 뻔한 것들뿐입니다. 각 규칙에 이유를 한 줄씩 달았습니다.

### 3.2 Tailwind 주의

globals.css 에 전역 `* { padding: 0; margin: 0; }` 같은 reset 을 넣지 않는다.
Tailwind v4 유틸리티가 @layer 안에 생성되므로 레이어 밖 규칙이 이를 덮어써 버린다.
(실제로 이 문제가 발생했다)

이유가 있어야 AI가 비슷한 상황에도 응용합니다.

Step 5. 두 줄기를 분리하고, 만들려던 걸 폐기하다

여기가 이번 작업의 핵심입니다.

저는 대시보드 안의 두 줄기(실적 사례글 / 칼럼)를 처음으로 제대로 나눠서 설계했습니다. 그러자 그동안 복잡해 보였던 것들이 하나씩 풀렸습니다.

깨달음 1: 두 줄기는 앞부분만 다르고 뒷부분이 같다

한때는 아예 다른 앱으로 만들까 고민했습니다. 그런데 뜯어보니 다른 건 입구뿐이었습니다.

실적 사례글 → 업무 문서에서 출발 ─┐
                                  ├→ 검토 → 금지표현 검사 → HTML 변환 → 발행
칼럼        → 인터넷 수집에서 출발 ─┘
                                     ↑ 이 뒷부분이 전체 작업량의 절반 이상

따로 만들었다면 이걸 두 번 만들고 두 번 고쳐야 했습니다.

깨달음 2: 복잡해 보인 건 두 가지를 묶어놨기 때문

문서 처리가 유난히 복잡했던 이유가 있었습니다.

• AI 분석용 → 문서 전체, 마스킹 불필요

• 블로그 게시용 → 첫 1~2장만, 마스킹 필요

목적이 다른 별개의 작업인데, 저는 이걸 하나의 파이프라인으로 생각하고 있었습니다. "전체를 마스킹하려니 손이 너무 많이 간다"고 느꼈는데, 전체를 마스킹할 일은 처음부터 없었습니다.

깨달음 3: 그래서 모듈 하나를 착수 전에 폐기했다

앞서 두 번이나 쓴 마스킹 모듈 설계서를 만들기 전에 버렸습니다.

이유는 셋이었습니다. 이미 구현이 있었고, 보안 전제가 바뀌었고(업무 문서를 AI에 넣는 것을 허용하기로 판단), 무엇보다 마스킹은 분석과 별개라 자동화 우선순위가 낮았습니다.

일부 문서는 종이를 스캔한 것이라 글자 좌표를 알 수 없어 마스킹 정확도가 급락합니다. 이름 끝 한 글자만 삐져나와도 사고입니다. 당분간 담당 직원 수작업으로 두기로 했습니다.

여기서 안전 절차 하나를 배웠습니다. 워드프로세서에서 문서 위에 흰 도형을 얹고 PDF로 저장하면 밑에 글자가 그대로 살아 있습니다. 도형만 걷어내면 읽힙니다. 안전한 방법은 페이지를 PNG로 먼저 저장한 뒤 그림판에서 칠하는 것입니다.

Step 6. 프롬프트를 세 번 고쳐 쓰면서 알게 된 것

사례글 초안 프롬프트가 v1 → v2 → v3까지 갔습니다.

v1 — 제 기존 블로그 글을 못 본 상태에서 일반적인 문법을 가정해 작성. 실제 발행글을 보여주자 즉시 폐기.

v2 — 실제 발행글 패턴 반영. 여기서 제 발행글의 오류도 하나 발견했습니다. 제목과 본문의 핵심 수치가 서로 달랐습니다. 사람이 손으로 쓰면 나는 실수죠. 그래서 숫자 일치 자동 검사를 시스템에 넣기로 했습니다.

v3 — 예전에 제가 쓰던 프롬프트를 뒤늦게 찾아 올렸더니 판단이 하나 뒤집혔습니다.

기준 문서에 "2번 1문장, 3번 5문장, 4번 2문장"이라는 분량 규정이 있었는데 실제 발행글이 훨씬 길어서, 저는 "문서가 낡은 것"이라고 넘겼습니다. 그런데 제 원래 프롬프트에도 같은 분량이 적혀 있었습니다.

혼동이었습니다. AI가 만드는 건 "원고"이고, 발행글은 제가 살을 붙인 결과물이었습니다.

그래서 이렇게 나눴습니다.

AI가 쓰는 것      → 매번 달라지는 부분 (사실관계·특징·전략·결과)
코드가 붙이는 것  → 매번 같은 정형 문구
                    (조직 소개, 상담 유도, 연락처, 주소, 제목 형식)

연락처를 AI에게 쓰게 하면 언젠가 틀리게 적습니다. 그 글은 검색에 계속 남고요.

이 구분은 제 예전 자료를 꺼내 보고 나서야 나왔습니다. 처음부터 정리해뒀다면 v1을 쓸 일 자체가 없었습니다.

결과와 배운 점

정량적 결과

정성적 결과

• "안 만들기로 한 결정"이 이번의 가장 큰 성과였습니다. 그대로 만들었다면 며칠 쓰고 결국 수작업으로 돌아왔을 겁니다.

• 두 줄기를 분리하고 나니, 각각이 단순해졌습니다. 섞여 있을 때만 복잡했습니다.

• 문제가 생겼을 때 "어디를 봐야 하는지" 감이 잡히기 시작했습니다. 층이 줄어든 덕입니다.

• 무엇을 AI에 맡기고 무엇을 코드로 고정할지 기준이 생겼습니다. "매번 달라지는 건 AI, 매번 같은 건 코드."

시행착오 총정리

제가 겪은 진짜 문제는 에러가 아니라 순서였습니다.

정상적인 순서는 이랬어야 합니다.

무엇을 만들지 정한다
   → 그게 어떻게 실현 가능한지 LLM과 상의한다
      → 설계를 문서로 남긴다
         → 그 설계를 코딩 에이전트에 넘긴다

제가 한 순서는 이랬습니다.

막연한 아이디어
   → 바로 코딩 에이전트에 추상적 지시
      → 결과물이 원하는 게 아님
         → 수정 지시
            → 또 아님 → 또 수정 → 방향 전환
               → 토큰 소진 → 급하게 다른 AI로 갈아탐
                  → 맥락 유실 → 설계 재변경 → 반복

아래쪽 순서는 무한 반복 구조입니다. 빠져나올 지점이 없습니다. 저는 이 고리를 끊으려고 "설계 문서를 먼저 만든다"는 지점으로 강제로 돌아왔습니다.

배운 점

1. 기능을 모르는 도구를 파이프라인에 넣으면, 그 층 전체가 블랙박스가 된다

중간 레이어를 하나 더 두면서 저는 편해질 줄 알았습니다. 실제로는 문제가 생겼을 때 어느 층 탓인지 구분할 수 없게 됐습니다. 개발자라면 로그를 보고 짚겠지만 비개발자는 못 합니다.

비개발자일수록 층을 줄여야 합니다. "이 도구가 정확히 뭘 해주는지 한 문장으로 설명할 수 있는가"를 도입 전에 물어보세요. 못 하겠으면 아직 넣을 때가 아닙니다.

2. 설계를 논의할 AI와 코드를 쓸 AI는 다르게 골라야 한다

같은 AI로 다 하려다 보니 어느 쪽도 잘 안 됐습니다. 지금은 설계 판단은 대화형 LLM, 파일 작업은 코딩 에이전트로 나눴습니다.

기준은 성능 순위가 아니라 "이 구조가 나중에 문제를 일으키겠는가"라는 질문에 제대로 답하는가입니다. 이건 모델마다 차이가 꽤 큽니다. 몇 번 물어보면 금방 알 수 있습니다.

3. 추상적 지시는 반드시 되돌아온다

"이런 걸 만들어줘"라고 하면 뭔가는 만들어집니다. 그런데 그게 내가 원하던 게 아닙니다. 수정을 시키고, 또 아니어서 또 수정하고. 그 반복이 토큰과 시간을 다 먹습니다.

제가 그 시간에 했어야 할 일은 "내가 만들려는 게 정확히 무엇이고, 그게 어떻게 실현 가능한지"를 LLM과 먼저 상의하는 것이었습니다. 30분이면 됐을 일입니다.

4. 하나의 프로젝트 안에 여러 줄기가 있으면, 시작 전에 반드시 쪼개야 한다

제 대시보드에는 두 줄기가 있었는데 그걸 나누지 않고 진행했습니다. 결과는 뒤죽박죽이었습니다. 어느 파일이 어느 줄기 것인지 모르게 되고, 하나를 고치면 다른 하나가 영향을 받았습니다.

쪼갠 뒤에는 "어디까지 공유하고 어디부터 갈라지는지"도 정해야 합니다. 저는 뒷부분(검토·변환·발행)이 공통이라는 걸 나중에야 알았습니다.

5. 토큰이 떨어져서 급하게 갈아타는 것이 가장 비싸다

한도에 걸려 다른 AI로 옮기면, 맥락이 유실되고 설계가 또 바뀝니다. 그리고 그 재작업이 다시 토큰을 먹습니다.

교훈은 "토큰을 아껴라"가 아닙니다. 방향 전환을 줄이면 토큰이 안 떨어집니다. 토큰 소진은 원인이 아니라 결과였습니다.

6. 요약본이 아니라 원본을 보여줘야 한다

AI가 만든 인계 문서의 오타 하나 때문에, 새 AI가 없는 버그를 지적했고 저는 그걸 확인하느라 시간을 썼습니다. 요약은 원본과 다를 수 있습니다.

7. "고쳐줘"와 "진단해줘"를 구분하면 손상 범위가 줄어든다

"깨졌으니 고쳐줘"라고 하면 AI는 멀쩡한 파일까지 다시 씁니다. 원인을 먼저 묻고, 답을 본 뒤에 고치라고 시키면 됩니다. 이번 화면 복구가 4개 파일 9줄로 끝난 이유입니다.

8. 만들기 전에 "이미 있는지" 확인하는 데 5분을 써야 한다

파일 목록을 한 번 훑고 AI에게 "이것들이 각각 무슨 일을 하냐"고 물었으면, 설계서를 두 번 쓸 일이 없었습니다. 비개발자는 파일 목록을 봐도 뭔지 모르니, 더더욱 물어봐야 합니다.

다음 계획

• 확정한 설계대로 문서 → 사례글 초안 생성 기능 구현

• 이미 발행한 건으로 첫 테스트 (정답지가 있으니 품질 비교 가능)

• 실제 토큰 사용량 측정해 글 한 편당 비용 산출

• 초안 검토 화면과 블로그 붙여넣기용 HTML 변환

• 그다음에야 칼럼 줄기 착수 (이번엔 순서를 지킬 예정)

전체 흐름 요약

[잘못 끼운 첫 단추 3개]
  ① 기능 모르는 중간 레이어 도입 → 작업당 시간 증가, 원인 추적 불가
  ② 설계 논의용 LLM 선택 실패    → 구조 판단이 약함
  ③ 설계 없이 추상적 지시로 착수 → 방향 계속 전환
        │
        ▼
  두 줄기(사례글/칼럼)가 뒤섞임 → 수정 반복 → 토큰 소진
        │
        ▼
  급하게 AI 교체 → 맥락 유실 → 설계 재변경 → 반복
        │
        ▼
[수습]
  ├─ 중간 레이어 제거, 2층 구조로 단순화
  ├─ 설계 LLM / 코딩 에이전트 역할 분리
  ├─ 화면 복구: "진단 먼저" → 4개 파일 +9 −2
  ├─ AGENTS.md 세팅 → 반복 지시 제거
  ├─ 두 줄기 분리 설계 → 공통부(검토·변환·발행) 식별
  ├─ 중복 모듈 발견 → 착수 전 폐기
  └─ 프롬프트 v1→v2→v3 → "AI는 원고, 코드는 정형 문구"
        │
        ▼
  다시 설계 단계로 복귀

총 추가 비용: 0원 가장 비쌌던 것: 설계 없이 시작해서 되돌아온 시간

도움 받은 것들

• Tailwind CSS v4 공식 문서 (PostCSS 플러그인 설정)

• 각 AI 도구의 공식 문서 (PDF 첨부 방식, 지침 파일 규약)

• Gpters.org 커뮤니티

다음 편(설계 확정 후 실제 구현 후기)도 이어서 올리겠습니다.

비개발자 관점의 AI 협업 개발 활용기에 관심 있으신 분들의 피드백 환영합니다!