[2023년 회고] 주니어 개발자, 인프콘 다녀왔습니다!

📌  2023 INFCON 참가 후기

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

 

열정 많은 개발자들이 모인 현장의 에너지를 직접 느낄 수 있었습니다.
개발자로 일을 시작하고 처음 참가한 컨퍼런스라 더욱 특별했습니다.
전문가 강연, 네트워킹 프로그램, 기업 부스 참여 등 다양한 경험을 할 수 있었습니다.

✨ 팁: 아침 8시 50분에 도착했는데 이미 줄이 길었어요.
세션이 시작되는 10시 30분 전에 부스 체험을 마치고 여유롭게 세션을 듣는 것을 추천합니다.

---

📌 기억에 남는 세션

---

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

 

✅ 기존 API 개발 방식의 문제점

• 문서 작성 → 코드 구현 → 문서화 도구 이용 → API 문서 전달 방식으로 작업했는데 여러 문제가 발생했다
• 사용되지 않는 API가 방치되고, 엑셀·깃헙 위키 등 작성자에 따라 문서 형식이 달라져 일관성이 없었다
• 밑그림 API와 프론트 API가 중복 생성되어 신규 개발자가 혼란을 겪었다
• 문서화를 건너뛰고 구두 전달하면 최종 변경사항이 반영되지 않아 불필요한 의사소통이 발생했다
• 같은 기능인데 다른 경로(api/users/create, api/users/user)를 사용하거나, 같은 의미를 다른 용어(userdetail, userinfo)로 표현하는 문제가 있었다

✅ 해결 방법: API First Design

 

Open API Specification 명세서를 먼저 작성하는 방식이다. 언어에 구애받지 않는 HTTP API 표준 인터페이스다.

 

진행 순서:

1. Open API 작성
2. 토론 및 공유
3. 합의된 명세서 기반으로 API 도구를 활용해 구현 (Swagger, Code Generators, Mock Server 등)

✅ 장점

• API 계약서를 강제해서 일관된 품질을 만들 수 있다
• 문서를 두 번 작성할 필요가 없다
• 변경사항 발생 시 API 자체를 변경하면 문서 업데이트가 자동으로 된다
• 버전 관리 시스템으로 버전을 관리할 수 있다
• 단일진실공급원(SSOT)으로 이해관계자들이 같은 컨텍스트에서 협업할 수 있다
• 비즈니스 가치에 집중하고 이를 유지할 수 있다

 

---

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

✅ 프로그래밍의 본질

프로그래밍은 특정 문제를 해결하는 직업이다. 비즈니스는 문제를 해결하고 이익을 얻는 행위이므로 비즈니스 가치가 포함된다.

문제 해결 프로세스: 문제 이해 → 설계 → 구현 → 평가

현실 문제를 가상 컴퓨터에 구현하므로 설계 도식화가 필요하다. 시니어는 직관을 통해 빠르게 문제를 해결할 수 있지만, 경험이 잘못됐을 때 유연하게 대처하는 방법론 체득이 중요하다.

 

✅ 유연하게 해결하는 방법

 

1) 추상적, 구조적 사고

• 추상적 사고: 현실 세계에서 관심 있는 것을 단순화하여 재해석하는 것. 현상과 물체를 가능한 만큼 분해하고 의도와 목적을 가지고 결합한다. 적절한 추상화 수준을 정하는 것이 중요하다.
• 구조적 사고: MECE 프레임워크처럼 요소들을 중복 없이 배타적으로 나누고 채우는 것

접근 방법:

• 탑다운(하향식): 큰 문제 → 작은 문제
• 바텀업(상향식): 세부 문제 → 전체 문제

2) 모델링

비슷한 요소끼리 분류하거나 특정 기준으로 라벨링한다. 추상화와 구조화가 동시에 발생한다.

이미 추상화·구조화된 것을 다시 추상화·구조화할 수 있다.

 

3) 프레임워크 사고

같은 문제라도 어떤 프레임워크를 사용하는지에 따라 해결 방법이 달라진다.

 

✅ 소프트웨어 설계의 구성 요소

1) 도메인 모델링

현실 세계의 비즈니스 문제를 개발 세계 언어로 표현한다. 요구사항에서 키워드를 추출한다.

 

2) 아키텍처

개발자가 일하는 방법 - 어떻게 만들고, 어떻게 나눌 것인가. 요구사항과 조직, 플랫폼(모바일/웹/앱)에 따라 달라질 수 있다.
서브시스템·모듈·디렉토리 중 어떤 것으로 분리할지 결정한다. 아키텍처는 언제든 바꿀 수 있다.

 

3) 코드 작성

• 패러다임: 어떻게 추상화할 것인가. 패러다임은 컴퓨터가 아닌 사람을 위한 것이다.
• 로직: 어떤 기능, 어떤 관점(사용자/관리자), 공통 로직으로 구성
• 문법 설탕: 프로그래밍을 간결하게 표현하는 것. 합의되지 않은 문법 설탕은 독이 될 수 있다.

4) 리팩토링

패러다임, 코드 크기, 소유권, 중복 여부, 수정 가능성, 의존성을 고려한다.
코드 내용을 숨길지 드러낼지 결정하고, 수정 가능성이 높으면 의도적으로 분리한다.
공통 내용과 중복 코드는 분리하는 것이 좋다. 추상화·구조화·일반화 수준을 정하는 것이 리팩토링이다.

 

5) 도식화

UML 툴을 사용해보자. 직관은 빠르지만 위험할 수 있다.
패턴을 기억해두면 직관적 이해에 도움이 된다. 다만 꼭 추상적·구조적인 것만이 좋은 것은 아니다.

---

열정 많은 개발자들을 직접 만나 동기 부여를 얻었습니다!
완벽하게 이해하지 못한 부분도 많아 더 공부해야겠다고 느꼈습니다.
내년에는 더 성장한 모습으로 참가하고 싶습니다. 🍀