사실은 2부에서 끝을 내려고 했지만, 코드 관련하여 적다보니, 좀 많이 장황해 진 것 같아 3부로 나눴다. 3부에서는 로그인 관련 코드와 더불어 필자가 이번 프로젝트를 하면서 느낀 전체적인 성찰 포인트와 총 소감으로 기나긴 윈터레스트 프로젝트 회고를 마무리 짓겠다.

🔐 4) 로그인 관련 코드들(정규표현식 + 카카오 로그인)

다음 과정은 프론트던 백이건 중요한 과정. 바로 유저의 정보를 처리하는 로그인 관련 코드 들이다. 이번 프로젝트에서는 특히 소셜 로그인까지 해보는 경험을 쌓으면서 정말 많이 배우고 경험했다.

1. 잘 못 알고 써 버린 정규 표현식.

먼저, 기본적인 로그인, 회원가입 로직은 기존에 경험했던 것들을 많이 활용해서 크게 어렵지는 않았으나, 이번에 필자는 정규 표현식을 처음 써 봣는데, 그런데 정말 잘못 알고 써 버린 경우가 있어서 그 부분에 대해 한 번 적어본다.

1) 갑작스러운 디버깅 중에 발견한 문제.

이번 프로젝트에서 회원가입 로그인을 맡으면서 일반 로그인은 생각보다 이전에 해 봤던 로직이라 크게 어려움 없이 했던 것 같다. 그런데, 문제는 백엔드와 api를 붙이면서 시작되었다. 일단, 에러 코드라던지 문구를 맞추지 않으면 백엔드에서 보내오는 리스폰스를 받아서 사용자에게 뭐가 문제인지 프론트 단에서 알려줄 수 없었다. 그래서 여러 차례 맞춰보면서 겨우 겨우 끝 맞췄는데, 문제는 발표 하루 전 날 다시 발생하고 말았다.

즉, 벨리데이션 과정에서 처리 되는 오류를 백단에서 받아오면 그 오류를 화면에서 사용자에게 변환하여 보여줘야만 했다. 로그인은 벨리데이션이 잘 되는데, 사인업은 벨리데이션이 특히 키 에러에서 안 먹는 것이었다. 이미 가입했다는 에러나 그런 것들은 전부 잘 받아오는데... 이상하게도 포맷 형식이 안 맞다는 키 에러만 문구가 계속 안 나왔다...

그래서 한 번 코드를 계속 살펴봤다.

그리고 백엔드 단의 종민님과도 계속 혹시 저기 백엔드 리스폰스 메세지가 이상하게 날라온 것은 아닌가 계속 맞춰 봤지만, 몇 시간 째 답이 없었다. 그러다 도저히 안 되겠어서 기존에 백엔드와 프론트 로그인 벨리데이션을 해 봤던 백엔드 태영님께 조언을 구했다.

2) 문제는 코드가 아니라 내 짧디 짧은 지식...

필자는 일단, 태영님께 자초지종을 설명했다.

지금 저희가 로그인 벨리데이션은 다 되고, 사인업 중에서 저 키 에러가 아무리 수정을 해봐도 안 잡히는데 뭐가 문제일까요?

키 에러를 백엔드에서만 처리하나요?

오잉? 거기서 필자는 벙쩠다. 그랬다. 필자는 따로 키 에러를 처리하지는 않는다고 답했다. 그러자 그는 코드를 좀 보자고 했다. 바로 코드를 보자마자, 그는 당연한 것이다고 답했다. 바로 필자의 지식이 탄로 나는 순간이었다.

"사실, 백에서 키에러 처리해 주는 것이랑, 프론트에서 처리해 주는 종류가 좀 다릅니다. 그래서 사실상 프론트에서 미리 키 에러 처리를 해 줄 수 있도록 정규 표현식을 쓰는 겁니다. 그래서 지금은 보니 저 정규 표현식에서 걸러주지 못하는 것 같네요. 저것만 하시면 될거에요~"

그랬다... 필자는 정규 표현식을 정확히 모르고 있었던 것이었다. 정규 표현식을 단순히, 그냥 필자가 극혐하는 무지성으로 써 버린 것이다...

3) 코드 수정.

그래서 바로 코드를 수정해 봤다.

조건 문을 다시 정규표현식을 담아서 넣어줬다. 즉, 만약 정규표현식을 만족하면 아래의 벨리데이션을 백엔드 처리 과정 및 회원 가입 처리를 해주는 것이다. 그 외에 정규 표현식 불 만족 시(이메일 형식x, 비밀번호 조건x) 형식이 안 맞다는 경고를 보여준다. 이를 통해 키 에러를 프론트 단에서 처리해 줄 수 있었다. 다음과 같이 잘 나오는 화면이 보인다.

물론 저기 가운데 왜 키 에러는 안 지웠냐고 반문할 수 있다. 이건 백엔드에서 처리해 줄 때, 혹여나 발생할 수 있는 키 에러가 나올 수 있기에 그 처리를 넣어주는 것이 좋다고 한다. 대개 발생할 일은 없지만, 혹여 모를 장애가 있는 경우 에러 디버깅을 위해 넣어주는 것이 좋다고 한다.

4) 성찰

너무나도 오만한 내 생각과 무지성 식의 코드를 안 짜기로 다짐했건만, 이번 기회를 계기로 다시 반성하게 된 것 같다. 앞으로는 하나의 코드를 짜도 그 코드가 왜 쓰일 지에 대해 다시 고민해 봐야겠다.

2. 카카오 로그인 좌충 우돌 정복기.

사실 카카오 로그인은 어렵다고 들었지만, 또 프론트는 그렇게 어렵지 않다고 들어서 너무 쉽게 생각했다가 이번에 큰 코를 다쳤다. 발표 2틀 전에 막 겨우 겨우 해내긴 했지만.... 인터넷에 떠 도는 수많은 가지각색의 방법을 보면서 혼동도 어려움도 컸던 과정이기에 기록을 남긴다.

1) 코드 치는 것보다는 생각이 더 많았던 과정.

다른 팀들은 카카오 로그인을 먼저 했다고 하지만, 우리 팀은 일반 로그인을 한 뒤에 카카오 로그인을 후순위로 미뤄뒀었다. 지금 와서 생각해 보면, 왜 이렇게 했을까.... ㅜㅜ 후회가 많이 되지만, 뭐 어쩌겠나... 이미 엎질러진 물. 그래서 남은 2틀 동안 기를 쓰면서 구현했다.

사실 코드를 치는 것보다는 이 과정을 어떻게 하는 지에 대한 생각이 더 많았다.

다음과 같이 카카오 로그인 과정 자체를 정리해 보면 대략적으로 이러하다.


생각했던 것보다는 과정 자체는 크게 어렵지 않았다. 결론적으로 요약하자면, 프론트 단에서 처리하는 과정만 봤을 때는, 카카오 서버에 인가코드를 받고, 이후 그걸 통해 다시 카카오 access 토큰을 발급 요청한다. 이후 다시 그 토큰을 백에다가 전달하면 백은 그걸 카카오서버에서 검증한 뒤에 사용자 정보를 받아서 다시 프론트에 우리 사이트에서 쓸 수 있는 jwt토큰으로 리스폰스를 보내준다. 이를 통해 프론트는 사용자를 로그인 시킨다. 이런 일련의 과정이라고 보면 되겠다.

2) 첫 시작은 인가코드 발급 부터...

사실 인터넷에 검색만 해봐도 다양한 과정들이 나오지만, 여기서부터 엄청 헤맸다. 인가코드를 받아오는 것 까지는 이해가 되는데. 그걸 받아오는 방법이 정말 다양했다. 필자는 그래서 공식문서를 꼼꼼이 읽고 또 읽었다. 아래는 카카오에서 인가코드 받기에 대한 설명이다.

인가 코드란?
인가 코드 받기는 카카오 로그인을 시작하는 단계로써, 카카오 로그인 동의 화면을 호출하고, 사용자 동의를 거쳐 인가 코드 발급을 요청하는 API입니다. 동의 화면은 [내 애플리케이션] > [카카오 로그인] > [동의 항목]의 설정을 반영합니다.

이 기능은 웹 브라우저에 로그인한 카카오계정 세션이 존재하는지에 따라 사용자 동선이 다릅니다. 웹 브라우저에 카카오계정 세션이 없다면, 사용자는 카카오계정 정보를 입력하거나 카카오톡으로 로그인하는 인증 과정을 거쳐 동의 항목 확인 화면을 보게 되고, 카카오계정 세션이 있는 상태라면 곧바로 동의 화면을 보게 됩니다.

카카오계정으로 로그인 과정
사용자는 동의 화면에서 서비스 이용 시 필요한 사용자 정보 및 권한 제공에 동의하고 로그인을 요청하거나 로그인을 취소할 수 있습니다. 사용자가 필수 동의 항목에 모두 동의한 뒤 [동의하고 계속하기] 버튼을 누르면, 카카오 인증 서버는 해당 사용자에 대한 인가 코드를 발급해 서비스의 redirect_uri에 전달합니다.

사실 이 내용만 봐서는 뭔가 딱 감이 전혀 오지 않았다. 그래서 다양한 사람들의 글을 읽고 무한 삽질을 시작했다.

3) 인가 코드 받기의 난항 1.

그러다 문득, 인가 코드를 받는 것을 다시 생각해 봤다.
인가코드에 대해 일단 접근하려면 크게 2 종류가 필요했다. CLIENT_ID와 REDIRECT_URI였다. 카카오 공식문서에서는 다음과 같은 uri로 받으라고 되어 있다.

GET /oauth/authorize?client_id={REST_API_KEY}&redirect_uri={REDIRECT_URI}&response_type=code HTTP/1.1
Host: kauth.kakao.com

그래서 필자는 이것을 조합해서 결국 KAKAO_AUTH_URL을 만들었다. 그런데 또, 이 다음이 문제였다. 이 url을 받고나서 카카오에서 설명한 대로 인가코드는 어떻게 받는 것인지 감이 안 잡혔다.

4) 인가 코드 받기의 난항 2.

그래서 이걸 어떻게 받을 지 고민해 보다가, 여러 방식들이 있는 것들을 조합해 본 결과. 결론적으로 카카오 접속하려는 버튼에 href를 줘서 그걸 통해서 접속해 보는 것이 좋겠다는 생각이 들었다. 왜냐면, 결국 카카오 로그인을 통해 사용자는 카카오 접속을 시도할 것이기에...

그래서 바로 로그인 페이지에서 해당 KAKAO_AUTH_URL을 선언해 주고, 그 밑에 카카오 로그인 버튼에 에이 태그를 설정해서 외부 링크로 접속하도록 한 번 해 봤다.

오~ 한줄기의 빛을 본 순간이었다. 드디어~ 카카오 페이지 팝업이 뜨면서 저렇게 접속은 가능했다.

5) 인가 코드 받기의 난항 3.

하지만.... 여기서 한 가지 과정이 더 남았다. 이렇게 접속까지는 되지만, 이후에 필자의 카카오톡 로그인을 하고나면.....

다음과 같은 빈 화면이 나온다. 사실 여기서 필자는 다시 또 당황했다. 이게 뭐지?

그래서 구글링을 다시 또 한 몇 시간 해보니, 답이 나오긴 했다. 저건 사실상 카카오서버에서 보낸 리다이렉트 uri 화면이었다. 그래서 여기서 현재 주소창을 잘 살펴보면, 파라미터로 code라고 나오면서 적혀 있다.

바로 이 코드 뒤에 부분이 우리가 원하고 바라던 그 인가코드님 되시겠다.... 후~ 겨우 찾았지만, 또 이걸 그냥 저렇게 주소 창에서 그대로 쓸 수가 있는가?

6) 인가 코드를 활용하는 방법.

그렇다. 다시 또 카카오는 내게 질문을 던졌다....

이봐요? 저희 인가코드는 드렸는데... 그건 또 개발자님께서 알아서 가공해서 쓰셔야 됩니다. 어떻게 받아올 지는 님이 검색해 보세용~

그렇다. 진짜 단전에서 딥빡이 올라왔지만, 결국 개발자로서 언젠가는 맞이하게 될 일. 다시 받아오는 방법이 뭔가 있을 것이라고 생각했다. 그리고는 키워드 검색을 해 봤다.

"how to get code in parameter"

역시나 스택 오버 플로우~ 굿~ 이걸 보고나니 역시 개발자들은 다 똑같은 경험을 하는 구나~라는 생각과 함께 코드를 쳐서 받아오면 되겠구나라는 생각이 들었다. 그래서 필자는 코드를 쳐 보기 전에 저게 되는 지 한 번 콘솔 창에 직접 해 봤다.

정말 신기했다. 알고보니, 저 window.location.href를 찍으면 현재 주소 url 자체를 불러올 수 있었고, 이후에 searchParams.get('받아올 값 앞에 문자') 이런 식으로 작성하면 현재 주소에서 코드만 받아올 수가 있었다.

7) 이제 문제는 그 다음...

인가 코드까지는 받아오는 방법을 익혔지만, 사실상 필자가 원하는 것은 카카오로부터 다시 또.... accessToken을 받아와야 했다. 그런데 그 방법이 전혀 또 떠오르지가 않았다. 그래서 이 부분에서 막혀서 진짜 다른 팀에도 물어봤지만, 다들 제대로 된 답을 얻기는 힘들었다. 필자 생각엔 그 당시에 필자의 이해력이 아직 도달하지 못했고, 거기에다가 각자의 사이트마다 구현 방식이 전부 다르기에 그럴 수밖에 없었다. 그래서 다시 공식문서로 돌아갔다.

8) 공식 문서에 대한 이해.

다시 또 카카오 공식 문서에서 토큰 받기 부분을 계속 읽어 봤다. 거의 밤 열한 시가 넘어서 그때 딱 떠오른 생각이....

"아! 그러면 이제 해당 인가코드를 뭔가 패치등을 활용해서 보내줘야겠다. 그러면 한 번 그 코드를 작성해 보자!"

서버 통신을 하려면 fetch 함수를 작성해서 그걸로 보내야 된다는 생각에 이르렀다.

9) 본격 fetch 함수 삽질 1.

하지만, 막상 코드를 바로 짤 수는 없었다. 그래서 다른 이들이 한 코드들을 계속 보면서 이해를 시도했지만, 막상 우리 사이트에 맞게 작성하기는 쉽지 않았다. 대부분이 각자 사이트마다 고유 방식이나, 백엔드와 맞추는 것 조차 달랐기에... 제자리 걸음이었다. 그러다 우연히 구글링을 하다가 마주한 코드에서 필자는 다시 이 코드를 활용해 보자고 무작정 덤볐다.

그렇게해서 짠 코드가 아래와 같다. 비동기 처리로 패치 처리를 하고 유즈 이펙트로 처리를 해주는 방식... 뭔가 잘 맞을까 싶다가도 일단 시간도 이해할 여력도 없기에 그냥 해 버렸다.. 후술하겠지만, 이때 짠 코드와 방식은 남의 코드를 베낀 거나 다름이 없기에.... 이해도 안 되었다.

const getToken = async () => {
    try {
      await fetch('https://kauth.kakao.com/oauth/token', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8',
        },
        body: qs.stringify({
          grant_type: 'authorization_code',
          client_id: restApiKey,
          redirect_uri: redirectUrl,
          code: code,
          client_secret: clientSecret,
        }),
      })
        .then(res => res.json())
        .then(data => console.log(data));
    } catch (err) {
      console.error(err);
    }
  };
  
  useEffect(() => {
    getToken();
  });

10) 본격 fetch 함수 삽질 2.

필자는 여유롭게 오~ 그 다음은 바로 백엔드에 이걸 전달하는 fetch 함수를 짜면 되겠구나 생각이 들었다. 그래서 결국 다음과 같은 코드를 짰다.

const sendToken = async () => {
    try {
      await fetch('${process.env.REACT_APP_SERVER_HOST}/user/login', {
        method: 'GET',
        headers: { Authorization: tokenData },
      })
        .then(res => res.json())
        .then(data => localStorage.setItem('access_token', data.access_token))
        .then(navigate('/win'));
    } catch (err) {
      console.error(err);
    }
  };

  useEffect(() => {
    getToken();
    if (tokenData) {
      sendToken();
    }
  });

이렇게 해서 잘 되겠지하고, 백엔드 종민님과 테스트 진행을 해 봤다. 그런데 이게 웬걸....

일단, 화면도 우리 로그인 후 리스트 화면으로 넘어가지 않았고, 토큰 역시 들어오질 않았다. 확인해 보니... 일단 카카오 측에서 토큰 조차 받아지지 않았다. 그래서 여기서 다시 또 막힌 필자는 백엔드의 태영님께 다시 자문을 구했다.

11) 그의 조언.

그는 내게 본인도 카카오를 안 해봐서 잘은 모르지만, 이렇게 하면 당연히 안 될 것이라고 했다.

일단 필자의 과오는 다음과 같았다.

1. 토큰을 받아오고 보내주는 함수들을 그냥 너무 이해 없이 막 썼다.
2. 현재 로그인 페이지에서 카카오에서 보내주는 페이지로 넘어간 것인데, 이 패치 함수가 로그인 페이지 코드에서 작성되었다.
3. 따라서 이 페이지를 따로 만들어 주고 거기서 처리해 주면 될 것이다.
4. 현재 비동기처리로 해 준 것의 코드 자체에도 문제가 있다. 이렇게 코드를 처리하면 비동기 처리가 제대로 되지 않는다.
5. 왜냐하면, 현재 우리 사이트의 경우에는 소셜로그인만 있는 것이 아닌, 일반 로그인까지 함께 사용하고 있기 때문에 저렇게 하면 일반 로그인도 작동을 안 하게 되기에....

그랬다. 결론적으로 종합하자면 필자가 들고온 저 코드는 완전히 우리 사이트와는 맞지 않은 단지 패치만 썼을 뿐.... 역시나 남의 것을 그대로 들고오는 행위는 잘못됨을 다시 깨달았다. 사실 저 코드를 쓰고 테스트를 해보니 잘되던 일반 로그인까지 말썽이기 시작했다.

12) 페이지의 분리.

먼저, 코드를 분리시키기로 결정했다. 위의 내용대로 일반로그인까지 있는 시점에서 저렇게 리다이렉트 된 카카오는 따로 관리해 주는 것이 맞다는 판단에서였다.

그래서 필자는

이처럼 새로운 파일을 만들었고, 그에 따라 라우터도 추가로 설정해 줬다. 라우터 추가는 왜 해줄까? 라고 생각했을 때, 당연히 그렇게 하는 것이 맞다. 왜냐면, 카카오 uri 주소에서 봤을 때, 우리팀이 설정한 리다이렉트 uri가 user/kakao 였기때문이다. 즉, 리다이렉트 uri 상 패스 파라미터에 따라서 저 컴포넌트가 실행되면서 인증을하고 바로 넘겨주는 것이 논리상 맞았다.

13) 코드 재작성.

이제 코드 역시 완전히 새로 짰다. 물론 아까 코드에서 힌트는 좀 받았다. 필자는 비동기로 쓸 필요는 없었고, 그냥 패치끼리 하나로 연결만 하면 되었다. 그 핵심적인 코드가 바로 .then이었다. 이때 백엔드 태영님께 굉장히 도움을 많이 받았다. 사실상 이때 fetch함수에 대한 처리 공부를 정말 실전적으로 많이 한 것 같다. 그래서 아래처럼 코드가 하나로 간단하게 작성된 것을 볼 수 있다.

위에 패치는 카카오 서버에서 토큰을 받아오는 패치이고, 이후에 코드는 전달받은 것을 제이슨 객체에 담아서 우리 백엔드에 전달만 하면 되었기에 then으로 패치를 처리하면 끝이었다. 그리고 이후에 인증이 되면 우리 토큰으로 바꿔서 세션 스토리지에 저장해 주고, 바로 유즈네비게이트로 리스트 페이지로 이동하는 방식이다.

이렇게 작성하니 진짜 이해를 하고 친 내 코드라는 생각과 함께, 우리 사이트에는 이 방식이 더 적합함을 느꼈다. 물론 로그인도 잘 되긴했다. 이후에도 물론 백엔드 단에서 바뀐 코드로 버그가 있던 적도 있긴 하지만, 크게 무리 없이 로그인은 잘 작동했다.

14) 성찰.

이번 소셜 로그인을 통해서 정말 많은 것들을 배웠던 것 같다. 일단, 가장 큰 것은 남의 코드 함부로 배낀다고 내 것이 되지 않는 것이다.

왜냐면 그것은 진정으로 내가 완벽히 이해해서 작성한 코드도 아닐 뿐더러, 지금과 같이 상황이나 조건에 맞지 않다면 말짱 도루묵이기 때문이다. 따라서 이렇게 앞으로도 어떤 기술을 조급하게 빨리 얻으려는 안일함을 절대 가지지 않아야겠다는 생각과 더불어 코드의 원리를 알고 적는 것의 중요성을 다시 한 번 다짐하게 되었다.

🤔 2. 이번 프로젝트에 대한 성찰 point.

이번 프로젝트는 지난 프로젝트에서 아쉬웠던 부분을 최대한 보완하고자 노력했다. 물론 그럼에도 불구하고 아직은 아쉬운 점들도 있었다.

👍 1) Good point!

1. 함께했던 모델링.

일단, 위얼네버댓 프로젝트에서 가장 아쉬웠던 점 중 하나로 생각했던, 모델링을 이번 프로젝트에서는 처음부터 모든 팀원이 함께 참여했다. 이를 통해, 우리 사이트의 전반적인 데이터 구조나 흐름, 체계 같은 것들을 알 수 있었다.

물론 이에 대해서는 의견이 좀 갈릴 수 있지만, 필자 개인적으로는 코드를 구현하는 것에 있어서도 더 도움이 되었다. 필자의 생각에 결국 모델링은 백과 프론트 모두가 알아야 한다고 생각한다. 모델링은 마치 건물의 골격을 하나, 둘 쌓아 올리는 과정이라고 볼 수 있다. 즉, 이러한 기본 골격에 어떤 재료가 들어가고 어떤 자리에 사용되는 지 알게 된다면, 작업자는 그 건물에 작업을 할 때 보다 이해가 쉬울 것이다. 왜냐면 그에 따라 다양한 특성과 상황을 고려해서 짤 수 있을 것이기 때문이다.

코딩도 다르지 않다고 생각한다. 프론트가 단순히 디자인적인 요소만을 감안해야 한다면 그렇다. 하지만, 좀 더 나아가 우리 사이트가 어떤 식으로 구조가 이루어지고 데이터는 어떻게 들어오고 있다는 것을 알면 어떨가? 그렇다면, 프론트 개발자가 백엔드 개발자와의 소통도 더 원활할 것이다. 더욱이 이번 프로젝트에서 백엔드 종민님과 태영님은 우리 프론트 측에 모델링을 하면서 이렇게 될 것 같다면서 의견을 물어봤고, 그에 따라 모델링도 계속 수정했다. 그리고 우리 팀 모두가 만족할 만한 모델링을 이른 시간에 합의할 수 있었다. 물론 이후, 코딩 과정에서도 서로에 대한 이해도와 만족도가 커진 것은 덤이다.

따라서 이번 프로젝트의 첫 번째 굿 포인트를 함께하는 모델링으로 꼽았다.

2. 새로운 기술들을 대하는 자세.

저번 프로젝트에서도 코린이(코딩어린이)인 필자는 수많은 새로운 기술들을 접했었다. 하지만, 사실상 이번에는 프론트에 더 집중하면서 특히, 더 많은 기술들을 딥하게 들어갔던 것 같다.

그래서 처음에는 "후~ 이거 어떻게 하나?ㅜㅜ" 이런 마음도 들었지만, 이후에는 오히려 기술들을 대하는 자세에 대해 배울 수 있는 좋은 기회였던 것 같다.

필자가 이번에 느낀 새로운 기술들을 대하는 자세는 대략 이렇다.

1. 처음보는 기술이라고 해서 쫄 필요는 전혀 없다.

누구나 처음 접하면, 새롭고 신기하고 전혀 이해가 안가는 코드다. 하지만, 실제 거기에서 쫄고 아무것도 안 한다면, 발전이 없다. 대표적인 예로, 필자의 방법이 아직 완벽하지는 않아도 masonry 레이아웃이 그랬다. 처음에는 쫄았지만, 계속 두드려보니, 별거 아니네? 이런 느낌이 들었다.

2. 처음부터 어렵게 할 필요는 없다.

쫄 필요 없다는 것과 이어지는 얘기인데, 우리가 그 기술이 어려운 이유는 바로 처음부터 무작정 우리가 사용하는 코드로 변환하려는 욕심때문이다. 다른 기술들도 다 마찬가지였지만, 필자는 이번에 마주한 신 기술들은 아주 기초적인 예제부터 시작했다. 즉, 따로 연습용 폴더에 샘플 예제부터 하나 씩 해결했다. 그리고 나서 원리가 이해되면 우리 코드로 점차 바꿔나가기 시작했다.

3. 조급함과 욕심을 조금 거두는 것도 현명하다.

지금 당장. 이 기술이 멋있는 것 같고, 남들 다 쓰니까, 최신 기술이니까 등등. 이런 저런 이유로 신 기술을 쓸 수는 있다. 하지만,해당 기술을 대하는 자신이 받아들일 준비가 제대로 되지 않은 시점에 그 기술을 쓰는 것은 무리가 된다.

이 격언처럼. 우리는 그 기술을 안다고 쓰는 것이 아니라, 기술에 대한 무게를 견뎌내야 한다고 생각한다. 만약 본인이 쓴 기술이 갑자기 버그를 일으켰는데, 기술의 원리 조차 잘 알지 못한다면 어떻게 하겠는가? 벌써 앞이 깜깜해진다. 그래서 필자가 저번에 무한스크롤을 구현하지 못한 것도 이러한 이유와 일맥 상통한다.

3. 코드를 검증하는 자세.

언젠가 하루는 백엔드 태영님께서 한 번 이렇게 의견을 낸 적이 있었다.

우리가 저번 프로젝트때는 사실상 너무 막 했던 것 같아요. 코드 완성되자마자 그게 되는 줄도 모르면서 그냥 막 붙이려고 하다보니, 시간도 많이 걸린 것 같고.. 그래서 차라리 프론트도 나름대로 코드가 제대로 작동하는 지 검증하고 해 보면 더 좋을 것 같아요.

그랬다. 어떤 코드이건 간에, 코드에 대한 검증을 본인 스스로 해 보는 것이 필요하다.

이 세상에 완벽한 코드는 없다.

아무리 자신이 애지중지 아끼던 코드라도 막상 실행이 안 되면, 말짱 도루묵이다. 그래서 일단 개발자는 자신의 코드가 실제로 실행이 되는 지 일차적인 검증이 필요하다. 이번 프로젝트에서 필자는 그래서 백엔드와 붙여보기 이전에, 따로 unsplash developer에서 무료 api를 통해 기본적인 테스트를 진행했다. 물론 백엔드와 통신 시에 일부 코드는 데이터 구조에 따라 변경을 하긴 해야했지만, 기본적인 부분에서 큰 문제가 나타나지는 않았다. 그래서 이런 자신의 코드에 대한 검증 절차는 프론트, 백 모두 필요하다라는 것을 실감했다.

4. 무지성 식의 어프로브 지양.

이번 프로젝트에서는 그래도 저번에는 아예 피어 코드리뷰가 없었던 것에 반해, 피어 코드 리뷰를 일정 정도 할 수는 있었다. 특히 첫 프로젝트에서는 무지성으로 그냥 시간에 쫓겨 무지성식 어프로브를 해주긴만 했던 것에 비하면 큰 발전인 것 같다.

무지성 식 어프로브를 지양하다 보니, 상대방의 코드를 보면서 배울 점도 익힐 수 있었다. 반면에 내가 보지 못 한 내 코드의 문제점을 겸허히 수용할 수 있는 좋은 시간이었다.

따라서 앞으로도 현업에 가서도 이렇게 코드 리뷰를 가지는 시간을 가질 수 있는 것은 꼭 필요하다고 생각한다.

5. 상황에 따른 역할 분담.

이번 팀을 통해 상황에 따른 적절한 역할 분담이 이런 것이구나라는 것을 참 많이 느꼈다.

팀으로서 어떤 일을 함께 할 때, 각자가 맡은 일이나 상황에 따라 팀 전체의 진행도는 더딜 수도 빠를 수도 있다. 이번 팀 프로젝트에서 필자와 백엔드 종민님은 생각보다 발표날 본인들의 구현 부분이 끝난상태였다. 물론 우리들도 역시 그날 밤새면서 겨우 끝내긴 했지만... ㅋㅋ

그래서 필자는 이를 통해 우리 두 사람은 발표 준비를 맡는 것이 더 좋겠다는 생각이 들었고, 때마침 백엔드 태영님도 그렇게 제안을 해 왔다. 그에 따라 우리는 발표 준비를 했고, 나머지 두 사람은 남은 여분의 일과 사이트 추가 버그 점검을 맡았었다. 이를 통해 우리 팀은 자원의 효율적 배분을 정말 잘 한 것 같았다.

😭 2) Bad point!

1. 그래도 여전히 아쉬운 코드 리뷰...

일전에 좋았던 점으로 무지성 어프로브를 지양했다고 언급했다. 하지만, 백프로 만족할 수는 없었다. 그건 아마도 우리가 아직 초보이기에 그럴 수도 있지만...

후반기에 갈수록 빠듯한 시간 탓에 완벽한 코드 리뷰를 할 수가 없었다. 그래서 이후에는 코드리뷰보다는 승인하기 바빴던 것 같다. 그래서 뒷 부분은 무지성식 어프로브가 많았어서 딱 이번에는 저번보다는 조금 나아졌던 것 같다. 물론 이후에는 이런 간극을 점점 좁혀 나갈 수 있도록 계속 노력하는 것으로 남겨두고, 또 이후에 진행될 리팩토링 기간에 다시 코드 피어 리뷰를 해야겠다.

2. 페이스 완급 조절의 아쉬움.

사실 저번 프로젝트에 비해 초기 설정이나 여러 부분에서 페이스 완급 조절이 굉장히 성공적이었다고 생각했다. 하지만, 막상 프로젝트가 진행되면서, 점점 페이스 완급 조절이 제대로 되지 않았다고 생각한다.

이번에는 웬지 모르게 특히 체력적으로 굉장히 힘들었다. 평소 필자는 주5일 1시간 이상 운동을 해 왔던 것에도 불구하고, 정말 끝에 갈수록 잠도 못 자는 경우가 많아지다보니... 힘에 부쳤다. 멘토분들이 뒤로 갈수록 체력 관리도 신경써야 한다고 하신 말씀이 정말 많이 와 닿았다. 그냥 앉아서 타이핑만 하는데, 무슨 체력이 얼마나 소모되겠어 했던, 나 자신을 반성하게 되었다.

프로젝트를 하면서, 단순히 코딩만 하는 것이 아니기에... 끊임없는 회의, 논의, 구상 등등 '정신적인 체력'을 관리하는 것도 중요했다. 프로젝트가 끝날 때 쯤에는 머리가 쥐가 나기 시작했던 것을 생각해 보면. 이번 프로젝트가 지난 위얼네버댓에 비해 육체적인 체력을 넘어 얼마나 정신적인 체력 관리가 필요했는 지도 엿 볼 수 있었다.

3. 큰 그림을 그리지 못 한 코딩.

이번 프로젝트에서 검증 절차를 통해 코드를 검증했다고 하지만, 사실 곳곳에서 디버깅을 할 것들이 폭탄처럼 밀려들어 왔다. 대표적으로 무한 스크롤이 대표적으로 그랬던 것 같다. 발표날까지도 말썽을 부리면서... 엄청나게 머리가 아팠다.

하지만, 이걸 다시 되 짚어보면, 큰 그림을 그리지 못하고 코딩을 한 필자의 코딩 실력에 있었다고 생각한다. 사실 우리가 모델링을 할 때, 분명 서칭 기능이 들어간다고 했기에, 그에 맞춰서 코딩을 했다면 어땠을까 아쉬움이 남는다. 또, 필자가 충분히 검증 단계에서 디버깅을 했다면, 추가적인 버그들도 미연에 방지할 수 있었겠다는 생각이 계속 들었다.

결론적으로 이제는 코딩을 막상 하기 전에 고려해야할 요소를 최대한 적어두고 그에 맞춰 중간 중간 체크해 볼 수 있도록 해야겠다는 깨달음을 얻었다.

4. 콘텍스트 api & 스타일 컴포넌트에 대한 미숙함.

이번 프로젝트부터 콘텍스트 api와 스타일 컴포넌트를 적용하라고 배웠다. 하지만, 막상 코딩을 하다보니 그것이 쉽지는 않았다. 일단 두 가지 모두 다 아직 완벽한 숙지가 이루어지지 않은 탓 인지... 적용을 하기 어려웠다. 일단 스타일 컴포넌트는 기본적인 것들에는 적용하긴 했다. 하지만, 아직 삼항 연산자나 복잡한 구조의 css에는 적용할 수 없었다. 그래서 아직 모달창은 css를 적용한 상태다. 물론 그에 따라 클래스명 겹침으로 인한 스타일 적용 오류 등을 맞이하면서, 스타일 컴포넌트 적용의 필요성을 다시 느꼈다.

콘텍스트는 전역 상태 관리라서 이번에 확실히 써보고 싶었지만, 아직 공부가 부족한 탓에 아예 적용을 못 시켰다. 하지만, 분명한 것은 무조건 써야 되겠다는 것을 느꼈다. 대표적으로 모달 창에 수많은 프롭스를 전달하면서, 엄청난 전달의 전달의 전달을 하는 등. 무한한 귀찮음과 비 효율성을 감지했다. 확실히 사람은 필요성을 느껴야 배움을 더 느끼는 것 같다. ㅎㅎ

이렇게 이번에는 비록 해당 기술들을 아쉽게도 적용하지 못했다. 그렇지만, 필요성을 느낀 프로젝트였기에 빠르면 이번 리팩토링 기간에는 한 번 다시 적용해 보겠다.

5. 섣부른 조급함.

필자 스스로 프로젝트를 하면서 느끼기에 성격이 굉장히 급한 것 같다. 어떤 결과물이 빨리 나오지 않으면, 조급함을 많이 느꼈다. 그러다 보니. 이로 인해 카카오 소셜 로그인을 하면서 다른 사람의 코드를 바로 적용해 보려고도 했다. 하지만 결국 코드를 싹 바꾸고 원리를 익히자 코드가 실행되는 것을 보면서 다시 한 번 느꼈다.

내가 무조건 조급하다고 이해도 없이 사용하는 무지성은 역시 피해야겠다고...

이제 앞으로는 조급함보다는 이 말씀처럼

조급함보다는 꾸준함이 더 중요하다는 덕목을 가지고 개발자로서 살아가야겠다.

🎉 3. 총평 및 마무리 소감.

후~ 드디어 총평까지 왔다. 정말 글이 장황해 진 것 같아 죄송하다. 사실 처음에는 1부 혹은 2부에서 마무리 하려고 했다. 하지만, 글 주변이 없어서 그런지... 굉장히 길어졌다.

무튼 이렇게 3개월을 마무리하는 마지막 프로젝트까지 끝낸 소감을 물어보신다면, 여태 잘 버텨냈고 앞으로도 잘 버텨내기 위한 발판을 마련한 것 같다. 정말 짧은 시간이지만, 그 사이에 기술적인 성장도 했지만 그 만큼 다양한 것들 배운 기회였다. 사실 이런 모든 경험은 우리 팀원들이 없었다면 할 수 없었을 것 같다. 끝으로 정말 고생했고, 수고했습니다. 우리 윈터레스트 팀원분들 감사합니다.

발표 3일 전 함께 위워크에 모인 우리 팀원들의 모습을 끝으로 마친다~