• 프로젝트 관련
    • 프로젝트를 진행하면서 힘들었던 점은? 혹은 어려웠던 점은?
      • 문제: 백엔드 서버 배포 전반적인 과정. 특히 인스턴스-로컬 연동과 .jar 파일 실행에 어려움을 겪음
      • 원인: 우선 인스턴스 서버가 ubuntu라 다루는 법을 잘 몰랐음. 명령문 하나 입력할 때마다 서치를 해야 했음. 그 외, 근본적인 기능적 이슈들은 다음과 같음.
      1. 인스턴스의 MySQL 에서 bind.address가 로컬로 한정되어 있던 것.
      2. 스프링부트의 application.properties에서 불필요하게 server.address와 server.port를 특정 주소와 포트로 한정시킨 것.
      3. 인스턴스로 배포한 백엔드 서버가 자꾸 다운되는 문제. 그런데 이건 ec2 자체 문제라서 문제 발생할 때마다 인스턴스 중지 후 재실행 하는 방법밖에 없다.
      • 개선:
      1. bind.address=0.0.0.0으로 변경하여 어디서든 mySQL 접근 가능하게 설정
      2. 불필요한 코드 삭제하여 해결 다만 앞으로도 이런 상황이 벌어질 수 있으니 리눅스/우분투를 다루는 법과 더불어 배포/네트워크 공부가 필요하다고 생각함.
  • 팀 관련
    • 팀에서 좋았던 점 / 아쉬웠던 점
      • 0~2주차에 설계한 큰 틀을 대체적으로 따라가서 개발 도중에 다시 방향을 아예 바꾸거나 설계를 다시 할 필요 없이 쭉 개발에 집중할 수 있었음. 다만 이미 개발한 것을 어쩔 수 없이 빼게 되거나, 일부 기능을 축소하는 일이 불가피하게 있었음. 그러나 주어진 시간이 촉박했기에, 부가적인 기능을 빼고 더 우선순위가 높은 일에 집중하는 것은 오히려 합리적인 선택이었다고 생각함. 또한 팀원분들이 새벽에도 연락이 가능해서 문제 상황이 생길 때 바로바로 보고하고 공유할 수 있었던 점이 좋았음.
  • 개인 역량 & 성장
    • 내 스스로 잘했다고 생각한 포인트가 있는지? 아쉬움은 없는지?

      • 우선 양적인 측면에서, 다른 팀은 백엔드를 2~3명이 맡는데 우리 팀은 나 혼자였음. 왜 팀이 그렇게 짜인 건지는 모르겠지만 우리 팀은 주제 특성상 백엔드에서 작업할 분량도 많아서 2~3인분을 혼자 해야 했는데, 이걸 끝낸 것 자체가 큰 일을 해낸 거라고 생각함. 추가로 변수명이나 클래스명에 최대한 약어를 쓰지 않고 간결하게 표현하고, 패키지 별로 깔끔하게 나눠서 다른 팀원들이나 멘토님이 보셨을 때도 이해하기 쉽게 설계했음.

        캡처.JPG

        캡처.1JPG.JPG

      • 멤버는 아니지만 멘토님께서 코드 리뷰해주셨을 때 전반적으로 깔끔하다고 말씀해주심. 수정사항이 있긴 했으나 간단하게 몇 줄 고치면 되는 정도로 금방 끝남. 한 가지 아쉬운 점은 비슷한 기능을 여러 메소드로 나눠서 작업해서 동일한 코드가 2~3회 정보 반복되는 부분이 있었는데, 이걸 한 메소드로 합쳐서 작업했으면 훨씬 간결하고 가볍게 구성할 수 있었을 것 같음.

      • 팀원으로서 의사소통 측면에서 노력한 것은 특히 프로젝트 막바지에 프론트와 연동하는 부분이었음. 앞서 말했듯 백엔드를 혼자 담당해서, 백엔드 (특히 서버) 문제로 프론트와 연동이 안 되면 나 말고는 해결할 사람이 없었음. 그래서 본격적으로 프론트-백 연동을 하는 시기에는 거의 잠을 안 자다시피 하면서 프론트 팀원분들이 서버가 다운됐다거나, 403 에러 코드가 뜬다거나, time out 에러가 뜨는 등 서버에 문제가 생겼다고 알려주셨을 때 최대한 빨리 해결하기 위해 노력했음. 특히 백엔드 서버를 배포한 ec2 인스턴스는 서버가 매우 약해서 조금만 과부하가 걸려도 심하면 하루에 2~3번씩 서버가 다운될 정도였는데, 서버가 다운되면 아예 프론트에서 작업을 못 하기 때문에 가능한 빨리 서버를 복구하기 위해 신경 썼음.