들어가며
오늘(2023.8.27 일요일), 점핏에서 개최하는 백엔드 개취콘에 다녀왔다. 기본적으로 오프라인 참여권은 추첨제로 진행되는데, 운 좋게 당첨되어 주말을 알차게 보낼 수 있었다.
세션 내용을 그대로 적기보다는, 각 세션을 들으며 받은 인사이트와 신입 백엔드 개발자로서 보낸 1개월 동안의 경험을 엮어 간단하게 남겨보려고 한다. (세션 내용이 궁금하신 분들은 곧 다시보기 영상이 업로드된다고 하니 그 부분을 참고해주시면 감사하겠습니다.)
세션 후기
총 4개의 세션 중에 일정 상 2개의 세션만 듣게되어 다소 아쉬웠으나, 그럼에도 얻은 인사이트가 꽤 많다. 또, 세션 내용이 내가 요새 겪고 있는 상황과 비슷한 부분이 많아 공감도 많이 되었고, 그 과정에서 들었던 생각과 고민을 세션 요약과 함께 남겨본다.
중요한 건 인터페이스야 - 손진규님
첫 번째 세션은 소통 비용에 대한 내용이었다. 진규님의 세션을 내가 이해한대로 요약하자면 다음과 같다.
- 소통 비용을 줄이기 위해 프로젝트에 참여하는 구성원이 모두 높은 이해도를 가져야한다.
- 기획 초기 단계부터 빠른 피드백을 주고 받음으로써, 프로젝트에 대한 높은 & 같은 이해도를 가질 수 있다.
- 고칠 때 비용이 많이드는(= 불확실성이 높은, 미루고 싶은)것 부터 약속하자.
기획자, 디자이너, 클라이언트 개발자, 백엔드 개발자가 참여하는 프로젝트가 있다고 하자. 그리고 기획 -> 디자인 -> 클라이언트 -> 백엔드 순으로 개발 프로세스가 진행된다고 하자(실제로 지금 다니고 있는 회사에서도 이런 프로세스를 따르고 있다.). 클라이언트까지 개발이 완료되거나 진행 중인 상황에서 이제 막 백엔드 개발자가 프로젝트에 참여, 또는 요구사항을 전달받아 '이거는 개발이 좀 힘든데요?' 라고 한다면 결국 기획 단계부터 다시 고쳐야 하는 상황이 발생한다. 그리고 이런 상황은 다시 많은 시간을 할애하게 만든다(정말이지 얼마나 비효율적인가.). 그래서 진규님은 모든 프로젝트 구성원이 기획 단계부터 참여하면서 어떤 기능이 가능한지, 어떻게 구현할지에 대해 피드백을 주고받으며 프로젝트에 대한 이해도를 높이고 생각의 싱크를 맞춰나가야한다고 말씀하신 것 같다.
빠르게 실패하기
세션을 들으면서 한 가지 책이 떠올랐는데, 바로 김창준님이 쓰신 <함께 자라기>이다. 책 내용 중에는 '빠르게 실패해야한다.' 라는 내용이 나오는데, 세션에서 구성원들이 기획 초기 단계 부터'이건 안 돼요. 이건 이렇게 해봐요'라고 피드백을 주고 받는 행위 역시 여기에 속한다고 생각했다.
나 역시 최근에 빠르게 실패를 하지 않아서 문제된 경우가 있다. 회사에서 최근에 시작한 프로젝트의 기획 회의에 같이 참여하고 싶다고 뜻을 밝혀 회의에 같이 참여하게 되었는데, 기획자분과 내가 서로 다르게 이해해서 빚어진 문제였다.
'고객에게 A 다음 B를 보여주는게 좋겠다.' 라고 얘기가 되어서 그에 유리한 도메인과 테이블을 설계하고 있었는데, 이틀 정도 지나서 선임분께 중간 보고를 드렸더니 그게 아니고 '기존 방식인 AB를 고객에게 한 번에 보여주는 것' 으로 진행된다는 답변을 듣게 된 것이다. 가슴 철렁한 순간이었다.
(보안상 위 예시는 일부 각색된 것임을 밝힙니다.)
나는 이미 도메인을 설계한 후에 기능을 구현하고 있는 단계였고, 설계의 많은 부분을 변경하고 기존 기능과의 호환성을 맞추느라 하루를 더 쓸 수밖에 없었다. 물론 내 도메인 설계 역량이 부족한 탓도 있다. 그러나 설계만이라도 빠르게 마쳐서 피드백을 받았다면 많은 시간을 세이브하고, 기능 테스트를 할 시간 역시 충분히 확보할 수 있었을 것이다.(지금 생각해보면 더 늦기 전에 지금이라도 확인해서 다행이라고 하는게 맞을 것 같다.)
빠르게 실패하지 않았고, 그로인해 리소스를 예상보다 더 많이 썼다. 더 빨리 더 많이 실패하자. 모르면 물어보고, 확실성을 더하자. 적어도 그렇게 하면 같은 일에 들어가는 시간을 줄이고, 아낀 시간은 더 좋고 안전한 프로덕트를 만들어낼 것이다.
내게 맞는 성장 환경 찾기 - 박준하님
준하님은 토스뱅크의 기업 문화와 성장하는 주니어 백엔드 개발자의 특징에 대해 말씀해주셨다. 내가 꽂힌 것은 후자였다.
- 성장하는 주니어의 특징은 '끝까지 파보는' 성격을 가진 사람들이다.
- 간헐적인 문제, 운 좋으면 나타나지 않을 문제를 그냥 넘기는 것이 아니라 끝까지 파서 해결하는 경험이 중요하다.
- 문제를 어떻게 발견하고, 해결하기 위해서 어떤 노력을 했는지가 중요하다.
- 끝까지 파보는 것은 엔지니어로서의 자긍심이다.
생각해보면 나 역시 끝까지 파보는 것을 좋아하는 편이다. 그러나 간헐적인 문제를 제대로 파서 해결해본 경험은 없다. 물론 아직 그런 문제를 발견하지 못했기 때문일 수도 있다. 현재 QA 엔지니어 분들이 쓰시는 Admin 서비스에 약간의 불편함이 있는데, 그런 UX 자체를 문제로 인식해서 시급한 일이 없을 때 개선해봐야겠다는 생각이 들었다. 문제를 문제삼지 않는다고 해서 문제가 아닌 것은 아니고, 나 또한 더 빨리 QA 분들께 피드백 받고, 그렇게 선순환을 만들면 회사 전체 관점에서 생산성에 조금이라도 기여할 수 있을 것 같다.
공부 많이 해라
이 밖에도 Q&A 시간에 공부와 관련된 조언들을 해주셨다.
- 100 만큼 공부해야할 것이 있다고 한다면, 10씩 나눠서 공부하지 말고 50씩 해야한다.
- 초반에 공부 많이 해놓고 나중에 1씩 하는 것이 좋다.
- 아는게 많아져서 시야가 더 넓어진다.
'공부해라. 주니어 때 많이 해둬야한다.' 정도로 요약할 수 있겠다. 과연 나는 공부를 많이 하고 있는가 라고 자문해본다면 절대 그렇다고 하진 못하겠다. 원래 평소에 조금씩 공부하는 편이었고, 그래서 다행히도(?) 출근을 한다고 공부량이 크게 줄거나 하진 않았다. 일정 시간을 채우면 휴식을 취하곤 했다. 그런데 어느 순간 부터 실력이 확 늘지는 않는다는 생각이 들었고, 강연을 들으며 그 원인이 input 이 부족하고, 아는게 적어서라고 스스로 결론을 내렸다. 매일 공부라고 해봐야 통근 시간을 포함해서 길어야 두 시간 정도 하고 있기 때문에, 절대적으로 부족한 양인 것은 맞다.
그래서 조급한 것인가라고 묻는다면 '조금.' 정도로 답변하고 싶다. 어쨌든 루틴을 지켜가고 있고, 또 회사에서도 많은 코드를 작성하며 구현력도 조금씩 느는 것을 느끼기 때문이다. 교육을 받을 때는 코드를 짜면서 어떻게 하면 책임을 잘 분리해서 이 객체 저 객체에게 책임을 할당할까 를 계속 고민했다면, 지금은 어느정도 선에서 마무리해야 최소한의 가독성을 챙기면서 기간 안에 구현해낼 수 있을까 를 고민하고 적용해가며 실험해가고 있다. 기간이 정해진 프로젝트이다 보니, 경계값 예외 처리 등 중요한 부분에 힘을 주고, 당장 잘게 쪼개지 않아도 되고, 잘 돌아가고 테스트에 의해 검증 받고 있다면 다음 구현으로 넘어가고 있다. (무조건 잘게 쪼개는 것도 꼭 좋은 것만은 아닌 것임을 경험하고 있다.) 비로소 교육 때 멘토님들께서 마감기한을 잘 지킨, '돌아가는' 코드가 우선순위라고 강조하셨던 것을 체감하는 중이다.
어떻게든 주어진 요구사항은 지켜내야하기에, 오히려 현업에 뛰어들고 나서 학자형으로 공부하던 방식이 조금씩이나마 야생형으로 바뀌어가고 있음을 느낀다. 지금은 이론적인 부분보다도, 많이 굴러서 구현력을 키우고 싶다. 그렇다고 이론을 소홀히 한다는 것은 절대 아니고, 현재 루틴을 잘 유지하면서 공부시간도 차차 늘려가다보면 어느새 스스로 세운 기준들을 갖고 주어진 태스크를 잘 수행해나가는 주니어가 되지 않을까하고 기대한다.
그 외
- 개발자로서 첫 커리어를 시작한지 이제 막 1개월이 지났다. 가장 많이 느낀 것은 내 실력 부족과 절대 코딩이 개발이 전부가 아니라는 것이다. 코딩은 기본이고, 정량화 불가능한 소프트 스킬같은 부분이 핵심이라는 것을 느낀다. 솔직히 소프트 스킬을 어떻게 하면 늘릴 수 있을지 정확히는 모르겠다. 더 귀기울이고, 더 자주 얘기 나누고, 모르는 것이 있으면 찾아보고 '잘' 질문하고, 그렇게 빠르게 실패하고. 이런 것들부터 하나씩 해나가봐야겠다.
- 문득 나는 왜 이렇게 '계속 공부해야겠다'라는 생각이 드는지 잠깐 고민해봤는데, 물론 개발자로서 평생 공부해야하는 것도 있지만, 근본적으로는 개발 공부라는게 꽤나 성과가 가시적이기 때문이라는 결론을 내렸다. 하면 늘고, 아는 만큼 보이고, 또 알게된 것을 나누는 것이 즐겁다. 회사 동기들과 고민해볼만한 주제로 토론하는 것도 꽤 신난다.
- 별개로 그냥, 진짜 좀 잘하고 싶다. 더 잘해질수록 더 어려운 작업을 만나겠지만, 그 때가 오면 내 실력도 늘어있을테니까 지금처럼 재밌게 개발하고 있지 않을까?
마침.
부족한 글 읽어주셔서 감사합니다.
잘 보고 가요 선호님! 좋은 내용들이 많네요 😀