코딩을 하다보면 참으로 자주 막다른 길에 봉착한다. 아니, 자주 그렇다는 건 오만한 표현이다. 쉼 없이 막다른 길에 봉착한다. 문제가 다양한 만큼, 해결책도 다양하다.
AI에게 물어보기
우선 AI에게 물어본다. 작은 문제일 수록 괜찮은 해결책이다. 특히, 오타, 기본적 문법 오류를 찾아내는 데에 탁월하다.
그러나 AI는 부분 점수를 받으려 모르는 질문에도 되는 대로 답하는 대학생처럼, 몰라도 자신있게 답한다. 아래와 같은 답변을 받으면 AI로 해결할 수 없다고 판단하고 다른 해결책을 찾아야 한다.
-
간단한 질문에 장황히 답변한다.
이는 내 질문이 구체적이지 않은 탓일 수도 있고, 애초에 구현이 힘든 기 때문일 수도 있다. 내가 원하는 것을 남들은 어떻게 구현했는지, 혹은 구현을 하기는 하는지 구글링하여 확인할 필요가 있다. -
첫 번째 답변에 문제를 지적했는데 같은 답변을 반복한다.
AI의 학습 데이터에 없는 내용을 물어볼 때 이와 같은 일이 일어난다. 모르는 사람에게 아무리 물어봐도 답은 안 나온다. 두 번 째에도 답이 안 나오면 지체없이 다른 방법을 사용하자.
구글에 검색하기
오류 메시지, 구현하려는 기능 등을 구글에 검색해본다. 스택 오버플로우, 포럼, 블로그 등 관련 있어보이는 글들을 열어보자. 비슷한 문제를 남들이 어떻게 해결했는지 찾아보고 여기서 이해가 안 되는 것은 다시 AI에게 물어본다.
공식 문서 / 타입 정의 파일 살펴보기
구체적 라이브러리에 한정된 지엽적 질문일 수록 AI가 해결해주지 못할 가능성이 커진다. 학습할 데이터가 부족한 탓에 그렇다. 데이터가 부족한 만큼 관련 문제를 다룬 스택 오버플로우, 블로그 등도 드물다. 이런 지엽적 질문은 두 가지로 나뉜다.
첫째, 머릿속에 떠오르는 기능을 구현할 함수 등을 모른다. 이럴 땐 공식 문서를 본다. 라이브러리가 제공하는 1차적 기능을 찾을 때 유용하다. Tailwind css로 가운데 정렬은 어떻게 하나 싶을 때 공식 문서에서 "center"라고 검색하고 관련 문서들을 읽는 것이 도움이 된다.
둘째, 특정 함수의 역할 혹은 한계를 모른다. 이때는 함수 정의를 본다. 커맨드 클릭으로 참조된 함수가 정의된 문서를 열 수 있다. 이를 타입 정의 파일(type definition file)이라고 한다. 여기서 입력 가능한 파라미터, 함수의 변환값의 타입 등을 볼 수 있다. 주석으로 이 함수를 언제 사용하는지도 보통 적혀 있다.
튜토리얼 보기 / MVP 만들기
그러나 위 해결책은 모두 표면적인 문제를 해결할 때 사용된다. 내가 정한 방향성에 문제가 있다면, 이는 위 방법을로 해결되지 않는다. 기저에 깔린 문제 자체를 발견할 수가 없으니 말이다.
하나를 고치면 또 다른 문제가 생기고 아무리 고쳐도 진전이 없다고 느껴질 때가 있다. 하나를 고치려면 이와 엮여 있는 또 다른 것을 고려해야 해서 건들기도 어려울 때가 있다.
문제의 덩치를 줄여야 한다. 문제와 연관된 것이 많으면 항상 그 많은 것들도 동시에 따져야 한다. 사람은 한 번에 한 가지만 의식할 수 있다. 고려할 게 많아지는 순간 생각은 멈춘다. 한 가지에 집중할 수 있게 문제의 덩치를 줄여야 한다.
고치고 싶은 여러 가지 중 가장 중요한 것은 무엇인가? 핵심을 골라내야 한다. 그리고 이 핵심만 구현한 앱이 무엇인지 생각한다. 내 앱이 그 기능을 쓴다고 하여 그 기능의 MVP가 항상 내 앱이지는 않다.
예를 들어 다중 사용자의 실시간 공유 메모 앱을 만드는데 아무리 해도 실시간 공유가 매끄럽게 되지 않는다고 해보자. 핵심 기능은 실시간 동기화이다. 그렇다면 그에만 집중된 앱은 무엇일까? 채팅앱이 떠오른다. 그렇다면 채팅앱 튜토리얼을 찾아본다. 그 튜토리얼의 개요를 보고 내 상황에 맞는 최소 기능 제품을 만들어본다.
매번 다른 줄의 코드를 치는 만큼 매번 다른 문제에 직면한다. 이 때마다 매번 다른 해결책을 찾으려는 것은 너무 고되다. 문제를 어찌어찌 해결했을 때 해결됐으니 됐다고 넘어가는 것이 아니라, 해결했던 경험들을 공통점에 따라 분류해두면 새로운 문제가 생겼을 때 좀 더 쉽게 대응할 수가 있을 것이다.
