가을의 문턱에서부터 함께한 전시로그를 돌아보며 ..
프로젝트를 진행하며 생각한 점 위주로 작성해보았다.
프로젝트 선택
훌륭한 아이디어가 많았지만 이미 내 마음에선 정해져 있었다.
전시회 기록 서비스와 편지 서비스 둘 중 고르기로 했다.
꽤 길게 진행되는 프로젝트기에.. 애정 없이 할 자신이 없었고, 후보를 두 개로 줄인 것이다.
고민 끝에 전시회로 결정했고, 나중에 들은 이야기로는 가장 인기가 많았다는데, 원하는 프로젝트를 할 수 있어서 다행이었다.
선택 기준
사실 딱 보자마자 마음에 드는 걸 골랐지만, 무의식에 나름의 기준이 있었다고 생각한다.
가장 큰 요소는 역시 내가 하고 싶은가?이다.
경험상 하기 싫은 공부는 손도 잘 안가고 생각도 귀찮았기 때문에 더더욱 중요했다.
또한, 같은 파트뿐만 아니라 팀 전체적으로 어떤 사람들과 함께 프로젝트를 하게 될까에 대한 생각도 필요했다. 잘 맞는 사람들이랑 하는 것이 좋을테니까.
누가 할 지도 잘 몰랐지만.. 전시회를 고르는 사람들의 '결'이라는 느낌으로 미루어 보아 당연히 오케이였다.
결과를 보면 난 촉이 좋은 사람일지도 모르겠다.
개발쪽으로 고려가 없었던게 아닌가 싶기도 하지만 괜찮다. 이런게 대학생의 특권 아니겠는가
목표
목적없는 걸음은 길을 잃기 마련이다
길을 잃어도 괜찮지만.. 다시 돌아오기 위해서라도 목표를 설정할 필요가 있다
이번 프로젝트에서 개인적으로 생각한 목표는 하나의 서비스를 시작부터 끝까지 함께 하며 전체적인 과정을 경험해보는 것이었다. 개발을 시작한 지 얼마 안되었고, 프로젝트 경험 또한 거의 없었기에 흐름을 익혀보고 싶었다.
그리고 팀 매칭 후, 규칙 등을 정하며 가장 많이 나온 이야기는 역시 협업에 관한 것이었다. 꽤 많은 사람들이 심지어 다른 파트와도 함께 하는 것이기에, 소통에 중점을 두었고, 나 또한 동감했다.
협업
특히나 개발은 협업이 중요하다는 이야기를 많이 들었다. 깃허브와 같은 코드 저장소부터 코드 컨벤션, 문서 관리 등.. 협업에 관해 신경쓸 것이 많다.
개발의 경우 함께 개발하긴 하지만 자신이 맡은 부분 외에는 잘 모르는 경우가 많았다. 나는 그런 점이 아쉬었고, 우리는 각자 파트만이 아닌 프로젝트 전체적으로 이해하기로 했다.
깃허브
깃허브에서 볼 수 있는 Isssu와 PR(Pull Request)을 적극 활용하기로 했다.
Issue
이슈 템플릿을 설정해두어 할 일을 먼저 적어두어, 서로 어떤 작업을 하고 있는지 확인할 수 있었다.
Pull Request
작업이 끝나면 PR을 올려 연결된 이슈와 함께 작업한 내용을 확인하고, 리뷰하는 과정을 필수로 거쳤다.
리뷰하며 서로의 코드를 반드시 확인하고, 승인이 있어야만 병합을 할 수 있도록 했다.
깃모지
협업에 관하여 신기한 것들이 많았다. 그 중 하나가 깃모지인데, 작업마다 ✨, 🐛 같은 이모지를 붙여서 어떤 작업을 했는지 한 눈에 볼 수 있도록 하기 위해 사용했다.
알림
빠르고 원활한 소통을 위해 자동으로 소식을 전하는 알림이 있으면 좋겠다는 생각을 했다.
Discode
웹훅을 통해 깃허브와 디스코드를 연결하여 작업할 때마다 알림을 받아 빠르게 확인할 수 있었다.
그 외에도..
선언이라는 이름으로 회의를 정말 많이 했다.
개발하며 각자의 생각을 담은 일지도 작성하고, 여러 방식으로 활발한 소통이 이루어졌다고 생각한다.
개발
창조의 영역부터 오류 수정까지 여러 이야기가 있지만, 가장 낯설었고 우리 프로젝트에서 빠질 수 없는 데이터 저장에 관한 기억이 가장 많이 남는다.
전시회
전시회 정보를 제공하기 위해 전시회 데이터가 필요했다. 직접 수집과 외부 API 호출을 통해 가져오는 방법이 있는데, 외부 API 호출을 통해 데이터를 가져와 저장하기로 했다.
거르고 걸러 필요한 데이터만을, 정확한 형식에 맞추어 기껏 조회했더니 일일 사용량에 막히기도 했지만
2000개 넘는 데이터를 저장하여 사용했다
배포
개발이 완료되고 로컬에서 테스트를 성공한 후에 해당 내용을 포함하여 배포를 했는데, 배포 환경에서는 에러가 발생하는 경우가 종종 있었다.
이미지 저장
우리는 유저의 프로필 사진과 전시회 이미지 및 포토 캘린더에서 이미지에 대한 처리가 필요했다.
이를 위해 AWS의 S3를 사용했는데, 클라우드에 이미지를 올려 누구나 볼 수 있도록 하기 위함이었다.
문제
배포 환경에서 이미지 저장 시, Permission Denied 에러가 발생하는 경우가 있었다.
인바운드 규칙을 설정했음에도 해결이 안되어, 알아보았다.
A. 보안 그룹의 인바운드 규칙으로 허용 포트를 지정했음에도 불구하고
EC2 인스턴스 내에서 별도의 포트 번호 과정을 가져야 하는 이유는 크게 두 가지로 나눠볼 수 있다.
-
보안 그룹은 AWS 네트워크 수준에서 작동하는 가상 방화벽이며,
EC2 인스턴스 내부에 있는 실제 응용 프로그램 또는 OS 수준의 방화벽은 관리하지 않는다.
따라서 EC2 인스턴스 내부에서 특정 포트나 서비스를 사용하려면 해당 포트를 개방하고 응용 프로그램이나 서비스를 설정해야 한다.
보안 그룹보다는 인스턴스 내의 소프트웨어 설정과 관련된 부분인 것이다. -
EC2 인스턴스 내부에는 로컬 방화벽이 존재할 수 있다.
로컬 방화벽은 트래픽을 제어하고 특정 포트를 차단하거나 허용하기 위해 사용된다.
보안 그룹의 규칙과 로컬 방화벽 설정이 충돌할 수 있으므로,
EC2 인스턴스 내의 로컬 방화벽 설정을 확인하여 포트가 제대로 열려 있는지 확인할 필요가 있다.
보안 그룹은 AWS의 네트워크 계층에서 작동하며 트래픽을 제어하는 역할을 하지만,
EC2 인스턴스 내부의 실제 응용 프로그램 또는 방화벽 설정은 개별적으로 관리되어야 한다.
S3는 443 포트를 사용하는 민감한 녀석이기 때문에, UFW라는 우분투 방화벽을 설정해주어 해결하였다.
배포 자동화
빠르고 편한 배포를 위해 배포 자동화 환경을 구축하였다.
간단하게 깃허브 액션과 AWS의 Code Deploy를 사용했다.
main 브랜치에서의 push를 트리거로 배포가 자동으로 진행된다.
프로젝트 후반부에 수정 및 추가 사항이 상당히 많았는데, 그때마다 빠르게 적용시킬 수 있는 점이 좋았다.
아쉬움
아쉬움은 다음 걸음의 방향을 정해준다
개발
개발쪽으로 아쉬운 점은 항상 넘친다.
공부할수록 공부할 것이 너무나도 많다는게 느껴지기 때문이다.
사용해본 적이 없던 기술을 적용했으면 더 좋았겠다는 생각이 든다.
CI/CD에서 Jenkins와 Docker를 써보고 싶고, 배포 환경에서 Nginx를 사용해보고 싶은 것과 같은 생각들이다..
이런 기술적인 것들 이외에도 항상 남는 깔끔하지 못한 코드에 대한 아쉬움.. 등이 있다.
협업
코드를 작성하고 개발을 시작하기 전에 구상을 먼저 해야한다. 후반부에 밀려오는 수정 사항들을 보며 우리가 느낀 점은 역시나 '처음에 설계를 더욱 잘 했으면 좋았겠다'는 생각이다.
결국 클라이언트(안드로이드)와 연결이 되어야 하기 때문에 개발 시작 전에 시간이 좀 오래 걸리더라도 같이 검수를 하면 좋았을 것 같다는 생각이 들었다.
서버 파트끼리는 소통이 정말 잘 되었다고 생각하는데, 다른 파트와의 소통 또한 더 잘 이루어질 수 있지 않았을까 하는 아쉬움도 있다. 충분히 잘 되었지만 말이다!
후기, 소감과 같은 단어를 적기엔 맘에 안들고..
쓸 말을 고르다 차라리 공백을 택한다
팀 전체적으로 친한 느낌은 아니지만 프로젝트로 이어지는 유대가 상당히 깊었다는 생각이 든다. 만나서는 허허 어색했지만서도, 사람으로 인한 큰 마찰 없이 프로젝트를 마무리 할 수 있었다는 것만으로도 성공적이지 않나 싶다. 특히나 우리의 가장 큰 목표였던 '원활한 소통'에 관해서는 더욱이 그렇고..
영속성이라는 개념이 있다.
메모리에 모여 있다가, '커밋'이라는 행위를 통해 한 번에 영구적으로 저장되는 영속성을 갖게 되는 것이다.
하지만, 중간에 에러가 발생하거나 모종의 이유로 실패하게 되면 영구적으로 저장할 수 없게 된다.
겨울은 향으로 온다는 말이 있다
이번 겨울의 향이 영속화 되기를 바라며..
