안녕하세요, Airbridge Report&Platform 팀에서 백엔드 개발자로 일하고 있는 박예준입니다.
저는 ICT 학점 연계 인턴십 프로그램을 통해 AB180에서 처음 실무 환경에 발을 디뎠습니다.
개발자라는 꿈을 현실로 마주한 첫 순간이었고, 동시에 제가 어떤 방향으로 성장하고 싶은지를 구체적으로 그려나가기 시작한 시간이었습니다.
10개월 동안 AB180의 Airbridge Product Division에서 백엔드 인턴으로 근무했고, 현재는 정규직 개발자로 전환되어 핵심 컴포넌트를 운영하고 있습니다.
이 글은 그 여정을 정리한 회고이자, 누군가에게는 실무의 첫 발걸음에 도움이 될 수 있기를 바라는 기록입니다.
첫 실무에 임하며
Data Pipeline 팀에서 비용 연동 및 포스트백 시스템 등 매체 연동 관련 업무를 맡았습니다.
처음에는 단순한 쿼리 수정도 조심스러웠지만, 점차 하나의 티켓을 처음부터 끝까지 설계하고 구현하고 배포하는 데 익숙해졌습니다.
돌이켜보면 '주니어 개발자'라는 이름에 천천히, 하지만 분명하게 가까워진 시간이었습니다.
소통을 “잘” 하는 법을 배웠습니다
AB180에서 가장 먼저 배운 역량은 커뮤니케이션이었습니다. 단순한 전달을 넘어, 맥락과 의도를 담는 소통이 필요하다는 것을 실감했습니다.
AB180의 동료 개발자들은 공통적인 의사소통 습관을 가지고 있습니다. 예를 들어,
•
"제가 그래서 이렇게 이야기하는 이유는~"
•
"결론을 내리게 된 이유는~"
와 같은 표현을 자주 사용하며, 주장의 배경과 근거를 함께 공유하는 문화를 자연스럽게 체화하고 있습니다. 이는 커뮤니케이션 비용을 줄이고, 더 나은 방향으로 업무를 이끌어가는 데 큰 역할을 합니다.
이러한 문화 속에서 저도 다음과 같은 방식으로 일하게 되었습니다:
•
업무 요청 시: 배경 + 목적 + 한 줄 요약 + 관련 링크 정리
•
의사 결정 시: Slack에 히스토리 남기기
•
리뷰 요청 시: 구현 의도와 리뷰 포인트를 사전 공유
이러한 커뮤니케이션 방식은 협업자와의 신뢰를 높이는 데에도, 스스로 사고를 정리하고 문제를 구조화하는 데에도 큰 도움이 되었습니다.
구조를 고민하게 만든 질문들
AB180은 “더 나은 설계”를 끝까지 파고드는 환경입니다. 인턴 기간 동안 가장 많이 들었던 말은 아마도
“왜 이렇게 설계하셨는지 궁금해요”
이 질문 하나가 제 사고의 방식 자체를 바꾸어 놓았습니다.
단순히 '작동하는 코드'를 구현하는 데서 나아가, '이 기능은 왜 이렇게 설계되었는지', '어떤 구조가 더 나은 선택일지', '그 결정이 이후 유지보수에 어떤 영향을 줄지'를 고민하게 되었고, 그러한 질문을 스스로 던지는 습관이 생기면서 업무를 푸는 방식에도 큰 변화가 생겼습니다.
결국 이 고민들은 자연스럽게 다음과 같은 기술적 주제로 이어졌습니다:
•
트랜잭션 처리 타이밍에 따라 DB 정합성이 깨질 수는 없을까?
•
데이터가 많아졌을 때, 쿼리 성능이 버틸 만할까?
•
캐싱은 어디에, 어떻게 적용해야 안정적일까?
이러한 고민은 성능 개선과 코드 구조 개선, 문서화로 이어졌고, 실질적인 변화로 나타났습니다.
Python에서 Kotlin으로, 안정적인 마이그레이션
기억에 남는 작업 중 하나는 포스트백 API를 Python에서 Kotlin으로 마이그레이션한 경험입니다. 약 3,000건에 달하는 고객사의 포스트백 커넥션(매체별 설정 조합)을 안정적으로 이관하고 데이터 정합성을 확보하는 것이 핵심 과제였습니다.
*포스트백(Postback)이란?
포스트백은 앱에서 발생한 이벤트(예: 설치, 구매)를 연동된 광고 채널에 전송하는 서버 간 통신 방식입니다. Airbridge에서 광고 채널로 포스트백을 전송하면 각 광고 채널은 CPA(Cost Per Action), CPI(Cost Per Install) 등 광고비 정산에 포스트백으로 전송한 데이터를 활용할 수 있습니다. 또한 광고 채널은 포스트백 데이터를 활용해 리타겟팅(Retargeting) 캠페인 등을 최적화할 수 있습니다.
예를 들어, 사용자가 앱을 설치하면:
1.
Airbridge SDK를 통해 이 이벤트를 수집하고,
2.
광고주(Airbridge 사용자)가 사전에 등록한 포스트백 설정에 따라,
3.
해당 이벤트 정보를 광고 채널(A사)에 HTTP를 통해 실시간 전송합니다.
마이그레이션 배경
Airbridge에서는 Python 기반 API가 오랫동안 운영되어 왔지만,
•
기존 Python 기반 API들과 일부 Kotlin API들이 함께 운영되며 언어 간 파편화가 심화되었고,
•
이로 인해 관리 복잡도와 유지보수성이 저하되는 문제가 있었습니다.
이러한 문제를 해결하고자 기존 설정 API를 Kotlin으로 재구성했고, 동시에 마이그레이션 전후 설정이 완벽히 일치하는지 확인할 수 있는 QA 시스템을 직접 구축했습니다.
핵심 흐름 요약
1.
사용자 요청에 따라 설정 API가 호출되면,
2.
기존 설정을 삭제하고 Source 테이블을 기반으로
3.
템플릿 언어로 렌더링하여 Destination 테이블을 구성합니다.
4.
구성된 설정은 Postback Worker가 실제 전송 시 참조합니다.
QA 시스템의 필요성 및 구현 과정
"설정이 수만 건 이상인데, 하나라도 잘못되면 광고 전환 추적에 치명적인 영향을 줄 수 있어요."
포스트백은 단순 설정 이상의 민감한 영역입니다. 외부 채널로 전송되는 이벤트는 광고 비용/성과 측정에 직결되며, 하나의 매핑 오류로도 ROI 추적이 무의미해질 수 있습니다.
그래서 설정의 일치 여부를 코드 단위로 검증할 수 있는 QA 시스템을 직접 구축하게 되었습니다.
구성 요소 | 설명 |
DB Snapshot & Comparison | 마이그레이션 전/후 테이블의 설정을 스냅샷하고, 항목별로 diff 비교 |
설정값 매핑 검증 | 템플릿 내 키 매핑 정확성 확인 (channel, global, app-channel 레벨) |
Liquid Template 변환 결과 비교 | 템플릿 렌더링 최종 결과가 기존과 완벽히 동일한지 검증 |
병렬 처리 (Coroutine) | 수만 건 단위 설정 처리에 대해서도 성능 확보 |
결과 리포트 | 설정 간 차이점 요약 리포트 자동 생성 |
시스템을 구축하며 다음과 같은 성능 개선도 달성했습니다.
•
개발 환경 QA 시스템을 새롭게 구축하여 마이그레이션 전후의 결과를 정밀하게 비교할 수 있도록 함
•
직렬 테스트 방식의 병목을 해소하기 위해 Coroutine 기반 병렬 처리를 도입해 테스트 시간을 3분 1.62초 → 51.24초(-72%)로 단축
•
직렬화 포맷 차이로 발생하는 데이터 정합성 문제를 해결하기 위해 기존 라이브러리를 커스터마이징하여 QA 정확도를 향상시킴
해당 작업은 단순한 이관을 넘어서 성능 개선, 정확성 확보, 유지보수성 향상이라는 세 가지 목표를 모두 달성할 수 있었고, 시스템에 대한 신뢰도를 높이는 경험이 되었습니다.
설계력과 책임감을 기른 Tech Spec 문화
AB180에서는 모든 기능 구현 전에 Tech Spec 문서를 작성합니다.
Tech Spec 문서에는 ‘왜 이 방식이 최선인가’, ‘트레이드오프는 무엇인가’에 대한 고민이 담겨야 합니다. 이 과정을 통해 작업자 간의 이해를 맞추고, 코드 리뷰 시 빠르게 컨텍스트를 파악할 수 있으며, 히스토리를 남기는 문서로서도 중요한 역할을 합니다. 뿐만 아니라, 개발 전에 방향성을 명확히 정리함으로써 이후 구현 중 변경이나 혼선을 줄이고, 결과적으로 전체 개발 속도도 더 빨라졌습니다. 이는 우리 팀의 큰 강점이자 효율적인 협업의 기반이 되었습니다.
하나의 기능을 구현하기 전, 왜 이 방식으로 구현하려는지, 어떤 문제가 있고 어떤 해결책이 적절한지를 팀원분들께 설명하고 설득해야 했습니다.
리뷰를 받고, 질문을 받고, 다시 수정하고... 그 과정은 결코 쉽지 않았지만, “어떻게 설계하고 왜 그렇게 해야 하는가”를 고민하는 훈련이 되었습니다.
그 결과, 제가 작성한 Tech Spec 문서가 실제 기능 구현과 운영으로 이어지는 경험을 통해, 설계에 대한 책임감을 체득했고 큰 자신감을 얻게 되었습니다.
포스트백 연동 UX 개선: 설계부터 점진적 배포까지
입사 후 가장 규모가 컸던 프로젝트는 포스트백 연동 UX 개선 작업이었습니다.
이전 시스템은 문서화되지 않은 매체 스펙, 복잡한 데이터 구조, 하드코딩된 설정 등으로 인해 유지보수가 어려웠고, 실제 고객사의 매체 연동 속도도 느렸습니다.
이를 해결하기 위해,
•
매체 스펙을 DB 기반으로 중앙 집중화
•
매체 그룹화 및 데이터 스키마 재설계
•
점진적 배포를 하는 동안 레거시와 신규 시스템이 양립 가능하도록 플래그 시스템 설계
•
PM이 백오피스에서 직접 점진적 배포를 설정할 수 있도록 시스템 구성
이 프로젝트는 개발 측면뿐 아니라 운영, 협업, 유저 경험까지 고려해야 했기 때문에 전체적인 관점을 갖고 일하는 연습이 되었고, 개인적으로도 가장 인상 깊은 성과였습니다.
설계부터 구현, 점진적 배포 전략 수립까지 전체를 처음부터 주도한 경험은
실제 운영 환경에서 어떤 구조가 '좋은 설계'인지를 체감할 수 있었던 계기였습니다.
곧 배포를 앞두고 있는데, 많은 고객사의 편의가 커졌으면 하는 바람입니다. 
장애 대응과 포스트모텀
실제 장애 상황도 경험했습니다.
작은 설정 실수로 인해 장애가 발생했지만, 사람을 탓하지 않는 AB180의 포스트모텀 문화 덕분에 문제를 숨기지 않고 투명하게 공유하며, 그 원인을 분석하고 재발 방지책을 마련할 수 있었습니다.
장애 발생 시점부터 처리 완료까지의 타임라인을 상세히 정리하고, 근본 원인을 기술적으로 분석하며, 재발 방지를 위한 액션 아이템을 팀과 함께 도출했습니다.
당시에는 식은 땀이 날 만큼 긴장도 컸지만, 그만큼 성장의 속도도 빨랐습니다. 장애를 단순히 해결하는 데 그치지 않고, 이후 유사한 문제가 재발하지 않도록 구조를 보완하면서 시스템의 견고함을 한층 더 끌어올릴 수 있었습니다. 이 경험을 통해 장애 대응이 단순한 복구를 넘어서, 시스템을 더 견고하게 만드는 계기가 될 수 있음을 느꼈습니다. 덕분에 장애 상황에서 보다 책임감을 가지고 대응하고, 실질적인 재발 방지 조치를 고민하는 개발자로 한 걸음 더 나아갈 수 있었습니다.
점점 성장하는 걸 느끼며 즐거웠습니다
인턴 기간 동안 느낀 제 변화는 화려하진 않았지만, 분명했습니다.
•
예상 작업 시간(ETA)을 산정하고, 일정 내에 끝내기 위해 스스로를 관리하기
•
문서 중심의 업무 흐름에 익숙해지고, 생각을 구조화해 전달하는 능력 기르기
•
소극적인 태도에서 벗어나, “허락을 기다리기보다 먼저 설계안을 제안하는” 습관 들이기
이러한 변화들은 작은 습관이었지만, 장기적으로는 큰 성장의 토대가 되었다고 느낍니다.
인턴이긴 했지만, 조직에 기여하고 싶은 열망이 매우 컸고 코드리뷰를 기다리면서 업무가 비는 타이밍이 있다면 바로 팀 리드분을 찾아가 일을 더 달라고 요청했던 것이 기억에 남습니다.
Jira Backlog에서 흥미로운 티켓들을 찾아와 먼저 해도 되냐고 여쭤보기도 하고, 동료분들이 툭 던지신 조언 하나하나 알아보고 실천하며 저의 빈 시간을 촘촘이 채워갔습니다.
또한, 레거시 코드에서의 중복 로직을 제거하고 구조를 재설계해서 먼저 제안드렸던 것도 생각나네요.ㅎㅎ
사내 스터디와 KT 문화
인턴 기간 동안 가장 만족도가 높았던 활동 중 하나는 사내 스터디였습니다. 팀과 무관하게 여러 백엔드 개발자분들과 기술 서적을 함께 읽고, 각자의 실무 경험을 바탕으로 인사이트를 나누며 기술적 시야를 넓힐 수 있었습니다.
운영환경에서의 문제 해결 사례, 기술 선택의 이유, 실제 적용 시 발생한 고민 등 생생한 사례들이 매주 공유되었고, 그 속에서 '좋은 개발자란 어떤 사람일까?'라는 질문을 자연스럽게 품게 되었습니다. 단순히 책을 읽는 것에 그치지 않고, 실무와 연결 지으며 내 일에 어떻게 적용할 수 있을지 고민하는 시간이었습니다.
또한 AB180에는 KT(Knowledge Technology)라는 조직 내 지식 공유 문화가 있습니다. 특정 도메인 지식이나 운영환경에서 겪은 문제 해결 경험, 기술 선택의 배경 등 생생한 사례를 KT 문서로 남기는 이 문화 덕분에, 경험을 공유하고 다시 학습할 수 있는 선순환이 자리잡고 있습니다.
저 역시 이러한 문화에 영감을 받아, 인턴 기간 동안 겪었던 트러블슈팅이나 시행착오를 개인적으로 정리해두고 회고 세션에서 공유했습니다. 직접 KT 문서를 남기지는 않았지만, 비슷한 맥락으로 팀에 도움이 되는 기록을 남기며, '경험을 통해 배우고 나눈다'는 문화의 중요성을 체감할 수 있었습니다.
마무리하며
AB180에서의 시간은 단순한 인턴십 이상의 경험이었습니다.
서비스를 운영하며 데이터를 다루고, 설계를 고민하고, 동료들과 소통하며 문제를 해결하는 과정 속에서 제가 어떤 개발자가 되고 싶은지 더 분명해졌습니다.
지금은 정규직으로 전환되어 핵심 컴포넌트를 운영하고 있으며, 앞으로도 더 나은 시스템과 구조를 고민하는 개발자로 계속 성장하고 싶습니다.
AB180은 그런 고민을 함께 나누고, 더 나은 개발자이자 더 좋은 동료로 성장해갈 수 있는 최고의 환경입니다.
ᴡʀɪᴛᴇʀ
Yejun Park @jun02160
Backend Engineer @AB180
