'문제'에 대해서 좀 더 깊이 있는 사고를 해보려고 한다.
내가 알고 있는 문제에 대한 정의는 '해결해야 할 대상' 이다.
문제를 해결해야 할 대상으로 인식한 이유는 문제가 발생하면 원인이 되는 대상이나 현상이 가장 먼저 눈에 들어오기 때문이다.
문제를 좀 더 추상화하면 다음과 같이 정의할 수 있다.
'현재 상태와 원하는 상태 사이의 간격'
문제의 크기는 그림에서 보여지는 것 처럼 간격의 거리이다. 간격이 좁으면 작은 문제이고, 간격이 크면 큰 문제이다.

위에 보이는 세 가지 문제 중에서 세 번째 문제가 다른 두 개의 문제보다 더 큰 문제라고 볼 수 있다.
그러나 문제의 크기는 절대적인 기준으로 결정되지 않는다.
현재 상태에서 원하는 상태까지의 간격이 얼마나 크게 느껴지는지는 문제를 바라보는 사람의 경험과 지식에 따라 달라질 수 있기 때문이다.
경험과 지식이 풍부한 사람이 세 번째 문제를 맞닥들이더라도 "이 문제 쉽게 해결할 수 있겠네!" 라고 생각하는 반면, 경험과 지식이 부족한 사람은 "이 문제 해결하기 쉽지 않겠는데? 하지 말까?" 라고 생각할 수 있다.
우리가 꾸준히 지식과 경험을 쌓고, 끊임없이 사고하며 성장해야 하는 이유는 인생을 살아가면서 맞닥들이는 다양한 문제들을 해결하기 위해서이다.
문제는 '현재 상태와 원하는 상태의 간격' 이라고 했다.
그렇다면 문제는 그 간격을 얼마나 인식하고 있는가에 따라 네 가지 유형으로 나눌 수 있다.
사람들은 누구나 다양한 문제들을 맞닥들인다.
- 눈 앞에 보이는 문제
- 눈에 보이지 않는 잠재적 문제
- 스스로 정의한 문제
- 문제인지도 모르는 문제

눈 앞에 보이는 문제는 현재 상태와 원하는 상태가 둘 다 명확히 보이고, 문제의 간격도 선명하게 인식된다. 가장 다루기 쉬운 문제 유형이다.
예를 들어보자.
- 서버 CPU 사용률이 85% 이다.
- 서버 CPU 사용률을 50% 이하로 낮춰야 한다.
- 테스트가 실패한다.
- 테스트가 성공해야 한다.
- API 응답 속도가 점점 느려지고 있다.
- API 응답 평균 속도를 100ms 이하로 낮춰야 한다.

눈에 보이지 않는 잠재적 문제는 현재 상태는 보이지만, 현재 시점에서는 문제의 간격이 드러나지 않는다.
원하는 상태를 의식적으로 정의하거나 미래를 가정해야 비로소 문제가 인식된다.
예를 들어보자.
- 트래픽이 3배 증가하면 장애가 발생할 구조
- 트래픽이 3배 증가해도 안정적으로 서비스를 제공해야 한다.
- 기술 부채가 계속 쌓이는 구조
- 기능을 추가하거나 수정하더라도 계속 속도와 품질이 유지되어야 한다.
- 특정 개발자 한 명만 알고 있는 시스템
- 팀원 누구나 시스템을 이해하고 유지보수 할 수 있어야 한다.

스스로 정의한 문제는 본인이 직접 목표를 설정하고 현재 상태와의 간격을 만들어내는 문제이다.
기존 문제를 해결하는 사람이 아니라 새로운 문제를 정의하는 역할을 한다.
현재는 아무런 문제가 없어 보일 수도 있다. 하지만 더 높은 목표를 설정하는 순간, 현재 상태와의 간격이 생기면서 새로운 문제가 정의된다.
즉, 목표를 높일수록 해결해야 할 문제도 새롭게 생겨난다.
많은 혁신은 기존 문제를 해결하는 것보다 새로운 목표를 정의하는 과정에서 시작된다.
예를 들어보자.
- 운영을 자동화하자.
- 사람이 반복적으로 수행하는 운영 업무를 자동화해야 한다.
- AI를 활용해 업무 효율을 높여 보자.
- AI를 활용하여 업무 생산성을 더욱 향상시켜야 한다.
- 조직 문화를 개선해 보자.
- 구성원들이 더 효과적으로 협업할 수 있는 문화를 만들어야 한다.
- 우선순위 기준을 잡아보자.
- 모두가 동일한 기준으로 의사결정을 할 수 있어야 한다.
- 고객 경험을 더 좋게 만들어 보자.
- 고객이 서비스를 더 쉽고 편리하게 사용할 수 있어야 한다.

문제인지도 모르는 문제는 가장 위험한 문제 유형이다.
현재 상태를 제대로 인식하지 못하거나, 더 나은 상태가 존재한다는 사실 자체를 알지 못한다.
따라서 현재 상태와 원하는 상태 사이에 간격이 존재한다는 사실조차 인식하지 못한다.
문제를 해결하기는커녕, 문제를 문제로 받아들이지 못하는 상태이다.
예를 들어보자.
- 보안 취약점이 존재하지만 이를 전혀 인식하지 못한다.
- 고객이 서비스를 불편하게 사용하고 있다는 사실을 모른다.
- 자신의 실력이 부족하다는 사실을 인식하지 못한다.
4개의 문제 유형을 인식하는 시점은 경험과 지식의 양에 따라서 달라짐을 느낀다.
내가 주니어 시절에는 눈 앞에 닥친 문제만 해결하느라 급급했는데, 경험과 지식이 어느정도 쌓으면서부터는 점점 눈에 보이지 않는 문제들이 보이기 시작했다.
그리고 시니어 경험을 축적하면서 새로운 문제 정의를 하는 수준까지 도달하게 된 듯 하다.
'개발이야기' 카테고리의 다른 글
| 첫 회사에서부터 엔씨소프트 희망 퇴직 까지의 여정 (36) | 2024.12.17 |
|---|---|
| 얇은 지식의 확장과 AI를 이용하여 깊이 보완하기 (0) | 2024.06.24 |
| 3번의 MSA 아키텍처 경험 (0) | 2024.06.17 |
| REST API 설계 시 코드성 값 (Integer vs String) (0) | 2023.05.17 |
| if 지옥에 빠지다 (0) | 2023.05.13 |
| 비효율의 숙달화 (448) | 2023.05.10 |
| Java Heap Dump 를 이용한 문제 해결 (0) | 2021.05.27 |
| Github webhook 302 오류 (0) | 2021.05.20 |