머신 러닝을 시작하는 프로그래머가 저지르는 실수

머신러닝을 시작할 때 정해진 방법은 없습니다. 각기 다른 방식으로 배우고, 목적 그리고 목표도 다릅니다.

프로그래머가 머신러닝의 세계로 뛰어드는 것은 새로운 프로그래밍 언어를 배우는 것과는 다른 경험입니다. 논리와 명확한 규칙, 100% 예측 가능한 결과에 익숙한 경험을 규칙이 아닌 데이터에서 패턴을 학습하고, 확률과 통계에 기반한 경험으로 바꿔야 합니다.

이런 근본적인 차이 때문에, 뛰어난 프로그래머도 머신러닝을 시작할 때 함정에 빠지곤 합니다. 이 글은 프로그래머가 겪을 수 있는 실수와 머신러닝 실무자로 거듭나기 위한 사고방식의 전환에 대해 이야기합니다.

실수 1: 바퀴를 재발명하려고 한다. (알고리즘 구현에 집착)

가장 흔한 실수입니다. 프로그래머는 종종 "이 기술이 어떻게 작동하는지" 알아야 직성이 풀립니다. 그래서 선형 회귀, 서포트 벡터 머신 같은 알고리즘을 밑바닥부터 직접 구현하려고 시도할 수 있습니다.

이는 마치 웹 애플리케이션을 만들기 위해 HTTP 프로토콜과 TCP/IP 소켓을 직접 구현하는 것과 같습니다. 물론 훌륭한 경험이 되겠지만, 당장 무언가를 해결하기 위해서는 비효율적입니다.

"알고리즘과 작동 원리"와 "이 알고리즘을 문제에 적용하는 법" 두 가지를 동시에 해결해야 합니다. 이미 어느정도 최적화된 라이브러리가 있는데, 굳이 처음부터 코드를 짜는 것은 낭비일 수 있습니다.

일단 라이브러리 사용자가 되었으면 합니다. 잘 만들어진 라이브러리를 가져와 문제에 적용하는 것부터 해보는것을 추천합니다. 알고리즘의 세부 구현은 나중에 그 기술을 깊게 파고들거나, 운영 환경에 맞는 커스터마이징이 필요할 때 파고들어도 늦지 않습니다.

실수 2: 100% 정확도를 추구한다.

프로그래밍 세계에서는 버그는 "0" 또는 "1"입니다. 코드는 작동하거나, 작동하지 않거나 둘 중 하나입니다. 하지만 머신러닝의 세계는 다릅니다.

소프트웨어 버그는 "실패"이지만, 머신러닝 모델의 95% 정확도는 "엄청난 성공"일 수 있습니다.

머신러닝은 본질적으로 통계적 추론입니다. 현실 세계의 데이터는 노이즈가 많고 불완전합니다. 100% 정확한 모델은 사실상 불가능하며, 만약 100%가 나왔다면 "Overfitting"울 의심해야 합니다.

"이 정도면 괜찮은데?"를 받아들이는 것이 중요합니다. 90% 정확도의 모델이라도 비즈니스 문제를 해결하고 가치를 창출할 수 있다면 성공입니다.

"완벽한 정답"이 아닌 "최선의 추정치"를 찾는 것을 목표로 해야 합니다. 모델의 성능을 높이는 것도 중요하지만, 그 모델이 실제 문제를 해결하는데 얼마나 유용한지를 기준으로 판단해야 합니다.

실수 3: 코드만 보고 프로세스를 놓친다.

프로그래머는 종종 "어떤 알고리즘을 사용할까?"라는 "모델링(코딩)" 단계에 집중합니다. 머신러닝에서는 모델링 코드가 차지하는 비중은 20%도 되지 않을 수 있습니다.

머신러닝의 성공은 알고리즘이 아니라 데이터와 프로세스에 있습니다. 따라서 전체 워크플로우에 익숙해져야 합니다.

1. 문제 정의: 무엇을 하려고 하는가?
2. 데이터 수집 및 정제
3. 모델이 잘 학습할 수 있도록 데이터를 가공
4. 모델 선택 및 훈련: 다양한 모델을 빠르게 테스트
5. 평가 및 튜닝: 모델의 성능을 검증하고 개선
6. 배포 및 모니터링: 실제 서비스 적용

GUI기반 도구로 이 전체 흐름을 먼저 경험해보는 것도 좋은 방법입니다. 코딩 없이 데이터가 어떻게 흘러가는지 한눈에 볼 수 있습니다.

• Weka: https://waikato.github.io/weka-wiki/
• Orange: https://orangedatamining.com/

나중에 Weka에 대해서 다뤄보도록 할께요.

실수 4: 수학에 압도당하거나 무시하거나

"머신러닝을 하려면 수학 학위가 필요한가요?" 많은 이들이 겁부터 먹습니다. 혹은 반대로 "라이브러리가 다 해주는데 수학이 필요한가요?" 라며 수학을 무시합니다. 둘 다 문제입니다.

자동차 운전을 위해 엔진의 연소 원리를 알 필욘 없지만, 차가 꿀렁거리거나 이상한 소리가 나면 최소한의 지식(엔진오일, 냉각수)이 있어야 문제를 진단할 수 있습니다.

모델이 왜 이런 예측을 했는지, 왜 성능이 안나오는지 이유를 모른 채 그저 파라미터만 바꿔가며 "감"에 의존하는 수학 무시형은 디버깅이 불가능해집니다.

이론에만 매몰되어 실제 코드를 한 줄도 짜보지 못하는 수학에 압도형은 지쳐서 포기하게 됩니다.

그래서 필요할 때 학습하는 전략을 취하시면 됩니다.

1. 일단 라이브러리로 모델을 돌려봅니다.
2. 모델 성능이 기대에 미치지 못하면, 해당 알고리즘의 작동 원리와 관련된 수학을 찾아보며 이해도를 높입니다.
3. 수학은 머신러닝을 시작하기 위한 필수 조건이 아니라, 더 잘하기 위한 핵심 도구입니다.

실수 5: 자동화

마지막으로, 프로그래머분들이 가진 강력한 무기를 잊지 않았으면 합니다. 바로 자동화와 시스템 구축 능력입니다. 많은 데이터 사이언티스트가 Colab or Jupyter에서 훌륭한 모델을 만들지만, 이를 실제 운영 환경에 배포하고 유지보수하는데 어려움을 겪습니다.

프로그래머는 이미 익숙한 CI/CD, 테스트 자동화, 빌드 및 배포에 대한 파이프라인 개념은 머신러닝 세계에서는 MLOps라고 불립니다. 이 영역은 프로그래머가 가장 빛을 발휘할 수 있는 기회입니다. 모델을 "만드는 것"을 넘어, 모델을 "안정적으로 서비스하는 것"에서 가치를 증명하시면 됩니다.

머신러닝은 코딩 스킬에 "실험"과 "통계"라는 새로운 스킬을 더하는 과정입니다. 알고리즘 구현이라는 숲에 갇히지 말고, 라이브러리를 활용해 문제를 해결하는 더 큰 그림을 보세요.

프로그래머들의 강력한 엔지니어링 능력은 머신러닝 프로젝트를 "연구"에서 "제품"으로 만드는 핵심 열쇠가 될 것입니다.

Read More

프로그래머가 비즈니스 문제를 해결해야 할까?

대부분의 조직은 R&R로 나눠져있다. 그리고 업계에 만연하는 것중 프로그래머는 비즈니스 문제 해결에 관여해서는 안된다는 얘기가 있다. 비즈니스 니즈에 집중하는 것이 프로그래밍의 순수한 기술적 본질을 훼손한다는 이야기이다.

나는 이런 관점에 반대한다.

일반적으로 개발자는 크게 3개의 레벨(주니어, 미들, 시니어)로 구분한다. 각 레벨에 대한 정의를 해보자.

• 주니어: 논란의 여지가 없는 레벨이다. 이론을 배웠고, 이제 업무를 시작하려는 레벨이다.
• 미들: 기술 스택에 대해 이해하는 숙련된 레벨이다.
• 시니어: 다양한 경험을 갖추고 있고, 기술 스택에 대한 경험도 많으며, 업계 전반의 폭넓은 이해를 갖추고 있어야 한다.

원하던 원치 않든, 프로그래머는 비즈니스 문제를 해결한다. 사업은 수익을 창출해야 하고, 여기에는 급여 지급도 포함된다. 수익을 창출하려면 문제(비즈니스 과제)를 해결해야 한다. 간접적이던 직접적이던 비즈니스에 "가치"를 부여하여 문제를 해결해야 한다.

몇 가지 예를 들어보자. 새로운 웹사이트를 만들어야 한다고 가정해보자. 업무 흐름은 아래와 같을 것이다.

현업 요구사항 -> 프로젝트 관리자 -> IT 실무자로 이어지는 업무 흐름에서 두 가지 접근 방식이 존재한다.

• 사례 #1: 요구사항 대로 그냥 코딩 - 모든 사람이 책임 범위내에서 일한다. 프로젝트 관리자는 현업과 논의하고 티겟을 만들고, 시니어는 아키텍처를 설계하고, 주니어는 미들과 개발을 한다.
• 사례 #2: 업무 시작 전에 프로젝트 관리자, 시니어, 현업등이 비즈니스 문제를 심도 있게 논의하는 회의를 여러 차례 진행한다. 단순히 문제 해결 방법 뿐만 아니라, 비즈니스, 개발자, 디자이너 등 모든 사람이 참여해서 효과적으로 문제를 해결하는 방법을 논의한다. 모두에게 효과적인 방안을 찾은 후에야 개발이 시작된다.

사례#1 에서는 모두가 "그냥 코딩"만 한다. 비즈니스 문제는 비효율적으로 해결된다. 마감일이 정해져 있으면, 허술한 해결책을 찾고, 책임을 전가하고, 장황하게 수정 작업을 하고, "새로운 요구사항"을 추가하는 상황이 발생한다. 이는 사람들이 요구대로만 했기 때문이다. 모두가 자신의 범위내에서 "톱니바퀴"처럼 일했고, 비즈니스 문제 해결에는 참여하지 않았다.

사례#2에서는 항상 발생하는 대부분의 잠재적 문제가 상호작용을 통해 해결된다. 필요한 것을 오해할 수 있기 때문에 개발자가 프로젝트 구현 방식을 근본적으로 변경할 수도 있다는 점은 당연한 것이다. 물론 역량에 따라 크게 달라지겠지만, 문제는 훨씬 줄어들 것이다. 이 시나리오에서 비즈니스 문제는 효과적으로 해결된다.

사례#1과 사례#2의 주요 차이점은 무엇일까?

구현 방식이 아니라 팀워크이다. 여기서 팀이란 단순히 프로젝트내에서 무언가를 구현하는 코더 몇 명이 아니라 참여하는 구성원 전체를 의미한다. 사례#2에서는 모두가 좋은 결과를 얻기 위해 함께 노력한다는 점이 존재한다. 물론 세상은 완벽하지 않지만., 가정적으로 그렇다.

이유는 모르겠지만, 사람들은 종종 문제 해결을 영업과 연관 짓는다. 프로그래머는 "어떻게" 판매될지 생각하는 것이 아니라, "무엇"이 판매될지를 생각해야 한다. 최종 제품의 품질은 아키텍처, 속도, 로직, 디자인 등에 따라 달라진다. 여러가지 것들이 제품의 품질에 담긴다.

본 글의 서두에서 프로그래머는 원하든 원치 않든 비즈니스 문제를 해결한다고 언급했다. 다시 한번 생각해본다. 프로그래머가 비즈니스 문제를 해결해야 할까?

그래야 한다고 생각한다. 역량, 직책 그리고 경험 측면에서 해결해야 한다.

프로그래머가 영업을 해야 할까? 물론 아니다. 그러나 영업이 안고 있는 비즈니스 문제를 해결해주어야 한다.

Read More