나의 첫 프로젝트 SAFE-T 에 대한 회고

⭐처음으로 정말 제대로 된 프로젝트를 수행해보다.⭐

저는 이번년도 3월 멋쟁이사자처럼 at 인하대학교 동아리를 들어가고 난 이후로, 매주 세션을 하며 프론트엔드에 관한 기본적인 문법 및 간단한 클론코딩, 나만의 자기소개 페이지 제작 등 여러 활동을 하며 한학기를 보냈습니다.
그러고 나서 대망의 여름방학! 여름방학에는 멋쟁이사자처럼 동아리원들끼리 학교내에서 시행하는 인하대 해커톤과, 멋쟁이사자처럼 12기 전체가 시행하는 중앙해커톤이 준비되어 있었습니다.
그전까지는 마땅한 해커톤 및 프로젝트를 한번도 해보지 못한 저는 저의 첫 해커톤에서 많은 부족함과 노력이 필요하다라는것을 절실하게 느끼게 됩니다,,, (운이 좋게도 인하대 해커톤에서 같이 한 팀원들끼리 잘 맞고 분위기도 좋아서 후에 있는 중앙해커톤까지 쭉 같이하게 됩니다 => 2달동안 거의 하루도 안빼놓고 매일 만나게 될지는 몰랐던 미래의 우리들)

이번 해커톤의 주제는 자유주제였어서 팀원들끼리 어떤 기획으로 개발을 할지 의견을 수립하였고, 장애인을 위한 심부름 앱, 내 근처 심야 약국 지도, 필라테스 정보 공유 커뮤니티, 중고물품 거래 플랫폼 등 다양한 의견이 나왔지만 제가 의견을 냈던 택시를 부르기 어려워하는 취약계층을 위해 좀 더 수월하고 간편하게 택시를 호출할수 있는 기능 제공할수 있는 서비스를 개발하기로 하였습니다!

💁‍♂️ 아이디어 설명

취약계층을 위한 택시 호출 서비스

목표: 택시를 부르기 어려워하는 취약계층을 위해 수월하고 간편하게 택시를 호출할수 있는 기능 제공
서비스 제공 대상 구체화 : 스마트 서비스 사용에 어려움을 겪는 노인, 지적 장애인

대략적인 기능 구현:
1. 복지관,병원,구청 등 취약계층들이 자주 가는곳에 QR 코드 설치 후 핸드폰의 QR코드를 스캔하면 바로 택시를 호출할수 있도록 함.
2. 택시 호출에 어려움을 느끼는 분들을 위해 앱에 여러 자원봉사자들을 등록하고, 취약계층이 도움을 요청하면 등록된 자원봉사자들한테 알람이 가서 가까운 위치에 있는 봉사자들이 도와줄수 있도록 구현.
3. 취약계층이 택시를 탔을 때, 비상상황에 대비하여 등록되어 있는 가족들이나 그때그때 자원봉사자를 매칭하여 실시간 위치 및 택시 번호를 공유 받을수 있도록 함.
4. 회원가입이나 로그인은 최대한 간단하게 진행될수 있도록 하고 (Face ID, 지문인식, 전화번호 등록)
5. 핸드폰에도 바로 호출을 할수있도록 간단한 버튼으로 호출 구현
6. 택시가 이런 취약계층을 탑승자로 받았을 때 호출을 수락/거절 할수 있도록 하고, 호출을 요청하면 택시의 실시간 위치와 번호가 공유될수 있음을 동의받음.
7. 취약계층을 일정인원 이상으로 태웠을 때 승객들이나 회사에서 알수 있도록 취약계층 탑승 수락에 대한 횟수가 데이터로 남으면 더 좋을거같음. (택시에 이것을 알릴수 있는 표식이나 훈장 등으로 소정의 이익이 발생할수 있기 때문)

이후에 얘기가 나오겠지만 장황한 설명에 비해 시간이 부족하여 구현을 못한 부분도 있습니다 ㅎㅎ,,

이렇게 대략적인 아이디어와 기능을 만들어놓고 저희는 다같이 피그마로 플로우차트와 와이어프레임을 만들기로 합니다. (피그마를 처음 사용해봐서 서툴었지만 이때 강의도 찾아보고 시간을 투자하여 이제는 어느정도 혼자 디자인을 할수 있는 정도로 성장하였습니다.)

👻 피그마로 구현한 프로토타입

피그마로 기능들과 페이지들의 디자인을 하고 난 뒤에 본격적으로 개발에 들어서게 되는데 이때의 저는 백엔드와의 협업으로 서비스를 배포하는 경험이 처음이고, 항상 혼자서만 페이지를 만들었지 누군가와 함께 소통을 하며 다같이 페이지를 만든 경험도 처음, 그리고 단순히 페이지 틀만 만드는거에 집중했지 실제 API 호출을 통하여 페이지에 원하는 지도와 경로 등을 띄우는것, 회원가입과 로그인을 할때 Access Token 발급을 통하여 내가 회원가입 한 아이디 비밀번호가 토큰을 발급받아 로그인을 할수 있도록 해야하는 점 등 그저 한낱 페이지 껍데기만 만들줄 아는 부족한 점 투성이였습니다.

우선 프론트엔드에서 첫 개발을 할때 가장 중요했던 점은 어떻게 폴더 아키텍처 구조를 잘 짜느냐가 중요했던것 같습니다.
프로젝트를 하기 전에는 폴더의 기본 구조를 어떻게 잘 짜야될까를 고민하기 보단 그냥 막무가내로 내가 이름 짓고싶은대로 지어야지, 나만 알아보면 되니깐 굳이 신경 안써도 되겠다 라며 대수롭지 않게 이 부분에 대해서 넘어갔던 저였지만, 이때 처음으로 폴더 구조도 어떤식으로 하는게 좋은지가 존재한다는것을 알았습니다. (특히 협업을 진행할때 폴더 구조를 잘 짜는것은 너무너무 중요!!)

위에 있는 폴더 구조를 참고하여 직접 만든 프로젝트의 폴더 구조

폴더를 구성하고 난 뒤에는 나 혼자 만드는것이 아닌 여러 팀원들과 함께 협업을 하는것이니 각각 수행한 작업들에 대해서 push 할때 충돌이 나지않도록 신경쓰고 (후에 각자 했던 작업들의 충돌은 정말 많은 문제와 시간을 소모시켰습니다,,,) 어떤 작업을 수행하고 난 뒤에는 내가 한 작업에 대해서 다른 팀원들이 알아볼수 있게 해야했습니다.
그래서 저희 팀원들은 협업 규칙을 정하고, 이슈 템플릿을 통해 이번 프로젝트에서 수행해야 하는 작업들에 대해서 각각을 이슈로 만들어 처리해야하는 것들에 대해 작업 할 내용과 체크리스트를 통한 작업 진행 현황등을 모두가 알아볼수 있도록 하였고, 커밋 컨벤션을 통한 커밋유형, 이슈번호를 달아서 Visual Studio Code에서 Commit를 실행할때 해당 이슈번호로 이슈를 추적할수 있도록 해주었습니다. 또한 그 이슈들에 대해서 수행한 작업들에 대해서는 PR 템플릿을 통해 해당 이슈에 대한 작업 내용, 추가적인 리뷰 요구사항등을 시행하여 어떤 부분에 대해서 자기가 무엇을 수행했고, 어떤 부분을 더 참고하고 수정하면 좋을지에 대해 적으며 협업을 해나갔습니다.

협업을 위한 git 커밋컨벤션 설정하기 => 커밋컨벤션 설정은 해당 페이지를 참고하였습니다.

🔎 협업때 사용한 Issue 템플릿과 PR 템플릿

하지만 이때 저희는 한가지 실수를 하게 되었는데, 모두가 다 main 브랜치에서 작업을 수행하며, 각자 작업이 끝나면 해당 이슈에 대한 PR를 남겼는데, 이러한 행동은 각자 작업환경이 모두 다른 서로한테 매번 바뀌는 main 브랜치는 빈번하게 서로의 작업환경에서 충돌을 일으키는 경우가 많았습니다.
이때는 브랜치에 대한 개념이 잘 잡혀있지않아서 main 브랜치에서 모든것을 수행하였는데, 이때 이러한 충돌들로 고생을 많이해서 다음 프로젝트에서는 서로의 충돌을 최대한 막기위해서 main 브랜치가 아닌 수행하는 페이지,컴포넌트에 대한 브랜치를 생성하여 충돌을 막고, 확실할때 이것을 push후 merge 해야하는 상황에서만 main 브랜치로 merge를 수행하게 되는 좋은 경험이 되었던것 같습니다.

💻 본격적인 개발에 대한 얘기

이번 프로젝트에서 구현해야하는것의 핵심은 회원가입과 로그인 부분, 내가 있는 위치에서 나의 현재 위치와 그 위치에 대한 지도를 띄우고 내가 원하는 목적지에 대한 경로 생성, 긴급호출 버튼을 누르면 보호자에게 연락이 가도록 설정 이였던것 같습니다.

로그인,회원가입 부분은 로그인창에서 회원가입 글씨는 누르면 회원가입 페이지로 넘어갈수 있도록 라우팅을 설정하고,
이때 회원가입이 성공이 되려면 사용자가 작성한 정보에 대해 그 정보를 저장하고 관리할수 있어야하는데, useForm 을 통해 회원가입에서 입력해야 하는 데이터를 관리하고 초깃값을 설정해줬습니다.
저희는 우선 apis 폴더에 authApi.js로 코드를 따로 적어서 인증 관련 API 요청을 쉽게 처리할 수 있도록 설정하였습니다. 이때 회원가입에 대한 인증 토큰을 발급받을수 있게 하기 위해서 토큰 인터셉터 설정을 통해

authApi.interceptors.request.use(
  (config) => {
    const token = localStorage.getItem("token"); // 로컬 스토리지에서 토큰 가져오기
    if (token) {
      config.headers.Authorization = `Bearer ${token}`; // Authorization 헤더에 토큰 추가
    }
    return config;
  },
  (error) => Promise.reject(error)
);

이때 회원가입에 대한 인증 토큰을 발급받을수 있게 하기 위해서 토큰 인터셉터 설정을
localStorage.getItem("token")을 통해 브라우저의 로컬 스토리지에서 token을 가져옵니다. 이 토큰은 사용자가 로그인할 때 서버로부터 받은 Access Token입니다.
이렇게 authApi.js의 인증 토큰 방식에 대한 코드를 통해서 로그인,회원가입 부분에서 authApi 인스턴스를 통해 이루어지는 모든 요청은 자동으로 인증 토큰을 포함할수 있도록 하였습니다.

실제로 회원가입 페이지에서 authApi.js에서 포함시킨 인증 토큰을 요청하고, 제대로 발급이 되면

 try {
    const response = await authApi.post("/signup", finalData);
    if (response.status === 200 || response.status === 201) {
      alert("회원가입이 완료되었습니다.");
      navigate("/login");
    } else {
      alert("회원가입에 실패했습니다.");
    }
  } catch (error) {
    if (error.response && error.response.data) {
      const { errors } = error.response.data;
      setError(errors || { general: "회원가입에 실패했습니다." });
    } else {
      setError({
        general:
          "서버와의 통신에 실패했습니다. 네트워크 연결을 확인해주세요.",
      });
    }
  }
};

authApi 인스턴스를 사용해 POST 요청을 /signup 엔드포인트로 보내고,
이 요청에는 finalData가 JSON 형식으로 포함됩니다.
만약 사용자가 이미 로그인된 상태라면, interceptors.request.use에 의해 Authorization 헤더에 Bearer 형식의 토큰이 자동으로 추가됩니다.

이때 토큰은 중요한 역할을 하게 되는데, 서버는 이 토큰을 통해 요청한 사용자가 인증된 사용자임을 확인할 수 있습니다. 예를 들어, 특정한 API에서는 사용자가 인증되어 있어야만 회원가입이 가능한 경우, 이 토큰이 반드시 필요합니다.(토큰이 없다면 서버에서 요청을 거부할수 있음)
이러한 응답처리를 통해 서버가 요청을 성공적으로 수행하면 (요청 응답 200 or 201)

HTTPS 응답 상태 코드에 관한 설명 => REST API 관점에서 바라보는 HTTP 상태 코드(HTTP status code)
출처: https://sanghaklee.tistory.com/61 [이상학의 개발블로그:티스토리]

사용자는 "회원가입이 완료되었습니다."라는 알림을 받고, 로그인 페이지로 리디렉션될수 있도록 설정하고, 회원가입 페이지에서 발급받은 인증 토큰으로 로그인이 가능하도록 각각의 페이지를 구성하였습니다.

프로젝트에서 사용한 JWT 토큰 인증방식에 대한 자세한 설명은 -> JWT(Json Web Token) 인증방식

이렇게 로그인과 회원가입 부분의 핵심 기능을 구현하고 난 뒤에는 사용자의 현재 위치를 받아와서 지도에 표시 후에 목적지가 입력이 되면 해당 목적지까지의 경로를 표현하고 택시가 호출 되어 택시 번호, 기사 정보, 예상소요시간, 요금 등을 표시할수 있어야했습니다.
현재 위치를 받아와서 지도에 표시하고 경로를 띄우는 작업에는 카카오 API인 Kakao Developers를 사용하였고, 실제 택시 정보를 받아오는것은 불가능하다고 판단하여 백엔드에서 가짜 택시 정보 API를 만들어서 택시를 호출하면 사용자의 현재 위치에서 가장 가까운 3대의 택시 데이터를 받아올수 있게 하였습니다.

카카오 API 사용을 위한 코드

const kakaoApi = axios.create({
  baseURL: "https://dapi.kakao.com/v2/local",
  timeout: 5000,
  headers: {
    "Content-Type": "application/json",
    Authorization: `KakaoAK ${process.env.REACT_APP_KAKAO_REST_API_KEY}`,
  },
});

( 인가 부분은 카카오에서 직접 허용받은 API Key를 사용하였고, 보안상 .env 파일에 따로 보관)

또한 async/await 비동기 방식을 사용하여 확실한 API 호출이 되고 난 뒤에 함수가 실행되도록 설정하고 사용자가 입력한 주소를 값으로 설정하여 유효한 주소가 제공되면 Kakao 지도 API에 GET 요청을 보낸 후에 주소에 해당하는 좌표 데이터를 추출하여 반환하도록 하였습니다.

주소에 해당하는 좌표 데이터 추출 코드

export const getAddressToCoordinate = async (address) => {
  if (!address) {
    throw new Error("주소가 비어있습니다.");
  }
  try {
    const response = await kakaoApi.get("/search/address.json", {
      params: {
        query: address,
      },
    });
    console.log("getAddressToCoordinate response:", response.data);
    return response.data;
  } catch (error) {
    console.error("Error fetching coordinates from address:", error);
    throw error;
  }
};

이렇게 카카오 API를 이용하여 사용자의 위치를 지도에 띄우고, 목적지까지의 경로를 띄우는 작업을 수행하면 목적지까지 이동을 할수있고, 취약계층을 위한 택시 호출 서비스이기때문에 해당 서비스에는 항상 긴급호출 버튼이 존재합니다.
긴급호출 버튼을 클릭하게 되면 긴급호출 페이지로 이동하게 되고, 긴급호출을 원할시에는 미리 등록해 놓은 보호자의 이메일로 도움을 요청하는 이메일이 전송됩니다. 해당 호출에 대한 내용에는 취약계층이 보호자에게 도움을 요청한다는 메세지와 함께 현재 위치가 전송될수 있도록 설정하였습니다.

📧 실제 보호자 설정을 완료 하고 긴급호출 버튼을 눌렀을때 보호자에게 오는 이메일

긴급호출에 대한 부분은 백엔드에서 만든 API 명세서에 /sendmail 이라는 이름의 URL로 post를 하도록 설정하였으므로 프론트에서는 해당 긴급호출 부분을

export const sendEmail = async () => {
  try {
    const response = await authApi.get("/sendmail");

    // 응답 데이터 그대로 리턴
    return response.data;
  } catch (error) {
    // 에러 처리
    console.error("Error sending email:", error);
    return { status: "500", message: "이메일 전송 중 오류가 발생했습니다." };
  }
};

을 통하여 API get 호출로 처리하여 이메일을 받을수 있게 처리하였습니다.

🔦 기존 택시 호출 서비스와의 차이점

현재 택시를 호출하는 서비스는 많이 존재합니다. 이러한 택시 호출 서비스는 디지털 사용이 익숙한 세대한테는 편리한 서비스를 제공하고 앱 서비스로 인한 간편한 택시 호출이 가능하게 하였습니다. 하지만 저도 실제로 이런 택시 호출을 사용해봤지만 실제로 택시를 호출하는것까지의 과정이 생각보다 복잡해서 처음쓸때는 해맸던 기억이 있습니다. 또한 택시 호출 서비스만이 아닌 카풀, 렌터카, 기차, 항공 등 택시 특화 서비스라기보단 여러 교통수단들을 아우르는 서비스들이 많습니다.
복잡한 UI/UX에 더해서 택시 뿐 아니라 여러 교통수단이 추가된 택시 호출 서비스는 취약계층들에게는 서비스를 사용해보기도전에 진입장벽을 느끼게합니다.
지금의 우리나라는 장애인 및 노인 등 취약계층의 비율이 크게 증가하고 있고, 이들은 일반인에 비해 낮은 디지털 정보화 수준을 가지고 있습니다.

일반인과 취약계층의 디지털 정보격차

이런 상황속에서 저희 SAFE-T 는 누구나 쉽고 간편하게 택시 호출에 특화된 서비스를 제공하고, 다른 여러 택시 서비스가 앱 서비스만 제공하는것에 비해 저희는 반응형 웹/앱 서비스를 제공하려고 했습니다. 앱 뿐만 아니라 웹에서도 반응형으로 서비스가 제공이 된다면, 취약계층분들이 많이 이용하는 병원, 복지관 등의 장소에서도 간편하게 택시 호출이 될수 있다고 예상하였습니다.
또한 긴급호출 서비스를 통해 취약계층에게 가장 필요한 긴급상황에 대비하고, 호출 메인 페이지에 QR 호출하기를 통해서 복잡한 과정없이 택시를 호출하여 모든 사용자들이 쉽게 사용할수 있도록 하고, 특히 취약계층분들을 위해 해당분들이 많이 이용하는 병원, 복지관, 경로당, 택시 승강장에 실제 해당 서비스 QR코드가 존재하여 QR코드를 찍는것만으로도 택시 호출이 가능할수 있도록 하는 차별점을 두었습니다.

🤦‍♂️ 구현하지 못한 부분과 아쉬웠던 점들

개인적으로 간편 택시 호출 서비스 SAFE-T는 저에게 많은 부족함을 알려주고, 노력해야한다는 생각이 들게함과 동시에 팀원들과 협업을 하면 어찌해서라도 결과물이 나오고 그 결과물이 생각했던것보다 서툴었음에도 불구하고 나름의 만족할수 있는 결과를 도출했다는점에서 좋은 경험이 되었습니다. 좋았던 경험들과 기억들도 물론 좋지만, 부족했던 부분과 결국 완벽하게 구현하지못한 부분을 다시 한번 확실하게 짚고 넘어가야 나중에 더 보완한 좋은 결과물이 나올수 있다고 생각하기에 지금부터는 이번 프로젝트를 진행하면서 아쉬웠던점들과 실제 추가 구현을 제대로 했다면 더 좋았을 점들에 대해 얘기해보겠습니다.

1. 제대로 이해하지못하고 사용한 API 개념과 호출
이번 프로젝트를 진행하면서 개인적으로 가장 아쉬웠던 부분이였습니다.
백엔드와 소통하고 모든 작업을 실행하려면 API 호출은 정말 기본인데, 이름만 들어왔지 실제로는 개념도 잘 모르고 제대로 알지못하고 사용하여 정말 많이 헤맸던 부분이였습니다.
REST API 에서 CRUD에 대한 개념은 알고있었지만 한번도 사용을 해보지못했고, 이런 부분에서 저는 api 명세서도 잘 이해하지 못하고, Swagger에서 직접 API 호출을 한 작업들에 대해서 테스트도 제대로 못해보는 사람이였습니다. 처음으로 직접 코드를 짜며 API를 사용하는것은 제가 생각했던것보다 더 어려웠고, 정말 많은 에러들때문에 머리아팠던 기억이 아직도 생생합니다,,,ㅎㅎ
하지만 이때의 저는 API 관련 지식들이 정말 중요하다는걸 깨닫고 개인적으로도 많이 공부하고 이해하려고 노력할수 있는 계기를 만들어줬습니다.
async/await 비동기 방식과 Try catch 방식, API 명세서에 존재하는 기능에 따라 나눠진 세부 URL을 제대로 사용하지 못하면 발생하는 에러들, Input에 넣어야하는 정보를 확실하게 넣으면 제대로 나오는 Output등 API 관련 부분은 매우 중요하고 아직까지도 꾸준하게 공부해서 능숙하게 다룰수 있도록 해야한다는것을 확실하게 느꼈습니다.

2. 토큰 인증 방식과 세션, 쿠키, 토큰의 차이점 등에 관한 개념의 부재
요즘 모든 서비스들에는 로그인을 해야 모든 서비스를 이용할수 있습니다. 이런 로그인 페이지를 제대로 구현하려면 로그인을 했을때 사용자가 로그인을 했다는것을 인지하고, 해당 로그인 정보를 저장할수 있는 인증, 인가 방식은 필수적입니다.
이렇게 로그인에 관한 정보를 저장하고 인증을 통해 사용권한을 부여할수 있도록 해주는 방식에는 쿠키,세션,토큰 등이 존재하는데 프로젝트를 진행할 당시에는 해당 개념들의 정확한 이해와, 각각의 장단점, 방식의 차이점 등 모르는것이 많은채로 프로젝트를 진행했습니다.
이러한 개념들을 모르는 상태로 코드를 짜고 개발을 진행하다보니 결국 이러한 토큰 발급은 정확히 어떤식으로 진행되는것인지, 어디서 토큰을 볼수있는지, 토큰의 유효기간이 다 지나면 어떻게 해야하는지 같은 기본적인 것들도 놓치는 부분이 많았는데, 이번 프로젝트를 계기로 이러한 개념을 확실하게 다지고 갈수있게 된 계기가 되었습니다.

3. 사용자의 현재 위치를 받아오려고 했지만 실패하여 결국 한 지점의 좌표로 고정하여 개발을 진행했던점
저희의 프로젝트에서 가장 중요했던 기능은 사용자가 택시를 호출하는 곳에서 그 호출하는 곳의 현재 위치를 카카오 API를 이용해서 지도형식의 위치를 띄우고, 현재 위치에서 목적지까지의 거리를 택시로 가는 경로 요금등과 함께 화면에 나타낼수 있어야하는것이였습니다.
하지만 코드를 짜고 수정하면서 GPS를 기반으로 하여 내가 있는 현재 위치에 대한 정보를 받아서 지도에서 띄우려고 했지만, 이때의 결과는 현재 위치에 대한 위치 오차가 너무 크게 나왔었습니다. (인천에서 현 위치를 받아오려고 했지만, 미국(?) 으로 위치가 받아짐,,,,,)
여러 시도를 했으나 도저히 오차를 감안해도 너무 위치의 차이가 커서 결국 학교로 위치를 고정시켜 개발을 진행했었습니다.
이렇게 학교로 위치를 고정시켜 어떤 목적지를 입력해도 거기에 따른 위치 경로를 나타내고 택시 정보를 나타내는건 성공하였지만, 실제 사용자들의 위치를 기반으로 어느곳에서 SAFE-T 서비스를 이용해도 정확한 위치와 함께 목적지에 따른 경로를 나타낼수 있었다면 어땠을까라는 아쉬움이 남았습니다.
이때 왜 현재 위치에 대한 정보를 정확하게 나타내지못했을까 생각을 해보면 Navigator.Geolocation API를 통해 사용자의 현재 위치 좌표를 얻었어야 했는데, 이 작업을 제대로 수행하지 못했기 때문이라고 예상 할수 있습니다.

4. HTTPS 응답 상태에 따른 에러가 발생했을때 에러를 처리할때의 미숙함과 그에 따른 많은 시간 소요
이번에 백엔드와의 소통 및 API 사용에 따라서 또 다른 난관이 정말 많이 발생했던것이 HTTPS에서 발생한 여러 콘솔에 찍힌 에러들과 네트워크 에러들이였습니다. 특히 이때의 저는 콘솔에 빨간색 글씨만 나와도 두려워하면서 확실하게 처리를 못하여 허둥지둥대는 경향이 많았는데, 이때 HTTP 응답 상태 코드의 다른 번호들로 인한 각각의 에러가 어떤에러인지 확실하게 알지 못해서 그랬던것 같습니다. 만약 제가 이때 400번대의 에러에서는 제가 코드를 수정하고, 500번대 에러에서는 백엔드와의 소통을 다시 한번 하는걸 빠르게 숙지했다면 이 부분에서 시간 단축을 많이 할수 있었을것이라고 생각합니다. (프로젝트를 하면서 느끼는 거지만 400번대와 500번대의 에러는 수정하거나 아예 새로짜도 정말 자주 뜨는 에러들이고, 생각보다 고치기 까다로운것들도 많기때문에, 너무 조급하게 생각하지말고 천천히 에러가 뜰만한 코드를 수정하면서 고치는게 제일 좋다고 생각이 듭니다.)

5. 모든 팀원들이 main 브랜치 사용으로 인한 협업시 발생했던 충돌들
저는 프로젝트가 처음이였고, Git과 Github도 제대로 배운건 동아리에 와서 처음이기에 다른 팀원들과의 협업에 대해서 많은생각을 하기보다는 그냥 내가 맡은 부분이나 코드에 대해서 그것만 잘 짜면 되지않을까라는 생각을 하였습니다. 그치만 이런 생각은 정말 잘못된 생각이였고, 프로젝트에서의 협업은 가독성이 좋고 간결한 코드보다도 더 중요한것임을 깨닫게 되었습니다.
이때의 프로젝트에서도 협업을 위해 자신이 해야하는 부분이나 내가 작업한 내용에 대해서 팀원들이 내가 어떤 부분을 수정했고, 어떤걸 해야하는지 Issue 템플릿과 PR 템플릿으로 협업하고자 하였고, 이 부분에 있어서는 생각보다 좋은 협업 방식이였다고 생각합니다.
하지만 가장 큰 문제는 모든 작업들을 main 브랜치에서 수행한것이였습니다. 모든 팀원들이 어떤 부분을 수정하고, 새로운 페이지를 만들때 각자의 작업환경에서 main 브랜치를 통해서 작업을 진행했는데, 이 부분에 있어서 각자 수행한 작업에 대해 상의도 없이 merge를 하게됐을때, 내가 팀원들이 했던 내용에 대해서 그 부분을 Sink Fork를 하고 다시 push를 하게되면, 수많은 충돌을 경험했습니다.
이 부분은 팀원들이 수시로 대화를 하면서 어떤 부분에 대한 수정과 추가를 알게해야하는데 사소하게라도 작업을 진행하다 같은 페이지를 수정하게 되거나, 전에 없던 새로운 페이지를 만들게 되면 이것은 곧 무수한 충돌들로 이어졌습니다. 또한 이런 충돌들에 대해서 다시 고쳐보려고 하니 다같은 main 브랜치에서 작업을 진행했기에, 수정하는 부분에 있어서도 많은 시간과 노력을 했습니다.
이러한 경험들로 인해 프로젝트가 간단하지않고 모두가 함께하는 작업에는 main 브랜치로의 push는 신중하게 해야한다는것을 깨달았고, 각자의 브랜치에서 새로운 브랜치를 생성하고, 작업을 완료하면 팀원들과 이 작업에 대해 상의를 충분히 하고나서 main으로 merge하는 변화가 생겼고, 수많은 git 명령어들과 사용법에 대해 꾸준한 공부가 필요하다는것을 많이 느끼게 되었습니다.

💎 마무리 💎

이번 프로젝트를 하면서 밤도 많이 새보고, 팀원들과 수많은 만남과 대화를 통해 협업능력도 기르며, 어떻게 하면 수많은 에러들을 해결해서 좋은 결과물이 나올수 있을까라는 고민들도 많이 하면서 개발 실력을 키울수 있는 좋은 계기가 되었습니다.
혼자서 공부하고 영상을 보며 코드를 따라치는것도 나중에 도움이 되겠지만, 이렇게 사람들과 다같이 어떤 목표를 세우고 그것에 대해 직접 부딪혀보고 힘들어하면서 원하는 작업을 끝내는것은 그 어떤 공부보다 개발 실력을 늘릴수 있었습니다.
앞으로도 내가 원하는것을 직접 만들어보고 아무것도 없는 백지에서 간단하게라도 완성이 된 결과물을 내는것의 차이는 정말 크다는것을 느끼면서 내가 앞으로 어떻게 공부를 해야하고, 모르는것이 생기면 어떻게 해쳐나가야하는지 조금은 방향성을 가질수 있게 되었습니다.
이번 프로젝트로 인하여 부족함을 느끼는것과 동시에 성취감도 느꼈기때문에 부족했던 부분은 꾸준하게 보완하고, 성취를 얻었던 부분은 나중에도 자주 생각하면서 내가 이 공부를 더 열심히 할수있게 만들어주는 원동력으로 삼아서 앞으로도 열심히 나아가겠습니다!

저의 첫 프로젝트인 빠르고 간편한 취약계층 특화 택시 호출 서비스 SAFE-T의 자세한 코드와 설명은
| SAFE-T | 에서 볼수 있습니다!!!