추가 글을 하나 남깁니다. 모든 내용은 저의 경험을 바탕으로 한 것으로 다른 배경을 가지신 분은 다르게 생각하실 수도 있습니다.
BOJ의 정체성은 ICPC와 올림피아드에 있지만, 코딩 테스트를 준비하는데도 사용할 수 있습니다. 정체성과는 별개로 코딩 테스트 덕분에 사용자도 꽤 많이 늘었고, 저도 즐겁게 BOJ에 문제를 올리고 운영할 수 있었습니다.
4월 15일에 공지 글을 올리고 여러가지 반응을 보았습니다. 그 중 “LLM이 문제를 잘 풀어서 코딩 테스트가 의미가 없다” 라는 의견에는 동의하기는 어렵습니다.
1. 경험
코딩 테스트와는 별개로, 예전부터 문제를 잘 푸는 것이 어떤 도움이 되는지에 대한 질문을 많이 받았습니다. 이에 대한 정답은 알 수 없습니다. 어떤 경험이 실제로 얼마나 영향을 미쳤는지를 판단하기는 어렵고, 어떤 것을 잘하는 데에도 하나의 방법만 있는 것은 아니기 때문입니다.
저의 경우에는 정보올림피아드로 시작해서 ICPC 대회에 나갔고, 이를 통해서 프로그래밍을 공부했습니다. 항상 콘솔창에서만 코딩을 했기 때문에, 뭔가 인터랙티브한 것을 만들어보고 싶었고, 2009년에 웹 프로그래밍을 공부하게 되었습니다. 또, 2010년 초부터는 iOS 앱 개발을 해서 실제로 꾸준한 수익을 어느정도 내기도 했었습니다.
문제를 풀때는 생각을 많이 하게 되고, 어떻게 내가 구현할지를 머리 속으로 정리를 많이 했는데, 이러한 경험이 다른 프로그래밍에서 크게 도움이 되었습니다. 저는 어떤 특정 알고리즘 또는 자료구조를 사용하는 것보다 이런 꾸준한 프로그래밍 경험과 생각의 깊이가 더 중요했다고 생각합니다. 특정 알고리즘이나 자료구조를 사용한 적도 당연히 있습니다. BOJ 기능을 만들때 다이나믹 프로그래밍을 이용한 적은 없지만, 일직선 상에 겹치는 선분의 개수를 세는 알고리즘 이용한 적은 있습니다.
디버깅 능력 역시 크게 도움이 되었습니다. 문제를 풀고 제출을 하면 물론 한 번에 맞는 경우도 많았지만 틀리는 경우도 있었습니다. 이때 했던 디버깅은 이후 BOJ의 개발에 큰 도움이 되었습니다.
BOJ의 초창기 모습은 월 16,500원의 가상 서버 호스팅에서 당시 오픈 소스 온라인 저지였던 hustoj를 이용해서 운영하던 서비스였고, 방문자도 크게 많지 않았습니다. 2012년에 런던 올림픽을 보면서 전체를 다시 구현했습니다. 이때 hustoj의 허가를 받고 hustoj를 사용한 사이트라는 문구도 빠지게 되었습니다.
2012년 당시에도 많은 사람이 사용하던 사이트는 아니었기 때문에, 비효율적인 부분도 원활하게 돌아갔습니다. 해가 지나가고 이용자가 점점 많아지면서 비효율적인 부분이 문제가 되기 시작했고, 문제를 풀때 익힌 디버깅 경험을 통해서 점점 고쳐나갔습니다.
디버깅 경험은 코드 디버깅 뿐만 아니고 로드 밸런싱, DB 서버 관련 오류 등을 디버깅하는데도 크게 도움이 되었습니다. 아직도 마음이 아픈 UCPC 서버 사고의 원인을 파악하기 위한 디버깅에서도 이 경험은 큰 도움이 되었습니다.
물론 제가 정보올림피아드나 ICPC에서 최상위권이었던 사람도 아니고, 웹이나 iOS 프로그래밍도 이름을 날렸던 사람은 아니기에 제 경험이나 생각이 틀릴 수 있습니다.
프로그래밍의 분야는 다양하기 때문에, 당연히 필요가 없을 수도 있고, 도움이 되지 않았을 수도 있습니다. 또한, 위의 제 경험은 다른 경험을 통해서도 충분히 배울 수 있습니다. 오직 문제를 푸는 것만이 기를 수 있다는 의견은 아닙니다.
2. 코딩 테스트
코딩 테스트의 목적은 문제를 잘 푸는 사람을 뽑기 위함이 아닙니다. 그런 목적이면 프로그래밍 대회를 열면 됩니다. 가장 중요한건 글로 되어 있는 문제를 이해하는 능력과 구현 능력이라고 생각합니다.
위의 목적 때문에 코딩 테스트에 사용되는 알고리즘과 자료구조는 어느정도 범위가 정해져있을 수 밖에 없습니다. 물론 변별력을 높인다는 명분 하에 더 어려운 알고리즘을 사용해야 하는 문제를 낼 수는 있지만, 이건 코딩 테스트의 목적과는 전혀 맞지 않다고 생각합니다.
또한 문제는 문제를 위한 문제도 만들 수 있지만, 업무를 하다 보면 만나는 상황을 이용해서 조건을 여러가지 추가하면서 만들 수 있습니다.
다만 코딩 테스트는 만능이 아닙니다. 짧은 시간 안에 제한된 형태의 문제를 해결해야 하기 때문에, 업무에 필요한 다양한 능력을 확인하기에는 한계가 있습니다. 실제로 코딩 테스트 문제를 잘 풀지 못하더라도 뛰어난 개발자들은 많이 존재합니다.
3. AI
위의 제 생각 때문에 LLM이 존재한다고 해서 코딩 테스트가 의미가 없어지는 것은 아니라고 생각합니다. 코딩 테스트가 없어질 수도 있고, 더 좋은 다른 방법이 나올 수도 있지만, 문제를 이해하고 해결 방법을 고민하는 과정 자체는 중요하다고 생각합니다.
여기서 말하는 문제는 BOJ나 코딩 테스트 문제가 아니라, 실제로 다양한 상황에서 마주하게 되는 문제를 의미합니다. 예를 들어, 주어진 요구사항을 바탕으로 기능을 구현하는 것, 서비스가 느려지는 원인을 찾고 개선하는 것, 오류가 발생했을 때 그 원인을 추적하고 해결하는 과정 등이 이에 해당한다고 생각합니다.
마지막으로 문제 해결을 알고리즘과 풀이를 암기하는 방식으로 이해하는 분들도 계신 것 같습니다. 이에 대한 답도 위에서 이미 작성한 내용으로 대신할 수 있을 것 같습니다.
접근성이 낮아진다고 해서 쉬워지는 것은 아닙니다. 아는 것이 있을수록 활용할 수 있는 폭은 상상 이상으로 넓어집니다.
startlink 2시간 전 60
안녕하세요.
추가 글을 하나 남깁니다. 모든 내용은 저의 경험을 바탕으로 한 것으로 다른 배경을 가지신 분은 다르게 생각하실 수도 있습니다.
BOJ의 정체성은 ICPC와 올림피아드에 있지만, 코딩 테스트를 준비하는데도 사용할 수 있습니다. 정체성과는 별개로 코딩 테스트 덕분에 사용자도 꽤 많이 늘었고, 저도 즐겁게 BOJ에 문제를 올리고 운영할 수 있었습니다.
4월 15일에 공지 글을 올리고 여러가지 반응을 보았습니다. 그 중 “LLM이 문제를 잘 풀어서 코딩 테스트가 의미가 없다” 라는 의견에는 동의하기는 어렵습니다.
1. 경험
코딩 테스트와는 별개로, 예전부터 문제를 잘 푸는 것이 어떤 도움이 되는지에 대한 질문을 많이 받았습니다. 이에 대한 정답은 알 수 없습니다. 어떤 경험이 실제로 얼마나 영향을 미쳤는지를 판단하기는 어렵고, 어떤 것을 잘하는 데에도 하나의 방법만 있는 것은 아니기 때문입니다.
저의 경우에는 정보올림피아드로 시작해서 ICPC 대회에 나갔고, 이를 통해서 프로그래밍을 공부했습니다. 항상 콘솔창에서만 코딩을 했기 때문에, 뭔가 인터랙티브한 것을 만들어보고 싶었고, 2009년에 웹 프로그래밍을 공부하게 되었습니다. 또, 2010년 초부터는 iOS 앱 개발을 해서 실제로 꾸준한 수익을 어느정도 내기도 했었습니다.
문제를 풀때는 생각을 많이 하게 되고, 어떻게 내가 구현할지를 머리 속으로 정리를 많이 했는데, 이러한 경험이 다른 프로그래밍에서 크게 도움이 되었습니다. 저는 어떤 특정 알고리즘 또는 자료구조를 사용하는 것보다 이런 꾸준한 프로그래밍 경험과 생각의 깊이가 더 중요했다고 생각합니다. 특정 알고리즘이나 자료구조를 사용한 적도 당연히 있습니다. BOJ 기능을 만들때 다이나믹 프로그래밍을 이용한 적은 없지만, 일직선 상에 겹치는 선분의 개수를 세는 알고리즘 이용한 적은 있습니다.
디버깅 능력 역시 크게 도움이 되었습니다. 문제를 풀고 제출을 하면 물론 한 번에 맞는 경우도 많았지만 틀리는 경우도 있었습니다. 이때 했던 디버깅은 이후 BOJ의 개발에 큰 도움이 되었습니다.
BOJ의 초창기 모습은 월 16,500원의 가상 서버 호스팅에서 당시 오픈 소스 온라인 저지였던 hustoj를 이용해서 운영하던 서비스였고, 방문자도 크게 많지 않았습니다. 2012년에 런던 올림픽을 보면서 전체를 다시 구현했습니다. 이때 hustoj의 허가를 받고 hustoj를 사용한 사이트라는 문구도 빠지게 되었습니다.
2012년 당시에도 많은 사람이 사용하던 사이트는 아니었기 때문에, 비효율적인 부분도 원활하게 돌아갔습니다. 해가 지나가고 이용자가 점점 많아지면서 비효율적인 부분이 문제가 되기 시작했고, 문제를 풀때 익힌 디버깅 경험을 통해서 점점 고쳐나갔습니다.
디버깅 경험은 코드 디버깅 뿐만 아니고 로드 밸런싱, DB 서버 관련 오류 등을 디버깅하는데도 크게 도움이 되었습니다. 아직도 마음이 아픈 UCPC 서버 사고의 원인을 파악하기 위한 디버깅에서도 이 경험은 큰 도움이 되었습니다.
물론 제가 정보올림피아드나 ICPC에서 최상위권이었던 사람도 아니고, 웹이나 iOS 프로그래밍도 이름을 날렸던 사람은 아니기에 제 경험이나 생각이 틀릴 수 있습니다.
프로그래밍의 분야는 다양하기 때문에, 당연히 필요가 없을 수도 있고, 도움이 되지 않았을 수도 있습니다. 또한, 위의 제 경험은 다른 경험을 통해서도 충분히 배울 수 있습니다. 오직 문제를 푸는 것만이 기를 수 있다는 의견은 아닙니다.
2. 코딩 테스트
코딩 테스트의 목적은 문제를 잘 푸는 사람을 뽑기 위함이 아닙니다. 그런 목적이면 프로그래밍 대회를 열면 됩니다. 가장 중요한건 글로 되어 있는 문제를 이해하는 능력과 구현 능력이라고 생각합니다.
위의 목적 때문에 코딩 테스트에 사용되는 알고리즘과 자료구조는 어느정도 범위가 정해져있을 수 밖에 없습니다. 물론 변별력을 높인다는 명분 하에 더 어려운 알고리즘을 사용해야 하는 문제를 낼 수는 있지만, 이건 코딩 테스트의 목적과는 전혀 맞지 않다고 생각합니다.
또한 문제는 문제를 위한 문제도 만들 수 있지만, 업무를 하다 보면 만나는 상황을 이용해서 조건을 여러가지 추가하면서 만들 수 있습니다.
다만 코딩 테스트는 만능이 아닙니다. 짧은 시간 안에 제한된 형태의 문제를 해결해야 하기 때문에, 업무에 필요한 다양한 능력을 확인하기에는 한계가 있습니다. 실제로 코딩 테스트 문제를 잘 풀지 못하더라도 뛰어난 개발자들은 많이 존재합니다.
3. AI
위의 제 생각 때문에 LLM이 존재한다고 해서 코딩 테스트가 의미가 없어지는 것은 아니라고 생각합니다. 코딩 테스트가 없어질 수도 있고, 더 좋은 다른 방법이 나올 수도 있지만, 문제를 이해하고 해결 방법을 고민하는 과정 자체는 중요하다고 생각합니다.
여기서 말하는 문제는 BOJ나 코딩 테스트 문제가 아니라, 실제로 다양한 상황에서 마주하게 되는 문제를 의미합니다. 예를 들어, 주어진 요구사항을 바탕으로 기능을 구현하는 것, 서비스가 느려지는 원인을 찾고 개선하는 것, 오류가 발생했을 때 그 원인을 추적하고 해결하는 과정 등이 이에 해당한다고 생각합니다.
마지막으로 문제 해결을 알고리즘과 풀이를 암기하는 방식으로 이해하는 분들도 계신 것 같습니다. 이에 대한 답도 위에서 이미 작성한 내용으로 대신할 수 있을 것 같습니다.
접근성이 낮아진다고 해서 쉬워지는 것은 아닙니다. 아는 것이 있을수록 활용할 수 있는 폭은 상상 이상으로 넓어집니다.