[오늘의 생각] 250810

신입 프론트엔드 개발자 실력이 늘지 않는다고 느껴짐
충분히 잘 구현했다고 생각했는데도 리뷰를 받아보면 고칠게 많고 잘못생각한것도 많고,, 사고력이나 논리가 부족하다는 생각이 많이 들어

 

내 친구 지피티에게 상담받기..

---

 

중요한 건 두 가지입니다.

1. 왜 틀렸는지, 왜 다른 방법이 더 좋은지를 정확히 이해하는 것
2. 피드백을 단순히 반영하는 게 아니라 본인 사고 체계에 편입시키는 것

 

개발은 구현보다 설계와 의사결정 과정이 더 중요합니다.

 

• 코드 쓰기 전에 종이에 구조, 흐름, 예외 케이스를 적어보기
  (UI 구조, 상태 흐름, API 응답 변화, 에러 처리 등)
• “만약 이 요구사항이 바뀐다면 내 코드가 얼마나 버틸 수 있나?” 자문하기
• 기능을 구현할 때, 최소 2가지 방법을 비교하고 장단점을 메모

 

리뷰 받은 내용을 바탕으로 학습자료 만들기

 

• 리뷰 받은 날짜 & 브랜치명
• 수정 전 코드 + 수정 후 코드
• 리뷰어 코멘트 그대로 복사
• 왜 이렇게 해야 하는지 본인 언어로 설명
• 비슷한 상황 예시를 스스로 만들어 보기

 

예시:

csharp
복사
편집
[날짜] 2025-08-10
[브랜치] feature/modal-improvement

[리뷰어 코멘트]
"modal이 스크롤 시 화면 밖으로 벗어날 수 있으니 position: fixed를 쓰는 게 안전"

[수정 전]
position: absolute;

[수정 후]
position: fixed;

[이유]
- absolute는 부모 기준, fixed는 뷰포트 기준.
- modal은 화면에 고정되어야 하므로 fixed가 맞음.
- 특히 스크롤 시 absolute는 부모 엘리먼트 위치에 따라 의도치 않게 이동.

[비슷한 상황 예시]
- Toast, Tooltip, Dropdown 같은 overlay 컴포넌트도 fixed가 적합.

 

 

 

1. 코드 작성 전
   • 기능 요구사항을 5줄로 요약
   • 최소 2가지 구현 방법 적고 장단점 비교
   • API 응답 변화, 엣지 케이스 예상
2. 코드 작성 중
   • 매 함수/컴포넌트마다 “이걸 나중에 수정하기 쉬운 구조인가?” 체크
   • CSS/상태 관리/이벤트 처리에서 다른 방식 시뮬레이션
3. 코드 작성 후
   • 직접 PR 리뷰 시뮬레이션: 스스로 장단점과 개선점을 3가지 적기
   • 내 코드가 다른 기능에서 재사용될 수 있는지 생각
4. 주간 회고
   • 이번 주 리뷰 중 가장 인사이트 컸던 3개를 재구현
   • ‘다시 한다면 이렇게 하겠다’ 버전의 코드 작성

---

구현보다 설계와 의사 결정 과정이 중요하다는 말이 나에게 필요했던 조언같다

부트캠프때부터 '늘 구현하느라 급급해서...'가 단골 변명이었다. 

구현하느라 급급해서 아쉬운 점이 있었다면 그걸 다시 검토해보고 리팩토링 해봤다면 좋았을텐데 단지 변명으로만 써먹었던거같다ㅎㅎ;

 

어떻게 하면 개발을 잘하는 개발자가 될 수 있을까 하는 고민이 생겼는데, 지피티가 나름 현실적인 방안을 제시해주었다.

과연 나는 좋은 개발자가 될 수 있을까? 최소한 그러기 위해 노력하는 개발자가 되고싶다.