스마일게이트 윈터데브캠프 회고🎯

이하얀·2023년 2월 22일
0
post-thumbnail

그동안의 활동에 대한 회고

📁 코드 설명

https://velog.io/@dlgkdis801/인증인가-서버-소셜-일반으로-전향하기4

📁 성공한 부분

  • Spring Framwork, Spring Security를 사용한 프로젝트
  • REST API 설계
  • 인증/인가 서버의 구축 및 정상 작동
  • JWT 도입 및 AccessToken과 RefreshToken의 사용
  • MySQL과 Redis의 혼용을 통한 사용자 인증
  • AWS EC2를 이용한 무중단 배포
  • 배포 실패 가능성을 염두한 이중 공유기 환경에서의 포트포워딩 대비

📁 부족한 부분

  • 빈번하게 일어나는 작업(ex.토큰 재발급)에 대한 속도와 편의성을 고려하지 못한 설계
  • 소셜 로그인 추가(OAuth 2.0)
  • 코드의 일관성
  • Gateway 차원에서의 인증

📁 고민 및 어려웠던 점

  • 많은 부분을 고려하며 설계했음에도 개발 과정에서 다양한 이유로 무산되는 경우가 많아, 설계에 대한 확신을 가지지 못하고 무작정 구현하는 것에만 집중하게 되었던 것에 대한 고민
  • 프론트의 의존 없이 Postman을 이용해 요청에 대한 정상 응답 처리 여부를 확인하고, 응답 틀을 커스텀하는 과정에서 생각한 것 이상의 많은 시행착오를 겪음.
  • Redis를 적용해보기는 했지만 속도 측면 이점을 크게 활용하지 못한 것에 대한 고민
  • 시간이 부족하다는 이유로 서버가 작동하는 것에만 포커스를 맞추게 되어 코드의 일관성과 간결성이 깨지게 된 것
  • AWS를 이용한 EC2 인스턴스의 배포 방식에 미숙하여 EC2 서버 내의 환경을 계속해서 자료를 찾아보며 로컬 PC와 동일하게 일일이 맞추는 과정이 필요했던 것
  • 모르는 부분이나 도움이 필요한 부분에 대한 질문을 망설여 너무나 많은 시간을 허비한 뒤에 뒤늦게 도움을 받게 되었던 것
  • 새로운 프레임워크를 적용하는 것에만 집중하다보니 Spring 자체의 SpringBoot, JPA, Spring Security 등에만 의존해 개발한 것에 대한 고민
  • 에러 또는 서버에 대한 새로운 요구사항이 추가되었을 때의 대처 시간이 너무나 오래걸렸던 점
  • Github 사용에 미숙하여, 프로젝트와 레포지터리의 연동 및 별도 브랜치의 사용으로 Pull request를 올리고 팀원에게 Approve 받는 방식에서 오랜 시간이 걸리고 실수도 잦았던 점

📁 배운 것

  • 토큰을 이용한 인증 방법
  • 새로운 프레임워크의 사용
  • RDBMS가 아닌 Redis를 추가하여 사용하는 경험
  • 여러 서버와의 통신을 위한 서버 배포
  • 서비스의 흐름을 고려한 설계
  • 현재 개발 상황을 틈틈이 개인 노션과 기술블로그에 기록하며, 꾸준하게 개발하는 것

📁 한계점

  • 테스트 코드의 작성 미흡
  • 에러에 대한 대처 시야가 좁아 유연하게 대응하지 못하고, 시간을 과도하게 한 곳에 쏟은 것
  • (새로운 DB를 도입하긴 했지만)익숙한 MySQL에서 크게 벗어나지 못한 DB 설계
  • 설계 및 계획의 수정이 너무 빈번하게 일어나 방향이 많이 바뀌게 된 것
  • 인증/인가에 대한 로직이 매끄럽지 못한 것

📁 향후 발전 방향

  • 캠프 기간 중 시기 별로 했던 고민들과 해결 방법, 해결하지 못했더라도 끝까지 부딪쳐 보며 대처하려 했던 흔적들의 기록을 다시 살펴 보며 캠프가 끝나더라도 문제가 생겼던 부분들을 계속해서 해결해 나가며 개선하고 싶음.
  • 이번 캠프를 통해 테스트 코드 작성을 시도해봤지만, 경험이 없어 제대로 된 방식으로 테스트하지 못하며 무작정 구현을 하고 에러를 살펴보며 개선하는 습관에서 벗어나지 못했음.
  • 테스트 코드에 대한 학습을 조금 더 거친 다음, 이러한 습관에서 벗어나 구현 과정에서 잘 작성된 테스트 코드를 적용하며 검증할 수 있는 방식을 사용하고 싶음.
  • 인증 서버가 아닌 Gateway 측면에서의 인증을 시도해보지 못해, 해당 부분을 시도해봄으로서 서비스 내의 다른 서버에 더 빠르게 접근하는 경험을 하고 싶음.

📁 겪었던 문제들

  • API 설계 경험 zero
  • 새로운 프레임워크의 사용
  • 인증/인가, Spring Security에 대한 지식 부족

📁 해결했던 방법

  • 모르면 물어보자!🔍
    • 스스로에 대한 확신이 부족한 상태로 개발을 진행하면서 ‘내가 너무 모르는구나’를 들키고 싶지 않은 마음에 모르는 것에 대한 질문을 꺼려했음.
    • 하지만, 결국 질문을 시도하게 되면서 혼자서 해결이 힘든 부분은 질문도 하며 다양한 아이디어와 힌트를 얻을 수 있다는 것을 알게 되었음.
    • 해결 방안에 대한 고민은 1) 구글링 및 벨로그 기록, 2) 팀원 질문 순서로 진행하고, 해결 방안이 하루 이상 나오지 않을 경우 3) 슬랙 ‘질의응답’ 채널을 활용해 질문을 하도록 했음.
  • 깨달은 점
    • 도움을 요청하는 것은 부끄러운 것이 아니다 → 질문의 ‘기회’를 눈 앞에서 놓치는게 바보다!
    • 도움은 주고 받는 것이다 → ‘여기에서 내가 제일 못하는 것 같아’라는 생각을 버리고, 다양한 질문에 관심가지며 내가 도움이 될 수 있는 일도 찾기!
    • 배운다는 것은 ‘퍼즐’을 맞추는 것이다 → 모르는 것은 배워서 나의 것으로 만들 수 있다고 생각하기!
      • 배우는 것에서 만족감을 느끼고, 거기에서 끝나는 것이 아닌 ‘나의 것’으로 만드는 노력을 하자 → 빈틈을 채우자는 목표를 가지기!
      • 그 배움을 나중에 누군가에게 전달하며 도움이 될 수 있다는 기대감을 가지자.

📁 설정 목표

  • SpringBoot + Spring Security + JWT를 활용한 인증/인가 서버 구축 O
  • 안정적으로 동작하는 서버 구현(인증/인가) O
  • RESTful한 API 설계
  • 서버 연동 및 배포(AWS EC2, 포트 포워딩..) O
  • 토큰 재발급 시 MySQL보다 속도가 빠른 Redis의 사용 O
  • OAuth 2.0을 이용한 소셜 계정 연동 및 소셜 회원가입 & 로그인 구현 X
  • 성능 테스트 - nGrinder와 같은 성능 테스트 툴을 사용한 부하 스크립트의 작성 및 테스트 X

📁 결과 요약

  • 클라이언트가 회원가입 URL을 통해 접근하여 회원가입 요청을 보내면 모든 조건 충족 시 회원가입 완료 응답을 보낸다.
  • 로그인 요청을 보내면 회원가입한 유저인지 확인하는 검증을 거쳐 일치할 경우 성공 응답을 보내며 토큰을 발급한다.
  • 이후, 정보 조회&수정, 회원 탈퇴 등의 요청을 보내거나, 그 이외의 데이터 요청을 보내면 AccessToken의 유효성을 검증한 뒤 요청에 데이터에 대한 내용을 응답한다.
  • 또한, 발급받은 AceessToken과 RefreshToken을 통해 정보가 일치할 경우 토큰의 재발급을 진행한다.

📁 원인과 해결

📌 테스트 코드 작성 오류

  • 원인 : 기본 테스트 코드 자체의 오류 + html 파일이 아닌 Postman과 같은 요청응답 테스트 툴을 사용해 테스트할 수 있도록 스크립트를 작성해야 함.
  • 해결 : 회원가입, 로그인, 정보 조회, 수정 등에 맞는 스크립트를 작성하여 Test를 작성함.
    예시) 회원가입 후 로그인 시, 중복 회원을 예외처리하는 것이 성공하는지 테스트

📌 DB 연동 오류

  • 원인 : 로컬 PC의 DBMS와 프로젝트에서 사용할 DBMS를 연동해줘야 하는데, 해당 부분을 환경변수로 넣어주지 않아 해당 프로젝트가 빌드 시 이를 찾을 수 없어 에러가 발생했었다.
  • 해결 : 환경변수를 넣어주고, aplication.yml 파일에 참조를 해주었다.

📌 소셜 로그인 도입

  • 소셜 로그인 → 일반으로 전향하게 된 이유에 대한 설명은 다음 링크 참고
    https://velog.io/@dlgkdis801/인증인가-서버-소셜-일반으로-전향하기
  • 원인 : 스프링부트의 버전에 맞는 현재 프로젝트를 불러오는 데에 실패한 것으로 보임.
  • 해결 : 같은 플랫폼의 같은 이메일로 여러번 로그인하여 캐시가 남아있어 액세스가 차단된 상태 → 크롬 내의 인터넷 사용 기록을 삭제하여 테스트 + 다른 브라우저 사용으로 해결
  • 해당 gif는 로그인까지 성공한 화면임.
  • 하지만, 남은 기간 동안 소셜로그인을 포함하여 사용자의 정보 가져오기 + 닉네임 정보 추가해서 회원가입 받기 등의 처리를 하는 시간이 매우 부족하며, API 설계를 전혀 하지 않은 상태로 html 페이지로 테스트를 하는 문제가 있었음.
  • 이 이후로도 사용자 정보 가져오기와 닉네임 정보 추가 로직을 작성하는 등의 매 과정에서 알 수 없는 에러가 발생해 해당 에러를 해결하는데에 최대 2일까지 소요하는 경우가 많았음.
  • 따라서 이 문제를 해결하고, 남은 시간을 정말 서버를 개발하는데에 더 집중하기 위해 Spring Security + JWT를 사용하는 일반적인 방식으로 전환하여 개발을 진행했으며, 기간 내에 완성할 수 있었음.

📌 스프링 3점대에서의 securityconfig 미적용 문제

  • 질문
  • 원인 : 스프링 3점대에서는, 기존 2점대의 config 파일에서 사용하던 변수들이 사용 불가한 경우가 많아졌다. 이 때문에 새롭게 사용가능한 변수로 대체해주어야 했고, 그 변수를 찾아 모두 변경해주었으나 실제 빌드 시 적용이 되지 않았다. → 아마도 확실하게 대체되는 변수인지 알 수 없는 상태로 변경하여 문제가 생긴 것 같았다.
  • 해결 : 확실한 방법으로 해결하려면, 이전 버전으로 다운그레이드하는 것이 맞다고 판단하여 스프링부트의 버전을 2점대로 낮추고, Java 버전을 11로 낮추어 config를 작성했다.

📌 깃허브에 연동한 프로젝트의 최상위 폴더 변경

  • 질문

    → 원인 : 깃 레포지터리에 연동되는 최상위 파일의 기준은 .git 폴더가 가지고 있기 때문에 내가 공유하고 싶은 최상위 폴더에 .git 폴더가 있도록 해줘야 함.
    → 해결 : 윈도우의 기본 설정이 .git 폴더가 숨겨지도록 되어 있어 설정을 풀고, 찾아두었던 해결방법대로 해결했음.

📌 별도 브랜치를 이용한 Pull Request 실패

📌 AccessToken payload에 닉네임 정보 추가 실패

  • 원인 : 다른 서버에서 해당 유저의 닉네임을 불러오기 위해 AccessToken의 payload에 닉네임 정보를 넣어주어야 했는데
    -> Subject에 포함 시키기
    -> Claims를 생성해 넣어주기
    -> payload 함수 생성하여 넣어주기
    이렇게 3가지의 방식으로 계속해서 변형해가며 적용을 시도해봤으나 결국 넣지 못했다.
    질문도 해보았으나, 시간도 많이 낭비하고 쓸 수 있는 방법을 전부 동원해본 것 같아 결국 다른 방법을 찾아보기로 했다.
  • 해결 : AccessToken에 닉네임 정보를 넣지 않고, AccessToken에서 제공되는 user_id를 통해 닉네임 정보를 요청해 받아오는 방식으로 진행하는 것으로 변경했다.

📌 AWS EC2 배포 중 DB 연동 실패로 인한 에러

  • 해당 부분의 자세한 트러블 슈팅 과정은 다음 링크 참고
    https://velog.io/@dlgkdis801/스프링-프로젝트를-AWS에-배포하기EC2
    https://velog.io/@dlgkdis801/SpringBoot-프로젝트-AWS에-배포하기

  • 상황 : AWS의 EC2 서버에 인증인가서버의 jar파일을 올렸으며, 빌드는 되지만 로그에 에러가 남는 상태

  • 원인 : DB와 JPA를 사용하지 못하는 에러로 판단하고 해결책을 찾아봄.

  • 해결 :

    • EC2 서버 내에 Apach2(http.d 활성 위함), MySQL(MariaDB)를 설치
    • 프로젝트의 aplication.yml에 EC2 서버 내의 설정을 추가 + build.gradle runtimeOnly 추가
      • 주의 : 우분투 서버에는 mariadb 관련 서버와 클라이언트를 설치했기 때문에 driver class name이 mariaDB 관련이어야함!

    • 다시 배포

📌 API Gateway 관련 코드 추가

  1. 연결해야하는 서버가 켜져 있지 않아 발생한 오류
  • 해결 : 배포 시점에 연결을 시도한 서버가 켜져 있지 않아 발생한 문제 → 연결 시도 서버를 켜는 것으로 해결함.
  1. 서버의 이름이 “Unknown”으로 보여지는 오류
  • 해결 : 서버 이름이 지정되어 있지 않아 발생한 문제 → 서버 이름 삽입으로 해결
  1. 배포된 인증인가 서버에 Postman으로 직접 요청 시에는 데이터가 삽입됨 → zuul을 거치면 들어가지 않는 오류
  • 해결 : aplication.yml에서 인증 인가 서버의 ip 정보를 제공해주지 않아 발생한 문제 → ip 정보 추가하여 해결

📁 회고 & 소감

  • 새로운 프레임워크의 사용
    • 기존에는 PHP와 HTML, JavaScript를 사용한 개발만 진행했으나, 이번 팀 프로젝트를 위해 Spring 프레임워크를 사용하는 경험을 하게 되었다.
    • 그 때문인지 다른 팀원보다는 개발한 ‘양’은 분명 적게 느껴졌다. 양이 작다는 것은 캠프 내내 나를 짓누르는 부담감으로 작용하기도 했다.
    • 또, 막상 하나의 서버를 개발하더라도 정말 많은 부분을 고려해야 하는데, 캠프 기간 내에 새로운 기술을 도입하는 것은 나에게 너무나 버거운 일인가 생각하게 될 정도로 많은 예외와 에러가 발생했었다(다 포기하고 싶었을 정도…ㅎㅎ).
    • 그 외에도 고려할 부분들을 끊임없이 생각하며 개발하니 다른 팀원보다 시간이 오래 걸리고, 상대적인 시간에 비해 너무나 비약한 결과물을 보여줄 수 밖에 없었다. 그리고 개발을 포기해야하는 부분도 상당히 많았다. 앞 부분에서 시간을 너무 많이 사용한 것이다.
    • 하지만, 이 과정들에서 내가 제일 모르니까 → 분명 내가 얻을 수 있는 것이 가장 많을 것이다는 긍정적인 생각으로 하루하루를 버티고 그렇게 3개월을 버텼다.
    • 또, 힘이 들고 지칠 때마다 팀원, 관계자 분들께 응원을 받으며 그 응원에 부응하고자 절대 ‘포기’만은 하지 않았다.
    • 그 누구보다 자리가 가장 오래 앉아, 가장 긴 시간을 고민하며 끝까지 개발했다는 점에서는 자부심을 느낄 수 있을 정도다.(많은 날들을 뜬 눈으로 지새우고, 그 날들의 새벽 5시쯤에는 슬랙 활동중 표시가 나밖에 없는 것을 보며 끝까지 해보자라는 생각으로 심적 부담감을 내려놓으려 애썼던 기억도 있다.)
    • Spring을 사용한 서버 개발에 성공했다는 결과를 낼 수 있게 되었다. 이 과정에서 힘들었지만 아무것도 모르던 캠프 이전의 나보다 훨씬 많은 부분을 고려하고 많은 방법을 도입할 수 있는 사람이 된 것 같다.
    • 새로운 프레임워크의 도입에 대해서 처음 언급했을 때부터 지금까지 팀원들의 걱정을 포함한 나 자신의 걱정까지 정말 많은 장벽이 있었지만 결국 해냈다.
    • 그렇기에 이번에 새롭게 사용할 수 있게 된 Spring을 중점적으로 활용하며 백엔드 개발자가 되기 위한 길을 걸어가고자 한다.

  • REST API 설계 및 개발
    • 항상 클라이언트와 서버를 같이 개발해왔지만, 이번 팀 프로젝트를 통해 서버만을 개발하는 백엔드로서 프로젝트를 진행했다.
    • REST API에 대한 설계조차 해본 경험이 zero였던 나에게는 이마저도 쉽지 않은 일이었다.
    • 하지만, 그 빈 부분을 매꾸기 위해 정말 많은 공부를 하고, 바쁘게 머리와 손을 움직였다.
    • 그 결과 더 이상 프론트에 의존한 응답 결과를 보는 것만이 아닌, Postman을 통해 직접 요청을 보내고 응답을 확인하며 API별로 메소드와 URL, 요청, 응답에 대한 내용들을 설계하고 수정해나가며 API 문서를 작성할 수 있게 되었다.
    • 노션 페이지에 모두의 API 문서를 공유해둔 덕분에, 자잘한 문제가 생기는 부분은 문서를 참고하며 개발을 하며 개발의 생산성을 높일 수 있었다.
    • 다만 한 가지 아쉬운 점은 해당 API가 RESTful한지 묻는다면, 100%라고 할 수 없다는 것이다.( API를 설계하고 개발하는 것에는 약간 부족했다고 생각한다.)
    • 물론 처음이었기에 최대한으로 노력을 했지만, 만족스럽지 못할 수 있다고 생각한다.
    • 하지만 또 처음이 있다면 다음이 있는 것이기 때문에, 그 ‘다음’부터는 스스로부터 만족할 수 있는 REST API를 만들어내고 싶다.

  • 인증/인가 서버와 JWT
    • 서버 개발 자체가 처음이었던 나에게는 서버를 맡아 직접 개발한다는 것 자체가 큰 부담이었다. 하지만 그렇다고 해서 쉽게 물러나려는 생각은 하지 않았다. 약하다고 그 자리에 안주하게 되면, 결국 나에게만 안좋은 것이다 생각하고 약하다면 강해지자고 생각했다.
    • 그래서 나는 REST API 개발에 대한 경험이 없기 때문에 가장 기초가 된다고 할 수 있는 인증/인가 서버를 개발하게 되었다.
    • 새로운 프레임워크 + 새로운 인증방식(Session → Token)이라는 부담은 컸지만, 꼭 해내야겠다고 생각했다.
    • 예상했던대로, Spring Security & JWT에 대한 지식은 너무나도 빈약했고, 이해하는 데에도 꽤 오랜 시간이 걸렸고, 포기하고 싶은 마음도 잠깐씩은 들었었다.
    • 그래도 공부한 시간을 개발에 잘 활용할 수 있다면 그보다 좋은 것은 없었기에 걱정은 잠시 내려놓고 공부하며 서버를 개발했다.
    • 그 결과
      • AccessToken과 RefreshToken을 어떻게 발급하고 관리할 것인지
      • SpringSecurity를 어떻게 사용하고 어떤 파일들이 서로 의존하고 연관되어 있는지
    • 등을 포함한 다양한 부분을 고민하며 개발할 수 있었다.
    • 이 서버를 개발하며, 가장 가볍고 작게 생각했던 사용자 인증과 인가 절차에 대해서 공부하고 생각보다 복잡한 절차가 필요하다는 것을 알게 되었고, 아키텍처 리뷰와 코드리뷰를 통해 생각하지 못했던 부분들을 더 고려해가며 보완해나갈 수 있었다.
    • 다만 아쉬운 점은, 인증과 인가의 절차가 생각보다 매끄럽지 못했다는 것이다. 설계 과정에서의 2% 아쉬운 부분이 개발을 통해 이렇게 드러난 것 같았다. 그래도 기초에 대한 구현을 하며 생각한 것보다 많은 고민과 좌절을 겪었고, 툭툭 털고 다시 일어나 걸어가는 방법을 배웠다.

  • AWS EC2
    • 사실, AWS와 EC2가 생소하지는 않았다.
    • 캠프 이전에 학교에서 클라우드 관련 부트 캠프를 진행했을 때 사용해봤기 때문이다. 하지만, 그 당시에는 튜토리얼이 전부 제공되었고 사실상 복사+붙여넣기로 완성한 EC2 서버였다는 점에서 경험했다고 말하기 어려웠다.
    • 이번 캠프에서 마지막 1주 간은 연동과 배포를 진행하게 되었는데, 배포에는 1~2일정도가 걸려 성공하게 되었다.(배포한다는 말은 들은 적이 없었는데.....갑자기 통보..를 받..🤦‍♀️)
    • AWS에서 제공하는 프리티어를 사용하다보니, 기본 제공되는 우분투 서버를 통해 프로젝트를 배포해야 했다. 이 곳에서 의외의 경험이 도움이 크게 되었다. 학교에서 배웠던 리눅스 관련 과목에서 서버를 배포해본 경험이 있어 그 부분을 생각하며 진행할 수 있었다.
    • 가장 중요한 점은, 내가 배포하려 이용하는 서버의 최소 환경이 로컬 PC의 환경과 동일하야 한다는 점이다. 앞서서 이야기했지만, DB에 대한 설정을 서버 내에 해주지 않아 에러가 발생했고, 하루정도의 시간이 걸려 해결하게 되었다.
    • 결국 EC2 서버 내의 java, apache, DB 등의 설정을 직접 명령어로 진행하여 적용했고, FileZilla를 이용해 배포할 파일을 로컬에서 간편하게 서버로 옮길 수 있었다.
    • 이렇게 에러를 잡으며 배포에 성공했으며 nohup을 사용해 계속 배포가 진행되도록 설정할 수 있었다.
    • 이렇게, 로컬 PC에서 정상적으로 작동하는 것을 확인하고 배포를 하는 과정에서도 많은 부분을 생각해야 한다는 것을 알게 되었다.
    • 로컬에서는 경험하기 어려운 새로운 문제들을 발견하고 해결하며 또 한 단계 성장할 수 있었다.
    • 아쉬운 점은 EC2 서버에 DB를 직접 설치해 진행했기에 AWS의 RDS 등은 활용해보지 못한 것이다.

  • 꾸준한 기록
    • 이번 캠프를 통해, 그동안 미뤄왔던 기록을 시작했다.
    • 평소에도 기록을 하는 습관을 중요하다고 생각해 개인적인 부분은 이곳 저곳에 끊임없이 기록을 했었지만, 막상 내가 하고자 하는 일에 도움이 될만한 기록은 전혀 하고 있지 않았다.
    • 어찌보면, 나는 개발자를 하겠다고 이야기했지만 왜 해야한다고 생각했는지와 동기부여가 없었던 것이다. 그래서 자연스레 기록도 미뤄왔던 것이다.
    • 하지만, 예상치 못한 캠프 합격 소식을 듣게 된 이후로부터 조금씩 기록을 시작하게 되었다.
    • 기록을 하며 1) 나의 지식 체크가 가능해진다, 2) 질문을 할 때 첨부하기 좋다, 3) 글을 쓰고 정리하는 기술이 늘어난다는 것을 체감했다.
    • 물론, 매일 매 순간을 기록하지는 못했지만 기회가 될 때마다 기록을 했다. 캠프 과정 중에는 이게 큰 도움이 될까?라는 생각을 했다.
    • 그런데 이렇게 회고를 하고 느낀점을 작성하며 정말 큰 도움이 되었다. 그 때 마주쳤던 어려움들, 감정들, 생각들을 다시 보며 그때의 상황과 감정을 떠올리기 용이했다.
    • 또한, 내가 어떤 부분을 잘 알고 있고, 어떤 부분이 많이 부족한지 알 수 있었다. 특히, 기초적인 지식들이 생각보다 빈 구멍이 많은 젠가처럼 쌓아져 왔다는 것을 알게 되었다.
    • 네트워크, 보안과 같은 부분을 고려하며 모르는 기초 지식이 생각보다 많다는 점과 학교 공부가 전부가 아니라는 것을 절실히 깨닫게 되었다.

  • 느낀점
    • 개발자가 되기 위한 아주 바닥의 기초조차 제대로 밟아온 적이 없다는 것을 깨닫고, 바닥부터 시작할 수 있게 되었다.
    • 모든 과정을 신경쓰고 고려하는 과정에서 어찌보면 개발 자체를 할 시간을 과하게 빼앗기는 것은 아닌가하는 생각도 했었다. 그런데 모든 과정이 끝난 지금 돌아보면, 그 때 안했으면 지금의 결과도 없다는 것이다.
    • 내가 목표했던 코드 이외의 부분도 고려할 수 있는 개발자로서의 기본 소양을 이 캠프를 통해 배우고, 내 것으로 만들 수 있게 되어 정말 많은 충족감과 만족감이 들었다.
    • 물론 부족한 점도 정확하게 깨달았기에, 어느 부분에서는 부담감과 막막함이 나를 짓누를정도로 몰려오기도 하지만 이 부담을 느낄 수 있는 것도 이 캠프를 끝까지 견뎌낸 나에게 주어지는 보상이라고 생각한다. 결국 이 캠프를 안하고 아무것도 성장하지 못한 나를 마주했다면 그것이 더 부끄러웠을 것이다.
    • 이렇게 소중한 기회가 나에게 다가와 이 모든 과정과 감정들을 경험할 수 있다는 것에 너무나 감사하고 다행이었다.
    • 딱 한가지 아쉬운 점이 있다면, 성능 테스트를 시도해보지 못한 것이다. 나에게 주어진 시간은 성능 테스트를 해보기 이전에 끝이 났기에 어쩔 수 없이 포기해야 했지만, 이 캠프가 끝났다고 해서 완전히 내려놓을 생각은 없다. 나에게는 코드 리팩터링과 성능 테스트가 남았기 때문!
    • 더 이상은, 개발자가 되기 위한 노력도 동기도 없는 사람이 아니다.
    • 이제는 개발이 재미있고 끊임없이 개발하고자하는 동기가 생기는 사람이다!
profile
언젠가 내 코드로 세상에 기여할 수 있도록, BE&Data Science 개발 기록 노트☘️

0개의 댓글