인턴십을 시작한 계기
저는 ICT 학점연계 인턴십 프로그램을 통해 AB180에서 인턴십을 시작하게 되었습니다. 원래는 4개월 예정이었지만, 업무와 배움이 흥미로워 2개월을 더 연장하여 결과적으로 총 6개월간 인턴십을 수행했습니다.
AB180은 마케팅 솔루션을 제공하며, 다양한 기업의 성장을 돕는 여러 제품을 보유하고 있습니다.
저는 그중 Airbridge라는 MMP 툴과 관련된 Data Pipeline 조직의 연동 스쿼드에서, 비용 연동 시스템과 대시보드 백엔드 API 개발을 담당했습니다.
수행한 일
제가 맡았던 주요 업무 중 하나는 광고 매체에서 받아오는 광고 비용 데이터를 Airbridge 대시보드에서 편리하게 조회·분석할 수 있도록 연동 로직을 개선하고 고도화하는 일이었습니다.
작은 개선부터 의미 있는 성과까지 다양한 작업을 수행했으며, 그중 한 사례를 아래에 소개합니다.
비용 연동 배치 E2E 테스트 시스템 개발
비용 연동 시스템은 Airflow로 구성되어 있으며, 4시간마다 약 2시간 50분~3시간에 걸쳐 대규모 배치 작업을 진행합니다.
이 과정에서 광고 비용 데이터를 외부 매체의 API를 호출하여 수집하고 Airbridge의 데이터 포맷에 맞게 변환하여 Snowflake에 삽입하게 되는데, 한 번의 배치에서 약 1억 4천만 건의 데이터가 삽입됩니다.
불필요한 데이터를 필터링하고 조건에 따라 집계함에도 이 정도 규모가 나오며, 삭제되는 데이터까지 합치면 한 번의 배치에서 다루는 데이터량은 더욱 방대해집니다.
이렇게 대량의 데이터를 처리하다 보니, 데이터 정합성과 테스트가 무엇보다 중요합니다. 기존의 정합성 테스트 과정은 다음과 같았습니다.
1.
기존 운영 환경의 코드로 결과를 생성합니다.
2.
개발 환경에 배포하고, 동일하게 결과를 생성합니다.
3.
두 결과의 차이를 쿼리로 비교하고, 그 결과를 구글 스프레드 시트로 정리합니다.
기존 테스트 프로세스는 아래와 같은 문제가 있었기 때문에, 이를 개선하기 위한 작업을 진행했습니다.
•
테스트 과정이 매우 번거롭고 시간이 많이 소요됨
•
비용 연동 배치 시스템은 외부 API를 호출해 데이터를 수집하기 때문에, 운영 환경에서 배치가 실행되는 시간에 테스트를 돌릴 경우 광고사의 API 호출 제한에 걸릴 우려가 있음 → 테스트 가능한 시간대가 제한적
•
Airflow를 띄우고 배치를 돌린 뒤, DB를 쿼리하고 시트를 작성하는 과정이 개발자에게 큰 부담이 됨
개선 시도
기존에는 테스트 시간을 단축하고 API 제한을 피하기 위해, 특정 고객사나 특정 매체만 선택해 실행할 수 있는 옵션이 존재했습니다.
하지만 이러한 방식은 부분적인 시나리오만 확인할 수 있어, 전체를 검증하기 어렵다는 문제가 있었습니다.
이러한 한계를 극복하고자, 다음과 같은 목표를 설정했습니다.
•
외부 API 제한에 영향을 주지 않을 것
•
테스트 실행 시간을 단축할 것
•
전체 앱 또는 고객사를 대상으로 실행하더라도 무리가 없을 것
•
개발자가 전체 E2E 과정을 쉽게 수행할 수 있도록 할 것
그리고 테스트 프로세스를 구조적으로 개선하는 작업을 진행했습니다.
1. 불필요한 Task Skip
가장 먼저, 그리고 가장 쉬운 접근은 불필요한 Task들을 건너뛰도록 설정하는 것이었습니다.
예를 들어, Druid에 인덱싱하는 단계나, 다음 배치를 위해 데이터를 세팅하는 단계는 테스트와 직접적인 관련이 없으므로 이러한 Task들을 선택적으로 Skip할 수 있도록 구현했습니다.
이때, DAG에 추가적인 Task가 등록되더라도 기존 로직이 영향을 받지 않도록 유연하게 처리했습니다.
2. API 호출부 대체
비용 연동 배치 시스템에서 가장 prod 환경에 영향을 많이 주는 부분은 외부 API를 호출하는 작업입니다.
이 두 가지 Task가 전체 1시간 10분 정도의 러닝 타임을 차지하므로, 이 부분을 대체하기로 했습니다.
옵션 A) Mock API 서버 만들기
가장 먼저 시도한 방법은 Mock API 서버를 구축하는 것이었습니다.
외부 API를 호출하는 대신, 미리 저장해둔 데이터를 내려주는 API 서버를 만들어, 테스트 시 해당 서버를 호출하는 방식입니다. 초기에 실제 데이터셋을 수집해두고, 이를 기반으로 DAG를 실행했을 때 기대한 결과가 나오는지 검증하려 했습니다.
하지만 이 방식에는 다음과 같은 한계가 있었습니다.
•
매체가 추가될 때마다 별도의 Mock 데이터를 생성하고 유지해야 함
•
API 응답 구조가 바뀌거나 새로운 고객사가 추가될 때마다 Mock 서버도 계속 수정해야 함
•
Edge Case를 전부 반영하려면 Mock 데이터를 주기적으로 최신화해야 하며, 이 관리 포인트가 과도하게 늘어남
결과적으로 유지보수에 비해 실익이 크지 않아, Mock API 방식은 실제 적용하지 않기로 결정했습니다.
옵션 B) 장애 복구/분석 용으로 남겨두던 운영 환경 데이터셋 활용하기
비용 연동 시스템은 외부 API 호출 결과를 S3에 저장하고, 이후 Task에서 해당 데이터를 사용하는 구조입니다.
결과값을 s3에 올려두는 이유는 추후 장애가 발생했을 때 원인을 파악하거나, 복구를 더 빠르게 하기 위함입니다.
장애 복구/분석을 위해 남겨두는 이 데이터셋은 배치마다 자동으로 업데이트되므로, API 호출 대신 운영 환경 데이터셋을 가져와 테스트용 경로(s3://.../batch-dev/...)에 복사하는 방법을 적용했습니다.
Airflow 내에서 BranchOperator를 사용해 다음과 같은 실행 분기 구조를 만들었습니다:
•
옵션 1: 외부 API를 호출하고, 그 결과를 s3://.../batch-dev/...에 저장
•
옵션 2: 외부 API는 호출하지 않고, 운영 환경(s3://.../batch/...)에 저장된 파일을 batch-dev 경로로 복사
이 구조 덕분에 테스트 시에는 실제 API를 호출하지 않고도 전체 DAG 흐름을 그대로 검증할 수 있게 되었고, 실제 시스템 로직과 거의 동일한 조건에서 테스트가 가능해졌습니다.
해당 방식 도입 이후, 테스트 실행 시간은 기존 51분에서 1분으로 단축되었고, API 호출 제한을 우려하지 않고 반복 테스트를 수행할 수 있게 되었습니다.
3. E2E 수행 과정 간소화
이전까지는 테스트 결과를 수동으로 정리해 QA 시트를 작성하고, 이를 PR에 첨부하는 작업을 반복해야 했습니다. 한 번에 정상 동작하면 좋지만, 문제 발생 시 수정 → 다시 실행 → 시트 재작성의 루틴이 개발자에게 반복적인 부담이 되었습니다.
그래서 이 QA 시트 생성 과정을 자동화하기로 결정했습니다.
우선 GitHub PR에 달린 코멘트로부터 테스트를 트리거하도록 했습니다.
이 방식을 선택한 이유는 다음과 같습니다.
•
PR 코멘트에 남겨진 QA 실행 기록을 통해, 누가 언제 어떤 설정으로 테스트했는지 쉽게 파악할 수 있음
•
개발자가 원하는 시점에 테스트를 실행할 수 있어 작업 흐름을 유연하게 관리할 수 있음
•
구현 난이도가 상대적으로 높지 않음
자동화를 위해 파이썬으로 QA 시트를 자동으로 생성해주는 별도의 코드를 작성했고, GitHub Actions에서 PR 코멘트를 모니터링하도록 설정했습니다.
PR에 특정 키워드(.qa)가 달리면, 댓글 안의 코드블록에 포함된 JSON 데이터를 읽어 QA 시트를 자동 생성합니다. 완성된 모습은 다음과 같습니다.
이제는 매번 수동으로 시트를 작성해 PR에 첨부하던 절차를 간소화하여, 테스트 반복이 필요하더라도 훨씬 효율적으로 진행할 수 있게 되었습니다.
결과
이제 비용 연동 시스템에서 빠르고 정확한 E2E 테스트가 가능해졌고, GitHub Actions를 활용한 자동화를 통해 개발자가 훨씬 쉽게 테스트를 진행하고 히스토리를 관리할 수 있게 되었습니다.
새롭게 도입된 테스트 시스템은 팀 내에서도 표준 프로세스로 자리잡아, 안정적으로 활용되고 있습니다.
회사 문화
인턴 생활을 하면서, AB180이 가지고 있는 조직 문화와 엔지니어링 문화가 상당히 인상 깊었습니다. 몇 가지를 꼽아보자면 다음과 같습니다.
1.
KT(Knowledge Transfer)
매주 진행되는 엔지니어링 모임으로, 조금 우선순위가 낮더라도 큰 임팩트를 낼 수 있는 주제를 발굴·조사하여 팀원들과 공유하고 토론하는 시간입니다.
주로 기술적인 트렌드나 서비스 운영 노하우 등을 다루는데, 이를 통해 새로운 아이디어를 접하고 팀 전체가 기술 역량을 골고루 높일 수 있었던 점이 인상 깊었습니다.
그리고 이는 별도로 기록으로 관리되어서, 꽤 이전의 KT기록들 또한 제가 보고 학습할 수 있었습니다.
2.
꼼꼼한 코드 리뷰
모든 코드가 머지되기 전 반드시 코드 리뷰 과정을 거치며, 리뷰가 상당히 꼼꼼한 편입니다.
단순히 “이건 잘못됐다”가 아니라, 왜 이렇게 해야 하는지 또는 더 좋은 방법은 무엇인지를 구체적으로 논이하기 때문에 매 리뷰 때마다 크게 배울 수 있었습니다.
이러한 과정 덕분에 코드 품질이 올라갈 뿐 아니라, 엔지니어링 팀 전체의 역량이 점진적으로 성장하는 것을 체감했습니다.
3.
테스트 문화
AB180에서는 Codecov를 도입하여서 테스트 커버리지를 90% 이상 유지하는 것을 목표로 합니다.
물론 커버리지가 전부를 말해주진 않지만, 지표를 도입함으로써 테스트가 누락되지 않도록 신경 쓰고, 문제가 발생했을 때 빠르게 대처할 수 있는 환경을 갖추고 있습니다.
실제로 많은 부분이 자동화 테스트로 커버되다 보니, 배포 전후로 얻는 안정감이 꽤 컸습니다.
4.
포스트모텀(Postmortem) 문화
장애나 문제가 발생하면, 회사에서는 포스트모텀을 진행하여 재발 방지책을 세우는 것을 원칙으로 합니다.
•
미리 방지할 수 없었는지
•
더 빨리 인지할 수 없었는지
•
더 빨리 복구할 수 없었는지
이 세 단계를 기준으로 문제 상황을 분류·분석하고, 우선순위를 최상으로 부여해 재발 방지 작업을 빠르게 진행합니다.
이런 프로세스가 잘 정착되어 있어, 같은 유형의 오류가 반복되지 않도록 체계적으로 개선하는 문화를 갖추고 있다는 점이 인상적이었습니다.
5.
개선을 장려하는 문화
회사에서 진행하는 1-on-1과 주간 미팅에서는 팀 내에서 개선할 것들을 제시하는 시간이 있습니다.
개발팀 내부에선 주마다 1번씩 팀 내 연동 프로세스를 개선할 만한 사항을 논의하는 시간을, 그리고 전사 구성원들이 제품의 개선사항을 제시하는 IdeaPark라는 문화도 있습니다.
이런 부분 덕분에 늘 문제 의식을 가지고 주변을 살펴보며 작은 부분도 놓치지 않으려 노력하고, 의견을 제시하게 되었습니다.
물론 제시된 모든 아이디어들이 받아들여진 것은 아닙니다. 몇몇 아이디어들은 너무 투입 시간 대비 효용이 안 나온다거나, 우선순위에 밀려서 기각되기도 했습니다.
하지만, 몇가지 아이디어는 실제 팀 내에서 채택되었고 작업을 하였습니다.
처음엔 의견이 거절되는 것이 익숙지 않았지만, 점차 적극적으로 제안을 이어가면서 제안이 거절되더라도 그 과정을 통해 많은 것을 배울 수 있었습니다.
배움
인턴 생활을 통해 얻은 기술적인 성장과 조직에서 배운 소통 방식을 따로 떼어놓고 이야기하기 어려울 정도로 많은 것을 배웠습니다.
더불어, 비용 연동 로직을 직접 다루면서 대용량 데이터를 다루는 경험이나 배치 구조 설계 같은 백엔드 엔지니어링의 핵심적인 부분도 경험할 수 있었습니다.
많은 리소스를 쓴다해서 그것이 큰 임팩트로 이어지는 것이 아닌 적절한 타겟을 방법을 채택하는 것이 더 큰 임팩트를 이끌어 나간다는 사실을 깨달았습니다.
적절한 최적화와 구조적 개선이 비용을 줄이면서도 시스템 효율을 높인다는 걸 여러 사례를 통해 확인했습니다.
무엇보다 인턴 생활에서 가장 인상 깊었던 부분은 회사에서 배운 소통 방식입니다. 회사의 대부분의 사람들은(의식하시는지는 모르겠지만) 상대방에게 요청이나 질문을 할 때 다음과 같은 순서로 질문하십니다.
1.
핵심 요청을 먼저 밝히기(두괄식)
ex) 지금 OOO 고객사의 페이스북 비용 데이터를 확인해줄 수 있을까요?
2.
추가 요구사항이나 상황 설명으로 상대방의 이해를 돕기
ex) 구체적으로는 어제 데이터가 10% 이상 누락되는 현상이 있어서, 원인을 파악하기 위함입니다.
3.
ROQ(Reason Of the Question), 즉 왜 이런 요청을 하는지에 대한 배경과 목적을 끝에 제시하기
ex) ~한 가설이 있는데, 이러한 가설이 맞다면 확인한 데이터에서 ~한 것이 나타날 것 같습니다.
이렇게 세 단계로 대화를 구성하면, 상대방이 맹목적인 요구가 아니라 분명한 이유와 맥락을 갖춘 요청이라는 것을 이해하게 됩니다.
자연스럽게 더 나은 대안을 함께 논의할 수 있고, 혹시 제가 미처 고려하지 못한 방법이 있다면 상대방이 제안해주기도 합니다. 덕분에 협업 과정이 훨씬 매끄러워졌고, 문제 해결 속도도 빨라졌습니다.
또한, 단계별로 정보를 제공함으로써 상대방의 이해도에 따라 소통 수준을 조절할 수 있어 더욱 효율적이었습니다.
아쉬운 점
돌이켜보면, 의견이 거절당했을 때 너무 빨리 수긍해버린 순간들이 아쉽습니다. 빠른 결정도 중요하지만, 왜 안 된다고 생각하는지와 이 기능이 정말로 필요한지를 조금 더 깊이 파고들어 설득했으면 어땠을까 하는 생각이 들기 때문입니다.
예를 들어, 비용 연동 배치 시스템 E2E 테스트 기능을 구현하면서 Task의 ID를 입력받아 해당 Task까지만 수행하는 방식의 좀 더 유연한 시나리오를 지원하고자 했지만, 구현 복잡도와 “정말 필요할까?”라는 이유로 3가지 시나리오로만 제한되었습니다.
그러나 후에 다른 개발자분이 QA 시스템을 사용하시면서, “중간에 생성되는 임시 테이블 데이터를 확인해야 할 때가 꽤 많다”는 피드백을 주셨습니다.
이는 제가 초기 구상했던 요구사항과 맞닿아 있었고, 만약 그때 조금 더 근거를 갖추고 의견을 피력했다면 결과가 달라졌을 수도 있겠다는 생각이 들었습니다.
마치며
6개월이라는 짧지 않은 시간 동안 AB180에서 인턴으로 지내며, 기대 이상으로 많은 것을 배우고 성장할 수 있었습니다.
백엔드 엔지니어링의 실무 전반을 접하면서 AWS 인프라 운영부터 메모리 최적화, 그리고 대규모 데이터 배치 작업의 설계·운영 등 폭넓은 영역을 경험했는데, 이를 통해 다양한 역량을 쌓을 수 있었습니다. 특히 문제를 발견하고 상황에 맞춰 개선안을 제시하는 태도를 기르게 된 것이 가장 큰 성과라고 생각합니다.
이러한 경험을 발판 삼아, 앞으로 더욱 깊이 있는 백엔드 개발 지식과 효율적인 협업 방식을 고민하며 계속 발전해나가고 싶습니다.
아쉽게도 복학이라는 개인 사정으로 AB180을 떠나게 되었지만, 이 회사는 정말 떠나고 싶지 않을 정도로 큰 성장을 이룰 수 있는 곳이라 생각합니다. 무엇보다 “회사의 가장 큰 복지는 사람”이라는 말처럼, 함께했던 분들이 너무나도 좋았습니다.
귀중한 기회를 주신 AB180에 다시 한 번 감사드리며, 이 글이 AB180 지원을 고민하는 분들께 작은 도움이 되길 바랍니다.
ᴡʀɪᴛᴇʀ
Hyukjoon Hong @hong-sile
Backend Engineer @AB180
