아키텍쳐 뜻

https://bcho.tistory.com/m/667


아키텍쳐란

컴퓨터를 구성하는 CPU, 메모리, 입출력장치의 기본이 되는 디지털 회로소자의 특성과 CPU 동작원리, 설계방법, 제어회로 및
마이크로 프로그램 등을 다루는 학문


폰 노이만 아키텍쳐(Stored program concept)
ex)
4 * 8 = 32 를 계산하고자 한다.
1. 컴퓨터는 4*8을 입력한다 (fetch)
2. 명령을 받은 컴퓨터는 해석한다 (decode)
3. 4와 8을 곱해서 32를 만들어 낸다. (execute)
4. 결과를 저장한다. (store)

> 데이터 메모리와 프로그램 메모리를 구분하지 않고, 하나의 버스를 갖는 구조
특징
- 프로세서에게 메모리 특정 지점부터 실행하도록 지시할 수 있다. 이 때 데이터와 명령어 사이에 뚜렷한 구분이 없어서 주어진 내용을 무조건 실행한다.
- 데이터 자체에 고유 의미가 없다. 즉, 이를 해석하는 프로그램에 의해 의미가 달라진다.
- 데이터와 명령어는 메모리를 공유한다. 특정 프로그램에서 명령어인 내용은 다른 프로그램에서 데이터일 수 있다.
> 폰 노이만 구조는 다른 작업을 시키려 할 때 굳이 H/W를 재배치할 필요 없이 S/W만 교체하면 된다.
범용성이 높다. 하지만 메모리 공유로 인해 고속 컴퓨터 설계에 문제 발생. Von-Neumann bottlenect
>파이프라이닝 기술을 구현하면 폰 노이만 구조는 문제가 된다.
> 파이프라이닝은 단순히 속도를 높이기 위해 fetch-decode-execute-store를 빨리 하는 것이 아니다


하버드 아키텍쳐
 프로그램과 데이터가 메모리에 저장되는 방식에서 프로그램과 데이터가 각기 다른 메모리에 저장되는 컴퓨터 구조.
 폰 노이만 구조는 파이프 라이닝을 구현하기 어렵다. 
 하버드 구조는 파이프 라이닝을 위해 구조를 변경한 것이다. 데이터 전용 메모리와 명령어 전용 메모리를 가졌다는 것이다. 
 하버드 구조를 쓰면 속도를 높일 수 있다. 하지만 비싸고 공간을 많이 차지한다. 
 폰 노이만 구조에서는 연산 결과를 명령어 위치에 쉽게 저장하지만 하버드는 메모리를 분리시켜 두기 때문에 구현하려면 복잡하다. (CPU 설계시에는 편하다)
특징
- 하바드 아키텍쳐 컴퓨터에서는 CPU는 메모리로부터 명령어와 데이터를 동시에 사용할 수 있다.
- 현재 명령을 마치는 것과 동시에 다음 명령을 가져올 수 있기 때문에 속도가 더 빠를 수 있다.

보통 아키텍쳐란 건축학을 의미한다고 한다.
컴퓨터 아키텍쳐(Computer architecture)의 경우 "
컴퓨터 구조(computer architecture)는 컴퓨터 공학에서 개념의 설계요, 컴퓨터 시스템의 근간이 되는 운영 구조이다. 컴퓨터의 여러 부분에 대해 설계적으로 이식되는 것들과 요구 사항들(특히 속도와 상호 연결)이 무엇인지 기능적으로 설명되어 있는 청사진이다. 주로 중앙 처리 장치 (CPU)가 메모리 주소에 내부적으로 수행하고 접근하는 방법이 집중적으로 설명된다.
하드웨어 부품을 골라서 상호적으로 연결하여 기능, 성능, 비용적인 목표를 충족하는 컴퓨터를 만들어 내는 과학과 기술로 정의될 수도 있다."라고 설명될수있다.
소프트웨어적 의미로는 "소프트웨어 구조(software architecture)는 소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙이다"
참 간단하다.ㅋㅋ
 
좀더 자세한 정의라면 "
Architecture(아키텍처)는 컴퓨터 시스템의 하드웨어 구조를 말합니다. 아키텍처는 컴퓨터 시스템을 구성하고 있는 하드웨어 장치인 CPU, 레지스터, 기억 장치, 입출력 장치 등과 같은 여러 가지 컴퓨터 구성 요소들에 대한 전반적인 기계적 구조와 이를 설계하는 방법입니다.
보통 규모에 관계없이 건물을 지을 때에는 우선적으로 시공에 앞서 대략적인 조감도를 작성한 후 전체적인 구조와 설계도를 먼저 작성합니다. 정보 시스템도 이와 비교될 수 있습니다. 이미 금융, 통신 같은 부분은 말할 것도 없이 거의 전 부문에 걸쳐 정보시스템은 점차 필수적인 요소라고 할 수 있습니다. 이러한 정보시스템은 중소기업에서 사용되는 시스템일지라도 건물에 못지않은 복잡성을 가지고 있습니다. 더군다나 이에 부가되어 웹과 인터넷의 발전에 따른 여러 가지 문제, 보안의 문제, 소비자의 코드에 맞추어야하는 화면 디자인의 문제 등을 해결하면서 동시에 과거의 시스템과의 연동을 고려해야만 하는 골치 아픈 문제들이 소프트웨어 개발자들을 괴롭히고 있습니다.

복잡성에 더해 과거와는 달리 어떤 소프트를 써서 어떤 방식으로 시스템을 만드는 가에 대해서도 다양한 선택의 문제도 있습니다. 이러한 문제를 해결하고자 하는 노력이 바로 아키텍처입니다. 아키텍처란 소프트웨어 개발자들이 어쩔 수 없이 작성해야만 하는 전체시스템의 밑그림을 말합니다. 아키텍처는 선택이 아니라 시스템의 개발에 있어 필연적으로 작성해야만 합니다. 설계도 없는 건물은 있을 수 없습니다. 만일 있다고 가정하더라도 당연히 안정성을 보장할 수 없고 그 가치 또한 매우 낮아질 것입니다. 제대로 된 상•하수도 지도를 가지지 못해 매년 가스관, 송수관 파열등의 사고를 반복하고 세금을 낭비하는 수도공사의 경우가 그 예가 될 것입니다.
메인 프레임의 시대로서 아키텍쳐의 중요한 부분은 하드나 OS 등의 플랫폼에 구축되고 있고 그 위에 어플리케이션을 구현하면 솔루션이라고 할 수 있습니다. 하지만 이제는 오픈시대가 되어 플랫폼도 선택사항이 증가하여 C/S로 어떤 기능 분할을 해야 할 것인가라든지 때때로 하드나 소프트의 특성에 맞추어 설계의 최적화를 생각할 사람이 필요하게 되었습니다.

아키텍쳐는 소프트웨어의 환경이 변화되고 있는 것을 감지해야 합니다. 그것은 비즈니스의 신속성(business velocity)를 증가시킵니다. ‘기업이 올바른 방향을 설정하는 한편, 그 운영 속도를 가속화 할 수 있는 능력’ 그것을 빠르게 표현하는 것입니다. 90년대의 소프트웨어의 화두는 ‘얼마나 빠르게 소프트웨어를 구축하는가?’ 라는 것이 최고의 목표였습니다, 그러나 21세기의 화두는 ‘올바른 방향을 유지하는 동시에 신속하고 품질을 보장할 수 있는 소프트웨어를 만들 것인가?’ 입니다.
90년대의 소프트웨어는 ‘목표’만 정확하면 그 품질을 개량화하기 수월한 소프트웨어들이 대다수였습니다. 일반 패키지들이 그러했고, 일반 업무들도 단위업무 중심이었기 때문입니다. 이제 21세기 소프트웨어는 수많은 프레임워크와 수많은 업무들이 연관관계를 가지는 구조이기에 그 품질목표마저도 모호한 상태이거나 계량화하기 힘들어진 상태입니다. 그러하기 때문에 아키텍쳐는 Service중심의 소프트웨어를 구상하여야 합니다. 최근 인터넷의 급속한 진화와 함께 이슈가 되고 있는 웹2.0 기술의 근간은 사용자 참여형 아키텍쳐라 할 수 있습니다." 이정도 되시겠다.