이번 글에서는 지난 3년간 개인 기여자(Individual Contributor, IC)가 아닌 한 명의 리더로서 좋은 리더란 무엇인지, 또 좋은 리더가 되려면 어떤 역량이 필요한지에 스스로 고민해 봤던 내용에 관해 적어보려고 한다. 아무리 기여자로서 일을 잘했던 사람이라고 해도 이 경험이 좋은 리더로서의 역량으로 이어지리란 법은 없기 때문에 자연스럽게 이런 고민을 시작하게 되었다. 리더에게는 단지 커뮤니케이션뿐 아니라, 나 스스로에 대한 이해와 인간 본연의 심리와 본능, 조직의 특성에 대한 이해와 같은 인문학적인 소양까지도 필요하다고 느꼈다.

정규 표현식이라는 것이 왜 세상에 나오게 되었는지, 어떤 환경에서 구동되는 것을 전제로 만들어진 것인지부터 알고 나면 자연스럽게 정규 표현식의 한계점도 이해할 수 있게 된다. 이번 글에서는 필자와 같은 프론트엔드 개발자에게는 너무나도 익숙한 HTML이라는 언어를 정규 표현식만으로 파싱 할 수 있는가라는 질문을 통해 정규 표현식이 개발된 목적과 한계에 대해서 이야기해보려고 한다.

이번 포스팅에서는 웹 개발자라면 한 번쯤은 얻어맞아 봤을 법한 CORS(Cross-Origin Resource Sharing) 정책에 대한 이야기를 해보려고 한다. 사실 웹 개발을 하다 보면 CORS 정책 위반으로 인해 에러가 발생하는 상황은 굉장히 흔해서 누구나 한 번 정도는 겪게 된다고 해도 과언이 아니다. 지금 보면 나름 친절하게 해결 방법을 잘 알려주고 있는 에러 메시지이지만, 웹 어플리케이션 개발 경험이 전무하던 당시에는 이 메시지를 보고도 뭘 어떻게 해야 하는지 한참 헤맸던 기억이 난다.

아무리 정규식의 기본적인 사용 방법을 알고 있다고 해도 실제로 정규식을 사용해야 하는 상황이 되면 눈앞이 깜깜해지기 마련이다. 그래서 이번 글에서는 실제로 필자가 지금까지 일을 하며 경험했던 여러 가지 상황을 토대로 정규식을 어떻게 사용했는지에 대한 몇 가지 예시와 설명을 조금 곁들여 볼까 한다. 정규식을 가장 많이 사용하는 상황인 “유저의 입력 검증”, “원하는 정보 찾기”, “문자열을 원하는 포맷으로 변경하기”를 예시로, 문제를 정의하고 정규식을 사용하여 문제를 해결해보도록 하자.

정규식의 정식 풀네임은 정규 표현식(Regular Expression)이지만, 사실 정규 표현식이라는 풀네임보다는 정규식, Regex, 규식이형 등으로 더 자주 불리고는 한다. 정규식은 패턴을 표현할 수 있는 일종의 표현식이고 이 표현식을 문자열에 적용하여 원하는 부분을 쏙쏙 끄집어낼 수 있는 굉장히 편리한 도구이지만, 그 특유의 악랄한 가독성 덕분에 왠지 모를 기피의 대상이 되고는 한다.

보통 개발자들에게 좋은 설계라고 했을 때 TDD, DDD, SOLID, 변경에 열린 구조, 순수 함수 등 기술적인 토픽들에 대해서 이야기하는 사람들은 굉장히 많지만 비즈니스에 대한 이야기를 하는 사람은 많지 않다. 개발자가 단순히 프로그래밍만 하는 사람이 아니라 프로그래밍을 이용한 비즈니스를 하는 사람들이라는 사실을 생각해보면 조금은 이상한 상황이라는 생각이 들었다. 이번 글에서는 개발자와 멀고도 가까운 주제인 비즈니스에 대해서 이야기 해보려고 한다.