Error
개발을 하면서 우리는 많은 문제에 직면해요. 단순히 실행이 되지 않는 것부터 시작해서 원하지 않은 결과가 나오거나, 똑같은 일을 계속해서 반복하고 있는 상황을 경험한 적이 있을 거에요.
오늘은 제가 이런 상황을 어떻게 극복해야 더 나은 개발자가 될 수 있을 지에 대해 고민한 내용을 정리해보려고 해요.
직면하는 문제
개발을 하면서 직면하게 되는 문제는 크게 두 개의 유형이 있다고 생각해요.
첫 번째로 "안돼요." 두 번째는 "귀찮아요."
위 문제들을 살펴보고 저의 생각을 말해보려고 해요.
"안돼요."
"안돼요."는 근본적인 문제에요. 실행이 안될 때, 원하는 결과가 나오지 않을 때, 현실적인 시간 내에 결과가 나오지 않을 때 등 진짜 "문제"라고 할 수 있는 상황이에요.
이러한 문제는 자신에게 문제가 있을 확률이 높기에 코드를 다시 검토하거나, API 명세서를 다시 읽어보거나, 같은 문제를 겪었던 다른 사람의 해결 방법을 살펴보면 대부분 해결할 수 있는 문제라고 생각해요.
"귀찮아요."
이 유형의 문제는 똑같은 작업을 반복하거나, 번거로운 작업을 해야만 하는 상황을 말해요. 프로그램에서 직접적인 오류가 발생하는 문제보다는 프로그램을 개발하기 위해 필요한 작업을 수행하며 발생하는 경우가 많은 것 같아요.
백엔드 개발자가 API를 개발하고 클라이언트 개발자에게 API를 설명하는 상황이 반복된다면 많은 시간이 소요되며 일정에 차질이 생길 수도 있어요.
개발자가 변경된 사항을 배포할 때, 필요한 설정들을 개발자가 직접 하나씩 설정한다면, 이때도 많은 시간을 개발이 아닌 배포에 사용하게 될 수 있어요.
이 유형의 핵심은 "오류는 발생하지 않는다."
아이러니하게 이 문제는 오류가 발생하지 않기 때문에 문제를 해결하지 않으려는 사람도 있어요. 그게 바로 접니다. 위에서 나온 예시처럼 API를 개발하고 클라이언트에게 API를 설명하는 시간으로 회의의 대부분을 소모했던 경험이 있어요.
제가 겪었던 문제들을 살펴보며 고민했던 내용을 이야기할게요.
내가 겪었던 문제 1
Spring Security를 사용하여 애플리케이션의 보안 설정을 정의하기 위해 이전에 작성했던 코드를 가져와서 사용하려는데 오류가 발생했어요. 사용한 지 일주일 채 지나지 않은 코드였는데 오류가 발생해서 단순 설정에서 문제가 있다고 판단하여 의존성 설치도 다시하고, 다른 사람이 사용한 코드도 봤지만 저와 동일하게 사용하고 있었고 해결할 수 없었어요. 그렇게 삽질을 계속하다가 해당 메소드의 접근하고 공식 설명을 보고 문제점을 알게 되었어요. 며칠 전 업데이트 되며 기존 사용 방법은 Deprecate 되고 새로운 방법으로 사용해야 함을 알게 되었어요.
저는 "안돼요."를 직면했을 때 다른 사람의 블로그, Stack Overflow 등을 먼저 검색하는 경우가 많았어요. 물론 많은 문제를 해결한 방법이기도 했어요. 다른 사람의 해결 과정을 보며 인사이트를 얻고 해결한 경우도 있기에 도움이 된다고 생각해요. 하지만 블로그나 Stack Overflow에서는 결국 불특정 다수의 의견이고, 과거의 사용 방법 및 해결 과정이 담겨있어요. 그렇기에 여기에는 내가 직면한 문제에 대한 해결 방법이 신뢰할 수 없거나 존재하지 않을 수 있어요. 추가로 이전에도 블로그를 참고하며 React Router를 사용하고 오류가 발생한적이 있었는데, 사용 방법이 바뀌었다는 것을 공식 문서를 통해 알게 되었고 공식 문서의 예제를 보고 해결한 적이 있어요.
이러한 문제를 해결하고 더 나은 개발자가 되기 위해서는 공식 문서를 읽어보는 습관을 들이는 것이 좋은 것 같아요. 만든 사람이 사용자를 위해 만든 공식 문서보다 정확한 것 없다는 것을 명심하려고 해요.
내가 겪었던 문제 2
이전 글에도 작성한 적 있던 백엔드 API 명세 과정이에요. 이전 프로젝트를 진행할 때 하나의 API를 만들면 사용 방법을 설명하기 위해 클라이언트 개발자들을 모아서 직접 설명하고 Postman을 사용하여 예시도 보여주었어요. 여러 API가 만들어졌을 때는 개발보다 설명에 시간을 쏟는 저를 볼 수 있었어요. 너무 비효율적이라는 것을 몸으로 느낀 저는 팀 Notion 페이지에 API 명세서를 작성했어요.
팀원에게 설명하는 시간은 확실히 단축되었어요. 하지만 변경 사항이 생겼을 때 Notion 페이지도 최신화해야 명세서 기능이 유지되기 때문에 이 점은 여전히 불편했지만,
"귀찮아요."
API에 문제가 생긴 것은 아니기에 프로젝트가 끝날 때까지 Notion에 API 명세서를 작성했어요. 그렇게 프로젝트가 끝나고 제가 겪었던 문제를 해결하기 위해 Swagger 프레임워크를 배웠어요. 기존 해결했던 명세서 작성 작업은 물론이고, 코드 변경과 동시에 최신화가 가능한 점, 테스트 케이스 생성이 가능한 점은 제가 겪은 문제를 해결해주었어요.
이러한 도구들은 초기에 배우는 시간이라는 비용이 필요하지만,사용할 수 있을 정도만 되어도 얻을 수 있는 이득은 시간이 지날 수록 커지게 되는 것 같아요.
내가 겪었던 문제 3
백엔드 애플리케이션을 만들고 실행하려고 할 때 본인의 컴퓨터를 24시간 켜둘 수 없기 때문에 서버를 이용하게 되는데 이때 로컬 개발 환경과 서버의 환경은 다르기 때문에 이를 맞춰주는 작업과 애플리케이션을 옮기는 과정이 필요해요. 하지만 이 과정은 "귀찮아요."
이러한 과정을 줄이기 위해 찾아보던 와중 Docker와 GitHub Actions를 알게 되었어요. 이 둘에 대한 설명은 공식 문서에 자세히 나와있기 때문에 생략할게요. 알게된 Docker와 GitHub Actions의 사용 방법을 배우고 서버의 환경 설정 과정을 없앨 수 있었고, 로컬 환경에서 애플리케이션을 서버로 보내야 하는 과정을 간소화 시켰어요. 이 배움을 통해 평소 빌드 및 테스트 부터 배포까지 걸리는 시간을 약 8~90% 감소시켰어요.
이렇게 시간을 단축하고 개발에 더 집중하게 되는 것이 개발자로서 매우 큰 이득이라고 생각해서 저는 이러한 도구를 사용 방법만이라도 배우는 것을 추천해요.
마무리
- 안되면 공식문서를 찾아봐요.
- 귀찮으면 도구를 배워봐요.
- 문제를 인지하면 미루지 말고 해결하려는 마음가짐을 가지려고 해요.
- 도구를 배우는 시간이라는 비용은 문제 해결과 그 이후에 얻는 이득을 위해 지불할 가치가 충분해요.
- 개발에 관련된 도구 외에도 Work flow 관리를 위한 Jira, 문서 기반 협업의 용도로 사용하는 Confluence 등 여러 가지 도구가 존재해요.
