SIPE 사담콘 5기 발표 후기

Preview

이번 2분기(3월~7월), SIPE(사이프) 다섯 번째 기수에 참여 했습니다. 

사이프는 개발자 동아리로 사이드 프로젝트 보다 다양한 활동과 네트워킹 위주의 개발자 동아리입니다.  

이번 SIPE 5기에 지원서를 내며 발표를 많이 하겠다는 이야기를 했었는데요.

 

실제로 이번 사담콘 발표를 포함해 3번의 발표를 하며 초기 목표는 달성한 것 같습니다. 

• 1차 라이트닝 토크쇼: 주식 관련
• 사이프톤(사이프 해커톤) 발표 
• 사담콘: 개발자의 온보딩  

--- 

사담콘이란?

https://event-us.kr/sipe/event/128290

SIPE 다섯 번째 컨퍼런스 - 사담콘 야호, 파라미터나 줘야지 - 이벤터스

https://5th-sadamcon.sipe.team

SIPE 다섯 번째 컨퍼런스 - 사담콘 야호, 파라미터나 줘야지

 

 

사담콘은 SIPE의 행사 중 하나로 꽤 규모가 있는 컨퍼런스 입니다. 

참여자 분들이 자신이 겪었던 개발 경험을 나누는 자리입니다.

 

사담콘 준비 과정 

사담콘을 준비하며 온라인 리허설을 필수로 진행했습니다. 저를 포함한 참가자분들 모두 이 리허설이 큰 도움이 되었다고 했습니다. 

그래서인지 다들 발표 시간도 준수하고 내용 전달도 굉장히 깔끔했었던 것 같습니다.

 

발표는 이전에 블로그, 링크드인에 올린 스타트업 3개월차에 적은 글을 기반으로 구성했습니다.

그 때 이후로 여러 가지 생각이 섞인 부분이 있어서 제 백그라운드에 대한 지나친 소개와 AX에 대한 try catch 등을 이야기하다보니  10분 정도 시간을 오버해서 16분 저도가 되었습니다. 

피드백 이후로 온보딩과 관련된 부분을 더 자세하게 다루고, 제 스토리나 AX와 관련된 부분을 제거했습니다. 

덕분에 9분 정도로 이야기를 끝내고 질의 응답에 더 시간을 쏟을 수 있었습니다. 

 

사담콘 후기 

다른 분들의 발표 내용이나 퀄리티가 상당히 좋다고 느껴졌습니다. 실제 경험을 기반으로 기술적인 이야기를 풀었는데, 지식이 많이 늘어났습니다. 다른 분들은 이런 시도들을 하고 있다는 생각도 많이 들었습니다.

 

사담콘에는 150명 정도의 분들이 참여해주셨는데 진행도 깔끔하고 딜레이되는 부분도 없지 스무스하게 진행 된 것 같습니다. 쉬는 시간 질의응답 세션에서 저도 많이 물어본 것 같습니다. 그 과정에서 발표 때도 좋았지만, 그 뒤에 있던 이야기들도 많이 공감이 되었습니다.

 

창완님의 경우(모던 프론트엔드 라이브러리 패키징 가이드) 

Nodejs 개발에 대한 어려움에 대해 이야기하면서 버전업과 하위 버전 처리에 대한 이야기도 했던 것같습니다.

 

상우님의 경우(AI 시대, 개발자의 AX는 무엇인가)

AX를 회사 내에 도입한 이야기를 했는데, 쉬는 시간에 말을 걸었을 때, 제 경험과 이야기하며 여러 공감을 했던 것 같습니다. 특히 저는 AX를 사용하는 도구를 만들어드려도, 막상 사용하시는 분들이 자체적으로 claude나 codex에서 자료를 던져서 해달라는 식으로 쓰는 경우가 많았습니다. 내가 만들어준 도구에 대한 러닝 커브 등 때문에 실제로 사용하지 않는 경험에 대해 공감을 했던 것 같습니다. 

 

진욱님은(CRUD에서 복잡한 아키텍처로: AI 시대의 서버 엔지니어링 의사결정)

계정팀에 일하면서 설계를 작게 시작한다는 주제였는데, 저도 계정팀에서 일한 경험이 있어서 그 부분에 대한 공감대를 이야기했었습니다.

 

 

 

발표 이후 질의 응답 (시간 상 못했던 것들도 포함 )

발표가 끝나고 slido를 통해 질문을 받았는데요. 현장에서 답변 드린 부분도 있지만, 답변을 못했던 부분, 생각이 정리된 부분들도 있어서 받았던 질문들에 대해 다시 답변 글을 적어보았습니다. 

 

온보딩 경험을 나누어주셨는데 거꾸로 팀원을 맞이하는 기존 팀으로서 새로운 개발자 팀원의 온보딩을 효과적으로 도우려면 어떤 것을 갖추면 좋을까요?

- 이 부분은 팀장(매니저)의 입장과 팀원의 입장이 조금 다를 거라 생각합니다.

 

공통적인 부분으로 로컬에서 앱을 실행 하는 것과 팀 내 개발 문화에 대한 공유가 제일 도움이 될 것 같습니다. 

그 다음으로는 스몰 토크 관련으로 그동안 무슨 일을 했는지에 대한 질문들과 그 일들과 팀이 그동안 했던 점과 하고자하는 부분에 교차점들을 생각해보면 좋을 것 같습니다.  

마지막으로 같이 페어 플래닝, 페어 프로그래밍(with AI), 페어 리뷰 형태로 진행해본다면 다른 팀, 회사에서 경험했던 PR 문화와 코드 리뷰 문화와의 차이점을 서로 알아가고 오해가 생길 시점들을 먼저 이야기할 수 있고 기술적인 부분도 자연스럽게 같이 이야기할 수 있었습니다. 기존 팀원 입장에서도 도움이 많이 되었습니다. 

 

매니저의 입장에서 

- 온보딩을 주기 위해선 짧은 주기의 확실한 목표를 주는 게 가장 중요하다고 생각합니다. 

첫날 가장 먼저 줘야하는 건 팀 리소스에 대한 권한, 계정 신청이고 해당 프로세스를 거치고 당일에 컴퓨터에서 회사에 서버 혹은 앱을 실행하고 디버깅 등을 할 수 있으며 팀 내 lint 나 컨벤션 등에 대한 세팅을 하는 게 가장 좋다고 생각을 합니다.

첫 주에는 하루 단위, 그 다음은 주 단위로 해야할 일들을 체크리스트로 하다보면 개발을 진행을 하는 게 좋았던 것 같습니다.

만약 지연이 된다면, github 내에 코드 리뷰 했던 기록이나 git log 혹은 브랜치 등을 보게 하는 것도 꽤나 도움이 되는 부분이라고 생각합니다.  그리고 이런 지연점들을 모아 개선점을 잡는 게 좋지 않을까 싶습니다. 

 

 

팀원의 입장에서 

- 팀원의 입장에서 새로운 사람과 친하게 지내고 싶어도 사실 아직 어떤 성향인지 몰라 어색하기도 하고 실제 온보딩은 팀장이 진행하고 버디가 도와주는 형태가 대부분이기 때문에 초반에 인사 정도만 나누고 질문에 대해 대답하는 게 일반적인 것 같습니다. 그리고 회사나 팀마다 다르겠지만 초창기에는 팀장님과 우선 이야기를 하고 접근하는게 좀 더 맞는 방향일 것 같습니다. 

 

가장 도움이 되었던 건 정리된 링크, 온보딩 문서 등에 대한 공유입니다. 대부분 문서들은 파편화되기 쉽고 보고 계신 분들이 있기 때문에 쉽사리 위치를 변경하기도 어렵습니다. 신규 입사 입장에서는 고문서 수집과 비슷한데요. 그런 부분에 대해서 링크형태로 볼 수 있는 목차가 있다면 훨씬 도움이 될 거라 생각이 듭니다. 

 

신입으로서는 어떤 마음가짐을 가지고 있어야 할지도 궁금합니다

신입이라면, 이런 고민을 하시는 분이라면, 우선 관찰을 많이 해보라고 말씀드리고 싶습니다. 

첫인상이 물론 중요하고 수습을 통과해야하지만, 회사가 정말 좋은 곳인지 아닌지도 판단해야합니다. 또 마라톤이기 때문에 여유를 가지고 무엇을 먼저 해야 하는지 생각해보는 것도 중요하다고 생각합니다. 

그 다음으로 회사에 잘 적응하고 싶다는 관점에서는 우선 팀장님이 주시는 미션들이 있다면 이게 가장 최우선이 되겠죠

만약 이런 온보딩이 없는 환경이라면 기존 팀원들의 일들에 대해 도움을 줄 수 있는 방법에 대해 고민하는 것입니다. 내가 이 분들의 수시/상시 업무들을 뺏어와야지, 혹은 자동화 해야 겠다. 도 좋은 접근일 것 같습니다. 

우선 팀장 입장에서는 신규 팀원이 들어오면 온보딩이란 일이 생긴 것이고, 온보딩에서 가장 어려운 부분은 신규 팀원이 어디까지 알고 있는지 입니다. 그래서 내 고민과 이해 정도를 바깥으로 공유하는 것이 꽤 좋은 전략인 것 같습니다. 발표 때도 일지를 적을 때 온보딩 문서를 최신화한다는 생각과 전략으로 진행해보라고 했던 부분입니다. 

 

입사 초기에 회사에 대해 잘 모르는 상황에서 이런 말을 해도 될까하는 부분도 있었을텐데 이와 같이 내 편을 만드는 과정에서 조심스러웠던 점이나 그걸 어떻게 해결하셨는지 궁금합니다.

이 부분이 가장 공감이 됩니다. 잘 모르는 상황이기 때문에 최대한 근거를 우선 글로 적었습니다. 이 부분은 AI의 도움도 꽤 많이 받은 것 같습니다. 제가 잘못 생각했을 가능성도 있고, 실제로 사용되자 않는 deprecate 한 부분일 수도 있습니다. 이 부분은 레거시 히스토리가 섞여 있을 수 있어서 AI가 잘 못 잡아주던 것 같습니다. 

이야기를 꺼낼 때 최대한 가볍고 편안하게 의견을 물어봤던 것 같습니다. 가장 중요한 목적은 공감대이기 때문입니다.

이야기를 주고 받을 때 간단하게 아 그렇구나라고 넘어갈 수도 있지만, 기술적으로 파고드는 질문을 나눌 수도 있습니다. 이럴 때 정리된 글(공식 문서의 링크, 혹인 기업의 개발 블로그 글등)을 같이 이야기를 하면서 이야기를 하면 서로 얼라인을 맞추는데 도움이 된 것 같습니다. 

그리고 그 이야기를 들어줄만한 사람인지도 잘 판단해야했던 거 같습니다.

 

시니어면 코드리뷰뿐만아니라 스크럼이나 협의체같은 ai가 할수 없는 것도 많이 원할텐데 회사에 도입된 개발 문화가 있을까요?

제가 들어간 회사는 스타트업이라 기대치가 낮았는데, 생각보다 개발자 문화가 나쁘진 않았습니다. 매일 스크럼을 진행했습니다. 

그리고 B2C 서비스이기 때문에 협의체는 콜라보 관련된 내용이 많아 대부분 마케팅 선에서 끝났던 것 같습니다. 

AI가 할 수 없는 부분은 

 

당장 처리해야하는 업무들이 많으면 문서화를 계속 미루게 되는데 문서화를 해야할 좋은 시점이 있나요

문서화는 빠르면 빠를 수도 좋습니다. 하지만 문서화는 정말 귀찮은 과정이고 의사 결정이 자주 바뀌면 문서는 쓸모가 없어지는 경우도 많습니다. 다만 AI가 나오면서 문서화가 너무 편해졌습니다. 내가 AI와 이야기하던 맥락과 의논 점들을 최대한 간단하게 정리해서 핵심 요약 형태로 글을 만드는 것들을 반복하고 AI에게 몇 번 피드백을 주다보면 문서화가 편해집니다. 특히 문서를 쓰려고하면 완성본부터 떠올리기 때문에 문서를 적는데 막막하고 시작하기 어려운 느낌이 강해서 미뤄지는 부분도 있는 것 같습니다.

팀 내에 스크럼 문화가 있다면 스크럼에 적었던 맥락들을 따로 히스토리화 해보다보면 자연스럽게 문서가 되기도 합니다. 

 

프로젝트가 끝나고 회고 모임 등을 해보는 것도 방법입니다.

개인적으로 문서는 개발 관련 설명보다 의사 결정의 히스토리(변경 사항)와 사용법이라면 재현 가능한 형태(스크립트 형태도 추천)와 주의할 점 정도 성공적이라고 생각합니다. 이 정도만 갖춰진다면 최대한 간결한 형태로 문서를 메모로서 처음 접근하고 의견을 나눠보는 식으로 방향을 잡는 걸 추천드립니다. 너무 힘을 쓰는 건 좋지 않다고 생각이 듭니다.  

 

첫 회사도 개발을 직접 하는 회사인거 같은데, 대기업을 퇴사한 이유가 궁금합니다,,

희망 퇴직을 해줬고 돈을 좀 많이 줬습니다.(솔직하게)

 

퇴직을 마음 먹을 때 사이프 3기를 했었는데요. 그동안은 회사의 일들만 하다보니 우물 안 개구리같은 느낌을 받았고 매너리즘과 불안감이 조금 있었지만, 밖으로 나가는 것에 대한 부담감도 있었습니다. 사이프 내에서 같이 미션을 하고 공부를 하면서 우물 밖을 경험해보니, 다른 회사에서 일하는 것도 재밌을 것 같다는 생각을 들었습니다. 

 

또한 퇴사하고 회사에서 주는 월급 이외에서 돈을 벌어보는 경험을 해보고 싶었습니다. 은퇴 후에 경험할 걸 지금 해보고 싶었습니다. 내가 정말 경쟁력이 있는지 지금 확인해야 미래의 모습도 그려볼 수 있을 거라 생각을 했었습니다. 그래서 퇴사하고 바로 취업하지 않고 강사나 1인 개발자 생활을 좀 더 했던 것 같습니다. 

 

저는 다음주에 스타트업으로 첫출근하는 신입입니다 시니어 관점에서 이야기해주셨는데, 같은 스타트업으로써 스타트업에서 신입이 살아남으려면 어떤거부터 해보면 좋을까요

제가 시니어 연차에 가까워지다보니 시니어 기준으로 이야기를 했던 거 같습니다. 하지만, 제가 이야기한 방법들에는 연차가 그렇게 중요하진 않은 것 같습니다. (PR을 빠르게 올리는 거 정도가 훨씬 더 어려울 수는 있겠네요.)

 

특히 일지를 적고, 온보딩 문서에 기여한다는 마인드를 가진 다는 부분은 꼭 적용해보셨으면 합니다. 한 번 알려준 걸 두 세번 물어보지 않을 수 있고, 제대로 이해하고 있는지 아닌지를 공개해놓는게 도움을 받기 더 쉬울거라 생각합니다.  

 

주니어나 신입 분들의 성장을 어떻게 도와드리는 게 가장 좋을까요?

저는 의견을 나눌 때 고려한 점과 고려했어야 하는 점들을 여러 관점에서 물어봤던 것 같습니다.

 

예를 들어

• 어떤 기능을 추가할 때 기존 코드 내에 비슷한 부분이 있는지 확인해봤는지,
• 코드가 과도하진 않은지, 고려할 필요없는 것까지 고려가 된 건지,
• DB 작업을 할 때면 쿼리 패턴과 인덱스에 대해서 고려한 부분이 있는지,
• IO 작업이나 비동기 타이밍 관련 이슈가 있지는 않은지,
• 고려하지 않은 엣지 케이스들이 존재하는지, 
• 실제 서비스에 반영 되었을 때 모니터링은 어떻게 해야할지 등등

등등 이런 질문들을 좀 정리해놓고 일정이 촉박하지 않을 때 물어보면 도움이 많이 되셨던 것 같습니다. 

 

플랜 리뷰는 어떻게 진행하시나요?

질의응답 때는 DB 설계부터 전체적인 부분을 다 한다고 했는데요. 좀 더 정리해서 말씀을 드려보겠습니다.

우선 개발을 담당한 사람이 전반적인 플랜 문서를 짜옵니다. 

 

여기에 필수적으로 들어가는 건

• AS-IS -> To-Be
• DB 스키마 
• 요구사항 특이점과 트레이드 오프 
• 업무 분리 및 각 플로우 설명

입니다. 최대한 러프하게 빠르게 진행하려고 합니다. 

제가 아직 팀에 들어간지 얼마 안되었기 때문에 가능하다면 팀 내 플랜 문서 전에 페어 플래닝 등을 요청해서 기존 프로세스에서 놓친 부분이 있는지 의견을 나누는 편입니다.  

 

플랜 리뷰는 그 사안에 따라 좀 다릅니다. 일반적으로 질의 응답으로 구성되고 이번에 플래닝 때 제가 들었던 건 대부분 "과하다" 라는 의견이었는데요. 시간이 촉박해 AI에게 많이 맡겼더니 설계가 너무 추상화가 되어버렸던 기억도 있습니다.

 

이렇게 플랜 리뷰를 거치는 가장 큰 목적은 팀원 전부가 리스크를 공유하기 위해서가 큽니다. 프로덕션에 나간 코드는 개인의 책임이 아니라 팀의 책임으로서 되어야합니다. 로직이나 히스토리를 모르면, 다른 팀원들은 대응하기 어렵고 억울할 수도 있다고 생각합니다. 

 

시니어한테 기대하는 팀원의 역할이 궁금해요

시니어한테 기대하는 팀원으로서 역할이라고 해석해서 답을 하겠습니다. 

 

이 부분은 저도 정확히 모르겠습니다. 팀장님도 이 부분에 대해 말할 때 굉장히 추상적으로 표현했었거든요.

일정 관리부터 시작해서 팀 내 조언, 플래닝, 모니터링까지. 사실 다른 곳에서 경력을 쌓아서 실력이 좋아도 팀 내 프로세스와 코드 베이스를 완전히 이해하려면 시간이 필요하기 마련입니다. 

스타트업이다보니, 시니어가 많지 않은 환경이라 시니어에 대한 환상이 있는 건가 싶기도 했습니다. 

 

제가 팀원들에게 주려는 건 우선적으로 다양한 시각으로 접근하는 것과 의사 소통 이지 않을까 싶습니다. 

주니어가 많은 환경에서는 팀이 부당한 일을 받아도 그게 당연한 줄 알고 감내하는 경우도 봤습니다. 저도 그랬던 거 같고요. 그래서 책임에 대한 경계에 대해 이야기하는 것도 좀 중요하다고 생각합니다.