고민의 시작

프로젝트를 진행하며 여러 논의점이 생기게 되었습니다.

같이 진행하는 멘티의 경우 언제나 같은 api 의 리턴 형태를 선호하였고, 저는 그 형태를 납득하기 어려웠습니다

데이터의 형태는 이러했습니다

{
    "code": 200,
    "message":"ok",
    "value": T,
}

api 가 성공했을 때에도, 실패했을 때에도 같은 형태의 데이터를 리턴해야 한다는 의견 이었습니다

고민이 되는 근본적인 이유는 이렇습니다

"http 에서 어차피 code 를 보내 줄 것이고, message 는 언제나 ok 인데 왜 중복되는 데이터를 보내야 하지?"

RESTFUL 은 지켜야 하는가?

위에서 표현한 모델의 경우는 예시이고 실제로 사용한다면 아래와 같은 형태를 가져 갈 것이라 생각합니다.

{
  "resultType":"USER_CREATE_SUCCESS",
  "message":"User create success",
  "value": {
    "id": 10000
  }
}

이러한 형태로 나타낸다면 클라이언트에서는 더 명확한 성공 메시지를 받을 수 있고 의미 있는 성공에 대한 타입을 받아서 이해할 수 있습니다

이렇게 하면 사실, RESTFUL 은 적용 될 이유가 없다고 생각합니다.

status 를 지키며 조작 할 필요가 없습니다. resultType 이 더 표현을 잘 해주기 때문이죠.

그렇다면 좀 더 넓은 시야에서, 기술 자체가 적용되야 하는지 적용되면 안되는지를 고민 해 봅시다.

회사에서 RESTFUL 을 사용하지 않는다면, 왜 사용하지 않을까요?

RESTFUL 을 사용하지 않는 이유

여러 블로그의 글들을 보면 RESTFUL 을 사용해야 하는 기술적인 이유에 대해 설명하고 있습니다

그럼에도 불구하고 RESTFUL 을 사용하지 않는 회사들은 많습니다

기술적으로 좀 더 이상향에 가깝더라도 이 기술을 사용하지 않는 이유는 여러가지가 존재합니다.

• 레거시 서버들이 RESTFUL 하게 만들어져있지 않기 때문에
  마이그레이션에 대한 비용이 큰 경우 RESTFUL 을 채택하지 않을 수 있습니다.
• RESTFUL 의 복잡성 때문에
  RESTFUL 한 설계를 위해서는 공통적인 이해가 필요합니다. 하지만 RESTFUL 은 어느정도의 복잡성을 가지고 있습니다. 이 복잡성은 개발자들이 서로 같은 이해를 가지지 않을 수 있다는 단점이 존재합니다. 누군가는 '저장 성공' 이라는 응답을 http status 200(OK) 을 이용하고 누군가는 http status 201(Created) 을 응답할 수 있습니다.
  서로 다른 status 는 인프라 팀에게 불필요한 복잡성주게 됩니다.
• 그 비즈니스에 맞는 더 적합한 설계가 있어서
  페이스북에서는 GraphQL 방식을 채택하여 클라이언트가 필요한 데이터를 지정하고, 서버가 그에 따라 '필요한 데이터' 를 응답합니다.

이러한 이유들은 협업을 진행 할 때 'RESTFUL 을 선택하지 않을' 사항이 됩니다.

마무리

사실 특정 기술을 알고있는 개발자는 '왜 이 기술 적용 안함?' 이라고 할 수 있지만, 모르는 개발자에게는 '왜 그 기술을 적용함? 복잡한데?' 라고 생각할 수 있습니다

그런 상황에서 '기술을 이해한' 개발자는 이렇게 말할 수 있습니다.

공부하면 되잖아?

우리는 기술을 선택 할 때 비용을 생각해서 기술을 선택합니다

사실 공부도 하나의 비용입니다.

아무리 좋은 기술이 있다고 해도 협업하는 팀이 해당 기술을 모른다면 채택하기 어렵습니다. 왜냐하면 학습이라는 비용이 들어가기 때문입니다.

그렇다면 다음의 것 중 어떤 것이 비용이 저렴할까요?

• 다른 개발자를 이해시키는 것
• 기술을 적용하지 않는 것

좋은 기술을 적용하지 않는다면 결국 그 기술이 갖는 단점을 포용하지 않아도 된다는 의미입니다.

반대로 말하면 그 기술의 장점을 가질 수 없다는 이야기가 됩니다. 결국은 학습이라는 비용을 생각해서 적용하지 않는다는 선택을 했을 때, 이것은 모두가 납득하는 결과가 만들어지고 기술 적용에 대한 논의는 종료됩니다.

개발이 진행될 수 있죠

물론 그 기술이 가져다주는 장점은 누리지 못하고 곧 기술부채로 쌓일 것입니다.

하지만 그 방향이 회사가 선택한 방향이라면 우리는 따라야 합니다.

우리는 우리의 코드를 짜는 개발자가 아니라 회사에게 코드를 작성해주는 개발자이기 때문입니다.