기능 구현보다 요구사항 정리가 더 어려웠던 이유

개발을 처음 시작했을 때는 구현이 가장 어려운 일이라고 생각했다.

어떤 라이브러리를 사용할지,

어떤 구조로 설계할지,

어떤 알고리즘을 적용할지 고민하는 것이 개발자의 핵심 업무라고 생각했다.

하지만 실무를 하면서 생각이 조금 바뀌었다.

생각보다 구현은 빠르게 끝나는 경우가 많았다.

오히려 어려운 것은

그래서 정확히 뭘 만들어야 하는데?

를 정리하는 일이었다.

개발은 생각보다 모호함과의 싸움이다

처음 요구사항을 받으면 대부분 이렇게 시작된다.

사용자가 편하게 사용할 수 있게 해주세요.

조회 기능을 개선해주세요.

관리하기 쉽게 만들어주세요.

틀린 말은 아니다.

하지만 개발을 시작하기에는 너무 넓다.

어떤 사용자인지,

무엇이 불편한지,

어떤 상황에서 사용하는지,

성공의 기준은 무엇인지가 빠져있다.

코드는 결국 명확한 지시를 따라 움직인다.

하지만 요구사항은 생각보다 추상적인 상태로 전달되는 경우가 많다.

내가 자주 했던 실수

예전에는 요구사항을 듣고 바로 구현부터 시작했다.

그러다 보면 나중에 이런 일이 생긴다.

아 이 경우도 있어요.

이것도 같이 되어야 해요.

원래 의도는 그게 아니었어요.

그때마다 코드를 수정했다.

당연히 일정은 늘어났고 구조도 점점 복잡해졌다.

돌아보면 개발이 어려웠던 것이 아니라 이해를 잘못했던 경우가 더 많았다.

문서를 쓰기 시작하면서 달라졌다

어느 순간부터 구현 전에 간단한 문서를 작성하기 시작했다.

복잡한 기획 문서는 아니었다.

정말 간단한 수준이었다.

목적
- 왜 만드는가

대상
- 누가 사용하는가

기능
- 무엇을 할 수 있는가

예외
- 어떤 상황을 고려해야 하는가

신기하게도 문서를 쓰기 시작하면 구현보다 먼저 질문이 보였다.

예외 케이스는 없는지,

정말 필요한 기능인지,

다른 기능에 영향은 없는지.

생각보다 많은 문제가 코드를 작성하기 전에 발견됐다.

문제를 정의하는 것이 절반이다

AI를 사용하면서 이 점을 더 많이 느끼고 있다.

요즘은 구현 방법을 찾는 것보다 문제를 설명하는 일이 더 중요하다.

좋은 질문에는 좋은 답이 나온다.

반대로 문제가 모호하면 AI도 모호한 답을 준다.

결국 개발자는 점점

어떻게 만들까?

보다

무엇을 해결해야 할까?

를 고민하는 사람이 되어가는 것 같다.

가장 어려운 것은 사람마다 생각이 다르다는 점

요구사항이 어려운 이유는 정답이 없기 때문이다.

개발자,

기획자,

디자이너,

사용자가 모두 같은 단어를 다르게 이해할 수 있다.

"간단하게"

"빠르게"

"편하게"

같은 표현도 사람마다 기준이 다르다.

그래서 요구사항 정리는 기술 작업이라기보다 번역 작업에 더 가깝다고 느낀다.

각자의 생각을 하나의 문장으로 정리하는 과정 말이다.

마무리

예전에는 좋은 개발자가 구현을 잘하는 사람이라고 생각했다.

지금은 조금 다르게 생각한다.

좋은 개발자는 구현 전에 문제를 명확하게 정의할 수 있는 사람에 가깝다.

구현은 언젠가 끝난다.

하지만 잘못 이해한 요구사항은 프로젝트가 끝날 때까지 따라온다.

그래서 요즘은 코드를 작성하기 전에 스스로 먼저 질문한다.

지금 내가 해결하려는 문제는 정확히 무엇인가?

생각보다 많은 문제의 답은 코드가 아니라 그 질문 안에 있었다.