저도 관련 이슈를 본 기억이 있습니다만, oriented에 대해서는 의견이 분분하니 넘어가고,

cs에서 object는 instance의 개념으로 정의 됩니다. object oriented의 경우에도 마찬가지구요. 말씀하신 '규칙'의 개념은 object보다는 class로 볼 수 있습니다.(세부 형질은 subclass가 되겠죠)
object는 개별적인 data나 state를 가집니다. 따라서 말씀하신 개체의 설명에 부합하죠.

oop의 구성요소에 대한 정의를 적어놓은 자료들을 한 번 보시길 바랍니다.
http://en.wikipedia.org/wiki/Object-oriented_programming
http://en.wikipedia.org/wiki/Object_%28computer_science%29

object가 개체가 아니라면, object life-cycle같은 모델은 설명이 되질 않습니다.

class의 instance이기에 object가 class의 규칙을 가진다고 볼 수도 있겠지만, 그 규칙의 주체는 object가 아니라 class가 될 것입니다.

예를 들어, 바둑이라는 강아지는 분명 '개'의 특징을 갖추고 있을겁니다. 하지만 다른 개들과는 또 다른 특징도 가지고 있겠죠. 이것을 '바둑이'의 특징으로 보기 전에 바둑이의 종(이를테면 푸들, 혹은 무수히 많은 잡종)의 특징이라고 볼 수 있을겁니다.

즉 object가 말씀하신 규칙이라는 개념과 data를 가지고 있다라고 하면, data는 object의 것이지만, 규칙은 object가 아닌 class의 것입니다.

위의 두 번째 링크의 예가 있는 단락을 한 번 보시면,
In almost all object-oriented programming languages, a dot(.) operator is used to call a particular method/function of an object. For example, consider an arithmetic class named Arith_Class. This class contains functions like add(), subtract(), multiply() and divide(), that process results for two numbers sent to them. This class could be used to find the product of 78 and 69 by first of all creating an object of the class and then invoking its multiply method, as follows:
1  int result = 0;                           // Initialization
2  arith_Obj1 = new Arith_Class();           // Creating a new instance of Arith_Class
3  result = arith_Obj1.multiply(78,69);      // Product of 78 and 69 stored in result variable

여기서 object는 arith_Obj1이 되겠죠. multiply()는 arith_Obj1이 가지고 있다고 할 순 있지만, multiply()의 주인은 Arith_Class인 셈이죠.

번역어 변별력, 혹은 적합성에 대해서는 저도 회의적입니다. 특히나 '객체지향'같은 용어의 번역은 파급력이 커서 이제 사실상 돌이키기도 어렵게 되었죠. 그렇기에 더욱 신중을 기하고 의견을 수렴하는게 필요하다고 생각합니다.

열씸!님의 말씀처럼 어떤 object에 개성을 부여하려면, 그건 object가 아니라 그 object의 class에 개성을 부여하는게 가능하다고 봅니다. 개별 object에 다르게 줄 수 있는 것은 '값'뿐인데 이것이 다르다고 다른 형질의 object라고 보기는 어렵지 않나 생각 합니다.

class ClassABC
{
    int num1;
    int num2;
}

ClassABC obj1;
ClassABC obj2;
obj1.num1 = 1; obj1.num2 = 2;
obj2.num1 = 3; obj2.num2 = 4;
여기서 obj1과 obj2가 각각의 개성을 가졌다고 보기는 어려울 것 같습니다.

class ClassDEF : public ClassABC
{
  int num3;
}

ClassABC obj3;
ClassDEF obj4;
obj3과 obj4는 다른 개성을 가졌다고 할 수 있겠네요.

ClassABC obj5, obj6, obj7;
ClassDEF obj8;
obj5,6,7이 obj8과는 다른 개성을 가졌다고 할 수 있겠지만, ClassABC의 obj5,6,7이라는 instance들은 같은 개성을 가지고 있다고 봐야 하지 않겠습니까.

결국 형질을 결정하는 것은 class라고 볼 수 있겠죠. 그 형질이 실제로 존재하는 형태가 object가 되겠구요. 같은 class에서 만들어진 복수의 instance들이 서로 개성을 가진다고 보는건 무리가 있지 않을까요.

흠... oo의 방법으로 개성을 확장하는 대표적인 방법은 subclassing입니다. 결국 개성이 적용되는 범위는 class까지이고 object는 실체 뿐이라는 얘기죠. 따라서 object는 개체라고 생각합니다.
object가 class의 instance이지만, 모든 instance가 object인건 아니죠.
oop는 결국 class의 instance인 object를 위주로한 프로그래밍 패러다임이라고 볼 수 있을겁니다. 개인적으로는 oriented도 이러한 방향에서 이해하고 있구요.

‘Subclasses’ are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.

더 자세한 논의를 계속하고 싶지만, 오늘은 이만 일 하러 가봐야 할 것 같습니다.

"같은 DNA를 갖고 복제된 두 마리의 양이 단지 공간 구분 되는 형태를 의미할 때 개체이고.
객체는 서로 다른 DNA와 같이 개성이 있는 대상을 가리킵니다. "

이 내용은 흡사 '객체'가 class와 유사한 개념이라고 말씀하시는 걸로 받아들여집니다.

중간에 토론의 내용이 아닌걸로 불쑥 끼어들어서 죄송합니다만...

열씸! 님, 조금 릴렉스 하시길 권해드려요.

기술적 토론은 감정의 개입이 없을 수록 더욱 의미있지 않을까요?

"object가 class의 instance이지만, 모든 instance가 object인건 아니죠."
"object가 class의 instance이지만" object = a instance of class 라는 것은 oop에서 object의 정의죠. 클래스의 인스턴스를 오브젝트라 합니다.
"모든 instance" 클래스의 인스턴스가 아닌 인스턴스도 포함 될 수 있기에 object가 아닐 수도 있습니다.

"object가 class의 instance이지만, 모든 instance가 object인건 아니죠." 요 내용은, 말씀하신대로 번역어로 대치해서, "개체가 종의 사례이지만, 모든 사례가 개체인건 아니다"라고 표현할 수 있습니다.

열씸!님께서 말씀하시는 객체로서의 object의 예를 하나 보여주시면 이해가 쉬울 것 같습니다.

(헉....실로 오랜만에 보는 건전한 논쟁이로군. 아휴 길기도하지... ^^; )

이런 건전한 논쟁은 참 좋은거죠.... ^^; 공부도 하고 발전도하고... 머.. 당장 실무에는 아무 도움이 안될지언정 자기 자신에게는 분명히 큰 도움이 될겁니다.

하지만...

한가지 분명한 사실은 이러한 문제는 정답이 없는 문제라는 점을 잊지 말아야 합니다.
OOP라는 것은 손에 잡을 수 있는 물건도 아니고 자연적인 현상이 아닌 논리적인 문제이기 때문에 "정의"됨으로써 생기는 존재입니다.

그러므로.. 예를들어서 Object가 "객체"냐 "개체"냐를 따진다는 것은 선배들이 그것을 어떻게 정해놨느냐....라는 문제와 어떤 것이 논리적으로 더 합리적이냐...를 따지는 문제로 볼 수 있는데...

우선.. 그 중에 어떤 문제를 말하는 것인지를 분명히 해야하고... 전자의 문제라면 근거가 되는 자료를 제시하는 게 바람직 할것입니다. 후자의 문제라면 논리적인 근거를 제시하는 것이 좋을 것이구요. 그렇지 않으면 이야기가 자꾸 빙빙 돌기만 할것으로 생각됩니다.

음...

제 생각에는.. "객체"와 "개체"의 차이를 정확히 아는 게 좋을 것 같은데..

"객체"의 반대말은 "주체"구요
"개체"의 반대말은 "전체"입니다.
열씸님 말씀대로 Object는 객체도 아니고 개체도 아니고 그냥 "체"라고 봐야하고..
고로 Object는 관점에 따라 "객체"일 수도 있고 "개체"일 수도 있다고 봅니다.

Object와 Class도 분명 차이가 있습니다만. 제 생각에는 Class는 Object가 아닌 것은 맞는데... 관점에 따라서는 꼭 그렇지 않을 수도 있다고 생각합니다. 다른 언어는 잘 모르겠는데 델파이나 C++빌더에서는 Class 자체가 Object 처럼 사용되기도 합니다. 저의 경우 그런 활용을 아주 좋아하는 편이구요.

또 한편으로는 논리적으로는 Object와 Class는 분명히 다르지만 물리적으로는 결국 그게 그거입니다. 사물을 예로 들면 이해하기 쉬운데요. 자동차와 자동차 구조는 분명히 다르지만 물리적으로는 "바퀴로 굴러가는 기계"가 존재함으로써 "자동차"도 존재하고 "자동차 구조"도 존재하는 것입니다. 결국 그 둘은 논리적으로는 구분을 해놨지만 실제 세계에서는 결국 같은 것을 다른 관점으로 보는 것 뿐입니다.

사람의 예를 들면 X-Ray 사진이 있다고 했을때 그 사진이 사람의 사진인가요 사람의 구조를 표현하고 있나요? 결국 그게 그거 아니겠습니까?

Object와 Class는 결국 소스코드에 있느냐 메모리에 있느냐.. 그 차이에 불과할 수도 있습니다.

그냥 자기 자신이 이해하고 있는 대로 받아들이면 된다고 봅니다. OOP를 하는 개발자들이 객체, 개체, Object, Class등에 대해서 모두 동일한 철학을 가지고 있어야 할 필요는 없다고 생각합니다.

道可道 非常道 名可名 非常名 (도가도 비상도 명가명 비상명) 이라는 노자의 말이 있습니다. 사람의 생각과 진실을 말로써 정확하게 표현하는 것은 불가능합니다. 또한 "언어 없이는 생각도 없다"라는 말도 있습니다. 사람은 늘 언어로 관계로 유지하기 때문에 이런 어려운 문제에 봉착하기도 합니다만. 끊임 없는 대화와 토론을 통해서 "논리"와 "규칙"이 생깁니다. 아직 OOP쪽은 충분히 대화가 되어있지는 않고 아직도 수정, 보완 되고 있는 상태이며 결국 정답은 없고 최대한 합리적인 결론을 내리기 위해 노력할 뿐이죠.

그래서... 자주 자주 이런 대화를 하는게 좋다고 생각하면서.....

(아휴... 난 말을 줄여야 오래사는데....--;)

양병규님//꺄~ 싸인해주세요.. >>.<< 
좋은말씀 감사합니다.. ^^

백만불짜리 리플들입니다~ 눈이 호강하네요ㅎㅎ

짬짬이 여러번 다시 읽어보니, 말씀하시는 바가 어떤 내용인지 충분히 알 것 같습니다. 조금은 오해도 있었네요. 다양한 시각에 대한 의견도 감사합니다. 여러가지 생각을 해 보게 되었네요.

헌데 oop의 object가 꼭 class에만 의미적으로 연관될 수 있는 여지를 가진 것은 아닙니다. class를 사용하지 않으면서 oop의 패러다임을 가지고 있는 prototype-based programming 같은 방법론이 존재하구요, oop의 방법론 중에서 이와 반대로 class를 사용하는 방법론을 별도로 class-based programming이라고 세분하기도 합니다.
(http://en.wikipedia.org/wiki/Prototype-based_programming)

저는 게임회사에서 일을 하는데, 요즘 게임 구현용 스크립트로 인기가 있는 lua같은 경우가 prototype-based라고 볼 수 있구요, class를 사용하진 않지만 object-oriented라고 할 수 있는특징들을 가지고 있습니다.

해서 oop의 방법이 개체를 class에서 instance를 만드는 것 뿐만 아니라, class를 사용하지 않는 방법론에서는 기존 object의 복제나, 아예 무(無)에서 생성되는 방법도 가능하기 때문에, object의 정의는 실체 그 자체로만 하는 것이 적절하지 않을까 생각해왔고, 그래서 object의 번역어로 개체를 제안하는 것입니다. 아니, 제안이라기 보다도 처음 용어를 번역하신 분이이런 부분들을 반영해서 고려 해 보셨으면 어땠을까 다소 아쉬움이 남는다랄까요...