매일 언제 끝나지 하고 안끝날 것 같았던 파이널 프로젝트가 끝이 났고 막상 끝나는 것을 기다렸는데 정말 끝나니 기분이 뒤숭숭하다. 아직도 부족한 부분이 많은 것 같고 실전에서 많은 기술들을 배웠지만 시간에 쫓겨 기능 구현은 했지만 블로그나 다른분들의 코드를 깊은 이해 없이 치다보니 이게 맞는건가 싶기도 하냐는 기분이 들기도 한다. 프로젝트가 한번 전복될 위기에서 많은 기능들이 추가되다 보니 너무 기능구현에 급급했던 것이 아닌가란 생각도 들기도 하는 기분이 들어서 아쉽다. 프로젝트는 끝났지만 프로젝트에서 사용했던 코드들을 까보며 개인적인 공부가 더 필요할 것 같고 테스트 코드나 다른 팀원분들이 구현했었던 아키텍처도 뜯어보며 파이널 프로젝트가 끝났지만 알고리즘과 더해져 더 많은 공부가 앞으로 필요할 것 같다..
실전프로젝트때 고생했던 내용들을 정리
Https
많은 어려운 기능이 있었지만 구현하는데 가장 오랜 시간이 걸렸던 개념이었다. 물론 개념을 이해하는데도 시간이 걸렸지만 한 줄로 말하자면 보안 기능을 강화하기 위해 도입했었고 백엔드 뿐만 아니라 프론트 쪽에서도 Https 에 대한 내용을 적용했어야 했고 PWA가 https 기능을 요구한다는 내용 때문에도 이를 도입했어야 했다. 실제로 개념을 이해하는데에는 큰 문제가 없었지만 기능을 구현할 때 도메인을 적용하고 cerbot이나 nginx를 도입하는데에는 큰 문제가 없었지만
Nginx Configuration 설정을 설정하고 sudo nginx -t 로 테스트를 진행할때 "nginx.pid failed (2 no such file or directory) " 오류가 계속났었고 인스턴스 새롭게 생성하고 도메인을 몇개를 다시 파도 안되었던 문제에 직면했다. 결국 $ sudo yum install certbot를 통해문제를 해결하긴 했지만 아직도 왜 문제가 발생이 되었고 해결되었는지는 잘 모르겠다. 인증서가 잘 발급이 되었고 https 인증이 되었으니 넘어가긴 했지만 아키텍처나 코드가 어떻게 실행되고 어떻게 작동하는지를 조금 더 알아 봤어야 했는데 시간이 부족해서 그러지 못했으니 더욱 아쉽게 느껴졌고 알고리즘을 진행하면서 남은 시간동안 지난 프로젝트를 조금이라도 돌아보려 하는데 이 때 코드의 원리나 필요성들을 더 많이 이해해야 겠다는 생각이 들었다
내가 생각하는 좋은 개발자란?
음 왠지 좋은 개발자란 구름과도 같은 것 같다. 눈에 보이고 이상향이 있지만 좋은 개발자가 되기 위해서는 지속적인 노력을 해야하고 앞으로 모든 시간을 좋은 개발자가 되기 위해 노력한다 해도 모든 것을 알지는 못하기 때문일 것이다. 하지만 실전프로젝트를 거치며 보다 나은 개발자가 되기 위해서는 크게 협업, 문제해결능력, 코드를 잘 짜는 개발자 이 세가지인 것 같다는 생각이 들었다.
물론 이 보다 많은 기준이 있겠지만 실전은 겼으며 프론트와 백엔드 간에 이해관점이 다르다는 차이를 알았다. 우리가 야구 모임을 위한 서비스를 만들었고 야구가 서비스가 실제 런칭되는 12월에는 진행되지 않는다는 착안점을 뒤늦게 깨닫고 프로젝트의 방향성 재확립에 대한 필요성이 프론트와 백엔드가 달랐다는 점, 실제로 프로젝트를 진행하면서도 서로를 이해하는 관점이 많이 달랐다는 것을 느꼈고 처음에는 프론트의 입장이 이해가 안되었지만 결국 마지막에는 그들의 입장도 이해를 했고 실제 현업에 가면 더욱 더 많은 갈등들을 겼을 텐데 이 정도 쯤이야란 생각이 들기도 했다. 결국 프론트든 백엔드든 한 곳만 잘해서 기능을 구현했다 하더라도 서로 기능 충족이 되지 않으면 그 기능을 쓸 수 없다는 것을 깨닫고 서로의 이해관계가 중요하다는 생각을 하였다.
두 번째는 코드를 잘짜는 개발자다. 물론 나는 아직 주니어 개발자라고 하기에도 부족한 실력을 가진 개발자고 이 글을 읽는 많은 분들이 지금의 의견은 공감하지 못할 것이라는 것을 안다. 하지만 코드를 잘 짜는 능력이 뒷받침이 되어야 문제 해결능력을 가질 수 있고 고객 서비스를 어떻게 강화할지에 대한 능력이 생긴다고 생각한다. 국어에서 한글을 모르고 글을 쓰는 것 처럼 말이다. 결국 지금 입장에서는 코드를 어느정도 짤 수 있는 능력이 중요하다고 생각했다. 기본적인 CRUD는 할 수 있지만 그 외에도 아키텍처나 기본 CRUD만 해서는 안된다고 느끼게 해주는 프로젝트였다. 어쨌든 지금은 기본이 되어야만 나중의 프로젝트 기획이나 문제 해결도 가능하다는 생각이 들었다.
부족했던 점
사실 이건 내가 팀장이었기에 느끼는 점일 지도 모르겠지만 프로젝트를 진행하면 시간 분배에 대해 굉장히 아쉬움이 많이 남는 프로젝트였다. 앞서 언급은 했지만 야구모임을 가져가는 서비스로 12월에 실제 야구경기가 없다는 점을 인지하지 못했고 기능을 구현할 떄 우리에게 꼭 필요한 기능인가, 우선순위를 어떻게 두어야 할까 라는 고민을 많이 하지 않고 기능 구현에만 급급했던 프로젝트 였던 것 같아 아쉬움이 남는다. 만약 우리가 우리의 서비스 런칭에 대해 자세히 조사하고 기능 구현에 대해서 우선순위를 정하고 프로젝트를 런칭했다면 이 기능이 지금 왜 필요하고 어떻게 쓰여야 할지, 아키텍처는 어떻게 구성되어야 할 지를 보다 명확하게 알았을 것 같은데 그러지 못했다는 점이 많이 아쉬웠고 실제로 현업에 가서는 고객사와 정해진 시간이 더욱 확실해질 텐데 이번 기회로 중요성을 겼었으니 더 괜찮지 않았나 라는 생각이 공존하는 점이었다.
앞으로는?
실전 프로젝트가 끝나고 알고리즘 주차에 접어들었고 알고리즘도 분명 중요하지만 기존 프로젝트의 코드를 하나하나 까보며 여기서 이게 왜 필요했는지 어떻게 구현을 하였는지를 알고리즘과 병행하면 좋을 것 같다고 생각했다. 물론 알고리즘 역시 처음하기에 배운는 것이 쉽지는 않겠지만 꼭 병행을 해야한다는 필요성을 느낀다. 어쩌면 실전 프로젝트보다 바쁜 남은 기간이 될 수 있겠지만 어쩌겠어.. 부딪혀 봐야지 라는 생각이 더 들었다.
'WIL' 카테고리의 다른 글
항해 99 13주차 회고(WIL) (0) | 2021.12.20 |
---|---|
항해 99 11주차 회고(WIL) (0) | 2021.11.29 |
항해 99 10주차 회고(WIL) (0) | 2021.11.28 |
항해 99 9주차 회고(WIL) (0) | 2021.11.15 |
항해 99 7주차 회고(WIL) (0) | 2021.11.02 |