저는 몇 달 전부터 회사에서 Product Engineer(이하 PE) 포지션으로 일하고 있습니다. 기능 하나를 골라서 스펙 정의부터 개발과 릴리즈까지 혼자 끝까지 끌고 가는 역할이었습니다.

이 글은 제가 PE로 일 해오면서 느꼈던 것들을 조금은 거칠게 공유하는 글입니다. 방법론이나 효율적으로 일 할 수 있는 제안서 성격의 글은 아닙니다. 아직도 PE는 그 역할 정의가 끝나지 않았고 만들어져 가는 중이라고 생각합니다. 세상에 이런 생각을 갖고 있는 PE도 있구나 정도로 읽어주시면 감사하겠습니다.

1. 가장 작은 일감부터

PE로 포지션을 변경하는 그 시작 지점에서, 저는 PM이라는 역할을 추상적으로만 아는 상태로 시작했습니다. 도서관에서 PM과 관련된 책을 몇 권 읽고 어느 정도 감은 잡았지만 막상 직접 해 보려니 막막했습니다.

PM팀과 미리 상의해서 가장 작은 단위의 일감부터 맡기로 했습니다. 지금 돌아보면 이 선택이 맞았습니다. 처음에는 결과물의 크기보다 역할 자체에 익숙해지는 것이 먼저였습니다. 스펙 문서 한 장을 쓰는 데 몇 시간, 며칠을 썼지만 지금 돌이켜보면 그것은 전혀 낭비가 아니었다고 생각합니다.

조급해지지 않는 것이 어려웠습니다. 개발만 할 때는 하루가 지나면 눈에 보이는 결과물이 남았는데, PE로 일한 첫 몇 주는 코드를 거의 쓰지 않았습니다. PM이라는 새로운 역할과 앞으로 PE로 어떻게 일 해야 할지에 대해 감을 잡아가는 시간이었습니다.

2. 어떤 사고방식으로 일해야 할까?

처음에는 기존 역할(백엔드, 프론트엔드)에 PM 역할을 얹는 방식으로 접근했습니다. 프로젝트 초기에는 PM 모드로 스펙을 정의하고 스펙 문서와 디자인이 확정되면 개발자 모드로 전환해서 코드를 작성하는 방식입니다. 저는 원래부터 Full-stack engineer였기에 이 방법이 자연스러웠습니다. 그래서 PM으로 일하는 방법에 대해서만 배우면 되겠다 라고 생각했습니다.

PM 모드와 개발자 모드, 두 모드를 엄격하게 나눈 데에는 이유가 있었습니다. 코드를 빨리 쓰고 싶은 마음에, 제품을 빨리 만들고 싶은 마음에 스펙이나 디자인을 현실과 타협하게 될까 봐 걱정했습니다. 제품의 스펙이 결정되면 이것을 기반으로 코드를 만들어야 하는데, 코드 또는 시스템 구조가 역으로 스펙에 영향을 끼치면 그 스펙의 품질이 더 나빠질 것 같았기 때문이었습니다.

그런데 이 방식은 잘 굴러가지 않았습니다. 스펙 문서와 디자인을 완전히 확정해 놓고 다음 단계로 넘어가는 것은 애초에 불가능합니다. 스펙 정의와 디자인 작업은 프로젝트 중반까지 이어지는 경우가 많았고 그때마다 두 모드를 오갔습니다. context switching 비용도 컸지만 심리적으로 지친다는 게 더 문제였습니다.

그래서 'Product Engineer'라는 역할이 하나 있고 내가 그 역할을 수행한다고 생각을 바꿨습니다. 말장난처럼 들릴 수 있지만 저에게 이것은 큰 차이라고 생각합니다. 나를 포함한 하나의 팀이 따로 존재하고 나는 팀원들을 지휘하는 팀장으로서 일하는 것입니다. 실재하지 않는 팀원이지만 제가 일하는 Workflow 내에서는 마치 살아있는 것처럼 그들을 관리하고 일을 지시하고 작업 결과물을 검토합니다.

그리고 첫 단계부터 마지막 단계까지 한 번의 호흡으로 이어 가는 쪽이 각 단계를 분절해서 따로 처리하는 것보다 덜 힘들었습니다.

한 번의 호흡이 필요한 이유는 다뤄야 하는 context의 크기 때문입니다. 문서와 코드, 출시 일정, 제품의 품질까지 전부 머릿속에 들고 있어야 하는데, 이게 흐릿해지기 전에 끝까지 밀고 가야 합니다. 6개월 전에 출시한 기능의 세부 동작이 지금 기억나는지 생각해 보면 됩니다. 그래서 6개월 이상 걸리는 대형 프로젝트는 한 명의 PE가 다루기 어렵다고 생각합니다.

처음에 걱정했던 타협을 지금은 무조건 나쁜 것으로 보지는 않습니다. 스펙의 근간을 흔드는 타협은 하지 않되, 출시를 좀 더 빠르고 원활하게 하기 위한 작은 규모의 스펙 변경은 현실적인 선택으로 받아들였습니다. 그 경계를 매번 명확하게 그을 수 있었던 것은 아닙니다.

3. 프로세스 바깥에 있던 것들

PM팀에서 기능의 대략적인 방향성과 그 기능이 필요한 이유를 공유받으면 그중 하나를 골라 처음부터 마지막까지 완수하는 방식으로 일했습니다.

그때 제 머릿속에 있던 프로세스는 이것이 전부였습니다.

PM팀 → 스펙 작성 → PM팀 리뷰 → 스펙+디자인 확정 → 개발 → QA → 릴리즈

이 흐름 바깥에 고객의 목소리(Voice of Customer)와 과거 고객 문의 이력, 특히 Sales팀과 CS팀의 피드백이 있었습니다. 저는 이 절차를 생략하거나 형식적으로만 거쳤습니다.

제가 저지른 실수 중 가장 아픈 부분입니다. 엔지니어로 일해 온 시간이 길어서인지 위 화살표로 이어지는 파이프라인에 시선이 고정되어 있었습니다. 파이프라인은 눈에 보이고 각 단계마다 산출물이 남는 반면, Sales팀과 CS팀의 피드백은 그런 형태가 아니라서 의식적으로 챙기지 않으면 그냥 지나갑니다. 만들어 놓고 아무도 쓰지 않는 제품은 의미가 없습니다.

4. 읽기가 99, 쓰기가 1

PE로 일하면서 읽기와 쓰기의 비율이 크게 뒤집히는 것을 체감했습니다. 과장을 좀 보태면 읽기가 99이고 쓰기가 1입니다. 이것은 개발자로 일 해도 유사할 것입니다. 작성하는 코드 양보다 읽어야 할 코드의 양이 많아지는 것입니다.

읽어야 하는 것은 두 종류였습니다. 하나는 기존 제품의 코드와 문서, 즉 맥락을 파악하기 위한 읽기입니다. 다른 하나는 AI가 생산한 문서와 코드를 검수하기 위한 읽기입니다. 시간이 갈수록 후자의 비중이 커졌습니다.

모든 문서를 전부 읽지는 않았습니다. 다만 초기 단계의 핵심 문서는 처음부터 끝까지 직접 읽었습니다. LLM은 앞 단계 문서에 어긋난 부분이 조금이라도 있으면 뒷 단계로 갈수록 원래 의도와의 차이를 키웁니다. 그래서 초기 문서일수록 두 번 세 번 읽었습니다.

최근 들어 LLM이 작성하는 글의 가독성이 떨어지는 문제가 발생하고 있습니다. 저뿐만 아니라 다른 사람들도 유사한 경험을 말하고 있습니다. 글의 가독성을 높이고 읽는 시간과 피로도를 줄이기 위해 여러 가지 플러그인을 설치하여 사용하고 있습니다.

5. 고치는 대신 롤백합니다

앞 절과 이어지는 이야기입니다. 초기 문서에 잘못된 문장이나 개념이 들어가 있으면 제품을 만들고 릴리즈하는 전 과정에서 LLM이 그 내용을 계속 참조합니다. 예를 들어, 이 기능을 만드는 이유에 대해 약간이라도 잘못된 개념이 초기 문서에 포함되어 있으면 뒷부분에 구체적인 실행 계획 문서를 만들 때 핀트가 어긋나는 내용이 포함되는 경우가 많았습니다.

LLM은 360도 방향으로 열려 있는 무한한 가능성이 있는 소프트웨어입니다. 사람의 역할은 목표 지점까지 다다를 수 있는 아주 좁은 범위로 이것을 한정시키는 것이라고 생각합니다. 초기 단계에 이 방향 설정이 잘못돼서 각도가 틀어지면 최종 단계에 다다라서는 엄청난 차이가 발생하게 되는 것입니다.

그래서 문서를 쓰는 중에 방향이 어긋났다고 느끼면 롤백하고 처음부터 다시 하는 쪽을 택했습니다. 중간을 부분적으로 수정하는 것보다 그게 빨랐습니다.

소스 코드 역시 언제든 롤백할 수 있다는 자세로 다뤘습니다. 다만 코드는 조금 다르게 접근했습니다. functional requirement를 충족하는 수준까지 최대한 빠르게 만들어서 일단 기능이 돌아가게 하고 코드 리뷰를 거치면서 점진적으로 개선했습니다. 이것은 제가 PM base가 아니라 개발자 base라서 그런 것일 수도 있습니다.

소스 코드가 돌아가는 것을 확인하고 나서도 결과가 너무 마음에 들지 않거나 잘못 구현되어 개선 작업으로는 어찌할 수 없다고 판단되면 롤백하고 다시 만들었습니다. 이때 중요한 것은 마음에 들지 않았던 부분을 설계 문서에 먼저 반영하는 것입니다. 그러지 않으면 같은 결과물이 다시 나옵니다.

6. 문서/코드를 직접 고치지 않습니다

제가 일하는 방식 중에 가장 많이 바뀐 부분입니다.

PDLC의 각 단계에서 제가 그 단계의 직접적인 작업자가 되지 않으려고 했습니다. PE로서 제가 한 명 있고 각 단계를 담당하는 에이전트가 따로 있는 구조입니다. 제가 쓰는 BMad에는 스펙 문서를 담당하는 PM 에이전트(John)와 개발을 담당하는 개발자 에이전트(Amelia)가 있습니다. 사람 이름처럼 보이지만 에이전트 이름입니다.

모든 문서를 에이전트가 쓰는 것은 아닙니다. 아주 초기 단계의 문서는 제가 직접 씁니다. 예를 들어 intent.md는 기능을 아주 짧게 소개하고 이 기능이 왜 필요한지를 적은 문서입니다. 전체 개발의 출발점이 되기 때문에 제가 처음부터 끝까지 씁니다. 초안만 잡고 나머지를 맡기는 경우도 있습니다.

그러나 그 이후에 생산되는 문서를 제가 직접 부분 수정하는 것은 좋지 않다고 봅니다. 이유는 문서의 종류와 분량 때문입니다. A라는 개념을 잘못 서술한 부분을 발견해서 고쳤다고 해도, 그 개념과 연결된 다른 문서까지 전부 찾아 읽고 같이 고치는 것은 사람에게 힘든 일입니다. 한 군데만 고쳐 놓으면 문서들 사이가 어긋나고 그 어긋남은 다음 단계에서 그대로 드러납니다.

그래서 틀린 부분을 발견하면 그 내용을 AI에게 말하고 전체 문서에서 비슷한 부분을 전부 찾아 고치라고 합니다. 요즘의 Claude나 Codex는 내부적으로 여러 도구를 조합해서 호출하기 때문에 문서 양이 많아도 잘 찾아내고 잘 고칩니다. 제가 손으로 하는 것보다 결과가 낫습니다.

이것은 소스 코드 역시 마찬가지입니다.

4절에서 읽기가 99이고 쓰기가 1이라고 했는데, 비율이 그렇게 된 이유가 여기에 있습니다. 읽고 판단하는 것은 제 몫이고 쓰고 고치는 것은 에이전트의 몫으로 나뉘어 있기 때문입니다.

7. Workflow

PE 역할을 시작하고 초기에 제가 목표로 삼은 것은 특정 기능을 완성하는 게 아니라 workflow를 만드는 것이었습니다.

전제는 이렇습니다. 소스 코드를 제외한 모든 산출물은 결국 소스 코드를 작성하기 위한 것이라고 생각합니다. 그래서 AI가 코드를 쓰기 쉽도록 스펙 문서와 중간 단계 문서를 만드는 것이 중요했습니다. 스펙 문서는 사람도 읽고 AI도 읽어야 하지만 중간 단계 문서 중에는 사람이 굳이 읽지 않아도 되는 것들이 있습니다. 이 구분을 해 두면 어디에 시간을 쓸지가 정해집니다.

제 경우에는 BMad(Spec) + BMad(Custom module) + Ralph loop 조합을 workflow로 만들어서 관리했습니다.

BMad의 스펙 모듈은 에이전트가 정해진 순서대로 질문을 던지고 그 답을 문서로 정리해 줍니다. 백지에서 문서를 시작하지 않아도 되고 반드시 결정해야 하는 지점을 빠뜨리지 않게 해 줍니다. 제품을 만들기 위한 ABC를 BMad 자체에서 요구하는 것입니다.
BMad의 커스텀 모듈은 BMad의 산출 문서와 Ralph loop을 연결하기 위한 징검다리 역할을 합니다. BMad 산출물 문서(ux-design-specification.md, architecture.md, prd.md, epics.md) 기반으로 prd.json이라는 파일을 만듭니다.
Ralph loop은 개발 단계에서 씁니다. prd.json 파일 기반으로 모든 Epic과 Story를 순차적으로 작업하도록 합니다. 각 Story별로 독립적인 세션을 열기 때문에 세션 토큰 리밋에 걸릴 위험이 적습니다. Story별로 작업 진행 상황도 관리하기 때문에 신규 세션이 열려도 내부적으로 작업 진행 상황에 대한 컨텍스트를 알고 있게 합니다.

이 조합이 정답이라는 뜻은 아닙니다. 세상에는 AI로 스펙 문서를 쓰는 기법과 소스 코드 개발 기법이 너무 많아서 그중 몇 개를 골라 처음부터 마지막까지 끊김 없이 굴러가는 하나의 흐름으로 만드는 것이 관건입니다. 끊기는 지점이 있으면 거기서 사람이 손으로 메워야 하고 그 순간 앞에서 말한 한 번의 호흡이 깨집니다.

workflow 자체를 소스 코드로 관리할 수도 있습니다. 저는 dev-hub라는 이름의 사내 Repository를 따로 두고 관리했습니다. dev-hub만 로컬에 내려 받아 claude, codex 등을 실행하면 바로 커맨드 명령어로 시작할 수 있게끔 한 것입니다.

여기까지가 지난 몇 달의 기록입니다. 지금도 방식은 계속 바뀌고 있어서 몇 달 뒤에 이 글을 다시 보면 고치고 싶은 부분이 있을 것 같습니다.

위에서 잠깐 언급했지만 Ralph loop 방식도 최근 들어서는 많이 언급되지 않는 느낌입니다. Claude나 Codex가 자체적으로 하나의 큰 작업을 처음부터 끝까지 완수해내는 능력이 정말 좋아졌기 때문인 것 같습니다.

PE로 일 한 다는 것은 어쩌면 가장 최신 기술과 방법론을 끊임없이 실험 해보고 받아 들이고 개선 해나가는 과정이 제일 중요할 수도 있겠습니다.

Product Engineer - 내가 느낀 것들