미리보기

기술 스택

기술 스택

Java

Spring Boot

Spring Security

MySQL

querydsl

JPA

Redis

AWS

Docker

nginx

프로젝트

포트폴리오

교육

대외활동

자격증

외국어

자기소개

자기소개

“개발자"의 정의를 고민하며 성장

저에게는 “사람들의 일상에 스며든 서비스” 를 개발하는 궁극적인 목표가 있습니다. 이 목표를 달성하기 위해 대규모 트래픽을 감당할 수 있는 아키텍처를 설계하고, 서비스의 핵심 로직을 직접 작성할 수 있는 개발자가 돼야겠다고 생각했습니다. 그중에서도 정말 깊이 있는 백엔드 개발자가 가져야 하는 역량이 무엇인지 고민하였습니다. 처음에는 코딩, 구현 능력이 좋기만 하면 개발자로서 필요한 자세를 모두 갖춘 것으로 생각했습니다. 하지만 대외활동과 팀 프로젝트를 진행하면서 개발자에 대한 근본적인 시각을 바꾸게 되었습니다. 개발자는 탄탄한 기본기를 바탕으로 다양한 문제 해결 능력을 갖추고, 끊임없이 새로운 기술들을 자신의 것으로 만들어야 한다고 생각합니다. 언제든지 새로운 문제들이 발생하며 개발자는 이를 제대로 파악하고 대처해야 하기 때문입니다. 또한, 컴퓨터는 여러 기술, 분야들이 유기적으로 이루어져 있기 때문에 기본기를 확실히 다져야 한다고 생각하게 되었습니다.

운영체제, 컴퓨터 네트워크 등 전공 서적을 다시 읽어가면서 동작 과정과 원리에 대해 외우는 것이 아닌 이해를 목표로 꼼꼼히 학습했습니다. 그동안 당연하게 사용했던 컴퓨터가 어떻게 실행되고 있는지, 그런 컴퓨터에서 제가 작성했던 코드들이 어떻게 메인 메모리에 올라가서 CPU에 의해 계산되는지 등 지식을 다시 정리했습니다.  그 결과 다양한 CS부터 현재 실행하고 있는 Spring Boot까지 수많은 지식들이 연결되어 있는 것을 직접 느끼기 시작했습니다. 이후 새로운 것을 배울때는 왜, 어떻게를 생각하며 기존 지식과의 연결점을 찾으면서 학습하고 있습니다.

---

Yes, No가 아닌 다양한 방법, trade-off를 이해하며 학습

백엔드 데브코스 교육과정에 입과 후 초기, 기술에 대한 궁금증 대해서는 무조건 “이렇게 하면 안 된다, 이렇게 해야 한다”와 같은 정답을 추구 했습니다. 즉, 모든 것에는 명확한 정답이 있는 것인 줄 알았습니다. 이는 저뿐만 아니라 주위 예비 개발자들도 흔히 오해하고 있다는 것을 깨달았습니다. 예를 들어, “객체를 생성할 때는 빌더를 써야 한다는 것”이 있었습니다. 이런 말을 처음 들었을 때는 무조건 따라야 한다고 생각했었지만, 실제로 개발하면서 오히려 불편함을 느끼며 다시 생각하게 되는 계기가 되었습니다. 

생성자에 매개변수가 많다면 빌더를 사용하는 것이 편할 수는 있지만, 오히려 필요한 매개변수를 빼먹을 수 있다는 것, Mapper를 만들어줘야 하는 번거로움, 테스트 코드 작성 시 더 불편을 느꼈습니다. 하지만 빌더에 넘기는 매개변수에 따라 다른 객체를 만드는 등 상당한 유연함이 있다는 장점도 느꼈습니다. 이를 통해 어떤 기술 또는 방법을 선택하는 것에는 명확한 정답이 있는 것이 아닌, 항상 trade-off가 뒤따르며 현재 상황에 가장 알맞게 선택하는 것이 중요하다는 것을 배웠습니다. 그 결과, 3개 이하의 매개변수가 필요한 생성자는 빌더를 적용하지 않기로 합의했습니다.

---

협업과 커뮤니케이션을 중시

"프로그래머스 백엔드 데브코스 4기"에서 최종 팀 프로젝트를 진행한 경험이 있습니다. 초기에 저를 포함한 팀원 전체가 코어 타임 도중에 실시간으로 궁금한 것을 서로 의논하였습니다. 하지만 너무 오랫동안 결론이 나지 않게 되어 몇 시간이 지나는 상황이 빈번하게 발생했습니다. 이로 인해 개개인이 개발에 집중하기 어렵게 되면서 프로젝트에 영향 끼치는 것을 느끼게 되었습니다.

저는 팀원들이 서로 불편함을 주지 않으면서 효율적으로 개발을 진행할 수 있도록 기존과 다른 새로운 협업 방식에 대해 고민하게 되었습니다. 최근 몇 년간 재택, 원격 근무가 대중화면서 비동기 커뮤니케이션이 자주 사용되는 것을 알게 되었습니다. 비동기 커뮤니케이션이 현재 팀에서 발생하고 있는 어려움을 해결해 줄 수 있다고 생각하여 정확한 방법과 적용 사례를 조사하고, 이 방식에 경험이 있는 멘토를 찾아 조언을 구했습니다.

회의를 통해 제가 당시에 느꼈던 협업 방식의 문제점을 설명했습니다. 문제를 해결하기 위해 개인 간 비동기 커뮤니케이션을 바탕으로 소통하고, 함께 의논할 사항은 코어 타임 시작 또는 끝나기 전 스크럼 때 정해진 시간 동안만 함께 의논하기를 제안했습니다. 팀원들 또한 문제에 대해 동일한 생각을 하고 있으므로 제안을 흔쾌히 수용하였습니다.

일주일 동안 적응기를 거치며, 모든 팀원이 새로운 방식에 불편함이 없는지 확인이 된 후 프로젝트가 끝날 때까지 유지되었습니다. 효율적인 의사소통을 통해 프로젝트의 완성도를 높일 수 있었고, 마침내 제가 속한 팀이 해당 프로젝트로 개발 우수상을 수여하게 되었습니다.

이런 경험을 통해 개발자의 개발 역량이 아무리 뛰어나도, 팀원들과의 소통과 협업이 제대로 이루어지지 않으면 프로젝트나 기업에는 악영향을 끼칠 수 있다는 것을 느꼈습니다. 저는 이러한 이유로 팀원들과의 효율적이고 적극적인 커뮤니케이션을 유지할 수 있도록 신경쓰고 있습니다.