Search

Let’s Swift 2024 컨퍼런스 후기

contents

 Let’s Swift

Let’s Swift 2024 컨퍼런스에 다녀왔습니다.
KWDC 2023 이후에 오랜만에 참여한 iOS 개발자 컨퍼런스 였습니다.
Apple 생태계에서 함께 개발을 해나가는 다양한 iOS 개발자들의 생각과 지식들을 엿볼 수 있는 시간이라고 생각이 들어서 컨퍼런스 공지가 뜨자마자 회사에서 단체 신청하여 참여하게 되었습니다.
결론적으로 만족스러운 시간이었습니다.

 Session

if(KakaoAI) 2024 때처럼 호기롭게 듣고 싶던 세션을 정리해서 갔지만 이번에도 다 듣진 못했습니다.
다 듣고 싶지만 막상 가면 쉽지 않네요.. ᐠ( ᐕ )ᐟ
점심 먹느라 하나 건너뛰고 위의 세션들을 순서대로 듣고 왔습니다. iOS 관련 세션들로만 구성되다보니 모든 세션을 흥미롭게 듣고 왔습니다.
그 중에서도 공유하고 싶은 세션 몇가지를 소개해보고자 합니다.

 On-Device Debugging: EchoKit

＞ 간략한 세션 설명

•
EchoKit으로 구현한 앱 내 콘솔창으로 실시간 로그 확인 및 빠른 문제 진단
•
Echoable 프로토콜로 On-Device 디버깅 지원
•
소요 시간과 성능 관련 데이터를 기록하여 성능 최적화

＞ 세션 참여 후 느낀점

회사에서 일을 하게 되면서 정말 열렬히 성장의 필요성을 느꼈던 것 중 하나가 디버깅 능력입니다.
‘디버깅이 그렇게 중요한가?’ 라고 누군가는 생각할 수 있겠지요. 솔직히 화면을 그려내는 기술보다 디버깅 기술이 우위에 있다고 생각합니다. 문제가 발생했을 때, 정확한 문제 지점을 파악하고 그에 맞는 방법을 찾아서 빠르고 안전하게 문제를 해결하는건 정말 힘들기 때문이죠.
아직도 디버깅을 잘 못합니다. 잘하고 싶은데. 🫨
아무튼 더 좋은 디버깅에 대한 니즈가 있는 상황이었기에 도영님이 발표하신 On Device Debugging: EchoKit 세션을 들었습니다.
세션을 들으면서 느꼈던 첫번째 생각은 ‘어떻게 저런 기능을 만들어야 겠다고 생각을 했지?’, 두번째 생각은 ‘우리 앱에도 저런 기능이 있다면 다방면으로 좋겠다’ 입니다.
‘우리 앱에도 저런 기능이 있다면 다방면으로 좋겠다’
콘솔 로그는 실제로 개발자들만 볼 수 있는 영역입니다. Xcode 콘솔을 사용해서 보기 때문이죠. 기획자나 QA는 콘솔없는 앱만 볼 수 있습니다. 따라서, 앱 내에 문제가 생겼을 때 어떤 문제가 발생했는지 자세하게 알지 못합니다. 이 부분을 알기 위해서 따로 개발자와 소통해야 하는거죠.
만약, QA 환경에서 콘솔 로그 기능을 켜둔다면?
굳이 개발자에게 물어보지 않고 어떤 문제가 발생했는지 알 수 있습니다. 서로에게 윈윈인 셈이죠. 성능 관련 로그도 심어두고 볼 수 있기 때문에 정확한 지표로 성능 이슈를 확인할 수 있게 됩니다. ʕ ᵔᴥᵔ ʔ
당장 다른 부서와의 협업뿐만 아니라 개발자 디버깅 생산성도 높아지기에 여러모로 필요한 기능이었습니다.
↓↓ 아래 남겨둔 링크로 들어가시면 EchoKit를 만나보실 수 있습니다. ↓↓

 새로운 회사, 새로운 프로젝트의 구성원으로 빠르게 적응하는 방법

＞ 간략한 세션 설명

•
개발자로서 역할을 잘하기 위한 7가지 방법
◦
코드 품질 유지
◦
설계 분석 및 시각화
◦
재설계를 통한 개선
◦
리뷰 문화 활성화
◦
디자인 패턴 학습
◦
모듈화와 접근 제어
◦
꾸준한 연습과 학습

＞ 세션 참여 후 느낀점

세션 제목에서 느껴지듯 개발 관련 내용을 발표하는 세션은 아닙니다. 어떻게 하면 내가 회사에서 책임과 역할을 개발자로서 잘 수행할 수 있는가에 대한 내용을 다루는 발표입니다.
현재 개발자로 회사에서 근무한지 일년도 되지 않았기 때문에 세션 발표를 통해서 얻어가는 점이 있을 거라고 생각이 들어서 세션을 듣게 되었습니다.
위에 정리되어 있듯이 우리가 개발자로서 회사에서 제 역할을 잘하기 위한 7가지 방법을 소개합니다.
현재 잘 하고 있다고 생각이 드는 부분도 있었고, 시간이 부족해서 간과해버리고 있던 부분도 있었으며, 공부해야 한다고 생각만 하면서 실행하지 않은 부분도 있습니다.
[ 현재 잘 하고 있다고 생각이 드는 부분 ]
•
코드 품질 유지
코드를 쓸 때는 글을 쓴다는 생각으로 써내려가는 편인데, 덕분에 다른 사람이 이해하기 편하도록 네이밍을 할 수 있습니다. 읽기 쉬운 코드는 팀원이 코드 리뷰를 진행할 때도 부담이 적기 때문에 복잡한 코드보다 더 의미있는 코드 리뷰를 받을 수 있게 됩니다.
•
설계 분석 및 시각화
항상 새로운 프로젝트를 시작하기 전에 클래스 다이어그램을 그려서 기존 코드의 관계를 미리 시각화해두는 편입니다. 첫 일감을 진행하면서 그렇지 못해서 데인 부분이 많았기에 미리 시각화해둡니다. 다른 팀원과 대화를 나눌 때도 편하게 볼 수 있고, 어떤 부분이 개선되어야 할지도 한 눈에 보기 쉽기 때문에 여러 모로 좋습니다.
•
리뷰 문화 활성화
최대한 모든 PR을 확인하려고 노력합니다. 그리고 가능하면 의미있는 리뷰를 남기려고도 합니다. 의미있는 리뷰라고 한다면 문제를 발생시킬 여지가 없는지 확인하고, 작성자가 의도한대로 코드가 작성되었는지 봐주고, 성능적으로 개선할 부분이 없는지 등을 보는 것이라고 생각합니다. 하지만 가끔은 소소한 궁금증을 남기기도 하는데 그런 질문에서도 배워갈 점이 많은 걸 보면 리뷰는 하면 할수록 reviewer, reviewee 모두에게 득이 되는 행위라고 생각합니다.
[ 현재 간과한 부분 ]
•
코드 품질 유지
일정 내에 기능 구현을 완료해야하니 기존에 사용하고 있던 메서드가 있다면 해당 메서드에 원하는 코드만 추가하여 작성하는 일이 비일비재합니다. 이런 경우 메서드의 크기가 커지게 되고, 하나의 메서드에서 다양한 작업을 수행하게 됩니다. 결국, 메서드를 읽기 어려워지는 순간이 오게 되죠.
일정이 촉박한 경우에도 메서드, 클래스를 잘 분리해서 하나의 역할만 할 수 있도록 조금 더 노력해야 할 거 같습니다.
•
모듈화와 접근 제어
코드를 작성할 때, 접근 제어 설정을 중요하게 생각하는 편입니다. 다른 클래스나 구조체가 알지 못해야 하는 프로퍼티나 메서드가 밖으로 보인다는건 누군가가 해당 프로퍼티나 메서드를 잘못 사용하게 될 거라는 암시같은 거죠. 하지만, 완벽하게 쓰느냐 라고 물어본다면 아니라고 답할 수 있을 거 같습니다. 흔하게 사용되는 public, private, internal은 잘 사용하고 있지만 그 외 접근 제어자는 잘 사용하지 않는 거 같습니다. 가장 큰 이유는 제가 의미를 명확하게 알지 못해서 입니다. 언제 fileprivate를 붙이는게 좋겠다 라는 명확한 개념이 박혀있지 않아서 그런 거 같네요. 공부를 해야겠지요. 공부해야 합니다.
[ 반성해야할 부분 ]
•
재설계를 통한 개선
변명이지만, 이리저리 새로운 작업에 치여서 “기존에 있던 코드를 재설계해봐야지”라는 시간적, 심적 여유가 없었습니다. 작업을 진행할 때, 리팩토링을 곁들이는게 아직은 어렵습니다. 오히려, 작업의 범위가 커져서 일정을 제대로 맞추지 못할까봐 걱정이 되더라구요. 새해가 가까워지니 내년 목표로 두고 실천해봐야겠습니다.
•
디자인 패턴 학습
무려 2024년 목표 3번째로 작성했지만, 하지 못한 일 중 하나 입니다. 공부해야지 공부해야지 하다가 공부해야지만 해버린… 일하면서 디자인 패턴의 중요성을 많이 느낍니다. 패턴을 적용해서 구현하는 경우도 많고, 용어가 통일되어서 팀원들과 대화 나누기도 쉽기 때문이죠. “알고 있는 패턴을 적용하면 좋겠다!” 라는 생각이 드는 그 날까지..
느낀점을 쓰다보니 개인 회고를 한 듯 하군요.

 마치며…

여러 세션을 들으며 iOS 개발을 사랑하는 사람들이 참 많다는 걸 느꼈습니다. 컨퍼런스에 참여할 때마다 사람들의 다양한 경험담을 들으며 참 많이 반성합니다. 항상 생각만 하고 실행은 안하는 게으른 개발자이기에, 이번 컨퍼런스에서 조금 더 부지런해질 원동력을 얻고 갑니다.