Story. 23 WIL x 2 (220328~220410)

오늘은 저번 주에 누락한 wil을 포함해서 2주에 걸친 wil을 작성하게 되었다.

곧 내일배움캠프 1기가 끝나는데 배운 내용을 정리하며 점검하는 시간을 가져야겠다.

---

👀 이번주에 한 일

• 프로젝트 중간발표 & 준비 (3.28 ~ 3.31)
• 배포 준비 및 서비스 최종 테스트 (4.1 ~ 4.5)
• 서비스 배포 및 설문조사 (4.5 ~ 4.7)
• 서비스 유지 보수 // 피드백 반영(4.5 ~ 4.10)
• 무한 스크롤 구현 (4.8)

 

📚 이번주 배운 것

• 테스트의 중요성
• 스크롤을 통한 페이지네이션

 

😄 이번 주 TMI

정말 많은 이슈가 있었던 2주였다. 먼저 중간발표를 위해서 back과 front를 병합하는 과정이 3월 30일에 있었는데 3주 동안 작업한 내용을 한 번에 병합하다 보니 이슈가 터질 때 여유 있는 대처를 하기 어려웠고 작은 이슈도 시간이 부족해서 큰 이슈가 되어버리는 일을 경험했다. 프로젝트가 진행되면서 조금 느슨해졌던 부분이 있는데 한 달이 넘어가는 프로젝트라면 최소한 주마다 서로 작업한 내용을 확인하고 병합해서 테스트하는 시간을 가지는 게 작은 이슈를 작은 이슈로 끝내는 좋은 방법이라고 생각한다. 

 

<이슈>

우리 팀에 있었던 가장 큰 이슈는 css파일이 적용이 되지 않는 문제였다. s3를 사용하면서 프로젝트의 모든 static 파일이 s3에 올라가게 되었는데 로컬의 다른 프로젝트에서는 작동하던 css, js가 병합 과정에서 제대로 작동하지 않게 되었다. 발표 전날 밤에 이러한 이슈를 알게 되었고 기능적인 부분은 완성이 되었으나 보여줄 페이지가 없어서 중간발표를 반 포기하는 상황이 벌어지게 되었다. 

이런 이슈를 좀 더 빨리 파악할 수 있었으면 유연하게 대처할 수 있었겠지만 시간이 없었기에 원인을 정확하게 파악하기보단 찍으면서 이슈 해결에 중점을 두고 밤을 새웠다. 

 

<추정 원인>

이슈를 해결하면서 팀원들과 생각한 몇 가지 추정 원인이 있었는데 이 부분은 명확하게 검토된 부분이 아니라 참고만 바란다. 

 

1. 서버 사이드 랜더링 문제

프로젝트의 기본 프레임워크가 장고이기에 장고 템플릿을 사용하여 프런트 작업을 진행했는데 s3에 있는 static을 장고가 가져오고 장고가 템플릿과 static을 렌더한 이후에 서버에 띄워지는 로직이라 중간중간의 렌더 과정에서 개발자가 파악하기 어려운 이슈들이 있지 않았나 싶다. (장고 템플릿의 정확한 작동 원리를 알지 못하기에 확신하지 못한다.)

 

2. 권한 문제 

s3는 참여자들의 권한을 제어할 수 있는데 이러한 권한 설정에 의해서 static을 가져오지 못한 거 같다. 

 

3. css 빌드 문제

css 빌드를 프로젝트 내에서 바로 진행한 게 아니라 다른 테스트 프로젝트를 만들고 빌드를 해서 css가 로컬 프로젝트에서 작동이 되는지 확인되지는 않았다. (이미 s3와 연동이 되었기 때문에) 나중에 해결 과정에서도 말을 하겠지만 css를 불러오긴 불러오는데 일부부만 불러오는 경우도 있어서 css 빌드에도 문제가 있지 않을까라는 생각을 해 보았다. 

 

<해결 과정>

처음으로 시도한 방법은 권한을 풀어주는 방법이었다. 이 부분은 튜터님의 도움을 받아서 보안 이슈가 생길 정도로 s3 버킷의 모든 권한을 풀었고 static 파일을 읽어오긴 하지만 부분만 적용되는 이상한 현상이 발생했다. 

이어서 시도한 방법은 버킷 db 등 새로 만들 수 있는 외부 환경을 새로 빌드해서 테스트를 해봤는데 이슈가 해결되지 않았다. 

마지막으로는 새로운 프로젝트 환경에서 작업내용을 클론 하여 전체적으로 프로젝트를 새로 빌드하는 것이었다. 일단 서버 쪽 기능은 잘 작동하는 걸 확인했었기에 백엔드 부분은 팀 레포지토리를 전부 활용을 했고 새로운 s3와 db를 연결하면서 템플릿과 css 적용 문제를 하나씩 확인해 보았다. 

일단 새로운 s3는 권한을 퍼블릭하게 다 풀어놨기에 권한이 문제가 되지는 않을 거라고 생각을 했다. 하지만 실제로 스태틱 파일을 넣어서 실행해보니 액세스 문제가 뜨는 걸 확인할 수 있었다. 

여기서 개발자 도구의 네트워크를 확인해 봤는데 실제 퍼블릭하게 접근할 수 있는 주소와 다르게 해더가 추가되어 있는 걸 확인할 수 있었다.

ex)
s3 버킷 내 파일 접근 url 주소 : https://greendoorhope.s3.amazonaws.com/feed/20220404/file_20220404005712.jpg

실제 네트워크에 찍히는 url 주소 :
https://greendoorhope.s3.amazonaws.com/feed/20220404/file_20220404005712.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=<YOUR_ACCESS_KEY_ID>/20220329/ap-northeast-2/s3/aws4_request&X-Amz-Date=20220329T000000Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=<SIGNATURE_VALUE>

이 내용은 x-amz에 관련된 건데 해당 url에 접근하기 위해 일시적인 접근 권한을 부여하기 위한 장치라고 생각된다. 

 

여기서 든 생각은 2가지.

1. 왜 해당 헤더가(x-amz-algorithm) 포함된 주소로 접근이 불가능한가?

2. 이미 s3를 퍼블릭하게 풀어놨는데 헤더가 필요할까? 필요 없다면 어떻게 헤더를 지울까?

 

1번 고민에 내 생각은 이렇다. 발행된 헤더의 내용을 살펴보니 현재 한국시간이 아닌 utc 시간으로 발급이 되어있었고 x-amz-expries 내용도 3600으로 1시간만 유효하기에 생긴 문제가 아닌가 싶다. 

 

좀 더 자세하게 설명하면 우리 서버는 기본적으로 한국에서만 배포할 계획이기에 서버가 한국시간으로 설정되어있다. 하지만 발행된 헤더의 날짜는 현재 한국시간의 9시간 전인 utc 시간으로 발급되었고 유효시간인 3600초(1시간)을 더해도 현재 한국 시간의 8시간 전이기에 이미 유효가 만료된 url이 되지 않았나 싶었다. 

이 문제의 원인을 좀더 명확하게 파악하고 해결을 하고 싶지만 시간이 없었기에 바로 2번 고민으로 넘어가게 되었고 헤더를 지울 수 있는 방법이 없나 찾아보게 되었다. 

 

2번 고민에 대한 해결은 의외로 간단했다. 템플릿 파일에서 img나 css, js 등 static 파일을 불러올 때

{% static 'css/style.css'%} 형태의 장고 템플릿을 사용해서 불러왔는데 이 부분을 '/static/css/style.css' 형태로 변경하자 뒤에 해더가 없는 깔끔한 url 주소로 네트워크에서 가져오게 되었다. 

 

이유는 모르겠지만,, 이제 static 파일을 네트워크로 가져올 수 있게 되었다!! 기쁨을 안고 서비스를 확인해 봤는데 css가 일부분만 적용이 되는 이슈가 생겼다. 

 

이미 권한 문제와 네트워크로 static 파일을 가져오는 건 확인했기에 이제 남은 건 css의 문제이다. 빌드된 css를 하나씩 주석처리해보고 새로운 코드를 추가하기도 하면서 css가 적용되는지 테스트를 했고 로컬에서 정상 작동하는 프로젝트를 바라보며 아침해를 맞이할 수 있었다. 

 

---

밤을 새우며 프로젝트를 심폐소생술로 살리고 중간발표를 하고 나니 기력이 쭉 빠졌다,,  static 이슈로 배포를 못했기 때문에 배포와 테스트를 해야 되는 과제가 남아있었는데 힘을 쏟지 못했고 이로 인한 문제는 다량의 피드백을 통해서 확인할 수 있었다.

 

그래도 우여곡절 끝에 배포된 greendoor. 배포 담당자분이 ams 크레딧이 녹아내릴 때 까지는 서버를 돌리신다고 하니 그때까지 유지 보수에 힘쓰며 발전시켜야겠다.

 

💥 다음주 목표! (간단하게)

• 최종 발표 준비
• 포트폴리오 준비

 

---

<greendoor 도메인>

https://grdr.net/

GREENDOOR

 

<greendoor 프로젝트 레포지토리>

https://github.com/4-tune-studio/greendoor

GitHub - 4-tune-studio/greendoor