djm03178   6달 전

알고리즘을 잘 하고 싶은 여러분이 질문 게시판에 질문을 올리기 전에 꼭 알아두셨으면 하는 것들을 모아봤습니다.

읽으면 좋은 글들

질문을 올리기 전에

여기에 서술할 내용 대다수는 위의 링크들에 이미 언급된 내용이지만, 특히 중요하다고 생각하는 것, 또 제가 개인적으로 부탁드리고 싶은 것들을 중심으로 다시 쓰겠습니다.

  • ★☆★☆★ 질문 검색을 통해 기존 질문들을 봅시다. ★☆★☆★ 질문 검색이란, 문제 페이지의 상단에 있는 여러 탭들 중 가장 오른쪽에 있는 "질문 검색" 탭을 말합니다. 여기에 가면 해당 문제에 대한 다른 사람들의 질문을 볼 수 있습니다. 내가 겪고 있는 문제는 다른 사람들 역시 똑같이 겪었을 확률이 매우 높습니다. 답변 글 자체가 내 코드의 문제점을 지적하고 있을 수도 있고, 문제의 원인은 다르더라도 답변에 달린 반례가 우연히도 내 코드의 반례가 될 수도 있습니다. 가능하면 기존의 질문글은 모두 읽어보고, 반례만 찾는 데에 그치기보다는 각 답변이 지적하는 내용에도 주의를 기울이면서 나도 비슷한 실수를 한 것은 아닌지도 확인해봅시다.
  • FAQ 글은 꼭 읽어보세요. 질문자 수가 많은 문제들의 경우 대부분 저와 @jh05013 님이 작성한 FAQ 글이 질문 게시판에 있습니다. 올라오는 질문의 대다수는 FAQ 글에서 문제의 원인을 찾을 수 있습니다.
  • 예제만 넣어보고 잘 돌아간다고 생각하지 마세요. 예제는 말 그대로 예제일 뿐입니다. 채점 서버에는 우리에게 공개되지 않는 수많은 입력 데이터가 있고, 이 모두를 통과해야만 정답을 받습니다. 꼭 '틀렸습니다'가 아니라 '런타임 에러', '시간 초과' 등도 마찬가지입니다. 로컬에서는 실행이 잘 되는데 제출하면 런타임 에러가 나는 것이 아니고, 런타임 에러가 날 만한 입력을 로컬에서 안 넣어보았기 때문에 안 났을 뿐입니다. 로컬에서는 답이 바로 나오는데 제출하면 시간 초과가 나는 것이 아니고, 시간 초과가 날 만한 입력을 로컬에서 안 넣어보았기 때문에 답이 바로 나왔을 뿐입니다. 물론 정말로 안 날 수도 있지만, 똑같은 조건으로, 즉, 채점 서버가 가지고 있는 모든 데이터들에 대해 실험을 해보지도 않고서 알 수는 없는 것입니다. 애초에 채점 데이터는 공개되지 않으니 이런 실험을 하는 것 자체가 불가능합니다. 내 코드를 틀리게 하는 반례가 존재함을 인지하고 문제점을 찾아나서야만 실력을 향상시킬 수 있습니다.
  • 다양한 입력을 스스로 만들어 보세요. 반례를 직접 만들어보는 것도 연습이 필요합니다. 예제가 나왔는데 틀렸다고 곧바로 질문하려 하지 말고, 스스로 반례를 찾아보고 틀린 이유를 분석하고 디버깅하는 과정을 끊임없이 거쳐야 실력을 향상시킬 수 있습니다.
  • 어떤 문제든 질문을 올리기 전 최소 30분은 고민해봅시다. 틀린 원인을 찾는 건 프로그래밍을 하는 데에 있어 매우 중요한 일이고 스스로 디버깅하는 데에 30분은 결코 긴 시간이 아닙니다.
  • 입력 형식을 그대로 지켜서 테스트 하세요. 예를 들면 두 수가 한 줄에 주어지는데 두 줄에 걸쳐서 입력받도록 한다든가, 숫자들 사이에 띄어쓰기가 없는데 띄어쓰기를 기준으로 입력받는 함수를 사용한다든가 하면 당연히 안 됩니다. 예제 옆에 '복사' 버튼이 괜히 있는 게 아닙니다.
  • 출력 형식도 그대로 지켜서 출력하세요. 대소문자 구분, 띄어쓰기, 개행 등 모든 글자가 정확하게 일치해야만 올바른 출력입니다. 매 줄의 끝에 공백 한 개의 유무, 마지막 줄의 개행 유무 정도의 눈에 보이지 않는 사소한 차이까지만 채점 프로그램이 인정해 줄 뿐, 기본적으로는 문제에서 요구하는, 예제 출력에서 보여주는 그대로를 한 글자도 다름없이 출력해야 합니다. 또한 불필요한 내용, 예를 들면 "정수를 입력하세요: " 와 같은 답과 무관한 내용을 출력해도 오답입니다.
  • 컴파일 에러는 "컴파일 에러"라고 쓰인 곳을 클릭하면 에러 메시지를 볼 수 있습니다.

질문 작성 시

  • 카테고리는 '질문'으로 설정하고, 문제 번호는 문제 번호를 적는 칸에 꼭 적읍시다. 문제 번호는 다른 사람들이 이 질문이 어떤 문제에 대한 질문인지 바로 확인하고 찾아갈 수 있는 링크를 제공해 줍니다.
  • 코드는 코드 올리는 칸에 넣읍시다. 글 본문에 코드를 넣으면 가독성이 매우 떨어집니다. 아래에 코드 올리는 칸이 따로 마련되어 있으니 반드시 코드 올리는 칸에 코드를 올립시다.
  • 반드시 틀린 코드 그대로를 한 자도 다름없이 올립시다. 로컬에서 테스트한 코드가 아니라, ★☆★☆★ 제출했던 코드 그대로 ★☆★☆★ 를 말하는 것입니다. 제출한 코드는 '내 소스' 탭에서 언어 이름을 클릭하면 볼 수 있으니 반드시 그 코드 그대로를 복사합시다. 한 글자라도 다른 코드를 올리면 제출 시 받았던 채점 결과와 전혀 다른 결과를 받을 수도 있고, 엉뚱한 곳에서 다른 오류가 생길 수도 있습니다. 심지어 틀린 부분을 고쳐서 맞는 코드를 만들어놓고도 제출을 안 해보고 질문을 올리는 경우도 심심찮게 보입니다. 꼭 마지막에 제출했던 코드 그대로를 올려주세요. 또한 코드는 반드시 전체를 올려야 다른 사람들도 복사해서 직접 테스트 해볼 수 있을 뿐 아니라, 내가 맞았다고 확신한 부분이 문제의 원인일 수도 있기 때문에 아무리 상관이 없어 보여도 꼭 전체를 올려야 합니다.
  • 맞은 코드와 틀린 코드의 차이가 궁금하다면 반드시 틀린 코드를 첨부합시다. 맞은 코드는 문제가 (아마도) 없으니까 맞았을 것입니다. 그러니 맞은 코드를 첨부해도 답변자가 딱히 도와줄 수 있는 부분이 없습니다. 중요한 건 틀린 코드입니다. 틀린 코드에는 문제가 있으니까 틀렸을 것이고, 위와 마찬가지로 틀린 코드를 한 글자도 다름없이 그대로 올려야 그 문제점을 찾을 수 있습니다. 맞은 코드를 올려놓고 "여기랑 저기를 이렇게 저렇게 바꿨는데~"라고 설명하지 말고, 틀린 코드를 우선적으로 올립시다. 말로 변경된 부분을 설명해도, 정말로 그 부분 외에 단 한 글자도 다르게 고친 부분이 없는지 답변자는 알 수 없습니다. 실제로 맞은 코드를 올려놓은 질문들의 경우, 질문자가 바꿔서 틀렸다는 부분만 말 그대로 바꾸어도 맞았습니다를 받는 경우가 대부분입니다. 말로 설명하지 않은 부분을 한 글자라도 바꾼 곳이 더 있어서 틀리는 경우가 더 많습니다.
  • 어떤 채점 결과를 받았는지 정확하게 적읍시다. 예를 들어 '틀렸습니다'를 받았다면 '틀렸습니다'를 받았다고 적어야지, '에러가 납니다'나 '멈춥니다', '안 됩니다', '실패합니다' 등과 같은 모호한 표현을 쓰면 그 코드의 채점 결과를 알아내기 위해 답변자가 다시 제출해보거나, 질문자의 제출 이력을 검색해봐야 하는 번거로움이 생깁니다.
  • 직접 돌려봤을 때 문제가 생겼다면, 그 문제가 뭔지 구체적으로 설명합시다. 예를 들어 어떤 입력을 넣었을 때 프로그램이 동작을 중지했다면 그 입력이 무엇이었는지, 어디까지 진행되었는지, 어떤 에러 메시지가 뜨지는 않았는지 등을 설명하면 답변자에게 큰 힌트가 됩니다. 아무 보조 설명 없이 "에러가 납니다"라고만 하면 어떻게 그 에러를 다른 사람들도 발생시켜봐야 할지 알 수도 없고, 그 에러가 답변자의 환경에서는 우연히도 발생하지 않을 수도 있어 더욱 막막합니다.
  • 코드에 대한 설명을 적읍시다. 다른 사람의 코드를 읽는 것은 매우 매우 매우 매우 어려운 일입니다. 설명이 없는 코드는 다른 사람이 보기엔 외계어에 가깝습니다. 하나부터 열까지 길게 설명하라는 뜻이 아닙니다. 내가 어떤 로직을 가지고 문제를 해결하려 했고, 그래서 어떤 코드를 통해 어떤 동작을 의도했으며, 어떤 변수가 어떤 역할을 하는지 정도만 간략하게 적으면 됩니다.
  • 불필요한 말들은 적지 않아도 됩니다. 대표적인 예시로,
    • "C언어 공부를 막 시작한 코린이입니다. 비주얼 스튜디오에서는 잘 돌아가는데 제출만 하면 5%에서 틀렸다고 나옵니다. 질문 게시판에 있는 반례 다 해봤고 임의로 만든 입력도 다 잘 나오는데 대체 왜 틀렸다고 나오는지 이유를 도통 모르겠습니다... 이틀째 이 문제만 붙들고 있습니다ㅠㅠ 제발 한 번만 도와주세요!"
    • 내용이 길기만 하고 정작 답변자에게 힌트가 될 만한 내용은 하나도 담겨있지 않습니다. 내 프로그래밍 경력이 얼마인지, 몇 %에서 틀렸는지, 잘 나오는 테스트가 뭐였는지, 얼마나 고생하고 있는지 알려주는 것은 답변자가 도움을 주는 데에 아무런 도움이 안 됩니다. 어떻게 하면 답변자가 내 질문과 코드를 읽고 싶게 만들고, 문제점을 쉽게 찾게 만들 수 있을지를 생각해 보세요.
  • 코드가 깨지지 않게 조심합시다. 간혹 올라오는 질문들 중 코드의 인덴트가 깨지고 꺾쇠괄호 <> 부분이 잘리는 경우가 보입니다. 에디터의 버그로 보이는데, 질문을 올릴 때 이런 상태가 되지 않았는지 한 번만 다시 확인해봅시다.

질문 작성 후

  • 이어지는 질문은 답글로 이어서 합시다. 같은 문제의 같은 코드에 대한 질문글을 굳이 중복으로 만들 필요도 없고, 하나의 글에서 이어서 하는 편이 보는 사람도 질문의 맥락을 이해하기 쉽습니다.
  • 코드를 수정했는데도 문제가 있다면 수정한 코드 전체를 다시 올립시다. 나는 분명 올바르게 고쳤고, 다른 곳에는 일절 영향이 없을 것이기 때문에 말로만 대충 설명하면 된다고 생각할 수도 있습니다. 그러나 내가 수정한 코드가 정말로, 정말로 100% 결함이 없는 코드인지 답변자에게 보여주지도 않고서 확신을 시킬 수는 없습니다. 게다가, 똑같이 올바르게 고친다고 해도 그 방법이 여럿 있을 수 있고, 구체적인 방법에 따라 코드의 다른 부분에 미치는 영향도 얼마든지 달라질 수 있습니다. 위에서 강조한 내용을 한 번 더 강조합니다. 힘들게 말로 설명하지 말고, 편하게 컨트롤 CV로 코드를 복붙하세요. 설명은 일단 코드를 올린 뒤에 덧붙여도 늦지 않습니다.
  • 답변이 달린 질문을 지우지 맙시다. 추후에 다른 사람이 내 질문글과 그 답변들을 보면서 도움을 얻고 좋은 참고 자료로 사용할 수도 있습니다. 질문한 내용이 부끄러울 수도 있지만, 그렇다고 해서 그 질문이 무의미했던 것은 아닙니다. 특히 답변이 달린 질문글을 지우면 답변을 열심히 달아준 답변자의 글까지 같이 없어지므로 답변자에게 큰 폐를 끼치게 됩니다.
  • 해결된 질문에는 '해결됨' 표시를 답시다. 특히, 답변을 받지 않고 스스로 해결한 경우에 아무런 표시가 없으면 다른 사람이 이미 해결된 질문에 열심히 답변을 다는 수고를 하게 될 수도 있습니다. 질문의 상단에 있는 '해결 됨으로 바꾸기' 버튼을 클릭해서 달 수 있습니다.
  • 답변자에게 감사를 표시합시다. 질문 게시판에 답변을 다는 사람들은 모두 자발적으로 시간을 내어 무보수로 도움을 주는 사람들입니다. 답변에 '좋아요'를 누르는 것으로도 충분하지만, 짤막한 감사 인사 한 마디는 그들이 계속해서 질문 게시판에서 활동을 하는 원동력이 됩니다.

기타

  • "테스트 케이스가 다 맞는다"라는 표현은 부적절합니다. 테스트 케이스에는 '예제'라는 뜻이 전혀 담겨있지 않으며, '예제'라는 말을 굳이 영어로 쓰고 싶다면 '샘플'이라고 써야 합니다. 정말로 조건 내에서 가능한 모든 입력을 전부 검증해 본 것도 아닌데 다 맞는다고 단정지을 수는 없습니다. 게다가, 예제가 다 맞는지 여부가 중요한 것도 아닙니다. 예제는 말 그대로 예제일 뿐이고, 다른 입력에 대해서도 올바른 결과를 출력한다는 보장은 전혀 되지 않기 때문입니다. 뿐만 아니라 미정의 동작 (undefined behavior) 등의 잘못된 코드에 의해, 로컬에서 올바른 답을 출력하는 입력에 대해서도 채점 서버에서는 잘못된 동작을 할 수 있음을 명심하세요.
  • "어떤 코드와 똑같은데 하나는 맞고 하나는 틀린다"라는 말도 부적절합니다. 둘이 차이점이 있기 때문에 서로 다른 채점 결과를 받는 것입니다. 물론, 정말로 동일한 코드인데 서로 다른 결과가 나오는 경우도 간혹 있는데, 이 경우 거의 대부분은 미정의 동작이 있어 프로그램의 실행 결과를 예측할 수 없는 경우로 둘 다 틀린 코드라고 봐야지, 맞아야 할 코드가 틀렸다고 볼 수 없습니다. 프로그래밍 언어에서는 한 글자만 달라지더라도 100% 정반대의 동작을 하는 프로그램이 만들어질 수 있음을 명심하세요.

댓글을 작성하려면 로그인해야 합니다.