반응형

3월부터 시작해서 벌써 7개월이 지나 마지막 날이 되었습니다. 짧다고 하면 짧고, 길다면 길 수 있는 시간이 지났습니다.

"10월이 되면 조금 성장해 있을까?"라는 생각을 하면서 부트캠프에 참여했던 거 같습니다.

7개월 동안 부트캠프에서 진행했었던 프로젝트의 과정을 기록해보려고 합니다.

 

첫 번째 프로젝트


첫 번째 프로젝트는 개인 프로젝트였습니다. Java만을 이용하여 콘솔로 입력을 받고, 콘솔에 출력을 하는 "스마트 스토어"를 만드는 프로젝트였습니다. 이 프로젝트에서는 List, Map, Set과 같은 컬렉션 프레임워크의 사용이 금지되었습니다. 즉, 사용할 거면 직접 구현해서 사용했던 프로젝트입니다. 평소에 편리하게 그냥 가져다 쓰던 List, Map, Set 등 편리한 컬렉션들이 어떻게 작동되는지 느껴볼 수 있었던 프로젝트였습니다.

 

다른 부트캠프에 비해서 제가 참여했던 패스트캠퍼스에서는 Java 언어 수강 기간이 꽤나 큰 비중을 차지했었습니다. 강사님의 강의는 대부분 라이브 코딩을 통해서 진행되었고, 중간에 받은 질문이나 오류들을 같이 트러블 슈팅하며 꽤나 깊은 영역까지 확인해 보며 학습할 수 있었던 거 같습니다. 하지만, 트러블 슈팅에 시간을 많이 쓰셔서 진도를 제시간에 나가지 못하는 경우도 꽤나 있어서 불만이 있는 수강생분들도 있었던 것으로 기억합니다. 저는 개인적으로 문제 해결 능력을 기를 수 있었던 재미있는 수강 시간이었던 것 같습니다.

 

 

두 번째 프로젝트


두 번째 프로젝트는 "야구관리 프로그램"이었습니다. Java와 JDBC 그리고 Database(MySQL)를 이용하는 토이 프로젝트였습니다. 데이터베이스 설계에 대한 이론 강의를 진행한 후에 프로젝트가 진행되어 직접 요구사항에 대한 데이터베이스 설계를 해 볼 수 있었습니다.

 

경기장, 팀, 선수, 퇴출 선수에 대한 테이블을 설계했고, 요구사항에 맞게 비즈니스 로직을 Service에 구현했습니다. 두 번째 프로젝트에서는 두 명이서 팀을 이뤄서 진행한 첫 번째 팀 프로젝트였기 때문에 Github Commit Message Convetion을 정하고, Pull Request를 이용해서 Rebase Merge를 하는 방식으로 프로젝트를 진행했습니다. 야구 관리 프로그램을 진행할 때, 패키지 설계에 대한 고민도 했었습니다. 이때는 기능을 기준으로 db, dto, model, service, view 이렇게 패키지를 분리해서 작업을 했었습니다.

 

독학할 때, 유튜브로 봤었던 최주호 강사님이 데이터베이스 수업을 맡아주셨었는데 수업을 하실 때 적절한 비유를 통해서 이해를 쉽게 할 수 있도록 도와주셨던 것 같습니다. Index에 대한 개념, Index는 언제 사용하면 좋을지, OneToOne, OneToMany, ManyToOne, ManyToMany 등 여러 가지 의존 관계에 대해서 배울 수 있었습니다. 지금까지도 유용하게 잘 사용하고 있는 지식들입니다.

 

https://github.com/khsrla9806/fastcampus-toyproject2

 

GitHub - khsrla9806/fastcampus-toyproject2: 🖥️ JDK11 + Gradle + JDBC + MySQL

🖥️ JDK11 + Gradle + JDBC + MySQL. Contribute to khsrla9806/fastcampus-toyproject2 development by creating an account on GitHub.

github.com

 

 

세 번째 프로젝트


세 번째 프로젝트는 그 유명한 "게시판" 프로젝트입니다. 드디어 Springboot를 사용하기 시작한 토이 프로젝트입니다. Spring Data JPA와 MyBatis에 대한 이론 강의를 진행한 후 프로젝트가 진행되어 요구 사항에서는 사용자 서버는 Spring Data JPA를 이용하고, 관리자 서버는 MyBatis를 사용하라는 요구 사항이 있었습니다. 백엔드 팀원끼리 진행했던 프로젝트였기 때문에 View는 Thymeleaf와 Bootstrap를 이용하여 Server Side Rendering을 했습니다.

 

세 번째 프로젝트에서 사용자 서버와 관리자 서버를 따로 분리해서 API 통신을 할지 아니면 멀티 모듈로 구성해서 Entity들을 공유하여 사용할지 결정해야 했었습니다. 관리자의 기능은 사용자 기능이 완료된 후에 함께 구현하기로 했었기 때문에 프로젝트의 남은 기한을 고려했을 때, 새로운 저장소를 만들어 서버 자체를 분리하는 데는 무리가 있다고 판단하여 멀티 모듈로 사용자는 8080 포트, 관리자는 8081 포트로 분리하기로 결정했습니다.

 

두 번째 프로젝트에서 유용하게 사용했었던 Github Convention과 Pull Request & Rebase Merge 전략을 그대로 가져와서 새로운 팀원들과 살을 붙여 이용했습니다. 추가로 작업 내용을 Issue화 해서 협업을 진행했습니다. Commit Message에 Issue 번호를 적어서 작성하면 어떤 작업에서 발생된 Commit 내용인지 빠르게 파악할 수 있어서 좋았습니다.

 

개인적으로 멀티모듈이 생각했던 거보다 구성하는 것이 힘들었고, 패키지 구조가 복잡해지고 내가 찾고자 하는 클래스 파일을 찾는데 힘들었던 것 같습니다. 다음 프로젝트에서 같은 상황이 존재한다면 서버 자체를 분리하고, API 통신을 하지 않을까라는 생각을 하게 되었던 프로젝트였습니다.

 

https://github.com/khsrla9806/board-project

 

GitHub - khsrla9806/board-project: 🖥️ Spring Boot (2.7.13) + Gradle + JDK11 + Spring Data JPA(Board) + MyBatis(Admin) + MyS

🖥️ Spring Boot (2.7.13) + Gradle + JDK11 + Spring Data JPA(Board) + MyBatis(Admin) + MySQL - GitHub - khsrla9806/board-project: 🖥️ Spring Boot (2.7.13) + Gradle + JDK11 + Spring Data JPA(Board) + M...

github.com

 

 

네 번째 프로젝트


네 번째 프로젝트는 "연차 & 당직 프로젝트"였습니다. 이번 프로젝트는 처음으로 프런트 개발팀과 함께 진행했던 협업 프로젝트였습니다. 처음 진행하는 협업 프로젝트여서 협업 특강을 따로 진행해 주었고, 요구사항도 그렇게 어렵지 않고 간단했습니다.

 

처음 하는 협업 프로젝트여서 지금까지 했던 방향과는 다르게 진행했습니다. 싱크업 미팅을 가진 후 프런트엔드 팀과 함께 먼저 주어진 기획을 가지고 와이어프레임을 작성했습니다. 와이어프레임을 함께 작성했던 이유는 요구 사항도 많지 않았고, 서로 생각하고 있는 개발 방향을 맞추기 위해서였습니다. 같은 기획서를 가지고, 다른 방향으로 충분히 생각할 수 있기 때문에 의견을 맞추는 것이 우선 되어야 한다고 생각했습니다.

 

와이어프레임을 작성한 후 백엔드 팀원끼리 모여 ERD 설계를 진행하고, API 명세서도 프런트 엔드 팀원분들과 함께 작성했습니다. 둘 다 처음 하는 협업이어서 어떤 Request를 받고, 어떤 Response를 줘야 할지에 대해서 의논했습니다. 처음 했던 협업 치고는 순탄하게 진행되었던 거 같습니다.

 

이번 프로젝트에서 새롭게 해 볼 수 있었던 것은 AWS Lightsail과 FileZilla를 가지고, 서버를 실제로 배포해 보는 경험을 해볼 수 있었습니다. 그리고 클라이언트 서버(HTTPS)와의 통신을 위해서는 SSL 인증서를 발급받아 도메인을 구매한 후 연결을 했어야 했습니다. 도메인은 가비아에서 저렴하게 구입했고, LetsEncrypt를 이용하여 인증서를 발급하고, application.yml에 설정을 추가해 줌으로써 프로젝트를 진행할 수 있었습니다.

 

https://github.com/khsrla9806/mini-annual-work-project

 

GitHub - khsrla9806/mini-annual-work-project: 🖥️ Spring Boot (2.7.14) + Gradle + JDK11 + Spring Data JPA + MySQL + AWS

🖥️ Spring Boot (2.7.14) + Gradle + JDK11 + Spring Data JPA + MySQL + AWS - GitHub - khsrla9806/mini-annual-work-project: 🖥️ Spring Boot (2.7.14) + Gradle + JDK11 + Spring Data JPA + MySQL + AWS

github.com

 

 

다섯 번째 프로젝트


다섯 번째 프로젝트는 "기업연계" 프로젝트였습니다. 지금까지 했던 4개의 프로젝트는 이 파이널 프로젝트를 위한 발판이라고 할 수 있습니다. 진행되는 과정은 연계된 기업의 대표분들이 직접 어떤 설루션을 해결해줬으면 하는지, 어떤 프로젝트를 진행하고 싶은지를 말하는 시간을 갖고 나서 1 지망, 2 지망, 3 지망 선택했습니다. 같은 기업을 선택한 사람들끼리 랜덤으로 팀이 구성되었습니다. 거의 모든 사람이 1 지망에 선택했던 프로젝트를 진행하셨던 거 같습니다. 기업연계 프로젝트는 PM, UX/UI도 합류를 하기 때문에 소통이 매우 중요했던 프로젝트였습니다.

 

패스트캠퍼스의 모든 프로젝트를 진행하며 조금 아쉽다고 생각되었던 부분이 팀을 랜덤으로 정해준다는 것이었습니다. 참여 점수, 성적 등을 고려하여 팀을 배정해 준다고는 하지만, 5~6개월이 지나는 동안 어느 정도 함께 해보고 싶은 사람들이 있다고 생각이 됩니다. 뭐 누구를 만나든 최선을 다해야 하는 것은 맞지만, 열정이 비슷한 사람들끼리 팀을 이루면 그 시너지 효과가 더욱 클 것이라고 생각되었기 때문입니다.

 

하지만, 불만과는 다르게 파이널 프로젝트에서 만났던 팀원분들은 열정이 넘치고, 오프라인 강의장까지 출석하시면서 함께 진행했습니다. 마지막 프로젝트이기 때문에 함께 이루고 싶은 팀의 공동 목표를 정했던 것 같습니다. 저희 팀에서 정한 공동 목표는 배포 자동화(CI/CD) 환경 구성, 테스트 커버리지 50% 이상 유지가 있었습니다.

 

실제로 프로젝트에서 Github Actions와 SSH를 이용하여 배포 자동화 환경을 구성했고, 테스트 커버리지는 57%를 달성했습니다. 그리고 새롭게 Java Code Convention도 정했습니다. 이때 나온 컨벤션이 거의 15개... 모두 다 지키지는 못했지만, 컨벤션을 정하는 과정에서도 배움이 있었습니다. 추가로 이번에는 Gitflow 전략을 도입하고, Rebase Merge 전략이 아닌 Squash Merge 전략을 사용했습니다. Squash Merge 전략을 사용한 이유는 하나의 작업에서 발생하는 Commit을 세분화하다 보니 너무 많은 Commit이 생겼고, 오히려 해당 작업을 추적하기가 어려워졌었습니다. 그래서 Squash Merge를 사용해서 세분화된 Commit들을 하나의 Commit으로 합쳐서 효과적으로 커밋을 관리하고, 가독성을 높일 수 있을 것이라고 생각했습니다.

 

 

https://github.com/livable-final/server

 

GitHub - livable-final/server: 오피스 혁신을 위한 통합 플랫폼 ‘오피스너’의 유저 가입자수와 WAU를

오피스 혁신을 위한 통합 플랫폼 ‘오피스너’의 유저 가입자수와 WAU를 높이기 위한 프로젝트 - GitHub - livable-final/server: 오피스 혁신을 위한 통합 플랫폼 ‘오피스너’의 유저 가입자수와 WAU를

github.com

 

 

마무리 회고


처음에는 Github를 Push, Pull 정도만 이해하고 사용했었습니다. 프로젝트를 거치면서 Pull Request도 사용해 보고, 충돌을 해결하기 위해서 Rebase도 사용해 볼 수 있었습니다. 더 나아가 Issue를 적극적으로 사용하게 되었고, 마지막에는 Organization을 생성하여 Client와 Server를 함께 관리하고, 상황에 적절한 Gitflow 전략과 Merge 전략을 선택해서 사용할 수 있을 정도로 성장을 했습니다.

 

프로젝트를 진행하며 점점 필요에 의해서 기술을 학습했던 거 같습니다. 사실 패스트캠퍼스에서 제공되었던 실시간 강의는 개인적으로 조금 부실하다고 느껴졌었습니다. 글씨가 너무 작거나 짧은 시간에 너무 많은 정보를 제공하려고 해서 너무 복잡했던 거 같습니다. 그래서 달마다 지급되었던 지원금을 모아서 인프런에서 김영한 님의 강의를 구매해서 수강했었습니다. 필요하다고 생각될 때마다 HTTP 강의, Spring 강의, JPA, QueryDSL, MVC 모두 구매해서 수강하고, 바로 진행하고 있던 프로젝트에 활용해 보며 학습했습니다.

 

다음에 프로젝트를 진행한다면 Docker를 사용해서 배포환경을 구성해보고 싶습니다. 그리고 파이널 프로젝트에서 잠깐 사용했었던 JMeter를 조금 심오하게 사용해서 성능 개선도 해보고 싶다는 목표가 생겼습니다. 지금까지 프로젝트에서 문서화를 할 때 접근하기 좋았던 Notion을 주로 사용했지만, Swagger를 사용하여 API 문서화를 진행해보려고 합니다. 무조건 한다. 👊🏻

 

결국에는 스스로 하지 않고 가만히 있으면 가마니가 됩니다. 어느 곳을 가던 하는 만큼 얻어갈 수 있다고 생각합니다. 제가 열심히 하고, 열정적으로 참여하면 주변 사람들도 그런 사람들로 채워졌던 거 같습니다. 비전공자로 개발을 시작했지만, 10개월 동안 좋은 사람들과 함께 진행할 수 있어서 좋았던 활동이었다고 말할 수 있을 거 같습니다.

 

반응형
반응형

저번에 9주 차 회고를 작성했었는데, 벌써 5주가 지나서 14주 차가 되었습니다. 허허 가볍게 회고록을 작성해보려고 합니다.

 

 

🙋🏻‍♂️ Database/Spring 실시간 강의 시작

저번 Java 수업이 끝나고 이제 Database와 Spring 실시간 강의를 시작했습니다. 혼자서 Spring 공부해 볼 때 최주호 강사님이 운영하는 메타코딩이라는 유튜브 채널에서 공부를 한 적이 있었는데, 이번 Spring 실시간 강의 강사님으로 오셔서 약간 기대가 되었습니다.

 

지금 벌써 강의를 시작한지 몇 주가 지났는데, 개인적으로 실시간 강의 만족도는 매우 높습니다. 모르고 넘어갈만한 내용들을 자세하게 알려주셨습니다. 특히 그림으로 그리면서 적절한 예시를 항상 들어서 설명해 주시는데 이 부분이 만족도가 굉장히 높았습니다.

 

Database, JDBC, MyBatis 강의를 지나서 지금은 Hibernate와 JPA에 대해서 강의를 진행중인데, 다음 주에는 두 번째 토이 프로젝트가 예정이 되어 있습니다. 간단한 프로젝트이긴 한데 이번에는 2인 1조로 프로젝트가 진행돼서 약간 기대반 설렘반입니다.

 

 

 

🥇 백준 골드 달성

저번 회고 글에서 다음 회고 글에서는 골드가 되어있었으면 좋겠다고 했었는데, 골드를 달성했습니다. 알고리즘 문제는 빠짐없이 매일 1문제씩 백준에서 풀고 있습니다.

골드 구간으로 넘어오고 나서 요즘은 삼성 기출 코딩테스트 구현 문제를 하나씩 건들고 있는데, 확실히 난이도가 높아지고 있는 것을 느끼고 있습니다. 다음 회고 글에서는 플래티넘이 되었으면 좋겠다고 쓰고 싶지만 경험치도 엄청 천천히 오르고 문제는 어려워져서 힘들 거 같습니다. 하지만 목표로 잡은 플래티넘이 되는 날까지 꾸준히 풀어갈 계획입니다.

 

 

 

🧑🏻‍💻 사이드 프로젝트 계획

이 부분은 정규 커리큘럼은 아니지만 팀원 분들과 의견이 맞아서 계획 중에 있습니다. 처음에는 Spring MVC를 공부하면서 Springboot와 Thymeleaf로 백엔드 팀원들끼리만 프로젝트를 진행해보려고 했었는데, 계획을 하다보니 프론트 팀원분들을 모집하게 되었습니다.

 

완성도 높은 프로젝트를 해보면 좋겠지만, 지금은 앞으로 있을 미니 프로젝트와 파이널 프로젝트를 대비하기 위한 간단한 연습정도로 생각하고 참여해볼 생각입니다. 그렇다고 느슨하게 할 생각은 없습니다. 프로젝트는 프론트 팀원분들이 확정되면 기획을 마무리하고 바로 개발에 들어가 볼 계획을 가지고 있습니다. 다음 회고글에서는 사이드 프로젝트 결과에 대해서 다루고 있을 수도 있겠네요.

반응형
반응형

지난 3주 차 회고를 작성한 지 벌써 6주가 흘러 9주 차 회고를 쓰게 되었습니다. 준비할 건 많고, 하루는 부족하고... 하루하루가 정말 빠르게 지나가는 것 같습니다.

 

 

👋🏻 Java 실시간 강의 종료

9주 차에 회고를 쓰게 된 이유는 Java 실시간 강의가 끝났기 때문입니다. 사실 여러 부트캠프를 보면 Java를 엄청 빠르게 끝내는 부트캠프들이 많은데, 제가 듣고 있는 과정에서는 화요일, 목요일에 Java 실시간 강의를 진행했었습니다.

 

언어를 너무 오랫동안 하는 거 아닌가에 대한 의문도 있었지만, 강사님이 Java의 상당히 깊은 부분까지 고려하면서 강의를 진행해 주셔서 저는 오히려 좋았던 거 같습니다. 어설프게 알고 있었던 부분들을 확실히 짚고 넘어가는 시간이 됐었습니다.

 

 

 

🥈 백준 실버 달성

이미 골드, 플래티넘이신 분들에게는 가소로워 보일 수도 있지만 실버를 달성했습니다. 골드를 향해서 빠르게 달려가고 있습니다. 😆

 

Solved.ac 티어

 

3주 차와 비교했을 때 자료구조, 알고리즘 제대로 학습을 한 뒤부터는 문제를 보는 눈이 조금은 달라졌다고 생각합니다. 문제를 읽었을 때, 입력 범위를 보고 나올 수 있는 시간 복잡도를 생각해 보고 어떤 자료구조가 적합할지 고민해 보는 노력을 하고 있어서 그런 거 같습니다.

 

기존에는 문제를 보면 그냥 바로 코드부터 치면서 시작했었는데, 경험해 보신 분들은 아시겠지만 이렇게 작성하다가 중간에 막히면 정말 답도 없습니다. 코딩 테스트 부분에서는 패스트캠퍼스에서 지정된 멘토님의 영향을 조금 받았다고 생각합니다. 사실 매일 적어도 1문제씩은 풀어보기라는 과제를 내주신 분이기도 하고, 알고리즘 문제 접근법이나 좋은 습관을 형성하는 데 있어서 도움을 많이 받았습니다. 다음 회고 글에서는 골드가 되어있었으면 좋겠습니다. 😄

 

 

 

📖 그룹 CS 스터디

이 부분은 부트캠프 정규 커리큘럼에는 존재하지 않지만, 각자 4명에서 5명으로 지정된 피어 그룹이 있는데, 저희 그룹원들과 따로 진행하고 있는 스터디입니다. 도서는 면접을 위한 CS 전공지식 노트라는 책을 사용해서 하고 있고, 전체적으로 짜여 있는 구성은 좋지만 면접 대비 도서라서 그런지 들어가 있는 내용은 다소 학습을 하는 데 있어서는 부족할 수 있다고 생각됩니다.

 

하지만 오히려 각자 맡은 부분에 있어서 책에 있는 내용 이외에도 추가적으로 학습해서 정리해서 발표를 진행했어서 부족함 없이 진행하고 있는 스터디라고 생각합니다. 다들 많은 내용을 공유해 주고, 학습하고 싶다는 열정이 있어서 가능한 스터디라고 생각됩니다. 

 

스터디 규칙은 매주 맡은 부분에 대해서 발표를 하고, 자신이 맡은 부분이 아니어도 해당 내용을 모두 숙지하고 오자는 규칙을 정했습니다. 그리고 따로 Github Organization을 만들어서 레포지토리를 만들고, 각자 정리한 내용을 Pull Request 하는 방식으로 스터디를 진행하고 있습니다.

Github Repository Readme 파일

 

 

 

 

👥 타 그룹과의 교류

부트캠프 후반부에 협업으로 진행하는 프로젝트가 존재합니다. 그래서 같은 기수에 교육을 듣고 계신 많은 분들과 소통해 볼 수 있는 자리가 있었으면 좋겠어서 저희 그룹 조장님을 앞세워 타 그룹과의 교류를 진행했었습니다.

 

모든 사람들과 교류해보지는 못했지만 그래도 많은 분들이 참여를 희망하셔서 다양한 분들을 만나볼 수 있었던 시간이 있었습니다. 교류를 하는데 이용했던 시간은 주로 1주일에 2번 존재하는 그룹 활동 시간을 이용했습니다. 

 

그때의 연이 닿아서 지금은 다른 그룹원분들과 함께 진행하고 있는 발표 스터디도 진행 중에 있습니다. "아니 무슨 스터디를 이렇게 많이 해?"라고 생각하시는 분들도 있을 거 같아서 다른 그룹원분들과 진행하고 있는 발표 스터디는 강제성이 없는 가벼운 스터디로 만들었습니다.

 

이 발표 스터디는 자신이 한 주 동안 학습한 내용들 중에 궁금했었던 내용이나 공유하고 싶은 내용들을 자유롭게 발표하는 스터디입니다. 발표할 내용이 없으면 굳이 하지 않아도 되고, 가볍게 시작했던 스터디인데 생각보다 다양한 주제를 가져오시는 것을 보고 나름 흥미를 느끼고 있는 스터디입니다.

 

발표 스터디 진행 노션

 

이외에도 많은 일들이 있었지만 저번 회고글과 조금 달라진 점을 위주로 작성해 봤습니다. 다음에도 작성할 내용이 생기면 회고록 작성하러 달려오겠습니다. 🙇🏻‍♂️

 

반응형
반응형

3월 17일 날 시작한 후 3주가 지났다. 사실 많으면 매주 회고글을 작성해보고 싶었는데, 아직 초반부라서 그렇게 적을 내용도 많진 않았다.

 

적응 기간도 조금 필요했고, 3주밖에 안 지났지만 나름 루틴에 적응을 해가고 있습니다. 해당 부분에 대해서 짧은 회고를 조금 남겨보려고 합니다.

 

 

🏃🏻 7개월을 꾸준히 참여하기 위해서 필요한 것은 '체력'

월요일부터 금요일까지 오후 1시부터 10시까지 매일 컴퓨터 앞에 앉아있다 보니 몸소 느낀 것이 있다.  '체력'을 키워야 개발자도 꾸준히할 수 있겠구나...

 

처음에는 별로 대수롭지 않게 생각을 했었는데, 요즘은 크게 느껴지고 있는 것 같다. 그래서 하루에 적어도 10분 정도씩은 나가서 뛰는 루틴을 추가해 봤다. 물론...이런 저런 핑계를 대며 안 갔었던 날도 많지만 확실히 작심삼일은 넘겼다. 이것도 나름 대견한 결과이다.

 

물론 10분이 짧을 수도 있지만, 아침에 이렇게 뛰고 오면 나름 오후 1시부터 시작하는 일과 때 정신이 조금 맑아지는 느낌이 난다. 확실히 안 뛰었을 때와는 다른 활력이 조금은 생긴 것 같다. 기회가 된다면 하프 마라톤! 해보고 싶다.

 

작심삼일은 넘긴 나의 도전 😀

 

 

 

🧐 하루에 한 번은 뇌를 돌리자 (알고리즘 문제 풀기)

뇌도 안 쓰다가 쓰려고 하면 저릿한 느낌이 든다. 쉬운 문제라도 조금씩 머리를 돌려보는 것이 중요하다고 느꼈고, Java 언어를 학습하면서 알고리즘 문제를 하루에 적어도 1문제를 해결해보자라는 목표를 정했다.

 

하지만 평소와는 다른 방법으로 알고리즘 문제에 접근해 보기로 했다. 사실 이 부분은 패스트캠퍼스 멘토님이 추천해 주신 방법이다. 

 

항상 알고리즘 문제를 풀 때 고민했었다. 스스로 문제를 푸는 것은 중요한데 이렇게 많은 시간을 쏟는 것이 효율적인 것인가라는 생각이다. 나는 지금껏 알고리즘 문제를 풀 때, 따로 시간을 지정해두지는 않았다. 그래서 어떨 때는 정말 4시간~5시간을 한 문제에 쏟았던 적도 많았다. 

 

근데 문득 이 방법은 그리 효율적인 방법이 아니라는 느낌이 들기 시작했고, 멘토님에게 질문을 드렸다. 멘토님의 의견을 받아들여 내가 정한 알고리즘 문제 풀이 방식은 다음과 같습니다.

1. 문제를 읽자마자 코드를 작성하지 않는다.

이전에는 문제를 읽고난 후 코드를 바로 작성했었다. 이렇게 했을 때의 문제점은 코드를 작성하는 과정 중간에서 막히면 코드를 싹 초기화하고 다시 작성하는 일이 빈번했다. 

그래서 결정한 방법은 처음에 문제를 정독한 후 20~30분 정도는 오직 알고리즘만을 생각하며 종이에 사용할 알고리즘의 방향성에 대해서 적어나간다.

만약 이 과정에서 1시간이 넘게 알고리즘 구상도 못하고 있다면, 그 문제는 모르는 문제로 생각하여 다른 사람의 알고리즘을 참고한다. 이때 코드 답을 바로 보지 않고, 알고리즘 방향만 먼저 참고한 후 해당 알고리즘대로 코드를 작성해봅니다.

알고리즘을 참고하고, 코드를 작성했는데도 계속 풀지 못한다면 다른 사람의 코드도 참고합니다. 이렇게 해결한 문제는 반드시 이해하고 넘어가야 합니다. 그리고 도움을 받은 문제는 따로 깃허브 레포지토리 Readme에 기록해 둡니다.
2. 도움받은 문제는 반드시 다시 풀어보기

일주일 이상이 지난 후 해당 문제를 다시 풀어봅니다. 이 과정은 내가 문제를 정확히 이해하고 넘어갔는지 확인하기 위한 작업입니다.
3. 새롭게 알게 된 알고리즘이나 개념이 있으면 블로그 기록하기

처음 사용해 본 알고리즘이나 기록해뒀으면 하는 과정이 존재하는 알고리즘 문제는 블로그에 따로 기록해 둡니다.

 

 

깃허브 레포지토리 README.md

 

 

 

🙋🏻‍♂️ 일일 계획의 성공률을 높여보자

멘토님을 만나기 전까지는 미친 듯이 달려 나가는 계획을 작성했었다. 물론 결과는 처참했고, 성공률도 저조했다.

성공률이 낮으니깐 뭔가 성취도도 조금 떨어지는 것 같고, 하루 만족도가 많이 떨어졌었다.

 

원인을 생각해 보면 "무리한 계획", "핑계"가 대부분을 차지했다.

 

아 오늘은 조금 힘드니깐 달리기 미뤄야겠다. 강의 듣느냐고 알고리즘 문제 못 풀었다. 내일은 꼭 풀어야지~ 이런 식의 핑계들이었다. 문제점은 파악했으니 해결방안을 생각해 봤다.

 

1. 계획은 최대한 구체적으로 작성

원래는 chapter 단위로 크게 크게 묶었었는데, 이번주에는 chapter안에 세부 chapter 단위로 나누어서 계획을 작성해 봤다.
이렇게 했을 때의 결과는 크게 크게 잡았던 계획보다는 확실히 성공률이 많이 늘었다. 그리고 추후에 복습에 대한 계획을 정할 때도 도움이 많이 됐다. 
2. 일과 시작 전에 알고리즘 문제 풀고 시작하기

2주 차까지는 온라인 강의, 실시간 강의 모든 일과를 다 마친 후에 알고리즘 문제를 풀 계획을 잡고 있었다. 근데 문제는 강의 계획이 지켜지지 않은 날은 알고리즘을 풀지 않고 넘어가는 날이 많았다. 사실 핑계다.

그래서 같은 그룹 스터디원의 의견을 수용하여 일과를 시작하기 전에 알고리즘 문제를 먼저 풀고 시작하는 계획으로 변경했다. 이렇게 했을 때 얻을 수 있었던 효과는 알고리즘 문제에 시간을 과도하게 사용하지 않는다는 점과 일과 시작 전에 뇌를 약간 워밍업 하는 느낌으로 시작할 수 있다는 점이 있었다.

 

이렇게 계획을 변경하고 난 후 3주 차 계획 성공률을 많이 높일 수 있었다. 이렇게 계속 적용해보고 점점 계획을 개선해볼 생각이다. 여기까지 3주차 회고를 마치며 다음 회고글은 언제일지 모르겠지만 그때는 지금보다 조금 더 성장해 있을 거라는 확신이 들었다. 🙂

반응형
반응형

국비교육을 받기로 한 이유

이번에 국민취업지원제도에 등록해서 국비지원 교육을 받게 되었습니다.  작년 초에 대학 동아리에서 처음 개발을 접하게 되었고 백엔드 개발자가 되기로 마음을 먹었습니다. 효율적인 성장을 하기 위해서는 뜻이 같은 사람들과 함께 성장하는 것이 중요하다고 생각합니다. 또한 앞으로 나아가는 법을 잘 모르는 상태이기 때문에 방향을 잡아줄 수 있는 교육 기관의 도움을 받는 것이 좋을 거 같다는 생각을 했고, 국비지원 교육을 받기로 결정했습니다.

 

 

패스트캠퍼스에 지원한 이유

그렇게 선택한 교육이 패스트캠퍼스 백엔드 개발 5기 부트캠프입니다. 많은 부트캠프가 존재하고, 선택의 요소들이 정말 많았습니다. 그중에서 패스트캠퍼스를 선택한 이유는 프로젝트가 많았기 때문입니다.

 

무조건 많은 프로젝트가 좋다는 의견은 아닙니다. 하지만 동아리에서도 그랬었고, 프로젝트를 통해서 협업 능력도 기를 수 있고 사람과 소통하는 법도 배울 수 있었다고 생각합니다. 그리고 프로젝트를 진행하면서 발생한 오류들을 해결하면서 많은 성장을 했고, 무엇보다 함께하는 즐거움을 느껴봤기 때문입니다.

 

패스트캠퍼스 백엔드 부트캠프 과정에서는 총 5번의 프로젝트를 합니다. 토이 프로젝트 3개, 미니 프로젝트 1개, 파이널 프로젝트 1개 이렇게 진행합니다. 이 부분이 저를 조금 끌리게 만들었던 요소였다고 생각합니다.

 

 

지원 과정 & 선발

처음 모집 요강을 봤을 때는 2023년 2월 14일이었습니다. 홈페이지에 들어가 지원을 하게 되면 지원을 할 때 입력했던 이메일로 메일이 도착하고 요구하는 대로 과정을 진행했습니다.

 

자기소개서 제출 -> 기초 소양 테스트 진행 -> 비대면 면접까지 하면 지원 완료입니다. 결과 발표는 3월 10일 날 최종 합격 발표를 받았습니다.

 

선발 메일 내용

 

패스트캠퍼스에서의 첫날

# 과정소개 및 Q&A

3월 17일 오늘 패스트캠퍼스에서 첫 교육이 시작됐습니다. 첫날은 OT를 진행했는데 대면으로는 진행되지 않고, zep이라는 프로그램을 이용해서 비대면으로 진행됐습니다.

zep 컨퍼런스홀

이렇게 캐릭터도 커스터마이징할 수 있고 막 돌아다닐 수도 있었습니다. 눈사람으로 꾸몄는데, 다른 귀여운 옷들도 많습니다. OT는 백엔드만 모여서 진행하는 것이 아닌 프런트엔드도 함께 진행합니다. 사람이 100명 정도로 많았기 때문에 가끔 렉도 걸리기도 합니다. 저는 맥북 M1을 사고 한 번도 발열을 느껴본 적이 없는데 오늘 처음 느껴봤습니다.

 

이렇게 컨퍼런스홀에 모여있으면 매니저분들이 과정에 대한 커리큘럼 설명과 Q&A 과정을 거쳤습니다. 생각보다 많은 사람들이 질문을 해주셨고, 매니저분들이 하나하나 꼼꼼하게 대답을 해주셨습니다. 

 

 

# 아이스브레이킹 시간

이제 과정 설명 및 Q&A가 모두 끝나고 잠시 휴식시간을 가진 후에 백엔드 수강자들끼리 모여서 다양한 나이, 성별, 성격의 사람들이 처음 만났기 때문에 어색한 분위기를 없애기 위해서 아이스브레이킹 시간을 가졌습니다. 이때는 4인에서 5인으로 팀이 랜덤으로 정해졌습니다. 

 

이렇게 팀원이 정해지면 컨퍼런스 홀과는 다른 공간으로 이동합니다. 이곳에서는 백엔드 수강자들만 모여있었고 팀별로 준비된 장소가 있었습니다.

백엔드 수강자들을 위한 장소

위에 보이는 하얀색 네모에 들어와 있는 사람들하고만 대화가 가능한 독립적인 공간입니다. 채팅을 해도 다른 공간에 있는 사람들은 안 보이는 것 같았습니다. 처음에는 조금 유치하다는 생각을 했는데 캐릭터가 보면 볼수록 매력 있습니다. 스페이스바를 누르면 점프도 가능하고, x를 누르면 앉기도 합니다. 다양한 감정표현도 존재합니다. 이쯤 되면 zep을 홍보하는 사람 같아서 그만하겠습니다.

 

이 공간으로 넘어와서는 팀끼리 팀장을 정했습니다. 저희 팀은 사다리 타기를 해서 팀장을 뽑았는데 저는 사다리에 정말 잘 걸립니다. 가위바위보는 맨날 지면서 이런 건 잘 걸립니다. 그렇게 팀장을 맡았고 팀원 맞추기 퀴즈, 영화 제목 맞추기, 잘린 사진 보고 뭔지 맞추기 등 다양한 활동들을 함께 하면서 아이스브레이킹 시간을 가졌습니다. 그렇게 17시 정도가 되었고 19시부터 있을 강민철 강사님의 특강이 준비되어 있었기 때문에 저녁 식사 시간을 가졌습니다.

 

 

# 개발자 마인드셋 특강

저녁 시간이 끝나고 19시부터 시작된 특강. 강민철 강사님의 특강 시간이었는데, 여기서 신기했던 점은 작년 대학교에서 멋쟁이 사자처럼 대학 10기에서 활동을 했었을 때 파이썬/장고로 개발하는 강의를 해주셨던 분이어서 정말 신기했습니다. 그때는 녹화강의였지만 오늘은...실시간 강의여서 그래서 더 집중해서 들었던 거 같기도 합니다. 

 

2시간 정도 되는 특강의 주제는 다음과 같았습니다. 개발자로서 어떤 마인드와 자세로 성장해야 하는가, 어떻게 효율적인 성장을 할 수 있는가였습니다. 주로 얘기해 주셨던 내용은 무엇을 통해 성장을 할 수 있고, 어떻게 빠르게 성장할 수 있는지에 대한 내용이었습니다. 

 

저는 이 특강을 듣고 "개발자 마인드셋"이라는 강의 이름을 정말 잘 지었다고 생각했습니다. 왜냐하면 제 마인드가 세팅된 거 같기 때문입니다. 사실 약간 정곡을 맞았던 부분이 많았습니다.

 

그중에서 가장 세게 맞은 부분은 블로그를 통한 성장에 대한 내용이었습니다. 저는 지금 성장을 위해 블로그를 하고 있습니다. 제가 작성한 게시글 중에서 토비의 스프링에 대해서 작성한 글들이 몇 개 있습니다. 사실 처음에는 토비의 스프링 책을 읽고 코드도 따라 쳐보면서 발생하는 오류에 대해서 정리를 좀 해볼까라는 생각으로 시작했는데 지금 보니 그냥 거의 책의 모든 내용을 요약해 놨다는 생각이 들었고, 이럴 거면 그냥 책을 보는 게 낫지 않을까라는 생각을 하면서 반성하게 되었습니다.

 

그래서 이제부터는 강의에서 얻은 대로 한번 블로그 글을 작성해 보는 연습을 해보자는 목표가 생겼습니다. 블로그는 제가 성장해 온 길을 증명할 수 있는 가장 강력한 무기가 될 것이기 때문입니다. 이렇게 마인드 세팅을 마무리하고, 이제 다음 주부터 10월 10일까지 긴 여정이 될 거 같습니다. 

 

최대한 1주일에 한 번이나 별다른 내용이 많이 없다면 1달에 한번 정도는 회고글을 남겨볼 생각입니다. 나중에 제가 다시 볼 수도 있고, 누군가 이 글을 읽고 도움을 받을 수 있기 때문입니다. 끝나는 날까지 화이팅입니다. 

 

 

반응형

+ Recent posts