시작
멋쟁이사자처럼 11기 운영진으로 활동을 시작하며 가진 목표는 함께 자라는 조직을 만드는 것이었다.
작년, 우아한 테크코스:프리코스에 참여해 진행하면서 불특정 다수의 사람들이 discussion탭에서 서로의 생각과 코드를 나누고, 질문과 답변을 이어가며 함께 성장하는 경험을 할 수 있었다.
나는 여기서 착안하여 우리도 우테코처럼 과제를 사이트로 제출하고, 제출시에 과제에 한주 회고를 작성, 그것을 공유해 읽으면서 세션과 운영을 해나가고 싶었다. 나는 그래서 이 사이트 아이디어를 투고했고, 좋은 반응을 얻게 되었다.
아쉽게도 회고 기능은 완전한 동의를 얻지못해서 넣지 못했지만, 어쨌든 프로젝트는 우리 동아리만의 사이트를 만드는 것으로 진행되게 되었다!
우리도 사이트 기똥차게 하나 만들자!
sopt나 디프만, nexters 등 여러 it동아리들은 사이트가 잘 되어있다. 하지만 우리 동아리는 그런게 좀 부족하다고 느꼈고, 이후 기수에서도 이 프로젝트를 쭉 이어갈 수 있도록 퀄리티 높고 유지보수가 가능한 사이트를 만들기로 하였다.
마침 들어오신 디자이너분
마침 디자인 운영진분께서 합류하게 되었고, 감사하게도 바로 사이드프로젝트에 합류하게 되셔서 프로젝트를 함께 진행하게 되었다.
어려웠던 부분, 고민했던 부분들
배포, CICD
나는 도메인 주소를 달아서 배포해보는게 두번째였다.
가비아, DNS, 네임서버
가비아를 통해 도메인을 직접 구매하고, 관리해본게 처음이었다.
ACM에서 DNS를 통해 서버 검증도 해보고... 인증서도 처음 발급해보고...!
이때 경험을 활용해 dev(테스트서버)도 구성하는데 어려움을 겪지 않았다!
AWS
이전 '호미' 프로젝트에서는 ec2와 code deploy를 사용해서 배포를 했었는데, 이번에는 serverless라는 라이브러리를 통해 aws lambda, s3, cloudfront로 배포하게 되었다.
lambda와 lambda@edge도 구분하지 못하던 나는 이후 소셜 로그인 오류 부분에서 정말 개고생을 하게된다.
구현
솔직히 이렇게 까지 규모가 큰 프로젝트라고는 생각하지 않았었는데...
내가 지금까지 했던 어떤 프로젝트보다 그 규모가 컸다.
재사용가능한 컴포넌트 설계하기
아무래도 세션, 프로젝트, 갤러리 등 세종류의 아카이빙 페이지를 구성하다보니 겹치는게 많았고, 이 부분을 한번에 처리하기 위한 고민들을 많이 했다.
제네릭을 제대로 활용한 경험이 별로 없는데, 이를 통해 제네릭을 제대로 활용하고, 들어온 data의 프로퍼티 키값을 통해 타입을 분기해주는 함수를 만들어 다형성을 구현할 수 있었다.
애니메이션! 애니메이션! 애니메이션!
Slider, Carousel
랜딩페이지와 Carousel을 구현하는데 어느정도 애니메이션 방향성이 겹쳐서 hook으로 제작해줬다.
framer-motion은 정말 애니메이션을 구현하는데 혁신적인 라이브러리라고 생각한다.
css로 구현하는 것보다 코드가 깔끔해져서 관리하기 정말 좋아지는 것은 물론, 간편하게 여러 곳에서 재사용할 수 있다는 점이 정말 매력적이다.
Scroll 애니메이션
랜딩에 들어가는 스크롤애니메이션도 framer-motion을 통해 구현했다.
scroll-snap 속성과 애니메이션 사이의 충돌을 해결하고자... 많은 노력을 기울였다.
이동하는 애니메이션은 반드시 absolute여야한다! relative는 해당 요소의 배치가 애니메이션으로 바뀌게 되면 다른 요소에도 영향을 미치기 때문이다.
rewrites, layout, router커스텀
nextjs에서 rewrites, layout, router커스텀과 같은 기능을 처음으로 사용해보았다.
rewrites를 통해 api주소 은닉, cors오류 해결을 할 수 있었고,
layout을 통해 각 페이지에 맞는 공통 레이아웃을 지정할 수 있었으며,
router커스텀을 통해 로딩시에 유저가 흰 화면을 보지 않고 로딩스피너를 볼 수 있도록, UX를 개선할 수 있었다.
소셜 로그인과의 사투
구글 소셜로그인을 붙여보면서 배포서버와 로컬 환경의 redirect_uri가 달라 로그인이 안되는 현상을 확인했고, 이 부분을 제대로 알지 못해서 엄청난 시간을 여기다가 소비했다.
백엔드 친구와 거의 3시간동안 서버 로그 디버그를 하면서, redirect_uri에 따라 구글자체의 access token이 발급안되는 문제를 확인했고, 이를 가설을 세우고 확인함으로써 결국은 해결해냈다...! 인간승리.
이 과정을 통해 빈약하던 소셜로그인 과정에 대해 제대로 이해할 수 있었다.
이 경험을 통해 access_token에 대한 이해를 높히고 싶다는 생각이 들었고, node와 로그인과 인가처리에 대한 공부로 이어지게 되었다.
더불어 axios의 interceptor를 활용해서 인가 만료시에 토큰 재발급을 한번에 처리해줌으로써, 여러번 같은 코드를 적거나, 처리해줄 필요없이 한번에 문제를 해결하도록 개선했다.
export const getAuthAxios = (token: IToken) => {
const authAxios = Axios.create({
baseURL: `${process.env.NEXT_PUBLIC_API_KEY}`,
headers: {
Authorization: `${token.access}`,
},
});
authAxios.interceptors.response.use(
(res) => res,
async (error) => {
const {
config,
response: { status },
} = error;
if (status !== 401) {
return Promise.reject(error);
}
const { access: newAccessToken, refresh } = await getNewToken(token.refresh);
LocalStorage.setItem('access', newAccessToken);
LocalStorage.setItem('refresh', refresh);
config.headers.Authorization = `${newAccessToken}`;
const response = await axios.get(config.url, config);
return Promise.resolve(response);
},
);
return authAxios;
};
느낀 점, 배운 점
소통의 부재
이번 프로젝트를 진행하는 동안 마감기한도 생각보다 쳐지고, 소통이 원활하게 이뤄지지 못했던 것 같다. 특히 모든 팀원이 진행상황을 다알지 못하는게 컸다고 생각한다. 괜히 PM이 있는게 아니라는걸 크게 느꼈다...
문서화도 잘 되지 않아서 구현하려면 물어보고, 그걸 확인하는 과정이 필수였다.
이후의 프로젝트에서는 api는 물론 기능부분에도 문서화를 잘하고 기록으로 남겨 공유하는 습관을 들여야겠다고 다짐했다.
멀고도 험한 개발의길
문제는 많고, 그것을 해결한 방법은 더 많다. 하지만, 해결방법만을 알아서는 안된다.
문제의 원인을 정확하게 파악하고, 그걸 해결할 방법을 찾자.
항상 왜?라는 질문을 놓치면 안된다고 생각하게됐다.
왜안돼? 왜 돼? 등 개발을 하다보면 왜?라는 질문이 생길때가 굉장히 많다.
얼레벌레하다가 되면 그냥 넘어가는 경우가 있는데, 절대로 그래서는 안된다는걸 확실히 알았다.
몇 시간, 몇 일, 몇 주가 걸리든 상관없다.
문제의 본질을 찾고, 방안을 모색하자.
그게 내 피와 살이 된다.
우리가 개선한 것들
1. 출석
현재 우리사이트는 51명의 이용자를 가지고 있고, 매주 비밀번호를 현장에서 발표하여 출석하는 형태로 출석을 사이트를 통해 수행하고 있다.
이전까지 수기로 출석체크해서 발생하는 휴먼에러가 아예 사라지게 되는 것이다.
2. 아카이빙
노션으로 아카이빙을 하고는 있지만 노션이미지는 데이터가 많아지면 로딩이 느려서 바로 확인하기 힘들다는 단점이 있다. 우리의 아카이빙 페이지와 이미지는 클라우드 프론트로 배포되어있어서 노션보다 매우 빠르고 확인하기 편리해졌다.