구현을 위임할수록 앞단은 무거워야한다

LLM에게 구현을 맡기면 속도가 올라갑니다. 동시에 빗나가는 속도도 올라갑니다.

직접 구현할 때는 중간에 멈출 수 있었습니다. 코드를 쓰다가 빠진 조건을 발견하고, 구조를 바꾸고, 다시 앞단으로 돌아갈 수 있었습니다. 판단과 구현이 같은 사람 안에서 같이 움직였기 때문입니다.

LLM에게 맡길 때는 그 감각이 분리가 되고 블랙박스가 잔뜩 있는 상태처럼 느껴질때가 정말 많습니다.

제가 앞에서 정리하지 않은 것은 모델이 중간에 자연스럽게 보정하지 않습니다. 비어 있는 부분은 그럴듯하게 채워지고, 저는 결과물을 보고 나서야 방향이 틀어졌다는 걸 알게 됩니다. 그래서 구현을 맡길수록 앞단이 무거워야 한다고 생각합니다.

개발은 원래도 코드만 쓰는 일은 아니었다

제가 생각하는 개발자의 역량은 코드를 잘 쓰는 데서 끝나지 않습니다. 요구사항을 기반으로 무엇을 만들지 이해하고, 실행 가능한 단위로 쪼개고, 위험 가능성과 검증에 대해서 고려하고 이후 운영 가능한 형태로 닫는 것까지 포함된다고 봅니다.

이전 회사에서 중장기적인 태스크를 주도할 때도 비슷했습니다. 특히 EMR 장비 연동처럼 1인 주도 task는 제가 직접 리서치, 개발, 문서화, 운영 흐름이 같이 전과정이 붙는 일은 코드만 잘 써서는 유지되지 않았습니다. 그때도 앞단과 뒷단을 봐야 했습니다.

다만 LLM을 쓰면서 그 필요가 더 선명해졌습니다. 직접 구현하지 않는 만큼, 구현 중에 자연스럽게 하던 판단을 앞단으로 꺼내야 했습니다.

앞단에서 정해야 하는 것들

LLM에게 일을 맡기기 전에 더 많이 정해야 합니다. 이유는 간단합니다. 기준을 명확하게 정하지 않아도 결과물은 나옵니다.

문제는 그 결과물이 맞는지 확인하는 비용이 뒤로 밀린다는 점입니다.

• 무엇을 만들 것인가
• 왜 이 단위로 나눌 것인가
• 어디까지 맡길 것인가
• 무엇이 나오면 맞다고 볼 것인가
• 어디에서 사람이 확인해야 하는가
• 어떤 조건이면 과정을 멈춰야 하는가

처음에 덜 생각하면 나중에 더 많이 확인하게 됩니다. 처음에 더 생각하면 뒤에서 더 넓게 맡길 수 있습니다.

제약은 덜 맡기기 위한 것이 아니다

처음부터 범위를 자르고, 기준을 세우고, 확인 지점을 넣는 것은 느려 보입니다. 하지만 목적은 속도를 줄이는 것이 아닙니다. 더 크게 맡기기 위한 조건을 만드는 것입니다.

제약이 없으면 위임은 불안정해집니다. 반대로 범위가 있으면 모델이 자유롭게 움직일 수 있는 구간과 반드시 멈춰야 하는 구간이 나뉩니다. 제가 모든 구현을 보지 않아도 되는 이유는 중간에 확인할 수 있는 지점이 있기 때문입니다.

Human-in-the-loop는 계속 끼어드는 일이 아니다

A-Z를 한 번에 맡기면 속도는 빠릅니다. 하지만 중간에 사람이 확인할 지점이 없으면, 어디서 가정이 바뀌었고 어떤 판단이 틀어졌는지 파악하기 어렵습니다. 그래서 human-in-the-loop가 필요하다고 생각합니다.

여기서 사람의 역할은 구현에 계속 끼어드는 것이 아닙니다. 사람이 들어가야 할 지점을 미리 설계하는 것입니다.

방향 정의 → 작은 단위로 분해
  → 첫 결과물 확인 → 기준 충족 시 다음 단계 위임
    → 동작 검증
      → 회고와 레슨 반영

중요한 것은 사람이 계속 붙어 있는 것이 아닙니다. 방향이 크게 틀어지기 전에 확인할 수 있는 구조를 만드는 것입니다.

많은 시니어 개발자분들에게 배운 것도 결국 이 지점이었습니다. 일을 잘게 쪼개는 것만큼, 어디에서 멈춰서 확인할지를 설계하는 능력이 중요하다는 점입니다.

Plan은 구현 지시서가 아니라 작업 제어 장치다

큰 태스크는 바로 구현하지 않습니다. 먼저 plan으로 전체 방향, 실행 단위, 확인 지점, 성공 기준을 잡습니다. 다만 plan을 그대로 구현 요청으로 넘기지는 않습니다. plan은 전체 지도를 만드는 문서이고, 실제 작업은 다시 priority todo로 쪼갭니다.

plan
  → priority todo - v1
    → phase 1
    → phase 2
    → phase별 업데이트

priority todo는 고정된 체크리스트가 아니라, 작업이 진행되면서 갱신되는 실행 큐입니다. phase를 하나 끝내면 실제로 드러난 조건을 반영해 다음 버전으로 수정하고, 예상과 다른 제약이 나오면 순서도 바꿉니다.

각 phase는 가능하면 커밋 가능한 단위로 끊습니다. 그래야 갑자기 되던 것이 안 될 때, 어느 지점에서 흐름이 깨졌는지 git bisect처럼 좁혀갈 수 있습니다. 계획을 나누는 이유는 실행을 관리하기 위해서만이 아니라, 실패 지점을 추적 가능하게 만들기 위해서입니다.

실험이 필요한 구간은 본 작업과 분리합니다. 원본 흐름은 유지하고, 분기된 흐름에서 가설을 검증합니다. 제가 원하는 것은 A-Z를 한 번에 맡기는 방식이 아닙니다. 먼저 나누고, 분기하고, 확인하고, 문제가 생기면 되돌아갈 수 있는 지점을 남기는 방식입니다.

실행 단위는 작은 가설 루프로 돌린다

plan과 priority todo가 전체 작업의 구조를 잡는다면, 각 phase 안에서는 작은 가설 루프를 돌립니다.

가설 → 실행 → 확인 → 반영

먼저 한정된 범위의 가설을 세우고 실행을 맡깁니다. 결과가 나오면 가설이 맞았는지 확인합니다. 맞으면 다음 phase로 넘기고, 틀렸으면 plan이나 priority todo를 수정합니다.

제가 키우고 싶은 역량도 이쪽에 있습니다. 프롬프트를 잘 쓰는 능력보다, 큰 일을 작은 실행 단위로 만들고 각 단위의 성공 기준을 세우는 능력입니다.

앞단을 무겁게 만든다는 것

앞단을 무겁게 만든다는 것은 문서를 많이 쓰는 일이 아닙니다. plan, priority todo, checkpoint 같은 도구도 그 자체가 목적은 아닙니다. 목적은 LLM이 빠르게 움직이더라도 작업이 처음 정한 방향에서 벗어나지 않게 만드는 것입니다.

결국 구현을 얼마나 잘 맡길 수 있는지는 뒤에서 얼마나 많이 고치는지가 아니라, 앞단에서 무엇을 얼마나 명확하게 정했는지에 달려 있다고 생각하며 중요성을 높게 봅니다.