개발자 커리어 점프 [점핏]! 개발자를 위한 직무 이야기를 전해드립니다.
AB180 사무실 벽면
개발자님의 직무 이야기
1. 담당하고 계신 업무를 소개해주세요.
조민규(Platform API Team) :
Backend Group > Platform API Team에 소속되어 있습니다. 에어브릿지 대시보드에 들어가는 기능들을 만들고, IAM과 같은 기반 시스템을 만들어가고 있습니다. 회사 내 프론트엔드 팀을 비롯해 에어브릿지의 고객사까지, 사용이 편하고 성능과 안정성이 높은 API를 제공하기 위해 노력 중입니다.
Production 수준에서는 API specification을 일관되게 하고, API 문서가 outdate되지 않도록 관리할 필요가 있고, rate limiting, validation, 권한 관리, 적절한 error message를 제공하는 등 생각보다 신경써야 할 일이 많습니다. 이들을 잘 챙겨서 완성도 높은 API를 제공하는 것이 목표입니다. 직접 작업도 하고, 다른 팀원 분들이 맡아서 진행할 수 있도록 간단한 업무 분장이나 가이드도 해 드리고 있습니다.
최찬환 (Data Serving API Team) :
저는 AB180 Backend Group의 Data Serving API 팀에서 Airbridge 사용자들이 원하는 마케팅 데이터를 리포트 형태로 제공해주는 API 개발을 담당하고 있습니다.
주로 Druid, Snowflake, DynamoDB, Luft(자체 개발 DW) 등 다양한 DW에 필요한 데이터를 쿼리하는 API 개발과, 비동기로 쿼리를 요청 및 데이터를 처리하는 워커를 개발하고 있습니다.
각 DW가 가진 특징이나 기능들에 대해 잘 이해하고 있어야 하며, 사용자들이 원하는 데이터인 ROAS, ARPU, ARRPU 등 마케팅 데이터에 대한 전반적인 이해가 필요합니다.
손건 (Data Pipeline Team) :
여러 소스로부터 하루 10억 건 이상의 데이터를 수집하고 처리하는 Data Pipeline팀에서 일하고 있습니다.
Data Pipeline팀의 업무는 크게 세 가지라고 볼 수 있습니다. 첫째로 사람들이 광고에 노출된 데이터와 웹 또는 앱에서 발생시킨 데이터를 수집합니다. 둘째로 수집한 데이터를 통해 유저가 어떤 광고를 보고 앱을 설치했는지 또는 물건을 구매했는지 등의 광고 성과를 측정하는 작업을 합니다. 마지막으로 광고 매체로부터 광고 비용 데이터와 추가적인 정보들을 저희 대시 보드에서 볼 수 있도록 연동하는 작업이 있습니다. 이 과정에서 정확한 데이터를 고객에게 전달하기 위해 갑작스러운 트래픽에도 데이터 유실 없이 잘 버티는 서버를 개발하고, 데이터 변경에도 유연하게 대응할 수 있는 설계를 지향하는 업무라고 생각하시면 될 것 같습니다.
2. 현재 회사와 지금의 직무를 선택하게 된 계기는 무엇인가요.
조민규(Platform API Team) :
회사를 처음 알아볼 때 AB180이 작은 스타트업이어서 빠르게 성장할 수 있는 환경일 것 같기도 했고, 아는 분과의 연결고리가 있어 관심이 생겼습니다.
고등학교 2학년 여름방학 때 ‘SW마이스터고 연합캠프’라는 것을 하게 되었는데, 모의면접 자리에 AB180도 있었습니다. 당시에 다른 회사들은 학생들에게 관심이 별로 없었는지, 이력서도 제대로 안 읽고 사실상 조언만 듣는 자리였는데 AB180은 조금 달랐습니다. 대표님이 직접 오시기도 했고, 이력서 첫 페이지부터 끝까지 꼼꼼히 읽으시면서 궁금한 프로젝트는 보여달라고도 하고, 메모까지 하는 모습을 보고 마음이 끌렸던 것 같습니다.
지금은 오래 다니면서 업무가 익숙해지기도 했지만, 좋은 동료가 많고, 엔지니어로서 존중받는 환경이라 계속 일하고 있습니다.
최찬환 (Data Serving API Team) :
AB180은 백엔드 개발자라면 누구나 경험해 보고 싶은 많은 트래픽과 대용량 데이터를 가지고 있었습니다. 저 또한 백엔드 개발자로서 이러한 대용량 실시간 데이터를 처리하는 경험을 통해 큰 성장을 할 수 있을 것 같다는 생각으로 AB180을 선택하게 되었습니다.
백엔드 개발자는 기능을 만들 때 데이터와 비즈니스 로직을 다룰 뿐만 아니라 다양한 인프라들의 특성을 고려하면서 개발해야 한다는 점에도 큰 매력을 느꼈습니다.
손건 (Data Pipeline Team) :
다른 곳에서 경험하기 어려운 대량의 트래픽을 경험해 볼 수 있다는 점 때문에 AB180을 선택했습니다. 개인적으로 나중에 외국의 큰 테크 회사에서도 일해보고 싶다는 마음이 있었습니다. 그러기 위해서는 내가 어떤 커리어를 쌓아야 할까 고민했고, 기술적으로 가장 중요한 것은 ‘대량의 트래픽을 안정적으로 처리한 경험’이겠구나 생각했습니다.
그런 생각을 하며 병역특례를 위해 회사를 알아보고 있을 때, 제 주변에 잘하는 친구가 자기가 다니고 있는 회사를 추천해줘 우연히 면접을 보게 되었습니다. 면접에서 ‘이벤트가 유실되지 않게 하려면 어떻게 해야 하는가'라는 날카로운 질문을 통해 강렬한 인상을 받았고, 합류를 결심했습니다.
3. 하루 일과를 소개해주세요.
조민규(Platform API Team) :
보통은 11시에 출근합니다. bot을 통해서 오늘 진행할 업무 내용들을 작성하고, 12시 반에 점심시간 이후로 일하다가 오후 8시에 퇴근합니다. 매주 월요일 오후 3시에는 각 팀원들이 돌아가며 지식공유 세션을 하는 KT(Knowledge Transfer)가 있어 참여합니다. 금요일에는 11시 15분에 팀 회고가 있어서 참가하고, ad-hoc으로 Tech Spec 리뷰나 포스트모텀 회의, 작업 킥오프, 코드리뷰 등을 처리합니다.
이렇게 얘기하면 너무 바빠보이는데, 중간중간 재밌는 글 있으면 읽어보고, 커피도 사러 다녀오고, 토론도 하는 등 자유롭게 리프레쉬할 수 있는 분위기입니다.
최찬환 (Data Serving API Team) :
오전 9시 ~ 11시에 탄력적으로 출근합니다. 출근하면 standuply 라는 슬랙 봇을 통해 근무지(재택, 사무실 등), 어제 한 일, 오늘 할 일을 공유합니다. 저희 팀은 자체적으로 standuply 를 통해 공유한 계획을 팀에 싱크하는 시간을 잠시 가집니다. 보통 업무 처리하는 과정에서 겪고 있는 고충이나 스케줄링 관련 고민 등을 공유합니다. 그 다음 12시 30분 까지 업무를 진행한 뒤, 12시 30분 부터 1시 30분까지 점심을 먹습니다. 이후에는 출근한 시간에 따라 오후 6시 ~ 8시까지 업무를 하고 퇴근합니다.
손건 (Data Pipeline Team) :
최근에는 날이 아주 따뜻해져서 아침에 러닝을 하고 있습니다. 이후 회사 출근해서는 팀 내부 요청을 처리하고 기능개발을 위한 작업 시간을 가집니다. 길게 집중하지는 못하는 스타일이라 할 때 집중해서 작업한 다음 중간중간 쉬는 편입니다. 퇴근 하고 나서는 아이디어가 있을 땐 사이드 프로젝트를 할 때도 있고 쉴 때도 있습니다.
4. 업무를 하며 가장 보람을 느낄 때는 언제이신가요.
조민규(Platform API Team) :
•
내가 만든 기능에 대한 Sales Team, 고객사의 긍정적인 피드백이 있을 때
•
내가 만든 코드가 칭찬받을 때
•
오늘따라 코딩이 잘 될 때
•
고민하고 있었던 것에 명쾌한 해답을 발견했을 때
•
내가 동료들에게 도움이 될 때
최찬환 (Data Serving API Team) :
개인과 회사가 성장하고 있는 것이 체감되는 순간 큰 보람을 느낍니다.
리펙토링을 진행하다 보면 과거의 내가 만들었던 코드를 보는 경우도 있습니다. 이 과정에서 과거의 나를 탓하기도 하지만, 때론 그 코드가 더 좋아질 수 있는 방법이나 문제점들을 현재의 내가 발견하는 모습을 보며 뿌듯함을 얻기도 합니다. 그 외에도 예전에는 해결하지 못했던 문제들에 대해 새로운 관점으로 해결 방법을 찾아내는 저의 모습을 보며 보람을 느끼기도 합니다.
AB180 B2B Mar-Tech SaaS 를 개발하기 때문에 고객사가 있습니다. 회사가 성장함에 따라 고객사가 많아지고, 새로운 기능을 출시할 때 고객사로부터 다양한 피드백을 받을 수 있습니다. 다양한 피드백 속에서 직접 개발한 기능을 고객사의 마케터 분들이 잘 활용하고 있는 모습을 보며 보람을 느끼는 것 같습니다.
손건 (Data Pipeline Team) :
크게 두 가지가 있습니다. 첫 번째로 개발한 기능이 고객사에서 좋은 피드백을 받아올 때가 가장 큰 것 같습니다. B2B 특성상 실제 프로덕트를 사용하는 고객을 자주 보지 못한다는 점이 있습니다. 하지만 가끔 들어오는 피드백이 계약하는 데 큰 도움이 됐다거나, 고객사에서 새로 개발한 기능에 만족했다고 보내온 메일에서 큰 동기부여를 받습니다.
두 번째로는 저와 팀원들의 시간 낭비를 줄여주거나 반복적인 작업을 없애는 일을 했을 때입니다. 일례로 최근 광고 비용을 가져오는 외부 API가 불안정해 alert을 자주 받았습니다. 이로 인해 팀원들의 피로감이 커진 걸 해결하기 위해 어떤 외부 API가 문제였는지와, 영향받은 고객사가 어디인지 쉽게 볼 수 있도록 통계를 내 슬랙 채널로 보내주는 것을 만들었습니다. 이후 alert을 대체할 수 있을지를 며칠간 테스트해본 뒤, 실제로 적용했습니다. alert은 적게 받으면서 모니터링을 더 편하게 할 수 있어 팀 전체의 피로도를 내릴 수 있던 좋은 작업이었다고 생각합니다.
AB180 회의실 및 업무공간
[AB180]의 개발이야기
1. 업무의 프로세스를 소개해주세요.
1-1. 기획부터 개발까지 진행되는 프로세스
티켓은 Jira를 통해 관리되며, UI/UX, 백엔드, 프론트엔드 작업자가 협업하는 티켓은 Roadmap이라는 타입으로 분류됩니다. 누구나 기능 개선을 제안할 수 있는 <아이디어파크> 에서 시작되는 작업들도 있습니다.
Roadmap 티켓의 시작은 UI/UX 작업자의 리서치로 시작합니다. 그 과정에서 엔지니어들이 자주 engage되는데, 프로덕트 특성 상 데이터 처리 파이프라인, 웹, 쿼리와 같은 부분에 지식이 많이 필요하기 때문입니다. 리서치 후 기획의 결과물은 Figma를 통해 공유되고, 작업자들이 모여 기획된 화면을 보고 Kick-off라는 회의를 거칩니다.
작업이 시작되면, Counterpart(짝) 엔지니어를 할당받습니다. Context를 함께 가져가면서 해당 작업에 대한 maintainer를 두 명 두기 위함입니다. 경우에 따라 Tech Lead의 역할을 하기도 합니다. 타 팀(WAS, Worker, Data Pipeline)의 유관자가 있는 경우에도 Counterpart로 추가합니다. 만약 API가 데이터를 잘못 건드리게 되면, 다른 컴포넌트에서 문제가 생기는 경우가 있기 때문입니다.
작업자는 PoC를 거친 후 Tech Spec이라는 문서를 작성해 Counterpart에게 리뷰받고, API Spec은 프론트엔드 작업자에게도 공유해 피드백받습니다.
Tech Spec이 fix되고 나면 master에서 브랜치를 checkout해 작업을 시작합니다. 이후 코드리뷰 → QA → Final QA → Code Owner 리뷰를 거친 뒤, 릴리즈를 진행합니다.
어떠한 특정 프로세스에 기반한다는 것은 따로 없으나, 기민(Agile)하게 움직이기 위해 불필요한 절차와 로드블럭을 없애기 위해 노력하고 있습니다. 예를 들어 최근에는 Tech Spec을 쓰는 것이 오히려 작업 일정을 늘리는 경우가 있다는 피드백이 있어서, 안 쓰고 넘어가도 되도록 프로세스를 정비했습니다.
1-2. [설계, 분석, 개발, QA, 런칭] 단계별 소요되는 평균시간
당연히 티켓의 크기에 따라 다릅니다. 그러나 각 단계마다 충분한 시간을 보장받을 수 있다는 장점이 있습니다. 먼저, 티켓마다 start date와 due date를 assignee가 직접 설정할 수 있게 되어 있습니다.
조직장에게 소구만 된다면 각 엔지니어가 제안한 일정대로 진행할 수 있습니다. 또한 Tech Spec을 작성하는 시간을 통해 설계/분석 시간을 보장받을 수 있으며, 이 과정에서 각 액션아이템의 구체적인 일정을 정할 수 있으므로 예측 가능성과 자율성이 높습니다.
물론 비즈니스적 요구사항에 따라 hard due가 있는 작업도 종종 있고, 이런 작업들은 당연히 열심히 달려야 합니다
일이 너무 바빠 휴일에 출근하게 되면, 업무 시간에 정해진 배율만큼 가산해 포상휴가도 지급해 줍니다.
2. ★개발 배포 프로세스를 소개해주세요.
Jira 티켓명에 해당하는 형태의 브랜치명(e.g. ABRRO-123)으로 코드가 push되면 개발용 서버가 배포됩니다. 배포 경과는 bot이 Slack으로 메시지를 보내 주도록 되어 있습니다.
특정 개발용 서버를 사용하는 대시보드를 netlify로 띄울 수 있도록 하는 slack command가 존재합니다.
이렇게 만들어진 netlify 대시보드를 PM에게 공유해 QA를 진행하도록 만듭니다. 작업 중인 코드를 develop, stage같은 브랜치에서 한 번에 관리하게 되면, 여러 엔지니어의 draft가 섞여 혼선이 있는 경우가 있어서 이와 같이 환경을 구성하게 되었습니다.
QA와 코드리뷰가 완료되고 나면 릴리즈하고, 성공적으로 릴리즈된 경우 Slack의 특정 채널에 공유해 칭찬을 받습니다(!).
하지만 잘못됐다면.. 어? 라는 slack command을 통해 쉽고 빠르게 rollback을 진행할 수 있습니다.
3. ★개발환경을 소개해주세요.
•
Mac을 사용합니다.
•
Slack, Notion을 사용합니다.
•
Git, GitHub로 형상관리합니다.
•
CodeBuild, CodeDeploy를 통해 CI/CD합니다.
•
모니터링을 위해 New Relic, CloudWatch, Athena, Runscope, Pagerduty 등을 사용합니다.
•
어떤 도구던 필요하면 추가하고, 필요 없으면 제거합니다.
•
API
◦
Python 3.7+, Flask, FastAPI 환경입니다.
◦
ORM으로 SQLAlchemy, 테스팅 툴로 pytest를 사용합니다.
◦
Main DB로 Aurora, 리포트 기능들을 구현하기 위해 Druid, ElasticSearch, Snowflake, DynamoDB, SQS 등을 사용합니다.
◦
Serverless를 통해 어플리케이션을 Lambda에 배포합니다.
•
Data Pipeline
◦
Python 3.7+, Sanic, Flask, GoLang 을 필요한 성능에 맞게 사용합니다
◦
비동기 분산처리를 위해 Kafka, SQS와 같은 메시지 큐를 사용합니다.
◦
현재 ECS를 사용해 필요한 서비스들을 제공하고 있고 k8s로 마이그레이션 하는 중에 있습니다.
◦
Aurora DB(Mysql), Snowflake, Druid, ElasticSearch, DynamoDB 등 빠른 데이터 서빙과 비용 최적화를 위해 여러 데이터베이스를 사용합니다.
◦
Airflow를 이용해 배치 작업들을 스케줄링 및 워크플로우 코드들을 작성합니다.
4. 코드리뷰 문화를 소개해주세요!
•
리뷰를 요청하는 Slack Channel과 Slack Application이 있습니다.
•
되도록이면 요청을 받는 즉시 리뷰를 진행하는 것이 권고됩니다.
•
PR당 diff 제한과 같은 구체적인 룰은 아직 없고, 팀이 커지면서 조금씩 만들어가고 있는 단계입니다.
•
당연하겠지만, 좋은 코드베이스를 만들기 위해 건설적인 토론을 지향합니다. 릴리즈 때문에 코드리뷰를 덜 하고 넘기는 경우가 잘 없다고 보면 될 것 같습니다.
5. 장애나 긴급상황에서는 어떤 프로세스로 대응하시나요.
alert이 발생하는 경우는 두 가지입니다.
•
New Relic, CloudWatch로 들어오는 로그를 기반으로 특정 규칙에 의해 alert
◦
500 error 등
•
Runscope에서 수행하는 scheduled test에서 fail이 발생하면 alert
이들은 기본적으로 특정 Slack Channel에 메시지를 보내고, 치명률이 높은 것은 Pagerduty를 통해 엔지니어에게 유선 전화를 하도록 되어 있습니다.
전화가 모두에게 가는 것은 아니고, 하루마다 바뀌는 Oncall 담당자에게 먼저 발신됩니다. 이후 몇 분간 장애를 확인했다는 Ack가 되지 않으면 총 3단계(팀원 전체 → 팀장 → 그룹장)에 걸쳐 escalate됩니다.
장애 대응은 다음과 같은 단계로 이루어집니다.
1.
장애 대응자/장애 제어자 선정
a.
장에 대응자는
i.
실제로 장애를 대응하며 제어자에게 경과를 간단하게 보고
b.
장애 제어자는
i.
해당 장애가 SLO를 만족하지 않는 경우 특정 Slack Channel에 공지
ii.
고객이 불편을 체감하는 경우 대시보드에 Notice 배너를 추가
iii.
<장애 처리 문서> 작성
2.
장애 대응이 완료되면 재공지
3.
장애 처리 문서를 기반으로 빠른 시일 내 Postmortem을 진행
4.
Postmortem에서 생성된 액션아이템을 통해 비슷한 장애가 다시 발생하지 않도록 시스템 개선
Postmortem Template
Postmortem에 대해 소개했는데, 저희 조직 내에서 장애는 사람 탓이 아니라 시스템 탓이라는 기조를 가지고 있습니다. 오히려 사람을 탓하는 게 더 잘못된 것이라 생각하는 분위기라고 보면 됩니다. 덕분에 조금 실수를 하더라도 주눅들지 않고, 계속 도전적으로 일할 수 있는 것 같습니다.
6. 기술 도입이나 업무 영역의 확장이 자유로우신 편인가요.
조민규(Platform API Team) :
기술 도입은 충분한 근거가 있다면 당연합니다. 백엔드 그룹 내에는 KT(Knowledge Transfer)라고 해서 매 주마다 한 명씩 지식 공유 세션을 진행하는 문화가 있는데, 여기서 신기술에 대해 소개하고 실제로 도입을 시작하는 경우도 종종 있습니다.
예를 들어 저의 경우에는 API 팀 내에서 사용하고 있는 Flask 프레임워크 대신 FastAPI를 쓰는 것이 좋아보여 발표를 진행했고, 최근에는 이것으로 실제 티켓이 만들어져 저에게 할당됐습니다(!).
조직장은 주기적으로 팀원들과 1:1을 진행하면서, 각자에게 하고 싶은 일을 물어보고 관련 작업을 assign해줄 수 있도록 준비합니다. 업무 영역의 확장 또한 하고자 한다면 얼마든 할 수 있습니다. 회사 내에 ‘다른 팀의 이야기'라는 것이 잘 없는 것 같습니다. 개발자가 디자인에 대해, 기획자가 개발에 대해 서슴없이 이야기할 수 있는 환경입니다.
손건 (Data Pipeline Team) :
회사 내의 프로세스를 개선하는 작업은 장려되는 분위기입니다. 회사에서 IAM 권한 신청에 어려움이 있어 문제를 해결해줄 솔루션을 찾고 있었습니다. 그러던 중 권한 관리를 도와줄 만한 툴인 ConsoleMe를 찾아 도입해 현재 팀원들 모두 만족해서 쓰고 있습니다.
어느 회사나 그렇듯 우선순위의 문제는 있겠지만, 필요함을 강력하게 어필하고 필요했던 상황들을 객관적인 자료로써 제공하면 합리적인 주장들은 대부분 받아들여지는 편입니다.
나의 개발 Tip
1. 일하는데 가장 중요하게 고려하는 데스크 세팅은 무엇인가요?
조민규 개발자님 데스크
조민규(Platform API Team) :
성능 좋은 PC와 QHD 이상의 32인치 모니터 2대와 애초에 자리에서 일을 잘 안 하다 보니 다른 주변기기는 특별한 취향이 없습니다. (업무용으로는 펜타그래프 키보드와 Magic Trackpad를 선호합니다.)
또한 개인적으로 윈도우 데스크탑을 가지고 코딩하는 것을 즐기는 편입니다. (가성비가 매우 좋습니다. 집에서 맥 기반 업무공간을 마련하는 것은 너무 비싸서..)
최찬환 개발자님 데스크
최찬환 (Data Serving API Team) :
듀얼 모니터와 키보드입니다. 중앙에 모니터를 두고 왼쪽에 피벗된 모니터를 두는걸 좋아합니다.키보드 같은 경우 해피해킹 배열을 사랑해서 자리에서는 해피해킹을 사용하고 맥북 기본 키보드도 따로 맵핑하여 해피해킹과 유사하게 사용합니다.
손건 개발자님 데스크
손건 (Data Pipeline Team) :
개발자로서 오래 일할 수 있도록 손목 건강에 신경을 많이 쓰는 편입니다. 인체공학 키보드를 사용해서 손목 부담을 많이 줄였고, 오른쪽에 보통 function key들이 많아 트랙패드를 사용할 때 손목을 더 많이 꺾게 됩니다. 키보드의 왼쪽에는 별다른 키들이 없어서 왼쪽에 트랙패드를 놓으면 어떨까? 하고 옮겨서 사용해 보았는데 생각보다 좋아서 계속 왼쪽에 트랙패드를 두고 사용중입니다.
2. 최근 가장 관심있는 기술스택(예, OS/ 언어) 은 무엇이며, 왜 관심을 가지게 되셨나요?
조민규(Platform API Team) :
최근에 글도 썼던(FastAPI의 시대. 아직도 Flask 쓰시나요?) FastAPI입니다. HTTP API 개발에 있어서 Flask에 불편했던 수많은 점을 명쾌하게 해결한 프레임워크입니다. 파이썬 웹 개발의 새 패러다임이 될 것 같아 공부도 해보고, 집에서 간단한 프로젝트들 하면서 소꿉놀이도 해 보고 있습니다.
최찬환 (Data Serving API Team) :
최근 Spring과 Kotlin에 관심을 가지고 있습니다. 새로운 기술 스택은 아니지만 프로덕트를 위한 서비스가 많아짐에 따라 여러 관리 포인트를 최소화 할 수 있는 방법에 관심이 많아졌고, 그런 점에서 Spring을 이용하면 좋을 것 같다는 생각으로 관심을 두고 있습니다. 또한 새로운 개발자 분들을 채용할 때도 해당 스택을 사용하시는 분들이 많아 좋을 것 같다는 생각을 가지고 있습니다.
손건 (Data Pipeline Team) :
기술 스택은 아니지만, 도메인 주도 설계(DDD)에 큰 관심을 두고 있습니다. 회사에 와서 변경에 유연한 설계를 하려면 어떻게 해야 할지, 비개발자와 개발자 간 커뮤니케이션에서 동일한 언어를 쓰고 요구사항이 코드로 잘 반영되려면 어떻게 해야 할지에 대해 많이 고민했습니다. 그러던 중 읽은 책이 에릭 에반스의 “도메인 주도 설계”와 반 버논의 “도메인 주도 설계 구현" 입니다.
위 두 가지 책에서 어떻게 도메인 개념을 잘 정립하고 반영하는지에 대한 많은 인사이트를 얻었고, 새로 만드는 프로젝트들에 적용하려 해보고 이벤트 스토밍을 미니 워크숍 형태로 진행해 보기도 했습니다. 처음에는 회사 내에서 반응이 시들했지만, 계속 책 한번 읽어보시라고 하고 KT에서 이야기한 결과 다른 팀에서도 DDD에 대한 긍정적인 의견과 도입을 점차 하려 노력하게 됐습니다.
3. 현재 하고 있는 업무의 역량을 키우기 위한 나만의 노력은 무엇인가요?
조민규(Platform API Team) :
관련해서 쓴 글이 있습니다(내게 실용적이었던 프로그래밍 공부 방법들). 요약하자면,
•
지식 전달용 책은 목차 위주로 보고 구글링하면서 학습
•
Stackoverflow에서 관심 있는 토픽의 인기 질문들 모아보기
•
Reddit에 관심 있는 서브레딧 구독
•
44bits.io 구독
•
feedly에 블로그들 rss 모아두고 알림 받기
•
기존에 잘 쓰던 라이브러리 코드리딩
•
글 쓰기는 튜토리얼보단 ‘나만의 주제’를 가지고 쓰기
최찬환 (Data Serving API Team) :
사내 스터디를 진행하여 똑똑한 사람들과 함께 새로운 개발 지식을 공부합니다. 같은 문제에 대해서도 각자 생각하는 관점의 차이를 보며 생각의 폭을 넓히려고 노력합니다.
업무를 하면서 학습한 내용을 개발 블로그를 통해 한 번 더 정리하고 공유하려고 합니다. 이런 경험을 통해 그 지식을 내 지식으로 만들려고 노력합니다.
손건 (Data Pipeline Team) :
개발자의 업무 역량이라고 하면 크게 개발능력과 소통능력 두 가지가 있다고 생각합니다.
첫 번째는 말 그대로 개발을 잘하기 위한 것입니다. 주로 퇴근을 빨리 하기 위해, 내가 덜 피곤하려면 어떤 능력이 더 필요할까 위주로 생각해서 필요한 것들을 공부하는 편입니다. 위에 소개해 드린 것처럼 관련 책을 읽기도 하고, 프로덕션에 바로 적용해 볼 수 없는 기술들을 사이드 프로젝트에서 적용해보거나 합니다.
두 번째로 소통능력은 주변 동료들의 얘기를 잘 듣고 잘 말하는 것입니다. 서로가 프로젝트에 관해서 더 깊이 이해한다면 경우에 따라 일의 양이 절반이 될 수도, 미리 도사리고 있는 위협을 피할 수도 있다고 생각합니다. 이런 능력을 기르기 위해 구두로 얘기한 내용을 꼭 슬랙에 정리하면서 어떻게 하면 더 잘 전달할 수 있을까를 고민해보는 편입니다.
AB180 열일 중인 동료들
우리회사는 개발자를 위해 이렇게 지원합니다.
1. 함께 일하는 동료들을 소개해주세요. (또는 어떤 사람들과 함께 하고 싶은지 미래의 동료를 소망해주세요)
조민규(Platform API Team) :
좋은 동료가 복지라고 생각될 정도로, 정말 우수하고, 착하고, 열정 가득한 사람들이 많습니다. 따라서 본인에게 할당된 작업들을 쳐낸다는 느낌보다, 조금이라도 잘 하려고 하고 일을 통해 성장하려는 욕심을 가진 사람들입니다. 효율화와 자동화에 적극적이라서 다들 나중에 멋진 시니어 엔지니어가 될 것 같습니다.
최찬환 (Data Serving API Team) :
저는 성장에 진심인 개발자들과 함께하고 있습니다. 함께 업무를 하며 자신의 성장, 팀의 성장, 회사의 성장 등 모든 성장을 중요시 생각합니다. 내가 성장하기 위해 해야하는 일을 고민하고 잘하려고 노력합니다.
그러기 위해 누구나 자유롭게 의견을 이야기하고 좋은 목표를 위해 언제든 토론합니다. 하지만 리소스 낭비를 하지 않기 위해 아젠다 등을 잘 정리하여 시간을 낭비하지 않습니다.
저는 앞으로도 제품과 개발적인 내용으로 자신의 의견을 합리적으로 이야기할 수 있는 사람, 언제든 의미있는 토론을 효율적으로 할 수 있는 사람과 일하고 싶습니다.
손건 (Data Pipeline Team) :
자신만의 강점이 확실한 사람이 많습니다. 분산처리를 잘하는 분도 있고, 남들보다 개발속도가 빠른 분, 마케팅 도메인에 대한 이해가 깊은 분 등등 각자 강점이 확실합니다. 새로 들어오실 분들이 이 모든 걸 잘하면 너무 좋겠지만 그건 욕심인 것 같고, 자신만의 전문성을 가지신 분이 들어와서 저희 팀에 부족한 점을 채워 주시고 부족한 부분은 팀에서 채워가길 원하시는 분이었으면 좋겠습니다.
2. 기술 역량 향상을 위한 교육 및 학습의 기회를 소개해주세요.
•
각 팀원이 전문성을 키울 수 있도록, 최소 3개월에서 최대 6개월의 체계적인 온보딩 커리큘럼을 운영하고 있습니다.
•
백엔드 그룹 내에서는 KT(Knowledge Transfer), UI/UX 팀 내에서는 Product Research를 운영하고 있고, CSM 팀에서는 주기적으로 외부 연사를 초대해 세션을 진행하는 등 발표가 자주 있습니다.
◦
이것에 대해 별도로 언급하는 이유는, 해당 팀원이 아니더라도 세션에 참여하는 것을 독려하고 있기 때문입니다.
•
팀 내에 지정된 멘토가 1:1로 지도, 조언을 통해 신규입사자의 원활한 온보딩을 돕습니다. 멘토링비도 지원되는 덕분에 같이 맛있는 점심도 먹을 수 있습니다
•
제한 없는 도서 구매 지원, 강의/세미나/컨퍼런스 등 참가비 지원, 자격증 응시료 지원 등. 그 외에도 기술 역량 향상을 위한 비용 지출은 상식적인 선에서 유연하게 지원해주고 있는 것 같습니다.
3. 우리회사의 테스트 기기현황 및 업무환경을 자랑해주세요.
•
MacBook Pro 및 고사양(QHD) 모니터, 키보드, 마우스, Magic Trackpad 등 각자에게 편한 주변기기 지원 및 스탠딩 데스크, 시디즈 의자
◦
최근에는 M1 Mac을 구매할 수 있게 되어 업무 환경이 더 좋아졌습니다
◦
맥은 2년마다 변경할 수 있습니다.
•
유료 소프트웨어 구매
◦
PyCharm, GoLand, DataGrip, IntelliJ 등. 업무용 소프트웨어 구매를 위한 지출은 따로 없다고 보면 됩니다.
AB180 회의실
AB180 의 채용 포지션이 궁금하다면?! 점핏에서 확인해보세요 점핏에서 개발자로 취업하고 취업축하금 받으세요!
