멘토링은 워낙 많이 다녀봐서 개발자 컨퍼런스는 어떤 내용을 다루는지 궁금해졌다.
주위에서 인프콘에 가보라고 권유를 많이 해주셔서 그냥 지원해놓고 잊고 있었는데, 얼떨결에 붙어버렸다.
이런 거 하면 맨날 떨어지던데, 이번엔 또 어째 붙었다.
오전 10시부터 개회식이 시작된다길래, 10시 30분 쯤 도착하게끔 기차표를 예매했었는데 같이 가게 된 분이 그러다가 사람 몰린다고 해서 6시 30분 기차를 예매하게 됐다. (전날 대회 준비 때문에 2시간 자고 일어나는데 죽는 줄 알았다..)
내 시간표는 이랬었다.
- 10시 40분 건 듣다가 나왔고, (너무 당연한 얘기라서)
- 14시 강의는 못 들었고, (밥 먹느라..^^)
- 16시 40분 건 너무 좋은 강의였는데, 듣다가 졸아버렸다. (피로의 극한)
꿀팁아닌 꿀팁이라면, 나는 처음에 MSA나 TDD 쪽에 최근 관심이 있어서 들은 거였는데, 비슷한 이유로 신청하는 거라면 다시 한 번 생각해볼 필요가 있다.
아예 모르는 내용을 들어보러 가는 게 아닌, 나처럼 어느정도 공부를 해보고 가면 그냥 공부한 이야기 또 들으러 가는 셈이 된다.
애초에 인프콘이 완전 시니어 개발자들을 대상으로 진행하지 않기도 하고, 시간 제한이 있기 때문에 강연으로 전달할 수 있는 내용에 한계가 있기 때문이라 생각한다.
그리고 뻔한 주제들도 이미 잘 알려진 개발자 분들이 하면 색다른 내용들을 배울 수 있다는 걸 알게 되었다.
토비의 "스프링과 함께 더 나은 개발자 되기"는 편하게 들으려고 갔다가 제법 감명 깊게 들었었다.
자세한 내용은 밑에서 다루고, 처음 도착했을 때는 굿즈 지옥이 날 기다리고 있었다.
놀랍게도 왼쪽의 저 가방 전부 다 인프콘 도착하고 30분 만에 받은 것들이었다.
좀 웃긴 썰이 하나 있었는데, 지인 분이 휴대폰 배터리가 거의 다 떨어져서 근처의 무선 충전기를 돈 주고 빌렸는데
내가 그 다음 부스에서 바로 보조배터리를 경품으로 받아버렸다. ㅎㅎㅋㅋ
결국 보조배터리는 다른 지인분이 배터리 없다고 하셔서 유용하게 사용하셨다.
부스를 돌아다니면 스탬프를 찍어주는데, 이걸 다 모으면 중앙 인프콘 부스에서 총 3번 뽑기를 할 수 있는 기회가 주어진다.
내 앞에 계시던 분은 에너지바를 3개를 뽑아버렸다.
그런데 솔직히 배가 고프기도 했고 에너지바 걸려도 나쁘지 않겠다 싶은 마음으로 왔기에, 진행자 분께서 "어떤 걸 얻고 싶어요?"라고 여쭤보셨을 때, "배고파서 에너지바 하나라도 걸렸으면 좋겠어요"하고 뽑았는데
키링이랑 유리컵, 스티커를 뽑아버린 해프닝도 있었다.
(옆에서 좋은 것만 뽑았다고 축하해줬는데, 에너지바 찾던 미친놈이 접니다.)
참고로 굿즈 받으려면, 부스마다 있는 QR 찍고 구글폼 설문 or 문제 풀고 보여주면 된다.
제일 처음으로 카카오 페이 갔는데 제법 웃겨서 캡쳐했다.
아래는 강의 들으면서 내 나름대로 정리해본 건데, 진짜 이런 내용이구만 참고해보고 인프콘 강의 영상 찾아보는 게 훨씬 좋다.
그리고 나쁜 강의는 없었다. 단순히 좀 더 새로운 내용을 배우지 못해서 실망한 게 몇 가지 있을 뿐이다.
📌 오늘도 여러분의 API는 안녕하신가요?
개인적으로 큰 기대 안 하고 들어갔다가, 정말 유익하다고 느꼈던 강연. 다음 프로젝트에서 바로 써먹어볼 계획이다.
🟡 As-is
- 일관성 관리 비용 증가
- 만드는 사람에 따라 문서 작성 기준 달라짐
- 두 번에 걸친 번거로운 작성
- 설계용, 전달용
- 전자를 남겨두면 새로 투입된 개발자 혼란
- 코드 변경사항이 최종 반영되지 않은 경우
- 하다보면 휴먼 에러 발생
- API 문서 반영하는 거 잊어먹음
- FE와 불필요한 의사소통 증가
- API 변경 하항을 명세보다 코드 구현 작업에 중점을 두었기 때문이 아닐까?
- 서로 다른 api 경론데 중첨
- 같은 기능을 의미하는데 다른 용어
- BE와 FE 가 같은 용어를 말하는데 다른 코드를 사용하는 경우(UserDetail <-> UserInfo)
🟡 To-be. API FIRST DESIGN
- 계약서의 중요성을 인지하라
- API FIRST Design 정의하기
- 기준: OAS, Open API Specification
- 언어에 구애받지 않는다. HTTP API 표준 인터페이스
- Open API 명세 기반 API 구현을 1순위로 두는 것
- 프로세스
- fe와 be가 OPEN API 명세 작성
- 틀 작성
- 반복적 설계 (토론+공유)
- open API 구현
- API 문서, CODE GENERATORS, Mock server, api gateway
- 문서 전달
- Code first에서 Api first
- fe와 be가 OPEN API 명세 작성
- 이점
- 버전 관리
- 공통 API 문서를 통해 협업 가능 (명세가 불변하므로, SSOT "단, 하나의 진실 공급원"
- 이해 관계자들과 풍성한 내용이 담긴 Open API 개발이 가능하다
🟡 오해와 진실
- Swagger는 API 문서화 도구다?
- 문서화는 여러 기능 중 하나에 불과하다.
- Swagger는 어노테이션 기반이 아니라 OpenAPI 기반의 명세서를 목적으로 한다
- API First design은 한 번에 결정하는 것이다?
- 서비스 유지 관리하기 위한 핵심 기능이라 여겨라
- Codegen은 주어진 템플릿만 사용할 수 있다?
- swift github repo에서도 이거 쓴다. (그만큼 중요함)
- 개발자가 불필요하게 시간을 빼앗기던 서버코드, 클라이언트 코드를 굳이 작성하지 않아도 되므로 주요 관심사에 시간을 더 투자할 수 있다.
- 도커 명령어로 실행도 가능.
결론 : 백엔드 가르칠 때, 정신머리를 뜯어고쳐야 한다.
마지막 결론을 동아리 부원들한테 보여줬더니, 상당히 두려워 하더라..
📌 오늘의 TDD는 실패하셨군요? 내일은 가능할지도..?
- 일반적으로 문제를 접근하는 방법
- 울타리 밖의 고기를 먹기 위해 달려드는 강아지
- 어쩌다 성공해도 어떻게 해결했는지 기억하지 못한다.
- 문제 해결 = 바라는 것과 인식하는 것의 일치
- 이전에 풀어본 경험이 있는가?
- 다른 문제에도 적용할 수 있는가?
- 거꾸로 연구하기 (이거 완전 알고리즘 문제해결 전략..)
- 거꾸로 연구하기 (Ex. 9L, 4L 병으로 6L 채우기)
- 요구하고 있는 것으로부터 문제를 풀었다고 가정한다 (어떻게 x, 무엇을 o)
- 실패하는 테스트를 만든다
- '이렇게 되었으면 좋겠다'라는 테스트 케이스 작성
- 복잡한 목표는 모두 만들어져있다고 가정한다
- 해결 방법을 위한 전제 조건을 탐색한다.
- 일단 푼다. (흑마법까지 허용한다)
- 리팩토링한다.
- "기대하는 결과를 먼저 생각하라"
- 요구하고 있는 것으로부터 문제를 풀었다고 가정한다 (어떻게 x, 무엇을 o)
- 배워야 하는 이유
- 다른 이유가 많지만 본질적인 이유는 일종의 패턴의 구현체로서 인식할 수 있기 때문이라 생각한다.
후기: TDD 책 복습한 기분..
📌 점진적 추상화
하나의 예제에 추가되는 요구사항에 대해 매우 주관적인 입장에서 접근해보겠습니다.
추상화 방향 , 범위 , 시기 , 템플릿 순서
- Overall
- 가장 쉬운 조건문 분기 코드 작성
- OCP에 위배된다는 코멘트가 달림
- 타입을 축으로 추상화 (인터페이스 생성 -> 구현체 분리) => 제대로 했을까?
- 요구사항 살펴보기
- 조건문 코드
- 오히려 직관적일지도
- 추상화한 코드
- 인터페이스에 의존하는 하위 구현체가 영향을 받음
- 확장에는 열려있으나 인터페이스 자체를 변경하기가 매우 힘들다!!
- 이거 클린 코드에 나오는 내용이다. 문제를 해결하기 위해 자료구조가 필요한지, 행위를 담당하는 로직이 추가되어야 하는지에 따라 인터페이스를 만드는 게 반드시 좋다고 할 수 없다. 소프트웨어 발전방향과 일치하지 않는 추상화는 유지보수가 더 어렵다. => 구현과 소프트웨어 사이의 괴리 발생
- 조건문 코드
- 추상화를 좀 더 줄였다면?
- 분기가 필요한 부분만 분리했다면 더 직관적이고 간결했다.
- 인터페이스 자체의 변경 없이 구현체 내에서 분기 가능했다.
- 너무 넓은 범위를 추상화하면, 오히려 더 많은 비용이 들어간다. 필요한 만큼만 해라.
- 추상화 시기
- 운이 좋을 땐 구현체를 추가하는 것만으로도 요구사항에 대응할 수도 있다.
- 잘못하면 인터페이스를 갈아 엎어야 한다.
🟡 if. 문에 요구사항을 추가했다면?
- 직관적으로 3개의 영역으로 분리할 수 있다.
- 위 세 개를 하나의 인터페이스로 묶을 수 있다.
- 함수를 쪼갬으로서 조금 복잡해질 수는 있으나 효과적이다.
- 더 함축된 이름과 구체적인 이름을 지어 정보를 확실하게 전달된다. process -> deposit, withdrwa (트레이드 오프)
🟢 과거의 코드는 그 위치에 있다는 사실만으로 상당한 영향력을 가진다.
- 좋은 추상화는 더 많은 맥락 속에서 얻어진다.
- 새로운 서비스 개발하는 개발자보다 리팩터링하는 개발자가 더 많은 맥락을 얻을 수 있다.
- 클래스 추출에서 멈추는 것도 하나의 방법이 될 수 있다.
- 함수 분리부터 시작해보고, 적절한 시기에 클래스를 찾아보는 것도 좋다.(그런데 겁나 어렵다. ㅠ)
🟡 if. 환율 정보도 기입해야 하는 경우
- 파라미터도 추상화할 것인가? (미쳤냐?)
- 함수가 일급객체인 언어에선 함수를 통해 위 문제를 어느 정도 회피할 수 있다. (콜백 메서드 패턴)
핵심은 서둘러서 추상화하는 순간 나중에 망할 수도 있다...^^
추상화엔 분명히 비용이 있고, 방향, 범위, 시기를 고민하아.
함수를 추출하는 것부터 시작해서 점진적으로 해보라는 게 주된 내용이다.
📌 스프링과 함께 더 나은 개발자되기
공부 방법과 관련한 이야기가 주된 내용이었다.
처음에도 말했지만 정말 가벼운 마음(정 아니다 싶으면 수면 보충할 심산)으로 참가했는데, 최근의 내 공부 방법을 많이 반성하게 됐다.
물론, 갑자기 깨달은 건 아니고 ㅎㅎ 스스로 생각하기에도 요새 공부를 위한 공부가 아닌, 보이기 위한 공부를 하고 있는 듯한 느낌을 굉장히 많이 받고 있었다.
그렇지만 공부할 양이 너무 많았고, 어떻게든 하나라도 더 보기 위해 고군분투하다가 인프콘 강의를 들은 후 집에 와서 한 가지 생각을 해보았다.
"그렇게 열심히 해서, 내 머릿속에 남은 지식은 과연 얼마나 될까?"
이미 클린 코드를 공부하다가 세게 현타가 와서 내려둔 참이었지만, 다른 공부들도 다시 한 번 둘러보게 되었다.
내가 정리한 것들은 정말 내가 이해한 내용이 맞을까.
누군가 해당 내용에 대해 설명해달라고 하면, 나의 지식인 것처럼 설명할 수 있는가.
이런 질문들에 대한 답변을 스스로 할 수 없었기에, 지금부터라도 다시 바로 잡아야겠다는 생각이 들었다.
뭐든지 초조해지면 되던 것도 안 된다는 것을 상기할 수 있어 좋은 기회였다.
컨퍼런스 재밌긴 한데, 아무래도 뭔가 했다하면 죄다 서울에서 진행하니까 왔다갔다 하기가 너무 힘든 감이 있다.
그리고 내가 이런 행사를 잘 안 가려고 하는 이유가 하나 더 있는데,
새로운 기술을 향한 나의 지적 욕구가 감당이 안 될 정도로 너무 높다는 점이다.
조금만 흥미로운 내용을 보면 찍먹을 해봐야 하는데, 그 찍먹의 정도가 남들의 기준에선 너무 깊다고 한다.
여튼 그러다보니 몸이 10개라도 모자란 🐜친 스케줄이 탄생하게 되는데, 번아웃이 왜 안 오지..?
그래도 너무너무 좋은 경험이 되었던 인프콘 행사~
추첨에 붙어서 참가할 수 있어서 즐거운 기억을 쌓을 수 있게 되어 좋았다.