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

이하얀·2023년 2월 22일

백엔드 스마일게이트

🎿 Smailegate(Winter-Devcamp)

목록 보기

40/49

그동안의 활동에 대한 회고

📁 코드 설명

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 실패

해당 부분의 자세한 트러블 슈팅 과정은 다음 링크 참고
https://velog.io/@dlgkdis801/현재-상황참고-링크
https://velog.io/@dlgkdis801/IntelliJ-Github-연동-다시
질문
답변 및 해결
→ 원인 : 자동 생성되는 파일을 업로드하여 서로 conflict가 발생한 상태(.idea 파일이 올라가지 않도록 설정하긴 했지만 시점의 차이로 자동 생성 파일 충돌이 일어나는 경우)
→ 해결 방법 힌트

→ 실제 해결

📌 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 관련 코드 추가

연결해야하는 서버가 켜져 있지 않아 발생한 오류

해결 : 배포 시점에 연결을 시도한 서버가 켜져 있지 않아 발생한 문제 → 연결 시도 서버를 켜는 것으로 해결함.

서버의 이름이 “Unknown”으로 보여지는 오류

해결 : 서버 이름이 지정되어 있지 않아 발생한 문제 → 서버 이름 삽입으로 해결

배포된 인증인가 서버에 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) 글을 쓰고 정리하는 기술이 늘어난다는 것을 체감했다.
- 물론, 매일 매 순간을 기록하지는 못했지만 기회가 될 때마다 기록을 했다. 캠프 과정 중에는 이게 큰 도움이 될까?라는 생각을 했다.
- 그런데 이렇게 회고를 하고 느낀점을 작성하며 정말 큰 도움이 되었다. 그 때 마주쳤던 어려움들, 감정들, 생각들을 다시 보며 그때의 상황과 감정을 떠올리기 용이했다.
- 또한, 내가 어떤 부분을 잘 알고 있고, 어떤 부분이 많이 부족한지 알 수 있었다. 특히, 기초적인 지식들이 생각보다 빈 구멍이 많은 젠가처럼 쌓아져 왔다는 것을 알게 되었다.
- 네트워크, 보안과 같은 부분을 고려하며 모르는 기초 지식이 생각보다 많다는 점과 학교 공부가 전부가 아니라는 것을 절실히 깨닫게 되었다.

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