프리코스 시작 전

프리코스 시작 전, 그 전 기수의 프리코스 진행방식을 미리 파악해보고 미리 목표를 세우게 되었다. 목표는

1. 구현 과정을 자세히 기록하기
2. 코드 리뷰 열심히 하기
3. 궁금한 점이 생기면 바로바로 알아보기

이렇게 3가지였다. 각각에는 나름의 이유가 있었는데

1. 구현 과정 자세히 기록하기

   구현 과정을 자세히 기록하는 과정은 제출한 이후에 내가 왜 이렇게 구현했는지 다시 생각해보기에 굉장히 좋은 방법이었으며, 다른 분들이 나의 코드를 리뷰할 때 이해하기가 굉장히 쉬워지는 방법이라고 생각했다. 또한 구현 과정을 정리해가면서 중간에 헷갈리는 순간이 왔을 때 읽어보며 도움을 받을 수 있었다.

2. 코드 리뷰 열심히 하기

   다른 사람들의 코드를 보며 알아가는 것이 많다는 생각을 하게 되었다. 다른 사람의 코드를 수월히 읽을 수 있다는 것, 그리고 배워갈 수 있다는 것도 스킬 중 하나라고 생각했다.

3. 궁금한 점이 생기면 바로바로 알아보기

   나는 그동안 궁금한 점이 생기면 AI의 도움을 받거나, 대충 알아본 후에 넘어갔던 것 같다. 하지만 이런 목표를 세우며 딥다이브를 계획하였다.

이번 8기 프리코스 1~3주차는 다른 기수와 동일하게 미션 제출 -> 코드 리뷰(자율)로 진행되었다.

매 주차별로 notion에 위와 같이 구현과정을 자세히 기록하여 리드미에 넣었고, 다른 분들의 코드리뷰도 진행하고자 꾸준히 디스코드에 글도 올리고, 서로 리뷰하는 등 활발하게 활동하려고 노력하였다.

주차별로 미션 수행하면서 궁금해진 부분이 있으면 정리해서 디스코드에 올려보기도 했다.

프리코스 1주차

1주차 레포

1주차 문제를 보고 은근 간단하면서도 어렵겠다는 생각을 했다. 문제를 봤을 때, 정규표현식으로 풀면 정말 간단한 문제인 것 같다고 생각이 들었지만, 객체지향 프로그래밍을 연습해보고자 하였기 때문에, 이 방식으로 만드는데 조금 어려움을 느꼈다.

결국 결과물은 뭐랄까... 객체지향이라고 해야돼...? 싶은 결과물이 완성되었고, 다른 분들의 코드를 리뷰해보며 예외처리에 많은 부족함을 느낄 수 있었다.

++ 회고를 하려고 다시 보다보니 리뷰에 대한 답변이 pending 상태인걸 발견했다... 내 답변들.. 지금 보내면 놀래실테니 그대로 냅두자ㅠㅠ

프리코스 2주차

2주차 레포

2주차의 경우에는 나름 만족스러운 결과물이 나오긴 했지만, 아쉬운 점은 제출할 때 써놨듯이, 목표로 했던 객체지향을 완벽하게 하지 못하고, 일부 절차지향을 사용했다는 것이다. 다른 분들과 코드리뷰를 어김없이 나눠보면서 얻은 피드백은

• 상수처리
• 책임 분리
• 캡슐화

이렇게 정리할 수 있었다. 특히 재밌는 미션이었어서 코드 리뷰를 굉장히 많이 진행했던 것 같고, 의미있는 의견 교환도 시도할 수 있었다.

캡슐화를 위한 프라이빗 필드, 메서드 사용은 이 때 많은 분들이 사용하시는걸 보면서 필요성을 많이 체감했다.

또한 jest 테스트 시간이 매번 이상해서 알아보고 디스코드 채널에 올려보았다.

jest 테스트 시간

프리코스 3주차

3주차 레포

1,2주차를 진행하며 객체를 만들 때 매번 객체 생성하는게 너무 귀찮았던 나머지... 그리고 왜 해야하는지 이유를 체감하지 못했던 나머지 상태를 가지지 않는 객체들은 모두 static으로 변경하였고, 결론적으로 정적 메서드로만 만들어진 결과물을 만들게 되었다.

관련된 글도 남겨놨었다.

그리고, 먼저 제공되었던 파일에 private 필드가 사용되어서, 사용해보는 경험을 할 수 있었는데, 위에 써놨듯이 그렇게 잘.. 사용할 수 있는 결과물이 아니었기에 완벽한 경험에는 실패했다.

이 때 좀 신랄한 리뷰를 많이 받았던 것 같고, 이 방법의 장단점에 대해서도 많이 고민해봤던 것 같은데, 이 과제를 한 이후에 다른 분들의 작업물을 보고, getter setter 메서드에 대해서도 많이 학습해봤던 것 같다.

오픈미션

이번 8기부터 새롭게 도입되었던 미션으로, 내가 진행한 내용은 디스코드 봇이다.

오픈미션 레포

오픈미션 대시보드

정말 처음보는 discordjs라는 라이브러리 사용에 도전하였으며, 웹에만 치중되었던 경험을 봇이라는 새로운 분야에 도전해보며 확장시킬 수 있다는 점에서 괜찮은 시도인 것 같다 생각이 들어 시작하게 되었다.

또한 도전이라는 키워드에 걸맞는 부분 2가지를 추가로 시도하였는데,

1. 봇의 상용화 기존 봇은 환경변수에 우리가 사용할 서버의 아이디를 넣어 사용하였는데, 다른 서버에서도 이용 가능하도록 변경하였다. 이게 왜 도전이냐면

   • 다른 서버에서 사용하기 위한 데이터 테이블 추가 생성

   • 서버 세팅 command 추가

     이걸 했어야했는데 우리는 FE 2명이었기 때문이다... 특히 db 세팅을 내가 담당하였고, 추가할 때 세팅을 해야하는 것도 나였기 때문에 부담감이 조금 있었다. 그래도 차분히 어떤 데이터가 필요한지 함께 미션을 진행한 크루분과 이야기해가며 만들어나갔던 것 같다.

2. 대시보드 생성 대시보드는 이 디스코드 봇 안에서 한 활동을 볼 수 있는 웹페이지를 만드는거였는데, 웹이면 해오던거 아니야? 하는 의견도 있을 수 있다. 하지만 시작했던 시점이 제출을 며칠 앞두지 않은 시점이라는 것을 감안하면 정말 큰 도전이라고 할 수 있다.

기능 확장 관련 정리 문서

리드미에 넣을 문서도 정말 꼼꼼히 작성하였다. 프리코스 내내 문서화에 대해 계속 고민해왔었고, 문서화를 제대로 하는 것이 기능 개발의 마무리라고 생각했기 때문에, 정말 꼼꼼히 하려고 노력했다. 추가로 아침마다 동료분과 데일리 스크럼을 진행, 각자 개발일지도 작성하면서 서로가 얼마나 진행하고 있는지 계속 확인했다.

작성한 오픈미션 노션

이렇게 오픈 미션을 완료하고, 봇을 배포한 다음 같이 미션을 진행한 여빈님과 함께 모각코 서버에서 잘 사용하고 있다.

1차 결과

오픈 미션 제출부터 1차 결과까지는 한달 이상의 시간이 남아있었다. 이 시간동안 나는 다른 면접도 보고, 쉬는 시간도 가지며 결과를 기다렸다.

결과는 합격!

합격 메일을 받기 전까지 아.. 붙지 않을까? 나 정말 열심히 했는데? 하는 생각과 그래도 이 많은 사람들 중에서 내가 붙을 수 있을까?하는 생각을 가지고 있었다. 결국 1차를 붙어 최종 코테를 가게 되면서 아 열심히 한만큼 정말 좋은 결과가 있었구나 싶은 생각이 들었고, 바로 최종 코테 준비를 시작하게 되었다.

최종 코테 준비

최종 코테 준비 전에 깃허브를 돌아다니면서 이전 기수 기출문제들을 찾아보기 시작하였다. 나는 FE에 지원하였기 때문에 특정 기수 이전의 문제들은 HTML이 함께 나오는 문제들이 나왔었고, 이런 문제들의 경우에는 BE 문제들을 가져와서 풀었다.

최종 코테 준비 레포 (현재는 비공개)

하루에 한문제 이상은 기본으로 풀려고 노력하였고, 시간은 오픈미션 때 만들어놓은 디스코드 봇을 사용하여

이런식으로 시간을 잴 수 있었다. 물론 언제부턴가 음성채널에 누적시간이 표시되기 시작하긴 했지만, 우리가 만든 봇을 사용해서 시간을 잴 수 있다는건 좋은 경험이었다.

그리고 공부시간도 확인할 수 있는 것!! 음성채널을 사용하지 않은 시간들도 있어서 확실한 시간은 아니지만 그래도 그 때의 기록을 확인할 수 있다는 것도 너무 좋았다.

개발 공부를 시작하고 처음으로 AI없이 1부터 10까지 내가 구현하는 연습을 시작하였다. 처음에는 객체지향 프로그래밍의 사용 이유조차 체감하지 못했고, 함께 오픈 미션을 진행했던 여빈님에게 물어보고, 계속 구현 연습을 해나가면서 많이 발전하게 된 것 같다.

실제로 1차 합격을 확인하고 바로 풀었던 온보딩 미션들의 코드를 지금 보면 많이 개판이다.

3주차 로또 미션처럼 여전한 static 사랑을 엿볼 수가 있다...

어떻게 풀어야하는가?

편의점 문제 도전

어느정도 감을 잡았던 시점은 편의점 문제에 도전하면서부터였다. 편의점 문제는 7기 4주차 문제로 꽤 악명이 높던 문제였는데, 그 전까지는 뭔가 데이터를 가지고 있는 개체 생성의 필요성을 체감하지 못했다. 하지만 이 문제는 이 부분이 필수적이었고, 지금 되돌아보면 부족한 점이 많지만, 그래도 구현할 수 있었다는 것 자체가 큰 발전이었던 것 같다.

편의점 구현 과정 기록

출석부 문제 도전

편의점 구현에 성공하고 며칠이 지난 후, 7기 최종코테 문제에 도전하게 되었다. 실전 경험을 한다 생각하고, 시간을 재면서 했는데 5시간 안에는 무슨 3시간을 지나갈 때 아예 파일들을 다 삭제해버리는 일이 생겼다. 결국 구현을 2번 갈아엎고, 3번째를 시도하기 전에 집에 갔는데 집 가는 길에 그 차가운 길바닥을 걸으며 (당시 밤 10~11시 경) map을 사용하여 구현하는 방식에 대해 생각해보게 되었고, 이 방식을 사용하며 풀 수 있었다.

당시 고민의 흔적들....

그리고 생각보다 디버깅에 시간을 많이 쏟았고, 한번 감이 잡혔을 때 바로 구현 성공해야겠다는 생각에 결국 새벽에 완성하였다.

ㅋㅋㅋㅋㅋ 새벽에 구현 완료한 후 소리지르면서 pr올리고 잠들었던 기억이 있다.

그래서 결론은?

어떻게 풀어야 더 쉽고 효율적이고 빠르게 풀 수 있는가에 대해 계속해서 고민을 했었다. 결론은

1. 설계를 꼼꼼히 한다.
2. 배열 그만 사랑하자.

이렇게 내리게 되었다. 1번은 그렇다 치고 2번은 왜? 싶을 수 있는데, 자바스크립트를 처음 공부하면서 알고리즘 문제를 풀기 시작했을 때, 나는 배열을 정말 사랑했다. 다른 자료구조를 사용할 생각을 하지 않고 배열만을 사랑했기에, 이 배열만으로 풀기가 힘든 문제들에서 벽을 마주하게 되었던 것 같다.

편의점 문제를 통해 obj를 사용하는 방법, 출석부 문제를 통해 map을 사용하는 방법을 공부하게 되었고, 배열만을 사용하던 기존 방식을 버려야겠다는 확신이 들게 되었다.

설계 방식의 변화

프리코스 초반에 디스코드에 설계에 대한 내용이 올라왔었다. 그에 대한 나의 답변은 이러했다. 그리고 최종코테를 진행하면서도 설계에 쏟는 시간이 점점 길어졌고, 5시간 중 2시간 이상을 설계에 쏟을 정도로, 생각을 많이 해보게 되었다.

연습 초반

초반에 연습한 미션들은 사실상 설계를 진행하지 않았다. 리드미에 구현할 기능 체크리스트를 작성하면서 순서를 결정하였고, 그냥 냅다 들이대는 방식을 사용했었다. 그나마 설계를 했다 할 수 있는 내용은 이런 내용이다.

음... 그냥 프로그램 순서 정도...? 만들 파일 정도...? 정리했다고 보면된다.

연습 후반

연습 후반에는 손으로 쓰지 않으면 설계가 진행되지 않을 정도로 설계에 많은 시간을 쏟았고, 그만큼 구현에 쓰이는 시간이 많이 줄었다.

연습의 기록들....

단순 프로그램 실행 순서 뿐만 아니라, 사용할 자료 구조, return할 결과 내용에 대해서도 미리 생각해보고, 생성할 파일들도 생각해보게 되었다.

학습 방식의 변화

최종코테를 준비하던 그 기간이 내가 개발을 공부하며 가장 프로그래밍 그 자체에 몰입했던 시간이 아닐까 생각하고 있다. 또한 궁금한점이 생기면 알아보고, 이야기해보면서 프로그래밍 자체의 많은 부분을 알아갈 수 있었다.

MVC 패턴에 대한 글

그 예시로 들 수 있는 글은 이 글인데, 읽어보면 알 수 있듯이 모르는 부분에 대해서 자세히 찾아보고, 다른 크루와 이야기도 나눠보고, 상의해보면서 결론에 도달하는 재미를 많이 느낄 수 있었다.

최종코테

최종코테 날 오히려 긴장을 덜 한채로 시험장에 도착했다. 약간 따수운 느낌의 우테코 교육장이 나왔고, 우테코스러운 가글이 있어서 찍어봤다.

시험볼 자리를 확인하고, 세팅을 한 뒤 계속 스트레칭을 하고 화장실을 가면서 준비를 했다. 오히려 시험 시작하기 3분 전에 갑자기 더워져서 안에 입은 옷을 벗어야 하나 고민하게 되었다....

코테 후기

어떤 문제가 나올지 긴장하며 문제를 확인했는데, 상당히 익숙한 문제가 나와 반가웠다. 그리고, 새로 생긴 도전 미션을 확인하게 되었다. 익숙한 문제였기에, 도전 미션을 반갑게 맞이할 수 있었고, 빠르게 구현한 후에 어떻게 도전을 해볼지 고민해보기로 하였다. 사전 목표로 세웠던 내용을 공유해보자면

1. 리드미를 꼼꼼히 작성하자
2. 일단 돌아가는 프로그램을 만들자.
3. 도전과제를 충실히 수행하자.
4. 객체지향 프로그래밍을 하자.

이렇게 사전 목표를 세우고 들어갔다.

구현

사전 설계를 완료하고, 구현을 하는데 초반부터 약간 멘붕이 왔다. 테스트 케이스 2번을 도저히 통과를 못 시키겠어서... 멘탈이 흔들렸지만, 이 부분을 리드미에 기록해둔 뒤에 다른 방식을 사용하여 통과시켰다. 추후 이 부분에 대해서는 공지가 올라왔다.

구현을 1차로 완료한 다음, 디버깅을 하며 생겼던 문제점인 결과 출력에 대해서도 리드미에 기록하고 해결한 다음 테스트 통과를 확인하였다.

도전 과제

도전 과제로는 크게

• 리팩토링
• 기능확장

이렇게 2가지가 제시되었다. 그리고 나는 둘 다 진행하기로 하였다. 리팩토링의 경우, 프리코스 초반 3주동안 받았던 피드백인 상수화, 프라이빗 필드 및 메서드 사용을 목표로 하여 리팩토링 하였다.

리팩토링을 완료한 다음, 테스트코드에 영향이 가지 않게 추가 기능을 구현하는 방식에 대해 고민을 해보았고, 테스트 코드를 분석 -> 영향이 가지 않게 추가하는 방법을 알아낸 다음에 추가 기능을 구현하였다.

처음에는 수동 구매와 등수 계산 조건 입력(현재는 제시되어 있음)을 생각하였고, 시간 관계상 수동 구매에 대한 내용만 진행하게 되었다.

제출

결과를 제출하기 3분 전에 추가 기능 구현이 완료되었고, 테스트까지 완료되었다. 추가 기능 구현에 들어간 시간도 그렇게 여유가 많은 상황이 아니었기에, 고민을 많이 하였지만 도전이라는 말에 걸맞게 도전!을 외치며 추가 기능 구현에 들어갔었다.

제출 10분전부터 안내가 나왔는데, 난 여전히 디버깅 중이었고... 정말 제출 직전에 추가 구현한 부분까지 실행이 되어 바로 제출하였다.

제출 후에 예제 테스트 실행 버튼을 누르고 얼마나 긴장했는지... 2/2 뜨자마자 너무 기뻤다. 테스트 결과를 확인하고, 내가 어떤 마음가짐과 의도로 이렇게 작업을 하였는지, 프리코스 동안 어떤 생각을 했는지 소감문에 작성하고 홀가분한 기분으로 시험장을 나왔다.

프리코스 종합 후기

우테코 프리코스는 나에게 정말 큰 도전이었다. 아 그냥 해보면 되지 라는 생각이 아닌 제대로 된 공부를 해보고 싶다 라는 생각으로 시작하였고, 실제로도 1~3주차 미션, 오픈미션, 그리고 최종코테까지 새로운 지식과 프로그래밍 스킬 습득으로 꽉 찬 시간을 보냈던 것 같다.

이제 최종 코테까지 끝나서 결과를 기다리는 시간이지만, 하고 싶은 것들은 더욱 많아진 상태고 오픈 미션에서 만들었던 봇의 추가 개발을 진행하고 있다.

프리코스에서 끝나지 않고, 최종코테까지 갈 수 있어서 최종코테 준비라는 큰 학습의 기회를 얻었던 것도 지금 되돌아보면 큰 행운이었던 것 같다. 결과가 어떻게 되든 앞으로도 이런 태도를 가지고 발전하는 사람이 되었으면 좋겠다.

추가로 오픈미션부터 최종 코테까지 함께 해준 동료분에게 감사의 인사를 드리고 싶습니다!!!!

합쳐서 10시간 5분ㄷㄷ

1차 설계

처음 문제를 보고 설계한 내용은 그렇게 복잡하지 않았다.

1. products, promotion 받아옴 -> 날짜 비교 -> 저장
2. 보유한 상품 출력 -> 구매할 상품, 수량 입력
3. 입력된 내용 형식 오류 검증
4. 재고 수량 확인 -> 프로모션 재고 모자라면 계속 진행 여부 확인 후 다음
5. 프로모션 가능한 제품이 있으면 증졍 여부 확인 후 다음
6. 수량이 없거나 재고가 없는 제품이면 오류 처리
7. 모든 단계 완료되면 멤버십 여부 확인
8. 멤버십 처리 후 결과 출력

이 순서에 따라서 책임 분리를 하였고, 정리하면 다음과 같다.

View

• InputView(사용자 입력 처리)
• OutputView(출력 처리)

Controller

• Controller(메인 컨트롤러, 입출력 처리 및 종합적인 처리 담당)

Model

• Store(상품 재고)
• Customer(사용자 정보)
• Worker(사용자 내용과 상품 재고 상호작용)
• Calculator(결과 도출)
• Validator(검증)

Controller에서 메인을 담당하게 되며, Worker가 Store와 Worker 사이를 상호작용하는 방식으로 설계하였다. 하지만 여기서 막히게 된 문제가 있었으니 미션 내용을 확인해보면

미션 내용

• 재고가 있는지 확인
• 재고가 있으면 프로모션 적용 가능한지 확인
• 프로모션 적용 가능한데 증정품 있으면 증정품 받을지 확인
• 프로모션 적용 가능한데 불가능한 부분이 일부 있으면 구매할지 확인
• 프로모션 적용 불가능만 있으면 그냥 구매처리

이렇게 나뉜다. 단순히 재고 처리에서만 이 내용이 나오게 되는데, 여기서 하나하나 로직이 굉장히 복잡한데

case 1) 증정품 있는 구매

1. 프로모션 적용되는 재고 가져옴
2. 그 재고가 구매하고자하는 재고보다 크면
3. 해당 프로모션에 대한 정보 가져옴
4. 해당 프로모션에 대한 증정품이 추가로 있다면
5. 사용자 input으로 증정 여부 입력
6. 증정 여부 yes면 증정하고, 구매 개수 추가
7. 증정 여부 no하면 증정 안함

case 2) 프로모션 일반 구매

1. 프로모션 적용되는 재고 가져옴
2. 그 재고가 구매하고자하는 재고보다 크면
3. 해당 프로모션에 대한 정보 가져옴
4. 해당 프로모션에 대해 정확한 개수(2+1이면 3배수)를 구매하고자 했다면
5. 구매 처리

case 3) 프로모션 재고 부족 구매

1. 프로모션 적용되는 재고 가져옴
2. 그 재고가 구매하고자 하는 재고보다 작으면
3. 프로모션 재고 부족한데 구매할건지 사용자 입력 받음
4. Yes면 프로모션 재고 소진 후 일반 재고 소진
5. No면 구매x

case 4) 프로모션 적용 안된 구매

1. 프로모션 적용되는 재고 가져옴
2. 프로모션 적용 재고 없으면
3. 구매 처리

case는 4개로 정리되었지만 내부에 사용자 입력 후, 나뉘는 case까지 합치면 총 6개가 된다. 그리고 view 계층 즉, 사용자 입력 처리를 controller에서 해야하기 때문에 이 나뉘는 갈래들을 worker에서 해결하고자 했던 나에게는 적절하지 않은 방식이었다.

2차 설계

일단 구매 품목마다 purchaseManager를 생성하는 방식으로 변경하였다. 그리고 return하는 내용 안에 이 구매 정보가 어디까지 진행되었는지 저장하도록 하였다. 근데 또 문제가 발생했는데, purchaseManager를 worker에서 생성하도록 되어있고, 그러면 input을 controller에서 받아서 처리해야되는데, input을 받은 다음의 로직 진행 여부를 manager에서 관리할 수가 없다는 것이었다.

3차 설계

일단 케이스에 따라 나뉘는 구매 진행 단계를 정리하였다. 그리고 return하는 내용은 다음과 같이 정리하였다.

{ 진행된 단계,
상품 이름,
구매 개수,
증정 개수 }

이렇게 정리하였다. 그리고 input을 받아서 -> 진행된 단계를 확인하고 -> 해당되는 단계의 로직을 진행하도록하는 방식을 사용하였다.

상품 하나 구매 진행 단계

구매 상품 하나에 대한 진행 단계를 정리하면 다음과 같다.

1. 구매 상품 하나에 대한 정보 입력 받음
2. 해당 정보 중 상품 이름, 개수를 바탕으로 purchaseManager 생성
3. input 없는 상태에서 단계 확인 로직으로 이동
4. input이 없으면 처음 단계 진행
5. 해당 상품에 대한 information 받음
6. 재고 있는지 확인(프로모션, 프로모션x 재고 합쳐서)
7. promotion 재고가 구매 재고보다 작거나 같은지 확인 7-1. 작거나 같고, 증정품 있으면 command 'check-free'로 설정 후 return 7-2. 작거나 같고, 정확한 개수 구매 가능하면 command false로 설정, 결과 return 7-3. 크고, 프로모 재고 있으면 command 'check-promo'로 설정 후 return 7-4. 크고, 프로모 재고 없으면 command false로 설정, 결과 return
8. 7-2와 7-4는 완료 처리
9. result를 바탕으로 command에 따라 입력 받고, worker의 reprocess로 보냄
10. purchaseManager의 단계 확인으로 보냄
11. command와 input결과에 따라 각자에 맞는 메서드로 이동 11-1. 'check-free'에 true면 증정품 받음, 결과 return 11-2. 'check-free'에 false면 증정품 안 받음, 결과 return 11-3. 'check-promo'에 true면 프로모 적용 안되는 부분도 구매함, 결과 return 11-4. 'check-promo'에 false면 구매 안함, 결과 return
12. 결과를 바탕으로 설정된 재고 구매처리
13. 결과를 바탕으로 설정된 고객 구매 정보 저장

이게 고객 1명의 구매 요청 내역 중 구매 상품 '하나'에 대한 내용이다.

종합 control

1. 상품 정보, 프로모 정보 가져와서 store 생성(재고 관리)
2. while문으로 아래의 내용 감쌈
3. 재고 출력
4. 구매 요청 내역 입력 받음
5. 각 구매 요청 내역에 대해 구매 처리
6. 멤버십 여부 받음
7. 해당 고객에 대한 영수증 출력
8. 추가 구매 여부 받음
9. 추가 구매 X면 종료 Y면 계속 진행

test 디버깅

디버깅의 경우 나머지는 다 잘 진행되었지만, 상품 재고 저장 부분에서 어려움이 있었다. 만약 프로모 재고만 있고, 일반 재고는 없는(정보 자체가 없는) 상품이 있을 경우에는 자체적으로 일반 재고 항목을 만들어서 재고없음 이라고 띄워야 했다.

예를들어 사이다 2+1이 10개 있는데 사이다 프로모 없는 상품은 아예 정보가 없을 때, 자체적으로 사이다 프로모 없음을 재고없음 처리해야한다. 그래서 진행한 방식은

1. 입력 받을 때, 상품 이름 목록을 받는다.
2. 해당 상품 이름들 마다 promo적용 안되는 재고 정보를 받음
3. promo 적용 안되는 재고가 없다면(근데 이름은 있으니까)
4. promo 적용x, 재고x인 내용 추가
5. 추가된 내용으로 store 구성

이렇게 진행하였고, 테스트 최종 통과하였다.

프리코스 3주차에 풀어봤던 로또 문제를 설계하던 도중에 MVC 패턴에 대해서 궁금증이 생겨 오픈미션을 함께 했던 여빈님과 이야기를 해보게 되었고, 이에 대한 내용을 정리하고자 한다.

일단 내가 그동안 계층 분리를 했던 내용은 다음과 같다.

또한 프리코스 내내 이상하게... 계층분리를 했었다.

MVC모델에 대해서 제대로 학습해본 사람이 보면 뒷목 잡고 기절할 만한 상황이지만... 일단 내가 하고 있던 생각에 대해 설명해보자면

View는 사용자와 상호작용하며 입출력을 담당하는 내용이고, Controller는 뭔가 내용을 처리하는 로직이며, Model은 상태를 가지고 있는 객체!라고 생각을 했다. 이 부분에 대해서 티가 나는 부분이 맨 위에 있는 controller에 3개의 파일이 있는 미션인데, 이 미션의 경우에는 상태를 가지고 있는 객체가 없었기 때문에, model 계층이 하나도 없다. 그니까 내용을 계속 처리하는 로직들만 반복되기 때문에 controller만 있다고 생각했던 것이다.

이번에는 프리코스 3주차에 풀었던 로또 미션을 다시 진행하고자 하고 있었고, 기초 설계를 완료한 다음의 내용은 다음과 같다.

글씨는.. 나 혼자 보기 위해 쓴거라 개판이지만 오른쪽 아래를 보면 MVC를 나눠놓은 모습이 보인다.

Model

• Lotto

View

• Input
• Output

Controller

• GameController
• LottoResult

이와 같이 나눠놨었고, 설계를 완료한 후에 README에 쓰고 있던 와중, 이와 같은 의문이 들었다.

1. GameController

- Input 받아옴
- Lotto 생성(LottoIssuer 만들까)
- 결과 출력
- Input 받아옴(당첨 번호, 보너스 번호)
- GameResult 돌림
- 결과 출력

여기서 2번째에 LottoIssuer만들까? 에 대한 부분에서 궁금증이 시작되었다. Lotto를 생성, 즉 발행하는 클래스를 만들까에 대한 고민이었고, 이 LottoIssuer를 만들게 되면 과연 이 파일은 MVC 중 어디에 해당되는가...에 대해 고민을 시작했다. 그리고 gpt에게 물어본 결과 model에 해당된다는 답변을 받게 되었다. 나는 의문이 생겼다. 아니.. 발행만 하는건데 왜 model이야? 그리고 mvc 모델을 검색해보게 되었고, 이와 같이 정리된 내용을 발견하였다.

내가 그동안 생각해왔던 방식과 완전히 다른 방식이었다. 완전히는 아니지만, 사용자와의 상호작용?을 하는 내용이 controller라는 말이었다. 이 내용을 바탕으로 그동안 해왔던 미션에 대해 생각해보면, controller가 단 한개만 존재하게 된다. 그래서 이 부분에 대해 여빈님에게 sos를 쳤고, 정말 좋은 답변이 돌아왔다.

정말 이해가 잘 됐다. 그니까 정리하자면 알바생은 사용자와 상호작용을 하며, 알바생이 해주는 서비스나 사용하는 기계들은 모두 model이라는 말이다. 그니까 view는 사용자가 하는 말, 그리고 영수증? 받는 물품? 에 해당되고, 알바생은 controller며, 포스기나 뭐 커피기계 이런건 다 model이다.

이 부분에 대해서 웹일 때의 경우를 찾아보았다.

1. 사용자가 브라우저에서 웹 페이지 주소를 입력해 서버로 HTTP GET 요청을 보낸다.
2. 서버는 Controller에서 HTTP GET 요청을 받는다.
3. Model(Service)에서 비즈니스 로직을 처리한다.
4. Model은 Controller로 화면에 필요한 데이터를 넘겨준다.
5. Controller는 받아온 데이터를 View에 넘겨주어 HTML 페이지를 만든다.
6. Controller에서 만들어진 HTML 파일을 브라우저에게 넘겨준다.
7. 브라우저는 HTML 파일을 렌더링한다.

이걸 보니 이해가 더 잘 됐다. 왜냐면 우리는 콘솔에 print되는, 그리고 콘솔을 통해 사용자와 상호작용하는 프로그램을 만들고 있기 때문에

1. 사용자의 입력을 받는다(View)
2. 받은 요청(입력)을 보낸다.
3. Controller에서 요청을 받는다.
4. Model에서 로직을 처리한다.
5. Model은 Controller로 필요한 결과를 넘겨준다.
6. Controller는 받아온 결과를 View에 넘겨준다.
7. View는 출력한다.

이렇게 정리될 수 있다는 것이다.

그래서 여기서 또 생긴 의문은 Controller가 2개 이상인 경우도 있는가?였다. 뭔가 우리가 그동안 해온 연습들은 다 controller가 1개였는데, 그럼 2개 이상인 경우는?에 대해 생각해보았고 첫번째 가설은

로직이 길어지면 controller 2개로 쪼개기 였다.

이 부분에 대해 Lotto로 설명하자면

• 입력 -> 로또 발행
• 결과 -> 출력

이렇게 나뉜다고 하자. 하지만 입력 -> 로또 발행한 내용을 아래의 결과 -> 출력 로직에서도 사용하기 때문에 서로 독립적이지가 않고, 이어줄 수 있는 매개체가 필요하게 되어 Controller가 서로를 이어주게(처리해주게) 되고, 그럼 이 두 로직은 model이 된다.

다음 가설은 사용자와 컴퓨터가 따로 있는 경우다.

이 부분은 예전에 풀어봤던 타노스 게임에서 생각해봤는데, 타노스 게임은 사용자쪽에서 실행하는 부분, 그리고 컴퓨터쪽에서 실행하는 부분이 나눠졌었다. 그럼 사용자쪽, 컴퓨터쪽 이렇게 나뉠 수도 있겠다 라는 생각을 했는데, 이 부분도 잘못 생각했었다.

만약 게임이 사용자 혼자 게임하기, 그리고 컴퓨터 혼자 게임하기로 나뉜다면 2개가 맞지만 이 부분도 사용자와 컴퓨터가 서로 상호작용하는 부분이 있기 때문에 controller는 하나가 되게 된다.

결론은 서로 독립적이지 않는 이상 controller는 하나라는 이야기이다.

최종 코테를 앞두고 계속 연습을 해가며, AI를 사용하지 않으니 생겨나는 의문점들도 많고, 확실히 짚고 넘어가고 싶은 내용들도 생기고 있는 것 같다. MVC 모델도 제대로 찾아보고, 애매한 부분을 해결하고자 하는 생각을 이전에는 못했었는데, 이번에 제대로 공부해보고 넘어갈 수 있게 되었다. 계속해서 연습을 해가며 헷갈렸던 부분들에 대해서 공부해나가면 좋은 결과가 있지 않을까 기대해본다!

깃허브를 이용해보신 분들이라면 한번쯤은 봤을 이 화면... 바로 2fa 인증 화면이다. 당시의 나는 2fa 방식 중 가장 확실하고 깃허브에서 권하던 방법인 authentication app, 즉 앱을 이용하는 방식을 회피하고 있었다. 귀찮다는 이유에서였는데.

하지만 그 외의 모든 방식은 다 만들어놨었다.

• recovery code, 저장해놨죠
• passkey, 발급받아놨죠
• 핸드폰 앱, 받아놨죠

정말 다 해놨다!!!!!!!! 그렇게 계속 2fa가 뜰 때마다 다른 방식으로 인증을 하고 있었는데 챌린지 4일차, 갑자기 authentication app만 떴다. authentication app 설정도 해본적이 없고, more options 눌러도 아무것도 안뜨고.... 첫번째로 한 일은 gpt한테 github 고객센터 이메일을 물어봐서 이메일을 보내는 것이었다. 하지만... 그 이메일은 수신이 막혀있는 이메일이었으며 다른 이메일들을 뒤져봐도 다 수신이 막혔다.

결국 찾아낸 방식은 딱 하나... 바로 깃허브 내에서 챗봇과 함께 이야기를 나누는 것이다. 즉, 챗봇의 면접을 통과해야만 이메일을 작성할 수 있는 것인데 챗 봇과 대화를 하다 보면... 일단 해본 항목들을 체크하게 되어있다. 난 다 해봤으니 넘어가고... 마지막에 뭘 눌렀는지 기록이 안 남아있는데 아무튼 노답인 상황이 인정되면 다음과 같은 폼이 뜬다. 즉, 깃허브 팀에 직접적으로 도움 요청이 가능하다. 하지만 이렇게 도움을 요청해도 돌아오는 메일은 다음과 같다.

너무 길어서 2줄요약하자면 다 아는 내용~ 리커버리 코드로 재설정 해보렴 아니면 우리가 unlink(사용못함) 해줄 수 있긴함^^ 이거 말고 도움 못줌^^ 이다.

여기에 개 열받아서 답장으로 이와 같이 보냈다.

그니까 난 깃허브 모바일 앱만 사용했지 authenticator 깔아본적도 없고! passkey도 있고! recovery code로 재설정도 해봤어! 근데!!!!!!!! 니네가!!!!!!!!! authentication만 요구 중이라고!!!!!!!!!!!! more option도 안뜬다고오오오와어ㅏㅇ 그니까 qr 코드 한번만 다시 보여주면 바로 설정할게ㅠㅠ 아니면 more option 한번만 열어줘ㅠㅠㅠㅠ

라는 뜻이다.

그렇게 날아온 답장은 다음과 같다.

어 니꺼 다른팀으로 넘어갈거임 ㄱㄷ

이게 7월 17일이었다.

그리고 챌린지는? 계속 진행되었고 난 걍 포기하고 새로운 계정을 파서 아니 판건 아니고 처음 깃에 대해서 배울 때 썼던 계정으로 사이드 프로젝트도 하고, 부스트캠프에서 만난 사람들과 팔로우도 주고 받으며 잘 살고 있었다. 물론 여기에 조금 더 많은 추억이 쌓여있긴 하지만 어쩔 수 없지 않나... (깃허브로 로그인한 모든 계정을 들어갈 수가 없어서 프로그래머스도 입문부터 깨고 있었다)

그리고 한달하고도 반이 지난 9월 2일 오늘 갑자기 메일이 왔다.

그니까 이미 인증앱 설정 되어 있고, 너 5월에 이미 인증앱 설정함! 근데? 다행히도 지금 로그인 가능하니까 드가서 인증앱으로 교체하렴

이 말 듣고 로그인해보니 그동안 보고싶었던 나의 예전계정에 들어가졌다....(물론 passkey 인증, 핸드폰 인증 모두를 거쳤다) 그리고 authentication app을 바로 등록했다.

그렇게 한달반동안의 사투는 끝이 났다....

그리고 현재는 어떤 계정을 써야할지 막막할 뿐이다.

한달 반동안 어떤 일이 있었냐면...

기존 계정

현재 계정이다.

뭔 계정을 써야할지 너무 막막하고... 그냥 새 계정을 쓸까 싶다. 새로운 시작의 느낌으로(?)

const EMAIL_SENT = new Date("2025-07-17");
const REPLY_RECEIVED = new Date("2025-09-02");

const DAYS_WAITED = Math.floor(
  (REPLY_RECEIVED - EMAIL_SENT) / (1000 * 60 * 60 * 24)
);

let patience = 0;
const MAX_PATIENCE = 0;

const account = {
  status: "half_dead",
  hope: null,
  waited: DAYS_WAITED,
};

while (patience <= MAX_PATIENCE) {
  // nothing left
}

개열받은 상황을 코드로 써달랬더니 gpt가 이렇게 써줌 그래요 저에게 남은건 없습니다. 191개의 커밋과 함께 올해를 채워나가보자고.....

일단 다른 것을 준비하며 프로젝트를 하던 중에 컴공을 다니는 친구가 추천해준 외국계 회사 공고에 설마설마 하며 서류를 넣어보았다. 나의 조건과 정말 잘 맞았고, 나의 배경과도 정말 잘 맞는 회사였다. 1차 서류가 통과되었고, 2차 간단한 미팅이 통과 된 후에 3차 과제 테스트가 주어진다는 메일을 받은 후, 나는 일단 벌벌 떨기 시작했다. 누군가와 협업을 해본지도 오래되었고, 혼자서 프로젝트는 그냥 맨땅에 헤딩하듯이 하고만 있었고, 풀스택 부트캠프 수료한 뒤에 한거라고는 부스트캠프에서 CS 기반으로 또 헤딩 밖에 없었기 때문이다.

분야는 프론트엔드로 보일 것 같지만 뜯어보면 풀스택 포지션이었기에.... 둘다 신경썼어야했고, 다행히 BE는 spring이 아니라 Nestjs여서 일단 동네 도서관에서 최근에 나온 JS랑 TS 책은 죄다 빌려와서 모르는 부분은 다 읽어봤던 것 같다.

급한 벼락치기가 끝나고한 벼락치기가 끝나고 물러날 곳이 없어진 나는 결국 테스트 응시를 눌렀고... 영어로 가득한 응시 안내 내용이 나를 반겼다.

내 github name을 넣고, repo url을 받으니 보이는... 이미 완성된듯한 프로젝트... 분명 공고에는 이렇게 써져있었다...ㅠㅠ 'Entry-level' 즉, 신입 개발자 였단 말이다ㅠㅠ 근데 나에게 이런 시련이ㅠㅠ 일단 침착하게 vscode를 켜서 clone을 받고, 시작을 하는데 여기서 첫번째 문제점이 터졌다.

start가 안된다

사전에 제시된 안내문에 start 방법이 적혀있었고, 그대로 terminal에 입력했는데 start가 안됐다. 침착하게(전혀 침착하지 않았음) package.json에 start:어쩌구 집어넣고 실행하니 ts-node가 내가 실행한 로컬에 설치가 안되어 있어서... 빠르게 설치하고 다시 실행했다.

일단 이 start는 성공을 하고, 주어진 테스트가 이 프로그램에서 특정 명령어를 입력했을 때 top3를 JSON으로 출력하도록 해라. 였기 때문에(거기에 디버깅을 첨가한) 이 로직을 담당하는 파일 안에 내용을 작성한다.

top3? 쉬웠다 사실... 이정도는 프로그래머스 lv.1 정도 밖에 안된다...

그리고 실행했더니 에러가 바바방 떴다. 한두개가 아니어서 하나하나 해결하느라 시간이 한참 걸렸다. 이 중 내가 가장 곤욕을 치룬 에러는... 서버에 연결을 못했다는건데 server를 따로 켜놓고 또 따로 이 프로그램을 실행해야한다. 라는 생각을 못했던거다(진짜 바본가;;;)

뒤늦게 알고 서버를 실행해봤는데 또 에러가 와바ㅏㅂ바ㅏㅂ바ㅏ바 떴다.

에러의 이유는 간단했다. Prisma client가 최신 스키마를 반영하지 못했다는거라서 npx prisma generate, migrate 콤보 날려주고 실행했더니 잘 실행되고 심지어 실행되면서 라우트가 아주 친절하게 나와주었다.

다음 서버 실행 -> 다른 터미널 -> curl로 API 확인 해보니 status는 200으로 ok였지만 응답 내용이

{"data":[],"links":{}}

비어있었다. 상식적으로 비어있을 리가 없었다. 위에 언급했듯이 top3 출력하는거였고.. 폴더들을 샅샅이 뒤져보니 seed.ts가 존재했다. 그래서 npx prisma db seed로 DB에 데이터 넣고, curl로 다시 api 확인해보니

{"data":[{"id":11,"name":"어쩌구저쩌구","status":0,"location":"솰라솰라"}

로 잘 나왔다.

다시 로직 담당하는 파일로 돌아가서 제공된 출력형식에 맞춰서 바꾸고 출력 확인을 하고, commit을 보냈다.

외국계 회사여서... PR에다가 영어로 설명을 쓰는게 진짜 너무 어려웠다. 회화보다는 독해, 작문에 강점을 가지고 있는 나지만(전형적인 코레안) PR 쓰는데에도 한 세월이 걸렸던 것 같다.

Project를... setup하는데에... 이거가... 필요했고오... 저거가... 했고오... 이거가... 오류가 났고오... 그래서 이거 했고오... 너네가 이거 하래서어... 이거 했고오.... 이거 있는거 알아내서어... 이거했고오....

아마 쟤네가 보기에는

안녕하새오. 나는. 김희주애오. 너내가 만든 코드를. 사용해서. 열심히 해보았어오.

이렇게 보이지 않을까 싶지만 그래도 좋은 경험 해본 것 같다.

첫 과제 테스트의 후기는 이렇게 끝내도록 하겠습니다. 몇년후에 보면 재밌지 않을까 싶음

그래서 난 백엔드인가 프론트엔드인가 이건 아직도 고민이긴 함 그럼 이상 사라질게요 안뇽

++ 떨어졌당 히히....

그래서 요즘 벨로그에 글을 열심히 올리고 있었으니 (하라는 웹 개발 공부는 안하고 이상한 것만 올려댐) 제 전문 분야 바로 투턱 없애기~ 를? 올려보도록 하겠습니다

자 포토샵에서 가장 중요한 것은 무엇이냐

바아로~ 모델입니다.

투턱에 대한 연습을 할 때 가장 필요한 것은 무엇이냐? 바로 투턱을 가진 모델입니다. 이 순간 바로 떠오른 모델 우리나라의 자랑 강호동씨 앞으로 모시겠습니다

아 네 사진이 참 잘 나왔네요. 사실 연예인들을 찍으러 다니거나 본인들을 찍게되면 딱! 이정도의 투턱이 나오게 됩니다. 정말 인공적으로 투턱을 만들어서 두겹.이 나오는 그런 턱들은 잘 안나오거든요 이 턱만 아니면 마음에 드는데.... 싶은 사진들이 나왔을 때 턱만 해결하는 법! 알려드리겠습니다아~

아... 확대하고 보니 화질이 구려서 너무 당황했네요... 전 고화소만 만져봐서(자랑 맞음) 일단 ctrl+j를 눌러 원본보존을 해줍니다. 그리고 ctrl+shift+x를 눌러 픽셀 유동화를 켜주고요 오른쪽에 브러쉬 도구옵션 저기 크기 말고는 딱히 건들 일이 없습니다. 크기로 조절해가면서

턱라인을 다듬어 줍니다. 안 다듬어주면.... 턱을 없앨 수가 없어용~

진짜 하다가 웃음 참느라 눈물남...너무 작게하면 얼굴이 빠그라지고용 크게하면 이목구비까지 빠그라지니까 적당량으로 움직여주셔야 합니다 근데 이거 핸드폰 보정앱에서 많이들 해보셔서 익숙할거예요

일단 턱라인을 좀 가지런히 했다면 나와서

요 올가미 도구를 선택해줍니다

그리고 이렇게 턱 라인의 아랫부분..을 따줍니다. 따주고 ctrl+j를 누르면 와 같이 새로운 레이어로 따준 부분이 복사되게 되는데요, 여기서 다시 ctrl+t를 누르게 되면 이 레이어만 이동할 수 있게 되고 여기에 우클릭 -> 뒤틀기 하면 약간... 머라하지 figma에서 본 것 같은 느낌의 무언가가 나옵니다. 그리고 이제 이 모형?을 비틀어섴ㅋㅋㅋㅋㅋㅋ 메인 턱 라인만 살리고 나머지를 살포시 덮어줍니다.... 이걸 뭐라고 설명해야돼... 그리고 이 부분에 남은 목주름? 턱주름? 을 없애봅니다. 어케하냐구용? 먼저, 원본, 턱깎은버전, 보존 하고, 나머지 2개를 합친다음 (2개 골라서 레이어 병합!) 스팟 복구 브러시를 사용해서 -> 요즘 아주 효자임 덤으로 여드름들도 없애줍니다.... 나 진짜 밤에 뭐하고 있는거지?

아무튼 그런 후에 다시 ctrl+j로 원본보존, 그리고 ctrl+shift+x로 픽셀 유동화 -> 턱선 정리 후 이렇게 턱선을 잡고 다시 ctrl j, t 뒤틀기로 이번에는 턱선을 멱삽 잡고 내립니다. 내리면 턱은 사라지고.... ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 나 진짜 웃겨 죽을 뻔했네ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ 턱만 확대해서 깎다가 줌아웃 해보니까 다른 사람이 있잖아요ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

마지막 꿀팁이 있다면

이런식으로 2줄을 같은 사진으로 띄우고 턱에 쉐딩을 발라주곸ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ(극단적인 예시) 위 레이어의 불투명도를 조정해주면 쉐딩이 된답니다~

이건 30% 12%

확실히 다르죠?

여러분들의 턱은 깎기 훨씬 쉬울테니 용기를 가지고 깎아보시기 바랍니다.

++

저 웃겨서 공부가 안돼요 이제 자야겠어요(1시임) 그럼 웃음이 되었길 바라면서 물러나겠습니다....

일단 제 소개!

나는 칼졸업 칼취업 후 퇴사하자마자 갑자기 개발 공부를 하겠다며 뛰어든 사람으로, 24년 10월말에 풀스택 부트캠프에 아무것도 모르는채로 들어가서, 6월에 베이직에까지 다이빙한 사람이다. 그러니 조금 실력이 떨어진(ㅠㅠ)다는 것을 감안하고 봐주십쇼.... 이렇게 말하면 슬픈데 아무튼 전공자는 아닙니다~

부제로 비전공자의 생존기 적어야함

입과 전

입과 전의 나는 베이직 첫날 12시간을 쏟을 정도로... 코딩 초보였다. 알고리즘 공부를 해보겠다는 의지로 파이썬을 혼자 독학해 몇주만에 백준 골드를 달성하고 뻗어버린 전적이 있지만(연휴였다)

++ 그때 당시 사진 찾아보니....

3일만에 골드 달성이었더라.... 근데 아직 골드4인걸 보면 class 점수빨인 것 같습니다 아무튼 이랬던 전적이 있지만

자바스크립트로는 풀지 못했다. 하지만 챌린지에 입과하겠다는 의지로 프로그래머스와 자바스크립트라는 무기로 싸워보았고, 결국 챌린지에 입과하게 되었다.

챌린지의 하루하루는 워낙 빡세다고 잘 알려져있어서 체력관리를 하려고 했는데... 뭐 입과 전에 병원 투어를 다녀본 결과 수치들이 죄다 안 좋길래 그냥 포기했다.ㅋㅋㅋㅋ

그래서 챌린지, 어땠어?

챌린지가 어땠냐고 물어본다면, 이렇게 답하고 싶다.

첫째주는 지옥이었고, 둘째주는 지옥이었으며, 셋째주는 재밌었고, 넷째주는 재밌는 지옥이었다.

나는 몰입이라는 것을 잘한다고 생각한다. 본인 입으로 저런 말을 하냐 할수도 있겠지만.... 엄마가 나를 키워온 이야기를 들어보면 입을 다물지 못할 썰들이 튀어나온다. 문제집 하나를 사줬더니 그거를 놀이터에 가서 다 풀어오더라 퍼즐 하나를 사줬더니 그거 다 맞출 때까지 안 자더라 니 아빠가 세운 게임 기록 깰 때까지 안 자더라 이런 썰들

그리고 이런 몰입의 시간이 3주차부터 정말 재미있게 시작되었던 것 같다. 즐기면서 시작되었다. 1주차는 미션이 공개되면 벽에 가로막힌 기분이었고, 계속 방황했다. 혼자 있는 기분이었고, 실제로도 혼자 헤매고 있었다. 2주차부터는 커뮤니티 안에서 함께하며 동료들과 함께 으쌰으쌰 힘내면서 헤쳐나가기 시작했다.

3주차부터는 미션의 방향성이 약간 달라졌는데, 그 방향이 나와 잘 맞았던 것인지 나는 꽤 재밌었던 것 같다. 그리고 앞선 2주동안 다른 사람들의 결과물을 보며 배웠던 부분들을 적용해보며 많이 성장했던 탓도 있던 것 같다.

그래서 4주차는 왜 지옥이었냐면... 체력의 끝이 보였다. 온 몸이 고장났고, 손이 계속 저렸다. 첫 2주는 살이찌던데 끝 2주는 살이 빠졌다. 공유오피스를 사용했기에 잠시라도 자자 하고 집에 가면 내가 못 들어온 줄 알고 마음 놓고 있던 부모님이 아침에 거지꼴로 일어난 나를 보고 맨날 놀라셨다. 대충 이렇게 다님

그리고 마지막 2주는 뭘 열심히 먹은 것 같으면서도 못 먹은 것 같은게, 오늘은 정말 일찍 끝나고 잘거라고, 2시 안에 잘거라고 5시 즈음에 마지막으로 밥을 먹는다. 그리고 시간이 지난다. 지난다. 지난다. 지난다. 그러다가 오전 5시가 된다. 그래서 살이 빠진다... 손이 저린건 저혈당 때문이었다.

하지만 오히려 너무 재밌었다. 모각코라고 줌에 들어와서 캠을 키고 다같이 코딩을 했는데 그 분위기가 재밌었고, 그 안에서 미션에 대해서 토론하는 것이 재밌었고, 미션에 대한 정보를 찾아 올리는 것도 재밌었고, 모든 것이 재밌었다. 그동안에는 웹 개발. 그니까 정말 웹을 만드는 법.에 대해서만 공부했었는데 진짜 프로그래밍을 해볼 수 있게 된 것 같아서 더 재미있었던 것 같다.

그리고 챌린지에서 가장 유명한 그 문장

개구리에 대해 알고 싶으면 개구리를 해부하지 말고 만들어라...? 맞나

죄송합니다... 제가 기억력이.. 아무튼 이 말이 정말 뼈에 맞은게 나는 정말 해부학을 배우는 학과 출신이라 해부를 하는데 하루는 교수님이 진짜 똑같이 생긴 뼈들 24개를 던져주고 시간안에 맞추라고 했다. 바로 척추였는데 항상 사람의 몸 속에서 무언가를 찾기만 했지 다 똑같이 생긴 애들을 맞춘 적은 없었기에 다들 우왕좌왕 했던 것 같다.

그리고 시험문제로는 순서를 다 써라. 이런식으로 나온다. 그래서 이 문장이 정말 와닿았던 것 같다. 직접 보고 그것이 무엇인지 아는 것은 정말 쉽다. 하지만 직접 만들고, 쓰는 것은 정말 어렵다. 나는 그것을 학부 4년동안 직접 경험했었다. 하지만 그러면서도 구현은 아직 너무 어렵다며 코드 읽는 것은 쉽다고 코드 리뷰, 디버깅에만 자신감을 보였었다.

챌린지는 CS지식을 직접 만들어보며 알아가는 과정이다. 예를들어 자전거가 굴러가기 위해서는 프레임, 바퀴, 브레이크, 안장, 등이 있어야한다. 이것들을 직접 만들어서 굴러가게 하는 것이 챌린지 과정이고, 하루에 이 자전거 하나를 만드는 것이 미션이다.

참고로 나는 자전거가 뭔지 몰라서 자전거부터 알아갔다. 아니? 이륜차가 뭔지도 몰라서 이륜차부터 알아갔다!!!! 하지만 재밌었다...

리드미 아티스트

내가 마지막 팀원들을 보며 한 말이 있다. 우리 팀원들... 리드미 아티스트셔.... 그만큼 리드미를 정말 잘 쓰는 분들이 마지막 팀원들이셨다.

미션의 강도만큼 피어컴파일링을 하며 모든 코드를 읽기 어려워 리드미를 우선적으로 읽게되고, 그래서 리드미에 나의 사고방식을 잘 적어두는게 중요하다고 생각한다. 그리고 그것을 매주 같은 팀원들의 결과물에서 많이 배워갔다.

지금도 1주차부터 4주차의 리드미들을 열어보면 결과물의 차이가 확 보여서 정말 재밌다. 거기에 베이직의 리드미까지 열어보면 화룡점정이다.

리드미에도 종류가 여러가지가 있다. 설계에 더 힘을 쓰는 분들, 자신이 고민한 내용을 더 많이 담는 분들, 구현한 내용을 더 자세히 쓰는 분들. 나는 그 모든 부분을 계속해서 왔다갔다 했던 것 같다. 아무래도 설계가 계속해서 나의 발목을 잡았기 때문에, 설계에 힘을 쓰는 것이 가장 어려웠던 것 같긴 하다.

챌린지를 거치며 얻은 것 중 가장 큰 것이 뭐야? 라고 물으면 나는 동료들도 동료들이지만 리드미라고 하고 싶긴하다.. 그만큼 나의 사고방식, 그리고 설계, 이런 것을 문서화하는 경험을 해본 것이 많은 도움이 되었다고 생각한다.

AI랑 친구먹기

요즘 AI가 뜨거운 감자 앗뜨앗뜨다. 부스트캠프에 들어오기 전 나는 gpt만을 애용(not 좀비딸)하던 사람이다. 말하는 것도 "이거이거 만들어봐" "이거 오류났어 왜이래" 이런식으로 프롬프트를 작성했었고, 다른거라고는 커서로 바이브 코딩만 해봤었다. 그런데 부스트캠프에 들어와서는 다른 AI 모델들도 사용해보기 시작했다. 시작은 베이직에서 수료생 분이 gemini를 사용해본 후기를 공유해주셔서 gemini를 사용해보며 시작되었다.

Gemini는 뭔가 딱딱한 기분(AI는 따지자면 저의 친구잖아요?)이라 잘 사용하지 않다가 2주차에 진입했을 때, 피어 분이 클로드를 엄청 추천해주셨다. 클로드가 설명도 잘해주고, 요즘 GPT에서 많은 이슈가 생기고 있는데, 클로드를 쓰면 좀 낫다. 라고 말해주셔서 클로드를 쓰기 시작했고, 그 이후로 클로드 신봉자가 되어 클로드를 3,4주차 피어세션 내내 전파하고 다녔다.

지가 똑똑히 봤슈 클로드가 똑똑한걸

클로드가 나에게 도움이 되었던 이유는 미션이 예를들어 10을 원한다면 나는 그 10 안에 있는 2부터 이해를 해야했었다. 그럼 클로드는 그 2에 대한 내용을 간단한 데모로 만들어서 설명을 해준다. 이 부분은 GPT가 할 수 없는 부분으로 나같은 사람들에게는 이해가 굉장히 쉬워지게 하는 방식이었다. 그리고 티키타카가 참 잘된다.

GPT는 이거잖아!!! 하면 아 맞아요 이거였어요ㅎㅎ 하고 소위말해 구라를 잘 친다... 정말 너무 잘 친다 이제는 그냥 안 믿는데 일단 물어보고 확인해본다... 아무튼 근데 클로드는 그에 대해 자세한 설명까지 덧붙여주기에 좀 더 신뢰가 갔던 것 같다. 이 부분에 대해서 또 할 말이 있는데, 클로드도 어느 정도 구라(?)를 치기 때문에, 3주차 후반부터는 perplexity까지 썼던 것 같다. perplexity는 출처까지 알려주기 때문에 학습에 정말 큰 도움이 된다.

이렇게 부스트캠프를 통해 상황에 따라 필요한 AI를 활용하는 능력을 기를 수 있게 되었다. 다른 캠퍼분들을 보니까 AI마다 누구는 퀴즈를 잘만들고 누구는 뭐를 잘만들고 누구는 말투가 이렇고 이런거를 다 아는 분들도 계시더라....

수료, 그리고 새로운 시작

챌린지를 처음 시작할 때 이게 끝이 나긴 할까? 라는 생각이 머리속에 가득찼던 것 같다. 그리고 수료를 할 때 나는 미련도 없이.. 공유오피스에서 짐을 빼기 위해 모니터를 해체하기 시작했다. 수료식이 끝나자마자 캐리어에 노트북을 던져버리고 바로 캐리어를 질질 끌고 집에 와 잠이 들었던 기억이 있다.

챌린지를 하면서 많은 분들과 친해지고, 이야기를 나누며 친해질 수 있었다. 그리고 그 분들과 결과가 어떻게 나오든 우리는 챌린지에서 최선을 다 했기에 잘 살기로 약속을 했다.

결론적으로 말하자면 멤버십 입과에는 실패했다. 챌린지 입과가 목표였기에, 그리고 챌린지를 이보다 더 열심히 할 수는 없다고 생각하기에 후회는 전혀 남지 않았고, 결과를 보자마자 바로 깃허브를 켜서 하던 것을 했던 것 같다...ㅎㅎ

다시 생각해보면 내가 하고 싶은 것을 할 시간이 없었던 것 같다.

혼자 노션을 정리하다보니, 졸업을 하자마자 취업, 퇴사를 하자마자 부트캠프, 부트캠프 수료하자마자 부스트캠프를 했다는 것을 깨달았다. 빈틈이 없다. 내가 하고자하는 프로젝트 같은 것을 할 기회가 없었던 것 같다. 그래서 이제는 나만의 시간을 가지고자 한다.

이미 나만의 시간을 즐기고 있다가 올리는 회고 글이지만...ㅎㅎ 이 글을 보는 여러분 모두 챌린지 동안 쌓였던 피로들 잘 풀고 좋은 시간 즐기길 바랍니다.

그럼 전 내일 쿠우쿠우 조지러 갑니다. 근데 박명수가 ISTP라면서요? 저도 ISTP임. 안녕안녕 여러분 가끔 연락줘요 어디로...? 어 그러게요.... DM 주시면 카톡 아이디 드림