소프트웨어

본문은 교보문고 7호 - 개발하는 마음 에 기고한 글입니다. 안녕하세요. 저는 의료 도메인의 문제를 해결하는 헬스케어 스타트업 굿닥에서 웹 프론트엔드 엔지니어로 일하고 있는 오원종입니다. 저는 비전공자 출신 개발자입니다. 대학에서는 신소재공학을 전공했고 군 전역 후 스물다섯이라는 다소 늦은(당시에는 그렇게 생각) 나이에 프로그래밍에 입문하게 되었습니다. 개발을 시작한지는 약 5년, 개발자로 커리어를 쌓은지는 이제 3년이 되어가는 시점에서 저는 지금 적성에 잘 맞는 일을 하고 있다고 생각해서 그 점은 정말 다행이고 감사합니다. 이번 글에서는 제가 어떠한 계기로 프로그래밍을 시작하게 되었는지 저에 대한 소소한 이야기를 들려드릴까 합니다. 스타트업에 관심을 가지다 제가 군 전역을 한 2016년 여름, 저는 여..

Adios 2022 (Part 1. 회사편)에 이어서 두 번째 회고록을 작성해 본다. 개인편 회고록은 크게 개발 관련, 개발 외적인 내용 관련으로 나누어서 작성해 본다. 개발 넥스터즈 올해 1월부터 2월까지 넥스터즈 20기 활동을 했다. 넥스터즈는 두 번째 기수 활동이었는데, 이 때도 마찬가지로 코로나로 인해 전면 온라인으로 세션을 진행했었다. 여담이지만 이 때 내가 첫 세션 시간에 결혼식 축가와 겹쳐서 불참을 했었는데, 이 날이 팀빌딩 날이었다. 사전에 운영진 분들께 다 양해를 구하고 부탁을 드리고 하긴 했지만, 결혼식 축가 준비하면서 계속 불안한 마음을 지울 수가 없었다. 너무나 감사하게도, 정말 좋은 분들과 팀빌딩이 되어서 프로젝트를 두 달동안 재밌게 할 수 있었다. 우리는 팬시마우스라는 서비스를 ..

올 해도 어김없이 한 해가 마무리가 되는 시점이 왔다. 나는 연례 행사로 연말에 한 해를 정리하면서 회고록을 쓴다. 올 해도 마찬가지로 2022년 회고록을 써보려고 한다. 정리를 하다 보니 내용이 많아서 Part 1. 회사편, Part 2. 개인편 으로 나누어서 회고를 작성해 보려고 한다. 지난 회고록이 궁금하다면? Adios 2021 Adios 2020 Adios 2019 올해 여름 회사에서 프로필 사진을 다시 찍었다. Table of contents DropBox Career Framework SWE 2 기준표 점검 잘 한 부분 잘 못한 부분 프로덕트 (Product) 비대면진료 서비스 V4 전사 마이그레이션 B2B 웹 B2C 모바일 비즈니스 (Business) 시리즈 A 투자 유치 안드로이드 의료 ..

사내에서 디미터 법칙을 주제로 작은 세미나를 준비했었는데, 그 내용을 정리해 보았습니다. Table Of Contents 디미터 법칙(Law Of Demeter) 결합도 통제(Coupling Control) 정보 은닉(Information Hiding) 메시지와 인터페이스 참고 자료(Reference) 디미터 법칙 위키피디아에서는 디미터 법칙에 대해 다음과 같이 정의하고 있다. 💡 The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specif..

6.1 아키텍처 특성 측정 아키텍처 특성을 정의할 때 흔히 다음과 같은 문제들이 발생한다. 물리학이 아니다 : 아키텍처 특성은 대부분 의미가 모호하다. 정의가 너무 다양하다 : 부서마다 정의를 통일하기 전까지는 원활한 소통이 어렵다. 너무 복합적이다 : 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다. 이 세가지 문제들은 아키텍처 특성을 객관적으로 정의하면 모두 해결된다. 6.1.1 운영적 특성 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석은 미묘하게 갈릴 때가 많다. 예를 들어 특정 요청에 대한 평균 응답 시간을 측정할 경우, 어떤 경계 조건 때문에 1%의 요청이 다른 요청보다 처리 시간이 10배 오래 걸리면 어떻게..

4. 아키텍처 특성 정의 아키텍트는 개발팀과 함께 도메인 또는 비즈니스 요구사항을 정의할 수 있지만, 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행한다. 아키텍처 특성은 다음 세 가지 기준을 충족한다. 비도메인(nondomain) 설계 고려 사항을 명시한다. 어플리케이션 설계 시 어플리케이션으로 처리할 일은 구체적인 요구사항으로 정리한다. 아키텍처 특성은 이 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시한다. e.g. 일반적으로 어느 정도의 어플리케이션의 성능은 중요한 아키텍처 특성이지만, 요구사항 정의서에는 적혀있지 않는 경..

플랫폼마다 제공하는 코드 재사용 메커니즘은 제각각이지만, 연관된 코드를 모듈(module)로 묶는 방법은 모두 지원한다. 본인이 선택한 개발 플랫폼에서 모듈성과 그것을 구현한 수 많은 코드를 이해하는 것은 아키텍트에게 대단히 중요한 일이다. 우리가 아키텍처를 분석해야 할 (메트릭, 피트니스 함수, 시각화 등) 많은 도구가 이 모듈성에 기반하기 때문이다. 모듈성은 일종의 구성 원리(organizing principle)이다. 아키텍트가 대충 아무렇게나 조각들을 이어 붙여 시스템을 설계하면 무수한 난관에 봉착해 옴짝달싹 못 하는 시스템이 되어 버린다. 물리학에 비유 하자면, 소프트웨어 시스템은 엔트로피(entropy, 무질서)가 증가하는 방향으로 움직이는 복잡한 시스템을 모델링한다. 질서를 유지하려면 물리적..

아키텍처의 사고는 크게 네 가지로 나뉜다. 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하면 개발팀과 어떻게 협력해야 할지 아는 것 어느 정도 기술의 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것 아키텍트는 다른 사람들이 보지 못하는 해결책과 가능성을 떠올릴 수 있다. 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고 조율하는 것 비즈니스 동인(business driver)의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것 2.1 아키텍처 대 설계 아키텍트처럼 사고한다는 건 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것이다. 전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 이 전통적인 아키..