두근두근 컬리의 면접, 팀에서 성장하기
컬리 입사 과정과 합격 이후 일어난 일들을 소개합니다
컬리의 채용은 활짝 열려있습니다
안녕하세요, 컬리에서 커머스시스템 서버 개발을 하고 있는 황지혜입니다.
오늘은 컬리 면접을 준비하던 때로 돌아가, 면접자가 되어 글을 쓰고자 합니다.
입사 전에 면접을 준비하며, 그리고 팀에 합류한 후 어떻게 팀 안에서 성장할 수 있었는지를 얘기 나누고자 합니다.
지원을 주저하시는 분들이 계신다면, 용기 내시는 데 도움이 되셨으면 합니다.
입사 지원 2주 전, 채용공고를 발견하다
앗 컬리에서 Java 서버 개발자(커머스시스템) 채용 공고가 올라왔네?!
지원해보고 싶다!
서류 합격
오와아! 서류 합격이라니!
1차 면접 3일 전
우선 채용 공고에 나와 있는
Job Description을 다시 살펴봐야겠다.
3일 남은 이 시점에서 내가 면접을 위해 준비할 수 있는 것은 무엇이 있을까?
개발하면서 매일 써온 것들에 대해서 아는 것이 중요하겠다.
매일 쓰는 클래스에 대해 이해할 수 없다면, 숙련된 자바 개발자라고 할 수 없겠지?
기본이 중요하다고 생각했다.
Java
Java에서는 매일 쓰는 클래스인 ArrayList, HashMap의 내부 구조에 대해서도 정리해보고,
인터페이스와 추상 클래스에 대해서도 정리해봐야겠다.
내부 클래스는 왜 static이어야 하는지, Java 가비지 컬렉터에 대해서도 내가 아는 만큼 정리해보는 게 좋겠네.
주요 Annotation 사용 방법에 대해서도 정리해봐야겠다.
Spring
Spring에서 중요한 건 어떤 게 있지?
IoC에 대한 내용이랑 매일 사용하는 Spring Bean이 어떻게 주입되는지도 정리해보자.
Bean의 생명 주기에 대해 정리해야겠다.
MySQL
MySQL에서 제일 중요한 게 뭘까?
흠.. 제일 중요한 건 인덱스에 대한 이해 아닐까?
인덱스에 대해서 이번 기회를 통해서 정리해보는 게 좋겠다.
Micro-Service
Micro-Service에 대한 이해 및 실무 적용 경험이라..
마이크로 서비스에 대해서도 내 경험을 살려서 준비하는 게 좋겠다.
합격 후 7개월 후
DDD 도메인 중심 사고, 문제해결에 대한 탐험가가 되어
면접을 볼 때는 DDD에 대해 책만 읽었지, MVC 패턴으로 개발해왔기 때문에 내가 과연 DDD로 개발을 해나갈 수 있을까 걱정했었다.
처음에는 헥사고날 아키텍처 자체가 처음 보는 구조라 다소 생소하게 다가왔다. MVC 패턴으로 개발하는 방식에 익숙했기 때문에 마이크로 서비스의 가장 안쪽 레이어인 도메인 모델을 먼저 설계한다는 사고 자체가 너무 어려웠다.
같은 팀의 우현님이 헥사고날 아키텍처에 대해 익힐 수 있도록 책을 지정해주셨고, 공부하고 얻은 인사이트를 발표하여 공유할 수 있도록 미션이 주어졌다.
한 챕터씩 발표하고 잘못 이해한 부분들에 대해 질문하고 피드백 받으며 조금씩 헥사고날 아키텍처에 대해 익혀나갔다.
공부한 내용을 바로 실무에 적용할 수 있도록 관련 코드 개선 미션도 주어져서, 이 미션을 해결하면서 실제 코드에서 아키텍처에 대해 고민하는 시간을 가질 수 있었다.
지금도 여전히 어렵긴 하지만, 도메인 중심으로 사고하려고 노력하고 코드로 옮기며 개발하면서 즐거움을 느끼고 있다.
무작정 코딩을 하고 그 위에 기능을 하나씩 붙여나가는 게 아니라 도메인에 대해 깊이있는 고민을 하고 개발을 해나가는 점이 인상 깊었다. 직군을 가리지 않고 다 같이 아이디어를 모아서 프로덕트를 함께 만들어가는 느낌이라 좋다.
진정한 DDD가 이런 걸까?
개발에 관한 것뿐만 아니라, 클라이언트와 커뮤니케이션을 해나가는 것부터 시작할 수 있었다.
현업 부서, 기획 부서와 이야기 하면서 그 도메인에 대해서 알아가고 코드에 녹여내는 과정이 DDD가 아닐까?
도메인에 대해 더욱 심층적으로 얘기하고 어떤 서비스를 만들 것인지에 대해 계속 얘기해 나갈 수 있구나. 기술적으로도 도전적인 과제들을 해결해가는 과정도 즐겁다.
테크 위클리, 함께 공부하여 경험을 나누어 보자
매주 수요일에는 테크 위클리가 열리는데, 이곳에서 공부한 기술이나 경험을 공유하기도 한다.
긍정적인 청중 앞에서 발표를 할 수 있는 기회가 주어지는 것이다.
나중에 큰 무대에서 발표할 기회가 생긴다면 이 경험을 밑거름 삼아 도전할 용기가 생겼다.
Git은 타임머신! 시간 여행자가 되다
종립님이 Git에 대해 테크 위클리에서 강의를 해주셨다.
Git은 소스를 올리고 pull 받아서 개발하는 소스관리 도구로만 생각했었는데, Git은 타임머신이라는 것을 알게 되었고, Git을 이용해서 팀원들은 점차 시간 여행자가 되었다.
Git 그래프가 꼬여서 고민하던 날, 종립님, 지훈님, 우현님과 함께 머리를 맞대고 화이트보드에 Git 그래프를 그려가면서 어떻게 꼬인 그래프를 풀어나갈 것인지 얘기를 나누기도 했다.
이런 과정을 통해 정확히 사용할 줄 몰랐던 Git을 터미널을 이용해서도 사용할 수 있게 되었고, Git의 히스토리를 관리할 수 있게 되었다.
코드 리뷰로 다양한 관점에서 코드를 개선하다
Pull Request를 통해 팀원들과 코드 리뷰를 한다.
2명 이상의 팀원들이 Approved를 해야 Develop 브랜치에 코드를 merge 할 수 있다.
PR의 리뷰가 필수인 환경이다 보니 끊임없이 토론이 펼쳐지곤 한다.
프로그래밍에 정답은 없기에 각자 자신의 주장에 맞는 근거를 제시하며 설득해나가는 재미도 느끼곤 한다. 팀원들의 다양한 관점에서의 코드리뷰를 통해, 내가 예상하지 못했던 버그를 발견하거나 좀 더 직관적인 코드를 작성해서 추가 커밋을 올리기도 한다.
실수를 공유하고 관리하는 문화
김창준 님의 저서 함께 자라기를 읽으며, 이 책에 나온 실수 관리 문화에 대해 깊은 인상을 받았었다.
김창준, 함께자라기(도서출판 인사이트), p91
실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다. 실수에서 배우지 못하겠지요.
반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다.
얼마 전, 쿠폰 서비스 장애가 발생한 적이 있다.
쿠폰 장애 관련 회의를 통해 인프라 관련 구조 개선이 필요하다는 사실을 인지하게 되었다.
누군가에게 책임을 묻고, 잘잘못을 따지는 게 아니라, 문제를 인식하고 어떻게 개선할지 함께 고민하는 문화가 인상적이었다.
함께 자라기에서 나오는 실수를 공유하고 관리하는 문화가 이곳에는 있었다.
앞으로를 기대하며
성장하고 있는 회사에서 레거시를 떼어내고 밑바닥부터 개발할 수 있는 경험을 하는 건 흔하지 않은 기회라고 생각합니다. 함께 폭풍 성장할 개발자분들 환영합니다! 저희 팀은 여러분을 기다리고 있습니다!
채용공고는 Java 서버 개발자(커머스시스템)를 참고해주세요!