들어가기 전에
인터페이스라는 단어는 비단 개발자 뿐만 아니라 일상생활을 하면서도 굉장히 많이 접하게 되는 단어이다. 하지만 이 단어가 가지고 있는 진정한 의미를 알고 있는 사람들은 많지 않다. 어쩌면 나도 인터페이스라는 단어를 잘 알고 있나 싶지만, 개인적으로 생각하고 있는 그 의미를 한 번 생각해보았다. 물론 내 생각이 정답은 아닐 수 있고, 사람이나 상황마다 그 의미는 충분히 달라질 수는 있다.
인터페이스의 의미
인터페이스는 서로가 이어질 때마다 만나는 접점이다.
서로의 대상은 여러가지가 될 수 있다. 사람과 사람, 사람과 물건, 물건과 물건, 코드와 사람, 코드와 물건, 소프트웨어와 소프트웨어, 소프트웨어와 하드웨어, 하드웨어와 하드웨어 등 뭐든지 인연은 이어질 수가 있다.
이어진다는 건, 물리적이던 추상적이던 만나는 지점이 생긴다는 뜻이다. 우리는 그 만나는 지점을 인터페이스라고 부를 수 있다.
인터페이스의 보통된 의미: 매뉴얼
접점 이라는 단어는 조금 추상적인 의미일 수 있다. 그럼 인터페이스를 보다 더 직관적이고 보통스럽게 설명할 수 있는 단어는 없을까?
나는 인터페이스는 매뉴얼이라고 생각한다. 매뉴얼은 다른 말로 사용법이다.
어떠한 물건과 그것을 사용하는 사람을 생각해보자. 인터페이스의 의미는 접점이고, 좀 더 구체적으로 말하자면, 인터페이스는 그 물건의 사용법이라고 할 수 있다.
매뉴얼의 덕목
알려줘야 할 건 알려주고, 숨길 건 숨겨
매뉴얼은 알려줘야 할 것과 숨기는 것을 잘 구별할 줄 알아야 한다.
한 번 거실에서 TV를 쓰고 있다고 상상해보자. TV의 매뉴얼에서
알려줘야 할 것은
1. 기능 : 어떤 것이 목적인지 알아야 한다. 예를 들면, TV를 켜기 위해선
2. 입력 : 목적을 이루기 위해서 어떤 것이 필요한가. 예를 들면, 전원버튼을 누른다.
3. 결과 : 입력을 넣었을 때 기능이 수행된 결과이다. 예를 들면, TV가 켜진다.
그럼 숨겨야할 것은 무엇일까?
기능이 동작되는 과정: 우리는 TV버튼을 눌렀을 때, 그게 TV안에서 어떠한 전자회로를 거쳐서 TV가 켜지는 지 전혀 몰라도 된다. 우리는 TV를 만드는 엔지니어가 아니라 일반 사용자이기 때문에 전원버튼을 눌렀을 때, TV가 켜지는 지만 알면 충분할 것이다.
예제1) 객체지향 언어에서의 인터페이스
인터페이스가 매뉴얼이라는 아이디어는 객체지향 프로그래밍을 할 때도 그대로 적용할 수 있다.
다음은 요리에 관련된 인터페이스와 구현체이다.
public interface Recipe {
Food Cook(Ingredient ingredient);
}
public class KoreanRecipe implements Recipe {
public Food Cook(Ingredient ingredient) {
// 재료를 한식으로 요리
return new KoreanFood(ingredient);
}
}
public class WesternRecipe implements Recipe {
public Food Cook(Ingredient ingredient) {
// 재료를 양식으로 요리
return new WesternFood(ingredient);
}
}이 레시피를 사용하는 쪽의 코드도 한번 봐보자
public Chef {
private Recipe recipe;
public void setRecipe(Recipe recipe) {
this.recipe = recipe
}
public Food Cook(Ingredient ingredient) {
return recipe.Cook(ingredient);
}
}- 요리사와 요리 사이의 접점: 레시피 인터페이스
이 요리사는 레시피를 Setter로 받아서 그대로 요리해서 음식을 만들어 낼 수 있다. 코드상으로 보면 이 요리사는 본인이 받은 레시피가 한식레시피인지 양식레시피인지 전혀 알 필요가 없다.(물론 실제로 그런 요리사는 없겠지만...)
우리는 인터페이스가 기능, 입력, 결과 라는 것을 알고 있으므로, 이 레시피를 인터페이스로 해석하면
기능: 요리하기
입력: 재료
결과: 음식
이다.
요리사는 레시피라는 매뉴얼이 하라는 대로 하기만 해도 안에서 어떻게 돌아가지는 지 몰라도 소정의 목적을 달성한 것이다.
객체 지향에서는 이런 가치관을 가지며 인터페이스를 만들며, 이를 통해 여러 디자인 패턴둘(대표적으로 전략패턴)을 만들어 낼 수 있다. 이러한 패턴을 통해 객체지향 코드는 서로간의 결합도를 끊어낸다고 할 수 있다.
예제2) API(Application Programming Interface)에서의 인터페이스
이 매뉴얼이라는 아이디어는 API에서도 통용된다.
흔하디 흔하게 볼 수 있는 API 레퍼런스 문서의 예이다.
사용자 정보 가져오기
URL: /users/{user_id}
HTTP 메서드: GET
요청 매개변수:
user_id (정수, 필수): 사용자의 고유 ID.
응답:
{
"user_id": 123,
"username": "johndoe",
"email": "johndoe@example.com"
}- 프론트엔드와 백엔드 사이의 접점: API
우리는 인터페이스가 기능, 입력, 결과 라는 것을 알고 있다.
API에 대응해보면
기능: 사용자 정보 가져오기
입력: 사용자ID
결과: 사용자 정보
라는 것을 알고 있으며, 이 과정을 수행하기 위해 서버가 어떠한 과정을 수행하는 지는 전혀! 알아야 필요가 없다. 그저 API를 사용하는 쪽은 감사한 마음으로 잘 매뉴얼대로 잘 사용하면 되는 것이다.
예제3) UX/UI에서의 인터페이스
- 사용자와 소프트웨어 사이의 접점: UI
화면 개발을 하다보면 유저 인터페이스라는 단어를 많이 듣게 되는데, 똑같이 매뉴얼이라고 생각하면 된다. 화면은 사용자에게 로그인을 할 수 있는 입력란과 버튼을 제공한다.
기능: 로그인
입력: email과 password를 입력하고 버튼 클릭
결과: 로그인 성공
사용자는 로그인이 어떻게 성공하는 지는 전혀 알 필요가 없다. 그냥 성공한 것이다! 어떠한 과정을 통해서 성공했는 지는 개발자만 알면 되는 것이다. 그것이 화면을 통하고 API를 통하고 객체지향의 인터페이스를 통하던 말던 아예 관심있을 필요가 없다는 것이다.
화면은 그저 로그인 기능이 가능한 UI만 제공해주는 것이다.
이 세상은 모두 인터페이스다
세상은 숨길 건 숨기고 보여줄 건 보여주는 걸로 이루어져 있다. 그게 나쁘다는 게 아니다. 그냥 만든 사람은 보여줄 필요가 있는 것만 보여주고, 사용할 사람은 쓸 필요가 있는 것만 쓰면 된다. 인간의 두뇌는 한계가 있다. 본인의 역할을 넘어서는 것까지 모두 알 수 없다. 그저 본인이 알아야 할 필요가 있는 것만 알고 그 외는 다른 사람들에게 책임을 넘기는 것이다. 이것이 집단지성이고 이러한 집단지성으로 세상은 좀 더 기술적으로 발전해 나가는 것 아니겠는가? 하하
