30대에 개발자를 시작한, 비전공자 2년차 개발자의 2024 연말 회고
안녕하세요.
저는 정확히 서른 두살에 개발자를 시작했고, 현재 2년차 백엔드 개발자로 회사를 다니고 있는 김설영이라고 합니다.
저의 이야기가, 저와 같은 상황에 처한 분들께 조금이나마 도움이 되기를 바라는 마음에 간만에 블로그에 오랜만에 글을 작성하게 되었는데요! 이 목적을 달성하기 위해서, 제목을 어떻게 작성해야 내 이야기가 도움이 될만한 분들이 나의 글을 찾을 수 있을까 정말 많은 고민이 들더라구요.
그러다 문득, 3년전 개발자를 준비하던 저의 마음은 어땠는지, 어떤 글들에서 도움을 얻었는지 생각 해보게 되었습니다.
3년 전의 저는 "30대에 개발자 시작이면 너무 늦은거 아닐까?", "널린게 전공잔데 나같은 비전공자, 게다가 나이도 적지 않은데 과연 뽑아는 줄까?"라는 고민들을 했었고, 그 고민에 대한 답을 외부에서라도 찾아보기 위해 "30대 비전공자 신입 개발자"라는 키워드로 정말 많은 글들을 검색했던 기억이 있습니다. 그래서, 저는 "나와 같은 비슷한 상황에 처한 분들은 저와 비슷한 키워드로 검색하지 않을까?" 라고 생각했고, 제목에 "30대", "비전공자" 키워드를 넣어 보았습니다.
글을 잘 작성하는 편이 아니라서, 경험이 잘 전달될지는 모르겠지만, 누군가에게는 동기부여가 되길 바라며 글을 시작해 보겠습니다. 😄
* 제가 어떻게 개발자가 되었는지 상세한 내용은 https://kimsy8979.tistory.com/37 을 참고해 주세요!
첫 회사에서 1년 7개월 동안 신입 개발자로써 배운 것들
좋은 기술이라고 해서 모든 상황에 좋은 것은 아니다
저는 입사 당시, 제가 배운 지식들과 제가 작성하는 코드들이 전부 옳다고 믿는 바보였습니다. 오픈 채팅방에서 오고가는 베스트 케이스들만이 정답인 줄 알았고, 유행하는 기술을 쓰지 않으면 전부 "안좋은 것, 뒤쳐진 것"이라고 치부해버리고는 했었죠.
일례로, "DB에 오는 부하를 줄여달라"라는 요청에 저희 팀이 캐시로 레디스를 도입하려고 시도했던 적이 있는데요. 그 때, 팀장님께서 "관리 포인트"와 이로 인한 "유지보수 비용 문제"를 언급하며 거절하셨습니다. 저는 그 때, "아, 비용 문제도 고려를 해야 하는구나"를 깨달았고, 좋은 기술이라고 해서 모든 상황에 좋은 것은 아니라는 점을 깨달았습니다.
저는 이 때 이후로, 기술을 도입하기 전에 다음의 요소들을 고려해 보려고 노력을 하고 있습니다.
- 반드시 그 기술이어야만 하는 이유가 있는지
- 팀원들의 러닝 커브가 함께 고려되었는지
- 유지보수 비용은 생각해 보았는지
- 회사의 상황도 고려가 되었는지 (비용문제 등)
* 여담으로, 처음에는 도입을 거절당했던 레디스가 시간이 지나면서 정말 필요해질 때가 왔는데 그 때 다시 필요한 이유를 말씀드려보고 도입을 성공하게 되었습니다. 😄
시도해보고 실패하면서 배우고 깨닫는 것이 가장 중요하다. 되는지, 적합한지는 해봐야 안다.
저는 어떠한 제안이 왔을 때, "어 이거 어디서 이렇게 하면 안된대요"라는 말을 많이 했던 것 같습니다. 사실은 시도해보기 귀찮아서도 있었던 것 같고, 안된다고 보았는데 굳이 해봐야되나? 라는 생각이 강하게 있었던 것 같습니다. 하지만, 같은 팀의 선임님께서는 이것 저것 모두 시도 해보시는 타입이셨습니다.
그러던 어느날, 제가 또 "이러이러 해서 안된다"라고 말씀드렸던 것을 선임님 께서는 시도를 해보셨습니다. 안된다고 말씀드렸던 것은 아주 잘 되었고, 이는 저희의 문제 해결 방법에 들어 맞는 것이었습니다. 저는 "아 모든 것은 해봐야 아는구나"를 깨달았고, 그 때 이후로 뭐든지 해보려는 습관을 들이기 시작했습니다.
뭐든지 시도를 해보니까 아래와 같은 생각들이 자리잡기 시작했습니다.
- "된다/안된다"와 "장/단점"을 논하기 전에, 시도 해보고 실패하면서 배우고 깨닫자
- 시도를 해보아야만 비로소 그 선택의 장/단점을 알 수 있고, 되는지 안되는지를 알 수 있다
- 하다보면 불편한 부분들이 보이고, 여러 개선점들이 자동으로 보이게 된다
- 이래서 유지보수성이 중요하구나, 이래서 작은 프로젝트에는 헥사고날을 쓰지 말라고 했구나, 이래서 infra와 domain은 분리하라고 했구나.. 등을 깨닫게 됩니다
JPA Entity는 도메인을 대표하는 객체가 되지 못할 수도 있다. (feat. 레거시 테이블)
저는 신입 시절(비록 얼마 전이지만), JPA Entity가 곧 도메인이며, JPA Entity에 적절한 연관관계를 맺어 애그리거트 루트를 만들면 그게 DDD다. 나는 DDD를 해봤다!..... 라는 이상한 망상에 절여져 있었습니다.
정말 테이블 모델링을 잘 했다면, JPA Entity가 도메인 객체로써 바로 사용될 수도 있다고 생각합니다. 하지만, 그렇지 못한 테이블의 경우, JPA Entity를 바로 도메인 객체로 사용하게 된다면 대 참사가 벌어지게 됩니다
저희 회사의 경우에는 레거시 테이블이 처음에는 하나의 개념을 표현 하다가, 필요한 컬럼들이 하나씩 추가되면서 다수의 개념을 표현하게 된 케이스입니다.
예를 들어서, 처음에는 "도서 보관함"이라는 개념을 표현하는 테이블이었는데, 여기에 "도서를 읽은 날짜"를 추가하고, "도서를 구매한 날짜", "도서를 구매한 금액"을 추가하게 되며, 결국에는 수많은 다양한 컬럼들을 보유하게 됐고, 이 테이블이 대체 "보관함" 개념인지, "도서를 읽은 내역" 개념인지, "결제내역" 개념인지 알 수가 없게 되었습니다.
그래서 보관함이라는 이름의 JPA Entity는, 도서를 보관하는 역할도 하고, 도서를 읽었는지 여부를 체크하는 역할도 하고, 결제 내역을 뽑아오는 역할도 하게 되는 등 다양한 메서드가 자리잡게 됐고, 이는 유지보수하기 힘든 형태의 코드가 되어버리는 결과를 낳았습니다.
- 위 요소들 뿐만 아니라, 해당 엔티티는 더 다양한 역할을 하고 있고, 이는 한 엔티티의 변경 요인이 여러가지가 되어, 유지보수 하기가 고통스럽다는 결과를 낳아버리게 되었습니다 😓
저는 레거시 테이블이, 탄생하던 시점에는 해당 도메인을 잘 대표할 수 있는 상태라고 생각하지만, 시간이 흐르면서 비즈니스가 변하고, 이에 따른 도메인 개념도 바뀌게 되면서, 자연스럽게 레거시 테이블 자체가 도메인을 대표하지 못하는 상태가 될 수 있다고 생각하게 되었습니다. 테이블을 비즈니스 변화에 따라 자유롭게 변경할 수 있다면 별 문제가 되지 않을 수 있지만, 보통 운영환경의 데이터는 많기 때문에 테이블을 변경하는 것 자체가 매우 큰 위험요소가 될 수 있어 상당히 제한적이라고 생각합니다. 따라서, 저는 테이블을 매핑한 객체와 도메인 객체는 DIP 원리를 이용해서 최대한 격리해야 한다고 생각하게 되었습니다.
제 방법이 모든 상황에 옳다는 것은 아닙니다. 그냥 JPA Entity 자체를 도메인 객체로 단순히 사용하지 못할 수도 있다는 것과, DDD 라는 하나의 방법론을 JPA Entity라는 기술에 한정지어 생각하던 저의 과거의 생각을 깨부수게 된 계기가 되었다는 것을 설명드려 보고 싶었습니다. 😄
아무리 좋은 변화라 할지라도, 변화 자체를 싫어하는 사람도 있다
저는 발전과 개선을 위해서는 변화가 동반되어야 하는 법이라고 생각합니다. 하지만, 이를 모든 팀원에게 강요할 수는 없습니다. 아무리 좋은 변화라고 할지라도, 그게 달갑지 않은, 현상 유지만 하려는 사람들이 있습니다. 저는 처음에는 답답했습니다. "아 좋은 방향인데 왜 다들 안하려고 하지?"라는 생각이 가득했고, 수많은 설득을 해보기도 했습니다.
저는 좋은 방향이라고 해서, 정말로 모두에게 좋은게 맞는가? 현상 유지만 하려는 것이 나쁜 것인가? 를 생각 해보게 되었습니다. 결국 내린 결론은, 사람마다 "가치"는 모두 다르다는 것입니다. 제가 좋다고 생각하는 방향을 끝까지 강요할 수는 없다는 것을 깨닫게 되었습니다.
이직 준비
저는 개발자를 시작할 때 부터 금융 도메인을 경험 해보고 싶다는 목표가 있었습니다. 하지만, 이를 달성하기 위해 지금의 회사에서, 그리고 내가 개인적으로 무엇을 해야할지 정리가 되지 않았습니다.
우리 회사에서 어떻게 커리어를 쌓아나갈 수 있을까를 수없이 고민했으나, 혼자서는 방향성을 정할 수가 없다고 판단해서 멘토링의 도움을 받아보기로 결정했습니다. 처음에는 인프런 멘토링과, F-lab 멘토링 중에서 고민을 했고 좀 더 중장기적인 방향성 설계가 필요하다고 생각해서 정말 비쌌지만 F-lab을 들어보기로 결정을 했습니다. (무이자 할부 만세 😇 아직도 갚는 중입니다. 너무 비싸서 함부로 추천 못하겠어요 ㅠㅠ)
F-lab 경험담
저는 결론적으로 멘토님께 크게 아래와 같은 것들을 배웠습니다.
- 개발자로써의 태도
- 엔지니어 적인 생각 방식
- 기술 면접을 볼 때, 포기하지 않고 끝까지 대답하기
- 공부 방법
- 공부에 효율은 없다. 1시간 공부를 하면 1시간 공부한 사람이 되는 것. 공부를 효율적으로 하려고 할 필요가 없다. 효율적으로, 영상 1.5배로 보고, 더 빨리 책을 읽고 단위 시간 내 많이 한다고 해서 다 머리에 들어 있는가? 등 많은 조언을 해주셨습니다.
- 지치지 않고 꾸준히 달려가는 방법을 찾기 (feat. 잘 쉬는 법)
- + 멋진 개발자 인맥( get멘토님() )
저는 위 다섯개만으로 아깝지 않은 멘토링이 되었다고 생각하며, 특히 지치지 않고 꾸준히 달려갈 방법을 찾아야된다는 부분을 알려주신 멘토님께 너무 감사하다는 생각이 들었습니다.
저는 늦게 시작한 만큼 더 열심히 해야한다고 생각하여, 저의 정신과 몸을 다 갈아넣으면서 공부를 했습니다. (평일 3시간, 주말 6시간 이상) 저는 쉬는 방법을 몰라 쉬지를 않았습니다. 하지만 멘토님의 걱정어린 조언으로 인해 억지로라도 쉬기 시작했고, 이제는 힘들 때는 좀 쉴줄 아는 개발자가 되었습니다.
늦었다고 생각해서 조급할 필요가 없었던 것 같습니다.
조급해질 때마다 저는 멘토님의 말씀을 되새기거나, 아래의 한기용님 영상을 챙겨보고는 합니다.
https://youtu.be/nLL409se8sM?si=1IjkOVRuDdQ-HmSO
https://youtu.be/FPdWTYxcdeM?si=vkddG1KQPOnPyiBc
우아한 유스방 5기
저는 유쾌한 스프링방 이라는 오픈 카톡방에서 "우아한 유스방"의 존재를 알게되어 모집 기간에 신청을 하게 되었습니다. 우아한 유스방은 퍼스널 브랜딩, 회사 분석 역량, 페어 프로그래밍, 코드 리뷰, 이력서 작성, 모의 면접 등을 통해 좀 더 나은 개발환경으로 갈 수 있도록 도와주고 제이슨님과 같이 좋은 소프트웨어 생태계를 만들어 가는 데에 공헌하는 것이 주 목적입니다.(https://velog.io/@beomdrive/woowahan-youth-start <- 우아한 유스방 4기 알렉스님의 글에서 차용했습니다!)
이곳에서 정말 많은 것을 해볼 수 있었고, 여기서 받은 도움들을 기반으로 카카오뱅크로의 이직까지 성공할 수 있었습니다. 🥳
- 우아한 유스방에서 했던 것들...
- 이력서 작성을 위한 미션 수행 및 기업 조사
- https://kimsy8979.notion.site/a6595a2b89cb4dc6a8c3fb750cd012cc?pvs=4
- 이력서 작성의 기반이 될 핵심 질문들을 대답 해가며 제가 어떤 사람인지에 대해 집중할 수 있었습니다. 또한, 기업을 조사하면서 제가 어떤 도메인에서 일하고 싶은지를 깨달을 수 있었습니다.
- 페어 프로그래밍 과제 수행
- https://github.com/woowahan-pjs/java-wordle/pull/35
- 다른 사람과 협업하며 하나의 프로젝트를 만들어 나가는 과정이 인상깊었습니다. 서로 다른 의견을 취합하여 좋은 방향으로 나갈 수 있는 방법에 대한 토론을 많이 할 수 있는 경험이었습니다.
- 간단한 쇼핑몰 API 구현 과제 수행
- https://github.com/woowahan-pjs/spring-shopping/pull/2
- 수행한 과제를 기반으로 모의 면접을 진행했습니다. 구현한 내용에 대한 질문들을 받으며 제가 몰랐던 내용들을 깨닫게 될 수 있었습니다.
- 페어 프로그래밍 과제 수행
- 이력서 작성을 위한 미션 수행 및 기업 조사
- 유쾌한 스프링방 : https://open.kakao.com/o/gPjtvkfe
- 신청 방법: 유쾌한 스프링방에서 존버(?)를 하다보면, 제이슨님이 우아한 유스방 신규 기수 모집 안내글을 올려주시는데, 그 때 신청을 하면 됩니다.
카카오뱅크로의 이직 썰
카카오뱅크에 가기까지의 여정이 어땠는지 간략히 소개드려 보겠습니다.
과제
기술과제가 주어집니다. 저는 정말 어려웠습니다. 한번도 구현해본 적 없는 것을 구현해야 해서, 많은 시행착오가 있었습니다. 저는 가장 단순한 방법으로 구현하자고 생각했고, 카뱅은 친절하게도 "어떤 부분에 중점을 두고 볼 것인지"를 힌트로 주어 "가독성"에 초점을 맞춰서 구현을 하였습니다. 구현은 제가 부족한 만큼 시간을 더 투자하자고 생각했고, 제출 당일에 연차를 내가면서까지 제출을 마무리했던 기억이 있습니다.
1차 실무진 면접
면접 준비 내용은 https://kimsy8979.notion.site/a505bda620bf49beb4d5cacb29459b84?pvs=4 에 정리 해두었습니다. (정리되지 않아 있는 점은 양해 부탁드립니다..ㅎㅎ)
면접장에 들어서자 마자 면접관 분들께서 친절하게 맞이해 주셨고, 정말 편안한 분위기에서 진행되었고, 가장 먼저 자기소개를 했습니다.
문득, 자기소개를 절면 안된다는 말이 머릿속에 떠올라 정신줄을 부여잡고, 절지 않기 위해 천천히 말을 이어 갔습니다. 덕분에 절지 않게 되었고, 절지 않으니 정말로 이후의 면접을 전부 망치지는 않게 되었습니다.(꿀팁입니다! 제이슨짱)
자기소개에서, 제 특이한 이력에 관심을 가져 주셨고, 간단히 제가 왜 개발자가 되었는지에 대해 설명드리게 되었습니다. 그리고 나서 곧 과제에 대한 코드 리뷰를 시작했는데, 자세한 내용을 공유할 수는 없지만 너무 코드 외에서만 문제를 해결하려 했던 저를 반성하게 되는 계기였습니다.
저는 현재 코드 내에서 해결 가능한 방법들을 살피지 않았고, 그에 대해 깊게 고민해보지 못한 저는 제대로 답변하지 못했습니다. 그리고, 은행이라는 특성을 고려하지 못했던 부분이 있었습니다. 저는 성능이 좋으면 최고! 라는 고정관념이 있었습니다. 하지만, 은행에서는 안전을 위해 어느정도의 성능 하락은 감수한다고 하셨습니다. 이런 트레이드 오프도 해야하는구나..를 깨달았고, 또 한번 인사이트가 넓어지는 느낌을 받았습니다.
과제 리뷰가 끝난 후로는, 이력 기반의 면접을 진행했습니다. 가장 최근 이력 기반으로 설명을 부탁하셨고, 이에 대한 질의 응답이 오고 갔습니다.
마지막으로, 저는 아래의 질문을 드렸습니다.
- 이번에 어떤 개발자를 채용하고 싶으신가요?
- 제가 팀에 가게되면 어떤 업무와 역할을 부여받게 될까요?
- 전체 목표는 MSA로의 전환인 것 같은데, 팀의 최우선 목표는 무엇일까요?
면접 후기는 https://kimsy8979.notion.site/1b8faf21db3f4996a68e2d8d8debab76?pvs=4 에 정리하였습니다.
2차 경영진 면접
회사 조사 내용은 https://kimsy8979.notion.site/4fa2f05c65524aff9716349498e031e6?pvs=4 에 정리하였습니다.
면접 준비는 https://kimsy8979.notion.site/25c9e6927a7047628b13a2f9c0b43699?pvs=4 에 정리하였습니다.
2차 경영진 면접은 컬처핏 위주의 질문들과, 기본적인 기술에 대한 질문들, 그리고 이력에 대한 질문들이 오고갔습니다. 비대면으로 진행이 되었고, 위에 정리된 내용들을 답변을 드렸습니다! (많이들 아시는 내용이라 자세한 내용은 생략하였습니다!)
감사하게도, 면접에 합격하여 카카오뱅크에 최종 합격하게 되어 10월부터 다니고 있습니다. 😁
이직 한달차에 배운 점들
저는 이전 회사에서 Stored Procedure를 Java Spring 으로 옮기는 작업을 하거나, 새로 개발하는 건들밖에 다뤄보질 못했는데, 여기에 와서는 많은 레거시 코드들을 다루고 있습니다. 레거시 코드를 보며, 왜 이렇게 유지보수성이 강조가 되었는지를 깨닫고 있는 중입니다. 레거시 코드를 대하는 자세와 주의해야 할 점, 그리고 반드시 다음 사람을 위해 코드를 알아보기 쉽게 짜야하는 이유 들을 깨닫고 있습니다.
사고친 썰을 하나 풀자면... 오래된 레거시 코드들은 잘 돌아가지만, 변경에 정말 취약한 구조로 되어있는 경우가 많습니다. 저는 이를 알지못하고, 문제가 있는 코드에서 단순히 이것만 바꾸면 되겠는데? 라고 생각 해서 바꾸고, 테스트를 돌려 잘 되는것을 확인했지만, 운영에 나가보니 안됐던 경험을 했습니다. 테스트 코드도 정말 잘 짜야됨을 깨달았고, 일부 사람들이 "실무와 비슷한 환경으로 할 수 있는 테스트 구성 연구"를 하는지를 알게 되었습니다. 이에 대한 내용은 다음에 기회가 되면 자세히 풀어보겠습니다. 😂
현재는...
일단 저는 "맡은 업무부터 잘 하자, 신뢰 자본을 잘 쌓자, 도메인 파악을 해보자"라는 자세로 업무에 임하고 있습니다. 도메인이 많이 복잡해서 이를 파악하고 개발하느라 오랜 시간이 걸리고 있지만, 내년에는 일하기 편한 동료, 1.5인분 이상을 할 수 있는 동료가 되고 싶다는 생각을 하고 있습니다.
저의 개발자로써의 삶은 아직 2년이 되지 않아 여기까지 입니다. 😅
제가 마지막으로 드리고 싶은 말은, "늦은 것이란 없다"라는 것입니다. 늦었다고 생각하면 할 수록, 자꾸 거기에 갇혀서 부정적으로 생각하게 되는 것 같습니다. "이 일이 정말 하고싶은지, 하고싶다면 왜 하고싶은지"를 먼저 생각해보는게 좋다고 생각합니다. 생각해본 결과 정말로 개발자가 하고싶다면, 꼭 도전해 보셨으면 좋겠습니다.
짧은 저의 개발인생이, 누군가에겐 큰 동기부여가 되기를 바라며, 글 마치겠습니다.
긴 글 읽어주셔서 감사합니다.