뚝딱뚝딱

유튜브 '삼평동 연구소'의 영상을 보고 인터페이스의 개념을 조금이나마 이해할 수 있었다.

https://youtu.be/a6F7rIKaxzo 

인터페이스가 뭔지는 아는데, 설명해보라고 하면 애매한 개념..
그래서 정리해봤다!!

인터페이스??

인터페이스는 하나의 약속이다.

무슨 약속이냐?

A라는 것을 하면 B라는 결과가 나온다는 약속을 정의한 것이다.

즉, "A→(약속=인터페이스)→B" 와 같은 중간다리 역할을 한다.

이것만으로는 감이 잘 오지 않을 수 있어, 예를 준비했다.

실생활에는 생각보다 인터페이스가 많다.

예를 들면, 리모컨 전원 버튼이 있다.

TV를 켜고 싶다. 그러면? 우리는 리모컨을 개발한 사람이 만든 "리모컨 전원 버튼"을 눌러서 TV를 켠다.

따라서 "리모컨 전원 버튼"은 인터페이스가 된다.

또 다른 예를 들어보자.

화장실에서 볼일을 보고, 물을 내리고 싶다. 그러면? 우리는 변기의 "레버"를 눌러서 물을 내리게 된다.

따라서 "변기 레버"는 인터페이스가 된다.

프로그래밍으로도 예시를 들어보자.

LampOn()이라는 함수가 있다고 하자.

램프를 켜기위해서 LampOn()함수를 호출했더니, 램프가 켜진다.

따라서 "LampOn()"함수는 인터페이스가 된다.

함수도 일종의 인터페이스라고 할 수 있다.

이처럼 개발자가 만들어 놓은 환경에서 어떠한 입력을 했을 때, 어떠한 출력이 나오도록 중간에서 구현한 것을 인터페이스라고 한다.

동영상에서는 "고기집 인터페이스"를 통해 개념을 더욱 쉽게 설명하고 있다.

설명이 아주 맘에 들어서 정리해보겠다.

고기집 인터페이스

고기집이 있다.

고기집에 들어가서 "저기요~" 하고 부르니, 네~하고 종업원이 와서 주문을 받는다.

그런데 요즘은 "호출벨"을 누르면,  종업원이 화면에 뜬 테이블 번호를 확인하고, 해당 테이블에 와서 주문을 받는다.

여기서 "저기요~"랑 "호출벨"은 인터페이스가 된다. 

앞에서 설명한 것처럼, "저기요~" 하거나, "호출벨"을 누르면, 종업원이 온다는 결과가 있기 때문이다.

호출벨이 개발되기 전에는 직접 사람이 "저기요~"하고 불렀는데, 가게가 바쁘면, 어디서 누가 부르는지 모를 수 있고, 시끄러워서 못듣는 문제가 발생할 수 있다.

이러한 구버전 방식, 즉 구버전 인터페이스의 문제점을 보완한 신버전 인터페이스인 "호출벨"이 개발된 것이다.

"호출벨"을 누르면 내부 신호를 통해 화면에 해당 테이블의 번호가 찍히고, 띵동~하는 소리도 울린다. 그럼 종업원은 화면 속 테이블 번호를 확인하여 주문을 받을 수 있으므로, 누가 부르는지 모르는 등의 문제를 보완할 수 있다.

정리하자면,

고기집에서 손님이 주문을 하기위해 "저기요~" 하고 부르는 구버전 인터페이스 또는, "호출벨"을 눌러서 부르는 신버전 인터페이스를 통해 종업원이 온다.

이제 인터페이스의 개념은 확실히 잡혔을 것이다.

그렇다면, 백엔드 개발에서 많이 언급되는 API는?

API??

API(Application Programming Interface)는 어플리케이션 층에서의 인터페이스라고 할 수 있다.

즉 일종의 거대한 인터페이스이다.

API를 잘 만들기 위해서는 아래 4가지를 따라야 한다.

1. 직관적인 입출력

인터페이스의 입력과 출력이 굉장히 직관적이어야 한다.

무슨 의미냐하면..

고기집을 예시로 들겠다.

"호출벨"을 한번 누르면(입력), 종업원이 온다(출력). 이렇게 인터페이스가 설계되어 있다면, 베스트 케이스이다.

정말 심플하고 명확한 입력에, 명확한 출력이기 때문이다.

 그런데, "호출벨"을 세번 연달아 눌러야, 종업원이 온다. 라고 인터페이스를 설계했다던지, "호출벨"을 모스부호 처럼 눌러야, 종업원이 온다. 라고 인터페이스를 설계했다면, 사용자 입장에서 굉장히 모호하고, 입력이 애매하다.

따라서 Simple is Best이다. 인터페이스의 입출력은 정말 직관적이고 심플하게 구현되어야 한다.

현재 나의 인터페이스 혹은 함수도 직관적으로 설계되어 있는지 들여다 볼 필요가 있다.!!

2. 성능 요구사항

성능 요구사항은, 출력에 대한 명확성이 있어야 한다.

그러니까 어떤 입력이 들어오더라도, 결과는 어떠한 형태로든 출력이 되어서 사용자에게 정보를 잘 전달해주어야 한다.

어떤 입력이나, 내부 시스템으로 인해 문제가 발생했다고 하자. 그럼 발생한 문제에 대한 에러 메시지를 출력한다던지, 잘 동작했으면 올바른 결과값을 출력한다던지, 반응이 꼭 있어야 한다는 것이다.

그 반응은, 메시지, 문서, 효과음 어떤 것이든 상관없다.

3. 하위호환지원

하위호환지원은, 신버전 인터페이스가 있음에도, 구버전 인터페이스 또한 지원하는 것이다.

또 고기집으로 예를 들어보겠다.

"호출벨"이 설치된 고기집이 있다. 이 고기집에 가서 주문을 하기 위해 "저기요~"라고 불렀다. 그런데 아무리 불러도 종업원이 반응이 없다. "호출벨"의 기능을 안써보거나 모르는 손님은, 신버전 인터페이스인 호출벨만으로 주문을 받는 식당에게 화만 나고, 더이상 이 식당을 이용하지 않을 것이다.

이런 융통성 없는 식당 같은 상황이 실제로 개발에서도 이루어진다.

따라서 손님이 "저기요~"라고 불러도 종업원이 와야하고, "호출벨"을 눌러도 종업원이 올 수 있도록 두가지 모두 지원하는 것이 하위호환지원이다.

But!!

실제로는 하위호환지원이 쉽지 않다. 유지 관리가 어렵기 때문에, 개발자들 입장에서 두가지 버전을 다 지원하는 것이 쉬운 일은 아니다. 왜냐하면, 구버전의 문제점이나 성능을 보완하기 위해 신버전을 개발하였는데, 동시에 두 버전을 모두 유지하기위해서는 신버전의 기술을 미처 사용할 수 없는 상황이 오는 등 걸림돌이 될 수도 있다.

따라서 현실적으로 신버전 인터페이스만 제공하게 되는 경우가 대부분이라고 한다.

(마이크로소프트사가 window의 여러버전을 하위호환하는 데에는 최고라고 한다.)

4. 쉬운 접근성과 대중성

인터페이스는 누구나 알수 있게 만들어야 한다.

만약 인터페이스를 개발했는데, 사용자입장에서 사용하기 너무 어렵고, 뭘 하는 건지 이해하지 못한다면, 안쓰게 된다.

안쓴다는 것은 개발을 안한 것이나 다름없다.

따라서 인터페이스를 개발했다면, 사용자에게 적극적으로 알려야 한다.

고기집을 예로 들면..

"호출벨"이 나오기 전까지, 고기집에서는 "저기요~"라고 부르기만 하면 됐다.

그런데, 아무런 통지나 알림도 없이, 고기집에서 "호출벨"을 테이블에 붙혀 놓았다.

사람들은 처음 보는 "호출벨"이 뭔지도 모르고, 심지어는 눈에 안띌수도 있다.

따라서 있어도 모르니까 "호출벨"을 안쓰게 된다.

"저기요~"하고 부르면, 종업원은 와서 주문을 받고 "다음부터는 "호출벨"을 눌러주세요~"라고 손님들에게 지속적으로 알려주어야 한다. 그래야 손님들은 기억을 하고 학습하여 "호출벨"을 누를 수 있게 된다.

이렇게 인터페이스를 알려주어야 하며, 사용하기 쉽게 해주어야 한다.

인터페이스에 대한 개념은 이쯤에서 정리하고, 추가적인 내용들이 생기면 다음 편에 이어서 쓰도록 하겠다.

개인적으로 고기집 인터페이스 설명으로 아주 쉽게 이해할 수 있어 좋은 것 같다.