[후기] 현업에서 써먹는 자동화

아직 글이 작성중에 있습니다

먼저, 아래의 내용은 동아리에서 진행했던 발표 내용을 정리한 내용임을 알려드립니다.

관련 내용: 현업에서 써먹는 자동화, 발표 자료

Intro

오늘은 현업에서 써먹는 자동화라는 주제로 글을 작성하려고 합니다. 글을 시작하기에 앞서, 생산성 이라는 주제에 대해 간략하게 이야기해 보겠습니다.

생산성이란 무엇일까요?

생산성의 정의는 다음과 같습니다:

주어진 자원(시간, 노력, 비용 등)을 활용해 얼마나 많은 성과나 결과를 효과적으로 창출할 수 있는지를 나타내는 개념.

이를 프로그래머의 관점으로 바꾸면 다음과 같습니다:

주어진 시간 내에 효율적으로 고품질의 소프트웨어를 개발하고 유지보수할 수 있는 능력.

가장 중요한 부분은 주어진 시간 내라는 점입니다. 하지만 아무것도 없는 환경에서 주어진 시간 내라는 요소와 고품질이라는 두 요소를 동시에 챙기는 것은 사실상 불가능합니다. 또한, 개발뿐만 아니라 유지보수가 용이한 코드를 작성하는 것은 일반적으로 많은 시간이 소요되는 작업입니다.

그렇다면, 위에서 언급한 세 가지 요소(기한, 고품질, 유지보수)를 모두 충족하기 위해서는 어떻게 해야 할까요?

제가 생각하는 가장 좋은 방법은 자동화입니다. 특히, 반복되는 실수를 방지하고 구성원이 개발에만 집중할 수 있는 환경을 조성하는 자동화가 중요하다고 생각합니다. 오늘은 지난 2년 동안 회사에서 진행했던 자동화 사례에 대해 이야기해보겠습니다.

자동화

자동화의 정의

프로그래밍 영역에서의 자동화란:

반복적이거나 수동적인 작업을 사람이 직접 수행하지 않고, 소프트웨어나 도구를 통해 자동으로 처리하는 프로세스.

이러한 자동화를 통해 효율성을 높이고, 오류를 줄이며, 개발자들이 더 중요한 창의적인 작업에 집중할 수 있도록 도울 수 있습니다. 무엇보다 실패했지만 실패가 반복되지 않는 환경을 만드는 것이 중요합니다.

자동화하는 이유

자동화의 주요 목적은 두 가지입니다: 개발 경험의 일관화와 개발 효율성 향상입니다.

이해를 돕기 위해 식당 주문 API를 만들어 보면서 설명하겠습니다. API 스펙을 관리할 때, 다음과 같은 선택지가 있습니다:

• Excel
• Swagger
• Git Book
• 기타(예: Redocly, Slate)

한 개발자는 API가 많지 않을 것이라 예상하고 Excel을 이용하여 API 스펙을 관리하기로 결정했습니다. 해당 개발자가 정리한 식당 주문 API의 스펙은 다음과 같습니다:

Excel을 통해 API를 작성하는 것은 문제가 없지만, 현재는 거의 사용되지 않는 방식입니다. 그 이유는 다음과 같습니다:

• 변경에 취약하다.
  • API Endpoint나 Parameter, Request, Response의 필드 이름이 바뀌면, 타입 시스템을 통해 변경을 감지할 수 없다.
• 문서 관리가 어려워진다.
  • 실제 구현과 문서가 분리되어 있어 문서 관리에 어려움이 생긴다.
• 비즈니스 변화에 대응하기 어렵다.
• 결과적으로 수익 창출이 어려운 구조를 가진다.

따라서, 가치를 창출해야 하는 개발자의 입장에서 위의 Excel 방식은 단점이 너무 많습니다.

그렇다면, 위의 단점을 개선하기 위해서는 어떤 요소들이 필요할까요? 다음과 같은 요구사항이 있을 수 있습니다:

• 변경이 발생했을 때 타입 레벨에서 변경을 감지할 수 있으면 좋겠다.
• Frontend와 Backend를 위한 변경 감지 Plugin이 필요하고, 나아가 테스트 자동화도 이루어지면 좋겠다.
• (옵션) 스펙이 정의된 보편적으로 사용되는 프로토콜과 관련된 Parser도 필요하다.

이러한 요구사항이 반영된 무언가가 있다면, 비즈니스 요구사항이 추가되거나 프로그래머의 실수가 발생하더라도 빠르게 대응이 가능할 것입니다. 또한, Build Test Automation, API Test Automation 등이 가능해져 개발자의 생산성을 높여줄 것입니다.

사실 위의 개선 사항은 OpenAPI Spec을 통해 나름 보편적인 Protocol과 Parser가 제작되어 널리 사용되고 있습니다.

다시 정리하자면, 자동화하는 이유는 다음과 같습니다:

1. 관심을 가져야 하는 곳에만 집중하도록 환경을 조성한다.
2. 이를 통해 가치를 만들어내기 쉬운 구조를 가진다.

왜 자동화하는가?

자동화가 중요한 이유는 다음과 같습니다:

• 동료의 개발 경험(DX) 향상:
  • 자동 생성하여 빠른 개발 프로세스를 수립할 수 있다.
• 개발 일관성:
  • 추가할 때 자동으로 네이밍 및 일관된 방식으로 처리된다.
  • 자동으로 추측 가능성을 향상시켜 의사 소통 비용을 절감할 수 있다.
• 기능 확장 비용 절감.

위의 API 스펙 예시처럼, 스펙을 합의된 프로토콜로 정의할 수 있다면 동료의 개발 경험을 향상시킬 수 있습니다. 예를 들어, API 스펙을 자동으로 생성하여 기존에 없던 FE/BE 개발자 간의 빠른 개발 프로세스를 수립할 수 있습니다.

추가적으로, API 함수의 네이밍을 자동으로 결정하거나, API 스펙을 추가하는 함수를 제공하여 일관된 방식으로 API를 추가할 수 있습니다. 결과적으로 API 스펙을 추가할 때 부담스럽지 않은 경험을 제공할 수 있습니다.

자동화의 종류

자동화의 종류는 세 가지로 분류할 수 있습니다:

1. 도입 비용이 낮고, 즉각 도움이 되는 자동화.
2. 도입 비용이 많이 들지만, 미래에 도움이 되는 자동화.
3. 상황에 따라 적용해야 하는 자동화.

예를 들어 첫 번째 경우는 OpenAPI Spec을 이용해 Mockup 서버를 자동으로 생성하는 경우입니다. 두 번째 경우는 주로 새로운 라이브러리나 개발 프로세스를 도입하는 것을 예로 들 수 있으며, 마지막은 문화적 관점(Pull Request Title Check)에서 시도할 수 있는 자동화들이 있습니다. 이러한 것들은 주로 회사의 규모와 구성원의 성향에 따라 도입 여부가 결정됩니다.

오늘은 위의 세 가지 관점에서 도입할 수 있는 자동화에 대해 소개하겠습니다.

1. 도입 비용이 낮은 자동화

Mock Server AutoGen(with. OpenAPI)

용어 정리

OpenAPI:

• 정의: RESTful API를 정의하고 문서화하기 위한 표준 포맷.
• 관련 정보:
  • OpenAPI Initiative에 의해 관리됨.
  • API의 엔드포인트, HTTP 메소드, 요청/응답 구조 등을 기술한 기계가 읽을 수 있는 문서로 만들 수 있음.
  • 이를 통해 개발자 간의 협업이 용이해짐.
  • 기계가 읽을 수 있기 때문에 관련 Parser를 만들 수 있고, 이를 통해 API 테스팅, 문서 생성, 코드 생성 등의 자동화가 가능.

Mock Server:

• 정의: 실제 서버 없이도 API 요청에 대한 응답을 테스트할 수 있는 가상의 서버.
• 주로 다음과 같은 상황에서 사용됨:
  • API 개발을 완료하지 않은 상태에서 Client가 API와 상호작용하는 방식을 미리 테스트.
  • 외부 서비스에 의존하지 않고 독립적으로 기능 구현이 필요한 경우.

문제 파악 및 해결하고자 하는 문제

현재 재직 중인 팀에는 다음과 같은 두 가지 문제가 있었습니다

1. API 스펙만 정의되고 구현이 안 된 API를 Client 코드에 반영할 때, UI를 테스트하기 어려워진다.
   1. 해당 API는 항상 Unimplemented 에러를 표시하기 때문입니다.
2. 특정 Backend 프로젝트의 경우, Cloud에 배포되어야만 API 테스팅이 가능하다.
   1. 복잡한 Configuration 및 Proxy Setting으로 인해 Local에서 실행할 수 없었기 때문입니다.
   2. 따라서 UI만 변경해도 UI 테스팅을 위해 최소 20분의 배포 시간이 소요됨.

제작 과정

우선 Mock Server를 제작하여 문제를 해결하고자 했습니다. 그러나 Mock Server를 만드는 과정에서 다음과 같은 제약 사항이 있었습니다:

1. 현재 팀의 Frontend 개발 리소스가 이미 한계에 도달했습니다.
2. Mock Server를 제작하면 API Spec 변경에 지속적으로 대응해야 합니다.
3. 결국 대응이 불가능한 시점이 올 것이며, 그로 인해 Mock Server는 아무도 사용하지 않게 될 것입니다.

따라서, 보다 효과적인 해결책이 필요했고, Mockup 서버 생성 자동화를 도입하게 되었습니다.

자동화가 가능하다고 생각했던 이유는 다음과 같습니다:

1. OpenAPI는 기계가 읽을 수 있는 문서이기 때문에, 자동화 도구의 개발이 용이합니다.
2. 따라서 Parser가 존재할 것이라는 확신이 있었습니다.
3. Parser와 Dummy Data 생성 라이브러리를 조합하면 Mock Server 자동화를 구현할 수 있을 것이라 판단했습니다.

이런 이유로 npm-swagger 패키지를 리서치하던 중, 우연히 msw-auto-mock라는 패키지를 발견하게 되었고, 이를 통해 비교적 쉽게 Mock Auto Generation 기능을 도입할 수 있었습니다.

이와 같은 자동화 도입에 관심이 있으신 분들은 Use OpenAPI to auto-generate client side code and MSW mocks 글을 참고하시기 바랍니다.

좋았던 점

가장 큰 장점은 UI 테스팅을 위해 Backend 서비스를 실행하지 않아도 된다는 점입니다. 이로 인해 개발 과정에서의 시간 소모가 크게 줄어들었습니다. 또한, API Spec만 있으면 Backend 개발자와 함께 동시적으로 개발할 수 있어 협업의 효율성이 향상되었습니다.

아쉬운 점

하지만 자동 생성된 Mock 데이터가 항상 적절하지는 않았습니다. 예를 들어, 특정 API에서 반환되는 데이터가 Image URL이어야 하는데, 일반적인 string 데이터가 내려오는 경우가 있었습니다. 이로 인해 <Image /> 컴포넌트가 제대로 작동하지 않는 문제가 발생했습니다.

현재 이 문제를 해결하기 위해 msw-auto-mock 패키지에서 생성형 AI를 활용한 개선 작업이 있었으며, 곧 이를 회사 프로젝트에 적용할 계획입니다.

2. 도입 비용이 높은 자동화

해당 자동화는 프로젝트의 필요에 따라 적용해야 합니다. 디자인 시스템이 존재하는 경우에는 도입을 추천합니다.

Design Token, SVG AutoGen (With Figma Token)

용어 정리

Design Token:

• 정의: 디자인 시스템에서 색상, 글꼴 크기, 간격, 그림자, 테마 등과 같은 디자인 속성을 코드로 변환하여 일관된 스타일을 유지하고, 다양한 플랫폼에서 재사용할 수 있게 하는 표준화된 값입니다.

SVG:

• 정의: 확장 가능한 벡터 그래픽스를 의미하는 XML 기반의 그래픽 형식입니다. 주로 아이콘으로 사용되며, 동적으로 속성(크기, 색상 등)을 바꿔야 하는 이미지에 적합합니다.

문제 파악 및 해결하려는 문제

프론트엔드 개발자가 디자인 시스템을 설계할 때 겪는 가장 큰 문제는 다음과 같습니다:

1. 디자이너가 원하는 Design Token 변경에 대응하기 어렵다.
   • TailwindCSS, Emotion, Vanilla Extract 등 여러 CSS 프리프로세서를 사용하는데, 이에 맞춰 Design Token을 전부 제작하는 것은 상당히 어렵습니다.
2. SVG를 React Component처럼 사용하기 어렵다.
   • SVG 파일을 React Component로 변환할 수는 있지만, 모든 SVG 파일에 대해 일일이 변환하는 것은 시간과 노력이 많이 소요됩니다.

해결하는 방법

1. Figma Token과 Style Dictionary 사용하기

1번 문제는 Figma Token과 Style Dictionary를 활용하여 해결할 수 있습니다.

• Figma Token: Figma에서 정의한 디자인 속성을 JSON 형식으로 추출하여 개발자와 디자이너 간의 원활한 협업을 돕는 도구입니다. 디자이너가 변경한 스타일을 쉽게 반영할 수 있어, 코드의 일관성을 유지하는 데 기여합니다.

• Style Dictionary: Figma Token에서 추출한 디자인 속성을 다양한 플랫폼에서 사용할 수 있는 형식으로 변환해주는 도구입니다. 이를 통해 개발자는 필요한 디자인 속성을 쉽게 관리하고 사용할 수 있습니다.

WIP 부연 설명 필요

2. svgr-cli 사용하기

2번 문제는 svgr-cli를 이용하여 Token Injection이 된 Generation Template을 사용하여 해결할 수 있습니다.

• svgr-cli: SVG 파일을 React 컴포넌트로 변환하는 도구로, 커맨드 라인에서 쉽게 사용할 수 있습니다. Token Injection이 가능한 템플릿을 사용하면 디자인 속성을 SVG에 자동으로 적용할 수 있어, 수작업으로 SVG를 변환하는 데 소모되는 시간을 줄일 수 있습니다.

WIP 부연 설명 필요

3. 상황에 따라 적용해야하는 자동화

PR title/label checker(With. Github Action)

용어 정리

• PR (Pull Request): 코드 변경 사항을 코드베이스에 병합하기 위해 제출하는 요청입니다. PR을 통해 다른 개발자들이 코드 리뷰를 하고, 변경 사항을 승인하거나 피드백을 제공할 수 있습니다.

• GitHub Action: GitHub에서 제공하는 CI/CD 도구로, 자동화된 작업을 설정하여 소프트웨어 개발 프로세스를 효율적으로 관리할 수 있게 해줍니다.

문제 파악 및 해결하려는 문제

조직의 개발 규모가 일정 수준을 넘어가면서 여러 가지 문제가 발생했습니다:

• PR 형식 및 Commit 형식의 비일관성: 각 조직마다 PR과 Commit 형식이 다르게 작성되어 일관성을 잃었습니다.

• Master 브랜치에 무분별한 Merge: 특정 프로세스가 만족되지 않아도 Master 브랜치에 머지가 되며, QA 통과 없이 실수로 Merge되는 경우가 있었습니다. 또한, Build Pipeline이 통과되지 않았는데도 Merge되는 문제가 발생했습니다.

• 신규 인원의 문맥 파악 어려움: 새로운 팀원이 팀의 문화에 익숙해지기까지 시간이 걸리며, 이 과정에서 실수가 발생하는 경우가 많습니다. 심지어 경력자들도 실수를 범할 수 있습니다.

• 버그 발생 방지: 모든 Master 버전은 Build가 통과되어야 하며, 해당 시점에 QA가 통과되는 것이 Revert 시에 유용합니다.

이런 문제들이 조직의 규모가 커짐에 따라 자주 그리고 지속적으로 발생했습니다. 이러한 문제를 해결하기 위해 범조직적으로 공감대가 형성되었고, GitHub Action을 통해 이 문제를 해결할 수 있다고 판단했습니다.

제작해야 할 Action

• GitHub Pull Request Title의 형식을 조직의 규칙에 맞게 검사합니다.
• GitHub Pull Request의 Label을 규칙에 맞게 검사합니다.

결과적으로, 두 Action이 실패하면 Merge가 불가능하도록 블로킹하는 구조로 설정합니다.

제작 과정

if문이 여러개인 조건으로 인해 자체 제작

WIP 부연 설명 필요

좋았던 점

이러한 자동화를 통해 다음과 같은 긍정적인 결과를 얻을 수 있었습니다:

• PR 제목 관련 Review 필요 없음: 자동화로 인해 PR 제목을 검토하는 데 소요되는 시간을 줄일 수 있었습니다.

• 문맥 파악의 용이성: Conventional Commit Rule을 통해 모든 PR의 종류를 쉽게 파악할 수 있으며, GitHub Action Bot을 이용해 처음 사용자도 Fail 이유를 해결할 수 있게 되었습니다.

• Jira Ticket 관리의 용이성: 연결된 Jira Ticket을 쉽게 찾을 수 있어, 작업의 연속성을 높이는 데 기여했습니다.

아쉬운 점 및 개선하고 싶은 점

• 사내에서 사용하는 GitHub Action의 자체 제작 및 Versioning: 현재 사용하는 GitHub Action을 더욱 발전시키고, 버전 관리 시스템을 도입하고 싶습니다.

• Label Check의 if문에 대한 추상화 강화: Label Check와 같은 조건문에서의 추상화를 더욱 강화하여 유지 보수성을 높이고, 기능 확장을 용이하게 만들고 싶습니다.

도입하고 싶은 자동화

앞으로 도입하고 싶은 두 가지 자동화가 있습니다:

1. UI 자동 생성 서비스: v0
2. API Testing 자동화: Cats

UI 자동 생성 서비스 - v0

v0는 UI를 자동으로 생성해주는 혁신적인 서비스로, 개발자가 디자인 시스템을 기반으로 더욱 효율적으로 사용자 인터페이스를 구축할 수 있도록 도와줍니다.

API Testing 자동화 - Cats

Cats는 API Testing을 자동화하는 도구로, 테스트 케이스를 신속하게 생성하고 실행할 수 있도록 해줍니다. 이를 통해 API의 안정성과 성능을 지속적으로 검증하고, 문제 발생 시 빠르게 대응할 수 있는 환경을 구축할 수 있습니다.

아쉬운 점

하지만, v0와 같은 서비스를 사내에 도입하기 위해서는 다음과 같은 조건이 필요합니다:

• 자체적인 디자인 시스템: UI 자동 생성 기능을 효과적으로 활용하기 위해서는 조직 내에서 일관된 디자인 시스템이 구축되어 있어야 합니다.

• AI 엔지니어: v0와 같은 서비스의 최적화를 위해서는 AI 관련 지식과 경험을 갖춘 인력이 필요합니다.

이러한 이유로 현재로서는 v0의 도입이 불가능하다고 생각하고 있어 많이 아쉽습니다.

후기

오늘 소개해드린 자동화는 필자가 현업에서 설득과 함께 DRI(Directly Responsible Individual) 역할을 맡아 진행했던 사례들입니다.

자동화의 필요성을 느끼지 못해 도입을 포기한 경우도 있었고, 반대로 기회가 되어 즐겁게 도입한 사례도 있었습니다. 이러한 경험을 독자분들께 공유할 수 있어 매우 기쁩니다.

마지막으로 아래의 글을 쓰며 글을 마칩니다.

매년 이런 생각이 듭니다.

개발을 잘 하는 것은 어렵습니다. 회사에서 일을 잘한다고 인정받는건 더 어렵습니다.

그리고 함께 일하고 싶은 동료가 된다는 것은 더욱 더 어렵습니다.

하지만 동료의 Pain Point를 잘 읽어내고, 동료의 생산성을 개선해줄 수 있는 방법을 고민하다보면, 어느 순간 같이 일하고 싶은 동료가 될 수 있다고 믿습니다.

이 글을 읽는 모든 분들도 오늘 소개한 자동화를 통해, 팀에 더 큰 힘이 되는 동료가 되셨으면 좋겠습니다.