2024년 1월부터 한국신용데이터 데이터플랫폼팀에서 백엔드 개발자로 일하고 있는 주니어 개발자 Skull(김윤기)입니다. 갓 수습을 마친 지 1개월 차. 길다면 길었던 3개월간의 수습 기간을 돌아보며 회사에 적응하면서 깨달았던 점과 느낀 점을 적어보았습니다.
입사하기까지
한국신용데이터와의 첫 만남은 작년 11월이었습니다.
저는 개발자를 희망하며 실력을 더 키우기 위해 우아한테크코스 4기를 수료하였는데요, 수료 후 작년 11월에 우아한테크코스 리크루팅데이가 개최된다는 소식을 들었습니다. 여러 기업이 리크루팅데이에 참가하였고, 관심 가는 기업들이 몇 군데 있었습니다. 한국신용데이터도 포함이었어요. HR, 개발 직군, 심지어 CTO이신 Oliver 님까지 오셔서 적극적으로 Q&A를 해주시는 모습을 보고 “정말 인재 영입을 진심으로 대하는 회사이구나”, “이 회사에 가면 좋은 사람들과 일할 수 있겠구나” 싶었었습니다! 우아한테크코스 리크루팅데이 과정에 대해 더 궁금하시면 우아한테크코스 오픈 리크루팅 데이 참여 후기; 너 내 동료가 되어라! 을 참고해 주세요.
그 후 한국신용데이터에 지원했고 여러 번의 면접을 통해 한국신용데이터에 합류하게 되었습니다.
입사 1개월 차
입사 후 첫 1개월은 회사 프로세스를 익히면서 보냈습니다. 회사에 입사하고 보니, 일을 하기 위해 알아야 하는 프로세스가 정말 많았습니다. 가장 기억나는 것은 기안을 올리는 것과 내부망의 존재입니다. 회사가 My data 사업자이다 보니 특히 다른 기업보다 보안에 민감한데요. 이 때문에 업무에 필요한 방화벽 허용 등을 위해 기안을 올려 승인받고, production 관련된 일은 모두 내부망을 통해서만 가능합니다. 처음에는 기안 양식과 프로세스가 익숙지 않아서 상신하고도 틀렸을까 봐 노심초사했었습니다. 하지만, 한 달 정도 일을 하면서 필요에 의한 다양한 기안을 작성하다 보니 어느새 절차에 익숙해져 있었습니다.
온보딩을 시작하면서 받았던 프로젝트도 기억에 남습니다. 간단히 말하면 기존 스칼라 서버 — kinesis -firehose — lambda로 되어 있던 카카오 메시지 발송 기능을 spring, kafka로 이전하는 프로젝트였습니다. 스칼라 코드를 아예 처음 보기 때문에 내가 저 코드를 제대로 파악할 수 있을까에 대한 고민이 많았습니다. 하지만 필요한 부분을 한 줄씩 분석하고, 모르는 부분은 찾아가면서, 사수에게 분석 내용을 보고하고 피드백을 받다 보니 어느새 전체 플로우를 파악할 수 있게 되었습니다.
입사 2개월 차
온보딩으로 받았던 프로젝트에 대한 파악을 끝내고 구현을 시작했습니다. 그와 동시에 다른 업무도 받으면서 동시에 진행했던 시기였습니다. 그러면서 마주쳤던 동시성 문제가 가장 기억에 남아서 이를 간략하고 소개하겠습니다.
우선 구현했던 로직은 다음과 같습니다.
- 카프카 프로듀서가 어떠한 이벤트를 produce한다. 이때 토픽을 T1이라 하자. 이벤트에는 유저를 식별할 수 있는 userId가 존재한다.
- 하나의 컨슈머 그룹에 있는 컨슈머들은 T1으로부터 메시지를 소비한다
- 소비한 메시지에서 userId를 사용해 다음과 같은 로직을 수행한다
- userId를 통해 DB 레코드가 있는지 확인한다
- 레코드가 있으면 레코드를 update한다
- 레코드가 없으면 새로운 레코드를 insert한다.
4. manual commit을 진행한다
위 로직 중 3번에서 동일한 userId를 가진 레코드가 여러 번 insert 되는 문제가 발생했습니다. 이 문제는 카프카 토픽의 파티션과 컨슈머들이 1:1 대응되는 상황에서, producer가 메시지를 produce할 때 라운드로빈 방식으로 각 파티션에 메시지를 produce하기 때문에 발생했습니다. 즉, 같은 userId를 가지 여러 메시지가 각기 다른 파티션에서 각기 다른 consumer에 의해 소비되어서 순서 보장이 되지 않은 채로 동시에 userId를 기준으로 디비 레코드 존재 유무를 판단해서 발생한 문제였습니다. 이를 도식화해서 보면 다음과 같습니다.
이 문제의 근본 원인을 파악하기까지 꽤 긴 시간이 필요했지만, 해결 방법은 간단했습니다. kafka producer에서 메시지를 produce할 때 userId를 키값으로 정해주는 것이 해결책이었습니다. 키값을 정해주면 그 키를 기준으로 메시지가 들어갈 파티션이 정해집니다. 따라서 여러 파티션에 같은 userId를 가진 여러 메시지가 분산되어서 저장될 일이 없어집니다. 결국, 서로 다른 컨슈머들이 같은 userId를 가진 서로 다른 메시지를 동시에 소비할 일이 없어서 위 문제가 해결됩니다.
코드 단에서의 해결 방법은 다음과 같습니다.
입사 3개월 차
3개월 차부터는 온보딩 프로젝트 구현이 어느 정도 마무리되고, 다른 운영 업무도 맡으면서 학생 때는 경험해 보지 못한, 운영에 필요한 커뮤니케이션 스킬을 배운 시기였습니다. 학생으로 공부할 때는 구현에서 마주칠 수 있는 문제를 주로 고민했습니다. 대화 상대도 대부분 개발자여서 그냥 편하게 관련 사항을 말하면 되었습니다. 그러나 회사에서 브레이즈 운영을 배우면서 다른 식의 커뮤니케이션과 다른 식의 고민하게 되었습니다. 커뮤니케이션의 경우, 커뮤니케이션 상대가 대게는 마케터분들입니다. 그 때문에 예전처럼 개발 용어를 섞어가면서 대화하는 대신, 상대가 이해하기 편하게 답변하게 되었습니다. 가령, “특정 데이터가 왜 조회가 안 되나요?”라는 문의에 대해 “배치가 아직 안 돌았어요”라는 답변을 하는 대신 “XX시가 지나야 조회가 가능합니다”라는 식으로요. 문제 해결을 위한 방식도 다릅니다. 예전에는 디버깅 툴을 이용해 하나씩 디버깅해 나가다 보면 문제가 해결되었습니다. 하지만, 운영에는 디버깅 툴이 없습니다. 문제가 될 만한 부분을 하나씩 찾아보면서 팀에서 운영하는 서비스의 문제인지, Saas의 문제인지를 찾아야 합니다. 팀에서 운영하는 서비스의 문제라면 버그를 찾아 해결해야 하고, Saas 문제라면 외부 담당자분께 문의 메일을 보내 해결해야 합니다. 그러면서도 최대한 리소스를 적게 들이면서 마케팅에 문제가 없도록 해야 합니다. 사실 저도 말로는 이해하고 있지만, 아직 완벽하게 익숙하지 않아서 몸이 안 따라주고 있습니다…
수습이 끝난 이후
수습이 끝난 이후 든 생각은 회사에 잘 적응하고 있구나 였습니다. 어느새 회사 프로세스에 익숙해져서 맡은 일을 큰 문제 없이 해내고 있습니다. 돌이켜 보면 회사의 온보딩 프로세스와 팀원들이 회사 적응에 가장 큰 도움이 되었던 것 같습니다. 팀원들과 인사팀분 들이 회사 적응에 힘든 점은 없는지 틈틈이 다가와 물어봐 주었고, 일을 잘할 수 있는 소소한 팁들을 알려주었습니다. 회사는 타 팀원들과도 친해질 수 있게 버디를 배정해 주고, 다양한 식사 자리를 만들어 주어서 많은 분들과 안면을 트고 지내게 되었습니다. 덕분에 타 팀과의 커뮤니케이션을 조금 덜 부담스럽게 할 수 있었습니다.
KCD는 이런분을 모십니다!
제가 생각해 봤을 때 KCD에 다니면서 느꼈던 점은
- 네카라쿠배에서 많은 경험을 쌓으신 훌륭한 시니어분들이 많습니다. 그 때문에 일을 하면서 KCD에서 일을 잘하는 방법을 넘어 좋은 개발자가 되기 위한 방법까지 배울 수 있습니다.
- 한참 성장 중인 스타트업이라 다양한 개발 문화가 적용되는 것을 직접 체감하면서 회사와 함께 성장할 수 있습니다.
첫 만남은 너무 어려워! 라는 말처럼 첫 회사를 고르는 건 어렵다고 생각합니다.
하지만 KCD에서의 첫 단추를 꿰맨 것에 후회는 없는 것 같아요. 많은 경험이 쌓인 훌륭한 시니어분들을 보고 성장해서, 나중에 시니어가 되었을 때, 주니어분들에게 길을 알려줄 수 있는 시니어가 되고 싶습니다.
데이터플랫폼팀 Skull(스컬)
2024년 1월부터 한국신용데이터 데이터플랫폼팀에서 백엔드 개발자로 일하고 있는 주니어 개발자 Skull(김윤기)입니다. 갓 수습을 마친 지 1개월 차. 길다면 길었던 3개월간의 수습 기간을 돌아보며 회사에 적응하면서 깨달았던 점과 느낀 점을 적어보았습니다.
입사하기까지
한국신용데이터와의 첫 만남은 작년 11월이었습니다.
저는 개발자를 희망하며 실력을 더 키우기 위해 우아한테크코스 4기를 수료하였는데요, 수료 후 작년 11월에 우아한테크코스 리크루팅데이가 개최된다는 소식을 들었습니다. 여러 기업이 리크루팅데이에 참가하였고, 관심 가는 기업들이 몇 군데 있었습니다. 한국신용데이터도 포함이었어요. HR, 개발 직군, 심지어 CTO이신 Oliver 님까지 오셔서 적극적으로 Q&A를 해주시는 모습을 보고 “정말 인재 영입을 진심으로 대하는 회사이구나”, “이 회사에 가면 좋은 사람들과 일할 수 있겠구나” 싶었었습니다! 우아한테크코스 리크루팅데이 과정에 대해 더 궁금하시면 우아한테크코스 오픈 리크루팅 데이 참여 후기; 너 내 동료가 되어라! 을 참고해 주세요.
그 후 한국신용데이터에 지원했고 여러 번의 면접을 통해 한국신용데이터에 합류하게 되었습니다.
입사 1개월 차
입사 후 첫 1개월은 회사 프로세스를 익히면서 보냈습니다. 회사에 입사하고 보니, 일을 하기 위해 알아야 하는 프로세스가 정말 많았습니다. 가장 기억나는 것은 기안을 올리는 것과 내부망의 존재입니다. 회사가 My data 사업자이다 보니 특히 다른 기업보다 보안에 민감한데요. 이 때문에 업무에 필요한 방화벽 허용 등을 위해 기안을 올려 승인받고, production 관련된 일은 모두 내부망을 통해서만 가능합니다. 처음에는 기안 양식과 프로세스가 익숙지 않아서 상신하고도 틀렸을까 봐 노심초사했었습니다. 하지만, 한 달 정도 일을 하면서 필요에 의한 다양한 기안을 작성하다 보니 어느새 절차에 익숙해져 있었습니다.
온보딩을 시작하면서 받았던 프로젝트도 기억에 남습니다. 간단히 말하면 기존 스칼라 서버 — kinesis -firehose — lambda로 되어 있던 카카오 메시지 발송 기능을 spring, kafka로 이전하는 프로젝트였습니다. 스칼라 코드를 아예 처음 보기 때문에 내가 저 코드를 제대로 파악할 수 있을까에 대한 고민이 많았습니다. 하지만 필요한 부분을 한 줄씩 분석하고, 모르는 부분은 찾아가면서, 사수에게 분석 내용을 보고하고 피드백을 받다 보니 어느새 전체 플로우를 파악할 수 있게 되었습니다.
입사 2개월 차
온보딩으로 받았던 프로젝트에 대한 파악을 끝내고 구현을 시작했습니다. 그와 동시에 다른 업무도 받으면서 동시에 진행했던 시기였습니다. 그러면서 마주쳤던 동시성 문제가 가장 기억에 남아서 이를 간략하고 소개하겠습니다.
우선 구현했던 로직은 다음과 같습니다.
4. manual commit을 진행한다
위 로직 중 3번에서 동일한 userId를 가진 레코드가 여러 번 insert 되는 문제가 발생했습니다. 이 문제는 카프카 토픽의 파티션과 컨슈머들이 1:1 대응되는 상황에서, producer가 메시지를 produce할 때 라운드로빈 방식으로 각 파티션에 메시지를 produce하기 때문에 발생했습니다. 즉, 같은 userId를 가지 여러 메시지가 각기 다른 파티션에서 각기 다른 consumer에 의해 소비되어서 순서 보장이 되지 않은 채로 동시에 userId를 기준으로 디비 레코드 존재 유무를 판단해서 발생한 문제였습니다. 이를 도식화해서 보면 다음과 같습니다.
이 문제의 근본 원인을 파악하기까지 꽤 긴 시간이 필요했지만, 해결 방법은 간단했습니다. kafka producer에서 메시지를 produce할 때 userId를 키값으로 정해주는 것이 해결책이었습니다. 키값을 정해주면 그 키를 기준으로 메시지가 들어갈 파티션이 정해집니다. 따라서 여러 파티션에 같은 userId를 가진 여러 메시지가 분산되어서 저장될 일이 없어집니다. 결국, 서로 다른 컨슈머들이 같은 userId를 가진 서로 다른 메시지를 동시에 소비할 일이 없어서 위 문제가 해결됩니다.
코드 단에서의 해결 방법은 다음과 같습니다.
입사 3개월 차
3개월 차부터는 온보딩 프로젝트 구현이 어느 정도 마무리되고, 다른 운영 업무도 맡으면서 학생 때는 경험해 보지 못한, 운영에 필요한 커뮤니케이션 스킬을 배운 시기였습니다. 학생으로 공부할 때는 구현에서 마주칠 수 있는 문제를 주로 고민했습니다. 대화 상대도 대부분 개발자여서 그냥 편하게 관련 사항을 말하면 되었습니다. 그러나 회사에서 브레이즈 운영을 배우면서 다른 식의 커뮤니케이션과 다른 식의 고민하게 되었습니다. 커뮤니케이션의 경우, 커뮤니케이션 상대가 대게는 마케터분들입니다. 그 때문에 예전처럼 개발 용어를 섞어가면서 대화하는 대신, 상대가 이해하기 편하게 답변하게 되었습니다. 가령, “특정 데이터가 왜 조회가 안 되나요?”라는 문의에 대해 “배치가 아직 안 돌았어요”라는 답변을 하는 대신 “XX시가 지나야 조회가 가능합니다”라는 식으로요. 문제 해결을 위한 방식도 다릅니다. 예전에는 디버깅 툴을 이용해 하나씩 디버깅해 나가다 보면 문제가 해결되었습니다. 하지만, 운영에는 디버깅 툴이 없습니다. 문제가 될 만한 부분을 하나씩 찾아보면서 팀에서 운영하는 서비스의 문제인지, Saas의 문제인지를 찾아야 합니다. 팀에서 운영하는 서비스의 문제라면 버그를 찾아 해결해야 하고, Saas 문제라면 외부 담당자분께 문의 메일을 보내 해결해야 합니다. 그러면서도 최대한 리소스를 적게 들이면서 마케팅에 문제가 없도록 해야 합니다. 사실 저도 말로는 이해하고 있지만, 아직 완벽하게 익숙하지 않아서 몸이 안 따라주고 있습니다…
수습이 끝난 이후
수습이 끝난 이후 든 생각은 회사에 잘 적응하고 있구나 였습니다. 어느새 회사 프로세스에 익숙해져서 맡은 일을 큰 문제 없이 해내고 있습니다. 돌이켜 보면 회사의 온보딩 프로세스와 팀원들이 회사 적응에 가장 큰 도움이 되었던 것 같습니다. 팀원들과 인사팀분 들이 회사 적응에 힘든 점은 없는지 틈틈이 다가와 물어봐 주었고, 일을 잘할 수 있는 소소한 팁들을 알려주었습니다. 회사는 타 팀원들과도 친해질 수 있게 버디를 배정해 주고, 다양한 식사 자리를 만들어 주어서 많은 분들과 안면을 트고 지내게 되었습니다. 덕분에 타 팀과의 커뮤니케이션을 조금 덜 부담스럽게 할 수 있었습니다.
KCD는 이런분을 모십니다!
제가 생각해 봤을 때 KCD에 다니면서 느꼈던 점은
첫 만남은 너무 어려워! 라는 말처럼 첫 회사를 고르는 건 어렵다고 생각합니다.
하지만 KCD에서의 첫 단추를 꿰맨 것에 후회는 없는 것 같아요. 많은 경험이 쌓인 훌륭한 시니어분들을 보고 성장해서, 나중에 시니어가 되었을 때, 주니어분들에게 길을 알려줄 수 있는 시니어가 되고 싶습니다.