이때까지 무엇을 하고 배웠는가?

어느덧 3월이 되었다

나는 지금까지 대략 4개월 정도 이곳에서 지내며 공부하고 있다.

기본적인 전공 지식이라던지 여러 가지 기초를 다시 다지고 한 걸음씩 나아가고 있다고 생각한다.

 

처음에는 아는것들만 나와서 기고만장했다.

그런데 이제 점차 후반부로 갈수록 점점 기술의 심화적인 내용이라던지 완전히 새로운 내용이라던지

내가 모르는 것들이 나오니 그때부터는 남들처럼 내용을 이해하기 위해 따라가기 바빴다

 

또, 내가 그 문제에 대해서 안다고 해도 다른 사람에게 쉽게 설명하지 못한다면

그건 아직 확실히 아는 게 아니라는 것을 많이 느꼈다.

 

정말로 완벽하게 이해하고 알고 있다면, 남에게 설명하는 것 또한 쉽게 해낼 수 있었을 것이다

하지만 나는 그런 질문에 잘 대답하지 못하고 지금도 쉽지는 않으니 아직 완벽히 내 것이 되었다고 할 순 없다.

 

그래서 노트에 정리하고 그 내용을 블로그에 다시 올려서 한 번씩 다시 보긴 하지만

노트에 정리한 것도 그 당시에 내가 쓴 글을 이후의 내가 봤을 때 이해하지 못한다면, 그것 또한 잘 못쓴 정리라고 생각한다.

 

이번에 블로그에 글을 작성하면서도 많이 배웠다.

남들이 보고 쉽게 이해할 수 없는 글이라면 내가 봐도 이해하기 쉽지 않은 글이고,

그것을 쉽게 풀어 정리하는 것도 하나의 공부라는 것을

 

PCCE를 도전해 보다

이번에 매달 프로그래머스에서 진행하는 코딩필수역량인증(PCCE)을 신청하여 시험을 쳐보았다.

이 전에도 기회는 있었지만 번번이 자신감 부족 및 타이밍을 놓쳐서 신청을 하지 못했었지만

이번에 한번 어떤 시험인지 체험해 보자 라는 느낌으로 도전해 보았다.

 

시험 자체는 그렇게 어렵지는 않았고 문제를 상세히 나열할 순 없지만 대략적으로 봤을 때백준 브론즈에서 잘 쳐주면 실버까지의 문제들이었던 것 같다.

 

물론 10문제 중에서 8문제를 풀었고, 합격은 했는데 Lv1 이 나왔다.내가 그 시험을 치면서 느낀 점은 이전에 코테 문제를 매일 풀었던 것이 헛수고가 아니었음을그리고 그걸 정리하고 다시 돌아보는 것도 정말 중요함을 느꼈다.

 

특히나 이러한 코테에서는 자동완성 기능이 있는 편리한 IDE를 쓰지 못하고함수를 내가 기억하고 있어야지만 작성할 수 있었다는 것에서 조금 어려웠다.

 

솔직히 말해서 너무 자동완성이나 이런 IDE에서 제공해 주는 편의성 기능에 의존하다 보니부끄럽지만 기본적인 함수마저 헷갈렸기에 마지막 두 문제는 풀지 못했다.

 

이번 시험으로 확실하게 알게 된 것은물론 코딩을 할 때 내 지식과 모든 기술을 총 동원해서 코딩하는 건 맞지만,적어도 코테를 준비한다면, 순수하게 메모장이라도 아니 그냥 종이에라도 바로 적어 낼 수 있을 정도로몸에 그냥 익히는 게 나을 것 같다는 생각이 들었다.

 

또 개인적으로 CS 지식이 많이 부족하다고 느껴 따로 책을 읽어보고 있다.내가 부족한 부분을 깨닫고 그 부분을 채우기 위해서 할 수 있는 일을 찾는 게 가장 중요하다고 생각한다.작은 도전이지만 점점 쌓이다 보면 코테 문제를 풀 때처럼 언젠가는 자연스럽게 성장할 것이라 믿는다.

빠르게 흘러간 한 주

이번 주 수업은 저번 주에 이어서 스프링 부트에 대해 배웠다.

한번 경험해본 스프링 부트였지만 정말 상세하고 깊게 구현하고, Mybatis 를 곁들여서 공부하니

내가 알고있던 기초적인 지식보다  더 심화되어 수업을 따라가기 급급했다.

 

Mybatis를 쓰면서 느낀건 일일이 매핑하고 쿼리문을 작성하는건 정말 쉽지 않다는 점이였고,

마치 건물을 세우듯 탄탄하게 기존 뼈대를 직접 만들어 세우고 그 위에 집을 짓는 느낌이였다.

내가 직접 작성하고 매핑하였기 때문에 문제가 생겨도 조금더 이해하기 쉬울순 있으나

그렇게 편리하지는 않았다.

SpringJPA랑 비교하면 정말 편의성이 C와 파이썬 차이인것 같다.

 

이 글을 작성하면서 내가 메모해놓은 코드들을 읽어보고 있는데 메모하는 습관을 들이기 잘한 것 같다.

공부할 때 어디든 기록을 해놓으면 머릿속에 1차로 저장하고 메모장에 2차로 저장하는 RAID 시스템 같은 느낌이다.

 

스프링 시큐리티에 대해서도 배웠었는데 솔직히 난 이게 왜 어렵다는지 이해하지 못했었다.

왜냐면 예전에 내가 작업할 때는 코드 몇줄만 넣으면 알아서 적용이 되었기에 이에 대한 예외 처리라던지 그런것만 해주면

해결되었던걸로 기억했기 때문이였다.

 

그런데 강의시간에는 그걸 하나하나 다 구현해봄으로써 더 심화적으로 볼 수 있었고, 왜 어렵다는지 이해하게 되었다.

실제로 그렇게 다시 구현해서 쓸 것 같진 않지만 이론적인 측면에서 이해하는데는 도움이 된 것 같다.

 

이외에도 스웨거(Swagger) 를 사용하여 테스트를 하는 방법에 대해서도 배웠는데 이것도 너무 깊게 들어가면

배보다 배꼽이 커지는 상황이 오는 것 같아 적당히 사용하는게 좋을 것 같다는 생각이 들었다.

코드를 설명할 땐 제일 나은 상황은 그냥 그 코드를 보자마자 이해할 수 있게 쉽고 간결하게 짜는게 중요하지

설명만 덕지덕지 붙여놓으면 오히려 그게 독이 될수도 있다는 생각이 들었다.

 

JWT(JSON Web Token)에 대해서도 배웠는데 이 부분은 예전에 OAuth를 구현할 때 필요해서 사용해본 적이 있다.

로그인 할때 세션과 JWT 방식이 있는데 상세한 차이는 유튜브로 따로 공부하였다.

간단히 말해서 세션은 정말 간결한 정보만 가지고 있지만 JWT는 더 다양한 정보를 포함한 Json타입이다.

 

둘 중 어느게 더 좋다고는 말 못하지만 왠만해서 대규모 트래픽 처리가 필요한 경우가 아니고서야

간단하게 세션만 써서 로그인을 구현하는것도 문제될건 없다고 생각한다.

어느 기술이 더 좋고 나쁘고가 있는게 아니라 필요에 따라서 내가 그 기술을 선택하는게 중요하다고 생각한다.

 

첫 병가를 쓰다.

이번주 수요일 부터인가 몸살에 걸렸었다.

당일에는 그게 몸살인지 모르고 그냥 피곤해서 그런가 했는데 상태가 점점 안좋아져서 일단 타이레놀을 먹으면서 버텼다.

 

그렇게 목요일이 되고, 주변 사람들이 몸살이면 좀 쉬면 낫는다, 병원에 좀 가라, 그러다 스노우볼 굴러간다 며

쉬라고 하길래 마음속으로 금요일 아침까지 상태가 호전되지 않으면 금요일까지 버티기로 하였다.

그런데 금요일에도 상태가 호전되지 않아서 결국 병가를 내고 병원에서 약을 타오게 되었다.

 

물론 공부하는것도 중요하고 건강도 중요하지만 쉰다는건 대체 어떻게 하는건지 잘 모르겠다.

그냥 유튜브나 보면서 놀면되는건가? 침대에 누워만 있으면 되는건가? 약먹고 잠만 자면 되는건가?

 

내 기준에선 뭐가 됐든 시간낭비 같이 느껴졌다.

하루라도 빠지면 뒤쳐진다는 생각이 들었다.

아마 다른 사람들도 그렇게 생각하고 몸을 혹사시키다가 상태가 나빠져서 나한테 그런 조언을 해준거겠지

 

결국 금요일에는 약을 먹고 팀 프로젝트를 위한 공부를 시작했다.

쉴때는 쉬어라. 어떻게 쉬는게 쉬는건지 그걸 다시 생각해보는 한 주가 되었다.

바쁘게 흘러간 한 주

이번주는 어느때 보다 바쁘게 흘러갔다.

이전에 작성해놓은 우선순위에 따라서 팀 프로젝트를 최우선으로 두고 작업한 결과

거의 대부분을 팀프로젝트에 시간을 쏟아 부었다.

물론 다른 일들도 중요하지만 지금은 팀 프로젝트가 더 중요하다고 판단했기

 

이전에 작성해둔 기능 명세서를 기반으로 기능을 개발하기 시작하였는데

모두들 열심히 참여해준 덕에 빠르게 개발이 진행되었다.

 

이번에 이렇게 개발을 하면서 다시금 느낀 감정은

재미있다. 그냥 즐겁다 였다.

너무 재밌어서 시간가는줄 모르고 기능 개발을 했다.

 

그러니깐 기능 하나를 두고 어떻게 구현해야하지? 왜 이렇게는 안될까? 어디서 문제가 발생한거지?

하나하나 그려보고 생각하고 고민한 끝에 결국 해냈을때 나오는 성취감이 정말 좋았다.

 

원래도 그런것을 좋아하는 편이였지만 이번에 다시 경험해보니 정말 즐거운 시간을 보낼수있었다.

물론 하루종일 그것만 붙잡고 있는 편은 아니지만 그래도 하루가 짧게 느껴진건 정말 오랜만이다.

팀의 재구성과 자리 재배치

이번에도 갑작스런 소식이 전해졌다.

그것은 바로 팀원이 교체된다는 소식이였다.

 

그 팀원이 여기서 이루어낸게 많은데 그걸 다 두고 떠난다니 아쉽긴 했지만,

내가 해야할일은 변치 않았기에 별로 신경쓰진 않았다.

 

어떤 일이 있어도 자신이 맡은 직무에 최선을 다해야 한다고 생각하는 편이기에

이는 책임 회피라고 생각했고 이런 일은 조금 지양해야한다는 생각이 들었다.

 

목요일 저녁에는 자리를 재배치 한다는 공지와 함께 팀원들끼리 같은 자리를 쓸수있도록 재배치 되었다.

정든 짝꿍을 보내고 우리 팀원과 함께한다는건 사실 그닥 내키진 않았지만 오히려 항시 같이 있으므로 더 원활하고

빠른 소통과 피드백이 가능하다는 점에서 좋았던 것 같다.

 

이번에도 이루지 못한 계획들

분명 블로그에 글을 쓴다고 했는데 팀프로젝트에 빠져서 글을 쓰지 못했다.

그러니 오늘 바로 노션에 틈틈히 정리한 내용을 정리해서 이 글을 쓰자마자 올려야겠다.

 

또, 책을 읽으려고 친구한테서 책도 빌렸는데

그 마저도 표지도 못넘겼다. 시작이 반이라더니 아직 시작도 못한거 보면 맞는 말인것 같다.

 

다음주는 한발자국 더 나아가야겠다.

팀 프로젝트 일정을 바로잡다.

이번 주에는 정말 많은 일이 있었는데 그 중 가장 큰 것은 팀프로젝트의 균열이다.

 

저번주에 계획했듯 나는 이번 주에도 리액트 공부를 했다.

매일 일정 챕터까지 들으며 노션에 정리하고 학습하는 시간을 가졌다.

 

그러다 수요일쯤 조원 중 한분이 저녁에 긴급 호출을 하였고,

그 자리에서 조장이 본인으로 바뀌었음과, 지금까지 프로젝트에 무엇을 기여했는지에 대한 질문을 하였다.

 

내 입장에서는 할말이 없었다.

팀 프로젝트를 위해서 리액트를 공부했건만 정작 중요한 백엔드 부분의 진행사항은 0%였고,

마지막으로 한건 일주일전에 간단한 CRUD를 하고 커밋한게 전부였다.

 

무엇이 잘못되었던걸까?

내가 생각할 때 여러가지 문제가 있었는데

 

첫째로 팀원들과의 소통 부족으로 각자 팀원들이 어떤 작업을 하고 있는지 몰랐다.

둘째로 처음 계획했던 Jira를 활용한 일정관리는 아무도 사용하지 않아 폐기됐고

셋째로 팀장이 모두 혼자 백엔드 작업을 하였기에 그동안 팀원들에게 내려진 지시가 없었다.

넷째로 팀원들도 프로젝트에 크게 관심이 없었다. 모두 열정적이였지만 그래서 어떻게 해야하나에 대해서는 아무도 답하지 못했다.

 

어떻게 개선하였나

목요일에 정기 회의를 하여 팀 프로젝트의 방향성, 일정이 많이 잘못되었음을 인지하고

이를 바로 고치기위해 짧고 굵게 일정을 다시 조정했다.

 

나의 경우 리액트 공부는 잠시 접어두고 엔티티 설계와 기능 개발을 하기로 하였고,

기간 제한을 두어 정해진 기간안에 기능을 개발하고, 중간 점검의 시간을 가지기로 하였다.

 

또한 팀원들과의 의사소통을 강화하기 위해서 디스코드를 활성화하고, 공지 등의 기능을 활용하여

팀원들 간의 중요한 정보 공유를 하였다.

한주를 마무리 하며.

참 아쉬운 점도 많았고 배운점도 많은 한 주였다.

 

아쉬운 점은 2번째 팀프로젝트 였지만 실질적인 개발은 처음이였기에 나 같이 이러한 팀 프로젝트를 경험한 사람이 있는데 반해

안해본 사람이 더 많았고 나 또한 부족한 점이 많아서 이러한 일정 문제가 생겼었다.

 

팀 프로젝트는 단순히 나 혼자 잘하는게 중요한게 아니라

팀원들과의 소통, 철처한 일정관리, 역할분담 등이 매우 중요하는걸 또 다시 배웠다.

 

처음에는 분명 잘 진행이 되고있다고 생각했지만, 날이 가면 갈수록 계획한대로 되지않았다.

다음 프로젝트 때는 꼭 그러한 부분을 수정하여 진행하자 다짐했었고, 그렇게 시작은 좋았지만

지속적인 관리가 없으면 의미가 없다는 사실을 깨달았다.

 

지금이라도 흐름을 다시 잡고 프로젝트를 진행하고 있으니 마지막엔 좋은 결과가 나올수 있도록 노력해야겠다.

 

즐거웠던 설 연휴

정말 긴 설 연휴가 끝나고 다시 일상으로 돌아왔다.

그동안 일주일 넘게 쉬면서 마음가짐도 많이 느슨해졌고 이참에 다시 한번 정신차리고 되새김을 해야한다 생각했다.

 

설 이전에는 항상 시간이 촉박하다 느껴졌었고, 실제로도 너무 많은걸 하루안에 다 하려고 하다보니 스트레스도 많이 받았다.

이를 해결하기위해 나의 하루, 일주일에 우선순위를 도입했다.

 

예를 들어서 만약 여러가지 일을 계획하였을 때 그 중에서 내가 당장 급하게 이번 주 안에 끝내야할 일이 있다면,

그 일을 1순위로 두고 나머지 일들을 중요도에 따라 나열하여 순서대로 처리한다.

 

이제 여기서 중요한건 그 모든일을 하루만에 끝낼 필요도 없다는 것이고, 그것 때문에 스트레스 받지 않을 수 있다.

그래서 지금 내가 계획했던 일들을 하나하나 쪼개고 분리하여 습관처럼 해야하는 일 빼고 나머지를 정리해보았다.

나의 우선순위

  1. 팀프로젝트 (스프링, 리액트 공부)
  2. CKA 준비 ( 쿠버네티스 자격증 )
  3. 매일 코딩 문제 풀기
  4. 자소서 작성 연습
  5. 개인 프로젝트 꿈.찾.사 보수

지금 내게 있어 가장 중요한건 팀프로젝트이고, 가장 중요하지 않은건 내 개인 프로젝트를 보수하는 일이라고 정했다.

나는 매일 이 모든 일들을 하루만에 다 한다고 생각하는게 아니라 할수 있는만큼, 그리고 여유가 있을때 마다 하기로 정했다.

 

이번주는 우선순위에 맞춰서 스프링과 리액트를 공부하고 팀원들과 회의를 통해서 프로젝트를 조금씩 진행해 나갔다.

CKA의 경우에는 이전까지 공부했던 내용을 다시 블로그에 정리해서 리마인드 하면서 진행하려고 계획했다.

 

이번주에는 비록 내가 맞춰놓은 우선순위와 계획에 맞춰서 진행하지는 못했지만, 그래도 이러한 틀을 세워두니

마음의 여유가 조금 생기고 시간적으로도 여유가 생겼다.

 

강의시간에 배운 내용도 매일 노션에 정리하고 있는데 이 내용을 블로그에 정리해서 올려도 되는지 모르겠다.

이번에 한번 물어보고 강의 내용도 정리해서 블로그에 작성해서 리마인드 하려고 한다.

이 계획도 계획만 세워놓고 또 안할지도 모르겠지만 시작이 어렵지 한번 올리고 나면 꾸준히 올릴거라 믿는다.

 

진로에 대해서 한번 더 고민하다

이번 주에 진로에 대해서 한번 더 고민하는 시간을 가졌다.

친구에게 전화가 와서 네트워크 엔지니어에 관심이 있다면 CCNA 자격증을 따는걸 추천한다 라는 내용으로 전화가 왔었다.

그 친구의 아버지가 그쪽 일을 하시는데 사람이 없다며 너는 관련된 공부를 했으니 한번 도전해보는게 어떻냐 라고 물어보았다.

 

나도 사실 그쪽에 관심이 없는건 아니였다.

군대에서 전산병으로 근무하면서 기사님들의 어깨너머로 본것도 있고,

개인적으로 네트워크에도 관심이 많아서 대학생 때 그쪽 관련해서 자격증 등에 대해서 알아본 적이 있다.

 

하지만 지금의 나는 클라우드나 인프라쪽으로 가기로 정했고, 또 내가 공부한 것 들과 지금 배우고 있는것 앞으로 딸 자격증까지

모두 그쪽이랑은 조금 거리가 있다. 그래서 고민 끝에 지금 내가 가는 길을 가기로 했다.

이 결정을 하면서 이런 저런 생각을 정말 많이 했고, 덕분에 시야가 조금 더 넓어졌다고 생각한다.

 

자소서를 작성하며 부족한 점을 알아갔다

이번 설에 자기소개서를 작성한 적이 있었다.

결국 제 시간안에 완성하지 못해서 제출을 못했지만, 많은 배움이 있었다.

 

글을 작성하고 친구에게 검토받고 다시 작성하고 지우고 쓰고... 반복의 연속이였기에

이번주에도 그에 관련해서 머리속 한 구석에서 생각하고 있었다.

 

그러다 내 자소서의 문제점을 어렴풋이 깨닫게 되었다.

 

나는 보통 자소서를 작성할 때, 이런식으로 작성했었다.

저는 ~프로젝트를 진행해보았고 ~문제점이 있어서 ~해결했습니다.

 

 

그런데 다시 생각해보니 기업에서 원하는건 내가 어떤 프로젝트를 했는가가 아니고

내가 프로젝트를 진행하면서 어떤 문제에 직면했고, 어떻게 그 문제를 해결했는가가 더 중요하단걸 느꼈다.

 

분명 매번 자소서를 쓸때마다 질문에도 적혀있었고 친구도 매번 그 부분을 지적했는데 왜 놓치고 있었을까.

어차피 내가 회사에 들어가도 다 새로 배워야 하는것들 투성이고, 내가 해봤던 프로젝트와 비슷한 프로젝트를 할 가능성도 낮다.

 

회사가 원하는건 어떤 프로젝트를 하던간에 문제를 해결할 수 있는 능력을 가진 사람을 원하는 것이었단걸

팀원들과 소통하고 문제에 대해 고민하고 해결책을 내놓을수 있는 사람을 원했다는걸 알았다.

 

이제서라도 알았으니 다음에 자소서를 쓸 때는 그 부분을 중점으로 써야겠다. 라고 생각하니

이제껏 내가 했던 프로젝트에서 생겼던 문제들과 적을 내용들이 생각이 났다.

 

분명 자리에 앉아서 쓸 때는 생각이 안났고, 실제로 그런쪽으로  고민해본적도 없었는데 새로운 경험이였다.

이번에 배운것을 토대로 계속 글을 쓰는 연습을 하면서 자소서를 준비해야 겠다는 생각이 드는 한 주였다.

 

Ps. 이번에 개인적으로 일기도 작성하고 있는데 하루동안 나의 활동을 되돌아보는 좋은 시간이 되고있다.

2번째 프로젝트의 시작

이번 주부터 2번째 프로젝트가 시작되었다.

이번 프로젝트는 Spring을 활용하여 웹 페이지를 만드는 게 목표인 프로젝트로써

저번 프로젝트가 DB설계만 했다면 이번에는 직접 설계한 DB를 활용하여 실제로 구현하는 프로젝트이다.

 

프로젝트를 하기 앞서 새로운 팀원들과 인사를 나눴는데 이전에도 그랬지만 모두 열정이 넘치는 분들이어서 좋았다.

Spring을 아직 경험해보지 못한 분도 계셨고 이전 직장에서 사용해보거나 나처럼 프로젝트를 진행해 보신 분도 계셨다.

그래서 일단은 설날에 프로젝트에 필요한 Spring을 공부해오기로 하였고 이 기회에 나도 리마인드 하는 시간을 가지기로 했다.

 

프로젝트 구성을 하기전...

이번 프로젝트에선 모두 모여서 이전 프로젝트에서 맘에 안 들었거나 문제가 되었던 부분에 대해서 소통하고 진행하였다.

팀원들은 여러 가지 의견을 내주었고 이러한 분위기가 정말 마음에 들었다.

또한 프로젝트에 대한 아이디어를 각자 한 개 이상으로 상세하게 구상해서 모두에게 발표하는 식으로 선정하였다.

 

회의 끝에 2개의 프로젝트가 남았는데 하나는 일정관리 사이트, 나머지 하나는 팀프로젝트 관리 사이트였고,

최종적으로 팀 프로젝트 관리 사이트가 선정되었다.

 

이전 프로젝트에 대한 기억

이전에 나는 졸업작품으로 Spring을 활용하여 '웹 주문 키오스크 시스템'을 만든 적이 있었다.

이때 우리 팀의 문제점을 생각해 보면

 

1. 버전관리 문제

      -> 모든 프로젝트 파일을 디스코드로 공유했었다.

 

2. 기능 명세서는 있었지만 상세한 API 명세서의 부재

    -> 이 때문에 프런트엔드와 백엔드 사이에서 어떻게 값을 넘겨주고 받을 건지에 대한 정의가 없어서 많은 혼선을 겪었다.

 

3. DB 이름 규칙 부재

   -> DB 이름에 대한 규칙이 정확히 없었기에 서로 다르게 작성하다 마지막 통합과정에서 충돌이나 많은 수정을 해야 했다.

 

4. 처음부터 너무 많은 기능을 설계

   -> 너무 많은 기능을 설계한 탓에 제 기한에 맞추느라 급급했고 완성했지만 미처 공개하지 못한 기능도 있었다.

 

5. Spring에 대한 이해도 부족

   -> 왜 이렇게 써야 하는지, 왜 이렇게 작동하는지 모르고 그냥 이렇게 해야 한다!라고 생각해서 썼던 것들이 많았다.

 

대충 정리하면 이런 문제들이 있었고 이번 프로젝트에서는 같은 실수를 하지 않기 위해 많은 공부를 해야겠다고 생각했다.

 

시작이 반이다

프로젝트를 시작하기 전 팀원들과 많은 이야기를 나누었고 일단 시작하기 전부터 계획을 확실하게 잡았다.

먼저, 위에서 말했던 '처음부터 너무 많은 기능의 설계' 부분에 대한 한계를 정했다.

최소한의 기능 즉, 최소한 우리의 프로젝트가 동작하는 기준치를 설정했고 생각보다 아주 많이 낮췄다.

 

물론 많은 기능을 넣으면 좋지만 우리에게 주어진 시간은 단 2 달이고, 이 안에 모든 걸 완성할 수 있다는 생각은 들지 않는다.

그렇기에 처음부터 최소치를 정하고 이제 모두 완성되고 난 이후에 시간이 남는다면 하나씩 추가하는 방향으로 설정하였다.

 

오늘 친구와 스터디를 하면서 API 명세서를 작성하는 것이 도움이 될 것이라고 배웠다.

아직 팀원들에게 말하진 않았지만 이 부분도 같이 도입하여서 확실한 규칙이나 기능을 설정하면

더 빠르고 효과적인 구현을 할 수 있을 것이라 생각한다.

 

이렇게 프로젝트 초기에 기반을 잘 다져놔야 그 위에 어떤 건물을 지어도 튼튼하고 안정적으로 운영할 수 있다고 생각한다.

그리고 지금까지 배운 것들을 제대로 활용하려면 이 기회에 적용하는 게 맞다고 생각한다.

 

최종적인 목표

처음 팀원들끼리 회의하던 내용 중에 하나는 우리 팀의 최종 목표를 어디까지로 할 것이냐였다.

나와 다른 팀원 2명은 배포까지 하기를 원했고 다른 분들은 Spring에 대해서 많이 배워가는 것이 목표였다.

 

개인적인 생각으로 물론 프로젝트를 진행해서 Spring에 대해 배워가는 건 매우 중요하고 핵심적인 일이라고 생각하지만

마지막으로 배포까지 하면 더 많이 배울 수 있을 것이라 생각한다.

 

그리고 나 또한 이번 프로젝트로 Spring에 대해서 더 확실하게 배워서 성장하고 싶다.

이전에 했던 프로젝트는 삽질 그 자체였지만 이제 삽질한 구덩이에 튼튼한 기반을 세워서 높은 건물을 세우고 싶다.

지금까지 배웠던 것들을 활용하여 성공적으로 프로젝트를 완성하고 배포하는 것이 목표이다.

 

Ps.
아직 부족한 부분이 많지만 그래서 더 좋다고 생각한다.
그만큼 아직 배울 것도 많고 얻을 수 있는 것도 많기 때문이다.

 

이번주에 배운 것

이번 주는 저번 주에 이어 Java에 대해 더 깊이 배웠다.

배열, 오버로딩, 오버라이딩, 상속, 다형성 등을 다루었고,

내가 이해하고 있던 것보다 더 심화된 내용을 배워 많은 것을 얻을 수 있었다.

 

원래 나는 '이 함수는 원래 이런 역할을 하는거지' 하고 사용했지만,

강의에서는 세세한 동작 과정을 알려주어 생각했던 것보다 훨씬 유익했다.

 

예를 들어 예외 처리의 경우, 보통 try-catch문을 사용하지만 특별한 경우가 아니면 해당 오류에 대한 Exception을 할당하거나,

범위가 넓다면 catch (Exception e)로 쓰는 것이 일반적이었다.

 

여기서 왜 catch (Exception e)로만 해도 모든 에러가 잡히는지에 대해

바로 이전에 배운 상속 개념을 가져와서 설명해주시니 구조적으로 이해가 됐다.

덕분에 몰랐던 사실들도 많이 배울 수 있었다.

 

인텔리제이의 오류 해결

Java 실습을 할 때는 항상 인텔리제이를 사용하는데,

처음 인텔리제이를 사용할 때부터 지금까지 프로젝트를 실행할 때 가끔 프리징이 걸려서 강제종료를 해야하는 상황이 발생했다.

강사님 뿐만 아니라 Windows 노트북을 사용하는 모든 수강생들이 불편을 겪었다. (Mac은 해당이 안됐다)

이유를 알 수 없는 오류로 계속 흐름이 끊기는 일이 빈번했는데,

이번에 그 해결법을 찾아 공유하여 다시 쾌적하게 강의를 들을 수 있게 되었다.

이 문제를 해결하지 못했다면 강의를 듣는 내내 인텔리제이에 대한 불쾌감만 더 늘어났을 것 같다.

 

코딩 테스트 연습

원래 대략 2주전만 해도 코딩테스트 스터디 모임이 있었다.

그런데 왜 과거형이냐면 있었는데 갑자기 어느순간 공중분해가 되어버려서 혼자서 매일 따로 문제를 풀고있다.

요즘은 매일 LeetCode에서 일일문제를 풀어 블로그에 게시하고 있고, 하루 종일 고민해도 안풀리면 그냥 솔루션을 보고

내 코드와의 비교 분석과 솔루션을 분석하며 공부하고 있다.

 

한 주를 마무리 하며...

이번 한 주는 저번보다 조금더 알차게 보내고 있다는 생각이 든다.

매일 코테 문제를 풀고, 블로그에 글쓰고, 깊이 있는 강의를 듣고, 또 정리하고...

이번년도는 시작부터 꽤 순항하고 있다는 생각이 든다.

 

ps.
블로그에 서식 기능이 있는거 같던데 서식을 하나로 통일해야겠다.

이번 주 요약

1. 첫번째 팀 프로젝트 발표

30일과 31일일에는 팀프로젝트 마무리 준비 및 발표를 하였다.

팀 명은 DBDB DEEP, 프로젝트 명은 ShowTimeNow이다.

 

이번 팀 프로젝트는 ER-다이어그램을 그려보고 DB를 설계하는데 중점을 두었다

그래서 우리 팀은 영화관을 주제로 삼았다.

 

팀원 중 영화관에서 근무했던 사람이 두 명 있었기에 그 경험과 불편했던 사항을 조합해서 세부적인 내용을 작성해나갔다. 

요즘 영화관에서는 독점 상영을 하는 영화가 늘었기에 이에 초점을 두고 대형 영화 3사의 정보를 취합해 보여주기로 하였다.

그 결과 영화관 통합 예매 시스템을 구축하자는 결론이 나왔고,

그에 맞춰 요구사항 명세서를 작성하고, ERD 설계를 하기 시작하였다.

 

이 과정에서 많은 수정사항과 충돌이 있었지만 서로 상대를 설득하여 잘 풀어나갔다.

덕분에 다른 팀들보다 조금 더 빠르게 일이 진행될 수 있었고 프로젝트는 성공적으로 진행되는 듯 하였다.

 

결론적으로, 프로젝트는 잘 마무리가 되었고 지금 다시 회고해보면 좋았던 점과 개선해야할 점이 보였다.

 

좋았던 점

1. 우리 팀원 중 한분께서 DB를 AWS에 올려 모두 하나의 DB에서 작업할 수 있게 설정해주셨다.

   - 이는 매우 중요한 부분으로 모두 같은 DB를 공유함으로써 팀원 모두가 동일한 DB로 작업할 수 있었다.

2. DB의 모든 동작을 프로시저로 만듦으로써 SQL문의 관리와 시연이 매우 편리했다.

  - 또한 이 프로시저를 요구사항 명세서에 같이 정리함으로써 매우 쉽게 추가된 기능을 확인할 수 있었다.

개선해야할 점

1. 확실한 리더가 없었다.

  - 프로젝트의 가장 중요한 리더가 딱히 없었기에 의견이 충돌나거나 병합해야할 때 어려움을 겪었다.

    실제 리더와 실질적 리더가 달랐고, 이로인해 혼선이 생기기도 했다.

2. 주제에 대해 실제 가능한 프로젝트인가 생각해봐야 했고 확실한 차별점이 있어야했다.

  - 영화관을 통합한다고 했으면 영화관 통합만 되야하는데 매점이라는 부가기능을 넣음으로써 매점이 영화관에 종속되어버렸다.

    실제로는 영화관마다 매점이 다를것이고 영화 / 매점은 서로 완전히 다른 객체이지만 이를 한데 묶은것은 실수였다고 생각한다.

3. 역활이 올바르게 분배되지 않고 치우친 부분이 있었다.

  - 역활을 나눌 때 ERD를 보고 테이블별로 역활을 설정했는데 내 경우 예약과 좌석 테이블을 맡았기에 상대적으로 할일이 적었다.

    하지만 다른 조원들은 그보다 더 많은 작업이 필요했고, 절대적인 작업량에서 차이가 났기에 나는 맡은 부분을 끝내고

    다른 팀원을 도와서 작업을 진행하였다.

4. ERD가 잘 작성되었는지 확실하지 않다.

  - 우리 팀 모두 ERD 테이블에 대해서 그렇게 잘 아는편이 아니라서 많이 알아보면서 작성하긴 했지만

    최종 결과물에도 분명 문제는 있다. 특히, 관계설정에서 많이 애를 먹었다.

    나 또한 이게 잘못되었음을 인지하였지만 조원들을 설득할 만큼 알고있지 않았기에 어찌할 수 가 없었다.

5. 발표 시에 PPT를 준비하지 않고 깃허브에 올라간 README를 보고 발표했다.

  - 다른 팀들이 발표하는것을 보고 많이 주눅들었었다. 우리팀이 그리 못한건 아니라고 생각하는데 적어도 발표를 한다면

    PPT라도 하나 만들어서 그걸로 발표하는게 맞았던것 같다. 

6. 기능 명세서에 완료/보류/폐기 를 같이 정리하면 좋을 것 같다.

  - 다른 팀원들의 발표를 보니 그런식으로 기능 명세서에 생각나는 기능을 모두 적고 상태를 따로 표시하여 정리하였다.

    이렇게 하면 다음에 기능을 수정할 때 많은 도움이 될 것 같다.

 

그리고 발표가 끝나고 강사님이 피드백을 해주셨고 정리해보자면 다음과 같다.

- 이러한 비슷한 기능을 가진 시스템이 존재하지 않는가?

- 멤버십 할인도 추가하면 좋을 것 같고 할인에 대해서 좀 더 고민해보면 좋을 것 같다.

- DB는 직접 다 등록했겠지만 실무에서는 회사 등 에서 지원하는 API를 통해 DB를 삽입할것이다.

- 프로시저를 사용한것은 좋은 선택이였다.

 

이번 프로젝트는 정말 많은 것을 배웠고 다음 프로젝트때는 이보다 더 확실하게 준비하고 싶다.

위의 개선사항들을 모두 종합하여 아쉬움이 남지 않는 프로젝트를 진행하고 싶다.

깃허브
 

GitHub - beyond-sw-camp/be13-1st-DBDBDEEP-ShowTimeNow

Contribute to beyond-sw-camp/be13-1st-DBDBDEEP-ShowTimeNow development by creating an account on GitHub.

github.com

2. JAVA 기초 학습

JAVA 기초에 대해서는 거의 다 알기때문에 특별할건 없지만,

인텔리제이 얼티밋을 6개월동안 제공해주셔서 사용해보았는데 생각보다 엄청나게 편리했다.

 

이를 활용해서 더 확실하게 JAVA의 기초를 쌓아가야겠다.

 

마무리 하며...

어느덧 24년이 끝나고 25년이 되었다.

24년은 정말 다사다난한 해 였고, 많이 배우기도 했다.

25년에는 내 기반을 더 열심히 갈고닦아서 꼭 취업하고 싶다.

 

ps.
이번에 교과목 평가도 봤는데 1등이랑 2문제 차이가 났다.
기초적인걸 틀리다니 아직 더 공부해야겠다.

어느덧 3주 차에 접어들었다.

이번주는 MariaDB를 리눅스에서 사용하는 방법과 Git의 사용법, 소프트웨어 공학에 대한 기초를 배웠다.

그중 Git 사용법에 대해 배웠던 것에 대해 이야기해보려고 한다.

 

Git이란

소스코드를 효과적으로 관리하기 위해 개발된 분산형 버전 관리 시스템이다.

나도 이전에 몇 번 Git을 사용하기도 했고 이를 활용해서 버전 관리를 하고 백업도 하는 식으로 유용하게 썼었다.

이전에 알고 있던 건 단순히 Git에 커밋하거나 복사하는 방법만 알고 있었다.

 

무엇을 배웠는가?

이번 시간에는 SourceTree를 활용하여 Git의 세부 기능들에 대해서 배우게 되었다.

Git에는 단순히 소스코드를 올리는 커밋뿐만 아니라 올라간 소스코드에 대한 버전관리를 할 수 있는 기능이 있다.

여기서 중요한 기능은 독립적인 저장소를 생성하는 브렌치라고 생각한다.

이를 활용하여 여러 개발자들이 동시에 다양한 분기를 나눌수 있는 기능이 있다.

 

여기서 Git frow를  사용해서 브렌치를 마스터, 개발, 기능,  릴리즈, 핫픽스 등의 브렌치로 나눠서 버전을 관리할 수 있는데

충돌이나 커밋 초기화, 폐기, 합치기 등등 관리 방법을 배웠다.

이를 활용하면 좀 더 체계적인 프로젝트 관리를 할 수 있다.

 

어떻게 활용할 수 있을까

이번에 배운 Git의 세부기능들을 활용해서 현재 관리 중인 꿈찾사 프로젝트나 앞으로 진행할 프로젝트에 적용시켜서

버전 관리를 더 효율적으로 할 수 있을 것 같다.

특히 꿈찾사 프로젝트의 경우에는 1인 개발이긴 하지만 실제 배포중이므로 개발중인 브렌치와 메인 브렌치를 나누면 더  효율적으로 관리할 수 있을것이라 기대된다.

 

그 외

이 외에도 소프트웨어 공학 기초는 이론적인 부분에 대해서만 배웠는데

이건 사실 이론보다는 실제로 이런 상황을 겪어보는게 가장 중요하다고 생각한다.

그래서 이미 정처기나 학부생때 배우기도 했어서 머리에 잘 들어오진 않았다. 

 

ps.
아무튼 이렇게 또 한주가 마무리 되었고 이제 다음주면 2024년도 끝이난다.
이 번 한해도 잘 마무리 하고 2025년도 이보다 더 유익하고 즐거운 시간이 되었으면 좋겠다.

회고를 하기 앞서...

아직 부족한 회고록이였지만 우수 회고자 선정  감사드립니다.

앞으로 더욱 좋은 글을 쓸수있도록 노력해야겠습니다.

이번 주 요약

이번 주는 저번 주 말에 했던 MariaDB의 진도를 계속 나갔다.

다음주면 MariaDB도 끝날 것 같다

 

첫 주에 DB를 배울 때를 생각해보면 나는 아는 지식에 더해서 배운다고 생각했었는데

생각보다 나는 모르는게 많았던 것 같다... 하나하나 다시 머릿속에 집어넣고 있다.

 

이번 주에는 가장 중요하다 했던 JOIN에  대해서 배웠는데

역시 JOIN이 추가되니 SQL을 배우고 있다는 느낌이 확실히 들었다.

수업시간에서 가장 좋았던건 역시 강사님이 수업시간 마지막 마다 문제를 내주시고

그걸 스스로 풀어보는게 이해하는데 도움도 되고 좋았던 것 같다.

팀 프로젝트의 서막

이번 주 부터 팀 프로젝트를 위한 팀이 구성되고 본격적으로 프로젝트를 시작하게 되었다.

기한은 12월 31일까지, 결과물은 내가 이해한 바로는 서비스를 하나 만들어서

그에 대한 요구사항 명세서와 ERD를  작성하는 것이다.

 

이 이야기를 듣자마자 처음 팀 프로젝트를 할때가 생각났다.

그때도 분명 요구사항 명세서 작성하고 ERD 작성하고 했었지... 참 어려웠는데...

이번에도 똑같았다. 명세서 작성은 쉽지 않았고 그것보다 어려운건 ERD 작성...

가장 어려운건 테이블 끼리의 관계와 정규화를 맞추는게 가장 어려웠다.

 

물론 아직 다 완성된 것 도 아니고 아직 한참 수정해야하지만

솔직히 지금 다시 보면 이전에 작성한 것들 모두 싹 갈아엎어야 한다고 생각한다.

가장 중요한 주제선정이 제대로 안된 것 같아서 이 부분을 해결해야 한다...

 

이번 프로젝트 회의를 하면서 좀 아쉬운건 정규화나 테이블 연관관계에 대해서 실습을 할 기회를

조금 더 많이 마련해줘야 했지 않나 그런 생각이 들었다.

아직 수업이 끝나지 않았지만 이에 관련해서  명세서의 중요성이나 ERD 테이블에 대해 좀 더

깊이있는 실습과 예제가 더 주어져야 했다고 생각한다.

기억에 가장 남는 것

금요일에 배웠던 인덱스 시간에 MySQL의 공식 DB를 사용하여 인덱스를 생성해보는 예제는 정말 기억에 남았다.

특히 MySQL 공식 DB의 양이 생각보다 엄청나게 방대해서 이걸로 실습 해보는 것은  정말 좋은 경험이였다.

물론 DB가 몇만개가 넘지만 이것 가지고도 유의미한 성능차는 알 수 없었지만,

그래도 이정도 양을 테스트 할 기회가 얼마나 있겠는가?

 

이에 대해서는 나중에 블로그에 자세히 기록할 예정이므로 필요한 사람은 보고 실습해봐도 좋을 것 같다

이번주를 마치며

이제  2주가 되었는데  이 쯤 되니 이 생활이나 환경에 조금이나마 익숙해진 것 같다.

매일 정시에 일어나고 똑같은 장소에서 수업을 듣고 점심을 먹고 회의 하고 집에 돌아오는 삶

내가 원했던 생활과 조금은 가까워지지 않았을까.

 

이전에는 그렇게 정해진 활동 없이 유유히 시간을 보내기만 했지만 (물론 그렇다고 놀기만 한건 아니다)

매일 수업을 듣고 잠자리에 들 때면 많은 생각을 하곤 한다.

내가 왜 여기에 있는가. 나는 왜 이곳에서 이러고 있는가.

내일은 더 나은 생활을 해야지 하고 눈을 감는다.

 

내가 여기에서 경험 하고 얻을 수 있는건 모두 얻어가고 싶다.

그러기 위해 여기까지 온거니깐.

 

ps.
이번에 자격증 공부를 위해 'AWS 공인 솔루션 아키텍트 스터디 가이드' 라는 책을 빌렸는데
내 생각보다 훨씬 어려운것 같다... 그래도 도전해봐야지.

+ Recent posts