안녕하세요. 꿈꾸는 개발자 하늘고래입니다.
종종 후배 개발자들이 진로와 관련된 상담 요청을 하여 상담할 때가 있습니다. 팀장으로서 또는 선배 또는 동료 개발자로서 답을 해주곤 합니다.
( 요즘 들어 말이 점점 더 많아지는 것으로 보아 꼰대가 되는 건 아닌지 걱정이 되네요. )
특히 C++로 개발하고 있는 친구들이 앞으로의 진로나 비전에 대해서 고민이 많은 것 같습니다. 인터넷이 발달하고, 모바일 플랫폼이 발달하면서 예전과 비교해 C++의 입지는 많이 줄어든 것은 사실입니다. 특히, C++ 기반 애플리케이션은 훨씬 더 많이 줄어든 느낌이 듭니다. 실제 네이버 계열사나 카카오 계열사 또는 유니콘 업체와 같이 큰 기업들은 C++보다는 주로 서버 영역으로 사람들 더 많이 구하고 있으니 이러한 고민이 괜한 우려가 아님을 알 수 있습니다.
사람마다 환경이 다르기에 딱 이렇게 하면 좋다는 일관된 답을 줄 수 있는 것은 아니지만, 그래도 항상 이야기 끝에는 언어도 중요하지만, 기본적으로 개발자가 갖춰야 할 덕목에 관해서 이야기하고 마무리하는 경우가 많습니다.
변화가 빠른 세상에서 하나의 언어를 깊게 아는 것도 중요하지만, 트렌드에 맞게 나를 변화시키는 것도 매우 중요한 일입니다. 그러기 위해서는 끊임없는 공부가 필요하기도 합니다. 하지만 역설적으로 변화에 적응하는 것도 중요하지만 변하지 않는 Identity를 갖는 것도 매우 중요합니다. 제 개인적인 생각에 개발에 있어 변하지 않는 Identity는 효율적인 문제 해결입니다.
사실 문제를 해결하는 과정은 대부분 알고 있으나, 이를 제대로 지키는 경우는 많지 않습니다. 생각보다 어려운 경우가 많이 있습니다. 이와 관련해서 꾸준한 훈련이 필요합니다.
해결하고자 하는 문제 정의
문제 정의는 “무엇”을 개발하는지 결정하는 단계입니다. 요구사항을 분석하고 정의하는 단계로, 여기서 가장 중요한 점은 요구사항을 프로그램을 사용하는 사용자 입장에서 생각하고 파악하고 명확하게 정의하는 것입니다. 또한 “무엇”을 개발할지에 대해서 추상적인 개념으로 접근하면 안 되고, 정확하게 문장으로 표현할 수 있어야 합니다.
이 단계 매우 중요한 이유는 프로그램 개발의 시작 단계이기 때문입니다. “무엇”을 개발할지에 대한 목표가 잘못되면 아무리 좋은 해결책을 통해 문제를 해결했다 하더라도 사용자가 원하는 문제가 해결될 가능성이 매우 낮기 때문입니다.
문제는 여러 가지 종류가 있습니다. 프로그램을 사용하면서 발생하는 여러 가지 불편함과 버그가 있을 수 있으며, 원하는 기능이 존재하지 않거나, 법이 바꾸면서 법에 저촉되는 경우가 발생할 수 있습니다.
사실 이러한 문제들은 개발자가 개발을 통해 해결해야 하는데, 개발자에게 넘어온 요구사항이 추상적이든 구체적이든 결국 개발자는 “무엇”을 개발하는지 파악해야 합니다.
만약, N까지의 합을 구하는 프로그램을 만든다고 가정한다면, 문제 정의는 다음과 같이 구체적인 한 문장을 표현되어야 합니다.
사용자가 화면에 0보다 큰 수를 입력하면, 그 수까지의 합을 계산하여 화면에 출력하는 프로그램을 만든다.
문제 해결 방안 모색
문제 해결 방안을 모색하는 단계는 “어떻게”를 결정하는 단계입니다. 흔히 말하는 설계 단계로, “무엇”을 개발하는지 결정되었다면 다음 단계로 문제를 “어떻게” 해결할지 고민하는 단계입니다.
사실 문제를 해결하는 방법은 수만가지가 있습니다. 여기서 중요한 점은 성능적으로 가장 좋은 해결책을 찾는 게 아닌, 현재 여러 가지 상황을 고려하여 가장 적합한 해결책을 찾아야 한다는 점입니다. 예를 들어 프로젝트 일정이 정해진 상태에서 성능적으로 가장 좋은 것을 만들기 위해서 리팩토링을 거쳐 전체적으로 다 변경해야 하는데, 그게 일정 내 불가능하다면 일정 내 해결 가능한 방법을 찾아야 합니다.
또한, 해결책을 찾고 바로 코딩에 들어가는 경우가 비일비재합니다. 아무리 간단한 부분이라도 바로 코딩에 들어간다면 빠르게 개발할 수 있어도 이로 인해 나중에 확장하기 어렵거나 버그가 많은 프로그램이 발생할 수 있습니다. 따라서 개발을 전에 문제를 해결하기 위한 방법을 찾고, 필요하다면 주변의 동료에게 방법을 공유, 논의 후 개발에 들어가는 것이 좋습니다. 여기서 그냥 바로 개발하는 것 보다 약간의 시간이 더 소모된다고 하더라도, 나중에 발생할 수 있는 버그를 줄여 유지보수 시간을 줄일 수 있다면 이게 훨씬 더 이득입니다.