2023 INFCON

꼭 가고싶었던 IT 콘퍼런스인 2023인프콘에 다녀왔습니다!❤️

📍 열정많은 개발자분들이 많다는 것을 몸으로 마음으로 느낄 수 있었습니다.

📍 개발자들에게 전문가 강연도 듣고 네트워킹 프로그램도 참여했습니다. 많은 기업들이 참여해 채용 관련 정보도 얻을 수 있었고 이벤트로 상품도 받는 등 신선한 경험을 한 컨퍼런스였습니다.
개발자로 일을 시작하고 처음으로 참가한 컨퍼런스라 기분이 색달랐습니다.

📍 아침 8시 50분쯤 도착했고 이미 줄이 길게 서있었습니다. 세션이 시작되면 부스에 참가하기 어렵기 때문에 세션이 시작되는 10시 30분 전에는 부스 체험을 마치고 세션을 여유롭게 듣는 것을 추천합니다.

📍기억에 남는 세션인 두개를 정리해보려고 합니다.

1. 당신의 API는 안전하십니까(김정규, 우아한형제들)

📌효율적인 api 문서 관리의 중요성을 느낀 계기

이전 : 문서 작성 - 코드 구현 - 문서화 도구 이용 - api문서 전달
방식으로 api 작업을 수행하고 있었다.
이 과정에서 다양한 문제점을 느꼈다.

📌발생한 문제점

1. api 설계시 사용되고 있지 않은 api 방치하는 문제점이 생겼다.

2. 일관성 없는 api 설계 문서는 관리하는데 힘들고 관리 비용이 든다.
   또한 엑셀, 깃헙 위키 등 만드는 사람에 따라 설계 문서가 달라져서 일관성 없는 api문서 만들어 낸다.

3. 밑그림 api, 프론트 api 두개가 생겨서 밑그림은 나중에는 지워야지 하고 남겨놓은 적이 있다.
   -> 신규개발자가 어떤게 정확한지 몰라 혼란스러운 문제가 생긴다.

4. 또한 문서화 도구 이용은 skip하고 구두 전달한 경우 최종 변경사항이 api문서에 반영되지 않아 불필요한 의사소통 하는 경우 발생했다.

5. 서로 다른 api path지만 결과적으로 같은 기능 - 다른 형태 api지만 모두 같은 기능.. api/users/create api/users/user

6. 의미하는 바는 같은데 사용되는 용어가 다른 문제점 발생한다. userdetail 프론트는 userinfo 이렇게

📌해결 방법 : api first design

1. open api 기반 api 계약서 우선으로 계약해 설계하는 것
2. 기준되는 open api specification 명세서를 작성한다.
3. 언어에 구애받지 않는 http api 표준 인터페이스이다.

api first desgin 으로 문제 해결하기

oepn api 작성 -> 토론, 공유 -> 정해지면 기반으로 api도구 활용해 구현한다.
(api문서 - swagger, html,,, code generators- server implements client implement, mock server, api gateaway)

api 계약서 먼저 작성하고 도구 사용해 코드 구현하는게 기존 방식과 가장 큰 차이점

📌장점

1. api 계약서 강제해서 일관된 품질 만들 수 있음
2. 2번에 걸치지 않고 작성할 수 있음
3. 변경사항이 생기면 api를 자체 변경해서 문서 업데이트 불필요하다.
4. version 값을 변경해서 버전관리시스템으로 버전을 관리할 수 있고 공통 api문서로 같이 협업할 수 있다.

5. 워드, 엑셀 혹은 코드 기반의 스프링 api문서를 사용했을 때는 시간이 지나면서 동기화된 문서 보장이 어려운데 이 디자인은 계약서를 수정할때 서비스 개발자들도 수정하기 좋고 타 서비스 개발자도 인지가능해서 결과론적으로 원소스 멀티유징이 가능하다.

6. 이해 관계자들과 context 맞추면서 함께 서비스 만들어간다는 의미를 느낄 수 있다.

단일진실공급원

1. 서로 다른팀, 서로 다른 시스템, 그 중 하나의 진실
   단일진실공급원의 역할이 api명세서 (ssot)이다.

2. swagger는 open api기반의 문서이다.
   비즈니스 가치에 집중하는 것 , 단순한 일회성이 아니라 비지니스 가치 유지하기 위한 것이다.

3. 코드젠은 주어진 템플릿만 사용할 수 있다 -> 오해

-> 결국 api first desgin을 새롭게 시작하는 프로젝트에서 시작할 수 있을 것이다. 여러분이 직접 증명해라

2. 소프트웨어 설계 : 이선협 (주식회사 코발트)

📌프로그래밍

1. 프로그램 결과를 이루기 위해 실행하는 계획 - 프로그래밍은 특정 문제를 해결하기 위해 - 문제해결하는 직업

2. 문제를 해결한다는 것?

• 비즈니스는 문제를 해결해주고 이익을 얻는 행휘이므로 비지니스 가치가 포함되는 개념이다. 이익에는 사회적 가치도 포함된다.

3. 문제 이해 -> 설계 -> 구현 -> 평가로 구성되어있는데
   "현실 문제"를 "가상 컴퓨터"에 만드므로 그에 따른 설계 도식화가 필요하다.

4. 설계는 설계와 코드로 나타내는 단계에 중첩되어있다.

5. 시니어는 직관 통해 문제 빨리 해결 가능, 경험 잘못됐을때 - 유연하게 해결하는 방법론 체득이 중요하다.

빠른 적응하는 방법론을 해결해야한다.

📌유연하게 해결하기

1. 추상적, 구조적 사고

추상 -> 공통되는 특성 추출

📍추상적 사고

1. 현실세계에서 관심있는 것을 단순화 재해석한 것이다.
2. 현상 물체를 가능한만큼 분해하고 의도와 목적을 가지고 결합
3. 무의미한 분해는 의미가 없다.
4. 코드에서 긴 프로세스를 하나의 함수로 묶는 것과 유사하다.
5. 적절한 추상화 수준을 정해야한다.

📍구조적 사고

1. 빈틈없이 정리하는 것
2. MSCE 프레임워크 요소들이 중복없이 배타적으로 어떻게 나누고 채울 것인가가 중요하다.

📍구체적인 방법

1. 탑다운, 바텀업 : 문제 해결 접근 두가지 방법
   큰 문제 -> 작은문제 (하향식접근법)
   세부문제 -> 전체문제(상향식접근법)

2. 모델

• 모델링 -> 분류(비슷한 요소끼리 아니면 혹은 라벨링이나 태그같이 특정한 기준으로)
• 추상화 구조화 동시에 발생한다.
• 추상화(관심있는 것을 뽑아낸다. 요소를 계층으로 나누거나), 일반화 (여러 사물 공통점을 묶는다.) 부모클래스 묶는 것 같음
• 이미 추상화, 구조화된것을 다시 추상화, 구조화할 수 있다.

3. 프레임워크 사고

1. 틀에 맞춰 작업을 한다.
   같은 문제더라도 어떤 프레임워크인지에 따라 해결방법이 달라진다.

2. 초기 사용자 스토리, 제목 각자 생각한 스토리 포인트, 다시 측정한 스토리 포인트 등등 회사 내 프레임워크 작성한다.

문제 정의를 분석해서 의미있는 정도까지 결합한다.

4. 소프트웨어 설계

소프트웨어 설계는
도메인 모델링, 아키텍처, 코드 작성 으로 구분해서 볼 수 있다.

4.1. 📍도메인 모델링

1. 문제는 현실 세계의 비즈니스이다.
   도메인 모델링은 비즈니스를 개발 세계 언어로 표현해야한다.

요구사항, 추가 요구사항에서 키워드를 뽑아낸다.

4.2. 📍아키텍처

1. 개발자가 일을 하는 방법 - 어떻게 만드는가, 어떻게 나누는가
   아키텍쳐는 요구사항과 조직에 따라 달라질 수 있다. 모바일 웹 앱인지에 따라서도 달라진다.

2. 구분

• 컨셉아키텍쳐

• 구현 아키텍쳐 - 하향식, 하향식 아케틱처 모델링 할 수 있다. - 어떻게 일할 수 있는지
  3개의 서브시스템, 모듈, 디렉토리중 어떤 것으로 분리할 것인가?

• 조직 상황 따라 분리

아키텍처는 언제나 바꿀 수 있다.

4.3. 📍코드 작성

코드 작성시

패러다임 - 인식체계
패러다임 어떻게 추상화 할 것인가
패러다임은 컴퓨터말고 사람을 위한 것
순차, 분기, 반복, 참조로 모든 프로그램이 구성된다.
객체지향 패러다임

4.3.1. 📍로직

어떤 기능, 어떤 관점(사용자/관리), 로직 구성함수(공통적으로 사용되는 로직)

문법 설탕 - 프로그래밍 간결하게 표현한 것

합의되지 않은 문법 설탕은 독이 될 수 있다.

4.3.2. 📍리팩토링

패러다임, 코드크기, 소유권, 중복 여부, 수정 가능성, 의존

4.3.3. 📍추상화, 구조화, 일반화

1. 코드 내용 숨길지 적나라하게 드러낼지 결정한다.

2. 분리할 것인지 합칠 것인지 결정하는데 수정 가능성 높으면 의도적 분리하기

3. 공통 내용 분리, 의도적 분리, 중복 코드가 있다면 분리하는 것이 좋다.

-> 추상화, 구조화, 일반화 수준 정하는 것이 리팩토링이다.

4.4.4. 📍도식화

-> UML 툴 사용해보자.
직관은 빠르지만 위험할 수 있다.
패턴을 기억해두면 직관적 이해하는 것에 좋다.

꼭 추상적 구조적이 좋은 것은 아니다.

---

열정 많은 개발자분들을 직접 만날 수 있어 동기 부여를 얻었습니다.
완벽하게 이해하지 못한 부분도 많아서 공부를 열심히 해야겠다고 느낀 컨퍼런스였습니다.
내년에도 참석하고 싶습니다. 더 성장한 모습으로 참가할 수 있기를! 💘🫡