이동욱

Problem

개발자가 카메라 HAL 패치를 검증하려면 최신 OS 이미지를 테스트 베드 서버에 직접 내려받아 시료에 업데이트(Fusing)하고, 빌드 산출물을 수동 패치로 만들어 merge해야 했습니다. 이 과정이 총 12시간 걸렸고, 단계마다 사람이 개입해야만 다음으로 진행되는 구조였습니다.

Approach

매일 정해진 시각에 최신 OS 이미지 조회 → 테스트 베드 반입 → 시료 Fusing → 산출물 패치 생성 → TDD 검증 → Pass 시 develop 자동 merge까지 전 단계를 무인 파이프라인으로 재구성했습니다. TDD Fail 시 해당 이미지를 무효 처리하고 직전 유효 이미지로 자동 Rollback하는 안전장치를 함께 설계했으며, 순차 처리의 병목이던 전체 시료 일괄 테스트 단계를 데이터로 분석해 프로젝트별 병렬 수행으로 바꾸는 안을 개발 조직에 제안, 채택시켰습니다.

Result

12시간 걸리던 파이프라인이 3시간 무인 파이프라인이 됐습니다(약 75% 단축). 진행 중 수동 개입 0회, Fail 시 자동 Rollback으로 안정성까지 확보했습니다.

Problem

개발자 패치가 merge되려면 평균 102분짜리 TDD 테스트를 통과해야 했는데, 동시에 처리할 수 있는 건수가 제한되어 요청이 몰리면 merge 대기열이 쌓였습니다. 시료(테스트 장비) 수 제약으로 병렬 증설은 불가능한 상황 — 테스트 자체를 빠르게 만드는 것이 유일한 해법이었습니다.

Approach

불필요한 수행을 구조적으로 제거했습니다. 기존에는 Fail이 발생해도 전체 테스트케이스를 끝까지 수행했지만, 개발자의 목적은 Fail 수정이므로 Fail 발생 즉시 중단하는 Fail-Stop을 도입했습니다. 또한 Heap leak 검사를 위해 전체 테스트를 2회 반복하던 구조를, 1회차부터 leak 검사를 켜 누수 의심 테스트케이스만 2회차에 재검사하도록 바꿔 반복 수행량 자체를 줄였습니다.

Result

TDD 평균 테스트 시간이 102분에서 73분으로 약 28% 단축됐고, merge 대기 병목이 완화되어 개발 흐름이 회복됐습니다.

Problem

신규 AP 칩셋이 출시될 때마다 운영 중인 카메라 CI에 해당 칩셋을 편입해 자동 테스트가 돌게 만들어야 합니다. 운영 중인 파이프라인을 직접 건드리는 작업이라 실수하면 기존 프로젝트 전체의 CI가 영향을 받고, 신규 칩셋 환경에서는 시료 Panic 같은 예측하지 못한 불안정성도 함께 옵니다.

Approach

첫 온보딩에서 Jira·Confluence 기반 업무·문서 관리 프로세스를 정착시키고, 이후 Build Enable → 파이프라인 Enable → 안정화로 이어지는 표준 절차로 반복 수행했습니다. 신규 환경에서 시료 Panic을 유발하는 테스트케이스를 식별·필터링해 파이프라인 안정성을 확보했습니다.

Result

여러 세대의 신규 칩셋을 운영 중인 CI에 영향 없이(무중단) 온보딩했고, 1회성 고위험 작업을 표준화된 반복 가능한 프로세스로 만들었습니다.

Problem

CI의 기반이던 테스트 자동화 프레임워크가 메이저 버전업되며 API가 대거 변경됐고, 테스트 진행 상태·결과를 callback URL로 전달하는 방식으로 바뀌었습니다. 기존 CI → 프레임워크 직행 구조로는 신규 버전과 통신할 수 없어, 운영 중인 CI를 세우지 않고 전환할 방법이 필요했습니다.

Approach

구버전 API를 사용하던 테스트 스크립트를 전수 조사해 신규 API로 리팩토링하고, 변경된 호출·응답 흐름을 중계할 릴레이 서버를 Node.js + Express로 직접 설계·구축했습니다. 영구 저장이 필요 없는 진행 중 데이터만 다루므로 저장소는 Redis를 선택해, 요구사항에 맞는 최소 구성을 유지했습니다.

Result

운영 중인 파이프라인을 중단 없이 신규 프레임워크로 전환했고, 전환의 핵심 컴포넌트인 릴레이 서버를 직접 만들어 남겼습니다.

Problem

OS 메이저 버전이 올라갈 때마다 이전 버전 대비 중복 코드 사용량(재사용률)을 측정할 필요가 생겼습니다. 일회성 수동 분석으로는 다음 버전에서 같은 작업을 처음부터 반복해야 하고, 측정 기준도 사람마다 달라질 수 있었습니다.

Approach

비교 대상인 target / origin 브랜치를 파라미터로 입력받아 SourcererCC로 중복 코드를 분석하는 파이프라인을 CI 위에 구축했습니다. 신규 버전이 나와도 파라미터만 바꾸면 동일 절차·동일 기준으로 반복 측정할 수 있습니다.

Result

수동 분석이 파라미터 입력 한 번으로 끝나는 자동화 파이프라인이 됐고, 버전마다 동일 기준으로 비교할 수 있어 측정 정합성을 확보했습니다.

Problem

CI는 구축보다 운영에서 신뢰가 결정됩니다. 정적분석, 현황 대시보드, 서버 환경 셋업 같은 파이프라인 주변 요소가 제각각 관리되면 품질 게이트 전체가 흔들립니다.

Approach

Jenkins 스케줄러 → 빌드 → Coverity 정적분석 리포트로 이어지는 주간 파이프라인을 무중단 운영하고, 신규 워크스테이션·노드의 init 스크립트를 리팩토링해 재현 가능한 셋업으로 표준화했습니다. CI 현황 대시보드(React · Node.js)를 유지보수하고, 운영 서버의 정기 보안 점검 위반사항을 조치했습니다.

Result

정적분석 품질 게이트가 상시 운영되고, 어떤 서버든 동일한 절차로 CI 환경을 재현할 수 있으며, CI 엔지니어와 개발자가 같은 대시보드로 상태를 공유합니다.

구성

PC 1대에 DevStack으로 Keystone · Nova · Neutron · Glance · Cinder · Horizon을 올리고, Internal Net(10.0.10.0/24) 위에 web · db · monitoring VM 3대를 배치했습니다.

격리

공유기 포트 포워딩을 두지 않아 외부 유입 경로 자체를 없애고, DHCP 범위(.2~.199)와 Floating IP Pool(.200~.220)을 분리했습니다. db-vm은 Floating IP 없이 출발지를 web-sg로만 허용해 web-vm 경유로만 접근됩니다.

IaC · CI

자원 생성·변경은 Terraform으로만 실행되게 하고 서비스는 cloud-init으로 배포했습니다. 노트북의 GitLab CE가 push마다 fmt · tflint · validate · tfsec 4종을 수행하며, 전체 삭제 후 terraform apply 1회로 동일 환경이 재생성되는 것을 검증했습니다.

문제

AI로 인해 기술은 빠르게 발전하고, 눈 떠보면 매일 새로운 기술과 개념이 등장하고 있습니다. 새로운 기술과 개념을 공부하고 체득한 뒤 이해한 내용을 글로 기록하는 기존의 학습 방법은 아직 필수적이라 생각합니다. 다만 변화하는 시대 흐름에 맞춰 지식을 학습하고 기록하는 방식도 어느 정도 변화할 필요가 있다고 느끼고 있었습니다.

구성

원문 → 위키 페이지 → 정적 사이트로 이어지는 파이프라인을 만들고, 에이전트에게 사서 역할을 부여했습니다. 원문 1건에 요약 페이지 1쪽이 대응하고, 새 자료가 기존 서술과 충돌하면 지우지 않고 양쪽을 남긴 뒤 모순으로 표시합니다. 사이트는 프레임워크 없이 파이썬 스크립트 하나로 렌더하고 Pagefind로 한글 전문 검색을 붙였습니다.

검증

역할을 문서가 아니라 기계 검사로 강제했습니다. 원문↔요약 1:1 대응, 페이지 간 링크 무결성, 원문이 발행물에 새어 나가지 않았는지를 각각 검사하는 스크립트가 CI에서 돌고, 머지 전에 통과하지 못하면 룰셋이 머지를 막습니다. 골든·결함 픽스처 26종으로 검사기 자체의 퇴화도 잡습니다.

배포

Terraform으로 S3 · CloudFront · ACM · Route53을 선언 관리하고, GitHub Actions에서 장기 자격증명 없이 OIDC로 역할을 맡아 배포합니다. 저장소를 공개할 때는 제3자 저작물인 원문을 히스토리 전체에서 분리해 별도 비공개 저장소로 옮겼습니다.