230110 TIL

오늘 배운 것 & 한 일

CD 구현

Git Actions를 이용한 CD 구현이 드디어 끝났다.

 

Git Actions는 모두 통과했는데 CodeDeploy에서 실패가 떠서 그걸 해결하느라 오래 걸렸다.

 

직접 EC2 서버의 로그 파일을 열어보면서 오류를 찾아서 해결했었다. 나중에 알게 된 사실이지만 로그를 안보고 AWS 인터페이스로도 확인을 할 수가 있었다..! 

 

실패한 사진

위 사진처럼 CodeDeploy 인터페이스에서 이벤트별로 상태를 확인할 수 있었다.

 

사진에서 보이듯이 AfterInstall이 실패한 거였는데 알고보니 scripts 파일 안에 있는 start.sh와 stop.sh 파일에서 프로젝트의 경로를 잘못 설정해줘서 저 둘을 실행하지 못한거였다..!

 

어쨌든 로그 찾는 법도 어느 정도 익혔으니 나쁘지 않은 수확이었다고 생각한다.

 

배포와 관련된 내용은 온전히 이해한 채로 쓴 게 아니라 다른 블로그를 따라한 것이기에 아직은 따로 글로 정리하기는 힘들 것 같다. 참고했던 블로그는 아래에 레퍼런스로 남겨 두었다.

 

RDS와 MariaDB

RDS를 적용하려고 찾아보다가 MariaDB 란 것을 알게 되었다.

 

MariaDB의 설명을 찾아보면 대부분 MySQL의 완벽한 상위호환처럼 이야기를 한다. 하지만 의문이 하나 있었다. 정말 MariaDB가 MySQL의 완벽한 상위호환이라면 왜 DB 엔진 점유율은 MySQL이 MariaDB 보다 훨씬 높은 것일까?

 

만약 MariaDB가 정말로 상위호환이라면, 아마 이미 MySQL 기반으로 만들어졌던 서비스를 교체하기 힘들어서 점유율 차이가 나지 않을까 생각한다. 하지만 그게 아니라면 MariaDB도 그 나름대로의 단점이 있고, MySQL도 MariaDB에 비해 뭔가 장점이 있을지도 모른다.

 

그래서 실제로 두 DB가 정확히 어떤 차이점이 있는지 알기 힘들어서 일단은 MySQL을 사용하기로 했다. 적어도 아직까진 MySQL을 사용하면서 문제가 없었으므로, MySQL로 인한 문제를 직접 겪어보는 게 나을거라 생각했다.

 

물론 선택만 했을 뿐 아직 적용은 못했다..ㅎ. 적용하는대로 TIL에 남겨보자. CI/CD 내용과 마찬가지로 아직은 다른 글을 보고 따라하는 수준이라 이 내용은 별도의 글로 정리하진 않을 것 같다.

 

디자이너님과 서비스의 차별점

오늘 디자이너님과의 회의가 있었는데 회의때 디자이너님이 멘토분께 받은 피드백을 공유해주셨다. 그 멘토님은 우리가 기획한 와이어프레임이 기존 다이어리 서비스와 차별점이 없어 보인다고 피드백 해주셨다.

 

항해에서 진행하는 실전 프로젝트에는 독특한 점이 하나 있다. 디자이너와 개발자들이 협업할 때 한 쪽이 다른 쪽에 외주를 준다기보단 양쪽 다 포트폴리오를 준비한다는 점이다. 이게 생각보다 골치가 아팠다.

 

웹 개발자들은 포트폴리오를 위한 프로젝트를 할 때 해당 서비스의 차별점보다도 웹 개발자로서 어필할 수 있는 부분에 집중해야 한다고 생각한다. 내가 어떤 기술을 다룰 수 있고, 어떤 기술적 문제를 해결하기 위해 무엇을 도입했는지 등 기술적인 부분에 상대적으로 더 집중하는 것이 좋다고 본다.

 

그런데 오늘 듣기론 디자이너는 서비스의 차별점이 포트폴리오에서 어필할 때 가장 중요하다고 한다. (이 부분은 현직 디자이너님께 따로 여쭤본 적이 없어서 정확하진 않다)

 

서로가 필요로 하는 부분이 다르다보니 이걸 잘 조율하는 것이 생각보다 어려웠다. 한 쪽이 외주를 받은 것이라면 외주를 부른 쪽의 입장에 맞추면 된다. 하지만 지금은 양쪽 다 포트폴리오를 준비하는 것이기 때문에 어느 한 쪽에 치우칠 수가 없었다. 

 

게다가 더 문제였던 건 내가 디자이너의 포트폴리오에서 서비스의 차별점이 중요할거라고 생각을 못했었다는 점이다. 디자이너 또한 개발자들처럼 디자인에서 기술적인 요소를 어필하는 것이 더 중요하지 않을까 하고 막연하게 생각하고 기획을 했었다.

 

이미 기획이 많이 진행된 오늘에서야 이 부분을 이해하게 되었다. 프론트의 일정을 고려했을 때 현재는 새로운 기능을 추가하기도 어려웠고, 기획을 다시 엎기도 힘들었다. 그러다보니 모두가 만족할만한 답이 무엇일 지 생각하는 게 쉽지 않았다. 실제로 아직까지 그에 대한 답을 내놓지는 못했다.

 

한번 이 부분은 계속해서 이야기를 하면서 잘 해결해 나가야 할 것 같다.  

잘한 점

프로젝트 기간 동안의 백엔드 팀 일정을 다시 정리하고 공유하였다. 막연하게 눈 앞의 할 일을 처리하다 보면 작업 속도가 굉장히 더뎌질 수 있다고 생각한다. 프로젝트 기간은 길고, 눈 앞의 할 일들이 적으면 마치 시간이 많이 남은 것처럼 착각하게 되기 때문이다.

 

그래서 나를 포함한 팀원 모두의 능률을 늘리기 위해 현재 상황을 기반으로 전체 일정을 다시 짜고, 프로젝트 기간 동안 백엔드에서 할 일들을 명확하게 하였다.

 

레퍼런스

https://bcp0109.tistory.com/363