올해도 작년과 마찬가지로 인프콘 티켓팅에 실패했다. 하지만!!
다행히 이번에도 인프런에 다니는 지인이 티켓을 하나 선물해줘 인프콘에 다녀올 수 있었다.
작년 인프콘에서는 발표세션이 아닌 즐길거리에 초점이 맞춰져 있어서 부스나 네트워킹 세션, 커피챗 등의 활동을 하러 다녔었기 때문에 아쉬움이 있었다. 이번에는 후회 없는 인프콘을 보내고자! 발표세션을 다 찾아보고 내가 현재 가지고 있는 고민의 실마리가 될 수 있는 발표세션들을 미리 선택하고 인프콘에 다녀왔다.
회사에서도 휴가를 쓰지 않고 인프콘을 다녀올 수 있도록 편의를 봐주셨다! 대신 인프콘의 발표 세션을 바탕으로 기술공유를 준비하고 네트워킹 세션에서 개발자들을 인터뷰해오라는 미션을 받았다!
1. 부스
다양한 기업 부스와 인프런의 자체 부스가 있었다.
이번 인프콘의 목적은 발표세션 최대한 많이 듣기였기 때문에 세션이 시작되기 전, 잠깐 부스 2~3곳에 들러 티셔츠나 스티커, 손풍기 등의 선물을 받았다!
2. 딥다이브 세션
2층의 강의실에서 딥다이브 세션이 진행되었다. 원래 이런 세션이 있는 줄도 몰랐는데 인프콘에 같이 온 회사 동료가 소개해줘 알게 되었다. 마침 우리 회사 내에서 제일 큰 화두가 기존 레거시 프로젝트의 개선이었는데 고민에 도움이 될 것 같아 참여를 결정했다.
세션이 12:20~13:40로 진행되었기 때문에 간단히 요기를 할 수 있는 샌드위치를 나눠주셨다!!
2-1. 10년 된 레거시 PHP 모노리스 갈아엎은 후기
포트원의 장두호 CTO님이 3년 간의 레거시 프로젝트 개선 과정을 발표해주셨다.
레거시라고 해서 무조건 나쁜 것은 아니다. 하지만 레거시가 성장의 병목이 될 때는 근본적인 개선이 필요하다.
예전에는 레거시를 나쁜 것이라고 동일시하여 봤던 적이 있었다. 내가 처음 입사하고 1년 동안 해왔던 작업들은 레거시를 유지보수하는 일이었다. 그래도 3년 정도밖에 진행하지 않은 프로젝트(기술 스택은 Spring Boot v2.3에 MyBatis)였기 때문에 그렇게 엄청난 레거시는 아니었다. 하지만 'JPA를 쓰지 않기 때문에', '스프링을 제대로 사용하지 않아서' 등의 이유로 그냥 왠지 모르게 마음에 들지 않았던 것 같다.
그러다가 2013년부터 유지보수되지 않은 레거시 끝판왕 쇼핑몰 프로그램을 맡았던 적이 있었다. 스트레스가 이만저만이 아니었다. 외주 업체에서 일정을 맞추기 위해 아무런 고민 없이 작성한 코드 + 내가 알지 못하는 언어 + 버전 관리 툴 미사용 등등의 요인 때문에 더 힘들었다. 이런 극단적인 상황에서는 당연히 근본적인 개선이 요구되었다. 2개월에 걸쳐 새로운 기술 스택을 사용한 프로젝트로 갈아 엎는 작업을 하면서 느낀 점은 기존 레거시를 갈아 엎는다는 게 쉬운 일은 아니라는 점이었다.
기존 비즈니스 로직이 잘 돌아가는 것은 물론 앞으로의 기능 추가를 위해 코드의 확장성 또한 고려해야 했다. 그 길 위에는 수많은 버그가 깔려 있었다. 결국 2개월 동안 내리 야근을 한 끝에 결국 프로젝트를 성공적으로 끝마쳤지만, 그 과정이 너무 힘들었기 때문에 "정말 필요한 게 아니라면 레거시를 뒤엎는 모험은 함부로 하는 게 아니구나"라는 걸 느꼈다.
그런데 여기서 "근본적인 개선이 정말 필요하다"라는 시점이 구체적으로 어떤 때일까? 생각해봤을 때 한마디로 표현하기 어려웠는데 딥다이브 세션에서 "레거시가 성장의 병목이 될 때"라는 얘기가 와닿았다. 그렇다. 프로젝트가 더 이상 앞으로 나아가기 판단되면 그 때는 근본적인 개선을 하는 게 맞다.
our temporary solution to a temporary problem has become a permanent problem.
- Naval Ravikant
발표 자료에 해당 문구가 보였을 때 남일 같지 않았다.
항상 회사의 초점은 "속도"에 맞춰져 있었다. 물론 스타트업에서 속도는 굉장히 중요하다. 짧은 시간 안에 더 많은 시도를 하고 더 많은 피드백을 받아야 비즈니스 완성도가 높아진다.(애자일의 철학과 상통하는 부분) 하지만 그렇게 "속도"만 바라보고 기능이 추가되다 보니 문제가 발생하기 시작했다. 어느 순간부터 버그가 양산되었고, 오히려 나아가는 속도가 느려지기 시작했다.
동료들은 배포에 더 많은 피로감을 느끼게 되었다. "어? 이거 레거시가 성장의 병목이 될 때라고 표현한 게 이런 걸 얘기하는 게 아닐까?"라는 생각이 들었다.
팀에서 현재 코드베이스를 개선하는 방법이 논의되고 있다. 하지만 "임시적인 해결책"이 될 가능성이 높다고 생각한다. "최악의 코드를 차악으로 변경하는" 작업이기 때문이다. 그런 개선으로 잠시 좋아질 수는 있겠지만 결국 "임시 해결책"은 또 다른 문제를 만들어내게 된다.
근본적인 개선이 진행되어야 팀원들도 동기부여를 크게 받고, 기술적인 성장을 한다는 느낌, 의미있는 일을 한다는 느낌을 받지 않을까?
모놀리스에서 점차 MSA로 발전해나가는 것이 좋다고 생각합니다.
마이크로서비스를 도입하기 전에는 다양한 요인을 고려하고, 도입한다면 왜 그래야 하는지 이유가 명확해야 한다. 엔지니어의 수는 어떻게 되는지, 기술적인 제약이 있는지, 데이터 등 많은 조건을 고려해봐야 한다.
v2를 한다고 해서 꼭! 마이크로서비스를 도입하는 방향으로 개선하지 않아도 된다. 오히려 도입이 'microservice tax'로 이어질 수도 있다. 따라서 모놀리스로 시작해 점차 MSA로 발전해나가는 방향도 염두에 두자.
레거시는 어떻게 유지보수하셨나요? => 구버전과 신버전 팀.
하지만 고객의 요구사항은 계속 들어온다. 결국 레거시를 유지보수해야 하고, v2는 v2대로 앞으로 나아가야 한다.
외부에서 바라볼 때는 시스템 개선 없이 계류되는 것으로 보일 수 있습니다.
레거시 개선은 상당히 긴 호흡으로 진행되는 작업이다. 포트원에서도 3년이라는 시간이 지났음에도 레거시가 아직 남아있다고 한다. "끝이 없는 작업"이라는 말씀까지 하셨다. 결국 레거시를 개선하는 문제는 이해당사자를 잘 설득하는 문제로 이어진다.
결국 어필을 잘 해야 한다. 생산성이 얼마나 올랐는지, 장애 지표가 얼마나 좋아졌는지 등의 수치를 통해 증명해야 한다.
3. 발표 세션
3-1. 지속 성장 가능한 설계를 만들어가는 법
토스페이먼츠의 김재민 님이 발표를 진행해주셨다.
"설계를 잘하는 법은 설계를 하지 않는 것이다."
처음에 이 말은 듣고 벙쪘다. ??? 무슨 소리를 하시는 거지???
나는 기능을 추가할 때 설계가 빈약한 것이 약점이라고 생각했다. 옆에서 동료는 도메인 모델링도 휙휙 하고 코드를 작성하기 전에 고민을 잘하고 구현에 돌입하는 것 같았다. 최근에서야 "오브젝트"라는 책을 읽고 간단하게 메시지 중심의 객체 설계라도 조금씩 하기 시작했다.
이런 고민이 있었기에 위 세션에 들어갔던 것인데 돌아오는 대답이 가히 충격적이었다.
구현할 때 2가지만 사용하면 됩니다. 개념과 격벽
나와 다른 점이 있다면 나는 그냥 구현에 들어가는 반면, 발표자님은 "개념"과 "격벽"이라는 도구를 사용했다는 점이다.
여기서 말하는 "개념" 도메인 객체와 동일하다고 봐도 된다.
개념을 생각하다보면 자연스럽게 그룹화를 하게 되는데 구분 없이 그룹화를 하면 오히려 장황해보일 수 있기 때문에 "격벽"이라는 것을 개념 사이에 세워 개념 간의 1차적 분리를 시도해볼 수 있다. "격벽"을 통해 개념의 흐름을 통제할 수 있게 된다.
패키지와 접근 제한자를 잘 활용해보면 "격벽"이라는 것을 효과적으로 만들 수 있을 것 같다.
요구사항은 계속 변합니다. 그래서 항상 준비해야 합니다.
요구사항은 계속 변하기 때문에 완벽한 설계란 환상입니다. 완벽한 설계가 있다면 그건 발전 없고 죽어가는 서비스나 가능한 얘기입니다.
소프트웨어는 soft해야 합니다.
그러니 이런 말은 하지 맙시다.
1. 요구사항이 완벽해야 설계 가능해요.
2. 우리 설계에서 그건 개발 못해요.
3. 설계해 봐야 개발 일정이 나옵니다.
이런 말들은 설계를 잘못 해놓고 하는 말입니다.
"그 요구사항 수용할 수 없어요." 회사에서 일을 하다보면 이런 얘기가 종종 들려온다.
나는 이런 말을 하지 않았다고 단언할 수 있을까? 아마 아닐 것이다.
소프트웨어는 문제를 해결하기 위해 존재하는 것이고 어떻게든 방법이 있다.
현실 세계를 소프트웨어에 끼워 맞추려 하지 말고, 그럴 시간에 소프트웨어를 최대한 활용할 수 있는 방법을 고민하자.
설계를 성급하게 하면 변화에 취약해집니다. 과도한 설계는 모든 것을 망가트려요. 설계는 필요한 만큼만 하는 게 좋습니다.
섣불리 추상화를 했다가 오히려 코드를 다 갈아엎는 경험이 한 번쯤은 있을 것이다.
코드를 작성하다보면 변경이 다른 곳까지 전파되어 불편하다는 느낌이 반복될 때가 있다. 또, 동료 개발자가 내가 만든 코드를 가져다 사용하기 어려워 하는 경우도 있었다. 나는 그 때가 코드를 추상화하기 가장 좋은 시점이라고 생각한다.
그냥 즉시 구현을 했으면 좋겠습니다. 증명하고 피드백 하세요. 테스트 코드로 반복할 수 있는 환경을 만들어 놓고 계속 반복하세요. 테스트 코드와 코드 작성을 반복하다보면 설계가 자연스럽게 만들어지게 됩니다. 결국 검증이 완벽한 설계를 위한 길입니다.
가장 먼저 떠오른 것은 TDD다.
"테스트로 요구사항을 세팅해놓고 요구사항에 맞게 돌아가는 코드를 만든다"라는 철학은 같았기 때문이다.
3-2. 혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?
아임웹의 김지호 님이 강연해주셨다.
데이터에 크게 관심이 없었기 때문에 가장 기대가 낮았지만 가장 흥미로웠던 주제였다.
이 내용만큼은 회사 분들에게 꼭 공유해야겠다고 느낄 정도였다.
백엔드 엔지니어는 행을 잘 읽고 쓰는 것이 중요합니다. 반면, 데이터 엔지니어는 어떨까요? 열을 잘 읽고 쓰는 것이 중요합니다.
백엔드 엔지니어와 데이터 엔지니어는 데이터를 바라보는 관점의 차이로 인해 많은 어려움을 겪는다고 한다.
예를 들어 테이블의 column에 json이나 array로 들어가 있다고 해보자. 백엔드 개발자 입장에서는 행 단위로 처리될 때 json과 array 타입의 처리가 간편하다. 하지만 해당 컬럼에 데이터 엔지니어링 요구사항이 들어오게 되면 어떻게 될까? 1억 7천만 row의 json과 배열을 모두 스캔해야 되는 상황인데 그게 가능할까? 열 단위 분석 요청의 비용이 너무 많이 들기 때문에 불가능할 것이다.
테이블을 모델링 하기 전에 한 번쯤 고민해보자. 이 데이터가 어떻게 쓰일 것인지.
아마 대부분의 테이블이 데이터 엔지니어링의 사정권에 들어오기 때문에 웬만하면 테이블은 정규화되어 있는 것이 좋다.
설계 맥락은 항상 중요하다.
결제방식에 따라 테이블에 컬럼을 추가하는 식으로 개발할 수도 있다. 그런데 테이블에 comment가 없다? 설계 맥락을 파악하고 싶어도 이 테이블을 만든 장본인은 이미 퇴사하고 없을 수도 있다. 이는 생산성을 떨어뜨리는 주범이다.
따라서 문서가 파편화되지 않도록 관리 필요하다. 데이터 카탈로그를 활용해 볼 수 있다.(dataHub라는 라이브러리) 카탈로그 시스템이 구축되어 있지 않다면 최소한 스키마에 코멘트라도 자세히 달아주자.
백엔드 엔지니어는 장애 없이 빠르게 대용량 트래픽을 처리하느냐가 중요하지만, 데이터 엔지니어는 대용량 데이터 관리가 중요하다.
백엔드 인프라와 마찬가지로 데이터도 분산처리가 필수다. 1개의 테이블에 수십억의 데이터가 존재할 수도 있기 때문이다.
그리고 데이터는 DB 데이터 관리가 전부가 아니다. Spark나 Hadoop과 같은 시스템을 사용하면 거기에 있는 데이터도 관리해야 한다.
그냥 모두 저장하는 것이 비즈니스를 지키는 가장 좋은 방법이다.
쇼핑몰 레거시에서 deleted_at을 찍는 게 아니라 아예 물리 삭제하는 로직으로 도배되어 있었다.
데이터가 남아있지 않았기 때문에 CS 대응할 때 굉장히 불편했던 기억이 있다. DB 데이터로 확인할 수 없었기 때문에 일일이 로그를 찾아 헤맸다.
하나의 컬럼에 하나의 맥락이 들어가 있어야 한다.
부끄러운 과거지만, 하나의 컬럼(시간 관련 컬럼)을 2개의 맥락(예약 신청에 관한 2개의 맥락)에서 사용하는 테이블을 설계한 적이 있다. 이렇게 설계된 테이블은 해당 데이터의 맥락을 정확히 파악할 수 없게 만든다.
좋은 서비스를 만들기 위해서라도 데이터에 대해 잘 알아야 합니다. 회사는 데이터를 가지고 의사결정을 진행합니다. 잘못된 데이터로 의사결정하면 손해가 발생하게 되니 데이터를 잘 관리하는 것은 필수입니다.
3-3. 클린 스프링: 스프링 개발자를 위한 클린 코드 전략
토비 님이 진행하신 세션이다.
경력이 쌓이면서 개발자는 점점 더 많은 고민거리를 가지게 되어 구현 속도가 느려진다?
그런데 왜 클린 코드를 작성하면 생산성이 떨어진다고 할까? 좋은 코드, 구조, 설계에 대한 과한 집착(유지보수성을 극단적으로 추구)
이 오히려 생산성을 떨어지게 만드는 것이다.
하지만 그런 고민으로 만들어지는 코드의 유지보수성은 생산성과 전혀 연관 없지 않다. 결국 유지보수성은 생산성으로 이어진다. 오히려 생산성만 극단적으로 추구하면 유지보수성이 떨어지기 때문에 둘 사이의 균형이 필요하다.
클린 코드를 추구해서 주석은 작성하지 않습니다.
코드가 클린하면 리팩토링할 필요가 없죠.
클린 코드는 버그가 적어서 테스트 코드가 없어도 되지 않나요?
클린 코드를 작성해야 해서 일정을 지킬 수 없습니다.
클린 코드 원칙에 위배되어서 리뷰를 승인할 수 없습니다.
'사람들이 클린 코드에 대해 오해하고 있구나', '사람들이 원칙만 추구하는구나'라는 생각이 들었습니다.
익숙한 기술로
핵심 기능이
동작하는
가장 단순한 코드를
리팩터링 하기 좋게 작성
시간이 없어서 테스트를 못한다?
회사에서 테스트를 하지 말라고 하면 어떻게 해야 하나요?
토비 님은 위와 같은 질문에 이렇게 답변하셨다고 한다. "그럼 테스트를 빨리 만들면 되지 않아요??"
이게 회사 사람들에게 체감할 수 있게 만드는 방법이다. 테스트를 만들면 더 빠르게 개발할 수 있다는 느낌을 받게 만들어야 한다. 그렇게 하려면 결국 훈련이 필요하고 연구를 해야 한다. 테스트를 더 빠르고 효과적으로 작성하고 개발하는 능력이 필요하다.
코드를 다루는 문제는 유지보수성, 생산성, 팀워크 삼체의 문제입니다.
교양 있는 개발자.
자신의 말을 하더라도 다른 사람의 기분을 나쁘지 않게 하는 것 말하지 않는 것이 교양있는 것이 아닙니다. 부정적인 피드백이라도 필요하다면 해야 합니다. 교양이 저절로 생기는 것은 아니기 때문에 훈련이 필요한 영역이에요. 항상 친절하세요. 동료에게, 자신에게요.
예를 들어, 클린 코드는 내가 행할 수 있는 친절 중 하나입니다.
3-4. 객체지향은 여전히 유용한가?
조영호 님이 발표를 진행해주셨다.
실제 코드 예시를 보여주시면서 발표 세션을 진행하셨다. 예시의 내용과 그 내용을 분석한 내용은 조영호 님이 직접 쓰신 책인 "오브젝트"와 거의 비슷했다. 나는 책의 내용을 복습하는 느낌으로 강의를 들었던 것 같다. (만약 객체지향에 입문하는 분이라면 꼭 한 번 들었으면 좋겠다.)
사실 강의 제목은 객체지향은 여전히 유용한가?로 지었지만 사실 올바른 질문은 "객체 지향은 언제 유용한가요?"라고 생각합니다.
만일 객체지향이 유용해 보이지 않는 개발자 분들이 있다면 그건 현재 하는 일의 맥락 때문일 겁니다. 나중에 시스템이 굉장히 복잡해졌을 때 객체지향이 도움이 될 수 있기 때문에 미리 공부해두는 것이 좋다고 생각합니다.
언제 유용한 지 항상 고민합시다.
그냥 도구 하나 배운다고 생각하는 것이 좋습니다. 이 툴이 언제 유용한지를 머리 속에 넣어두고 나중에 사용하면 됩니다. 코드를 만들 때 어떤 기술이나 패러다임이 유용한지를 질문하고 고민합시다.
코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정하세요 주니어 시기에 배워야 할 게 정말 많을 겁니다. 취사선택하고 싶은 마음도 알지만 그냥 배우고 고민하면 좋을 것 같습니다.
4. 질의응답
강연자 님들과 질의 응답을 할 수 있는 장소가 2층에 마련되어 있었다.
조영호 님의 "오브젝트"를 보면서 스터디를 진행하는 중이라 조영호 님에 대한 호기심이 증폭되어 있는 상태였고, 질의응답에 참여하면서 객체지향에 대한 인사이트를 좀 더 알아가고 싶었다. 질의 응답은 40분 동안 진행되었다.
Q. 다형성에 대한 질문
A. 타입이 확장된다는 전제가 있어야 합니다. 다형성이 if을 객체로 바꾸는 것이 아닙니다. (코드를 변경함으로써) 고통스러운 순간이 올 때 바꾸는 게 맞습니다. 절차적인 설계의 단점은 룰이 없다는 것입니다. 그런 단점에도 불구하고 다형성이 있는 게 무조건 좋은 설계가 아닙니다. 추상화는 비용이 매우 비싸기 때문에 그 선택을 하는 타당한 이유가 있어야 합니다.
Q. 함수형 프로그래밍에 대해 어떻게 생각하시는지
A. 함수형은 좋습니다. 유연합니다. 객체지향보다 조합하기 훨씬 좋다고 생각해요. 함수형은 좋지만 훨씬 복잡해요. 큰 구조는 객체지향으로 가져가고, 객체의 행위를 바꾸는 작은 단위들. 유연성이 필요한 부분들. 그 부분들을 함수형으로 짜는 걸 추천합니다.
함수형은 어렵다는 게 단점입니다. 함수의 단위가 작기 때문에 컨트롤하기가 어렵습니다.
Q. 외부 연동사를 사용할 때, 인터페이스를 사용한 추상화에 대하여 (현재 외부 연동사가 1개 있고, 새롭게 추가될 가능성이 있어서 추상화를 진행해야 하는지가 질문이었다.)
A. 될지 안될지 모른다면 그럼 안하는 게 맞습니다. 런타임에 기대되는 동작이 하나만 있는데 추상화되었는 코드를 보면 굉장히 당황스럽습니다. 변경하기 쉬운 설계는 인터페이스를 사용하는 게 아닙니다. 단순한 코드가 변경하기 쉬운 코드가 좋은 설계입니다.
A, B, C가 들어왔더니 중복이 있다? 그러면 그 때 추상화하는 것이 맞습니다. 처음부터 PG사의 요구사항을 알 수 없는데 그걸 공통화한다는 게 쉽지 않습니다. 추상화는 최대한 미루는 것이 맞습니다. 바뀌지 않는데 다형성을 사용하는 건 낭비입니다.
Q. 토비님은 계층 간에 인터페이스를 무조건 두는 것을 얘기하셨습니다. 여기에 대해 조영호 님은 어떻게 생각하시는지?
A. 제가 발표에서 진행한 내용은 유연성을 부여하기 위함이고 토비 님이 말씀하신 스프링의 인터페이스는 (강결합을 끊고 싶기 때문에) 디커플링을 하는 것이 목적입니다. 레포지토리 쪽은 인터페이스를 도입하는 것이 맞습니다. 외부의 요소를 사용하고 싶다면 인터페이스로 끊어주는 것이 맞습니다. 런타임에 뒤에 있는 모든 의존성을 다 가져오기 때문입니다. 내가 의존하고 있는 게 시스템 밖에 있는 것이라면 인터페이스를 사용해야 testability가 높아집니다.
Q. 그렇다면 서비스 레이어의 디펜던시를 끊는 게 맞나요?
A. 지금까지도 논쟁이 있는 부분 설계적으로 이상적으로 보이지만 그냥 통합테스트 하더라도 인터페이스 정의하지 않는 게 나은 것 같습니다.
Q. 팀원들이 잘 이해할 수 있는 설계를 위해 객체지향을 사용해야 하는데? 현재 절차지향적인 코드가 만연해서 팀원들에게 익숙합니다. 현재 딜레마에 빠져 있는데요. 어떻게 하는 게 좋을까요?
A. 절차적으로 짜는 게 좋을 것 같습니다. 절차적이던 객체지향적이던 스타일이 다 다르면 조직에게 어렵습니다. 동료들이 같은 컨벤션으로 코드를 짜는 게 좋습니다.
Q. 설득을 하고 싶다면?
A. 굉장히 힘든 길이 될 거에요. 객체지향으로 짜는 게 왜 좋은지를 설명해야 합니다. 그런데 이것이 설득되려면 듣는 분들도 학습이 되어 있어야 합니다. 회사의 상황은 책과는 다릅니다. “책에서 이게 좋대요”보다는 현재 코드와 도메인을 잘 파악하고 독립적으로 할 수 있는 부분을 병합하는 것이 좋지 않을까? 생각합니다.
Q. 조영호님은 새로운 패러다임을 학습할 때 어떻게 하시나요?
A. 패러다임을 공부할 때, 저는 패러다임 자체를 공부하지 않고 언어나 프레임워크를 공부합니다. 그냥 코드를 만들어봅니다. 예전에 만들어놓은 코드를 그대로 가져와서 새로운 언어나 프레임워크로 새롭게 만들어봅니다. 학습할 때 가장 좋은 방법은 동료들과 얘기하는 것입니다. (지금은 주변에 연차가 비슷한 동료들이 얼마 안 남았지만) 비슷한 연차의 동료 서비스 코드에 대해 얘기하면서 배우는 것이 많습니다. 그런 것이 어렵다면 책이나 강의, 자료 같은 것을 보고 습득을 하는 것이 좋지 않을까요? 맞는지 안 맞는지 모르더라도 학습을 해놓는 것이 좋습니다.
Q. 도메인을 나누는 기준은 무엇인가요?
A. 도메인은 논리적인 단위입니다. 시스템 단위가 아니라 풀어야 하는 문제를 풀 수 있는 논리적인 단위로 나뉘어져야 합니다. 주문과 결제는 다른 도메인이라는 것을 직관적으로 알 수 있을 겁니다. 주문과 결제가 해결하려는 문제가 각자 다르기 때문입니다. 상품도 도메인이 나뉩니다. 상품 등록 상품 대행 상품 전시 등등등 하지만 시스템의 사이즈가 작으면 다른 도메인이어도 같은 시스템 안으로 묶을 수도 있습니다. 결국 트레이드오프의 문제입니다.
5. 네트워킹 세션
조영호 님과 질의응답을 끝내고 네트워킹 세션에 참여했다. 각각의 스탠딩 테이블 여러 개발자들이 모여 이었다. 각자 사탕을 하나씩 받은 것처럼 보였고 거기에는 질문이 적혀 있었다.
내가 갔을 때는 이미 시간이 20분 밖에 남지 않아 스탠딩 테이블에 참여하긴 어려웠다. 대신 회사에서 받은 개발자 인터뷰하기 과제를 수행했다. 현재 회사에서 프론트엔드 개발자를 채용하고 있었기 때문에 총 3분의 프론트엔드 개발자를 인터뷰했다. 인터뷰를 통해 개발자들은 어떤 회사에 가고 싶어하는지, 어떤 문화를 원하는지 파악해볼 수 있었다.
