패스트캠퍼스: 데브캠프김민태의 프론트엔드 개발 1기_과정 중간 회고

nakyeonko3·2024년 11월 3일

FE 국비지원 국비지원취업 부트캠프 패스트캠퍼스 프론트엔드개발자 회고

패스트캠퍼스: 데브캠프_김민태의 프론트엔드 개발 1기

목록 보기

7/9

이제 부트캠프 졸업까지 2개월도 안남은 상황이다.
지금 시점에서 내가 부트캠프에서 어떤 걸 겪었는지 회고하는 방식으로 정리해보려고한다.
지난 번에 회고 했던 것 처럼 KPT 회고 방식으로 회고를 진행하려고 한다.

KPT 회고

회고 개요

KPT 회고 를 바탕으로 회고를 함
Keep: 현재 만족하고있고, 계속 이어갔으면 하는 부분
Problem: 불편하게 느끼는 부분, 개선이 필요한 부분
Try: Problem에 대한 해결책
Practice: Try 중에서 당장 실행 가능한것. 또는 구체적인 Try예시

KEEP

프로젝트, 프로젝트, 프로젝트

개발 프로젝트를 정말 많이했다. 패스트캠퍼스 부트캠프에서 팀으로 진행한 토이프로젝트가 3개 정도 있었고 그외 개인적으로 진행한 사이드 프로젝트도 많았다.

정말 짧은 기간동안에 많은 프로젝트를 진행했던 것 같다.

토이프로젝트2
https://github.com/Dev-FE-1/Toy_Project_II_team4
https://toy-project2-team4-fastcom4.web.app

토이프로젝트3
https://github.com/Dev-FE-1/Toy_Project_3_team4

`npm i byul`

love1ace님과 같이 만든 자동으로 깃 메시지를 적어주는 npm 라이브러리이다.

지금은 npm에서 주간 다운로드 수가 많이 줄었지만 초반에는 천명 넘게 다운로드 수가 나오긴했다.

byul-npm링크
https://www.npmjs.com/package/byul

git hook이라는 생소한 git의 기능을 이용해서 만들어서 처음 버전에서 정말 버그도 많았고, 해당 버그들을 해결하면서 git hook에 대해 많이 배웠다. 이 프로젝트를 하면서 좀 gpt나 claude 같은 ai 개발 도구들을 더 잘 쓰게 되었다.

멘토링 & 나만의 질문 작성법 만들기

패캠 자체에서 진행하는 스터디와 멘토링도 꽤 도움이 되었다.
스터디 멘토링(대략 4명정도의 멘티와 1명의 멘토가 지정되서 매주 zoom미팅으로 질답을 주고받으면서 멘토링이 진행됨)을 거의 매주 진행되어 왔는데 항상 할 때마다 멘토님께 평소에 궁금했던 내용들이나 코딩하다가 잘 안되는 부분들을 멘토님께 물어볼 수 있어서 좋았다.

무엇보다 질문을 자주 하다보니 질문 하는 나만의 요령도 생겼다. 나는 이 방식으로 질문을 한다.

1. 질문지 첫 문장에는 질문하려는 것의 주제를 적기(ex. npm 라이브러리 문제, react 무한로딩, )
2. 문제가 발생한 맥락 적기, 이 문제가 어떤 상황에서 이런 문제가 발생했는지 적어야됨.
3. 이 문제를 해결하기 위해 어떤 시도들을 했는지 적기, 어떻게 해결하려고 하는지 적기
4. 질문지 적고 나름대로 질문에 나만의 해결책들을 2가지 만들어서 시도 해보기

사실 저렇게 질문지를 적으면서 내가 가지고 있었던 궁금증들이 해결되는 경우가 많았다. 코딩 관련 문제들은 저거 질문지 적으면서 거의 다 해결된 것 같다.

나는 코딩 보다는 구글링이나 gpt같은 걸로 얻기 힘든 지식들 위주로 질문하긴 했던 것 같다.

커리어 관련 질문이나 tailwind vs styled component 같은 사람마다 다르게 대답할 수 있는 질문 같은 것들도 많이 물어봤다.

Problem

부트캠프를 다니면서 내가 지금 겪고 있는 어려움이나 프로젝트를 진행하면서 아쉬웠던 점들 위주로 정리를 하겠다.

AI 의존도가 높은 개발

요즘에 정말 거의 AI한테 코드를 맡기는 경우가 늘었다.

일단 내가 만들 기능에 대한 기능 명세를 잛게 만들고 해당 명세서를 바탕으로 claude한테 해당 코드를 만들어 달라고 한다음에 코드 조금만 고쳐서 그냥 쓰는 경우가 많은 것 같다.

빠르게 개발하는데는 이 방식이 좋긴하다. 그냥 코드를 몰라도 빠르게 기능들을 만들 수 있다.

막상 코딩이 끝나고 자려고 할 때 오늘 뭔가 배운게 전혀 없이 그냥 AI가 만들어준 코드를 복붙만 했다는 느낌이 들었다.
그리고 내가 만든 코드가 아니다 보니 버그가 발생했을 때 해결하기가 어려워졌다.

에러로그도 거의 보지 않고 ai한테 에러로그 복사해서 무슨 문제가 발생했는지 물어볼 때가 많은 것 같다.

AI를 쓰는 것 자체는 문제가 없지만,
적어도 AI가 만들어준 코드가 어떤 코드인지는 알고 쓰자.

Practice
ai 코드 내용을 그대로 쓰지 말고 한번 쭉 보고 생각해보고 써라.
에러가 발생하면 에러로그를 읽어보고 3번정도 시도 해보고 AI한테 물어보자.

코딩하는 시간이 줄음

프로젝트를 안하니 거의 코딩을 하는 시간이 심하게 줄었다. 사이드 프로젝트도 하고 있긴한데 코딩 보다는 기획이나 디자인에 더 많은 시간을 써버린 것 같다.

Practice
문서보다는 동작하는 소프트웨어가 중요하다.
기획과 디자인은 처음에는 간단하게 하고, 빠르게 프로토타입을 만들어서 검증해보는 것이 더 좋을 것 같다.

슬로우 스타트

정말 신기한 일인데, 항상 프로젝트를 하면 마감 직전까지 코딩을 하다가 완성시키는 경우가 많은 것 같다.
아니 요즘에 스터디 할때도 스터디 과제 마감 직전에 다하게 되고. 이슈도 이슈 마감일 직전까지 미루다가 하는 경우가 많은 것 같다.

왜 이런 일이 자꾸 발생할까?

우선순위가 낮은 일을 먼저해서 그런 것 같다.

우선순위가 높은 일들을 먼저하고 그 다음에 중요하지 않은 일들을 해야하는데 자꾸 그 반대가 된다.

그러고 보니 어제도 이런 일이 있었다.

API 몇개 만들어야하는데 생각해보니 오늘 회의록을 정리하지 않았던 것 같아서 회의록을 먼저 작성하고 코딩을 했다.

재밌는 개발 블로그 글을 찾아서 오늘 할 이슈들을 다 잊어먹고 그 블로그글만 하루종일 읽는다거나 그런 일들이 빈번히 발생하는 것 같다.

(문제의 블로그, react 기여자분이 만든 블로그임)
https://overreacted.io/the-two-reacts/

Practice
나름대로 must(반드시 해야할 일)와 have to(해도 되고 안해도 될 일을)을 구분하는 게 좋을 것 같다.

Try

그리고 앞으로 어떻게 이 문제들을 해결하고, 아쉬운 일이 덜 발생하도록 예방책을 만들자.

칸반 보드

칸반에 할 일들을 리스팅 하고 중요하고 당장 할 일만 남기고 나머지는 지우거나 나중에 하자.

로켓 스타트

일단 아침에 일어나고 2시간 동안 이메일, 슬렉, 핸드폰을 보지 말고 당장 해야 될 코딩에 집중을 하자.

슬로우 스타트에 반대되는 말이라서 이렇게 적었다.

매주, 매일 회고

내가 뭔가 문제가 있다면 빠르게 발견하고 이를 해결해야 된다.
그러기 위해서 빠르게 나에게 회고를 통해 셀프 피드백을 진행하고 해결책을 마련하는 것이 좋을 것 같다.
너무 길게 적지 말고 빠르게 5분동안 매일 회고를 적자
너무 오래동안 적어도 문제다. 문제를 해결하는데 시간을 써야되지 문서를 작성하는데 시간을 많이 쓰면 안된다.
그날 회고에서 전날 회고에 적은 것들이 제대로 이행되었는지 확인도 해보는 것이 좋을 것 같다.