내부 개발자 포털로 업무 자동화하기

이번 블로그에서는 내부 개발자 포털(IDP)인 Port를 사용해 사내 블로그 포스팅 프로세스를 자동화한 썰을 풉니다. 인포그랩에서는 블로그를 포스팅하기 위해 매일 10분 이상씩 하던 단순 반복 작업을 클릭 한 번에 동작하도록 했습니다. 그 결과, 개발자, 테크니컬 라이터의 스트레스를 줄여 더 중요한 업무에 집중할 수 있는 환경을 만들었습니다.

반복 작업을 줄이는 건 단순히 시간만 단축하는 것이 아닙니다. 수많은 사람이 단순 작업을 반복하느라 더 유용한 가치를 만드는 데 시간을 쓰지 못하고 있습니다. 이러한 작업을 줄이면 더 큰 가치를 창출하는 업무 시간을 확보할 수 있습니다. 이에 인포그랩에서는 수많은 교육 자료와 블로그의 배포 프로세스를 자동화하여 멤버들이 더 가치 있는 작업에 주력하도록 돕습니다.

내부 개발자 포털이란?

내부 개발자 포털(IDP)은 사내의 수많은 도구와 기능, 그리고 프로세스를 통합한 플랫폼입니다. 이는 개발자가 클릭 한 번으로 인프라를 배포하거나, 자신이 만든 서버를 통합적으로 관찰할 수 있도록 합니다. 개발자는 Git을 사용해 코딩하고, 내부 개발자 포털의 버튼만 클릭하면 됩니다.

내부 개발자 포털은 아래 세 가지 구성 요소로 나눌 수 있습니다.

• 블루프린트 : 인프라나 소프트웨어 등을 추상적으로 정의한 스키마입니다. Kubernetes 클러스터나 네임스페이스부터 배포 환경, 블로그 포스트까지 필요에 따라 무엇이든 정의할 수 있습니다.
• 서비스 카탈로그 : 블루프린트를 바탕으로 실제 어떻게 각 요소(entity)가 구성되어 있는지를 확인하는 창입니다. “특정 네임스페이스에 엮여 있는 Git 프로젝트들” 처럼 요소끼리 어떻게 연결되었는지를 그래프로 확인할 수 있습니다.
• 셀프 서비스 : 수동 프로세스를 자동화해 만든 하나의 작업입니다. 예시로는, “네임스페이스 지우기”, “파이프라인 동작시키기” 등이 있습니다. 작업을 실행하면 백엔드 서버(Webhook, GitHub Action, …)가 동작합니다.

내부 개발자 포털을 인포그랩에 적용하기

저는 내부 개발자 포털을 처음 접하고 제일 먼저 ‘지금 쓰고 있는 블로그를 배포하는 프로세스’를 자동화하고 싶었습니다. 그래서 사내 토이 프로젝트로 ‘내부 개발자 포털을 이용한 블로그 포스팅 자동화 시스템’을 만들었습니다. 이번 프로젝트의 소스 코드는 이곳에서 확인할 수 있습니다.

현재 프로세스 분석하기

인포그랩이 현재 어떻게 블로그 포스팅을 하고 있는지 정리했습니다. 아래는 블로그 하나를 작성하기 위해 거쳐야 하는 수많은 단계를 나열한 것입니다. ‘블로그를 노션에 작성’하는 프로세스는 별다른 개선 사항이 없었습니다. 하지만 노션에 있는 블로그를 Git으로 배포하는 프로세스는 다음 문제가 있었습니다.

첫째, 비개발 직군 멤버가 회사 블로그를 쓰기 불편했습니다. 회사 블로그는 개발자들만 작성하지 않습니다. 오늘날 테크니컬 라이터, 기획자, 디자이너 등 여러 직군의 사람이 자신의 노하우를 블로그로 작성합니다. 익숙하지 않은 마크다운 문법과 Git을 사용하면 많은 스트레스를 받습니다.

둘째, 불필요한 반복 작업이 많습니다. VS Code, Notion, GitLab 등 여러 도구를 사용해 자잘한 수정을 거쳐야 합니다. 특히 이미지의 이름을 바꾸는 일은 정말 고역입니다. 하지만 이러한 부분이 자동화가 불가능한 영역이 아니기에 개선하고 싶었습니다. 또한 오로지 노션과 내부 개발자 포털만 가지고 블로그를 손쉽게 배포하고 싶었습니다.

1 단계. 노션에 블로그를 작성

2 단계. 노션에 있는 블로그를 코드로 작성 후 푸시

회사의 컨벤션 정리하기

인포그랩에는 효율적인 협업을 위해 많은 컨벤션이 있습니다. 예를 들어 GitLab 이슈를 만들 때는 이슈 제목을 [Blog] <title> 형식으로 만들고, 브랜치 이름은 issue<issue_number>-<file-name> 형식으로 만들어야 합니다. 또한 지난 포스팅에서도 언급했듯이 효과적인 커밋 컨벤션을 지켜야 합니다. 저는 내부 개발자 포털로 커밋 컨벤션, 이슈와 브랜치 컨벤션 등을 자동화하기로 했습니다.

커밋 컨벤션

export function formatCommitMessage(title: string, issueIid: number) {
  return `📝 Docs(블로그): ${title} 포스트

#${issueIid}`
}

블로그 이슈 컨벤션

export function formatIssueDescription(title: string) {
  return `
# 다음 지침을 따르십시오.

- [x] 제목이 간결한가?
- [x] 적절한 feature 에픽을 선택하였는가?
- [x] 적절한 마일스톤을 선택하였는가?
- [x] 적절한 레이블을 추가하였는가? (필수: \`type\`)
- [ ] 연관 아이템을 연결하였는가?

# 설명

${title}`
}

블로그 메타데이터

export function formatBlogMetadata(data: BlogMetadata) {
  return `
summary: ${data.summary}
id: ${data.id}
categories: ${data.categories.join(', ')}
tags: ${data.tags.join(', ')}
status: ${data.status}
authors: ${data.author}

`
}

그 밖의 네이밍 규칙들

• 이슈 제목: [Blog] <블로그 제목>
• 브랜치 이름: issue<issue_number>-<file-name>

블로그 블루프린트 정의하기

블루프린트란 인프라나 소프트웨어 등을 추상화한 것을 의미합니다. 전 블로그를 추상화해 블루프린트를 정의했습니다. 블로그 블루프린트를 정의하려면 블로그에 필요한 속성을 정리해야 합니다. 노션에서 블로그를 작성하므로 노션 URL과 작성자 정보가 속성으로 필요했습니다.

또한 대부분은 이슈와 Merge Request를 만든 후 그 아래에서 작업하는데요. 이를 반영해 내부 개발자 포털에서 Blog 블루프린트를 이슈와 Merge Request 블루프린트에 연결(relation)하였습니다. 최종 결과는 아래 그림과 같습니다.

셀프 서비스(백엔드) 개발하기

이제 이 블로그를 포스팅하는 프로세스를 자동화할 차례입니다. 셀프 서비스는 수동 프로세스를 자동화한 작업입니다.

자동 프로세스를 수행하는 백엔드가 필요하기 때문에 이번 프로젝트에서는 AWS SAM(Serverless Application Model)을 사용하여 개발했습니다. 사내 프로젝트이기 때문에 트래픽이 많지 않을 것이고, AWS Lambda는 비용이 저렴하고 배포가 쉽기 때문에 선택했습니다. 프로그래밍 언어는 향후 유지보수를 위해 다른 개발자들도 보편적으로 사용하는 TypeScript(Node.JS)를 선택했고, GitLab SDK와 Notion SDK로 각각의 API를 사용했습니다.

내부 개발자 포털과 셀프 서비스의 가장 큰 장점은 ‘**유저가 딱 내부 개발자 포털만 알면 된다’**는 것입니다. 그래서 유저는 내부 개발자 포털(여기서는 Port를 선택)에 클릭으로 요청만 하면 되도록 설계했습니다.

작업에 앞서 설계한 개략적인 흐름도는 아래와 같습니다.

실제 적용하기

아래는 인포그랩에서 실제 사용하는 내부 개발자 포털입니다. 블로그 각각에 얽힌 작성자와 이슈, Merge Request 등을 한눈에 파악할 수 있습니다. 아울러 여러 곳에 흩어져 있던 교육 블로그, 사내 블로그 등을 통합하여 쉽게 관리할 수 있습니다. 이렇게 하면 개발자는 물론이고 Git에 익숙하지 않더라도 모든 사람이 손쉽게 작업을 진행할 수 있게 됩니다.

인포그랩은 내부 개발자 포털로 블로그 작성, 배포 과정을 간소화했습니다. 이로써 개발자와 테크니컬 라이터가 블로그 포스팅을 할 때마다 번번이 이슈와 브랜치, Merge Request를 만들지 않아도 됐고요. 노션에서 블로그를 작성한 뒤, VS Code로 다시 편집하는 수고를 덜었습니다. 섬네일 이미지 파일명을 회사 매뉴얼에 맞춰 작성 또는 수정하지 않아도 됐고요. 유튜브 영상 소스를 입력할 때, 유튜브 홈페이지에서 ‘소스 코드 복사’를 눌러 VS Code에 붙여넣기할 필요도 없어졌습니다.

수정 사항을 반영하기도 좋아졌습니다. 이전에는 아무리 긴급해도 반드시 거쳐야 하는 작업이 많았지만 이제는 여러 단계를 자동화해 신속히 재배포할 수 있습니다. 결과적으로 MTTR(평균 수정 시간)을 개선하여 한 층 더 나은 DevOps 조직으로 발돋움하였습니다. 아울러 인포그랩 블로그에는 필수로 들어가야 하는 몇 가지 문법이 있습니다. 기존에는 이러한 문법을 사람이 직접 검사했다면 이제는 내부 개발자 포털에서 자동으로 검사합니다. 검사가 실패한다면 배포를 원천 차단합니다.

아쉬운 점과 개선할 점

회사 블로그를 포스팅하는 업무 프로세스를 개선하기는 했지만 도구를 잘 사용할지 의문이 들었습니다. 블로그는 한 번 작성하면 이후에는 보통 수정하지 않기 때문입니다. 앞서 정리했던 수동 프로세스를 한 달에 한 번 정도만 반복하면 되기 때문에 사람들의 불만이 크지 않았던 것 같습니다. 그렇기 때문에 이번 자동화 시스템은 블로그 포스팅 측면에서 큰 호응을 얻지는 못했습니다.

하지만 원래의 의도와는 조금 다른 업무에서 좋은 반응을 받고 생산성을 높일 수 있었습니다. 인포그랩은 지금 교육 콘텐츠를 제작하고 있습니다. 교육 콘텐츠는 피드백을 받거나 기술이 업데이트될 때마다 수정한 후 배포해야 합니다. 이렇게 자주 수정해야 하는 상황에서는 내부 개발자 포털이 빛을 발할 수 있었습니다. GitLab에서 내려준 통계에 따르면 현재 교육 콘텐츠 배포 주기가 0.6일로, 굉장히 빠르고 탄력적으로 자료를 만들고 있다는 것을 알 수 있습니다. 교육 자료도 애자일하게 만들고 있는 것입니다!

앞으로는 인포그랩의 개발자나 엔지니어들이 손쉽게 배포하고 지울 수 있는 포털을 만들 계획입니다. 또한 회사 비품 관리와 같은 개발 이외 업무도 내부 개발자 포털에서 관리할 예정입니다. 이렇게 조직의 다양한 업무를 내부 개발자 포털에서 관리하면 구성원들에게 폭넓은 인사이트를 주고, 업무 편의를 높일 수 있을 것이라 믿습니다.

마무리

내부 개발자 포털을 사용하면 블로그 포스팅 업무를 자동화하는 것 이외에도 상상하는 모든 업무를 자동화할 수 있습니다. 하지만 각자의 비즈니스 로직에 따라 꼭 맞는 블루프린트 설계와 셀프 서비스 개발이 필요합니다. 조직 구성원들은 복잡한 절차나 반복 작업을 최소화하고, 자신의 진짜 중요한 업무에만 집중할 수 있습니다. 높은 생산성을 보장하는 내부 개발자 포털을 만들어 구성원이 더 만족하는 팀을 만들어 보아요.

인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련 지원이 필요하시면 문의하기 로 연락해 주십시오.