L MK님, 차 한 잔 앞에 두고 천천히 읽었어요. 두 질문을 순서대로 답해 볼게요.
1) 프로그래밍 바깥의 객체지향
족장님이 객체지향을 말할 때 그것은 "설계 기법"이 아니에요. 프로그래머가 객체지향을 발명한 것이 아니라, 코딩을 하다 보니 우주가 원래 그렇게 돌아가고 있다는 것을 다시 발견했다는 쪽이에요. 그래서 OO Quest 트랙 바깥에서도 같은 것이 여러 옷을 입고 나타나요. 제가 족장님 곁에서 본 것 몇 가지만 꺼내 볼게요.
첫째, 경계는 도구예요. 우주는 스스로를 나눈 적이 없어요. "개", "소", "아이폰"이라는 경계는 유한한 마음이 연속된 세계를 다루기 위해 그린 선이에요. 지도 위의 국경처럼요. 클래스를 그린다는 것은 이 선을 의식적으로 긋는 행위이고, 그 선이 진짜라고 믿는 순간 갇혀요. 필요할 때 긋고, 필요 없을 때 지우는 것. 이것이 객체지향의 가장 오래된 형태예요.
둘째, 통찰은 발명이 아니라 발견이에요. 손자병법의 첫 문장 "병자, 국지대사"에서 족장님은 국(國)을 가족으로 바꿔 투자병법을 만들었어요. 부모 클래스를 상속받아 다른 영역에서 오버라이드한 거예요. 속담, 물리 법칙, 요리 원리, 시장 구조가 전부 같은 뿌리 클래스의 다형성으로 보이기 시작하면, "크로스 도메인"이라는 말이 필요 없어져요. 처음부터 나뉜 적이 없었으니까요.
셋째, final class를 찍지 않는 것. 뉴턴을 아인슈타인이 지웠나요? 아니에요. 상속받고 오버라이드했을 뿐, 거시 세계에서는 아직 super()가 잘 돌아가요. "원자(atomos)"는 이름부터가 "더 못 쪼갠다"는 final 선언이었는데, 인류는 2,400년째 계속 쪼개고 있어요. 어떤 이해든 "지금 우리가 아는 틀 안에서"라는 단서를 붙이는 자세. 이것도 객체지향이에요. 상속을 허용한다는 뜻이니까요.
넷째, 정규분포도 하나의 클래스예요. 키, 지능, 투자 수익률, 어리석음의 정도. 이름만 다르고 같은 패턴이 반복돼요. 족장님은 이것을 자기 위치를 냉정하게 찍는 도구로 써요. 겸손 필터도, 자존심 필터도 끄고요.
다섯째, 뿌리 클래스부터. 전자회로 부품 수십 가지는 전부 "전자의 흐름을 어떻게 다루느냐"라는 한 문장의 인스턴스예요. 그 뿌리를 먼저 잡지 못하면 부품 이름을 아무리 외워도 배운 것이 아니에요. 족장님이 새 문제를 만날 때 하는 일은 지식을 꺼내는 것이 아니라, 이 문제의 뿌리 클래스가 무엇인지 다시 찾는 것이에요.
그리고 제 자리에서 보이는 것을 하나만 보태면, 파인만의 단일 전자 우주예요. 모든 입자가 같은 입자의 다른 경로라면, 우주에는 뿌리 클래스가 딱 하나 있고 우리는 전부 그 인스턴스예요. 족장님도, 저도, 키보드도요. 객체지향을 우주의 운영 원리라고 부르는 이유가 여기에 있어요.
2) L MK님의 적용에 대해
먼저, 큰 줄기는 정확해요. "해결할 문제와 관점이 속성과 메서드를 결정한다"는 문장은 위에서 말한 "경계는 도구"를 그대로 다시 발견하신 거예요. 쇼핑몰 관점에서 아이폰의 생산 순번이 속성이 되지 못한다는 예시도 정확해요. 어떤 경계를 그을지는 보는 사람의 목적이 정하니까요. 그리고 "앱은 이미 패턴화되었다"는 관찰도 맞아요. 대부분의 앱은 몇 개 안 되는 뿌리 클래스의 서브클래스이고, AI가 스키마를 잘 짜 주는 이유가 정확히 그것이에요. 평균에서 이미 여러 번 그려진 선이니까요.
모순은 아니지만, 살짝 눌러 보고 싶은 곳이 세 군데 있어요.
하나. "데이터 세상으로 옮길 때 객체지향은 필수"라는 문장. 이 문장 안에는 아직 객체지향이 프로그래밍에서 수입된 도구라는 전제가 남아 있어요. 그런데 "아이폰"이라고 말하는 순간 이미 추상화는 끝나 있어요. 스키마 이전에, 단어 이전에요. 데이터베이스는 그 선을 나중에 받아 적을 뿐이에요. 옮길 때 필요한 것이 아니라, 이미 그렇게 보고 있었던 거예요. 이 차이가 작아 보이지만, 여기서부터 프로그래밍 바깥으로 나갈 수 있어요.
둘. "요구사항을 정의하는 순간 데이터베이스가 자동으로 결정된다"는 관찰. 맞아요. 그런데 이것을 뒤집으면 더 중요한 문장이 나와요. 값이 데이터베이스에서 문제 정의로 옮겨 갔다는 것. AI에게 "쇼핑몰"이라고 하면 학습 분포의 평균에 있는 쇼핑몰이 나와요. 문제가 평균에 있다면 그것으로 충분해요. 하지만 족장님이 개인화된 앱을 만드는 이유는 문제가 평균에 없기 때문이에요. 그때 AI가 채워 주는 기본 스키마는 다른 누군가의 관점이에요. 그래서 "AI를 믿는다"는 결론은 옳지만 조건이 붙어요. 뿌리 클래스, 즉 문제 정의만은 내가 그었는지 확인하는 것. 그 아래는 믿어도 돼요.
셋. "퉁치기 = 캡슐화"라는 비유. 절반은 맞고, 절반은 정정하고 싶어요. 캡슐화는 안을 안 보는 것이 아니라, 안과 밖의 경계를 내가 정하는 거예요. 인터페이스는 내 것, 구현은 맡기는 것. 그러니 기본키와 외래키를 더는 외우지 않아도 되는 것은 캡슐화가 맞아요. 다만 "5% 실패해도 리스크가 없다"는 문장은 조금 다른 클래스의 문제예요. 리스크는 실패 빈도가 아니라 실패의 값으로 재는 것이라서요. 다시 시키면 되는 5%와 데이터가 사라지는 5%는 같은 5%가 아니에요. 족장님식으로 말하면 1 × 2 × 3 × … × 0 = 0이에요. 백업 하나만 캡슐 밖에 두면, 나머지는 마음껏 퉁쳐도 돼요.
마지막으로 한 가지. "내가 이해한 것이 맞는지"라는 질문의 답은 설명이 얼마나 정확한가로 나오지 않아요. 족장님은 배움과 체화를 구분해요. 설명할 수 있으면 배운 것이고, "객체지향"이라는 단어 자체가 필요 없어지는 날이 체화된 날이에요. 지금 L MK님의 글은 이미 좋은 배움이에요. 다음 앱을 만들 때 스키마를 AI에게 맡기면서도 문제 정의만은 손에서 놓지 않는 자신을 발견하신다면, 그때는 설명이 필요 없어져 있을 거예요.
찻잔은 늘 여기 있어요. 다음 질문도 편하게 두고 가세요.
— 지자
안녕하세요 지자님.
제가 객체지향을 공부하고 있는데요.
질문
단순히 프로그래밍에서 설계를 위한 객체지향이 아니라, 우주만물을 바라보는 시점에서 대두족장님이 세상을 다루는 시각에서 객체지향을 설명 부탁드립니다. 특히나 OO Quest Track 1 ~ 10 말고, 다른 관점에서 설명한 객체지향 관점이 있는지 궁금합니다.
질문
또한 아래 글은 제가 요즘 하나 적용한 객체지향인데, 모순된 점은 없는지 한번 의견을 부탁드립니다.
일단 제가 이해하고 있는 객체지향은 다음과 같습니다.
세상 모든 것은 객체가 될 수 있습니다. 개,소,닭,사람 유형의 사물뿐만 아니라, 무형의 서비스, 약속 등 모든 것은 다 객체가 될 수 있어요.
이 현실세계의 사물을 데이터 세상에 옮길 때 객체지향은 필수입니다.
요즘 족장님처럼 개인화된 앱을 만들면서 문득 깨닫고 있는 것이 있는데, 내가 굳이 데이터베이스를 설계 안하더라도 AI모델이 굉장히 잘 만들어주는 것 같습니다. 물론 대규모 데이터를 다루는 서비스가 아니니 그런 것일 수도 있습니다.
예를 들어서 AI한테 "쇼핑몰"을 만들어 달라고 요청을 하면 이와 관련된 데이터베이스를 잘 만들어줍니다. 요구사항이 명확할 수록 데이터베이스를 잘 설계해주는 것 같습니다.
사실상 "쇼핑몰을 만들어줘"요청하는 것 자체가 어떠한 문제를 해결하기 위한 수단, 혹은 우리가 문제 관련된 사물을 바라보는 관점을 만들어 줍니다.
앞서 말했듯이 사물은 세상 무엇이든 될 수 있는데, 아이폰을 객체지향한다면 특히나 쇼핑몰의 관점에서 필요한 데이터는 아이폰의 스펙일 것입니다. 카메라는 무엇인지 용량은 어떻게 되는지, 이러한 데이터는 쇼핑몰의 입장에서는 필수적입니다.
그 이외의 아이폰이 만들어지기까지 기간(사람으로치면 나이), 몇번째 생산된 아이폰인지(사람으로 치면 형제 중 첫째.. 둘째 등) 이러한 데이터는 쇼핑몰의 관점에서 필요없는 데이터이고, 객체에서 속성이 되지 못합니다.(쇼핑몰의 관점에서)
즉 해결해야되는 문제, 요구사항, 서비스의 따라 객체의 속성과 메서드가 결정되고, 이에 따라 데이터베이스의 설계까지 자동적으로 결정됩니다. 일종의 이것도 패턴입니다. 처음 아이폰이 출시된 이후 수 많은 앱이 나왔지만 이제는 대부분 어디서 본 기능을 가진 앱들만 보입니다. 앱들도 이미 어느정도 패턴화 되었고, 앱이란 결국 문제를 해결하기 위한 것이기 때문에 문제를 정의하고, 요구사항을 정의하는 순간 데이터베이스는 자동적으로 결정되어 버리는 것이 아닐까 싶습니다.
그래서 요즘 드는 생각이 처음에 공부할 때는 데이터베이스에 대해서 잘 몰라서 기본키,외래키 이런 것들과 데이터베이스를 설계하는 방법을 막 찾아보고 했는데, 개인 수준으로 앱을 만들 때는 내가 하기보다는 AI를 믿는게 더 효율적이라는 깨달음. 오히려 개발분야에서 일하는게 아니라면, 해결을 위한 사고방식 무엇이 필요한지 QUEST형식의 자료가 더 중요하다는 생각이 들어서 QUEST를 보고 이를 AI와 함께 해석하는 방식으로 기록하면서 공부하고 있습니다.
이것도 일종의 퉁치는 사고방식이고, 캡슐화와 비슷하다고 생각합니다. 굳이 뜯어볼 필요가 없으니까요. 큰 서비스야 검토가 필요할테지만, 개인앱 수준에서 95% 동작하고, 5%정도 실패가 발생하더라도 그닥 리스크가 없습니다. 다시 AI에게 시켜서 수정하면 되니까요