소시지에서 오믈렛까지

Source: Dev.to

아무도 정말 소시지가 어떻게 만들어지는지 보고 싶어 하지 않겠죠? 그 과정은 지저분하고, 화려하지 않으며, 보통 최종 발표에서 건너뛰게 됩니다 (그리고 오, 우리는 그게 얼마나 다행인지 모릅니다! 🤮🤮🤮)… 하지만 “소시지 만들기”를 건너뛰면 “완전한 오믈렛”을 절대 얻을 수 없습니다!

음, 소시지…

…하지만 오늘은 아침 식품에 대해 이야기하는 것이 아니라 기술에 대해 이야기합니다! 우리 세계에서는 대부분의 사람들이 테스트, 리팩터링, 툴링 같은 거친 디테일보다는 반짝이는 새로운 기능이나 거대한 비용 절감 이야기에 집중하고 싶어합니다. 이러한 “소시지 만들기” 활동이 없으면, 우리가 갈망하는 가속과 개선이 모두 포함된 완전한 DevOps “식사”는 언제나 아슬아슬하게 손에 닿지 않습니다.

우리 팀도 최근에 이를 직접 겪었으니, 오늘은 코드 품질을 향상시키기 위한 우리의 “소시지 만들기” 여정을 살펴보고, 그것이 DevOps 결과라는 “오믈렛”에 어떻게 직접 연결되는지 보여드리겠습니다.

소시지는 어떻게 만들어졌을까 🐖

많은 팀과 마찬가지로, 우리는 처음엔 그다지 규율이 없었습니다. 오해하지 마세요, 우리는 필요한 박스들을 모두 체크하고 있었습니다:

• 우리의 코드는 회사 공식 버전 관리 시스템에 저장되었습니다.
• 풀 리퀘스트는 거버넌스 기준에 따라 검토되고 승인되었습니다.
• 우리의 변경 사항은 CI/CD를 통해 배포되었습니다.
• 파이프라인에 의존성 분석 스캔이 포함되었습니다.

회사 입장에서는 우리의 DevOps 실천이 정상 궤도에 있었고… 조금은 진보적이라고 할 수 있었습니다. 하지만 자세히 들여다보니 방어구에 금이 가 있었습니다:

• 대부분의 PR 리뷰는 회사 규칙을 따르기 위한 형식적인 절차에 불과했습니다. 수백 줄에 달하는 변경 사항도 반분 안에 승인되는 경우가 있었습니다 (구식 “연필 휘두르기” ✏️).
• 테스트? 존재하던 작은 부분도 파이프라인에 통합되지 않았고, 직접 실행을 기억할 때만 실행되었습니다.
• 품질 분석 도구? 음…

우리는 빠르게 움직였지만, 가끔씩 깨지는 일이 있었습니다. 매번 코드 푸시가 다음과 같은 루프가 되었습니다:

1. PR 승인 받고 푸시.
2. 어라, 배포가 왜 깨졌지?
3. 오류를 고치고 새 PR을 연다.
4. 🤞 1번으로 돌아가기

우리의 목표는 더 빠르게 움직이는 것이 아니라 더 지속 가능하게 움직이는 것이 분명했습니다. 이를 위해서는 먼저 소시지를 만들어야 했습니다. 우리는 코드 품질을 최우선 과제로 삼기로 했습니다. 이것이 우리에게 의미했던 바는 다음과 같습니다.

툴링을 중앙 집중화 🎯

우리는 팀 전체가 채택할 최소한의 툴 세트를 조사하는 것부터 시작했습니다.

IMPORTANT – 이것은 워크스테이션에 대한 무거운 거버넌스를 말하는 것이 아니라, “우리 것”이 될 소수의 확장 프로그램과 툴에 대해 팀 합의를 이루는 것입니다.

어떤 툴이 승리할지 결정한 기준

• 해당 툴은 업계에서 널리 받아들여지고 있어야 합니다.
• 오픈 소스라면 🧟 “좀비 프로젝트”(즉, 최근 활동이 있는 프로젝트)가 아니어야 합니다.
• CI와 개발자의 로컬 에디터 모두에서 구현 가능해야 합니다.
• 개발자에게 거의 추가 작업을 요구하지 않아야 합니다. “선인장 🌵으로 안전벨트를 만들지 마세요.”
• 팀 고유의 오버라이드가 가드레일에 반영될 수 있도록 커스터마이징이 가능해야 합니다.

몇몇 툴은 이미 회사에서 제공하고 있습니다. 예를 들어 Blackduck과 SonarQube가 그것입니다. 이 툴들은 필수이거나 로드맵에 포함돼 있기 때문에 우리도 통합해야 했습니다.

파이프라인에 구현 🛠️

품질 툴 목록을 정의한 뒤, 우리는 코드를 임시 복사본(각 실행마다 생성되고 이후 파기되는 컨테이너)에서 파이프라인에 실행했습니다. 이는 모든 의존성과 특이점을 인식하게 만들며, 코드가 환경을 이동할 때 정기적으로 스캔해 실수나 보안 문제를 조기에 잡아냅니다.

IMPORTANT – 구현 ≠ 강제.

코드 품질을 개선하려는 팀이 가장 흔히 저지르는 실수는 감당할 수 있는 범위를 넘어서는 것입니다. 오랫동안 품질 검사를 하지 않았다면 초기 고통이 클 수 있습니다. 툴링이 일정 기간 사용된 뒤 명백한 문제들이 정리될 때까지 머지를 차단하지 않음으로써 전환을 완화하세요.

우리는 SonarQube가 이미 모든 PR을 스캔하고 있었지만(강제는 아니었음) 결과가 형편없다는 것을 발견했습니다: 수백 개의 보안 핫스팟, 수백 개의 코드 스멜, 그리고 모노레포 구조 때문에 보고되지 않은 커버리지.

• 보안 핫스팟 – 잠재적으로 악용될 수 있는 항목(예: “토네이도 주의보”).
• 코드 스멜 – 동작은 하지만 더 깔끔하거나 유지보수가 쉬워질 수 있는 코드.
• 코드 커버리지 – 자동화된 테스트가 실행한 코드 비율; 높은 커버리지는 포괄적인 테스트를 의미합니다.

다음 몇 주 동안 우리는:

1. 툴링이 신뢰할 수 있는 정보를 보고하도록 만들었습니다(멀티‑언어 모노레포용 맞춤 GitHub Actions 워크플로).
2. 테스트 실행, 결과 집계, 최종 데이터 전달 전략을 정의했습니다.
3. 프로덕션에 배포된 레거시 코드를 커버하기 위해 다수의 테스트를 작성했습니다.
4. 테스트하기 어려운 코드를 리팩터링해 많은 스멜과 핫스팟을 제거했습니다.

우리의 간단한 모토는: Get. To. Passing. 매 푸시마다 지표가 개선되는 것을 보는 것은 정말 보람 있었습니다—순수한 도파민이 솟구쳤습니다!

이제 우리는 소시지를 가졌습니다 🐷

오늘 우리는 자랑스럽게 보고합니다:

• 5개의 코드 스멜 (≈150개에서 감소)
• 0개의 보안 핫스팟 (≈130개에서 감소)
• 테스트 커버리지 > 85 % (0 %에서 상승)

“소시지 만들기” 작업이 결실을 맺어 훨씬 건강한 DevOps “오믈렛”을 제공했습니다.