API 문서 자동화를 위한 RestDocs 적용 방법에 대해 알아봅시다! API 문서 자동화는 정말 중요한 일입니다. 사람이 손으로 해서는 결국 한계가 있고, 규모가 커질수록 걷잡을 수 없게 됩니다. 가령 문서 파일로 API를 관리하고, 이를 공유하고 업데이트 하는 식으로 사용하게 될 경우, 형상관리를 하더라도 분명 이슈가 발생하게 됩니다. 코드에 반영을 했는데 문서에 반영을 하지 않는다던가, 최신화되지 않은 문서를 참조하고 있다거나, 변형된 파일이 공유된다거나.. 정말 많은 이슈가 생길 수 있습니다. 그래서, 프로덕트가 배포되는 시점에 문서도 자동화되어 배포될 수 있게 구성할 수 있다면, 그리고 프로덕션 코드에는 영향이 없다면, 정말 좋겠습니다. 초기 설정이 다소 까다로워서 그렇지 한 번 구축을 완료하..
스티커 제작 넛지: 회고덕 아마도 3차 스프린트 초반이었던 것 같습니다. 회고덕 팀의 스티커가 배부되었는데, 너무 예쁘게 잘 나와서 스티커 붙이기를 그닥 좋아하지 않던 제가 모니터 스탠드와 사물함에 회고덕 팀의 스티커를 붙였습니다. 우리 팀 줍줍도 마스코트 디자인이 너무 잘 나왔기 때문에 꼭 스티커를 만들어야겠다 생각했습니다만 팀원 모두가 지쳐있고 너무 바쁜 상황이어서 디테일 하나하나를 모두 합의하며 진행하기엔 다소 무리가 있겠다 생각했습니다. 그래서 회고덕 팀의 아리를 통해 회고덕 팀이 제품을 제작했던 업체를 확인했습니다. 필요한 진행을 모두 진행한 뒤 최종 결정 시점에 의사를 확인하고 피드백을 받는 정도로 진행해도 무리가 없는 무게감의 일이 아닐까 추측했기 때문입니다. 사실 이러한 일 처리 방식은 상..
테코톡 발표를 마쳤습니다. 2년 전 이맘때쯤, 국비 수강 과정중에 테코톡을 처음 접했었는데.. 그 트랙룸에서 제가 발표를 하는 날이 오다니 아직도 믿기지가 않네요. (정말? 내가? 왜? 우테코? 실화냐..) 영상으로 전해지던 우테코만의 분위기를 저도 경험할 수 있었습니다. 원하지만 이루어지지 않을거라 생각하며 그러나 또 원하는 ㅋㅋ 그런 마음이었는데 이런 날도 오네요.. 발표를 들어주시고 격려해주고 응원해주신 모든 분들 정말 감사드립니다. 더 많이 학습하고 준비해서 더 양질의 발표를 하고 싶었지만 그러지 못해서 정말 아쉬운 마음이 크고 실망스러운 생각입니다. 그러나 마쳤다는 기쁨이 너무 크네요 ㅋㅋ 준비할 땐 몰랐는데.. 끝나고 나니 정말 홀가분합니다.
팀 프로젝트를 진행하며 몹 프로그래밍, 페어 프로그래밍 등을 활용하고 있습니다. 이 과정에서 하나의 컴퓨터를 호스트로 두고 진행하게 되면, 공동 작업자의 기여가 깃허브에 나타나지 않는다는점이 아쉬웠습니다. 관련하여 케이의 https://kth990303.tistory.com/349 포스팅을 읽고 이를 쉽게 적용하기 위한 플러그인을 설치한 내용을 작성해봅니다. 공동 작업자 표시 예시 깃헙 커밋 내역에서 공동 작업자를 표시해주고 싶었습니다. 상대방의 캐리를 받아 작업을 진행했는데, 나의 컴퓨터를 호스트로 사용했다는 이유로 커밋 내역에 저만 기록된다는 점이 아쉬웠습니다. 위처럼 공동 작업자들을 표시해줄 수 있다면 공동 기여분에 대한 보다 명시적인 표시를 해줄 수 있어 페어 프로그래밍 이후 만족감이 더 높을 것..
팀 프로젝트를 진행하며 다음과 같은 요구사항이 발생했습니다. 1. 특정 워크스페이스 구성원인지 식별할 수 있어야 한다 2. 내부 구성원이라면 해당 사용자를 식별할 수 있는 정보를 확보해야 한다 이를 구현할 방법에 대해 탐색한 결과를 간단히 기록해봅니다 OAuth Flow OAuth Flow 를 이해하는 데에 시간이 많이 필요했습니다. 레벨2에서 인증, 인가를 학습하며 RFC 문서를 통해 인증 서버와 자원 서버를 구분하여 사용한다는 개념은 미리 습득해두었지만, 이를 하나의 사용자 관점에서만 접근했었기 때문에 미싱 링크가 존재했습니다. 사용자와 두 개의 서비스가 존재할 때, 서비스 A는 사용자에 대한 인증을 서비스 B에 의존하는 상황이라면 상호작용하는 대상이 셋이 되고, 이 경우에 대한 이해가 추가적으로 필..
