안녕하세요! 서비스플랫폼팀에서 백엔드 엔지니어 Sophia 입니다.🙂
작년 9월, 풋풋한 신입으로 입사했는데 벌써 약 1년이라는 시간이 훌쩍 지났습니다.
오늘은 19살 고등학생이던 제가 어떻게 한국신용데이터에 합류하게 되었는지 그리고 1년간 성장 스토리를 솔직하게 풀어보려 합니다.
19살 직장인의 첫 시작
저는 회사에 입사하기 전까지 미림마이스터고등학교에 다니던 평범한 고등학생이었습니다.
제가 다녔던 마이스터고등학교는 일반 고등학교와 동일하게 3년 교육 과정을 마쳐야 하지만 대학 진학보다 취업을 목표로 한다는 점이 가장 큰 차이점입니다. 취업에 집중하다 보니 마이스터 고등학교는 다양한 학과로 나뉘어 있고 각 학과마다 배우는 내용도 다릅니다. 저는 그 중 ‘소프트웨어과’를 선택해 3년간 공부해 왔습니다.
한국신용데이터와의 첫 만남은 학교에서 열린 회사 설명회를 통해서였습니다. 설명회에서 한국신용데이터가 빠르게 성장하는 모습을 그래프로 보여주셨는데 당시 저는 회사의 도메인과 서비스 내용에 자연스럽게 관심이 생겼습니다. 당시 ‘160만 명(현재 180만명)의 자영업 사장님들을 도울 수 있는 서비스’라는 이야기가 제 눈길을 사로잡았는데 '나도 사용자에게 도움이 되는 서비스를 만들고 싶다'는 명확한 목표가 생겼습니다. 그 마음으로 지원서를 제출했고 기다리던 합격 소식을 들었을 때의 기쁨과 뿌듯함은 아직도 생생합니다. 그때는 실감이 잘 나지 않으면서도 정말 감사한 마음이 들었습니다.
어느덧 캐시노트 180만명의 자영업 사장님들을 돕는 서비스가 되었습니다!
처음이지만 편안했던 첫 출근
처음 출근하던 날, 학교가 아닌 회사로 향하는 길은 설렘과 함께 ‘과연 잘 적응할 수 있을까’ 하는 걱정이 앞섰습니다. 팀원들과 동료분들께 인사를 드리고 얼굴을 익히며 잘 지내는 제 모습을 상상하면서도 발걸음은 가볍지만 조심스러운 마음에 조금은 느리게 움직였던 것 같습니다. 새로운 환경에 빠르게 적응해 좋은 모습을 보여드리고 싶다는 마음이 컸습니다.
하지만 그런 걱정들은 첫날 자연스럽게 해소되었습니다.팀원들과 자기소개를 하며 서로 닉네임과 얼굴을 익히는 시간을 가졌고,커피를 마시고 점심도 함께하면서 점차 회사 분위기에 녹아들 수 있었습니다. 특히 저를 챙겨주었던 특히 저를 챙겨주었던 버디 'Anna' 덕분에 다른 팀 동료분들과도 친해질 수 있어서 적응이 훨씬 수월했습니다. 아래의 이미지처럼 다른 팀 동료분과도 점심도 같이 먹고, 모르는 부분을 세심하게 알려주며 하루가 정말 소중하게 흘러갔던 기억이 납니다.
처음 느꼈던 긴장과 걱정이 따뜻함으로 바뀌었던, 저에게 아주 특별한 하루였습니다.
실무에서 깨닫게 된 개발의 깊이
입사 후 첫 한 달
입사 후 첫 한 달은 회사의 업무 프로세스를 익히고 프로젝트 구조를 이해하는 데 집중했습니다.
학교에서의 개발 경험이 주로 기능 구현에 초점을 맞췄다면 실무에서는 본격적인 개발에 앞서 다양한 준비 단계가 필요했습니다.
예를 들면 필요한 기안 절차를 먼저 거치고 보안을 위한 내부망 환경에서의 작업 방식 등 새롭게 익히는 부분들이 많았었습니다. 처음에는 생소한 시스템과 양식에 익숙하지 않아 작성한 기안을 여러 번 검토하며 조심스럽게 제출하곤 했지만 점차 이러한 과정을 경험하면서 자연스럽게 적응할 수 있었습니다.
처음으로 기여한 프로젝트 ‘메시지 플랫폼’
업무적으로 처음 기여한 작업은 메시지 플랫폼 프로젝트에서의 기능 개발이었습니다.
제가 맡은 역할은 에러 로그를 슬랙 채널로 전송하는 기능을 구현하는 일이었는데 단순히 코드를 작성하기에 앞서 코드를 작성하려면 ‘메시지가 어떤 구조로 전달되는지’, ‘어디에서 에러가 발생할 수 있는지’ 등을 고민하면서 도메인에 대한 이해를 먼저 챙기기 위해 노력했었습니다.
이를 위해 팀원 분께서 프로젝트의 도메인과 흐름을 설명해주시는 시간을 주셨었고
해당 프로젝트에서 핵심 기술로 Kafka가 사용된다는 점도 알려주셨습니다.
이후 저는 Kafka의 프로듀서-컨슈머 구조, 메시지 전달 방식 등에 대해 이론을 공부하고 Docker 환경에서 Kafka를 직접 구동해보며 테스트를 진행했습니다.
실제로 메시지를 생성해 토픽을 전송하고 직접 에러 처리 시나리오를 확인해보면서 기능 구현에 필요한 실질적인 감각을 익혀나갈 수 있었습니다.
이러한 학습을 바탕으로 프로젝트 구조와 기능 구현 방향에 대해 팀원 분들 앞에서 발표하는 시간도 가졌었습니다.
발표를 준비하며 전체 흐름을 다시 점검하고 문서화하는 과정은 제가 맡은 기능이 전체 시스템 안에서 어떤 역할을 수행하는지를 보다 명확하게 이해하는 계기가 될 수 있었습니다.
기능 구현을 마무리 후 첫 PR을 등록한 후에는 팀의 코드 리뷰를 통해 기술적인 판단과 구조적 접근 방식에 대한 피드백도 받을 수 있었던 경험이었습니다.
실무에 익숙해지기까지
입사 두 달 차에는 신규 통합 회원 서비스인 ‘캐시노트 아이디’ 프로젝트에 본격적으로 참여하게 되었습니다.
처음에는 ‘내가 이렇게 큰 프로젝트에 참여해도 괜찮을까?’ 하는 부담감이 있었지만 학교에서의 경험과 실무 개발 사이의 차이로 인해 낯설음도 컸습니다. 특히 서비스 기획의 배경과 히스토리를 충분히 알지 못해 “이 API는 어떤 화면에서 호출되는 걸까?”, “이 플로우에서는 어떤 예외 케이스를 고려해야 하지?” 등 여러 질문들이 생기며 도메인 이해의 부족을 절감했습니다.
이에 따라 개발에 곧바로 착수하기보다는 우선 팀의 코드 구조와 컨벤션을 익히는 데 집중했습니다.
API가 사용자 흐름 속에서 어떻게 작동하는지와 에러 처리는 어느 시점에서 어떤 방식으로 해야 하는지를 하나씩 분석하고 학습해 나갔습니다.
혼자서 고민하던 시간도 있었지만 PM 분께 질문을 드리거나 기존 문서를 참고하며 전체 흐름을 파악해갔고 점차 머릿속에서 서비스 구조가 유기적으로 연결될 수 있었습니다.
이러한 과정으로 PR도 성공적으로 등록할 수 있었고 리뷰를 통해 다양한 피드백을 받을 수 있었습니다.
특히 코드 스타일을 넘어서 도메인부터 사용자 흐름까지 고려한 리뷰는 인상 깊었는데 팀 내 협업과 사용자 중심의 개발 방식에 대한 인사이트도 함께 얻을 수 있었습니다.
첫 PR이 머지되던 순간의 뿌듯함은 지금도 기억에 남는 것 같습니다 😀
프로젝트 확장과 함께한 성장
프로젝트가 점차 확장되면서 경험의 폭도 함께 넓어졌었습니다. 단순한 로그인 및 회원가입 구현을 넘어서
약관 동의 플로우 설계
기존 회원 서비스 마이그레이션
클린 아키텍처 기반의 리팩토링
QA 과정에서의 이슈 대응
등 다양한 작업을 통해 실무 개발의 전 과정을 경험할 수 있었습니다.
특히 인상 깊었던 경험은 처음올 아키텍처 설계에 직접 참여하게 되었던 일입니다.
저희는 클린 아키텍처를 도입해 프로젝트 구조를 새롭게 설계했습니다. 이어 팀원분들과 함께 컨벤션 정의 및 디렉토리 구성, 책임 분리에 대한 의견을 나누며 저희만의 기준을 세워 나가는 과정은 설계에 대한 이해도를 높일 수 있었고 개발자로서의 관점을 넓히게 된 계기가 되다고 생각합니다.
또한 기존 회원 서비스에서 사용하던 기능들을 새로운 시스템에 통합하는 마이그레이션 작업 역시 중요했던 경험이었습니다. 이 과정에서 데이터와 로직을 안정적으로 이전하기 위한 논의와 테스트를 반복하며 날날들을 보냈었습니다.
마지막으로 프로젝트는 QA 단계를 거치면서 운영 환경에 배포 완료되었고 실제 사용자에게 기능 전달되기까지 전 과정을 함께할 수 있었습니다.
처음에는 막막했던 실무 프로젝트였지만, 개발부터 운영까지 전체 사이클을 경험하며 서비스 전체를 바라보는 시야와 협업 경험을 함께 쌓을 수 있어서 배포한 이후 정말 뿌듯했던 것 같습니다.
첫번째 이미지 : TO-BE 캐시노트 아이디
두번째 이미지 : AS-IS 캐시노트 아이디
기능 구현을 넘어, 전체 흐름을 이해한다는 것
첫 프로젝트에 이어 가장 기억에 남는 프로젝트를 묻는다면 약관 시스템 교체 프로젝트가 가장 오래 기억에 남습니다.
기존 시스템의 약관을 신규 시스템으로 전환하는 작업은 처음에는 단순히 약관을 저장하고 조회하는 기능만 고려했습니다. 하지만 시간이 지날수록 실제 서비스에서는 어떤 흐름으로 약관이 적용되고 관리되어야 하는지를 고민하게 되었고 그 과정에서 다양한 커뮤니케이션과 설계 논의가 이어졌습니다.
결국 이러한 고민의 쌓이며 단순한 개발 이상으로 기억에 남는 프로젝트가 되었습니다.
처음 약관 플로우를 이해하고 도메인 지식을 쌓아가는 과정은 결코 쉽지 않았습니다. 기존 코드에서 약관이 어떻게 사용되고 있는지를 파악하고, 신규 시스템에서 어떤 방식으로 전환되어야 하는지를 해석하는 데 많은 시간이 필요했기 때문입니다.
“이 부분은 이렇게 바뀐 이유가 있었구나”, “기존 약관 처리에서 이런 점이 문제가 됐었구나”와 같은 생각을 반복하며 흐름을 따라가다 보니, 어느 순간 단순히 코드를 구현하는 것이 아니라 ‘전체 시스템 안에서 약관이 어떤 역할을 하는지’를 고민하게 되는 계기가 되었던 것 같습니다.
또한 이런 고민들이 깊어지면 "이 기능은 이렇게 해석하는 게 좋을까요?" 또는 "이 문제점이 발생할 수도 있을 것 같습니다"라는 질문을 많이 드렸었습니다. 같은 팀원분들은 언제나 열심히 들어주시고, 해결책을 알려주시면서 점차 문제를 해결해 나갈 수 있었습니다. 덕분에 약관을 하나씩 구현해 가면서 많이 배울 수 있었고 작업에 대한 자신감도 생겼던습니다. 또한 이러한 문제의 원인을 정확히 파악하고 재현 시나리오를 만들면서 점차 예상치 못한 상황에 유연하게 대응하는 힘도 키워나갈 수 있었습니다.
실제 업무를 맡고 약관 도메인에 대한 이해가 깊어질수록 내가 구현한 코드가 왜 이렇게 설계되어야 하는지 그리고 어떤 기준으로 수정되어야 하는지를 스스로 판단할 수 있는 힘도 키웠습니다.
이후 그 과정에서 자연스럽게 도메인 정리와 팀 공유의 필요성을 느껴 약관 플로우에 대한 내용을 정리해 팀원분들에게 발표하는 기회를 갖기도 했습니다. 발표 당시에는 팀원분들과 피드백을 주고받으며 단순 구현자가 아닌 프로젝트의 일원으로서 오너십을 느끼면서 책임감도 더 가져 프로젝트에 임할 수 있었습니다.
물론 프로젝트를 진행하는 동안 수차례 수정과 테스트를 반복하며 쉽지 않은 순간도 있었지만 돌이켜보면 그 과정들이 성장을 위한 발판이 되었다는 걸 느낍니다.
이번 프로젝트는 기술적인 성장도 있었지만 무엇보다 도메인과 도메인의 흐름, 예외 상황 등등 팀과 함께 문제를 풀어나가는 개발자의 역할을 새롭게 바라볼 수 있었습니다.
프로젝트를 마치고 여러 팀의 협력과 지원 덕분에 새로운 시스템을 잘 런칭할 수 있었다는 점에 감사했습니다. 저 역시 그 과정 속에서 한 단계 성장할 수 있었고 이 경험은 앞으로의 개발자 경험으로서 큰 밑거름이 될 것이라 믿습니다.
성장통을 겪고 얻은 깨달음: ‘더 나은 개발자’가 되기 위한 마음가짐
직접 참여한 프로젝트를 배포하고 서비스를 운영해보면서 실제 업무를 통해 다양한 케이스를 접하고 이를 해결하는 과정에서 많은 것을 배웠습니다. 그 과정에서 겪은 문제들을 해결해 나가며 지금도 계속해서 배우고 성장하고 있다는 생각이 듭니다. 이렇게 프로젝트를 마칠 수 있어 정말 뿌듯함과앞으로의 마음가짐을 이 글을 통해 정리하며 마무리하고자 합니다.
이번 프로젝트를 진행하면서 저는 느낀 점이 한 가지 있습니다.
바로 ‘개발자에게는 여러 선택의 순간들이 있다’는 사실 입니다. 여러 선택이 있는 순간들 중에서 단순히 눈앞의 문제를 해결하는 데 급급하기보다는, ‘왜 이 방법을 선택해야 하는가?’ 또는 ‘이게 최선의 방법일까?’에 대해 깊게 고민하는 것이 중요하다는 점 입니다.
이러한 마음가짐이 앞으로 더 나은 개발자로 성장하는 데 도움이 될 거라 생각합니다.
이 글을 마무리하면서, 앞으로도 매 순간을 깊이 생각하며 고민하고 최선의 선택을 할 수 있도록 노력하는 마음가짐을 KCD에서 계속해서 유지해 나가고 싶습니다.
PS. 회사에 잘 적응할 수 있도록 도움 주신 저희 회사 분들과 팀원분들에게..!! 무한히 감사합니다.
지금, KCD는 사장님의 더 나은 내일을 위해 함께할 동료를 찾고 있어요.
✨영입 중인 포지션 확인하기
✨KCD가 더 궁금하다면?
안녕하세요! 서비스플랫폼팀에서 백엔드 엔지니어 Sophia 입니다.🙂
작년 9월, 풋풋한 신입으로 입사했는데 벌써 약 1년이라는 시간이 훌쩍 지났습니다.
오늘은 19살 고등학생이던 제가 어떻게 한국신용데이터에 합류하게 되었는지 그리고 1년간 성장 스토리를 솔직하게 풀어보려 합니다.
19살 직장인의 첫 시작
저는 회사에 입사하기 전까지 미림마이스터고등학교에 다니던 평범한 고등학생이었습니다.
제가 다녔던 마이스터고등학교는 일반 고등학교와 동일하게 3년 교육 과정을 마쳐야 하지만 대학 진학보다 취업을 목표로 한다는 점이 가장 큰 차이점입니다. 취업에 집중하다 보니 마이스터 고등학교는 다양한 학과로 나뉘어 있고 각 학과마다 배우는 내용도 다릅니다. 저는 그 중 ‘소프트웨어과’를 선택해 3년간 공부해 왔습니다.
한국신용데이터와의 첫 만남은 학교에서 열린 회사 설명회를 통해서였습니다. 설명회에서 한국신용데이터가 빠르게 성장하는 모습을 그래프로 보여주셨는데 당시 저는 회사의 도메인과 서비스 내용에 자연스럽게 관심이 생겼습니다. 당시 ‘160만 명(현재 180만명)의 자영업 사장님들을 도울 수 있는 서비스’라는 이야기가 제 눈길을 사로잡았는데 '나도 사용자에게 도움이 되는 서비스를 만들고 싶다'는 명확한 목표가 생겼습니다. 그 마음으로 지원서를 제출했고 기다리던 합격 소식을 들었을 때의 기쁨과 뿌듯함은 아직도 생생합니다. 그때는 실감이 잘 나지 않으면서도 정말 감사한 마음이 들었습니다.
어느덧 캐시노트 180만명의 자영업 사장님들을 돕는 서비스가 되었습니다!
처음이지만 편안했던 첫 출근
처음 출근하던 날, 학교가 아닌 회사로 향하는 길은 설렘과 함께 ‘과연 잘 적응할 수 있을까’ 하는 걱정이 앞섰습니다. 팀원들과 동료분들께 인사를 드리고 얼굴을 익히며 잘 지내는 제 모습을 상상하면서도 발걸음은 가볍지만 조심스러운 마음에 조금은 느리게 움직였던 것 같습니다. 새로운 환경에 빠르게 적응해 좋은 모습을 보여드리고 싶다는 마음이 컸습니다.
하지만 그런 걱정들은 첫날 자연스럽게 해소되었습니다.팀원들과 자기소개를 하며 서로 닉네임과 얼굴을 익히는 시간을 가졌고,커피를 마시고 점심도 함께하면서 점차 회사 분위기에 녹아들 수 있었습니다. 특히 저를 챙겨주었던 특히 저를 챙겨주었던 버디 'Anna' 덕분에 다른 팀 동료분들과도 친해질 수 있어서 적응이 훨씬 수월했습니다. 아래의 이미지처럼 다른 팀 동료분과도 점심도 같이 먹고, 모르는 부분을 세심하게 알려주며 하루가 정말 소중하게 흘러갔던 기억이 납니다.
처음 느꼈던 긴장과 걱정이 따뜻함으로 바뀌었던, 저에게 아주 특별한 하루였습니다.
실무에서 깨닫게 된 개발의 깊이
입사 후 첫 한 달
입사 후 첫 한 달은 회사의 업무 프로세스를 익히고 프로젝트 구조를 이해하는 데 집중했습니다.
학교에서의 개발 경험이 주로 기능 구현에 초점을 맞췄다면 실무에서는 본격적인 개발에 앞서 다양한 준비 단계가 필요했습니다.
예를 들면 필요한 기안 절차를 먼저 거치고 보안을 위한 내부망 환경에서의 작업 방식 등 새롭게 익히는 부분들이 많았었습니다. 처음에는 생소한 시스템과 양식에 익숙하지 않아 작성한 기안을 여러 번 검토하며 조심스럽게 제출하곤 했지만 점차 이러한 과정을 경험하면서 자연스럽게 적응할 수 있었습니다.
처음으로 기여한 프로젝트 ‘메시지 플랫폼’
업무적으로 처음 기여한 작업은 메시지 플랫폼 프로젝트에서의 기능 개발이었습니다.
제가 맡은 역할은 에러 로그를 슬랙 채널로 전송하는 기능을 구현하는 일이었는데 단순히 코드를 작성하기에 앞서 코드를 작성하려면 ‘메시지가 어떤 구조로 전달되는지’, ‘어디에서 에러가 발생할 수 있는지’ 등을 고민하면서 도메인에 대한 이해를 먼저 챙기기 위해 노력했었습니다.
이를 위해 팀원 분께서 프로젝트의 도메인과 흐름을 설명해주시는 시간을 주셨었고
해당 프로젝트에서 핵심 기술로 Kafka가 사용된다는 점도 알려주셨습니다.
이후 저는 Kafka의 프로듀서-컨슈머 구조, 메시지 전달 방식 등에 대해 이론을 공부하고 Docker 환경에서 Kafka를 직접 구동해보며 테스트를 진행했습니다.
실제로 메시지를 생성해 토픽을 전송하고 직접 에러 처리 시나리오를 확인해보면서 기능 구현에 필요한 실질적인 감각을 익혀나갈 수 있었습니다.
이러한 학습을 바탕으로 프로젝트 구조와 기능 구현 방향에 대해 팀원 분들 앞에서 발표하는 시간도 가졌었습니다.
발표를 준비하며 전체 흐름을 다시 점검하고 문서화하는 과정은 제가 맡은 기능이 전체 시스템 안에서 어떤 역할을 수행하는지를 보다 명확하게 이해하는 계기가 될 수 있었습니다.
기능 구현을 마무리 후 첫 PR을 등록한 후에는 팀의 코드 리뷰를 통해 기술적인 판단과 구조적 접근 방식에 대한 피드백도 받을 수 있었던 경험이었습니다.
실무에 익숙해지기까지
입사 두 달 차에는 신규 통합 회원 서비스인 ‘캐시노트 아이디’ 프로젝트에 본격적으로 참여하게 되었습니다.
처음에는 ‘내가 이렇게 큰 프로젝트에 참여해도 괜찮을까?’ 하는 부담감이 있었지만 학교에서의 경험과 실무 개발 사이의 차이로 인해 낯설음도 컸습니다. 특히 서비스 기획의 배경과 히스토리를 충분히 알지 못해 “이 API는 어떤 화면에서 호출되는 걸까?”, “이 플로우에서는 어떤 예외 케이스를 고려해야 하지?” 등 여러 질문들이 생기며 도메인 이해의 부족을 절감했습니다.
이에 따라 개발에 곧바로 착수하기보다는 우선 팀의 코드 구조와 컨벤션을 익히는 데 집중했습니다.
API가 사용자 흐름 속에서 어떻게 작동하는지와 에러 처리는 어느 시점에서 어떤 방식으로 해야 하는지를 하나씩 분석하고 학습해 나갔습니다.
혼자서 고민하던 시간도 있었지만 PM 분께 질문을 드리거나 기존 문서를 참고하며 전체 흐름을 파악해갔고 점차 머릿속에서 서비스 구조가 유기적으로 연결될 수 있었습니다.
이러한 과정으로 PR도 성공적으로 등록할 수 있었고 리뷰를 통해 다양한 피드백을 받을 수 있었습니다.
특히 코드 스타일을 넘어서 도메인부터 사용자 흐름까지 고려한 리뷰는 인상 깊었는데 팀 내 협업과 사용자 중심의 개발 방식에 대한 인사이트도 함께 얻을 수 있었습니다.
첫 PR이 머지되던 순간의 뿌듯함은 지금도 기억에 남는 것 같습니다 😀
프로젝트 확장과 함께한 성장
프로젝트가 점차 확장되면서 경험의 폭도 함께 넓어졌었습니다. 단순한 로그인 및 회원가입 구현을 넘어서
약관 동의 플로우 설계
기존 회원 서비스 마이그레이션
클린 아키텍처 기반의 리팩토링
QA 과정에서의 이슈 대응
등 다양한 작업을 통해 실무 개발의 전 과정을 경험할 수 있었습니다.
특히 인상 깊었던 경험은 처음올 아키텍처 설계에 직접 참여하게 되었던 일입니다.
저희는 클린 아키텍처를 도입해 프로젝트 구조를 새롭게 설계했습니다. 이어 팀원분들과 함께 컨벤션 정의 및 디렉토리 구성, 책임 분리에 대한 의견을 나누며 저희만의 기준을 세워 나가는 과정은 설계에 대한 이해도를 높일 수 있었고 개발자로서의 관점을 넓히게 된 계기가 되다고 생각합니다.
또한 기존 회원 서비스에서 사용하던 기능들을 새로운 시스템에 통합하는 마이그레이션 작업 역시 중요했던 경험이었습니다. 이 과정에서 데이터와 로직을 안정적으로 이전하기 위한 논의와 테스트를 반복하며 날날들을 보냈었습니다.
마지막으로 프로젝트는 QA 단계를 거치면서 운영 환경에 배포 완료되었고 실제 사용자에게 기능 전달되기까지 전 과정을 함께할 수 있었습니다.
처음에는 막막했던 실무 프로젝트였지만, 개발부터 운영까지 전체 사이클을 경험하며 서비스 전체를 바라보는 시야와 협업 경험을 함께 쌓을 수 있어서 배포한 이후 정말 뿌듯했던 것 같습니다.
첫번째 이미지 : TO-BE 캐시노트 아이디
두번째 이미지 : AS-IS 캐시노트 아이디
기능 구현을 넘어, 전체 흐름을 이해한다는 것
첫 프로젝트에 이어 가장 기억에 남는 프로젝트를 묻는다면 약관 시스템 교체 프로젝트가 가장 오래 기억에 남습니다.
기존 시스템의 약관을 신규 시스템으로 전환하는 작업은 처음에는 단순히 약관을 저장하고 조회하는 기능만 고려했습니다. 하지만 시간이 지날수록 실제 서비스에서는 어떤 흐름으로 약관이 적용되고 관리되어야 하는지를 고민하게 되었고 그 과정에서 다양한 커뮤니케이션과 설계 논의가 이어졌습니다.
결국 이러한 고민의 쌓이며 단순한 개발 이상으로 기억에 남는 프로젝트가 되었습니다.
처음 약관 플로우를 이해하고 도메인 지식을 쌓아가는 과정은 결코 쉽지 않았습니다. 기존 코드에서 약관이 어떻게 사용되고 있는지를 파악하고, 신규 시스템에서 어떤 방식으로 전환되어야 하는지를 해석하는 데 많은 시간이 필요했기 때문입니다.
“이 부분은 이렇게 바뀐 이유가 있었구나”, “기존 약관 처리에서 이런 점이 문제가 됐었구나”와 같은 생각을 반복하며 흐름을 따라가다 보니, 어느 순간 단순히 코드를 구현하는 것이 아니라 ‘전체 시스템 안에서 약관이 어떤 역할을 하는지’를 고민하게 되는 계기가 되었던 것 같습니다.
또한 이런 고민들이 깊어지면 "이 기능은 이렇게 해석하는 게 좋을까요?" 또는 "이 문제점이 발생할 수도 있을 것 같습니다"라는 질문을 많이 드렸었습니다. 같은 팀원분들은 언제나 열심히 들어주시고, 해결책을 알려주시면서 점차 문제를 해결해 나갈 수 있었습니다. 덕분에 약관을 하나씩 구현해 가면서 많이 배울 수 있었고 작업에 대한 자신감도 생겼던습니다. 또한 이러한 문제의 원인을 정확히 파악하고 재현 시나리오를 만들면서 점차 예상치 못한 상황에 유연하게 대응하는 힘도 키워나갈 수 있었습니다.
실제 업무를 맡고 약관 도메인에 대한 이해가 깊어질수록 내가 구현한 코드가 왜 이렇게 설계되어야 하는지 그리고 어떤 기준으로 수정되어야 하는지를 스스로 판단할 수 있는 힘도 키웠습니다.
이후 그 과정에서 자연스럽게 도메인 정리와 팀 공유의 필요성을 느껴 약관 플로우에 대한 내용을 정리해 팀원분들에게 발표하는 기회를 갖기도 했습니다. 발표 당시에는 팀원분들과 피드백을 주고받으며 단순 구현자가 아닌 프로젝트의 일원으로서 오너십을 느끼면서 책임감도 더 가져 프로젝트에 임할 수 있었습니다.
물론 프로젝트를 진행하는 동안 수차례 수정과 테스트를 반복하며 쉽지 않은 순간도 있었지만 돌이켜보면 그 과정들이 성장을 위한 발판이 되었다는 걸 느낍니다.
이번 프로젝트는 기술적인 성장도 있었지만 무엇보다 도메인과 도메인의 흐름, 예외 상황 등등 팀과 함께 문제를 풀어나가는 개발자의 역할을 새롭게 바라볼 수 있었습니다.
프로젝트를 마치고 여러 팀의 협력과 지원 덕분에 새로운 시스템을 잘 런칭할 수 있었다는 점에 감사했습니다. 저 역시 그 과정 속에서 한 단계 성장할 수 있었고 이 경험은 앞으로의 개발자 경험으로서 큰 밑거름이 될 것이라 믿습니다.
성장통을 겪고 얻은 깨달음: ‘더 나은 개발자’가 되기 위한 마음가짐
직접 참여한 프로젝트를 배포하고 서비스를 운영해보면서 실제 업무를 통해 다양한 케이스를 접하고 이를 해결하는 과정에서 많은 것을 배웠습니다. 그 과정에서 겪은 문제들을 해결해 나가며 지금도 계속해서 배우고 성장하고 있다는 생각이 듭니다. 이렇게 프로젝트를 마칠 수 있어 정말 뿌듯함과앞으로의 마음가짐을 이 글을 통해 정리하며 마무리하고자 합니다.
이번 프로젝트를 진행하면서 저는 느낀 점이 한 가지 있습니다.
바로 ‘개발자에게는 여러 선택의 순간들이 있다’는 사실 입니다. 여러 선택이 있는 순간들 중에서 단순히 눈앞의 문제를 해결하는 데 급급하기보다는, ‘왜 이 방법을 선택해야 하는가?’ 또는 ‘이게 최선의 방법일까?’에 대해 깊게 고민하는 것이 중요하다는 점 입니다.
이러한 마음가짐이 앞으로 더 나은 개발자로 성장하는 데 도움이 될 거라 생각합니다.
이 글을 마무리하면서, 앞으로도 매 순간을 깊이 생각하며 고민하고 최선의 선택을 할 수 있도록 노력하는 마음가짐을 KCD에서 계속해서 유지해 나가고 싶습니다.
PS. 회사에 잘 적응할 수 있도록 도움 주신 저희 회사 분들과 팀원분들에게..!! 무한히 감사합니다.
지금, KCD는 사장님의 더 나은 내일을 위해 함께할 동료를 찾고 있어요.
✨영입 중인 포지션 확인하기
✨KCD가 더 궁금하다면?