프콘이 선정이 딸이에요
대학도 삼수를 안 했는데 인프콘은 매년 떨어졌다. 무려 삼수까지 와버린 인프콘. 올해도 역시 안 되겠거니 하며 인프콘을 신청했다. 목요일에 선정 결과가 나온다는 문장을 보고 기대도 하지 않았다. 너무 당연하게 떨어질거라 생각했다. 놀라운 점은 떨어져도 타격이 없었다.
백수로 즐겁게 살던 중 인프런에서 카톡이 왔다. 시간을 보니 2시였다. 뭐 또 탈락했겠군? 하고 카톡을 봤는데?
프콘이, 선정이 딸이에요.
인프콘에 선정되었다. 로또를 하면 당첨 숫자를 모두 피해가고 뽑기를 하면 꽝이 나오던 내가, 인프콘이라니? 당첨돼서 너무 기쁜 마음에 친구한테 선정됐다고 바로 연락을 했다.
근데 생각해보니 친구도 인프콘을 신청했다. 만약 친구가 선정되지 않았다면? 속히 말하는 넌씨눈 짓을 한 것이나 다름 없었다. 기쁨을 꽉 눌러 담고 친구의 연락을 기다리는데...
대박. 그렇게 친구와 같이 가게 되었다. (겉절이는 나다. 친구는 묵은지.)
아침에는 0개 오후에는 3개인 것은?
고 코엑스
인프콘을 기다리는 동안 친구와 들을 세션을 미리 정했다. 기다리는 과정이 너무 즐거워서 아이돌 콘서트를 가는 기분이었다. 전날에는 점심, 저녁 해결을 위해 근처 음식점들을 예약하기도 했다.
그리고 9시에 코엑스에 도착! 너무 배고파서 몇년만에 맥모닝을 먹었다. 음~ 굿..
친구가 사진을 찍자해서 찍었는데 걍.. 자기 마음대로 찍었다. 난 잘 찍어줬는데 웃기는 친구다.
우리는 가자마자 기업부스를 돌며 굿즈를 털었다. 무신사 쪽에는 처음부터 줄이 길어서 다른 곳부터 돌고 무신사에서 기다렸다.
무신사 무려 30분을 기다렸구요..? 굿즈 결과는요?
하하! 무신사 옷을 받을 수 있었다. 물론 친구는 꽝 ^^.
위로 차원으로 그 주에 손가락을 크게 베여서 액땜한 덕분이라고 했다.
세션
세션이 시작할 때가 되어 우리는 기업 부스를 포기하고 세션을 들으러 갔다. 나의 체력 이슈 때문이기도 했다. 그래, 난 오래 서있으면 죽는 병에 걸렸다.
지속성장 가능한 설계를 만들어가는 방법
우리가 선택한 첫번째 세션은 재민님의 지속성장 가능한 설계를 만들어가는 방법 이다. 재민님의 유튜브는 이미 구독하고 있었는데 그 분인지 그때 알아서 헉, 했다.
첫번째 세션을 정리하자면 아래와 같은 문장으로 요약할 수 있겠다.
설계를 잘 하는 방법은 설계를 하지 않는 것이다.
듣자마자 나도 모르게 노트북으로 ?를 쓰고 친구를 쳐다보니 친구도 똑같은 얼굴이었다. 역시 주니어에겐 어려운 설계의 세계...
그럴 줄 알았다는 듯, 재민님은 개념과 격벽이라는 개념으로 세션을 풀어나가셨다. 자신의 경험을 단어로 함축해서 청자들에게 이해시키는 과정이 솔직히 놀라웠다. 그리고 세션에서 강조하신 내용 중 가장 인상 깊었던건
성급한 설계하지마라. 과하게 설계하지마라. 필요한만큼만 설계해라.
라는 느낌의 말씀이었다. 주변에 취미로 소설을 쓰거나 현직이신 분들이 좀 계시는 편이다. 그런데 취미로 글을 쓰는 분이 자기의 글에 대해 고민을 하자, 지인분이 이렇게 말한 적이 있다. "XX님, 문학 하려고 하지 마세요."
속뜻은 쓰고 싶은 글이 뭔지 먼저 생각하라는 말이다. 우리가 그 글에 어떤 의미를 담으려고 노력하는 것보다 쓰고 싶은 글을 먼저 써보는 것이 때때로 더 도움이 된다. 그래서 어떤 문장보다 저 문장이 와닿았던 것 같다. 현재 주어진 문제에 대해서 필요한만큼 설계하고 구현하는 것이 과정에 매몰되기 쉬운 주니어들에게 필요한 자세같다.
디버깅 마인드셋
아마 코딩을 하다보면 난데 없는 버그 때문에 고생을 해본 경험이 있을 것이다. 혹은 버그를 보자마자 어? 이거 아니야? 하고 해결해본 적도 많을 것이다. 또는 혼자서 해결 못하다가 옆사람에게 설명하다 어? 저 알 것 같아요. 하고 해결해본 적도 있을 것이다.
그래서 대체 고수들은 어떻게 디버깅한다는거지? 궁금해서 세션에 참석하게 되었다.
인지적 과정이 생략된 직관적 판단 때문에 디버깅 능력이 증가하기 어렵다.
우리가 고수의 디버깅을 따라가기 어려운 이유다. 문제 상황 시, 고수들의 생각 흐름 과정을 듣지 못한 채 내려진 판단 때문에 우리의 디버깅 능력이 증가하기 어렵다는 말이다.
세션에서 디버깅은 아래와 같은 흐름을 보인다고 한다.
원인파악 -> 문제해결 -> 사후 처리
여기서 고수들은 원인파악 시간에 오랜 시간을 들인다고 한다. 그렇다면 문제 원인파악을 하는건 어떻게 할 수 있는걸까?
- 문제 정의
- 우선 어떤 문제가 발생했는지 정의한다. ex) 클라이언트가 서버에 데이터를 요청했는데 데이터가 없다.
- 정상 동작 정의
- ex) 클라이언트가 데이터 조회를 요청하면 서버는 user1에 대한 데이터를 응답한다.
- 최소 재현 환경 구축해서 관찰
- DB를 직접 조회하거나 유닛 테스트나 통합 테스트를 진행해본다.
- 차이를 발생시키는 원인 탐색
- 어디에서 원치 않는 작동을 하는지 원인을 탐색한다.
- 가설 설정 및 검증
위의 작업을 할 때 가장 중요한 것은 사전 작업이다. 디버깅 작업에 매몰되지 않게 시간 분배를 해보는 것이다. 만약 분배한 시간보다 더 많은 시간이 걸리면 적절히 멈추고 작업을 회고 해야만 한다.
주니어들은 원인 파악 시 빠진 부분이 있어서 디버깅에 시간이 오래 걸린다고 한다. 그러자 무수히 많은 과거들이 떠올랐고 동감했다.
더불어 이런 인지적 과정 단계를 정의하고 세션으로 발표하신 점에 대해 친구랑 감탄했다. 진짜 최고다..
사이드 프로젝트로 성장하기
요즘 좋은 사이드 프로젝트가 많다. 처음 듣는 기술을 쓰는 사람도 많아서 아, 나도 저 기술 써야하나? 하는 생각도 든다. 그런 갈팡질팡한 마음에 선택한 세션이다. 발표자인 조현우님은 한해동안 12개의 사이드 프로젝트를 했다고 하셔서 헉, 했다. 눈감아, 김뛰까.
본인이 사이드 프로젝트를 진행해보면서 팁 같은 것들을 많이 말씀해주셨는데 정말 도움이 되어 남겨본다.
- 2-3일 이내 끝낼 수 있는 프로젝트 선정해보기
- 몰입은 오래 지속되지 않는다 - 관심 있는 분야로 선정하기
- 나의 뛰까 같은.. - 안 써 본 기술 한가지씩 추가하기
- 대신 다음에 해볼 프로젝트에 다시 적용한다 - 사이드 프로젝트 운영 비용 아까워하지 말기 (뜨끔 ^^)
- 개인 프로젝트 vs 팀 프로젝트
- 개인 프로젝트 추천 (이유는 모두 알잖아요)
여태 많은 기능을 담은 프로젝트만 구상했었는데, 이번 세션을 통해 친구와 많은 이야기를 나눴다. 들어보니 친구 주변 개발자분도 작은 프로젝트를 구현해서 성장하신다고 했다. 백엔드라고 해서 너무 로그인, 게시판 구조에 매몰되었던건 아닐까? 라는 생각도 해보는 기회였다.
~ 여기서부터 체력 이슈로 클린 스프링까지 쉬어가요 ~
클린 스프링
정말 기대했던 토비님의 클린 스프링. 토비의 스프링을 읽어봤고 강의도 전부 있어서 큰 기대를 했다. 하지만 반전, 토비님은 클린 코드를 이야기하고 싶으셨다고.
토비님이 이야기하고 싶으셨던 내용은 클린코드는 과연 생산성을 저하시키는가? 이다. 많은 사람들이 클린 코드를 지키다보면 생산성이 떨어져서 오히려 비용이 더 들 수 있는 작업이라고 한다. 나 역시 들어본 문장이었다.
여기서 우리는 클린 코드에 대한 정의를 다시 해보는 시점이 된다. 클린 코드란,
- 읽기 좋은 코드
- 이해하기 좋은 코드
- 확장하기 좋은 코드
를 의미한다. 즉, 유지보수하기 좋은 코드를 의미한다. 그렇다면 유지보수하기 좋은 코드와 생산성은 배타적인 관계인가? 토비님은 그렇지 않다고 하셨다. 개발 생산성과 유지보수는 서로 영향을 주는 관계가 될 수 있다.
아주 익숙한 그래프일 것이다. 나도 그렇다. 그렇다면 정말 이 관계가 가능하냐는 것인데, 유지보수가 좋으면서 생산성이 좋은 코드를 만들기 위해 충족될 조건이 있다고 하셨다.
- 개발 시작은 빠르고 간단하게 (익숙한 기술로)
- 핵심 기능에 집중
- 동작하는 코드를 만들어라
- 가장 단순한 코드를 만들어라
- 리팩터링 하기 좋게 작성
그렇다면 누가 리팩터링 하기 좋게 작성하는 것일까? 바로 팀원이다. 팀원에게 익숙한 기술로 빠르고 간단하게 기능을 구현하고, 팀원이 리팩터링 하기 좋게 테스트 코드를 작성하고 검증한다. 그러면서 토비님은 결국 클린 코드가 팀의 동료 개발자와 관련되었다는 것을 의미한다고 하셨다.
그때 어떤 기술을 도입할 때 러닝커브에 대한 고려를 해야한다는 멘토님의 말이 떠올랐고 내부 테스트 프로그램이 전사적으로 도입될 때 적용에 어려움이 있어 반대했던 팀원들이 떠올랐다.
더불어 토비님은 세션 타이틀에 '스프링'이 붙기 때문에 끝나기 전, 팁을 알려주셨다.
- 자기 책임에 충실한 오브젝트를 구분하고 의존관계를 유연하게
- 클린(자동) 구성 정보
- 헥사고날 아키텍처를 지향하라
- 계층과 모듈 경계에는 api, 즉 인터페이스를 사용 (누가 뭐라하면 토비님이 쓰라고 했다고 하셨다 ㅋㅋㅋ)
- 스프링 할거면 테스트 해라
- DB 테스트에는
@Transactional써라. (ㅋㅋㅋㅋ)
위대한 팀이 위대한 사람을 만든다. 우리 교양 있고 친절하자.
1년도 되지 않았을 때 고생했던 때가 떠올라서 맘이 뭉클해졌다.(물론 같이 고생해서 팀원들이랑 많이 친해진 경험이 있다) 감동 과다된 상태로 토비님의 세션은 그렇게 끝이 났다.
객체지향 여전히 유용한가?
처음에 세션 타이틀 보고 헉, 했던 기억이 난다.
이제 객체지향적인 코드에 대해 고민하기 시작한 주니어인데 벌써 유용하지 않다는 소리인가? 해서.
발표자는 무려 조영호님이다. 객체 지향의 사실과 오해, 오브젝트의 저자. 그래서 무조건 들으러 왔다.
친구랑 객체지향 여전히 유효한가..? 유용한가..? 어둠에 침침한 눈으로 작성하고 있을 때쯤 세션이 시작했다.
우선 조영호님은 타이틀에 대한 오해부터 풀어나가셨다. 그리고 달변가셔서 너무 놀랐다. 인프콘에 달변가가 아닌 분이 없었다.
여튼, 객체지향이 여전히 유용한가가 아니라, 객체지향이 언제 유용한가?에 대한 질문이 필요하다는 뜻이었다.
객체 지향은 언제 유용한걸까? 그렇다면 객체지향이 유용하지 않은 케이스도 있는 걸까?
조영호님은 몇개의 코드와 예시로 메세지를 전달하셨다. 객체지향이 무조건 옳은 것은 아니며 우리는 실제로 객체지향과 절차지향을 섞어 쓰고 있다고.
예를 들어, 데이터를 변환할 때는 절차지향이 편리하다. setter를 사용해서 변환하면 되니까. 하지만 객체지향을 사용하면? 타입마다 사용하는 상태가 다르기 때문에 instanceof 같은 것을 사용하여 데이터를 매핑 해줘야 한다.
우리가 명심할 것은 우리가 하나의 패러다임만을 사용하고 있지 않다는 것이다. 복합적인 패러다임을 사용하고 있기 때문에 언제 유용한지 판단하는 것이 우리의 몫이다.
분명 객체지향이 언제나 옳은 게 아니라는 것을 알면서도 잊고 있었다는 걸 다시금 생각하게 된 세션이었다.
인프콘을 마무리하며
아침엔 0개이고 오후엔 3개인 것은 무엇일까? 바로 친구의 칫솔세트다. 그녀는 칫솔세트 세개를 얻었고 나는 타포린백 세개를 얻었다.
더위에 약한 관계로 체력적 이슈가 계속 몰아쳤지만 원했던 세션들을 모두 들을 수 있어서 즐거웠다.
친구와 나처럼 성장 하기 위하여 많은 분들이 노력하고 있구나, 하며 이직의 원동력이 되기도 했다. (물론 면접 본 곳은 떨어졌다. ㅎ)
끝나고 친구랑 중앙해장 달려가서 몸보신했다 ㅎㅎ
인프콘 불러줘서 너무 고맙읍니다.. 내년에도 불러줘요..!🥹
