Backward Compatibility

호환성 (Compatibility) 이라는 말을 들어보셨나요?

  • .NET 3.0 버젼 Framework에서 .NET 2.0으로 구현했던 Application이 돌아가지 않는다면?
  • JDK 1.6버젼에서 JDK 1.4 Framework 기반의 Application이 돌아가지 않는다면?

새로 나온 제품이 아무리 좋은 기능이 많이 추가 되어 있더라도..예전 제품과 호환이 되지 않는다면, 그 제품은 잘 팔리지 않을 겁니다.  이번 POST 를 통해 우리가 Product 또는 Framework을 만들때 고려해야 되는 호환성과 여러가지 종류에 대해서 공유하고자 합니다.

 

 

Cross-Version Compatibility

동일한 제품의 다른 버젼에서 만들어진 코드가 호환성을 가지는 지를 언급하는 말로, 예를 든다면 Microsoft SQL 2000에 사용했던 SQL 스크립트가 2005에서도 잘 돌아가는 예를 말하는 것입니다

 

Backward Compatibilty 와 Forward Compatbility

하위 호환성 – 하위 제품의 소스,포멧등이 최신 제품과 호환 될때이며, 상위 호환성 – 상위 제품의 소스, 포멧등이 하위 제품과 호환될때를 말합니다.

많은 제품들이 하위 호환성은 잘 지원합니다. 예를 든다면 Microsoft Office 2007에서 Microsoft Office 2003이 만든 포멧들과는 잘 호환이 된다고 볼수 있습니다.

하지만 골치 아픈 문제는 상위 호환성인데, Microsoft Office 2007에서 만든 Word , PowerPoint 파일들이 2003에서도 사용할수 있을까요?

아시다시피 두 제품은 완전히 다른 파일 포멧을 가지고 있어서, 2003을 위한 별도의 변환 툴을 제공하여 상위 호환성을 제공할려고 합니다.

단순히 읽기만 되지 편집이 되지 않기 때문에, 완벽한 상위 호환성을 갖추었다고 볼수는 없습니다.

하지만 이 이면에는 또 설계자들이 고려해야 하는 골치 아픈 문제들이 숨겨져 있습니다.

 

Cross-Redist Compatibiltiy

서로 다른 제품에서 만들어진 코드가 잘 호환이 되는지.

예) Oracle에서 사용한 Query가 Microsoft SQL에서도 잘 호환이 되는지?

Turbo C에서 동작하던 코드가 Visual C++ 에서도 잘 동작하는지?

 

Binary Compatibilty

예전버젼에서 만들어진 바이너리 파일이 새 버젼에서도 재 컴파일 없이 잘 호환이 되는지.

 

Source Compatibilty

서로 다른 버젼이지만 변경없이 소스코드 컴파일이 잘 되는지

 

API Compatibility

서로 다른 버젼의 API간에 호환성을 제공하는 말로,호환성의 레벨이 Source Compatiblity보단 더 크고, Binary Compatibility 보다는 약한 경우인데요.

Source Compatbility는 입력 파라메터나 리턴값에 공변형 (Covariant) Type을 사용할수 있지만, API는 그러지 못합니다.

 

호환성을 버리는 경우..

  • 정책적으로 호환성을 버리는 경우도 있습니다.

혹시 이런말은 들어보신적 있나요?  Java의 적은 .NET이 아니라. 예전 Java 이다. 

이말의 의미는 JDK 1.4에서도 동작하는 코드가 JDK 1.6 코드에서도 잘 동작하기 때문에, 굳이 개발자가 JDK 1.6을 사용하지 않는 다는 말입니다. 

JDK 1.6에 아주 좋은 기능을 넣어 놓아도, 굳이 예전 함수들을 이용해도 잘 돌아가는데 굳이 새로운 기능을 이용할 필요가 있냐? 라는 애기이지요.

물론 .NET 2.0과 .NET 3.0 Framework에서도 동일한 문제가 발생합니다.

이것은 새로운 기능을 넣은 Framework 설계자들에게는 상당히 골치 아픈 문제입니다. 훨씬 뛰어난 기능을 추가했음에도 불구하고 하위호환성으로 인해 예전 기능을 그대로 사용하기 때문이지요. 이럴땐 최악의 경우 어쩔수 없이 예전 기능을 포기하기도 합니다.

 

  • 전혀 새로운 패러다임의 등장으로 인해 내부를 다 뜯어 고쳐야 하는 경우를 위해.

이 경우는 아마 VS 6.0과 .NET의 관계이지 않을까 쉽습니다.

Web과 Web Service 라는 새로운 패러다임의 득세로 인해 과감히 VS 6.0 스타일을 버리고 새로운 .NET 을 내놓은 경우입니다.

 

또 PS3와 같이 가격적인 문제로 PS2와 호환이 안되는 제품을 출시한 예와 같이 다양한 이유가 존재할수도 있습니다.  혹시 어쩔수 없이 호환성을 포기할 수 밖에 없었던 다른 이유가 있으신 분은 같이 공유해 주시길 바랍니다.

그 이외에도 호환성에 대한 다양한 이야기가 있으면 POSTing 해주시고 트랙백을 부탁드립니다.

 

 

Join the conversation! 4 Comments

  1. >> Digital Angel Master님

    허걱 제가 url 포워딩을 하다 보니 ^^; 죄송합니다.
    이 글을 포스트 주소는

    https://arload.wordpress.com/2008/05/26/compatibility/

    입니다. ^^

    wordpress는 trackback을 외부로 명시적으로 지원하지 않는거 같네요 ^^;;; 좋은 글 주셔서 감사합니다.

    응답
  2. 바이너리 레벨의 호환성은 모르겠지만, 소스레벨의 호환성을 깨는 것은, 어떻게 보면 프레임워크 개발자의 용기라고 생각합니다.

    프레임워크 개발자가 소스레벨의 호환성을 지키지 않는다는 것은 결국 자신이 설계한 인터페이스를 재설계했다는 것을 의미하는데, 이는 프레임워크 개발자 스스로 자신의 지난 설계에 오류가 있었다는 것을 인정하는 것이겠지요. (이유가 무엇이든지, 현재 상황에 예전의 인터페이스는 맞지 않으니까요…)

    어떠한 다른 것도 고려하지 않고, 개발만을 생각했을 때, 인터페이스 변경은 매우 용감한(?) 일이라고 생각합니다. 수 많은 개발자에게 욕을 먹으면서도, 어쩌면 자신의 새로운 인터페이스를 강조하는 것이니까요. 그것은 그만큼 자신의 새로운 설계에 확신이 없으면 할 수 없는 일이라고 생각합니다.

    님 블로그 잘 보고 갑니다 ^^

    응답
  3. >> 석환님

    좋은 말씀 감사합니다.

    말씀해주신 것 처럼, 더욱더 혁신적인 것을 잘 수용하기위해서 어쩔수 없이 호환성을 깰수 밖에 없는 경우가 있다는 점 감사합니다.

    자주 방문해 주시고, 역시 석환님의 블로그도 가르켜 주세요 ^^ 그럼 좋은 하루 되세요

    응답

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

카테고리

Articles, My Thinking, Software Engineering

태그