프로젝트를 통해 배운 내용
0~100
처음에는 단순히 서버와 데이터베이스를 관리하는 백엔드 개발자의 역할에 대해 이론적으로만 이해하고 있었다. 하지만 프로젝트를 통해 실제로 제품을 완성하기까지의 과정을 직접 경험해보며, 백엔드 개발자의 역할이 훨씬 넓고 다양하다는 것을 느낄 수 있었다. 요구 사항 기획, 분석, 설계, 개발, 테스트, 배포, 유지 보수 등의 전체적인 개발 사이클을 경험하면서 0 to 100로 웹 페이지를 만들어 보며 백엔드 개발자가 하게 될 업무에 대해서 전반적으로 경험 할 수 있는 경험이 되었다.
위 경혐을 통해 서로 얽혀있는 문제들에 대한 시야가 넓어지는 느낌을 받을 수 있었다. 취업을 하게 되면 신입개발자로써 맡게 될 부분은 한정적이겠지만 내가 맡게 될 업무가 다른부분에 어떤 영향을 미칠 수 있는지 알 수 있게 된 것 같다.
협업
프로젝트를 진행하면서 협업의 중요성을 깨닫게 되었다. 코드 리뷰를 통해 팀원의 코드를 검토하고 피드백을 주는 과정에서, 개인적으로는 놓칠 수 있는 부분을 발견하거나 더 좋은 해결책을 제시하는 등 팀 전체의 코드 품질을 향상시키는 데 큰 도움이 되었다.
또한, 프론트엔드 팀과 밀접하게 협업하면서 CORS 문제와 같은 통합 문제를 해결하는 방법을 배울 수 있었다. 이를 통해 백엔드 개발자만의 관점에서 벗어나 전체 시스템을 이해하고 다른 팀원들과 소통하는 능력을 키울 수 있었다.
이런 경험을 통해 저는 프로젝트의 성공을 위해서는 개개인의 기술적 역량 뿐만 아니라 효과적인 팀워크와 협업이 중요하다는 것을 배웠다. 앞으로도 이러한 경험을 바탕으로 더욱 향상된 협업 능력을 갖추어가야겠다는 다짐을 할 수 있는 기회가 되었고 동시에 프론트엔드 지식의 부족함과 필요성에 대해서도 느낄 수 있었습니다.
열정의 방향성
처음 프로젝트를 기획할 당시 나는 많은 기능을 구현하고 싶었다. 하지만 많은 기능들을 욕심내는 나에게 감사하게도 이런 조언을 해주셨었다. 그 기능들이 추가된다고 해서 이력서에 쓸 한줄이 될 수 있을까요? 이 얘기를 듣고 열정의 방향성에 대해서 생각해 볼 수 있었다. 취업을 위해 모인 집단인 만큼 이번에 진행한 프로젝트는 이력서에 적을 가장 큰 내용이 될 것인데, 비슷한 수준의 기본적인 CRUD 몇개 추가한다고 해서 이력서에서 자랑할 만한 기술적인 메리트가 없다. 그래서 보안의 관한 고민 등을 고민해보며 넓이보다는 깊이에 비중을 두고 프로젝트를 완성할 수 있었다.
이렇듯 무조건적으로 많이 하는게 중요한게 아니다. 결과적으로 많은기능을 포기함으로써 더 좋은 경험을 할 수 있게 되었던 것이다. 취업이라는 목표가 분명함에도 엉뚱한 방향을 향해있는 나의 열정의 방향성에 대해서 고민해 볼 수 있는 좋은 기회였다.
부족하다 생각되는 부분
지식, 경험, 알고리즘
최근에 아는만큼 보인다라는 말에 크게 공감할 수 있었다.
프로젝트를 진행하며 나는 로직을 구현하는데 있어서 크게 막힌 부분이 거의 없었었다. 이는 내가 잘나서가 아니라 아는것만 아는 방식으로 하기 때문이었다. 그런데 문제는 내가 구현한 로직이 구린데 그걸 스스로 인지하지 못하는 경우가 많다는 것이다. 예시로 회원정보를 조회, 수정하는 로직에서 나는 회원 객체의 식별자 id를 이용했었는데 id의 경우 규칙성이 있고 유추당할 수 있다. 따라서 외부에 회원 id를 제공해야할 때는 규칙성이 없는 uuid를 이용하도록 바꿨는데 스스로 이러한 문제점을 생각해 내지 못하고 멘토님의 피드백 덕분에 가능했던 일이었다.
이렇게 죽이되건 밥이되건 일단 구현을 해낼 수 있다는건 만족스럽지만 문제는 내가 만든게 밥이 아니라 죽이라는걸 인지하지 못한다는 것이다. 결국 이 문제의 원인은 나의 지식과 경험이 부족해서 발생하는 문제인 것 같다.
그리고 이러한 일은 알고리즘을 공부할 때도 마찬가지였다. 풀이법을 모르니 막무가내로 3중, 4중 반목문을 통해 알고리즘 문제를 푼 경험이 많다. 이는 시간복잡도가 매우 안좋기 때문에 사실상 쓰면 안되는 방법인데 결국에 이것도 내가 더 깔끔하게 푸는 방법을 모르기 때문에 발생한 일이다.
이러한 부분을 결국 내가 더 열심히 공부하고 경험해서 해결하는 방법 밖에는 없을 것 같다.
질문의 타이밍
아직도 질문을 하는 타이밍을 모르겠다. 고민없이 질문하고 답변을 얻으면 기억에 안남을 뿐만 아니라 정보를 찾는 과정에서 얻을 수 있는 추가적인 정보를 놓칠 수 있다. 흔히들 핑프(핑거프린스: 노력하지 않고 질문하는 사람)가 되지 말아야한다고 말하는데, 나는 이말에 크게 공감한다.
그래서 문제가 발생하면 debug, search를 통해서 스스로 문제를 해결하려고 하는데 문제는 조금만 더 하면 해결할 수 있을 것 같은데?하는 생각에 조금 더 조금 더 하다가 시간이 순식간에 지나가 버린다. 최근에도 Redis Repository오류에 관해서 너무 오래 고민하는 것 같아 질문을 했었는데 또 질문을 하는 과정에서 스스로 문제를 해결해 버렸다. 이러한 경험들이 다 지식이 되고 오랜시간을 투자한 만큼 기억에 많이 남기는 하지만 앞으로 취직하고 현업에 가게되면 효율성에 대해서도 고민해봐야한다고 생각한다.
1년차 개발자인 친구(이하 홍길동)가 만 하루를 꼬박 고생해서 문제를 해결하고 후에 선임 개발자에게 말했더니 홍길동씨 너무 비효적이지 않나요? 저한테 물어보셨으면 금방 해결하실 수 있었을텐데라는 말을 들었다고 한다. 회사에서는 생산성 있는 작업을 위해 효율을 고려하지 않을 수 없다. 따라서 앞으로 막히는 부분이 생긴다면 3시간 이상은 고민하지 않는다 등의 기준으로 질문하는 타이밍을 정해야겠다는 생각을 해볼 수 있었다. 하지만 또 case by case인 문제가 너무 많아서... 이 기준을 어떻게 잡아야할지 너무 어렵게 느껴진다.
