질문을 환영한다는 말과, 질문에 답하는 일은 생각보다 멀리 떨어져 있다. 물어봐도 된다고 해놓고 막상 올라온 코드에는 “기본부터 공부하세요”라는 답만 남긴다면, 그 사람은 어디서부터 다시 시작해야 할까. 그렇다고 정답 코드를 통째로 붙여주는 것이 늘 좋은 도움인 것 같지도 않다. 당장의 오류는 사라져도 무엇을 바꾼 것인지 모른 채 넘어갈 수 있으니깐.
미국 뉴햄프셔에서 개발하는 Jessica Doering의 10월 29일 글도 이 간격을 다룬다. 초보자를 환영한다고 말하는 커뮤니티에서, 실제로 질문하거나 작은 작업을 공개하는 일은 얼마나 편한가. 자신의 경험이 모든 여성이나 초보자를 대표하지 않는다는 선을 분명히 그은 점이 좋았다. 누군가의 좋은 경험으로 다른 사람의 어려움까지 없었다고 할 수는 없는 것이다.
이 글은 오늘 새로 나온 소식은 아니다. 이번 주 DEV의 토론 목록에서 다시 읽었고, 내가 더 생각해보고 싶은 것은 환영 문구보다 그 아래에 달릴 첫 답변이다. 질문하는 방법은 앞서 작은 재현 예제를 정리하는 글에서도 살펴봤다. 이번에는 반대편, 이미 조금 더 알고 있는 사람이 답할 차례를 생각해본다.
틀린 곳을 알려준 뒤에 남는 것
설명을 위해 간단한 폼을 가정해보자. 누군가 공백만 넣고 저장했는데 성공으로 표시된다고 질문한다. 코드를 본 사람이 “검증이 잘못됐네요”라고 답한다. 맞는 말일 수 있다. 그런데 이 답을 받은 사람은 검증이라는 이름을 하나 더 알게 됐을 뿐, 지금 열린 파일에서 무엇을 확인해야 하는지까지 알게 된 것은 아니다.
나는 답변에 작은 입력 하나를 남기면 좋겠다. “공백 세 칸을 넣었을 때도 저장 요청이 나가는지 먼저 봐주세요. 빈 내용을 거절하려는 폼이라면, 기대하는 것은 요청 전에 오류가 보이는 동작입니다.” 여기까지는 원인을 확정하지 않는다. 문자열이 존재하는지만 확인했을 수도 있고, 브라우저에서 보낸 값과 서버에 저장한 값이 달라졌을 수도 있다. 실제 코드를 보지 않고 어느 쪽이라고 단정할 이유는 없다.
그다음 답변은 관찰한 결과에 따라 달라질 것이다. 요청 자체가 나가지 않았다면 화면의 성공 표시를 살필 수 있고, 요청에 공백이 그대로 들어갔다면 어느 단계가 입력을 검사하는지 좁힐 수 있다. 공백이 전부 잘못된 문자라는 뜻도 아니다. 비밀번호나 자유 형식의 문서처럼 임의로 지우면 안 되는 값도 있다. 이 예제에서는 비어 있는 내용을 저장하지 않기로 한 폼의 약속을 확인하는 것이다.
이렇게 쓰고 보면 답변이 조금 길어진다. 그래도 긴 이론을 한 번에 설명하는 것과는 다르다. 지금 눈앞의 차이 하나를 함께 볼 수 있게 만드는 일이다. 왜 틀렸는지 설명하되, 설명을 읽은 사람이 다음 입력을 직접 골라볼 자리를 남긴다.
잘한 부분을 말하는 것도 비슷한 것 같다. “잘하셨네요”라는 말 뒤에 입력을 읽는 부분과 저장하는 부분을 나눈 점을 짚어주면, 고치는 과정에서 무엇을 유지해야 할지도 보인다. 코드가 지저분하다는 인상과 실제로 잘못된 동작, 팀에서 정한 형식을 한꺼번에 같은 무게로 말하지 않으면 좋겠다. 지금 해결해야 하는 오류 옆에 취향의 차이까지 쌓이면 처음 질문한 문제는 오히려 흐려진다.
다음 답변까지 대신 만들 필요는 없다
도움을 주다 보면 질문을 완성된 과제로 바꾸고 싶어질 때가 있을 것이다. 재현 코드와 환경을 모두 갖춰 오면 답하기 편하다. 하지만 처음인 사람은 어떤 부분을 지워도 되는지조차 모를 수 있다. 그럴 때는 원본 전체를 요구하기보다, 지금 공개할 수 있는 작은 입력과 기대한 결과부터 같이 정리할 수도 있다. 업무 코드나 다른 사람의 정보를 게시판에 올려야만 도움을 받을 수 있는 구조가 되어서는 안 될 것이다.
반대로 모든 것을 대신 고쳐주고 끝내면 질문한 사람의 판단은 어디에 남을까 싶다. 공백만 있는 값과 내용이 있는 값을 각각 넣고 무엇이 달라졌는지 적어보게 하는 정도면 충분할 수도 있다. 설명을 이해했다고 답하는 것과, 바꾼 조건을 스스로 설명하는 것은 다른 일이니깐. 여기서 말하는 폼과 대화는 가정한 예제이며, 어떤 방법으로 실제 학습 성과가 높아졌다고 측정한 이야기는 아니다.
물론 질문에 늘 답할 수는 없다. 시간이 없거나, 해당 분야를 모르거나, 공개된 자료만으로는 판단하기 어려울 때도 있다. 그럴 때 확인하지 않은 해결책을 자신 있게 주는 것보다 어디까지 알 수 있는지 말하는 편이 낫겠다. 지금 제공된 예제에서는 오류가 재현되지 않는다거나, 이 조건을 더 알아야 한다는 설명도 다음 시도의 한 부분이 된다.
환영한다는 말을 더 크게 쓰기 전에, 방금 적은 답변을 한 번 더 읽어보고 싶다. 잘못된 부분은 분명한가. 그걸 읽은 사람이 혼자 해볼 수 있는 작은 행동이 남아 있는가. 초보자에게 필요한 친절은 판단을 없애는 것이 아니라, 그 판단에 들어오는 문턱을 조금 낮추는 일에 가까운 것 같다.
