코더가 아닌 개발자가 되려면 어떻게 해야할까

 

프로젝트를 진행하면서 여러 에러와 마주하면서 처리하며 나아가고 있다. 그러면서 문뜩 생각이 스쳐 지나갔다.

에러는 처리하고 있는데 내가 지금 에러를 처리했지만 문제를 해결하고 있는 것이 맞는것인가?

아직 초심자고 신입을 준비하는 사람이라 더 생각할 필요는 없지만 그래도 한번쯤 생각나게 만드는 키워드가 2개가 있다.

 

'코더'와 '개발자' . 이 2개이다.

 

코더도 물론 힘들다. 하지만 개발자는 그보다 더 힘들 것이다.

내가 생각한 코더와 개발자의 차이는 '코드를 치는 사람'과 '문제를 해결하는 사람' 이라는 차이이다.

이 차이는 분명 엄청난 차이가 있다.

"코드를 치는 사람이 다 문제를 해결하진 않지만
문제를 해결하는 사람은 다 코드를 쳤을 것이다."
라고 나는 생각한다.

 

그래서 코더가 아닌 개발자가 되려면 어떻게 해야하나 사람들에게도 물어봤다.

나에게 대답해준 현업 개발자 분은 "Hello world 도 의도를 갖고 작성한다면 개발자에요" 라고 표현을 했다.

무슨 말인지는 이해는 했지만 와닿지는 않아서 영혼의 단짝(?) GPT 한테 물어봤다.

GPT가 알려준 개발자와 코더의 차이를 적어보려고 한다. 한번 읽어봤지만 나중에 리마인드겸 읽어볼겸 작성해본다.

(나중에 도움이 될까해서 해서 남기기도 하는 것도 있고

나를 돌아볼겸 회고록이라는 카테고리에 넣어둔 것도 이런 이유다.)

 

[출처 : ChatGpt]

 

코더 / 개발자 , 차이

항목	코더	개발자
접근	코드를 작성한다	문제를 해결한다
초점	기능 구현 중심	설계, 개선, 유지보수 포함
특징	시키는 대로 구현	왜? 어떻게?를 스스로 묻고 구조화
성장	느림, 기술 외우기	빠름, 기술을 이해하고 선택

 

=> 코딩 그 자체보다 왜 이렇게 구현해야하는가, 더 나은 구조는 무엇인가를 고민하면

이미 개발자의 사고를 하고 있는 것.

 

개발자가 되기 위한 3단계 사고법

1. 무작정 구현하는 것이 아닌 의도 있는 구현

예시) Tailwind를 사용했어

Tailwind로 예쁘게 만들었어~ ( X )

왜 Tailwind를 사용하였고, 어떤 구조를 고려했는지 ( O )

내가 구현한 것이 의도를 붙여 설명해보기 (ex: 로그인 실패 시 UX를 고려해 input 흔들기 focus를 줌)

 

2. 코드 위주가 아닌 구조 중심으로 생각하기

- 폴더 구조는 적절한가?

- 컴포넌트는 재사용 가능한가?

- 상태 관리는 너무 흩어져 있지 않은가?

-> 프로젝트 구조에 대한 리팩터링 계획을 세워보자

 

3. "왜?"를 습관처럼 묻기

- 왜 zod를 썼을까?

- form은 왜 useRef 말고 useState로 해야했을까?

- 왜 이 API는 GET이 아닌 POST일까?

-> "왜?"라는 질문을 나에게 1번만 더 던지는 연습을 하면 코더에서 개발자로 넘어갈 수 있다.

 

자신을 위해 할 수 있는 작은 실천

1) 한 기능을 만들고 나면, "이건 어떻게 하면 더 좋을까?" 적어보기

2) 다른 개발자 포트폴리오 구조 분석 -> 비교

3) Git 커밋 메시지/블로그 글에 "왜 이걸 이렇게 했는지" 적기

4) README.md에 프로젝트 구조, 선택한 기술 이유, 리팩터링 고민 등 기록

 

마무리

상기시키기 위해서 적어도 1주일에 한 번 한달에 한 번 이 글을 찾아서 읽어보려고 한다.

올바른 방향으로 나아가는데 많은 도움이 될 것 같다.