안녕하세요, 클라이언트챕터에서 아테나스랩 모바일 개발 직군에 지원하시는 분들을 위해 궁금해하실 만한 부분을 문화와 실제 업무 모습 위주로 정리해보았습니다.
훑어보기
클라이언트 챕터는 어떤 원칙을 가지고 일하나요?
아이디어 구상부터 배포까지 개발의 A-Z에 참여할 수 있는 환경을 제공합니다.
클라이언트 개발자의 업무 범위는 어디까지일까요? 아테나스랩 클라이언트 챕터는 아이디어 구상을 비롯한 기능 개발의 전 과정에 본인의 의사에 따라 참여할 수 있습니다. 기획 단계에서부터 PO, 디자이너, 서버 개발자와 피드백과 의견을 주고받으며 기획을 함께 개선해나갑니다. 모두가 서로의 의견이 필요하다는 것을 잘 알고 있습니다. 탑다운으로 내려온 요구사항을 해결하느라 일의 의미를 모른 채 기능 개발과 이슈만 해결하는 개발자보다는 나의 기준과 철학을 바탕으로 고객에게 무엇이 좋고 나쁜지 판단해 의견을 전달할 수 있는 오너십(Ownership) 있는 챕터를 추구합니다.
필요하다면 우리에게 주어진 환경을 지속적으로 개선해 나갑니다.
“오늘보다 나은 내일!” 아테나스랩 클라이언트 챕터는 창의성을 발휘하여 꾸준히 코드 베이스, 아키텍처, 업무 프로세스 등을 개선해나가는 팀이에요. 소프트웨어 개발자 마틴 파울러는 자신의 저서 『리팩토링』에서 “소프트웨어 개발자는 자신 주변의 중력을 조금씩 줄여나감으로써 더 멀리 나아갈 수 있다”고 했습니다. 아테나스랩 클라이언트팀은 변화하는 환경에서 고객들의 요구사항을 끊임없이 반영하면서도 우리에게 필요한 업무 프로세스 및 도구를 지속적으로 개선해 세계 최고의 모바일 앱 개발팀을 목표로 나아가고 있습니다.
솔직한 피드백을 통해 개인의 커리어 성장을 지원합니다.
구글 임원, 애플 대학교 교수, 창업을 거쳐 현재는 다양한 실리콘밸리 기업의 자문을 맡은 Kim Scott은 자신의 저서 『Radical Candor』에서 “개인적인 관심”과 “직접적인 반대의견"의 두 가지 요소가 결합한 “완전한 솔직함”이 개인이 아닌 팀의 성과를 만들어낸다고 했습니다. 아테나스랩 클라이언트 챕터의 동료들은 서로의 일에 완전히 무심하지도 무조건 반대하지도 않습니다. 대신에 서로 코치가 되어 솔직한 반대의견, Disagree And Commit(반대해도 결정되면 따르기), 진심 어린 피드백 문화 위에서 퀄리티 높은 제품 제작과 고객 만족을 추구합니다.
높은 커뮤니케이션의 기준을 가지고 “유효한” 일을 만들어냅니다.
아테나스랩 클라이언트 챕터는 높은 커뮤니케이션의 기준을 설정하고 팀원이 정확한 커뮤니케이션을 위해 노력하고 있습니다. 서로간의 정확한 커뮤니케이션은 팀원간의 신뢰 수준을 높여주고 목표를 더 쉽게 달성할 수 있도록 돕습니다.
개발자가 하게 되는 실제 업무는 어떻게 진행되나요?
기획 아이데이션 피드백
코드 리뷰뿐만 아니라 기획자와도 수시로 피드백을 주고받으며 고객에게 더 나은 방법이 무엇일지 고민해요!
API 인터페이스 설계
서버 개발자와 클라이언트 개발자와 협의하여 API 스펙을 정하고 서로 피드백 합니다.
테크니컬 라이팅
기술 블로그, 스펙 문서, 기술문서 등 챕터 외부에 제공하는 문서 등을 작성합니다.
신규 팀원 온보딩
CI/CD를 통한 자동화된 앱 배포
오늘학교는 Flutter로 개발하는 크로스 플랫폼 앱으로 내부 배포와 테스트 배포를 양 플랫폼으로 하는 경우, 배포에 드는 시간이 매우 큽니다. 그래서 우리는 Fastlane과 Github Action으로 배포 파이프라인을 구성하여 사용하고 있습니다.
챕터 정기논의 및 설계 리뷰
한 스프린트에 한 번씩 정기적으로 모여 챕터 어젠다 논의와 설계 리뷰 등을 진행합니다.
애자일한 개발 문화
MVP를 통한 핵심 가설 검증, A/B 테스트, 짧은 주기의 배포를 통해 PMF(Product Market Fit)을 찾아갑니다.
동료들의 기술블로그 피드백
아테나스랩에서는 동료의 기술 블로그 글 피드백을 통해 나의 기술적 역량 및 글쓰기 실력을 향상할 수 있어요.
앞으로의 클라이언트 챕터의 남은 과제
클린 아키텍처를 넘어 DDD로의 점진적인 전환
•
현재 클라이언트 챕터에서는 클린 아키텍처, 유비쿼터스 랭귀지, 디자인 요소 컴포넌트화 등등 DDD를 실천하기 위한 여러 가지 방법을 실천하고 있지만, DDD의 실천은 한 두 챕터만의 노력으로는 완성되는 것은 아니기에 다른 챕터와 함께 DDD를 실천하는 방향성을 갖고 있어요. 이러한 개발방법론의 실천을 통해 개발 비용을 지속해서 낮춰나갈 생각입니다.
테스터블한 구조를 넘어 테스트 실천으로
•
현재 클라이언트 챕터는 테스트 비용을 낮추기 위한 실천을 해나가고 있습니다. 현재 클라이언트는 테스트 가능한 아키텍처를 지향하여 작업하고 있지만, 백엔드와의 통합 테스트, 단위 테스트 작성, 오류를 최소화할 수 있는 테스트 프로세스 정립 등은 아직 과제로 남아있습니다.