개발 능력은 코딩을 잘하는 능력이 아니다

 

 

개발 감각 있는지 확인하는 가장 현실적인 방법

 

가끔 이런 생각이 든다.
요즘도 공부는 꾸준히 하고, 새로운 기술도 따라가고, 일도 열심히 하는데 이상하게 “내가 잘 가고 있나?” 싶을 때가 있다.

이번에 본 영상(개발감각 있는지 확인하는 법)은 그 찝찝함을 꽤 정확하게 건드렸다.
핵심은 단순했다.

개발 감각은 코딩을 잘하는 능력이 아니다.

처음엔 좀 의외였다.
우리는 보통 문제를 빨리 푼다거나, 최신 스택을 잘 다룬다거나, 코드 구조를 깔끔하게 짜는 걸 ‘감각 있다’고 말하니까.
근데 영상에서 말하는 감각은 그보다 앞 단계에 있었다.

“지금 이 상황에서 진짜로 풀어야 할 문제가 뭔지 고르는 능력.”

그리고 그걸 가능한 적은 비용으로, 가장 빠르게 해결하는 판단력.

---

예시가 좋았다.
“실시간 채팅 기능 만들어주세요”라는 요청이 들어왔을 때를 생각해보자.

보통은 바로 기술 선택으로 달려간다.
웹소켓, 메시지 큐, 스케일링, 이런 키워드부터 머리에 뜬다.

근데 감각 있는 개발자는 그 전에 질문부터 한다.

• 이 기능의 핵심 가치는 뭔가?
• 이번 릴리즈에서 절대 깨지면 안 되는 건 뭔가?

만약 핵심이 ‘실시간 느낌’이 아니라 ‘메시지 누락 없는 전달’이라면,
초기 버전은 HTTP 폴링 같은 단순한 방식이 오히려 맞을 수도 있다.

화려하진 않다.
하지만 사용자 입장에서 필요한 건 “멋진 기술”이 아니라 “문제 해결”이다.

---

이 지점에서 좀 뜨끔했다.
나도 가끔 ‘좋은 구현’을 목표로 삼다가, 정작 ‘좋은 해결’을 놓칠 때가 있었으니까.

결국 개발 감각은 뭘 더할지보다 뭘 포기할지 결정하는 힘에 가깝다.
모든 걸 다 잘하려고 하면 대체로 아무것도 끝내지 못한다.

---

영상에서 실전적으로 도움됐던 건, 감각을 키우는 방법도 꽤 구체적이었다는 점이다.

첫 번째는 오픈소스의 PR 토론이나 RFC를 읽는 것.
사용법 문서만 보면 “어떻게 쓰는지”만 알게 되는데, 토론을 보면 “왜 그렇게 만들었는지”가 보인다.
그 안엔 항상 제약, 타협, 포기가 있다.
그게 결국 실무 판단력의 재료다.

두 번째는 장애 회고(postmortem)를 읽는 것.
실제 서비스는 멋진 코드보다, 망가지지 않고 복구 가능한 코드가 더 중요하다.
장애 사례를 읽다 보면 “우리 시스템은 비슷한 실수를 견딜 수 있나?”라는 질문을 자연스럽게 하게 된다.
이게 꽤 큰 차이를 만든다.

---

최근엔 기능 시작 전에 스스로 한 가지만 먼저 묻는다.

“이 기능에서 지금 가장 중요한 한 가지는 뭘까?”

이 질문 하나만 제대로 해도,
기술 선택이 훨씬 명확해지고, 일정도 덜 무너지고, 팀 대화도 덜 꼬인다.

개발 감각은 어떤 천재적인 재능이라기보다
좋은 질문을 반복해서 던지는 습관에 가까운 것 같다.

다음 작업 들어가기 전에,
“어떻게 만들지?”보다 먼저
“지금 진짜 해결해야 하는 게 뭔지”부터 확인해보면 좋겠다.