|
첫 인터페이스 설계를 7년전에 해 본 것 같다.
그때는 정말 어리버리하게 만들었었다. 지금 보면 살짝 낯 뜨거울 정도로..
그 놈들이 지금까지도 별 수정없이 사용된다니 믿기지 않기는 하지만...
오늘도 인터페이스 설계에 대한 회의를 하는데,
예전에 만들었던 것을 떠 올리게 하는 사건이 있어서 잠시 되돌아보니
오늘도 포함해서 많은 아쉬운 순간들이 생각난다.
인터페이스 설계에서 생각해야 하는 점들을 정리해보자.
그리고 똑같은 실수는 되풀이 하지 말자.
- 무엇과 무엇을 연결하는가?
로컬 장비내에서의 통신인가? 리모트 장비와의 통신인가?
- 인터페이스가 구현될 최상위 통신 프로토콜은 무엇인가?
FILE인가? PIPE인가? TCP인가? HTTP인가? 혹은 또다른 무엇인가?
- 통신망은 어떤 상황인가?
내부망인가? 아니면 이더넷으로 나가야 하는가?
그리고 내부망에서 L4같은 것들의 설정값 혹은 정책은 어떠한가?
- request, response의 크기
size를 줄여서 request, response가 왠만하면 하나의 packet에 가게 할 것인가?
아니면 그냥 그런 거 고민 안 할 것인가?
- BINARY 포멧을 사용해야 하는가? TEXT 포멧을 사용해야 할 것인가?
때에 따라서는 BINARY 포멧을 써야 할 때도 있다.
- 커넥션과 싱크 문제는?
항상 연결되어 있을 것인가? 하나 처리하고 끊을 것인가?
그리고 싱크로 할것인가? 어싱크로 할 것인가?
- CHARSET은?
UTF8을 쓸 것인가? 유니코드를 쓸 것인가? 아니면 영문으로만 제약할 것인가?
- 시간문제는?
시간이 중요한 문제인가? 몇초차이는 용납이 되나?
- 사용하는 프로토콜을 적절히 사용하였나?
예를 들면 TCP 쓰는데 data부분에 받는 측 ip, port값이 나온다거나,
HTTP request 만들었는데 data부분에 url이 있거나 하지는 않는가?
- REST 에서 발생하는 여러가지 거시기한 상황들
만일 다른 설계자가 REST를 이상하게 쓰자고 주장하면 어떻게 할 것인가?
- 결과 코드, 오류코드의 개념을 어떻게 구현할 것인가?
아마 사람 머리 수만큼 설계안이 나올 것이다. 그렇지 않다면 누군가 놀고 있다.
그리고 비즈니스 오류의 개수가 엄청나게 많지 않나? 그럼 어떻게 할것인가?
- 멀티 request의 개념이 있는가?
트랜잭션 처리를 해야하나? 아니면 기계적으로 배치작업처럼 처리를 할 건가?
아니면 BPML처럼 제어코드를 정의할 것인가?
- 서비스 불가능한 상황에 대해서도 고려되어 있는가?
마이그레이션 중이라던가, 서비스 접었다거나, 서비스 점검등의 상황에 대비하였나?
- 확장성은 어떻게 생각하나?
확장성있게 무엇인가를 더 추가할 것인가?
아니면 발생할 것 같지도 않은 "그때" 가서 다시 생각해 보겠나?
- 하위 버전은 생각해 봤나?
인터페이스가 변경되면 어떻게 처리할래?
- 설계한 인터페이스에서 과한 부분이 없는가?
더 뺄 것이 없는가?
- 인터페이스가 알아먹을만 한가?
너무 복잡하게 설계되어 있지는 아니한가?
...
이외에도 엄청나게 많은 중요한 사항들이 있을 것이다.
그러나 가장 중요한 것 한가지는 바로 아래 한줄일 것이다.
- 설계가 끝난 후 협업한 설계자와 더 친해졌는가? | 
