프로그래머에게 수학이나 알고리즘이 중요한가요?

이덕곤(자바 서버사이드 개발자)

수학의 영역은 매우 넓은데요. 모든 영역의 수학이 필요한 것은 아닙니다. 하지만 필요한 부분이 생긴다면 바로 찾아서 공부하고, 이해할 수 있어야 합니다. 사실 저도 지도팀에 오기 전에는 수학이 큰 의미가 없었습니다. 지금도 제가 수학을 활용해 알고리즘을 만드는 것은 아니지만, 동작 원리를 알기 위해 조금씩 공부하게 되네요.

김수민(보안 솔루션 개발자)

반드시 중요한 것 같지는 않은 것 같아요. 대부분의 암호 알고리즘을 직접 구현하여 지금도 제가 속한 팀에서 핵심 라이브러리로 사용하고 있기는 합니다. 그렇지만 모든 개발자가 직접 구현할 필요도 없고 사용된 수학을 이해해서 쓸 일은 더더욱 없으니 말이죠. 그렇지만 수학이 필요하다면 기꺼이 수학을 공부해서 적용할 수 있어야 하고, 중요한 알고리즘이 필요한 부분이 있다고 하면 새로운 알고리즘을 만들거나 기존 알고리즘 중에서 적합한 것을 찾아서 적용할 수 있어야 한다고 봅니다.

즉 그때 그때의 환경에 따라 다르다고 보는 것이 맞을 것 같습니다.

좀 더 일반적으로 얘기하면 알고리즘이건 수학이건 모르는 것보다 훨씬 나은 상황이 더 많지 않을까 싶습니다. 그렇지만 닭 잡는 데 소 잡는 칼을 쓸 필요는 없는 것처럼 필요한 상황에 맞는 수준으로만 사용하면 될 것 같습니다.

이재영(하드웨어 개발자)

네, 무척 중요합니다. 같은 결과지만 알고리즘이나 수학에 따라서 코드가 간결해지고 빨라질 수 있습니다. 그렇지만 모든 알고리즘을 머릿속에 넣는 행동은 바보같은 짓입니다. 필요할 때 잘 찾는 방법을 아는 것이 좋습니다.

이재현(니마시니 인공지능 개발자)

(꼭 그래야만 한다면) 동일한 목적을 달성한 두 코드의 우열을 따지는 방법은 알고리즘과 수학 이외에는 없습니다. 플랫폼이나 라이브러리가 난무하는 최근의 추세에 알고리즘이나 수학이 기술의 전제조건이라고 생각하지는 않습니다만, 그저 빌려 쓰는 것에 만족하지 못하고 스스로 무언가를 하고 싶은 사람의 등대는 늘 수학과 알고리즘 이론일 뿐입니다. 그것 없이도 행복하다면 수학과 알고리즘 능력이 필요하진 않다고 생각하기 때문에, 기술을 배우기 위한 필수 과목이라고 말하지는 않겠습니다. 하지만 코딩을 오래 즐겁게 하고 싶다면, 배워두는 것이 좋을 것이고, 결국은 그렇게 될 거라고 생각합니다. 첨언하면, 프로그래밍을 하는 데 수학의 전분야가 필요한 것도 아닙니다. 알아두면 좋은 친구입니다.

윤성열(데이터 수집 분석 서비스 개발자)

개인적으로 중요하다고 봅니다. 20줄의 코딩이 3~4줄로 작성될 수 있고 프로그램의 성능에도 많은 영향을 미칩니다. 코딩의 라인수가 적다고 많은 게 달라지진 않지만 실 업무를 오랫동안 해보니 유지보수 측면에서도 많은 도움이 됩니다.

자료구조 알고리즘은 일단 기본으로 깔고 시작하는데 업무에도 많은 도움이 됩니다. (그리고 실제 회사의 면접에서도 관련된 많은 질문을 하기 때문에 면접에도 도움이 됩니다!!)

전상현(아키텍트, 보안 전문가)

혹시 그거 아세요? 알고리즘과 수학, 프로그래밍의 공통점이 있습니다. 바로 공학적 사고가 필요하다는 것이죠. 공학적 사고는 별게 아닙니다. 발산과 수렴의 연속체입니다. 여기서 발산은 얼마나 많은 경우의 수를 생각할 수 있는가의 문제이고, 수렴은 그 많은 수 중에서 가장 적절한 것을 선택할 수 있는가의 문제입니다.

그래서 저는 알고리즘이나 수학이 프로그래밍 공부에 무척 중요하다고 생각합니다. 단, 제대로 알아야 합니다. 어지간히 알고리즘을 이해하거나 수학을 한다고 하면 그다지 도움되지 않을 것 같아요. 하나를 알더라도 그것의 원리를 깊게 알고 있으면, 그 원리에 도달하기까지의 수많은 발산과 수렴 과정도 같이 알게 됩니다. 그렇게 되면 프로그래밍할 때 자연스럽게 더 많은 발산과 더 빠른 수렴을 하게 도와주는 것이죠.

양용석(웹 퍼블리셔)

네 정말 중요합니다. 무조건 수학이 최고입니다. 근데 제 분야에서는 굳이 중요치 않긴 해요. 웹 디자인이나 HTML5, 그리고 CSS3까진 수학이 별로 필요 없는데, 자바스크립트라는 프로그래밍으로 넘어가면 수학이 중요해집니다.

송재운(웹 프로그래머)

알고리즘에 대해서 거창하게 생각하는 경우가 많은데요. 개인적으로는 잘 모르겠습니다. 정렬을 더 빠르게 하기 위한 퀵정렬이라든지 검색을 더 빠르게 하기 위한 이진탐색이라든지 이러한 것만 알고리즘은 아니거든요.

1부터 10까지의 수의 합을 구하기 위해서는 어떤방식으로 개발을 할까?

1. 1부터 10까지 반복하면서 하나의 변수에 그 수를 더한다.

2. 1과 10 사이에는 서로 같은 값을 가지는 쌍 [1,10][2,9][3,8][4,7][5,6]으로 구성되어 있으므로

   처음수+마지막수) * (더하는 갯수의 반) ⇒ 11 * 5 = 55

1번 방식이나 2번 방식이나 문제를 해결하기 위한 방법(알고리즘)이라고 생각합니다. 마치 복잡하고 어려운 알고리즘을 공부하고 복잡한 수학 공식을 익혀야 프로그램을 개발할 수 있는 것처럼 생각하는 경우가 많은데, 그렇지 않습니다.

프로그램이라는 건 그 구현 방식을 크게 나누면 데이터와 데이터의 이동입니다. 데이터를 담을 변수를 만들고 그 데이터를 필요 조건에 따라 이동시키는 일이죠. 대부분의 프로그램은 제어문(if문, for문)만 사용할 줄 알면 됩니다.

좀 더 복잡한 알고리즘을 알면 그걸로 좋고 좀 더 복잡한 수학공식을 알면 그걸로 좋습니다. 물론 복잡한 알고리즘과 수학 공식을 이해하고 사용할 수 있다면 더 좋겠지요. 하지만 사용하지 않는다고 프로그램 개발을 못하는 건 아닙니다.

김성박(서비스 개발자/교육자)

어떤 프로그래밍을 하느냐에 따라서 알고리즘, 수학 등의 중요도가 달라지는 것 같습니다. 그런데, 다다익선이라고 분명히 알고리즘과 수학을 잘 알면 도움이 될 때가 분명히 있을 거라 생각합니다.

요즘 딥러닝, AI 등이 인기가 많은데요. 해당 내용을 공부해보면 수학이 굉장히 중요하다는 것을 쉽게 알 수 있습니다. AI를 공부하고 싶어하는 개발자 중에서 왜 수학을 열심히 공부하지 않았을까? 하고 후회하는 분들도 많이 봤습니다.

그리고, 전산 관련 회사를 들어가고 싶다면 기술 면접을 보게 되는데, 보통 알고리즘 문제를 많이 냅니다. 원하는 회사에 들어가고 싶다면 알고리즘 공부는 당연히 해야 할 공부입니다.

이재근(시스템 프로그래머)

소프트웨어는 분야가 굉장히 다양합니다. 알고리즘이나 수학이 중요한 분야도 있고 그렇지 않은 분야도 있습니다. 저한테도 약한 부분이 알고리즘과 수학인데, 잘 헤쳐나가고 있답니다.(^^) 기본적인 것은 배워두되, 나머지는 필요할 때 빠르게 습득할 수 있는 능력 정도만 갖춰두면 될 것 같습니다.

신상재(소프트웨어 아키텍트)

약간의 논란이 있을 듯하여 시기를 조금 잘라서 구분하고 싶습니다. 초창기 개발을 배울 때는 절대적으로 필요합니다. 논리적인 사고에 대한 훈련과 자료구조 등에 대한 이해를 해야 하기 때문입니다. 현존하는 컴퓨터의 동작원리를 CPU프로세서의 아키텍처까진 이해를 못하더라도 최소한 메모리 상에서 데이터를 어떻게 다루어야 문제를 풀 수 있는지는 알고 있어야 합니다.

다만, 이 단계가 자연스럽게 느껴질 정도로 몸에 체화한 이후라면 그때는 좀 더 다른 보다 복잡한 문제를 해결하는 데 관심을 두어야 합니다. 예를 들어 고등학교와 대학교에서 근의 공식을 유도하거나 미적분의 원리를 이해하는 것은 중요하지만, 실제 사회에 나와서는 그것은 응용하는 도구로 활용해야 하는 것과 같습니다.

기초 과학을 하는 입장과 응용 공학을 하는 입장은 분명히 다르기 때문에, 만약 일반적인 혹은 대부분의 경우에 해당하는 애플리케이션 개발에서는 동작 방식을 이해하기 위한 개념으로는 활용되더라도 그것 자체를 구현할 기회는 극히 적을 겁니다. 그것은 우리가 바닥부터 모든 것을 만들어야 하는 것이 아니라 클래스나 펑션, 라이브러리나 모듈, 프레임워크와 같은 재사용 가능한 단위를 최대한 활용하면서 해결해야 할 문제에 집중해야 하기 때문입니다.

기초에 대한 이해의 폭이 넓을수록 더 복잡한 문제도 잘 해결하는 데 도움은 되겠지만 결국은 시간이라는 리소스는 제한되어 있기 때문에 가장 효과적인 결과를 얻기 위한 선택과 집중을 해야 합니다. 그렇다고 본다면 알고리즘과 수학은 올바른 해법을 선택할 수 있는 기본 소양과 판단력을 기르는데 분명히 도움을 주지만 그것 자체에 지나치게 집착하는 것은 논리를 전개하며 커뮤니케이션을 하는 것을 목적으로 두지 않고 상대의 무지를 잡아 비방하는 소피스트와 같을 수 있습니다.

결국 알고리즘과 수학 자체는 죄가 없습니다. 그것을 가지고 어떤 상황에서, 어떤 관점으로, 어떻게 활용하는지에 대해 판단하는 사람의 문제로 봐야 합니다. 비슷한 케이스가 디자인 패턴인데 애당초 복잡한 문제 해결을 위해 반복되고 공통된 패턴에 대해 이름을 붙이고 사용 용처를 정리하여 이해와 커뮤니케이션에 도움을 주려던 것을 이 패턴을 아니 모르니, 패턴 적용이 맞니 틀리니 하면서 논쟁을 벌이는 것은 누가 더 기억력이 좋은가를 가리는 싸움지지 문제 해결에는 전혀 도움이 되지 않습니다.

실제로 초기 자바 개발자들은 J2EE Core Design Pattern을 책을 보고 실제로 한땀한땀 손으로 구현하며 시스템을 만들었습니다. 그때는 비즈니스 로직보다 그러한 골격 자체를 만들 수 있느냐가 기술 우위를 결정했기 때문에 다들 그걸 어떻게 만들 것인가 어떤 패턴이 맞냐 틀리냐로 갑론을박하며 성장할 때가 있었습니다.

하지만 요즘엔 그렇게 밑바닥부터 만들지 않습니다. 그런 문제를 다 해결한 프레임워크를 사용하고, 심지어 다양한 컨텍스트 상황에 맞게 골라 쓰고 조합해서 씁니다. 그 내부에 어떤 패턴을 쓰는지, 어떤 알고리즘으로 구현이 되었는지는 중요하지 않습니다. 해결하려는 문제는 비즈니스 요구사항이지 그 구현 방식이 아니기 때문입니다.

그래서 일정 학습 단계를 지났다면 문제 해결 방법을 거시적으로 보는 안목이 필요합니다. 내가 해결해야 하는 문제에 어떤 알고리즘을 써보는 것이 좋은지, 그 이름을 알고 있고 그 이름으로 구현된 라이브러리를 찾아 쓸 수 있으면 됩니다. 최근 IT 환경은 그 어느 때보다도 기술 스펙트럼이 넓어졌기 때문에 내가 직접 구현할 것과 남에게 의지해서 활용할 것에 대한 빠른 판단이 필요합니다.

간혹 자신이 사용한 라이브러리의 버그 때문에 곤욕을 치른 분들이 직접 만들어서 사용하는 것에 안도감을 느끼기도 하는데 그런 경우는 개인적인 취향을 존중해줘야지 무조건적으로 뭐가 맞다 틀리다 이야기할 것은 아닙니다. 심지어 서버도 잘 돌다가 오류 나면 버리고 새로 만들거나 교체하는 것이 요즘 패러다임입니다. 어떤 알고리즘을 사용할지 빠른 판단이 가능하고 그것을 사용했을 때 문제가 있다면 재빨리 그것을 버리고 다른 대안을 찾아서 교체하면 됩니다. 굳이 Immutable(불변의)이라는 단어를 가져오진 않더라도 방망이 깎는 노읹다 용처에 맞는 방망이를 얼른 사와서 활용하는 지혜가 필요한 때입니다.

그런 의미에서 직원을 평가하거나 구인을 할 때 알고리즘 시험으로 평가를 하는 것에는 주의가 필요합니다. 알고리즘 문제를 줄 때는 이 사람이 얼마나 컴퓨팅 사고를 가지고 있는지, 주어진 문제 상황을 어떻게 풀어가는지, 현재 그가 얼마나 학습이 되어 있는지, 알고 있는 지식을 잘 활용할 수 있는지, 그리고 그것을 활용한 경험이 있는지와 같은 다양한 관점에서 판단을 해야 합니다. 단순히 무슨 문제를 풀었기 때문에 개발자로 인정한다거나 역량이 높다고 판단하는 것은 지극히 관리의 편의주의적인 생각일 수 있습니다.

이미 알려진 그런 허점을 방치하면 할수록 과거 입시위주 교육이 낳은 폐해나 영어로 대화를 못하는 토플 고득점자의 양산 사태와 같이 개발자 코스플레이어를 양산하고 신분 세탁에 악용되며, 개발자 생태계 자체를 교란시키는 행위가 될 수 있다는 점을 항상 경계해야 합니다.