Review

[Review] INFCON 2023 후기

나죽못고나강뿐 2023. 8. 21. 17:03

아, 이거 대체 언제 다 쓰냐 ^^ 미치겠다. 공부할 게 너무 많아.

멘토링은 워낙 많이 다녀봐서 개발자 컨퍼런스는 어떤 내용을 다루는지 궁금해졌다.

주위에서 인프콘에 가보라고 권유를 많이 해주셔서 그냥 지원해놓고 잊고 있었는데, 얼떨결에 붙어버렸다.

웬일이지?

이런 거 하면 맨날 떨어지던데, 이번엔 또 어째 붙었다.

 

오전 10시부터 개회식이 시작된다길래, 10시 30분 쯤 도착하게끔 기차표를 예매했었는데 같이 가게 된 분이 그러다가 사람 몰린다고 해서 6시 30분 기차를 예매하게 됐다. (전날 대회 준비 때문에 2시간 자고 일어나는데 죽는 줄 알았다..)

 

내 시간표는 이랬었다.

  • 10시 40분 건 듣다가 나왔고, (너무 당연한 얘기라서)
  • 14시 강의는 못 들었고, (밥 먹느라..^^)
  • 16시 40분 건 너무 좋은 강의였는데, 듣다가 졸아버렸다. (피로의 극한)

꿀팁아닌 꿀팁이라면, 나는 처음에 MSA나 TDD 쪽에 최근 관심이 있어서 들은 거였는데, 비슷한 이유로 신청하는 거라면 다시 한 번 생각해볼 필요가 있다.

아예 모르는 내용을 들어보러 가는 게 아닌, 나처럼 어느정도 공부를 해보고 가면 그냥 공부한 이야기 또 들으러 가는 셈이 된다.

애초에 인프콘이 완전 시니어 개발자들을 대상으로 진행하지 않기도 하고, 시간 제한이 있기 때문에 강연으로 전달할 수 있는 내용에 한계가 있기 때문이라 생각한다.

 

그리고 뻔한 주제들도 이미 잘 알려진 개발자 분들이 하면 색다른 내용들을 배울 수 있다는 걸 알게 되었다.

토비의 "스프링과 함께 더 나은 개발자 되기"는 편하게 들으려고 갔다가 제법 감명 깊게 들었었다.

 

자세한 내용은 밑에서 다루고, 처음 도착했을 때는 굿즈 지옥이 날 기다리고 있었다.

현대 굿즈 클라스 덜덜

놀랍게도 왼쪽의 저 가방 전부 다 인프콘 도착하고 30분 만에 받은 것들이었다.

좀 웃긴 썰이 하나 있었는데, 지인 분이 휴대폰 배터리가 거의 다 떨어져서 근처의 무선 충전기를 돈 주고 빌렸는데

 

내가 그 다음 부스에서 바로 보조배터리를 경품으로 받아버렸다. ㅎㅎㅋㅋ

결국 보조배터리는 다른 지인분이 배터리 없다고 하셔서 유용하게 사용하셨다.

 

2층에서 받은 책에 적혀있던 문구

부스를 돌아다니면 스탬프를 찍어주는데, 이걸 다 모으면 중앙 인프콘 부스에서 총 3번 뽑기를 할 수 있는 기회가 주어진다.

내 앞에 계시던 분은 에너지바를 3개를 뽑아버렸다.

그런데 솔직히 배가 고프기도 했고 에너지바 걸려도 나쁘지 않겠다 싶은 마음으로 왔기에, 진행자 분께서 "어떤 걸 얻고 싶어요?"라고 여쭤보셨을 때, "배고파서 에너지바 하나라도 걸렸으면 좋겠어요"하고 뽑았는데

키링이랑 유리컵, 스티커를 뽑아버린 해프닝도 있었다.

(옆에서 좋은 것만 뽑았다고 축하해줬는데, 에너지바 찾던 미친놈이 접니다.)

 

너무 어려웠던 카카오 페이 문제 ㅎㅎ;

참고로 굿즈 받으려면, 부스마다 있는 QR 찍고 구글폼 설문 or 문제 풀고 보여주면 된다.

제일 처음으로 카카오 페이 갔는데 제법 웃겨서 캡쳐했다.

 

아래는 강의 들으면서 내 나름대로 정리해본 건데, 진짜 이런 내용이구만 참고해보고 인프콘 강의 영상 찾아보는 게 훨씬 좋다.

그리고 나쁜 강의는 없었다. 단순히 좀 더 새로운 내용을 배우지 못해서 실망한 게 몇 가지 있을 뿐이다.

 

📌 오늘도 여러분의 API는 안녕하신가요?

개인적으로 큰 기대 안 하고 들어갔다가, 정말 유익하다고 느꼈던 강연. 다음 프로젝트에서 바로 써먹어볼 계획이다.

 

🟡 As-is

  1. 일관성 관리 비용 증가
    • 만드는 사람에 따라 문서 작성 기준 달라짐
  2. 두 번에 걸친 번거로운 작성
    • 설계용, 전달용
    • 전자를 남겨두면 새로 투입된 개발자 혼란
  3. 코드 변경사항이 최종 반영되지 않은 경우
    • 하다보면 휴먼 에러 발생
    • API 문서 반영하는 거 잊어먹음
    • FE와 불필요한 의사소통 증가
    • API 변경 하항을 명세보다 코드 구현 작업에 중점을 두었기 때문이 아닐까?
  4. 서로 다른 api 경론데 중첨
  5. 같은 기능을 의미하는데 다른 용어
    • BE와 FE 가 같은 용어를 말하는데 다른 코드를 사용하는 경우(UserDetail <-> UserInfo)

 

🟡 To-be. API FIRST DESIGN

  1. 계약서의 중요성을 인지하라
  2. API FIRST Design 정의하기
    • 기준: OAS, Open API Specification
    • 언어에 구애받지 않는다. HTTP API 표준 인터페이스
    • Open API 명세 기반 API 구현을 1순위로 두는 것
  3. 프로세스
    • fe와 be가 OPEN API 명세 작성
      • 틀 작성
    • 반복적 설계 (토론+공유)
    • open API 구현
      • API 문서, CODE GENERATORS, Mock server, api gateway
    • 문서 전달
      • Code first에서 Api first
  4. 이점
    • 버전 관리
    • 공통 API 문서를 통해 협업 가능 (명세가 불변하므로, SSOT "단, 하나의 진실 공급원"
    • 이해 관계자들과 풍성한 내용이 담긴 Open API 개발이 가능하다

 

🟡 오해와 진실

  1. Swagger는 API 문서화 도구다?
    • 문서화는 여러 기능 중 하나에 불과하다.
    • Swagger는 어노테이션 기반이 아니라 OpenAPI 기반의 명세서를 목적으로 한다
  2. API First design은 한 번에 결정하는 것이다?
    • 서비스 유지 관리하기 위한 핵심 기능이라 여겨라
  3. Codegen은 주어진 템플릿만 사용할 수 있다?
    • swift github repo에서도 이거 쓴다. (그만큼 중요함) 
    • 개발자가 불필요하게 시간을 빼앗기던 서버코드, 클라이언트 코드를 굳이 작성하지 않아도 되므로 주요 관심사에 시간을 더 투자할 수 있다. 
    • 도커 명령어로 실행도 가능.

결론 : 백엔드 가르칠 때, 정신머리를 뜯어고쳐야 한다.

 

마지막 결론을 동아리 부원들한테 보여줬더니, 상당히 두려워 하더라..

 

📌 오늘의 TDD는 실패하셨군요? 내일은 가능할지도..?
  1. 일반적으로 문제를 접근하는 방법
    • 울타리 밖의 고기를 먹기 위해 달려드는 강아지
    • 어쩌다 성공해도 어떻게 해결했는지 기억하지 못한다.
  2. 문제 해결  = 바라는 것과 인식하는 것의 일치
    • 이전에 풀어본 경험이 있는가?
    • 다른 문제에도 적용할 수 있는가?
    • 거꾸로 연구하기 (이거 완전 알고리즘 문제해결 전략..)
  3. 거꾸로 연구하기 (Ex. 9L, 4L 병으로 6L 채우기)
    • 요구하고 있는 것으로부터 문제를 풀었다고 가정한다 (어떻게 x, 무엇을 o)
      • 실패하는 테스트를 만든다
      • '이렇게 되었으면 좋겠다'라는 테스트 케이스 작성
      • 복잡한 목표는 모두 만들어져있다고 가정한다
    • 해결 방법을 위한 전제 조건을 탐색한다.
    • 일단 푼다. (흑마법까지 허용한다)
    • 리팩토링한다.
      • "기대하는 결과를 먼저 생각하라"
  4. 배워야 하는 이유
    • 다른 이유가 많지만 본질적인 이유는 일종의 패턴의 구현체로서 인식할 수 있기 때문이라 생각한다.

후기: TDD 책 복습한 기분..

 

📌 점진적 추상화

하나의 예제에 추가되는 요구사항에 대해 매우 주관적인 입장에서 접근해보겠습니다.

추상화 방향 , 범위 , 시기 , 템플릿 순서

  1. Overall
    • 가장 쉬운 조건문 분기 코드 작성
    • OCP에 위배된다는 코멘트가 달림
    • 타입을 축으로 추상화 (인터페이스 생성 -> 구현체 분리) => 제대로 했을까?
  2. 요구사항 살펴보기
    • 조건문 코드
      • 오히려 직관적일지도
    • 추상화한 코드
      • 인터페이스에 의존하는 하위 구현체가 영향을 받음
      • 확장에는 열려있으나 인터페이스 자체를 변경하기가 매우 힘들다!!
      • 이거 클린 코드에 나오는 내용이다. 문제를 해결하기 위해 자료구조가 필요한지, 행위를 담당하는 로직이 추가되어야 하는지에 따라 인터페이스를 만드는 게 반드시 좋다고 할 수 없다. 소프트웨어 발전방향과 일치하지 않는 추상화는 유지보수가 더 어렵다.  => 구현과 소프트웨어 사이의 괴리 발생
  3. 추상화를 좀 더 줄였다면?
    • 분기가 필요한 부분만 분리했다면 더 직관적이고 간결했다. 
    • 인터페이스 자체의 변경 없이 구현체 내에서 분기 가능했다.
      • 너무 넓은 범위를 추상화하면, 오히려 더 많은 비용이 들어간다. 필요한 만큼만 해라.
  4. 추상화 시기
    • 운이 좋을 땐 구현체를 추가하는 것만으로도 요구사항에 대응할 수도 있다.
    • 잘못하면 인터페이스를 갈아 엎어야 한다.


🟡 if. 문에 요구사항을 추가했다면?

  • 직관적으로 3개의 영역으로 분리할 수 있다.
  • 위 세 개를 하나의 인터페이스로 묶을 수 있다.
  • 함수를 쪼갬으로서 조금 복잡해질 수는 있으나 효과적이다.
  • 더 함축된 이름과 구체적인 이름을 지어 정보를 확실하게 전달된다. process -> deposit, withdrwa (트레이드 오프)


🟢 과거의 코드는 그 위치에 있다는 사실만으로 상당한 영향력을 가진다.

  • 좋은 추상화는 더 많은 맥락 속에서 얻어진다.  
  • 새로운 서비스 개발하는 개발자보다 리팩터링하는 개발자가 더 많은 맥락을 얻을 수 있다.
  • 클래스 추출에서 멈추는 것도 하나의 방법이 될 수 있다.
  • 함수 분리부터 시작해보고, 적절한 시기에 클래스를 찾아보는 것도 좋다.(그런데 겁나 어렵다. ㅠ)


🟡 if. 환율 정보도 기입해야 하는 경우

  • 파라미터도 추상화할 것인가? (미쳤냐?)
  • 함수가 일급객체인 언어에선 함수를 통해 위 문제를 어느 정도 회피할 수 있다. (콜백 메서드 패턴)

핵심은 서둘러서 추상화하는 순간 나중에 망할 수도 있다...^^
추상화엔 분명히 비용이 있고, 방향, 범위, 시기를 고민하아.
함수를 추출하는 것부터 시작해서 점진적으로 해보라는 게 주된 내용이다.

 

📌 스프링과 함께 더 나은 개발자되기

공부 방법과 관련한 이야기가 주된 내용이었다.

처음에도 말했지만 정말 가벼운 마음(정 아니다 싶으면 수면 보충할 심산)으로 참가했는데, 최근의 내 공부 방법을 많이 반성하게 됐다.

 

물론, 갑자기 깨달은 건 아니고 ㅎㅎ 스스로 생각하기에도 요새 공부를 위한 공부가 아닌, 보이기 위한 공부를 하고 있는 듯한 느낌을 굉장히 많이 받고 있었다.

그렇지만 공부할 양이 너무 많았고, 어떻게든 하나라도 더 보기 위해 고군분투하다가 인프콘 강의를 들은 후 집에 와서 한 가지 생각을 해보았다.

"그렇게 열심히 해서, 내 머릿속에 남은 지식은 과연 얼마나 될까?"

 

이미 클린 코드를 공부하다가 세게 현타가 와서 내려둔 참이었지만, 다른 공부들도 다시 한 번 둘러보게 되었다.

내가 정리한 것들은 정말 내가 이해한 내용이 맞을까.

누군가 해당 내용에 대해 설명해달라고 하면, 나의 지식인 것처럼 설명할 수 있는가.

이런 질문들에 대한 답변을 스스로 할 수 없었기에, 지금부터라도 다시 바로 잡아야겠다는 생각이 들었다.

 

뭐든지 초조해지면 되던 것도 안 된다는 것을 상기할 수 있어 좋은 기회였다.

 

컨퍼런스 재밌긴 한데, 아무래도 뭔가 했다하면 죄다 서울에서 진행하니까 왔다갔다 하기가 너무 힘든 감이 있다.

그리고 내가 이런 행사를 잘 안 가려고 하는 이유가 하나 더 있는데,

새로운 기술을 향한 나의 지적 욕구가 감당이 안 될 정도로 너무 높다는 점이다.

 

조금만 흥미로운 내용을 보면 찍먹을 해봐야 하는데, 그 찍먹의 정도가 남들의 기준에선 너무 깊다고 한다.

여튼 그러다보니 몸이 10개라도 모자란 🐜친 스케줄이 탄생하게 되는데, 번아웃이 왜 안 오지..?

 

그래도 너무너무 좋은 경험이 되었던 인프콘 행사~

추첨에 붙어서 참가할 수 있어서 즐거운 기억을 쌓을 수 있게 되어 좋았다.

저작자표시 비영리