내가 글을 잘 못 쓰는 이유

부제: 너무 고려하지 말 것

들어가기 전

본 글은 제가 “왜 나는 글을 못 쓸까”라는 주관적인 깨달음을 얻기까지 과정에 대한 이야기입니다. 뭔가 제목만 보고 기대하는, 글 잘 쓰는 방법과 같은 내용은 나오지 않습니다.

원래 부제를 “프로그래밍 교육에 대한 고찰”이라고 정했었는데 해당 글이 프로그래밍을 다른 사람들에게 가르치는 저의 개인적인 경험과 이를 어떻게 하면 좋을지에 대한 고민, 그리고 그 과정에서 느낀 점을 서술하기 때문입니다. 그러는 과정에서 왜 내가 글을 쓰지 못하는지에 관해 깨닫게 된 과정을 서술합니다.

---

0. 들어가며

이전에 다녔던 회사의 발주전산은 당시 회사의 요구사항을 따라오지 못했다. 기본적인 수발주 기능은 동작하나 정산에서 항상 문제가 되었다. 정책적으로 복잡한 할인율을 반영하지 못하고 중간에 발생한 취소 등에도 취약했다. 이전에는 해당 업무를 담당하지 않고 있었기에 우선 필요한 대로 최종 산출물 엑셀을 넣으면 추가적으로 정산을 수행할 수 있는 프로그램을 만들어 해당 문제를 해결하였다.

대부분 문제가 그렇지만 시간이 지남에 따라 상황은 변하고 가만히만 있으면 좋겠는 문제는 더 커지기 마련이다. 만약 문제가 커지지 않았다면 그 이유는 누군가 대신 해결해 주고 있기 때문일 것이다. 이 또한 그랬다. 더 이상 정상적으로 최종 산출물 엑셀을 뽑아낼 수 없게 되었고 추가 개발을 하지 않는 이상, 수동으로 문제를 해결할 수밖에 없었다. 문제를 해결할 방법은 두 가지가 있었다.

1. 기존에 개발한 추가 정산 프로그램을 계속 사용하면서 기존과 같은 최종 산출물 엑셀 파일을 만들 수 있게 한다.
   (문제가 발생한 고장 난 부분을 모방하는 프로그램을 만든다.)
2. 사실 최종 산출물 엑셀 파일은 원래부터 중간 자료일 뿐이니 한 번에 진짜 최종 정산내역을 만드는 프로그램을 개발한다.
   (정산 최종결과물이 나오는 프로그램을 다시 만든다.)

물론 이러니저러니 해도 결국은 2번을 선택할 수밖에 없다. 그러나 가장 중요한 것은 “어찌 됐든 일은 돌아가게 해야 한다.”이다. 좋은 설계, 좋은 코드 그런 것보다 최우선으로 돼야하는 것은 언제나 “일이 되는 것”이다. 그러니 급한 대로 1번과 같이 작업했었고, 모두가 생각하는 것과 같이 결국 2번 작업을 수행하였다.

사실 마음 같아서는 최종유저의 UI부터 관리자의 제품관리, 할인율 정책관리까지 발주전산 자체를 다시 만들고 싶었다. 그러기 위해 이리저리 뜯어보고 관련자와 많은 대화를 하는 등의 노력을 하였으나 현실적으로 상황이 그럴 수가 없었기에 이는 포기하고 현재 필요로 하는 정산을 수행하는 별도의 프로그램을 개발하였다. 과정과 결과가 어찌하였던 그 당시에는 요구사항을 충족하였다. 그러나 막상 필요가 충족되고 나면 그때는 생각하지 못했던 문제 사항이 나타나고 추가적인 필요는 늘어나기 마련이다.

정산이나 분석, 보고서 등과 관련된 것을 만들었던 사람이라면 알 것이다. 이것이 결국은 노가다의 산물이라는 것을. 최종사용자가 원본 데이터를 전처리부터 가공, 시각화까지 자유롭게 할 수 있는 툴을 사용하는 것이 아니라면 결국 개발자가 쌓이는 데이터를 분석하고 처리, 가공 후 이쁘게 양식화해서 출력하고 시각화하는 코드를 일일이 작성해야 한다는 것을 말이다.

사용자의 요구사항은 정말 변화무쌍하다 처음에 이렇게 보고 싶다가도 결국 보고 나면 “아, 이게 아니라 이렇게” 하면서 다른 걸 보고 싶게 된다. 결국 데이터를 분석하고 가능성을 검토하는 것도 노가다고 가공하는 것도 노가다고 양식화하는 것도 노가다고 시각화하는 것도 노가다이다. 다 노가다이다. 앞에서 말한 코드가 아닌 툴을 사용하는 것도 결국은 해당 툴의 사용 방법을 익혀서 하는 노가다일 뿐이다. 툴이라도 있으면 다행이지 툴이 없는 경우 대환장 파티가 시작되는 것이다. 그리고 툴은 느리다!

1. 가르치자

문제는 어디서부터 오는 것일지 생각해 봤다. 최종 사용자의 요구사항이 명확한 경우 해당 보고서가 나오고 자동화되기까지 다음과 같은 과정을 거치게 된다.

1. 사용자의 요구사항을 듣고 구체화한다.
2. 원본 데이터(보통 전산에서 쌓는 데이터베이스)를 분석하고 (자동화 등이) 가능한지 분석한다.
3. 만약 불가능하다고 판단된다면 해당 데이터를 쌓는 과정부터 추가해야 한다.
4. 가능하다고 판단되면 원본 데이터를 처리하기 쉽게 우선 가공한다.
5. 요구에 따라 뭔가 합친다든가 하는 처리를 수행한다.
6. 원하는 양식에 맞게 출력한다.
7. 시각화(6번도 사실 시각화일 수 있다)한다.
8. 이제 필요에 맞게 볼 수 있도록 기간이나 조건 등의 필터 추가하고 자동화한다.

아주 간단하다! 위와 같은 작업을 사용자의 요구마다 반복 수행하기만 하면 된다. 말은 그렇게 하지만 그것만을 전문적으로 업으로 삼고 있는 사람이 아닌 이상 그러고 있을 수만은 없다. 상업 응용 소프트웨어(Enterprise Application Software) 개발자는 그것만 하는 사람이 아니기 때문이다. 기업의 규모가 커서 데이터 분석 처리만 전문적으로 하는 사람이 있을 수도 있지만 현실은 그러지 못한다. 대부분 일반 개발자가 위 업무를 수행한다.

많은 개발자가 꿈꾸는 것이 무엇인가. 기획을 하는 사람이 또는 해당 리포트나 자료가 있어야 하는 사람이 DB에 접근해 직접 Query를 짜가면서 필요한 것을 찾고 얻을 수 있기를 바란다. 그리고 보통은 본인들도 그렇게 하고 싶어한다.

많은 사람이 개발자들과의 대화 도중 “내가 직접 할 수 있으면 그냥 내가 하고 싶다.”라고 말한다. 얘기하는 본인도 답답해서 그렇겠지만 나도 그렇다! 그래서 직접 SQL을 사용해서 원하는 데이터를 찾아가는 과정을 날것으로 보여주었다. DB를 보여주고 구조를 설명하고 원하는 데이터를 찾기 위해서 어떤 과정을 거치는지 설명하였다. SQL을 배우면 이런 걸 직접 할 수 있다고 얘기하였다.

원래 엑셀을 이용해서 업무에 필요한 이런저런 자료를 곧장 잘 만드는 분이었기에 충분히 가능성이 있었고 이것을 배움으로 더 많은 것을 할 수 있는 사람이 될 것이라 생각했었다. 본인도 그것을 원하였기에 나는 SQL을 가르쳐주기로 하였다.

2. 어떻게 가르치지?

누군가에게 내가 알고 있는 것을 알려주는 것은 참으로 어려운 일이다. 실제로 내가 좋아하는 것이 내가 알고 있는 것을 다른 사람에게 알려주는 것이지만 항상 어렵다고 느낀다. 1년 7개월의 프로그래밍 학원 강사 경험을 하였고 많지는 않지만 5명가량의 성인 과외를 하면서 항상 느끼는 거지만 어떻게 가르쳐야 좋을지 사실 아직도 잘 모르겠다. 물론 나의 경험이 앞으로의 선택을 방해하고 있는 것이 아닌가 하는 의구심(뒤에서 설명한다)도 있긴 하지만 말이다. 결론만 얘기하면 어떤 분야이든 결국 무수히 많은 반복 학습을 통해서 체득되지 않으면 소용이 없다.

성인 프로그래밍 개인과외는 대부분 하고자 하는 바가 명확하고 목적이 뚜렷하다. 내가 지금까지 진행했던 과외를 나열해 보면 아래와 같다. (물론 그 외 몇 가지가 더 있지만 생략한다.)

1. 검색어 상위 노출, 블로그 마케팅을 주업으로 하고 이를 자동화하고 싶다.
2. 교통 관련 회사에 근무하고 데이터 처리, 가공, 시각화, 수요분석 및 예측을 하고 싶다.
3. 논문 등의 자료를 분석하여 특정 분야의 추세 도출 및 상관관계를 분석하고 싶다.
4. 드론 관련 오픈소스 하드웨어, 소프트웨어를 사용하여 드론을 자체 제작하고 싶다.
5. 공장 PLC에서 발생한 데이터를 모니터링하여 분석 및 알림을 보내게 하고 싶다.

보면 다들 너무나 하고 싶은 것이 분명하다. 그리고 하나하나가 실제 직업으로 가져야 할 정도의 전문성과 역량을 요구하고 있다. 누가 보면 ‘저런 걸 다 가르치는 건 불가능하다.’고 할 수 있다. 맞다. 나는 각 해당 분야에 전문가가 아니고 엄청난 역량을 가지고 있지도 않다. 진짜 내가 저렇게 할 수 있게 가르쳐 준 것이 아니다. 어디까지나 희망 사항일 뿐이다. 어떻게 내가 저런 것을 다 알고 가르칠 수 있겠는가. 물론 실제로 그렇게 되기를 원할 수 있고 그렇겠지만 당사자들도 그렇지 않다는 것을 알고 있고 생각보다 기본적인 걸 배우는것만으로 아주 벅차다.

결론만 얘기하면 대부분 중간에 그만두게 된다(아닌 경우도 있다). 이유는 간단하다. 실제로 내가 그들에게 그들이 원하는 것을 제공해도 배우는 사람이 따라오기가 너무 벅차기 때문이다. 중간 과정이 생략되기 때문이다. 처음 만나서 그들이 원하는 것을 많은 물음과 답변을 통해서 알아낸 뒤에 이를 해결하기 위해 필요한 것과 그것이 동작하는 과정들에 관해서 설명해 준다. 그리고 실제로 동작하는 코드를 하나씩 짜면서 설명해 준다. 그러면 대부분 반응은 비슷하다. “나도 이렇게 하고 싶다. 간단하네요. 이게 다예요?” 맞다. 이게 다다. 아주 간단하게 마법처럼 해결된다. 물론 현실에서 발생하는 수많은 문제들을 제거한 예제이기에 그런 거지만 결국은 내부의 진짜 어려운 원리를 제외하면 그것이 다다.

이 아주아주 간단한 것을 하기 위해서 이제 내가 할 것은 1. 과정의 흐름 설명하기 2. 각 과정의 세부 내용과 동작 원리 등 설명하기 3. 여러 예제를 통한 연습만 진행해 주면 된다. 나도 그렇게 생각했고 다들 그러기만 바랄 것이다. 그런데 내가 가장 크게 간과한 것이 있었다. 바로 “프로그래밍을 모른다.”이다.

프로그램(Program)이 무엇인가. 바로 “순차적인 진행”이다. 그렇다면 프로그래밍(Programming)이란 무엇인가. 바로 “순차적인 진행을 만드는 것”이다. 그렇다면 프로그래머(Programmer)는 무엇인가. 바로 “순차적인 진행을 만드는 사람”이다. 쉽지 않은가? 그렇다면 프로그래밍 언어(Programming Language)는 이 "순차적인 진행을 만들기 위한 언어"가 되는 것이다. 모든 프로그램은 시작과 끝이 있기 마련이고 시간에 따라서 순차적으로 진행돼야만 한다. 우리는 이러한 순서를 논리적으로 전개하기 위해서 언어를 학습하고 사용한다. "논리의 전개" 이 어찌나 명확한 것인가. 결국 이 능력이 필수적으로 수반돼야만 다음을 진행할 수 있는 것이다.

그러나 나는 이 가장 중요한 것을 간과하고 만 것이다. 각 흐름에서 과정만 보면 간단할 수 있다. 그러나 실제 그 데이터를 얻어내는 과정에서 수많은 조건과 반복을 작성하고 이를 추상화하기 위한 사용자 함수를 작성하는 과정에서 대부분 매우 힘듦을 느낀다. 혹자 “그러면 이를 배우면 되지 않겠냐” 할 수 있다. 바로 그거다! 배우면 된다. 바로 여기서 다들 매우 큰 괴리를 느끼는 것이다. 갑자기 수업이 프로그래밍 언어 수업이 되고 만다. 왜 for 문을 이렇게 작성했는지, 왜 for 문은 이렇게 생겼는지, 왜 여기서는 함수로 분리했는지, 왜 변수명 또는 함수명을 이렇게 지었는지 등을 설명하고 다시 본래 흐름으로 돌아오면 이미 딴 세상을 갔다 온 기분이 드는 것이다.

실제 하고자 하는 것을 이해하기도 어려운데 프로그래밍 언어 자체에 대한 내용 설명을 한번 하면 오늘 쓸 수 있는 집중력을 다 써버린 듯한 느낌이 들것이다. 그냥 ‘왜 이렇게 작성 했는가’만 설명하면 쉬울 수도 있는데 이 문법이 무엇을 의미하는지, 이를 위해서 필요한 전제조건이 무엇인지를 설명하기 시작하면 꽤 많은 시간이 사용된다. 그리고 설사 지금 이해했다고 생각해도 다음에 똑같은 부분이 나오면 또 모르기 때문에 다시 한번 설명해 줘야 한다. 물론 이전에 들었던 기억이 있기 때문에 좀 더 잘 이해할 수는 있으나 결국 흐름이 끊기고 괴리를 느끼는 것은 마찬가지다.

그렇기에 첫 과외 이후 이러한 사실을 깨닫고 난 이후에는 “프로그래밍 언어에 대해서 별도로 학습이 필요하고 선행돼야만 한다”고 얘기해 주었고 이를 위해 필요한 과정들에 관해서 설명해 주었지만 쉽지는 않았다. 물론 불가능하지 않다. 가능하다. 그러나 쉽지 않다. 다들 직업이 있는 사람들인데 프로그래밍도 학습하고 어려운 원래 본인들이 하고자 하는 것 또한 학습하는 것이 정말 쉽지 않은 일이다. 그러면 “과외를 우선 프로그래밍 자체를 하면 되지 않겠냐?” 하지만 사람들이 원하는 것은 그것이 아니다. 그 이유에 관해서 설명하면 한도 끝도 없기에 이는 생략한다.

그래도 혹시 이유를 원하는 사람이 있을 수 있으니 정말 간략하게 설명하겠지만 필요 없다면 해당 문단은 넘어가면 된다. 내가 그들에게 “지금 하고자 하는 것을 하기 위해서는 이러한 지식이 필요하고 이러한 과정의 흐름을 통해서 원하는 것을 얻어낼 수 있습니다. 그러나! 이런 논리적인 전개를 하기 위해서는 프로그래밍을 필히 할 수 있어야 해요. 프로그래밍을 기본적으로 하려면 얼마나 시간이 걸리냐고요? 글쎄요.. 한 1년이요? 어느 정도 하려면 2년? 제가 알려줄 수 있냐고요? 그럼요. 알려줄 수는 있는데 그래도 1년은 하셔야 해요. 그럼, 원래하려던 건 언제 하냐고요? 물론 그다음에 해야죠? 같이 할 수 있냐고요? 아.. 물론 같이할 수는 있는데…” 이렇게 말하면 어떻겠는가. (물론 처음에 다 이렇게 말한다) 내가 알려주기도 뭐하고 안 알려주기도 뭐하고 다 배우고 오라기도 참 뭐한 것이다.

내가 알려주면 된다. 그런데 본인이 하고자 하는 것이 진짜 이건가 하는 의구심이 끊임없이 그들의 머릿속을 지나갈 수밖에 없다. 그러다 그만두게 된다. 그리고 이를 생략해도 비슷하게 된다. 그렇기에 나는 이제 더 이상 과외를 하지 않는다.

어떻게 하면 프로그래밍을 학습할 수 있을까. 내가 학원에서 프로그래밍 강사로 1년 7개월간 기본적인 C언어, Java, 자료구조를 가르치면서 느낀 것과 어려움이 있다. 그들의 최종목적(위 과외와 같은)이야 어떻든 간에 우선 언어를 배우는 수업에 들어왔기에 나는 언어만 가르치면 된다. 문법을 알려주는 것? 농담이 아니라 몇 시간이면 끝낼 수도 있다. 모든 상세한 문법을 얘기할 수는 없겠지만 기본적으로 반드시 사용되는 문법이면 데이터(변수, 언어에 따른 자료형) 할당 및 사용, 조건분기(if, switch 등), 반복(for, while 등), 함수로 크게 4가지가 다이다. 그다음은? 무한반복뿐이다. 자연스럽게 사용할 수 있도록 체득할 때까지 그저 무한 반복할 뿐이다.

당연히 단순히 반복만 하는 것이 아닌 충분한 설명이 필요할 것이다. 그저 무작정 반복하는 것이 아닌 이해가 수반되면 더 빠르고 효과적인 학습이 될 것이다. 그러나 결국은 반복이다. 수많은 사람을 가르치다 보면 정말 가끔 타고난 사람들이 있기는 하다. 한 번만 설명해도 이해하고 설명하지 않는 것도 기존의 지식을 응용해서 알아내고 생각지도 못한 부분들을 질문하는 사람이 있다. 그러나 정말 열에 하나 나타날까 말까, 한다. 대부분은 그렇지 않다.

내가 할 수 있는 것은 충분히 이해되도록 쉽고 응용과 멀어지지 않는 뜬구름 잡지 않는 납득한 가능한 설명을 한 뒤에 이에 해당하는 문제를 가능한 시간만큼 많이 풀어주면서 새롭게 나타나는 개념과 어려움에 관해서 설명해 주는 것이 다다. 그렇게 무한반복. 그리고 그들도 체득될 때까지 무한반복하고 이해가 되지 않는다면 질문하고 깨우쳐 가는 수밖에 없다. 천재가 아니라면 그렇게 해야 한다.

충분히 이해되는 설명이 제공됐다는 전제하에 정도의 차이가 있을 수 있지만 결국 절대적인 시간을 얼마나 쏟아붓느냐가 관건이 된다. 내가 해줄 수 있는 것은 한계가 있다. 그렇기에 배우는 사람이 그만큼 시간을 써주지 않는 이상 진행이 불가능하게 된다. 물론 대부분은 공부해 오지 않는다. 거의 모든 문제는 거기서부터 시작된다.

“우리가 하고자 하는 것은 이거니까 여기까지는 혼자 공부해 오세요.”라고 해도 이런저런 이유에 의해서 공부해 오지 않는다. 결국 배우는 사람이 어느 순간에 재미를 붙이고 스스로 학습할 때까지는 가르치는 사람이 그 지점까지 유도를 해줄 수밖에 없다. 쉽지 않은 일이다. 그러나 개인적으로 그것이 재미있고 그 과정에서 나 또한 배우는 것이 많기 때문에 배우는 사람이 의지만 있다면 당연히 그래 줄 수 있다.

처음에는 쉬운 SQL 책(Head First SQL)을 추천해 주었고 공부해 오기를 바랐다. 앞에서 설명한 것과 같이 나의 과외 경험들 때문에 그랬다. 우선 기본은 스스로 하고 본론부터 같이 하기를 바랐다. 초반에는 공부를 어느 정도 하였으나 그렇게 유지되는 것이 쉬운 일이 아니라는 것을 모두가 알 것이다. 진짜 쉬운 일이 아니다. 어려운 일이다! 한두 달이 지났을까 그렇게 본론은 언제쯤 나갈 수 있는지를 생각하다가 그냥 오래 걸려도 하나씩 내가 알려주는 게 빠르겠다는 생각이 들었다. 그래서 퇴근 후 일주일에 한두 번 짧게 30분이라도 조금씩 알려주기로 마음을 먹었다.

공부를 안 해와도 괜찮다. 복습을 안 해와도 괜찮다. 꾸준히 하다 보면 의지가 있기에 나아지겠지, 생각하였다. 그러다 어느 순간에 깨닫고 필요에 의해서 스스로 찾아보면서 공부하고 질문도 하는 날이 올 것이다. 물론 당연히 일반적이지 않은 교육 방법이다. 그러나 내 필요에 의해서 그렇게 하는 것이고 나 또한 그것을 좋아하고 받는 사람도 의지가 있으니 진행하는 것일 뿐이다.

3. 문제가 이상한데?

해당 장은 SQL을 모르면 이해하기 힘들 수도 있습니다. 그러나 이해가 되지 않는 부분은 무시하고 넘어가도 괜찮습니다.

결국은 무한반복 연습문제를 풀어서 체득하고 실제 사례를 만나면서 하나씩 산을 넘는 것 말고는 답이 없다. 그렇기에 우선 나는 그렇게 문제를 풀 수 있는 무언가를 찾았다. 많은 자료를 찾아본 것은아니었지만 다행히 프로그래머스에서 SQL 문제를 제공하고 있었다. 이것을 하나씩 풀면서 필요한 것을 설명하고 조금씩 익혀가기로 하였다.

안 그런 것들도 있었지만 참 이상한 문제들이 많았다. 문제는 해당 문법을 쓰게 금 유도해 놓고 사실 그 부분은 결국 필요가 없다든가 조건이 명시는 돼 있는데 실제 데이터에는 그 조건에 해당하는 행이 없다든가 하는 것들 말이다. 그러니까 문제는 해당 문법을 요구하고서는 문제 푸는 사람이 실수든 몰라서든 해당 문법을 사용하지 않았을 때 정답처리 되는 문제들이 많다는 말이다. 그럴 때마다 나는 잘못된 점을 설명하면서 원래라면 어떠해야 한다고 설명해 주었다. 왜냐면 나는 필요하다고 설명했는데 막상 정답은 안 써도 정답처리가 되기 때문이다. 그럼 참 할 말이 없다.

문제를 설계하기는 정말로 어렵다. 고려해야 하는 것이 한두 가지 아니기 때문이다. 문제를 푸는 사람이 알고 있는 정도, 해당 문제를 통해서 무엇을 알고 있는지 확인하고자 하는 것, 그러기 위한 데이터의 적절성과 전제조건 기술, 그리고 난이도 등이 있다. 수업 커리큘럼을 짜고 적절한 정도와 순서에 맞는 문제를 제공하는 것은 쉬운 일이 아니다. 큰 노력을 해야 함을 알고 있기에 제공되는 문제가 맘에는 들지 않고 순서도 적절하지 않다고 생각했지만 지금 그것이 크게 중요한 것이 아니기에 넘어갔다. 내가 설명해 주면 그만이고 그렇다고 내가 잘 설계해서 다시 만들어 주기도 어렵기 때문이다.

그러다 폭발하고 말았다. SELECT로 묶여있는 문제들을 다 풀고 SUM, MAX, MIN으로 묶인 문제들을 풀기 시작했다. 첫 번째 문제부터 말썽이었다.

가격이 제일 비싼 식품의 정보 출력하기, https://school.programmers.co.kr/learn/courses/30/lessons/131115

우선 해당 문제 그룹의 이름이 무엇인가? SUM, MAX, MIN이다. 그렇다면 이 문제에서 요구하는 것은 당연히 Aggregation Function의 사용 유무일 것이다. 그러나 위 문제는 그럴 수도 있고 그렇지 않을 수도 있다.

우선 문제는 온전한 row를 요구하고 있다. 그러나 aggregation function을 사용할 경우 그룹에서 해당 컬럼이 하나의 값으로 처리되게 된다. 즉 해당 필드는 요구한 하나의 값이 되고 나머지 필드는 그냥 그룹의 맨 윗줄이 출력되게 된다.

위와 같이 해당 테이블을 가격순으로 내림차순 정렬할 경우 19,000원이 가장 비싼 식품으로 나오게 된다. 그러나 이 문제에서 단순히 MAX 함수만을 사용하면 어떻게 될까?

앞에서 설명한 것과 같이 aggregation function을 사용한 필드는 원하는 값이 나오고 나머지 값은 그 그룹(여기서는 그룹핑을 하지 않았기 때문에 테이블 자체가 하나의 그룹으로 처리 됨) 맨 윗줄 나오게 된다. 그러면 ‘ORDER BY를 쓰면 되지 않냐?’고 물을 수 있다.

SELECT PRODUCT_ID, PRODUCT_NAME, PRODUCT_CD, CATEGORY, MAX(PRICE)
FROM FOOD_PRODUCT
ORDER BY PRICE DESC

안된다. GROYP BY가 ORDER BY보다 처리가 앞서기 때문이다. 그리고 그렇게 될 거였으면 사실 집계함수는 필요도 없었다.

어떤가. 사실 MAX는 필요가 없다. 그런데 여기에도 함정이 있다. 최고가 식품이 2개라면?? 그러면 LIMIT 2를 써주면 되는 것일까? 그럴 리가 없지 않은가. 문제의 조건에 “최고가 식품은 n개”라는 조건을 명시한 것이 아니라면 그렇게 풀어서는 안 된다. 그러면 어떻게 해야만 하는 것일까?

띠용… 갑분싸 Sub-Query?? 물론 SQL을 사용하면서 sub-query를 알고 있어야 하는 것이 맞다. 그런데 이 문제는 Aggregation Function의 사용을 보고자 하는 게 아니었나? 뭔가 잘못됐다고 느꼈다. 그러나 문제에 제시된 조건만으로 해당 문제를 풀기 위해서는 위와 같은 방법이 최선일 것이다. 정말 문제를 낸 사람의 의도가 이와 같다면 할 말은 없지만 말이다. 그렇기에 넘어갔다. “어떻게만 풀어라.”라는 제한이 현실에는 존재하지 않기 때문이다.

그리고 두번째 문제를 보았다.

가장 비싼 상품 구하기, https://school.programmers.co.kr/learn/courses/30/lessons/131697

이번 문제는 SELECT MAX(PRICE) AS 'MAX_PRICE' FROM PRODUCT로 정말 Aggregation Function의 사용만을 보는 문제였다. ‘다행이군’하고 넘었다. 그러나 테이블 구조를 설명하면서 이상한 점이 있었다.

해당 테이블은 PRODUCT_ID와 PRODUCT_CODE 두 개의 unique field를 갖고 있다. 사실 PRODUCT_ID는 없애고 PRODUCT_CODE만을 primary key로 삼아도 문제는 없을 것이다. 물론 내부적으로 사용하기 위한 key라면 필요할 수 있다. 무엇을 의도하였는지 모르기에 이 부분은 설명만 하고 넘어갔다. 그런데 PRODUCT_CODE가 VARCHAR(8)임을 보고 ‘어?’ 싶었다.

“아니.. 어차피 고정길이 8자면 CHAR(8)을 쓰지 VARCHAR(8)를 써? 이 사람 튜닝을 해본 거야 안 해본 거야? 뭔가 내부 최적화를 바라는 건가? 아니면 요즘은 그런 거 신경 안 써도 크게 차이 안 나니까 그냥 무시한 건가? 아니면 그냥 모르는 건가? 다른 것들도 그렇지만 좀만 더 신경 써주면 좋겠는데.”

4. 이래서 내가 글을 못 썼구나…

그렇게 혼자 구시렁대면서 설명해 주다 순간 정적의 시간이 생겼다. 깨닫고 말았다. 아, 내가 이래서 글을 못 쓰는구나... 하고 말이다.

사실, 문제 푸는 데 아무런 지장이 없는 것들일 뿐이다. 문제가 요구하는 것이 그것이 아니고 그걸 알 사람이면 이런 문제 안 풀고 있다. 너무 많은 것을 고려하고 생각하기에 문제가 되는 것이다. 문제라고 하니 문제일 수 있는 것이다. 물론 모든 것들을 다 고려하면 참 좋겠지만 현실이라는 것이 그렇지 못한 것 천지다. 어느 정도 융통성 있게 넘어갈 수 있어야 하는데 그렇지 못할 때가 많다.

실제 일을 함에서도 최대한 잘하려고 하는 편이긴 하지만 세상 어떻게 다 충족하면서 일을 할 수 있겠는가. 그러면 일을 못 한다. 그렇기에 넘어갈 수는 있는 것은 넘어가고, 넘어가야만 하는 것들이 더 많은게 현실이기에 그러려니 하는 것이 많다. 그러나 가르치는 것에서는 그럴 수 없다는 뭔가 강박관념이 있다. 제대로 해야 한다는 생각에 갇혀서 너무 과하게 준비하고 정작 해야 하는 것을 놓치고 있다 느낌이 있다. 글 쓰는 것도 그렇다.

Auth에 대한 고민들이란 글을 쓸 때도 무지막지하게 긴 글이 나오게 된 이유가 그렇다. 단편적인 설명만 하고는 거기에서 파생되는 수많은 물음을 해소할 수 없음을 알기에 우선은 총론을 작성하고 거기서 하나씩 별도의 글로 써가자고 생각했었다. 그리고 하나의 글에서 모든 사항을 다 얘기할 수도 없고, 한다 해도 빠지는 것이 있기에 전제 사항을 덕지덕지 붙이게 되었다. 그러면 글을 못 쓰게 된다.

아! 그렇구나! 하며 깨닫게 되었다. 적당이라는 것을 알아야만 하는데 참 쉽지 않다.

5. 마치며

뭔가 주저리주저리 지극히 개인적인 ‘아, 내가 이래서 글을 못 쓰는 구나’라는 생각 하나가 나오기까지의 과정을 적어보았다. 사실 이런 글이 누군가에게 큰 도움이 될 것 같지는 않지만 나한테는 도움이 되기에 작성해 보았다.

---

여담

사실 글에서 나오는 내용들을 아래와 같은 제목으로 작성 해볼까 하는 생각이 있었다.

• 성인 과외를 하면서 느낀 어려운 점들
• 가르치면서 느낀 프로그래밍 학습에 대한 생각들

뭐 이 정도가 있지 않을까 싶은데 뭔가 그렇게 거창하게 글을 작성 하기에는 글재주가 없다. 그렇게 쓰지 않고 있었으나 그냥 내 개인적인 감상을 말하면서 같이 얘기하면 되지 않을까 해서 글을 작성하였다. 뭔가 위 제목으로 시작해서 하나의 결론을 맺기가 힘든 것을 알기에 그냥 결론을 다른 방향으로 틀고 하고 싶었던 말을 하였다.

어느 정도 글의 구성이 나오고 ‘글 제목을 바꿔볼까…’ 싶다가도 그냥 원래의 제목을 유지하였다.