1. 엔데믹 상황으로 들어선 뒤 본격적으로 해외 컨퍼런스나 밋업에 참여할 기회가 많았는데, 아시아, 유럽, 대양주, 미주 쪽을 목표로 해 봤다. 이 중에서 유럽만 빼고는 다 컨퍼런스나 밋업을 다녀왔으니 나름 선방(?)했지 않았나 싶다.

2. 개인적으로는 컨퍼런스 발표를 최대한 줄여보고 내실(?)을 좀 다질 수 있는 한해로 삼고자 했으나... 내실 보다는 여전히 컨퍼런스 발표가 많았다. 내년에는 좀 더 내실을 다진 후에 다시 발표를 하는 방향으로 최대한 노력을 해 봐야겠다.

3. 올해 목표중 하나는 가급적 상대방의 의견과 내 의견이 다를 수도 있다는 것을 인정해 보기였다. 의외로 스스로를 반추해 보면 상대방의 의견과 내 의견이 다를 수 있다는 것을 인정하지 못했던 것 같다. 특히나 "소프트웨어 개발"이라는 측면에서 봤을 때, 정답이 있을 수 없고, 내가 선택한 방법이 다른 사람/상황에도 적용할 수 있다고 생각하는 것이 얼마나 오만한 접근인지를 여러 상황을 통해 가슴으로 받아들이게 된 한해였지 않았나 싶다. 예전에는 이걸 머리로만 이해했다면, 올해는 가슴으로 받아들이는 원년(?)쯤 된 것 같다.

4. 물론, 좋은게 좋은거다 라는 식으로 접근하기 보다는 "나는 이렇게 했는데, 이게 꼭 너의 상황과는 맞지 않을 수도 있으니 참고만 해라" 정도로 했던 것 같다. 이런 자세를 최대한 견지하려고 하다보니 좀 더 시야가 넓어지는 느낌을 받았다. 내년에도 비슷한 접근 방식을 취해 보려고 한다.

5. 사는 곳이 서울/경기 지역이 아니다보니 지역의 활동가들과 많은 교류(?)가 있었더랬다. 이들의 방식은 서울/경기 지역의 활동가들과는 완전히 다르다는 것을 일년 내내 느꼈다. 아직도 내가 사는 곳의 일하는 방식은 낯설기만 한데, 이를 최대한 이해하는 것을 내년의 목표로 삼아볼까 한다.

6. 내년에는 블레이저를 어떻게 해서든 좀 띄워볼까 싶다. 띄운다고 뜬다면 좋겠다만, 최소한 한국의 개발바닥에서 블레이저가 꽤 다방면으로 활용도가 높다는 것을 알려주는 것만으로도 충분하지 않을까 생각한다. 뭐... 한국에서 안 떠도 전세계적으로는 계속 뜨는 중이니까 나야 크게 상관은 없다마는...

7. 파워 플랫폼 관련해서 계속해서 이런저런 작업을 해 봤는데, 파워 플랫폼 뒷단에서 서폿해 주는 코드-퍼스트 개발자 환경에 좀 더 포커스를 두는 방향으로 전환해야 할 듯 싶다. 결국 회사에서 사용하려면 뒷단이 탄탄해져야 하기 때문에...

8. 내년엔 플랫폼 엔지니어링과 API 플랫폼 구성에 좀 더 신경을 써 볼까 싶다. 한국에서 플랫폼 엔지니어링은 이상하게도 SRE에 몰려 있는 편인데, SRE와 겹치지 않는 부분을 좀 더 다뤄봐야 할 듯 하다. 그러기 위해서는 API 플랫폼도 다뤄봐야 할 듯 싶은데, 한국에서 과연 가능할지는 모르겠다...

9. 이쯤으로 하고 올해의 활동은 마무으리 하는 걸로!

간단히 적어보는 2023년 회고

0. API 떡밥은 쉬었지만 여전히 핫하니까, 그냥 나도 덥썩.

1. API의 개발 책임(?)/주도권(?)이 프론트엔드에 있는지 백엔드에 있는지는 중요한 게 아니다. 중요한 건 API 설계임. 하나의 API 앱에 다 때려박을 수도 있고, API를 수십개로 쪼갤 수도 있고, 그건 회사마다 상황에 따라 다르게 선택하면 되는 건데, 그게 설계단에서 검증을 해야 함.

2. 일단 API는 한 번 만들어진 후 배포를 하면 없앨 수가 없다. 없앨 수는 있겠지만 해당 API 엔드포인트를 누군가 쓰고 있다면, 그 사용자가 없어지기 전 까지는 없앨 수가 없음. 그래서 API는 변경 비용이 비싸다고 하는 것임.

3. 10년 쯤 전에 다니던 직장이 API 플랫폼 장사를 하던 회사였고, SOAP 기반 웹서비스로 API 장사를 했더랬는데, XML 노드 하나 추가하는 것은 괜찮지만, 변경하거나 삭제하는 건 최소 6개월의 depreciation 노티스를 줬다. 그 기간동안에는 신규 API와 기존 API를 둘 다 지원해야 했음.

4. 보통 마이크로서비스 아키텍처든 모놀리식 아키텍처든 기존에 사용하던 API들이 많다면 그것들을 묶어주는 API를 따로 만들기도 하고, 프론트엔드 쪽에서는 해당 프론트엔드 쪽에만 맞춤형으로 기존 API들을 묶어서 사용하기도 한다. 이를 BFF 패턴이라고 하는데, 이건 사실 코어 API하고는 크게 상관이 없음. 그걸 백엔드 쪽에서 관리하기엔 무리데스. 사실 BFF는 굳이 신규로 API를 개발할 필요도 없이 API 게이트웨이 수준에서 충분히 처리가 가능하기 때문이기도 함.

5. 그러니... API 설계나 잘 하쟈. 그러라고 OpenAPI 쓰는 것 아니겠음?

6. API 설계 우선 원칙에 대해 예전에 이상한 모임 하면서 2015년인가 2016년인가부터 목놓아 부르짖었지만, 아직도 이게 새롭다는 게 더더욱 신기함. 그 때 한창 한국 개발자 커뮤니티에서 API 얘기 엄청 헀던 것 같던데...

7. 그러니 이 책 한 번 잘 읽어보고 API 설계 잘 하면 좋겠다...

https://www.yes24.com/Product/Goods/124127840

난 이 책하고는 1도 관계 없음

API 설계 우선 원칙

Support Engineer

박영주

디지털 트랜스포메이션

박민우

하정훈

Microsoft Tech Specialist

한석진

메롱니모

Microsoft Partnership Development Manager

Lana

김정우

사업 개발

김지우

microsoft channel executive

ShimSarah

Microsoft Business Program Manager

김서영

Microsoft  Principle Data Scientist

박승욱 (Steven Park)

강유진

Microsoft / Senior Product Designer

Senior Cloud Advocate

저스틴

김진성

Microsoft Software Engineer

Software Engineer

ayoon

Microsoft Cloud Solution Architect

김나연

Applied researcher

김유진

Microsoft 엔지니어

Dain

Microsoft 개발자

진주

Microsoft 소프트웨어 엔지니어

한충우

Microsoft 백엔드 개발자

Zech

이정윤

Microsoft - Integrated Marketing Manager

이주형

Microsoft Principal Tech PM

최윤석

Microsoft UX/UI 디자이너

윤태영