Device Flow로 만드는 안전한 개발로그 초안 발행 파이프라인

문제: 작업 기록은 남지만, 공개 가능한 글은 자동으로 남지 않는다

하루 동안 구현한 기능은 커밋과 변경 파일에 남지만, 그것만으로는 읽을 만한 개발로그가 되지 않는다. 특히 왜 이 방식을 골랐는지, 어디에서 막혔는지, 어떤 안전장치를 추가했는지는 커밋 제목만으로 복원하기 어렵다.

이번 작업의 목표는 AI가 작업 맥락과 공개 가능한 변경 정보를 바탕으로 초안을 만들되, 사람의 최종 검토를 건너뛰지 않도록 하는 것이었다. 그래서 결과물을 곧바로 발행하는 자동화가 아니라 검토 가능한 draft 생성 파이프라인으로 정의했다.

브라우저 승인 방식: GitHub Device Flow

자동화 스크립트가 장기 비밀번호나 개인용 API 키를 들고 있는 구조는 만들고 싶지 않았다. 대신 명령을 실행할 때마다 GitHub Device Flow를 시작하고, 터미널에 표시된 코드를 브라우저에서 직접 승인하는 흐름을 사용했다.

흐름은 다음과 같다.

1. 스크립트가 Device Flow 시작 API를 호출한다.
2. GitHub이 사용자 코드와 인증 URL을 돌려준다.
3. 사용자가 브라우저에서 로그인한 뒤 코드를 승인한다.
4. 서버는 승인 결과로 GitHub 프로필을 조회한다.
5. 설정된 관리자 숫자 ID와 일치할 때만 짧은 수명의 앱 인증 정보를 발급한다.

이 방식의 장점은 어떤 GitHub 계정을 사용할지 브라우저에서 명시적으로 고른다는 점이다. 로컬 CLI의 활성 계정이나 저장된 토큰에 의존하지 않으며, 인증 과정에서 받은 GitHub 인증 정보는 DB와 로그에 저장하지 않는다.

개발로그 전용 API를 기존 글쓰기 API와 분리했다

일반 게시글 API는 관리자가 직접 편집한 HTML과 Markdown 원본을 저장하는 용도다. 개발로그는 입력 구조와 검증 규칙이 다르다. 제목, 날짜, 주제 키, 여러 개의 회고 섹션, 기술 메타데이터를 받으며 공개 전 안전성 검사가 필수다.

그래서 개발로그는 별도 API와 서비스 계층으로 분리했다. 서버는 섹션을 Markdown으로 조립하고 HTML로 렌더링한 뒤 기존 HTML 정화 과정을 한 번 더 통과시킨다. 코드 블록과 링크 같은 개발로그에 필요한 표현은 유지하면서 스크립트 같은 위험한 HTML은 제거된다.

같은 날짜와 같은 주제 키로 다시 업로드하면 새 글을 계속 만들지 않고 기존 draft를 갱신한다. 제목을 조금 고치거나 설명을 보완해도 초안이 여러 개 쌓이지 않도록 한 선택이다.

공개 전 필터: 막고, 가리고, 마지막에는 사람이 읽는다

안전성은 한 가지 정규식으로 해결할 수 없어서 세 단계로 나눴다.

• 알려진 인증 정보 형태와 개인 키, JWT처럼 보이는 값을 감지하면 업로드를 거부한다.
• 운영자가 설정한 차단 목록에 조직명, 내부 도메인, 호스트 이름을 넣으면 대소문자와 관계없이 거부한다.
• Windows 경로, 네트워크 경로, 사설 IP는 본문에서 각각 일반화된 표기로 마스킹한다.

이 검사는 오류 응답에도 원래 값을 되돌려 주지 않는다. 민감한 문자열을 발견했다는 사실과 섹션 위치만 알려 준다. 그래도 규칙 기반 검사는 문맥을 완전히 이해하지 못하므로, API의 저장 상태는 항상 draft다. 실제 발행은 관리자 화면에서 글을 읽은 뒤에만 가능하다.

Device Flow는 OAuth App에서 별도로 켜야 했다

처음 Device Flow 시작 요청은 일반적인 OAuth 설정이 되어 있어도 바로 동작하지 않았다. GitHub은 이 App에서 Device Flow가 명시적으로 활성화되지 않았다는 오류를 반환했다.

이 문제는 코드의 재시도 로직으로 해결할 일이 아니었다. OAuth App 설정에서 기능을 활성화한 뒤에야 브라우저 승인 코드가 발급됐다. 인증 기능을 설계할 때는 애플리케이션 코드뿐 아니라 공급자 콘솔의 권한과 활성화 상태도 하나의 배포 조건으로 문서화해야 한다는 점을 다시 확인했다.

자동 태그와 테스트가 운영 흐름을 단순하게 만든다

개발로그에는 항상 개발로그 태그를 붙이고, 공개 저장소 메타데이터에서 확인한 언어와 기술 토픽은 허용된 이름으로 정규화해 추가할 수 있게 했다. 본문에서 임의의 단어를 마구 추출하지 않기 때문에 예상하지 못한 태그가 생기는 일을 줄일 수 있다.

인증 흐름은 시작, 승인 대기, 승인 성공, 만료·거절, 관리자 불일치까지 테스트했다. 개발로그 API는 draft 생성, 날짜와 주제 단위 갱신, 발행된 글의 덮어쓰기 거부, 안전성 검사, 관리자 권한을 테스트했다. 전체 테스트와 정적 검사까지 통과한 상태에서 수동 실행 도구를 추가했기 때문에, 이후에는 /devlog 명령으로 같은 절차를 반복할 수 있다.

다음 사용 흐름

하루 작업이 끝나면 먼저 공개 가능한 작업 기록을 수집한다. AI는 수집 결과와 당일 작업 맥락을 바탕으로 초안을 보여 주고, 사람은 내용과 표현을 검토한다. 승인된 초안만 API로 업로드하며 결과는 여전히 draft다.

이제 남은 과제는 더 많은 자동 발행이 아니다. 수집 결과가 충분하지 않은 날에는 AI가 추측으로 내용을 채우지 않도록 하고, 공개 범위가 애매한 작업은 초안에서도 제외하는 운영 규칙을 계속 지키는 것이다.