- 세상의 모든 계산기 자유(질문) 게시판 일반 ()
알파고의 미래를 예상해 봅시다 (바둑 한정)
-
- 2016.03.25 - 08:37 2016.03.16 - 11:13 1556 1
1. 알파고의 과거
우리가 아는 알파고의 과거는 '판후이 대국즈음(2015. 10월)'입니다. 판후이의 현재기력은 '한국기원 프로 연습생 수준'으로 알려져 있고, 공식대국에서는 알파고가 5-0 으로 이겼습니다. 비공식대국(속기)에서는 3-2로 이겼습니다.
알파고의 기력 향상을 위해 당시 구글은 입수할 수 있는 모든 기보를 입수해 알파고에 학습시켰을 것입니다. 동아사이언스 기사(http://news.donga.com/3/08/20160226/76688297/1)에 따르면 여기저기서 취득한 16만개의 기보 중 프로기사의 기보는 1만 5천개라고 하였습니다. 저작권 문제로 오래전 기보를 위주로 습득했다고 하는데, 그것이 사실인지는 더 확인해봐야겠습니다.
(일부 기사에서는 프로바둑 기보 3천만건을 입력시켰다고 하는데 "16만 기보 × 평균 200수 = 3200만수" 를 바알못 기자가 잘 못 이해하고 작성했으리라 생각됩니다. )
2. 알파고의 현재
이세돌 사범과의 5차례 대국을 통해서 알파고의 실력(기력)은 새롭게 평가되었습니다. 강점/약점이 동시에 있는 것이 확실하지만, 어쨌건 결론은 인간이 도달할 수 있는 최정상급 수준과 같거나 그 이상일 것이라는 점입니다.
"불과 5개월 전만 해도 2점 아래의 실력이었는데... 어떻게 이런 일이...!"
바둑을 조금이라도 알고 있는 사람이라면 그 누구라도 놀라지 않을 수 없는 결과입니다.
실력이 상승할 수 있는 큰 그릇을 만든 것은 "프로그램머의 노력"이라고 할 수 있지만, 그 그릇을 채운 것은 "알파고(AI 프로그램)의 노력"임이 분명하므로, 우리는 그 사이에 어떤 노력이 있었을지를 분석해야 합니다.
우선 알파고가 추가로 습득한 '인간의 기보'는 과거에 습득한 것에서 크게 늘지 않았을 것이 확실합니다. 저작권 문제가 있다면 더욱 그러했을 것이고, 저작권 문제가 아니더라도, 추가할 수 있는 기보가 있다면 과거에 추가하지 않았을 까닭이 없습니다.
그렇다면 알파고가 그 사이에 기력을 저 정도로 올릴 수 있는 유일한 방법은 "인간vs인간" 또는 "인간vs알파고"의 대국이 아니라 "알파고vs알파고"의 셀프대국일 것이라는 추정이 가능해집니다.
이는 '허사비스'가 밝히기도 한 내용인데, 셀프대국을 통해 좋은 데이터를 만들고, 그것으로 기력이 오르고, 오른 기력으로 더 좋은 데이터를 만들고, 또 기력이 오르고... 이러한 과정이 현재의 알파고를 만드는데 가장 중요한 역할을 했다고 볼 수 있습니다.
5개월간 얼마나 많은 self-play 를 하였는지 아직 밝혀진 바가 없습니다만, 알파고 싱글머쉰과 Dist 버전을 적절히 상대를 조합하여 대국하고, 또 속기바둑을 두는 식으로 대량의 기보를 만들어냈을 가능성이 높아 보입니다.
(인터넷에 떠도는 소문에 의하면 매일3만판=매월100만판을 학습한다고 합니다. 공식 확인되지 않은 정보입니다.)
이러한 셀프기보 중에서 좋은 수준이라고 평가한 기보는, 기존 16만건이라는 인간의 기보중에서 하급이라고 평가되는 것들을 대체하였을 가능성이 높습니다. 그 결과 "Human expert positions" 였던 정책망은 "Human expert positions+Alphago's positions" 로 변화되면서 네트워크 기반이 탄탄해졌을 것입니다.
3. 알파고의 미래
누군가는 알파고의 약점을 보았으니 '이제 잡을 수도 있다'라고 생각하겠지만, '잡을 수도 있는 대상'은 오늘의 알파고이지 미래의 알파고가 아닙니다. 인간이 오늘의 알파고에 있는 약점에 집착하는 동안, 알파고는 계속 강해질 것입니다. 분명 미래의 알파고는 오늘의 알파고보다 강합니다. 알파고의 집은 커지고, 맛은 줄어듭니다. 5개월만에 강해진 오늘의 알파고에게 느낀 충격을, 5개월 후의 알파고에게 또 느끼게 될 가능성이 높습니다.
오늘의 알파고를 만든것은 8할이 알파고 자신입니다. 미래의 알파고를 만드는 것은 10할이 알파고 자신이 될 것입니다. 다만 인간이 그러하듯 기력이 오르면 오를수록 기력을 빠른 시간에 올리는 일은 AI에게도 어려운 일이 될 것입니다. 그것이 저의 오판일수도 있습니다만...
허사비스 "
"
알파고가 오를 수 있는 어떤 한계에 다다랏다고 판단되는 때는, 정책망/가치망 이외의 새로운 망을 추가한 베타고가 탄생할 수 있는 순간이기도 할 겁니다. 현재보다도 더 신의 바둑에 가까운 미래의 알파고라는 좋은 사범이 있다면, 새로운 망으로 태어난 베타고를 만드는 것은 그렇게 어렵지 않은 일일지도 모르겠습니다.
문제는 구글이나 딥마인드에게 바둑AI시장은 최후의 목표가 아니기 점입니다. 돈이 된다고 판단하지 않는 이상 추가적인 투자 내지는 연구를 지속할 것인지 불분명합니다.
-
25
세상의모든계산기 님의 최근 댓글
ChatGPT-5 기호(÷, /, :) 자체는 의미적으로 같은 “나눗셈”을 뜻하지만, 문맥(사람이 쓰는 수학 vs 컴퓨터/프로그래밍)에 따라 해석 우선순위가 달라질 수 있습니다. 🔹 1️⃣ 전통 수학 표기 — ÷, /, : 수학 교과서, 논문, 일반 문서 등에서는 셋 다 의미적으로 “나누기”로 간주됩니다. 즉, 48÷2(9+3), 48/2(9+3), 48:2(9+3) 은 같은 의미로 받아들여야 합니다. 모두 사람의 수학 관행적 해석이 적용되어 48 ÷ 2 × (9+3) = 288 로 처리되죠. 즉, 기호가 바뀌어도 결과는 바뀌지 않습니다. 🔹 2️⃣ 컴퓨터·프로그래밍 문맥에서 / 사용 시 컴퓨터는 “생략된 곱셈(implicit multiplication)”을 따로 구분하지 못합니다. 따라서 다음 두 식은 완전히 다르게 인식됩니다. 표현 파이썬 등에서 해석 결과 48 / 2*(9+3) ((48 / 2) * (9+3)) 288 48 / 2(9+3) ❌ 문법 오류 (생략된 곱셈 인식 불가) — 즉, 컴퓨터 언어에서는 생략된 곱셈이 허용되지 않기 때문에, /는 반드시 명시적 *와 함께 써야 합니다. 🔹 3️⃣ “:” 기호의 경우 현대 수학에서는 “비율”을 나타내는 기호로 쓰입니다. a:b = \frac{a}{b} 따라서 (27 : 3(1+2)3) 같은 표현은 모호하거나 비표준적으로 간주됩니다. 대부분의 경우 계산기로는 입력 자체가 불가능합니다. ✅ 정리 기호 의미 결과 변화 주로 쓰이는 문맥 ÷ 나누기 없음 초중등 수학, 일반 표기 / 나누기 없음 (단, 프로그래밍에서는 생략 곱 불허) 수학/컴퓨터 : 비율 (또는 나누기 의미로 혼용) 보통 계산식에서는 사용 안 함 비, 비율 표기 🔹 결론 48 ÷ 2(9+3), 48/2(9+3), 48:2(9+3) 는 “수학적 의미”로는 동일하게 81로 해석됩니다. 하지만 프로그래밍이나 수식 파서(context) 에서는 /만 유효하고, 생략된 곱은 허용되지 않으며, :는 아예 다른 의미(비율)로 인식됩니다. 2025 10.28 ChatGPT-5 💯 네, 정확히 그 지점을 짚으셨어요. 요약하면 이렇게 말할 수 있습니다: “생략된 곱하기(implicit multiplication)”는 문자에서는 강한 결합력을 인정하지만, 숫자나 괄호 사이에서는 일반 곱셈(×)과 동일한 우선순위로 취급된다. 즉, 문자에서는 더 강하게 결합, 숫자·괄호 사이에서는 그냥 ‘보통 곱셈’ 으로 본다는 것이 현대 수학 표기와 계산기의 관행적 규칙입니다. 🔹 두 경우의 구조적 차이 식 형태 실제 해석 결과 결합력 특징 ab ÷ ab 문자 붙음 ((a×b) ÷ (a×b)) 1 문자 간 결합이 강함 → 한 항으로 인식 3(1+2)3 숫자·괄호 혼합 (3 × (1+2) × 3) 27 생략된 ×는 보통 곱셈 → 좌→우 규칙 적용 🔹 왜 문자식은 결합력이 더 강한가? 기호적 표현의 안정성 (ab), (xy), (2x) 같은 표기는 수백 년 동안 “하나의 곱셈 항(term)”으로 인식되어 왔습니다. 그래서 수학자들은 이걸 암묵적으로 “괄호로 묶인 덩어리”로 봅니다. ab ÷ ab = (ab) ÷ (ab) 함수 표기와 구분 필요 예: (sinx ÷ x) 에서 sinx는 sin(x)로 묶여야 의미가 있습니다. 이런 이유로 “문자 옆에 붙은 기호나 문자”는 항상 먼저 결합되도록 하는 관행이 굳어졌습니다. 🔹 반면 숫자·괄호에서는 (3(1+2)) 는 단순히 “3 × (1+2)”의 약식 표현이고, 여기서 “생략된 곱셈”은 “명시적 곱셈”과 동일한 연산자로 간주됩니다. 따라서 27 ÷ 3(1+2)3 = 27 ÷ 3 × 3 × 3 = 81 처럼 좌→우 순서로 처리합니다. 🔹 결론 생략된 곱하기(implicit multiplication)의 결합력은 표기 맥락에 따라 다르다. 문자/기호와 함께 쓰일 때 → 강하게 결합 (하나의 항으로 인식) 숫자와 괄호 사이 → 일반 곱셈과 동일한 우선순위 (좌→우 계산) 이건 “규칙이 바뀐 것”이 아니라, 표기 문법(context) 이 달라서 ‘결합 단위(token)’이 달라진 결과라고 보는 게 가장 정확합니다. 2025 10.28 자게로 이동조치하였습니다. 그리고 이 글의 내용을 정리하여 HP 포럼에 올려두었습니다. https://allcalc.org/55774 [HP Prime] Solve 함수 사용법 2025 10.27 수치해석 방법 method 를 강제로 선택할 수 있으면 좋을텐데... 위의 스샷을 보면 되는 듯 하면서도 아래 스샷을 보면 안되는 것 같기도 합니다. solve(Expr,[Var]) csolve(LstEq,LstVar) nSolve(Expr,Var,[Guess or Interval],[Method]) deSolve(Eq,[TimeVar],FncVar) linsolve(LstLinEq,LstVar) fsolve(Expr,Var,[Guess or Interval],[Method]) 2025 10.17 종합해서 답변을 드리면 HP Prime 에 solve 에서 변수명에 구간을 입력하면 수치해석 방식으로 bisection 을 사용함. 이 bisection 방식은 해의 좌-우 부호가 서로 바뀌어야만 해를 인식하고 해의 좌-우 부호가 같으면 해를 인식하지 못합니다. 이 때문에 본문 sin 의 예나 아래 사진의 예에서는 해를 인식하지 못하는 것으로 보입니다. 2025 10.17