Linear + Codex 연동 실무: 이슈에서 PR까지 자동화

Linear 이슈에서 바로 시작하는 Codex Cloud 실무

예전엔 이슈를 만들면 사람이 움직였습니다.

이제는 이슈를 만들고, assignee를 열고, Codex를 찍으면 AI가 먼저 움직입니다.

오늘 이야기하는 건 “터미널 켜고 CLI 실행하고 MCP 붙이고…” 그런 복잡한 루트가 아닙니다.
그냥 Linear 이슈 화면에서 바로 Codex한테 일을 넘기는 흐름입니다.

조금 극적으로 말하면 이렇습니다.

PM이 이슈를 만든다.
나는 Codex에게 할당한다.
Codex는 클라우드에서 일한다.
나는 진행 상황을 보다가 마지막에 리뷰한다.

이게 왜 재밌냐고요?
드디어 개발자가 타이핑 담당자에서 판단 담당자로 승진하는 느낌이 나거든요.

오늘 말하는 자동화는 정확히 이겁니다

Linear에는 이슈를 에이전트에게 delegate하는 방식이 있고, Codex도 그 대상이 될 수 있습니다. OpenAI 공식 문서 기준으로는 Linear에서 이슈를 Codex에게 할당하거나 댓글에 @Codex를 멘션하면, Codex가 cloud task를 만들고 진행 상황과 결과를 다시 이슈에 올립니다. Codex Cloud 자체도 별도의 클라우드 환경에서 코드를 읽고, 수정하고, 실행하는 흐름을 지원합니다.

즉, 이 글의 핵심은 이것 하나입니다.

“이슈를 쓰자마자 개발자에게 DM 보내는 대신, Codex에게 바로 assign 한다.”

생각보다 이 한 줄이 팀의 일하는 방식을 꽤 많이 바꿉니다.

셋업도 생각보다 단순합니다

이 흐름을 쓰려면 먼저 Codex 쪽에서 GitHub를 연결하고, Codex가 작업할 저장소용 environment를 만들어둬야 합니다. 그다음 Codex 설정에서 Codex for Linear를 설치하고, Linear 이슈 댓글에서 @Codex를 한 번 멘션해서 계정을 연결하면 됩니다. 그 이후부터는 이슈를 팀원에게 배정하듯 Codex에게도 배정할 수 있습니다.

여기서 중요한 건 “AI를 쓰는 법”이 아니라,
AI가 일할 작업장(environment)을 먼저 만들어두는 것입니다.

사무실 없는 사람한테 일을 시키면 안 되잖아요.
Codex도 비슷합니다. 일할 repo와 environment가 있어야 똑바로 움직입니다.

실전 흐름: 진짜로는 이렇게 굴러갑니다

1) 이슈를 만든다

당연한 말 같지만, 여기서 반은 결정됩니다.
Codex는 마음을 읽는 존재가 아니라, 이슈를 읽는 존재니까요.

좋은 이슈는 길 필요는 없고, 대신 아래 네 개가 있어야 합니다.

• 무엇이 문제인지
• 어디까지 고칠 건지
• 어디는 건드리지 말아야 하는지
• 완료 기준이 뭔지

예를 들면 이런 식입니다.

제목: 회원가입 실패 시 에러 토스트 추가

배경
- 현재 회원가입 API 실패 시 사용자 안내가 없음

목표
- 실패 시 공통 에러 토스트 노출
- 중복 클릭 방지 상태 유지

범위
- web/app/signup 경로만 수정
- API 스펙 변경 금지
- 기존 디자인 시스템만 사용

완료 조건
- 에러 토스트 노출
- 로딩/disabled 상태 유지
- 테스트 추가

이슈가 이 정도만 돼도,
Codex는 “아무거나 열심히 하는 AI”가 아니라
“정해진 범위 안에서 일하는 동료”처럼 보이기 시작합니다.

2) assignee에서 Codex를 고른다

이 단계가 오늘 글의 주인공입니다.

Linear 문서 기준으로 이슈는 properties 사이드바의 assignee 필드에서 팀원이나 agent를 선택해 배정할 수 있습니다. 에이전트에게 일을 delegate하면, 책임자는 여전히 나이고, 에이전트가 내 대신 작업하는 추가 기여자로 붙는 구조입니다.

이 구조가 좋은 이유는 명확합니다.

완전히 AI에게 넘겨서 “누가 owner인지 모르는 상태”가 아니라,
이슈의 owner는 사람이고, 실행은 Codex가 맡는 구조라서 팀 운영이 덜 흔들립니다.

그리고 이게 진짜 실무에 맞습니다.
속도는 AI가 가져가고, 책임은 사람이 유지하니까요.

3) Codex가 Cloud에서 작업을 시작한다

Codex에게 이슈를 할당하면, Codex는 작업을 시작하고 업데이트를 다시 이슈에 남깁니다. 진행 상황은 Linear 이슈의 Activity에서 볼 수 있고, 더 자세한 내용은 task 링크를 통해 따라갈 수 있습니다. 작업이 끝나면 Codex는 요약과 완료된 task 링크를 남겨서 PR 생성 단계로 이어지게 합니다.

여기서 제일 좋은 포인트는
“AI가 뭘 하는지 안 보인다”는 불안이 꽤 줄어든다는 겁니다.

예전 AI 도구들은 가끔 이런 느낌이었죠.

“뭔가 하고는 있는데… 그래서 지금 어디까지 됐는데?”

반면 이 흐름은 이슈 안에서 진도가 보입니다.
그러니까 팀 입장에서는 새로운 툴을 쓴다기보다,
기존 이슈 흐름 안에 새로운 작업자가 한 명 추가된 느낌에 가깝습니다.

4) repo가 헷갈리면 코멘트로 못 박아준다

Codex는 이슈 문맥을 보고 작업할 environment와 repo를 고릅니다. 다만 애매하면 최근에 쓰던 environment로 떨어질 수 있어서, 저장소를 확실히 고정하고 싶다면 댓글에 @Codex fix this in org/repo처럼 명시하는 방식을 권장합니다.

실무에선 이 한 줄이 엄청 중요합니다.

모놀리포거나, 비슷한 repo가 여러 개 있거나, 프론트/백엔드가 나뉜 팀이면
이걸 안 적는 순간 Codex가 열심히 틀린 장소에서 성실하게 일하는 사고가 납니다.

제가 추천하는 패턴은 이겁니다.

@Codex 이 이슈 처리해줘.
repo는 myorg/frontend 로 고정하고,
signup flow 범위에서만 수정해줘.
pnpm lint, pnpm test까지 돌리고
변경 요약도 남겨줘.

핵심은 문장을 멋있게 쓰는 게 아니라
repo, 범위, 검증 기준을 적는 겁니다.

잘 되는 이슈는 따로 있습니다

Codex에게 바로 assign하기 좋은 이슈는 대체로 이런 종류입니다.

• 재현 가능한 버그 수정
• UI 문구/상태 처리 개선
• 테스트 추가
• 제한된 범위의 리팩터링
• CI 깨짐 복구
• 특정 파일/경로 안쪽 수정

반대로 아래 같은 일은 아직 사람이 먼저 잡아주는 게 낫습니다.

• 요구사항이 흐린 일
• 여러 팀이 얽힌 의사결정
• 아키텍처 방향 자체를 정해야 하는 일
• “이상하긴 한데 뭐가 문제인지 모르겠다” 류의 일

AI는 빠릅니다.
하지만 애매함을 사랑하진 않습니다.

이 흐름의 진짜 장점은 “일을 미는 비용”이 줄어든다는 겁니다

예전엔 이슈를 만들고 나서도 한 번 더 일이 있었습니다.

• 누구한테 줄지 정하고
• 배경 설명 다시 하고
• 관련 repo 말해주고
• 테스트 기준 말해주고
• “확인되면 PR 주세요”까지 말해야 했죠

그런데 Linear에서 바로 Codex에게 assign하는 방식은
그 전달 비용을 확 줄입니다.

이슈 자체가 이미 전달문이 되고,
Codex는 그 이슈를 읽고 바로 Cloud에서 일을 시작합니다.

한마디로,
이슈가 메모에서 실행 버튼으로 바뀌는 것입니다.

이 차이가 생각보다 큽니다.

그래도 마지막은 사람입니다

Codex는 실수할 수 있기 때문에 답변과 diff를 항상 검토해야 합니다.

역할을 정확히 나누는 것이 중요합니다.

• 이슈 정리: 사람
• 초안 구현: Codex
• 결과 검토: 사람
• 최종 merge 판단: 사람

이렇게 두면 제일 안정적입니다.

AI에게 키보드를 맡길 수는 있어도,
책임까지 아웃소싱하면 안 되니까요.

마무리

오늘 이야기의 요점은 거창하지 않습니다.

Codex를 쓰려면 꼭 별도 창을 열 필요가 없습니다.
Linear 이슈에서 바로 Codex에게 할당하면 됩니다.

그리고 그 순간부터 이슈는 더 이상 “나중에 누가 할 일”이 아니라,
지금 바로 Codex Cloud에서 실행될 수 있는 작업이 됩니다.

개인적으로 이 흐름이 좋은 이유는 딱 하나입니다.

개발자가 게을러질 수 있어서가 아니라,
개발자가 더 비싼 판단에 시간을 쓰게 해주기 때문입니다.

버튼 클릭 한 번으로
“이슈 작성자”가 아니라
“AI 동료를 지휘하는 사람”이 되는 경험.

생각보다 꽤 재밌습니다.