[점핏] 두번째 개취콘 후기 (JUMPIT TO BACK-END)

 
 

 
 
 

인프콘을 다녀온지 조금 더 지나서 점핏*교보문고가 함께하는, 개취콘에 오프라인 참여자가 되었다.
 
이 컨퍼런스 역시 200명을 오프라인 참여자로 뽑는데 1800명이상의 사람이 신청해서
 
약 10대1의 경쟁률이라고 하는데 
이거 또 왜... 돼...? 하는 마음이다.

 

 

 

이 중 가장 느낀점이 많았던 2가지 세션에 대해서만 정리를 하고,  후기를 남기고자 한다.  

 

 

 

---

 

 

1. 중요한건 인터페이스야

강남언니 개발리더 → 손진규님

 

 

좋은회사에 취업한 개발자되기?

예를 들어보자.

교수가 되기 위해 교수가 된 경우가 있다. (나는 다 이뤘으므로 연구를 하지 않는 사람들..) >> 주객전도
연구를 하기 위해 교수가 되는 것이 좋겠다.

 

 

좋은 곳에 취업을 하는것보다는
개발을 잘 하는 개발자가 되는게 좋겠다.

인터페이스란 서로 분리된 컴포넌트 사이에서 정보를 주고받기 위한 경계이다
서로 다른 경계에서 인퍼테이스라는 약속을 통해 정보를 주고받게되는데..
우리는 인터페이스를 처음부터 잘 정의/약속해야한다

1️⃣ 첫번째 예시

잠을 잘 못자는 사람들을 위한 서비스 - 사이드 프로젝트 - 숙면을 돕는 컨텐트 제공 - 보다 - 유저 스토리 - 기획 디자인.. 설계 개발까지 하면 됨 API가 나왔다!!! → 클라이언트 개발자에게 전달을 했는데,,

“그렇게 만들면 제가 쓰기 어려워요”

 

무엇이 문제인가?

✅ 클라이언트 개발자에게 API를 어떻게 만들엊면 좋을지 물어보지 않음
> 코드 변경에 추가 비용 발생
> API 개발을 하는 동안 클라이언트 개발자는 기다리게 된다.

 

설계면에서  어떤 정보를 전달 받겠구나 → 약속이 된 상태이므로 변경 가능성이 낮아짐
* 각자 병렬적인 작업과 맞춰보기가 가능해진다.

 

2️⃣ 두번째 예시

적은 비용으로 빠르게 개발을 했어! 개발한 결과물이다 전달
→ 디자이너는  "어 제가 원하던거랑 동작이 좀 다른데요..?"

 

3️⃣ 세번째 예시

디자인이 나왔는데 개발 솜씨 좀 한번보여줘야지!!
→ " 이건 개발이 좀 힘든데요?

 

 

🤔 이런 문제가 발생하는 원인은?

- 만들기 전에 무엇을 만들지 명확하게 확인하지 않았음.
- 무엇을 만들것인지 정하는데 누군가가 참여하지 않았다.

 

기획이나 디자인 고민해서 정리해서 전달하면 좋을까? 

→ 대부분 실패한다.
→ 문서화가 이런 문제를 해결하는데 썩 도움이 되지 않는다.

 

 

왜?

• 대부분의 사람들은 생각을 글로 적는 역량이 떨어짐
• 읽는 사람들도 다 들어올 수 없음
• 변경에 비용이 많이 발생한다.

어떻게 해결할 것인가?

• 제품을 함께 기획하라
• 빨리 와이어프레임 만들어서 공유 > 모든 구성원이 달라붙어서 빠르게 피드백을 한다
• 여기는 개발이 어렵다. 여기는 사용자가 이해를 못할 것 같다. 여기는 이렇게 개발하면 될것 같다 …
• 자연스럽게 모든 구성원이 제품에 대해 이해도가 높아진다.

 

 

4️⃣ 마지막 예시

제품에 대한 높은 이해도를 갖고 완성을 했는데…

고객이

와 내가 원하던거에요! 라고 하지 않는다.

이건 제가 원하는게 아닌데요? 라는 반응이 온다

 

 

고객이 원하는 제품인지 미리 확인하지 않았다.

 

** 고객의 생각은 내 생각과 다를가능성이 너무너무 높다

 

 

치명적인 생각의 오류

• 본인이 쓸것 같으면 남들도 쓸거라고 생각하게 된다.
• 고객에게 실제로 물어봐야하고, 변경에 비용이 엄청나게 드니까 고객의 생각 위주로 해야한다.
• 미리 고객이 원하는 제품인지 확인하라
  - MVP 먼저 : 가장 작은 제품을 만들어서 고객의 반응을 보기 (실제 제품이 나와야해서 얘도 비용이 많이듬)
  - 프로토타입 > 프리토타입 (고객이 원하는건지 미리미리 보는것 )
  - 회의때마다 스케줄 조정하는 흉내를 내보면서 우리 고객들이 이 제품이 잇다면 이럴때 이런 방식으로 쓰겠구나 > 개발에 적용될 수 있음 > 값싼 검증
  
                    

 

우리는 본능적으로 ...

사용자에게 인터페이스를 제공하는 상황
제품을 제공하든, API를 제공하든

이때 일하는 순서에서
불안하지 않은 것부터 하고 싶어하는 욕구가 있다.

 

(많은 비용)                           (적은 비용)
고객 ← 디자인 ← 클라이언트 ← 서버

 

불안한것 모르는것부터 검증을 하면 더 비용이 적게 든다.

 

 

고객에대한 검증부터... 디자인 검증... 순서로 

 

고객 → 디자인 → 클라이언트 → 서버

 

 

 

• 고칠때 비용이 많이 드는것부터 약속하기 = 불확실성이 높은 것부터 약속하기 (미루고 싶은것)
• 어떤것이 가장 불확실한가? 어떤것을 제일 피하고 싶은가?
• (케이스바이케이스 이긴 하다)
  
  

 

센스있게 일하는 주니어 개발자는?

• 믿고 맡길 수 있는
• 하고자 하는 얘기를 다 설명하지 못하고 받아들이는 사람도 제대로 받지 못한다 (정보가 어딘가 비게 된다)
• 오너십을 갖고 있는 사람은  다시 질문을 하고 비어있는 부분을 채운다.
  - 어떤 목적으로 하는건가요? 하고 묻기
  - 주인 의식을 갖고 적극적으로 임하는 자세
• 결국 양쪽 다 관심있는 사람이 통역사 역할을 하게 됨
• 1년은 해야 성과가 나타나는 일들이다.
  
  
  

---

 

✍️ 느낀점

 

나는 문서화에 진심인 사람이기도 하고,

실제로 내가 만드는 문서의 가독성이 너무 좋다는 칭찬을 엄청나게 받는다. 

 

 

그러나 아무리 잘 작성해도

받아들이는 사람이 100퍼센트 받아들이지 못한다는 점,

사람이기 때문에 발생가능한 문서 작성의 오류 역시 무시할 수 없다는 것을 느꼈다.

 

 

인터페이스를 잘 정의하고, 더나아가서 소통의 창구로써의 문서를 항상 고민해보는 개발자가 되어야겠다 생각했다.

 

 

 

---

 

 

2. 내게 맞는 성장 환경 찾기

 

→ 토스뱅크 CTO 박준하님

 

 

 

 

 

커가는 회사에서의 두가지 경험

 

1️⃣ 개발직군과 팀들

 

굉장히 많은 직군들이 있다.

 

 

웹서비스를 만들어야겠다.

→ 서버가 세팅이 되고 접속할 수 있게 만들고..

→ 유저는 서버를 통해 DB의 데이터를 갖고 보여준다.. 이게 대부분 서비스의 모습이다.

 

 

유저에게 들어가는 응답이 된다. 응답이 정확한지, 빠른지 

→ 개발자는 모든것들에 대해 전문가가 될수는 없다.

 

 

그러면 DBA 라는 전문직군에게 부탁하자

→ DB 개발자 분들은 부담을 줄였지만, DB팀에 대한 벽이 생기기 시작함.

→ 앞에 있는 영역을 담당하는 개발자는 직접 못 건들고 직접 못보고... 다른 사람에게 맡겨야하는 상황이 생김

 

 

갈수록 점점 세분화 되는 개발팀들

서비스 개발팀 / 플랫폼 개발팀 / DB팀

→ 서비스 개발의 공통기능이 생기며 플랫폼 개발팀이라는 조직이 생김

 

 

협업을 열심히 잘 해 나갈수 있다면 너무 행복할건데

각팀 업무의 범위가 셋업되는 순간 달라지게 됨

 

 

팀의 업무, 팀의 목표

→ 각 팀별로 목표를 세우고, 회사 전체의 목표가 잘 달성되길 바라게 되는데 거기에 집중된다.

→ 그 팀이 좋은 목표 달성을 위해  팀의 목표에 맞추어 평가를 하고, 팀의 OKR 달성 정도에 따라 인센티브 비중을 나누게 됨

이런 업무 범위와 제약… 고객에게 좋은 응답속도를 보장하기 위해 모든것들을 보던 개발자들이 DB팀에 맡기게되면서

 

"혹시 설정을 바꿀수 없을까요?" 라고 물었을 때 

"사고가 날수도 있는데, 우리 팀의 OKR에 반대되는 행위이다" 라고 말할수도 있음

 

 

 

내 성장에 도움이 되는 방향은?

나는 백엔드 개발자로써 좋은 응답속도를 내고 싶은데,

내가 맡은 영역 앞 뒤로 넓은 범위에서 문제가 생길 수있다.  (앞뒤에 있는 팀들에 대한 영향)

 

 

이런 문제가 생기지 않는 조직 문화

그런 사람들이 모여있는 곳에서 일을 하면 좋겠지만.. 모두가 그럴수는 없다.

 

또 가고싶었던 회사가 막상 가보니 다른 문화일수도 있음

 

 

 

 

 

내가 손해를 보더라도   회사 목표에 맞추어 설득을하고 역할을 해내면서 요청을 하는걸 해야함.

 

 

회사에서 하지 못하는 분위기때문에 못하는게 너무 많다.
그걸 냅두면 내 성장에 도움이 될 수 없다.

 

 

하지 못하는 이유에 대해 열심히 들어야한다.

팀장님/방향에 대해 이야기를 해보다보면 그 일까지는 신경을 못쓰게 된다

→ 리소스가 부족한거면 내가 좀더 해보겠다. 내가 조사해보겠다.

내 팀에선 싫어할수도 있지만 내가 더 공부하고 그런 의견을 내는건 충분히 시도할만하다.

 

 

나의 OKR을 달성하기 위해서다. 나의 인센티브를 위해서다 라고 하면 안되지만

유저에게 좋은 응답을 보내기 위해 해결하기 위해 알아보는것이다 라는 내용을 충분히 공유할것

 

 

맥락과 목표를 잘 잡아서 이야기를 하고 설득을하면 통할 수 있다.

나 한명이 조직에 영향을 주고, 의견내고 도움을 줄 수 있는 주니어 개발자가 되자.

 

 

2️⃣ 품질의 책임

 

장애가 발생 했을 때 문제를 해결하고 재발 방지 대책을 집중하게 되는데

내용과 히스토리 노력을 알지 못하는 회사의 의사 결정권자들... >> 제약들이 점점 더 생기게 된다.

 

 

품질 책임에 대해 모든 개발자가 노력하면 안전성도 더 올라갈텐데 >> (그런 조직이 생기게 되면 얘기가 또 달라진다.)

테스트를 열심히 해주시는 QA조직이 품질 책임을 지게 됨 장애가 계속 발생하니까 QA가 생기니까 모두가 좋아했음

 

점점 더 QA조직이 많은 권한과 책임을 가지게 되면서..
출시 일정과 테스트 상황만 보며 <일정 맞추는 게 목표>가 되어버리는 경우가 있다.

 

우리의 목표는 좋은 응답속도와 안정적인 서비스의 제공인데..

 

 

example

개발에 대해 <서비스 오픈전에 2주간의 시간을 달라!> 라고 말했음 

 

근데  기획부터 디자인이 계속 바뀌면서 당연히 출시일정이 미뤄지고.. > 2주의 시간을 투자할 수 없게 되기도 함. 

결국 목표했던 개발을 다 끝내지도 못하고, 테스트를 진행할 수 있는 환경을 만드는게 목표가 된다.

 

 

내부 기능이 다 안만들어졌어도 넘기게 되버리면,  QA 테스트를 하면서 당연히 문제가 발생할건데

그 순간에 다시 개발을 진행하게 되고….목표 자체를 점점더 잊게 되고,  QA조직만 만족시키려고만 하게 됨

 

 

 

품질 안정화를 위한 팀이 개발의 완성도를 떨어뜨리는 것과 동기부여를 떨어지게 만드는 상황을 만들게 됨

 

과연 누구를 위한 일인가.

 

 

 

내 성장에 도움이 되는 방향은?

개발기간이 부족한데 이런건 못하는 상황이고,  이 영역을 빼고 테스트를 먼저 진행하던지, 전체 일정을 미루던지 해야한다 라고 말해버리면…

 

그땐 한발 물러서야할수도 있음 회고를 하며 바꿔가기위한 노력을 해야한다.

 

 

결국 조직 전체의 목표를 맞추는게 중요하다.

개발자가 내가 모든것들을 알고싶은것들은 고객들에게 더 좋은 서비스를제공하기 위한것들일뿐

 

 

기술역량 더 키우고, 문제가 발생했을 때 해소를 하고 넘어가지말고, 엔지니어로써 끝까지 파봐야한다.

 

 

 

오픈소스 환경을 계속 쓰는 이유는?

스프링부트 코틀린 .. 어떤 회사에 들어가서도 똑같이 사용하게 될 텐데

그런 오픈소스 환경이 학습 할 수 있는것도 많고, 문제를 엄청 깊게 파고들기에도 좋음

(레디스 코드 언급)

 

 

 

 

✍️ 느낀점

 

주니어 개발자에 대한 주제로 이야기를 듣다보면

언제나 권한과 설득에 대한 이야기를 듣는것 같다. 

 

부족한 역량에도 책임감을 가지고 더 공부해서 설득하는,, 여러번의 시도를 해봐야할것 같다. 

 

 

✔️ 다른것에 주객전도 되지 않기.

✔️ 개발자로써, 더 나은 응답 속도와 안정적인 서비스를 제공할 수 있도록 꾸준히 공부하기

 

 

---

 

 

일체형 보조배터리와 이런저런 선물을 받았다.  

 

 

 

4개의 세션을 들으면서 

공부해야할것도 정말 많고, 꾸준하게 성장하려면 해야하는 노력이 정말 많음을 다시 느꼈다. 

 

 

언젠가 취업을 하게 되면 

신입/ 주니어 개발자로써 팀의 개발 커뮤니케이션 문화에 동참하는

 

동료들에게 함께 일하고 싶은 개발자로써 평가받는,

멋진 개발자가 되고 싶다!!!