1. 본인이 끝까지 파고들어 본 가장 의미있었던 개발 경험 또는 개발 활동에 대해 얘기해 주세요. 그 개발 경험 또는 개발 활동을 통해 배운 점이 무엇인지, 본인의 어떤 부분이 성장했는지에 대해 작성해 주세요. (반드시 지원한 포지션과 관련된 경험이 아니어도 좋습니다.)
[끊임없는 배움과 다양한 이해를 위해]
기존 프로젝트의 백엔드를 완성한 후, 운영을 위해 새로운 인원들과 기존 프로젝트의 내용을 다시 파악했습니다.
이 때에 기존 제가 공부했던 방식과는 많이 다른 방식을 배우게 되었습니다.
- 연관관계의 제거
기존의 프로젝트는 여러 데이터들이 연결될 때에 FK로 연결하였고 이들을 DB에 매번 연결하여 가져왔습니다.
그리고 변경된 내용에서는 FK를 제거하게 되었습니다.
그 이유는 총 두 가지가 제안되었는데,
1. FK자체가 갖는 성능 저하 이슈
2. 설계 변경에 따라 데이터의 유지보수 간략화
이었습니다.
그동안 연관관계를 설정하여 데이터 간의 정합성을 맞추는 것이 매우 중요한 것으로 알고 있었기 때문에 위와 같은 내용을 확인하였을 때에 제안된 내용을 신뢰하지 못했습니다.
또한, 이외에도 FK의 오버헤드가 성능 저하를 유발한다고 하지만 JPA상에서 데이터를 호출할 때에 외래키와 조건을 동시에 사용하면 더 오히려 빠르게 데이터를 가져올 수 있으니 이 방식이 옳다고 생각하여, 이 연관관계 제거를 반박하기 위해 다양한 레퍼런스를 참고하여 공부해 보았습니다.
- 캐싱 서버와 정합성 검증 로직
그리고 여러 글이나 기존 서비스를 참고하여 확인해 보았는데, 다양한 서비스에서 FK를 실제로 쓰지 않는다는 이야기를 듣고 놀랐습니다.
여기에는 Redis와 같은 NoSql을 통한 캐싱이 큰 도움을 주었다고 하는데, 미리 데이터를 저장해 놓고 정합성을 잘 검증하기만 하면 매번 DB와의 통신을 하지 않고도 쌓여 있는 데이터에서 필요한 것을 뽑아 사용할 수 있다고 했습니다.
즉 미리 모든 데이터를 캐싱시켜 두고, 이 데이터들을 상황에 맞추어 쓰기만 하면 되기 때문에 자체적으로도 오버헤드도 있고 최근 IT의 발전에 따라 다양한 DB상의 변화가 이루어 지는데, 이로 인한 데이터의 변경이 생겼을 때에 여러 부분에서 적용이 힘든 FK를 제거할 수 있다는 내용이었습니다.
그동안 알고 있던 내용 외에 다양한 이유로 새로운 페러다임이 제시되었다는 것이 신기했고, 또 재미있는 내용이었어서 이에 관한 공부를 추가로 진행해 보았습니다.
- 실제로 적용하고, 확인해 보며
이 때에 배운 FK제거와 Redis사용을 통한 DB부하 제거는 현재 스터디 중에 있습니다.
그리고 저희의 상황에 맞추어 내용을 조금씩 변경하고 이에 따른 Trade-off를 살펴 보는 중입니다.
예를 들어 캐싱 서버를 따로 두는 것은 예산에서 처리하기 힘들 것이라 생각하여 Spring boot 서버에서 Redis를 붙이거나 FK는 ERD상에서는 적용하고 실제로는 제거하는 등의 부분입니다.
현재는 개발 참여 인원들이 해당 내용에 대해 잘 알지 못하는 상황이라 이전에 내용을 공부한 제가 스터디를 진행하고 있고, 매 주 공부한 내용을 서로 발표하고 토론하고 있습니다.
이를 통해 기존에 제대로 알고 있다고 생각한 것도 금방 바뀔 수 있다는 것을 알았고, 지금보다 더 열심히 공부하고 새로운 것을 익히고 싶다는 생각을 갖게 되었습니다.
----
2. 지원하신 포지션과 연관지어, 학교 수업 또는 대외활동 등을 통해 습득한 CS 지식이나 기술적 역량에 대해 설명해 주세요. (최대 3개 / 1,000자 이내)
- 확인, 그리고 적용
다양한 공부를 통해 개발자로서의 기초를 다진 후, 제가 배운 것들을 확인해 보는 동시에 여러 문제를 경험하며 이를 해결해 보기 위해 개인 프로젝트를 진행하였습니다.
Spring boot환경에서 Spring data JPA와 H2 Database, spring security, 그리고 이를 보여주는 프론트 뷰를 구현하여 보았고, AWS상에서 구동시켜 확인해 보았습니다.
개발의 시작부터 끝까지 혼자 진행해 보면서 다양한 문제를 실제로 접할 수 있었고, 이전에 배웠던 내용을 실제로 적용하거나 새로운 기술들 시도해 보면서 조금 더 개발에의 흥미를 가질 수 있었습니다.
또한 단순히 기능의 구현에 초점을 맞추어 개발하는 것 보다는, 최선의 퍼포먼스와 깔끔한 코드 작성을 위해 계속해서 노력해야 한다는 사실을 알 수 있었습니다.
- 발전을 위하여
이전까지 개발자로서의 지식의 확장과 다양한 경험을 쌓아 올리는 데에 집중하였다면, 이후로는 깊이를 더해나가는 공부를 하고 있습니다.
JPA, Spring Data JPA에서의 N+1방지 방법과 영속성 컨텍스의 Dirty checking을 사용한 update 사용 이유, OSVI를 사용한 최적화, 실무에서의 lazy fetch와 fetch join 관련 주의사항 등 기초적이지만 중요한 개념들을 정리하고, 이를 통해 기존 프로젝트를 리팩터링 중에 있습니다.
그리고 제가 가진 지식들이 맞는지 확인하고 더 많은 사람과 협업하여 발전할 수 있는 개발자가 되기 위해 디자이너, FE개발자, BE개발자들과 함께 공통의 목표를 이루어 보았습니다.
현재는 고안한 아이디어를 토대로 새로운 프로젝트를 Spring Boot 기반 백엔드를 통해 진행 중에 있습니다.
해당 프로젝트는 더욱 많은 것을 배우기 위해 Redis를 사용한 캐싱 처리, FK를 사용하지 않는 개발과 그 이유에 관한 공부를 함께 진행 중에 있습니다.
---
3. 본인의 SW개발 활동 경험 중 다른 사람과 함께 같은 목표를 위해 노력한 경험 또는 어려운 기술적 문제를 해결한 경험에 대해 얘기해 주세요.
(활동 기간, 주요 내용, 문제 접근 방식, 극복해가는 과정, 사용 언어와 기술 설명 등 타인과 협업하고 문제를 해결하는 과정 속 본인이 주도적으로 참여한 부분을 중심으로 작성해 주세요. 결과나 성과 등 참고 가능한 URL이 있다면 본문에 포함해 주셔도 좋습니다.)
백엔드를 넘어 개발자가 되기 위해
2022년 초에 동아리에 들어가며 백엔드 개발자로서 최대한의 배움을 얻기 위해 다양한 노력을 했습니다.
회사를 재직하며 사내에서 진행하던 프로젝트 외에도, 출퇴근 시간을 이용하여 알고리즘 문제를 풀었으며 추가로 동아리에서의 개발을 위해 API개발과 고도화 등을 공부했습니다.
주말에는 토요일 14시부터 17시까지 동아리 정규 미팅을 진행했고, 일요일에는 추가적인 스터디를 진행하였습니다.
이러한 스케쥴을 계획했던 이유는 이전에 배웠던 내용들을 실제로 적용하는 것 외에도 더 많은 것을 배우고 싶었고, 더욱 뛰어난 개발자가 되고 싶었기 때문입니다.
다만 일주일 내내 다양한 스터디를 진행하면서 주변 친구들이나 가족들과 보낼 시간이 줄어들게 된다는 단점이 있었습니다.
또한 API의 운영과 유지보수를 짧은 시간동안 빠르게 적용해야 했기에, 평소에 잠을 줄이며 개발에 몰두하였습니다.
이 때문에 많은 것을 배울 수 있다는 장점이 있었지만, 개인의 삶에서는 힘든 것들이 많았습니다.
다행이도 동아리를 하면서 친해진 분들과 이야기를 나누며 계속해서 공부에의 원동력을 유지할 수 있었고, 끈기를 갖고 모든 목표를 달성할 수 있게끔 노력했습니다.
그 덕분에 저희가 진행했프로젝트는 실제 어플리케이션을 출시했으며, 해당 내용을 통해 공부한 것을 바탕으로 백엔드 개발에의 지식을 함양할 수 있었습니다.
이전까지는 하루의 남는 시간을 공부에 사용하였다면, 올해의 상반기의 삶은 모든 삶을 최대한으로 쏟아부었다고 스스로 생각할 수 있을 정도로 공부에 몰두하였고, 덕분에 마음먹었던 것을 이루고 할 수 있다는 자신을 갖게 되었습니다.
동아리에서 겪은 문제점과 해결 방식, 그리고 관련 내용들은 회고와 정리로 남겨두었습니다.
