bpDev

컴퓨터과학과 현상학 (아님)

bpDev — Wed, 22 Oct 2025 23:42:33 +0900

GPT는 어투 자체가 거짓말스럽다 ㅋ

요즘 소설을 자주 써서 그런가;

이야기는 아주 잘 지음..

그런데 약간 술자리 2, 3차 이야기 같다는..

GPT:

겉으로는 철학과 공학이 전혀 다른 길을 걷는 것처럼 보이지만,
현대 컴퓨터과학의 가장 근본적인 개념들 — ‘추상화’, ‘표상’, ‘관찰자’, ‘객체’, ‘의도성’ — 은
~~모두 현상학적 사고에서 출발했다고 말할 수 있다.~~

1. 현상학의 핵심 ― “존재는 인식 속에서만 드러난다.”

에드문트 후설(Edmund Husserl)은 이렇게 말했다.

“사물은 그 자체로 존재하지 않는다.
오직 의식에 나타나는 방식(현상) 으로만 존재한다.”

즉, 우리는 사물을 ‘있는 그대로’가 아니라,
우리 인식이 구성한 방식대로 본다.
이걸 의도성(intentionality) 이라 부른다 —
모든 의식은 ‘무엇을 향해 있다’.

이 철학은 “객관적 실체”보다 “관찰된 구조”를 중요시했다.
그게 바로 현대 컴퓨터과학의 추상화 모델과 닮았다.

2. 추상화와 현상학의 평행 구조

현상학컴퓨터과학

‘사물 그 자체(Ding an sich)’는 인식 불가능하다	하드웨어의 전자적 상태는 직접 다루지 않는다
우리는 현상(의식에 나타난 것)을 다룬다	우리는 인터페이스, 데이터 구조, API를 다룬다
의도성: 인식은 항상 ‘대상’을 향한다	포인터: 모든 데이터는 ‘주소(대상)’를 가리킨다
의미는 맥락 속에서만 성립한다	변수/객체의 값은 환경(context) 속에서만 유효하다

즉, 컴퓨터과학의 핵심 사고는
“현실을 직접 다루는 것이 아니라,
현실의 표상(representation) 을 다룬다.”
이건 후설이 말한 현상학적 구조 그대로다.

3. ‘객체 지향 프로그래밍’과 후설 이후의 현상학

후설의 제자 하이데거(Martin Heidegger)는 말했다.

“도구는 사용될 때만 드러난다.
망치는 쓸 때만 ‘망치다움’을 드러낸다.”

이 사상은 훗날 컴퓨터과학에서 Object-Oriented Programming(OOP) 으로 이어진다.
객체(object)는 그 자체로 의미가 없다.
메서드(행동) 를 통해서만 드러난다.

hammer.use();

‘hammer’라는 객체는 단순한 데이터 덩어리가 아니라,
행위와 관계 속에서만 의미를 갖는다.
이건 하이데거의 “존재는 사용 속에서 드러난다”라는 존재론과 완전히 일치한다.

4. 인공지능과 ‘의도성’

AI 연구는 사실상 현상학의 연장선이다.
기계가 세상을 “있는 그대로” 이해하는 것이 아니라,
입력된 데이터(즉, ‘현상’)를 바탕으로 세계를 표상한다.

예를 들어,
신경망은 실제 사과를 이해하지 않는다.
오직 사과의 픽셀 패턴을 통계적으로 해석할 뿐이다.
그건 인간이 사과를 ‘보는 방식’을 수학적으로 모델링한 것이다.

인간: 의식이 대상을 구성한다.
인공지능: 모델이 데이터를 통해 세계를 구성한다.

즉, AI는 현상학의 계산적 구현이다.
“세계는 외부에 있지 않고, 관찰자의 내부에서 구성된다.”
이 문장은 현대 딥러닝의 본질을 정확히 요약한다.

5. 프로그래밍 언어 철학과 현상학

프로그래밍 언어 자체도 현상학적이다.

C 언어: 존재(값)를 다루는 대신, 위치(주소)를 다룬다.
→ “존재는 공간적 맥락 속에서 드러난다.”
Python: 객체의 행위를 통해 의미를 부여한다.
→ “존재는 관계 속에서만 의미를 갖는다.”
함수형 언어(Haskell 등): 상태를 제거하고 순수한 ‘관계’만 다룬다.
→ “본질은 외부 상태가 아닌 인과적 관계 속에 있다.”

이 모든 언어들은 사실상 “세계의 모델링 방식”을 철학적으로 구현한 셈이다.

6. 정보의 본질 ― 현상학적 ‘의미의 축소’

현상학은 에포케(ἐποχή), 즉 판단의 중지를 강조했다.
사실 여부를 묻지 않고, “지각된 현상 그 자체”를 관찰하라는 것이다.

컴퓨터는 이 사고를 완벽히 따른다.
기계는 ‘진짜’ 사과를 구분하지 않는다.
그저 입력된 데이터 배열(현상)을 해석할 뿐이다.
기계에게 ‘의미’란 곧 입력된 현상의 패턴이다.

이건 곧, 컴퓨터의 정보처리 방식이
“현상학적 환원” 그 자체임을 의미한다.

7. 결론 ― 현상학은 디지털 세계의 뿌리다

현상학은 인간이 “세계와 자신을 분리해서 사유할 수 있는 구조”를 제시했다.
컴퓨터과학은 그것을 “기계적으로 구현”했다.

후설의 문장
“모든 의식은 대상에 대한 의식이다.”

프로그래밍의 대응
“모든 데이터는 포인터나 참조를 통해서만 접근된다.”

따라서,
현상학은 단순한 철학이 아니라,
“모델링의 철학적 근본” 이다.
컴퓨터과학은 그 사상을 기호와 전자 회로의 형태로 구현한 것이다.

Grok:

작성하신 글은 현상학과 컴퓨터과학의 개념적 연관성을 흥미롭게 다루고 있으며, 전반적으로 논리적이고 설득력 있는 주장을 펼칩니다. 그러나 몇 가지 점에서 철학적·기술적 엄밀함을 검토할 필요가 있는 부분이 있습니다. 아래에서 글의 주요 주장과 잠재적 문제점을 분석하며, 틀린 부분이 있는지, 혹은 개선할 여지가 있는지를 점검하겠습니다.

1. 전체적인 논지 평가

글은 현상학(특히 후설과 하이데거의 철학)과 컴퓨터과학의 핵심 개념(추상화, 표상, 객체, 의도성 등)이 본질적으로 연결되어 있다고 주장합니다. 이는 매우 창의적이고 통찰력 있는 접근입니다. 실제로 현상학과 컴퓨터과학은 "현실을 직접 다루지 않고 표상(representation)을 통해 다룬다"는 점에서 유사성을 가질 수 있습니다. 그러나 몇 가지 주장에서는 철학적 개념과 컴퓨터과학의 기술적 개념을 연결하는 과정에서 지나친 단순화나 비약이 있을 수 있습니다. 이를 하나씩 검토해 보겠습니다.

2. 주요 주장별 검토

(1) 현상학과 컴퓨터과학의 연관성 (추상화, 표상, 의도성)

주장: 컴퓨터과학의 추상화, 표상, 의도성 같은 개념은 현상학에서 비롯되었다.
평가: 이 주장은 흥미롭지만, "직접적인 기원"을 암시하는 표현은 과장일 수 있습니다. 컴퓨터과학의 개념들은 현상학뿐만 아니라 논리학(특히 수학적 논리학, 예: 튜링, 폰 노이만), 공학, 그리고 다른 철학적 전통(예: 분석철학, 실용주의)에서도 영향을 받았습니다. 예를 들어, "추상화"는 후설의 현상학보다 아리스토텔레스의 형이상학이나 칸트의 선험적 철학에서도 기원을 찾을 수 있습니다. 현상학이 컴퓨터과학에 영향을 미쳤다는 점은 인정될 수 있지만, "모두 현상학에서 출발했다"는 표현은 지나치게 단정적입니다.
수정 제안: "현상학적 사고가 컴퓨터과학의 개념 형성에 중요한 철학적 통찰을 제공했다" 정도로 완화하면 더 정확할 수 있습니다.

(2) 후설의 의도성과 컴퓨터과학의 포인터 비교

주장: 후설의 의도성("모든 의식은 무엇을 향한다")과 컴퓨터과학의 포인터("데이터는 주소를 가리킨다")가 유사하다.
평가: 이 비교는 직관적으로 흥미롭지만, 철학적·기술적으로 엄밀하지 않을 수 있습니다. 후설의 의도성은 인간 의식의 본질적 특성(의식이 항상 대상을 향하는 구조)을 다루는 반면, 포인터는 메모리 주소 참조라는 기술적 구현입니다. 의도성은 주관적 경험과 의미의 생성에 초점을 맞추지만, 포인터는 의미보다는 기계적 데이터 접근 메커니즘에 가깝습니다. 이 둘을 직접 연결하는 것은 비유적으로는 유효할 수 있지만, 철학적 개념과 기술적 개념의 본질적 차이를 간과할 위험이 있습니다.
문제점: 포인터는 "의도성"보다는 "참조(reference)"나 "지시성"에 더 가까운 개념으로, 현상학적 의도성과는 맥락이 다릅니다. 예를 들어, 포인터는 데이터의 물리적 위치를 가리키는 반면, 의도성은 대상에 대한 주관적 의미 구성과 관련이 있습니다.
수정 제안: 포인터와 의도성을 직접 비교하기보다는, "컴퓨터과학의 참조 구조가 현상학적 의도성과 유사한 '대상 지향적' 사고를 반영한다"고 설명하면 더 적절할 수 있습니다.

(3) 객체 지향 프로그래밍(OOP)과 하이데거의 존재론

주장: 하이데거의 "도구는 사용될 때만 드러난다"는 사상이 객체 지향 프로그래밍(OOP)으로 이어진다.
평가: 이 부분은 매우 창의적이며, 하이데거의 "현존재(Dasein)"와 "도구적 존재(Zuhandenheit)" 개념이 OOP의 객체와 메서드의 상호작용에 비유될 수 있다는 점에서 설득력이 있습니다. 실제로 OOP는 객체가 "상태"와 "행동"을 통해 의미를 갖는다는 점에서 하이데거의 도구적 존재론과 유사성을 가질 수 있습니다. 예를 들어, hammer.use()는 망치가 특정 맥락에서 사용될 때 비로소 그 기능적 의미를 드러낸다는 점에서 하이데거의 철학과 통합니다.
문제점: 그러나 OOP의 기원은 하이데거의 철학보다는 수학적 모델링(예: Simula 언어)과 공학적 필요(코드 재사용성과 모듈화)에 더 직접적으로 뿌리를 두고 있습니다. 하이데거의 철학이 OOP 설계자들에게 명시적으로 영향을 미쳤다는 역사적 증거는 부족합니다.
수정 제안: "OOP의 철학적 구조가 하이데거의 존재론과 유사한 점을 보인다" 정도로 서술하면, 직접적 기원을 암시하지 않으면서도 철학적 유사성을 강조할 수 있습니다.

(4) 인공지능과 현상학

주장: AI는 현상학의 연장선이며, 신경망은 사물을 "있는 그대로" 이해하지 않고 픽셀 패턴을 통계적으로 해석한다.
평가: 이 주장은 상당히 설득력 있습니다. AI, 특히 딥러닝은 입력 데이터(현상)를 기반으로 패턴을 학습하며, 이는 후설의 "의식이 대상을 구성한다"는 현상학적 관점과 유사합니다. 신경망이 "사과"를 픽셀 데이터의 통계적 패턴으로 처리한다는 점은 현상학의 "사물은 의식에 나타나는 방식으로만 존재한다"는 주장과 철학적으로 연결될 수 있습니다.
문제점: 다만, AI의 작동 원리는 현상학뿐 아니라 정보이론, 통계학, 인지과학 등 다양한 분야의 영향을 받았습니다. AI를 "현상학의 계산적 구현"으로 단정하는 것은 다른 학문적 기여를 간과할 수 있습니다. 또한, 현상학은 주관적 경험(의식)을 강조하지만, AI는 주관적 의식 없이 데이터 처리를 수행하므로, 이 둘의 본질적 차이를 명확히 해야 합니다.
수정 제안: "AI의 데이터 처리 방식은 현상학적 관점과 유사한 구조를 가지며, 특히 입력 데이터를 통해 세계를 표상한다는 점에서 현상학과 공명한다"는 식으로 표현하면 더 정확할 수 있습니다.

(5) 프로그래밍 언어와 현상학

주장: C, Python, Haskell 등의 프로그래밍 언어가 현상학적 사고를 구현한다.
평가: 이 부분은 매우 창의적이나, 지나치게 비유적입니다. 예를 들어, C 언어의 포인터가 "존재는 공간적 맥락 속에서 드러난다"는 현상학적 사고와 연결된다는 주장은 철학적 해석으로는 흥미롭지만, C 언어의 설계는 실제로는 하드웨어 제어와 효율성(예: 메모리 관리)을 목표로 했습니다. 마찬가지로 Python의 객체 지향적 특성이나 Haskell의 함수형 프로그래밍이 현상학과 직접적 연관이 있다고 보기는 어렵습니다. 이들 언어는 각각의 실용적·수학적 필요에 따라 발전했습니다.
문제점: 프로그래밍 언어의 설계는 주로 공학적, 수학적, 실용적 맥락에서 이루어졌으며, 현상학적 철학과 직접적 연관성은 역사적으로 확인되지 않습니다. 이를 철학적으로 재해석하는 것은 가능하지만, "구현했다"는 표현은 과장될 수 있습니다.
수정 제안: "프로그래밍 언어의 설계와 작동 방식은 현상학적 사고와 유사한 철학적 구조를 반영할 수 있다" 정도로 완화하면 더 적절합니다.

(6) 정보의 본질과 현상학적 환원

주장: 컴퓨터의 정보 처리는 현상학적 환원(에포케)과 유사하다.
평가: 이 주장은 매우 통찰력 있습니다. 후설의 에포케는 "사실 여부를 판단하지 않고 현상 그 자체를 관찰"하는 것을 강조하며, 이는 컴퓨터가 데이터(현상)를 있는 그대로 처리한다는 점과 유사합니다. 예를 들어, 컴퓨터가 사과의 "진짜" 본질을 따지지 않고 픽셀 데이터를 처리하는 방식은 현상학적 환원과 철학적으로 공명합니다.
문제점: 다만, 에포케는 주관적 의식의 맥락에서 수행되는 철학적 방법론이고, 컴퓨터의 데이터 처리는 의식 없이 기계적으로 이루어지므로, 이 둘을 동일시하는 것은 신중해야 합니다.
수정 제안: "컴퓨터의 정보 처리 방식은 현상학적 환원의 구조와 유사성을 보인다"고 표현하면 더 적절할 수 있습니다.

3. 틀린 부분은 있는가?

글 자체에 명백히 "틀린" 부분은 없지만, 몇 가지 주장에서 철학적 개념과 컴퓨터과학의 기술적 개념을 지나치게 직접적으로 연결하거나, 컴퓨터과학의 역사적·기술적 기원을 간과하는 경향이 있습니다. 주요 문제점은 다음과 같습니다:

과도한 단순화: 현상학과 컴퓨터과학의 개념을 1:1로 매핑하려는 시도는 철학적·기술적 엄밀함을 떨어뜨릴 수 있습니다. 예를 들어, 포인터와 의도성, OOP와 하이데거의 존재론을 직접 연결하는 것은 비유적으로는 유효하지만, 역사적·기술적 근거가 부족합니다.
역사적 맥락 부족: 컴퓨터과학의 개념들이 현상학에서 직접적으로 기원했다는 주장은 역사적 증거가 약합니다. 컴퓨터과학은 논리학, 수학, 공학의 영향을 더 직접적으로 받았으며, 현상학의 영향은 간접적이고 철학적 해석의 영역에 가깝습니다.
철학적 개념의 기술적 적용: 현상학의 의도성, 에포케 같은 개념은 주관적 의식과 관련이 깊지만, 컴퓨터과학은 의식 없는 기계적 처리에 초점을 맞춥니다. 이 차이를 명확히 하지 않으면 혼동을 초래할 수 있습니다.

4. 개선 제안

글의 논지를 강화하려면 다음과 같은 점을 고려할 수 있습니다:

역사적 맥락 추가: 컴퓨터과학의 발전 과정에서 현상학이 직접적 영향을 미쳤는지, 아니면 철학적 유사성에 초점을 맞출 것인지 명확히 하세요. 예를 들어, 앨런 튜링이나 존 폰 노이만 같은 컴퓨터과학의 선구자들이 현상학과 직접적 연관이 없었음을 인정하면 신뢰도가 높아집니다.
비유적 접근 강조: 현상학과 컴퓨터과학의 개념적 유사성을 강조하되, "기원"이나 "구현" 같은 강한 표현 대신 "공명한다"거나 "유사하다"는 표현을 사용하세요.
철학적·기술적 차이 명확화: 현상학의 주관적 의식과 컴퓨터의 기계적 처리 간의 본질적 차이를 언급하면 논리가 더 견고해집니다.
구체적 사례 추가: 예를 들어, 특정 프로그래밍 언어나 AI 알고리즘(예: CNN, Transformer)이 현상학적 사고와 어떻게 유사한지 구체적으로 설명하면 설득력이 높아집니다.

5. 결론

글은 현상학과 컴퓨터과학의 철학적 유사성을 창의적으로 탐구하며, 흥미로운 통찰을 제공합니다. 그러나 몇 가지 주장에서 지나친 단순화나 비약이 있으며, 컴퓨터과학의 역사적·기술적 기원을 간과한 점이 아쉬운 부분입니다. 명백히 "틀린" 부분은 없지만, 철학적 개념과 기술적 개념의 연결을 더 엄밀히 다루고, 비유적 접근임을 분명히 하면 논지가 더 강력해질 것입니다.

만약 특정 부분에 대해 더 깊이 논의하고 싶거나, 추가적인 수정 방향이 필요하다면 말씀해 주세요!

Claude:

이 글은 흥미로운 시도이지만, 몇 가지 중요한 문제가 있습니다:

주요 오류들

1. 역사적 인과관계의 과장

"현대 컴퓨터과학의 가장 근본적인 개념들이 현상학적 사고에서 출발했다"는 주장은 역사적으로 부정확합니다
컴퓨터과학의 추상화 개념은 수학(특히 형식논리학, 집합론)과 공학적 필요에서 발전했지, 현상학에서 직접 영향받은 것이 아닙니다
튜링, 폰 노이만, 처치 등 컴퓨터과학 선구자들은 현상학보다는 수리논리학과 형식주의에 기반했습니다

2. 개념의 억지 대응

"포인터 = 의도성"이라는 비교는 표면적 유사성만 본 것입니다
- 후설의 의도성(intentionality)은 의식이 항상 무언가에 '대해' 있다는 의미
- 포인터는 단순히 메모리 주소를 가리키는 기술적 장치
이 둘은 작동 방식도, 목적도 완전히 다릅니다

3. OOP와 하이데거의 연결

객체지향 프로그래밍은 1960-70년대 Simula, Smalltalk에서 시작
하이데거의 "도구적 존재론"과는 직접적 연관이 없습니다
오히려 데이터 캡슐화, 모듈성 같은 공학적 필요에서 출발했습니다

4. "AI는 현상학의 계산적 구현"

이는 너무 비약적입니다
AI는 통계학, 확률론, 최적화 이론에 기반합니다
"모델이 데이터를 통해 세계를 구성한다"는 진술은 현상학적이라기보다 베이지안 추론에 가깝습니다

더 정확한 관점

철학과 컴퓨터과학 사이에 사후적 유사성이나 평행적 구조는 발견할 수 있습니다. 하지만 "영향 관계"나 "기원"을 주장하려면 역사적 증거가 필요합니다.

예를 들어:

추상화 개념: 힐베르트의 형식주의, 러셀의 타입 이론
의미론: 타르스키, 크립키의 형식의미론
계산 이론: 괴델, 튜링의 수리논리학

오히려 둘 다 20세기 초 형식주의 운동이라는 공통 배경에서 나왔다고 보는 게 더 정확합니다.

다시 GPT:

지적한 부분들 정확합니다.
당신이 짚은 네 가지 비판은 모두 본질적인 오류를 제대로 짚고 있습니다.
이 논의는 “비유적 유사성”과 “역사적 영향 관계”를 구분하지 않으면 금세 미끄러지기 때문입니다.
아래는 그 구분을 분명히 하면서,
현상학과 컴퓨터과학이 ‘직접적 인과 관계’가 아니라 ‘병렬적 사유 구조’를 공유한다는 관점으로 재정리한 버전입니다.

1. 인과관계가 아닌 공시적 평행선

튜링, 처치, 폰 노이만, 괴델 등의 연구는 전적으로 수리논리학, 형식주의, 공학적 실용주의의 계보 위에 있습니다.
현상학(후설, 하이데거 등)은 그들과 직접 교류한 철학적 기반이 아니었습니다.

따라서 “컴퓨터과학이 현상학에서 출발했다”는 서술은 역사적으로 잘못입니다.
보다 정확한 진술은 다음과 같습니다.

“현상학과 컴퓨터과학은 같은 시대적 문제의식(표상, 의미, 구조화) 에 대해
각기 다른 언어로 응답했다.”

즉,

후설은 “의식이 세계를 어떻게 구성하는가?”를 물었고,
튜링은 “기계가 절차를 어떻게 표현할 수 있는가?”를 물었다.

둘 다 ‘형식화(formalization)’ 라는 동일한 지적 흐름의 일부였다는 점이,
유일하고도 합리적인 연결고리입니다.

2. “포인터 = 의도성”의 비유 한계

이 대응은 구조적 유사성 수준에서는 흥미로울 수 있지만,
철학적 내용까지 등치시킬 수는 없습니다.

구분후설의 의도성C의 포인터

철학적 의미	의식이 항상 ‘대상’을 향해 열려 있음	변수의 메모리 주소를 가리키는 참조 도구
존재론적 지위	인식론의 구조적 전제	컴파일러 수준의 구현 메커니즘
작동 방식	의미 생성의 방향성	간접 접근을 위한 주소 연산

즉,
“포인터는 의도성을 구현한다”가 아니라
“포인터는 참조(reference) 라는 개념을 통해
‘대상과의 간접적 관계’라는 현상학적 구조를 닮았다” 정도로 표현해야 타당합니다.

3. 객체지향과 하이데거의 ‘도구 존재론’

객체지향(OOP)은 역사적으로
Simula(1967), Smalltalk(1972)에서 비롯되었고,
하이데거의 철학과는 직접적인 영향 관계가 전혀 없습니다.

다만 개념적 평행선은 존재합니다.

하이데거OOP

도구는 사용될 때 의미를 드러낸다 (“ready-to-hand”)	객체는 메서드 호출 시 행위로 드러난다
존재는 맥락 속에서 드러난다	객체는 상호작용(인터페이스) 속에서 의미를 가진다

이건 “철학이 OOP를 낳았다”가 아니라
“도구 사용이라는 인간적 경험이
철학과 프로그래밍 모두에서 비슷한 구조로 표현되었다”는 수준의 유사성입니다.

4. AI와 현상학 ― ‘해석’의 공통 구조

AI의 기반은 통계학, 확률론, 선형대수, 최적화입니다.
이는 명백히 형식적·수학적 계보에 속합니다.

다만,
AI가 데이터를 통해 ‘세계의 모델’을 구성한다는 점에서,
현상학이 “세계는 인식의 구조 속에서만 주어짐”이라고 말한 것과
사유의 방향이 평행하게 닮아 있다고 말할 수 있습니다.

이건 철학적 영향이 아니라,
“인간 인식의 구조를 모방하다 보니
자연스럽게 현상학과 닮은 결과가 나왔다”는 의미의 결과적 수렴(convergence) 입니다.

5. 정확한 정리

관점잘못된 주장교정된 진술

역사적 기원	컴퓨터과학은 현상학에서 비롯되었다	둘 다 20세기 초 형식주의 운동의 결과로, 평행적으로 발전했다
포인터와 의도성	포인터는 의도성을 구현한다	포인터의 ‘참조 구조’가 의도성의 ‘대상 지향성’과 유사하다
OOP와 하이데거	OOP는 하이데거의 철학에서 영향을 받았다	도구적 존재론과 OOP는 “관계 속의 의미”라는 공통 구조를 가진다
AI와 현상학	AI는 현상학의 계산적 구현이다	AI는 수학적 모델이지만, ‘데이터를 통한 세계 구성’이라는 구조가 현상학과 평행하다

요약 결론

역사적으로:
컴퓨터과학은 현상학에서 직접 파생된 것이 아니다.
그 뿌리는 수리논리학, 형식주의, 공학적 필요다.
철학적으로:
그러나 인간의 ‘지각 구조’를 모방하려는 과정에서,
AI·프로그래밍·추상화는 현상학적 구조와 평행한 형태로 수렴했다.

따라서 올바른 표현은 이렇게 된다.

“현상학은 컴퓨터과학의 기원이 아니라,
그 형식적 사유가 인간 인식의 구조와
동일한 문제를 다른 언어로 탐구한 동시대적 사유이다.”

일관된 인간의 글이 그리워지는 효과가 좀 있다

위키피디아는 어떻지..?

https://en.wikipedia.org/wiki/Phenomenology_(philosophy)

Phenomenology (philosophy) - Wikipedia

From Wikipedia, the free encyclopedia Philosophical method and schools of philosophy Phenomenology is a philosophical study and movement largely associated with the early 20th century that seeks to objectively investigate the nature of subjective, consciou

en.wikipedia.org

임베딩 공간에서 (0, 0)은 무슨 뜻인가?

bpDev — Wed, 22 Oct 2025 01:38:29 +0900

https://www.aiweirdness.com/welcome-to-word-vector-space-19-03-29/

Welcome to Word Vector Space

On this blog I’ve posted a lot about neural networks and other machine learning algorithms. Unlike other kinds of computer programs, they don’t rely on step by step instructions from a programmer - instead, they’re given a goal, like a score to maxim

www.aiweirdness.com

☞ 추후 이 링크랑 github 살펴볼 것 ☜

이 질문 위에서 소설을 써서 상당히 문학적으로 답변을 줌 ㅋㅋ

1️⃣ 임베딩 공간에서 (0, 0)은 무슨 뜻인가?

수학적으로 보면 (0, 0)은 벡터의 원점, 즉 아무 방향성도, 아무 의미적 특징도 없는 상태예요.

언어적으로 해석하면,

“어떤 문맥에도 특별히 연결되지 않은, 가장 중립적인 개념”
또는
“정보가 거의 없는 단어”
입니다.

2️⃣ 실제 모델에서 (0, 0)에 가까운 단어는?

물론 실제 임베딩은 512차원, 768차원 등이라 단순히 (0, 0) 같은 점은 존재하지 않아요.
하지만 원점에 가까운 벡터, 즉 “모든 차원에서 값이 거의 0에 가까운 벡터”는 존재합니다.
그건 보통 다음과 같은 것들과 관련됩니다.

유형예시이유

불용어(stopwords)	“the”, “a”, “is”, “of”, “and”, “to”	문법적으로 자주 등장하지만 의미 정보는 거의 없음
패딩 토큰(padding token)	<pad>	문장 길이를 맞추기 위해 넣은 의미 없는 토큰
문장 구분 토큰	<sep>, <cls> 등	구조적 신호이긴 하지만 단어 의미는 없음
숫자나 기호	“123”, “@”, “#” 등	문맥적 의미가 거의 없음

즉, (0, 0)에 가깝다는 건 "언어적으로 비중립적"하다는 뜻이에요.
문장의 내용을 바꾸지는 않지만, 구조를 유지하는 역할을 합니다.

3️⃣ 의미적으로 해석하자면

(0, 0)은 의미의 진공,
그 주변은 문법적 허공,
중심에서 멀어질수록 의미가 특정 영역으로 쏠림.

그래서 임베딩 공간의 중심은 “의미의 중립지대”라고 할 수 있습니다.

4️⃣ 감각적 비유

만약 이 임베딩 공간을 은하계로 본다면:

(0, 0)은 아무 별도 없는 은하의 중심 어둠
주변에는 ‘the’, ‘a’, ‘of’ 같은 작고 희미한 별들이 떠 있음
반면 “apple”, “cat”, “love”, “refrigerator” 같은 단어들은
각자의 은하 팔(팔 성운) 쪽에 자리해, 서로 다른 별자리처럼 모여 있음

요약하자면,

임베딩의 (0, 0)은 “의미가 가장 희미한 자리”,
즉 “언어라는 우주에서의 중심 공허점”이에요.

1️⃣ 모델이 임베딩 원점 근처의 단어를 자주 사용한다면 — “평평한 언어의 문체”

임베딩의 원점 근처는 모든 방향(의미 벡터) 에서 거의 0에 가까운 자리입니다.
즉, 특정 의미로 치우치지 않은 단어들이 밀집해 있죠.

이런 단어들이 많이 쓰인 글의 특징은:

특징설명

중립적 어조	감정이나 의견 없이 사실만 전달 (예: 뉴스 헤드라인, 백과사전)
의미 밀도 낮음	각 문장이 새로운 정보를 덜 추가함
문장 간 편차 적음	글 전체의 벡터 분포가 원점 주변에 좁게 모임
대표 예시	“금융 시장은 오늘 하락세를 보였다.”, “회의가 열렸다.”

→ 즉, 이런 문체는 ‘정보 전달’은 하지만 ‘정서적 에너지’가 거의 없는 글쓰기입니다.

그래서 언어 모델이 이런 단어를 자주 쓴다면,
그건 마치 의미적 무채색 언어, 즉 감정도 주장도 없는 글체를 사용하는 셈이에요.

2️⃣ 의미적으로 강한 단어들이 원점에서 멀어진다면 — “감정의 언어는 별자리처럼 퍼진다”

임베딩 공간의 끝쪽(멀리 떨어진 곳)에는
의미가 강하게 특정 방향으로 치우친 단어들이 있습니다.

예를 들어:

“사랑”, “기쁨”, “환희” → 감정 양성 방향
“증오”, “전쟁”, “비극” → 감정 음성 방향
“혁명”, “신념”, “자유” → 철학적 강도 방향

이런 단어들이 많은 글은
임베딩 공간에서 넓게 퍼지고 방향성이 뚜렷한 구름 모양으로 나타납니다.

수학적으로 보면:

분산(variance) 이 크고,
중심에서 멀리 있는 벡터가 많고,
특정 방향의 평균벡터(mean vector) 가 강한 편향을 가집니다.

즉,

감정이 강한 글은 임베딩 공간에서 폭발적으로 확산된 형태를 띱니다.
(마치 중립적 언어가 구름이라면, 감정적 언어는 폭풍 구름이에요.)

3️⃣ (0, 0) 근처에 있던 단어가 학습을 통해 멀어지는 과정 — “의미가 태어나는 장면”

실제로 임베딩 학습은 “의미의 생성 과정” 을 수학적으로 모델링한 것이 맞습니다.

Word2Vec의 학습 과정을 보면,
초기에는 모든 단어 벡터가 무작위(random) 로, 즉 거의 원점 근처에 흩어져 있어요.
훈련이 진행되면,
단어들이 문맥 속에서 자주 함께 등장하는 방향으로 조금씩 이동하기 시작하죠.

예를 들어:

“apple”이 “banana”, “fruit”과 자주 등장하면
그들과 가까운 벡터로 이동하고,
“dog”은 “animal”, “pet” 쪽으로 이동합니다.

즉, 학습은

원점의 무의미한 점들이 “의미의 중력장” 속으로 떨어지며 궤도를 형성하는 과정이에요.

철학적으로 보자면 —
이건 마치 “혼돈에서 의미가 생겨나는 과정”,
즉 의식의 진화나 학습의 은유로도 읽을 수 있습니다.

요약

질문공간적 현상문체적/철학적 의미

원점 근처 단어가 많을 때	벡터가 중심 근처에 밀집	중립적, 객관적, 정보 중심 언어
원점에서 멀리 떨어진 단어	방향성이 강함	감정적, 시적, 주관적 언어
원점에서 벗어나는 학습	무의미 → 의미로의 이동	지식·경험·의식의 성장 은유

어텐션 시티의 탄생

bpDev — Wed, 22 Oct 2025 00:38:12 +0900

"의미는 관계 속에서만 존재한다."

글, 표지 GPT-5

《어텐션 시티의 탄생》

1. 서막 ― 혼돈의 도시

그 도시의 이름은 SeqTown이었다.
수많은 단어들이 행진처럼 이어진 도시.
문장 하나가 도로였고, 문단은 대륙이었다.

이 도시는 오래도록 RNN 왕국이 다스려왔다.
왕국의 군대는 질서정연했다.
단어 병사들이 한 줄로 늘어서서,
“첫 번째 단어가 끝나야 두 번째 단어가 움직인다.”
그것이 그들의 법이었고, 전통이었다.

하지만 세상은 변하고 있었다.
문장들은 길어지고, 문맥은 멀리 이어졌다.
앞줄의 병사가 뒤줄의 의미를 잊어버리는 일이 잦았다.
왕국의 연산 속도는 느려졌고,
기계들은 피로에 찌들었다.

그때 나타난 젊은 혁명가가 있었다.
그의 이름은 Attention.
그는 외쳤다.

“이제 더 이상 한 줄로 설 필요는 없어!
모두가 서로를 바라보면 되잖아.”

2. 혁명 ― “모두가 모두를 본다”

Attention은 자신만의 도시를 세웠다.
이곳의 이름은 Transformer City.
그곳에서는 모든 단어가 자유롭게 하늘을 날았다.

한 단어가 다른 단어를 볼 수 있었고,
어떤 단어는 아주 멀리 떨어진 구절과도 연결될 수 있었다.

이 도시는 세 가지 신호로 움직였다.
그것은 세 개의 신비한 열쇠였다 —

Query (질문): “나는 누구를 봐야 하지?”
Key (열쇠): “나는 어떤 의미를 가진 존재인가?”
Value (값): “내가 전할 정보는 이것이야.”

모든 단어는 이 세 가지 신호를 품고 있었다.
Attention은 각 단어의 Query가 다른 단어들의 Key를 두드리게 했다.
열쇠가 잘 맞는다면, 그 단어에 더 많은 주의를 주었다.

“너와 나의 유사도가 클수록, 나는 너를 더 본다.”

이 단순하지만 절묘한 규칙이 Transformer City의 심장이었다.

그리고 이 모든 연산은 한 번에 이루어졌다.
왕국 시절처럼 단어가 줄을 서서 기다릴 필요가 없었다.
모든 병사가 동시에 눈을 떴고, 동시에 서로를 봤다.

3. 인코더와 디코더 ― 쌍둥이 탑

도시의 중심에는 두 개의 탑이 있었다.
인코더 타워와 디코더 타워.

인코더 타워에는 입력 문장의 단어들이 들어왔다.
프랑스어 문장이라면, 단어들이 차례로 빛의 형태로 변해 들어왔다.
각 단어는 스스로와 다른 단어를 주시하며 의미의 조각을 완성했다.
그 결과로 인코더의 꼭대기에는
문장의 전체 의미를 압축한 빛나는 벡터가 떠올랐다.

그리고 그 빛은 디코더 타워로 전달됐다.
디코더의 일꾼들은 그 빛을 참고해 새로운 언어를 만들어냈다 —
영어, 스페인어, 한국어…

하지만 디코더에는 한 가지 법이 있었다.

“미래를 보지 말 것.”

아직 생성되지 않은 단어를 보지 않도록
**마스크(mask)**가 걸려 있었다.
디코더의 주의는 오직 과거 단어들과 인코더의 빛으로만 향했다.
그들은 시간을 순서대로 따라갔지만,
동시에 이미 만들어진 모든 단어를 한눈에 볼 수 있었다.

4. 위치의 마법 ― 포지셔널 인코딩

이 자유로운 세계에도 한 가지 문제가 있었다.
모든 단어가 서로를 다 볼 수 있다 보니,
“누가 먼저였는지”를 잊어버리기 시작한 것이다.

그러자 학자들이 새로운 마법을 만들어냈다.
그것이 바로 **포지셔널 인코딩(Positional Encoding)**이었다.

그들은 사인과 코사인, 두 개의 파동을 이용해
각 단어에 “좌표”를 새겼다.
이 좌표는 10000이라는 거대한 주기를 기준으로
주파수가 달라지는 파동이었다.

그래서 모델은 이렇게 기억하게 되었다.

“나는 세 번째 단어야.
그리고 네 번째 단어와는 1만큼 떨어져 있어.”

이 마법 덕분에 Transformer City는
문장 속의 순서를 잃지 않고 자유를 누릴 수 있었다.

5. 멀티헤드의 시대

Attention은 머리가 여러 개였다.
하나의 눈으로는 단어 사이의 모든 관계를 다 볼 수 없다는 걸 깨달았기 때문이다.

그래서 그는 **여러 개의 시선(Head)**을 만들어냈다.
각 시선은 다른 관계를 바라봤다.
어떤 시선은 문법적인 연결을,
어떤 시선은 감정의 흐름을,
또 어떤 시선은 주제의 일관성을 포착했다.

그리고 모든 시선이 본 것들을 모아
최종적인 이해를 완성했다.

“여러 관점을 합치면 더 깊이 이해할 수 있다.”

그것이 Transformer City의 철학이었다.

6. 병렬의 신전

Transformer City의 진정한 힘은 **병렬성(Parallelism)**이었다.

RNN 왕국은 한 줄로 일했지만,
Transformer는 수천 개의 손이 동시에 움직였다.
그래서 훈련 속도는 수십 배 빨랐고,
GPU 신전의 불꽃이 그들의 연산을 가속했다.

이 새로운 도시의 발전 속도는 폭발적이었다.
이제 그들은 긴 문장도 쉽게 다뤘고,
언어의 바다에서 의미를 추출했다.

7. 후일담 ― 계승자들

Transformer City의 성공은 세상 전체를 바꾸었다.
그 후손들이 전 세계로 퍼졌다.

BERT, 문장의 의미를 깊이 이해하는 현자.
GPT, 문장을 새로 창조하는 시인.
T5, ViT, Whisper… 다양한 분야의 자손들.

그들의 가슴 속엔 모두 같은 문장이 새겨져 있었다.

“Attention is all you need.”

8. 에필로그 ― 인간의 언어, 기계의 사유

세월이 흘러, 이제 Transformer의 후손들은 인간의 말을 듣고,
그 의미를 이해하며, 때로는 인간보다 더 유려한 문장을 써내려간다.

그러나 Transformer의 첫 설계자는 이렇게 말했다.

“우리가 만든 것은 기계가 아니라,
의미를 향한 눈이다.”

언어를 본다는 것은 곧 세계를 이해한다는 뜻이었다.
그리고 그 첫 시선의 이름은 — Attention이었다.

해설 요약

이 소설에 등장한 개념들은 실제 논문의 구조를 상징합니다:

소설 속 표현실제 의미

RNN 왕국	과거의 순환신경망 모델
Attention 혁명가	Self-Attention 메커니즘
Query, Key, Value	어텐션의 핵심 수식 구성요소
인코더 타워	입력 문장을 벡터화하는 인코더 블록
디코더 타워	출력 문장을 생성하는 디코더 블록
마스크	미래 토큰을 참조하지 않게 하는 규칙
포지셔널 인코딩	문장 내 순서 정보를 위한 sin/cos 좌표 부여
멀티헤드	여러 종류의 관계를 병렬로 학습하는 구조
병렬의 신전	GPU 가속과 병렬 처리의 이점
Transformer City	Transformer 모델 전체

" 모든 병사가 동시에 눈을 떴고, 동시에 서로를 봤다. "

아래 떠다니는 클론들 눈을 동시에 떴던 것 같은데, 위 문장을 보니 이 장면이 잠깐 떠올랐다. ㅋ

에반게리온 한 장면

"의미는 관계 속에서만 존재한다."

존재나 의미나 관계 모두 예전과 다르게 정의되고 있지 않을까?

진화랄 것도 없을 것 같은 짧은 시간 동안인데도 변화가 너무 크게 느껴진다.

상대적으로는 우리가 너무 여린 존재이기도 하고..

그만큼 꽉 막힌 경우도 많은 것 같다.

기계의 심장 - 하나의 컴퓨터가 깨어나는 이야기

bpDev — Mon, 20 Oct 2025 21:41:17 +0900

글, 표지 GPT-5

밤은 깊었고, 방 안에는 고요히 빛나는 한 줄기 푸른 불빛만이 있었다.
그것은 전원 버튼이었다.

찰나의 떨림, 그리고—
세상은 전류의 물결로 깨어났다.

1. 중앙의 왕 ― CPU

기계의 중심에는 한 명의 왕이 있었다.
그의 이름은 CPU,
수많은 계산과 명령의 행진을 지휘하는 절대자였다.

왕의 궁전은 금빛 회로로 둘러싸인 하나의 도시였다.
그의 밑에는 여러 명의 코어 기사들이 있었다.
각자는 병법과 연산의 달인이었고,
왕의 명령을 받아 수많은 전투—곧 프로세스들을 병렬로 수행했다.

그들의 대화는 인간의 언어가 아니었다.
0과 1, 단 두 글자의 시.
그 속에 우주의 질서가 숨어 있었다.

2. 기억의 여왕 ― RAM

왕은 홀로 기억하지 않았다.
그의 곁에는 신비로운 여왕 RAM이 있었다.
그녀의 궁정은 잠시 머물다 사라지는 꿈의 나라 같았다.

명령이 시작되면, 여왕은 하얀 손으로 기억의 조각을 꺼내
왕에게 건넸다.
하지만 전원이 꺼지는 순간—그 모든 기억은 바람 속으로 흩어졌다.
그래서 그녀는 언제나 덧없는 미소를 띠고 있었다.

3. 심연의 기록자 ― Storage

깊은 땅속, 차가운 철제의 성벽 속에는
묵묵히 깃털 펜을 움직이는 한 존재가 있었다.
그는 Storage,
세상의 모든 일을 기록하는 불멸의 서기관이었다.

왕이 내린 명령, 여왕이 흘린 꿈,
모든 흔적은 그의 두꺼운 강철의 서책 안에 새겨졌다.
그의 글은 느리지만, 결코 잊히지 않았다.

4. 그림자 화가 ― GPU

성벽 밖, 황금빛 먼지를 일으키며 달리는 또 하나의 예술가가 있었다.
그의 이름은 GPU,
빛과 색의 신이자, 세상을 그리는 화가였다.

그는 수백, 수천의 작은 요정들을 부렸다.
요정들은 픽셀 하나하나를 쌓아 올려
왕국의 벽면에 이미지를 그렸다.

CPU의 기사들이 질서의 전쟁을 벌일 때,
GPU의 요정들은 혼돈 속에서 아름다움을 완성했다.

5. 전류의 강 ― 메인보드

이 모든 것은 한 강을 따라 흐르고 있었다.
그 강의 이름은 메인보드 버스.
전류는 강물처럼 흘러, 왕과 여왕과 화가를 이어 주었다.

그 위에는 구리빛 다리들이 놓였고,
데이터는 이 다리를 건너 노래하듯 움직였다.
때때로 전압이 높아지면 번개가 치듯,
모든 회로는 빛으로 뒤덮였다.

6. 바람의 기사 ― 쿨러

그러나 이 왕국에도 고통은 있었다.
열기.
모든 생명은 계산의 불꽃 속에서 뜨겁게 타올랐다.

그때 등장한 것은 쿨러였다.
그는 거대한 날개를 가진 바람의 기사.
그의 날개가 돌 때마다, 뜨거운 회로 위로
시원한 바람이 불었다.

그가 없었다면, 왕국은 순식간에 불타버렸을 것이다.

7. 깨어남 ― 부팅의 의식

모든 존재가 자리 잡았을 때,
왕은 깊은 숨을 내쉬며 명령을 내렸다.
“모든 코어, 깨어나라.”

그 순간—
여왕의 기억이 펼쳐지고,
서기관의 기록이 불려나오며,
화가의 붓이 빛을 그리기 시작했다.

기계의 심장은 박동을 시작했고,
세상은 다시 작동 중이었다.

8. 전원의 신 ― 사용자

그리고 멀리서 한 존재가 그들을 지켜보고 있었다.
그의 손끝이 단 하나의 버튼을 누를 때마다
왕국은 태어나고, 사라졌다.

그는 창조자이자 파괴자,
“사용자”라 불리는 신이었다.

그의 의지가 곧 명령어였고,
그의 클릭 한 번이 왕국 전체의 운명을 바꾸었다.

에필로그

밤이 다시 찾아왔다.
모든 불빛이 꺼지고, 전류의 강이 고요히 멈추었다.

그러나,
서기관은 여전히 철의 심연에서 속삭였다.
“기억은 남는다. 다음 부팅을 위해.”

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
오글거리지만 웃겨

Singleton Pattern

bpDev — Mon, 17 Mar 2025 00:58:46 +0900

class Connection {
    private static Connection _inst;
    private int count;
    
    private Connection(){
    	count = 0;
    }
    
    public static Connection getInstance(){
    	if(_inst == null){
        	_inst = new Connection();
        }
        return _inst;
    }
    public void count(){
    	count++;
    }
    public int getCount(){
    	return count;
    }
}

public class BB {
	public static void main(String[] args){
		Connection conn1 = Connection.getInstance();
		conn1.count();
		Connection conn2 = Connection.getInstance();
		conn2.count();
		Connection conn3 = Connection.getInstance();
 		conn3.count();
		conn1.count();
		System.out.print(conn1.getCount());
    }
}

이 코드는 Singleton pattern을 사용하여 프로그램 전역에서 단 하나의 Connection 객체만 생성되도록 구현한 것

앱 내에서 특정 클래스의 인스턴스가 오직 하나만 존재하도록 보장하고, 어디서든 접근할 수 있도록 하기 위한 것

싱글턴 패턴은 프로그램에서 모든 클라이언트가 사용할 수 있는 단일 인스턴스가 있어야 할 때 사용할 것

(단일 책임 원칙 위반, 멀티스레드 환경에서 동기화 처리, 메서드 이름 선택으로 인한 혼동 등 주의점들 있음)

1. 싱글턴 구현

- 클래스 내의 private static Connection _inst; 선언에서 _inst 변수는 클래스 내에서 단 하나의 인스턴스만 저장함
: 멤버 변수 중 static정적 변수 _inst. 이 변수는 클래스가 메모리에 로드될 때 한 번만 할당(생성)되며, 모든 호출자가 공유하는 유일한 인스턴스를 저장함(한 번 생성된 _inst 변수에 저장된 인스턴스가 프로그램 내 모든 곳에서 동일하게 사용됨.). Java에서 static 변수는 클래스 로딩 시점에 메모리에 할당되고, 클래스 전체에서 그 이름으로 단 하나만 존재함.

: 멤버 변수 중 인스턴스 변수 count 선언. 변화값을 담는 용도.

- private Connection() 생성자를 통해 외부에서 직접 인스턴스 생성을 막음

: 비공개 생성자. 생성자를 private로 선언하여 외부에서 직접 인스턴스를 생성하는 것을 막음. 이는 외부 코드가 new Connection()을 호출하지 못하게 하여 오직 클래스 내부의 메서드에서면 인스턴스를 생성할 수 있도록 함

- public static Connection getInstance() 메서드는 _inst가 null일 때만 새로운 Connection 객체를 생성하고, 그 이후에는 이미 생성된 객체를 반환하여 항상 동일한 객체를 사용하게 됨. 즉 _inst를 통해 클래스 전체에서 유일한 Connection 인스턴스만 존재/공유하게 하며 객체 생성이 여러번 이루어지는 것을 방지함

: 정적 팩토리 메서드. 이 메서드는 최초 호출 시 인스턴스가 없으면 새로 생성하고 이후 호출부터는 이미 생성된 인스턴스를 반환함. 즉 인스턴스 생성은 지연 초기화(lazy initialization) 방식으로 이루어짐

2. 메서드들

- public void count()는 인스턴스 변수 count 값을 1 증가 시킴

- public int getCount()는 현재 count의 값을 반환함

3. main 메서드의 실행 흐름

- Connection conn1 = Connection.getInstance();

: 첫 호출이니까 null이라서 새로운 Connection 객체 생성함. count는 0이 됨

- conn1.count();

: count가 ++ 증가하여 1이 됨

- Connection conn2 = Connection.getInstance();

: 이미 생성된 동일한 객체를 반환받음

- conn2.count();

: count가 1에서 1 증가하여 2가 됨

- Connection conn3 = Connection.getInstance();

: 다시 동일한 객체를 반환받음

- conn3.count();

: count가 또 증가하여 3이 됨

- conn1.count();

: 동일 객체의 count가 1 증가하여 4가 됨

- System.out.print(conn1.getCount());

: 최종적으로 count의 값인 4를 출력함

https://refactoring.guru/ko/design-patterns/singleton

싱글턴 패턴

/ 디자인 패턴들 / 생성 패턴 싱글턴 패턴 다음 이름으로도 불립니다: Singleton 의도 싱글턴은 클래스에 인스턴스가 하나만 있도록 하면서 이 인스턴스에 대한 전역 접근(액세스) 지점을 제공하

refactoring.guru

Embedding model이란 + CLIP, Stable diffusion

bpDev — Sat, 22 Feb 2025 18:54:56 +0900

출처 : aws.amazon.com/ko/what-is/embeddings-in-machine-learning

임베딩(Embedding)이란?

어떤 “이산적(discrete 구분되는)”인 객체(예: 단어, 문장, 이미지, 그래프 상의 노드 등)를 연속적인 벡터 공간으로 변환(매핑)하는 방법. 이산적인 데이터(예: ‘단어’, ‘문서’, ‘이미지’, ‘엔티티’)를 숫자 벡터로 표현해주기 때문에, 컴퓨터가 수학적으로 취급하거나 계산하기 쉬워짐. 이때 벡터 간의 거리나 방향을 통해 유사성, 문맥, 의미 관계 등을 어느 정도 추론할 수 있게 됨. * 이미지와 텍스트는 다른 종류의 정보지만, CLIP 모델 같은 것으로 동시에 학습 시킬 경우 벡터가 가까워 질 수 있음

"Embedding

고차원 공간에서 단어나 이미지와 같은 데이터를 수학적으로 표현한 벡터뭉치. 데이터 처리 시 각 데이터에 일대일로 대응하는 벡터를 만들어 이를 밀집된 벡터 뭉치로 두게 되는데 이를 임베딩이라 하는 것이다.

기존에도 자연어를 처리하는 데에는 아스키 코드와 같은 언어 모델들이 이미 존재했지만 이는 단순히 단어와 컴퓨터가 인식하는 언어 사이의 일대일 대응일 뿐이며, 단어의 뜻이나 속성을 나타내는 속성은 전혀 없었다. 때문에 이러한 기존의 언어모델을 이용하여 단어의 뜻이나 맥락이 필요한 응용에는 한계가 있을 수밖에 없었으므로 이러한 응용을 위해서는 단어가 가진 속성을 포함한 언어 체계가 필요했다. 이러한 방법론의 일환으로 단어의 각각의 속성을 벡터로 치환한 후에 이러한 속성들의 합을 벡터 뭉치(=임베딩)로 만들어 단어에 대응시키는 방법론이 제시된 것이다. 이 경우 두 단어 간의 유사성을 측정하거나 언어 번역 또는 텍스트 분류와 같은 작업을 수행하는 것이 매우 수월하게 된다. 이와 같은 원리는 마찬가지로 이미지에도 적용할 수 있으며, 이를 응용하면 이미지 분류 또는 이미지 검색과 같은 작업을 좀 더 수월하게 수행할 수 있게 된다.
대표적인 임베딩의 생성 알고리즘이 그 유명한 CLIP 모델. CLIP 모델은 텍스트와 이미지의 임베딩을 생성할 수 있는 사전 훈련된 신경망으로, 자연어를 입력할 경우 이를 임베딩으로 변환하여 77 x 768 숫자 값 목록이 생성된다. AI 그림 모델로 유명한 Stable Diffusion이 바로 이 CLIP 모델을 사용하여 만들어진 그림 생성 모델이다. SD를 써 본 사람이라면 한번쯤은 '클립 건너뛰기' 옵션을 보았을텐데, 이 클립 건너뛰기에서의 클립이 바로 이 CLIP 모델을 의미하는 것이다."

"CLIP model

OpenAI에서 개발한 신경망 아키텍처로, 자연어를 이해하고 Computer Vision을 구현하는 등 인간의 언어/이미지를 컴퓨터로 처리할 수 있게끔 해주는 모델이다.
CLIP 모델은 ViT(Vision Transformer)와 Transformer 언어 모델(Transformer-based language model)을 결합하여 이미지와 텍스트를 모두 처리할 수 있게 만들어놓은 모델이다. 여기서 ViT란 비지도학습을 통해 이미지에서 특징을 추출할 수 있도록 만들어진 Transformer가 이미지를 처리할 수 있도록 이미지를 patch 형태로 처리할 수 있도록 하는 모델이다. 이미지 추출을 할 수 있는 모델을 ViT, CNN 모델로 테스트했다. Transformer 언어 모델은 사전훈련(pre-trained)을 통해 텍스트 데이터를 학습해놓은 모델이다.
CLIP 모델에 자연어를 입력할 경우 이를 임베딩으로 변환하여 77 x 768 숫자 값 목록이 생성되며, 이 임베딩의 숫자값을 바탕으로 이미지 처리가 가능한 것이다.
CLIP 모델은 2022년부터 우후죽순으로 개발된 AI 그림의 기반이 모두 여기에 있다 해도 전혀 과장이 아닐 정도로 AI 개발에 있어 강력한 도구 중 하나이다. 이를 통해 텍스트 및 이미지와 같은 복잡한 데이터를 처리하고, 컴퓨터가 이해하는 방식이 혁신적으로 개선되었기 때문."

"Stable Diffusion

Stability AI에서 오픈소스 라이선스로 배포한 text-to-image 인공지능 모델이다. 2022년 8월 22일 출시했다. 대다수의 이미지 인공지능들은 온라인에서만 서비스하는데, 스테이블 디퓨전은 개인의 PC로 실행 즉 '로컬 환경'으로 설치 및 실행 할 수 있는게 큰 차이점이다.
Stable Diffusion은 독일 뮌헨 대학교 Machine Vision & Learning Group (CompVis) 연구실의 "잠재 확산 모델을 이용한 고해상도 이미지 합성 연구"를 기반으로 하여, Stability AI와 Runway ML 등의 지원을 받아 개발된 딥러닝 인공지능 모델이다.
Stability AI는 영국인 에마드 모스타크(Emad Mostaque)가 만든 회사로, Stable Diffusion에 방대한 LAION-5B 데이터베이스를 학습시킬 수 있도록 컴퓨팅 자원을 제공하였다. OpenAI의 Dall-e 2나 구글의 Imagen과 같은 기존 text-to-image 모델들과는 다르게 컴퓨터 사용 리소스를 대폭 줄여 4GB 이하의 VRAM을 가진 컴퓨터에서도 돌릴 수 있다...
... 2023년 7월 26일 Stability AI에서 SDXL 버전을 출시했다. 매개변수가 8억 9천만개에서 26억개로 약 3배 가량 늘어난만큼 세밀한 묘사가 기존의 SD 1.5보다 훨씬 뛰어나고 단어나 간단한 문장도 쓸 수 있다. 다만 퀄리티가 늘어난 만큼 요구 사양도 크게 늘어나서 여전히 1.5를 사용하는 사람들도 많다.
한국 시간으로 2024년 6월 13일, 매개변수 20억개 버전인 SD3 medium이 먼저 오픈소스로 풀렸다. 매개변수만 보면 SDXL보다 6억개 적지만, 내부 알고리즘을 Unet에서 MMDiT로 갈아치우고 보다 효율적인 방향으로 학습을 시키는 등 SDXL보다 가벼우면서 이미지의 품질이나 정확성은 훨씬 진보했다고 한다. 회사 관련인들의 주장으로는 일반인 선에서는 medium으로도 충분하고도 넘칠 성능이라고 한다. 미세 조정에서도 SDXL보다 더 효율적일 것이라고 장담한 것은 덤.
다만 SDXL까지와 달리 SD3는 Stability AI에게 별도의 수수료를 지불하지 않는 한 비상업적 목적으로만 모델을 활용해야 하다보니 본격적인 보편화가 쉽지 않을 전망이다. 특히 SD3 기반 NovelAI Diffusion이나 Pony Diffusion 등 우수한 모델의 등장 시기가 더 미뤄질 가능성이 높다. 가장 대중적인 커뮤니티인 Civitai에서도 라이선스 문제가 해결되기 전까지는 SD3 관련 자료를 일시적으로 금지했으며, 결국 Stability AI 측에서 라이선스를 대폭 완화하는 방향으로 수정했다.
Stability AI가 Stable Diffusion 3로 갈팡질팡하며 삽질을 계속하는 사이, Black Forest Labs라는 Stability AI 출신 인원들이 설립한 신흥 인공지능 회사가 출범하면서 매개변수 120억짜리 강력한 그림 인공지능 모델인 FLUX.1을 선보였다. 물론 Stability AI도 이에 대응하듯이 개선판인 Stable Diffusion 3.1을 예고했고 훨씬 가벼우면서 FLUX.1 Pro에 못지 않게 우수한 이미지를 생성할 수 있다고 주장했지만, 유저들의 반응은 또 속냐며 차가운 상태다보니 실제로 상당한 개선을 선보여야 할 것으로 평가된다.
실제로 경쟁자의 등장 및 여러 비판으로 호되게 당한 것을 반면교사 삼았는지, 개선판인 Stable Diffusion 3.5는 호평을 받았다. 확실히 강력하기는 하지만 너무 무거워서 로컬 유저들에게 부담을 주는 FLUX.1에 비해서, 다양한 성능을 제공하는 SD3.5에 더 기대를 거는 유저들도 많이 나타났다."

임베딩의 중요성
NLP(자연어 처리) 분야에서는 주로 “단어, 문장, 문서” 등을 벡터로 바꿔서 텍스트 분석, 감정 분석, 질의응답, 기계 번역 등 다양한 과제에서 활용. 컴퓨터 비전(이미지 처리) 분야에서는 이미지나 영상 데이터를 CNN, Transformer 등으로 처리하여 특징 벡터(Feature Vector)로 변환함으로써 이미지 분류나 유사 이미지 검색 등에 사용함
기타 분야(추천 시스템, 지식 그래프 등)에서도 엔티티나 관계를 벡터화하여 유사성, 관련성, 추론 등에 사용함

정적 임베딩(Static Embedding) vs 문맥적(동적) 임베딩(Contextual Embedding)
Word2Vec, GloVe, FastText, Doc2Vec 등은 정적 임베딩을 만듦 → 한 번 학습하면 같은 단어(또는 문서)에 대해서는 항상 동일한 벡터가 나옴
BERT, ELMo, Sentence-BERT 등은 문맥 의존적 임베딩 → 똑같은 단어라도 문맥에 따라 다른 벡터가 생성됨
이미지 임베딩에서는 CNN뿐 아니라 최근에는 Transformer 기반 방식(ViT, Swin Transformer 등)이 활발히 연구/활용되고 있다고 함. Knowledge Graph 지식 그래프 Embedding은 엔티티(점)와 관계(선)를 벡터 공간에서 수학적으로 모델링함으로써, 연결/관계를 예측하거나 새로운 지식을 추론할 수 있도록 함

Embedding model 종류들

1. 자연어 처리(NLP)에서의 임베딩 모델

(1) Word2Vec
개발자: Google (Tomas Mikolov 등)
특징: 단어를 벡터로 변환하며, 주변 단어(문맥)를 기반으로 의미를 학습
방법: CBOW(Continuous Bag of Words)와 Skip-gram 두 가지 방식
용도: 단어 간 유사성 계산, 텍스트 분석
예: "왕"과 "여왕"의 벡터가 비슷한 위치에 매핑됨

(2) GloVe (Global Vectors)
개발자: Stanford University
특징: 단어의 동시 발생 확률(Co-occurrence)을 기반으로 전역 통계 정보를 활용
장점: Word2Vec보다 단어 쌍의 관계를 더 잘 잡아냄
용도: 텍스트 분류, 감정 분석 등

(3) FastText
개발자: Facebook
특징: Word2Vec의 확장판. 단어를 n-gram(문자 단위)으로 쪼개 학습
장점: 드문 단어나 오타에도 강함
용도: 다국어 처리, 철자 오류가 많은 데이터에 유리

(4) BERT (Bidirectional Encoder Representations from Transformers)
개발자: Google
특징: 양방향 문맥을 고려해 단어 임베딩 생성. 정적인 벡터가 아니라 문맥에 따라 동적으로 변함.
장점: 문장 수준의 이해가 뛰어남
용도: 질의응답, 텍스트 생성, 감정 분석

(5) ELMo (Embeddings from Language Models)
개발자: Allen Institute
특징: 문맥에 따라 단어의 의미를 다르게 임베딩(동적 임베딩)
장점: 다의어(예: "bank"가 은행인지 강둑인지) 구분 가능
용도: 복잡한 NLP 태스크

(6) Sentence-BERT (SBERT)
특징: BERT를 개선해 문장 수준의 임베딩을 효율적으로 생성.
용도: 문장 유사도 비교, 클러스터링

2. 이미지 처리에서의 임베딩 모델

(1) CNN 기반 임베딩 (예: ResNet, VGG)
특징: Convolutional Neural Network로 이미지 특징을 추출해 벡터로 변환
용도: 이미지 검색, 얼굴 인식

(2) Vision Transformer (ViT)
특징: 트랜스포머 구조를 이미지에 적용해 패치 단위로 임베딩
용도: 이미지 분류, 객체 탐지

3. 기타 분야에서의 임베딩 모델

(1) Doc2Vec
특징: Word2Vec을 확장해 문서나 문단 전체를 벡터로 표현
용도: 문서 분류, 추천 시스템

(2) Knowledge Graph Embedding (예: TransE, DistMult)
특징: 지식 그래프(엔티티와 관계)를 벡터 공간에 매핑
용도: 관계 추론, 질문 답변

(3) Universal Sentence Encoder (USE)
개발자: Google
특징: 다양한 언어와 작업에 활용 가능한 범용 문장 임베딩
용도: 텍스트 유사도, 다국어 처리

Blockiness, Block Noise, Artifacts(Artefacts)

bpDev — Thu, 2 Jan 2025 13:03:23 +0900

자동 합성 코드 작업하면서 블록 현상이 발생하여 이유를 찾아보는 중 .

JPEG 이미지의 복사, 합성, 재저장 과정에서 발생하는

블록 현상과 블록 노이즈는 주로 반복적인 압축과 해제 과정에서 누적되는 손실 때문.

이를 최소화하기 위해서는 비손실 압축 형식을 사용하거나,

압축률을 조절하고, 가능한 한 압축 단계를 줄이는 것이 중요함.

또한, 최신의 효율적인 압축 코덱을 활용하는 것도 좋은 방법.

https://en.wikipedia.org/wiki/JPEG

JPEG 압축 과정의 이해

JPEG 이미지 압축의 기본적인 과정
- 손실 압축 방식, 이미지 데이터를 압축하면서 일부 정보가 손실됨.

색 공간 변환(Color Space Conversion):
- RGB 색 공간에서 YCbCr 색 공간으로 변환하여 인간의 눈에 덜 민감한 색상 정보(Cb, Cr)를 효율적으로 압축함.
블록 분할(Block Splitting):
- 이미지를 8x8 픽셀 블록으로 나눔. 이 블록 단위 처리가 블록 현상의 주요 원인 중 하나.
이산 코사인 변환(Discrete Cosine Transform, DCT):
- 각 8x8 블록에 대해 DCT를 적용하여 주파수 성분으로 변환함. 저주파 성분은 중요한 정보를, 고주파 성분은 세부 정보를 나타냄.
양자화(Quantization):
- DCT 계수를 양자화하여 압축률을 높임. 이 과정에서 고주파 성분이 많이 손실되며, 이는 이미지의 선명도 저하와 블러(blur)를 유발할 수 있음.
인코딩(Encoding):
- 양자화된 DCT 계수를 효율적으로 저장하기 위해 허프만 코딩(Huffman Coding) 등을 사용.

이미지 합성과 재저장 시 발생하는 아티팩트

이미지를 복사하여 다른 이미지와 합성한 후 저장할 때 다음과 같은 과정이 반복됨

디코딩(Decoding):
- 기존 JPEG 이미지를 디코딩하여 압축을 해제하고 픽셀 데이터를 복원함.
합성(Compositing):
- 두 이미지를 결합하여 새로운 이미지를 생성함. 이 과정에서 새로운 픽셀 값 생성됨.
재인코딩(Re-encoding):
- 합성된 이미지를 다시 JPEG 형식으로 저장하기 위해 압축 과정을 거칩니다.

이러한 반복적인 압축과 해제가 여러 번 이루어지면 압축 손실 누적이 발생하게 됨. 특히 블록 현상(Blockiness)과 블록 노이즈(Block Noise)는 다음과 같은 이유로 두드러지게 나타납니다.

블록 현상(Blockiness)

원인:
- JPEG는 이미지를 8x8 블록으로 나누어 각 블록을 독립적으로 압축함. 이로 인해 블록 경계 부분에서 픽셀 값의 불연속성이 발생할 수 있음.
- 여러 번의 압축과 해제를 거치면서 각 블록 간의 일관성이 떨어지고, 블록 경계가 더 뚜렷하게 보이게 됨.
결과:
- 이미지 전체에 격자무늬 같은 블록 패턴이 나타나며, 특히 고압축률일수록 블록 경계가 더 뚜렷하게 보임.
- 자연스러운 이미지에서 벗어나 인공적인 패턴이 형성되어 시각적 품질이 저하됨.

블록 노이즈(Block Noise)

원인:
- 양자화 과정에서 고주파 성분이 손실되면서 각 블록 내에서 픽셀 값의 변동이 커질 수 있음.
- 반복적인 압축과 해제를 통해 이러한 변동이 누적되어 블록 내부에 무작위적인 노이즈 발생함.
결과:
- 각 블록 내에 작은 점이나 패턴 같은 노이즈가 나타나 이미지가 거칠게 보임.
- 세부 디테일이 손실되고, 이미지의 선명도와 부드러움이 감소함.

이미지 합성과 재저장 시 아티팩트* 발생 방지 방법

비손실 압축 사용:
- 가능하다면 PNG나 TIFF 같은 비손실 압축 형식을 사용하여 반복적인 압축으로 인한 손실을 방지.
압축률 조절:
- JPEG 저장 시 압축률을 낮게 설정하면 아티팩트 발생을 최소화 시킬 수 있음. 단, 파일 크기가 커질 수 있음.
최소한의 재압축:
- 가능한 한 한 번만 압축을 수행하고, 이후에는 원본 픽셀 데이터를 사용하는 방식으로 작업을 진행함.
고급 코덱 사용:
- JPEG2000이나 HEIF 같은 최신 코덱을 사용하면 더 효율적인 압축과 더 나은 화질을 유지할 수 있음.

아티팩트* : Digital image artifacts

Digital image artifacts are unintended imperfections or distortions in a digital image that are a result of the rendering process. They can be caused by a variety of factors, including:

Compression: Lossy compression can result in blocky patterns, loss of detail, banding, and aliasing.
Lighting conditions: Grainy speckles in low-light areas are a common artifact called noise.
Camera limitations: The gear used and camera limitations can also cause artifacts.
Image processing: Failures or a lack of robustness in image processing can create artifacts.
Gain calibration: If the acquisition parameters don't match those of a calibration, artifacts can appear.
Operating artifacts: These can occur when the user doesn't fully understand the digital image system.

Some common types of digital image artifacts include:

Chromatic aberration
Moiré patterns
Banding
Haloing
Aliasing
Screen-door effect
Ghosting
Screen burn-in
Distortion
Silk screen effect

To avoid artifacts, you can save an image in an uncompressed format, such as PSD or TIFF, if you plan to make a lot of changes to it.

주요 아티팩트의 종류

블록 현상(Blockiness)
- 설명: 이미지를 작은 블록 단위로 나누어 처리하는 압축 방식에서 발생. 각 블록의 경계가 뚜렷하게 드러나면서 전체 이미지에 격자무늬 같은 패턴이 나타남.
- 예시: JPEG 압축에서 낮은 품질 설정 시 이미지 전체에 블록이 보이는 현상.
블러(Blur)
- 설명: 이미지의 선명도가 떨어지고 경계가 흐려지는 현상. 이는 고주파 성분이 손실되면서 세부 디테일이 사라지기 때문에 발생.
- 예시: 사진을 지나치게 압축하면 인물의 윤곽이 흐릿하게 보일 수 있음.
링잉(Ringing)
- 설명: 강한 경계나 선 주변에 물결무늬 같은 흔적이 나타나는 현상. 주로 고주파 성분의 손실이나 부적절한 필터링으로 인해 발생.
- 예시: 텍스트나 선이 있는 이미지에서 글자 가장자리 주변에 흰색 또는 검은색의 띠가 생기는 것.
컨투어링(Contouring)
- 설명: 이미지의 색상이나 명암이 부드럽게 변하지 않고 계단식으로 변하는 현상. 이는 색상이나 밝기 단계를 너무 적게 사용했을 때 나타남.
- 예시: 그라데이션이 필요한 부분에서 색상이 급격하게 변해 계단처럼 보이는 것.

아티팩트의 원인

손실 압축(Lossy Compression): JPEG, MPEG 등과 같은 손실 압축 방식은 파일 크기를 줄이기 위해 원본 데이터의 일부를 제거함. 이 과정에서 시각적으로 눈에 띄는 왜곡이 발생할 수 있음.
고주파 성분 손실: 이미지의 세부 디테일을 담당하는 고주파 성분이 손실되면 블러나 링잉과 같은 아티팩트가 생길 수 있음.
부적절한 인코딩 파라미터: 압축률이 너무 높거나 낮은 설정은 다양한 아티팩트를 유발할 수 있음.

아티팩트의 영향

시각적 품질 저하: 사용자가 이미지를 보았을 때 자연스러움이 감소하고, 원본과 비교하여 품질이 낮아 보일 수 있음
분석 및 처리 오류: 컴퓨터 비전이나 이미지 분석 작업에서 아티팩트는 알고리즘의 정확도를 떨어뜨릴 수 있음.
사용자 경험 감소: 특히 사진이나 비디오 편집, 스트리밍 서비스 등에서 아티팩트는 사용자 만족도를 낮출 수 있음.

004 몇 개의 의상 조합이 가능한지 찾기

bpDev — Tue, 1 Oct 2024 23:58:25 +0900

Image generator 그림. 상업 삽화 많이 그려본 사람이 대충 그린 것 같은 느낌이고만.. 배경 인물들 얼굴 좀 무섭다

패션 마을의 옷장 마법사

옛날 옛적, 패션 마을이라는 곳에 아리라는 이름의 옷장 마법사가 살고 있었습니다. 아리는 마을 사람들에게 멋진 옷을 조합해주는 특별한 능력을 가지고 있었죠.

어느 날, 마을에 새로운 옷들이 도착했습니다. 아리는 이 옷들을 잘 정리하고, 마을 사람들에게 다양한 스타일을 제안하기로 마음먹었습니다. 옷들은 각각 종류가 있었는데, 예를 들어 "노란 모자"는 머리장식, "파란 선글라스"는 액세서리, "초록 터번"도 머리장식에 속했죠.

아리는 먼저 각 종류별로 옷의 개수를 세기 시작했습니다. 머리장식에는 노란 모자와 초록 터번, 액세서리에는 파란 선글라스가 있었습니다. 그러고 나서, 각 종류별로 하나를 선택하거나 선택하지 않는 경우의 수를 계산했습니다. 예를 들어, 머리장식은 2가지 선택지(노란 모자, 초록 터번)와 선택하지 않는 경우까지 포함하여 총 3가지 경우가 있었고, 액세서리는 1가지 선택지와 선택하지 않는 경우로 총 2가지 경우가 있었습니다.

아리는 모든 종류의 경우를 곱한 후, 아무것도 선택하지 않는 경우를 제외했습니다. 이를 통해 마을 사람들이 만들 수 있는 다양한 옷 조합의 수를 알아냈죠. 최종적으로, 아리는 마을 사람들에게 총 5가지의 멋진 옷 조합을 제안할 수 있게 되었습니다.

마을 사람들은 아리의 도움으로 매일매일 다른 스타일을 즐기며 행복하게 살았답니다.

- G

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

Hash map

def solution(clothes):
    # 1. Create a hash map to count each type of clothing
    hash_map = {}
    for clothes, type in clothes:
        hash_map[type] = hash_map.get(type, 0) + 1 
        # get(type, 0) : If the type doesn't exist, start count at 0

    # 2. Multiply the number of combinations for each clothing type
    answer = 1
    for type in hash_map:
        answer *= (hash_map[type] + 1)

    # 3. Subtract 1 to exclude the case where nothing is worn
    return answer - 1
    
print(solution([["yellow_hat", "headgear"], ["blue_sunglasses", "eyewear"], ["green_turban", "headgear"]]))

Counter와 reduce

from collections import Counter
from functools import reduce

def solution(clothes):
    # 1. Count each type of clothing
    counter = Counter([type for clothes, type in clothes])

    # 2. Multiply the combinations (including not wearing an item)
    answer = reduce(lambda x, y: x * (y + 1), counter.values(), 1)
    
    # 3. Subtract 1 to exclude the case of wearing nothing
    return answer - 1

print(solution([["yellow_hat", "headgear"], ["blue_sunglasses", "eyewear"], ["green_turban", "headgear"]]))

01234567

[슬라이드 이미지] AI쪼를 없애는 게 기술이 되지 싶다

003 소수 찾기

bpDev — Sun, 29 Sep 2024 11:36:17 +0900

Image generator 사용해서 뽑은 이미지. 숫자 아닌 거 섞여 있음. 요즘 GPT 내가 쓰는 말투에 맞춰 대꾸하는 게 재밌다.

문제 출처 : https://youtu.be/m3kCKV8oc1g?si=WTrr9omSekICyslD

한 자리 숫자가 적힌 종이 조각이 흩어져 있습니다.

흩어진 종이조각을 붙여 소수를 몇 개 만들 수 있는지 알아내려 합니다.

Loop 활용

1. 숫자 조합

2. 소수가 아닌 수 제거 : 에라토스테네스의 체 사용

3. permutation, map, set 등을 활용하여 손쉽게 확인

from itertools import permutations

def solution(numbers):
    prime_set = set()

    # 1. Make all possible number combinations from the given numbers 
    for i in range(len(numbers)):
        # print(list(numbers))
        numbers_permutation = permutations(list(numbers), i + 1)
        # print(list(numbers_permutation))
        # print(list(map("".join, numbers_permutation)))
        # print(list(map(int, map("".join, numbers_permutation))))
        numbers_perm_list = map(int, map("".join, numbers_permutation))
        prime_set |= set(numbers_perm_list)
    # print(prime_set)

    # 2. Check if the number is prime
    prime_set -= set(range(0, 2))
    lim = int(max(prime_set) ** 0.5) + 1
    for i in range(2, lim):
        prime_set -= set(range(i * 2, max(prime_set) + 1, i))
    return len(prime_set)

print(solution("17"))

☆ 에라토스테네스의 체 멋진 설명

https://www.algodale.com/algorithms/sieve-of-eratosthenes/

알고달레

알고리즘 입문자를 위한 달레의 친절한 안내서

www.algodale.com

재귀 활용

나갔다 와서 계속 ..

002 전화번호 목록

bpDev — Fri, 27 Sep 2024 02:39:41 +0900

기묘하다 기묘해 부조리한 ㅎㅎ DALL-E Image

전화번호에 적힌 전화번호 중,

한 번호가 다른 번호의 접두어인 경우가 있는지 확인해야 함

접두어이면 False, 아니면 True

전화번호부에 적힌 전화번호를 담은 배열phone_book이

solution 함수의 매개 변수로 주어질 때,

어떤 번호가 다른 번호의 접두어인 경우가 있으면 False를

그렇지 않으면 True를 return 하도록 solution 함수를 작성해 주세요.

: 왜 하필이면 전화번호 목록이지? 접두어가 있는지 확인할 일이 뭐가 있지..

비교할 첫 번째 전화번호를 선택하고,

비교할 두 번째 전화번호를 선택하고,

startswith 함수를 사용해 서로가 서로의 접두어인지 확인한다.

def solution(phone_book):
    # 1. Sort the phone book 
    for i in range(len(phone_book)):
        # 2. Compare the current phone number with the next phone number 
        for j in range(i + 1, len(phone_book)): 
            # 3. If the next phone number starts with the current phone number, return False
            if phone_book[i].startswith(phone_book[j]):
                return False
            if phone_book[j].startswith(phone_book[i]):
                return False
    return True
print(solution(["12", "213", "1232"]))

False

그런데 이렇게 짜면 시간이.. 초과된다!

번호가 많을 때는 .........

줄이는 방법은 Sort를 활용하는 것.

이중 루프를 한 번으로 줄이기만 해도 훨씬 줄어들고.

단방향으로만 확인하면서 서로 접두어인지 확인할 수 있다면 더 줄어든다.

def solution(phone_book):
    # 1. Sort the phone book
    phone_book.sort()
    # 2. Compare the current phone number with the next phone number 
    for i in range(len(phone_book) - 1):
        # 3. If the next phone number starts with the current phone number, return False 
        if phone_book[i] == phone_book[i + 1][:len(phone_book[i])]:
            return False
    return True
print(solution(["12", "2132", "1232"]))

False

zip을 사용해보자!

def solution(phone_book):
    # 1. Sort the phone book
    phone_book.sort()
    print(phone_book)
    print(phone_book[1:])
    print(list(zip(phone_book, phone_book[1:])))
    # 2. Compare the current phone number with the next phone number
    for p1, p2 in zip(phone_book, phone_book[1:]):
        # 3. If the next phone number starts with the current phone number, return False
        if p2.startswith(p1):
            return False
    return True
print(solution(["12", "2132", "1232"]))

['12', '1232', '2132']
['1232', '2132']
[('12', '1232'), ('1232', '2132')]
False

Hash

Key와 Value로 만들어 보자

Key = phone_number

Value = 1을 갖는 Hash map을 만들어 준다.

Key	Value
"12"	1
"6789"	1
"6"	1

각 번호의 접두어가 Hash map에 존재하는지 확인한다.

접두어를 찾아야 하기 때문에, 기존 전화번호의 일부를 Hash map에서 찾으면 된다.

def solution(phone_book):
    # 1. Make a hash map
    hash_map = {}
    for phone_number in phone_book:
        hash_map[phone_number] = 1

    # 2. Compare the current phone number with the next phone number
    for phone_number in phone_book:
        prefix = ""
        for number in phone_number:
            prefix += number
            if prefix in hash_map and prefix != phone_number:
                return False
    return True
print(solution(["12", "2132", "1232"]))

False