SOPT에서 진행한 컨퍼런스인 MIND23에 다녀왔다! 인프랩 CTO님이랑 테오님이 오신다고 해서 꼭 가고 싶었는데 친한 동생도 관심 있다고 해서 요번에 같이 다녀왔다 ㅎㅎ 인프콘 때는 부스를 하나도 못 돌아서 너무 아쉬웠는데 이번에는 그래도 8~9개 정도는 부스를 돌아볼 수 있어서 좋았다👀 각종 스타트업 서비스를 둘러볼 수 있는 것도 좋았는데, SOPT 부스도 넘 재밌었다... SOPT에서 개발한 서비스들이 퀄리티가 정말 좋아서 깜짝 놀랐었다,,,👍 무엇보다 서비스 설명해주시는 분들이 본인들의 서비스에 대한 열정이나 자부심이 높아 보여서 멋있었던 것 같다. 못 본 다른 부스들도 아쉽다ㅠㅠ!!

🚀 SOPT Booth

인상깊었던 부스는 palmspring, smeem, piickle이었던 것 같다... 근데 다른 서비스들도 다 너무 매력 있었다.
palmspring은 실제로 수요가 많을 것 같다는 느낌이 들었다. 실제로 기업들이 자신들만의 회사 블로그나 팀 블로그를 운영하고자 하는 경우가 많으니까... CRM 형태로 배포해도 재밌을 것 같다는 생각이 들었다. 그리고 설명해주신 분들이 말씀하신대로 스타트업에게는 이 블로그 빌더가 실제로 자신들의 기업을 알리는 데도 도움이 될 수 있을 것 같다. 그리고 나만 그런지는 모르겠지만... 개발자들이 유독 그런 것 같은데 서비스 자체도 중요하지만 사내 문화에 매력을 느껴서 입사를 결심하는 사람들이 많은 것 같은데, 이런 팀 블로그가 많이 생겨나게 되면 그런 요소들을 어필하는 데도 도움이 많이 될 것 같다. 그리고 옛날에 노션 에디터 구현에 대해 고민한 적이 있는데 직접 구현하셨다길래 프론트엔드 엔지니어분 명함을 받아왔다...👀👍
smeems는 개인적으로 영어 공부가 필요한 지금... 나한테 가장 필요한 앱이었는데 아쉽게도 아직 안드로이드 출시가 되지 않아서 다운로드 받지 못했다...🥹 대신 출시 알림 신청을 해 두었다. 신기한 게 옛날에 내가 그대로 시도하려다가 못 했던 방식의 영어 공부라서 더 흥미가 갔다. 원래 그냥 개인 SNS에 한글로 일기를 쓰고 그걸 영어로 번역해 보는 연습을 하려다가 의지 부족으로 실패한 적이 있는데, 이런 앱이 있으면 훨씬 수월하게 영어 공부를 할 수 있을 것 같다...ㅎㅎ 개인적으로 실제로 내가 가장 잘 쓸 것 같은 서비스였다.
piickle은 부스 설명 읽고 흥미로워서 가장 먼저 방문했던 SOPT 부스였는데 부스에 계신 분들이 설명도 너무 자세히 해주시고 프로덕트를 보니까 퀄리티도 높아서 재밌었던 것 같다...!!! 대화 주제에 대해 고민해 본 적은 있지만 이런 서비스를 생각해 본 적은 없는데 아이디어가 흥미로웠다. 특히 BX 디자이너에 대해 여쭤보면서 서비스 이름이 왜 피클인지에 대해서 들었었는데 그 얘기가 정말 재밌어서 기억에 남는다. BX 디자인이라는 것에 새롭게 알게 된 순간이었다👀

🚀 Startup Booth

스타트업 부스는 거의 다 돌고 왔던 것 같다. 평소에 관심 있었던 기업 부스들도 많이 있길래 신기했다...!

데이터리안 부스에서 테스트 했는데 같이 간 동생이랑 똑같은 결과가,,, mbti가 ENTJ라서 이런 테스트 하면 맨날 ENTJ 같은 것만 나오는데 같이 간 동생도 ENTJ라 그런가(ㅋㅋㅋㅋㅋㅋ)

코드잇 대코캠 13기를 곧 모집한다길래 살짝 찍어왔다... 어차피 계속 공부해야 하는데 모던 자바스크립트나 들으면서 할까 싶기도...

슥삭 부스도 있어서 다녀왔다! 옛날에 설치했다가 그때는 본격적으로 취준 할 때가 아니라서 삭제했던 것 같은데 이번에 다시 설치하니까 지금의 나에게 유용한 정보들이 정말 많아서 이번에야말로 너무 잘 사용할 것 같다...ㅠㅠㅋㅋㅋㅋ 나도 이제 진짜 취준할 때가 왔구나...

🚀 Speaker Session

세션은 2,3,4,6을 들었었는데 개발자 세션인 2, 3번을 위주로 정리했어서 블로그에는 2, 3번 세션에 대해 정리해 보도록 하겠다. 기대했던 테오님 세션은 기대했던만큼 감명깊었다...🥹

📌 커리어 각 지점의 커밋 로그 - 이동욱

1. 첫 직장

• 120개의 기업 지원 후 최종 합격 1개 (wow)

2. 두 번째 직장

✔️ 원했던 직장

• 코드 리뷰 등 좋은 개발 문화
• 뛰어난 동료
• 365/24 서비스 운영 & 장애 경험
• 본격적으로 TDD, 테스트 코드를 학습하고 실무 적용

✨ 나도 내가 원하는 회사가 무엇인지 짧게나마 생각해 보는 기회가 되었다...

3. 세 번째 직장

• 다양한 경험을 가진 시니어들과의 협업 갈망
  💫 기술 블로그 내용을 커뮤니티에 공유해서 틀린 점을 조언 받고 고치려고 노력함
  → 이것 덕분에 많이 알려져서 유명한 시니어 개발자분께 오셨다고 한다... 역시 이런 습관이 좋은듯

4. 네 번째 직장

• "서생의 문제 의식, 상인의 현실 감각"
• 서생의 문제 의식 -> 스타트업 비전
• 상인의 현실 감각 -> 재무제표
• 유니콘 기업이 아닌 낙타 기업!

스타트업에서 성장하기

1. 나만의 학습 방법 찾기

• 원서, 유튜브, 도서
• 시간 > 돈
• 신뢰할 만한 분께 질문이 가능한 강의, 코드리뷰를 구매
• 계속 점검하고 더 좋은 방법을 찾아야 함

2. 본인에게 잘 맞는 환경 구축

• 모니터 개수, 수면 시간 등등...
• 가장 잘 맞는 방법, 장소를 찾아 발전시켜야 함

3. 자존감 기둥 만들기

• 뛰어난 동료, 실패한 프로젝트... -> 자존감이 떨어지는 날이 올 것
• 연사님의 자존감 기둥 : 글쓰기, 커뮤니티 참여, 운동, 멘토링, 동료와의 대화, 독서...

4. 거인의 어깨 위에 올라가기

• C레벨 테크 리드와 가까이 일할 수 있는 기회
• 그들이 어떻게 커뮤니케이션 하고, 어떻게 신뢰를 얻어내는지
• 그들이 어떻게 문화를 만들고, 어떤 기준으로 결정을 내리는지

5. 남을 설득하는 방법 배우기

• 완벽한 논리가 중요한 게 아니다!

📌 Don't Be a Programmer, Be a Problemn Solver. - 유용태

1. 성장하면서 알게 된 개발의 가치

좋은 개발자가 되기 위해서는 당연히 개발을 잘해야 한다.

• 이론보다는 실전
• 결국 요구사항을 잘 파악해서 만들어내는 능력이 중요
• 개발은 학문보다는 운동 같은 것!
• 빠삭하고 정통한 이론을 가지고 있는 것 vs 모르지만 어쨌든 만들 수 있는 것
• 할 줄 아는 것과 해내는 것은 다른 능력!

구현을 잘하는 게 아니라, 높은 품질의 코드를 만들어내는 것이 중요하다.

• 높은 품질의 코드는 '생산성'과 '유지' 측면에서 매우 중요
• 더 나은 기술을 습득하고자 하는 것도 높은 생산성과 안정적인 개발을 위해 필요한 것
• 경험을 통해서 깨닫게 되면서, 다시 원론과 정석을 잘 아는 게 중요

하지만 실전에서는 개발을 잘하는 것만으로 충분하지는 않더라

• 사업과 개발을 함께 하다보니 가치의 충돌 발생
• 요구사항의 변화는 자주 발생하는데, 코드 품질을 유지하려다 보면 유연하게 대처하기 어려울 때가 많음
• 더 빨리 만들기 위해서는 코드 품질을 다소 희생해야 한다.

그럼에도 코드 품질을 지키는 것이 중요하다고 생각함

• 요구사항과 마감의 압박 속에서도 좋은 추상화, 견고한 코드를 유지하고자 하는 게 잘하는 개발자라고 생각함

그러나...

• 코드 품질을 고집하면, 결국 시간과 성능의 압박을 받게 됨
• 코드 품질을 포기하면, 개발자로서 자괴감에 빠짐...
• 그 결과는? → 야근과 번아웃

시장은 내 생각보다 고품질의 코드를 중요하게 생각하지 않는다.

• 고품질의 코드와 새로운 기술은 눈으로 잘 드러나지 않는다.
• 개발의 결과물들은 주로 기획, 디자인, 유용함, 시장가치 등으로 평가 받음
• 개발자들조차 코드가 공개된 개발자의 라이브러리를 코드의 품질을 보고 선택하기보다는, 그 라이브러리의 유용함과 만듦새가 다운로드와 확장을 만든다!

코드보다 그 코드로 어떤 가치를 만들어내는가가 더 중요하다.

• 같은 기술에 같은 사람이 같은 시간을 들여서 만들어도, 무엇을 만들어내느냐에 따라 가치가 달라진다.
• 심지어 비즈니스가 망하면 고품질의 코드라도 의미가 사라진다...
• 코드의 품질은 중요하지만, 정말로 지금 그만큼 중요한가?
• 내가 추구하고자 하는 코드의 품질은 어떤 가치를 가지는가?
• 내가 만들고 있는 것은 어떤 가치를 만들어내는가?

개발자의 평가는 결국 어떻게보다 무엇을 개발하느냐에 따라 정해지더라

• 사실 어떻게가 정말 중요하지만, 그걸 증명하기가 대단히 어렵다.
• 그래서 결국 무엇을 만들었는지로 판가름이 난다.

기왕이면 더 나은 가치를 만들어 내자!

• 나는 코드를 만들지만, '코드가 만들어내는 가치'를 만들고 있는 것

• 더 가치 있는 코드는 적절한 코드 품질 위에 좋은 요구사항을 구현하고 일정을 지키는 것

"개발의 가치는 기술이 아니라, 그 기술로 어떤 문제를 해결하는가, 그래서 어떤 가치를 만들어내는가에 있다!"

2. 코드의 가치와 비즈니스

비즈니스가 성공하여 규모가 커지고 복잡해지면 다시 코드의 품질이 중요해진다.

• 코드의 품질이 떨어지면 결국 비즈니스의 가치를 하락시킨다.
• 안전성이 떨어진 제품은, 서비스의 질적 하락으로 유지할 수 없게 만들고,
  구조가 좋지 못한 코드는 앞으로 개발을 하는 비용을 비약적으로 높게 만들고 유연함과 속도를 떨어뜨린다.
• 코드의 품질은 비즈니스 가치를 높이기보다는, 떨어뜨리지 않는 방부제 역할을 한다고 생각하면 좋을듯

개발자의 평가가 어떻게보다 무엇을 개발하느냐에 따라 정해지는 이유

• 비즈니스가 성공하면 비즈니스의 복잡도와 규모가 커지게 되고, 자연스럽게 기술적 챌린지가 높아진다.
• 그렇기에 성공한 거대규모의 비즈니스를 개발한다는 것은, 같은 기술을 사용하더라도 난이도가 다르기에 자연스레 개발자 대우가 높아진다.

비즈니스 가치를 높이는 것은 곧 기술적 챌린지를 만들면서 결국 개발의 가치를 더 높이게 된다.

• 성공하면 규모가 커지고 자연스럽게 서비스 복잡도도 올라감
• 서비스의 규모와 복잡도가 기술적 챌린지를 만들고, 이를 극복하는 경험이 개발자에게 대단한 기술적 성장을 경험하게 해 줌
• 가치는 배타적인 게 아니라 상호보완적이구나!

비즈니스와 코드의 품질 간의 균형 감각

• 비즈니스 가치는 개발의 가치를 높여주고, 개발의 가치는 비즈니스 가치를 구현하고 그 가치를 떨어뜨리지 않도록 만들어 줌
• 개발자의 역할은 코드의 품질을 유지하면서도 비즈니스 가치를 높이는 균형의 수호자가 되어야 한다.
• 필요에 의해서 필요한 기술을 필요한 만큼만 사용하는 것이 얼마나 중요한지 알게 됨
• 배워야 한다는 기술에 집착하기보다 지금 상황에 더 알맞게, 더 빠르게, 더 쉽게 적합한 기술을 찾고자 하는 시각이 중요

3. 협업의 가치와 문제해결사

개발자의 직무로만 비즈니스의 가치를 높이는 건 쉽지 않다.

• 시장에서 고품질의 코드를 원하는 것은 아니지만, 저품질의 코드도 원하지 않는다(ㅋㅋ)
• 개발에게 기대하는 것은 구현과 안정성
• 개발은 대개 비즈니스 가치의 저점을 높일 수는 있으나, 고점을 높이기는 어렵다.

개발자 직군의 직접적인 목표가 비즈니스 가치 창출이 아니므로, 대개 가치의 충돌이 생긴다.

• 특히 개발자가 중요시하는 코드의 품질과 안전성이 제일 중요한 목표가 된다.
• 대기업과 같이 사람이 많고 역할이 분명히 나눠질수록 그런 경험이 보이더라.

내 성과가 아니라 우리의 성과이고, 우리의 성과가 내 성과이다.

• 그렇지만 성과는 보통 비즈니스의 성과로 평가되기 마련
• 개발의 가치는 비즈니스의 가치로 인해 만들어진다는 사실을 기억하자.
• 나를 도와줄 사람들이 필요하고, 내가 그들을 도와 가치를 높이기 위해서는 협업을 잘해야 한다.

나를 위해 협업하자! 내가 남을 돕는 게 곧 나를 돕는 일이다.

• 협업은 단순히 함께 일하는 것을 넘어, 서로의 전문성과 지식을 통합하여 더 큰 가치를 창출하는 과정
• 그들이 더 잘할 수 있도록 해서 비즈니스의 가치를 만들 수 있도록 하는 것이 나의 역할

개발은 코드로만 하는 게 아니다.

• 코드가 만들어내는 가치를 더 높일 수 있도록 하는 모든 행위가 곧 개발이라고 할 수 있다.
• 개발자는 1차적으로는 기술을 통해 문제를 해결하여 가치를 만들어내는 사람이지만,
  그것에 이르게 하는 모든 행위가 다 개발의 영역이며,
  그 과정에서 겪는 모든 문제들을 해결하는 것 역시 개발의 일

프로그래머를 넘어서 문제 해결사가 되자!

• 개발자의 진짜 역할은 "문제 해결"
• 순수하게 기술적인 문제만 있는 건 아님
• 팀원들 간의 의사소통, 사용자의 니즈 파악, 협업, 일정 마감, 가치, 기술 교체, 기술 부채

4. 함께 문제를 해결하는 방법

공항의 불만 처리 사례

• 대기 시간을 기술적으로 더 줄일 수 없는 상황

→ 정답 : 비행기에서 내려 수화물 찾는 거리를 늘렸다.

• 체감시간이 줄어듦!

개발로만 모든 문제를 해결할 필요는 없다.

• 다른 각도로 접근하면 문제를 해결할 수 있는 방안이 있다.

기억에 남는 실제 경험담

✨ 개인적으로 이 경험담 부분이 넘 흥미로웠다.

• 특정 서버 API의 호출 결과가 10초가 넘어가는 상황
• 그래서 서비스 로딩이 너무 느리다는 인식을 하고 있음
• 성능 개선을 시도하고는 있으나 언제 개선이 될지는 모르는 상황...
• 그렇다고 성능 개선이 될 때까지 업데이트를 무한정 미룰 수도 없다.

당시 쟁점들

• 서버가 해결해야 하는 문제다!
• 아니다! 인프라가 확충되면 해결되는 문제인데 인프라 지원이 안 된다고 한다.
• 클라이언트에서 캐싱을 해라.
• 보안정책상 서버에서 내려받는 특정 데이터는 로컬에 보관해서는 안 되는데, 그런 데이터가 포함되어 있어서 캐싱을 할 수 없다.
• 캐싱을 하더라도 동기화 이슈가 발생하게 될 것이다.

최선의 방법?

• 서버의 기술적 이슈이니 서버가 해결하는 게 맞다!
• But, 그 방법을 시도해 보는 데 많은 시간 소요가 예상됨
• 이상적인 최선의 방법이 아니더라도 다른 좋은 방법이 없을까?

시도

⭐ 쟁점들을 각자의 입장이 아니라 "함께 해결해야 할 문제"로 보고, 내 전문성을 바탕으로 다른 입장의 문제들을 바라보자.

• 서버에서 근본적인 해결책은 아니더라도 초기 속도를 올리는 건 할 수 없나?
• 인프라에서 다른 리소스는 지원받을 수 있는 건 없을까?
• 클라이언트가 캐싱을 해서 유의미한 성능 체감을 만들 수 있을까?
• 그러면서 보안 정책을 우회할 방법은 없나? 혹은 새롭게 합의할 수 있나?
• 동기화 딜레이의 어색함을 UI나 디자인으로 풀 수는 없을까?

그래서 어떻게 되었나?

• 클라이언트에서 캐싱을 하되, 자체적으로 암호화를 통해서 합의된 보안 검증을 해결하고,
  동기화는 화면을 먼저 갱신하고 데이터는 별도로 처리하는 낙관적 업데이트로 처리하고,
  로딩 UI를 개선하면서 체감 속도를 높일 수 있었다!
• 이게 분명 최선의 해결 방법은 아니었고, 많은 작업들이 있었으며, 나중에 정상적인 성능이 나온다면 하지 않아도 될 개발을 한 것이지만,
  ⭐ 이 업데이트를 통해 사용자의 만족도가 크게 올라간 주요 업데이트 중 하나가 되었습니다!

그리고 얻은 성과와 부수적인 성과

• 사용자들에게 유의미한 체감 속도 향상 경험 제공
• 부수적으로 얻은 것들
  • 캐싱이 다른 모든 기능에 포함되면서 전반적인 앱 성능 개선
  • 낙관적 업데이트 모듈
  • 서버의 성능 개선을 위한 시간 확보로 인해 조금 더 효율적인 로드맵 확보

⭐ 부수적인 성과는 이걸 얻고자 시작한 것은 아니었지만, 문제를 해결하려고 시도했기 때문에 얻을 수 있던 것이었음

문제 해결을 잘하는 법

• 핵심이 되는 문제를 찾아야 한다.
  • 보통은 부정적인 현상에 대한 대응책으로 해결하고자 함
  • 그렇지만 어떤 문제들은 본질적인 문제로 나오는 걸 수도 있음
• 대립되어 보이는 상황에서 문제 해결의 실마리가 잇다.
  • ex) 캐싱을 하면서도 보안도 같이 할 수 있는 방법은 없을까?
• 문제를 해결하는 방법은 최선의 방법 하나만 있는 게 아니다!
  • 문제는 함께 풀어가는 것
  • 다양한 시각에서 다양한 직군들이 모여 조금씩 문제를 조각내어 해결할 수 있다.

5. 협업을 잘하는 개발자가 되자

"같이 일하기 편한 사람이 되자"

• "안 된다"로만 말하지 말기
• 시키는 일이 아니라 해결해야 하는 문제다.
• 잘 들어주는 사람이 되어라
• 맥락의 차이가 오해를 만든다.
• 설득이 아니라 생각의 주파수를 맞추는 것
• 그렇기에 평소에 의도와 맥락을 언제나 분명히 하자
• 말은 휘발되어 오해를 만든다. 꼭 글도 함께 써라.
• 커뮤니케이션도 연습이 필요하다.

6. 끝으로...

절대적인 것은 없고 상대적인 것이며, 상황에 맞는 가치들의 균형 감각이 중요하다.

기업가 정신을 가지는 메이커 : MIND

• 내가 만들어내는 가치와 협업의 힘을 이해하고 나면 모든 과정에서 주체적으로 일할 수 있다.
• 무엇보다 이런 MIND는 일을 즐겁게 만들어준다.

✨ 스타트업에서 인턴 하면서 "시간 안에 개발해야 한다", "코드 품질보다 일단 만들어내는 게 우선이다" 라는 말을 많이 들었었는데, 그때마다 회의감이 들었었다. 취직하기 위해 공부할 때는 클린 코드나 좋은 구조에 대해 그렇게 많이 고민하는데 막상 현업에 들어가면 기한 안에 개발하기 위해 코드 품질을 희생해야 하는 순간도 오다니... 인정하기 싫은 아이러니라고 생각했던 것 같다^_ㅠ ㅋㅋㅋㅋ 하지만 결국은 경험을 통해 기한 안에 기능을 구현하면서 코드 품질도 어느 정도 챙기며 개발할 수 있는 능력을 터득하는 것이 중요하고, 결국 기한 안에 코드를 완성해서 비즈니스 가치를 높이고 유저가 많이 유입되면 다시 코드 품질이 중요해지는 시기가 오기 때문에 개발자에게 도움이 된다는 말씀을 듣고 많이 깨달았던 것 같다.

🚀 후기

이제 컨퍼런스나 세미나 그만 좀 가야겠다... 최근 한 달 동안에만 3개 정도 다녀왔더니 넘 힘듦... 그래도 다녀온 세미나들 다 재미 있었다^_^ SOPT 중앙 부스에서 SOPT 회원분들께 동아리 관련 설명도 들었는데 점점 SOPT에 들어가고 싶다는 생각이 들었다🥹... 사실 가을부터 일정이 많이 빡빡해서 지원할 수 있을진 모르겠지만...ㅠㅠ 아모튼 내년에도 SOPT에서 컨퍼런스를 열게 되면 또 참여할 것 같다😄👍