아무리 작은 업무라도 정성껏 하자(나쁜 API 규격의 부메랑)

 처음 내가 서버 개발을 담당하게 되었을 때, 생각보다도 간단했던 기능에 약간 기운이 빠지기도 했다. 서버는 단순히 데이터 동기화의 역할만 해주면 될 뿐이라고 알게 되었을 때 데이터 동기화 기능만 만들어주고 이후엔 서버 개발에선 빠질 것 같았다. 실제로 앱 개발 팀장님이나 우리 팀장님이나 그렇게 얘기를 하셨고.

 내가 서버를 맡기 전까지 서버를 담당하신 앱 개발 팀장님께 인수인계받은 내용으로는 앱 개발 팀장님이 이미 설계하신 API가 있었고, RequestBody의 대략 형태를 그려보자면 아래와 같았다. 의미를 풀어서 써보자면, data로 type의 작업을 task의 정보를 가지고 한다는 의미이다. 그 말인즉, 엔티티는 엄청 많은데 그 많은 엔티티의 작업을 처리하는 엔드포인트가 하나였다.

{
    "job":[
    	'{\"data\":\"USER\", \"type\":\"CREATE\", \"task\":\"~\"}',
        '{\"data\":\"USER\", \"type\":\"DELETE\", \"task\":\"~\"}'
    ]
}

 처음 이 API를 봤을 때 거의 절망스러웠지만... 어쨌든 난 앱에서 주는 데이터만 서버에 그대로 저장하고 앱에서 요청하면 저장해놓은 데이터를 위와 같은 형태로(...) 내려주면 된다고 해서 '아, 이건 아닌데...'싶으면서도 어차피 이 기능 하나만 만들고 빠지기로 했기 때문에 개발 팀장님이 설계하신 API대로 만들었다.

---

 그런데 문제는 사실 서버가 위에 적은 것처럼 앱에서 주는 데이터 저장했다가 앱에서 요청하면 그 데이터를 주기만 해서는 안되었다는 것이다. 나는 어차피 간단한 기능이므로 거의 다 만들고 테스트를 하고 있었는데, 앱 개발자들이 앱을 개발하면서 내가 몰랐던 다른 요구사항으로 인해 원래는 앱에서 했던 로직을 데이터의 정합성과 일관성의 이유로 서버에서 처리해주길 요청했고, 그렇게 너무 많은 로직이 서버로 넘어왔다.

 사실 이미 나는 다 만들고 테스트를 하고 있던 중이었는데, 계속 서버쪽을 수정해야하는 문제가 생기니 API 규격을 수정해야 하긴 하지만 시간에 쫓겨 API 규격 수정없이 수정 개발을 했다.

 그리고 개발을 진행하는 동안 상황이 많이 바뀌어 원래 간단히 동기화 기능만 만들어주고 빠지려던 나는 서버 개발에 붙박이가 되었다. 베타 버전까지는 저 API로 하긴 했는데, 나도 모르는 사이에 상용 오픈 이야기가 나왔다.(아니 애초에 상용 오픈까지 이렇게 짧게 잡을지도 몰랐다. 이런 내용이 좀 공유되었으면 좋았을텐데. 어느샌가 상용 오픈 날짜가 잡혀있었다. ㄷㄷ)

 사실 앱에서 서버로 로직을 넘겨달라고 요청한 때부터 앱 개발 팀장님께 '지금 API로는 나중에 추가 기능을 붙이고 싶어도 붙일 수가 없는 구조고, 다른 개발자가 와서 봐도 이해하기 힘들거고, 설사 이해해서 코드를 짠다해도 스파게티코드가 될거다, API 규격을 아예 뜯어서 고쳐야 한다.'고 말씀을 드리긴 했다.

 근데 이제 상용 오픈 이야기가 나오니, 더 이상 이 API 규격으로는 힘들겠다 싶어서 본격적으로 앱파트에 API 규격이 변경되어야 하니 앱도 변경되어야 할 것 같다 라고 이야기를 했다. 그랬는데... 보통 어떤 작업을 API로 만드는데, 앱파트는 테이블 단위로 API를 생각하고 있어서 이해를 잘 못 하셨다. 지금 이 API의 문제가 뭔지 이해를 못 하시는 느낌이었다. 예를 들어, 내가 앞으로 API를 엔티티중심으로 뜯어서 개발하려고 한다니까 A엔티티+B엔티티(B엔티티는 A엔티티와 외래키로 묶인 관계)를 요청 못 받지 않냐고 하셨다. 그래서 그건 A엔티티와 관련이 있으니까 A엔티티 관련 API로 요청을 주면 B엔티티도 같이 처리해주겠다고 했다. 그럼 A엔티티+C엔티티는 못 받지 않냐고 하셔서 요청 데이터가 바뀌면 API를 새로 만들어달라고 하셔야 한다고 했다. 그렇게 열띤 토론 끝에 API 규격을 변경하기로 했고, 오늘 API를 Restful하게 바꾸는 작업이 끝났고 내일 출근해서 앱파트에 변경된 API 규격을 공유해야 한다.

---

 사실... 내 단점이 보이는 내용이기도 해서 기술블로그에 적을까 말까 했지만 다음에 또 이런 일을 겪지 않기 위해, 나뿐만 아니라 내 글을 읽은 다른 개발자가 나와 같은 경험을 하게 하지 않기 위해 적었다.

 내 스스로도 내게 아쉬운 점은 주변에서 정해주는대로 내 역할을 한계지었다는 것이다. 처음 저 API를 봤을 때 정말 마음에 안 들었지만 어차피 요구받은 기능만 해주고 빠지는데 너무 일을 키우는 것 같아서 마음에 들지 않아도 그냥 저 API로 작업했다는게 지금 와서 생각해보면 정말 잘못된 선택이었다. 내가 못하면 하다 못해 원래 API를 설계해놓으셨던 앱 개발 팀장님께라도 처음부터 이 API 규격은 이러저러한 문제점이 있으니 Restful한 규격으로의 변경을 고려해보시면 좋을 것 같다, 라고 한 마디라도 했으면 좋았을텐데 그러지 못한 게 지금도 많이 아쉽다.

 그래도 어찌저찌 API 규격을 뜯어고쳤다. 더 늦지 않은 게 너무나도 다행이라는 생각이 든다. 그리고 Restful하게 작성된 API를 보면서 10년 묵은 체증이 낫는 기분이 들었다. 앱 개발자들과의 첫 협업이라 이래도 될까 저래도 될까 눈치도 많이 보았지만, 이번 일로 아무리 작은 업무라도 내 한계가 정해진 업무라도 조금 더 내가 할 수 있는 일이 있으면 눈치 덜 보고 적극적으로 얘기해보고 나서보자라는 생각이 들었다.