좋은 기회로 유스콘 오프라인 행사에 다녀올 수 있었습니다.
많은 인사이트와 동기부여를 얻을 수 있었던 좋은경험이었기에, 짧게남아 글로 남겨보고자 합니다.
서론
유스콘을 처음 알게된것은, 여러군데 들어가있던 개발 오픈단톡방 중 1곳이었습니다.
소수의 인원만이 존재했던 한 오픈채팅방에서 한분이 유스콘 발표를 한다는 말을 꺼내셔서 처음 알게되었습니다.
→ 이후, 지인의 유스콘 오프라인 신청 권유, ATDD 슬랙방의 홍보, 다른 단톡방에서의 언급 등등으로 생각보다 큰 행사임을 깨달았고, 오프란인 참가 자격을 얻어 다녀왔습니다. (300명이 지원했고 140여명이 오프라인 참가자격을 얻었다.)
"주니어 개발자가 발표하는 컨퍼런스" 라는 키워드에서, 나와 비슷한 연차의 사람들이 이런 무대에서 발표도 할수 있구나,, 라는 생각에 굉장히 흥미로웠습니다.
발표는 트랙1과 트랙2 로 나뉘어, 동시간대에 2가지 세미나를 청강할 수 있었습니다.
제가 참가한 트랙은 아래와 같고 인상깊었던 부분에 대해서만 솔직하게 정리해보고자 합니다.
- 성장해서 서비스를 만들려고 했다가, 서비스를 만들면서 성장한 이야기 - 이현호님
- 그렇게 개발자가 된다. - 박경태님
- ELK 스택을 활용해 통계성 데이터를 제공하는 API 구현하기 - 유기성님
- 함께해요 멀티 모듈 - 정명구님
- 너 납치된거야 (feat. DevOps) - 김보경님
- 복잡함은 끝, 간결함의 시작 : 버티컬 슬라이스 아키텍쳐 - 이중석님
+ 1시간 가량의 시니어 분들과의 수다 타임 (with. 부릉, LG 유플러스, 모두의 프린터(피로곰), 당근마켓, 토비님)
오프라인 장소는 우아한 형제들 테크살롱에서 진행되었습니다 (좋더라고요 ㅎㄷㅎㄷ)
성장해서 서비스를 만들려고 했다가, 서비스를 만들면서 성장한 이야기 - 이현호님
첫번째 트랙이기도 하고, 발표를 굉장히 잘하셔서 기억에 남았습니다.
이현호님은 개발자리라는 유튜브 채널을 운영하고 계시고 10여개의 ios 어플을 배포한 경험이 있다고 하셨습니다
발표 내용
- 발표자님의 성장 스토리를 듣는 기분이었습니다.
- 컴공 전공자이시고, 당장 사용하지 않는 많은 CS와 지식들을 공부하던 학습방법에 지쳤던 경험들을 이야기하실 때 저도 컴공으로써 공감이 많이 되었습니다.
- 언제가는 쓰이게되지 않을까? 라는 관점의 지식의 사냥(무작위 학습)은 결국 필요할때 필요한 지식이 되어주지 못한다.
- 개발을 위한 공부가아닌 → 공부를 위한 개발이 되어야한다. (공부를 하고 개발 X → 개발을 해보고 모르는걸 공부 O)
학습 곡선
- 문제를 먼저 정의하고
- 문제해결을 위한 지식, 기술을 습득하고
- 이후 배운것을 정리하자
- 이렇게 나의 책갈피를 만들어가면 이게 추후에 어떠한 것이든 결과물로 돌아와 준다.
Q&A
- 좋은 개발을 적용한다고 해서 좋은 서비스가 나오는가? 에 대해서 한번 더 생각해 보자
- 어떤 지식을 습득했을 때, 성장이 고민되어진다면 먼저 지저분하게 만들고 문제를 발견해서 개선하는 경험을 해보는게 어떤가?
- (개인 질문 - 현재 내 상황에서 고민중인 부분을 따로 찾아가서 질문드림)
서비스의 데드라인은 항상 잡고 기획을 짜시는지, 데드라인을 정했지만 계속 미루어질 때 어떻게 하셨는지?- 데드라인은 무조건적으로 지킬려고한다.
- 지킬 수 있는 데드라인을 정해야하고, 그걸 잘 못하기 때문에 주니어인 것
- 데드라인이 정해졌다면, 완벽한 서비스를 만들려고 하지말고 배포할 수 있는 만큼의 작은 서비스를 완성하고 개선해보시는게 어떠신가요~ 라는 답변을 받았습니다
그렇게 개발자가 된다. - 박경태님
제일 좋았습니다.
이 발표도 경태님의 성장 곡선에 대한 발표 느낌을 받았습니다.
발표 내용
- 가수는 언제부터 가수인가? 개발자는 언제부터 개발자인가?
- 조직의 구성원이 된다는 것은 사소한 것 어떤 것이든 문화를 나누고 만들어갈 때 진정한 조직원이 된다.
- 포비(자바지기 - 박재성님) : 문화를 만드는 것은 리더만의 일이 아니다.
- 개인적으로 이렇게 유스콘에 발표를 하는 것도, 혹은 들으러 오는 것도 문화에 기여한 것이라고 생각함
- 경태님은 3.5개월 국비교육을 들은 후, SI 회사로 들어가 혼자 모든 일을 하셨다고 함
- 엉덩이로 개발했고, 혼자 일했지만 마치 팀원이 있는것처럼 문화를 만들어 갔다고 함
- 작은 업무를 대하는 태도와 변화가 ➡️ 좋은 결과를 가져오더라
- 내 위치에서 할 수 있는것을 하자
- 내가 지금 6을 알고있다면, 3,4 혹은 5를 알고있는 사람에게는 6,7을 알려줄 수 있다.
- 모든 경험에는 배울 점이 있다. 받아들이는 마음을 달리해보자
→ 아버지는, 아이가 세상에 나왔을 때부터 아버지가 되는게 아니라
아이를 키우면서 아버지가 된다.
Q&A
- 문화를 만들고 전파할 때, 팀원을 설득할때는 관심을 먼저 끌어보자 - 후킹 포인트를 먼저 던지고, 준비한 것을 준다.
- 경태님은, 인수테스트 기획자분들이랑 같이하면 진짜 좋데요~ 관심있으세요? 사실 제가 자료 다준비했어요~ 식으로 설득하신다고 함
- 설득은 무조건 공식문서에서 한다. 그것이 아니라면 권위에서 나오는 설득이 될 뿐이다.
(유명한 사람이 한 말, 블로그 글)
함께해요 멀티 모듈 - 정명구님
핸즈온 세션이지만, 노트북을 가져가지 않아 열심히 듣고 기록만 했었습니다.
멀티모듈에대한 키워드만 알다가, 어떤것인지 개념과 적용 방법에 대해 정말 기초부터 알 수 있어서 좋았습니다.
멀티모듈이란 이런것이 이렇게 적용한다는 것을 알았으니 추후에 직접 해보자!
아래 레포지토리에서 참고 가능하고 브랜치멸로 step1,2,3 순서대로 진행되었습니다.
https://github.com/dding94/youthcon23
GitHub - dding94/youthcon23: 함께해요 멀티모듈
함께해요 멀티모듈. Contribute to dding94/youthcon23 development by creating an account on GitHub.
github.com
발표 내용
- 멀티 모듈에 대한 이해
- 멀티 모듈이란, 한 프로젝트에 많이 사용되는 외부 의존성을 모듈화 하는 것
- 각 모듈은 최소한의 의존성을 가지도록 설계
- 모듈화를 통해서 책임과 기능을 분리할 수 있음
- 멀티 모듈의 설계에 대해서
- 멀티 모듈 장점 (외부 의존성의 관리)
Q&A
- 멀티모듈을 설계할 때는 항상 추이 종속성을 생각해야한다 → 멀티모듈은 오히려 관리포인트의 증가로 이어질 수 있다.
- 섣부른 멀티모듈은 오버 엔지니어링이 될 가능성이 크다.
- 멀티모듈을 적용하는 시점은, 멀티 모듈을 적용했을 때 관리하는 포인트가 더 적어진다고 느껴지는 시점
- EX - API 서버와 동떨어진 배치 프로세스작업을 할 때, 어떤 서드파티 작업을 진행할 때
복잡함은 끝, 간결함의 시작 : 버티컬 슬라이스 아키텍쳐 - 이중석님
가장 신선했던 발표 👍
이중석님은 백명석님이 CTO로 계시는 케이타운포유의 근무하십니다.
인프런에 무료 TDD 강의도 굉장히 인상깊게 봤었고, 종종 유튜브에서 라이브 코딩하는 것을 본적이 있어 개인적으로 되게 기대가 되었던 세션이었습니다. (잘생기고 몸이 진짜 좋으심)
발표 내용
- 버티컬 슬라이스 아키텍쳐란
- 하나의 클래스에 API 수신, 송신 비지니스 로직을 담음 (Controller 하나에 비지니스 로직을 때려 넣음)
- Controller 와 서비스가 합쳐진 레이어드 아키텍쳐라는 느낌을 받았다.
- 버티컬 슬라이스 아키텍쳐를 적용한 이유
- 기존에는 헥사고날 아키텍쳐를 적용해서 프로젝트를 진행함
- 신규 서비스를 개발하는데 있어, 개발자, 기획자 모두 도메인에 대한 이해도가 부족하다보니 작업이 진행되고 도메인 이해도가 늘어갈 수록 보이지 않던 문제점이 보임
- → 기획의 수정으로 이어짐
- 헥사고날 아키텍쳐는 너무 많은 클래스를 수정해야하므로 빠른 피쳐를 요구하는 신규 서비스에는 적합하지 않다고 생각함
- 수시로 변하는 요구사항과 기획에 빠른 대처가 가능해짐
- 단 버티컬 슬라이스 아키텍쳐는, 자칫 잘못하다가 스파게티 코드가 될 수 있음.
- 버티컬 아키텍쳐를 가지지만, 여기도 어느정도 룰과 규칙을 정해야함을 발표를 들으면서 느낌
Q&A
완전히 새로 접한 내용이라, 발표때 다른분들이 했던 질문은 기억이 나지 않습니다...
한참 생각하고 고민하다가 따로 찾아가 드렸던 개인 질문들입니다.
- 질문) 코드의 재사용성을 고려했을 때, 버티컬 슬라이스 아키텍쳐를 적용하는 것 보다 단순한 레이어드 아키텍쳐를 적용하면 더 좋지 않을까요?
- 답) 비지니스 로직을 재사용한다는 상황에서 설계에 대해 다시 고민해볼 수 있는 지점이라고 생각한다.
비지니스 로직을 도메인이 가져간다면, 비지니스 로직이 중복될 일이 없다.
- 답) 비지니스 로직을 재사용한다는 상황에서 설계에 대해 다시 고민해볼 수 있는 지점이라고 생각한다.
- 질문) 버티컬 슬라이스 아키텍쳐를 적용한다면, 결국 멀티모듈과 같이 패키지가 단일 도메인 위주로 분리될 거 같은데
2개 이상의 도메인을 참조하는 비지니스 로직을 가지는 새로운 도메인은 패키지의 설계를 어디로 두어야하나요?- 답) 이것도 고민했던 부분인데, 버티컬 슬라이스 아키텍쳐가 적용되는 부분 자체가 굉장히 단순한 비지니스 로직을 가져가는 부분들에만 적용을 했다.
- 답) 패키지 의존성을 단방향으로 설정하면 좋지만, 트레이드 오프를 생각했을 때 어느정도 허용하고 개발 편의성을 올리는 방향으로 설계했다.
- 추후, 서비스가 커졌을 때 버티컬 슬라이스 아키텍쳐로 설계했던 부분을 다시 헥사고날 아키텍쳐로 리펙토링 할 것인가?
- 답) 아니다. 추후 리펙토링을 하더라도 헥사고날로는 돌아가지 않을 것 같다.
- 차라리 레이어드 아키텍쳐를 적용할 것 같다.
느낀점
- 버티컬 슬라이스 아키텍쳐를 사용할려면 팀원 모두가 클린코드에 대한 이해도가 상당해야하고, 코드 리뷰문화가 필수로 있지 않으면 적용하기 힘들 것 같다는 생각이 들었습니다.
- 또한, Rich Domain 위주의 DDD 구조도 이해하고 있어야한다고도 생각이 들었습니다
- 도메인의 순수성 vs 완전성에 대한 호불호가 있는 만큼 올바른 적용 상황을 잘 판단해야겠다는 생각도 들었습니다.
수다 타임
모든 세미나가 끝나고, 이렇게 시니어 개발자 5분과의 질의 응답 시간이 있었습니다.
- 김태일님 (부릉 본부장)
- 심근우님 (LG 유플러스,컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커의 저자)
- 전홍님(피로곰, 모두의 프린트)
- 박용권(당근마켓) 이일민님(토비님)
유스콘에 끝까지 참석하신 분들이 오픈톡방에 질문을 올리면 답변을 해주시는 방식으로 진행되었고,
전체적으로 유쾌하고, 솔직한 답변을 들을 수 있어서 이 시간도 신선한 기억으로 남아있습니다.
📌 가볍게 들어서, 기록을 하거나 디테일하게 기억이남지는 않지만
1시간 가량의 대화에서 개인적으로 5분에게 느껴졌던 것이 있었습니다.
- 개인의 성장도 중요하지만, 삶의 우선순위가될 정도로 중요한가
- 성장을 위한 환경을 찾기보다, 정말 지금 환경에서 성장할 수는 없는가에 대해 생각해보자
- 개발자는 서비스를 만드는 사람, 좋은 개발보다는 좋은 서비스가 우선이 아닐까?
지금은 퇴사하신 전 팀장님도 가끔 이것과 비슷한 뉘앙스의 조언을 해주신적이 있었는데
다시한번 "나는 어떤 개발자가 되어야 하는가" 에 대해 생각하게되는 시간이었습니다.
마무리
처음 유스콘을 시작할 때. 오픈 연설(?)을 짧게 해주셨는데 그말이 아직까지도 참 좋은 울림으로 남아있다.
"다른 컨퍼런스는 듣는이를 위한 무대이지만, 유스콘은 발표자를 위한 무대입니다. 여러분들은 들러리이고 박수 많이 쳐주시면 감사하겠습니다!"
✔️ 발표를 해보고싶은데 무선운 사람을 위한 무대! 유스콘!
✔️ 발표자를 위한 컨퍼런스!
너무 신선한 문장이었고, "이런 분들의 도움아래에 컨퍼런스 발표 경험을 할 수 있다면 나도 도전해 볼까?" 라는 용기도 조금 생겼다.
업계에 선한 영향력을 행사하기위한 노력과 생기있는 기운이 느껴졌다.
이렇게 선한 영향력을 행사하는 분들을 볼 때마다, 참 대단하고 이런 네트워크를 가지는 개발업계가 점점 더 좋아질려고한다.
내가 돈, 인정, 성장, 성취감이 아닌 단순한 재미를 위해 개발을 할 수도있겠다. 라는 생각이 들었다.
이런 업계라면 조금 더 네트워크에 적극적으로 참여해보고, 문화에 기여해 볼 수 있도록 움직여봐도 괜찮지 않을까..?
아무튼 많은 동기부여와 좋은 인사이트를 얻을 수 있어서 보람찬 시간이었다!
내년에도 발표를 하든 참가를 하든 하자!
'회고 > 일상 후기 회고' 카테고리의 다른 글
| [회고] "간헐적 메모리 장애" 삽질부터 트러블 슈팅까지 (8) | 2023.11.02 |
|---|---|
| 넥스트스텝 ATDD with Spring 수료 회고 (0) | 2023.08.21 |
| 2022년 회고. 26살, 내가 개발자가 되기까지의 기록 (7) | 2023.01.25 |
| 모의면접 (0) | 2021.12.04 |
| 데브코스에 떨어졌다. 나만의 일정을 계획하자 (0) | 2021.07.28 |